【AUTOSAR入门】第一天：AUTOSAR AP 基础与架构

学习目标

1. 建立 AUTOSAR AP 的知识框架，理解其与 CP 的本质差异及核心价值。
2. 掌握 AP 的逻辑架构组成，明确功能集群的角色与协同关系。
3. 完成 RTA-VRTE Starter Kit 工具链部署，实现首个 AP 应用的配置与运行。

上午：理论核心

1. AUTOSAR AP 概述

1.1 为什么需要 AUTOSAR AP？

汽车电子的发展已从 “机械控制” 转向 “软件定义”，传统 ECU 架构面临三大核心挑战：

• 计算能力瓶颈：ADAS / 自动驾驶需实时处理 TB 级传感器数据（如激光雷达点云、摄像头图像），传统 8 位 / 16 位 MCU 无法满足高性能计算（HPC）需求。
• 软件灵活性不足：经典平台（CP）的静态配置无法支持 OTA 增量更新（如新增自动驾驶功能需重新刷写 ECU），难以应对用户对功能迭代的需求。
• 跨域协同困难：车辆控制（动力、底盘）、智能驾驶（感知、决策）、智能座舱（人机交互）需高频数据交互，传统信号级通信（如 CAN）带宽不足（CAN FD 最高 8Mbps，难以支持多传感器融合数据传输）。

AUTOSAR AP（Adaptive Platform）正是为解决这些问题而生，其设计目标可概括为：支持高性能计算、动态软件架构、跨域服务协同。

1.2 AP 与 CP 的核心差异（深度对比）

案例：某车企自动驾驶系统中，CP 负责控制制动执行器（硬实时、ASIL-D），AP 负责处理激光雷达数据并生成制动指令（软实时、ASIL-B），两者通过 SOME/IP 协议协同，既保证安全又满足算力需求。

1.3 计划动态性（Planned Dynamics）

AP 的 “动态性” 并非完全无约束，而是通过 “计划动态性” 平衡灵活性与可靠性，核心机制包括：

• 动态行为预定义：所有可能的动态操作（如服务启动 / 停止、任务调度切换）需在设计阶段定义规则（如 “仅允许在车辆熄火时更新自动驾驶算法”）。
• 资源边界限制：为每个应用分配最大 CPU / 内存配额（如 “导航服务最多占用 20% CPU”），避免资源争抢导致的性能波动。
• 静态基础配置：核心功能集群（如通信管理、安全监控）的基础参数（如 IP 地址、端口号）需静态配置，确保系统稳定性。

应用场景：OTA 更新时，AP 先验证新服务的资源需求是否在预定义范围内，若超出则拒绝更新，避免因内存不足导致系统崩溃。

2. AP 逻辑架构深度解析

2.1 架构设计原则

AP 的逻辑架构遵循 “功能聚合” 而非 “模块拆分”，核心原则包括：

• 功能集群化：将关联功能整合为 “功能集群”（Functional Cluster），而非单一模块（如 “执行管理” 包含任务调度、进程隔离、资源监控等功能），便于跨模块优化。
• 接口标准化：仅标准化 “平台与应用的接口”（确保应用可移植），不限制 “功能集群间的内部接口”（允许供应商自主优化，如通信管理与安全管理的交互可自定义）。
• 分层解耦：通过 “自适应基础” 与 “自适应服务” 两层架构，分离核心功能（如通信、执行）与扩展功能（如诊断、日志），支持按需扩展。

2.2 架构组成（AUTOSAR R19-11 版本）

AP 逻辑架构分为自适应基础（Adaptive Foundation） 和自适应服务（Adaptive Services），两者均由 “功能集群（Functional Cluster）” 组成（见图 2.2）。

2.2.1 自适应基础（Adaptive Foundation）

包含支持系统运行的核心功能集群，是所有 AP 应用的必备组件：

案例：当自动驾驶服务因传感器故障崩溃时，执行管理（EM）会根据状态管理（State Management）的规则，重启服务并临时降低算力需求（如关闭激光雷达，仅用摄像头数据），确保车辆可控。

2.2.2 自适应服务（Adaptive Services）

提供面向应用的高阶功能，按需集成（非必选），典型功能集群包括：

2.3 功能集群的协同关系

AP 的功能集群并非孤立工作，而是通过 “事件触发” 与 “数据交互” 形成闭环：

1. 服务调用流程：应用 A 调用 “摄像头图像服务” 时，先通过通信管理（CM）的服务发现功能找到服务地址，再通过执行管理（EM）分配 CPU 资源，最后由安全管理（Security Management）验证调用权限。
2. 故障处理流程：当通信管理（CM）检测到网络中断时，会向状态管理（State Management）发送事件，状态管理触发 “降级模式”，执行管理（EM）暂停非核心服务（如娱乐服务），优先保障自动驾驶通信。

3. AP 逻辑架构与 CP 的对比

3.1 架构设计理念差异

• CP：采用 “分层架构”，从下到上为硬件抽象层（MCAL）、基础软件层（BSW）、运行时环境（RTE）、应用层（SWC），每层接口严格定义（如 MCAL 的 SPI 驱动接口），确保不同供应商的模块可兼容（如 Vector 的 BSW 可搭配 EB 的 RTE）。
• AP：采用 “功能集群架构”，不强制定义集群间接口（如执行管理与通信管理的交互方式由供应商自主设计），允许供应商通过内部优化提升性能（如某厂商将服务发现功能集成到通信管理中，减少模块间调用耗时）。

3.2 灵活性与约束的平衡

• CP 的静态性：所有配置（任务调度表、信号路由）需在编译阶段确定，运行时不可修改（如 CAN 信号的波特率固定为 500kbps），优势是资源占用低（适合 8 位 MCU），劣势是无法应对动态需求（如新增传感器需重新配置 RTE）。
• AP 的动态性：支持运行时修改配置（如服务端口号、任务优先级），但需通过 “计划动态性” 约束（如仅允许在车辆静止时修改），优势是灵活性高（适合 OTA 更新），劣势是资源开销大（需 64 位 CPU 支持）。

案例：某车型的 CP 控制单元（如 ESP）需在出厂前完成所有配置，若后期想新增 “雨天制动防滑” 功能，需召回车辆重新刷写；而 AP 控制单元（如 ADU）可通过 OTA 远程新增 “雨天模式” 服务，无需召回。

下午：工具链入门

1. RTA-VRTE Starter Kit 部署

RTA-VRTE Starter Kit 是 Vector 公司推出的 AP 开发工具链，包含虚拟机环境、配置工具（ISOLAR-VRTE）、编译工具链，可快速搭建 AP 开发环境。

1.1 硬件与软件准备

• 硬件要求：

  • CPU：Intel i7 及以上（支持虚拟化技术 VT-x），4 核 8 线程以上（虚拟机需分配 2 核）。
  • 内存：16GB 及以上（主系统 8GB + 虚拟机 8GB）。
  • 硬盘：500GB SSD（虚拟机镜像约 100GB，预留编译空间）。
  • 网络：稳定的互联网连接（下载工具链与依赖包）。

• 软件要求：

  • 操作系统：Windows 10/11 专业版（支持 Hyper-V 或 VMware）。
  • 虚拟化软件：VMware Workstation Pro 16+（推荐，兼容性更好）或 Hyper-V。
  • 工具链版本：RTA-VRTE Starter Kit V3.9.0（包含 ISOLAR-VRTE 9.0、QNX 7.1、Linux Ubuntu 18.04）。

1.2 部署步骤（VMware 为例）

1. 下载工具链：从 Vector 官网获取 RTA-VRTE Starter Kit 安装包（约 20GB），包含两个虚拟机镜像：

   • Primary_Host_VM.vmdk（主虚拟机，含配置工具与编译环境）。
   • Secondary_Host_VM.vmdk（从虚拟机，用于分布式部署测试）。

2. 导入虚拟机：

   • 打开 VMware，点击 “文件→打开”，选择Primary_Host_VM.vmx，导入主虚拟机。
   • 重复操作导入从虚拟机，修改虚拟机名称为 “AP_Primary” 和 “AP_Secondary”。

3. 配置虚拟机资源：

   • 右键 “AP_Primary→设置”，分配 2 核 CPU、8GB 内存、100GB 硬盘空间。
   • 网络适配器选择 “桥接模式”（确保主 / 从虚拟机与主机在同一网段）。

4. 启动虚拟机：

   • 启动 “AP_Primary”，用户名 / 密码为 “autosar/ap1234”（默认）。
   • 登录后，验证是否安装成功：打开终端，输入rtavrte --version，若显示 “V3.9.0” 则成功。

1.3 常见问题与解决

• 虚拟机启动失败：检查是否开启 CPU 虚拟化（进入 BIOS 开启 VT-x），或关闭主机的 Hyper-V（与 VMware 冲突）。
• 网络连接失败：桥接模式下，若虚拟机无法联网，可改为 “NAT 模式”，通过主机共享网络。

4. ISOLAR-VRTE 基础操作

ISOLAR-VRTE 是 AP 的配置工具，用于定义服务接口、配置功能集群参数、生成应用代码，核心功能包括 ARXML 编辑、代码生成、部署管理。

4.1 界面组成

ISOLAR-VRTE 的界面分为 4 个区域：

• 项目浏览器：左侧面板，显示项目文件（如 ARXML、代码文件）。
• 编辑区：中间面板，用于编辑 ARXML 文件（服务接口定义）。
• 属性窗口：右侧面板，显示选中元素的属性（如服务端口号、数据类型）。
• 输出窗口：底部面板，显示代码生成日志与错误信息。

4.2 创建第一个服务接口（ARXML）

服务接口是 AP 应用通信的基础，通过 ARXML（AUTOSAR XML）文件定义，步骤如下：

1. 创建项目：

   • 点击 “File→New→AUTOSAR Project”，命名为 “FirstAPProject”，选择存储路径（如/home/autosar/projects）。
   • 选择 AUTOSAR 版本为 “R19-11”（主流版本），点击 “Finish”。

2. 定义数据类型：

   • 在项目浏览器中右键 “Data Types→New→Primitive Data Type”，命名为 “UInt32”，属性窗口中设置 “Base Type” 为 “uint32”（32 位无符号整数）。
   • 同理创建 “Float32”（浮点型），用于表示传感器数据（如温度、湿度）。

3. 定义服务接口：

   • 右键 “Service Interfaces→New→Service Interface”，命名为 “TemperatureService”。
   • 右键 “TemperatureService→New→Operation”，命名为 “GetTemperature”（获取温度的服务方法）。
   • 在属性窗口中，设置 “Return Type” 为 “Float32”（返回温度值），“Parameters” 为空（无输入参数）。

4. 保存 ARXML：点击 “Save”，生成TemperatureService.arxml文件，该文件定义了一个 “获取温度” 的服务接口，后续应用可通过调用该接口获取数据。

4.3 配置简单服务调用

1. 创建客户端与服务器应用：

   • 右键 “Applications→New→Application”，创建 “TemperatureServer”（服务器应用，提供温度服务）和 “TemperatureClient”（客户端应用，调用服务）。
   • 为 “TemperatureServer” 添加 “Provided Interface”（提供的服务），关联 “TemperatureService”。
   • 为 “TemperatureClient” 添加 “Required Interface”（需要的服务），关联 “TemperatureService”。

2. 配置通信参数：

   • 右键 “Communication→New→SOME/IP Configuration”，设置 “Protocol” 为 “UDP”，“Port” 为 “5000”（服务端口）。
   • 关联服务器应用与端口：将 “TemperatureServer” 的服务绑定到 5000 端口。

3. 生成代码：

   • 点击 “Build→Generate Code”，ISOLAR-VRTE 会根据 ARXML 生成 C++ 代码（如服务接口的头文件TemperatureService.h）。
   • 输出窗口显示 “Code generation successful” 则成功，代码存储在/home/autosar/projects/FirstAPProject/generated目录。

4.4 验证 RTE 通信

RTE（运行时环境）是 AP 应用与平台交互的桥梁，需验证服务调用是否正常：

1. 在终端中进入项目目录，执行编译脚本：

   bash

• cd /home/autosar/projects/FirstAPProject  
  ./build.sh  # 脚本会调用G++编译生成可执行文件  
  

• 启动服务器应用：

  bash

• ./bin/TemperatureServer  # 显示“Server started on port 5000”  
  

• 新打开一个终端，启动客户端应用：

  bash

1. ./bin/TemperatureClient  # 显示“Received temperature: 25.5°C”（模拟数据）  
   

   
   若客户端成功获取数据，说明 RTE 通信正常，服务接口配置正确。

下午实操练习：部署与验证

练习目标

在 RTA-VRTE Starter Kit 的虚拟 Target ECU 中部署 “温度服务” 应用，验证跨 ECU 通信。

练习步骤

1. 配置 Target ECU：

   • 打开 “AP_Primary” 虚拟机，启动 QNX 系统（开始菜单→QNX→Launch QNX Target）。
   • 虚拟 Target ECU 的 IP 地址为 “192.168.1.100”（默认），通过ping 192.168.1.100验证主机与 Target ECU 的连通性。

2. 部署服务器应用到 Target ECU：

   • 在 ISOLAR-VRTE 中，右键项目→“Deploy→Deploy to Target”，输入 Target ECU 的 IP（192.168.1.100）、用户名（root）、密码（qnx）。
   • 选择部署 “TemperatureServer”，点击 “OK”，输出窗口显示 “Deployment successful”。

3. 在 Target ECU 上启动服务器：

   • 通过 SSH 登录 Target ECU：ssh root@192.168.1.100，密码 “qnx”。
   • 执行/home/root/TemperatureServer，启动服务。

4. 在主机上启动客户端：

   • 主机终端中执行./bin/TemperatureClient 192.168.1.100（指定服务器 IP），若显示 “Received temperature: 25.5°C”，则跨 ECU 通信成功。

总结与答疑

核心知识点回顾

1. AP 的核心价值：支持高性能计算、动态软件架构、跨域服务协同，填补 CP 与信息娱乐系统的空白。
2. 逻辑架构：由自适应基础（执行管理、通信管理等）与自适应服务（诊断、日志等）组成，功能集群通过事件与数据协同。
3. 工具链实操：通过 ISOLAR-VRTE 定义服务接口，在 RTA-VRTE 的虚拟环境中实现服务调用，验证 AP 的通信机制。

常见问题解答

1. Q：AP 是否会替代 CP？
   A：不会。AP 与 CP 是互补关系：CP 负责低资源、高安全的核心控制（如制动、转向），AP 负责高算力、动态更新的智能功能（如自动驾驶、座舱交互），两者通过 SOME/IP 协议协同。

2. Q：ARXML 文件的作用是什么？
   A：ARXML 是 AUTOSAR 的标准配置文件，用于描述服务接口、功能集群参数、应用部署信息等，是工具链（如 ISOLAR-VRTE）生成代码的依据，确保不同厂商的 AP 平台可兼容。

3. Q：虚拟 Target ECU 与真实硬件有何区别？
   A：虚拟 Target ECU（如 QNX 虚拟机）用于前期开发与测试，可模拟多核 CPU、网络环境，但无法完全替代真实硬件（如真实 ECU 的温度、电磁干扰特性），后期需在真实域控制器上验证性能。

课后作业

1. 对比 AP 与 CP 在 “OTA 更新” 场景下的实现差异，写出不少于 300 字的分析。
2. 使用 ISOLAR-VRTE 创建一个 “湿度服务” 接口（返回湿度值），并完成客户端与服务器的代码生成及部署。