联合汽车电子：

在某客户项目中，整车厂规划基于新一代中央域控+区域接入的电子电气架构实现整车功能服务化，联合电子应用业务驱动型开发方法帮助整车厂完成整车服务架构设计。

图片

图 6-3 SOA服务架构设计过程展开

业务驱动型指从业务用例出发，以服务为导向，正向设计SOA汽车软件的开发方法。在设计过程中，通过“业务过程分析”、“服务操作分析”、“候选服务分析”三个步骤，解决“应该构建哪些服务？”、“每个服务应该封装什么逻辑？”两个核心问题。

以雨刮子系统为例，客户提出雨刮低速、雨刮高速、雨刮点动等多个场景用例，分析过程如下：

⚫ 业务过程分析：

采用用例驱动的方法来分析业务需求和过程。用例驱动指从用户使用的角度而非开发人员的角度考量功能需求和系统实现，重视从系统外部观察对系统的使用。由用例驱动的开发活动，可以建立需求和服务操作之间清晰的追溯关系，为抽象和封装服务提供充足的语境信息。

⚫ 服务操作分析：

服务封装的业务逻辑，由服务操作实现。服务操作代表了服务所执行的特定动作，可类比软件中的方法或函数。

⚫ 候选服务分析：

“SOA汽车软件分层模型”为候选服务分析提供了有价值的参考。根据重用性和自主性的面向服务设计原则，参考三层模型设计元服务和基础服务。对元服务和基础服务的设计，SOA鼓励即使没有立即重用的要求，也要根据服务导向的设计原则促进重用，因此潜在的重用也要考虑在内。通过良好的SOA设计，当业务用例增加，或原有业务用例发生变更时，良好的基础服务和元服务设计，保证了重用性和较少的软件变更，从而实现更快速高效的功能迭代和清晰明确的版本管理。

⚫ 服务接口设计：

服务接口设计是服务架构设计过程中的重要一环，在候选服务分析完成后，大致暴露的服务接口会被确定，服务接口决定了服务之间的动态数据交互，决定了业务逻辑的行为和功能，需要在迭代中不断完善，反复更新。

此处，值得一提的是原子服务和设备抽象服务接口的设计和定义), 设备抽象服务解决电子电气架构中不同执行器/传感器暴露统一的接口问题，原子服务则对传感/执行器的语义做统一的规划和定义。联合电子将对原子服务和设备抽象服务接口的设计定义为平台驱动型(由下至上)设计方法下的工作产出。

当前，软件定义汽车工作组发布的API参考文档为定义智能汽车软硬件接口标准化的规范性文件。工作组通过对API接口的标准化定义，为各领域带来全新的体验，联合电子也正在参与API接口定义工作，并在项目上进行应用实践。

⚫ 服务部署：

在SOA软件开发过程中，服务的部署涉及到整车电子电气架构的信号矩阵。对于业务驱动型分析方法，功能需求导向是设计原则，对于Tier1熟知的业务逻辑领域，推荐Tier1 提供具体服务模块的部署信息， 这些部署信息作为正向设计的产物，会体现在

后续的整车厂整车软件架构之中，是整车厂设计整车信号通讯矩阵不可或缺的重要一环。

在SOA软件架构下，整车厂整体把握软件架构的总集成方，Tier1作为各个业务领域(车控、底盘、动力、高级辅助驾驶系统等)的合作伙伴，将作为组件负责人向整车厂 提供对应的架构描述文档，最终系统级的架构设计文档由整车厂输出，并结合软件模块和基础软件部分，完成各个子系统的集成。

图 6-4 SOA架构在软件中的实现过程

联合电子认为， 面向服务化的软件架构，未来将促进多个供应商体系下软件集成互相协同。在这样的方案里， Tier1 会充当Component Designer 的角色，是Component的“专家”，对组件内部的架构设计和业务逻辑有着主导权；组件与组件之间的接口则由整车厂来承担和定义，Tier1/软件供应商在严格遵照该定义后，将软件架构和软件模块以固定的形式持续向整车厂推送。未来逐步迭代和成熟的接口也将是软件定义汽车的标准接口，其一定程度的抽象可以形成行业内的标准规范。

6.3 SOA服务化设计、开发与测试验证

威马汽车：

威马汽车将汽车看做万物互联中智慧城市分支的一部分，在设计时将中央大脑作为车辆与外界互联的网关，负责提供车辆信息、车辆控制等服务。威马汽车在向SOA架构的转型中不仅考虑车内服务的互相调用，还考虑将服务提供给移动设备、智能穿戴、第三方APP、路端设施和其他车辆，在满足安全性的前提下让威马汽车更加符合互联的需求。

威马汽车对SOA理念的首次尝试是座舱系统“威马快捷”APP的开发：将座舱可实现的车辆控制功能（车窗控制，灯光控制，座椅控制，空调控制等）在APP端包装为一个个服务元素，用户可创建卡片自由组合编辑这些服务元素。激活卡片后，座舱系统依次下发卡片中服务对应的控制信号，呈现出独特的场景控制，满足用户的个性化需求。这种方式是将APP模拟为一个服务器，为用户呈现可提供的服务，同时将这些服务的执行命令进行后续的下发。

第二次应用是出于对座舱软件优化的目的：座舱硬件和通信的变化，以及关联零部件方案的变更，往往都会影响到座舱应用层软件的变更。同样的功能，在不同的项目中，应用层都需要重新开发调整。出于减少应用层开发工作量，和增加应用层可移植性的目的，在应用层和通讯层之间，构建一个S2S模块，将整车相关的信号（车辆控制信号，车辆设置信号，车辆状态信号，车辆报警信号）按照SOME/IP的标准，封装为一个个服务，应用层直接调用相关的服务接口，信号的控制逻辑由S2S模块来传递执行。

S2S通讯层底层ECU2ECU3CANUSB以太网车窗控制信号ECU1车窗状态信号模式设置信号模式状态信号故障报警信号······车窗服务模式服务报警服务···语音软开关车辆设置报警显示状态显示座舱系统

图 6-5 威马汽车第二阶段服务化架构

这种方式在一定程度上实现了应用层通讯逻辑的解耦，避免了一个功能点的变更，带动多个应用变更的情况：比如车窗纹波防夹和霍尔防夹方案的选择，影响座舱车辆控制、语音控制、车辆状态显示等多个应用的软件变更，通过服务化，将差异化的信号定义为标准化的服务接口，增加了应用层软件的适配性和可移植性。

随着中央计算平台+区域网关的架构方案在项目中应用，威马汽车目前正处于第三阶段的SOA工作：整车级的服务定义及软件开发。整车级的服务定义，依托业内统一的标准，才能更大程度发挥出优势。现阶段，威马汽车参照中汽协软件定义汽车工作组发布的《原子服务API参考》，进行车身、热管理、动力、能量管理、驾驶域、人机交互六个部分的服务接口定义。

状态获取服务主动通知服务目标请求服务组合服务状态采集服务执行反馈服务控制下发服务中央处理器自动驾驶座舱系统以太网以太网域控1以太网域控2以太网域控3以太网应用服务

图 6-6 威马汽车第三阶段服务化架构

服务接口的定义原则，主要就是解耦和稳定。从请求到执行，再到状态改变，定义为不同的服务接口，各个接口在功能层面上是互相联系的，但从服务的角度看，每个接口都是独立存在的，请求不关心执行的逻辑，执行不追溯需求的来源，也不跟踪状态的变化，状态仅是当前最新信息的体现。

示例：车窗服务

每一个车窗状态作为一个服务，服务接口包含车窗解闭锁控制、锁状态信息、开度控制及状态信息、升降控制、以及学习状态、防夹状态等信息。车窗的相关信息由区域控制器传输给中央服务器；对于需求方，控制请求的下发和状态的获取全部面向中央服务器，不与区域控制器直接对接，由中央服务器进行优先级和前置条件的判断，并将控制信息传递给区域控制器。

软件定义汽车的定义中，都属于原子服务的范畴，整车厂和第三方应用可以基于这些原子服务，搭配出更加满足用户需求的组合服务和应用服务，提升产品的竞争力。

岚图汽车：

传统智能驾驶辅助系统的功能开发都是通过“定制开发的软件+特定硬件”的方式实现并交付给整车厂，软件和硬件之间是紧耦合的。程序代码根据需求是固定式的，后期如果需要系统升级，软件程序将重新编写。同一个功能在不同的车型搭载时，因为硬件不同，软件无法复用，软件灵活性差；另外，功能软件移植到新的硬件时，需要重复的设计、开发、测试。耗费大量的重复工时，影响到功能的迭代周期。随着用户需求的日益增加，这种开发方式远远满足不了用户的需求。

在软件定义汽车的背景下，面向服务的软件架构能从根本上解决了这个问题。通过全新的电子电气架构实现软硬件解耦，产生出硬件抽象层，将原有的硬件资源抽象成为一个共享的资源，实现整车的信息共享，供其他功能调用，从而演变出新的功能，满足客户不断增长的需求。

基于整车SOA软件分层架构，根据驾驶辅助系统的特性，岚图汽车基础平台架构将整车应用软件细分为云端控制的车队管理层、本地功能控制的功能管理层、用于功能实现的规划控制层、用于获取环境感知的传感器感知层、控制执行的执行器层。该分层架构可以实现各层级之间软件模块解耦，其需要遵循以下规则：上层服务可以依次或跨层依赖下层服务；不允许下层服务依赖上层服务，实现本层的软件模块执行。

将基于SOA的软件开发方法以驾驶辅助系统ICA为例阐述其实现过程。

⚫ ICA需求场景流程分析

用户期望车辆能分担驾驶负担，降低用户高速使用场景下频繁的纠正方向盘、控制安全距离及车速频率。

⚫ ICA服务与接口定义

根据驾驶辅助系统的 SOA 软件分层策略，将初始服务操作提炼的服务如下：

图 6-7 岚图汽车ICA服务分层图

⚫ ICA 服务部署及接口映射

将服务实例化的服务映射到具体的运行环境中。基于集中式的电子电气架构拓扑，将HMI相关的服务部署在HMI处理器上，将算力要求较高的服务部署在驾驶辅助系统SOC上，将规划控制及CAN交互的服务部署在驾驶辅助系统 MCU上。

面向SOA服务的测试实践：

在SOA开发实现的过程中，V模型右侧的测试验证较传统整车架构也有了革命性的变化。主要体现在通信网络增多、链路复杂深入。

在SOA软件架构中，软件从上而下，分成了不同的层级和模块。可以看出功能较传统架构实现链路上复杂了，这也就对功能测试的问题分析和定位，提出了更多的困难和挑战。

不同的供应商提供不同的软件模块和接口，整车厂主导集成。测试过程中，对于跨越多个软件模块进行传输的数据对象，更难在实际的问题中进行问题模块定位。面对此类问题，整车厂需要配置人员能调动多个供应商进行问题解析，快速识别问题根源。同时要求软件供应商做好各阶段的基础的软件模块单元测试和功能测试至关重要。对于传统嵌入式ECU，这一部分整车厂基本没有介入，在SOA开发过程中容易疏漏，需要管控到位。

面向SOA服务的测试的通信协议目前主要为SOME/IP和DDS。以SOME/IP报文为例，测试问题的报文定位不仅体现在特定服务中数据对象是否正确发送，还需要往前一步分析服务数据对象发送的前提是否满足。因此问题的分析和定位不仅要梳理数据对象的服务器是否正确发送Offer和服务内容，同时需要检查数据对象的客户端是否正确订阅。以太网的点对点数据传输，使得数据分析量也成多倍增加，如原来的一条CAN报文，可能会变成多条Event报文进行传输。测试工作也会相应的增加。

面向SOA服务的测试完整的测试内容涉及物理层、TCP/IP协议、应用层服务等。其中，应用层服务直接影响整车放定义的相关功能。针对应用层服务主要有一致性测试和性能相关测试。

⚫ 一致性测试

主要测试车辆的服务内容是否都按照通信矩阵定义实现。结合SOME/IP协议标准和整车厂自定义内容，对控制器的服务发现行为、服务中具体的方法、请求和事件进行全方位测试，确保服务端和客户端的行为都同步实现和满足矩阵要求。

⚫ 性能测试

主要测试控制器的报文处理能力，如：收到多条请求是否可以实时处理，不出现报文丢失，并驱动对应负载；收到服务的Offer报文后，客户端是否可以快速订阅；收到服务的订阅后，服务端是否可以快速处理并发送对应的Event。

基于SOA服务的域控制器集成了更强的硬件，在软件层面可同时具备传统多个控制器的功能，如车身、舒适和动力。软件的高度集成带来了更多的产品问题，敏捷开发使得域控制器的版本释放变得更加频繁。按照整车厂传统的只在车型大阶段安排测试已经变得不再适应，需要安排不同层级的域控制器通信与功能测试，才能更好的控制器产品质量。

华人运通：

华人运通根据整车软件定义提出了自下而上的六层软件架构体系。其中第三层在设备抽象层的基础上提出设备树概念，设备树可以理解为基于设备抽象层的扩展应用，丰富了设备抽象的应用场景。

⚫ 设备树概念

设备树一词来源于计算机行业，是指系统中每个设备都有相应的节点来对应，所有的这些设备形成了一个树状结构用来描述设备的硬件信息。同样，基于整车设备抽象层也可以搭建整车上的设备树用于显示整车所有设备信息以及相关状态。

⚫ 设备树范围

由于设备抽象层的出现，整车硬件设备抽象化，对于设备抽象层之上可以获取所有设备的相关状态信息用于显示和设备管理。将设备抽象层部署在Zonal控制器和中央计算大脑中，抽象出整车设备包括：

1) 一级/二级控制器

2) ZCU/一级/二级IO开关

3) ZCU/一级/二级传感器

4) ZCU/一级/二级执行器

对于整车来说，上述任何设备是否安装在车上都可以从设备树信息显示中查看。

设备树除了显示设备信息外，还可以显示设备状态。

图 6-8 华人运通SOA设备树样例

⚫ 设备树作用及价值

通过设备树，整车厂可以对整车设备以及设备之间的关系进行查看。任何设备的信息包括生产日期、软硬件版本、供应商名称等发生任何变化，通过设备树都可以查看到。同时华人运通还在研究抽象设备即插即用，配合设备树的显示，设备树可以动态显示即插即用设备。另外，基于设备树的概念，华人运通同时提出了基于设备抽象创建整车设备诊断的方案。即通过设备抽象层，实时获取设备树上所有控制器、IO开关、传感器和执行器的状态信息。

通过这样的方式，设备树可以实时上报任意设备的故障信息以及对应发生故障时间戳，再通过上传这类信息至后台存储，为问题分析和数据定位提供了强有力的支持。同时，车辆下线的过程中车辆可以通过车辆本身的设备树完成相应的设备装配检查，真正意义上做到自动化的EOL下线检查。每次车辆上电过程，设备树也会进行设备管理和自检，相当于车辆的内嵌式诊断仪。

对于整车厂，无需每个项目针对不同配置进行定制化地开发诊断仪，设备树服务可根据不同车型进行配置，提升了车辆检查的效率同时也简化了相应流程。由此看来，设备树的提出对于车辆整个生命周期都有较深远的意义和影响。

中汽创智：

从座舱软件整体架构的角度来看，中汽创智认为在方案实施时，既要在系统上满足整车SOA架构的要求，又要充分利用座舱现有操作系统成熟稳定的技术方案和平台优势，目前座舱操作系统以QNX+Android或Linux+Android为主，相对于AP平台，Android平台的执行管理、log系统、持续化存储、升级等功能模块在消费电子领域也经得到了充分的使用验证。同时值得注意的是，Android系统本身也是符合SOA架构理念的，（android采用了AIDL（Android Interface Definition Language Android接口定义语言）和HIDL（HAL interface definition language硬件抽象层接口定义语言）来做接口约束定义，服务需要注册到ServiceManager中（SOA中的服务注册入口），通过ServiceManager的客户端代理获取服务本地接口再进行远端调用）。因此我们更建议以Android现有架构框架为主，在系统上满足整车SOA的需求为架构设计目标，实践总结如下：

⚫ 座舱域能够在整车系统层面满足SOA架构的要求，能够将其他域需要的服务提供出来，同时能够通过消费或组合其自身的服务来构建不同的应用功能；

⚫ IDL工具能够尽可能支持不同的开发语言，能够充分发挥SOA架构应对分布式系统的优势，各个系统在调用时仅需关注接口约束，服务的实现尽可能发挥特定平台的优势；

⚫ 考虑到中央计算单元会采用AP架构，整车也大概率会通过ARXML做整车机接口定义，我们在选择IDL的时候需要考虑和ARXML的兼容和转换；

⚫ 充分利用遗留代码，要充分考虑代码的复用性及可测试性。

在服务的实现上，中汽创智借鉴了Clean Architecture的设计理念：

外部依赖（系统接口、数据库，框架）服务实现围绕数据的用例数据模型定义依赖规则

图 6-9 Clean Architecture设计理念

⚫ 单一的依赖方向，从软件的变化度思考，在特定领域场景，数据模型是基本不会发生变化的，所以我们将其放到整个依赖的核心，围绕数据模型，会产生一系列的功能用例（如空调的风量值这是一个数据，围绕这个值会产生上调风量，下调风量等功能用例），功能用例的集合就是服务实现；

⚫ 将所有外部依赖，诸如系统接口，数据以及数据访问，所有的支持性框架代码都放到外部，以依赖注入的方式注入的服务实现层，这样一来，数据模型层，用例层，服务实现层就只和语言相关，可以比较容易的在不同的系统上移植；

⚫ 具备良好的可测试性，每一层都有清晰的边界，由于依赖的单向性，使得可以比较容易的mock各层的依赖，这样比较容易构建单元测试的用例，也便于做打桩测试。

⚫ 可以适配不同芯片架构和操作系统的硬件平台。FTZen支持主流的异构多核计算平台，并可以支持多路外部传感器和外部设备，比如：多路摄像头、毫米波雷达、激光雷达、高精地图等接入。同时部署FTZen的控制器具有和其他ECU进行符合SOA的标准协议通信的能力；

⚫ 支持执行管理统一调度多应用的部署，支持信息安全基础设施（加解密、身份认证)和OTA升级服务；

⚫ 通信管理模块能够支持和兼容多种通信协议，除了动态服务发现之外，还支持自

适应的传输层：通过当前通信节点的位置，判断参与者是进程内、进程间还是跨芯片，从而可以做到自动选择传输层。对于应用层来说，不需要关心传输层，从而获得无感且最优的传输性能；

⚫ 向上层应用提供标准统一的接口封装，支持将算法、功能应用以及基础平台管理通过SOA服务提供，支持灵活跨车型、跨平台的应用开发模式；

⚫ 通过SOA架构的服务接口定义和子系统的划分，Freetech设计了适用ADAS/AD产品的标准原子服务定义，根据子系统划分的设计为：数据服务子系统、感知子系统、融合子系统、预测子系统、决策规划子系统、控制子系统。

a) 服务接口重用性：跨产品和项目复用原子服务接口

b) 服务接口移植性：在不同的硬件芯片平台上进行移植

c) 服务接口可维护性：公司标准定义，原子服务接口统一维护

a． 主动安全功能，比如：FCW/AEB、LKA、FCTA/RCTA等；

b． 舒适行车功能，比如：ACC、PA、HWA、NOA等；

c． 泊车功能，比如：RPA、APA、AVM等。

福瑞泰克：

福瑞泰克智能系统有限公司（Freetech）推出了面向ADAS/AD产品落地的SOA软件中间件产品FTZen，如下图所示：

图 6-10 FTZen设计框架