基于AUTOSAR的域控制器以太网通信系统设计实现

郑 燚，张世民，陆云龙

（1. 宁波大学信息科学与工程学院，宁波 315211； 2. 浙江合众新能源汽车有限公司，上海 201107）

前言

传统的分布式汽车电子电气架构中，大量电子控制单元（electronic control unit，ECU）间交互链路繁杂低效，扩展性低［1］。即使引入中央网关，集成度仍较低，难以更新功能［2］。为解决这一问题，汽车电子电气架构开始向集中式发展，以将相关功能归并整合进一个“域”的方式集中管理大量ECU。对单个功能域内ECU 进行管理的高性能ECU 即域控制器。域控制器的集成化设计大幅减少ECU 及交互链路数量，简化硬件网络。软件架构层面，为提高ECU软件可移植性，促进规范化，汽车开放系统架构（AUTomotive open system architecture， AUTOSAR）应运而生。依此设计的软件可快速移植到新硬件平台，大大节省开发成本，规范化接口令软件设计更加安全高效。经长久发展，AUTOSAR 架构趋于成熟，被广泛应用于ECU 软件开发和汽车电子设计，如汽车底盘控制系统开发［3］、底层通信软件设计［4］、整车电子电气架构设计［5］、汽车电子诊断系统开发［6］和电机控制系统设计［7］等领域。

AUTOSAR架构和域控制器概念的引入，为满足用户日益增长的智能驾驶需求提供了新解决方案，也对ECU 性能尤其是通信性能提出了更高要求。传统CAN 总线已无法满足日益增长的智能驾驶通信需求和复杂功能调试需求，对下一代通信系统的开发迫在眉睫。因此，技术成熟、成本低廉、通信速率高的以太网逐渐被看好成为下一代车载通信主流［8］。面向服务的IP 中间件协议（scalable serviceoriented middle-ware over IP，SOME/IP）对AUTOSAR架构兼容性好，逐渐成为车载以太网主流应用层协议之一。国内对SOME/IP 的研究仍处在起步阶段，文献［9］中设计了基于SOME/IP 协议的通信系统并验证了通信可用性，文献［10］中尝试在样例小车上模拟SOME/IP 通信，文献［11］中探究了SOME/IP 协议在整车通信网络中应用的可能性，文献［12］中验证了SOME/IP 通信系统在多核处理器上的可用性，文献［13］中对SOME/IP 协议的通信性能进行了测试验证。

以太网通用测量校准协议（XCP on ETH）可利用以太网的高带宽满足复杂调试需求。近年来，多种XCP 标定系统逐步应用于整车控制器标定调试中［14-16］。

本文中基于AUTOSAR 架构，设计实现了应用于智能驾驶域控制器的车载以太网通信系统软件，包括基于SOME/IP 协议的大流量通信系统和XCP on ETH 的标定系统，并进行了面向实车应用场景的测试验证。

1 基于AUTOSAR 的域控制器软件系统设计

1.1 AUTOSAR架构简介

AUTOSAR架构具备硬件不敏感、模块化程度高、安全性好等优点，符合集中式架构设计的需要。如图1所示，AUTOSAR架构将软件拆分为基础软件（basic software， BSW）、运行环境（runtime environment，RTE）和应用软件（application， APPL）3 层，分离应用软件与驱动，通过标准化接口进行交互。这种交互方式在AUTOSAR 架构下被广泛应用。在域控制器软件系统中，应用软件部署在APPL 层，BSW 层提供应用功能运行的基础软件环境和服务，APPL层通过RTE层提供的标准化接口调用BSW层功能服务。

图1 AUTOSAR软件架构［17］

1.2 域控制器软件结构设计

1.2.1 APPL和RTE设计

智能驾驶域控制器须在复杂路况下实现自动泊车、定速巡航、车道保持和碰撞预警等智能驾驶功能。各功能应用场景不同，所需信号与产生的控车指令也相异。将使用场景相近、所需信息趋同的功能整合，可将域控制器应用层划分为若干软件组件（software component，SWC）。域控制器应用软件架构如图2 所示。泊车辅助功能应用于低速环境，处理行人蹿出等紧急情况的概率较高，对车身周边信息实时性要求高，故单独设立泊车辅助SWC 并分配独立信道，减少信号处理时间，增强安全性。碰撞预警功能对时效性要求极高，单独设立碰撞预警SWC及相应信道可简化信息处理过程，避免延迟。定速巡航、车道保持等高速环境行车功能所需信息相似，如车速、车道线标识和跟车目标等，故整合为巡航辅助SWC，通过模式开关拆分整合信号，节约系统资源。冷却液温度、电源状态、电池温度等与智能驾驶功能无直接关系，但关乎行车安全的信息由车况监控SWC 收集处理，判断当前整车状态是否支持功能正常运行，如检测到严重故障，则立刻终止智能驾驶功能并记录故障信息，以备维修人员查看。每个SWC 中包含若干运行实体（runnable entity， RE），它们是SWC 的最小代码片段，也是功能的具体实现，记录着功能触发条件和接口列表等信息。这些运行实体分布在系统服务的任务（AUTOSAR OS task）中，以任务为单位进行运行调度。

图2 应用软件结构

RTE 层定义SWC 各模块对外交互接口。接口分为单向的发送-接收接口和双向的客户端-服务端接口两类［17］。APPL 所需输入信号与输出指令多为单向传输，使用发送-接收接口。故障处理等复杂场景则以客户端-服务端接口进行双向交互。

1.2.2 BSW设计

BSW 层结构如图3所示。驱动代码部署于微控制器抽象层（microcontroller abstraction layer，MCAL）。MCAL 隔离硬件资源与上层软件，进行软件移植时只须适配MCAL，大大提升软件可移植性。ECU 抽象层（ECU abstraction layer）承担服务层与MCAL 间交互。服务层提供通信、存储与系统服务等功能。AUTOSAR架构中，所有软件模块部署在系统服务提供的任务中，在系统调度下分时运行，占用CPU资源。单个CPU处理所有任务总耗时占总运行时间比例即为CPU负载。出于系统安全性考虑，多核系统中常以最高的CPU负载值作为整个系统的负载参考。

图3 基础软件层结构框图［18］

2 基于SOME/IP 协议的车载以太网通信系统设计

2.1 SOME/IP协议介绍

SOME/IP 协议是目前车载以太网通信的新兴应用层协议。它在OSI 7层模型中和DOIP 协议、XCP协议等均处于应用层，如图4 所示。它可适配不同传输层协议，且对AUTOSAR架构兼容性良好。

图4 常见车载以太网协议的OSI 7层模型图［19］

不同于传统的CAN 协议等汽车行业常用的面向信号与发送者的协议，SOME/IP 是面向服务的通信协议。它会在通信开始前预先建立好点对点的通信链路——即客户端与服务器端的连接。仅当客户端产生通信需求时，通信才会在指定的客户端与服务端中进行，不会像面向信号的协议一样向整条总线上所有节点发送。这种点对点通信方式可有效提高通信效率并降低总线占用率，减少冗余信息传输。

SOME/IP 协议的点对点链路建立，依赖一种建立在多播地址上的特殊服务——服务发现（SOME/IP service discovery，SOME/IP-SD）［20］。通过向多播地址——一种可被多个节点接收的IP 地址发信，SOME/IP 服务端与客户端可匹配通信服务需求。客户端向服务端订阅服务后，点对点通信链路正式建立。

SOME/IP 协议的服务类型分为方法和通知两类。客户端向服务端请求，服务端根据请求决定是否响应的服务被称作方法（method）。方法报文，根据客户端请求后服务端是否需要响应，分为不需要响应的开火&丢弃（fire&forget，F&F）类型和需要响应的请求&响应（request&response，R&R）类型。服务订阅后，服务端自动向客户端发布信息的服务被称作通知（notification）。只反映服务端事件状态快照，定周期由服务端向客户端发送的通知被称为事件型报文（Event）。允许客户端对服务器端进行数据读写的通知被称为字段报文（field）［21］。

2.2 SOME/IP通信系统设计

用于智能驾驶域控制器的通信系统需要满足：（1）有较高通信带宽，适应智能驾驶功能需求。（2）时延低，减小控车指令传输延迟。（3）系统负载较低，避免因系统负载过高导致故障。不同于传统以太网流行的TCP协议，UDP协议作为轻量化传输层协议，不需要多次握手过程，传输时延更低，效率更高。此外，SOME/IP-SD需要服务端向多个节点共用的多播地址同时广播服务信息，UDP 支持这一功能，但TCP不支持。因此，本文将基于SOME/IP 和UDP 协议设计基于AUTOSAR架构的车载以太网通信系统。

针对域控制器的不同通信需求，本文在设计通信服务时采用不同种类SOME/IP报文作为相应的传输载体。

选用Event 型报文负责行车轨迹、障碍物、车身运动状态等智能驾驶功能所需单向、大流量、定周期信息的传输，避免频繁订阅服务产生的额外通信负载。针对设置开关，ECU突发告警等触发型、低频率单向信息，本系统选用F&F 类型进行传输以简化传输链路。

对于重要的、需要域控制器立刻进行处理的信息，如系统故障等，本系统选择R&R 类型报文以确认对端响应，尽快完成故障处理。

通信系统架构（以发送过程为例）如图5 所示。原始数据的序列化（serialization）是将待发送的原始数据转换成二进制串的过程，可压缩数据包的大小，节省传输带宽，也能在传输时保证对象完整性与可传递性。接收端以反序列化（deserialization）将二进制串恢复成原始数据。大数据通信管理模块（large data communication， LDCom）负责将信号和协议数据单元（protocol data unit， PDU）进行映射。协议数据单元路由（protocol data unit router，PDUR）将PDU向下层协议传递，接收信息也由PDUR 进行提取与映射。

图5 SOME/IP通信系统设计

UDP 协议单帧最大长度仅为1500 B。数据包过长时需要从PDUR 向SOME/IP-TP 发起拆包请求，将大数据包拆分成若干小包。同理，接收端也须进行组包操作还原大数据包。

数据包由PDUR 下行到套接字转换（socket adapter， Soad）模块，将以太网概念中的套接字（socket）与PDU 对应，为数据包打包协议包头，如SOME/IP 包头的信息标识（message ID）和信息长度等［22］。TCPIP 模块根据传输层协议进一步封装数据，以太网接口层（ETH interface，ETHIF）对接硬件驱动，向总线发信。接收链路逆发送链路进行。当数据链路层使用片外硬件时，须添加相应驱动。

在这一系统中，Soad 层以下部分可根据不同传输协议分别设计，快速替换其他协议，大大增强软件可移植性。

AUTOSAR 架构下，CAN、ETH 等通信系统常共用PDUR 模块进行总线路由。传统ECU 通信系统部署于多核硬件时，多将各类通信系统全部部署在单个内核，避免系统内部产生跨核通信。但域控制器以太网通信带宽高、流量大，任务处理时间相比传统通信系统大幅增加，单核集中部署会导致CPU 负载飙升。为降低负载，本系统将SOME/IP 通信部署在其他低负载内核，分散单核过高负载，通过通信管理模块收集通信需求。此外，序列化和反序列化过程常在中断处理函数中执行，在处理大数据包时会在中断状态中停留过久，进而影响域控制器软件正常运行，尤其是对周期稳定性有强要求的其他通信系统。本系统将大数据块的序列化和反序列化从中断处理程序移出，减少停留，保障其他功能周期稳定。

3 基于XCP协议的标定系统设计

3.1 通用测量校准协议介绍

为避免频繁烧写程序导致调试效率降低和可能的硬件损坏，需要一种可实时更改程序内变量的手段，即标定［23］。目前，标定功能主流协议是通用测量校准协议（universal measurement and calibration protocol，XCP，其中X 表示任意传输层）。XCP 协议由CAN 测量校准协议（CAN calibration protocol，CCP）发展而来，主要用于ECU 数据获取和校准访问，包括测量、标定、刷新和旁路等方面。实际生产主要使用测量和标定功能。

XCP 协议主要包含两类报文：主机向从机发布的命令接收对象（command transformation object，CTO）和从机向主机回传的数据传输对象（data transformation object，DTO）［24］。XCP 测量方式分为异步和同步两种。如图6 所示，异步模式需要上位机向从机频繁轮询并等待从机，总线负载占用较高，且无法使用时间戳，缺少时间一致性。而数据单向流动的同步测量有效降低了总线负载，提升了传输效率，也便于使用时间戳。

图6 异步测量（左）与同步测量（右）原理图

同步测量报文包含若干数据传输对象（data AcQuisition，DAQ），DAQ 由DTO 与内存之间的映射关系（object descriptor table，ODT）组成，ODT 中包含待测地址与数据长度的配对，称为条目（Entry）［15］。

如表1 所示，所有条目写入从机内存，编译后不能修改的标定方式为静态DAQ 标定，在标定开始前由上位机计算完毕的称动态DAQ 标定。动态DAQ标定不需要为单次调试中用不到的待测量固定内存占用，可只寻址所需内容，从而大大减少ECU 内存消耗。

表1 动态与静态DAQ比较

3.2 标定系统设计

智能驾驶功能调试须同时观测大量信号，如表2所示。待测量超过3000个，总数据量达3810 Kbps，仅10 ms 周期待测数据量就超过2 Mbps， CCP 协议1 Mbps的通信速率［16］无法满足需求。存储大量待测信号会大幅占用内存。为节约内存，本系统采用动态DAQ标定。

表2 标定系统通信数据统计

与SOME/IP 协议类似，XCP 协议位于OSI 模型应用层。XCP 协议可兼容多种传输协议，为满足智能驾驶标定系统的高带宽需求，出于节约资源考虑，本文选择UDP 传输协议，与SOME/IP 通信系统共同使用相关驱动。

标定系统结构如图7 所示。系统硬件由上位机、车载路由和域控制器组成。车载路由可通过无线网络转发域控制器和上位机数据，不需要5 类线接口，简化了车载硬件。与SOME/IP通信系统不同，高度集成的XCP 模块可以直接根据上位机需求实时取址，数据处理功能如拆组包等均集成到模块内，不需要额外设计。

图7 标定系统结构图

XCP 模块所需PDU 同样通过PDUR 模块进行数据路由，TCPIP 层以下驱动可与SOME/IP 通信系统兼容共用，不需要部署其他传输协议，节约系统资源。

智能驾驶域控制器标定过程须观测大量实时数据确定运行状态，待写入参数在实时性和数量上则要求均较低。为确保数据实时性，待测量由运行代码直接取址得到，这些数据随应用代码部署于离散内存地址，因此，本系统需要较大XCP 模块读取范围。待写入参数可集中分配到同一内存区域进行编译，以减小XCP 模块的写入取址范围，避免误操作写入对智能驾驶功能的干扰。各类智能驾驶功能部署任务执行周期不同，为降低系统负载，本系统依照功能运行周期分别设计多条标定事件，避免长周期待测量占用短周期通道，提升传输效率。

4 测试验证

4.1 SOME/IP通信系统测试

系统设计完成后，通过Davinci configurator 和developer 等规范化AUTOSAR 设计工具实现程序代码，用HighTec 编译器进行集成编译，生成可执行文件。可执行文件由Lautebach 调试器烧录进基于英飞凌TC397芯片的域控制器平台。为获取实车应用数据，将平台硬件装车后启动智能驾驶功能，实时获取系统负载数据。测试环境如图8所示。

图8 智能驾驶域控制器实车测试环境（左）与硬件平台（右）

车载以太网系统负载如图9和图10所示。基于UDP 传输协议的SOME/IP 以太网通信系统相比TCP传输协议大幅降低了CPU 负载，多核优化策略也有效降低了域控制器系统负载。

图9 车载以太网单核通信负载对比

图10 多核负载优化对比

为测试SOME/IP 通信系统实车运行性能，使用Wireshark 软件统计以太网通信数据，测试结果如图11和图12所示。在超过2000 s的长时通信测试中，系统平均接收速率2433 Kbps，发送速率1944 Kbps。合计4377 Kbps 的传输速率远高于车载CAN 总线500 Kbps 通信速率和CAN FD 总线1 Mbps 的常规通信速率，证明本系统通信性能良好。为验证系统能否满足智能驾驶功能需求，分别测试泊车辅助、定速巡航、车道保持等功能。泊车场景根据车位与车身位置可分为水平车位与垂直车位，分别进行泊入与泊出测试，如图13 所示。对定速巡航与车道保持功能进行整合测试，在高速路段同时开启相应功能，持续行驶152 km 并收集所有故障信息，如图14 所示。开启碰撞预警功能在高速路段持续行驶1318 km，共计出现9 次碰撞风险场景，场景下碰撞预警功能均正常运行。在以上测试中，智能驾驶功能运行稳定，无通信系统故障，通信系统能够满足域控制器使用需要。

图11 SOME/IP接收速率

图12 SOME/IP发送速率

图13 泊车辅助测试

图14 定速巡航与车道保持测试

4.2 以太网XCP标定系统测试

为检验大容量标定系统的可靠性与稳定性，本系统在CANape 软件中载入所有待测数据，运行智能驾驶功能后建立标定连接。在功能运行中实时读取数据与修改参数，观察功能运行是否正常，数据读取是否稳定，同时统计标定功能CPU负载。

如图15 所示，使用标定系统调试过程中，标定系统CPU 负载仅11.381%，满足大流量标定系统的高速率、低负载需求，系统功能稳定。

图15 标定系统CPU负载

5 结论

基于AUTOSAR 架构设计实现了智能驾驶域控制器车载以太网通信系统，包含基于SOME/IP 协议的应用通信系统和基于XCP on ETH 的标定调试系统。在基于英飞凌TC397芯片的域控制器硬件平台上部署通信系统软件后装车，在实车条件下测试智能驾驶功能，并收集通信系统性能与负载数据。测试结果表明，本通信系统可满足智能驾驶功能对大流量高速通信和对复杂功能进行调测的需求，且系统负载低，传输稳定。车载以太网通信性能相比上一代通信协议大大提高，可以满足基于集中式汽车电子架构的智能驾驶功能更强的通信需要，对智能驾驶功能进一步迭代和实际应用有重要意义。