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

2022年8月5日，在由Gaspar和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(CP)平台会在上面运行。Adaptive AUTOSAR的平台将可能运行在整车计算机上，实现动态服务的通信和OTA的功能。交通……区域控制器和车载电脑之间需要on，软件的实现就是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端部署某个/IP模块，会涉及到很多子模块，整个实现过程相对复杂。另外，这种方案对同一信息需要双重维护，一个基于信号角度，一个基于服务，会造成信息的冗余，影响信号的实时传输。

图片来源:谢宏建

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

图片来源:谢宏建

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

图片来源:谢宏建

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

图片来源:谢宏建

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

0

图片来源:谢宏建

刚才给大家介绍了如何在AUTOSAR上实现信号和服务的转换。对于这样的解决方案，在车载通讯和车载电脑通讯中很有帮助，但对于车外通讯帮助不大。

汽车API的必要性

那么如何实现车外生态通信需要看车载API:

目前汽车行业有两个趋势。首先是互联互通。整车不再是孤岛。它需要与云互联。通过云端可以实现OTA和远程诊断，实现车辆状态查询和车辆控制。此外，汽车还需要通过蓝牙与手机、手表互联，通过V2X协议与交通设施和其他车辆通信，形成完整的交通智能网络。还可以通过MQTT协议与智能家居、智能城市进行通信，构成了整个IOT生态系统。2022年8月5日，在由Gaspar和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(CP)平台会在上面运行。Adaptive AUTOSAR的平台将可能运行在整车计算机上，实现动态服务的通信和OTA的功能。交通……区域控制器和车载电脑之间需要on，软件的实现就是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端部署某个/IP模块，会涉及到很多子模块，整个实现过程相对复杂。另外，这种方案对同一信息需要双重维护，一个基于信号角度，一个基于服务，会造成信息的冗余，影响信号的实时传输。

图片来源:谢宏建

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

图片来源:谢宏建

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

图片来源:谢宏建

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

图片来源:谢宏建

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

0

图片来源:谢宏建

刚才给大家介绍了如何在AUTOSAR上实现信号和服务的转换。对于这样的解决方案，在车载通讯和车载电脑通讯中很有帮助，但对于车外通讯帮助不大。

汽车API的必要性

那么如何实现车外生态通信需要看车载API:

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

图片来源:谢宏建

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

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

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

3

图片来源:谢宏建

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

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

4

图片来源:谢宏建

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

5

图片来源:谢宏建

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

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

6

图片来源:谢宏建

有了vss和vsc，还是解决不了软件互联的问题。比如云端的信号和服务基于HTTP协议发送到车载电脑，车载电脑内部主要基于someip通信，甚至包括dds协议。我们还需要支持工具和软件来实现不同协议之间的转换。

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

7

图片来源:谢宏建

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

图片来源:易特驰官网

(以上内容来自ETech /AUTOSAR技术经理谢宏建在2022年8月5日由Gaspar和AUTOSAR联合主办的第三届软件定义车辆论坛2022暨AUTOSAR中国日上发表的主题演讲《区域框架下的信号服务转换与车辆接口》。) 2

图片来源:谢宏建

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

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

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

3

图片来源:谢宏建

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

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

4

图片来源:谢宏建

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

5

图片来源:谢宏建

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

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

6

图片来源:谢宏建

有了vss和vsc，还是解决不了软件互联的问题。比如云端的信号和服务基于HTTP协议发送到车载电脑，车载电脑内部主要基于someip通信，甚至包括dds协议。我们还需要支持工具和软件来实现不同协议之间的转换。

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

7

图片来源:谢宏建

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

图片来源:易特驰官网

(以上内容来自ETech /AUTOSAR技术经理谢宏建在2022年8月5日由Gaspar和AUTOSAR联合主办的第三届软件定义车辆论坛2022暨AUTOSAR中国日上发表的主题演讲《区域框架下的信号服务转换与车辆接口》。)

标签：发现DS理念远程

汽车资讯热门资讯