SOME/IP是一种汽车中间件解决方案，其全称是ScalableService-OrientedMiddlewareoverIP，即位于IP协议层以上的一种面向服务的可扩展的中间件。全称有点拗口，下面通过拆解来说明。
“中间件”，该术语起源于复杂的软件系统开发，用以实现软件组件之间的数据交换，这种数据交换通常需要经由网络，中间件的任务就是确保需要交换数据的软件组件在网络中透明地传输数据。SOME/IP作为一种中间件负责组织传输复杂数据（消息传递）并约定软件组件之间的函数调用（远程过程调用，RPC）。
如今汽车中的软件数目十分庞大，并且还会随着汽车内部功能和系统的分布扩张而不断增加。这些分布式功能可能使用到一个ECU中的不同进程，也可能扩展到不同ECU的各种进程中去，随着系统复杂度的增加，不可能仅仅将消息放入到网络中传输就完成功能的实现，还需要使用RPC来正确控制这些分布式功能；另外，不同ECU可能使用不同的软件架构以及操作系统，因此还需要中间件来桥接不同的便携式操作系统接口（如Linux或QNX和AUTOSAR系统之间的衔接）。
“可扩展”，表示SOME/IP能够实现不同硬件平台、不同操作系统或嵌入式固件以及不同应用软件的异构设备之间的可扩展性和互操作性。
高端信息娱乐系统最需要基于服务提供的复杂接口，如复杂的数据类型、对数据库的访问、列表的传输等。在其他使用车载网络的系统中，CAN总线的使用仍占主导地位，信息在网络中传输，由接收器决定如何处理该信息。但是，在新型应用领域，如辅助驾驶领域，CAN的通信方式越来越不适用。另外，在CAN中，数据长8Byte，且没有大量的头信息，这些均限制了RPC或服务发现(ServiceDiscovery,SD）的使用。
“位于IP协议层以上”，这表明了SOME/IP协议在汽车以太网协议栈中所处的位置，汽车以太网协议栈总共可划分为五层，分别为物理层、数据链路层、网络层、传输层、应用层，SOME/IP协议是一种应用层协议。
二
SOME/IP&SOME/IP-SD简介
SOME/IP是一种汽车中间件解决方案。它从一开始就被设计为能够完美适配不同尺寸和不同操作系统的设备，像是小型ECU如摄像头、AUTOSARECU、以及信息娱乐ECU如车载信息娱乐系统（HeadUnits），还有远程通信设备等，都可以使用SOME/IP协议有效地交换ECU间的消息。同时SOME/IP还支持信息娱乐领域的功能以及车辆中其他领域的功能，使SOME/IP能够用于MOST以及更传统CAN方案的替换方案。
SOME/IP支持广泛的中间件功能：
【表格】
对于表中提到的服务发现再补充两句，SOME/IP-SD是SOME/IP中的服务发现机制，通过SOME/IP-SD，SOME/IP可以确定服务是否可用，客户端可以通过SOME/IP-SD来查找服务的地址，判断服务的可用性，或者订阅事件组等。
三
SOME/IP协议分析
3.1面向服务的通信
区别于传统CAN/LIN等面向信号（Signal-Oriented）的通信方式，SOME/IP提供面向服务（Service-Oriented）的通信方式。
由于基于信号的通信解决方案中的软件和硬件紧密耦合，因此ECU之间的通信是静态定义的。基于信号的通信是一种根据发送者需求实现的通信过程，当发送者发现信号的值变化了，或者发送周期到了，就会发送信息，而不考虑接收者是否有需求。
而在面向服务的架构中，发送方仅在接收方需要时才发送数据。这种方法的优点在于总线上不会出现过多不必要的数据，从而降低负载，不过这仅仅是基于服务通信的一方面。当谈论到自动驾驶、ADAS、联网汽车等时，面向服务的架构(SOA)是必不可少的。在以太网和SOME/IP的支持下，SOA将整个系统建模为serviceinterface，可以轻松地将新软件添加到系统中，而无需担心与其他软件的兼容性。
如上图所示：
SOME/IP为应用程序提供抽象的面向服务的接口，因此，应用程序不需要处理IP地址和端口，而只需要处理服务。Server端提供了一个实现服务接口的服务实例（服务接口，直白理解就是服务与外界通信的接口，也就是服务模块与外界沟通的基本出入口）。Client端则通过SOME/IP方式使用服务实例。
3.2SOME/IP通信机制
SOME/IP支持的通信模式包含以下四种形式：
客户端可以通过远程调用Getter方法获取Field的值，也可以通过远程调用Setter方法设置Field的值。另外和Event相似，当客户端订阅了某个事件组，若EventGroup中包含的Field发生变化，服务端会主动的通过Notification消息通知客户端；当然，用户也可以选择周期发送Notification消息。
Field和Event的区别是：Field是一个持续存在的变量，比如多媒体音量、车速、环境温度等，这些可以在任何时刻获取；而Event指的是一个事件，事件没有发生就不存在，比如发生碰撞，出现故障等。
下面看一个实际的例子来对这些通信模式产生更具体的印象：
服务是由智能摄像头控制器提供的，可提供的具体服务之一是检测限速标志。ADAS（高级辅助驾驶系统）需要摄像头提供的限速标志信息，因此ADAS控制器会作为客户端。
4种通信模式的例子：
3.3SOME/IP协议报文格式
SOME/IP协议在OSI七层网络结构中位于应用层，从功能上讲，SOME/IP是一种将服务接口进行打包或解包的中间件：从应用层发送的数据按照SOME/IP的格式打包后，再传递到下层的TCP/IP或UDP/IP层，再进行逐层打包和封装，最终通过物理层以比特流的形式进行传输；接收时则按照与打包相反的规则进行解包。
SOME/IP报文由消息头（Header）和数据段（Payload）组成，报文结构如下：
3.3.1MessageID[32bit]
MessageID用于唯一标识服务的Method或Event，可区分不同的服务。MessageID对于整个车辆系统来说必须是唯一的。
MessageID的结构：
MessageID前16位是ServiceID，每个服务需要有一个唯一的服务ID，由系统集成商进行标识。后16位是MethodID。
对于Method，MessageID的结构如下：
其中MethodID的第一个位（bit）是0。使用16位的Service-ID和从0位开始的16位的Method-ID(对于实际值，Method-ID中还剩下15位)，这将允许最多65536个服务，每个服务最多32768个方法。
对于Events和Notifications，MessageID的结构如下：
对于Events来说，MethodID的第一个位（bit）是1。这意味着每个服务最多可以有32768个事件或通知。
可以看出，MethodID的最高位可用来判断具体的通信方式，即采用的是Method还是Event。
3.3.2Length[32bit]
Length字段长度为32位，包含从RequestID开始到SOME/IP消息结束的长度，长度是以字节为单位的。注意，Length不包括MessageID和Length。
3.3.3RequestID[32bit]
RequestID是客户端的唯一标识符，要能在响应到达前或超时前不被重用。
在生成响应消息时，服务器必须将RequestID从请求中复制到响应消息中去，这才使得客户端可以将响应对应到发出的请求上。
RequestID前16位是ClientID，用来区分特定的客户端，在整车系统中该值必须唯一；后16位是SessioID，用来标识同一客户端的多次请求。
SessionID主要用于Request&Response类型的多次调用，每调用一次，SessionID增加1。
如果会话不在活动状态，SessioID设置为0x00，当会话处于活动状态时，SessioID设置为[0x1,0xFFFF]范围内的值。当SessionID为0x00时，服务器并不会对这个请求作出反应。
3.3.4ProtocolVersion[8bit]
该字段存放SOME/IP协议的版本号，用来识别使用的SOME/IP头格式（不包括payload的格式）。目前固定为1。
3.3.5InterfaceVersion[8bit]
该字段存放服务接口的版本号，用来识别服务接口的主版本号。
3.3.6MessageType[8bit]
MessageType字段用于区分不同类型的消息，包含如下值：
【表格2】
当没有错误发生时，常规请求(MessageType0x00)应由响应(MessageType0x80)响应。如果发生错误，将响应包含错误的消息(MessageType0x81)。
MessageType的第三高位(=0x20=0b00100000)被称为TP-Flag，设置为1表示当前的SOME/IP消息是一个segment。
3.3.7ReturnCode[8bit]
ReturnCode用来表示请求是否被成功处理。为了简化header布局，每个消息中都会传输ReturnCode字段。
【表格3】
3.3.8Payload[variablesize]
Payload由Event的数据元素或Method的参数组成，大小取决于所使用的传输层协议，对于UDP，payload介于0到1400个字节之间，由于TCP支持payload分段，所以支持更大的长度。
注意：SOME/IP所有的Header字段必须以网络字节顺序(大端字节序)编码。Payload内参数的字节顺序应由配置来定义。
3.4SOME/IP服务示例
下面来看一个场景示例，以CD播放器（CD_Player）服务为例。
通常使用接口描述语言（IDL）来定义服务的服务接口，如下所示：
ServiceCD_Player{track_number//Field{unsignedinttrack;//曲目编号set(track);//设置曲目的方法(使用Request&ResponseMethod)get();//获取实际播放曲目编号的方法}tray.eject();//按下弹出(eject)按钮时触发的事件Booleantray_state;//当CD托盘打开或关闭时，状态分别为OPEN或CLOSEDtray_state:open_tray();//用于打开托盘的方法，该方法的返回值为tray_state}在定义了上述接口之后，假设此时用户（HU，车载主机）希望将CD_player设置为Tracknumber10，那么HU将会向CD播放器（服务器）发送命令CD_Player.track_number.set(10)。该服务的方法为track_number.set,set值为10。此命令设置的通信方式为request/response，即该命令设置后希望接收到回应。
另一个场景：用户（HU）希望打开CD托盘，并反馈完成情况。那么，在上述命令中，用户将向CD播放器发送设置指令CD_Play.open_tray()，且希望得到CD播放器的反馈（基于request&response的通信方式）。当HU接收到CD_Player.open_tray()==OPEN指令时，说明它发出的命令已经成功执行了。
在上述情境中，用户还可以向CD播放器发送read(“getfield”）指令，接收CD播放器track状态的信息。它也可以订阅CD播放器track状态信息：每当CD播放器状态改变时都将自动向用户发送通知（“event”)。还有一条命令：“Subscribe.CD_Player.Eject()”，当CD托盘打开后，CD播放器会向所有订阅用户发送此命令。
3.5SOME/IP协议报文格式
SOME/IP-SD依赖于SOME/IP，SOME/IP本身支持TCP和UDP通信，但SOME/IP-SD只能通过UDP进行传输。
SOME/IP-SD主要用于：
以上功能主要是通过offer消息来实现的，即每个设备广播(组播)的消息中包含该设备提供的所有服务。如果客户端应用程序需要某项服务，但目前没有服务器主动提供，那么客户端也可以发送“find”消息。
SOME/IP-SD报文也是一种SOME/IP的数据报文，是在SOME/IP数据报文的基础上进行了扩展，增加了Entry、Option等字段；Entry用于同步服务实例的状态和发布/订阅的管理，Options用于传输Entries的附加信息。
下图给出一个SOME/IP-SD报文示例：
可以看出，报文中存在两组EntryArray，一个SD报文可能包含多个Entry，每个Entry大小都是16个字节，一个Entry可能包含0-2个Option。
下面来看具体每项的含义：
MessageID：
对于SD，ServiceID固定为0xFFFF，MethodID固定为0x8100。
RequestID：
ClientID一般固定为0x0000。SessionID初始为0x0001，每发送一次数据后便加1。
ProtocolVersion：
固定为0x01。
InterfaceVersion：
Messagetype：
固定为0x02(Notification)。
ReturnCode：
固定为0x00(E_OK)。
Flags：
SOME/IP-SD报头以一个8位的Flags字段开始，它用于标识全局ServiceDiscovery信息。Flags=重启标志(RebootFlag)+单播标志(UnicastFlag)，如下图所示：
Flag字段中的未定义位应静态设置为‘0’。
Reserved：
为空，当前不需要考虑；
EntriesArray：
Entry可以理解为“入口”，包含了服务实例以及需要订阅的事件组的信息，EntriesArray分为两类，针对服务的ServiceEntry和针对事件组的EventgroupEntry。
格式分别如下：
ServiceEntry：
ServiceEntry用于服务发现。
Type：FindService(0x00)、OfferService(0x01)、StopOfferService(0x01)；
IndexFirstOptionRun：OptionArray中第一个Option的索引；
IndexSecondOptionRun：OptionArray中第二个Option的索引；
#ofopt1：第一个Option使用的选项数；
#ofopt2：第二个Option使用的选项数；
ServiceID：表示该Entry所涉及的服务或服务实例的ServiceID；
InstanceID：表示该Entry涉及服务实例的InstanceID，如果包含一个服务的所有服务实例，则设置为0xFFFF；
MajorVersion：服务的主版本号；
TTL：Entry的生命周期，单位为秒；
MinorVersion：服务的次版本号。
EventgroupEntry：用于事件订阅。
Type：SubscribeEventgroup（0x06）、StopSubscribeEventgroup（0x06）、SubscribeEventgroupAck（0x07）、SubscribeEventgroupNack（0x07）；
InstanceID：表示该Entry涉及服务实例的InstanceID，任何实例的InstanceID都不能设置为0xFFFF（这一点和在ServiceEntry中的不同）；
Reserved：应被设置为0x000;
Counter：用于区分同一订阅者的订阅事件组。如果不使用，设置为0x0；
EventgroupID：事件组ID。
OptionArray：
主要存放Entry的附属选项信息，对于不同类型的消息，要配置的选项也不一样。
3.6SOME/IP-SD应用场景
这里参考《汽车以太网AutomotiveEthernet(原书第2版)》，罗列SOME/IP-SD的几种应用场景。
3.6.1汽车启动时
3.6.2客户变更时
客户在购买汽车时，汽车厂商向客户提供了许多选择。作为一条经验法则，汽车越大，价格越高，可供选择的选件或功能就越多。大量的选择意味着汽车制造商根据特定客户的要求制造专属汽车。如果没有SD，每个ECU需要通过静态配置确定汽车中其他ECU功能的可用性。但是通过SD,ECU则可以自行建立车辆中可用的功能/ECU列表，而不需要任何特定组合的预配置。这一方式显然更为可靠。因此，汽车越复杂，SD的优势就越大。
3.6.3事件传输失败时
3.6.4局部网络保证能源效率时
随着车载网络规模的不断扩大和ECU数量的增加，能耗问题不容忽视。如果能够做到在特定时刻仅对使用的ECU进行100％供电那是最理想的。比如，客户已经抵达目的地且停放好车辆，但是希望通过内置的免提系统完成呼叫，那么汽车应该停用网络上不需要的其他ECU，包括发动机控制系统或传动系统等。这个例子表明，车载网络可能会动态变化。在变化的环境中，工作的ECU必须知道哪些功能仍然可用，哪些不可用。假如没有SD，也可以通过超时来实现上述目的。但是，在使用场景相同的情况下，使用超时方法的响应速度不如SD快。通过SD获取功能可用信息将更具有时效性。车载网络越复杂，就越能体现基于服务的通信方式和SD的优势。
四
Yeskit僵尸网络家族分析
汽车以太网聚焦于车内联网，即车内各种电子控制单元（ECU，ElectronicControlUnit）之间的通信。
“随着消费者对车载连接和高级驾驶辅助(ADAS)的需求不断增长，汽车行业一直面临着这样一个挑战，即提供具有竞争力的创新功能，同时最大限度降低成本。汽车以太网技术允许多个车载系统通过一对非屏蔽双绞线（UTP）同时访问信息。通过消除繁琐的屏蔽布线，汽车制造商可以显著降低连接成本和布线重量。”这段来自OPENAllianceInc.官网上的描述简单明了的介绍了汽车以太网技术发展的初衷。
2013年，采用博通BroadR-Reach技术的宝马X5量产，标志着汽车以太网技术的正式应用。紧接着，各种行业组织和国际标准组织也积极参与到汽车以太网技术的标准化工作中，推动了汽车以太网技术的发展。在汽车以太网标准化方面，下面4个标准化组织或联盟起到了主要的推动作用，它们是IEEE802.3和IEEE802.1工作组、OPEN联盟、汽车开放系统架构联盟AUTOSAR、以及AVnu联盟。
4.1IEEE
InstituteofElectricalandElectronicsEngineers，电气和电子工程师协会，他们根据汽车行业需求，对汽车以太网的物理层和上层通信协议进行标准化。
针对汽车以太网标准，IEEE组织也对IEEE802.1和IEEE802.3标准进行了相应的补充和修订。具体为：
4.2OPENAlliance(One-PairEther-Net)Inc.
是一个非盈利的、开放的行业联盟，主要由汽车行业和技术供应商参与合作，鼓励在汽车网络应用中广泛采用基于以太网的网络作为标准。
据OPENAlliance官网发布的新闻显示，截至2020年2月，OPENAlliance共成立了15个技术委员会（TechnicalCommittees），专注于推动汽车以太网标准。他们的目标是创建和发布以太网领域各个方面的规范，比如：
OPENAlliance发布的TC8是目前行业内关于汽车以太网的标准测试规范之一，在2.0版本中加入了对SOME/IP协议的测试。
4.3AUTOSAR联盟
AutomotiveOpenSystemArchitecture，即汽车开放系统架构，是一家致力于制定汽车电子软件标准的联盟（参与者有全球各家汽车制造商、零部件供应商以及各种研究、服务机构）。
汽车行业里有众多的整车厂（OEM）和供应商。每家OEM会生产很多车型，对不同子系统和零部件会选择不止一家供应商，每家供应商也会向不止一家OEM供货。减少开发成本最有效的办法就是，尽可能让产品可重复利用，用数量来分摊开发成本。OEM希望可以让同一套系统和部件用在不同的车型上,同一辆车上来自不同供应商的各个系统和部件可以相互兼容；供应商希望开发出来的部件和算法可以通过简单的软件调整就供给不同的OEM。此外，各个供应商的开发进度往往是不同步的。OEM希望可以在供应商开发的过程中就可以测试该部件是否与整车上的其它系统正确配合。因此，需要一种统一的、标准化的系统描述方法。
这便是AUTOSAR的初衷，即通过提升OEM以及供应商之间软件模块的可复用性和互换性来改进对复杂汽车电子电气架构的管理。
ClassicAUTOSAR从4.0版本开始支持汽车以太网通信，主要包括Ethernet驱动、Ethernet接口、TCP/IP、SocketAdaptor、DoIP、UDPNM、SOME/IP等软件模块。
SOME/IP被AUTOSAR集成的几个关键发展节点如下：
4.4Avnu联盟
正是由于IEEE组织、OPEN联盟、AUTOSAR联盟、以及AVnu联盟的共同发展与合作，规范了汽车以太网符合OSI模型的整体架构。
图中蓝底色的部分为汽车以太网技术协议，灰底色的部分为传统以太网技术协议。
以太网提供了主干网，TCP和UDP提供了传输层，但数据序列化、远程过程调用等还需要一个中间件，这也正是SOME/IP被创建的原因！
另外，上图中涉及的汽车以太网应用协议的基础特点以及应用场景罗列如下：
【表格4】
附录参考链接
[1]未来汽车的神经与血管--车载以太网-大大通
[2]车载操作系统（五）：AUTOSAR规范
[3]Some/IP如何应用于面向服务架构SOA架构开发
[4]汽车以太网标准化组织介绍_怿星科技的博客-CSDN博客
[5]COMMUNICATIONPROTOCOLSFORETHERNETINTHEVEHICLE
[6]HowSOME/IPEnablesServiceOrientedArchitectureinECUNetwork
[7]【SOME/IP通信系列】(九)解读SOME/IP-SD服务发现协议
[8]SOME/IP-SD深入浅出
[9]汽车以太网协议知多少
[10]WhatisSOME/IPProtocol
[11]一文搞懂车载以太网之SOME/IP
[12]OpenAllianceOpenAlliance官网
[13]基于SOME/IP的残余总线仿真环境
[14]一文搞懂车载以太网之SOME/IP
[15]ClassicPlatform-AUTOSAR
[16]一文入门车载以太网，吐血整理!不看可惜！
[18]面向服务通信与面向信号通信
[19]SOME/IP有那么难吗？
[20]AdaptiveAUTOSARvsClassicAUTOSAR
[21]SOME/IP如何在ECU网络中实现面向服务的架构_多源焦点
[22]Some/IP如何应用于面向服务架构SOA架构开发_Mode_Type_套接字
[23]HowSOME/IPEnablesServiceOrientedArchitectureinECUNetwork
[24]详解SOME/IP协议文档_aFakeProgramer的博客-CSDN博客_someiptp
[25]vsomeip-GENIVI的SOME/IP开源实现
[26]车载以太网|测试之实锤-SOME/IP概述及TC8SOME/IP测试实践-知乎
[27]《汽车以太网AutomotiveEthernet(原书第2版)》
关于绿盟科技格物实验室
绿盟科技格物实验室专注于工业互联网、物联网和车联网三大业务场景的安全研究。实验室以“格物致知”的问学态度，致力于以智能设备为中心的漏洞挖掘和安全分析，提供基于业务场景的安全解决方案。积极与各方共建万物互联的安全生态，为企业和社会的数字化转型安全护航。