AutoSAR Classic Platform和Adaptive Platform 区别
概述
本文主要内容分为两章节。第一章节简要介绍了AUTOSAR的软件架构，设计理念以及方法论，对Classic Platform和Adaptive Platform做了简单的比较。第二章主要介绍了Adaptive Platform的特性。
第一章 AUTOSAR架构介绍
AUTOSAR(AUTomotive Open System ARchitecture)是汽车和软件行业领先公司的全球合作联盟，为智能移动开发和建立标准化的软件框架以及开放的E/E系统架构。考虑到目前和未来市场中不同的汽车E/E架构，AUTOSAR联盟为汽车软件架构建立了开放的行业标准。因此AUTOSAR有两种含义，一是代表AUTOSAR联盟，二是代表AUTOSAR软件架构。
AUTOSAR 组织
随着AUTOSAR标准的完善以及广泛的应用，AUTOSAR联盟中的成员也是越来越多。这进一步推动了AUTOSAR软件架构的发展和应用。
官网：https://www.autosar.org/
AUTOSAR基本原理
相比传统软件架构，AUTOSAR在上层软件和底层硬件平台之间嵌入标准的中间层，实现了软硬件的解耦。AUTOSAR的口号是标准上协作，实现上竞争。
通过软硬件解耦，缩短研发周期和降低研发成本，同时通过软件的复用提升研发质量和效率。由于有统一的标准（软件接口，文件交换格式，方法论），因此OEM、供应商、工具提供商等可以协同开发，简化软件系统的集成，软件模块可以复用和高效率的衍生，提高了研发效率，降低整体软件的研发成本。
基本的AUTOSAR方法
下图是简化版的AUTOSAR开发工作流。AUTOSAR将应用软件和硬件平台进行解耦，在应用软件和基础软件与硬件之间嵌入虚拟功能总线，应用之间的通信或者访问硬件资源等都是通过虚拟功能总线进行资源交换。在Classic Platform中虚拟功能总线VFB为RTE层，在Adaptive Platform中虚拟功能总线为ARA层。由于AUTOSAR采用自上而下的方法论，从架构设计、接口描述，软件开发，功能组件集成都是采用模型开发。因此可以使用代码生成工具，将SWC(Software Component)描述文件、ECU描述文件、系统约束文件等导入工具后可以生成可执行代码。
未来的汽车产业挑战
2003年，汽车行业的高端玩家们发起了汽车嵌入式系统软件架构标准化项目——AUTOSAR(汽车开放系统架构)。2017年，为适应汽车的发展趋势（智能化，网联化等），应对汽车E/E系统开发面临的新的挑战（高性能处理器的应用，自动驾驶软件的实现，高带宽通信的需求，车与外界的互联互通，汽车E/E架构的演变等），AUTOSAR组织推出了AUTOSAR Adaptive Platform。
QoS=Quality ofService,服务质量
AUTOSAR的愿景和目标
AUTOSAR架构的特点
AUTOSAR 软件架构
Foundation
Foundation是Classic Platform和Adaptive Platform公共的部分，比如总线协议，方法论等
Classic Platform
CP平台是为硬实时和安全要求严格的嵌入式系统的提出的AUTOSAR解决方案。
Adaptive Platform
AP平台是为高性能计算的ECU提出的解决办法，用于自动驾驶等。
Acceptance Tests
AUTOSAR验收测试是总线级和应用程序级的系统测试，用于验证与应用软件组件和通信总线相关的AUTOSAR堆栈的行为
Acceptance Interface
AUTOSAR根据语法和语义为以下五个汽车领域标准化了大量的应用接口:车身和舒适性、动力总成发动机、动力总成传动系统、底盘控制以及乘员和行人安全。
AUTOSAR Classic Platform架构
Classic AUTOSAR将微控制器上的软件抽象为三个软件层：应用程序、运行时环境(RTE)和基本软件(BSW)。其中BSW分为三个主要层：服务层、ECU抽象层和微控制器抽象层。应用与应用之间，以及应用于BSW之间的通信都是经过RTE完成数据交换，因此做到了应用与硬件的完全独立。
Classic AUTOSAR是分层软件体系结构，软件需求在设计时通过每一层的静态配置来实现。因此，对于运行时的更改，它的灵活性较低，但是这点还是可以接受的，因为这个平台通常在车辆的生命周期内保持稳定，因为被控制的传感器和执行器的应用逻辑不会改变，传感器和执行器仍然履行它们本身的功能。
VECTOR Classic AUTOSAR架构
AUTOSAR Adaptive Platform架构
Adaptive AUTOSAR平台为AUTOSAR应用实现了运行环境ARA。使用两种接口完成数据交换：服务和API。平台由功能集群组成，这些集群按服务和自适应AUTOSAR基础进行分组如下。
Adaptive AUTOSAR解决了新一代汽车高性能需求、连接性和持续软件无线(OTA)更新带来的新市场需求，它作为多个供应商的软件集成平台，解决了Classic AUTOSAR经典架构的局限性，其为灵活性而设计的，以便在运行时支持软件更改。Adaptive AUTOSAR构建在POSIX操作系统之上，由不同的功能模块组成，这些模块被划分在服务模块和基础模块上,它的的通信是面向服务类型的，会将网络绑定到DDS或者SOME/IP使用以太网与其它ECU通信。
Adaptive Platform逻辑视图
Non-PF: 非平台服务: Non-platform service
VECTOR Adaptive AUTOSAR架构
AP与CP架构比较
AUTOSAR CP平台与AP平台特性比较
综上，AUTOSAR包含了Classic Platform和Adaptive Platfrom。Adaptive Platform并不是用来取代Classic Platform或者非AUTOSAR平台，而是为了相互兼容，协作并满足未来的需求。
EMS:Engine-Management-System发动机管理
第二章 Adaptive AUTOSAR特性介绍
技术范围和方法
智能ECU
现在的ECU的主要功能实现都是为了增强或者取代电子机械系统，所以现在的电子电器架构很多都采用线控系统。ECU内部的嵌入式软件根据输入的信号或者来自于车载网络的其他ECU的信息控制输出信号。许多软件是根据目标车辆设计和实现，在车辆的生命周期中不会发生根本性的变化。
未来的车辆功能，比如高级自动驾驶，会使得软件变得非常复杂且需要很高的算力，并且要满足严格的集成性和安全需要。这些软件实现了环境感知、行为规划等功能，并将车辆集成到外部后端和基础设施系统中。由于外部系统的发展或功能的改进，在车辆的生命周期中，车辆中的软件需要更改。正是由于这些需要，现在越来越多的车辆支持OTA功能，OTA功能就像我们使用手机一样，可以借助空中升级功能不断更新软件功能。功能的更新可能是修复一个BUG，或是增加一个功能，又或是增强一个性能等等，这种变化使能车辆具有不断升级的能力，也赋予了用户与车辆更多的粘性。
由于AUTOSAR Classic Platform(CP)标准不能完全解决以上需求，因此，AUTOSAR组织提出了AP平台的标准，AP平台主要提供了高性能的计算和通信机制以及灵活的软件配置，例如支持OTA软件升级。
技术驱动
技术驱动主要有两个方面，一个是以太网，另一个是处理器。
日益增长的车辆网络带宽需求帮助以太网应用在汽车网络通信中，提供了更高的带宽和交换网络，相比传统的车载通信总线，例如CAN总线，其带来了长消息的有效传递和点对点的通信。虽然CP也支持以太网通信，但主要是为传统通信技术设计和优化的，因此也是很难充分利于以太网的通信能力。
类似的，随着汽车功能越来越复杂，对于处理器的处理能力的需要也是逐年剧增。虽然多核处理器已经能够应用在CP平台，但是有些应用需要成百上千的多核处理器，比如GPU，专用加速器等应用相比传统MCU来说能够提供更高的性能。CP平台曾经是为了单核处理器设计，虽然现在也支持多核，但计算的最佳性能往往需要结合不同的计算资源，比如多核，协处理器，GPU，FPGA和加速器等。这种混合方式被称为异构计算，其能力远远超过了CP。
AP特性
AP包含的特性来自于未来的智能ECU和技术驱动两个方面。高性能的计算满足了安全的需要同时也需要很高的能耗，因此带来了许多新的挑战。为了应对这些挑战，AP采用了很多传统ECU未充分利用的技术。有如下几个方面
C++
Adaptive AUTOSAR平台的应用都将采用C++编程。虽然C语言是嵌入式系统的主要编程语言，具有执行速度快、效率高的特点；但是在性能要求非常高的复杂应用和算法开发上（如机器学习、图像特征识别等）具有面向对象特性的C++显然比C更具有优势。C++能够提供算法开发和性能均衡的软件。并且方便很快地适配和量产开发。
SOA
为了支持复杂的应用程序，同时在处理分布和计算资源分配方面允许最大的灵活性和可伸缩性，AP遵循SOA(service-oriented-architecture)的架构。SOA主要基于以下概念：系统由一组服务构成，其中 一个可使用另外一个的服务，应用程序可根据自己的需要使用一个或者多个服务；此外服务可以在应用程序运行的本地ECU上，也可以运行在另一个AP实例的远程ECU上。关于什么是SOA，目前还没有明确的结论。
官网：Scalable service-Oriented MiddlewarE over IP (SOME/IP) (some-ip.com)
并行处理能力
分布式计算本质是并行的。先进的多核异构处理器既具有强大的计算能力也能为并行计算提供技术支持，随着多核异构计算技术的发展，AP具有扩展其功能和性能架构的能力。事实上，硬件和接口规范仅是实现AP的一部分，在OS等技术和开发工具的发展上对实现AP的应用也至关重要。
利用现有标准
重新发明轮子是没有意义的，尤其在规范方面。正如已经在c++中描述的那样，AP采取了重用和适应现有开放标准的策略，以促进AP自身的更快发展，并从现有标准的生态系统中受益。因此，开发AP规范的一个关键重点是不要随意引入现有标准已经提供的新替代功能。例如，这意味着不会仅仅因为现有标准提供了所需的功能，但接口表面上不容易理解，就随意引入新的接口。
安全性
AP所针对的系统通常需要某种级别的安全性，可能是最高级别的安全性。新概念和技术的引入不应破坏这些需求，尽管实现这些需求并非易事。为了应对这一挑战，AP结合了体系结构、功能和过程方法。该架构基于基于SOA的分布式计算，这使得每个组件更加独立，避免了意想不到的干扰，具有专门的功能来帮助实现安全和保障，以及诸如c++编码指南之类的指导方针，它促进了像c++这样的复杂语言的安全使用。
动态计划
AP支持应用程序的动态部署，动态地管理资源和通信，以减少软件开发和集成的工作量，从而缩短迭代周期。在AP架构下，不同的应用可能由不同的供应商提供，因此在产品交付阶段，AP允许系统集成商合理限制这种动态部署的特性以降低不必要的风险和影响。
敏捷
敏捷尽管没有直接反映在平台功能中，AP的目标是适应不同的产品开发过程，特别是基于敏捷的过程。对于基于敏捷的开发，至关重要的是系统的底层架构是可增量扩展的，在部署后可以更新系统。AP的体系结构应该允许这样做。作为概念的证明，AP规范本身和演示者(AP的演示实现)都是用Scrum[^1]开发的。
[^1]: Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums. [1]
CP、AP和非AUTOSAR ECU的集成
综合以上的介绍，AP不会替代CP或者非AUTOSAR的平台。而是与这些平台以及外部后端系统(如路边基础设施)交互，形成一个完整的系统(图2-1不同平台部署示例、图2-2 AP与CP交互示例)。例如，CP已经包含了一些SOME/IP协议，AP也支持这些协议。
架构
我们将从逻辑视图，物理视图以及方法论三个方面了解自适应平台的架构。
逻辑视图
ARA
下图表示AP的架构，其中Adaptive Application(自适应应用)运行在ARA(AUTOSAR自适应应用的运行环境)之上。ARA是应用程序（AP中称为Adaptive Application）运行时的基础环境，可以提供多种本地功能供应用程序调用，这些本地功能在AP中统称为Function Clusters，其分为两个部分：Foundation Function Clusters和Service Function Clusters。
语言绑定，C++标准库，以及POSIX接口
这些API的语言基于C++绑定的，C++标准库也可以作为ARA的一部分使用。关于OS接口，只有POSIX标准的单进程概要文件(PSE51接口)作为ARA的一部分可用。选择PSE51是为了为现有的POSIX应用程序提供可移植性，并实现应用程序之间的自由干扰。
C++标准库包含许多基于POSIX的接口，也包括多线程接口。
应用启动和关闭
由Execution Management(EM)管理应用的生命周期。应用程序的加载/启动是通过使用EM的功能来管理的，它需要在系统集成时或运行时进行适当的配置才能启动应用程序。下图说明了不同类型的AP应用。
应用交互
对于AAs(Adaptive application)之间的交互，PSE51没有包含IPC (Inter-Process- Communication)，所以在AAs之间没有直接的交互接口。通信管理(CM)是唯一的显式接口。CM还为ECU内外部提供面向服务的通信。CM处理服务请求/响应的路由，而不管服务和客户端应用程序的拓扑部署。
非标准接口
AA和功能集群可以使用任何非标准接口，只要它们不与标准AP功能冲突，并且符合项目的安全性/安全性要求。除非它们是纯粹的应用程序本地运行时库，否则应该注意尽量减少这种使用，因为这将影响软件对其他AP实现的可移植性。
物理视图
OS，处理器，和线程
AP操作系统要提供多进程 POSIX OS的兼容性。每一个AA实现为一个独立的进程。自适应平台服务和非平台服务也实现为进程。
进程可以是一个单线程或多线程进程。可以使用OS API根据进程所属的逻辑层而有所不同。如果它们是运行在ARA之上的AAs，那么它们应该只使用PSE51。如果一个进程是功能集群之一，它可以自由使用任何可用的操作系统接口。
AA进程不能直接使用IPC，只能通过ARA进行通信。其他进程可以通过IPC或任何其他可用的OS功能相互交互。
基于库或基于服务的功能集群的实现
在图3-1 AP架构逻辑视图中，功能集群可以是自适应平台基础模块，也可以是自适应平台服务。如前所述，这两个过程通常都有。为了与同样是进程的AAs进行交互，它们需要使用IPC。有两种替代设计可以实现这一点。一种是基于库的设计，由功能集群提供的接口库链接到AA，直接调用IPC。另一种是基于服务的设计，流程使用通信管理功能，并有一个服务器代理库链接到AA。代理库调用通信管理接口，协调AA进程和Server进程之间的IPC。注意，它是由实现定义的，AA是否只直接执行IPC与通信管理或混合直接IPC与服务器通过代理库。为功能集群选择设计的一般原则是，如果它只在AP实例中本地使用，那么基于库的设计更合适，因为它更简单，也更高效。如果它以分布式方式从其他AP实例中使用，建议采用基于服务的设计，因为通信管理提供透明的通信，而不考虑客户端AA和服务的位置。自适应平台基础的功能集群是基于库的，自适应平台服务的功能集群是基于服务的。最后，需要注意的是，一个功能集群的实现可以没有进程，而是以库的形式实现，在AA进程的上下文中运行，只要它满足功能集群定义的需求规范和软件规范。在这种情况下，AA和功能集群之间的交互将是常规的过程调用，而不是像前面描述的那样基于IPC。
功能集群间的交互
通常，功能集群可以以AP实现的特定方式相互交互，因为它们没有绑定到ARA接口，比如限制IPC使用的PSE51。它可能确实使用了其他功能集群的ARA接口，这些接口是公共接口。功能集群之间的一个典型交互模型是使用功能集群的受保护接口来提供实现功能集群的特殊功能所需的特权访问。
机器/硬件
AP将其运行的硬件视为机器。背后的基本原理是，硬件可以使用各种与hypervisor相关的技术进行虚拟化，并实现一致的平台视图。在硬件上，可以有一个或多个机器，并且在一台机器上只能运行一个AP实例。通常假定该硬件包括一个芯片，托管一个或多个机器。但是，如果AP实现允许的话，多个芯片也可以组成一个机器。
方法论和清单
为了支持功能应用程序的分布式、独立和敏捷开发，需要在开发方法上采用标准化的方法。AUTOSAR自适应方法涉及到工作产品的标准化，用于描述工件(如服务、应用程序、机器及其配置);并在各自的任务中定义了这些工作产品应如何交互，以实现设计信息的交换，为自适应平台的产品开发所需的各种活动。图4.1说明了自适应AUTOSAR的开发工作流草案，其中涉及的步骤主要包含以下7步，最终将开发的软件集成入车辆中。
-
E/E Architect Define Services
-
ECU(Machine) Architect/Platform Software Cluster Architect
-
Software Cluster Architect
-
Application Developer
-
Software Cluster Integrator
-
ECU(Machine) Integrator
-
Vehicle Integrator
相关概念介绍：
Machine：在AP的概念体系中，Machine代表一种计算资源，它可以是真实存在的处理器，也可以是一个虚拟机，AP软件则运行在某一个特定的Machine上。
Manifest：Manifest是一种AUTOSAR模型的描述文件，主要包含AP软件部署涉及到的一些配置信息（比如Service Instance Manifest会包括服务接口的版本信息，SD参数信息等内容）
操作系统
概述
操作系统负责运行时的资源和时间管理。EM负责平台初始化和应用的启动和停止，与操作系统协同工作。
AP没有为高性能的处理器指定操作系统。而是，其定义执行上下文和操作系统接口供AP应用使用。
OSI(操作系统接口)规范包含了ARA中部分应用接口以及AP应用的标准接口。OS本身可以很好地提供其他接口，例如创建进程，这是执行管理启动应用程序所需要的。然而，提供此类功能的接口，以及其他接口，不能作为ARA的一部分使用，它被定义为依赖于平台实现。
OSI同时提供C和c++接口。对于C程序，应用程序的主要源代码业务逻辑包括在POSIX标准中定义的C函数调用，即在IEEE1003.13[1]中定义的PSE51。在编译过程中，编译器决定来自平台操作系统的哪个C库提供了这些C函数，应用程序的可执行文件应该在运行时被链接。对于c++程序，应用软件组件的源代码包括在c++标准及其标准c++库中定义的函数调用。
POSIX
市场上有几种操作系统，例如Linux，提供了POSIX兼容的接口。但是，与平台服务和基础相比，应用程序需要对操作系统使用更受限制的API。
一般的假设是，用户应用程序应该使用PSE51作为操作系统接口，而平台应用程序可以使用完整的POSIX。如果在应用程序级别需要更多的特性，它们将从POSIX标准中获取，而不是在任何可能的地方新指定。
自适应平台基础和自适应平台服务功能的实现可能会进一步使用POSIX调用。特定调用的使用将留给实现者，而不是标准化的。
调度
操作系统提供多线程和多进程的支持。标准的调度策略是SCHED_FIFO和SCHED_RR，由POSIX标准定义。其他如SCHED_DEADLINE或者任何其他操作系统规定的策略也被允许，但有一些限制，即这些策略可能不能跨不同的AP实现移植。
内存管理
支持多进程的原因之一是实现了不同功能集群和AA之间的自由干扰。操作系统对多进程的支持迫使每个进程处于一个独立的地址空间中，与其他进程隔离和保护。同一个可执行文件的两个实例在不同的地址空间中运行，这样它们在启动时可能共享相同的入口点地址和代码以及数据值，但是数据将在内存中的不同物理页中。
设备管理
设备管理将在POSIX的PSE51接口下提供。
执行管理
概述
EM负责系统执行管理的各个方面，包括系统初始化和应用的启停。EM与操作系统协同工作执行应用的调度。
系统启动
当机器启动时，操作系统会被首先初始化然后EM作为操作系统一个初始进程被启动。然后EM启动自适应平台基础的其他功能集群和平台级应用程序。自适应平台基础启动并运行后，EM将继续启动自适应应用程序。平台级应用程序和自适应应用程序的启动顺序由执行管理基于机器清单和应用程序清单信息决定。
EM的职责
EM负责AP平台和应用执行管理的各个方面，包括
1、平台生命周期管理
EM是自适应平台启动阶段的一部分，负责自适应平台和部署的应用程序的初始化
2、应用生命周期管理
EM负责已部署的应用程序的有序启动和关闭。EM根据机器清单和应用程序清单中的信息确定已部署的应用程序集，并根据声明的应用程序依赖项派生启动/关闭顺序。根据机器状态和功能组状态，部署的应用程序在自适应平台启动时或之后启动，然而，并不期望所有的应用程序都立即开始活动工作，因为许多应用程序将向其他应用程序提供服务，从而等待和侦听传入的服务请求。
执行管理不负责应用程序的运行时调度，因为这是操作系统的责任。但是，执行管理负责操作系统的初始化/配置，使其能够根据执行管理从机器清单和应用程序清单中提取的信息执行必要的运行时调度。
状态管理
状态管理提供了一种机制来定义自适应平台的操作状态。状态管理定义了AUTOSAR自适应平台的操作状态，由EM执行不同状态之间的转移。
EM有四种不同的状态：
-
Machine State
该状态主要用控制机器生命周期(Startup/shutdown/restart)，平台级的进程，和其他基础设施。在每台机器上都必须存在几个强制性的机器状态。其他特定于机器的机器状态可以在机器清单中定义。
-
Function Group State
该状态主要用于单独启动和停止功能一致的用户级应用进程组。它们可以在机器清单中配置。
-
Process State
该状态用于应用程序生命周期管理，并由执行管理内部状态机实现。
-
Application State
该状态描述了应用程序可执行程序的任何实例的内部生命周期，即进程。每个进程必须向执行管理报告应用程序状态更改。
如下图，显示了在状态管理请求了不同功能组状态之后，不同类型状态之间的交互的简化示例。可以看到功能组的状态转移，以及引用此功能组的一个状态的流程和执行状态。
通讯管理
概述
通信管理实现了自适应AUTOSAR应用程序之间面向服务的通信，适用于所有级别的通信，如进程内、进程内、机器间。它由潜在生成的服务提供者骨架和服务请求者代理以及可选的用于中央代理和配置的通用通信管理器软件组成。
通信管理提供了内置的安全机制，即E2E保护，其可以用于所有级别的对于事件和方法的通信。
面向通信的服务SOC
服务的概念意味着提供给应用程序的功能超出了基本操作软件已经提供的功能。通信管理软件提供了一些机制来提供或使用这些服务，用于机器内部通信和机器间通信。
一个服务包括：
-
Events
-
Methods
-
Fields
通信伙伴之间的通信路径可以在设计时、启动时或运行时建立。该机制的一个重要组件是充当代理实例的Service Registry，它也是Communication Management软件的一部分。
每个提供服务的应用程序都在服务注册中心注册这些服务。要使用服务，消费应用程序需要通过查询服务注册表来查找所请求的服务，这个过程称为服务发现。服务发现可以发现所有本地和远程的服务实例。服务消费由Proxy（P1...P3）表示，应用可以选择使用哪一个服务实例。
语言绑定和网络绑定
通信管理提供了标准化的方法，即如何将已定义的服务呈现给应用程序实现者(上层，语言绑定)，以及服务数据在网络上的各自表示(下层，网络绑定)。这确保了源代码的可移植性和编译服务在不同平台实现之间的兼容性。
语言绑定定义了如何通过使用目标编程语言的方便特性将服务的方法、事件和字段转换为直接可访问的标识符。性能和类型安全(只要目标语言支持)是主要目标。因此，语言绑定通常是由由服务接口定义提供的源代码生成器实现的。
网络绑定定义了如何将已配置服务的实际数据序列化并绑定到特定的网络。它可以根据Communication Management配置(AUTOSAR元模型的接口定义)来实现，既可以解释生成的特定于服务的配方，也可以直接生成序列化代码本身。
网络绑定的三种方式：
-
SOME/IP网络绑定
-
基于Signal的网络绑定
-
DDS网络绑定
本地服务注册也是网络绑定的一部分。
请注意:语言绑定和网络绑定之间的接口被认为是通信管理软件内部的私有接口。因此，定义该接口的规范目前已超出范围。尽管如此，平台供应商还是被鼓励独立地为他们的软件定义这样的接口，以方便实现其他语言绑定(而不是c++)以及平台实现中的其他网络绑定。
生成c++语言绑定的代理和框架
c++语言绑定的上层接口提供了在AUTOSAR元模型的接口描述中定义的服务的面向对象的映射。
作为Communication Management软件开发工具的一部分，生成器生成c++类，这些类包含各个服务的字段、事件和方法的类型安全表示。
在服务实现端，这些生成的类被命名为服务提供者骨架。在客户端，它们被称为服务请求者代理。对于服务方法，服务请求者代理提供了同步(阻塞调用者直到服务器返回结果)和异步调用(被调用的函数立即返回)的机制。调用者可以同时启动其他活动，当服务器的返回值通过c++标准模板库(std::future)的特殊特性可用时，调用者可以接收结果。
可以对平台实现进行配置，使生成器创建模拟类，以便在相应的服务器还不可用时轻松开发客户端功能。同样的机制也可以用于对客户机进行单元测试。虽然代理类可以被客户端直接使用，但c++绑定的服务提供者骨架只是抽象基类。
服务实现应该从生成的基类派生并实现相应的功能。ara::com的接口还可以为端到端安全通信提供代理和框架。
这些接口的设计保证了应用程序的兼容性，无论端到端加密保护是打开还是关闭。
静态和动态的配置
通信路径的配置可以在设计时、启动时或运行时进行，因此被认为是静态或动态的。
完全静态配置:根本不需要服务发现，因为服务器知道所有的客户端，而客户端也知道服务器。
应用程序代码没有发现:客户机知道服务器，但服务器不知道客户机。事件订阅是应用程序中唯一的动态通信模式。
应用程序中的完整服务发现:在配置时不知道任何通信路径。服务发现的API允许应用程序代码在运行时选择服务实例。
RESTful通信
概述
通信栈ara::com和ara::rest都可以在AP应用之间建立通信路径。ara::rest是一个构建RESTful API的框架，以及在RESTful API之上构建特定服务的框架。它没有定义特定的开箱即用的API来直接构造RESTful服务。这个框架是模块化的，它允许开发人员直接访问RESTful消息事务中涉及的不同层。相反，ara::com的重点是提供一个传统的函数调用接口，并隐藏超出这一点的事务的所有细节。另一个重要的区别是ara::rest确保了与非AUTOSAR对等点的互操作性。例如，一个ara::rest服务可以与一个移动HTTP/JSON客户端通信，反之亦然。
What's the RESTful？
REST：Represetational State Transfer（表象层状态转移）
1.每一个URI代表一种资源；2.客户端和服务器之间，传递这种资源的某种表现层；3.客户端通过四个HTTP动词（get、post、put、delete），对服务器端资源进行操作，实现”表现层状态转化”
架构
ara::rest的架构是基于模块化设计的，它支持API级别以及服务级别的设计。下图说明了它的总体设计。它描述了一个服务应用程序是如何在ara::rest中组成的。
ara::rest的通用REST层只提供了三个基本抽象:一个树状结构的消息有效负载(对象图)、一个URI和一个请求方法(比如HTTP中的GET或POST)。从这些基本的原语，特定于领域的RESTful api可以被组合起来，通过对象图、URI和方法定义一个具体的高层交互协议。它的目的是定义访问特定领域数据模型的规则，并为应用程序提供一个抽象(c++) API。当不需要进一步的抽象时，自适应应用也可以直接使用ara::rest，而不是使用这个域API。
组件
ara::reset包含以下组件的集合
Object Graph是一个独立的协议绑定的树形数据结构，其是所有ara::reset通信的基础。它的目的是映射到协议格式，如JSON和C结构体。这最大限度地提高了与非ARA通信节点和经典AUTOSAR的兼容性。对象图是以消息的形式传输的，这些消息完全从一个具体的底层协议绑定中抽象出来。如果需要，它们仍然允许用户访问特定于协议的详细信息。
在ara::reset的异步编程模式中，消息封装了request/replay通信周期的整个上下文。
路由概念提供了一种将请求(包括请求方法和URI)映射到用户定义的处理程序函数的方法。路由是将抽象从通用REST提升到特定类型的RESTful API的基础。
Uri是一种符合RFC的通用Uri表示，但它是一种高效的Uri表示。
ara::rest为服务器和客户端通信提供了所谓的(网络)端点，两者都提供了相当程度的资源控制。两者的设计都是为了在单核和多核系统上提供快速和高效的通信能力。
整个框架设计严格地面向最大限度的资源控制。可以严格控制和定制所有计算和分配，以满足应用程序(部署)的精确需求。
诊断
诊断管理实现了ISO 14229-5(UDSonIP)，其主要基于ISO 14229-1(UDS)和ISO 13400-2(DoIP)。
诊断管理是使用ara::com的自适应平台服务。因此，其是语言独立的，所以可以使用其他语言，比如在以后可以使用JAVA。配置基于Class Platform的AUTOSAR Diagnostic Extract Template(DEXT)。DEXT目前已经得到很多OEMs和Vendor使用。
诊断管理使用的传输层是DoIP。未来的自适应平台会支持其他的传输层比如CAN。也许还计划支持定制的传输层，因为DoIP通常不用作车载协议。
此部分的范围是去从自适应应用中抽象诊断协议。这些接口与经典平台(例如SetEventStatus)协调一致，允许经典平台开发者进行简单的更改。
诊断功能子集
诊断功能的子集类似于CP平台的DCM，实现了诊断的服务器。当前支持的服务是有限的，但是 UDS的服务会在以后进行扩展。
除了ISO 14229-1的伪并行客户端处理之外，还扩展了诊断管理器(Diagnostic Manager, DM)，以支持对不同诊断客户端的完全并行处理。这满足了现代汽车架构的需求，包括多个诊断客户端(测试器)用于数据采集、后端访问、SOTA(软件空中传输)，最后是经典的车间和生产用例。
事件记忆子集
事件记忆子集类似于CP平台的DEM，负责DTC管理。
支持的功能和接口和CP平台类似。监测的事件和一个DTC绑定。DTC可以分配为PrimaryMemory(通过19 02/04/06访问)或者配置UserMemories(经过19 17/18/19访问)。DTC可以存储快照和扩展数据。
对老化和就绪计算有重要影响的操作周期变化需要转发给DM。
同样，存储和启用条件的变化需要转发给DM，通过启用条件可以控制dtc的一般更新。例如禁止在电压低时禁止所有网络的监控。根据存储条件，DTC不能存储在DTC Memory。
持久化管理
概述
持久化管理提供应用在NVM中存储信息的机制。该数据可在启动和点火循环使用。持久化通常被实现为一个库，它运行在自适应应用程序的进程中，具有该进程的权限。
持久化管理库将存储位置标识符作为来自应用程序的参数，以寻址不同的存储位置。
可用的存储位置分为两类：
-
Key-Value Storage
-
File-Proxy Storage
每个应用可以使用多个存储类型的组合。
对于一个应用，存储的数据总是私有的。使用存储库不能在不同应用间共享数据。这一决定是为了防止在communication Management提供的功能之下出现第二个通信路径。
持久化管理对于存储的数据提供加密方法，确保敏感数据在写入物理设备之前进行加密。
Key-Value存储
键值存储提供了从一个存储位置存储和恢复数据的机制。支持的value类型是基础类型，C++ Plain Code数据结构和从这些类型派生的数组/容器。
每个Key-Value数据库的键必须是唯一的字符串，并且由应用程序使用存储库提供的方法定义。
File存储
并不是所有持久存储的数据类型都适合Key-Value机制，因此AP平台还支持File存储机制。
File存储提供对一组文件的访问，类似于文件系统的目录。
健康管理
概述
健康管理为AP应用在车辆内外提供保护信息交互的机制。包括ECU内外的通信机制。出于此目的，提供的机制允许在发生任何损坏时进行错误检测，没有保护数据完整性的机制。健康监控是ISO26262(控制流程监控、外部监控设施、看门狗、逻辑监控、时间监控、程序顺序监控)所要求的。
健康提供监控应用正确执行的机制。允许对检测偏差定义处理。
另外，安全对编码指引提供指导，有利于安全可靠的使用复杂的语言，比如C++。
信息交换的保护
最新的AUTOSAR E2E配置支持所有AUTOSAR AP和CP实例组合之间的安全通信，无论它们是在相同或不同的ecu中。在有用的情况下，将提供使用自适应平台中面向服务的更多功能的机制，以允许安全通信。所提供的功能提供了验证从发布者发送和由订阅者接收的信息在传输期间没有更改的可能性。根据AUTOSAR CP中的E2E机制，在E2E上下文中不提供传输确认和传输安全。
当在发布者和订阅者之间的通信中使用端到端保护时，在发布者的进程中同步调用端到端保护。在订阅者端，在接收订阅者流程中的数据时调用被选中的端到端。
平台健康管理
提供健康管理机制以支持fail-safe应用。包含如下方面
-
Alive supervision
-
Deadline supervision
-
Logical supervision
-
Error handing of supervision errors
-
Health Monitoring
C++编程指引
AUTOSAR C++ 14编码指南文档适用的主要应用领域是汽车，但它也可以用于其他在安全相关和关键环境中工作的嵌入式应用。AUTOSAR C++ 14编码准则适用于在32位和64位微控制器上，使用POSIX或类似操作系统，提供高效和完整的c++ 14语言支持的高端嵌入式微控制器。
现有的标准是不完整的，包括旧的c++版本，或者不适用于关键/安全相关的。特别是，MISRA c++:2008不包括c++ 11/14。多个新的语言特性需要分析它们在提供有效实现方面的作用，以及使用每个特性会带来多大的风险。
安全措施(Security)
概述
Security服务提供AP平台增强系统的方法，比如安全通信和访问管理系统。
身份和访问管理
我们建议AUTOSAR自适应平台采用身份和访问管理框架，以支持对各个AUTOSAR组件(自适应AUTOSAR应用程序、服务和功能集群)进行身份验证，并引入角色和权限管理功能的概念。使用IAM框架，这些应用程序可以查询基于现有策略的访问控制决策。查询将通过功能集群处理，因为应用程序没有与IAM框架的直接接口。在使用请求时，服务将能够利用指定的框架来评估请求者的权限和权利，并相应地实施相应的策略。
这个框架背后的思想是由日益增长的安全需求驱动的，因为AUTOSAR自适应平台需要与它的应用程序建立一个健壮的、定义良好的信任关系。如果攻击者破坏了应用程序，它不应该对自适应平台本身有任何影响，攻击者的能力应该被限制在被破坏的应用程序的能力。这就是为什么应用程序应该只能访问系统资源或触发它们应该执行的操作。IAM框架管理身份和访问权限，可以被视为一种可理解的机制，将应用程序的访问限制在必要的最低限度。
Crypto和Key管理
AUTOSAR自适应平台支持用于通用密码操作和安全密钥管理的API。该API支持在运行时动态生成密钥和加密作业，以及对数据流进行操作。为了减少存储需求，密钥可以存储在加密后端内部，也可以存储在外部，并根据需要导入。
该API旨在支持在单独的组件(如硬件安全模块(HSM))中封装安全敏感的操作和决策。通过将密钥限制到特定的使用(例如，仅解密)，或根据IAM的报告，将密钥的可用性限制到单个应用程序，可以提供对密钥和密钥使用的额外保护。
根据应用程序支持的不同，API还可以用于在处理TLS和SecOC等加密协议时保护会话密钥和中间秘密。
安全架构
Key管理
更新和配置管理
概述
AP平台提供一个很重要的能力是通过OTA(over-the-air)升级软件和配置。为此，AP平台提供Update and Configuration Manager(UCM)服务处理软件升级请求。
UCM负责升级，安装，卸载和记录AP平台的软件。它的角色类似于已知的包管理系统，如Linux中的dpkg或YUM，具有额外的功能，以确保以一种安全的方式更新或修改Adaptive Platform上的软件。
软件包处理
除了应用程序和配置数据，每个软件包都包含一个清单，提供元数据，如包名、版本和处理包所需的其他元信息。
软件包的数据内容可以包含一个或多个自适应应用程序，内核或固件更新，或更新的配置和校准数据。
UCM基于提供的元数据和Adaptive Platform软件信息处理软件包。
软件信息报告
UCM提供了服务接口，该接口公开了检索Adaptive Platform软件信息的功能，例如已安装软件的名称和版本。
软件更新的一致性
UCM确保只安装具有所有描述的依赖项的验证包。这样就不会安装不需要的或不合适的软件。UCM提供了一个读取安装结果的界面。如果在更新过程中出现故障，UCM将平台恢复到一个已知的功能状态。可恢复故障的一个例子是由于功率损失而中断的更新过程。
时间同步
概述
当需要跨分布式系统的不同事件的相关性时，不同应用程序和/或ECU之间的时间同步(Time Synchronization)是至关重要的，无论是为了能够及时跟踪这些事件，还是为了在准确的时间点触发它们。
由于这个原因，一个时间同步API被提供给应用程序，所以它可以检索与其他实体/ECU同步的时间信息。
时间同步功能是通过系统中不同的“时间基础资源”来提供的。
设计
对于AP平台，下面3种不同的技术应用满足时间同步的需要
-
CP平台的StbM模块
-
chrono库 - std::chrono (c++ 11)或boost::chrono
-
POSIX Time 接口
时间同步模块提供类似于CP平台StbM的功能，但带有一个std::chrono启发的API设计。
时间同步模块会考虑以下几个方面
-
Startup Behavior
-
Constructor Behavior(初始化)
-
Normal Operation
-
Error Handing
未来会考虑以下几个方面
-
Shutdown Behavior
-
Error Classification
-
Version Check
架构
应用程序将能够访问每个时间基础资源(Time Base Resource)的不同专门化类实现。TBR以资源的形式提供，就像在ara::com设计中提供服务一样，因此它采用了以下ara::com的架构设计模式
代理:类似于ara::com服务代理骨架模式，TS提供了一个资源代理模式，省略了骨架部分。
查找:类似于ara::com服务代理查找模式，TS提供了一个资源代理查找模式来提供对tbr的访问。
代理方法:类似于ara::com代理方法模式，TS使用的方法模式也遵循异步的Future模式。
当谈到避免延迟时，这种架构设计显然将时间同步设计置于正面冲突之中，因为后者是由ara::com API的设计模式的异步行为固有地添加进来的。
AUTOSAR利弊
随着AUTOSAR组织的日益扩大和越来越多的汽车行业开始使用AUTOSAR架构，我们有必要思考相比以往的软件开发，使用AUTOSAR架构有哪些利弊。
利弊在某种条件下是相互转换的，有利就有弊。目前AUTOSAR还是由外国几个公司主导，占据市场主要的几家AUTOSAR服务（软件以及工具）提供商有VECTOR、EB、ETAS、MENTOL,国内有普华基础软件，经纬恒润，东软睿驰，和华为等几家，但是市场占有率还是非常低。
AUTOSAR优势
-
标准化，大家在同一个起点开始竞争
-
缩短开发以及测试周期，快速适配不同车型和项目
-
缩减开发人员，降低测试要求
-
开发人员熟悉工具和简单理论即可开发，门槛低
AUTOSAR弊端
-
软件架构费用昂贵
-
代码逻辑复杂，选项众多，对于存储资源占用大
-
软件开发容易成为工具人，成就不高
中国AUTOSEMO介绍
官网：https://www.autosemo.com/
总结
AUTOSAR Adaptive还在逐步完善丰富，除了以上介绍的功能，最新的AP还扩展了Automated Driving Sensor Interfaces(自动驾驶传感器接口)、Intrusion Detection System Manager(入侵检测系统管理)等功能。随着AUTOSAR Adaptive的完善，其带给汽车系统诸多好处，比如提高所有制造商的开发效率，提高开发速度，缩短车辆子系统间接口的开发时间以及通过标准化提升功能安全，全球所有制造商都使用用一个平台，这样可以缩短系统与其他车辆的集成时间，提高系统之间的兼容性以及提升信息安全.