feifei.xu/autosar_standard_spec_v4.4
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6f293acbf70ce755cc397f46142c440f608e4284
autosar_standard_spec_v4.4/General/AUTOSAR_EXP_LayeredSoftwareArchitecture.md
T

51 KiB
Raw Blame History

分层软件架构

AUTOSAR CP Release 4.4.0

原文：Layered Software Architecture（文档 ID 053）

翻译状态：已完成 v1

对应原文 PDF：General/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf

翻译日期：Step 3 - P0 批量翻译

文档标识

字段 值
文档标题 分层软件架构（Layered Software Architecture）
文档所有者 AUTOSAR
文档责任人 AUTOSAR
文档标识号 053
文档状态 正式版（Final）
所属标准 Classic Platform
所属版本 4.4.0

文档变更历史

日期 版本 变更人 变更说明
2018-10-31 4.4.0 AUTOSAR Release Management 采纳 LIN 从节点支持，移除 LinNm；新概念：密钥管理、MCAL 多核分布初稿；编辑性变更
2017-12-08 4.3.1 AUTOSAR Release Management 编辑性变更
2016-11-30 4.3.0 AUTOSAR Release Management 引入 4.3 新概念：加密栈、车到车通信（V2X）、SOME/IP 传输协议、DLT 重新设计；移除过时的 Dbg 模块；编辑性变更
2015-07-31 4.2.2 AUTOSAR Release Management 编辑性变更
2014-10-31 4.2.1 AUTOSAR Release Management 引入 4.2 新概念：交换机配置、发送者-接收者序列化、CAN-FD、大数据 COM、E2E 扩展、全局时间同步、支持构建后 ECU 配置、车载安全通信（SecOC）、ASIL/QM 保护；引入新的错误分类；编辑性变更
2014-03-31 4.1.3 AUTOSAR Release Management 编辑性变更
2013-03-15 4.1.1 AUTOSAR Administration 澄清 CAN/LIN 从节点的部分网络支持；新的以太网栈扩展；将加密服务管理器添加到系统服务；修订 J1939 的表示并添加新的 J1939 模块；添加新的能量管理概念："Pretended Networking"、"ECU Degradation"；添加新模块："Output Compare Unit Driver" 和 "Time Service"；更改生产错误的处理；修复各种排版和布局问题
2011-12-22 4.0.3 AUTOSAR Administration 在幻灯片 "ki890" 上为 R3 兼容性 FlexRay 传输层 FrArTp 添加说明；为能量管理和部分网络添加概述章节；更正有关 DEM 符号生成的示例；修复小排版问题；澄清 AUTOSAR-ECU 术语（幻灯片 "94jt1"）；更正 EcuM 的 CDD 访问描述（幻灯片 "11123"）
2009-12-18 4.0.1 AUTOSAR Administration 在幻灯片 "94juq" 上添加有关系统基础芯片支持的说明；澄清 DBG 和 DLT 文本（幻灯片 "3edfg"）；更正 DBG 描述（幻灯片 "11231"）
2010-02-02 3.1.4 AUTOSAR Administration 文档已重新结构化。现在有 3 个主要部分：架构、配置、集成和运行时方面；整个内容已更新以反映 R 4.0 规范的内容；已添加 R4.0 中新引入或大幅扩展的主题。例如：多核系统、分区、模式管理、错误处理、报告和诊断、调试、测量和标定、功能安全等；法律免责声明修订
2008-08-13 3.1.1 AUTOSAR Administration 法律免责声明修订
2007-12-21 3.0.1 AUTOSAR Administration 基于新的唤醒/启动概念的更新；构建后时间配置的详细说明；LIN 栈描述的"精简"；ICC2 图；扩展文档元信息；进行小的布局调整
2007-01-24 2.1.15 AUTOSAR Administration 添加 ICC 集群；协调文档内容；法律免责声明修订；添加发布说明；修订"用户建议"；添加"修订信息"
2006-11-28 2.1.1 AUTOSAR Administration 重新处理：错误处理；调度机制；根据 R2.0 中的架构决策进行更多更新
2006-01-02 1.0.1 AUTOSAR Administration 更正版本发布
2005-05-31 1.0.0 AUTOSAR Administration 初始发布

目录

  1. 架构
  2. 配置
  3. 集成和运行时方面

介绍

目的和输入

本文档目的

分层软件架构描述了 AUTOSAR 的软件架构：

  • 它以自顶向下的方法描述了 AUTOSAR 软件的分层结构
  • 将基础软件模块映射到软件层
  • 并展示它们之间的关系

本文档不包含需求，仅作信息性参考。所提供的示例并不打算在所有方面都完整。

本文档重点关注概念性分层软件架构的静态视图：

  • 它未规定具有详细静态和动态接口描述的结构化软件架构（设计）
    • 这些信息包含在基础软件模块本身的规范中

输入

本文档基于 AUTOSAR 的规范和需求文档。

范围和可扩展性

AUTOSAR 的应用范围

AUTOSAR 专用于汽车 ECU。此类 ECU 具有以下特性：

  • 与硬件（传感器和执行器）的强交互
  • 连接到车辆网络，如 CAN、LIN、FlexRay 或以太网
  • 微控制器（通常为 16 位或 32 位），具有有限的计算能力和内存资源（与企业级解决方案相比）
  • 实时系统
  • 从内部或外部闪存执行程序

注：在 AUTOSAR 概念中，ECU 指的是一个微控制器加上其外设和相应的软件/配置。机械设计不在 AUTOSAR 的范围内。这意味着如果在一个外壳中布置了多个微控制器，则每个微控制器都需要其自己的 AUTOSAR-ECU 实例描述。

AUTOSAR 可扩展性

AUTOSAR 软件架构是一种通用方法：

  • 标准模块可以在功能上扩展，同时仍保持合规性
    • 但是，它们的配置必须考虑在自动基础软件配置过程中
  • 非标准模块可以作为复杂驱动程序集成到基于 AUTOSAR 的系统中
  • 不能再添加其他层

1 架构

1.1 软件层概述

顶层视图

AUTOSAR 架构在最高抽象级别上区分三个软件层：应用层、运行时环境和基础软件，它们在微控制器上运行。

  • 应用层（Application Layer）
  • 运行时环境（Runtime Environment, RTE）
  • 基础软件（Basic Software, BSW）
  • 微控制器（Microcontroller）

粗略视图

AUTOSAR 基础软件进一步分为以下层：服务层、ECU 抽象层、微控制器抽象层和复杂驱动。

  • 应用层（Application Layer）
  • 运行时环境（Runtime Environment, RTE）
  • 服务层（Services Layer）
  • ECU 抽象层（ECU Abstraction Layer）
  • 复杂驱动（Complex Drivers）
  • 微控制器抽象层（Microcontroller Abstraction Layer）
  • 微控制器（Microcontroller）

详细视图

基础软件层进一步划分为功能组。服务的示例有系统、内存和通信服务。

  • 应用层（Application Layer）
  • 运行时环境（Runtime Environment, RTE）
  • 服务层细分为：
    • 系统服务（System Services）
    • 内存服务（Memory Services）
    • 加密服务（Crypto Services）
    • 板外通信服务（Off-board Communication Services）
    • 通信服务（Communication Services）
    • I/O 硬件抽象（I/O Hardware Abstraction）
    • 复杂驱动（Complex Drivers）
  • 板载设备抽象（Onboard Device Abstraction）
  • 内存硬件抽象（Memory Hardware Abstraction）
  • 加密硬件抽象（Crypto Hardware Abstraction）
  • 无线通信硬件抽象（Wireless Communication HW Abstraction）
  • 通信硬件抽象（Communication Hardware Abstraction）
  • 微控制器驱动（Microcontroller Drivers）
  • 内存驱动（Memory Drivers）
  • 加密驱动（Crypto Drivers）
  • 无线通信驱动（Wireless Communication Drivers）
  • 通信驱动（Communication Drivers）
  • I/O 驱动（I/O Drivers）
  • 微控制器（Microcontroller）

微控制器抽象层

微控制器抽象层是基础软件的最低软件层。它包含内部驱动，这些是直接访问 µC 和内部外设的软件模块。

任务：使更高软件层独立于 µC。

属性：

  • 实现：依赖于 µC
  • 上层接口：标准化且独立于 µC

ECU 抽象层

ECU 抽象层将微控制器抽象层的驱动接口化。它还包含外部设备的驱动。它为访问外设和设备提供 API，无论它们的位置（µC 内部/外部）以及它们与 µC（端口引脚、接口类型）的连接。

任务：使更高软件层独立于 ECU 硬件布局。

属性：

  • 实现：独立于 µC，依赖于 ECU 硬件
  • 上层接口：独立于 µC 和 ECU 硬件

复杂驱动

复杂驱动层从硬件跨越到 RTE。

任务：提供集成特殊目的功能的可能性，例如设备的驱动：

  • AUTOSAR 中未规定
  • 具有非常高的时序约束
  • 用于迁移目的等

属性：

  • 实现：可能依赖于应用、µC 和 ECU 硬件
  • 上层接口：可能依赖于应用、µC 和 ECU 硬件

服务层

服务层是基础软件的最高层，它对应用软件也很重要：I/O 信号的访问由 ECU 抽象层覆盖，而服务层提供：

  • 操作系统功能
  • 车辆网络通信和管理服务
  • 内存服务（NVRAM 管理）
  • 诊断服务（包括 UDS 通信、错误存储和故障处理）
  • ECU 状态管理、模式管理
  • 逻辑和时间程序流监控（Wdg 管理器）

任务：为应用、RTE 和基础软件模块提供基本服务。

属性：

  • 实现：大多数独立于 µC 和 ECU 硬件
  • 上层接口：独立于 µC 和 ECU 硬件

AUTOSAR 运行时环境（RTE）

RTE 是为应用软件（AUTOSAR 软件组件和/或 AUTOSAR 传感器/执行器组件）提供通信服务的层。在 RTE 之上，软件架构风格从"分层"变为"组件样式"。

AUTOSAR 软件组件通过 RTE 与其他组件（ECU 内和/或 ECU 间）和/或服务通信。

任务：使 AUTOSAR 软件组件独立于到特定 ECU 的映射。

属性：

  • 实现：ECU 和应用特定（为每个 ECU 单独生成）
  • 上层接口：完全独立于 ECU

服务类型介绍

基础软件可细分为以下类型的服务：

  • 输入/输出（I/O）：传感器、执行器和 ECU 板载外设的标准化访问
  • 内存：内部/外部内存（非易失性内存）的标准化访问
  • 加密（Crypto）：加密原语的标准化访问，包括内部/外部硬件加速器
  • 通信（Communication）：车辆网络系统、ECU 板载通信系统和 ECU 内部 SW 的标准化访问
  • 板外通信（Off-board Communication）：车到车通信（V2X）、车内无线网络系统、ECU 板外通信系统的标准化访问
  • 系统（System）：提供可标准化的（操作系统、定时器、错误存储）和 ECU 特定（ECU 状态管理、看门狗管理器）服务和库函数

基础软件模块类型介绍

驱动（内部）

驱动包含控制访问内部或外部设备的功能。

内部设备位于微控制器内部。内部设备的示例包括：

  • 内部 EEPROM
  • 内部 CAN 控制器
  • 内部 ADC

内部设备的驱动称为内部驱动，位于微控制器抽象层中。

驱动（外部）

外部设备位于微控制器外部的 ECU 硬件上。外部设备的示例包括：

  • 外部 EEPROM
  • 外部看门狗
  • 外部闪存

外部设备的驱动称为外部驱动，位于 ECU 抽象层中。它通过微控制器抽象层的驱动访问外部设备。通过这种方式，AUTOSAR 也支持集成在系统基础芯片（SBC）中的组件，如收发器和看门狗。

示例：具有 SPI 接口的外部 EEPROM 的驱动通过 SPI 总线的处理程序/驱动访问外部 EEPROM。

例外：内存映射外部设备（例如外部闪存）的驱动可以直接访问微控制器。这些外部驱动位于微控制器抽象层中，因为它们依赖于微控制器。

接口

接口（接口模块）包含从架构上位于其下方的模块中抽象的功能。例如，从特定设备的硬件实现中抽象的接口模块。它提供通用 API 来访问特定类型的设备，与该类型现有设备的数量无关，并且与不同设备的硬件实现无关。

接口不更改数据的内容。

通常，接口位于 ECU 抽象层中。

示例：CAN 通信系统的接口提供通用 API 来访问 CAN 通信网络，与 ECU 内的 CAN 控制器数量无关，并且与硬件实现无关（片上、片外）。

处理程序（Handler）

处理程序是一种特定的接口，它控制一个或多个客户端对一个或多个驱动的并发、多个和异步访问。即它执行缓冲、排队、仲裁、多路复用。

处理程序不更改数据的内容。

处理程序功能通常合并在驱动或接口中（例如 SPIHandlerDriver、ADC 驱动）。

管理器（Manager）

管理器为多个客户端提供特定服务。在所有纯处理程序功能不足以从多个客户端抽象的情况下，都需要管理器。

除了处理程序功能外，管理器还可以评估和更改或调整数据的内容。

通常，管理器位于服务层中。

示例：NVRAM 管理器管理对内部和/或外部内存设备（如闪存和 EEPROM 内存）的并发访问。它还执行分布式和可靠的数据存储、数据检查、默认值提供等。

库介绍

库是用于相关目的的函数集合。

库：

  • 可以由 BSW 模块（包括 RTE）、SW-C、库或集成代码调用
  • 在调用方的上下文中在同一保护环境中运行
  • 只能调用库
  • 是可重入的
  • 没有内部状态
  • 不需要任何初始化
  • 是同步的，即它们没有等待点

AUTOSAR 中规定的以下库：

  • 定点数学
  • 浮点数学
  • 定点数据插值
  • 浮点数据插值
  • 位处理
  • E2E 通信
  • CRC 计算
  • 扩展功能（如 64 位计算、滤波等）

1.2 软件层内容

微控制器抽象层

µC 抽象层由以下模块组组成：

  • 微控制器驱动：内部外设的驱动（例如看门狗、通用定时器）；直接访问 µC 的功能（例如核心测试）
  • 通信驱动：ECU 板载（例如 SPI）和车辆通信（例如 CAN）的驱动；OSI 层：数据链路层的一部分
  • 内存驱动：片上内存设备（例如内部闪存、内部 EEPROM）和内存映射外部内存设备（例如外部闪存）的驱动
  • I/O 驱动：模拟和数字 I/O 的驱动（例如 ADC、PWM、DIO）
  • 加密驱动：片上加密设备（如 SHE 或 HSM）的驱动
  • 无线通信驱动：无线网络系统（车内或板外通信）的驱动

微控制器驱动包括：WDT 驱动、GPT 驱动、Core Test、RAM Test、Flash Test、MCU 驱动、Clock Unit、Power & 等。

内存驱动包括：内部闪存驱动、内部 EEPROM 驱动、外部 EEPROM 驱动、Flash 驱动等。

加密驱动包括：SHE/HSM 驱动。

通信驱动包括：SPI、CAN、LIN、FlexRay、Ethernet 等驱动。

I/O 驱动包括：PWM、DIO、ADC、ICU、OCU、PORT、CCU、SCI 等。

微控制器抽象层：SPIHandlerDriver

SPIHandlerDriver 允许多个客户端对一个或多个 SPI 总线进行并发访问。

为了抽象专用于片选的所有 SPI 微控制器引脚功能，这些功能应由 SPIHandlerDriver 直接处理。这意味着这些引脚不应在 DIO 驱动中可用。

示例：

  • 板载设备抽象：外部 Watchdog 驱动
  • 内存硬件抽象：外部 EEPROM 驱动
  • I/O 硬件抽象：外部 ADC ASIC 驱动、外部 I/O ASIC 驱动
  • 通信驱动：SPIHandlerDriver
  • 通信驱动下的 µC 资源：SPI

复杂驱动

复杂驱动是在基础软件栈内实现非标准化功能的模块。

一个示例是使用特定的复杂 µC 外设（如 PCP、TPU）通过直接访问 µC 实现复杂的传感器评估和执行器控制，例如：

  • 喷射控制
  • 电动阀控制
  • 增量位置检测

任务：满足处理复杂传感器和执行器的特殊功能和时序要求。

属性：

  • 实现：高度依赖于 µC、ECU 和应用
  • 对 SW-C 的上层接口：根据 AUTOSAR 规定和实现（AUTOSAR 接口）
  • 下层接口：限制性访问标准化接口

ECU 抽象：I/O 硬件抽象

I/O 硬件抽象是一组模块，它们抽象了外设 I/O 设备的位置（片上或板载）和 ECU 硬件布局（例如 µC 引脚连接和信号电平反转）。I/O 硬件抽象不抽象传感器/执行器！

不同的 I/O 设备可以通过 I/O 信号接口访问。

任务：

  • 表示 I/O 信号，因为它们连接到 ECU 硬件（例如电流、电压、频率）
  • 隐藏 ECU 硬件和布局属性以避免影响更高软件层

属性：

  • 实现：独立于 µC，依赖于 ECU 硬件
  • 上层接口：独立于 µC 和 ECU 硬件，依赖于根据 AUTOSAR 规定和实现的信号类型（AUTOSAR 接口）

ECU 抽象：通信硬件抽象

通信硬件抽象是一组模块，它们抽象了通信控制器的位置和 ECU 硬件布局。对于所有通信系统，需要特定的通信硬件抽象（例如用于 LIN、CAN、FlexRay）。

示例：ECU 具有带有 2 个内部 CAN 通道的微控制器和带有 4 个 CAN 控制器的附加板载 ASIC。CAN-ASIC 通过 SPI 连接到微控制器。

通信驱动通过特定于总线的接口（例如 CAN 接口）访问。

任务：提供访问总线通道的相同机制，无论其位置（片上/板载）。

属性：

  • 实现：独立于 µC，依赖于 ECU 硬件和外部设备
  • 上层接口：依赖于总线，独立于 µC 和 ECU 硬件

内存硬件抽象

内存硬件抽象是一组模块，它们抽象了外设内存设备的位置（片上或板载）和 ECU 硬件布局。

示例：片上 EEPROM 和外部 EEPROM 设备可通过相同机制访问。

内存驱动通过内存特定的抽象/仿真模块（例如 EEPROM 抽象）访问。

通过在闪存硬件单元上仿真 EEPROM 抽象，可以通过内存抽象接口对两种类型的硬件进行通用访问。

任务：提供访问内部（片上）和外部（板载）内存设备和内存硬件类型（EEPROM、闪存）的相同机制。

属性：

  • 实现：独立于 µC，依赖于外部设备
  • 上层接口：独立于 µC、ECU 硬件和内存设备

板载设备抽象

板载设备抽象包含无法视为传感器或执行器的 ECU 板载设备的驱动，例如内部或外部看门狗。这些驱动通过 µC 抽象层访问 ECU 板载设备。

任务：从 ECU 特定的板载设备中抽象。

属性：

  • 实现：独立于 µC，依赖于外部设备
  • 上层接口：独立于 µC，部分依赖于 ECU 硬件

加密硬件抽象

加密硬件抽象是一组模块，它们抽象了加密原语的位置（内部或外部硬件或基于软件）。

示例：AES 原语在 SHE 中实现或作为软件库提供。

任务：提供访问内部（片上）和软件加密设备的相同机制。

属性：

  • 实现：独立于 µC
  • 上层接口：独立于 µC、ECU 硬件和加密设备

加密服务

加密服务由两个模块组成：

  • 加密服务管理器（Crypto Service Manager）：负责管理加密作业
  • 密钥管理器（Key Manager）：与密钥提供主控（位于 NVM 或加密驱动中）交互，管理证书链的存储和验证

任务：以统一方式向应用提供加密原语和密钥存储。抽象硬件设备和属性。

属性：

  • 实现：独立于 µC 和 ECU 硬件，高度可配置
  • 上层接口：独立于 µC 和 ECU 硬件，根据 AUTOSAR 规定和实现（AUTOSAR 接口）

通信服务 - 概述

通信服务是一组用于车辆网络通信（CAN、LIN、FlexRay 和以太网）的模块。它们通过通信硬件抽象与通信驱动接口。

任务：

  • 为车辆网络通信提供统一接口
  • 为网络管理提供统一服务
  • 为诊断通信提供到车辆网络的统一接口
  • 从应用中隐藏协议和消息属性

通信服务包括：COM、PDU Router、IPDU Multiplexer、传输协议（总线特定）、网络管理（总线特定）、状态管理器（总线特定）、诊断通信管理器、Com Manager、Generic NM Interface、Transformer（Com Based、SOME/IP、E2E、Large Data、Secure Onboard Communication）、Diagnostic Log and Trace。

属性：

  • 实现：独立于 µC 和 ECU 硬件，部分依赖于总线类型
  • 上层接口：独立于 µC、ECU 硬件和总线类型

通信栈 - CAN

CAN 通信服务是一组用于与 CAN 通信系统进行车辆网络通信的模块。

任务：

  • 为 CAN 网络提供统一接口
  • 从应用中隐藏协议和消息属性

CAN 通信栈支持：

  • 经典 CAN 通信（CAN 2.0）
  • CAN FD 通信（如果硬件支持）

属性：

  • 实现：独立于 µC 和 ECU 硬件，部分依赖于 CAN
  • AUTOSAR COM、Generic NM（网络管理）接口和诊断通信管理器对所有车辆网络系统都是相同的，每个 ECU 存在一个实例
  • Generic NM 接口仅包含调度程序。不包含进一步功能。在网关 ECU 的情况下，它还可以包括 NM 协调器功能，该功能允许同步唤醒或关闭多个不同网络（相同或不同类型）
  • CAN NM 特定于 CAN 网络，将为每个 CAN 车辆网络系统实例化
  • 通信系统特定的 Can State Manager 处理依赖于通信系统的启动和关闭功能。此外，它控制 COM 的不同选项以发送 PDU 和监控信号超时

通信栈扩展 - TTCAN

TTCAN 通信服务是纯 CAN 接口和 CAN 驱动模块的可选扩展，用于通过 TTCAN 通信系统进行车辆网络通信。

任务：

  • 为 TTCAN 网络提供统一接口
  • 从应用中隐藏协议和消息属性

注：

  • 具有 TTCAN 的 CAN 接口可以同时为 TTCAN 节点和纯 CAN 节点提供服务

通信栈 - LIN

LIN 通信服务是一组用于通过 LIN 通信系统进行车辆网络通信的模块。

任务：

  • 为 LIN 网络提供统一接口
  • 从应用中隐藏协议和消息属性

LIN 通信栈提供：

  • 经典 LIN 通信
  • LIN 主/从通信
  • LIN 传输协议

属性：

  • 实现：独立于 µC 和 ECU 硬件，部分依赖于 LIN
  • LIN 通信栈使用 LIN 接口与硬件无关的接口
  • LIN 状态管理器处理 LIN 通信系统的启动和关闭
  • LIN NM 是 LIN 特定的网络管理

通信栈 - FlexRay

FlexRay 通信服务是一组用于通过 FlexRay 通信系统进行车辆网络通信的模块。

任务：

  • 为 FlexRay 网络提供统一接口
  • 从应用中隐藏协议和消息属性

属性：

  • 实现：独立于 µC 和 ECU 硬件，部分依赖于 FlexRay
  • FlexRay 通信栈支持 FlexRay 协议规范 2.1
  • FlexRay 状态管理器处理 FlexRay 通信系统的启动和关闭
  • FlexRay NM 是 FlexRay 特定的网络管理

通信栈 - 以太网

以太网通信服务是一组用于通过以太网进行车载网络通信的模块。

任务：

  • 为车载以太网提供统一接口
  • 从应用中隐藏协议和消息属性

属性：

  • 实现：独立于 µC 和 ECU 硬件，部分依赖于以太网
  • 以太网通信栈支持 TCP/IP 协议族
  • 以太网状态管理器处理以太网通信系统的启动和关闭
  • 以太网 NM（NM）协调网络状态
  • SOME/IP Transformer 支持基于服务的通信

通信栈 - 总结

不同的车辆网络系统具有不同的通信栈。共同的部分（如 AUTOSAR COM、Generic NM、诊断通信管理器、PDU Router、IPDU Multiplexer、E2E、SecOC、Large Data COM）在多个总线类型之间共享。

总线 通信栈模块
CAN CAN Interface、CAN Driver、CAN Transceiver Driver、CanIf、CanNm、CanSm、CanTp
LIN LIN Interface、LIN Driver、LIN Transceiver Driver、LinIf、LinNm、LinTp
FlexRay FlexRay Interface、FlexRay Driver、FlexRay Transceiver Driver、FrIf、FrNm、FrSm、FrTp
以太网 EthIf、EthSm、TCP/IP 栈、SOME/IP、SD

内存栈

内存栈是一组提供非易失性内存管理功能的模块：

  • NVRAM 管理器（NvM）：管理对内部和/或外部内存设备的并发访问；执行分布式和可靠的数据存储、数据检查、默认值提供等
  • 内存抽象接口（MemIf）：提供对内存设备（EEPROM 和闪存）的统一访问
  • EEPROM 抽象（EA）：提供 EEPROM 仿真（如果使用闪存）
  • 闪存 EEPROM 仿真（Fee）：提供闪存上的 EEPROM 仿真
  • EEPROM 驱动：访问内部/外部 EEPROM 设备
  • 闪存驱动：访问内部/外部闪存设备

任务：提供非易失性内存的统一抽象，独立于内存设备的数量和位置。

属性：

  • 实现：独立于 µC，依赖于内存设备类型
  • 上层接口：独立于 µC、ECU 硬件和内存设备

I/O 栈

I/O 栈包括 ADC、DIO、PWM、ICU、OCU 等驱动以及它们的硬件抽象。

任务：提供对外设的标准化访问，独立于位置（片上/板载）和硬件布局。

属性：

  • 实现：独立于 µC，依赖于 ECU 硬件
  • 上层接口：独立于 µC 和 ECU 硬件，依赖于信号类型

看门狗栈

看门狗栈包括：

  • 看门狗驱动（Wdg）：控制内部/外部看门狗硬件
  • 看门狗接口（WdgIf）：提供对不同看门狗硬件的统一访问
  • 看门狗管理器（WdgM）：监督应用和 BSW 模块的执行

任务：提供看门狗功能的统一抽象。

属性：

  • 实现：独立于 µC，依赖于看门狗硬件
  • 上层接口：独立于 µC 和看门狗硬件

系统服务

系统服务是基础软件的最高层，包括：

  • 操作系统（OS）：调度、任务管理、中断处理等
  • ECU 状态管理器（EcuM）：管理 ECU 的启动、关闭、睡眠和唤醒
  • BSW 模式管理器（BswM）：根据规则执行模式管理
  • 看门狗管理器（WdgM）：监督应用和 BSW 模块
  • 通信管理器（ComM）：管理通信通道
  • 网络管理（Nm）：协调网络状态
  • 诊断事件管理器（Dem）：管理诊断事件
  • 诊断通信管理器（Dcm）：处理诊断通信
  • 时间服务（Tm）：提供时间戳和定时器
  • OS-Application 计时器：基于 OS-Application 的时间监控

复杂驱动

复杂驱动层是 AUTOSAR 架构中的一个特殊层。它用于：

  • 集成非 AUTOSAR 标准的功能
  • 处理具有非常严格时序要求的硬件
  • 提供迁移路径

复杂驱动可以从硬件直接跨越到 RTE。

1.3 多核系统中的软件层内容

多核架构概述

在多核系统中，AUTOSAR 架构需要支持跨多个核心的软件分布。不同核心可以运行：

  • 不同的 BSW 模块
  • 不同的 SW-C
  • 共享的 BSW 模块

多核 BSW 模块分布

BSW 模块可以分布到多个核心：

  • 类型 1：模块的所有实例都在一个核心上运行（集中式）
  • 类型 2：模块的实例分布在多个核心上，每个核心都有自己的实例
  • 类型 3：模块的实例分布在多个核心上，所有核心共享同一个实例

主从模式

多核系统中的 BSW 模块可以使用主从模式：

  • 主实例（Master）：在一个核心上运行，负责模块的主要功能
  • 从实例（Slave）：在其他核心上运行，处理本地功能

主实例和从实例之间的通信通过 OS-Application 间的通信机制（IOC）实现。

跨核心通信

多核系统中的跨核心通信通过以下机制实现：

  • OS-Application 间通信（IOC）：用于 SW-C 之间的通信
  • 共享内存：用于 BSW 模块之间的数据共享
  • 信号路由：用于跨核心的信号传输

多核 BSW 模块处理

AUTOSAR 4.4 引入了多核 MCAL 分布的初稿。多核 BSW 分布的设计原则：

  • 模块的主要部分（核心功能）在一个核心上运行
  • 适配器（Adapter）模块在其他核心上运行
  • 主核心通过共享内存或硬件机制与其他核心通信

1.4 混合关键系统中的软件层内容

混合关键系统概述

混合关键系统在同一 ECU 上集成了不同 ASIL 等级的软件组件。系统需要满足最高 ASIL 等级的要求。

隔离机制

混合关键系统需要适当的隔离机制：

  • 时间隔离：通过时间监控防止低优先级任务干扰高优先级任务
  • 空间隔离：通过内存保护防止低关键性组件访问高关键性组件的内存
  • 通信隔离：通过专用通道控制跨关键性级别的通信

OS-Application 和分区

OS-Application 是 AUTOSAR 中分区的主要机制：

  • 每个 OS-Application 都有自己的内存空间和时间预算
  • OS-Application 之间的通信通过受控的接口（IOC）实现
  • OS-Application 可以配置为可重启或可终止

BSW 在混合关键系统中的处理

BSW 模块在混合关键系统中的处理：

  • 所有 BSW 模块都位于特权 OS-Application 中
  • BSW 模块应该不重启或不终止
  • 用户 SW-C 可以位于不同的 OS-Application 中
  • 跨 OS-Application 的通信通过 IOC

错误检测和响应

混合关键系统中的错误检测和响应：

  • 内存保护违规：触发保护钩子
  • 时间预算违规：触发保护钩子
  • 保护钩子决定采取的操作（终止、重启、关闭、无操作）

1.5 模块概述

模块分类

AUTOSAR BSW 模块可以根据其功能进行分类：

类别 示例模块
微控制器驱动 Mcu、Port、Dio、Gpt、Wdg、Adc、Pwm、Icu、Spi 等
通信驱动 Can、Lin、Fr、Ethernet、Spi 等
内存驱动 Flash、Eeprom 等
I/O 驱动 Dio、Adc、Pwm、Icu、Ocu 等
加密驱动 Crypto、SHE/HSM 等
抽象 Port、Dio 等的抽象层
接口 CanIf、LinIf、FrIf、EthIf、Spi 等
管理器 NvM、WdgM、Dem、ComM、EcuM 等
服务 OS、EcuM、BswM 等

标准模块列表

完整的 BSW 模块列表见《基础软件模块列表》（AUTOSAR_TR_BSWModuleList）。

1.6 接口

一般

AUTOSAR 接口是软件组件之间通信的标准化方式。接口类型包括：

  • AUTOSAR 接口（AUTOSAR Interface）：标准化的接口
  • 标准化 AUTOSAR 接口（Standardized AUTOSAR Interface）：AUTOSAR 标准化的接口
  • 标准化接口（Standardized Interface）：BSW 模块之间的接口

层的交互（示例）

以下示例说明了不同层之间的典型交互：

示例 1：应用通过 RTE 访问 I/O

SW-C → RTE → I/O Hardware Abstraction → MCU Driver → I/O Pin

示例 2：应用通过 RTE 进行网络通信

SW-C → RTE → COM → PDU Router → CanIf → Can Driver → CAN Transceiver → Bus

示例 3：应用通过 RTE 访问非易失性内存

SW-C → RTE → NvM → MemIf → Fee → Flash Driver → Internal Flash

2 配置

配置概述

AUTOSAR 基础软件支持以下配置类：

  1. 预编译时间（Pre-compile time）

    • 预处理器指令
    • 代码生成（选择或合成）

  2. 链接时间（Link time）

    • 模块外部的常量数据；数据可以在模块编译后配置

  3. 构建后时间（Post-build time）

    • 可加载的常量数据位于模块外部。与 [2] 非常类似，但数据位于允许重新加载的特定内存段中（例如在 ECU 生产线上重新刷写）

独立于配置类，可以通过变化点提供单个或多个配置集。在提供多个配置集的情况下，如果变化点在运行时绑定，则实际使用的配置集应在运行时选择。

在许多情况下，一个模块的配置参数将属于不同的配置类。

示例：提供构建后时间配置参数的模块仍可能有一些预编译时间可配置的参数。

注：在 AUTOSAR 4.1.x 之前，多个配置集被建模为构建后时间配置类的子类。

预编译时间（1）

用例

预编译时间配置将用于：

  • 启用/禁用可选功能
    • 这允许排除不需要的源代码部分
  • 优化性能和代码大小
    • 使用 #define 在大多数情况下产生比访问常量甚至通过指针访问常量更有效的代码
    • 生成的代码避免了代码和运行时开销

限制：

  • 模块必须以源代码形式提供
  • 配置是静态的，可能由一个或多个通过变化点标识的配置集组成。要更新任何配置集（例如更改某些参数的值），必须重新编译模块

所需实现

预编译时间配置应通过模块的两个配置文件（_Cfg.h、_Cfg.c）和/或代码生成完成：

  • *_Cfg.h 存储例如宏和/或 #define
  • *_Cfg.c 存储例如常量

预编译时间（2）

示例 1：启用/禁用功能

// File Spi_Cfg.h:
#define SPI_DEV_ERROR_DETECT  ON

// File Spi_Cfg.c:
const uint8 myconstant = 1U;

// File Spi.c (available as source code):
#include "Spi_Cfg.h"           /* for importing the configuration parameters */
extern const uint8 myconstant;

#if (SPI_DEV_ERROR_DETECT == ON)
Det_ReportError(Spi_ModuleId, 0U, 3U, SPI_E_PARAM_LENGTH);
#endif

注：为了保持示例简单，未使用 AUTOSAR 规定的编译器抽象和内存抽象。

预编译时间（3）

示例 2：报告给 Dem 的事件 ID

NVRAM 管理器的 XML 配置文件指定它需要事件符号 NVM_E_REQ_FAILED 用于生产错误报告。

// File Dem_Cfg.h (generated by Dem configuration tool):
typedef uint8 Dem_EventIdType; /* total number of events = 46 => uint8 sufficient */

#define DemConf_DemEventParameter_FLS_E_ERASE_FAILED_0    1U
#define DemConf_DemEventParameter_FLS_E_ERASE_FAILED_1    2U
#define DemConf_DemEventParameter_FLS_E_WRITE_FAILED_0     3U
#define DemConf_DemEventParameter_FLS_E_WRITE_FAILED_1     4U
#define DemConf_DemEventParameter_NVM_E_REQ_FAILED         5U
#define DemConf_DemEventParameter_CANSM_E_BUS_OFF          6U
...

// File Dem.h:
#include "Dem_Cfg.h" /* for providing access to event symbols */

// File NvM.c (available as source code):
#include "Dem.h"      /* for reporting production errors */
Dem_SetEventStatus(DemConf_DemEventParameter_NVM_E_REQ_FAILED, DEM_EVENT_STATUS_PASSED);

链接时间（1）

用例

链接时间配置将用于：

  • 配置仅作为目标代码可用的模块（例如出于 IP 保护或保修原因）
  • 在编译之后但在链接之前创建配置

所需实现

  1. 一个配置集，无运行时选择：配置数据应捕获在外部常量中。这些外部常量位于单独的文件中。模块直接访问这些外部常量。
  2. 2..n 配置集，运行时选择可能：配置数据应捕获在外部常量结构中。模块在初始化时获得指向这些结构之一的指针。结构可以在每次初始化时选择。

链接时间（2）

示例 1：由多实例化模块（闪存驱动）报告给 Dem 的事件 ID，仅作为目标代码可用

闪存驱动的 XML 配置文件指定它需要事件符号 FLS_E_WRITE_FAILED 用于生产错误报告。

// File Dem_Cfg.h (generated by Dem configuration tool):
typedef uint16 Dem_EventIdType; /* total number of events = 380 => uint16 required */

#define DemConf_DemEventParameter_FLS_E_ERASE_FAILED_0    1U
#define DemConf_DemEventParameter_FLS_E_ERASE_FAILED_1    2U
#define DemConf_DemEventParameter_FLS_E_WRITE_FAILED_0     3U
#define DemConf_DemEventParameter_FLS_E_WRITE_FAILED_1     4U
#define DemConf_DemEventParameter_NVM_E_REQ_FAILED         5U
#define DemConf_DemEventParameter_CANSM_E_BUS_OFF          6U
...

// File Fls_Lcfg.c:
#include "Dem_Cfg.h"   /* for providing access to event symbols */
const Dem_EventIdType Fls_WriteFailed[2] = {
    DemConf_DemEventParameter_FLS_E_WRITE_FAILED_1,
    DemConf_DemEventParameter_FLS_E_WRITE_FAILED_2
};

// File Fls.c (available as object code):
#include "Dem.h"      /* for reporting production errors */
extern const Dem_EventIdType Fls_WriteFailed[];

Dem_SetEventStatus(Fls_WriteFailed[instance], DEM_EVENT_STATUS_FAILED);

链接时间（3）

示例 2：由仅作为目标代码可用的模块（闪存驱动）报告给 Dem 的事件 ID

问题：Dem_EventIdType 也是根据此 ECU 上的事件 ID 总数生成的。在此示例中，它表示为 uint16。闪存驱动使用此类型，但仅作为目标代码可用。

解决方案：在 ECU 开发的合同阶段，必须固定一些变量类型（包括 Dem_EventIdType）并为每个 ECU 分配。目标代码供应商必须使用这些类型进行编译，并使用正确的类型交付目标代码。

构建后时间（1）

用例

构建后时间配置将用于：

  • 配置仅定义结构但 ECU 构建时不知道内容的数据
  • 配置在 ECU 构建后可能更改或必须适应的数据（例如在生产线末端、在测试和标定期间）
  • ECU 跨不同汽车版本的可重用性（相同的应用，不同的配置），例如低成本汽车版本中的 ECU 可能在总线上传输比豪华汽车版本中的相同 ECU 更少的信号

限制：

  • 实现需要在可刷写区域中存储所有可能相关的配置项，并在配置访问时需要指针解引用。实现排除了代码的生成，这会影响性能、代码和数据大小

所需实现

  1. 一个配置集，无运行时选择：配置数据应捕获在外部常量结构中。这些外部结构位于可以单独重新加载的单独内存段中。模块在初始化时获得指向基础结构的指针。
  2. 2..n 配置集，运行时选择可能：配置数据应捕获在外部常量结构中。这些外部结构位于可以单独重新加载的单独内存段中。模块在初始化时获得指向多个基础结构之一的指针。结构可以在每次初始化时选择。

构建后时间（2）

示例 1

如果配置数据在内存大小和位置上固定，则模块可以直接访问这些外部结构。

PduR.c → Compiler → Linker → PduR.o
                                    Direct access
                                    (via reference as given by
PduR_PBcfg.c → Compiler → Linker → PduR_PBcfg.o    the pointer parameter of
                                    PduR's initialization function)

构建后时间（3）

所需实现 2：配置仅作为目标代码可用的 CAN 驱动；可以在初始化时从多个配置集中选择一个配置集。

// File Can_PBcfg.c:
#include "Can.h" /* for getting Can_ConfigType */
const Can_ConfigType MySimpleCanConfig [2] =
{
    {
        Can_BitTiming        = 0xDF,
        Can_AcceptanceMask1  = 0xFFFFFFFF,
        Can_AcceptanceMask2  = 0xFFFFFFFF,
        Can_AcceptanceMask3  = 0x00034DFF,
        Can_AcceptanceMask4  = 0x00FF0000
    },
    { ... }
};

// File EcuM.c:
#include "Can.h"   /* for initializing the CAN Driver */
Can_Init(&MySimpleCanConfig[0]);

// File Can.c (available as object code):
#include "Can.h"   /* for getting Can_ConfigType */

void Can_Init(Can_ConfigType* Config)
{
    /* write the init data to the CAN HW */
};

变体

不同的用例需要不同类型的可配置性。因此，提供以下配置变体：

  • VARIANT-PRE-COMPILE：此变体中仅允许使用"预编译时间"配置的参数。
  • VARIANT-LINK-TIME：此变体中仅允许使用"预编译时间"和"链接时间"配置的参数。
  • VARIANT-POST-BUILD：此变体中允许使用"预编译时间"、"链接时间"和"构建后时间"配置的参数。

用例示例：

  • 网关中可重新编程的 PDU 路由表（需要构建后时间可配置的 PDU 路由器）
  • 静态配置的 PDU 路由，无开销（需要预编译时间配置的 PDU 路由器）

为了允许在每个 BSW 模块中实现这些不同的用例，最多可以指定 3 个变体：

  • 变体是模块的配置参数到配置类的专用分配
  • 在变体内，配置参数只能分配给一个配置类
  • 在变体内，不同配置参数的配置类可以不同（例如开发错误检测的预编译时间和可重新编程的 PDU 路由表的构建后时间）
  • 可能且预期的是，特定配置参数被分配给所有变体的相同配置类（例如，开发错误检测通常是预编译时间可配置的）

内存布局示例：构建后配置

EcuM 定义索引：
   0x8000   &index (=0x8000)
   0x8000   &xx_configuration = 0x4710
   0x8002   &yy_configuration = 0x4720
   0x8004   &zz_configuration = 0x4730
   ...

Xx 定义模块的配置数据：
   0x4710   &the_real_xx_configuration
   0x4710   lower = 2
   0x4712   upper = 7
   0x4714   more_data
   ...

Yy 定义模块的配置数据：
   0x4720   &the_real_yy_configuration
   0x4720   Xx_data1=0815
   0x4722   Yy_data2=4711
   0x4724   more_data
   ...

说明 - 在哪里找到什么是总体协议：

  1. EcuM 需要知道所有地址，包括索引
  2. 模块（xx、yy、zz）需要知道自己的起始地址：在本例中：0x4710、0x4720 …
  3. 起始地址可能是动态的，即随新配置而变化
  4. 初始化模块时（例如 xx、yy、zz），EcuM 将配置数据的基址（例如 0x4710、0x4720、0x4730）传递给模块，以允许配置数据的大小可变

模块数据在本地（模块内）达成一致：

  1. 模块（xx、yy）知道自己的起始地址（使实现者能够分配数据段）
  2. 只有模块（xx、yy）知道自己配置的内部细节

内存布局示例：多个配置集

0x8000   &index[] (=0x8000)
FL   0x8000   &xx_configuration = 0x4710
      0x8002   &yy_configuration = 0x4720
      0x8004   &zz_configuration = 0x4730
      ...
      0x8008   &xx_configuration = 0x5000
FR
      0x800a   &yy_configuration = 0x5400
      0x800c   &zz_configuration = 0x5200
      ...
      0x8010   &xx_configuration = …
RL   0x8012   &yy_configuration = …
      0x8014   &zz_configuration = …
      ...

说明 - 在哪里找到什么是总体协议：

  1. 索引在数组中包含多个描述（FL、FR、…）（这里同意数组元素的大小为 8）
  2. 有一个商定的变量包含一个描述的位置：selector = CheckPinCombination()
  3. 与其直接传递指针，不如有一个间接级别：(struct EcuM_ConfigType *) &index[selector];
  4. 其他一切与传统的单一配置情况一样工作

3 集成和运行时方面

3.1 可运行实体映射

可运行实体（Runnables）是软件组件的主动部分。它们可以并发执行，通过将它们映射到不同的任务。

该图显示了其他实体，如 OS-Application、分区、µC 核心和 BSW 资源，这些都需要考虑此映射。

映射关系：

  • VFB 视角下的 SW-C（0..）与可运行实体（0..）相关
  • 实现/ECU 视角下的可运行实体（0..）与任务（0..）相关
  • 任务属于 OS-Application（1）
  • OS-Application 属于 µC 核心（1）
  • 分区（1）可以包含多个 OS-Application

3.2 分区

介绍

  • 分区通过在 OS 中使用 OS-Application 实现
  • OS-Application 用作错误隔离区域：
    • 允许对 SW-C 和资源进行逻辑分组
    • 为每个 OS-Application 单独定义恢复策略
  • OS-Application 一致性由系统/平台确保，例如：
    • 内存访问违规
    • 时间预算违规
  • 由于检测到错误，OS-Application 可以在运行时终止或重启：
    • 进一步操作所需：参见后续幻灯片上的示例
    • 所有 BSW 模块都放在特权 OS-Application 中
    • 这些 OS-Application 不应重启或终止
  • OS-Application 在 ECU 配置中配置：
    • SW-C 映射到 OS-Application（后果：限制可运行实体到任务的映射）
    • OS-Application 可以配置为可重启或不可重启
  • 跨 OS-Application 边界的通信通过 IOC 实现

重启 OS-Application 的示例

发生系统违规（错误）时的处理：

  • 错误（例如内存或时序违规）已在系统中发生
  • 由集成商代码决定重启 OS-Application
  • 其他 OS-Application 不受影响
  • OS-Application 被 OS 终止，可以进行清理
  • 与 OS-Application 的通信停止
  • 来自 OS-Application 的通信停止（例如端口的默认值）
  • OS-Application 正在重启（集成商代码），为 OS-Application 设置初始化环境（init runnables、端口值等）
  • 与 OS-Application 的通信停止
  • 来自 OS-Application 的通信停止
  • OS-Application 已重启并运行
  • 通信已恢复
  • OS-Application 内部处理状态一致性

涉及的组件

保护钩子（Protection Hook）：

  • 在保护违规（内存或时序）时执行
  • 决定采取的操作（终止、重启、关闭、无操作）
  • 由集成商提供
  • OS 通过检查返回值来根据决定采取行动

OsRestartTask：

  • 在保护钩子返回"重启"时由 OS 启动
  • 由集成商提供
  • 在 OS-Application 的上下文中运行，并启动必要的清理和重启活动，例如：
    • 停止通信（ComM）
    • 更新 NvM
    • 通知看门狗、CDD 等

RTE：

  • 在 OS-Application 中执行 RTE 清理和重启的函数
  • 触发已重启 OS-Application 的 init runnables
  • 处理正在重启/终止的 OS-Application 的通信一致性

操作系统：

  • OS-Application 具有状态（APPLICATION_ACCESSIBLE、APPLICATION_RESTART、APPLICATION_TERMINATED）
  • OS 提供 API 以终止其他 OS-Application（针对内存/时序以外的错误）

重启示例

序列图显示了 OS-Application 重启的时序过程：

  1. OS-Application 处于 APPLICATION_ACTIVE 状态
  2. ProtectionHook 检测到违规并被通知
  3. 通知 RTE
  4. ActivateTask 触发 OS-Application 状态变为 APPLICATION_RESTARTING
  5. 触发 BSW 分区中的清理
  6. 轮询异步清理结束
  7. 向 RTE 请求重启分区
  8. AllowAccess 重新启动对 OS-Application 的访问
  9. OS-Application 状态返回到 APPLICATION_ACTIVE
  10. TerminateTask 结束重启任务

3.3 调度

AUTOSAR 使用基于优先级的抢占式调度：

  • 任务具有优先级
  • 更高优先级的任务可以抢占更低优先级的任务
  • 调度表用于在特定时间激活任务

调度机制

AUTOSAR 中的调度机制包括：

  • 任务：调度的基本单位
  • 调度表：在特定时间点激活任务
  • 事件：触发任务激活
  • 中断：处理异步事件
  • 自旋锁：保护共享资源
  • 资源：管理共享资源

时间保护

时间保护确保任务在配置的时间预算内完成：

  • 配置每个任务的执行时间预算
  • 监控任务的实际执行时间
  • 超时触发保护钩子

3.4 模式管理

AUTOSAR 中的模式管理提供：

  • 模式：表示系统状态
  • 模式声明组：模式集合
  • 模式切换接口：用于模式切换的接口
  • 模式管理器：协调模式切换

BSW 模式管理器（BswM）

BswM 协调 BSW 模块的模式：

  • 接收来自应用、其他 BSW 模块和 ECU 状态的事件
  • 根据配置的规则计算所需的操作
  • 执行模式请求

应用模式管理器

应用中的模式管理由应用软件实现，通过 RTE 提供的模式切换接口进行通信。

3.5 错误处理、报告和诊断

AUTOSAR 中的错误处理包括：

  • 开发错误（Development Errors）：在开发过程中检测到的错误
  • 运行时错误（Runtime Errors）：在运行时检测到的错误
  • 生产错误（Production Errors）：影响 ECU 行为的错误
  • 扩展生产错误（Extended Production Errors）：用于更详细的错误分类

错误分类

错误类型 处理模块 处理方式
开发错误 Det 仅开发期间
运行时错误 Dem 运行时记录
生产错误 Dem 存储在事件内存中
扩展生产错误 Dem 详细分类

诊断事件管理器（Dem）

Dem 负责：

  • 存储诊断事件
  • 管理 DTC（诊断故障码）
  • 处理事件状态
  • 提供事件查询接口

诊断通信管理器（Dcm）

Dcm 负责：

  • 处理来自诊断测试仪的请求
  • 实现 UDS（统一诊断服务）协议
  • 与 Dem 交互获取事件信息

3.6 测量和标定

AUTOSAR 中的测量和标定使用 XCP 协议：

  • XCP 主设备：测量和标定工具
  • XCP 从设备：ECU
  • A2L 文件：标定描述文件

测量和标定的实现

  • RTE 提供对内部变量的访问
  • 标定参数：可在运行时修改
  • 测量点：可被工具读取

3.7 功能安全

AUTOSAR 支持 ISO 26262 功能安全要求：

  • ASIL 等级：QM、A、B、C、D
  • 安全机制：内存保护、时序监控、独立监控
  • 故障检测：检测和处理故障
  • 故障响应：安全状态转换

安全相关的 BSW 模块

  • WdgM：看门狗管理
  • OS：内存和时间保护
  • EcuM：安全状态管理

3.8 安全

AUTOSAR 中的安全（Security）功能：

  • 加密服务（Csm）：提供加密操作
  • 安全硬件扩展（SHE）：硬件安全模块
  • 硬件安全模块（HSM）：高级硬件安全
  • 安全车载通信（SecOC）：保护车内通信
  • 可信执行环境（TEE）：隔离安全关键操作

3.9 能量管理

能量管理包括：

  • ECU 状态管理：RUN、POST-RUN、SLEEP、SHUTDOWN
  • 通信模式：FULL COMM、NO COMM、SILENT COMM
  • 网络管理：协调网络的唤醒/睡眠
  • 部分网络：仅唤醒需要通信的 ECU
  • ECU 降级：在故障情况下减少功能

Pretended Networking

Pretended Networking 是一种机制，其中 ECU 在没有实际通信活动的情况下保持网络活动状态，以减少唤醒时间。

ECU 降级

ECU 降级允许 ECU 在检测到故障时减少其功能，以保持基本操作。

3.10 全局时间同步

全局时间同步在分布式系统中很重要：

  • 时间主节点：提供全局时间基准
  • 时间网关：在不同网络之间同步时间
  • 时间从节点：同步到全局时间
  • 同步协议：例如 PTP、gPTP

AUTOSAR 中的时间同步

  • StbM：同步时间基准管理器
  • EthTSyn：以太网时间同步
  • CanTSyn：CAN 时间同步
  • FrTSyn：FlexRay 时间同步

翻译说明

本文档是 AUTOSAR 经典平台（CP）4.4.0 版本中关于分层软件架构的说明文档（EXP）。文档详细描述了 AUTOSAR 软件架构的分层结构、各层内容、配置机制和集成运行时方面，包括多核、混合关键系统、分区、模式管理、错误处理、功能安全、能量管理、全局时间同步等关键主题。翻译过程中：

  1. 保留：所有 API 标识符、模块缩写、协议名（CAN、LIN、FlexRay、Ethernet、BSW、RTE、VFB、ECU 等）、配置类名称、需求 ID、文档 ID。
  2. 翻译：所有章节标题、说明性文字、表格内容、图形标题。
  3. 术语：按照《翻译术语表》进行统一，如 BSW（基础软件）、RTE（运行时环境）、VFB（虚拟功能总线）、ECU（电子控制单元）、SWC（软件组件）、SBC（系统基础芯片）、SHE（安全硬件扩展）、HSM（硬件安全模块）等。
  4. 格式：将原文页脚和"X of 162"页码指示符合并到章节结构中，所有图表（Figure）以引用方式列出。
  5. 代码块：原文中的 C 代码示例使用代码块保留，便于读者参考对照。
  6. 特殊处理：AUTOSAR 方框符 ⌈⌋ 用于标记需求条目（本文档中较少使用，因为本文档主要描述性内容）。原文中"X of 162"等页码标识被移除。
  7. 结构化翻译：原文档包含大量 UML 图和架构图（基于幻灯片格式），翻译中以描述性文字和结构化列表替代具体的图形内容。
Reference in New Issue View Git Blame Copy Permalink