一、、、、AUTOSAR架构概览
随着汽车向智能化、、网络化、、信息化方向不断发展，，，车载微控制器的数量呈几何级增长，，，由于汽车元件生产厂商的差异，，，，导致汽车电子软件之间差异较大，，，不同厂家的软件不能复用。。。这不仅使汽车电子产品研发周期延长，，而且使汽车软件开发成本增加。。。
为此，，，，在2002 年，，，为解决上述问题，，，，宝马、、、、博世以及奔驰等知名企业联合起来提出了汽 车 网 络 开 放 式 架 构 标 准AUTOSAR，，旨在统一汽车软件领域。。次年，，，，他们便着手开展相关工作，，，开始绘制 AUTOSAR 的草图。。而对于这个要定义的统一架构，，，其具体涵盖哪些内容呢？？？彼时，，，一位工程师将自己的想法通过草图展现了出来。。。
在一次研讨会上，，，一位工程师向众人阐释AUTOSAR架构主要分为三层。。话音未落，，，会场突然安静，，，众人心中疑惑：这么简单的架构真能统一复杂的汽车软件吗？？？但这位工程师并未在意，，，，而是继续深入讲解。。。此架构关键在于基础软件（BSW）部分，，，它还可进一步细分为三层：
而应用（Application）部分与其他架构中的应用类似，，这里不再赘述。。。。另外，，运行时环境（Runtime Environment，，简称 RTE）值得一提，，，，它为应用提供通信服务，，，应用通过 RTE 能够访问 BSW 的功能，，，并且提供了统一标准的接口，，极大地增强了各模块的可移植性，，让各模块保持相对独立。。
随后，，，，工程师进一步细化架构图，，，并加以解释。。比如 Memory Service，，它能够让应用通过 RTE 进行调用，，，，还创建了很多便于应用访问的接口，，，，其实现方式是通过调用 Memory Hardware Abstraction 来访问 Memory Drivers。。。。通过这样的三层关系，，，基本能够满足市面上大部分功能需求。。不过，，，总会存在这几层架构无法实现的功能，，此时 Complex Drivers 就派上用场了，，，它允许用户自行定义，，，以实现一些复杂的驱动功能。。
以 Memory Service 为例，，，，它为 Application（应用程序）提供了便利，，能让 Application 通过 RTE（运行时环境）进行调用，，，并且设置了诸多可供应用程序访问的接口方法。。。而 Memory Service 访问 Memory Drivers（内存驱动程序）的方式，，，是通过调用 Memory Hardware Abstraction（内存硬件抽象层）来实现的。。。。
通过这三层关系就实现市面上大部分功能需求了。。。但是，，，总会有这几层实现不了的功能吧，，，，怎么办？？？？Complex Drivers就可以提供给用户自己定义啦，，，，可以做一些复杂的驱动。。。。
基础软件（BSW）按照功能类型还可细分如下：
Input/Output (I/O)：它实现对传感器、、、执行器及板上外围器件的标准化访问，，为不同设备搭建统一交互通道，，，，保障汽车电子系统采集与指令下达的准确与稳定。。。
Memory：规范对非易失性存储器（NVM）的访问，，，确保车辆重要数据能有序存储、、、、便捷读取，，支撑系统数据管理的高效和安全。。。
Crypto：提供密码原语访问标准，，，，涵盖内外部硬件加速器，，保障车辆关键信息传输时加密、、解密操作规范，，，，维护信息安全。。。
Communication：负责访问车辆内各通信系统，，，制定统一 “通信规则”，，，让 ECU 间及内部软件能顺畅交互、、、协同工作，，，，确保系统通信有序。。
Off-board Communication：专注车辆到外部通信的标准化访问，，，，在车与云端、、、、路侧单元等交互时，，确保按标准有序开展，，，助力汽车与外界互联互通。。。
System：提供操作系统等通用服务，，，，以及 ECU 特定服务（如 ECU 状态管理、、看门狗管理器等），，，，全方位支持系统运行，，，是保障汽车电子系统稳定可靠的关键所在。。。。
除此之外，，，，还有一个容易被忽略的部分 ——Library（库）。。它实际上是众多函数的集合，，，具备以下特点：
可被 BSW 模块（包括 RTE）、、软件组件（SW-C）、、、集成代码调用
在同一保护环境中，，，于调用方的上下文中运行
只能调用库自身内容
具有可重用性，，，，即可以被重复调用而不影响其功能和数据
没有内部状态，，，，不会因多次调用产生额外的状态变化
不需要任何初始化操作，，，调用时相对便捷
是同步的，，，，不存在等待点，，，调用过程较为直接
二、、、AUTOSAR的基础软件层
基础软件（BSW）在 AUTOSAR 架构中至关重要，，工程师对此进行了详细讲解，，，，参会人员也越发觉得 AUTOSAR 有望成为行业统一标准，，并期待了解更多细节内容。。。
2.1.MCAL（Microcontroler Abstraction Layer，，微控制器抽象层）
Microcontroller Drivers（微控制器驱动）：具备直接访问微控制器内部外围设备（例如看门狗、、、通用定时器等）的权限，，像核心测试等相关驱动程序都归属于此，，负责对这些内部设备进行驱动管理。。。
Communication Drivers（通信驱动）：涵盖车载 ECU（例如 SPI 接口相关）和车辆通信（例如 CAN 总线等）的驱动程序，，，，属于 OSI 层中数据链路层的一部分，，保障通信链路的正常运行。。。。
Memory Drivers（存储驱动）：负责对片上存储设备（例如内部闪存、、内部 EEPROM）以及存储器映射的外部存储设备（例如外部闪存）进行驱动管理，，，方便数据在不同存储介质中的读写操作。。。。
I/O Drivers（输入 / 输出驱动）：用于模拟和数字 I/O 的驱动器（例如 ADC、、PWM、、DIO 等），，，实现对各种输入输出信号的处理和控制。。
Crypto Drivers（加密驱动）：针对 SHE 或 HSM 等片上加密设备的驱动程序，，确保加密相关操作能顺利执行。。。
例如，，，，SPIHandlerDriver 允许多业务并发访问，，它抽象出了 SPI 的所有功能，，但用于 SPI 功能的 IO 在使用时不能另作他用，，，以此保证 SPI 功能的独立性和稳定性。。。。
2.2. CDD（Complex Driver，，，，复杂驱动）
CDD 用于实现 BSW 里面非标准化功能。。。。也就是说，，，，在标准化定义之外的功能，，，像 UART（通用异步收发传输器），，由于 MCAL 中没有对其进行标准化定义，，，，就可以通过 CDD 来实现相应功能。。
2.3. I/O Hardware Abstraction（I/O 硬件抽象）
这是一组模块，，，它的主要作用是从外围 I/O 设备（片上或板上）的位置以及 ECU 硬件布局（例如微控制器引脚连接和信号电平反转等情况）中进行抽象，，，但不会从传感器 / 执行器中抽象出来。。。可以通过 I/O 信号接口来访问不同的 I/O 设备，，以此简化对 I/O 设备的操作和管理。。。
2.4. Communication Hardware Abstraction（通信硬件抽象）
同样是一组模块，，，不过它是从通信控制器的位置和 ECU 硬件布局方面进行抽象。。。。对于不同的通信系统（例如 LIN、、CAN、、、FlexRay 等），，，，都需要特定的通信硬件抽象来进行适配。。例如，，，，当 ECU 具有带 2 个内部 CAN 通道的微控制器，，，并且还有带 4 个 CAN 控制器的附加板载 ASIC，，，且 CAN - ASIC 通过 SPI 连接到微控制器时，，就可通过总线特定的接口（例如 CAN 接口）去访问通信驱动程序，，确保通信的正常开展。。。。
2.5. Memory Hardware Abstraction（存储硬件抽象）
该模块是从外围存储设备（片上或板载）的位置和 ECU 硬件布局中抽象出来的一组模块。。例如，，，，能够通过相同的机制去访问片上 EEPROM 和外部 EEPROM 器件，，，并且可以借助特定于存储器的抽象 / 仿真模块（例如 EEPROM 抽象）来访问存储器驱动程序。。通过在闪存硬件单元顶部模拟 EEPROM 抽象，，，，还能通过存储器抽象接口对这两种类型的硬件实现通用访问，，方便了对不同存储硬件的统一管理。。
2.6. Onboard Device Abstraction（板载设备抽象）
包含用于 ECU 板载设备的驱动程序，，，，这里的板载设备不能简单视为传感器或执行器，，如内部或外部看门狗等设备。。这些驱动程序通过微控制器抽象层来访问 ECU 车载设备，，从而实现对相关板载设备的有效控制和管理。。。
2.7. Crypto Hardware Abstraction（加密硬件抽象）
它是从加密基元（内部或外部硬件或基于软件的加密元素，，，，例如 AES 原语在 SHE 中实现或者作为软件库提供等情况）的位置进行抽象的一组模块，，，便于对加密相关硬件进行统一管理和操作。。。。
2.8. Crypto Services（加密服务）
加密服务管理器，，其职责是对加密作业进行全面管理，，，，确保加密操作按要求有序执行。。
密钥管理器，，，，它负责与密钥预配置主机（在非易失性存储器 NVM 或加密驱动程序中）进行交互，，，并管理证书链的存储和验证工作，，，，保障加密过程中的密钥和证书管理安全可靠。。。。
2.9. Communication Services（通信服务）
是一组用于车辆网络通信（涵盖 CAN、、、、LIN、、、、FlexRay 和以太网等常见网络类型）的模块，，它们通过通信硬件抽象与通信驱动程序进行接口对接。。。。这部分涉及的内容较多且重要，，，比如涉及到 CAN、、、LIN 甚至 TCP/IP 等通信协议相关内容，，后续通常需要另外召开会议深入讨论，，，以更好地梳理和明确相关细节及应用。。。
讲到这里，，会上的其他人听着听着有些懵逼，，越讲越复杂了，，工程师停了下，，，说，，，，通信服务这部分，，涉及到CAN、、、、LIN甚至TCP/IP等，，，，内容很多也很重要，，后续尊龙时凯另外召开会议讨论吧。。。。
2.10. Memory Services（存储服务）
主要由一个模块 ——NVRAM 管理器构成，，，，它负责对非易失性数据进行管理（涵盖从不同的内存驱动器读取 / 写入数据等操作）。。。。它以一种统一的方式向应用程序提供非易失性数据，，，，包括对内存位置和属性等信息进行汇总整理，，，同时还提供诸如保存、、、加载、、校验和保护、、、验证以及可靠存储等非易失性数据管理机制，，，，确保数据的安全性和完整性。。。。
2.11. System Services（系统服务）
是一组可为所有层的模块所使用的模块和功能集合。。。。例如实时操作系统（包含计时器服务）以及错误管理器等都属于系统服务范畴。。。其中部分服务依赖于微控制器（例如操作系统本身），，，可能还会支持特殊的微控制器功能（例如时间服务）；部分服务则依赖于 ECU 硬件和应用程序（例如 ECU 状态管理），，，，还有些是与硬件和微控制器相对独立的。。它既为基本软件模块提供支持，，，，也为上层应用提供基本的服务保障。。。
另外，，，，在系统服务中，，，有专门用于处理 AUTOSAR 中错误处理不同方面的模块，，，比如：
诊断事件管理器，，负责处理和存储诊断事件（也就是错误）以及相关的 FreezeFrame 数据，，，，便于后续对故障进行分析排查。。。。
诊断日志和跟踪模块，，能够支持对应用程序进行日志记录和跟踪操作，，，，收集用户定义的日志消息并将其转换为标准化格式，，方便统一管理。。。。
基本软件中检测到的所有开发错误都会报告给默认错误跟踪程序，，确保错误信息能被及时知晓和处理。。
Diagnostic Communication Manager 提供了用于诊断服务的通用 API，，，，为诊断相关操作提供统一接口。。
三、、、、AUTOSAR的多核处理
此刻，，，，有人提问，，市面上μC更新换代非常快，，，性能也不断提升，，甚至有多核处理器，，，，这个架构如何应对多核处理？？？工程师想了想，，，show出了下图
并结合下图给出解释：
基础软件（BSW）模块可分布于多个分区和内核之中。。。所有分区共享相同的代码。。。
模块在每个分区上可以完全相同，，，如图中输入 / 输出（I/O）栈中的数字输入 / 输出（DIO）驱动所示。。
或者，，，，它们可以使用依赖内核的分支来实现不同的行为。。通信（Com）服务和脉宽调制（PWM）驱动使用主从通信方式来处理从相应从设备发往主设备的调用。。。
主设备与从设备之间的通信并未标准化。。。例如，，，它可以基于基础软件调度器提供的功能，，也可以基于共享内存。。。。
箭头表示根据分布方式以及调用来源，，哪些组件会参与服务调用的处理。。
在运行基础软件（BSW）模块的每个分区中都设有基础软件模式管理器（BswM）：所有这些分区都是受信任的。。。。
每个内核有一个电子控制单元管理器（EcuM）（每个都位于一个受信任分区内）。。
通过引导加载程序启动的内核上的电子控制单元管理器（EcuM）是主电子控制单元管理器（Master EcuM）：主电子控制单元管理器（Master EcuM）会启动所有从电子控制单元管理器（Satellite EcuMs）。。
四、、、AUTOSAR的Safety功能
那么，，，安全功能如何？？工程师都有考虑和准备：
AUTOSAR提供了一种灵活的方法来支持与安全相关的ECU，，，可以使用两种方法：
注意：分区基于OSApplications，，，，OS-Application的TRUSTED属性与ASIL/non-ASIL不相关。。。。
使用不同BSW分区的示例，，，看门狗堆栈放置在自己的分区中
ASIL和非ASIL SW-C可以通过RTE访问WdgM
BSW的其余部分放在自己的分区中
参考文档：
AUTOSAR_EXP_LayeredSoftwareArchitecture
服务热线：
0551-65691812
客户留言
0551-65691812
