什么是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系统设计（下）》。
