目录
1、Adaptive AUTOSAR 简介
Adaptive平台: 一种新的 AUTOSAR
1.1 Adaptive的案例
1.2 经典平台与适应性平台的比较
1.3 单一系统
1.4 架构
逻辑架构
1.5 软件架构
本文图片来源 博世ETAS AP AUTOSAR ，如有侵权，请留言联系作者删除，谢谢。
在过去的30-40年中，在汽车环境中使用软件——无论是以功能的数量还是复杂性来衡量——已经从简单的发动机管理系统发展到在车辆平台中普及。
AUTOSAR Classic 平台是为了应对汽车软件日益复杂的需求而开发的。该平台的特点是支持硬实时性、高安全性、低资源拥有属性 ECUs，因此非常适合于传统的汽车用例。Classic 平台仍然是功能性汽车 ECUs 的明显选择，这些 ECUs 直接连接到传感器和执行器，依赖于低资源使用率和经典的实时性能。然而，有一些明确的趋势推动着 ECU 开发的未来发展，从而推动了 E/E架构的发展，这些趋势可以通过以下要求加以总结:
互联——连接车辆需要高带宽的动态数据连接，以进行故障管理、路边基础设施互动、实时更新前方道路状况的 ADAS 系统、空中软件更新OTA等。
自动驾驶——自动驾驶和辅助系统(ADAS)旨在减少驾驶员的工作量。ADAS 系统要求 E/E 架构集成先进的传感器和支持算法，涉及高性能计算机处理(HPC) ，如计算机视觉、传感器融合的对象模型等。
共享——代理服务、移动即服务、应用程序
电气化——新的动力总成要求，电池管理
总的来说，这些需求被称为 CASE ——互联、自动驾驶、共享、电气化的缩写。
驱动下一代汽车 E/E 架构发展的 CASE 需求正在以不断增长的速度促进汽车 ECUs 的变化:
自动化，需要处理大型数据集，例如计算机视觉或基于多传感器输入的真实世界对象模型的推导。大数据需要应用程序内部的并行处理这些数据的内在并发性，并及时生成解决方案。高性能计算需要平台支持新的硬件架构，例如异构处理器，gpu，多核心，处理器网格架构等。这样的硬件需要平台和编程语言的支持，应用程序要扩展到能够从它们部署到的新的 HW 和动态环境中获益。
连通，无论是从车辆到外部的连通，还是从车辆到外部的连通性，都需要动态通信和有效地分发大量数据，例如，数据采集和分析系统产生的大量数据集，例如图像处理，必须有效地并行处理，并与特定伙伴进行通信。
新技术(如以太网)带来的动态高通信带宽，意味着通信带宽不是限制因素。
作为一种服务的移动性要求灵活的 SW 是安全的，但可以更新以反映新的功能或法规要求。
已经尝试使用经典 AUTOSAR 来满足 CASE 需求。例如，相对简单的驾驶辅助系统，如车道跟踪和自适应巡航控制已经成功地实现了使用经典 AUTOSAR。然而，当多个这样的系统定义在一辆车的结果是，许多 ECUs 可以决定影响车辆的安全，如是否加速或停止！为了确保没有冲突发生，协调多个决策所需要的开销导致系统复杂性和所需测试的大量增加。因此，需要一个新的高性能、高灵活性的平台，支持高性能计算、动态通信和增量变化，能够在离开传统 AUTOSAR 平台的车辆内执行集中决策任务，以满足功能性 ECUs 的实时性和安全性要求。
将当前的汽车 ECUs 分为功能性 ECUs 或信息娱乐 ECUs 是很方便的(图2.1)。
图2.1: Classic、 Adaptive 和 Infotainment ECUs 的特征
AUTOSAR 经典平台已经被开发为非常适合于功能性 ECUs。这些 ECU 的特点是拥有属性强的实时性(期限可能在微秒范围内，满足所有的期限对于 ECU 的正确操作是至关重要的)和强大的安全要求ASIL-D。它们通常也有低资源可用性(无论是 CPU，RAM 或 Flash) ，需要完全静态配置的最佳使用。
相比之下，信息娱乐 ECUs 运行在一个高资源环境中，通常是由于用户界面的要求。一个信息娱乐 ECU 通常不是一个实时系统，因为期限如果存在的话，可以在100毫秒左右，操作通常不是正确操作的关键，如果操作根本没有发生，那么缺失的功能不是车辆操作和/或乘员安全的根本。最后，一个信息娱乐 ECU 通常运行在一个嵌入式 PC 上，运行成熟的操作系统，例如 Linux，而不是汽车操作系统。
Adaptive AUTOSAR 的设计是为了搭建两个世界之间的桥梁，提供一个具有灵活软件和高资源可用性的实时执行环境。Adaptive平台 ECU 的特点是具有软实时性(截止时间可能在毫秒范围内，偶尔错过的截止时间不是灾难性的)和一些安全要求 -- AUTOSAR 打算为Adaptive平台提供中等级别的 ASIL，尽管实现可以选择符合更高级别的 ASIL，或者可以使用诸如安全分解等体系结构技术来实现更高级别的 ASIL (拥有属性)。然而，与 Classic 不同的是，它的目的是使用基于 POSIX 标准的多核、动态操作系统的高资源环境。
Adaptive平台的实现可以使用有计划的动态来限制平台的动态方面，以支持可预测的执行或资源消耗。Planned dynamics 可能会将动态内存分配限制在启动阶段，预先确定服务发现过程，将应用程序分配给特定的核心，或者确保只访问文件系统中预先存在的文件。
AUTOSAR 希望 Adaptive 和 Classic Platform 实例能够在一个系统中共存，因为这两个平台可以处理不同的问题空间。Adaptive ECUs 支持需要动态通信和高性能的决策制定 ECUs，通过高度并行的架构结合动态 SW 变化的应用程序独立更新。相比之下，Classic ECUs 支持功能性 ECUs 直接操作传感器和执行器，并且在严重资源受限的环境中要求高安全性、实时 SW。
然而，Adaptive 和 Classic Platform 共享一个共同的基础，其中包含两个平台的核心元素，如核心需求、 SOME/IP 中间件等。使 Classic 和 Adaptive 之间的互操作成为可能，例如，提供了将 Classic 的基于信号的通信与 Adaptive 的面向服务的通信相连接的方法。
Foundation 定义了 AUTOSAR 的主要需求; 其中一些是 Classic 和 Adaptive 的共同需求，而另一些是一个平台的独特需求。
例如，支持深度嵌入式系统的核心 AUTOSAR 需求仅适用于 Classic，而支持高性能计算的需求仅适用于 Adaptive Platform。这两个要求都没有说 Classic 不能支持高性能，也没有说 Adaptive 深度嵌入只是各自平台形式的优势不同。
AUTOSAR 提供了标准化的应用程序编程接口，例如通信和持久存储，使应用程序在不同的平台实例之间具有可移植性。然而，虽然 Classic 和 Adaptive 都提供了在不同平台实现之间的可移植软件，但这些平台可以使用完全不同的方法，例如 Classic的基于信号的通信和 Adaptive 的面向服务的通信，因此在为 Classic 开发的软件和为 Adaptive 开发的软件之间没有可移植性。
低资源 ECUs 非常适合 Classic 平台，因为硬件需求比Adaptive要简单得多; 例如，单个地址空间不需要虚拟地址。然而，在 Adaptive 中，应用程序之间更复杂的隔离需要 MMU 支持。此外，Classic 平台有一个静态定义的配置，所有的任务，信号等在配置时都是固定的。相比之下，Adaptive 支持动态通信和并发，为应用程序提供更高的灵活性，以响应其环境或规模，以适应部署机器。然而，这种灵活性是有代价的。在 Classic 中，应用程序直接从 flash 执行，但是在 Adaptive 中，应用程序可以从文件系统加载到 RAM 中。这意味着 Adaptive 可以支持 SW 的增量更改，而不需要重新更新整个 ECU。
Adaptive 只是一个动态的 RTE 吗？是... ... 也不是！在 Classic 平台中，
RTE 执行两个任务:
调度应用程序 SWCs
应用程序 SWCs 之间的通信。
这些角色分别存在于 Adaptive Platform (操作系统、执行管理和通信管理)中，但是在 Adaptive Platform 中没有 RTE 的直接模拟。
平台的逻辑体系结构描述了平台软件是如何组成的，例如，体系结构中存在哪些模块、它们的接口以及用户应用程序如何与平台交互。
AUTOSAR Classic Platform 的逻辑架构包含定义良好的层，每一层都有精确定义的角色和接口。AUTOSAR Classic 平台的一个主要特点是所有配置都是静态的，RTE 实现固定软件组件之间的通信，调度使用固定优先级的固定任务集等。AUTOSAR 经典平台的静态特性对于满足高安全性、高实时性、资源有限的 ECUs 的要求至关重要。Classic Platform 中模块之间严格定义的接口使得来自不同供应商的模块能够一起工作——至少在理论上是这样，即使这在实践中很少使用——但是限制了平台软件中的实现和优化的可能性。
Adaptive Platform 的逻辑架构(AUTOSAR R19-11的图2.2)将平台功能划分为 Adaptive Foundation 和 Adaptive Services，每个功能都由功能集群组成。
一个功能集群是功能的集合、规范要求、软件等。而不是一个单一的软件模块，因为内部平台优化的潜力。这种区别反映在功能性集群的命名中，例如 Execution Management 而不是 Execution Manager，因为它代表管理执行的功能，而不是运行时组件的活动。
Classic 和 Adaptive Platforms 都标准化了平台和应用程序之间的接口，使用户软件能够从一个平台实例移植到另一个平台实例。然而，在Adaptive平台中，功能集群之间的接口不是由 AUTOSAR 定义的，因为每个Adaptive平台实例都被认为来自单一供应商。这意味着平台内部的架构接口可以被优化，并且不受限于遵循逻辑架构。
与典型的平台层软件体系结构相比，Adaptive Platform 具有反映平台需求的模块化软件体系结构。主要的动机是支持分配给机器的软件的更新
图2.2: Adaptive平台逻辑体系结构(AUTOSAR R19-11)
这就产生了一个动态平台架构，它不仅支持增量式软件更新，而且还支持当软件集不再是静态的时候出现的灵活、动态、通信和调度的紧急需求。
Adaptives platform 软件体系结构使用面向服务的应用程序(SOA)体系结构。因此，Adaptive Applications 通过网络上的通信协议提供和请求服务——一个具有良好界面的独立功能单元。一个服务可以远程访问，独立于其他支持松散耦合分布式应用开发的服务进行操作和更新。
客户端基于(半)正式的服务描述(定义服务功能)来发现和访问所提供的服务。在 AUTOSAR 中，服务描述是 ARXML 服务接口(Adaptive Studio 支持 DSL，以便更容易地定义服务、软件组件等。参见第4.2节)。
面向服务的体系结构(SOA)支持有效、灵活和适应性强的解决方案，因为它本质上促进模块化设计和高度内聚和松散耦合的服务的部署。模块化是确保的，因为服务描述代表了服务的功能性，因此是服务客户端唯一的访问机制。因此，只要服务描述不变，服务是可以被新的实现替代的，或者可以被不同的服务替代而不影响用户。所需的高内聚力和松散耦合源于服务定义，它需要一个“定义的结果”，自然而然地创建执行单个任务并避免紧密耦合解决方案的服务。
SOA 对可伸缩性也有很好的支持。提供的服务可以自动复制以利用额外的硬件，例如，在运行时创建额外的服务实例以确保使用特定平台变体上的所有处理单元。使用SOA，很容易添加新的服务来支持新的功能，因为提供的服务是独立于任何现有服务的。
本文图片来源 博世ETAS AP AUTOSAR ，如有侵权，请留言联系作者删除，谢谢。
