21、汽车电子系统中的 AUTOSAR 技术解析

汽车电子系统中的 AUTOSAR 技术解析

1. 软件组件端口与通信

软件组件可通过端口相互通信，端口类型包括发送 - 接收端口和客户端 - 服务器端口。组件间的通信由运行时环境（RTE）在本地或通过网络实现。大多数情况下，AUTOSAR 接口应能在本地和网络环境下传输数据。

标准 AUTOSAR 接口是一种语法和语义都在 AUTOSAR 中标准化的接口，常用于定义 BSW 模块中的标准化服务。标准化接口本质上是一种 API，通常针对特定编程语言（如 C）定义，用于同一 ECU 上的软件组件模块，以确保使用相同的编程语言实现，但它不能保证软件组件间的通信数据能通过网络传输。

2. 运行时环境（RTE）

2.1 RTE 的重要性与功能

RTE 是 AUTOSAR 架构的重要组成部分，是特定 ECU 上 AUTOSAR 虚拟功能总线（VFB）接口的实现。它为 AUTOSAR 软件组件和基础软件模块（包括操作系统和通信服务）提供通信服务，涵盖了因软件组件映射到 ECU 而产生的系统服务可变元素以及标准化的 RTE 服务。

2.2 RTE 上下部分的访问规则

在 RTE 下方，BSW 模块可通过适当接口（如 AUTOSAR 接口和 AUTOSAR 标准化接口）直接访问其他模块；在 RTE 上方，AUTOSAR 软件组件只能通过端口相互通信，不能直接访问 BSW 模块。

2.3 可运行实体

AUTOSAR 软件组件的内部行为以可运行实体的形式实现，可运行实体是指令序列，是 AUTOSAR 软件组件的调度单元和由 RTE 触发的基本控制单元。可运行实体需要映射到操作系统的基本可调度单元（任务），其映射关系需在 ECU 配置描述中说明，且所有可运行实体由 RTEEvent 触发。RTE 支持多种事件，如定时器过期、数据到达和服务器调用返回等。

可运行实体分类如下：
| 类别 | 特点 | 映射任务 |
| ---- | ---- | ---- |
| 类别 1 | 不支持等待点，需在特定时间内终止 | AUTOSAR OS 的基本任务 |
| 类别 2 | 有多个等待点或始终等待响应返回 | AUTOSAR OS 的扩展任务 |
| 类别 3 | 目前超出 RTE 规范范围 | 无 |

2.4 RTE 的生成

RTE 生成需适配特定的 ECU 和系统配置，当输入描述和配置相同时，RTE 生成器应产生相同的 RTE API 和 RTE 代码。生成过程分为两个阶段：
1. 合同阶段 ：使用组件的 AUTOSAR 接口定义的有限信息生成应用程序头文件，这些头文件定义了组件与 RTE 之间的契约。例如，一个 AUTOSAR 软件组件有一个发送端口 P 和数据元素 D，合同阶段将生成 RTE API 函数 Rte_Send_P_D，软件组件使用该函数通过发送端口 P 发送数据元素 D。
2. 生成阶段 ：使用组件的所有相关信息（如映射到 ECU 和通信拓扑）生成 RTE 以及可选的本地配置。AUTOSAR 系统中的每个 ECU 都会生成一个 RTE，生成可执行文件需要应用程序头文件和所有必要的 BSW 代码。

2.5 软件组件的开发与交付

使用 RTE 特定 API 开发 AUTOSAR 软件组件与 ECU 硬件无关，因为生成的应用程序头文件包含端口访问和发送/接收数据的信息，软件组件的源代码可独立于通过 BSW 的通信方法提供。软件组件编译成功后，会分析目标文件（如 ROM 和 RAM 的实际内存需求信息）。软件组件的交付包包括：
1. 软件组件类型描述
2. 软件组件内部行为描述
3. 实际的软件组件实现和编译后的软件组件
4. 软件组件实现描述

3. AUTOSAR 分层架构

AUTOSAR 为汽车电子系统定义了分层软件架构，BSW 是标准化软件层，为 AUTOSAR 软件组件提供资源和服务，但自身不执行任何功能。BSW 位于 AUTOSAR RTE 下方，不能直接与 AUTOSAR 软件组件交互，包含标准化软件模块和 ECU 特定软件模块。

3.1 微控制器抽象层（MCAL）

MCAL 是基础软件的最低层，使高层软件层独立于微控制器，以依赖微控制器的软件模块形式实现。高层软件组件可通过 MCAL 访问微控制器寄存器，但不能直接访问。MCAL 管理微控制器外设（如数字 I/O、模拟/数字转换器和串行外设接口），实现通知机制以支持操作和信息的分发。MCAL 模块可视为微控制器设备驱动程序，分为四类：微控制器驱动程序、内存驱动程序、通信驱动程序和 I/O 驱动程序。

3.2 ECU 抽象层

ECU 抽象层位于 MCAL 之上，为特定 ECU 的电气值和 ECU 板上的外部设备提供软件接口，将高层软件组件与底层 ECU 硬件布局解耦，以独立于微控制器但依赖于 ECU 硬件的软件模块形式实现。此外，它还为 ECU 中的外设和设备提供接口，无论其位于微控制器内部还是外部以及与微控制器的连接方式。

3.3 服务层

服务层位于 ECU 抽象层之上，提供额外的系统服务，如非易失性随机存取存储器（NVRAM）管理器、诊断事件管理器（DEM）、闪存和内存管理等。它是基础软件的最高层，可直接访问硬件，为应用程序和 BSW 提供基本服务，大多数情况下以独立于微控制器和 ECU 的软件模块形式实现。

3.4 AUTOSAR 操作系统

AUTOSAR 操作系统与 OSEK 兼容，是服务层的一部分。其要求包括：
1. 静态配置和缩放
2. 可预测实时性能
3. 基于优先级的调度
4. 运行时保护机制
5. 可在无外部资源的低端控制器上运行

AUTOSAR OS 可直接访问硬件资源（如微控制器中的定时器用于调度），标准 OSEK OS（ISO 17356 - 3）被用于 AUTOSAR OS。

3.5 复杂设备驱动程序（CCD）

CCD 可直接访问硬件资源，用于支持和资源关键应用以及未在 AUTOSAR 软件架构标准化接口中标准化的新设备驱动程序。此外，它还可为高定时约束和迁移提供特殊功能，可能以依赖于应用程序、微控制器和 ECU 的软件模块形式实现。

3.6 RTE 的作用

BSW 和软件组件（SWC）严格分离，RTE 位于它们之间。RTE 保护 BSW 不被 SWC 直接访问，允许 SWC 通过标准化接口访问 BSW 服务（如微控制器外设和内存服务），其另一个重要职责是提供 SWC 之间的通信服务，无论它们是否在同一 ECU 内，可被视为特定 ECU 上的中间件，是 VFB 概念的实现。

4. AUTOSAR ECUs 演示

4.1 向 AUTOSAR ECU 迁移

AUTOSAR 概念和优势已得到多个 OEM 的验证，但基于模型开发的初始高成本和未来的不确定性使 OEM 难以采用 AUTOSAR 系统。对现有系统进行修改和优化是开发符合 AUTOSAR 系统的良好解决方案，迁移可提供向 AUTOSAR 系统过渡的机会。迁移所需的活动包括：
1. 进行 AUTOSAR 开发过程和工具的培训
2. 检查现有系统和 AUTOSAR 系统
3. 记录 AUTOSAR 开发过程
4. 将现有系统转换为 AUTOSAR 系统
5. 确保现有系统与 AUTOSAR 系统的一致性

为验证从现有系统到 AUTOSAR 系统的迁移，需要进行以下比较：
1. 现有系统与 AUTOSAR 系统的一致性
2. 性能比较
3. 可重用性比较
4. 开发过程成熟度比较

AUTOSAR 迁移工作流程示例如下：
1. 从遗留系统开始迁移
2. 通过 AUTOSAR 接口从遗留应用程序和 RTE 开发简单的 AUTOSAR SWC
3. 开发遗留中间件到 RTE 的 AUTOSAR 接口
4. 开发 AUTOSAR BSW 并替换遗留中间件
5. 从遗留应用程序在 RTE 上开发更多 AUTOSAR SWC
6. 替换剩余的遗留应用程序和遗留中间件

4.2 LKAS 系统在 AUTOSAR 中的应用

4.2.1 LKAS 系统概述

LKAS 的主要功能是辅助驾驶员使车辆保持在当前车道内，它获取车辆在车道内的位置，并在需要时控制车辆的横向移动。LKAS 由传感器/执行器组件、处理单元和人机界面（HMI）组件组成。

4.2.2 LKAS 的状态与转换

开发 LKAS 时，需首先定义其状态和转换。HMI 菜单或 LKAS 开关可实现 LKAS 关闭和开启状态之间的转换。由于 LKAS 是辅助系统而非自主系统，驾驶员承担全部责任。LKAS 的重要要求包括驾驶员可随时控制 LKAS 以及指示 LKAS 的当前状态。当 LKAS 开启且激活条件满足时，需在 5 秒内辅助车道保持并指示当前状态；当激活条件不满足时，需指示 LKAS 的停用状态；当 LKAS 关闭时，为安全起见应优雅地停止车道保持辅助。

4.2.3 LKAS 组件通信与接口

LKAS 的组件分布在车辆上，通过车内网络（IVN）连接。检测传感器（如视觉传感器）处理物体和车道信息，LKAS 根据这些信息确定车辆在车道内的位置并控制电动助力转向（EPS）模块。HMI（如仪表盘）指示 LKAS 的状态并开启 LKAS 功能，每个组件都可以是一个 AUTOSAR ECU。

开发 AUTOSAR LKAS 时，需要定义 AUTOSAR 软件组件和接口。例如，HMI 控制和 HMI 指示软件组件被定义，HMI 控制和 LKAS 控制之间的接口是简单的客户端/服务器端口，HMI 控制 SWC 可请求 LKAS 开启/关闭服务，LKAS 控制 SWC 执行该服务并返回结果。

4.2.4 车辆速度与视觉服务请求

根据美国国家公路交通安全管理局（NHSTA）的数据，约 70% 的美国单车辆高速公路事故发生在车道和道路偏离时。为辅助高速公路上的车道保持，LKAS 将在车辆速度超过参考速度（符合各国法律法规）时激活。车辆速度 SWC 定期向 LKAS 控制 SWC 发送当前车辆速度数据，当车辆速度超过参考速度时，LKAS 控制 SWC 向视觉传感器 SWC 请求视觉服务。

4.2.5 视觉传感器 SoC

在单视觉传感器的情况下，为低功耗设计的片上系统（SoC）作为廉价计算平台并满足汽车资格要求，用于基于视觉的解决方案（如车道检测、车辆检测、雷达视觉融合、交通标志检测、相机应用和前照灯控制）。例如 Mobileye SoC 架构由两个 32 位 RISC 处理器、四个视觉计算引擎和多个外设组成。

4.2.6 可运行实体的状态判断与处理

可运行实体的状态判断与处理流程如下：

graph TD
    A[开始] --> B{是否指定 RTEEvent}
    B -- 是 --> C{是否有 WaitPoints 或等待响应}
    C -- 否 --> D[类别 1 可运行实体]
    C -- 是 --> E[类别 2 可运行实体]
    B -- 否 --> F[不可被 RTE 激活]
    D --> G[映射到 AUTOSAR OS 基本任务]
    E --> H[映射到 AUTOSAR OS 扩展任务]

4.2.7 内部行为开发

设计好 AUTOSAR SWC 和接口后，需要开发 SWC 的内部行为。可使用多种基于模型的开发（MBD）工具（如 MATLAB/Simulink 和 dSpace TargetLink）通过 AR - XML 对 SWC 的内部行为进行建模，开发过程如下：
1. 通过 AR - XML 文件将 AUTOSAR SWC 从 AUTOSAR 工具导入 MBD 工具。
2. 从导入的 AUTOSAR SWC 生成模型。
3. 加载已使用 MBD 工具开发的 SWC 行为模型（如 Simulink 模型和 Stateflow 模型）。
4. 验证 SWC 的行为模型和配置是否符合 AUTOSAR SWC。
5. 为 AUTOSAR SWC 生成源代码和 AR - XML 文件。
6. 从 MBD 工具导入包含 SWC 内部行为的生成 AR - XML 文件。
7. 使用 AUTOSAR 工具模拟 AUTOSAR SWC。

在 MATLAB/Simulink 中，使用 arxml.importer 类解析 AUTOSAR SWC 描述文件，完成行为模型应用后，需配置 AUTOSAR 接口。验证配置无误后，可使用 MBD 工具（如 MATLAB/Simulink 中的实时工作室和嵌入式编码器）生成 AUTOSAR SWC。目前，可使用 AUTOSAR 工具通过 AR - XML 合并生成的 AUTOSAR SWC 进行开发和仿真，例如在 Vector DaVinci Developer 中，使用菜单中的“导入 XML 文件”导入生成的 AR - XML，当完成相关配置后，即可在 VFB 上对 SWC 进行仿真。

综上所述，AUTOSAR 技术为汽车电子系统的开发提供了标准化的架构和方法，通过 RTE 实现软件组件的通信和交互，分层架构确保了系统的可维护性和可扩展性。在实际应用中，如 LKAS 系统，AUTOSAR 技术能够有效实现系统功能，提高汽车的安全性和智能化水平。同时，向 AUTOSAR 系统的迁移为现有系统的优化和升级提供了可行的途径。

4.2.8 内部行为开发详细步骤分析

在使用 MBD 工具开发 AUTOSAR SWC 内部行为时，每个步骤都有着重要的意义和作用，下面详细分析各步骤：

步骤	操作内容	作用
1. 导入 AUTOSAR SWC	通过 AR - XML 文件将 AUTOSAR SWC 从 AUTOSAR 工具导入 MBD 工具	建立 MBD 工具与 AUTOSAR 工具之间的数据连接，为后续模型生成提供基础数据
2. 生成模型	从导入的 AUTOSAR SWC 生成模型	将 AUTOSAR SWC 的抽象描述转化为 MBD 工具可处理的模型形式
3. 加载行为模型	加载已使用 MBD 工具开发的 SWC 行为模型（如 Simulink 模型和 Stateflow 模型）	将预先开发好的具体行为逻辑融入到生成的模型中
4. 验证模型和配置	验证 SWC 的行为模型和配置是否符合 AUTOSAR SWC	确保开发的模型和配置满足 AUTOSAR 规范要求，避免后续出现兼容性问题
5. 生成代码和文件	为 AUTOSAR SWC 生成源代码和 AR - XML 文件	将模型转化为可执行的代码和用于描述 SWC 的 XML 文件
6. 导入生成文件	从 MBD 工具导入包含 SWC 内部行为的生成 AR - XML 文件	将 MBD 工具生成的内部行为信息重新导回到 AUTOSAR 工具中
7. 模拟 SWC	使用 AUTOSAR 工具模拟 AUTOSAR SWC	对开发好的 SWC 进行功能验证和测试

4.2.9 不同接口类型下端口的功能

在 AUTOSAR 系统中，不同的接口类型（客户端/服务器接口和发送者/接收者接口）下，端口有着不同的功能，具体如下：

客户端/服务器接口

端口类型	功能描述	示例
PPort	提供客户端/服务器接口中服务的实现	LKAS 控制 SWC 中的 CS_PP_OnOff 端口，提供 OnOff 服务
RPort	调用客户端/服务器接口中的服务	HMI 控制 SWC 中的 CS_RP_OnOff 端口，可调用 OnOff 服务

发送者/接收者接口

端口类型	功能描述	示例
PPort	生成发送者/接收者接口中定义的数据	车辆速度 SWC 中的 SR_PP_Vehicle Speed 端口，生成车辆速度数据
RPort	读取发送者/接收者接口中的数据	LKAS 控制 SWC 中的 SR_RP_Vehicle Speed 端口，读取车辆速度数据

4.2.10 视觉传感器 SWC 处理流程

当 LKAS 控制 SWC 向视觉传感器 SWC 请求视觉服务时，视觉传感器 SWC 的处理流程如下：

graph TD
    A[接收视觉服务请求] --> B[进行视觉处理]
    B --> C[预 - 处理]
    C --> D[跟踪器处理]
    D --> E[分类车道检测]
    E --> F[返回服务结果]
    F --> G[包含车辆位置、偏离率和服务错误等信息]

4.3 AUTOSAR 系统迁移的挑战与应对策略

虽然向 AUTOSAR 系统迁移具有诸多优势，但也面临着一些挑战，以下是常见挑战及相应的应对策略：

挑战	应对策略
基于模型开发的初始高成本	分阶段进行迁移，先从简单的组件和功能开始，逐步扩大迁移范围，降低一次性投入成本
未来的不确定性	与 AUTOSAR 技术供应商保持密切沟通，及时了解技术发展趋势和标准更新，提前做好应对准备
现有系统与 AUTOSAR 系统的兼容性问题	在迁移前进行充分的系统检查和分析，对现有系统进行必要的改造和优化，确保其与 AUTOSAR 系统的兼容性
开发人员对 AUTOSAR 技术的熟悉程度不足	加强对开发人员的培训，提供丰富的培训资源和实践机会，提高开发人员的技术水平和应用能力

4.4 AUTOSAR 技术在未来汽车电子系统中的发展趋势

随着汽车行业的不断发展，AUTOSAR 技术在未来汽车电子系统中将呈现以下发展趋势：

4.4.1 更高的集成度

未来的汽车电子系统将需要集成更多的功能和组件，AUTOSAR 技术将不断优化其分层架构和通信机制，以支持更高的集成度，实现不同功能模块之间的高效协作。

4.4.2 更强的安全性

汽车的智能化和联网化程度越来越高，安全问题成为重中之重。AUTOSAR 将加强对安全机制的支持，如加密通信、访问控制等，确保汽车电子系统的安全性和可靠性。

4.4.3 更好的兼容性

随着汽车电子系统中使用的硬件和软件种类不断增加，AUTOSAR 技术将进一步提高其兼容性，能够更好地适应不同的硬件平台和软件环境，降低开发成本和难度。

4.4.4 与新兴技术的融合

AUTOSAR 将与人工智能、大数据、云计算等新兴技术深度融合，为汽车提供更智能、更高效的功能，如自动驾驶、智能互联等。

5. 总结

AUTOSAR 技术为汽车电子系统的开发带来了标准化、模块化和可复用性的优势。通过软件组件端口和 RTE 实现了组件间的高效通信，分层架构确保了系统的可维护性和可扩展性。在实际应用中，如向 AUTOSAR ECU 迁移和 LKAS 系统的开发，AUTOSAR 技术展现出了强大的功能和应用价值。

同时，我们也看到了向 AUTOSAR 系统迁移面临的挑战，但通过合理的策略和方法可以有效应对。未来，AUTOSAR 技术将不断发展和完善，与新兴技术融合，为汽车行业的智能化和电动化发展提供有力支持。汽车制造商和开发人员应积极拥抱 AUTOSAR 技术，不断探索其在汽车电子系统中的应用，推动汽车行业的创新发展。