浅谈汽车电子（一）初识AutoSAR

前言

  AutoSAR(Automotive Open System Architecture)是一种汽车行业开放系统架构，旨在简化汽车软件开发，通过分层架构和标准化接口降低复杂性。文章介绍了AutoSAR的原理、架构组件和关键工具链，强调了其在提高开发效率和降低成本中的作用。

一、AutoSAR的引入

  AUTOSAR(即汽车开放系统架构)是一家由汽车电子、半导体和软件行业的全球各家汽车制造商、供应商、服务提供商等公司组成的全球开发合作伙伴组，成立于2003年7月，其核心成员由德国宝马、戴姆勒及博世等9家公司构成；并联合推出了一个开放化的、标准化的汽车嵌入式系统软件架构规范。其核心在于分成架构的高度的抽象对汽车嵌入式系统的软件和硬件系统进行解耦，大大提高了独立性，降低了他们之间的耦合性。

二、AutoSAR的架构

  在AUTOSAR中分为两大架构：CP（Classic Platform）和AP（Adaptive Platform）。CP面向传统嵌入式ECU（如发动机控制），采用严格分层（应用层→RTE→BSW→硬件）；而AP则主要面向高性能计算（如自动驾驶），采用服务导向（SOA），分层更灵活。

注：CP AUTOSAR虽然可以支持SOME/IP，但是CP AUTOSAR中SOME/IP只不过是把Sender-Receiver的CAN通信转换成了Client-Server的以太网通信，整个通信链路仍是静态配置的，并不是真正的面向服务的通信。

2.1 CP的分层

  在CP架构中，系统软件采用严格的分层设计模式，各层之间通过标准化的接口进行交互，每一层只能调用下一层的接口，并为其上一层提供接口。这种分层架构不仅提高了软件的可重用性和可移植性，还便于不同厂商开发的软件模块集成。通常情况下，信息的传输路径是：应用层（SWC）→ RTE（实际路由） → BSW（基础软件） → 硬件

2.1.1 应用层（Application Software Layer）

• 位于AUTOSAR架构最上层，负责实现具体的车辆功能和控制逻辑
• 由多个独立的软件组件（Software Component，SWC）构成，每个组件通过标准化的虚拟功能总线（VFB）端口（Port）进行通信
• 采用面向服务的架构（SOA）设计，支持组件复用和灵活配置
• 典型组件示例：
  • 发动机控制组件：包含喷油控制（燃油喷射量计算、喷射正时）、点火控制（点火提前角计算）、爆震检测等子模块
  • 变速箱控制组件：包含换挡逻辑、离合器控制、档位识别等功能
  • 每个SWC通过Runnable实体实现具体功能，可配置触发条件（时间触发/事件触发）

2.1.2 运行时环境（Runtime Environment，RTE）

• 作为应用层和基础软件层之间的中间件，实现虚拟功能总线到实际ECU总线的映射
• 提供标准化的通信机制：
  • 信号路由：实现SWC之间的信号传递
  • 数据转换：处理不同字节序、信号解析等
  • 模式管理：协调组件的工作模式切换
• 负责管理SWC之间的交互和调度：
  • 实现组件间接口（Sender-Receiver接口、Client-Server接口）
  • 处理Runnable的调度和执行
• 典型应用场景：
  • ABS组件需要获取轮速信号时，通过RTE从传感器接口组件请求数据
  • 当发动机温度过高时，通过RTE向仪表盘组件发送告警信号

2.1.3 基础软件层（Basic Software Layer，BSW）

• 采用模块化设计，进一步细分为多个服务子层：
  • 服务层（Services）：
    • 操作系统：符合OSEK/VDX标准，提供任务管理、中断处理等功能
    • 通信服务：CAN/LIN/FlexRay等总线通信协议栈
    • 存储服务：EEPROM/Flash访问管理
    • 诊断服务：UDS/OBD诊断协议实现
  • ECU抽象层（ECU Abstraction）：
    • 提供统一的ECU硬件接口，如GPIO抽象、ADC抽象
    • 示例：将不同厂商的CAN控制器差异进行封装
  • 微控制器抽象层（MCAL）：
    • 直接操作硬件的驱动，如PWM驱动、ADC驱动
    • 与具体MCU型号强相关
    • 通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作
• 提供统一的硬件访问接口，包括：
  • 通信接口：CAN收发器控制、LIN通信
  • IO接口：数字输入/输出、模拟量采集
  • 定时器接口：PWM生成、输入捕获

2.1.4 微控制器（Microcontroller）

• 硬件执行平台，通常采用汽车级芯片（如Infineon Aurix、NXP S32等）
• 主要组成部分：
  • 处理器核心：多核架构（锁步核等安全设计）
  • 存储单元：Flash（程序存储）、RAM（运行内存）、EEPROM（参数存储）
  • 外设资源：
    • 通信接口：CAN、LIN、FlexRay控制器
    • 定时器单元：PWM生成、输入捕获
    • 模拟模块：ADC、DAC
  • 安全机制：看门狗、内存保护单元（MPU）
• 典型特性：
  • 工作温度范围：-40°C ~ +125°C
  • 符合ISO 26262功能安全标准
  • 支持AUTOSAR标准的MCAL驱动

  你可能看到这里已经懵了，我们可以通过linux框架下类别一下：

2.1.5 VFB机制

  VFB（虚拟功能总线） 是 AUTOSAR 架构中的核心设计概念，用于在早期开发阶段解耦软件组件与硬件通信，实现“硬件无关”的交互。VFB是一种标准化的虚拟通信接口，其不是运行时实体，生成代码后会被 RTE 替代，故而不存在独立的“VFB 模块”。

  这里以车灯控制 SWC 与车身控制器 SWC 通信为例：

• 设计阶段：定义 VFB 接口 LightControl_Status（Sender-Receiver 接口），无需指定通信方式（CAN/LIN）

• 部署阶段：由系统配置工具（如 DaVinci Configurator）决定：

  • 两个 SWC 在同一 ECU → RTE 生成内部函数调用。
  • 在不同 ECU → RTE 生成 CAN 报文（ID 0x200）

• 运行时：RTE 自动选择通信路径，对 SWC 透明

2.2 AP的分层

  AP 的完整架构包含Adaptive Applications、 ARA（运行时环境）、Functional Clusters和OS & Hardware（底层支撑），其中以 ARA（AUTOSAR Runtime for Adaptive Applications）为核心，其标准化功能分为 Foundation（基础服务）和 Services（扩展服务）两类。"

2.2.1 应用层

  应用需通过 ARA 接口访问底层服务（如 ara::com），禁止直接调用 OS API（如 socket()），除非明确允许（POSIX 子集）。此外，动态加载需遵循 Manifest 文件（定义依赖关系和资源权限）。

• 功能：
  • 运行高性能计算任务（如 AI 推理、传感器融合）
  • 支持动态加载/卸载（无需重启 ECU）
• 示例：
  • 自动驾驶的感知模块（激光雷达点云处理）
  • 智能座舱的语音识别服务

2.2.2 ARA（Adaptive Runtime Environment）

  ARA 是 AP 的核心，提供标准化的服务接口，类似于 CP 的 RTE，但更灵活。RTE 是静态生成的信号路由层，ARA 是动态服务化运行。

• ara::com（通信服务）：支持 SOME/IP、DDS（面向服务的通信）。
• ara::exec（执行管理）： 控制应用的 动/停止，管理生命周期。
• ara::diag（诊断服务）：提供 UDS over SOME/IP 诊断能力。

2.2.3 服务层

  提供基础功能，类似于 CP 的 BSW，但以 服务化方式提供，这里也是分为两大核心：

• Foundation（基础功能集群）：必选功能，如 ara::com、ara::exec、ara::diag。
• Services（可选扩展服务）：如 ara::em（执行管理）、ara::per（持久化存储）。

2.2.4 操作系统层（OS & Hypervisor）

• POSIX 兼容操作系统： Linux和QNX
• Hypervisor 支持（可选组件）：广泛用于混合关键性系统

2.2.5 硬件抽象层（HAL）

  不同于CP 的 MCAL，但不同之处在于MCAL是静态配置的寄存器级驱动， AP 的 HAL 更接近 Linux 设备驱动（如 ioctl 接口）。