随着无人驾驶、车联网、智能交通等技术的不断引入，车载ECU 单元数量的不断增加［1］，基于CAN 总线通信模式的网络拓扑越来越复杂，对于汽车上新功能的增加及维护造成了较大的困难［2］，传统的整车电子电气架构难以满足汽车新兴业务的快速发展技术需求。近年来，众多汽车厂商对汽车电子电气架构的升级进行研究，博世公司指出整车电子电气架构正从分布式向集中式发展，大众、特斯拉［3］、华为［4］等公司也以集中化为方向提出了各自的架构方案。在集中化发展的过程中，面向服务的软件架构（service-oriented architecture，SOA）逐渐获得了重视。利用SOA架构进行软件设计能使软硬件解耦，促进汽车电子电气架构进一步向集中式发展，同时也能使车载软件向多元化发展。
1 汽车电子电气架构设计
1.1 架构设计原则
基于域集中电子电气架构设计时，功能域的划分应当符合如下原则：1）域内信号根据实时性或可靠性，信号相似的服务划分在同一功能域下［5］。2）根据车辆现有的ECU 逻辑功能划分功能域，将功能相近且经常产生信号交互的服务划分在同一功能域下，便于减少域间信号路由，降低网关负载［6］。
J1939标准［7］对OBD-Ⅱ的诊断提出了规范，定义的诊断信号码将整车按功能划分为5个域：动力总成域、底盘域、车身域、自动驾驶域和信息娱乐域［8］，汽车电子电气架构［9］如图1所示。
图1 域集中式汽车电子电气架构
1.2 基于骨干以太网与多域控制器的整车电子电气物理架构设计
以沙滩车为例采用域集中式方案构造整车电子电气架构。使用以太网将5 个功能域与中央网关进行连接，功能域内通过域控制器控制其功能，域控制器之间通过中央网关进行通信。使用Docker将各域控制器及中央网关封装成镜像，并根据各镜像生成对应的容器。Docker 可以指定各个容器的端口号映射，利用该特性可以在同一台计算机上完成各域控制器与中央网关之间的以太网通信。域集中式整车电子电气架构如图2所示。
图2 架构设计示意图
1.3 基于SOA的汽车通信服务架构设计
SOA架构是车载以太网的重要特征，通过提供服务的方式实现功能，能够降低通信网络上的负载［10］。服务端将质量、控制信息和其他关于服务的细节打包在1个服务内为客户端提供服务，客户端在需要此服务的时候才会向服务端请求服务。
SOME/IP是面向服务的通信中间件，提供标准服务接口，广泛应用于车载以太网［11］。SOME/IP协议在车载以太网7 层模型的位置如图3 所示。SOME/IP 支持3 种通信方式，即Method（方法）、Event（事件）和Field（字段）。Method 是发起-答复制，Client 向Server 请求数据时，Server 进行答复；Event 与CAN 总线的通信模式比较相近，Server 周期性向整个架构发送服务提供的消息，对该服务有需求的Client 响应后获得该服务，但不会对Server进行回复。Field通信模式与Event类似，除了获取通知消息之外，还能对Server进行Getter和Setter操作，即向服务器请求数据与主动修改服务器的数据，报头格式见图4。以转向灯功能服务为例，采用Method通信方式，定义Payload报文格式如下：
图3 SOME/IP在车载以太网7层模型的位置
图4 SOME/IP报头格式
利用SOME/IP 协议定义的各功能域的部分服务列表如表1 所示。整车信号矩阵的设计内容较庞大，以车身域为例，选择其中部分功能进行定义说明。R/R Method 即请求-响应方法，客户端发送请求报文至服务端后，服务端将执行服务的结果通过响应报文反馈至客户端；F&F Method即提出-遗忘方法，客户端发送请求报文至服务端后，无需返回响应报文；Event 为周期性事件，Field 为字段通信，通信特征如前文所述。
表1 各功能域SOME/IP部分服务
2 测试平台构建
由于车载以太网处于研究阶段，验证电子电气架构功能需要对应的测试平台［12］，因此设计了仿真平台，完成功能验证及性能测试。
仿真平台分为前端汽车模型和后端电子电气架构两部分，搭建通信网关以完成前后端通信。后端能搭建各类电子电气架构，前端能根据通信总线上的报文完成动作显示。通信网关负责完成前后端之间的数据交换，前后端通信内容全部经过通信网关，通信接口预留为统一格式，完成解耦合设计。平台整体结构见图5。前端设计为网页形式，包含汽车模型和详细数据2 个操作界面。汽车模型界面为Unity 3D环境下的某模型汽车，详细数据界面以列表形式展示车辆状态及变化动态。后端分为集中域式电子电气架构和通信网关。架构部分实现了集中域控式的电子电气架构，各域控制器与中央网关分别利用Docker 进行封装打包形成镜像，生成的容器通过SOME/IP协议进行通信。通信网关使用LCM与各域控制器通信，使用WebSocket协议向前端传送数据；还能够直接与架构中的各域控制器通信，将模拟操作的控制指令发送至对应的ECU 或域控制器上。所有通信数据都以标准接口经过网关，前后端通信协议之间互不影响，实现了前后端的解耦合。部分通信接口报文格式见表2，SOME/IP协议定义的部分服务报文见表3。
图5 平台整体结构示意图
表2 网关与通信网络转向灯部分通信报文格式
表3 架构上部分SOME/IP服务
3 集中域式电子电气架构功能验证
3.1 自动驾驶域与车身域通信功能验证
使用WireShark 对网络报文进行抓包，观察报文是否合法、前端是否正常工作。以转向灯服务为例，根据表1 定义，转向灯服务的Method ID 为0x0361，Client ID 为0x0010，采用Request & Re?sponse 方案，Session ID 为0x0000。其Payload 报文为2个unsigned int格式的数据，分别代表转向灯的左右位置及状态。在通信网关定义的标准报文格式中，id 为2 的报文控制左转向灯的状态，value 值代表转向灯状态，0 为关、1 为开，id 为2001 的报文是转向请求操作，value 值代表其请求操作，0 为无转向请求，1为有左转向请求，2为有右转向请求。
以左转向灯服务为例进行域集中式架构的通信功能验证，将前端与后端部署在服务器上，使用网关程序连接，操作汽车模型观察架构上的数据变化与网关接收到的消息。功能验证的流程见图6。
图6 架构功能验证示意图
过程①：在前端页面中选择车辆状态为左转向预设环境，前端发送id为2001，value为1的报文至后端网关程序，网关转发至架构中的自动驾驶域控制器上，如图7 所示，观察到网关程序接收到一条id为2001，value为1的JSON字符串。
图7 网关程序接收到的报文
过程②：自动驾驶域控制器经过架构中央网关向车身域控制器发送转向灯服务请求，请求包使用SOME/IP协议，包内Service ID为0x1234、Method ID为0x0361，Request ID 中Client ID 为0x0010、Ses?sion ID 为0x0000。由Payload 定义可知，该包Pay?load部分由2个unsigned int格式数据组成，分别是position和status，position值为1，即需要响应的器件为左转向灯，status 值为1，即状态为亮起。观察到中央网关接收到了Request 报文，报文内各属性值及Payload部分与上文中的定义一致，见图8a。
过程③：提供转向灯服务的车身域控制器接收到请求后，以SOME/IP协议返回Response包至自动驾驶域控制器，告知该域控服务已成功调用。2个报文中对应的所有ID 值、属性值及Payload 均一致，Message Type 为Response。中央网关上抓取到该Response包，如图8b所示。
图8 中央网关上抓取到的Request包和Response包
过程④：车身域控制器提供转向灯亮起的服务。根据标准服务接口定义，车身域控制器向前端发送1个id为2，value为1的报文，前端根据报文内容点亮左转向灯。实验中观察到通信网关接收到1条id为2、value为1的JSON字符串如图7所示，同时前端车辆模型完成了左转向灯的点亮状态显示，如图9所示。
图9 仿真平台前端汽车模型状态更新
实验结果表明：域集中式电子电气架构能以SOA的形式完成车载以太网的数据通信，域控制器能正确提供服务，测试平台能抓取到对应的通信报文，前端车辆模型能根据对应报文显示状态。
将该架构置于沙滩车上进行同一功能验证，自动驾驶域控制器及车身域控制器布置如图10a 所示，A 为自动驾驶域控制器，B 为车身域控制器。自动驾驶域控制器与外界电脑相连，通过电脑手动发送转向灯请求，验证结果如图10b～c 所示：沙滩车能正确响应架构中的报文，域集中式电子电气架构在功能上能达到预期的需求。
图10 沙滩车域控制器布置和车身域（车灯）状态更新
3.2 单条报文跨域实现功能性能验证
为了比较SOA架构与传统CAN总线架构的性能，在Ubuntu下对2种类型的架构进行了不同场景的测试，对比网关吞吐量及CPU利用率2项指标。
3.2.1 单项功能场景
设计实验1：自动驾驶模块/域控制器调用左转向功能测试。自动驾驶模块或域控制器向车身控制器、电机控制器及转向控制器发送车辆减速及向左转向的报文。传统CAN总线架构下，3个执行单元分别为车身控制器BCM、电机控制器MCU 及转向控制器EPS，自动驾驶决策模块使用3条周期发送的CAN 报文发送至各执行器完成左转向功能；SOA 架构下，3 个执行单元为车身域控制器BDC、动力总成域控制器下的MCU 单元与底盘域控制器下的EPS单元，整个左转向功能定义为1个服务及3个子服务，自动驾驶域控制器只需请求单个服务，各执行器接收服务请求报文并完成左转向功能。测试所调用的3 个执行模块分别属于3个不同的功能域。
设定此功能周期性调用，每100 ms 调用1 次。传统CAN 总线架构与SOA 架构的网关吞吐量和CPU占用率对比如图11所示。测试结果表明，2种架构在单报文跨域实现单条功能的场景下，最大吞吐量均为16 kb·s?1左右，传统CAN 总线架构的报文持续占用总线，SOA架构的报文仅在周期性发送时占用总线。传统CAN总线架构对CPU的占用率为30%～35%，SOA架构对CPU占用率约15%。
图11 单功能场景2种架构的指标对比
3.2.2 多项功能场景
设计实验2：充电时充电口及电池状态的人机交互界面（human machine interface,HMI）显示功能测试。充电设备向电池管理系统发送充电口电流及电压报文，电池管理系统将车载电池的温度、电压及电量与充电口电流及电压报文发送至信息娱乐系统的HMI。传统CAN 总线架构下，该功能由电池管理系统BMS 及HMI 之间通信实现，BMS 周期性发送3 条CAN 报文至HMI；SOA 架构下，该功能由动力总成域控制器PDC与信息娱乐域控制器IDC 之间通信实现，IDC 向PDC 订阅充电时电池信息的服务。
设定此功能周期性调用，每100 ms 调用1 次。传统CAN 总线架构与SOA 架构的网关吞吐量和CPU占用率对比如图12所示。测试结果表明：2种架构在单报文跨域实现多条功能的场景下，传统CAN总线架构的最大吞吐量保持在16 kb·s?1左右，SOA架构的最大吞吐量为6 kb·s?1左右。传统CAN总线架构对CPU 的占用率为30%～35%，SOA 架构对CPU占用率为10%～15%。
图12 多功能场景2种架构的指标对比
3.2.3 实验结果分析
传统CAN总线架构的通信总线上时刻存在报文，SOA架构仅在周期性发送时才存在报文。这是由于传统CAN 总线架构是面向信号的，无论车辆状态是否发生变化，总线上所有信号都需周期性发送，吞吐量几乎保持不变；SOA架构由于面向服务，每次周期性调用服务时才产生报文吞吐，因此传统CAN 总线架构的CPU 资源占用率始终较高，而SOA架构的资源占用率低于传统CAN总线架构。
实验2 的SOA 报文设计中，2 个功能域通过1条报文传输多个服务。实验2 中传统CAN 总线架构的网关吞吐量及CPU 占用率与实验1 的同指标相比几乎没有变化，这是由于其通信报文数目不变，不存在功能域的概念，本质上还是3 个电控单元进行通信。SOA 架构的网关吞吐量及CPU 占用率则明显优于实验1，调用的多个服务由同一域控制器提供的，因此该服务所需的数据可封装在1个结构体内，网关吞吐量及CPU的资源开销会更小。
综上所述，基于骨干以太网与多域控制器划分方案及SOA的整车电子电气架构在性能上优于传统CAN 总线架构，在同一域控下的服务调用开销明显低于传统CAN总线架构。SOA架构能够为车载CPU节省更多资源。
4 结论
利用仿真平台对基于骨干以太网及多域控制器的域集中式电子电气架构完成了功能测试及验证，结果表明该架构能够正确完成通信，网关吞吐量及资源占用率都优于传统CAN总线架构。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
