SOME/IP协议内容（一）
SOME/IP协议应该提供基于服务的通信，其中通信路径是在运行时建立的。
基本原理:基于服务的通信允许在系统设计阶段没有预定义的通信。
用例:在系统设计阶段，伙伴之间的通信不是静态定义的。
SOME/IP协议应支持协议的多个版本，以区分网络上消息的版本。
基本原理:一个版本需要能够区分SOMEIP消息的不同版本与不同的结构在头部或有效载荷。
用例:在同一网络中同时使用旧协议和新协议的情况下，对SOME/IP进行向后不兼容的扩展和修改。
SOME/IP协议应该支持事件通信，事件通信是由服务提供者产生和发送的单向通信。
基本原理:在网络上的通信中需要考虑基于事件的通信。
用例:在事件基础上产生的数据的通信，例如变速。
SOME/IP协议应该支持不同的事件通信更新策略，以便在循环基础上或当值发生变化时进行通信
基本原理:不同的数据需要在不同的条件下进行交流
用例:一些基于事件的数据只需要在更改时进行通信，另一些则以循环方式进行通信，例如，为了避免在运行时重新启动ecu时出现错误
SOME/IP协议应该支持单播和组播的事件通信，以及基于可配置阈值的单播和组播之间的自动切换。
基本原理:根据接收方数量的不同，单播或多播通信效率更高。单播消息是一种为某些不需要在接收不需要的数据上花费处理资源的接收者隐藏数据的机制。如果多个接收器接收相同的数据，组播可以节省带宽。
用例:订阅者的数量在运行时急剧变化。
SOME/IP协议应该支持单向RPC通信，它触发RPC的执行而不通知调用者结果
基本原理:如果调用者不需要被告知RPC的结果，单向通信就足够了。
用例:在调用方只对触发RPC感兴趣但没有结果的情况下执行RPC
SOME/IP协议应该支持双向RPC通信，并将结果通知调用者
基本原理:如果调用者需要被告知RPC的结果，那么必须将其反馈给调用者。
用例:执行rpc并将结果传输回调用者。
SOME/IP协议应该支持与getter、setter和通知事件的字段通信。
基本原理:对于在中央控制的属性，此通信模式提供了所需的访问功能。
用例:车辆中的一方拥有由多个其他方设置和/或使用的中心属性。
SOME/IP协议应该支持下面不同的传输协议。
SOME/IP协议需要基于TCP/IP和UDP/IP进行数据传输。
基本原理:SOME/IP并不直接在IP上操作，但需要一个基于IP的传输协议来提供基本的传输服务。
用例：SOME/IP通过UDP的时间关键通信，SOME/IP通过TCP的时间不关键的大数据通信。
SOME/IP协议应该支持不同长度的消息。PDU的大小应根据要传输的数据的大小而变化。
基本原理:消息长度是特定于应用程序的。
用例:一些应用程序传输小数据块，其他应用程序传输大数据块。
同一应用程序发送的数据长度在执行过程中可能有所不同。
SOME/IP协议将支持大数据的分段传输。发送方应该能够将一个大的消息分割成多个较小的片段。这些被传送到接收器。接收方应能重新组合原始信息。
基本原理:时间关键数据不能通过TCP传输，但UDP必须使用。UDP协议最大报文长度为4KB。IP分片只能使用到65 kb。所以，现有的技术没有提供合适的细分可能性。在这些情况下，分割需要由SOME/IP来完成，而不是由应用程序本身来完成。
用例:超过65KB的数据的时间关键传输
某些/IP协议应使用车辆范围内的唯一标识符来标识服务
基本原理:有必要区分服务车辆的范围。
用例:特定服务的发现。
SOME/IP协议应该支持提供相同功能的服务的多个服务实例。
基本原理:一个系统设计可能使用多个实例提供一个服务，另一个系统设计可能使用每个实例定义多个服务。
用例:车辆中的多方提供相同的服务以支持故障转移处理，如果一个服务实例的提供者出现故障，订阅者可以切换到另一个服务实例。
SOME/IP协议应该支持在一个服务中组合多个RPC方法、事件和字段。基于服务的功能(例如服务发现)应该将它们放在一起处理，但是封装的RPC方法、事件和字段本身应该是可用的。
基本原理:如果功能经常一起使用，或者从体系结构的角度来看存在其他分组的原因，那么为每个功能提供自己的服务是不合适的。
用例:总是一起使用的功能的组合。
SOME/IP协议应支持将同一提供商的事件分组为事件组，以实现一次性订阅特定事件组的所有事件。
基本原理:如果事件是由同一方提供的，则将事件分组到事件组中可以实现更有效的服务订阅。
用例:大量相关事件由同一方提供。
SOME/IP协议应该支持在事件组中对同一提供商的字段进行分组，从而可以一步订阅特定事件组的所有字段。
基本原理:如果字段是由同一方提供的，则将其分组为eventgroup可以实现更有效的服务订阅。
用例:大量相关字段由同一方提供。
SOME/IP协议应该使用该服务唯一的标识符来标识事件和字段的通知。
基本原理:一个服务中的事件需要与同一服务中的其他事件区分开来。
用例:由多个事件组成的服务。
SOME/IP协议应该支持传输整数数据类型，有符号和无符号的8、16和32位长度。
基本原理:为了规范SOME/IP的序列化算法，SOME/IP需要支持一组基本数据类型。
用例:c-数据类型的通信
SOME/IP协议应该支持传输布尔数据类型。
基本原理:为了规范SOME/IP的序列化算法，SOME/IP需要支持一组基本数据类型。
用例:布尔值的通信。
SOME/IP协议将支持传输浮点数据类型称为单和双(在IEEE 754[3]中定义为binary32和binary64)
基本原理:为了规范SOME/IP的序列化算法，SOME/IP需要支持一组基本数据类型。
用例:c-数据类型的通信
SOME/IP协议应该支持结构化数据类型的传输，这些数据类型可以由一个或多个固定或可变大小的结构化数据类型和/或原始数据类型组成。
基本原理:为了规范SOME/IP的序列化算法，SOME/IP需要支持一组数据类型。
用例:多个基本数据类型的一致通信。
SOME/IP协议应该支持在执行过程中确定具体数据类型的联合数据类型的传输。
基本原理:为了规范SOME/IP的序列化算法，SOME/IP需要支持一组数据类型。
用例:具有动态选择表示的可能性的数据通信。
SOME/IP协议应支持一维和多维数组数据类型的传输，且数据元素数量灵活。应提供最多数量的数据元素。
基本原理:为了规范SOME/IP的序列化算法，SOME/IP需要支持一组数据类型。
用例:同一类型的可变数量的数据元素的一致通信。
详见《AUTOSAR_RS_SOMEIPProtocol》