AUTOSAR 学习笔记(一)：架构与整体概述

1. AUTOSAR 是什么

AUTOSAR（AUTomotive Open System ARchitecture，汽车开放系统架构） 是一个由汽车制造商、零部件供应商、半导体厂商和软件工具商共同建立的开放、标准化的汽车软件架构联盟。其核心目标是：

  • 在 ECUs 之间实现软件的模块化和可复用；
  • 实现软硬件解耦（应用层软件与底层硬件无关）；
  • 提高软件开发效率，降低成本；
  • 提高软件质量和可靠性。

核心成员

  • 核心成员（Core Partners）：BMW、VW、Daimler、Bosch、Continental、Toyota、Ford 等
  • 国内常见的 AUTOSAR 工具提供商：Vector、Elektrobit（EB）、ETAS、Mentor/Siemens、东软睿驰、华玉通软、经纬恒润 等

2. AUTOSAR 版本演进

版本 特点
AUTOSAR 3.x（Classic） 早期的标准化版本
AUTOSAR 4.x（Classic） 目前主流，功能完善（如 CSM, DET 等）
AUTOSAR Classic Platform（CP） 面向传统 MCU（AUTOSAR CP），硬实时、AUTOSAR 组件化
AUTOSAR Adaptive Platform（AP） 面向高性能处理器（Linux/AUTOSAR 自适应/SoC），动态、基于 POSIX/服务化

本文系列以 AUTOSAR Classic（CP） 为主，即面向单片机实时 ECU 的场景。

3. 分层架构模型

┌────────────────────────────────────────────────┐
│              Application Layer (应用软件层)        │
│   SWC (Software Component)  传感器/作动器组件       │
├────────────────────────────────────────────────┤
│      Runtime Environment (RTE) 运行时环境         │
├───────────────┬─────────────────────────────────┤
│  Service Layer│  ...MCAL 之间                 │
│    (服务层)     │                                │
│..................... │             │
├─  ECU 抽象层 (ECU Abstraction) ----┤
├─   MCAL (微控制器抽象层)  --------  │
├── 驱动层Drivers -----------------─┤
│  MicIntController Hardware         │
└────────────────────────────────────┘

按垂直方向（经典 BSW 三层）：

  1. 服务层（Service Layer）：OS、网络管理、诊断服务、通信服务、内存服务等——提供与硬件无关的系统级服务。
  2. ECU 抽象层（ECU Abstraction Layer）：对 MCU 外设封装，隐藏 MCU 硬件细节（如 Dio 信号抽象、Fls 抽象、Port 抽象）。包括 COM/CAN 抽象等。
  3. MCAL（Microcontroller Abstraction Layer）：直接操作寄存器/MCU 外设，最靠近硬件，不由 MCAL E2E。

按横向（独立于硬件/依赖硬件）：

  • Application Layer（应用软件）
  • RTE — 应用与 BSW 之间的通信枢纽，生成 AUTOSAR COM 等
  • BSW（Basic Software） 三层：服务层、ECU 抽象层、MCAL

4. 重要概念

4.1 Software Components（SWC）

应用层由多个 SWC 组成，每个 SWC 是功能封装的单元（如仪表软件 SWC、空调 SWC）。SWC 之间通过 Port（端口） 相连，通过 Runnable（可运行实体）实现功能。

  • Port：P-Port（提供者）、R-Port（请求者）；PRSPort（需求/提供）。
    • 数据传递：Sender-Receiver（发送/接收）接口
    • 请求/响应：Client-Server（客户端/服务器）接口
  • Runnable（可运行实体）：SWC 内的一段代码，由 RTE 调度（周期调用、事件触发等）。
  • Connector：定义 SWC 之间的连接（数据映射）。

4.2 模块（Module）

每个 BSW 是一个模块，例如：

  • 通信模块：Can、CanIf、CanTp、CanNm、Fr、Lin、Eth、Com、PduR
  • 诊断模块：Dcm、Dem、Fim
  • 内存模块：Fee、Fl、NvM、Ea、MemAcc
  • 系统模块：EcuM、ComM、WdgM、Det、Dcm、Os、StbM

5. AUTOSAR 开发流程

AUTOSAR 采用 V 模型 开发流程，覆盖从系统设计到软件组件开发到集成与测试：

需求分析 -> 系统设计 -> 软件组件设计 -> 代码生成（RTE/BSW）-> 集成
  <---- 验证 <---- 单元/<插入 测试 <----- 测试

关键步骤：

  1. 系统/网络拓扑设计：定义 ECU 数量、总线（CAN/LIN/FlexRay/Ethernet）、信号与车内互联。
  2. 接口/数据设计：定义数据类型、Port、接口（在工具中 ARXML 描述）。
  3. SWC 建模：构建 SWC、端口、Runnables、事件等。
  4. ECU 提取：从系统模型中抽取单个 ECU 的配置视图（ECU Extract）。
  5. BSW 配置：配置各 BSW 模块（通信、诊断、内存、系统服务）。
  6. 生成代码：工具生成 RTE、COM、PT 等代码。
  7. 集成与测试：将 SWC 和 BSW 编译连接，集成测试。

5. 配置文件（ARXML）

  • AUTOSAR 的配置文件以 ARXML（Automotive XML 格式）存储。
  • SYSTEM/ECU extract 层：系统级配置（ECU 提取）。
  • 常用工具：Vector DaVinci Configurator、EB tresos、Dorado、Artop 等。

6. AUTOSAR 具备的优势

  • 标准化：不同工具箱之间互操作，降低软件集成难度。
  • 复用性：软件组件可在不同平台复用（ECU 对外只看接口）。
  • 可维护性：分层清晰，模块边界明确，便于维修和管理。
  • 交换性：接口统一，不同 ECM 厂商可替换（供应商之间的软件互换）。

7. 常见问题

AUTOSAR 与中小客户的关系：AUTOSAR 解决复杂度、可移植性和集成标准化的问题，对大型 OEM 和 Tier1 有巨大价值；对小型项目可能略显复杂，但仍是趋势。

AUTOSAR 4.x vs. Adaptive：CP 适合中小型 MCU 实时场景（ADAS 中转向、发动机控制等）；AP 适合高性能 SoC（智能驾驶、自动驾驶域）。很多新型平台都会并行。

自动生成 vs 手动：大多数 BSW 和 RTE 由工具生成，应用层 SWC 开发以手写为主，接口服从 AUTOSAR 规范。

（本页为 AUTOSAR 系列第 1 篇：整体概述，后续将深入通信栈、诊断、内存、RTE 等。）

posted @ 2026-08-02 19:18  mengjie_9  阅读(1)  评论(0)    收藏  举报