#01 引 入

在SOA架构中，服务是构成系统的基本单元，它代表了系统中的某个功能或操作。服务通过明确的接口与外界进行交互，实现了功能的封装和重用。SOA架构的核心就是服务，它通过将应用程序划分为一系列的服务来降低系统的复杂度，提高系统的灵活性和可维护性。在SOA中，服务是通过其接口被定义和访问。接口是服务与外界交互的桥梁，它定义了服务的输入、输出和行为规范。

在SOA架构中，以太网通信作为服务的传输载体，负责在不同的ECU或服务之间传递数据和信息，根据AUTOSAR平台的规范与推荐，一般选择以太网应用层协议SOME/IP协议或者DDS协议作为跨域通信协议。

本文以SOMIP协议为例进行SOA通信配置说明，它支持服务发现、服务订阅、事件通知以及请求-响应等通信模式，是AUTOSAR标准中定义的关键通信协议之一。可以参考AUTOSAR官方文档，如《Specification on SOME/IP Transport Protocol》。SOME/IP协议使得SOA架构中的服务能够在以太网环境中进行高效的通信和交互，从而实现了服务的动态发现和绑定。

#02服务接口信息配置

在SOME/IP协议中，服务接口被明确划分为三种类型：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分为三种类型：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协议中，这部分字段占有16bits，一般都会用十六进制来表示，需要在每个服务内保持唯一性，同时避开特殊取值，如0x0000与0xFFFF；

对于通知类型的接口，会设定事件组，来同时接收该组内所有事件和属性的通知，而无需分别订阅每个单独的事件或属性，同样需要一个16bits的字段来表示事件组；

特别注意，根据协议规范，通知类型消息，即Notifier/Event的ID，16bits最高位固定为1，不会是0；

另外，SOMEIP协议是基于IP层的应用层协议，所以也需要指定以太网传输层的协议；

根据以上信息，可以制定服务通信矩阵如下：

类似的，也可以使用field类型通信：

注意，一般情况下，Method的RR类型接口返回值通常是为了表示接口调用的状态，Field的Setter类型接口不仅执行字段的赋值操作，还返回了操作后的某种数值结果，以便于调用者了解设置操作的影响。

#03服务通信信息配置

在SOME/IP中，消息的发布、发现与订阅机制是其核心功能之一，它严格遵循以服务为单位的通信原则。这一机制使得不同的服务能够在车辆内部网络实现高效、灵活的数据交换。为了确保服务间通信的顺利进行，每个服务在参与通信之前，都需要进行详尽且细致的通信信息配置。

首先，服务ID（Service ID）是区分不同服务的唯一标识符。每个服务都会被分配一个特定的服务ID，这个ID在整个网络中必须是唯一的，以确保消息的准确路由和识别。服务ID的分配通常遵循一定的规则或标准，以便于管理和维护，同样避开特殊取值，如0x0000与0xFFFF。

其次，实例ID（Instance ID）进一步细化了服务的身份标识。在某些情况下，同一类型的服务可能需要以多个实例的形式存在，以满足不同的通信需求。实例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大带宽通信。