区域架构下信号服务转换与VehicleAPI

2022年8月5日，在盖世汽车与AUTOSAR联合主办的2022第三届软件定义汽车论坛暨AUTOSAR中国日上，Etech /AUTOSAR技术经理谢宏建以区域架构下的信号业务转换为主题，详细介绍了区域架构的发展现状以及如何实现区域架构下的信号业务转换。针对AUTOSAR即将推出的车用ApI标准化，谢宏建表示，“谁能开发出一个被主机厂和供应商广泛接受的车用API，谁就赢得了整个市场！”组织以下演讲内容:

地域性建筑的发展现状及演变趋势

我们先来看看什么是地域建筑。目前整个汽车行业都在进行新四化:一是电动化。传统的发动机和变速箱已经被动力电池、驱动电机和电控系统所取代，经过十几年的发展已经趋于成熟。二是互联互通。汽车不再是一个孤岛，它将与万物互联。再次，智能，一般指自动驾驶技术，也是目前最热门的话题。例如，在这三天的会议中，许多话题都集中在自动驾驶技术上。最后，个性化是以用户为中心的延伸，随着汽车工业的发展，消费者对个性化的要求会越来越高。汽车新四化带来技术和商业模式的创新，同时也给整个主机厂和供应商带来巨大的挑战:如何快速更新软件和功能？如何开展跨区域合作？如何基于大数据提升用户体验？如何提高资源效率，包括计算资源和带宽资源？如何增强信息安全和功能安全？如何降低整个电机架构的复杂度？

面对诸多挑战，我们已经达成共识，要从建筑的创新入手。详细查看新架构。从硬件维度来说，为了提高可扩展性，提高总线通信效率，减少线束，所有的i/o资源都会按照区域重新划分，打破功能界限，最终形成区域控制器。从应用层来看，整车的计算资源将进一步集中在整车计算机上，未来所有的应用都可能部署在整车计算机上，甚至运行在云端。

基于这两个维度，我们发现区域控制器将扮演三个重要的角色:第一，作为区域的输入输出中枢，它将连接所有的传感器和执行器，实现最基本的硬件逻辑。其次，它将作为区域的数据中心，实现区域路由和网关的功能。然后作为配电中心，基于智能电网配电模块，实现整个区域内传感器、执行器、ECU功率的动态分配。

我们可以通过以下几个方面来看地域建筑在行业中的发展。

首先，硬件的集成。新架构需要减少ECU的数量和线束的长度。只有将所有区域的硬件功能资源集中到区域控制器上，才能达到目的。其次，软件的集成。目前很多主机厂已经实现了整车OTA功能。未来要看区域相关功能和应用层是否搬到整车电脑上。第三是区域控制器的数量。所有OEM都可以在架构中部署2-6个区域控制器。在配电方面，需要采用传统的、机械式的保险丝盒或者升级为智能配电模块，实现所有i/o资源的动态配电，实现电源冗余。此外，千兆以太网、新型CAN XL、CAN FD等协议将用于骨干网和子网，实现整个通信网络拓扑。最后，重点讨论智能驾驶和智能驾驶舱的子节点、数据和功率分配是否集成到区域控制器中。

AP和CP之间的通信差异

至此，我已经简单介绍了区域控制器的特点。下面我们来看看AUTOSAR如何实现区域控制器中的信号服务转换。首先，为什么需要实现信号和服务的转换？在E/E架构中，区域控制器和整车计算机起着最重要的作用。区域控制器本身主要是一个微控制器，经典的AUTOSAR平台会在上面运行。Adaptive AUTOSAR的平台将有可能运行在整车计算机上，实现动态服务的通信和OTA的功能。区域控制器和整车计算机之间需要通信，如何实现CP和AP之间的通信就是如何在软件中实现。之所以需要AP和CP之间的通信，是因为运行在AP上的功能应用软件肯定需要获取CP软件产生的车速、温度等传统信号。反过来，CP软件需要实现一些功能逻辑，获得功能软件应用层下发的命令服务。

我们来看看AP和CP的区别。从通信方式来看，CP软件是以信号的方式实现通信的，是静态配置的。就整个开发流程而言，首先需要定义通信矩阵，生成相应的配置，然后做相应的代码生成、调试、运行、测试和验证，最后部署到ECU。一旦部署在ECU中，整个通信属性就固化了，一旦需要改变信号，就会涉及到整个过程。在AP端，通信方式不同。它基于服务模式，可以动态配置。比如我们访问一个网站，我们只会在访问的时候和电脑的服务器进行通信。当不被访问时，计算机不需要定期与服务器通信。从AP软件的角度来看，我们可以在不改变整个操作系统的情况下，动态添加客户端和服务器。基于AP和CP之间通信协议不同，如果要实现CP和AP之间的通信，必须在一定的层次上实现信令和业务转换的功能。

实现信号业务转换的四种方案

结合新的架构，如果要实现信号和业务的转换，基本上有以下几种方案:

首先是在传统ECU中部署信号和服务的转换。这时可以发现，传统ECU是基于服务与区域控制器、区域控制器、整车计算机进行通信的。实际上，这个方案基本上是不可能实现的。因为传统ECU是供应商提供的完整解决方案，增加基于服务的通信方式会非常昂贵。而且传统ECU本身没有以太网的通信协议栈，计算资源有限，很难实现这个功能。

第二种方案是将信号服务转移到区域控制器。传统ECU与区域控制器的通信是基于信号的方式，而区域控制器与整车计算机的通信是基于服务的方式。这个方案目前很好理解。

第三种方案是将信号服务方案部署到整车电脑的AP上。传统ECU通过信号与区域控制器通信，区域控制器通过信号与整车计算机通信。AP会将信号转换成基于附加模块的服务，并将它们提供给应用层。这个方案也是可实施的。

最后一种方案是直接将信号服务部署到应用层，这显然会在应用层造成巨大的问题，这种方案基本不会实现。

如何在AUTOSAR上实现信号与业务的转换

我们来看看第二个和第三个方案是如何在AUTOSAR上实现的。

如果s2s部署到区域控制器，相应的，由于AP侧已经有ara::com，这是一个协议栈，有DDS，一些/IP等动态服务通信，AP侧不需要做任何改动。但是在CP上实现SOME/IP的协议功能，有SD模块，BswM模块，SOME/IP TP模块等。除了相关的协议栈，整个SOME/IP通信协议是结合应用层实现的。

有了这个方案，最大的好处就是CP和AP都支持SOME/IP协议，所以可以基于厂商的工具链实现通信协议栈。当然，这种方案也有很多缺点:如果在CP端部署某个/IP模块，会涉及到很多子模块，整个实现过程相对复杂。另外，这种方案对于相同的信息需要双重维护，一个是基于信号角度的信息维护，一个是基于服务的信息维护，会造成信息冗余，影响信号传输的实时性。

如果把s2s部署到整车电脑上，从CP就可以实现基于信号的传输模式。对于区域控制器，可以遵循传统的开发流程，不需要额外部署一些/IP协议栈，就可以将所有信号传输到整车计算机。在这种方案下，AP实际上需要部署额外的s2s模块:需要通过操作系统的TCP和UDP协议采集整个以太网报文，通过COM的相关协议栈对信号进行分析，获得相应的信号位置和长度信息，然后需要额外的s2s功能模块将所有信号转换成服务。

这种方案的优势在于，不仅可以实现信号实时输出到整车计算机，还可以通过区域控制器中CP AUTOSAR的PduR模块，将传统的全区域控制下的CAN/LIN信号直接发送到整车计算机，可以高效保证通信的实时性。缺点是AP的工具链端需要部署s2s的功能。

实现该方案的关键方法论是提供信号的通信矩阵和一些/IP相关的描述文件，通过ETIC的VRTE自适应工具对信号和业务进行映射，最终生成s2s的功能模块。

作为全球领先的嵌入式软件开发和汽车信息安全解决方案和服务提供商，Etech可以提供完整的AP和CP解决方案。ISOLAR是ETIC推出的解决方案，有三个主要功能。ISOLAR-A用于开发应用层和系统配置，包括系统的通信矩阵和诊断描述文件。ISOLAR-B可以配置CP相关的软件协议栈。最近增加了等值线自适应等功能，可以实现AP的配置和开发。然后基于Etech的同一个ISOLAR工具，可以实现信号和服务的配置生成和映射，更容易实现s2s解决方案。

刚才我已经介绍了如何在AUTOSAR上实现信号和服务的转换。对于这样的解决方案，在车载通讯和车载电脑通讯方面很有帮助，但是对于车外通讯没有帮助。

汽车API的必要性

那么如何实现车外的生态交流，就需要看一看车载API了:

目前汽车行业有两个趋势。首先是互联互通。整车不再是一个孤岛。它需要与云互联。通过云端可以实现OTA和远程诊断，实现车辆状态查询和车辆控制。除此之外，汽车还需要通过蓝牙与手机、手表互联，通过V2X协议与交通设施和其他车辆进行通信，从而形成一个完整的交通智能网络。还可以通过MQTT协议与智能家居、智能城市进行通信，构成了整个IOT生态系统。

在这种趋势下，汽车和手机最大的区别就是手机协议明确，但是汽车有很多车内外的通信协议。如何打通不同的协议？这是我们面临的最大挑战。

第二个趋势是国内外都在打造自己的操作系统，即OEM。OS一般来说，OEM。OS针对的不仅仅是车内的软件系统，还有云端的软件系统。

在汽车中，我们知道最底层的硬件是微控制器和微处理器，甚至是包含两者的SOC。硬件上层是启动程序，烧录更新引导程序；然后是hypervisor，实现区域隔离和系统隔离。上层可能涉及芯片中不同内核、不同域之间的通信软件，再往上可以根据功能分为不同的基础软件或中间件，如以太网交换机软件、信息安全软件、经典autosar软件、整车计算机中的自适应autosar软件、自动驾驶相关软件、智能驾驶舱相关软件等。然后就是各种应用软件。

这是车厢的尽头。让我们简单看一下云。云可能包含一些核心服务、平台服务、数字孪生服务等。它还将包括生态系统的开放开发端口；也可以运行一些与车辆各种功能域相关的软件和第三方软件。车载API的目的就是在此基础上实现所有应用软件的互操作。Etech提供各种开发端口，未来将进一步把应用软件部署到云端，支持第三方服务。

车云未来的集成需要车载API的支持，需要满足以下要求:一是明确需要开放的、已知的接口，帮助不同的应用层实现交互和复用。二是高，容易集成。第三，不能给代工带来额外的工作。

COVESA在第十三届AUTOSAR开放大会上为AUTOSAR提出了标准化概念，包括三个方面:一是定义了通用数据模型和服务模型，实现了不同设备间信息描述的统一。二是标准化相应的数据和服务。事实上，国内很多机构和企业都在尝试制定标准化的数据和服务。难点不在于技术，而在于如何让更多的主机厂和供应商达成数据和服务标准化的共识。三是相应软件基础协议栈的支持，帮助实现跨通信交互和数据转换。

回到通用数据服务模型，covesa采用的vss和vsc语言。vss的全称是车辆信号规范，来源于2016年w3c汽车工作组发布的首个公开工作草案。在设计之初，就希望车载信息娱乐系统和本地车载网络中运行的应用程序能够访问车辆信号和其他数据。所以vss主要是针对车辆信号，按照功能对车辆信号进行分类。

例如，这是一个树形信号分类的例子。绿色的原点代表分支，整车信号可以根据功能域分为不同的分支。分支的末端可以是信号属性、传感器信号或致动器信号。Vss用yaml语言描述，方便人类读写。其次，它可以很容易地被各种工具解释，并且可以生成其他类型的文件。然后，基于vss标准，所有相关从业者可以就统一的信号描述和文件类型达成一致，从而实现更容易的信号信息交互。也为配套工具的开发做了很好的准备。

展望未来，汽车可能会像手机一样，成为一个更加融合的智能设备。作为应用程序开发人员，他们通常不需要关心车辆模型和系统之间的差异。应用程序开发完成后，它们可以部署到任何车辆上，并使用相关功能。从这个角度来看，车辆API将发挥关键作用。所以谁能开发出被主机厂和供应商广泛接受的车用API，谁就赢得了整个市场！谢谢大家！