序
1 引入
- 在
SOA架构中，服务是构成系统的基本单元，它代表了系统中的某个功能或操作。
- 服务通过明确的接口与外界进行交互，实现了功能的封装和重用。
- SOA架构的核心就是服务: 它通过将应用程序划分为一系列的服务来降低系统的复杂度，提高系统的灵活性和可维护性。
- 在SOA中，服务是通过其接口被定义和访问。接口是服务与外界交互的桥梁，它定义了服务的输入、输出和行为规范。
- 在
SOA架构中，以太网通信作为服务的传输载体，负责在不同的ECU或服务之间传递数据和信息
根据
AUTOSAR平台的规范与推荐，一般选择以太网的应用层协议SOME/IP协议或者DDS协议作为跨域通信协议。
- 本文以
SOMIP协议为例进行SOA通信配置说明，它支持服务发现、服务订阅、事件通知及请求-响应等【通信模式】，是AUTOSAR标准中定义的关键通信协议之一。
可以参考
AUTOSAR官方文档，如《Specification on SOME/IP Transport Protocol》。
SOME/IP协议使得SOA架构中的服务能够在以太网环境中进行高效的通信和交互，从而实现了服务的动态发现和绑定。
2 服务接口信息配置
- 在
SOME/IP协议中，服务接口被明确划分为3种类型：Method、Field、Event
每种类型都服务于不同的通信需求。
1）Method
Method是一种请求-响应式的服务接口
客户端通过发送请求消息给服务端，并期望从服务端接收到一个响应消息。
这种类型的接口通常用于执行某些操作或计算，并返回结果。
Method接口非常适合于需要即时反馈的交互场景
如: 控制车辆某个部件的开关状态、查询当前的系统参数等。
如: 一个“打开车窗”的Method请求会被发送到车窗控制ECU，该ECU执行操作后，通过响应消息告知请求者操作是否成功。
Method又细分为RR与FF两种形式
RR：（Method with response）客户端发送请求消息（ Request） 调用某一方法， 服务端通过响应消息（ Response） 将结果返回给客户端。FF：（Method fire & forget）客户端发送请求消息（ Request） 调用某一方法， 服务端不回复响应。
- 交互过程可以参考下图：
Method交互示例
2）Field
Field接口代表了一种可以被读取或写入的数据项，它通常与某个服务的状态或配置相关。
与
Method不同，Field的访问不需要明确的请求-响应流程，而是通过订阅机制来实现数据的实时同步。
Field接口适用于需要频繁更新或监控的数据
如: 车辆的速度、温度、电池电量等。
如: 车辆仪表板ECU可能订阅了车速传感器的Field接口，以便实时显示当前车速。
- 具体的来讲，
Field分为3种类型：Setter、Getter、Notify
Field字段是客户端可以远程访问的服务端中的变量；- 客户端可以通过远程调用
Getter方法获取Field的值；- 客户端可以通过远程调用
Setter方法设置Field的值；- 当客户端订阅了某个事件组， 且事件组中包含的
Field发生变化，服务端会主动的通过Notification消息通知客户端；
- 交互过程可以参考下图：
Field交互示例
3）Event
-
Event接口用于通知客户端某些重要事件的发生，这些事件可能是由服务端自主触发的，也可能是对外部条件变化的响应。 -
Event的发送是单向的
即: 服务端向订阅了该事件的客户端发送通知，而不需要等待客户端的响应。
Event接口非常适合于异步通知场景
如: 碰撞预警、车门未关警告等。
如: 当车辆检测到即将发生碰撞时，碰撞预警系统会通过Event接口向驾驶员辅助系统发送碰撞预警通知，以便及时采取措施。
- 交互过程可以参考下图：
- 在实际通信过程中，客户端首先订阅（ Subscribe） 服务的某一事件组（ Event Group） ， 当事件组中包含的事件发生之后，服务端将通过
Notification消息（Notify） 通知客户端：
Event交互示例
上述针对Method、Field、Event三种通信类型介绍的各种使用场景并无绝对，根据实际开发场景、开发习惯可以灵活调整
如: 一个“打开车窗”的请求场景，使用Method和Field都可以实现。
4）服务接口信息设计的案例举例
如: 给出以下氛围灯功能的软件架构需求，对其配置通信信息；
针对模式控制和模式获取，可以采用Method中RR方法；针对模式通知可以使用Event类型；
- 对于服务的每个接口，都要设定
ID来代替，在SOMEIP协议中，这部分字段占有16 bits
一般都会用十六进制来表示，需要在每个服务内保持唯一性，同时避开特殊取值，如0x0000与0xFFFF；
-
对于通知类型的接口，会设定事件组，来同时接收该组内所有事件和属性的通知，而无需分别订阅每个单独的事件或属性，同样需要一个16bits的字段来表示事件组；
-
特别注意，根据协议规范，通知类型消息，即
Notifier/Event的ID，16bits最高位固定为1，不会是0；
即：0 - Method / 1 - Event
另外，
SOMEIP协议是基于IP层的应用层协议————故：也需指定以太网传输层的协议（UDP or TCP）
- 根据以上信息，可以制定服务通信矩阵如下：
类似的，也可以使用
field类型通信：
注意：一般情况下，
Method的RR类型接口返回值通常是为了表示接口调用的状态，Field的Setter类型接口不仅执行字段的赋值操作，还返回了操作后的某种数值结果，以便于调用者了解设置操作的影响。
3 服务通信信息配置
- 在
SOME/IP中，消息的发布、发现与订阅机制是其核心功能之一，它严格遵循以服务为单位的通信原则。
这一机制使得不同的服务能够在车辆内部网络实现高效、灵活的数据交换。
为了确保服务间通信的顺利进行，每个服务在参与通信之前，都需要进行详尽且细致的通信信息配置。
- 首先，服务ID（
Service ID）是区分不同服务的唯一标识符。
每个服务都会被分配一个特定的服务ID，这个ID在整个网络中必须是唯一的，以确保消息的准确路由和识别。
服务ID的分配通常遵循一定的规则或标准，以便于管理和维护，同样避开特殊取值，如0x0000与0xFFFF。
- 其次，实例ID（`Instance ID）进一步细化了服务的身份标识。
在某些情况下，同一类型的服务可能需要以多个实例的形式存在，以满足不同的通信需求。
实例ID就是用来区分这些同类型服务的不同实例的。
例如：同一车的4个摄像头，即可用不同的实例ID做区分。
- 接下来是单播通信的配置。
- 每个服务都需要配置一个或多个单播IP地址（
Unicast IP Address）以及对应的单播端口号（Unicast Port Number）。- 单播IP地址用于标识服务在网络中的位置，而单播端口号则用于区分同一IP地址上运行的不同服务或应用。
- 单播通信允许服务之间建立直接的、点对点的通信链路，适用于需要即时响应或高可靠性的通信场景。
- 对于发布-订阅模式的通信，事件组（Event Group）的配置是必不可少的。
- 事件组是一组相关事件的集合，它们共享相同的组播IP地址（Multicast IP Address）和事件组端口（Event Group Port）。
- 当一个服务发布事件时，它会将事件消息发送到相应的事件组组播IP地址和端口上，所有订阅了该事件组的节点都会接收到这个消息。
这种方式极大地提高了通信的灵活性和效率，特别适用于需要向多个节点同时发送相同信息的场景。（如果协议上未对事件组配置组播通信形式，可以不配置事件组的组播IP与端口号）
- 此外，服务SD（
Service Discovery）信息的配置也是服务通信中不可或缺的一环。
服务SD IP地址（Service Discovery IP Address）用于标识服务发现服务的位置；- 而服务SD端口号（Service Discovery Port Number）则用于指定服务发现服务监听的端口，根据
AUTOSAR的官方建议统一为30490。- 服务发现服务负责在网络中广播服务的信息，使得其他服务能够发现并进行通信。
VLAN划分（Virtual Local Area Network Partitioning）则用于提高网络的安全性、可管理性和可扩展性。
- 通过
VLAN划分，可以将物理网络分割成多个逻辑子网，每个子网都包含一组具有相同通信需求的服务。- 服务在配置时需明确指定其所属的
VLAN，以确保消息能够在正确的网络区域内传输。
结合以上分析，针对氛围灯服务可以给出如下配置：
一般情况下，也需要指明部署在哪个控制器上，不过单播IP也明确了唯一的控制器；也需要指明，该服务在该控制器上是以何种身份存在，即，是
Client还是Server，以便明确该服务部署是服务发布方还是服务发现方；
综上所述，
SOME/IP协议中的服务配置是一个复杂而精细的过程，它涉及到服务ID、实例ID、单播IP、单播端口号、事件组组播IP、事件组端口、服务SD IP、VLAN划分、服务SD端口号等多个方面的信息。通过详尽的配置和精细的管理，可以确保服务在网络中能够高效、可靠地进行消息的发布、发现与订阅，为车辆实现SOA大带宽通信。
X 参考文献
- 车载服务通信（SOME/IP）设计实践 - Weixin/焉知汽车
