文章目录
1.Adaptive AUTOSAR和Classic AutoSAR特点
Classic AutoSAR是基于强实时性的嵌入式OS上开发出来的软件架构，能满足传统汽车定制化的功能需求，且能很好胜任；
但是一旦要汽车接入网络，网络很可能有延迟、干扰，很可能无法满足强实时性，这种情况下Classic AutoSAR就无能为力了，Adaptive AUTOSAR就诞生了。
由于Adaptive AUTOSAR安全级别基本还停留在ASIL-B（最高是D），所以很多需要强安全级别的ECU当下还是需要Classic AutoSAR（能满足ASIL-D）来实现。
- 对比结果如下：
AP和CP AutoSar关系如下： - Adaptive Autosar 不是针对Classic Autosar的升级替换，它的出现主要面对汽车更复杂的需求，包括自动驾驶、车联网以及域控制等
- 而传统的ECU依然采用Classic Autosar进行开发，同时他们共存在未来智能汽车中，他们可以通过以太网进行交互。
2.Adaptive AUTOSAR和Classic AutoSAR对比
基于Autosar经典平台开发的汽车控制器，具有如下特点：
- （1）硬实时，可在us时间内完成事件的实时处理，硬实时任务必须满足最后期限的限制，以保证系统的可靠运行。
- （2）高功能安全等级，其可达到ASIL－D的安全等级。
- （3）对CPU、RAM或Flash等资源具有较低的占用率。
- （4）软件功能通常是固化不可动态变更的。
Apdative Autosar作为异构软件平台的软件架构，Adaptive AUTOSAR主要用于域控制器，可以成为连接Classic AutoSAR和Linux这样的非实时OS的桥梁，其具有如下特点：
-
1、软实时，具有毫秒级内的最后期限，且偶尔错过最后期限也不会造成灾难性后果。
-
2、具有一定的功能安全要求，可达到ASIL－B或更高。
-
3、与经典平台不同的是，它更适用于多核动态操作系统的高资源环境，如QNX。
-
Adaptive Autosar与Classic Autosar相比，虽实时性要求有所降低，但在保证一定功能安全等级的基础上，大大提高了对高性能处理能力的支持，以支持智能互联应用功能的开发，因此C＋＋将成为Adaptive Autosar平台的主要开发语言。
-
AUTOSAR Adaptive的一个主要功能是通信层ara::com，它负责AUTOSAR Adaptive应用之间的通信，也负责与汽车中其他ECU之间的通信。
-
AUTOSAR Adaptive还为诊断、信息安全和功能安全提供功能支持。
-
这与AUTOSAR Classic基础软件非常相似，但是有一些架构和技术上的区别，例如ara::com是一个面向服务的中间件，这使得在运行期间动态创建通信路径成为可能，这种动态性是ECU运行期间安装软件的前提。
然而在AUTOSAR Classic中，需要首先修改通信矩阵，然后才能让ECU接收或发送新的内容。
使用面向服务的方法，可以动态建立服务的订阅，从而实现硬件驱动和上层软件更严格的分离，使得汽车中独立于硬件的应用变得高度可移植。 -
与基于AUTOSAR Classic的ECU相比，这种方式更加优化了资源配置。
例如，在开发阶段，如果某个ECU的资源达到上限，可以在不更改硬件的情况下把软件轻松地移植到另一个或另几个ECU上，软件组件在不同车型上的重用性大大提升。 -
在AUTOSAR Adaptive项目中，软硬件隔离使得OEM和供应商之间的任务分配有了新的变化。
从前一个功能块通常被作为汽车中的一个物理设备来订购，现在完全可以做到只采购软件。
为了实现这种方式，每个AUTOSAR Adaptive应用都是一个独立的二进制文件，应用开发将独立于ECU开发。
通过安装应用商店的应用，汽车司机自己也可以成为一个软件集成者。 -
但假如运行的系统出现了故障，谁该为此负责呢？未经测试的应用组合可以被安装在车辆上，这种情形和传统的ECU集成要求相冲突，AUTOSAR Classic下每一个配置都需要经过彻底的测试。
-
为了避免测试AUTOSAR Adaptive上所有应用的组合，必须保证应用之间无干扰。
操作系统可以保证安全相关的应用不会超过内存上限。
为了达到这个目的，操作系统提供硬实时调度方法，为应用定义内存上限和最差情况执行时间。因为没有与硬件的直接交互，中断导致的负载变化变得不再重要。 -
Adaptive Autosar的出现并不是为了取代Classic Autosar平台，而是针对不同的应用场景实现两者的共存和协作，Classic Autosar平台支持高安全性和高实时性的应用场景，因此对于深度嵌入式的软件功能需部署运行在经典平台上；
-
而Adaptive Autosar则支持大数据的并行处理，所以对于高性能运算的功能则需要运行在Adaptive平台上
Simulink中CP和AP的对比
- 看到其中的RTE在Classic Autosar中，而ARA（Autosar Run-time For Adaptive）是Adaptive Autosar的实时运行环境
- 他们主要区别是 Classic RTE基本是静态配置的，而Adaptive ARA则是动态的，并且Application就像我们在电脑上安装软件一样可以安装、升级、卸载。
Vector中AP和CP的对比 - Adaptive Autosar中保留了部分Classic的基础服务，例如诊断、网络管理等，而新增了很多新的服务如升级与配置、健康管理、执行管理、状态转移等。
- 操作系统由之前的Autosar OS 变为POSIX（可移植操作系统）如Linux等。
3.AP架构说明
-
架构分层主要分为硬件层，基础服务层，ARA（实时运行环境），以及应用层。
-
基础服务层中，主要服务包括，通信服务（COM）、加密服务（crypto）、日志记录服务（Log）、诊断服务（Diag）、存储服务（Per）、状态管理（SM）、执行管理（Exec）、时间同步（Tsync）、升级配置管理（UCM）等
4.AP关键点
关键概念1：一切都是OS中的进程
关键概念2：面向服务的进程间通讯
服务接口可以包含：
- 方法(函数)
- 时间(消息)
- 字段(数据)
关键概念3：以C++为方式实现
5.AP基础服务介绍
进程管理
- Application就是OS的一个一个进程
- Autosar 采用一个Manifest用来配置管理这些进程信息，包含平台相关的信息，恢复操作以及与服务或库相关的依赖关系，Instance配置文件主要包含静态的信息，这里会配合执行管理Exec、升级与配置管理UCM以及状态管理SM等来配合管理进程。
通信服务ara::com
- 采用Proxy/Skeleton的通信架构，同时采用中间件SOME/IP。
具体服务请求方式如下图（vector图）所示：1. 代理请求服务–2.服务传输–3.调用服务–4.结果响应–5.获取结果。
具体事件请求过程如下：1.服务端事件请求–2.事件传输–3.事件存储–4.用户事件处理。
执行管理 ara::em
- 执行管理负责系统初始化以及Adaptive Applications的启动和关闭。
- 它使用Manifest文件中包含的信息来执行这些任务，包括何时以及如何启动可执行文件。
启动阶段：进行OS的启动，根据应用的manifest文件中的描述，进行应用程序的启动与执行。
运行阶段：使应用运行在状态机所期望的状态，并监测状态机状态的改变和进程的终止。
关闭阶段：在操作系统中结束应用实例的进程。
诊断管理ara:diag
- Adaptive Autosar也同样使用UDS诊断服务，只是物理层采用以太网方式，同时也可以看到应用层通过com服务来请求诊断服务。
存储管理ara::per
-
主要通过per模块的服务来针对关键数据进行存储或实现流存储。
