28、AUTOSAR：汽车软件架构的关键技术解析

html8

墨衍会员 · AI 创作全网分发码龄8年

关注

原创最新推荐文章于 2026-08-18 15:05:41 发布 223 阅读 AI 写同款· GEO 优化 ›

嵌入式软件定时之道专栏收录该内容

¥69.90 ¥499.90

30篇文章

订阅专栏

超级会员免费看

AUTOSAR：汽车软件架构的关键技术解析

1. AUTOSAR 概述

AUTOSAR 即汽车开放系统架构（AUTomotive Open System ARchitecture），它是一个由汽车制造商、供应商、工具制造商和开发服务提供商组成的联盟。其主要目标是为机动车控制单元软件开发标准化软件架构、接口和开发方法。

在 AUTOSAR 中，时序问题在多个方面都扮演着重要角色。例如，AUTOSAR 时序扩展（TIMEX）允许对运行时要求进行详细描述，但目前只有少数量产项目使用 TIMEX。运行时环境（RTE）的配置和使用方式对软件的运行时行为有很大影响，这里存在一些陷阱，已经导致许多项目出现问题。AUTOSAR 运行时接口（ARTI）旨在显著改善 AUTOSAR 模块和 AUTOSAR ECU 应用软件的跟踪和调试，但它仍处于起步阶段。同样，基于 POSIX 操作系统的 AUTOSAR 自适应平台（AP）在时序方面也还很年轻，除了 POSIX 中定义的时序参数外，汽车软件还缺少一些重要的时序参数，如 Delta Time（DT），它是控制器的核心参数。

在 2016 年之前，基本上只有一种 AUTOSAR，其标准侧重于实现实时操作系统的 ECU。AUTOSAR OS 标准是 OSEK/VDX 标准的直接继承者。但很明显，这种经典的 AUTOSAR 很难扩展以支持高性能 ECU，如自动驾驶所需的 ECU。因此，创建了一组新的标准：AUTOSAR 自适应平台（AP），之前的 AUTOSAR 成为经典标准，即 AUTOSAR 经典平台（CP），所有通用元素，如方法相关的元素，都转移到了新创建的基础（FO）中。

AUTOSAR CP 和 AUTOSAR AP 都使用 ARXML（AUTOSAR XML 格式）记录所有配置信息。在 ECU 项目中，这些信息分布在多个 ARXML 文件中。虽然 XML 原则上人类也可读，但 ARXML 并非如此，由于大量的引用和巨大的文件大小（单个 ECU 的 ARXML 文件通常超过 200 MB），必须使用工具来处理它们。

2. AUTOSAR 经典平台（CP）

2.1 功能架构

在 AUTOSAR CP 项目中，像发动机控制单元的怠速控制这样明确定义的功能是如何实现的呢？首先是功能架构层面，在这个阶段，甚至还未确定一个功能最终是在 AUTOSAR CP 还是 AUTOSAR AP ECU 上实现，所以功能架构层用灰色突出显示，而不是图中引入的绿色（AUTOSAR CP）或棕色（AUTOSAR AP）。实际系统中会包含各种各样的功能。

2.2 软件架构、SW - C 定义和 VFB

在创建软件架构时，需要决定是使用 AUTOSAR CP 还是 AUTOSAR AP。功能通过软件组件（SW - C，有时也写作 SWC）来描述，软件架构还定义了 SW - C 之间的通信方式。虽然还未指定使用哪种物理介质来交换数据，但通信类型已确定，有两种不同类型：
- 发送者/接收者 ：发送者向一个或多个接收者发送数据，这是单向通信。如果接收者需要响应，则需要额外的通信通道。
- 客户端/服务器 ：客户端向服务器请求服务，如数据提供。

一个软件组件可以是发送者、接收者、客户端或服务器，甚至可以承担多个角色，也可以不进行 AUTOSAR 通信，不承担任何这些角色。在软件架构层，软件组件通过单个虚拟总线，即虚拟功能总线（VFB）进行通信。

2.3 RTE

通信由 RTE（运行时环境）组织，每个 RTE 都有一个配置环境和一个代码生成器。RTE 的一项重要任务是确保通信期间的数据一致性。即使在发送者、接收者、客户端或服务器的抽象层面思考，在底层也需要对存储单元进行读写和复制操作。在生成代码之前，RTE 代码生成器会分析可能出现数据不一致的地方。例如，如果两个任务具有相同的优先级，它们不能相互中断，因此不会导致相互写入不一致的数据。分析之后，RTE 会生成安全通信所需的数据、副本、访问函数和复制例程。在原则上不会出现数据一致性问题的地方，会使用高效、快速的机制，如简单的全局变量。

2.4 实现、系统配置和可运行体

软件组件的实现通过可运行体（Runnables）来完成，它们通常是无参数、无返回值的函数。可运行体有特定的要求，特别是在调度方面，例如“必须每 10 毫秒执行一次”。可运行体被分配到任务中，有两种方式：用户手动实现配置，或者部分配置由 RTE（更准确地说是 RTE 配置环境和 RTE 代码生成器）完成。如果没有手动干预，可运行体通常会加载到单个 ECC 任务中，并由周期性事件触发。

任务被分配到 OS 应用程序，每个 OS 应用程序被分配到一个 CPU，CPU 是处理器的一部分，处理器又焊接在 ECU 中，形成了一个层次结构。

下面是 AUTOSAR CP 开发流程的 mermaid 流程图：

graph LR
    A[功能架构] --> B[软件架构]
    B --> C[RTE]
    C --> D[实现、系统配置和可运行体]

3. AUTOSAR 自适应平台（AP）

3.1 功能架构

与 AUTOSAR CP 一样，各个功能的定义独立于所使用的平台。虽然只展示了一个简单的功能，但实际系统会有大量的功能。

3.2 软件架构 AA

在 AUTOSAR AP 中，一个功能会分布到一个或多个自适应应用程序（AA）中，反之，一个 AA 也可以实现多个功能。对于熟悉经典 AUTOSAR 或嵌入式领域的开发者来说，可以将 AA 想象成为 PC 开发的应用程序。下面是一个 AA 的 main 函数示例：

int main(int argc, char *argv[])
{
    int retval = 0;
    // initialize App data here
    ExecutionClient.ReportExecutionState(kRunning);
    // call App code here (which may or may not return), e.g.:
    retval = AppCode();
    ExecutionClient.ReportExecutionState(kTerminating);
    // save persistent App data and free all resources here
    return retval; // terminate
}

在运行时，POSIX 操作系统会将 AA 视为常规进程，它有一个或多个线程。这个小代码示例让我们了解了自适应应用程序的核心。

3.3 实现和系统配置

在实现和系统配置层面，除了实际的应用程序和可执行文件外，还必须创建清单文件：
- 执行清单 ：每个 AA 都需要这个清单，它描述了应用程序的执行要求以及对其他 AA 的任何依赖。类似于 Linux 上 systemd 的服务描述文件。例如，对于一个家庭自动化系统，为 Raspberry Pi 开发的软件将无线电控制的电源插座、无线电恒温器和其他设备与 LAN 连接，开发的守护进程（一个永久运行的程序）监听无线电流量并将接收到的消息转发到 LAN 供其他设备处理。假设该守护进程使用一个 Web 服务器，那么在系统启动时，首先要启动网络驱动程序，然后是 Web 服务器，最后才是守护进程，这些依赖关系会记录在执行清单中。该清单还指定了 AA 应该何时以及以何种形式（一次或永久，如上述守护进程）执行。
- 服务实例清单 ：描述 AA 使用的服务。
- 机器清单 ：汇总了与执行环境（具体硬件、虚拟机或容器）相关且独立于 AA 的所有信息。

执行清单和服务实例清单属于一个 AA，它们与可执行文件及其数据（如参数集）一起形成一个软件包。

3.4 部署

与 AUTOSAR CP 的部署不同，AUTOSAR AP 可以在运行时将软件分发到 ECU。这正是 AUTOSAR AP 具有适应性的原因，随着时间的推移，系统可以通过加载新的自适应应用程序来适应其环境。软件更新和配置管理负责在运行时将 AA 纳入系统，其他重要元素包括通信管理和执行管理组件。

3.5 执行管理和执行客户端

在上述 AA 的 main 函数中，有两个下划线标注的函数调用是 AA 必需的。参数为 kRunning 的调用标志着 AA 执行阶段的开始，即其“运行”状态，参数为 kTerminating 的调用标志着其结束。这两个语句将应用程序的后续状态通知给执行管理。AA 是否离开运行状态，或者是否仅在控制单元关闭时才发生，取决于 AA 本身。

3.6 确定性执行和确定性客户端

基于经典 AUTOSAR 的 ECU 软件通常有很大比例的周期性任务，软件架构通常围绕应用程序的主控制算法进行设计。因此，定期激活的任务是 AUTOSAR CP 开发者日常工作的重要部分。当 AUTOSAR CP 开发者首次接触 AUTOSAR AP 时，可能会想知道如何在 AUTOSAR AP 中配置与旧的周期性任务等效的功能。一个 POSIX 专家可能会建议自己设置一个定时器，但开发者肯定希望从基础软件中获得更多支持。

AUTOSAR 中的确定性客户端为开发者提供了很多功能，这里只考虑与时序相关的功能，包括无需自己设置定时器即可定期执行代码的能力。
- 冗余执行 ：可以并行第二次执行与安全相关的进程，其基本思想与锁步多核（lock - step multi - core）相同。
- 周期性执行 ：周期性执行可能与预期有所不同。确定性客户端要求 AA 遵循预期的状态模型，AA 可以处于以下状态之一：
- 注册服务（kRegisterServices） ：应用程序注册其通信服务，即告知系统它将提供哪些通信服务。
- 服务发现（kServiceDiscovery） ：应用程序确定将为其提供哪些服务。
- 初始化（kInit） ：应用程序初始化自身及其数据。
- 运行（kRun） ：应用程序执行其常规代码的一个周期，这是唯一可以定期执行代码的状态，其他状态都被视为“特殊情况”，必要时，服务发现状态可能会再次出现。
- 终止（kTerminate） ：应用程序准备终止。

状态序列可能如下（如果没有意外的服务发现发生）：
注册服务 → 服务发现 → 初始化 → 运行 → 运行 → 运行 → … → 运行 → 终止

下面是使用确定性客户端的 AA 的代码示例：

// Top-level application function of an Adaptive
// Application (AA) which uses the Deterministic Client
int AppCode(void)
{
    ActivationReturnType dccType;
    // Deterministic Client
    // Cycle (DCC) type
    while (1) { // endless loop
        dccType = DeterministicClient.WaitForNextActivation();
        // each execution of the code below is one "Cycle"
        switch (dccType) {
            case kRegisterServices:
                // call handler registering services here
                break;
            case kServiceDiscovery:
                // call service discovery handler here
                break;
            case kInit:
                // call init handler here
                break;
            case kRun:
                // call cyclic App handler here
                break;
            case kTerminate:
                return 0; // terminate with success
            default: // invalid return value
                return 1; // terminate with error
        }
    }
}

在这个代码中，实际的应用程序代码被封装在一个无限循环中，每次循环开始时都会调用 DeterministicClient.WaitForNextActivation() 方法。该方法是阻塞的，直到执行管理器激活后才会返回。激活后，POSIX 操作系统会将 AA 设置为“运行”状态，方法返回并指示 AA 的状态，根据这个状态执行相应的代码。

3.7 POSIX 调度

图中展示的大部分内容并不是 AUTOSAR 特有的，而是普遍适用于 POSIX 操作系统。一个 POSIX 应用程序由一个或多个线程的进程组成，进程的线程可以在（多核）处理器的不同 CPU 上同时运行。例如，图中显示三个线程在两个 CPU 上运行，线程 2 仅在 CPU 1 上运行，而线程 1 和线程 3 必须与其他应用程序共享 CPU 0。

3.8 AUTOSAR AP 中的时序

比较 AUTOSAR CP 和 AUTOSAR AP 的概述图可以发现，CP 只有一个状态图，而 AP 有三个：执行客户端、确定性客户端和 POSIX 调度。时序参数通常与状态机相关联，任务、中断、进程或线程在运行时改变状态，时序参数通常定义为两个转换入口点之间的时间差。在 AUTOSAR AP 中有三个状态机的情况下，使用哪个状态机来定义时序参数取决于关注点。如果关注确定性客户端的视图，则使用其状态机；如果关注线程的处理，则使用 POSIX 状态机，所有状态机同时有效，并产生各自的时序参数。

下面详细介绍确定性客户端的时序参数：
|参数|含义|
| ---- | ---- |
|PER（周期）|描述同一周期类型的两次连续激活之间的时间差，应与运行时配置的周期相对应。|
|DT（Delta Time）|描述同一周期类型的一个实例开始与后续实例开始之间的时间。|
|JIT（抖动）|描述实际周期时间与期望周期时间的偏差。|
|J（绝对抖动）|与抖动类似，描述实际周期时间与期望周期时间的偏差情况。|
|IPT（初始等待时间）|一个周期“等待开始”的时间，即激活与开始之间的时间差，更准确地说是 ACTIVATION 事件与 DeterministicClient.WaitForNextActivation() 调用返回之间的时间差。|
|RT（响应时间）|表示从 ACTIVATION 事件到受影响的循环体结束的时间，即到 DeterministicClient.WaitForNextActivation() 调用的时间。|
|DL（截止时间）|最大允许的响应时间，是一个规范，无法测量。|
|ST（空闲时间，剩余时间）|描述一次循环结束与同一周期类型的下一个循环体的 ACTIVATION 事件之间的“间隙”，无论在此间隙中是否有其他周期类型的循环通过。根据 AUTOSAR 规范，在两个 kRun 实例之间只能有一个 kServiceDiscovery 实例。如果在运行时 kServiceDiscovery 实例插入到两个 kRun 实例之间，空闲时间只能在有限程度上用于确定额外代码在导致时序问题之前可以消耗的时间，这种情况下最好使用下面描述的 NST。|
|NST（净空闲时间，净剩余时间）|由空闲时间减去空闲时间内属于其他周期类型循环运行的所有 GET 计算得出，仅适用于 kServiceDiscovery。|

这些时序参数的定义是为了确保有一套适用于 RTOS 世界和 AUTOSAR CP，以及 POSIX 世界和 AUTOSAR AP 的时序参数定义。

AUTOSAR：汽车软件架构的关键技术解析

4. 总结与对比

4.1 AUTOSAR CP 与 AP 的对比

对比项	AUTOSAR CP	AUTOSAR AP
基础操作系统	基于实时操作系统	基于 POSIX 操作系统
功能实现方式	通过软件组件（SW - C）实现功能，使用虚拟功能总线（VFB）通信	功能分布到自适应应用程序（AA），运行时 POSIX 视为常规进程
配置文件	使用 ARXML 记录配置信息，分布在多个文件，需工具处理	除应用程序和可执行文件，还需创建执行清单、服务实例清单和机器清单
部署方式	一般非运行时部署	可在运行时将软件分发到 ECU，具有适应性
时序相关	大量周期性任务，软件架构围绕主控制算法	有多个状态机（执行客户端、确定性客户端和 POSIX 调度）定义时序参数

从上述对比可以看出，AUTOSAR CP 更侧重于传统的实时控制场景，而 AUTOSAR AP 则更适应动态变化和复杂的应用环境，具有更好的灵活性和可扩展性。

4.2 时序参数的重要性

在汽车软件系统中，时序参数对于系统的稳定性、可靠性和安全性至关重要。无论是 AUTOSAR CP 中的周期性任务调度，还是 AUTOSAR AP 中复杂状态机下的时序控制，都需要精确的时序参数来保证系统的正常运行。例如，在发动机控制单元中，如果怠速控制功能的时序出现偏差，可能会导致发动机运行不稳定，甚至出现故障。

5. 应用案例分析

假设我们有一个汽车智能驾驶辅助系统，该系统需要实时处理传感器数据、做出决策并控制车辆的行驶。

5.1 使用 AUTOSAR CP 的实现

功能架构 ：确定系统的各项功能，如障碍物检测、车道保持、自适应巡航等。
软件架构 ：将这些功能划分为不同的软件组件（SW - C），例如传感器数据采集 SW - C、决策算法 SW - C 和控制执行 SW - C。它们通过虚拟功能总线（VFB）进行通信。
RTE ：RTE 负责确保各 SW - C 之间通信的数据一致性，生成安全通信所需的代码。
实现与配置 ：将可运行体（Runnables）分配到任务中，例如传感器数据采集可运行体每 10 毫秒执行一次，决策算法可运行体每 20 毫秒执行一次。任务被分配到 OS 应用程序，最终分配到 CPU 上运行。

下面是 AUTOSAR CP 实现智能驾驶辅助系统的 mermaid 流程图：

graph LR
    A[功能架构（确定功能）] --> B[软件架构（划分 SW - C）]
    B --> C[RTE（确保通信一致性）]
    C --> D[实现与配置（分配可运行体到任务）]
    D --> E[运行（CPU 执行任务）]

5.2 使用 AUTOSAR AP 的实现

功能架构 ：同样确定系统的各项功能。
软件架构 ：将功能分布到多个自适应应用程序（AA）中，例如传感器数据处理 AA、决策算法 AA 和控制执行 AA。每个 AA 有自己的 main 函数。
实现与配置 ：创建执行清单、服务实例清单和机器清单。执行清单描述 AA 的执行要求和依赖关系，例如传感器数据处理 AA 依赖于传感器硬件驱动，决策算法 AA 依赖于传感器数据处理 AA 的输出。
部署：在运行时将 AA 分发到 ECU 中，软件更新和配置管理负责管理 AA 的加载和更新。
执行管理 ：通过执行客户端和确定性客户端来控制 AA 的执行状态和时序。例如，确定性客户端可以实现传感器数据处理 AA 周期性执行，确保数据的实时性。

下面是 AUTOSAR AP 实现智能驾驶辅助系统的 mermaid 流程图：

graph LR
    A[功能架构（确定功能）] --> B[软件架构（划分 AA）]
    B --> C[实现与配置（创建清单）]
    C --> D[部署（运行时分发 AA 到 ECU）]
    D --> E[执行管理（控制 AA 状态和时序）]
    E --> F[运行（AA 执行任务）]

6. 未来发展趋势

随着汽车行业向智能化、网联化和电动化方向发展，AUTOSAR 作为汽车软件架构的重要标准，也将面临新的挑战和机遇。

6.1 更高的性能需求

未来的汽车系统需要处理更多的数据和更复杂的算法，如自动驾驶中的深度学习算法。这就要求 AUTOSAR 能够支持更高性能的硬件平台，提高软件的运行效率。

6.2 更强的安全性和可靠性

汽车的安全性至关重要，尤其是在自动驾驶场景下。AUTOSAR 需要进一步加强安全机制，例如采用冗余执行、故障诊断和容错技术，确保系统在各种情况下都能安全可靠地运行。

6.3 更好的兼容性和互操作性

随着汽车供应链的全球化和多样化，不同供应商的软件和硬件需要更好地兼容和互操作。AUTOSAR 应不断完善标准，提高不同系统之间的兼容性，促进汽车软件生态系统的发展。

6.4 与新兴技术的融合

如 5G 通信、云计算和人工智能等新兴技术将逐渐应用于汽车领域。AUTOSAR 需要与这些技术进行融合，实现车辆与外界的高效通信和智能交互。

7. 结论

AUTOSAR 为汽车软件的开发提供了标准化的架构和方法，无论是经典平台（CP）还是自适应平台（AP），都在不同的应用场景中发挥着重要作用。通过对 AUTOSAR 的深入理解和应用，可以提高汽车软件的开发效率、质量和可维护性。同时，随着汽车行业的不断发展，AUTOSAR 也需要不断演进和完善，以适应新的技术需求和市场挑战。汽车制造商、供应商和开发者应密切关注 AUTOSAR 的发展动态，积极参与标准的制定和应用，共同推动汽车软件行业的进步。