车载以太网SOA架构下ECU间的互通性研究

作者简介：糜斌（1971— ），男，江苏扬州人，工程师，学士；研究方向：车载以太网。

摘要：文章从车载以太网SOA架构下AUTOSAR与GENIVI的关系出发，阐述了采用不同类型SOME/IP协议栈的设备之间实现互通的需求。通过对实际项目中互联问题的深入分析，揭示了问题来源，给出相应场景下的解决方法。最后，文章提出了工具化检查方法，以利于采用不同协议栈设备之间的互联互通。

关键词：车载以太网；SOA架构；SOME/IP协议

中图分类号：中图分类号 文献标志码：文献标志码

0 引言

车载以太网适合用于桥接车内多个域的骨干网络［1］。服务导向架构（Service Oriented Architecture，SOA）有助于构建灵活可变的平台系统。SOA架构下车内ECU之间的互联互通，可能会面临不同的框架、不同的信息交互需求表述格式、不同的SOME/IP协议栈等方面的问题，需要对其进行研究。

1 项目背景与互联需求

2020—2021年，笔者参与开发某车载以太网项目，车载以太网拓扑，如图1所示。IVI通过Switch与IVC，Meter，DVR，HUD相连。

IVI与其他ECU间通过SOME/IP交互信息。由于设备架构不同，所以存在互操作性问题。在AUTOSAR与GENIVI框架下，采用不同接口定义语言的设备绑定各自的SOME/IP协议栈实现信息交互的示意图，如图2所示。

项目组遵循TC8 V3.0 ［4］标准，对IVI采用的协议栈能否通过SOME/IP_ETS测试进行了评估。测试结果表明vsomeip3是可用的。

2 互联问题分析归类

在系统联调阶段，ECU间不能正常交互的问题较多。通过分析，这些问题归类如下：

2.1 测试规范的版本问题

有部分设备的ETS测试采用的是TC8V2.0版本。与V3.0相比，V2.0在一些细节方面定义不清晰，不能保证协议栈细节实现上的一致性。

2.2 协议栈配置问题

vsomeip3增加了对E2E［5］的支持，但需要在json配置文件中对E2E进行配置，且要求client端和server端的E2E配置一致。有部分设备采用的是XML格式的配置文件，其中E2E配置的profile参数项不一致导致协议栈不能正常解析E2E Header，造成互联问题。

2.3 协议栈完成度问题

SOME/IP并不是“1个”协议，SOME/IP包含多个部分：SOME/IP基本协议［6］、SOME/IP-SD服务发现协议［7］、SOME/IP-TP传输协议［8］等。无论是TC8V2.0还是V3.0，其对SOME/IP协议栈的测试用例针对的是基本协议和服务发现协议，后来被AUTOSAR納入标准的传输协议并不在其范围之内。SOME/IP-TP支持在协议栈层面对大数据进行UDP方式传输。vsomeip3目前尚未支持SOME/IP-TP，造成互联问题。

2.4 中间文件的兼容问题

中间文件作为不同厂家之间表达接口需求的数据文件，最好采用同一种标准。但如前述，AUTOSAR采用的是ARXML；GENIVI则是采用FIDL/FDEPL。转换面临兼容性问题，FIDL的表达与SOME/ IP的序列化需求存在差距，在面对定长字符串、定长数组、枚举基类型以及可选字段的结构时，FIDL/FDEPL与ARXML之间的转换存在困难，这给不同阵营的设备互联带来了问题。

2.5 原始需求的表达与解读问题

FIDL/FDEPL与ARXML还不能一一对应，有些地方须参照原始需求来确定序列化。车厂对信息交互的原始需求一般以xlsx文件形式给出。但各家模板不一致导致歧义，造成互联问题。

3 互联问题的解决

解决方案采用了从上到下、从需求→实现→测试的次序。

3.1 针对原始需求表达

SOME/IP相关的原始需求是在车厂提供的网络设计规范中给出的。但信息表述比较分散，格式不够规范，通常各ECU开发方采用各自的xlsx文件模板整理规格化的SOME/IP需求表格，以便工具的后续处理。但需求表格会因为理解上的原因或版本更新原因而不一致。

笔者推荐的解决办法是xlsx文件由服务提供方按统一的模板填写，并提供给使用方。这样做有效避免了歧义的产生。

3.2 针对中间文件

在GENIVI与AUTOSAR框架下，从用户需求→接口定义的中间文件→接口代码和配置文件的顺序（见图3）。在各自框架下，中间文件都起到了承上启下的作用。但不同框架下的中间文件转换存在兼容性问题，对此，可以采用以下两种方法。

（1）规避：在xlsx文件中定义业务相关的接口时，参数的定义尽量避免引入兼容性问题，如：给字符串/数组加入长度定义。

（2）后处理：在服务接口代码生成后再处理，如：根据FIDL/FDEPL生成的接口代码中枚举基类型与基于ARXML生成的代码中类型不一致时，对生成的代码进行手动修改/工具软件扫描修改。

FIDL/FDEPL规范定义也在不断完善中，最新资料表明，FDEPL文件中可以设置EnumBackingType来改变枚举的默认数据类型，这样枚举基类型的问题就不复存在了。

3.3 针对协议栈完成度

vsomeip3不支持SOME/IP-TP，但项目最初需求中存在超长的UDP数据报文。针对不同情况，可以采用以下3种对策。

（1）规避：在定义业务相关的接口时，对采用UDP传输的数据包长度进行检查，确保数据包长度不超过1 400字节。

（2）调整传输方式：部分消息的传输方式改成TCP。

（3）引入其他协议处理：基本信息采用SOME/IP传输，而扩展信息采用TFTP传输。

3.4 针对协议栈配置

协议栈的配置与协议栈的具体实现关系很大。如问题中提到的E2E配置项，在本地配置是完整的，但与对端配置不一致，造成双方不能正常交互信息，将E2E的profile配置项更正一致后，这个问题就解决了。

配置不正确或者不一致会导致很多莫名其妙的问题，需要认真检查。

3.5 针对测试验证

统一按TC8V3.0进行SOME/IP_ETS测试，以保证一致性。

在测试过程中，有时需要分析是协议栈在实现方面的问题还是测试程序的问题。在进行SOMEIP_ETS_034：echoUINT8E2E测试时，就出现了E2E Header数据顺序错误的情况。好在TC8V3.0比V2.0中多了对echoUINT8E2E_req的参数顺序的明确规定，采用抓取测试程序发出的数据包进行比对的方法明确了是测试程序的问题，更正测试程序后问题解决。

4 检查工具的开发

在对SOA架构下采用不同SOME/IP协议栈的设备互联问题的分析与解决过程中，笔者萌生了开发检查工具的想法。检查工具可以将项目中积累的知识经验保留下来，在以后的项目中发挥作用，提高开发效率。

当前，检查工具包括如下模块：（1）xlsx需求文件检查模块。对格式规范的检查和信息完整性检查。（2）ARXML文件检查模块。检查是否存在FIDL/FDEPL文件不支持的定义。（3）FIDL/FDEPL文件检查模块。检查FIDL和FDEPL文件之间的一致性。（4）协议栈管理模块。管理各协议栈的基本信息及协议栈对规范的完成情况。（5）json配置文件检查模块。检查格式正确性和配置项完整性。

5 结语

本文通过对车载以太网实际项目中ECU间互联问题的分析，给出了解决方案。检查工具的开发则进一步提高了解决互联问题的能力和效率。车载以太网在不断发展，SOA架构下ECU间的互通性研究不会止步。

参考文献

［1］CHARLES M，ROBERT B，JEFFREY Q.Automotive Ethernet-The Definitive Guide［M］.America：Intrepid Control Systems，2014.

［2］AUTOSAR.ARXML Serialization Rules 4.3.1［EB/OL］.（2017-12-08）［2022-10-27］.https：//www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_TPS_ARXMLSerializationRules.pdf.

［3］Wiki.Franca IDL［EB/OL］.（2018-04-13）［2022-10-27］.https：//www.detailedpedia.com/wiki-Franca_IDL.

［4］OPEN ALLIANCE.Automotive Ethernet ECU TestSpecification V3.0［EB/OL］. （2020-05-08）［2022-10-27］.http：//www.opensig.org/download/document/275/OA_Automotive_Ethernet_ECU_TestSpecifications_Version_3.0.zip.

［5］AUTOSAR.E2E Protocol Specification R19-11［EB/OL］.（2017-10-27）［2022-10-27］.https：//www.autosar.org/fileadmin/user_upload/standards/foundation/19-11/AUTOSAR_PRS_E2EProtocol.pdf.

［6］AUTOSAR. Requirements on SOME/IP Protocol［EB/OL］.（2020-11-30）［2022-10-27］.https：//www.autosar.org/fileadmin/user_upload/standards/foundation/20-11/AUTOSAR_RS_SOMEIPProtocol.pdf.

［7］AUTOSAR.SOME/IP Service Discovery Protocol Specification［EB/OL］. （2017-03-31）［2022-10-27］.https：//www.autosar.org/fileadmin/user_upload/standards/foundation /1-1/AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol.pdf .

［8］AUTOSAR.Specification on SOME/IP Transport Protocol［EB/OL］.（2017-10-27）［2022-10-27］.https：//www.autosar.org/fileadmin/user_upload/standards/classic/21-11/AUTOSAR_SWS_SOMEIPTransportProtocol.pdf.

（編辑 姚 鑫）

Abstract： Starting from the relationship between AUTOSAR and GENIVI under the on-board Ethernet SOA architecture， this article elaborates on the requirements for interoperability between devices using different types of SOME/IP protocol stacks. Through in-depth analysis of interconnection issues in actual projects， the sources of the problems were revealed and corresponding solutions were provided in the corresponding scenarios. Finally， the article proposes a tool based inspection method to facilitate interconnectivity between devices using different protocol stacks.

Key words： vehicle Ethernet; SOA architecture; SOME / IP protocol