汽车基础软件AutoSAR自学攻略(三)-AutoSAR CP分层架构(2)
下面我们继续来介绍AutoSAR CP分层架构，下面的文字和图来自AutoSAR官网目前最新的标准R24-11的分层架构手册。该手册详细讲解了AutoSAR分层架构的设计，下面让我们来一起学习一下。
Introduction介绍
目的及投入
本文档的目的
分层软件架构描述了 AUTOSAR 的软件架构：
➢ 它以自上而下的方式描述了 AUTOSAR 软件的层次结构，并且
➢ 将基础软件模块映射到软件层，并且
➢ 展示了它们之间的关系。
这份文件侧重于概念分层软件架构的静态视图：
➢ 它没有指定具有详细静态和动态接口描述的结构化软件架构（设计）
◼ 这些信息包含在基本软件模块自身的规范中。
Scope and Extensibility
AUTOSAR 的应用范围
AUTOSAR 专门用于汽车电子控制单元（ECU）。此类 ECU 具有以下特性：
➢ 与硬件（传感器和执行器）的强交互，
➢ 连接到诸如 CAN、LIN、FlexRay 或以太网等车辆网络，
➢ 计算能力和内存资源有限（与企业解决方案相比）的微控制器（通常为 16 位或 32 位），
➢ 实时系统，以及
➢ 从内部或外部闪存执行程序。
注意：在 AUTOSAR 的概念中，ECU 指的是一个微控制器加上外围设备以及相应的软件/配置。机械设计不在 AUTOSAR 的范围内。这意味着如果在一个外壳中布置了不止一个微控制器，那么每个微控制器都需要其自身的 AUTOSAR-ECU 实例描述。
AUTOSAR 可扩展性
AUTOSAR 软件架构是一种通用方法：
➢ 标准模块的功能可以扩展，同时仍保持合规，
◼ 但它们的配置必须在自动基本软件配置过程中予以考虑！
➢ 非标准模块可以作为复杂驱动程序集成到基于 AUTOSAR 的系统中，
➢ 不能添加更多层。
Top view
AUTOSAR 架构在最高抽象级别上区分了三个软件层：应用程序、运行时环境和在微控制器上运行的基础软件。
Coarse view
AUTOSAR 基础软件在以下层中进一步划分：Services 服务、ECU Abstraction ECU 抽象、Microcontroller Abstraction 微控制器抽象和Complex Drivers 复杂驱动程序。
详细视图
基本软件层进一步细分为功能组。服务的示例包括系统服务、内存服务和通信服务。
Microcontroller Abstraction Layer 微控制器抽象
微控制器抽象层是基础软件的最低软件层。它包含内部驱动程序，这些内部驱动程序是能够直接访问微控制器（µC）和内部外设的软件模块。
任务： 使更高的软件层独立于微控制器（µC）
特性：
实现：取决于微控制器
上层接口：标准化且与微控制器无关
ECU Abstraction Layer ECU 抽象层
ECU 抽象层与微控制器抽象层的驱动程序相连接。它还包含外部设备的驱动程序。
它提供了一个 API，用于访问外设和设备，无论它们的位置（微控制器内部/外部）以及它们与微控制器的连接方式（端口引脚、接口类型）如何。
**任务：**使更高的软件层独立于 ECU 硬件布局
特性：
实现：微控制器（µC）独立，电子控制单元（ECU）硬件相关
上层接口：微控制器（µC）和电子控制单元（ECU）硬件独立
Complex Drivers Layer复杂驱动程序层
复杂驱动程序层从硬件延伸到 RTE 。
任务： 提供集成特殊用途功能的可能性，例如设备驱动程序：
➢ 不在 AUTOSAR 中指定的；
➢ 具有非常高的时间限制的；
➢ 用于迁移目的等。
特性：
实现：可能取决于应用程序、微控制器（µC）和电子控制单元（ECU）硬件
上层接口：可能取决于应用程序、微控制器（µC）和电子控制单元（ECU）硬件
Services Layer服务层
服务层是 BasicSoftware 的最高层，其与应用软件的相关性也适用：虽然对 I/O 信号的访问由 ECU 抽象层涵盖，但服务层提供：
➢ 操作系统功能
➢ 车辆网络通信和管理服务
➢ 内存服务（NVRAM 管理）
➢ 诊断服务（包括 UDS 通信、错误内存和故障处理）
➢ ECU 状态管理、模式管理
➢ 逻辑和时间程序流程监控（WdgManager）
任务： 为应用程序、RTE（实时环境）和基本软件模块提供基础服务。
特性：
实现：主要是微控制器（µC）和电子控制单元（ECU）硬件独立
上层接口：微控制器（µC）和电子控制单元（ECU）硬件独立
RTE Runtime Environment 实时环境
RTE 是为应用软件（AUTOSAR 软件组件和/或 AUTOSAR 传感器/执行器组件）提供通信服务的一层。在 RTE 之上，软件架构风格从“分层式”转变为“组件式”。AUTOSAR 软件组件通过 RTE 与其他组件（ECU 内部和/或外部）和/或服务进行通信。
任务： 使 AUTOSAR 软件组件独立于到特定 ECU 的映射。
特性：
实施：电子控制单元（ECU）和特定应用（针对每个 ECU 单独生成）
上层接口：完全独立于电子控制单元
服务类型介绍
基础软件可细分为以下几类服务：
➢ 输入/输出（I/O）
对传感器、执行器和 ECU 板载外设的标准化访问
➢ 内存
对内部/外部内存（非易失性内存）的标准化访问
➢ 加密
对包括内部/外部硬件加速器在内的加密原语的标准化访问
➢ 通信
对以下内容的标准化访问：车辆网络系统、ECU 板载通信系统和 ECU 内部软件
➢ 车外通信·
对以下内容的标准化访问：车对 X 通信、车内无线网络系统、ECU 车外通信系统
➢ 系统
提供可标准化的（操作系统、定时器、错误存储器）和 ECU 特定的（ECU 状态管理、看门狗管理器）服务和库函数
驱动（内部）
驱动程序包含控制和访问内部或外部设备的功能。
内部设备位于微控制器内部。内部设备的示例有：
➢ 内部 EEPROM
➢ 内部 CAN 控制器
➢ 内部 ADC
内部设备的驱动程序被称为内部驱动程序，并且位于微控制器抽象层中。
驱动（外部）
外部设备位于微控制器之外的 ECU 硬件上。外部设备的示例有：
➢ 外部 EEPROM
➢ 外部看门狗
➢ 外部闪存
外部设备的驱动程序称为外部驱动程序，位于 ECU 抽象层中。它通过微控制器抽象层的驱动程序访问外部设备。通过这种方式，AUTOSAR 也支持集成在系统基础芯片（SBC）中的组件，如收发器和看门狗。
➢ 示例：具有 SPI 接口的外部 EEPROM 的驱动程序通过 SPI 总线的处理程序/驱动程序来访问外部 EEPROM 。
异常： 用于内存映射外部设备（例如外部闪存）的驱动程序可能会直接访问微控制器。这些外部驱动程序位于微控制器抽象层，因为它们依赖于微控制器。
Interface接口
一个接口（接口模块）包含了对在架构上位于其下方的模块进行抽象的功能。例如，一个从特定设备的硬件实现中抽象出来的接口模块。它提供了一个通用的 API，以访问特定类型的设备，而不受该类型现有设备数量的影响，也不受不同设备硬件实现的影响。
该接口不会更改数据的内容。
通常，接口位于 ECU 抽象层。
示例：CAN 通信系统的接口提供了一个通用的 API，可独立于 ECU 内 CAN 控制器的数量以及硬件实现方式（片上、片外）来访问 CAN 通信网络。
Handler处理
处理程序是一种特定的接口，用于控制一个或多个客户端对一个或多个驱动程序的并发、多重和异步访问。即它执行缓冲、排队、仲裁、复用。
处理程序不会更改数据的内容。
处理程序的功能通常被并入驱动程序或接口中（例如 SPI 处理程序驱动程序、ADC 驱动程序）。
Manager管理
在纯处理程序功能不足以从多个客户端进行抽象的所有情况下，都需要一个管理器为多个客户端提供特定服务。
除了处理程序功能外，管理器还可以评估、更改或调整数据的内容。
通常，管理器位于服务层
示例：NVRAM 管理器管理对内部和/或外部存储设备（如闪存和 EEPROM 存储器）的并发访问。它还执行分布式和可靠的数据存储、数据检查、提供默认值等操作。
Introduction to Libraries库函数介绍
库是用于相关目的的函数集合。
库：
➢ 可由 BSW 模块（包括 RTE）、SW-C、库或集成代码调用
➢ 在相同保护环境中于调用者的上下文中运行
➢ 只能调用库
➢ 是可重入的
➢ 没有内部状态
➢ 不需要任何初始化
➢ 是同步的，即它们没有等待点
