AUTOSAR Adaptive Platform 零基础入门教程

面向嵌入式工程师的 AUTOSAR AP 学习指南

基于 AUTOSAR AP R25-11 官方文档 Explanation of Adaptive Platform Software Architecture 编写。
专有名词保留英文，如 Functional Cluster、Service-Oriented Architecture、SOME/IP 等。

前言

如果你是一名嵌入式工程师，日常和 MCU、RTOS、CAN 总线打交道，那么你可能已经听说过 AUTOSAR —— 汽车开放系统架构。你可能也注意到了，近年来"Adaptive Platform"（自适应平台，简称 AP）这个词越来越多地出现在自动驾驶、智能座舱、域控制器等领域。

这份教程就是为你准备的。

你需要什么基础？ 基本的 C 语言功底、对嵌入式系统的初步了解即可。如果你熟悉 C++ 的基础语法（类、继承、虚函数），学习起来会更加顺畅。如果你之前学过 AUTOSAR Classic Platform（CP），那更好——我们会经常对比两者，帮你快速建立认知。

学完能获得什么？ 你将理解 AUTOSAR AP 的整体架构、核心概念、各 Functional Cluster 的职责和交互方式，以及 AP 在实际项目中是如何运行的。这不是一个"看完就能写代码"的教程，而是一个"看完能看懂架构文档、能和团队对话、能继续深入"的基础。

让我们开始吧。

第1课从 Classic 到 Adaptive：为什么需要 AP

1.1 你熟悉的 Classic Platform

在传统的汽车电子世界里，ECU（Electronic Control Unit）是主角。一个 ECU 通常包含一颗资源有限的微控制器（MCU），运行一个实时操作系统（RTOS），执行确定性的控制任务——比如控制车窗升降、管理发动机喷油、控制 ABS 制动。

AUTOSAR Classic Platform（CP）就是为这类场景设计的。它的核心特征是：

静态配置：软件在编译时就确定了所有任务的调度、信号的映射、通信矩阵。运行后几乎不变。
强实时性：基于固定优先级的抢占式调度，能保证微秒级的响应时间。
资源受限：典型的 MCU 可能只有几百 KB 的 RAM 和几 MB 的 Flash。
C 语言为主：不允许动态内存分配，代码风格偏底层。
信号导向通信：ECU 之间通过 CAN/LIN 总线传递信号（Signal），通信矩阵在配置阶段就固定了。

这套体系在车身控制、底盘控制、动力总成等领域运行得非常好，而且会持续存在很久。

1.2 新需求来了

然而，从 2010 年代开始，汽车行业出现了一些 CP 无法满足的需求：

自动驾驶（Autonomous Driving）：需要处理来自摄像头、毫米波雷达、激光雷达（LiDAR）、超声波传感器的大量数据。一帧摄像图像可能几 MB，点云数据每秒几十 MB。MCU 根本处理不了这种量级的数据。

高性能计算（High-Performance Computing）：自动驾驶需要运行复杂的感知算法（目标检测、语义分割）、规划算法（路径规划、行为决策）。这些算法需要 GPU、DSP 等高性能处理器，需要 GB 级的 RAM。

软件持续更新（OTA, Over-The-Air）：自动驾驶算法需要不断迭代优化。不可能像以前一样每次更新都让车主去 4S 店刷写 ECU。需要通过无线网络远程更新。

与云端交互（Cloud Connectivity）：车辆需要和 OEM 的后端服务器通信，获取高精地图、交通信息、远程诊断等。

灵活的软件架构（Flexible Architecture）：新功能需要快速开发和部署，不能每次都走几个月的集成流程。

这些需求指向了一种全新的计算平台——高性能计算平台（HPC, High-Performance Computing），它使用的是：

高性能的应用处理器（如 ARM Cortex-A 系列、x86），而不是 MCU
通用的操作系统（如 Linux、QNX），而不是 RTOS
大量的内存和存储空间（GB 级）
以太网（Ethernet）作为主要通信骨干网

AUTOSAR Adaptive Platform（AP）就是为这类高性能计算平台设计的中间件标准。

1.3 CP 与 AP 的核心对比

维度	Classic Platform (CP)	Adaptive Platform (AP)
目标硬件	MCU（Cortex-M 系列等）	应用处理器（Cortex-A、x86 等）
操作系统	专有 RTOS（AUTOSAR OS, OSEK）	POSIX 兼容 OS（Linux, QNX）
编程语言	C（禁止动态内存分配）	C++14/17（允许动态内存）
通信模型	信号导向（Signal-based），静态通信矩阵	服务导向（Service-Oriented），动态服务发现
通信总线	CAN, LIN, FlexRay	车载以太网（Ethernet）
调度方式	静态固定优先级调度	OS 动态调度（Linux CFS 等）
软件更新	刷写整个 ECU Flash	支持增量 OTA 更新
典型应用	车身控制、底盘、动力总成	自动驾驶、智能座舱、域控制器
实时性	硬实时（微秒级确定性）	软实时（毫秒级，尽力保证）
内存管理	无虚拟内存，无堆	虚拟内存，允许堆分配
进程模型	单进程多任务（Task）	多进程多线程

重要认知：AP 不是 CP 的替代品，而是互补。一辆未来的汽车中，CP 和 AP 会共存。CP 负责底层的实时控制（制动、转向），AP 负责上层的高性能计算（感知、规划）。它们之间通过网关（Gateway）通信。

1.4 AP 到底是什么

一句话总结：AUTOSAR Adaptive Platform 是一个汽车中间件标准（Middleware Standard）。

它不是一个具体的软件产品，而是一套规范（Specification）。就像 AUTOSAR CP 定义了"ECU 上的软件应该怎么组织"一样，AP 定义了"高性能计算平台上的软件应该怎么组织"。

具体来说，AP 标准定义了：

Functional Clusters（功能簇）：平台应该提供哪些功能模块，如通信、存储、安全、诊断等。
C++ API：每个功能模块对外提供什么样的 C++ 接口。
架构模式：这些模块之间如何交互，遵循什么设计原则。
部署模型：软件如何打包、部署、更新。

一个具体的 AP 实现（比如 Vector 的 MICROSAR Adaptive、EB 的 coreride、ETAS 的 RTA-VRTE）会根据这套标准开发出实际的产品。你在项目中使用的，是某个供应商的 AP 实现（称为 Stack），而不是"标准"本身。

1.5 关键术语速览

在继续之前，先认识几个贯穿整个教程的核心术语：

Adaptive Application（自适应应用）：运行在 AP 上的应用程序。每个应用是一个独立的进程（Process）。
Functional Cluster（功能簇）：AP 的功能模块。比如 Communication Management 是一个 FC，Cryptography 是另一个 FC。
ara::com：AP 的核心通信框架，基于 SOME/IP 协议实现服务导向通信。
SOME/IP：Scalable service-Oriented MiddlewarE over IP，AP 使用的通信协议。
Manifest（清单）：描述系统配置的文件，定义了进程、服务、通信等所有配置信息。
Function Group（功能组）：一组逻辑相关的功能，通过状态切换来控制哪些进程运行。
Service-Oriented Architecture（SOA）：服务导向架构，AP 的核心架构范式。

第2课 AP 整体架构一览

2.1 架构全景图

AUTOSAR AP 的架构可以从两个角度来理解：层次结构和功能分类。

层次结构（从上到下）：

┌─────────────────────────────────────────────────────┐
│            Adaptive Applications                     │
│    (App1)    (App2)    (App3)    (App4)             │
├─────────────────────────────────────────────────────┤
│          AUTOSAR Adaptive Platform (Middleware)      │
│  ┌──────────┬──────────┬──────────┬──────────┐      │
│  │ Runtime  │Communication│ Storage│ Security │      │
│  │  (EM,SM) │  (ara::com)   │(Per)  │(Crypto) │      │
│  ├──────────┴──────────┴──────────┴──────────┤      │
│  │     Safety      │   Configuration │  Diag  │      │
│  │     (PHM)       │   (UCM,Registry)│ (DM)   │      │
│  └─────────────────┴─────────────────┴────────┘      │
├─────────────────────────────────────────────────────┤
│         POSIX Operating System (Linux / QNX)         │
├─────────────────────────────────────────────────────┤
│              Hardware (SoC, GPU, DSP)                │
└─────────────────────────────────────────────────────┘

Adaptive Applications 位于最上层。每个应用是一个独立的进程（Process），使用 C++ 编写，通过 AP 提供的 C++ API 来使用平台服务。

AUTOSAR Adaptive Platform 位于中间，是中间件层。它向上为应用提供标准化服务，向下依赖 POSIX 操作系统。

POSIX OS 提供进程管理、线程管理、内存管理、文件系统、网络协议栈等基础能力。AP 通过 OS Interface 功能簇来抽象 OS 的差异。

Hardware 是底层硬件，通常是基于 ARM Cortex-A 或 x86 的高性能 SoC，可能配有 GPU、DSP、NPU 等加速器。

2.2 七大功能类别

AP 的所有 Functional Cluster 被组织成 七大类别（Category）：

类别	包含的 Functional Cluster	核心职责
Runtime	Execution Management, State Management, Log and Trace, Core, OS Interface	平台运行基础：进程生命周期管理、状态管理、日志、核心初始化
Communication	Communication Management, Raw Data Stream, Network Management, Time Synchronization, Automotive API Gateway	数据通信：服务导向通信、原始数据流、网络管理、时间同步
Storage	Persistency, Remote Persistency	数据持久化：文件存储、键值存储、远程存储
Security	Cryptography, IDS Manager, Firewall	安全防护：加密解密、入侵检测、网络防火墙
Safety	Platform Health Management, Safe Hardware Acceleration	功能安全：健康监控、硬件加速器安全使用
Configuration	UCM, VUCM, Registry	配置与更新：软件包管理、OTA 更新、配置注册表
Diagnostics	Diagnostic Management	车辆诊断：UDS 诊断服务、DTC 管理

2.3 Daemon 与 Non-Daemon

每个 Functional Cluster 要么是 Daemon（守护进程），要么是 Non-Daemon（非守护进程）。这是一个非常重要的区分：

Daemon 型 FC：作为独立的系统进程运行。它们提供系统级服务，多个应用共享同一个 Daemon。例如 Execution Management、State Management、Communication Management 都是 Daemon。

Non-Daemon 型 FC：以库（Library）的形式链接到每个应用进程中。每个应用进程都有一份自己的副本。例如 Core、OS Interface、Log and Trace、Persistency 都是 Non-Daemon。

┌───────────────┐  ┌───────────────┐  ┌───────────────┐
│   App Proc 1  │  │   App Proc 2  │  │   App Proc 3  │
│ ┌───────────┐ │  │ ┌───────────┐ │  │ ┌───────────┐ │
│ │Non-Daemon │ │  │ │Non-Daemon │ │  │ │Non-Daemon │ │
│ │(Core,Log) │ │  │ │(Core,Log) │ │  │ │(Core,Log) │ │
│ └─────┬─────┘ │  │ └─────┬─────┘ │  │ └─────┬─────┘ │
│       │       │  │       │       │  │       │       │
│  Application│  │  Application│  │  │  Application│
│    Code     │  │    Code     │  │    Code     │
└───────┬───────┘  └───────┬───────┘  └───────┬───────┘
        │                  │                  │
        ▼                  ▼                  ▼
┌──────────────────────────────────────────────────────┐
│                  Daemon Processes                     │
│  ┌─────┐ ┌─────┐ ┌──────┐ ┌──────┐ ┌───────┐       │
│  │ EM  │ │ SM  │ │ ara  │ │Crypto│ │ PHM   │ ...   │
│  │     │ │     │ │::com │ │      │ │       │       │
│  └─────┘ └─────┘ └──────┘ └──────┘ └───────┘       │
└──────────────────────────────────────────────────────┘

2.4 设计原则

AP 的架构遵循几个重要的设计原则，理解它们有助于理解"为什么 AP 要这样设计"：

SOLID 原则：和通用软件工程中的 SOLID 原则一脉相承。

单一职责（SRP）：每个 Functional Cluster 只负责一个明确的功能领域。比如 Persistency 只管存储，不管通信。
接口隔离（ISP）：接口设计精简，客户端不依赖它不需要的方法。
依赖倒置（DIP）：高层模块和低层模块都依赖抽象接口，而不是具体实现。

无环依赖原则（Acyclic Dependencies Principle）：所有 Functional Cluster 之间的依赖关系构成一个有向无环图（DAG）。这避免了循环依赖，使得模块可以独立测试、独立部署。

利用现有标准：AP 尽量使用已有的开放标准（如 POSIX、SOME/IP、TLS），而不是自己重新发明轮子。

第3课运行基石：Core、OS Interface 与平台启动

3.1 Core：平台的"第一行代码"

Core 是 AP 最基础的功能簇。它负责平台的初始化和去初始化，提供所有其他模块都依赖的基础类型。

平台启动时，Core 的 ara::core::Initialize() 函数被调用。它按照正确的顺序初始化所有 Daemon 型功能簇。当平台关闭时，ara::core::Deinitialize() 按照相反的顺序去初始化它们。

Core 提供的基础类型（你会在 AP 的每一个角落遇到它们）：

ara::core::Result<T> —— 这是 AP 中最重要的类型之一。它表示一个操作的结果：要么成功（包含一个值 T），要么失败（包含一个错误码 ErrorCode）。类似于 Rust 的 Result<T, E> 或 C++23 的 std::expected<T, E>。

// 一个返回 Result 的函数示例
ara::core::Result<int> divide(int a, int b) {
    if (b == 0) {
        return ara::core::ErrorCode(DIVISION_BY_ZERO);
    }
    return a / b;  // 成功，返回值
}

// 使用 Result
auto result = divide(10, 3);
if (result) {
    // 成功
    int value = result.value();
} else {
    // 失败
    auto error = result.error();
}

为什么用 Result<T> 而不是异常（Exception）？因为在安全关键的汽车软件中，异常的行为不可预测（何时抛出、栈展开的开销），而 Result<T> 强制调用者显式处理错误，更安全、更确定。

ara::core::Future<T> 和 ara::core::Promise<T> —— 用于异步编程。Promise 是"生产者"端，用来设置结果；Future 是"消费者"端，用来获取结果。

ara::core::Promise<int> promise;
ara::core::Future<int> future = promise.GetFuture();

// 在另一个线程中设置结果
promise.SetValue(42);

// 在当前线程等待结果
int value = future.Get();  // 阻塞直到有结果

ara::core::StringView —— 非拥有（non-owning）的字符串引用，类似于 std::string_view。用于高效传递字符串，避免拷贝。

ara::core::ErrorCode —— 错误码类型，所有平台错误的统一表示。

ara::core::MemoryResource —— 内存资源抽象，用于管理不同类型的内存区域（如共享内存、DMA 缓冲区）。

3.2 OS Interface：与操作系统的桥梁

AP 运行在 POSIX 兼容的操作系统上（主要是 Linux 和 QNX）。OS Interface 功能簇提供了一个 C++ 封装层，将 POSIX API 包装成面向对象的接口。

OS Interface 是 Non-Daemon 的——它以库的形式链接到每个进程中。

它封装的主要 POSIX 能力包括：

POSIX 能力	OS Interface 封装	用途
pthread	`ara::os::Thread`	线程创建和管理
pthread_mutex	`ara::os::Mutex`	互斥锁，线程同步
pthread_cond	`ara::os::ConditionVariable`	条件变量，线程间通知
clock_gettime	`ara::os::Clock`	系统时钟和单调时钟
timer_create	`ara::os::Timer`	定时器
shm_open	`ara::os::SharedMemory`	共享内存段
mq_open	`ara::os::MessageQueue`	消息队列
fork/exec	`ara::os::Process`	进程创建和管理

对于嵌入式工程师来说，你可以把 OS Interface 理解为"AP 版本的 HAL（硬件抽象层）"——只不过它抽象的不是 MCU 外设，而是操作系统。

POSIX PSE51 是 AP 要求的最低 POSIX 配置文件。它包含实时系统需要的核心特性：线程、互斥锁、条件变量、时钟、信号量、共享内存、消息队列等。

3.3 平台启动流程

理解了 Core 和 OS Interface，我们可以看看 AP 的启动流程了。这是理解整个平台运行机制的起点：

[硬件上电]
    │
    ▼
[Bootloader] ─── 信任链验证 ──→ [OS Kernel 启动]
                                      │
                                      ▼
                              [OS 初始化完成]
                                      │
                                      ▼
                          ara::core::Initialize()
                                      │
                          ┌───────────┴───────────┐
                          ▼                       ▼
                  [初始化 Non-Daemon FC]   [启动 Daemon FC]
                   Core, OS, Registry     EM, SM, CM, Crypto...
                          │                       │
                          └───────────┬───────────┘
                                      ▼
                          [EM 启动所有配置的进程]
                                      │
                          ┌───────────┴───────────┐
                          ▼                       ▼
                   [App Process 1]         [App Process N]
                   (链接 Non-Daemon FC)    (链接 Non-Daemon FC)
                          │                       │
                          └───────────┬───────────┘
                                      ▼
                          [所有进程报告 Running]
                                      │
                                      ▼
                          [EM 通知 SM：启动完成]

关键步骤：

硬件上电，Bootloader 执行，通过信任链（Chain of Trust）验证 OS 的完整性。
OS Kernel 启动（Linux/QNX），完成基础初始化。
Execution Management（EM） 被 OS 启动（EM 是 AP 的第一个进程）。
EM 调用 ara::core::Initialize()，初始化所有 Daemon 型功能簇。
EM 读取 Manifest（通过 Registry），确定需要启动哪些进程。
EM 依次启动各个 Adaptive Application 进程。
每个进程内部，Non-Daemon FC 的库代码被初始化。
所有进程报告"Running"状态给 EM。
EM 通知 State Management：平台启动完成。

信任链（Chain of Trust）：从 Bootloader 开始，每一步都验证下一步的数字签名。Bootloader 验证 OS → OS 验证 EM → EM 验证每个 App。这确保了只有经过认证的代码才能在平台上运行。

第4课 Execution Management：谁来决定"谁运行"

4.1 核心职责

Execution Management（EM） 是整个 AP 的"指挥官"。它控制着所有 Adaptive Application 进程的生命周期——什么时候启动、什么时候停止、什么时候重启。

EM 是一个 Daemon 型功能簇，在平台启动时由 OS 启动，是 AP 中最早运行的模块之一。

4.2 Function Group：功能的逻辑分组

要理解 EM 的工作方式，首先需要理解 Function Group（功能组） 的概念。

Function Group 是对系统功能的一种逻辑划分。每个 Function Group 代表系统的一种"工作模式"或"功能域"。

举个例子，一辆配备自动驾驶功能的汽车可能有这些 Function Group：

Function Group	含义	包含的进程
Driving	正常驾驶模式	基础感知、车道保持、自适应巡航
Parking	自动泊车模式	超声波处理、泊车规划、全景影像
Autonomous	高度自动驾驶	完整感知栈、路径规划、行为决策
Infotainment	信息娱乐	导航、音乐、语音助手
Diagnostic	诊断模式	诊断服务、数据上传

每个 Function Group 有多个 State（状态），最基本的是 On 和 Off。

当 Function Group "Parking" 切换到 On 状态时，EM 就会启动泊车所需的所有进程。当它切换到 Off 时，EM 就停止这些进程。

4.3 Process 与 StartupConfig

在 AP 中，每个 Adaptive Application 是一个独立的 进程（Process）。进程的定义在 Manifest 中，包含以下关键属性：

可执行文件路径：进程要运行的二进制文件。
调度策略和优先级：在 OS 中的调度参数。
资源组（Resource Group）：进程可以使用的 CPU 时间和内存预算。
状态依赖（State Dependency）：定义进程在哪些 Function Group State 下应该运行。

StartupConfig 描述了进程在特定 Function Group State 下的启动配置：

Function Group State: "Parking.On"
    ├── Process: UltrasonicProcessing
    │     ├── 调度策略: SCHED_FIFO
    │     ├── 优先级: 20
    │     ├── 资源组: ParkingResources
    │     └── 启动决策: OnStateDependency
    ├── Process: PathPlanning
    │     ├── 调度策略: SCHED_OTHER
    │     ├── 优先级: 15
    │     └── ...
    └── Process: SurroundView
          ├── ...

启动决策（StartupDecision） 有两种：

Immediate：平台启动时立即启动该进程。
OnStateDependency：当特定的 Function Group State 被激活时才启动。

终止决策（TerminationDecision） 也有两种：

OnStateDependency：当离开某个 Function Group State 时停止。
TerminateImmediately：发送 SIGKILL 立即终止。

4.4 进程状态切换的完整流程

假设当前系统处于 "Driving.On" 状态，驾驶员按下了"自动泊车"按钮，系统需要切换到 "Parking.On" 状态。EM 的工作流程如下：

1. State Management 请求切换到新的 Function Group State:
   - Driving: Off
   - Parking: On

2. EM 分析差异：
   - 需要停止的进程：Driving 独有但 Parking 不需要的
   - 需要启动的进程：Parking 需要但当前未运行的
   - 保持运行的进程：两个状态都需要的

3. EM 向需要停止的进程发送 SIGTERM
   - 等待进程优雅退出（在超时时间内）
   - 如果超时，发送 SIGKILL 强制终止

4. EM 启动 Parking 所需的新进程
   - 按照 Manifest 中的配置设置调度参数
   - 通知 PHM 开始监控新进程

5. 所有新进程报告 Running 状态

6. EM 通知 State Management：状态切换完成

4.5 Resource Group：资源管理

在同一个硬件平台上运行多个应用，需要合理分配 CPU 和内存资源。Resource Group 就是 EM 用来管理资源分配的机制。

Resource Group 是层级结构的：

RootResourceGroup (总预算: 100% CPU)
├── SafetyCriticalGroup (预算: 40% CPU)
│   ├── PerceptionProcess (预算: 25%)
│   └── PlanningProcess (预算: 15%)
├── ComfortGroup (预算: 30% CPU)
│   ├── InfotainmentProcess (预算: 20%)
│   └── NavigationProcess (预算: 10%)
└── BackgroundGroup (预算: 20% CPU)
    └── LoggingProcess (预算: 20%)

父组可以将部分预算"借"给子组。这种机制确保了关键任务始终有足够的 CPU 时间，即使非关键任务突然变忙也不会抢占它们的资源。

4.6 ExecutionClient：应用与 EM 的通信

每个 Adaptive Application 进程内部都有一个 ExecutionClient 实例。它是应用和 EM 之间的通信通道。

应用通过 ExecutionClient 向 EM 报告自己的执行状态（如 Starting、Running、Terminating）和执行错误。如果应用检测到自身无法恢复的错误，可以通过 ExecutionClient 通知 EM，由 EM 决定是否需要重启进程。

// 伪代码示例：应用报告执行错误
ara::exec::ExecutionClient& client = ...;  // 从平台获取
ara::core::ExecutionErrorReport report;
report.AddError(someError);
client.ReportExecutionError(report);

第5课 State Management：系统的"大脑"

5.1 核心职责

如果说 Execution Management 是"手脚"（负责启动/停止进程），那么 State Management（SM） 就是"大脑"（负责决定系统应该处于什么状态）。

SM 的核心职责是：确定当前系统的目标 Function Group State。

5.2 Machine State：系统的宏观状态

SM 管理的最顶层状态是 Machine State，它描述了整个系统的宏观运行状态：

Machine State	含义
Off	系统关闭。没有应用进程运行。
Startup	系统正在启动。EM 正在初始化各功能簇和进程。
Running	系统正常运行。各 Function Group 按需求激活。
Shutdown	系统正在关闭。EM 正在有序停止所有进程。
Restart	系统正在重启。先 Shutdown 再 Startup。

Machine State 的转换通常由外部事件触发：

[Off] ──点火/上电──→ [Startup] ──启动完成──→ [Running]
  ▲                                            │
  │                                         关闭请求
  │                                            │
  └──────────── [Shutdown] ←───────────────────┘
                      │
                   关闭完成
                      │
                      ▼
                    [Off]

[Running] ──重启请求──→ [Restart] ──→ [Startup]

5.3 StateRequest：应用如何请求状态变化

Adaptive Application 可以通过 StateClient API 向 SM 发送状态请求。

例如，当驾驶员按下"自动泊车"按钮时，泊车应用会向 SM 发送一个请求：

// 伪代码示例：应用请求状态变化
ara::sm::StateClient& stateClient = ...;

// 请求：激活 Parking 功能组，停用 Driving 功能组
ara::sm::StateRequest request;
request.SetFunctionGroupState("Parking", "On");
request.SetFunctionGroupState("Driving", "Off");

ara::core::Result<void> result = stateClient.RequestStateChange(request);

SM 收到请求后，会进行冲突解决：如果有多个应用同时请求不同的状态变化，SM 根据优先级决定哪个请求优先。

5.4 优雅关闭

SM 负责协调系统的优雅关闭。流程如下：

SM 收到关闭触发（如 ignition off）。
Machine State 切换到 Shutdown。
SM 通知 EM：目标 Function Group State 变为"全部 Off"。
EM 依次停止所有应用进程（先发 SIGTERM，等待超时后 SIGKILL）。
所有进程停止后，EM 通知 SM。
SM 调用 ara::core::Deinitialize()，去初始化所有 Daemon 型功能簇。
系统关闭。

5.5 Suspend-to-RAM（R25-11 新增）

R25-11 版本为 SM 增加了 Suspend-to-RAM 功能。这是一种低功耗状态：系统将当前运行状态保存到 RAM 中，然后关闭大部分硬件。当收到唤醒信号时，系统从 RAM 恢复状态，快速回到之前的工作状态。

这对于需要快速唤醒的场景（如从待机状态快速启动自动驾驶）非常有用。

第6课服务导向通信：ara::com 与 SOME/IP

6.1 从信号到服务

在 AUTOSAR CP 中，ECU 之间的通信是信号导向的：发送方把信号值放到 CAN 报文中，接收方从 CAN 报文中提取信号值。通信关系在配置阶段就固定了——谁发给谁、发什么信号、周期是多少，全部写死在通信矩阵里。

AP 采用的是服务导向（Service-Oriented）的通信模型。核心思想是：

通信的双方不再是"发送方"和"接收方"，而是服务提供者（Provider）和服务消费者（Consumer）。
服务提供者把自己能提供的服务"广播"到网络上。
服务消费者通过网络"发现"可用的服务，然后使用它。
通信可以是本地的（同一个 ECU 上），也可以是远程的（不同 ECU 上），应用代码不需要改变。

这就是 Service-Oriented Architecture（SOA） 的核心思想。

6.2 Service Interface：服务的"合同"

每个服务都由一个 Service Interface 定义。Service Interface 就像一份"合同"，规定了服务能提供什么。

一个 Service Interface 可以包含三种元素：

Method（方法）：请求-响应模式，类似 RPC（远程过程调用）。消费者调用方法，提供者执行操作并返回结果。

Service Interface: WeatherService
├── Method: GetTemperature() → float     // 获取当前温度
├── Method: GetForecast(day) → Forecast  // 获取天气预报

Event（事件）：发布-订阅模式，一对多的通知。提供者发布事件，所有订阅了该事件的消费者都会收到通知。

Service Interface: SensorService
├── Event: ObjectDetected(ObjectInfo)     // 检测到障碍物时通知
├── Event: SpeedChanged(float)            // 车速变化时通知

Field（字段）：可读可写的共享状态，支持订阅变化通知。

Service Interface: VehicleStatusService
├── Field: CurrentSpeed (read-only, subscribable)  // 当前车速
├── Field: TargetTemp (read/write)                 // 目标温度

6.3 Proxy 与 Skeleton：代码长什么样

在 AP 中，服务的使用者通过 Proxy 来调用服务，服务的提供者通过 Skeleton 来实现服务。

┌────────────────┐                    ┌────────────────┐
│  Consumer App  │                    │  Provider App  │
│                │                    │                │
│  ┌──────────┐  │    网络（Ethernet） │  ┌──────────┐  │
│  │  Proxy   │◄─┼────────────────────┼─►│ Skeleton │  │
│  │(客户端桩)│  │    SOME/IP 协议    │  │(服务端桩)│  │
│  └──────────┘  │                    │  └──────────┘  │
│                │                    │                │
└────────────────┘                    └────────────────┘

Proxy（代理）是客户端桩（Client Stub）。它为消费者提供和本地调用一样的接口，但实际通过网络将请求发送给服务提供者。

Skeleton（骨架）是服务端桩（Server Stub）。它接收来自网络的请求，调用应用实现的业务逻辑，然后将结果返回。

Proxy 和 Skeleton 通常由工具从 ARXML 文件自动生成。应用开发者只需要：

消费者端：使用 Proxy 调用方法、订阅事件。
提供者端：继承 Skeleton 实现业务逻辑。

消费者端代码示例：

// 使用自动生成的 Proxy 类
#include "WeatherServiceProxy.h"

// 创建 Proxy 实例
auto proxyResult = WeatherServiceProxy::BindProxy();
if (proxyResult) {
    auto& proxy = proxyResult.value();

    // 调用方法（同步）
    auto tempResult = proxy->GetTemperature();
    if (tempResult) {
        float temperature = tempResult.value();
    }

    // 订阅事件
    proxy->ObjectDetected_Event().Subscribe(
        [](const ObjectInfo& obj) {
            // 收到障碍物检测通知
            ProcessObject(obj);
        }
    );
}

提供者端代码示例：

// 继承自动生成的 Skeleton 类
#include "WeatherServiceSkeleton.h"

class WeatherServiceImpl : public WeatherServiceSkeleton {
public:
    // 实现方法
    ara::core::Result<float> GetTemperature() override {
        float temp = ReadSensor();
        return temp;
    }

    // 发布事件
    void OnObjectDetected(const ObjectInfo& obj) {
        ObjectDetected_Event().Notify(obj);
    }
};

// 启动服务
auto skeleton = std::make_shared<WeatherServiceImpl>();
skeleton->OfferService();  // 让服务可用

6.4 Offer/StopOffer：服务的生命周期

Offer/StopOffer 模式是 AP 中最重要的生命周期模式之一。

OfferService()：服务提供者调用此方法，宣告"我现在可以提供服务了"。平台会通过服务发现机制（SOME/IP-SD）在网络上广播这个消息。
StopOfferService()：服务提供者调用此方法，宣告"我不再提供服务了"。

// 服务提供者
skeleton->OfferService();    // 服务上线
// ... 服务运行中 ...
skeleton->StopOfferService(); // 服务下线

消费者端也有对应的模式：

FindService()：消费者开始搜索服务。当服务可用时，会收到通知。
StopFindService()：停止搜索。

// 服务消费者
proxy->FindNew();   // 开始搜索
// ... 当服务可用时，收到回调 ...
proxy->StopFind();  // 停止搜索

为什么需要这个模式？ 因为在动态的汽车环境中，服务不是永远可用的。比如：

泊车摄像头只在泊车模式下才启动。
某些服务可能因为故障而暂时不可用。
为了节省资源，不需要的服务应该被关闭。

Offer/StopOffer 模式让服务的可用性可以动态变化，和 Function Group State 联动。

6.5 SOME/IP：底层通信协议

SOME/IP（Scalable service-Oriented MiddlewarE over IP）是 AP 通信的基础协议。它运行在 IP 网络之上（UDP 或 TCP），定义了消息的格式和交互模式。

SOME/IP 消息类型：

消息类型	含义	对应概念
REQUEST	客户端请求调用方法	Method 调用
RESPONSE	服务端返回方法结果	Method 返回
ERROR	方法执行出错	Method 错误
EVENT / NOTIFICATION	事件通知	Event 发布

SOME/IP-SD（Service Discovery）是服务发现协议。它负责：

宣告服务的可用（Service Offer）
宣告服务的不可用（Service StopOffer）
管理事件的订阅（Subscribe / StopSubscribe）

SOME/IP-SD 使用 UDP 组播来广播服务信息。当一个新的服务上线时，网络上的所有节点都能很快发现它。

6.6 通信的传输方式

SOME/IP 可以运行在不同的传输层协议上：

传输协议	特点	适用场景
UDP	无连接，低延迟，不保证可靠	周期性事件、实时性要求高的数据
TCP	面向连接，可靠传输	方法调用、大数据传输
共享内存	同一 ECU 上的进程间通信	本地通信，零拷贝

对于同一 ECU 上的两个应用之间的通信，平台会自动使用共享内存而不是以太网，性能更高。

第7课其他通信相关功能簇

7.1 Raw Data Stream：大数据流传输

ara::com 适合结构化的服务通信，但对于高带宽的原始数据流（如摄像头视频流、LiDAR 点云），它的开销太大了。

Raw Data Stream（RDS） 功能簇专门处理这类场景。它提供两种流传输方式：

IP-based Raw Data Stream：基于 TCP/UDP Socket 的直接数据流。没有服务发现的开销，应用直接通过 IP 地址连接。

IEEE 1722 Stream：基于 AVB/TSN（Audio Video Bridging / Time-Sensitive Networking）的数据链路层流。提供确定性的低延迟传输，适合对时延极敏感的传感器数据。

ara::com 适合：控制指令、状态信息、结构化数据
              （小数据量，需要服务发现，需要类型安全）

Raw Data Stream 适合：视频流、点云、原始传感器数据
              （大数据量，低延迟，不需要服务发现）

7.2 Network Management：网络可用性管理

在车载网络中，不是所有网络通道都永远在线的。为了节省电能，不使用的网络可以被关闭。

Network Management（NM） 功能簇负责管理网络连接的可用性。它提供两个核心操作：

NetworkRequest：请求某个网络通道可用。NM 会确保该网络被激活。有超时机制——如果网络在超时时间内没有就绪，请求失败。
NetworkRelease：释放之前请求的网络。当没有任何使用者需要该网络时，NM 可以将其关闭以节省电能。

// 伪代码示例
auto handle = nm.RequestNetwork("Ethernet_1", timeout);
// ... 使用网络进行通信 ...
nm.ReleaseNetwork(handle);

NM 与 State Management 紧密配合：当某个 Function Group State 需要特定网络时，SM 会通过 NM 确保网络可用。

7.3 Time Synchronization：时间同步

在分布式系统中，所有节点需要有统一的时间基准。AP 的 Time Synchronization 功能簇提供了这个能力。

核心概念：

TimeBase：一个命名的、同步的时间参考点。例如 /vehicle/time 代表整车统一时间，/gps/time 代表 GPS 时间。
Provider：提供时间的实体（如 GPS 接收器、gPTP 主时钟）。
Consumer：读取时间的实体（大多数应用都是 Consumer）。

AP 支持 gPTP（IEEE 802.1AS）协议来实现亚微秒级的时钟同步。这对于传感器数据融合（如将摄像头和雷达的数据在时间上对齐）至关重要。

7.4 Automotive API Gateway：连接外部世界

Automotive API Gateway（AAG） 是 AP 和外部系统之间的桥梁。它提供了标准化的方式让外部客户端（如手机 App、云端服务）访问车辆数据。

AAG 的核心是 VSS（Vehicle Signal Specification）——一个标准化的车辆信号树。它定义了统一的信号名称和结构，如 Vehicle.Speed、Vehicle.Chassis.AcceleratorPedal.Position。

外部客户端可以通过 VISS（Vehicle Information Service Specification） 协议（基于 WebSocket）来读写这些信号，而不需要关心底层是 CAN 总线还是 SOME/IP 服务。

第8课数据存储：Persistency

8.1 两种存储模式

AP 的 Persistency 功能簇提供两种数据持久化方式：

FileStorage（文件存储）：基于文件系统的存储。每个应用有一个私有目录，可以进行标准的文件操作（读、写、删除、列出文件）。

// 伪代码示例
auto storage = ara::per::FileStorage::Open("MyAppStorage");
auto file = storage.OpenFile("config.json", ara::per::AccessMode::ReadWrite);
file.Write(configData);
file.Close();

KeyValueStorage（键值存储）：简单的键值对数据库。键是字符串，值是字节数组。支持增删改查。

// 伪代码示例
auto kv = ara::per::KeyValueStorage::Open("MyAppKV");
kv.Write("max_speed", speedData);
auto result = kv.Read("max_speed");

8.2 安全特性

Persistency 支持两种安全特性，都通过 Cryptography 功能簇实现：

DataEncryption（数据加密）：存储的数据自动加密。应用写入明文，平台负责加密后写入物理介质。读取时自动解密。应用代码不需要改变。

DataIntegrity（数据完整性）：为存储的数据计算校验和或签名。读取时验证数据是否被篡改。

这两种特性通过 PersistencyDomain 来配置。一个 PersistencyDomain 定义了一个存储区域的属性：存储位置、是否加密、是否校验、配额限制等。

8.3 Remote Persistency

R25-11 新增了 Remote Persistency 功能簇。它通过 ara::com 将 Persistency 服务暴露为远程服务，允许：

一个应用代理管理其他应用的存储。
将数据持久化到远程机器（如云端存储）。

第9课安全体系：Cryptography、IDS 与 Firewall

9.1 Cryptography：加密的瑞士军刀

Cryptography 是 AP 中最复杂的安全功能簇。它提供了所有密码学操作的统一接口。

核心架构：

CryptoProvider：主入口/工厂。应用通过它获取所有密码学功能。
CryptoContext：代表一个具体的密码学操作配置（算法、模式、密钥）。
KeySlot：密钥的逻辑容器。每个 KeySlot 定义了密钥的访问策略（可以做什么操作：加密、解密、签名、导出等）。
KeyStorageProvider：管理 KeySlot，支持加载、存储和删除密钥。

支持的密码学操作：

类别	算法
对称加密	AES (CBC, CTR, GCM, CCM), DES, 3DES
非对称加密	RSA, ECDSA, Ed25519
哈希	SHA-256, SHA-384, SHA-512, SHA3
MAC	HMAC, CMAC, GMAC
数字签名	RSA-PSS, ECDSA, Ed25519
密钥派生	HKDF, PBKDF2
密钥协商	ECDH
AEAD	AES-GCM, AES-CCM, ChaCha20-Poly1305

证书处理：CryptoProvider 还包括 X509Provider，用于 X.509 证书的解析、验证和证书链校验。

HSM 集成：密码学操作可以卸载到 HSM（Hardware Security Module） 硬件安全模块上执行，提供防篡改的密钥存储和高性能的密码运算。

9.2 IDS Manager：入侵检测

Intrusion Detection System Manager（IDS Manager） 负责检测和报告车辆内的安全事件。

工作流程：

事件报告：各个功能簇或应用通过 EventReporter 向 IDS Manager 报告安全相关事件（如未授权访问尝试、证书验证失败、异常网络流量）。
事件鉴定：IDS Manager 对事件进行评估和鉴定，判断是否为真正的安全事件（QualifiedEvent）。
事件存储和转发：鉴定后的安全事件被存储，并可以转发给外部系统（如 OEM 的 SIEM 平台）进行进一步分析。

9.3 Firewall：网络防火墙

Firewall 功能簇提供基于规则的网络流量过滤。

核心概念：

Rule（规则）：匹配数据包的属性（源/目的 IP、端口、协议），执行动作（Allow 或 Deny）。
RuleSet（规则集）：一组规则的集合。可以同时激活多个规则集。
NetworkZone（网络区域）：定义安全区域，如"车内网络"、"车外网络"、"诊断网络"。
DefaultAction：当没有规则匹配时的默认动作。推荐"默认拒绝"。

Firewall 规则在 Manifest 中配置，支持动态更新。被丢弃的数据包会作为安全事件报告给 IDS Manager。

9.4 安全体系的整体视图

外部攻击面
    │
    ▼
┌──────────┐    ┌──────────┐    ┌──────────┐
│ Firewall │───→│IDS Manager│───→│ 外部 SIEM │
│ (过滤)   │    │ (检测)    │    │ (分析)    │
└──────────┘    └──────────┘    └──────────┘
    │                                ▲
    ▼                                │
┌──────────┐                   ┌──────────┐
│ Crypto   │──────────────────→│ 安全通信  │
│ (加密)   │  SecOC, TLS, IPsec│ (ara::com)│
└──────────┘                   └──────────┘
    │
    ▼
┌──────────┐
│ 信任链    │  Boot → OS → EM → App
│ (启动验证)│  每一步验证数字签名
└──────────┘

第10课功能安全：Platform Health Management

10.1 为什么需要 PHM

AP 运行的是 POSIX 通用操作系统，不像 CP 的 RTOS 那样有确定性的调度保证。但自动驾驶等功能对安全性的要求极高（ASIL-B 甚至 ASIL-D）。

Platform Health Management（PHM） 功能簇就是为了在 AP 上实现功能安全而设计的。它监控所有"被监控实体（SupervisedEntity）"的健康状态，在检测到故障时执行恢复动作。

10.2 三种监控类型

Alive Supervision（存活监控）：类似看门狗（Watchdog）。被监控的进程必须定期报告"我还活着"。如果在超时时间内没有报告，PHM 认为进程已经挂死。

进程:  ──check──check──check──×──────×──────
PHM:   OK    OK    OK    超时! 执行恢复动作

Deadline Supervision（截止时间监控）：检查进程是否在规定时间内完成特定操作。如果操作执行时间超过截止时间，视为故障。

进程:  ──start──done(5ms)──start──done(8ms)──start──×(>10ms)
PHM:   OK     OK          OK     OK          超时! 执行恢复动作

Logical Supervision（逻辑监控）：检查应用是否遵循了正确的逻辑控制流。应用在执行过程中设置"检查点（Checkpoint）"，PHM 验证检查点的顺序和时间是否符合预期。

进程:  ──CP1──CP2──CP3── (预期顺序)
PHM:   OK

进程:  ──CP1──CP3──CP2── (顺序错误!)
PHM:   故障! 执行恢复动作

10.3 恢复动作

当 PHM 检测到故障时，可以执行以下恢复动作（RecoveryAction）：

恢复动作	描述
RestartProcess	重启故障进程
ResetNode	复位整个计算节点
SetProgrammedState	切换 Function Group State（如从自动驾驶降级到手动驾驶）
OfferService / StopOfferService	控制某个服务的可用性

恢复动作的优先级和策略在 Manifest 中配置。PHM 的设计遵循"检测→诊断→恢复"的模式。

10.4 硬件看门狗

作为最后一道防线，PHM 还管理硬件看门狗（Hardware Watchdog）。如果软件完全失去响应（包括 PHM 自己），硬件看门狗会在超时后触发硬件复位。

10.5 Safe Hardware Acceleration（R25-11 新增）

R25-11 新增了 Safe Hardware Acceleration（SHA） 功能簇，提供了一套框架来将计算密集型任务卸载到硬件加速器（GPU、DSP、FPGA）上，同时满足功能安全要求。

它的 API 模型类似 OpenCL：

Platform → Device → Queue → TaskHandler (计算内核)
                  → Buffer (输入/输出数据)
                  → Event (同步机制)

与消费级 OpenCL 不同，SHA 增加了：

安全分区和非安全分区之间的内存隔离
确定性执行保证
错误检测和恢复机制

第11课配置与更新：UCM、VUCM 与 Registry

11.1 Registry：配置的源头

Registry 功能簇提供对 Manifest 的访问。Manifest 是 AP 系统的"总配置文件"，描述了系统中的一切静态配置信息：

所有进程的定义和启动配置
所有服务接口的定义
通信配置（哪些服务在哪些端口上提供）
安全策略（密钥存储位置、防火墙规则）
存储配置（Persistency Domain）
监控配置（PHM Supervision 参数）
诊断配置

Manifest 在编译时从 ARXML 文件生成，在运行时是只读的。应用通过 Registry 的 ManifestAccessor API 来读取配置信息。

11.2 UCM：单节点软件更新

Update and Configuration Management（UCM） 负责管理单个 ECU 上的软件更新。它的核心概念是 Package（软件包）：

软件包的生命周期：

[传输 Transfer] → [处理 Process] → [激活 Activate] → [回滚 Rollback (可选)]
     │                │                  │                   │
  下载到 ECU      验证签名/完整性     安装新版本          如果激活失败
  (可选分阶段)    检查兼容性/依赖     可能需要重启        回退到旧版本

UCM 通过 D-PDU API（ISO 22900-2）来执行底层的编程操作（刷写 Flash）。

关键特性：

原子性：安装操作是事务性的——要么完全成功，要么完全回滚。不会出现"安装了一半"的状态。
签名验证：每个软件包都必须经过数字签名验证，确保来源可信且未被篡改。
前置条件检查：安装前检查兼容性、依赖关系、可用空间等。

11.3 VUCM：整车级别的更新协调

Vehicle Update and Configuration Management（VUCM） 在整车层面协调软件更新。一辆车可能有多个 ECU 运行 AP，VUCM 负责：

Update Campaign（更新活动）：将多个 ECU 的更新组织成一个统一的更新活动。
跨 ECU 依赖管理：如果 ECU-A 必须先于 ECU-B 更新，VUCM 会确保顺序正确。
驾驶员交互：通过 VehicleDriverApplicationInterface 通知驾驶员有可用更新，请求确认。
OTA 集成：与 OEM 的后端服务器通信，下载更新包。

OEM 云端
    │
    ▼ (OTA)
┌──────────┐
│   VUCM   │ ──── 协调更新活动 ────┐
└──────────┘                      │
    │                             │
    ▼                             ▼
┌──────────┐              ┌──────────┐
│ ECU-A    │              │ ECU-B    │
│ (UCM)    │              │ (UCM)    │
│ 更新感知  │              │ 更新规划  │
└──────────┘              └──────────┘

第12课诊断：Diagnostic Management

12.1 车辆诊断基础

车辆诊断是汽车开发、生产和售后维护中不可或缺的环节。最核心的诊断标准是 UDS（Unified Diagnostic Services, ISO 14229）。

UDS 定义了一系列诊断服务（以 SID 标识）：

SID	服务名称	用途
0x10	DiagnosticSessionControl	切换诊断会话（默认/编程/扩展）
0x11	ECUReset	复位 ECU
0x19	ReadDTCInformation	读取故障码（DTC）
0x22	ReadDataByIdentifier	读取数据标识符（DID）
0x2E	WriteDataByIdentifier	写入数据标识符
0x31	RoutineControl	执行诊断例程

在 AP 中，诊断通过 DoIP（Diagnostics over IP, ISO 13400-2） 传输，即 UDS 消息封装在 TCP/IP 报文中。

12.2 Diagnostic Management 的核心概念

Conversation（诊断会话）：一次诊断Tester和车辆之间的诊断连接。有类型区分：Normal（默认）、Programming（编程）、Extended（扩展）。

DTC（Diagnostic Trouble Code）：故障码，标识具体的故障。每个 DTC 有状态（pending、confirmed、active 等）。

Monitor（监控器）：监控某个条件，根据结果设置或清除 DTC。例如，监控电池电压是否在正常范围内。

Routine（例程）：可被诊断 Tester 触发的诊断操作，如"擦除内存"、"复位 ECU"。

DataIdentifier / DID（数据标识符）：命名的数据元素，可以被诊断 Tester 读写。如软件版本号、传感器校准值等。

12.3 SOVD：面向服务的诊断

AP 还支持 SOVD（Service-Oriented Vehicle Diagnostics），将传统的 UDS 诊断服务封装为 ara::com 服务。这使得诊断可以通过标准的 SOA 机制进行，也方便外部系统（如云端诊断平台）集成。

第13课部署视图：软件如何到达车上

13.1 部署层次结构

AP 的部署模型遵循清晰的层次结构：

Software Package（软件包）
  └── Software Cluster（软件簇）
        └── Process（进程）
              └── Executable（可执行文件）

13.2 三类软件包

在一台 Machine（ECU）上，软件包分为三类：

Platform Core Package（平台核心包）：

每台 Machine 有且仅有一个。
不可移除。
包含 OS、设备驱动、核心 Functional Cluster。
是 AP 的基础。

Platform Package（平台包）：

零个或多个。
包含额外的 Functional Cluster（如额外的加密算法、额外的通信协议）。
可以独立安装和移除。

Application Package（应用包）：

零个或多个。
包含 Adaptive Application。
可以独立安装、移除和更新。

13.3 Manifest 体系

AP 有四种 Manifest，各司其职：

Manifest 类型	描述内容	创建阶段
Application Design	应用的软件架构：服务接口、端口定义	应用设计阶段
Execution	进程的运行配置：启动参数、调度策略、资源限制	系统集成阶段
Service Instance	服务实例的网络配置：SOME/IP Service ID、Instance ID、端口号	系统集成阶段
Machine	整台 Machine 的完整软件配置：所有包、网络配置、时间域	车辆配置阶段

13.4 增量部署

AP 支持增量部署——在开发阶段，可以动态地启动、停止、更新应用，而不需要重新部署整个平台。这大大缩短了开发迭代周期。

在生产环境中，系统集成功能可以通过 Execution Manifest 来限制动态行为，以满足安全认证的要求：

预确定服务发现结果（禁止动态变化）
限制动态内存分配只在启动阶段
固定进程到特定 CPU 核心
只执行经过认证的代码

第14课通信协议全景

14.1 协议分层

AP 使用的通信协议覆盖了从数据链路层到应用层的完整协议栈：

应用层        │ SOME/IP | SOME/IP-SD | DLT | DoIP | SecOC | E2E | DDS | VISS | HTTP
─────────────┼─────────────────────────────────────────────────────────────────────
传输层        │         TCP          │         UDP          │
─────────────┼─────────────────────────────────────────────────────────────────────
网络层        │              IPv4 / IPv6 (IPsec)                           │
─────────────┼─────────────────────────────────────────────────────────────────────
数据链路层    │    Ethernet    │  MACsec   │  IEEE 1722 (AVB/TSN)  │  CAN XL
─────────────┼─────────────────────────────────────────────────────────────────────
物理层        │    车载以太网 (100BASE-T1, 1000BASE-T1)  │  CAN XL 物理层

14.2 核心协议详解

SOME/IP：AP 的核心中间件协议。定义了服务调用的消息格式（16 字节头部 + 载荷），支持请求/响应、事件/订阅、字段读写。运行在 UDP 或 TCP 上。

SOME/IP-SD：服务发现协议。使用 UDP 组播广播服务的可用性和事件订阅状态。是 SOA 动态性的基础。

DLT（Diagnostic Log and Trace）：AUTOSAR 标准的日志协议。支持日志级别过滤（Fatal/Error/Warn/Info/Debug/Verbose），日志消息可以跨网络传输到诊断工具。

DoIP：UDS 诊断消息的 IP 传输协议。将诊断 Tester 的请求通过 TCP 转发到目标 ECU。

SecOC：安全车载通信。为 PDU 级别的通信提供认证和新鲜度保护，防止消息被篡改或重放。

E2E（End-to-End Protection）：端到端保护。为安全相关的数据提供完整性校验，确保数据从传感器到执行器的整个传输路径中没有被损坏。

S2S（Signal-to-Service）：信号到服务的转换网关。在 AP 和 CP 之间架起桥梁——将 CP 的信号通信转换为 AP 的服务通信，反之亦然。

14.3 协议的 AUTOSAR 分类

AUTOSAR 对每个协议标注了来源类型：

类型	含义	示例
native	AUTOSAR 自己定义的协议	SOME/IP, SOME/IP-SD, S2S, SecOC, E2E
adopted	第三方协议，加了 AUTOSAR 扩展	TimeSync (基于 IEEE 802.1AS)
supported	原样使用的第三方协议	TCP, UDP, TLS, DHCP, DNS, DDS
external standard	recognized 的外部标准	HTTP, OAuth 2.0, VISS

第15课平台扩展机制：Callout、Callback 与 Plugin

15.1 为什么需要扩展

AP 标准定义了一套通用的中间件，但不同 OEM（车厂）有不同的需求。比如：

某个 OEM 想用自己的加密算法实现。
某个 OEM 想自定义诊断传输协议。
某个 OEM 想添加自定义的新鲜度值管理逻辑。

AP 提供了三种标准化的扩展机制，让 OEM 可以在不修改 Stack 源码的情况下定制平台行为。

15.2 Callout：静态扩展

Callout 是最简单的扩展方式。OEM 提供一个函数，平台在特定的调用点执行它。

特点：

静态注册：在链接阶段（link time）通过链接器注册，没有运行时开销。
唯一实现：每个调用点只能有一个实现。
无运行时可变性：一旦编译，不能更改。

适用场景：需要确定性的、不需要运行时变化的扩展。例如 Communication Management 中的 Freshness Value Manager。

// OEM 实现的 Callout 函数
namespace OemCallout {
    void FreshnessValueUpdate(uint32_t counterId) {
        // OEM 自定义的新鲜度值更新逻辑
    }
}

15.3 Callback：动态函数级扩展

Callback 允许在运行时动态注册功能。平台在特定事件发生时调用注册的回调函数。

特点：

动态注册：运行时通过 std::function 或 Skeleton 注册/注销。
可多个注册：同一个回调点可以注册多个处理函数。
运行时可变：可以随时注册和注销。

注意：注册之前和注销之后发生的事件会丢失。

适用场景：需要运行时灵活性的扩展。例如 Diagnostic Management 中的 DownloadService。

// 注册回调
ara::diag::RegisterDownloadCallback(
    [](const std::string& packagePath) -> ara::core::Result<void> {
        // OEM 自定义的下载处理逻辑
        return {};
    }
);

15.4 Plugin：动态类级扩展

Plugin 是最灵活的扩展方式。OEM 提供一个完整的类（带元信息），平台在运行时发现和加载。

特点：

动态注册：运行时注册，带元信息用于选择。
多实现可选：可以有多个 Plugin 实现，运行时根据配置选择。
三种配置方式：
1. Manifest 中指定完整类名
2. 从 Manifest 生成头文件，OEM 实现
3. Plugin 打包为动态链接库（.so/.dll）

适用场景：需要运行时选择实现的、复杂的功能扩展。例如 Cryptography 的 CryptoProvider Plugin、诊断的传输协议 Plugin。

// OEM 实现的 Plugin 类
class OemCryptoProvider : public ara::crypto::CryptoProviderSkeleton {
public:
    static ara::core::StringView GetID() { return "OemCryptoV2"; }

    // 实现所有密码学操作...
    ara::core::Result<void> Encrypt(...) override { ... }
    ara::core::Result<void> Decrypt(...) override { ... }
};

15.5 三种机制的对比

特性	Callout	Callback	Plugin
注册时机	链接时（静态）	运行时（动态）	运行时（动态）
粒度	函数	函数	类
多实现	否	可以	可以
元信息	无	无	有
运行时开销	无	低	中等
安全认证友好度	高	中	低（动态库）

第16课错误处理与可信平台

16.1 三类运行时错误

AP 将运行时问题分为三类，每类有不同的处理方式：

Error（错误）：API 函数无法完成其功能（如输入参数无效）。可恢复。应用必须通过 Result<T> 处理它。

auto result = SomeApi(invalidParam);
if (!result) {
    // 处理错误：重试、降级、通知用户
    HandleError(result.error());
}

Violation（违规）：内部 ARA Runtime 的前置/后置条件失败。不可恢复。通常由 API 误用或 Manifest 不一致引起。导致进程立即终止。

// 例如：在 StopOffer 之后还尝试调用 Offer
// 这是 API 误用，会触发 Violation → 进程被终止

Corruption（损坏）：系统资源损坏（栈/堆溢出、硬件内存错误如位翻转）。不可恢复。导致进程立即终止。通常由硬件故障引起。

这个分类的核心思想是：可恢复的问题让应用处理，不可恢复的问题让进程终止并由 PHM 重启。

16.2 可信平台（Trusted Platform）

AP 的安全基础是信任链（Chain of Trust）：

Trust Anchor (信任根，通常在 HSM 中)
    │ 验证
    ▼
Bootloader
    │ 验证
    ▼
OS Kernel
    │ 验证
    ▼
Execution Management
    │ 验证
    ▼
Adaptive Application 1
Adaptive Application 2
...

每一步在启动下一步之前，都验证其数字签名。这确保了：

完整性（Integrity）：代码在存储和传输过程中没有被篡改。
真实性（Authenticity）：代码来自合法的来源（OEM 或认证的供应商）。

Trust Anchor 是信任链的根，通常是一个存储在 HSM 或不可修改的安全存储中的公钥。它是整个信任体系的起点。

第17课综合实战：理解一个自动驾驶场景

17.1 场景描述

让我们用一个完整的场景来串联所有知识：一辆配备 L2+ 辅助驾驶功能的汽车，从启动到自动驾驶到泊车的完整流程。

17.2 系统启动

1. 驾驶员按下启动按钮
2. Bootloader 验证 OS 签名 → 启动 Linux
3. Linux 内核初始化 → 启动 Execution Management
4. EM 调用 Initialize()，启动所有 Daemon FC
5. EM 读取 Manifest，启动基础进程：
   - 感知进程（Perception）
   - 通信进程（Connectivity）
   - 诊断进程（Diagnostics）
   - 日志进程（Logger）
6. 所有进程报告 Running
7. EM 通知 SM：启动完成
8. Machine State → Running

17.3 切换到高速领航辅助（Navigate on Pilot）

1. 驾驶员在中控屏上激活"高速领航"功能
2. 领航辅助 App 通过 StateClient 向 SM 发送请求：
   - Function Group "NavigateOnPilot" → On
   - Function Group "NormalDriving" → Off
3. SM 验证请求，解决可能的冲突
4. SM 通知 EM：切换 Function Group State
5. EM 执行切换：
   a. 停止 NormalDriving 独有的进程
   b. 启动 NavigateOnPilot 需要的进程：
      - 高精度感知（LiDAR + Camera + Radar 融合）
      - 路径规划（Path Planning）
      - 行为决策（Behavior Decision）
      - 高精地图匹配（Map Matching）
   c. 通知 PHM 更新监控配置
   d. 通知 NM 确保车载以太网可用
6. 新进程启动，通过 ara::com 建立服务连接：
   - 感知进程提供 ObjectDetectionService
   - 规划进程订阅 ObjectDetectionService
   - 规划进程提供 PathPlanService
   - 决策进程订阅 PathPlanService 和 ObjectDetectionService
7. 所有新进程报告 Running
8. 系统进入高速领航辅助模式

17.4 运行中的通信

在高速领航模式下，各进程之间通过 ara::com 进行服务导向通信：

CameraService ──(Event: FrameReady)──→ PerceptionService
LiDARService  ──(Event: PointCloud)──→ PerceptionService
PerceptionService ──(Event: ObjectList)──→ PlanningService
                                           PlanningService
PlanningService ──(Method: GetPath)──→ BehaviorService
BehaviorService ──(Method: GetDecision)──→ ControlService
ControlService ──(Method: SetSteering/SetBrake)──→ CP Gateway

同时，Time Synchronization 确保所有传感器数据在时间上对齐。Persistency 记录行驶日志。Cryptography 保护通信安全。PHM 监控所有进程的健康状态。

17.5 故障处理

假设感知进程中的 LiDAR 处理线程出现故障：

1. PHM 的 Alive Supervision 检测到 Perception 进程超时未报告
2. PHM 评估故障严重性
3. 根据 Manifest 中配置的恢复策略：
   - 如果是轻微故障：PHM 通知 EM 重启 Perception 进程
   - 如果是严重故障：PHM 通知 SM 降级 Function Group State
4. SM 切换状态：
   - NavigateOnPilot → Off
   - NormalDriving → On
5. EM 停止自动驾驶相关进程，启动基础驾驶进程
6. 系统降级到人工驾驶模式
7. Diagnostic Management 记录故障 DTC
8. IDS Manager 记录安全事件（如果涉及）

17.6 到达目的地，切换泊车

1. 驾驶员到达目的地，按下"自动泊车"
2. App 请求 SM：
   - NavigateOnPilot → Off
   - Parking → On
3. EM 停止导航相关进程，启动泊车进程：
   - 超声波处理（Ultrasonic Processing）
   - 全景影像（Surround View）
   - 泊车规划（Parking Planning）
4. 泊车进程通过 Raw Data Stream 接收超声波和摄像头的高带宽数据流
5. 泊车完成后，Parking → Off，所有泊车进程停止

17.7 车辆关闭

1. 驾驶员熄火
2. SM 收到关闭触发
3. Machine State → Shutdown
4. SM 通知 EM：所有 Function Group → Off
5. EM 向所有进程发送 SIGTERM
6. 进程优雅退出（保存状态、释放资源）
7. 超时未退出的进程被 SIGKILL
8. 所有进程终止
9. EM 调用 Deinitialize()
10. 系统断电

附录 A 术语表

术语	英文	含义
自适应应用	Adaptive Application	运行在 AP 上的应用程序，每个应用是一个独立进程
功能簇	Functional Cluster (FC)	AP 的功能模块，如 Communication Management、Cryptography
服务导向架构	Service-Oriented Architecture (SOA)	以"服务"为核心组织软件的架构范式
服务接口	Service Interface	定义服务能提供的 Method、Event、Field
代理	Proxy	客户端桩，消费者通过它调用远程服务
骨架	Skeleton	服务端桩，提供者通过它实现服务逻辑
服务发现	Service Discovery (SD)	动态发现网络上可用服务的机制（SOME/IP-SD）
功能组	Function Group	功能的逻辑分组，通过状态切换控制进程运行
清单	Manifest	描述系统配置的静态文件
守护进程	Daemon	作为独立系统进程运行的 FC
非守护进程	Non-Daemon	以库形式链接到应用进程的 FC
信任链	Chain of Trust	从信任根开始的逐级签名验证机制
平台扩展	Platform Extension	OEM 定制平台功能的机制（Callout/Callback/Plugin）
被监控实体	Supervised Entity	PHM 监控的对象（进程、硬件等）
软件包	Software Package	部署的基本单元，包含一个或多个软件簇
端到端保护	End-to-End Protection (E2E)	确保数据在传输路径中完整性的机制

附录 B ara:: API 命名空间速查

命名空间	功能簇	主要用途
`ara::core`	Core	基础类型：Result, Future, Promise, ErrorCode, StringView
`ara::os`	OS Interface	OS 抽象：Thread, Mutex, Clock, SharedMemory
`ara::exec`	Execution Management	执行错误报告
`ara::sm`	State Management	状态请求和通知
`ara::log`	Log and Trace	日志记录
`ara::com`	Communication Management	服务导向通信
`ara::rtps`	Raw Data Stream	原始数据流传输
`ara::nm`	Network Management	网络可用性管理
`ara::ts`	Time Synchronization	时间同步
`ara::agw`	Automotive API Gateway	外部 API 网关
`ara::per`	Persistency	数据持久化
`ara::rper`	Remote Persistency	远程持久化
`ara::crypto`	Cryptography	密码学操作
`ara::ids`	IDS Manager	入侵检测
`ara::fw`	Firewall	防火墙
`ara::phm`	Platform Health Management	健康监控
`ara::sha`	Safe Hardware Acceleration	安全硬件加速
`ara::ucm`	UCM	单节点软件更新
`ara::vucm`	VUCM	整车软件更新
`ara::registry`	Registry	Manifest 访问
`ara::diag`	Diagnostic Management	诊断服务

附录 C 推荐学习路径

阶段一：建立全局认知（1-2 周）

先读本文教程，建立对 AP 整体架构的认知。然后阅读 AUTOSAR 官方的 Explanation of Adaptive Platform Software Architecture（即本文的参考文档），重点关注 Chapter 4（Overview and Goals）、Chapter 8（Solution Strategy）和 Chapter 9（Building Block View）的概述部分。

阶段二：深入核心 FC（2-4 周）

按以下顺序阅读各 FC 的 SWS（Software Specification）文档：

Core（AUTOSAR_AP_SWS_Core.pdf）—— 理解基础类型
Communication Management（AUTOSAR_AP_SWS_CommunicationManagement.pdf）—— 理解 ara::com
Execution Management（AUTOSAR_AP_SWS_ExecutionManagement.pdf）—— 理解进程生命周期
State Management（AUTOSAR_AP_SWS_StateManagement.pdf）—— 理解状态管理

阶段三：理解通信协议（2-3 周）

阅读 SOME/IP 协议规范（AUTOSAR_TP_SOMEIPProtocol.pdf），理解消息格式、传输映射、服务发现协议。然后阅读 ARA COM API 说明文档（AUTOSAR_EXP_ARAComAPI.pdf）。

阶段四：扩展知识（持续）

根据项目需要，选读其他 FC 的规范文档。安全方向重点看 Cryptography 和 PHM；诊断方向重点看 Diagnostic Management；OTA 方向重点看 UCM 和 VUCM。

参考资源：

AUTOSAR 官方文档下载：https://www.autosar.org/standards/ （选择 Adaptive Platform, R25-11）
CSDN 图解 AUTOSAR AP 系列：搜索"图解AUTOSAR_AP"
书籍：《基于AUTOSAR自适应平台的软件开发与应用》（同济大学出版社）

文档信息

本教程基于 AUTOSAR AP R25-11 官方文档 Explanation of Adaptive Platform Software Architecture（Document ID: 982）编写。

参考的官方文档还包括：AUTOSAR_AP_SWS_Core、AUTOSAR_AP_SWS_CommunicationManagement、AUTOSAR_AP_SWS_ExecutionManagement、AUTOSAR_AP_SWS_StateManagement 等功能簇规范文档。

posted @ 2026-07-16 17:53 无极至上阅读(62) 评论(0) 收藏举报

刷新页面返回顶部

抬头仰望星空，低头脚踏实地