1.简介及功能概述
AUTOSAR在汽车网络中提供检测和可用服务(即功能实体)的功能。 为此，它被利用了IP多播及所谓SOME/IP- sd消息。服务发现模块(Sd)位于AUTOSAR BSW模型管理器模块(BswM)和AUTOSAR Socket适配器模块(SoAd)之间。 下表是文章中的缩写解释。
| BswM | Basis software manager |
| ECU | Electronic Control Unit |
| DEM | Diagnostic vent Manager |
| DET | Default Error Tracer |
| SD | Service Discovery |
| Sd | Service Discovery Module in AUTOSAR |
| SoAd | Socket Adaptor |
| SOME/IP | Scalable service-Oriented MiddlwarE over IP |
| SOME/IP-SD | SOME/IP Service Discovery |
Socked适配器在以太网栈和服务发现模块之间传递服务请求。应能够激活和取消服务发现模块的激活TCP/ ip套接字到TCP/ ip套接字的PDU并触发事件的初始传输(触发传输)。SoAds套接字连接表需要预先配置以接收其他连接表ecu的Service Discovery模块发送的单播和组播消息。
由于ECU可以连接到多个(虚拟)网络，所以可能会有多个服务发现实例，可能会有多个连接表项。每个(虚拟)接口的单播Rx、组播Rx和Tx pduid三元组需要在SoAd中配置，并为服务发现模块所知。另外，Service Discovery模块更新端点信息(IP地址和端口号)。
需要指出的是，代码文件的结构应包括以下文件：
-Sd_Lcfg.c—表示链路时间可配置参数和
- Sd_PBcfg.c -构建后可配置的参数。
该文件应包括构建后的所有链接时间和可配置参数。
服务发现模块的主要任务是管理车辆通信中称为服务的功能实体的可用性，并控制事件信息的发送行为。这允许只向需要它们的接收者发送事件信息(发布/订阅)。这里描述的解决方案也被称为SOME/IP- sd (IP-服务发现上部可伸缩面向服务的中间件)。
使用服务发现不同的服务ecu在服务车辆网络中可以提供服务实例并找到服务实例。ECU以前提供的例子可以停止提供服务。以后找到这样的服务实例会保持不响应。服务实例是由服务界面定义的单一实现。在AUTOSAR在上下文中，搜索是识别可用服务实例及其位置的操作。
除了服务实例的状态外，服务发现还可以控制特殊信息的发送，称为事件。这些事件分为Eventgroups，服务发现可以通过发布/订阅打开/关闭；因此，打开/关闭应该Eventgroup事件的发送和接收。
2.具体内容
适用以下定义：
| 服务 | 功能实体提供接口 |
| 服务实例 | 单个服务实例 |
| Offer | 提供服务实例的消息条目 |
| Stop Offer | 停止提供服务实例的消息 |
| 查找 | 用于搜索服务实例的消息条目 |
| 事件 | 实现服务实例ECU发送给使用此服务实例的服务实例ECU |
| Eventgroup | 一个或多个事件的逻辑分组。事件组是服务的一部分 |
在抽象级别上，服务可以包含零到多个eventgroup。但是，在创建整个系统时，必须将这些信息分配给不同角色的不同信息ecu(客户机和服务器)。当实例服务和包含的服务Eventgroups、ServerServices和ClientServices以及EventHandlers和ConsumedEventgroups都是从Services和Eventgroups实例化的。
一个本地ECU需要处理两种不同的服务：
(1)服务器服务-本地服务ECU为车辆的其他部分提供服务器服务实例(即位于本地)，并可视为服务器服务实例。
(2)客户端服务-本地服务ECU另一个可以可以用ECU提供的服务器服务实例，并可视为该服务的客户端实例。
本地服务器服务ECUs服务发现模块必须(服务器角色):
(1)提供本地服务(如有)；即提供服务SWC准备就绪，在ECU服务在当前状态下是可用的。
(2)当地服务不再可用时，收回服务提供(停止提供)。
（3）回答并响应其他ecu的发现。
对于客户端服务，本地服务ECUs服务发现模块必须(客户角色):
(1)监控报告，并根据配置找到将此信息存储在易失性内存中。
(2)停止监控，并根据配置将信息存储在易失性内存中。
(3)发送搜索取决于当前的搜索ECU及其swc的状态。
服务发现也可用于管理发布/订阅关系。基于发布/订阅的服务发现用例1ECU中(使用ConsumedEventgroup发布/订阅客户端ECU(使用发布/订阅服务器)接收(订阅)一些数据EventHandler)。
虽然订阅是在SD新闻中明确定义，但发布是基于服务实例本身的可用性(OfferService条目)。根据提供的发布/订阅客户端可以通过服务实例订阅SubscribeEventgroup条目。发布/订阅服务器现使用此订阅将发布/订阅客户端注册为订阅指定信息中的相关方，并开始将信息发送到发布/订阅客户端，以悬挂某些事件或加班。
作为优化，SD支持使用单个多播消息将事件消息发送到多个客户端，而不是每个客户端。
3.服务发现消息格式
服务发现信息格式应包括以下字段：
（1）请求ID(客户端ID /会话ID)[32比特]
(2)协议版[8位]
(3)接口版[8位]
(4)消息类型[8位]
(5)返回码[8位]
(6)标志[8位]
(7)保留[24位]
（8）Entries数组长度[32位]
（9）Entries数组(由“length of Entries字节长度定义为数组)
(10)选项数组长度[32位]
(11)选项数组(字节长度由选项数组的长度定义)
3.1 请求ID
由客户端ID和会话ID组成。虽然客户端I不用于服务发现，但会话ID用于检测车辆中其他服务发现实例的重新启动或重新启动，以便修复服务发现模块的本地状态。
请求ID字段由一个客户端ID字段[16位]和一个会话ID字段[16位]组成。客户机ID应该被静态地设置为0x0000。服务发现模块初始化后，本地ECU发送的消息的Session ID应为0x0001。每次调用SoAd_IfTransmit()时，会话ID应该为组播和每个单播通信伙伴分别递增和存储。这意味着发送到多播地址的第一个SD消息的会话ID是0x0001，发送到任何单播通信伙伴的第一个SD消息的会话ID也是0x0001。每次Session ID换行时，Session ID都会以0x0001的值重新开始。绕圈意味着会话ID的当前值是最大值(0xFFFF)，下一个增量意味着计数器必须重新开始。
3.2 协议版本
该字段用来描述SOME/IP的当前版本。协议版本字段的长度为8位。协议版本字段的值应该被静态地设置为0x01。
3.3 接口版本
该字段用于描述SOME/IP服务的当前版本;即当前版本的SOME/IP-SD本身。接口版本字段的长度为8位。接口版本字段的值应该被静态地设置为0x01。
3.4 消息类型
该字段用于区分某些/IP消息的类型。SOME/IP-SD只使用事件消息;因此，它总是使用相同的类型。消息类型字段的长度应为8位。Message Type字段的值应该被静态地设置为0x02。
3.5 返回码
该字段返回码用于表示请求是否被成功处理。这不适用于SOME/IP-SD;因此，返回代码将被静态地设置为0x00。返回码字段的长度应为8位。返回码字段应该被静态设置为0x00。
3.6 标志
该字段开始SOME/IP-SD报头。它用于发送全局服务发现信息，其中包括最近一次重新引导的当前状态以及接收单播消息的能力。
Flags字段的长度为8位。Flags字段的第一个位(最高顺序位)应该称为重启标志。重启后，所有消息的重启标志都应该设置为1，直到Request ID字段的Session ID结束，从而再次从0x0001开始。之后，重启标志将被设置为0。
对于单播和组播，服务发现应该跟踪通信伙伴最后一次接收的会话ID值和重启标志值。这意味着通过多播接收到的通信伙伴值不会被单播消息更新。根据连续的服务发现消息(对于通信伙伴;重启标志从0改变为1或会话ID不增加，但重启标志保持1。
服务发现也可以根据单播信息检测重启。通过会话ID和重启标志检测到的重启将导致由该通信伙伴控制的本地状态过期。重新启动服务器,客户机使用一个服务,客户办理重启如果停止提供入口是在重新启动服务器,客户机使用一个服务,服务器要处理重启StopSubscribeEventgroup条目是否收到。
Flag字段的第二个位(第二高阶位)称为Unicast Flag。Flag字段的Unicast Flag设置为Unicast Flag，设置为1，表示:该ECU支持接收单播消息。Flag字段中的未定义位应该被静态设置为0。
3.7 保留
该保留字段目前未被使用，为进一步增强SOME/IP-SD协议而保留。保留字段的长度为24位。保留字段的所有位应该被静态地设置为0二进制。
3.8 Entries数组
当SOME/IP-SD找到或提供服务实例或处理订阅时，这是由所谓的条目完成的，这些条目在SOME/IPSD消息的条目数组中传输。
Entries数组的第一个字段的长度为32位。条目数组的第一个字段应该携带条目数组的字节数(不包括这个32位字段携带长度信息)。存在两种类型的条目:服务的类型1条目和事件组的类型2条目。
Type 1 Entry的长度应为16字节。Type 1格式应包含以下字段，顺序和大小如下:
（1）类型(8位)
（2）索引1选项[8位]
（3）索引2选项[8位]
（4）# opt 1[4比特]
（5）# opt 2[4位]
（6）服务ID[16位]
（7）实例ID[16位]
（8）主版本[8位]
（9）TTL(24位)
（10）小版本[32位]
Type 1 Entry格式布局的Type字段应包含以下值之一:
（1）0x00编码FindService
（2）0x01编码OfferService和StopOfferService。
Type 1 Entry格式布局的索引优先选项运行字段的固定大小应为8位。Type 1 Entry格式布局的Index First Option Run字段将携带该条目在选项数组中的第一次选项运行的第一个选项的索引。
Type 1 Entry格式布局的索引第二选项运行字段的固定大小为8位。Type 1 Entry格式布局的Index Second Option Run字段将携带该条目在选项数组中的第二次选项运行的第一个选项的索引。Type 1 Entry格式布局的Number of Option 1字段的固定大小为4位。Type 1 Entry格式布局的选项1的数量应携带第一个选项运行使用的选项的数量。Type 1 Entry格式布局的Number of Option 2字段的固定大小为4位。Type 1 Entry格式布局的选项2的数量字段应该携带第二个选项运行使用的选项的数量。如果选项的数量设置为零，则认为该选项运行为空。对于空运行，索引(即索引第一选项运行和/或索引第二选项运行)应设置为零。实现应该接受和处理传入的SD消息，选项运行长度设置为零，选项索引不设置为零。Type 1 Entry格式的Service ID字段必须固定为16位。Type 1 Entry格式布局的ServiceID字段应该携带服务的ServiceID，使用参数SdServerServiceID和SdClientServiceID静态配置，取决于是一个服务器条目还是一个客户端条目。
Type 1 Entry格式布局的Instance ID字段应该有16位的固定大小。Type 1 Entry格式布局的InstanceID字段应该携带服务的InstanceID，使用参数SdServerServiceInstanceID和SdClientServiceInstanceID静态配置，取决于是一个服务器条目还是一个客户端条目。
如果不是单个实例而是所有实例都被寻址，Type 1 Entry格式布局的Instance ID字段应该设置为0xFFFF。第1类条目格式布局的主要版本字段应具有固定的8位大小。
Type 1 Entry格式布局的MajorVersion字段将携带SdServerServiceMajorVersion和SdClientServiceMajorVersion，这取决于是一个服务器条目还是一个客户端条目。Type 1 Entry格式布局的TTL字段必须固定为24位。
Type 1 Entry格式布局的TTL字段定义了表项的生存时间，以秒为单位，使用参数SdServerTimerTTL和SdClientTimerTTL配置。Stop-Entries除外，它们的TTL为0。Type 1 Entry格式布局的次要版本字段必须固定为32位。
Type 1 Entry格式布局的MinorVersion字段应该包含SdServerServiceMinorVersion和SdClientServiceMinorVersion。
3.9 Option
该数组是服务发现消息的最后一部分。选项数组中的选项携带附加信息。配置选项传输服务中条目的附加属性发现消息。可以使用配置选项传输0到n个配置项。这些配置项可以包括例如主机或服务的名称。
详细内容请参考《Specification of Service Discovery AUTOSAR CP Release 4.3.1》