• 背景:

      对带宽不断增长的需求促使汽车行业考虑使用其它通信总线,不只局限在当前总线CAN、FlexRay 和MOST。特别是信息娱乐、ADAS、高度自动驾驶和OTA等应用,对汽车网络带宽需要高达100 Mbps 的高速数据传输速度。此外,从现有的分布式基于信号的通信(CAN、LIN)到基于服务的通信的转变可能是颠覆性改变。

      考虑到车辆内部 ECU 不断增长通信带宽需求,Ethernet成为最合适的选择。作为业界公认的协议,Ethernet有30 多年研发和成熟协议(如 TCP/IP 和 UDP)的支持。然而,以太网不能按原样不动用于汽车行业,与汽车ECU的通信需求兼容,需要增加附加组件实现信号和服务转化。这就SOME/ IP(面向服务的中间件 IP)的作用和实现逻辑。

      在深入了解 SOME/IP 之前,我们需要清楚基于信号的通信和面向服务的通信特点和差异;

  • 基于信号的通信架构VS面向服务的架构对比

      基于信号的通信长期以来一直用于通信协议,例如 CAN、LIN、FlexRay、MOST 等。对于基于信号的通信解决方案中的软件和硬件紧密耦合,因此 ECU 之间的通信是静态定义的。假定软件在其生命周期内不会被修改,基于信号的通信最适合此类应用。

     基于信号的通信领域,只要数值更新(周期型)或修改,就会通过网络发送数据。发送方不关心网络中的ECU是否需要数据。这种安排可能会给节点带来他们可能永远不需要的数据。

      在面向服务的架构,发送方仅在接收方需要时才发送数据。因此,接收方必须将正在等待数据的接收需求通知到服务器,这仅仅是基于服务的通信的一方面。

      当我们谈论高度自动驾驶、ADAS、联网汽车等时,面向服务的架构 (SOA) 是必不可少的。在以太网和 SOME/IP 的支持下,SOA 将整个系统建模为service interface,可以轻松地将新软件添加到系统中,而无需担心与其他软件的兼容性。

      虽然以太网提供了Backbone主干网,TCP 和 UDP 提供了传输层,但数据序列化、远程调用过程等需要一个中间间,这正是创建 SOME/IP 的原因!

  • 什么是SOME/IP

   SOME/IP 代表 ScalableService-Oriented Middleware over IP,由 BMW 集团于 2011 年开发。该名称清楚地表明它是一种中间件解决方案,可在控制单元之间实现面向服务的通信。更具体地说,SOME/IP 提供了广泛的中间件功能,如序列化和远程过程调用 (RPC),使 ECU 软件能够相互通信;

   SOME/IP 可以在 OS(Genivi、AUTOSAR、Linux 和 OSEK)和非 OS 嵌入式系统上实现。最近,它已成为Adaptive AUTOSAR 实施的首选中间件;

    如前所述,面向服务的体系结构使不同网络上的软件组件更容易相互通信。因此,为了让不同网络上的这些应用程序相互理解,必须有某种中间件。它的主要作用是解析消息格式,并使消息的预期接收者能够理解它,SOME/IP是专门为此目的设计的。

  • SOME/IP 主要特性:

    • 序列化:它是数据在数据单元中表示的方式,数据单元可以是 UDP TCP 消息。当数据通过网络传输时,读取数据的ECU可能有不同的架构、操作系统等。只在一致数据传输机制的情况下,才能确保互操作性,SOME/IP 允许一些序列化。

    • 远程过程调用 (RPC):这是一种根据Client ECU 的请求远程调用功能的方法。它是Client ECU 在需要来自Server的一些数据时采用的一种数据交换方法。 RPC 可能有也可能没有返回值,即Client可以请求数据作为响应或简单地调用一个函数来执行服务器端的某些任务。

    • 服务发现(Service Discovery:服务发现 (SD) 协议是 SOME/IP 概念的支柱。在面向服务的架构中,服务(functional entity- methods, events or fields)必须是可发现的。 SOME/IP SD 协议管理这方面—是提供服务还是停止服务可用。

    • 发布/订阅(Publish/Subscribeclient可以订阅server的内容,以便它可以动态地从server接收更新的数据。SOME/IP 的发布/订阅功能推导出client需要并共享相同的数据(event/field)。Pub/Sub SOME/IP SD 管理。

    至此,我们已经了解了面向服务架构的概念以及SOME/IP在其实现中的作用。我们现在将更深入地了解 SOME/IP 和以太网究竟是如何实现 ECU 客户端/服务器间通信的。


  • SOME/IP 通信的工作原理

     在开始我们的探索之前,我们必须了解一些与 SOME/IP 相关的术语:

Service

提供interface的events, methods或field的组;

Service Instance它是service的单个实例;它实现了一个Service Interface;
Event它是发生某些事情时从server发送给Client的消息;
Field它是表示服务的状态,属于服务的一部分,因此始终具有值;
Getter/Setter一个Request/Response调用,提供对 field属性的读/写访问;
Event Group它是一个由多个Event组成的逻辑组;
Method它可能是一个可以调用的函数、子程序或过程;
Notifier负责在 field值改变时发送事件消息;
Notification Event通知notifier发送的事件消息;

   Server ECU提供实现service interface的Service Instance,Client ECU可以使用SOME/IP用此service Instance从Server请求所需的数据。服务发现协议(Service Discovery protocol)有两种机制,客户机通过这两种机制了解可用的服务。

    第一种机制是“提供服务'Offer Service'”,Server能够使用它向网络提供可用服务。另一种是“查找服务'FindService'”,它使Client能够请求可用的服务。

    但是,为了让Client使用该服务,它必须先订阅Server上的内容。

    使用 SOME/IP SD协议,Client可以向Server发送订阅Event Group。如果订阅请求有效,Server将以肯定确认响应,反之亦然。

     由于 ECU 内部的应用程序在面向服务的架构中没有紧密耦合,多个Client可以同时订阅Server上的服务,数据可以通过 UDP 或 TCP 提供。在 UDP 的情况下,数据被发送到所有作为活动订阅者的Client。数据传输通常通过单播、多播或广播发送。但是,对于 TCP,发出请求的Client必须与Server建立连接以进行数据传输。

     虽然 SOME/IP 的基本原理基于Client-Server架构,其中Client的请求之后是Server的响应,但存在多种通信方法/通信模式:   

    1. Request/Response Method

      • Request是从Client发送到Server以调用函数的消息。

      • Response是从服务器发送到客户端的消息,描述了客户端调用的函数的结果。


    2. Fire and Forget Method

      • 消息从Client发送到Server以调用函数。

      • Server没有返回任何响应。


    3. Services: Event

      • Event是从Server周期性地或在Server属性发生变化时发送到Client的回调

      • Server仅将更改通知给先前订阅的那些Client

      • 每次Event发生时都会向Client发送事件通知

    4. Services: Field

      • FieldService的属性,可以使用Getter/setter 远程访问。

      • getter是读取字段值的方法

      • setter 是设置字段值的方法

      • Field的值发生变化时,通知程序会发出通知事件。

            如下是ECU A作为Server 提供者和ECU B作为Client 服务的使用者例子,可视化解释Some IP信逻辑:

    • SOME/IP优势和应用场景:

         SOME/IP 是一个精心制作的中间件,具有CAN、MOST 和 FlexRay 的特性以及令人垂涎的面向服务的通信。它不仅使整个车辆网络动态灵活,而且还提供了执行 CPU 密集型应用程序所需的骨干

         a. 为车辆电子系统添加新功能变得更加容易;

        b. 作为互联生态系统的一部分,为车辆系统提供所需的灵活性;

        c. 借助EventMethod,可以使用以太网实现复杂的服务接口;

        d. 它支持单播和多播。

        e. 它通过引入事件、通知程序等来降低数据路径的复杂性。