AUTOSAR中国技术官钱贾敏：R22-11技术信息解读

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系统架构。