总目录链接==>> AutoSAR入门和实战系列总目录

本系列文章由两部分组成：第一部分讨论了AUTOSAR 经典平台，该平台旨在基于微控制器的深度嵌入式 ECU。第二部分现在介绍了更新的自适应平台，它针对功能更强大的板式计算机以实现更高级别的功能。

AUTOSAR 自适应平台

动机

汽车的数字化并没有因高度嵌入式设备而停止，而是通过新的专用硬件实现了进一步的增长。在自动驾驶的保护伞下，更多高阶功能将被集成到未来的汽车中。

经典平台针对 C 编程语言和小型、高度嵌入式设备。自适应平台的目标是更高一个抽象级别。此级别包括更强大的硬件。两者都需要启用更复杂的用例。因此，自适应平台使用 C++ 编程语言，从 C++11 和 C++14 标准开始。目标硬件是功能强大的单板 PC，运行符合 POSIX PSE51 标准的操作系统，具有多核 CPU 和可能的高性能计算 (HPC) 功能。

标准

自适应平台位于深度嵌入式 ECU 世界（将保留经典）和信息娱乐设备世界（可能保持原样，或与移动市场更加融合）之间。实时性要求稍微宽松一些，但是毫秒级的延迟是可以接受的。所用硬件（多核 CPU、HPC 专用硬件）的更高性能可实现要求更高的功能。

另一个区别：计划动态。而在经典平台中，可变性通常必须在编译时处理，这意味着在开发 ECU 期间，自适应平台支持运行时服务发现。实际允许的灵活性程度（只能发现预配置的服务实例，或完全开放的发现）可以根据 SWC 指定。

在架构方面，自适应平台遵循与经典平台类似的主要模式：分层架构是标准化的，主要为应用程序提供与硬件无关的 API 和服务。下图以图形方式总结了这一点：AUTOSAR Runtime for Adaptive Applications (ARA) 成为经典平台 RTE 的精神继承者，提供了大量的库和服务。所谓的自适应应用程序是仅依赖于这些功能并变得完全可移植的应用程序。对于要求苛刻的用例，可能会引入不可移植的依赖项（例如，在专用硬件上），但会降低兼容 ECU 之间的可移植性。

自适应平台基础

该基金会由 11 个功能集群组成，可粗略地分为三类：基本功能、通信和安全保障。

基本功能

「执行管理」( ) 处理应用程序的状态和整个 ECU。上电和内核启动后，它开始系统初始化并控制所有其他应用软件组件的启动和终止。它可以通过清单进行高度配置，允许依赖于机器状态的活动应用程序集。为了便于使用，可以将相关应用程序捆绑在功能组中以获得通用的执行属性。ara::exec

「操作系统接口」(n/a) 指定自适应平台本身无法有效实现但托管操作系统无法有效实现的功能。这些功能是 (a) PSE51 合规性，(b) 内存和 CPU 的基本资源管理，以及 © 对时间触发执行的支持。该功能集群还确保操作系统 在主机系统初始化后将控制权移交给执行管理。

「记录和跟踪」( ) 为自适应应用程序和平台的其余部分提供 API 以记录事件。它支持严重性级别（调试、信息性、警告、错误）以及上下文和记录器 ID 的概念，以对消息进行分组和过滤。ara::log

「Persistency」 ( ) 为（只读）配置数据提供永久存储，读写特定于应用程序的数据格式。在功能方面，它支持错误检测和纠正。提供了基于文件的 API 和键值 API。ara::per

「时间同步」( ) 允许应用程序设置和检索公共时基。该功能集群本身不提供时基，但允许其用户充当时间提供者（主）或请求者（从）。不同的时基（本地、全局、同步）允许客户端维护自己的时基，或者在不同的 ECU 内部或之间进行同步。ara::tsync

通信

「通信管理」( ) 为应用程序和平台服务之间基于服务的通信提供了基础。它定义了服务接口，这是一种灵活的耦合机制，用于定义提供的和所需的接口。这些接口可以是方法（想想：远程过程调用）、字段（可读写共享内存）和事件（只读通知）。端口允许将多个接口组合在一起。CM 从底层协议或总线（vSOMEIP、CAN 等）中抽象出来。ara::com

「Restful communication」 ( ) 提供了一种正交通信范式，它较少连接或基于服务，但受到基于 Web 的无状态 API 的启发。这个功能集群提供了基本的构建块来创建自适应应用程序，这些应用程序提供 REST-ful 服务（服务器部分）或与其他服务（客户端部分）交互。ara::rest

安全保障

「身份和访问管理」( ) 提供类似于权限管理的机制，允许授予或拒绝自适应应用程序对自适应平台基础和服务的访问。ara::iam

「Cryptography」 ( ) 提供了一个标准化接口来访问多种加密算法的实现。这些包括随机数生成、散列算法以及几个对称和非对称密码。ara::iam

「平台健康管理」( ) 允许使用执行管理的 API 来监督自适应和平台应用程序。如果失败，可以配置特定的操作。可能的操作包括重启应用程序，或应用程序、功能组或 ECU 内的状态更改。ara::phm

自适应平台服务

从 R18-03 版本开始，有四种指定的自适应平台服务：

「诊断」( ) 提供统一诊断（UDS、ISO 14229）和 IP 诊断（DoIP、ISO 13400）中指定的服务。这包括诊断事件的概念，即错误、警告或故障，以及诊断通信，它处理上述事件从源到持久存储的传输。ara::diag

「信号到服务映射」( ) 提供了一个面向经典平台的兼容层。它将信号从经典平台转换为自适应平台中的服务。因此可以实现 CP 和 AP 软件组件之间的互操作性。ara::s2s

「网络管理」( ) 处理任何连接总线的状态管理，如果需要进行时间关键型通信，可能会保持总线处于活动状态。ara::nm

「状态管理」( ) 负责定义 ECU 的当前活动状态。对于更精细的粒度，所谓的功能组允许功能集群和/或自适应应用程序组的单独状态转换。在状态更改请求的情况下，它会触发执行管理以执行必要的更改。ara::sm

「更新和配置管理」( ) 提供了在 ECU 上安装新软件组件和升级现有软件组件的方法。支持无线 (OTA) 和基于车间（通过诊断设备）的用例。ara::ucm

DemonstratorDemonstrator

借助自适应平台，AUTOSAR 扩大了其范围，不再只是创建规范。除了之前发布和维护规范文档语料库的工作模式外，该联盟还选择在规范发布时附带说明性演示代码库，展示自适应平台基本软件堆栈在实践中的样子。但是，此自适应平台演示器 (APD) 未经过生产使用审查。虽然规范文档是公开的，但只有注册的 AUTOSAR 合作伙伴可以通过静态版本（R17-03、R17-10、R18-03）或最新的开发版本访问 Demonstrator 代码库。

实现

与经典平台一样，需要一个软件堆栈才能在生产中使用 AUTOSAR。下表列出了提供或已经宣布提供自适应平台软件堆栈的制造商：

VENDOR STACK
Elektrobit EB corbos AdaptiveCore
VectorVector 自适应显微镜

路线图

AUTOSAR目前正在准备2018年10月下旬发布R18-10，这个日期也标志着工作模式的转变，如下图所示。标准制定将从目前的发展阶段切换到更稳定的演进阶段。从那天起，Classic (CP) 和 Adaptive Platform (AP) 的发布周期将同步。这一变化将使推出同时影响两个平台的新功能变得更加容易。

自适应平台发布时间表。成熟度级别增加到 R18-10，然后质量稳定，同时继续发布功能。R18-10 计划与经典平台版本 4.4.0 同步。
下面是博主整理的AutoSAR入门和高阶实战笔记，可长按或扫码订阅。
图片