目录
Communication Hardware Abstraction
AUTOSAR 的ICC（Implementation Conformance Class）
2. Standardized AUTOSAR Interface
什么是autosar
AUTOSAR(AUTomotive Open System ARchitecture)，中文是“汽车开放系统架构”，是一家致力于制定汽车电子软件标准的联盟。他们制定了一套专门用于汽车的开放性的框架和行业标准，它将用作管理将来的应用程序和标准软件模块中功能的基本基础结构。
autosar 做了什么
AUTOSAR通过以下内容作了标准化：
- 软件接口
- 交换格式
- 方法论
同时具备以下优点或特点：
- 硬件和软件彼此广泛独立。
- 可以通过水平层将开发分离（通过抽象），从而减少开发时间和成本。
- 重复使用软件可提高质量和效率
- 将汽车系统的基础软件标准化为一个跨OEM的“标准栈”
- 集成不同供应商生产的功能模块，适用于不同的车辆及不同的车型
- 从软件中把硬件抽象出来，对于不同硬件平台具有更大的灵活性
- 通过对BSW的标准化提高了代码质量
- 竞争力只体现于对OEM的特殊功能要求的实现
- 重用性可以覆盖整个网络节点，甚至跨不同OEM
Foundation、CP、AP
Foundation目的是增强AUTOSAR平台之间的互操作性。
其基础包含在AUTOSAR平台之间共享的通用要求和技术规范（例如协议）。
Foundation确保了不同AUTOSAR标准的兼容性，因此包含了所有常见工件，例如
- 提供了描述AUTOSAR体系结构及其所有接口的方法
- 定义交换格式和描述模板（例如清单）以启用
-
- 无缝集成完整的车辆E / E架构，
- µC和µP软件堆栈的自动配置，以及
- 无缝集成应用软件
- 支持确保系统安全性的手段
- 提供用于记录标准的模板
CLASSIC PLATFORM （CP）
AUTOSAR Classic平台体系结构在运行在微控制器上的三个软件层之间的最高抽象层上有所区别：应用程序（Application），运行时环境（RTE）和基本软件（BSW）。
- 应用软件层主要与硬件无关。
- 软件组件之间的通信以及通过RTE访问BSW。
- RTE代表应用程序的完整接口。
- BSW分为三个主要层（服务，ECU（电子控制单元）抽象和微控制器抽象）和复杂驱动程序：
-
- 服务进一步分为代表系统，内存和通信服务基础结构的功能组。
ADAPTIVE PLATFORM
AUTOSAR Adaptive平台为 Adaptive Applications（ARA）实现AUTOSAR Runtime 。提供两种类型的接口：Service和API。该平台由按服务和Adaptive AUTOSAR基础分组的功能集群组成。
- 集成Adaptive平台的功能
- 定义需求规范的聚类
- 从应用程序和网络角度描述软件平台的行为
- 不限制实施Adaptive平台的体系结构的最终软件设计。
每台（虚拟）计算机的AUTOSAR Adaptive平台基础中的功能集群必须至少具有一个实例，而服务可能会在车载网络中分布。
与AUTOSAR Classic Platform相比，用于Adaptive Platform的AUTOSAR Runtime Environment在运行时动态链接服务和客户端。
基于autosar 开发
SWC
SWC，即Software Component，是封装了部分或者全部汽车电子功能的模块，其包括了其具体的功能实现以及与对应的描述。
例如，我们可以把Dimmer、Switch、Door Control设计成SWC
SWC分类：
- Atomic component (最小的逻辑单元，无法再分)
-
- Application（普通应用类）
- Sensor/actuator（给Application提供I/O控制等）
- Composition（可以包含数个SWC的逻辑集合）
Port
Port是SWC之间通信用，算是SWC的组成部分。
Port分两大类：S/R(Sender/Receiver)和C/S(Client/Server)
Runnables
Runnables，即Runnable entities，也是SWC的组成部分，但它是运行在RTE里面，由RTE周期事件触发或者其他事件触发时调用。Runnable包含着实际运行的函数。
RTE
RTE，Run Time Environment实时运行环境，是整个AUTOSAR架构运行的桥梁，各个模块SWC之间的通信不是直接交互的，而是经过该层作为运行的基础，RTE里包含着OS大量的运行策略和服务。RTE也是VFB（Virtual Functional Bus）的实现。
- RTE需要配置(e.g. 把runnables对应到OS的tasks中去)
- 通过RTE的事件触发runnables的运行
- 生成调用runnables的task代码
- 配置OS的一部分 (tasks, events, alarms)
- 实现SWC之间的通信
- 每个ECU的RTE因SWC的需求而异
- RTE抽象了OS，防止SWC直接访问OS和BSW
BSW
基础软件（BSW）可以按以下类型分：
- Input/Output (I/O)标准化访问sensors, actuators以及板上的外围器件。
- Memory
标准化访问内部或外部的Memory（NVM）。 - Crypto标准化访问密码原语，包括内部/外部硬件加速器
- Communication
标准化访问车辆网络系统，ECU车载通信系统和ECU内部软件 - Off-board Communication标准化访问车辆到X的通信，车辆无线网络系统中，ECU车外通信系统
- System提供标准化的（操作系统，计时器，错误存储器）和特定于ECU的（ECU状态管理，看门狗管理器）服务和库功能
MCAL
从底下往上讲，第一个Microcontroler Abstraction Layer（即MCAL），其有以下模块：
- Microcontroller Drivers具有直接µC访问权限的内部外围设备（例如看门狗，通用定时器）驱动程序（例如核心测试）
- Communication Drivers车载ECU（例如SPI）和车辆通信（例如CAN）的驱动程序。OSI层：数据链路层的一部分。
- Memory Drivers片上存储设备（例如内部闪存，内部EEPROM）和存储器映射的外部存储设备（例如外部闪存）的驱动程序。
- I/O Drivers用于模拟和数字I / O的驱动器（例如ADC，PWM，DIO）。
- Crypto Drivers用于SHE或HSM等片上加密设备的驱动程序。
- Wireless Communication Drivers用于无线网络系统的驱动程序（车载或车外通信）。
CDD
CDD即Complex Driver，它是用来实现BSW里面非标准化功能的。也就是说，标准化定义以外的功能可以通过CDD来实现，如UART，MCAL是没有定义UART的标准化的。
下面是基于 AUTOSAR CP 开发一个 CDD 的基本步骤：
- 定义接口：首先，你需要定义 CDD 和其他 AUTOSAR 软件组件之间的接口。这个接口应该包含所有需要的服务和操作，以便其他软件组件可以通过这个接口与 CDD 交互。
- 实现驱动：在定义了接口之后，你需要实现 CDD 的功能。这通常涉及到直接与硬件设备交互，包括读取硬件状态、发送命令到硬件设备，等等。
- 集成和测试：在实现了 CDD 之后，你需要将其集成到你的 AUTOSAR 系统中，并进行充分的测试，以确保它能够正确地与硬件设备以及其他软件组件交互。
- 文档和维护：最后，你需要创建适当的文档，描述 CDD 的功能、接口和使用方法。你还需要对 CDD 进行维护，以适应硬件设备或系统需求的变化。
I/O Hardware Abstraction
I/O Hardware Abstraction是一组模块，从外围I/O设备（片上或板上）的位置和ECU硬件布局（例如µC引脚连接和信号电平反转）中抽象出来。I/O硬件抽象不会从传感器/执行器中抽象出来！可以通过I /O信号接口访问不同的I/O设备。
Communication Hardware Abstraction
Communication Hardware Abstraction是一组模块，从通信控制器的位置和ECU硬件布局中抽象出来。对于所有通信系统，都需要特定的通信硬件抽象（例如，对于LIN，CAN，FlexRay）。
例如，ECU具有带2个内部CAN通道的微控制器和带4个CAN控制器的附加板载ASIC。CAN-ASIC通过SPI连接到微控制器。
可通过总线特定的接口（例如CAN接口）访问通信驱动程序。
Memory Hardware Abstraction
Memory Hardware Abstraction 是一组模块，从外围存储设备（片上或板载）的位置和ECU硬件布局中抽象出来。
例如，可以通过相同的机制访问片上EEPROM和外部EEPROM器件。可以通过特定于存储器的抽象/仿真模块（例如EEPROM抽象）访问存储器驱动程序。通过在闪存硬件单元顶部模拟EEPROM抽象，可以通过存储器抽象接口对两种类型的硬件进行通用访问。
Onboard Device Abstraction
Onboard Device Abstraction 包含用于ECU板载设备的驱动程序，不能将其视为传感器或执行器，例如内部或外部看门狗。这些驱动程序通过µC抽象层访问ECU车载设备
Crypto Hardware Abstraction
Crypto Hardware Abstraction是从加密基元（内部或外部硬件或基于软件）的位置抽象的一组模块。例如，AES原语在SHE中实现或作为软件库提供。
Crypto Services
Crypto Services包含两个模块：
- 加密服务管理器负责加密作业的管理
- 密钥管理器与密钥预配置主机（在NVM或加密驱动程序中）进行交互，并管理证书链的存储和验证
Communication Services
Communication Services是一组用于车辆网络通信（CAN，LIN，FlexRay和以太网）的模块。它们通过通信硬件抽象与通信驱动程序接口。
Memory Services
Memory Services由一个模块NVRAM管理器组成。它负责非易失性数据的管理（从不同的内存驱动器读取/写入）。
它以统一的方式向应用程序提供非易失性数据。内存位置和属性的摘要。提供非易失性数据管理机制，例如保存，加载，校验和保护和验证，可靠的存储等。
System Services
System Services是一组模块和功能，可由所有层的模块使用。示例包括实时操作系统（包括计时器服务）和错误管理器。
其中一些服务是：
- 取决于µC（例如OS），并且可能支持特殊的µC功能（例如Time Service），
- 部分依赖ECU硬件和应用程序（例如ECUM Management）或
- 硬件和µC独立。
它提供基本的申请服务以及基本软件模块
有专门的模块可用于AUTOSAR中错误处理的不同方面， 例如：
- 诊断事件管理器负责处理和存储诊断事件（错误）和相关的FreezeFrame数据。
- 诊断日志和跟踪模块支持对应用程序进行日志记录和跟踪。它收集用户定义的日志消息并将其转换为标准化格式
- 基本软件中检测到的所有开发错误都报告给默认错误跟踪程序。
- Diagnostic Communication Manager提供了用于诊断服务的通用API
- 其他的，等等
LIBRARY
Library实际上是很多functions的集合，它可以：
- 由BSW模块（包括RTE），SW-C，库或集成代码调用
- 在同一保护环境中在调用方上下文中运行
- 只能调用库
- 可重入的
- 没有内部状态
- 不需要任何初始化
- 是同步的，即它们没有等待点
AUTOSAR 的多核处理
并结合下图给出解释：
- BSW模块可以分布在多个分区和核心中。所有分区共享相同的代码。
- 每个分区上的模块可以完全相同，如图中I/O堆栈中的DIO驱动程序所示。
- 作为替代，他们可以使用依赖于核心的分支来实现不同的行为。Com服务和PWM驱动程序使用卫星主机通信来处理从相应卫星到主机的呼叫。
- 主站与卫星之间的通信不规范。例如，它可以基于BSW调度程序提供的功能，也可以基于共享内存。
- 箭头指示服务调用的处理涉及哪些组件，这取决于分发方法和调用的来源。
- 每个运行BSW模块的分区中的基本软件模式管理器（BswM）
- 所有这些分区都是受信任的
- 每个内核一个EcuM（每个在一个受信任的分区中）
- 通过引导加载程序启动的那个核心上的EcuM是主EcuM
- 主EcuM启动所有卫星EcuM
- 如图所示，IOC提供了通讯服务，这些客户端可以访问需要跨同一ECU上OS-Application边界进行通讯的客户端。IOC是操作系统的一部分。
- BSW模块可以在多个内核上执行，例如图中的ComM。在运行时确定负责执行服务的核心。
- 每个核心都运行一种ECU状态管理
AUTOSAR 的 safety 功能
AUTOSAR提供了一种灵活的方法来支持与安全相关的ECU，可以使用两种方法：
- 所有BSW模块均根据所需的ASIL开发
- 所选模块是根据ASIL开发的，ASIL和非ASIL模块分为不同的分区（BSW分发）
AUTOSAR 的ICC（Implementation Conformance Class）
ICC (Implementation Conformance Class) 是 AUTOSAR 标准中的一个概念，用来分类和定义汽车电子控制单元 (ECUs) 的软件架构实现。实质上，它描述了 ECU 软件的实现必须满足的 AUTOSAR 标准的子集。
以下是一些常见的 ICC 类别：
- ICC1: 这个类别的实现通常包括最基本的 AUTOSAR 架构组件，如 OS（操作系统）、RTE（运行时环境）和基本的通信堆栈。
- ICC2: 在 ICC1 的基础上，这个类别的实现增加了一些更复杂的功能，如诊断通信、网络管理和更复杂的 ECU 状态管理。
- ICC3: 这是最复杂的类别，包括了所有 AUTOSAR 标准的功能，如动态的RTE和多核OS支持等
当前，AUTOSAR并未将ICC2级别上的群集限制为专用群集，因为许多不同的约束和优化标准可能会导致不同的ICC2群集。 可能存在不同的AUTOSAR ICC2集群，可以根据要定义的ICC2遵从性方法声明符合性。
ICC1呢？
兼容AUTOSAR（ICC1-3）的基本软件（包括RTE）必须具有ICC3模块规范指定的外部性能。例如，针对以下行为：
- 总线
- 引导加载程序和
- 应用
另外，关于ICC3中的系统描述，ICC1 / 2配置应兼容。
AUTOSAR 的三种接口
1. AUTOSAR Interface
AUTOSAR Interface定义了软件组件和/或BSW模块之间交换的信息。该描述独立于特定的编程语言，ECU或网络技术。 AUTOSAR Interface用于定义软件组件和/或BSW模块的端口。通过这些端口，软件组件和/或BSW模块可以彼此通信（发送或接收信息或调用服务）。AUTOSAR使得可以在本地或通过网络在SoftwareComponents和/或BSW模块之间实现这种通信。
2. Standardized AUTOSAR Interface
Standardized AUTOSAR Interface是其语法和语义在AUTOSAR中标准化的AUTOSAR Interface。Standardized AUTOSAR Interface通常用于定义AUTOSAR服务，这是AUTOSAR基本软件向应用程序软件组件提供的标准化服务。
3. Standardized Interface
Standardized Interface是一种在AUTOSAR中标准化的API，无需使用AUTOSAR Interface技术。这些Standardized Interface通常是为特定的编程语言（如C语言）定义的。因此，通常在始终位于同一ECU上的软件模块之间使用Standardized Interface。当软件模块通过Standardized Interface进行通信时，将无法再通过网络路由软件模块之间的通信。
简单地理解，AUTOSAR Interface多用于Application、Abstraction于Complex Driver上；Standardized AUTOSAR Interface多用于BSW中的Service上；而Standardized Interface呢，是AUTOSAR定义的BSW中的模块直接交互用的接口。
108
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
