对于常规的IT界SOA来说，基本都是就以太网实现的，车载环境下，不管是技术还是实现思路，该实现方式将更加趋于更加成熟。SOME/IP作为站在以太网顶端的一种优化协议，应用于SOA的服务通信开发实践，有较多值得被关注的点需要说明，如下罗列了一些典型的被人们所关注的SOME/IP相关的问题项，对于帮助工程师建立更加全面的认知可以起到很好的作用。
1. Some/IP协议的Header报头各位数的含义表示什么？SD的数据通信是如何实现的？
Some/Ip协议Header主要包括MessageID（32bit）、Length（32bit）、RequestID（32bit）、ProtocolVersion（8bit）、InterfaceVersion（8bit）、MessageType（8bit）、ReturnCode（8bit）。
其中MessageID用于区分不同的服务和服务接口。其中分为16bit的serviceID和16bit的MethodID，其中MethodID最高位为0或1表示的是Event或Notifier。对于特定的Header，SD明确定义MessageID固定为0xFFFFF8100；在Someip中由于可以支持多种不同的数据通信，因此可以通过MethodID的最高位来判断具体的通信方式；MessgeType固定为0x02。
Length（32bit）表示RequestID至Payload的字节长度；长度字段描述了 SOME/IP 消息的总长度。这是特别必要的，因为可以将多个 SOME/IP 消息连接到同一个收件人以提高传输速率。接收器可以通过将标头中指定的长度与帧的实际长度进行比较来区分这些。如果这大于指定的值，则会出现另一个 SOME/IP 帧。SOME/IP 有效负载Playload的长度受到底层传输协议（UDP 或 TCP）和以太网分段的限制，应避免这种情况。
RequestID（32bit）用来响应特定的数据请求和发送，主要包括ClientID用来区分特定的车载ECU的客户端，因此，对于ClientID来说在整车系统中该值必须是唯一的；
SessionID（初始值设置为0x0001）主要用于Request和Response类型的通信协议多次调用，每调用一次，SessionID增加1，在其他类型的数据通信中可以根据需要进行选择性使用；SomeIP用ProtocolVersion表明协议版本类型；ReturnCode则主要用来知名通信中的相关错误信息。
对于Some/IP所定义的服务接口来说，一般是采用跨系统通信的重要组成，并且参照自己特有的一套序列化原则，系统设计阶段需要基于Some/IP提供的数据类型，统一设计服务接口描述。
对于SD的数据通信一般分为发现服务、订阅事件组、接收事件，其中发现服务和订阅事件组需要SD完成，接收或通知事件由SomeIP直接完成。对于SD模块中，需要定义对应节点是作为Client还是Server端使用，在SD中主要的配置选项包含SD基础配置、SD服务端配置、SD客户端配置。
可参照如下图进行：
2. Method/Event/Field/Eventgroups都是用的Provider和Consumer接口吗？相互之间的工作机制区别有哪些？
Method方法：有响应（请求/响应）和无响应（Fire&Forget）。Event事件：发生某事时从服务器到客户端的消息。Fields字段：属性/状态的获取器/设置器/通知器。Eventgroups事件组：用于发布/订阅处理的事件和字段的逻辑组。
对于每个SOA来说，至少得有一个Provider和若干个Consumer接口，一个服务接口需要满足SOME/IP协议的组成规则，里面包含Method/Event/Field三部分。因此，可以说以上三部分内容都是采用的Provider和Consumer接口。
比如以雷达所表示的一个通信接口举例说明相应的接口描述。其中，服务接口Fields可主要用于提供雷达的刷新频率UpdateRate（Unit32），Events可主要用于当检测到雷达目标后，提供制动时间或停车事件BrakeEvent（RadarObjects）和parkingBrakeEvent（RadarObjects），Methods可主要用于数据矫正Adjust和标定Calibrate。其中数据矫正包括位置目标输入，是否矫正成功的标志输出，位置有效性输出。标定则是包括相关的数据配置，标定结果标志位输出。
下面来具体说明下如上服务接口的定义方式区别和通信机制。比如Event和Field两者就存在如下区别：
Event仅在发生某些事情时发生，事件没有初始值，未定义事件的生命周期。基于状态的元素应建模为字段，Event 和 Field 的事件消息是相同的，区别在于初始事件仅存在于字段。通常将事件用于时间有限的观察，将字段用于状态等数据。
3. SOA在一定程度上就是SOME/IP的基础实现么？基于SOMEIP的SOA中sender/receiver接口类型是怎样定义的？
SOA实现重点在于服务通信标准化，即面向服务的通信（SOC,Service-Oriented Communication）。并以服务重用、灵活重用为目的进行服务划分，即基于服务的服用共享式进行设计（SORS，Service-Oriented Reuse-Shared Design）。用于承载和适配SOC和SORS的软件实现是基于服务的软件架构（SOS，Service-Oriented Software Architecture）。所以，整体来说简单的将SOA简单的等效为SOME/IP是不合理的。
但是，SOA作为一种面向服务的架构标准，可以将其与SOME/IP基础协议所定义的内容进行实现，SOME/IP 则允许SOA中的应用程序进行通信，数据包格式由服务规范自动确定。所以可以说SOA的服务架构是SOME/IP实现有效通信的载体。SOME/IP在包括涉及系统、软件、硬件的架构所定义的软硬件模块中发挥具体作用。服务器提供实现服务接口的实例化，客户使用 SOME/IP的服务实例化。
SOME/IP位于应用层，提供面向服务的通信接口。其通信方式为Autosar中提到的CS接口的概念，就是客户端(client)和服务端(Server)，当有请求发出时，SOME/IP才会发出数据，否则不发送数据，类似于COM模块的Direct模式，这样总线上就没有不必要的数据，降低总线负载。
4. SOA中服务仲裁有何价值？多个消费方消费同一个service时，怎么做仲裁，仲裁逻辑怎么设计？
仲裁能力是任何 SOA 的关键益处之一。
仲裁并不是所有服务都必须的，但是“它是被设计交付可组合性（即业务敏捷性）的面向服务架构所必需的。几乎所有有价值的长运行事务都必须能够仲裁，这是为了让它们可以被组合、被再组合，以及被编排，共享消息的语义需要依赖仲裁功能。
仲裁要求并鼓励消息携带更多的上下文信息，除了请求 - 响应和发布 - 订阅，仲裁使消息交换模式极大地复杂化。
多个消费方使用同一个Service时，仲裁过程要求仲裁系统对于它所拦截的消息的语义有较好的理解，根据理解的语义判定消费方对于具体服务的需求紧急度和重要度，从而Server通过Notification推送给Client已订阅的服务内容。
SOME/IP 可以看作是一种基于对象的面向服务的体系结构。信息通过实例化服务对象提供给系统，这些由客户端应用程序访问，客户端应用程序为他们想要访问的每个服务实例化相应的Proxy“代理”对象。被判定为高优先级的客户端应用程序通过将代理对象附加到服务对象并使用它来监视Event事件和Field字段从而获取getter或Setter更改来订阅信息。也可以调用服务对象上的操作来执行远程调用或读/写特定字段。
5. v-SOA中instance和machine什么关系？AP 里面的每个子模块的设计实现都是用采用SOA设计思想吗？
从外看，我们可以将机器Machine看作一个抽象的硬件 软件平台和通讯接口。硬件包括一个N核CPU，软件平台可以定义为具体OS。每个Machine可以有N个进程，每个进程都会对应可执行文件。对于服务实例ServiceInstance来说，主要定义SOA通讯怎么映射和部署到transport传输层协议（如SomeIp）。即定义一个服务是提供方还是消费方，服务提供的具体功能，服务具体类型，服务接口，服务实例ID等内容。最终实际的将服务实例映射到目标硬件层面，可以说这个硬件层面就是由Machine配置的虚拟机软件承接。
如上图所示基于SOA的Autosar相应的开发流程如下：
1）首先是定义服务：输出ServiceInterface，这个过程一般属于OEM工作范围，通常由OEM定义相应的ARXML接口文件实现；
2）生成Machine Manifest用来描述目标硬件和软件平台环境，并使用Autosar工具链将应用映射到进程Process;
3）使用Autosar供应商工具链，生成基于Skeleton/Proxy的类，其中proxy(代理)是skeleton(server端)的对外接口;
4）实现SWC和使用目标软件平台工具链在可执行环境中将对应的目标文件编译为可执行文件Executables；
与SOA有着强绑定关系的Autosar来说，其开发过程往往离不开整个服务接口定义、服务通信定义，以及实现整个Autosar的各类中间件。对于v-对于SOA来说，SOC可以实现通信标准化，动态建立通信关系，连接信息孤岛。SOME/IP就是基于SOA思想定义的通信中间件，也是对车载环境定义的一套通信协议，出自AP Autosar，可以达到屏蔽系统异构性，实现互操作的目的。所以，就AP的每个子模块中实现SOC而言，可以完全依赖于SOME/IP，采用SOA设计思想来完成（当然，针对不同的前提条件，其他传输协议如DDS也可以使用来作为通信协议端）。但是，在AP Autosar的开发架构下用于 SOME/IP 的套接字适配器、COM 和 RTE、服务发现所定义的单独的模块，这些过程实现也是具备极大的挑战性的。
这里需要注意的是Client ≠ AUTOSAR Client/Server。
6、dds和someip在arxml建模的区别？
SOME/IP 是一种汽车中间件解决方案，可用于控制消息。SOME/IP 专为汽车行业设计。SOME/IP 是作为 AUTOSAR 的一部分开发的规范集合，描述了其序列化协议、服务发现以及与 Classic AUTOSAR 集成的转换器。
DDS（数据分发服务） 也是用于通信的汽车中间件，针对更广泛的工业物联网领域。它是由对象管理组 (OMG) 发布的一系列开放标准。SOME/IP 和 DDS 都允许分布式应用程序使用发布/订阅模式和服务请求/回复模式 (RPC) 进行通信。但也存在如下显着差异：
1）通信模式不同
DDS 和 SOME/IP 之间的一个显着区别在于，使用 DDS，应用程序不需要绑定到服务的特定实现。它简单地引用主题和服务，并且可以完全透明地进行一对一或一对多的通信，而无需对应用程序代码进行任何更改。它确实需要跟踪单独对等点的存在或管理任何新对象以响应对等点的加入或离开。这一切都是自动处理的。从这个意义上说，它比 SOME/IP 更具动态性。
2）应用程序编程接口（API）
SOME/IP 没有定义标准 API，实现通常提供 C API，但它们不能跨实现移植。
DDS 具有适用于多种语言的标准 API。对于 C 和 Java，这些都包含在 DDS-PSM-JAVA 和 DDS-PSM-CXX 规范中。因此，通常可以移植 DDS 应用程序并在 DDS 实现之间切换。
3）网络传输
SOME/IP 支持 UDP 和 TCP 进行数据传输。对于可靠的通信，SOME/IP 回退到 TCP。使用 DDS支持RTPS（实时发布订阅）的有线协议，实现了与传输无关的可靠性和分段协议，该协议运行在任何传输之上，包括带有多播的 UDP。可以通过多播 UDP 处理大数据和可靠数据。Some/IP 无法做到这一点。
此外，许多 DDS 实现提供了“自定义传输”SDK，因此可以在您自己的自定义传输上运行 DDS，而不会牺牲任何功能和 QoS。这对于 SOME/IP 是不可能的，因为某些特性（如可靠性和分段）必须由传输实现。
4）信息安全能力不同
一般来说，SOME/IP 也依赖于传输来保证安全。因此，要安全地使用它，就需要在 TLS 或 DTLS 上运行。对于 DDS，最好使用 DDS 安全规范中定义的机制，这些机制与传输无关。DDS 安全性还提供了对安全性的更细粒度的控制以及用于访问控制的语言，因此可以分别保护 DDS 域和主题，并区分对主题的读取和写入权限。此外，由于 DDS 安全性与传输无关，因此它可以与任何传输一起使用，包括共享内存、多播或自定义应用程序定义的传输。
5）服务质量实现不同
SOME/IP 仅提供一种用于选择 UDP 与 TCP 的“可靠性”Qos 设置。DDS 提供了许多 QoS 策略，使用户能够以声明方式指定发布者和订阅者之间如何交换信息。我们开发SOA的服务架构中，通常dds通常重点在于传输数据类通信（比如传感器数据），SOMEIP更多是传输控制类信号通信（如加减速控制信号、车门车窗控制信号）。
总结
本文就基于SomeIp协议开发过程中可能出现的典型问题进行了比较详细的分析和解读，可以帮助读者或工程实践者进行部分问题规避，但是SomeIp协议的复杂度和可能出现的踩坑远不止于此，比如由于当前的 SOME/IP 协议不提供任何安全措施，如何提升Someip的信息安全能力，免受黑客攻击，就是业内比较关注的话题。协议制定过程中如果能够保留56 字节用户数据明确用于可能的安全扩展。只要安全协议每帧传输的附加数据不超过这 56 个字节，就可以在不更改标准和兼容实现的情况下保护 SOME/IP 通信。这一系列操作都有助于对Someip的能力扩展，当然这里无法穷举，希望后续可以通过抛砖引玉的方式在后续开发过程中获得更多的输入。
,
