（图片来源主要来源于Simulink 以及 Vector）
在Autosar官网（autosar.org）上，目前CLASSIC PLATFORM 更新到4.4版本，ADAPTIVE PLATFORM更新到19.03版本，期盼已久的Adaptive Autosar终于有了基本构架。Adaptive Autosar 不是针对Classic Autosar的升级替换，它的出现主要面对汽车更复杂的需求，包括自动驾驶、车联网以及域控制等，而传统的ECU依然采用Classic Autosar进行开发，同时他们共存在未来智能汽车中，他们可以通过以太网进行交互。本文主要针对当前Adaptive 的信息进行汇总说明。
上面图片来自Simulink，我们看到其中的RTE在Classic Autosar中，而ARA（Autosar Run-time For Adaptive）是Adaptive Autosar的实时运行环境，他们主要区别是 Classic RTE基本是静态配置的，而Adaptive ARA则是动态的，并且Application就像我们在电脑上安装软件一样可以安装、升级、卸载。
上面图片来自Vector，我们看到其实整体的差别还是比较大的，Adaptive Autosar中保留了部分Classic的基础服务，例如诊断、网络管理等，而新增了很多新的服务如升级与配置、健康管理、执行管理、状态转移等。操作系统由之前的Autosar OS 变为POSIX（可移植操作系统）如Linux等。
以下进行一些对比说明：
| 比较项 | Classic | Adaptive |
| 使用语言 | C | C++ |
| 实时性 | 硬实时 | 软实时 |
| 适用场景 | 传统ECU，如ECM、VCU、BMS、MCU等 | 自动驾驶、辅助驾驶、车联网 |
| 功能升级 | 一般ECU开发后比较固定 | 可灵活在线升级 |
| 安全等级 | 最高到ASILD | ASILB（目标还是到D） |
| 主要通信方式 | CAN、LIN | 以太网 |
| 操作系统 | Autosar OS（OSEK OS） | POSIX |
架构分层主要分为硬件层，基础服务层，ARA（实时运行环境），以及应用层。
基础服务层中，主要服务包括，通信服务（COM）、加密服务（crypto）、日志记录服务（Log）、诊断服务（Diag）、存储服务（Per）、状态管理（SM）、执行管理（Exec）、时间同步（Tsync）、升级配置管理（UCM）等
（以下几点主要来自Matlab）
从上节我们知道Application就是OS的一个一个进程，Autosar 采用一个Manifest用来配置管理这些进程信息，包含平台相关的信息，恢复操作以及与服务或库相关的依赖关系，Instance 配置文件主要包含静态的信息，这里会配合执行管理Exec、升级与配置管理UCM以及状态管理SM等来配合管理进程。
采用Proxy/Skeleton的通信架构，同时采用中间件SOME/IP。
客户端 -->服务端
具体服务请求方式如上图（vector图）所示：1. 代理请求服务--2.服务传输--3.调用服务--4.结果响应--5.获取结果。
服务端-->客户端
具体事件请求过程如下：1.服务端事件请求--2.事件传输--3.事件存储--4.用户事件处理。
执行管理负责系统初始化以及Adaptive Applications的启动和关闭。 它使用Manifest文件中包含的信息来执行这些任务，包括何时以及如何启动可执行文件。
启动阶段：进行OS的启动，根据应用的manifest文件中的描述，进行应用程序的启动与执行。
运行阶段：使应用运行在状态机所期望的状态，并监测状态机状态的改变和进程的终止。
关闭阶段：在操作系统中结束结束应用实例的进程。
Adaptive Autosar也同样使用UDS诊断服务，只是物理层采用以太网方式，同时也可以看到应用层通过com服务来请求诊断服务。
主要通过per模块的服务来针对关键数据进行存储或实现流存储。
