易特驰/AUTOSAR技术聚焦区域架构下的信号服务转换，对区域架构的发展现状，如何在区域架构下实现信号服务转换做了详尽地介绍，针对AUTOSAR即将推出的Vehicle API（整车接口）标准化，表示：“谁能够开发出来让OEM和供应商广泛接受的Vehicle ApI，谁就会赢得整个市场！”以下为演讲内容整理：

区域架构的发展现状与演进趋势

先来看一下什么是区域架构。目前整个汽车行业正处于新四化的变革当中：首先是电器化，动力电池、驱动电机和电控系统取代了传统的发动机和变速箱，经过十几年的发展已经趋于成熟。第二个是互联化，汽车不再是一个孤岛，它将会与万物互联。再次是智能化，智能化一般指的是自动驾驶技术，也是当前最热门的话题，比如这三天的会议，很多话题都是围绕自动驾驶技术。最后是个性化，个性化是以用户为中心的延伸，随着汽车行业的发展，消费者对于个性化的需求会日益强烈。汽车新四化带来技术和商业模式的创新，同时也为整个OEM和供应商带来了巨大的挑战：如何快速的更新软件与功能？如何进行跨区域合作？如何基于大数据提升用户的体验？如何提升资源效率，包括计算资源和带宽资源？如何增强信息安全和功能安全？如何降低整个电机架构的复杂度？

面对诸多挑战，我们达成的共识是从架构的革新入手。具体看一下新的架构，从硬件维度看，为了提高扩展性、提升总线通信效率、减少线束，所有i/o资源会根据区域重新划分，打破功能边界，最终形成区域控制器。从应用层看，整车的计算资源会进一步向整车电脑集中，将来所有的应用程序都有可能部署到整车电脑上，甚至会上升到云端运行。

基于这两个维度，我们发现区域控制器会扮演三个重要角色：首先作为区域的输入输出中心，会连接所有的传感器、执行器，实现最基本的硬件逻辑。其次会作为区域的数据中心，实现区域路由、网关功能。再是作为电力分配中心，基于智能电网分配模块，实现对整个区域的传感器、执行器和ECU电源的动态分配。

我们可以通过以下几个方面看看行业内区域架构的发展状况。

首先是硬件的集成度，新的架构要减少ECU的数量和线束的长度，只有将所有区域下的硬件功能资源都向区域控制器上进行集中，才能实现目的。其次是软件的集成度，目前许多OEM都实现了整车OTA功能，未来还要看是不是把区域相关的功能和应用层上移到整车电脑上。第三是区域控制器的数量，所有的OEM在架构上都可以部署2-6个区域控制器。电力分配方面，是采用传统的、机械式的保险盒，还是升级到智能配电模块，来实现所有i/o资源的动态电力分配，并且实现电力冗余。此外，在骨干网和子网上会采用千兆的以太网、新的CAN XL，CAN FD等协议组合，来实现整个通信的网络拓扑。最后是针对智能驾驶和智能座舱的子节点、数据和电力分配，是否集成到区域控制器当中。

AP和CP通信的差异性

到此我已经简单介绍了一下区域控制器的特点，下面我们再来看一看如何在区域控制器当中以AUTOSAR的方式实现信号服务的转换。首先，为什么需要实现信号和服务的转换。E/E架构中，区域控制器和整车电脑扮演着最为重要的角色，区域控制器本身以微控制器为主，上面还会运行着Classic AUTOSAR（CP）平台。在整车电脑上大概率会运行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，SOME/IP等动态服务通信的协议栈，因此AP端不需要做任何改变。但要在CP端实现SOME/IP的协议功能，除了需要部署相关协议栈之外，还要有SD模块，BswM模块，SOME/IP TP模块等等，并结合应用层实现整个SOME/IP的通信协议。

采用这样的方案，最大的优势就在于CP端和AP端都支持SOME/IP协议，那么通信协议栈基于供应商的工具链就能实现。当然这个方案也存在很多不足：如果在CP端部署SOME/IP模块，它会牵扯到很多子模块，整个实施过程相对来说比较复杂。此外，这一方案针对同样的信息需要两重维护，一个是基于信号角度维护信息，还要基于服务进行维护，会造成信息的冗余，影响到信号传输的实时性。

如果将s2s部署到整车电脑端，从CP端可以实现基于信号的传输方式，针对区域控制器可以沿用传统的开发流程，将所有信号转到整车电脑端，不需要再额外部署SOME/IP协议栈。这一方案下，AP端实际还需要部署额外的s2s模块：需要通过操作系统的TCP，UDP协议，将整个以太网的报文收集上来，通过COM相关协议栈进行信号的解析，获取对应的信号位置和长度信息，再需要额外的s2s的功能模块，将所有信号转换成服务。

这一解决方案的优势在于，不仅能够实现信号向整车电脑输出的实时性，还能将整个区域控制下面传统的CAN/LIN信号，经过区域控制器中CP AUTOSAR的PduR模块直接给到整车电脑，可以高效地保证通信的实时性。缺点是AP的工具链端需要部署s2s的功能。

该方案得以实现的关键方法论是，提供信号的通信矩阵和SOME/IP相关的描述文件，经过易特驰的VRTE Adaptive工具进行信号和服务的映射，最终生成s2s的功能模块。

易特驰作为全球领先的嵌入式软件开发与汽车信息安全解决方案和服务提供商，能够提供完整的AP和CP的解决方案。易特驰推出的解决方案ISOLAR带有三个主要的功能，ISOLAR-A 被用于应用层、系统的配置开发，包含系统的通信矩阵和诊断描述文件。ISOLAR-B可以做CP相关软件协议栈的配置。最近又增加了ISOLAR Adaptive这样一个功能，可以实现AP的配置开发工作。那么，基于易特驰的同一ISOLAR工具，就可以实现信号、服务的配置生成，信号和服务的映射，更加容易的实现s2s解决方案。

刚才向大家介绍了如何在AUTOSAR上实现信号和服务的转换，对于这样的解决方案，它在整车通信、车载电脑通信上非常有帮助，但对于车外通信没有任何的帮助。

Vehicle API的必要性

那么如何实现车外生态通信，需要看一下Vehicle API：

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

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

趋势之二是，无论国内还是国外都在打造属于自己的操作系统，即OEM.OS。总的来讲，OEM.OS 所针对的不仅仅包含了车端的软件系统，还包含了云端的软件系统。

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

这是车端， 我们再来简单看下云端， 云端有可能会包含一些核心服务，平台服务，数字孪生服务等； 还会包含生态系统开放开发端口； 那还有可能会运行一些和车辆各个功能域相关的软件和第三方软件。 而vehicle API的目的则是基于此实现所有应用软件的互联互通功能。易特驰提供各种各样的开发端口，将来会进一步将应用软件部署到云端，支持第三方服务。

车云一体化的未来需要Vehicle API做支撑，Vehicle API需要满足以下要求：第一是明确需要开放和已知的接口，帮助不同的应用层实现交互、复用。第二是高度、易于集成。第三是不能给OEM带来额外的工作。

COVESA在第十三届AUTOSAR开放大会上提出了针对AUTOSAR的标准化理念，包含三个方面：第一定义了通用数据模型和服务模型，实现不同设备之间信息描述的统一。第二是标准化相应的数据和服务，实际上，国内也有很多组织和企业尝试去制定标准化的数据和服务，难点并不在技术上，而在于如何让更多的OEM和供应商达成标准化的数据和服务共识。第三是相应的软件基础协议栈的支撑，去帮助实现跨通信的交互、数据转换。

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

比如这就是一个树状信号分类示例。 绿颜色的原点代表分支，可以将整车信号按照功能域划分在不同的分支。 分支的末端可以是信号的属性，传感器信号，或者执行器信号。 vss采用yaml语言来进行描述，方便人类读写。其次，可以容易被各种工具进行解读并生成其他类型文件。 那么基于该vss标准，可以让所有相关从业者在统一信号描述，及文件类型上达成一致，从而实现更加容易的信号信息交互。为配套工具的开发也做了很好的准备。

有了vss和vsc， 我们还是无法解决软件的互联互通，比如云端的信号和服务基于HTTP协议给到车载电脑，车载电脑内部是以someip通信为主，甚至还包含dds协议。 我们还需要配套的工具和软件来实现不同协议之间的转换。

在autosar concept703中提到了一个解决方案：该方案由配置工具和网关模块构成。在autosar端，信号和服务采用vss vsc描述语言。 autosar工具商基于vss和vsc的输入转换成应用层所需要的arxml文件实现符合ara com的通信接口。 同时autosar工具还需要将vss vsc信息转换成需要满足http协议或者其他协议的接口文件。 用于实现相关协议信息的解读。 基于此，还需要特定的网关中间件来实现不同协议之间的转换。 最终实现应用层与通信协议的完全解耦。

展望未来，汽车有可能像手机一样，成为一个更加趋同的智能设备，作为应用开发者，往往不再需要关心车型差别和系统差异，应用开发出来以后都能够部署到任何车型上，并使用相关的功能。这一角度下，Vehicle API会起到关键的作用，因此，谁能够开发出来让OEM和供应商广泛接受的Vehicle API，谁就会赢得整个市场！