2022年末,AUTOSAR联盟发布了最新版本标准R22-11。
2023年3月14-16日,在2023第四届软件定义汽车论坛暨AUTOSAR中国日上,AUTOSAR中国技术官钱贾敏针对R22-11新增的三部分内容进行了介绍。包括Timing(时序)技术;针对V2X和SOVD远程诊断的技术规范;车内通信标准以及协议的相关规范。钱贾敏表示,本次更新共分配并完成了2029个标准开发任务,包含334618行AP平台Demo代码,旨在为未来智能驾驶定义一套统一的E/E系统架构。
钱贾敏 | AUTOSAR中国技术官
以下是演讲内容整理:
下图涵盖了R22-11的新技术,概括起来有三大部分:第一部分Timing时序技术,这是AUTOSAR突出介绍的新基础方向;第二部分关于V2X和远程诊断方面的技术规范;第三部分集中在车内通讯相关的通信标准以及协议规范。
图源:AUTOSAR中国
Timing时序技术
对人来说,时间是非常重要的因素,对汽车而言也是如此。尤其是面向域融合的电子电气发展方向,原来分布在各个ECU中的单一功能会集成到一个区域控制器里。如何保证那么多的功能实时、确定、正确的执行,时序技术非常重要。
在AUTOSAR内部专门负责时序技术标准开发的工具组叫资源工作组,WG-RES工作组将资源集中在时间资源上,也是计算资源上。时序技术和功能安全、信息安全一样,贯穿于整个ECU软件开发的生命周期,从最开始的系统架构设计到中间部分的软件实现,再到最后系统的验证测试都离不开它。在R22-11版本里AUTOSAR重点补足了红色关于时序方面的规范信息。
图源:AUTOSAR中国
图源:AUTOSAR中国
时序相关的信息规范主要分为三大部分:
第一部分,我们称之为TAD。这块涉及到开发生命周期的两头——系统设计和系统验证部分,借助今天市面上已有的时序工具,支撑前期系统时序的仿真以及后阶段时序的测量分析工作。
第二部分,在AUTOSAR 4.0就已经有的TIMEX规范,主要关注时序在AUTOSAR里建模的规范。我们知道建模里不只定义模式,还会定义时序相关的参数,这个参数会在规范里得到描述。
第三部分,主要是关于时序记录和读取的规范。我们测时序要打时间戳,靠调用API来记录,在CP上主要通过DLT模块,在AP上主要通过Log & Trace。另外记录下的时序数据怎么往外传,时序工具怎么读取和显示,这些都定义都在ARTI规范里。
图源:AUTOSAR中国
举个时序技术的例子,电动汽车从油门踏板踩下去到最后电机把扭矩输出的过程,从系统功能的需求来讲,要求响应时间在150毫秒内。这个系统需求时序怎么设计?很熟悉的是系统架构设计,首先要定义架构,做虚拟功能总线的开发。我们会把150毫秒系统功能的过程分解成三个软件功能,一是传感输入,专门采集油门踏板信号的功能;二是功能处理和计算;三是执行器输出。每个功能又可以分解出多个Runnable。
但在复杂多核系统上,拆分出来的Runnable会运行在不同的核上,有可能还会运行在不同的SOC上。如何确保每个Runnable按照我预想的顺序来执行,以及如何确保整个系统功能在要求的时间内完成?我们必须按照规范把整个顺序关系、事件链建起来,建完后对每个Runnable的时间资源进行定义。定义完之后,TAD第一步要借助工具,对整个系统功能进行仿真;仿真通过后把软件实现出来,在实现的过程中每个部分都要调用AUTOSAR里面的API记录时间戳,在AP和CP里有固定的模块记录时间戳,可以同时在工具里面输入ARTI描述文件测量整个系统的时序。最后在工具里把甘特图形式的运行过程显示出来,这样大家可以很方便的分析整个系统时序运行的正确与否,和原来设计的是否一样,这就是整个时序设计的过程。时序技术从源头设计时就需要考虑使用工具进行仿真和测量,以更好的应对复杂系统运行的挑战。
V2X与SOVD标准
针对V2X,AUTOSAR标准化面临两个主要的挑战。
一是不同国家和地区对V2X的法规以及相关的协议不同,协议的差异带来很大挑战。
二是不同天线ECU功能的差异。目前市面上的天线ECU可以分成两类,第一类是远程天线ECU,这类天线ECU的特点只负责和汽车、云端之间的报文数据收发,可以通过各种协议,比如MQTP,但不负责报文的过滤和信号的提取工作。第二类是主动天线ECU,这类天线ECU的功能比较强大,除了与云端的数据收发外,还要支持数据的过滤、报文中信号的提取以及打包等工作。所以对不同天线ECU功能的分配也是AUTOSAR对V2X标准化重要的挑战。
应对两个主要挑战,第一AUTOSAR在R22-11中开发了新的V2X remote antenna ECU的规范。在远程天线ECU中,不同的厂商远程V2X ECU与云端之间数据收发的协议完全不同,不同协议的数据包交给车内的ECU处理比较麻烦,针对这种场景AUTOSAR专门开发了一个V2xRAL层,将V2X云端之间的报文做一些处理,处理成AUTOSAR标准的,在内部以太网传送的格式规范,将来其他ECU的开发将得到统一规范格式的AUTOSAR V2X报文。
图源:AUTOSAR中国
第二主要是V2X Data Manager模块,用来屏蔽不同V2X国家和地区协议的差异,以及信号标准的差异。
图源:AUTOSAR中国
再切换到远程诊断部分,SOVD全称是面向服务的车辆诊断功能。是AUTOSAR和ASAM组织合作拓展车辆和云端之间通信的规范。
AUTOSAR如何支撑SOVD在AUTOSAR上的落地?R22-11中主要对AUTOSAR AP里的DM做了更新。这个模块主要负责诊断管理,专门支持SOVD远程诊断服务。通过这种修改让整个AUTOSAR的AP能够支撑SOVD技术。
图源:AUTOSAR中国
车内通信标准
刚才讲到了车云通信,接下来看车内通信。
首先,车内通信部分AUTOSAR R22-11变更的部分是关于SAME/IP的SD。之前的版本中在AP和FO里都有描述,两者描述存在冲突情况,所以在R22-11版本进行了统一,让两者协议更一致。
第二,发布了ara::com的解释性API说明文档,对大家理解使用有很大的帮助。
第三,信息安全是非常重要的领域,R22-11里AUTOSAR加入了这个MACSec部分,发布的协议还是draft的版本。
接下来其他升级的部分包括了CAN XL、CP平台对DDS的支持,还有CP平台上的确定性TSN,更多考虑了定时周期性的传送,还包含优先级的通讯。
图源:AUTOSAR中国
总体而言,AUTOSAR对整个R22-11新的版本发布投入了巨大的精力,给大家分享一些重要的数字。
“2029”,AUTOSAR为了发布整个R22-11总共分配了2029个版本;
“1440”,在任务开发的时候记录了1440次的变更;
“182”,整个R22-11版本发布涉及182个AUTOSAR合作伙伴参与,需要群策群力;
“334618”,代表AP平台Demo代码共334618行;
“13”代表我们有13个新技术概念,并把它变成最终的标准发布出来;
“2”大家都知道,我们有两条主要的产品线;
“1”是我们的愿景,整个汽车行业有一套统一标准化的E/E系统架构。
相关文章