■糜斌
从车载以太网环境下SOA及SOME/IP的关系出发，分析了汽车环境下SOA架构应用对相关工具链的需求。针对在采用开源与商用SOME/IP协议栈的不同情况下现有工具链应用中发现的功能不足问题和兼容性问题，提出了完善措施和解决办法。在实际项目应用中，按照所提方法开发相关的工具软件，最终达到了在采用开源与商用SOME/IP协议栈的设备之间互连互通的结果。
现代汽车已高度联网且联网的程度仍在日益加深，预计未来将有四种网络：汽车内联网、汽车间联网、汽车与道路基层设施间的联网、汽车与互联网之间的互联。车载以太网属于汽车内联网。
在汽车应用方面，提到以太网时就不仅仅是常规意义上的以太网，还包括各种协议栈和技术，如SOME/IP协议和SOA。
SOME/IP协议：Scalable Service-Oriented Middleware on IP，最初是由宝马公司2011年开发设计的一套中间件所采用的通信方式。后来被AUTOSAR接纳并纳入其正式标准。几个关键发展节点如下：
AUTOSAR4.0—完成宝马SOME/IP消息的初步集成；
AUTOSAR4.1—支持SOME/IP-SD及其发布/订阅功能；
AUTOSAR4.2—添加transformer用于序列化以及其他相关优化；
AUTOSAR4.3—修复一些transformer bug同时添加针对大量UDP数据包的SOME/IP-TP协议以及其他SOME/ IP-SD的优化工作。
SOA是面向服务的架构，目的是构建灵活可变的平台系统，能帮助我们站在一个新的高度理解整车环境下各Ecu中各种组件的开发、部署形式，帮助我们以更迅速可靠、更具重用性地架构整个业务系统。较之面向信号，以SOA架构的系统能够更加从容地面对业务的急剧变化。
车载信息娱乐（IVI）是车载以太网的3个主要应用领域之一。IVI属于需要快速迭代的领域，采用SOA就是一个较好的选择。
由于SOME/IP协议名称中的Service-Oriented，有些人在提到SOA时就会将它与SOME/IP等同。其实，SOME/IP只是一种比较适合用于车载领域SOA的协议规范，它主要解决的是SOA架构下网络通信问题。SOA的实现是多元化的，同理SOA架构下的通信协议是多元化的，任何基于服务机制的协议均可以认为是SOA架构通信协议，如数据分发服务（DDS）、MQTT等。DDS的目标是更广泛的工业物联网领域。MQTT目前主要是一种用在车和云之间的车联网通信协议。
在车载以太网环境下，SOME/IP给SOA提供了很好的支撑，本文基于SOME/IP协议来研究SOA工具链。
相关工作
SOA架构中，需要从车内的业务需求出发，设计多个层次的服务，考虑服务部署及应用。实际项目中，车上多个Ecu 还会采用不同的操作系统及不同来源的SOME/IP协议栈，给车内的互连互通的实现增加了一些复杂性。
从2019年开始，在2个型号产品（操作系统分别是Linux 和Android）上，分别采用了2家第三方的商用SOME/IP协议栈及相关的SOA工具。而在内部平台项目（操作系统是Linux）中，则采用了GENIVI的开源协议栈vsomeip及相应的工具，并对工具链进行了完善。
实际开发中，首先涉及的是需求的表述。项目都沿用了目前国内较多车厂采用的excel表格方式来表达SOME/IP服务需求矩阵。这个xlsx文件需要满足一定的格式化要求，以便于工具的转换处理。有了xlsx需求规格文件，通过相应的工具链将其转化为接口定义文件，生成接口代码，导入项目进行进一步的编码调试工作。
经历了不同项目以太网SOA架构下的需求梳理、工具应用/开发、编码调试、测试验收等工作，我碰到并解决了很多SOME/IP协议栈及SOA工具链相关的问题，对车载以太网环境下，如何应用SOA工具链提高开发效率、如何避免工具链的陷阱有了深入的认识。下面分商用和开源两个方面进行论述。
商用SOME/IP协议栈及SOA工具链
商用SOME/IP协议栈的协议实现程度较高，协议栈提供商一般会提供较为易用的SOA工具链。
基本功能包括需求录入/需求导入、ARXML中间文件生成、服务接口生成和部署文件生成。
需求录入/需求导入必须保证信息的完整，除了服务接口的定义和数据类型的定义外，还要有服务部署和服务发现参数等相关内容。工具一般都提供了信息形式检查及完整性
宝马检查。
车载环境下，受AUTOSAR规范的影响，ARXML文件已经成为信息的记录和传递的一种标准。商用的相关工具，都支持将ARXML文件作为中间文件进行信息交互。
服务接口和部署文件是工具生成给APP/中间件使用的成果物。在生成服务接口和部署文件时需注意client端和server端的区别。服务接口一般是C++接口形式，部署文件一般采用xml格式，里面包含SOME/IP协议栈需要使用的配置信息。
不同厂家的商用工具链在功能上存在差异，有些提供了扩展功能，如：服务监控功能、java接口功能等。
服务监控功能有助于故障定位和排除。java接口功能则是在Android环境下服务接口可以是java接口形式。这时工具生成的代码包含了一个C++中间件，中间件与框架代码之间通过HIDL或者本地SOCKET进行通信，框架代码中包含工具生成的java接口。
商用SOA工具链一般不提供Fidl/Fdepl文件生成功能。
开源SOME/IP协议栈及SOA工具链
开源SOME/IP协议栈是GENIVI的vsomeip，目前版本是v3.1.20.3。
Franca接口定义语言，即FIDL全称是Franca Interface Definition Language。Franca是一个用于定义和转换软件接口的开源框架，FIDL是一种正式定义的、基于文本的接口描述语言。
FDEPL全称是Franca Geployment，用于描述部署规范（De-ployment Specification）：IDL元素属性的类型安全定义和部署定义（Deployment Definition）：具体接口的属性值。
JSON全称是JavaScript Object Notation，是一种轻量级的、基于文本的、开放的数据交换格式。JSON比XML简洁。
基本功能需求包括需求录入/需求导入、Fidl/Fdepl中间文件生成、服务接口生成和部署文件生成。
vSOMEIP是genivi基于AUTOSAR标准实现的SOME/IP协议栈，使用C++作为主要开发语言。CommonAPI 是genivi基于FIDL开发的一套序列化工具。
在CommonAPICpp UserGuide中，有对CommonAPI创建可执行应用程序的基本工作流的介绍。
现有SOA工具链的不足
商用/开源SOA工具链都存在不足。商用SOA工具链的不足主要表现在缺少对FIDL/FDEPL的支持，生成的中间文件不能直接用于开源环境。另外，一些工具提供商同时也是协议栈提供商，工具链的最终输出与具体使用的协议栈存在一定的绑带关系，缺少通用性。
开源SOA工具链的不足比较多，也是我们研究的重点，主要包括如下几个方面：
需求导入困难
Franca Editor可以输出FIDL/FDEPL文件，但开源SOA 工具链中缺少从xlsx需求规格文件转换生成FIDL/FDEPL 文件的工具，用户在有xlsx需求规格文件的情况下还需要重新编辑FIDL/FDEPL文件，影响开发效率。
ARXML支持程度不够
商用软件基本遵循AUTOSAR的标准，采用ARXML作为中间数据；开源阵营则是采用Franca接口定义语言。开源SOA工具对ARXML支持程度不够，在需要与商用工具链进行衔接时存在困难。
缺少协议栈完成度识别功能
开源SOA工具链输出的接口代码主要针对开源的CommonAPICpp，基于开源协议栈vsomeip。在对vsomeip的源码及版本历史进行解读后发现vsomeip尚不支持AUTOSAR4.3中定义的针对超长UDP数据包的SOME/ IP-TP协议；在按TC8标准对vsomeip进行ETS测试时，发现其对端到端（E2E）通信保护的支持存在问题。目前开源SOA 工具缺少检查机制，在编辑FIDL/FDEPL文件阶段不能预先给出提示，造成生成的接口代码运行时产生异常。
存在兼容性问题
兼容性问题主要存在于SOME/IP的序列化上面：SOME/ IP支持定长的字符串和数组，有不同的序列化格式，ARA支持，Franca/CAPI不支持；ARA枚举数据类型可能和Franca接口中使用的枚举数据类型不一致；SOME/IP指定了具有可选字段的结构的序列化，Franca不支持。
兼容性问题造成车载以太网内既有使用开源SOME/IP 协议栈的设备，又有使用商用SOME/IP协议栈的设备时，设备之间的互通会存在问题。
文档欠缺
文档通常是开源软件的弱项，开源SOA工具链也不例外。在车载以太网不断发展，相关的协议规范不断更新的情况下，缺少准确及时的文档对开发工作影响很大。
工具链的完善
在项目开发过程中，针对开源SOA工具链的不足，给出了完善措施，并进行了一定的实践。
首先，在常规形式检查的基础上补充了需求检查机制。我们开发了1个工具用于对Fidl/Fdepl文件进行扫描，识别业务相关的接口需求对协议栈的要求，给出后续处理建议。
在开发中碰到了采用开源协议栈的设备与采用商用协议栈的设备之间不能互通的问题，通过抓包分析，发现就是
■李佳
近日，微软团队，包括TypeScript创始人Anders Heljsberg 在内，推出TypeChat，旨在解决自然语言界
面开发过程中面临的复杂问题。在新库的文章中提到，目前的大语言模型的英文缩写（LLM）默认使用会话式自然语言，即诸如英语交流时使用的语言。而解析自然语言是一项极其困难的任务。
TypeChat基于TypeScript类型，TypeChat库可以为LLM人工智能（如OpenAI的ChatGPT）构建提示，要求LLM 以符合类型的方式返回数据。如果回复未能通过验证，TypeChat会尝试通过进一步的交互进行修复，最终Type Chat会对交互进行总结，以便在采取行动前进行确认。
数据将以JSON格式传输，文档指出，由于许多语言模型都擅长生成JSON，微软团队提供的示例包括用户输入的情感分析、咖啡馆或餐厅的订餐、日历安排、数学计算以及在Spotify上播放音乐。
好处是准确性更高、编程更容易上手，另外，由于类型限制了人工智能的响应，因此安全性也更高一些。
OpenAI之前曾推出“新的Chat Completions API中函数调用功能”。函数调用功能使得开发人员能够在调用模型时通过JSON模式描述函数，还可以令LLM输出一些带参数的JSON，以去调用这些函数。TypeChat的想法并无不同，因为这意味着LLM的输出可以与开发人员的代码进行整合。
这样一来TypeChat会不会是多余的呢？这个问题有人在TypeChat的GitHub仓库上提出过。毫无疑问的答案是：TypeChat旨在与任何LLM配合使用，而不仅仅是配合OpenAI使用。尽管目前团队提供的所有
示例都是在OpenAI 或Azure OpenAI端点上运行，但考虑到微软与OpenAI的密切关系，这也就不足为奇了。
开发者的反应各不相同，有的说：“迫不及待想试试。”也有的说：“LLM就是专门生成自然语言输出，为什么要从这样的输出获取结构化输出呢？”其实已经有很多其他项目也是在解决同样的问题，尤其是微软的Guidance项目。
不过，TypeChat的吸引力在于，数百万的开发者已经颇为熟悉TypeScript，而且TypeChat的团队包括Hejlsberg 以及TypeScript高级项目经理Daniel Rosenwasser、技术研究员Steve Lucco等资深人士。
不同工具对枚举类型的处理不同，造成序列化后的数据包不一致。当时通过手动修改工具产生的接口代码解决了问题，后来发现在Fdepl文件中可以设置关键字Enum Backing Type的值来改变枚举的默认数据类型，这样解决问题更好，所以我们更新了文件编写指南，并在Fidl/Fdepl文件扫描检查工具中增加了1个功能：对枚举类型的设置进行检查/更新。
查阅vsomeip的版本历史说明，在vsomeip3中是实现了E2E的相关机制的，包括Profile1、Profile4和Profile custom。但我们在进行ETS测试时，相关测试用例不能通过。还是抓包分析，发现加E2E保护时，vsomeip3覆盖掉E2E报头所在位置对应的data，覆盖长度与profile类型相关。结合vsomeip3的源码进行分析发现，在vsomeip3的json配置文件中，可以对e2e节进行设置，通过修改json配置文件，可以
将报头放置在真正的用户数据后面，避免数据覆盖问题。所以我们开发了一个小工具，用于对client端和server端的json配置文件进行扫描，检查/更新相关设置，当然不仅仅是e2e的设置。
正在开发的工具是需求导入工具，即xlsx→FIDL、FDEPL转换工具。xlsx中包含的信息种类较多：服务接口定义、数据类型定义、服务部署、服务发现参数等。当前的目标是在xlsx格式规范的情况下，对其中内容进行合规性扫描，在检查无错的情况下生成FIDL、FDEPL文件。为此我们编写了指导手册，对xlsx格式进行了约束。
上述工具都可以以插件形式加入主工具程序，对工具链进行完善。
车载以太网下的SOA还有一个比较大的目标，就是AUTOSAR与GENIVI的互操作能力。对工具链来说主要是实现FIDL、FDEPL与ARXML之间的相互转换。这里面需要考虑很多问题，除了前面提到的兼容性问题，还需要考虑相关规范中的限制性规定等。从目前GENIVI资料来看，Franca IDL还不能100%兼容AP的ARXML。但协议和规范在发展，工具链也将越加完善。
总之，车载以太网在不断发展，基于SOME/IP的SOA架构使得我们可以站在更高的角度应对业务的变化。对SOA 工具链进行研究进而完善，则能加快开发速度，提高系统部署和维护能力。