一文了解汽车嵌入式AUTOSAR架构
如下展示了AUTOSAR的目标、主要挑战和解决方案以及这些解决方案所带来的好处。
处理与系统相关的快速增长的电气/电子复杂性；
产品修改、升级和更新的实施灵活性；
提高软件解决方案的可扩展性和交叉兼容性；
提高系统的软件质量和可靠性；
在早期开发阶段启用错误检测。
AUTOSAR 架构
Autosar架构的意义
现代车辆中电子/电气系统的数量和这些系统的复杂性正在增加。车辆网络日益复杂是 AUTOSAR 发展背后的动力。
现代车辆每辆都有 一百多个 ECU 。它们中的每一个都有大量的功能。不遵循标准，当ECU硬件设计改变时，软件开发最有可能要重写。
AUTOSAR 的应用范围专用于汽车 ECU，并具有以下特性：
与硬件（传感器和执行器）的强交互，
连接到车辆网络，如 CAN、LIN、FlexRay 或以太网，
计算能力和内存资源有限的微控制器。
时间关键的系统和实时程序从内部存储器执行。
分层 Autosar 架构概述
AUTOSAR 架构在三个软件层之间的最高抽象级别上进行了区分：应用层，运行时环境，基础软件。
应用层
应用层是 AUTOSAR 软件架构的最顶层，支持自定义功能实现。该层由特定的软件组件和许多应用程序组成，它们是一组相互连接的 AUTOSAR 软件组件，并按照指令执行特定任务。
每个 AUTOSAR 软件组件都封装了完整应用软件的部分功能。AUTOSAR 没有规定 AUTOSAR 软件组件有多大。根据应用程序的要求，AUTOSAR 软件组件可能是一个小型的、可重复使用的功能，例如车道保持辅助、雨刷控制、自动门解锁等。
软件组件之间的通信是通过使用虚拟功能总线的特定端口实现的。这些端口还可以实现软件组件和 AUTOSAR 基础软件 (BSW) 之间的通信。
客户端-服务端通信：客户端可以通过支持操作的服务端发起操作的执行，服务端执行操作并立即将结果提供给客户端（同步操作调用）。
发送者-接收者通信：这是一种异步通信模式，其中发送者提供一个或多个接收者所需的数据。
RTE 层为应用软件组件提供独立于 ECU 的接口，为应用软件组件(SWC)提供通信服务。
客户端/服务端端口，其中服务端是服务的提供者，客户端是服务的用户。 发送方/接收方端口，发送方将信息发送到一个或多个接收方。
AUTOSAR 基础软件 ( BSW ) 进一步分为三层：
服务层，
ECU抽象层，
微控制器抽象和复杂设备驱动程序 (CDD)。
每一层都有不同的功能模块，不同层之间的模块交互都是指定的。
微控制器抽象层是基础软件的最底层，这意味着 MCAL 模块可以直接访问硬件资源。MCAL 包含内部驱动程序，这些驱动程序是直接访问 µC 和内部外围设备的软件模块。
顾名思义，MCAL 层使上层独立于 HW（MCU）。
操作系统功能 车联网通讯及管理服务 内存服务（NVRAM 管理） 诊断服务（UDS、错误处理、内存） ECU状态管理、模式管理 逻辑和时间程序流监控（WdgM）
AUTOSAR COM模块详细说明
本节列出了 AUTOSAR COM 模块所有功能模块。有关 AUTOSAR COM 模块在通信堆栈中的放置，请参阅下图。
该模块是AUTOSAR MCAL层的一部分（例如：CanDrv，LinDrv，FrDrv），它实际上与ECU的底层硬件进行交互，并为其上层提供独立于硬件的接口。此模块取决于硬件，并且驱动程序代码可能会根据基础硬件而有所不同。BusIf是唯一可以访问此总线驱动程序的模块。
多核微控制器的分层软件架构
随着汽车领域对计算资源的需求越来越高，OEM和Tier 1正在逐步引入多核 ECU 在其电子架构中的使用。此外，这些多核 ECU为新功能的引入提供了基础， 例如功能安全要求的实施。
AUTOSAR 4.0 版引入了对多核嵌入式 RTOS 的支持。AUTOSAR 4.0 规范中引入了多核启动/关闭、核间通信 (IOC) 等新概念，以扩展单核操作系统规范。
改进后的 Autosar 架构如下所示：
功能安全
系统的安全性取决于特定功能的预期操作。功能安全标准 ISO26262 源自 IEC-61508，指导我们采用基于汽车特定风险的方法来开发电气和电子 (E/E) 系统。功能安全的目标是正确执行预期操作，否则系统将发生故障并转移到可预测的安全状态。软件是影响系统级复杂性的参数之一。可以使用软件开发的新技术和概念来最小化复杂性，从而有助于实现功能安全。AUTOSAR R4.0 考虑了对现代汽车软件开发很重要的功能安全方面。
Autosar下有很多开发方法来检测和报告软件开发每个阶段的功能错误。即使功能安全在整个产品开发的每个阶段都适用并遵循，直到涉及到用户。
以下是导致 E2E 保护检测到的错误的典型干扰源列表：
SW相关来源：
S1。大多数生成的 RTE 中的错误，
S2。部分生成和部分手动编码的 COM 中的错误
S3. 网络堆栈错误
S4. 生成的 IOC 或 OS 出错
硬件相关资源：
H1。硬件网络故障
H2。网络电磁干扰
H3. 上下文切换期间或内核之间通信时的微控制器故障
开发 SWC 接口时采用的一个实用方法示例是为数据正确性提供端到端保护。
对于每个传输安全相关数据的 RTE Write 或 Read 函数（如 Rte_Write_<p>_<o>()），都有对应的 E2E 保护封装函数。
封装函数调用 AUTOSAR E2E 库。
包装函数是软件组件的一部分，最好是生成的。
封装函数与相应的 RTE 函数具有相同的签名，只是代替Rte_ 的是E2EPW_。
E2EPW_ 函数由 SW-C 的应用逻辑调用，封装函数执行保护/检查并在内部调用 RTE 函数。
对于 ECU 间通信，通过 E2E 保护发送的数据元素是按字节数组。字节数组被复制到 COM I-PDU 而不做任何更改。
ECU 设计和配置方法
AUTOSAR 为系统开发步骤提供了一种通用的技术方法。该图显示了使用 AUTOSAR 技术构建 ECU 的设计步骤概览。这意味着必须为系统中的每个 ECU 执行这些步骤。
需要注意的是，AUTOSAR 没有规定执行开发活动的精确顺序。Autosar 既不讲述流程，也不讲述商业模式和“角色”和“责任”。
下图是通常遵循的工作流程的示例。下图分别描述了 BSW 和应用软件的开发流程。
此阶段的主要活动是从系统配置描述中提取特定于 ECU 的信息、ECU 配置以及可执行 ECU 软件的生成。以下部分将更详细地描述这些活动。
提取特定于 ECU 的信息
AUTOSAR ECU Configuration Extractor工具（例如 System Desk，Da-Vinci）从特定 ECU 所需的系统配置描述中提取信息。这是映射到此特定 ECU 的系统配置描述的所有元素的一对一副本。输出是系统配置的 ECU 摘录。网络数据库（例如 CAN.dbc）文件是生成 ECU 提取物 (.arxml) 的输入。
配置（BSW）ECU
ECU 配置主要处理RTE 和基础软件模块的配置。该配置基于系统配置的 ECU 摘录中可用的参数。可用 SWC 实现和 BSW 模块描述的集合。BSW 还包含供应商特定的 ECU 配置。这是必要的，因为输出 ECU 配置描述具有灵活的结构，在 ECU 提取时不定义固定数量的配置参数。
必须在 BSW 配置期间定义通信模块、MCAL、操作系统或 AUTOSAR 服务。
软件组件实现
SWC 的初始工作从提供软件组件描述 [SWCTempl] 的必要部分开始。即组件内部行为描述作为软件组件相关模板的一部分。内部行为描述了组件的调度相关方面，即可运行实体及其响应的事件。此外，行为指定组件（或更准确地说是哪个可运行组件）如何响应接收到的数据元素等事件。但是，它没有描述组件的详细功能行为。