SomeIP服务架构及开发流程讲解

对于未来智能汽车推动的汽车电子这一传统汽车专业的转型升级，其复杂的设计理念已经从面向用户转向面向开发者。即，对于汽车用户来讲只需要输入相关的服务需求即可。而实现该服务具体的工作则是开发者应该考虑的问题。  

对于未来的智能汽车来说，其重要的ECU应该同时存在基于基于新型开发架构下的 AP Autosar 的 ECU 和基于传统汽车软件架构的 CP Autosar，通过车载以太网中的 SOME/IP 这类协议通信实现AP Autosar 软件框架下的Signal2Service 、Publishe/Subscribe操作。因此，被新一代智能汽车领域所重点关注的面向服务的架构SOA （AP Autosar）通常也与 SOME/IP 常常绑定到一起进行开发。  

然而事实是，随着智能汽车对域内和跨域通信要求的不断提升，其无论是否真正需要实现面向服务架构通信，实际上对于不同ECU层之间的数据通信往往已经不仅限于CAN这类传统的通信协议。

因为无论从通信速度（CAN 一般是 512kb/s，CAN FD 能到 1MB/s，而基于 SOME/IP 的以太网能到1000 Mbps）还是通信负荷（CAN 是 8Byte，CAN FD 能到 64Byte,而 SOME/IP 能到 1500 Byte）上，CAN通信都远不及以太网ETH协议SomeIP。  

对于SomeIP来说，其通信方式为Autosar中提到的CS接口的概念，原理是在接收方有需求时才发送信息，这样可以规避出现过多不必要的数据。SomeIP支持广泛的中间件功能：包括序列化、远程过程调用（RPC）、消息传递、服务发现（SD）、发布/订阅（Pub/Sub）、UDP消息分段。因此，对于SomeiP在智能驾驶汽车中的开发一直都是近来智能驾驶汽车开发一个重点。  

SomeIP服务架构及开发流程  

结合下图说明整个SomeIP的开发模型架构。整个SomeIP从底向上分为Native层、Framework层、应用层。其中，应用层主要包含SomeIP的应用程序及服务发现端口。Framework层主要涉及SomeIP服务封装，Native层则是包含HAL层主要是将主要的车载控制硬件放到HAL层中，而作为底层操作系统（如Linux驱动仅完成一些简单的数据交互）。

其中从顶至下包括SomeIP管理模块、通信矩阵模块、通用API接口、SomeIP协议栈。前两个模块主要依赖通用应用接口和SomeIP协议栈模块。这里需要说明的是SomeIP管理模块是一个守护进程，用于为上层APP提供服务，同时负责维护SomeIP协议栈连接，SomeIP支持客户端开发SomeIP 客户端程序，也支持服务端开发SomeIP服务端程序。

同时，SomeIP的通信矩阵模块实现SomeIP所有业务的通信矩阵开发为Plugin形式被其管理模块所加载。SomeIP中的通信矩阵组件是基于通用API接口设计开发的，使用了Core-runtime和Someip-runtime两个组件。而在底层SomeIP协议栈中，以堆栈API中依赖服务发现和配置模块。  

那么对于整个与SomeIP关联的服务开发流程而言，主要涉及如下几个重要的步骤：  

1）需求设计阶段  

该阶段需要需求经理提交需要使用SomeIP业务的需求，并输出至开发工程团队。通常情况，需求经理给出的SomeIP业务需求是一组客户级别的自然语言需求，工程团队在拆解过程中，需要将该客户级别的自然语言解析成开发团队能够识别的伪代码模式需求。  

2）需求开发阶段  

开发工程团队按照需求填写SomeIP通信矩阵文档，判断通信矩阵是否规范，是否需要修改。开发主要基于SomeIP的接口进行。  

由于Someip协议被新一代智能汽车各类ECU中大量使用来进行车载以太网的数据通信。因此，在用someip协议进行通信时，需要按照someip定义的协议格式进行数据收发和处理，这类协议通信数据的数据结构类型千变万化，这将会涉及到需要将大量业务数据，并按照someip定义的协议格式进行序列化和反序列化的问题。  

序列化：指将数据结构或对象依据事先定义好的规则转换成二进制串的过程；反序列化：指将二进制串依据相同规则重新构建成数据结构或对象的过程。对于SomeIP而言，均需要将结构体各元素按照顺序序列化到缓冲区内，且序列化的过程通常是基于长度Length字段表示结构体中数据元素的字节长度。  

对于整个SomeIP开发来说包括Java端的代码开发和调用JNI接口native底层服务实现。  

①服务端与客户端顶层应用服务实现代码示例：  

对于服务端与客户端顶层开发来说，主要采用Java进行服务定义与调用。首先需要获取someip服务端实例、注册回调，启动服务端。客户端实现逻辑和服务端基本一致，只是在回调函数需要标记服务是否可用，只有可用的服务才能被客户端所订阅访问。如果检测到服务可用时，只要客户端有业务需求，则在需求触发后封装请求数据，调用request方法远程请求到服务端进行处理。  

对于SomeIP协议来说，通常需要确保其信息传输安全性，这一安全性保护通常需要使用TLS这类安全手段进行防护。如果希望使用TLS传输，则可以在启动服务器后调用配置接口来对设置TLS相关参数进行设置。    

②服务端与客户端底层服务封装实现代码示例：  

java是跨平台语言，自然而然会失去对底层的控制，于是想要调用底层方法，就必须使用native方法间接调用底层操作系统的方法(c,c++实现)。native是一个关键字，其修饰的方法只说明不实现。native方法需要加载到本地栈中。  

本示例中，Java与底层代码接口native代码实现需要依赖提前定义的函数库libsomeipnative.so。首先，定义回调函数类Class mCallBack，用以继承SomeIP的服务实例监听类SomeIpInstanceListener，在主函数中注册监听，启动服务端。并在子函数中实现对应方法。  

3）需求实现验证  

需求验证阶段主要为接口定义Topic和Protobuf文件，编写业务代码，调用SomeIP 应用接口实现业务功能。  

topic用于绑定客户端或者服务端的具体方法。上层应用只需要调用topic，HAL层服务服务就可通过topic的Java Native Interface关键字找到对应的指针调用native服务或客户端代理的相关接口。  

Topic=Message_Type->Service_id->Instance_id->Method_id   protobuf 提供了C++、java、python语言的支持，采用了二进制字节的序列化方式。保证java和native间序列化的数据能够正确的反序列化。  

SomeIP通信矩阵的设计与实现  

SomeIP通信矩阵开发是整个SomeIP开发的核心重点，也是难点。整个工程算法结构涉及编译配置，定义服务/客户Base类、接口（包含共同属性接口和回调接口），数据类型定义，插件定义，SomeIP协议栈配置文件，日志记录文件，Proto文件等。整个通信矩阵都要呕通过编译配置通过CommonAPI工具将field文件生成出口文件。  

首先，通过SomeIP通信矩阵中接口描述和部署等定义生成field文件。在应用层和SomeIP通信矩阵模块进行数据交互中需要进行序列化和反序列化操作，因此，需要定义protobuf文件进行矩阵接口描述和数据类型定义。   然后，根据SomeIP通信矩阵中的部署描述定义，生成topic文件。该文件作为惟一的，用于标识某个服务下的某一个实例接口，通常是被定义为整型数据uint64。  

此外，还要根据SomeIP通信矩阵中的部署描述定义，开发协议栈配置文件，用于对SomeIP的协议栈初始化加载。  

如上内容完成后，就需要以一定的通用工具如CommonAPI将接口描述文件通用可读源码文件（一般是C/C++代码文件）放到源码目录下。当然该目录要同样存放编译器或编译接口文件，以实现对代码的编译。  

最后，通过生成的接口文件做对应的服务及调用开发，并对对应的服务在参考示例文件中进行实例化。  

 如上图所示为SomeIP通信矩阵开发中的要素分析（以诊断调查问卷为切入点进行访问分析），其中包括在矩阵开发中需要的几种服务定义，数据类型类型定义，通信行为定义等。

其子项的设置充分考虑了关于对智能驾驶域及智能座舱域原始功能的设计关联项（如原子服务、通信数据类型、服务发现与调用等），从服务层向底层数据定义的拆解中生成代码字段。通过服务发现、调用生成的服务内容，逐渐形成SomeIp的通行行为代码。

这个过程类似Can通信诊断的开发，对于系统工程师而言，可以从顶层分析分解调用已形成的代码数据字段进行部分修改，实现在开发过程中嵌入更多有意义的服务内容，并扩充其诊断协议列表和通信矩阵表。

审核编辑：刘清