让SOME/IP运转起来——SOME/IP系统设计（上）

什么是SOME/IP？

SOME/IP（Scalable service-Oriented MiddlewarE over IP）是AUTOSAR应用层的协议，是基于IP协议的面向服务的可拓展性的中间件。

SOME/IP中主要定义了：

• 数据的序列化：SOME/IP支持的数据类型，复杂数据的序列化及反序列化方式
• 通信机制：提供Request/Response、Fire&Forget、发布-订阅的通信机制
• 服务发现：实现节点在网络上找到可用的服务，还可以进行订阅

SOME/IP作为一种通信协议，主要应用于车内ECU之间的通信，相比较传统的CAN来说具有可扩展性，报文传输内容更多，基于以太网，面向服务等优势。

那么如何使用SOME/IP实现车内ECU之间的通信呢？

SOME/IP系统设计

SOME/IP的系统涉及几个层面：功能，功能逻辑，通信，ECU部署。

由于功能需求、功能逻辑、ECU部署由架构工程师开发，通信过程由通信工程师进行设计，中间交接的部分是十分重要的，因此在整个过程中，需要架构工程师和通信工程师的共同合作，才能达到一个正确的设计结果。

SOME/IP系统设计需要通信工程师梳理使用SOME/IP传输的信号以及信号传输的逻辑，并将这些信号设计成服务接口，以符合SOME/IP面向服务的特点和通信机制，通信的逻辑形成时序图，可以为系统测试提供输入。

在整个系统设计的过程中会涉及到三个输出产物：

• UC：以太网Use Case，承接架构的开发产物，用来梳理使用SOME/IP传输的信号内容和逻辑。
• 矩阵：SOME/IP服务接口设计，将UC中梳理出来的需要使用SOME/IP传输的信号，以符合SOME/IP要求的服务接口的格式进行设计。矩阵还可以转换为ARXML供下游工具解析，并以此为基础继续开发。
• 时序图：将UC中使用SOME/IP传输的功能的逻辑绘制为时序图，为系统测试提供输入。

系统设计注意事项

UC

系统设计的第一步，作为架构工程师与通信工程师之间工作衔接的中间产物，需要双方明确功能、信号、逻辑等，才能保证系统设计的正确性。

矩阵

• 服务划分：可以根据功能或者SWC进行划分
• 唯一标识符：Service ID、Method ID、Instance ID需要全局唯一指示服务接口
• 服务接口：根据SOME/IP通信机制和接口类型的定义，选择能够实现功能的通信逻辑的接口和通信机制
• 数据类型：根据SOME/IP对数据类型的要求，选择能够实现功能通信信号的数据类型，以确保SOME/IP可以正确序列化和反序列化
• 订阅组：订阅的服务接口需要部署在某个EventGroup里，才能实现订阅
• 通信协议选择：根据TCP和UDP的特点选择即可，如TCP更加可靠，UCP更加实时
• 版本管理：可以根据平台或者车型的更新或扩展计划进行版本管理，需要保证向后兼容

时序图

需要体现Server和Client的ECU、服务、信号传输使用的服务接口，必要时还要体现接口具体传输的数据以及事件发送的机制。

SOME/IP通信设计例子

功能需求整理

• 功能需求：通过HU接听电话，并且在屏幕上显示通话相关信息及状态
• 子系统：该功能分为“交互”和“通话”两个逻辑单元
• ECU部署：“交互”部署到HU，“通话“部署到TBOX

梳理交互逻辑及信息

• 电话呼入
• TBOX向HU发送通话信息
• HU进行显示
• 用户通过HU进行操作
• HU向TBOX发送接听或者拒绝通话
• TBOX向HU反馈操作响应并执行相应动作
• 如果通话信息及状态有更新，TBOX向HU发送相关信息

服务接口设计

根据梳理的交互逻辑及信息，将服务定为TBoxTelephony，部署在TBOX上，服务接口分别为CallOperarion和CallInfo，分别用于控制电话接听或者拒绝和通话相关信息及状态。

下表为接口设计内容：

传输协议选择

根据TCP和UDP的特性，以及实际功能的要求，每个服务接口单独选择。

端口定义

系统设计的第一步，作为架构工程师与通信工程师之间工作衔接的中间产物，需要双方明确功能、信号、逻辑等，才能保证系统设计的正确性。

时序图设计

总结

SOME/IP系统设计实现了系统内ECU之间的SOME/IP通信，设计思路可以总结为确定功能需求，梳理功能的逻辑及信息，设计服务接口，传输协议及端口号的定义等。

矩阵内包含的服务接口设计是覆盖整个系统的，ECU的开发都需要遵循矩阵的设计，但是矩阵的内容可以是确定的，格式可能会大不相同，因此就需要一种统一的格式来承载——ARXML（AUTOSAR XML）格式文件，那么ARXML是如何生成的呢？敬请期待《SOME/IP系统设计（下）》。