智能汽车车用基础软件的内核和中间件

作者：初光

3533 次浏览

17 次

2022-10-21

编辑推荐:

本文主要介绍了智能汽车车用基础软件的内核和中间件，分别从技术形态、技术发展趋势、关键技术解读、典型应用四个方面对基础软件开发平台的重要组成部分 AUTOSAR CP、AUTOSAR AP、操作系统内核、虚拟化进行介绍。
本文来自于微信公众号车端，由火龙果软件Linda编辑、推荐。

本章节分别从技术形态、技术发展趋势、关键技术解读、典型应用四个方面对基础软件开发平台的重要组成部分 AUTOSAR CP、AUTOSAR AP、操作系统内核、虚拟化进行介绍。

2.1 AUTOSAR CP

2.1.1技术形态

AUTOSAR CP 是 Classical Platform AUTOSAR 的简称，广泛用于对实时性、安全性要求高的动力域控、底盘域控、车身域控等方面，以达到软硬件解耦、提高开发效率、提升软件复用性等目的。AUTO- SAR CP 规范不仅提出了软件分层架构，而且定义了基于该规范的标准开发流程，即开发方法论。下面从开发方法论、软件分层架构、工具链这三方面详细说明。

1.开发方法论

AUTOSAR CP 为基于该规范的系统开发提供了一个通用的技术方法。它定义了从系统开发到单个ECU 开发的各个阶段，以及在各个阶段需要完成的工作内容、需要提供的成果物。开发一个系统可分解为以下四个阶段。

AUTOSEMO 一、开发抽象系统描述和基于 VFB( 虚拟功能总线，它描述了系统中所有 SWC 之间的交互关系，与 ECU 个数和网络拓扑无关）的系统描述，如图 2.1-1 所示。该阶段首先基于功能提出对整个系统的技术要求和约束条件，并且从功能视角设计合理高效的系统架构。其次，工程师在车辆电子电气架构尚未确定之前就开始基于 VFB 进行系统架构设计，将功能视角的系统架构转为 VFB 视角的系统架构。

图 2.1-1 抽象系统描述与基于VFB的系统描述

二、开发系统和子系统，如图 2.1-2 所示。该阶段将整车的电子电气架构作为输入，结合网络拓扑和硬件资源情况将 VFB 视角的 SWC 分配到各个 ECU，并且将 VFB 的接口转换成能够在通信总线上传输的数据，最后生成 System Extract 和 ECU Extract 供 ECU 软件集成时使用。

图 2.1-2系统和子系统开发

三、开发应用软件和基础软件。在 VFB 视角的系统架构设计完毕后，即可进行原子级 SWC 开发包括实现其内部行为，无需关心具体ECU 信息。另一方面，在系统和子系统设计完成后，即可进行基础软件开发。因为基础软件独立于 VFB，所以只要在 ECU 软件集成前完成开发即可。四、ECU 软件集成。当 ECU Extract、基础软件、原子级 SWC 都开发完成后即可进行 ECU 软件集成。在该阶段工程师定义好 Schedule Table，将 SWC Runnable 分配到 task 中、补充基础软件配置、生成 RTE 后即可编译链接生成可执行文件。总的来说，该方法论将汽车嵌入式软件开发分为系统架构级、ECU 级和 SWC 级。系统架构级开发可进行整车级别的软件架构设计以及相关功能模块的定义。ECU 级开发则着重开发单片机底层软件。SWC 级开发则主要开发具体控制算法。各级开发可以并行，不同的开发之间通过标准化的 ARXML 文件进行交互。

2.软件分层架构

在 AUTOSAR CP 分层架构中，自上而下分别为应用软件层（Application Layer）、运行时环境（Runtime Environment）、基础软件层（Basic Software Layer）, 如图 2.1-3 所示。应用软件层包含若干个软件组件，软件组件间通过端口进行交互。每个软件组件可以包含一个或者多个运行实体，运行实体中封装了相关控制算法，其运行可由 RTE 事件触发。运行时环境作为应用软件层与基础软件层交互的桥梁，为软硬件分离提供了可能，是 VFB 的具体实现。RTE 可以实现软件组件间、基础软件间以及应用软件组件与基础软件之间的通信。RTE 封装了基础软件层的服务、提供了标准化接口，使得应用软件层可以通过 RTE 接口调用基础软件服务。此外 RTE 抽象了ECU 之间的通信，即 RTE 使用标准化接口将 ECU 之间的通信抽象为软件组件之间的通信。基础软件层又可分为四层，包括服务层、ECU 抽象层、微控制器抽象层和复杂驱动。各层又由一系列基础软件组件构成，包括系统服务、存储服务、通信服务等，它们主要用于提供标准化的基础软件服务。

图 2.1-3 AUTOSAR CP软件分层架构

服务层提供了汽车嵌入式系统软件常用的一些服务，包括系统服务、存储服务以及通信服务三大部分。还提供包括网络管理、存储管理、模式管理和实时操作系统等服务。ECU 抽象层与 ECU 平台相关，但与微控制器无关，包括板级硬件抽象、存储硬件抽象、通信硬件抽象和 I/O 硬件抽象。该层将 ECU 结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器或者 I/O 的访问，从而不需要考虑这些资源是由微控制器片内还是片外提供的。微控制器抽象层是实现不同硬件接口统一化的特殊层，包括微控制器驱动、存储驱动、通信驱动以及 I/O 驱动。通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。最后，由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以在 AUTOSAR CP 规范中没有被标准化，统称为复杂驱动。如上所述，AUTOSAR CP 良好的分层架构为软硬件之间解耦、软件模块之间解耦提供了坚实的保障。

3.工具链

V 模型是目前汽车电子软件开发过程中采用的主流开发模式，V 模型左侧统称为设计阶段，主要涵盖业务需求分析（Requirement Analysis）、系统设计（System Design）、架构设计（Architectural De- sign）、模块设计（Module Design）和编码（Coding）五个阶段。V 模型右侧统称为测试阶段，涵盖单元测试（Unit Testing）、集成测试（Integration Testing）、系统测试（System Testing）和验收测试（Ac- ceptance Testing）四个阶段。在 V 模型左侧，当前主流商用工具链可以全面支撑 AUTOSAR CP 开发方法论中提到的系统架构级、ECU 级和 SWC 级开发，详细请参考图 2.1-4 AUTOSAR CP 工具链。

图 2.1-4 AUTOSAR CP工具链

参照 AUTOSAR CP 方法论和开发流程，开发工具主要分为以下四类：一、系统设计工具。一般由 OEM 使用，主要用于完成软件组件框架（端口、端口接口、数据类型、运行实体、触发事件）的设计及框架代码生成；实现软件组件间通信端口的连接；导入 DBC、LDF 等传统网络描述性文件实现软件组件向 ECU 映射等工作。

二、软件组件设计工具。一般由 Tier1 使用，主要用于软件组件框架的搭建，生成符合 AUTOSAR 规范的代码与软件组件 ARXML 文件。之后将 ARXML 文件导入 Matlab Simulink 后可继续进行控制算法模型开发，开发完成后通过自动代码生成获得的 C 代码将用于 ECU 软件集成。

三、MCAL/BSW 配置及 RTE 代码生成工具。MCAL 配置工具主要用于底层驱动的配置与配置代码生成、BSW 配置工具主要用于基础软件协议栈的配置与配置代码生成，生成后的配置代码需要与工具供应商提供的静态代码一同进行 ECU 软件集成。RTE 代码生成工具以软件组件 ARXML 或基础软件配置ARXML 为输入，生成符合 AUTOSAR CP 标准的 RTE 代码，向软件组件提供可靠的通信和调度服务。

四、编译与调试工具。用于 ECU 软件集成时的编译与调试。由于 AUTOSAR CP 工程代码量十分庞大，所以对编译器和调试器的要求也相对较高。

此外，目前市面上的 AUTOSAR 工具链都是桌面应用程序，这使工具链的维护和升级都不方便，并且由于应用程序在各个电脑上都是独立的，所以其资源是不可共享的，使开发效率降低。而随着 5G 和千兆网络的普及，在未来，AUTOSAR 工具链由桌面应用程序发展为 Web 应用程序成为可能。具有超大带宽、超低时延、更加稳定可靠等特征的宽带网络结合超强性能的 Web 应用程序服务器，以及 Web 应用程序本身的优势，这使得工具链供应商可以更加方便的维护及更新工具，开发者们更加高效、友好的合作开发。

2.1.2技术发展趋势

AUTOSAR CP 发展历史悠久，从诞生到现在已经有近 20 年的历史。本章节将从当前痛点分析角度来阐述 AUTOSAR CP 存在的问题和未来发展趋势。AUTOSAR CP 带来的优势和便利前文已经叙述了很多，但是它也不是完美的，在实际应用过程中也存在一些问题，下面将从五个方面分别阐述。一、架构充分解耦导致标准和接口规范繁多。不可否认 AUTOSAR CP 的规范文档非常详尽，但正是两百多个多达几万页的标准文档让一些传统的嵌入式工程师望而止步。同时 AUTOSAR CP 提出了很多新概念，比如标定量通过描述文件进行描述；应用接口不通过传统全局变量的方式与底层软件交互，而是对接口进行描述定义通过 RTE 统一接口进行匹配等。AUTOSAR CP 的软件开发理念和传统嵌入式工程师的认知偏差也是其普及率不高的原因之一。

二、工具链价格昂贵国产研发之路任重而道远。动辄几百上千万的软件使用授权费对 OEM、Tier1 来说都是很大的研发投入。尽管国内已经有普华基础软件、经纬恒润、东软睿驰、中汽创智等几家供应商开始布局工具链的开发，但国产工具链的研发推广之路依然任重而道远。

三、工具链之间兼容性差影响合作开发的灵活性。在实际项目中并没有体现出 AUTOSAR CP 软件模块的复用性和独立性。由于各厂商对 AUTOSAR CP 规范的理解并不完全一致，而且各厂商的工具也并不完全兼容，导致 OEM 集成各家供应商开发的软件模块需要花费大量的精力和时间。原本希望借助 AU- TOSAR CP 标准统一的优势合作开发，但是因为工具链的兼容性问题而不得不统一工具链的使用，严重限制了合作开发的灵活性。

四、自动化程度低导致开发和集成效率偏低。基础软件与应用软件的接口集成需要大量的手动配置工作，不仅操作上低效出错率高，而且在错误检查方面也不如传统软件集成方便。对于某些错误提示往往不能快速定位错误原因，对于某些需求追加或变更往往不能快速对应。针对这一痛点，国内大部分 OEM 都已经开始使用自动化脚本工具直接操作 ARXML 来代替这种重复性的工作。

五、代码可读性差导致调试困难。这是代码生成工具普遍存在的问题，和 MATLAB 的 AUTOSAR 工具箱生成的代码一样，一些 AUTOSAR 工具链的 RTE 代码生成工具生成的代码可读性也较差，这给软件调试带来了不少麻烦。例如在调试基于 SOMEIP 的服务通信时需要根据服务请求信号、提供信号的数据流向和函数调用关系，一层一层地查询才能理解整个通信过程。

2.1.3关键技术解读

1.基础软件多核分配

基础软件多核分配是发挥多核系统并行计算、负载均衡、快速响应优势的关键技术。没有基础软件的多核分配，就算应用软件做了多核分配，多核系统的优势将受到核间通信效率的制约，甚至系统整体性能还不如单核。实现基础软件多核分配的主要技术手段有主卫星方式（Master/Satellites）和通信协议栈分割（Com-Stack Split）两种。

一、主卫星方式。如图 2.1-5 主卫星方式的基础软件分割所示，该方式可适用于 Dem、FiM、WdgM、Com、NvM、XCP、EcuM 等基础软件组件。当这些组件提供的服务需要被多个核使用时可以考虑主卫星方式，即卫星给其所在核的其他模块提供服务接口并将收到的服务请求通过主卫星通信传递给主星，主星协调、过滤和接收各卫星的服务请求并进行处理，最后将处理结果通过主卫星通信反馈给卫星。由于主卫星之间的工作分配 AUTOSAR CP 并未标准化，所以用户可自定义。一种极端情况是主星具备全部功能，卫星仅为同核其他模块提供服务接口并将服务请求转发到主星上处理；另一种极端情况是卫星和主星一样具备全部功能并不需要主星处理服务请求，它只需要与主星保持必要信息的同步。

图 2.1-5 主卫星方式的基础软件分割

由于卫星提供的接口可以被该核的其他模块直接调用并通过高效的主卫星通信与主星交互，从而避免了低效的 Client/Server 通信，大大提高了多核系统中基础软件的服务效率。另外由于主卫星可并行处理服务请求，因此 CPU 负载可以被有效平衡、基础软件的服务速度也得到提高。

二、通信协议栈分割方式。该方式通过一个增强型的 PduR 引入FIFO 队列（无需自旋锁）或 Buffe（r 需要配合自旋锁）这样的数据结构对跨核 PDU 进行路由，可将不同类型的总线协议栈分配到不同的核，如将 CAN 协议栈和以太网协议栈分配到不同的核。通过这样的协议栈分割可达到 CPU 负载均衡及提升多核系统实时性的目的。

2.软件集群技术

软件集群（Software Cluster）在 R20-11 版本中被首次提出，是 AUTOSAR CP 在软件架构方面的一次创新，其本质是利用二进制接口技术实现更为灵活的软件集成与更新。

图 2.1-6 软件集群技术示例

如图 2.1-6 软件集群技术示例所示，通过软件集群技术 AUTOSAR CP 软件架构被分割成了两个独立的软件集群，分别为应用软件集群（Applicative Software Cluster）和主软件集群（Host Software Cluster）两部分。其中应用软件集群可以单独编译，其搭载一组关联度较高的 SWC ；主软件集群也可以单独编译，其除了可以搭载 SWC 之外还必须搭载基础软件（包含 OS 和 MCAL）。一个控制器中可以存在多个高度解耦的应用软件集群，但是只能且必须存在一个主软件集群，分别将应用软件集群和主软件集群烧写至目标板后即可形成完整的、可执行的程序。这样的软件架构创新使得软件的开发与集成变得更加灵活，尤其是当需要更新软件功能时，无需更新全部软件，只要更新特定的软件集群即可。

如图 2.1-6 软件集群技术示例中的蓝框所示，各个软件集群就像是控制器上的一块块拼图，而这些拼图之间是通过软件集群连接块（Software Cluster Connection）拼接起来的。软件集群连接块由三部分组成，分别是二进制清单（Binary Manifest），跨软件集群通信（Cross Cluster Communication），代理模块（Proxy Modules）。其中最关键的是二进制清单，它在编译阶段产生且 AUTOSAR CP 规定了其标准格式，它为各个软件集群编译后文件（Binary Objects）之间提供了定义良好的接口，从而能将其连接在一起形成完整的可执行文件。图 2.1-7 软件集群的连接展示了二进制清单连接两个软件簇的例子，其中软件集群 A 运行时需要一个资源（Require Resource，指软件集群运行时所需要的一切，或是 S/R 接口，或是 NV 块），而这个资源正好可以由软件集群 B 提供（Provide Resource）。软件集群 A/B 的二进制清单中都分别存储了这个资源的基本信息包括：资源属性（Require/Provide）、资源类型（S/R、NV 块等）、资源 ID、句柄一览表（Handle，即用于访问该资源的信息如数据指针、函数指针、数据等）等。对于软件集群 A 来说，因为在其单独编译阶段没有相应的 Provide Resource，所以其二进制清单的句柄一览表被默认值填写且是可修改的，如图 2.1-7 黄色框所示。对于软件集群 B 来说，因为其具备固定的Provide Resource，所以其二进制清单的句柄一览表在编译时已确定且是不可修改的，如下图绿色框所示。如果在烧写时进行软件集群连接，那么目标板内的软件集群连接器软件（On-board Software Cluster Connector）负责在烧写的同时，将软件集群 B 中资源的句柄拷贝至软件集群 A 中资源的句柄，从而完成两个软件集群的连接。

图 2.1-7 软件集群的连接

跨软件集群通信用于支撑 VFB 通信。而代理模块分为高代理模块（High Proxy Modules）和低代理模块（Low Proxy Modules）两部分，其中高代理模块位于应用软件集群代替原先的基础软件模块提供符合 AUTOSAR 标准的接口，低代理模块位于主软件集群负责实现真正的基础软件模块功能，二者之间通过二进制清单连接。

2.1.4典型应用案例

本章节将分享几个基于 AUTOSAR CP 基础协议栈的典型应用案例供读者参考。

1.SOME/IP 应用案例

在某公司 L3+ 自动驾驶项目中，整车和传感器通过 CAN 总线与自动驾驶域控制器的 MCU 进行交互， MCU 再将从 CAN 总线接收到的数据组包转发给 SOC 的各应用模块，MCU 与 SOC 之间则通过基于以太网的 SOME/IP 通信协议进行交互。常用的 SOME/IP 以太网消息类型有：REQUEST、REQUEST_NO_RETURN、NOTIFICATION、RE- SPONSE。其中 REQUEST 为期待响应的请求，客户端有需求时才会向服务端发送请求，且客户端会等待服务端反馈的结果。例如，客户端如果需要向服务端请求 VIN 码，则可发送 REQUEST 类型的消息。RESPONSE 则为响应消息，即服务端的用于响应客户端 REQUEST 类型的报文。例如：客户端向服务端请求 VIN 码，服务端则通过 RESPONSE 类型的消息给客户端回复 VIN 码。REQUEST_NO_RETURN 为不期待响应的请求，客户端有需求时才会向服务端发送请求，但客户端不关注结果。例如，客户端如果需要向服务端请求打开车窗，客户端可发送 REQUEST_NO_RETURN 类型的消息。NOTIFICATION 为事件通知，客户端先向服务端订阅消息，服务端当发现被订阅的消息发生变化时则主动通知客户端。例如，客户端向服务端订阅车速信息，服务端如果发现车速变化则可发送 NOTIFICATION 类型的消息给客户端。在本案例中，由于 MCU 与 SOC 的通信数据具有数据量大、通信数据类型确定、数据周期性发送等特点，因此 SOME/IP 消息采用 NOTIFICATION 类型。自动驾驶域控制器的软件架构如图 2.1-8 所示。

图 2.1-8 自动驾驶域控制器软件架构

MCU 一侧基于 AUTOSAR CP 搭建应用软件，主要包括三个应用模块：VDC（Vehicle Data Center）将整车相关 CAN 数据做预处理，此类 CAN 数据主要指 VCU、EPS、EPB 等控制器数据；XDC （X Sensor Data Center）将各传感器的 CAN 数据做预处理，此类 CAN 数据主要指毫米波雷达、组合导航、智能摄像头等传感器数据；IDC（Internal Data Center）将预处理后的 CAN 数据转换成以太网数据并通过 SOME/IP 协议发送到 SOC 一侧。SOC 一侧基于 AUTOSAR AP 搭建，其中 SDC（Service Date Center）将以太网数据转换为 SOC 应用模块所需要的数据。在 SOME/IP 通信中，SOC 侧的 SDC 作为客户端，启动后即开始订阅 MCU 侧的所有已知服务，MCU 一侧收到订阅后即开始以固定周期向 SDC 侧发送订阅的报文，为保证实时性，SOME/IP 的数据传输周期与 CAN 报文周期一致。

SOME/IP 序列化方式采用大端一字节对齐。因为一字节对齐是最简单的对齐方式，大多编译器很容易实现；并且采用一字节对齐，序列化后没有冗余数据，报文的有效负载段都是有意义的数据，所以总体传输效率得到了一定提升。另外，SOME/IP 通信报文中的 Payload 也会添加时间戳和 Rolling Counter 等信息，SOC 一侧的应用在使用 MCU 传来的数据之前，会先把时间戳取出来，并作数据校验、对齐、分析等工作。SOME/IP 报文结构如图 2.1-9 所示。

图 2.1-9 SOME/IP报文结构

本案例中的 SOME/IP 协议均基于 UDP 协议开发，它在用户有需求的时候才发送报文，这种方法有以下几点优势：

一、传输效率高。与 CAN 等周期性的网络相比，总线上不会出现过多不必要的数据，从而减少了资源消耗，点对点的全双工传输模式也让通信效率变得更高。

二、通信速率快。对于雷达这类较大的数据，需要 MCU 能在短时间内及时地将数据传输到 SOC，使用以太网是目前各类总线通信中速率最快的，它最能满足大数据量的通信需求。

三、数据长度长。CAN-FD 报文数据长度最大 64 字节，LIN 报文数据长度最大 8 字节，单帧 Flex- ray 报文数据长度最大 254 字节，而基于 UDP 的以太网单帧报文长度可达 1500 字节，能满足大数据的通信需求。

四、实现较简单。以太网已有成熟的 TCP/IP 协议栈，基于 Linux 平台还有开源的 Vsomeip 协议栈，可直接移植使用。

2.时间同步应用案例

在智能驾驶中，时间是一个非常重要的参数，各个系统中需要保证时间一致，其中包括车云系统之间时间一致；域控之间时间一致；域控与各个 ECU 之间时间一致；ECU 与各个传感器之间时间一致等。车云系统为保证时间一致，常在车载 ECU 中加装 GPS 模块，ECU 通过 GPS 数据与云平台时间保持一致。车内系统（域控之间、域控与 ECU 之间、ECU 与传感器之间）为保证时间一致主要采用：PTP（Precision Time Protocol 高精度时间同步协议）、PPS（同步脉冲信号）、AUTOSAR CP 同步方案等。

如图 2.1-10 多传感器融合系统中，Camera ECU 通过高精度摄像头采集车道线、障碍物、标识等信息；Radar ECU 通过毫米波雷达进行障碍物、障碍物速度等信息的采集；Camera/Radar ECU 通过CAN-FD 将处理的数据交给 ADCU 进行数据融合，ADCU 中自带 GNSS 芯片保证与云端时间一致。由于该系统对数据实时性、真实性要求比较高，所以需要保证 Camera/Radar ECU 采集的数据时间一致。为了达到该目的，如图 2.1-11 时间同步步骤所示，本案例采用了 AUTOSAR CP 时间同步解决方案，即ADCU 作为 Time Master 实体，Camera/Radar ECU 作为 Time Slave 实体，由 ADCU 对 Camera/Ra- dar ECU 进行时间同步。

图 2.1-10 多传感器融合系统

时间同步的步骤与方法如下：

图 2.1-11 时间同步步骤

一、ADCU 以 1s 为周期发送同步0帧，即图中 t1 时刻发送 t0 时刻的时间戳。二、Camera/Radar ECU 在 t2 时刻收到同步帧后，记录 t2 时刻的时间戳。三、ADCU 间隔固定时间（100ms）后发送跟随帧，发送内容即Δt0 时间。

四、Camera/Radar ECU 在t3 时刻接收到跟随帧后，进行绝对时间计算并将绝对时间更新到 ECU 中，公式为：t3 = t0 +Δt0 + t3–t2。

注：本章有关AUTOSAR 的内容是AUTOSEMO 会员单位的经验解读，仅供行业参考。

2.2 AUTOSAR AP

2.2.1技术形态

新四化（电动化，网联化，智能化，共享化）的变革驱使汽车软件系统变得更加灵活。汽车软件既要安全又要可持续更新以反映新的功能特性或法规要求，为此需要新架构支持软件组件的动态部署以及与非车载系统之间的交互。今天的汽车 E/E 架构可划分为信息娱乐、底盘和车身控制等不同域，信息娱乐系统通常使用 Linux 或商业化的通用操作系统，车身控制则使用标准的 AUTOSAR CP。随着未来新技术及深度嵌入式系统对计算能力需求的不断增长，急需第三种控制器—— 域控制器，用于集成特定领域的功能特性（如车辆动力域、车身域等 )，形成域集中或跨域集中式电子电气架构。在未来，随着汽车电子及软件功能的大幅增长，E/E 架构最终可能向基于中央计算平台的整车集中式电子电气架构，以及车云协同控制发展。在这种趋势下，需要高度灵活、高性能且支持 HPC、动态通信等特性的新软件架构平台—— Adaptive Platform AUTOSAR 平台（下文简称 AUTOSAR AP）。

1.软件分层架构

典型的域控软件架构如图 2.2-1 所示，整体可被分为四层，即操作系统层、基础平台层、原子服务层、应用组合服务层。AUTOSAR AP 在基础平台层，这一层包含了 AUTOSAR AP、AUTOSAR CP、专用基础功能等，主要为整车提供基础运行环境。原子服务层是实现数据融合和控制逻辑的功能模块，作为服务的最小单位与单一执行实体，通过 API 为应用提供可按需编排的基础服务，实现一次开发多次复用，最大化提升开发效率。该层的设计目标是原子服务与平台解耦，提升软件复用性。应用层基于原子服务实现对整车服务、应用、体验等进行定义和组合增强，构建差异化竞争力的业务应用，体现千车千面。

图 2.2-1 域控软件架构图

图2.2-2 AUTOSAR AP在软件架构中的位置

AUTOSAR AP 在域控软件架构中位于中间件的位置，通过服务和API 为上层服务提供功能，如图2.2-2 所示。

在 Non-AUTOSAR 环境中，系统已经实现了部分 AUTOSAR AP 标准组件，只需要实现剩余部分组件即可满足 AUTOSAR AP 的标准。比如在 Android Automotive OS 中，软件框架提供了进程管理、执行管理、Log、加密、生命周期管理等功能，基础软件供应商实现通信管理、诊断、升级、网络管理等功能，即可满足 AUTOSAR AP 的标准。

2.工具链

基于自适应平台的应用程序开发一般要经历三个阶段，分别是设计建模阶段、软件开发阶段、集成部署阶段，为了更好地支撑这三个阶段的活动，AP 工具链具备以下能力：

设计建模阶段使用建模工具，用于生成 ARXML，完成 Adaptive Application、Service Instance、Executable、Machine 等设计开发，配置 SWC（Software Component）相关配置项，完成 SWC 端口及框架设计 , 最终导出 AP 平台的 ARXML 文件。产品工具应具备支持导入导出、解析、编辑ARXML 文件的能力。

软件开发阶段：使用 AP 产品生成工具，用于实现组件 API 代码及 Manifest 配置文件的生成。输入是标准的 ARXML 文件，生成源代码和 Manifest 配置文件，另外需要包含应用层的代码编辑器和代码库管理，实现源码编辑，编译链文件编写，代码库同步等功能。

集成部署阶段：使用集成编译调试以及部署工具，包含编译工具、可视化调试工具、部署工具、资源监控等工具，支持编译、调试、部署等功能。

3.开发方法论

为了支持 AP 平台下应用程序独立、敏捷、分布式的开发，需要在开发方法论上有一套标准化的方法。AUTOSAR AP 开发方法论涉及工作产品的标准化，用于描述工作产品（如服务、应用程序、机器及其配置）、工作产品应如何交互、以实现自适应平台产品开发过程中不同角色之间所需的信息交换。图 2.2-3 简要展示了 AP 平台的开发工作流，总体来说需要经历三个阶段七个步骤，最终将开发的软件集成入车辆中。

（1）架构设计阶段

① 服务接口设计（Define Services）：主要是定义服务接口及数据类型，包括定义服务所包含的method、event、field、trigger 等通信元素以及数据类型详细说明等；

② 机器配置设计（Configure Machine）：定义和配置机器的网络通信属性，包含网络连接配置，服务发现配置等信息；

（2）软件开发阶段

③ 定义与配置可执行实例及通信方式，定义可执行实例如何访问软件集；

④ 定义软件集群所提供的服务实例、配置服务实例和可执行实例的映射；

⑤ 服务实例接口框架源码生成；软件集群源码开发及测试等；

（3）集成与部署阶段

⑥ 软件集群集成 (Integrate Software) ：配置可执行实例和进程的映射、定义和配置应用程序配置清单、定义和配置服务实例部署信息；

⑦ ECU 集成 (ECU(Machine) Integrate)，定义应用程序执行清单 (Execution Manifest)、定义平台程序的配置清单、诊断和进程之间的映射配置；

图2.2-3 AUTOSAR AP开发方法论

2.2.2技术发展趋势

1.架构发展趋势

（1）Adaptive AUTOSAR 的历史 Adaptive AUTOSAR 于 2017 年应运而生，主要为了提供高算力、高网络带宽下的基础软件开发平台标准。目前最新版本为 R21-11。

（2）Adaptive AUTOSAR 的发展趋势

① 技术趋势

在汽车行业，智能网联、自动驾驶、V2X、OTA 等功能逐渐成为标配，Adaptive AUTOSAR 面向POSIX 标准的操作系统，可以更好支持这些功能。在最新的标准中为了更好的支持开发，在可用性及稳定性上做了如下提升：

a.可用性：提升模块特性的合理性及便利性。支持更多的 SOA 通讯协议、通信失效模式的检测、灵活支持日志内容定义等。同时，针对域控制器的异构平台，新版本在 AP 与 CP 的共用特性及方法论上进行统一，定义了自动驾驶的传感器接口、整车级健康管理的架构与接口、针对整车 OTA 升级的流程等域控制器架构的使用功能等。

b.稳定性：增加针对系统稳定的特性。如在 EM 细节中增加了配置进程错误码、功能组增加 unde- fined 状态、增加对进程意外终止的处理，PHM 中增加确定性执行的监控，UCM 中增加容错机制等。

同时在这些功能场景下，信息安全与功能安全成为不可或缺的关键机制。Adaptive AUTOSAR 针对这两项安全需求，定义了完善的特性：a.面向功能安全：新增了系统健康监控，主要用于系统协调健康状况 / 错误。主要包含以下内容：

SHM Client 交流平台健康状况；

SHM Master 确定健康指标；

根据健康指标进行的机器恢复（例如降级）；

增加了确定性同步的内容，描述了同步行为和周期性激活的要求，包括时间同步和数据同步。

b.面向信息安全：增加了入侵检测系统管理，由标准化的接口来报告安全事件。通过标准化的过滤机制来传输合格的安全事件。

增加了 Crypto API 的描述；

软件和硬件解耦；

支持分离式非耦合开发；

应用程序独立于加密解决方案。

② 基础软件技术路线

随着各种域控制器方案陆续问世，各细分赛道由分散到集中，由独立到整合。目前整车域控制器，例如智驾域控，中央域控，智能座舱域控等均需得到高性能 MPU 芯片的支撑，因此 POSIX 标准系统的搭载显得尤为必要。基于 POSIX 系统之上的 AUTOSAR Adaptive 平台及相关工具链，为应用开发过程中的效率带来显著提高，而座舱域控一般在 Linux 基础之上搭载安卓系统，在程序启动、状态切换、存储等方面有自己独立的生态，而诸如 SOA 通信、整车诊断、健康管理的方面需要参考 AUTOSAR AP 平台标准给予补齐和增强，工具链未来需要从整车视角实施统一化配置。

③ 新的分工趋势

受域控制器行业的蓬勃发展以及各项政策利好，越来越多的参与者以各种新的身份加入进来，整体的行业角色将不再是 E/E 时代的 OEM、Tier1 及 Tier2 三种。随着产业链结构的变化，位于下游负责整车生产和组装的主机厂（即行业所说的 OEM），将不再通过系统与设备集成来获取价值增量，而会转向基于用户需求和自身产品定位，建立有效的梳理筛选机制，向上游 Tier1 及 Tier2 提出更多定制化的需求。

2.工具链发展方向

工具链（tool chain）是在一套流程里面用到的所有工具和相关库组成的集合，上一个工具的输出或环境状态成为下一个工具的输入或启动环境。因此，工具链的效率决定了整个系统的开发效率。所以随着行业的发展成熟，工具链的发展将由现在分散的多工具相互切换配合形态，逐步升级到成熟开放的中间服务体系，来匹配整个产业的发展态势，在平衡各自的专业分工的前提下避免产生信息数据孤岛。

现行的工具链标准基本是在 AUTOSAR AP 规范所约定的框架内按照给定的方法论实现功能，各家比拼的是对 AP 服务模块的实现及理解。在第一阶段的服务实施提供后，要比拼的就是在整个产业上下游的环节中的规范度、可移植性及整体的效率提升。

从集成角度，基于 AP 的开发工具链一般是基于 Linux 系统进行开发、编译和调试，在用户桌面端往往出现多种开发工具同时使用的问题，因此亟需一套集成开发环境来简化用户桌面，为基于 AP 的应用开发提供便捷性。

2.2.3关键技术解读

1.面向服务的架构（SOA）

当前整车电子电气架构，功能不集中，分散到不同 ECU，使得功能和信号交互异常复杂，代码和逻辑冗余相当严重，而互联网开发思想不断涌入汽车行业，汽车电子电气开发也必须尽快适应变革。面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，独立于实现服务的硬件平台、操作系统和编程语言，使得构建在各种这类系统中的服务可以以一种统一和通用的方式进行交互。通过引入 SOA 架构，不但可以使应用软件与硬件及应用软件与应用软件之间松耦合，还可以使车端软件、通信、信息安全能和云端环境产生很好的协同，实现一整套车云生态环境，因此车端采用基于服务的通信 SOA 是有效的落地方案。

2.软硬分离

传统汽车控制器的开发模式是等硬件确定后，再进行软件的设计、开发、测试，软件的开发依赖于硬件，无法先行或同步开发，导致软硬件两个团队人员只能顺序完成工作，浪费时间。并且一旦硬件发生改变，软件则需要大量的修改适配，重复工作量巨大。在新型整车集中式 E/E 架构下，功能服务化，接口统一化，增加了中间件层，软硬分离成为可能。

3.虚拟化

当前高算力芯片层出不穷，通过虚拟化技术，将芯片上所跑的各类业务分类进行隔离已经是目前很多车企的选择。同时，在软硬分离的背景下，在 x86 架构 PC 机上或云端通过虚拟化技术运行虚拟控制器进行服务设计的验证也是目前的主流软件先行方案。

2.2.4典型应用案例

1.基于 AP 的基础软件产品和解析

（1）日志与调试

日志作为行为或状态详细描述的载体，提供可用于分析系统的活动和诊断问题的跟踪记录。在安全事件分析、事件回溯和取证过程中起着相当重要的作用。

在 AP AUTOSAR 中，Log and Trace 模块负责管理和记录 AP 平台的日志，既可以应用于开发过程，也可以适用于量产过程。在架构上，Log and Trace 模块会与 AP 的时间同步及通信管理等模块交互。基于 AP AUTOSAR 标准定义的 LT 协议，Log and Trace 模块可以让 AP 应用程序将信息记录到通信总线、控制台或文件系统上。同时 DLT 协议也提供了包括日志等级、日志 ID 等字段内容，日志客户端可以使用此信息来关联、排序或过滤接收到的日志帧，便于日志的解析查看以及日志相关功能的扩展。

平台典型的日志系统架构图如图 2.2-4 所示：

图2.2-4 Log And Trace案例

其中，App 通过使用 DLT 接口将相应的操作步骤、状态监控、故障信息等内容发送至 Daemon；Daemon 表示 DLT 守护进程，它接收并处理来自 AP 应用程序的日志信息，并根据配置对日志进行终端显示、文件存储、网络传输等操作；

Dlt-Viewer 表示通过网络传输接收 Daemon 日志信息的客户端，对日志信息进行 UI 展示，方便用户进行日志的查看和分析。

（2）日志记录分析

上文介绍了从日志产生到日志数据流转的整个过程，基于已有的日志信息，Dlt-Viewer 可以提取出我们所关注的数据，如图 2.2-5 所示。Dlt-Viewer 提供相当多 DLT 日志处理功能，除了日志显示、日志导入 / 导出等功能外，还提供了强大的日志过滤、标记等功能。过滤器可以是某一字段，甚至是正则表达式。它提供了插件的开发接口，极大地提升了功能扩展的能力。

图2.2-5 日志记录分析

（3）系统启动监控

通过解析各功能模块产生的 DLT 日志，可以分析出整个系统上电启动过程，用户可以直观地观测各功能模块的启动过程，并根据观测结果调整各功能的启动策略，达到功能模块稳定、快速启动的目的。

2.基于 AP 的应用场景介绍

本节主要介绍基于 AP 的智能域控制器（后续简称 IDC）OTA 升级场景及其实现方案。IDC 的 OTA 功能可以进行自身应用软件及系统软件、关联器件固件的升级，并在数据管理、软件升级、可追溯性、安全验证方面满足 AP 的相关要求。

在OTA 的功能实现过程中，IDC 与外界的数据交互如图2.2-6 所示。云端OTA 云服务器向车端HUT（终端信息展现单元 Head Unit & Telematics）推送升级任务，用户确认升级后，HUT 会通过网关向 IDC 及其他 ECU 以 UDS 的形式发送升级指令及升级数据，IDC 接收升级指令与数据后，在确保安全的情况下完成软件升级并向 HUT 反馈安装进度及安装结果。