AUTOSAR CP

2.1.1  技术形态

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

1. 开发方法论

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

一、开发抽象系统描述和基于 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 为周期发送同步帧，即图中 t1 时刻发送 t0 时刻的时间戳。

二、Camera/Radar ECU 在 t2 时刻收到同步帧后，记录 t2 时刻的时间戳。

三、ADCU 间隔固定时间（100ms）后发送跟随帧，发送内容即Δt0 时间。

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

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