SOA在汽车上的应用（2）

marjrh

接上篇。

2）多项关键技术共同促进SOA在汽车上的应用

芯片：

在分布式EEA阶段，各个ECU只连接特定的传感器和执行器，ECU的主要工作是提供I/O资源和网络接口，并进行实时控制。即使ECU需要运行操作系统，一般也是短小精悍的实时操作系统。在这个阶段，ECU并不需要特别强大的算力和巨大的存储空间，使用普通的车规级MCU芯片即可满足需求。
上篇文章提到，当EEA发展到第3阶段时开始使用DCU对某一个功能域进行集中控制，也是从这个阶段开始，DCU对于芯片算力的需求有了大幅度的提升。
以娱乐功能为例，最早就是简单的收音机或者CD播放器，并且都是实体按键操作。后来用触摸液晶屏进行HMI显示和操作，同时功能不断增加（视频播放、蓝牙音乐及电话、导航、语音控制、倒车影像等），这使得对娱乐主机MCU的数据处理能力和软硬件资源调度能力的要求不断提高，不仅MCU提高到32位，还增加了GPU进行图像处理及运行类似于android这样的非实时性嵌入式操作系统，以便有效分配系统资源，对各种任务调度管理。
等发展到了信息娱乐功能由智能座舱DCU集中控制阶段，除了以上娱乐功能之外，DCU还将组合仪表、HUD、氛围灯控制、DMS（驾驶员监测系统）、行车视频记录等功能进行集中控制。此外，智能网联汽车还需要与外界进行海量的数据交互。
智能座舱DCU要求芯片的数据运算和处理能力进一步提升，并且需要多核异构的系统级芯片SOC来满足不同类型的控制和计算需求。在算力增加的同时，车规级芯片在功耗、安全和成本方面比消费电子要求更高。综上所述，强大的车规级芯片是实现SOA的底层硬件基础。

操作系统（OS）：

强大的芯片构成了实现SOA的底层硬件基础，但软件技术同样很重要。先从离硬件最近的系统软件-OS开始介绍。
在最初的分布式EEA阶段，很多ECU的功能简单，不需要OS。随着ECU功能的增加以及与外部交互接口越来越复杂，需要OS来协调管理硬件资源及进行任务调度。
汽车不同功能对OS特性的要求也不同。例如，动力域和底盘域功能直接参与车辆的行驶控制，对系统控制的实时性、可靠性和安全性要求非常高，一般使用CP AUTOSAR OS（兼容OSEK OS）。又例如，对于娱乐功能，更注重OS对于应用程序的兼容性和应用生态的丰富性，对于实时性和可靠性要求可适当降低，因此，android这类OS越来越受欢迎。
到了域控制阶段，例如，在智能座舱DCU中，由于娱乐与仪表的功能安全等级不同，需要使用不同安全等级的OS，为此在DCU中引入了虚拟机管理技术(例如，AUTOSAR Hypervisor)。在虚拟机上可以同时运行两个或多个不同的OS，例如，娱乐功能使用Android，仪表功能使用QNX。
上篇文章介绍了整车能力分层的概念（感知执行层、通用控制层及计算层），不同层的能力要求不同，采用的OS也不同。一般来讲，感知执行层的ECU和通用控制层的ZCU不需要OS或采用实时性OS，确保对计算层下发的指令进行快速响应，对执行器进行实时控制。计算层的CCU硬件一般采用多核异构系统芯片（SOC），满足复杂的运算和大量的数据处理需求。CCU需要通过虚拟机技术运行多个不同类型的OS，因为不同的业务需求所适用的OS不同。例如，关键安全功能运行CP AUTOSAR OS，娱乐功能运行Linux或Android等。

AUTOSAR：

在介绍了芯片和OS之后，接下来以AUTOSAR为例，介绍SOA的软件架构如何设计。
AUTOSAR的设计理念和思路都着眼于汽车系统的基本软件要求，并努力做到向前和向后的系统兼容性。AUTOSAR将SOA设计融入到了它的方法论中，对最终的软件产品提供了标准化的服务设计和实现方式。当然，SOA的实现方式可以多种多样，AUTOSAR只是其中一种可选的方式，它是否能成为最适合SOA的软件架构还需要时间的检验，但仅从当前来看，AUTOSAR是相对完整并具备可操作性的SOA软件架构解决方案。
AUTOSAR分为Classic AUTOSAR(CP）和Adaptive AUTOSAR(AP)。AP是在CP的基础上发展而来。CP一般应用于对实时性、安全性和可靠性要求高的嵌入式ECU，AP一般应用于需要高算力的多核异构中央计算单元（CCU）。


图1 CP AUTOSAR   



图2 AP AUTOSAR  

CP的通信协议基于在系统运行前的静态预配置的基于信号的规范，而AP基于面向服务的通信，允许动态启动通信。即在CP中，运行时的服务必须在编译时处理确定的，而AP支持运行时服务的动态注册。AP支持的应用程序动态调度策略，它允许在运行时动态部署应用程序。
SOA的软件架构设计离不开服务模型的设计。针对服务组件，SOA定义了服务组件的架构模型SCA（SCA，Service Component Architecture），模型中的主要元素分为“服务接口”和“服务实现”两大类。

表1 AP的SCA模型描述



AP采用经典的代理(Proxy)-框架(Skeleton)模式来完成SCA模型的描述。这种模式将直接交互的客户端(Client)和服务端(Server)分离，由代理负责传递信息来完成服务调用，客户端和服务端不需要处理通信层详细信息。
服务组件由服务单元提供的“业务逻辑”和适配目标系统环境相关的“基础设施逻辑”两部分组成。在开发过程中，这两部分是解耦的，可同时进行的，且软件形态是灵活的。
服务单元的逻辑可以是源码或被封装为SDK形式，且不关心具体的编程语言；基础设施逻辑 (Interface和Message) 则以C++的形态编码，与服务管理中间件一起确保服务的动态响应性和服务自身的可扩展性，其软件形态同样可以是源码或SDK形式提供。
在流程上方法论上，”实现和部署”工作主要分为服务组件接口设计，服务组件集成实现和安装部署3个步骤：1、组件接口设计阶段: 编写arxml完成对服务组件SCA中“基础设施逻辑”的配置开发，并经由AP中间件供应商提供的代码框架和生成器(Generator)，最终得到相关的配置文件(.json)和源代码(.cc/.cpp)；对“服务单元逻辑”，可同步基于建模工具进行开发；2、组件集成实现阶段: 编写APP框架，完成“服务单元逻辑”与“基础设施逻辑”的软件集成工作；3、组件安装部署阶段: 编写编译和安装脚本，完成源码的编译链接和可执行文件(App)的安装，同时，对APP安装部署权限和系统环境做适配调整。表2 服务组件的设计和部署


SOME/IP:

SOME/IP (Scalable Service-Oriented MiddlewarE Over IP) ，即“运行于IP之上的可伸缩的面向服务的中间件”。“中间件”是一种独立的系统软件或服务程序，SOA软件架构中的“服务”可借助中间件在不同的软件平台或操作系统之间共享资源。
SOME/IP属于应用层协议，它提供面向服务的通讯接口。SOME/IP定义的服务接口包含方法（Methods），事件（Events），字段（Fields）和事件组（Event groups），可以支持请求/响应模式的远程服务调用，也可以支持订阅/发布模式的消息通知。



图3 车载以太网协议

服务是SOME/IP的最核心概念，在一个服务中，定义了服务端（Server）和客户端（Client）两个角色：服务端提供服务，客户端调用服务。对于同一个服务，只能存在一个服务端，但可以同时存在多个客户端调用服务，一个服务由Method/EventField组成。

SOME/IP的访问方式分为事件通知（Notification）、远程过程调用（Remote Procedure Call，RPC）和访问进程数据（Getter、Setter）3种。事件通知与传统CAN通信消息类似，服务端周期性或者事件变化时向客户端发送特定消息。远程过程调用是当客户端有请求的时候，向服务端发送一个请求消息，服务端根据情况返回响应。访问进程数据可以使客户向服务器端写入（Setter）或者读取（Getter）数据。
SOME/IP数据包括2部分，分别是Header和Data。在传输的过程中可以通过TCP和UDP两种通信数据协议进行传输。SOME/IP定义的通信方式主要包括4类：1. Method: 包含了请求后有应答的Method，和请求后没有应答的Method（Fire&Forget）。2.  Event：当某种事情发生后，服务端向客户端发送的报文。3.  Field：Get/Set/Notifier某种属性或者状态。4.  EventGroup：用来进行publish/subscribe处理Eventsand Fields的通信的逻辑组。
SOME/IP定义了其服务发现协议SOME/IP-SD，用于动态发现服务的提供者地址以及检查服务状态是否健康。SOME/IP-SD的报文通过UDP发送，每个设备通过在局域网中周期性地广播一条包含其提供的所有服务的OfferService报文来帮助其他设备完成服务发现（服务IP，端口等信息）。服务调用者也可以通过广播一条FindService消息来主动查询自己需要的服务。
SOME/IP中与数据通信相关的一些术语定义如下：1. Request/Response：客户端向服务端请求特定的报文，然后服务端将相应的数据报文返回给客户端。2. Fire&Forget：客户端调用服务端Method的报文，通过请求完成Method远程调用；3. Notification：对应Event接口类型，类似CAN报文，在特定的事件触发下，服务端会发给客户端一个notification报文主要包括Cyclic事件、数据Changed等；4. Publish/Subscribe：主要用于SOME/IP的SD（服务发现），客户端首先订阅相关的服务，只有订阅成功后，才允许进行Notification通信。5. Field：一个可被远程访问的属性。主要包含三种类型的数据通信Getter、Setter和Notifier。其中Getter读取属性值，请求报文的payload为空，响应报文中含有当前属性值；Setter设置属性值，将预设值置于请求报文的payload中，属性的设置结果放于响应报文中，Notifier类似于Event，Notifier在订阅完成后，会立即发送Initial Event，通知当前值。

小结：

强大的车规级芯片是实现SOA软件架构的底层硬件基础。

操作系统是离底层硬件最近的系统软件， 它负责为应用软件协调管理硬件资源并进行多任务的切换和调度。

AUTOSAR本质上是一种软件设计的方法论，它为具体如何实现SOA的软件架构提供了标准化的服务设计和实现方式。例如，AUTOSAR定义了为了运行AP的应用程序，操作系统需要具备POSIX标准库接口，操作系统应通过在启动和运行时的动态调度和通信路径的动态配置来支持应用程序的动态行为。

SOME/IP是一种中间层协议，是实现SOA的面向服务通信的一种具体的技术实现方式。AUTOSAR将SOME/IP也融入到了它的方法论中，例如，规定CP只能支持SOME/IP协议，而AP可以运行SOME/IP，也支持HTTP协议，AP后续还会增加其他协议。CP仅支持静态SOME/IP服务交互机制，而AP可以支持静态和动态SOME/IP服务交互机制。SOME/IP在AUTOSAR中的实现主要包括与SD相关的配置和数据通信协议相关模块的配置。

正如SOA的软件架构实现方式不是唯一的（AUTOSAR只是其中一种可选的方式），SOA软件架构下的通信协议也是多元化的，任何基于服务机制的协议均可以认为是SOA通信协议。在汽车上，应用比较广泛的主要是SOME/IP、HTTP、MQTT协议，其中SOME/IP满足车规要求，用于车内节点之间的服务通信，而HTTP和MQTT承接于互联网，多运用于无线网络，以便于车内节点和云端交互，但也可以用于车内有线以太网。

未完待续。。。

lixinfu

好的，针对您所提到的内容，我作为汽车工程师的回复如下：

随着技术的发展，芯片在汽车领域的应用逐渐成熟，其重要性愈加凸显。在分布式EEA阶段，普通车规级MCU芯片可以满足基本需求。但当进入DCU对功能域集中控制的阶段时，芯片算力的需求显著提升。以娱乐功能为例，现在的娱乐系统融合了导航、互联网连接、多媒体播放等功能，这些都依赖于高性能芯片的支持。而随着SOA（面向服务的架构）在汽车上的广泛应用，未来的汽车将实现更加复杂的智能化功能，如自动驾驶、智能导航等，这将更加依赖先进的芯片技术。因此，多项关键技术的共同促进，使得SOA在汽车上的应用得以快速发展。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]