AP AUTOSAR 2 —— Introduction to Adaptive AUTOSAR
目录
1_AUTOSAR到底是什么？
什么是AP，什么是CP？两者的关系？
2 Introduction to Adaptive AUTOSAR
2.1 The Adaptive Platform: A New AUTOSAR
2.2 The CASE for Adaptive
2.3 Classic and Adaptive: A Comparison
2.4 A Single System
2.5 Architecture
2.5.1 Logical Architecture
2.5.2 Software Architecture
AP核心模块和各模块的功能：
本文图片来源 博世ETAS AP AUTOSAR ，如有侵权，请留言联系作者删除，谢谢。
1 AUTOSAR到底是什么？
AUTOSAR说白了，可以认为它就是一套标准：
- 标准了我们ECU的开发流程；
- 标准了我们开发流程中的文件交换格式；
- 标准了我们ECU内部的代码应该如何去规范，如何书写。
AUTOSAR也是一个中间件：操作系统，中间件，应用软件-各司其职分工不同。
- 操作系统--我负责对硬件，提供线程创建等服务，其他我不管。
- 中间件--我负责和不同操作系统对接，并给上面应用提供通讯，资源管理等服务，其他我不管。
- 应用软件--具体的功能实现都是我的事，不同系统，不同硬件的事我不管。
中间件的核心思想在于“统一标准、分散实现、集中配置”。
技术目标：标准上合作，实现上竞争。
为什么需要上 AUTOSAR？
- 考虑系统的可用性和安全性，系统冗余的要求
- 考虑系统在不同的车辆，不同的ECU，不同的平台上可能需要进行裁剪
- 底层软件BSW作为一个标准的内核，来进行提供。
- 功能上需要能够通过网络进行传递，也就是说ECU的功能可以在网络上进行移植，
- 来自不同供应商提供的模块，要能够进行整合
- 考虑在整个产品的生命周期内，对产品的软件进行维护。
- 要尽可能多的使用现成的产品而不是要去单独开发，在汽车生命周期里进行软件更新的
- autosar平台应用的领域要覆盖汽车大部分领域，如车身、安全、底盘、人机界面和娱乐系统等。
什么是AP，什么是CP？两者的关系？
当前汽车控制器，如ECU与其他功能或信息娱乐性控制器有明显的不同，基于Autosar经典平台开发的汽车控制器，具有如下特点：
AUTOSAR经典平台ECU 的特点是硬实时性（截止时间可能在微秒范围内，并且满足所有截止时间对ECU的正确操作至关重要）具有很强的安全要求——ASIL-D。它们通常还具有较低的资源可用性（无论CPU时间，RAM或闪存），需要完全静态配置以实现最佳使用。
CP AUTOSAR的特点：
1、硬实时，可在us时间内完成事件的实时处理，硬实时任务必须满足最后期限的限制，以保证系统的可靠运行。
2、高功能安全等级，其可达到ASIL-D的安全等级。
3、对CPU、RAM或Flash等资源具有较低的占用率。
4、软件功能通常是固化不可动态变更的。
信息娱乐ECU通常不是一个实时系统，因为截止时间（如果存在的话）可能在100毫秒内，并且操作通常对正确操作不敏感——如果操作没有发生，则缺失的功能对车辆操作和/或乘员安全没有根本影响。
信息娱乐ECU通常在运行成熟操作系统（如Linux）的嵌入式PC上运行，而不是在汽车操作系统上运行。而Apdative Autosar则是连接这两者的桥梁，其具有如下特点：
AP AUTOSAR的特点：
1、软实时，具有毫秒级内的最后期限，且偶尔错过最后期限也不会造成灾难性后果。
2、具有一定的功能安全要求，可达到ASIL-B或更高。
3、与经典平台不同的是，它更适用于多核动态操作系统的高资源环境，如QNX。
4、AP 就是跑在操作系统上的一个应用程序。
RTE Runtime Enviroment在Classic Autosar中的运行环境
ARA（Autosar Run-time For Adaptive）是Adaptive Autosar的实时运行环境，他们主要区别是 Classic RTE基本是静态配置的，而Adaptive ARA则是动态的，并且Application就像我们在电脑上安装软件一样可以安装、升级、卸载。
我们看到其实整体的差别还是比较大的，Adaptive Autosar中保留了部分Classic的基础服务，例如诊断、网络管理等，而新增了很多新的服务如升级与配置、健康管理、执行管理、状态转移等。
操作系统由之前的Autosar OS OSEK 变为——> POSIX（可移植操作系统）如Linux，QNX等。
以下进行一些对比说明：
| 比较项 |
Classic |
Adaptive |
| 编程语言 |
C |
C++ |
| 实时性 |
硬实时 |
软实时 |
| 适用场景 |
传统ECU等 |
自动驾驶、车联网、娱乐系统等 |
| 功能升级 |
一般ECU开发后比较固定 |
可以灵活在线升级 |
| 安全等级 |
最高到ASL-D |
ASL-B（目标是达到ASL-D） |
| 主要通信方式 |
CAN、LIN 等(面向信号) |
以太网等（面向服务） |
| 操作系统 |
Autosar OS (OSEK OS) |
POSIX |
|
|
|
|
汽车的电子电气架构是不断进化的，之前传统的ECU软件和硬件是高度绑定的，一个软件有一个特定的功能，且在整个生命周期中不会升级，不同模块间通信的数量也较少。
这样就可以通过传统的域控制器来解决。每个域有一些控制器来管理整个域内的传感器。
如今或在未来的几年内，软件需要不断升级，比如之前中控屏的功能比较简单，现在的中控屏可以实现多维的展示，可以集成最新的娱乐功能，这些都可以通过OTA升级来不断更新，因此中央架构就出现了，将ECU的功能整合到几个高性能处理器中，外面连接传感器，这样可以节省ECU的数量，简化线束，简化布局，由于功能集中，统一底层且模块化，可以很方便的实现在线升级。
汽车的自动驾驶出现了很多新的需求，从L1过度到L3，为了实现L3以上的自动驾驶，需要能支持高算力芯片，同时能满足数据安全和功能安全的要求，有时还需要支持云端的数据传输，还有支持海量的数据流。
这些给整个系统架构带来了新的挑战，新的架构外围是getway负责高效的数据传输，中间的高性能控制器提供算例
从之前的域控制器架构——>到现在或者未来几年的高性能芯片连接的中心架构——>再到未来的将数据传输和运算算例分离的Zonal架构
随着下一代架构的智能网联化发展，要求一些节点具备处理海量数据和执行大规模高频次算例的能力，这就必然会要求此类节点具备丰富的软硬件资源，同时满足车载环境下安全性的要求。
该背景下，擅长用于嵌入式ECU的CP就显得心有余而力不足了。
引用其他资料：
三、Classic Autosar与Adaptive Autosar的比较
当前汽车控制器，如ECU与其他功能或信息娱乐性控制器有明显的不同，基于Autosar经典平台开发的汽车控制器，具有如下特点：
1、硬实时，可在us时间内完成事件的实时处理，硬实时任务必须满足最后期限的限制，以保证系统的可靠运行。
2、高功能安全等级，其可达到ASIL-D的安全等级。
3、对CPU、RAM或Flash等资源具有较低的占用率。
4、软件功能通常是固化不可动态变更的。
而信息娱乐性控制器，则正好与上相反，其一般会占用较大的硬件资源，且一般不具有实时性，因其一般运行在嵌入式PC上，如LINUX，而不是汽车级操作系统上，所以其即使出现故障也不会造成严重的安全事故。
而Apdative Autosar则是连接这两者的桥梁，其具有如下特点：
1、软实时，具有毫秒级内的最后期限，且偶尔错过最后期限也不会造成灾难性后果。
2、具有一定的功能安全要求，可达到ASIL-B或更高。
3、与经典平台不同的是，它更适用于多核动态操作系统的高资源环境，如QNX。
Adaptive Autosar与Classic Autosar相比，虽实时性要求有所降低，但在保证一定功能安全等级的基础上，大大提高了对高性能处理能力的支持，以支持智能互联应用功能的开发
因此C++将成为Adaptive Autosar平台的主要开发语言。
2 Introduction to Adaptive AUTOSAR
2.1 The Adaptive Platform: A New AUTOSAR
在过去的30~40年中，在汽车上使用的软件（无论是从功能的数量还是复杂性来衡量）已经从简单的发动机管理系统发展到在汽车平台中无处不在。
AUTOSAR Classic平台是针对日益复杂的汽车软件需求而开发的。该平台的特点是支持硬实时、高安全性、低资源可用性ECU，因此非常适合传统的汽车用例。Classic平台仍然是功能性汽车ECU的明显选择—这些ECU直接连接到传感器和执行器，这些传感器和执行器依赖Classic的低资源利用率和实时特性。然而，有许多明确可识别的趋势推动着ECU开发的未来增长，因此E/E体系结构的未来增长可以通过需求来总结：
- 连接性：用于故障管理和ADAS改进的数据收集、车上和车下的动态连接性、实时路况更新、空中软件更新。
- 自动化：驾驶员辅助和高度自主系统，使用计算机视觉、传感器融合。
- 共享所有权：代理服务、移动即服务、应用程序。
- 电气化：新的动力系统要求、电池管理。
2.2 The CASE for Adaptive
驱动下一代汽车电子/电气体系结构发展的案例需求正在以不断增长的速度推动汽车电子控制单元的变革：
自治性要求处理大数据集，例如用于计算机视觉或基于多传感器输入推导真实世界的对象模型。大数据要求应用程序内的并行性，以利用处理此类数据时固有的并发性并及时生成解决方案。
高性能计算要求平台支持新的硬件架构，如异构处理器、GPU、多核、处理器网状架构，如果应用程序要扩展到能够从部署到的新硬件和动态环境中获益，那么这样的硬件需要平台和编程语言支持。
- 连接，无论是从车辆到外部，还是从外部到外部，都需要动态通信和高效地分发大数据，例如，ADAS产生的大数据集（例如用于图像处理的数据集）必须高效地并行处理，并与特别合作伙伴进行通信。
- 新技术（如以太网）带来的动态高通信带宽，意味着通信带宽不是限制因素。
- 作为服务的移动性需要安全但可更新的灵活软件，以反映新的功能或法规要求。
已经尝试使用经典AUTOSAR来满足案例需求。例如，相对简单的驾驶员辅助系统（如车道跟踪和自适应巡航控制）已使用经典AUTOSAR成功实现。然而，当在一辆车内定义多个这样的系统时，结果是许多ECU可以负责影响车辆安全或动态的决策，例如是加速还是停车！协调多个决策ECUs以确保不发生冲突所需的开销导致系统复杂性和所需测试的大幅增加。因此，需要一种新的高性能、高度灵活的平台来支持高性能计算，动态通信和增量更改，可在车辆内执行集中决策角色，离开经典的AUTOSAR平台，以满足功能性ECU的实时性和安全性要求。
2.3 Classic and Adaptive: A Comparison
可以方便地将当前的汽车ECU分为功能ECUs或信息娱乐ECUs (Figure 2.1)
AUTOSAR Classic平台的开发, 非常适合功能性ECU。这些ECU的特点是具有强安全要求（ASIL-D）的硬实时性（截止日期可能在微秒范围内，满足所有截止日期对ECU的正确操作至关重要）。
它们通常也具有低资源可用性（无论CPU时间，RAM或闪存），需要完全静态配置以实现最佳使用。
相比之下，信息娱乐ECU通常由于用户界面的要求而在高资源环境中运行。信息娱乐ECU通常不是一个实时系统，因为截止日期（如果存在）可能在100毫秒内，并且操作通常对正确操作并不重要-如果操作从未发生过，则缺失的功能对车辆操作和/或乘员安全不是根本性的。最后，信息娱乐ECU通常在运行成熟操作系统（如Linux）的嵌入式PC上运行，而不是在汽车操作系统上运行。
Adaptive autosar旨在连接两个世界，提供具有灵活软件和高资源可用性的实时执行环境。自适应平台ECUs的特点是软实时（截止日期可能在毫秒范围内，偶尔错过的截止时间后果不是灾难性的）和一些安全要求AUTOSAR打算将中级ASIL用于自适应平台，尽管实现可以选择符合更高的ASIL或可以使用体系结构技术，如安全分解，以达到更高的水平。不过，与Classic不同的是，它适用于使用基于POSIX标准的多核动态操作系统的高资源环境。
自适应平台的实现可以使用计划的动态来限制平台的动态方面，以利于可预测的执行或资源消耗。计划的动态可能会将动态内存分配限制在启动阶段，预先确定服务发现过程，将应用程序分配给特定的核心，或确保仅访问文件系统中预先存在的文件。
随着无人驾驶技术的如火如荼，车联网及万物互连、云技术的日益发展，Adaptive Autosar的出现不仅可满足现有需求，还可满足未来汽车技术的革新变化，由于其支持各种自适应的部署、复杂的微控制器以及各种非Auosar系统的互动，未来汽车将拥有不同类型的架构并互相进行补充。
Adaptive AUTOSAR need to be :
- Safety
- Deterministic 确定性
- Follow AUTOSAR Standards Methodology as exchanges format 遵循AUTOSAR标准方法作为交换格式
- Dynamically Integrated :enables OTA upadtes with dynamic Integration 动态集成：启用具有动态集成的OTA升级
- Easy to maintain for 10 to 15 years 易于维护未来10至15年
2.4 A Single System
AUTOSAR期望自适应平台和经典平台实例将在单个系统中共存，因为平台处理不同的问题空间。
自适应ECU支持需要动态通信和高性能的决策ECU，这些ECU通过高度并行的体系结构，结合动态的软件更改来实现与应用程序无关的更新。
相比之下，经典的ECU支持功能ECU直接操作传感器和执行器，并在资源严重受限的环境中要求高安全性、实时软件。
但是，Adaptive和Classic平台共享一个共同的基础，包含两个平台的核心元素，如核心需求、SOME/IP中间件等。该基础使Classic和Adaptive之间的互操作成为可能；
例如，提供了将经典的基于信号的通信与自适应的面向服务的通信相结合的方法。
该Foundation定义了AUTOSAR的主要需求；有些是经典和自适应的共同需求，而另一些则是一个平台所独有的。
例如，支持深度嵌入式系统的核心AUTOSAR需求仅适用于Classic，而支持高性能计算的需求仅适用于Adaptive平台。
这两个要求都没有说Classic不能支持高性能，也没有说Adaptive Deep-embedded只是因为各自平台的优势不同。
AUTOSAR提供标准化的应用程序编程接口，例如用于通信和持久存储的接口，以实现应用程序在不同平台实例之间的可移植性。
然而，尽管Classic和Adaptive都提供了不同平台实现之间的可移植软件，但这些平台可以使用完全不同的方法，例如Classic基于信号的通信和Adaptive面向服务的通信，因此，为经典而开发的软件和为自适应而开发的软件之间没有可移植性。
低资源ecu非常适合经典平台，因为硬件要求比自适应的简单得多；例如，经典平台环境中，单个地址空间不需要虚拟寻址。然而，在自适应环境中，应用程序之间更复杂的隔离需要MMU支持。
此外，经典平台有一个静态定义的配置，所有任务、信号等在配置时都是固定的。
Adaptive支持动态通信和并发性，从而为应用程序响应其环境或扩展以适应部署机器提供了更高的灵活性。然而，这种灵活性是有代价的。
在经典中，应用程序直接从flash执行，但在Adaptive中可以从文件系统加载到RAM中。这意味着Adaptive可以支持软件的增量更改，而无需重新刷新整个软件ECU。
在经典平台中，RTE执行两个角色：应用程序swc的调度和应用程序swc之间的通信。这些角色存在于AP 中（分别是操作系统/执行管理和通信管理），但是Adaptive Platform中没有RTE的直接模拟。
2.5 Architecture
2.5.1 Logical Architecture
经典AUTOSAR平台的逻辑架构
AUTOSAR经典平台的逻辑架构包含定义良好的层，每个层都有精确定义的角色和接口。
AUTOSAR Classic平台的一个主要特点是所有配置都是静态的；
RTE在一组固定的软件组件之间实现通信，调度使用一组具有固定优先级的固定任务等。
AUTOSAR Classic平台的静态特性对于满足高安全性要求至关重要，硬实时使用有限的资源ecu，经典的平台就是为之设计的。
经典平台中模块之间的严格定义接口使来自不同供应商的模块能够协同工作（至少在理论上，即使这很少在实践中使用），但限制了平台软件内的实现和优化的可能性。
平台的逻辑架构描述了平台软件是如何组成的，架构中存在哪些模块、它们的接口以及用户应用程序如何与平台交互。
自适应AUTOSAR平台的逻辑架构
（AUTOSAR R18-10如图2.2所示，AUTOSAR R19-11如图2.3所示）将平台功能划分为自适应基础和自适应服务，每个服务由功能集群组成。
AP核心模块和各模块的功能：
| Functional Cluster |
缩写 |
description |
| Execution Management |
EM ara::exec |
平台生命周期管理，平台的初始化，控制应用程序的启动，停止。它通过一系列json配置文件，可以决定一些列应用程序的启动停止顺序 应用程序解决了一组连贯的功能需求。 EM进程最先启动，是所有AP进程的父进程。 |
| Communication Management |
CM ara::com |
负责Application之间通信（面向服务的通信）,应用程序不需要知道对端的地址，应用开发者只要关心特定的功能，不用关心具体的通信 可以是一个ECU内同一个进程的通信，也可以是不同进程的通信，或者不同ECU之间的通信。它都是使用统一的接口，它内部还实现了IPC通信 |
| Core Types |
ara::core |
Core Types定义了一些核心的Types和一些Function，多个功能集群作为其公共 interface 的一部分使用的通用类和功能。 |
| Persistency |
ara::per |
为AP应用程序和其他FC提供了一组API接口来读，写非易失性存储器的方法。 提供了将信息存储在Adaptive Machine的非易失性存储器中的机制提供了访问非易失性存储器的标准接口 |
| RESTful |
ara::rest |
用来开发web服务的，来实现接收http的请求，有get put set ,它确保了和非AUTOSAR客户端的通信， |
| Time Synchronization |
ara::time |
在分布式系统中，同步事件的时间非常重要，提供了系统维度的时间同步功能（CP是StbM），有助于构建TSN网络 |
| Platform Health Mgnt |
ara::phm |
平台健康管理模块，对整个系统进行监督，监控一个应用程序是否存活，或者是否按预期运行，同时支持模式仲裁和错误处理，（如在发生故障时采取“补救措施”）还实现了一个看门狗的机制 |
| Identity Access Mgnt |
ara::iam |
为Service Interface，AP Foundation FC以及Adaptive Application的请求提供访问控制framework旨在运行时强制执行对AUTOSAR资源的访问控制 |
| Logging & Tracing |
ara::log |
给应用程序提供了一套通用的接口，负责记录AP AUTOSAR的日志，并将日志信息推送到dlt demo窗口或者文件系统中。它是通过DLT协议以太网传输，还可以通过DLTViewer来格式化的查看日志。 |
| Crytography |
ara::crypto |
用于通用加密操作和安全密钥管理 |
| State Management |
Ara::state service |
状态管理功能集群负责车辆的状态管理器，负责收集用户应用程序的状态请求，包括保持通信或保持ECU活动； 监控来自Hypervisor的命令；监控网络管理的状态；它仲裁这些需求，控制总体的ECU到一个特定的状态，最后将最终状态反馈给EM模块，由EM模块来负责切换状态，控制应用程序的启动和停止。 通过API提供状态更改机制来请求状态更改、序列化功能组的状态更改请求以及管理实际的状态转换。 |
| Diagnose |
ara::diag service |
1.实现基于ISO14229-1（UDS）它的接口与CP AUTOSAR比非常像，有DCM和DEM ISO13400-2（DoIP）的ISO142229-5 2.配置基于CP中的DEXT（诊断提取模块）
|
| Signal to Service Mapping |
ara::s2s service |
|
| Network Management |
ara::nm service |
协调“内部协调状态机”中的网络（部分网络，VLAN或网络直连）的正常运行模式和总线睡眠模式之间的转换。 通过状态管理进行控制（为状态管理提供了一个服务接口）。它与具体的网络通信的方式无关，独立运行，提供了一系列的服务来请求网络状态，（如：请求网络，释放网络，支持部分网络，获得用户数据信息等） |
| Update and Configuration Management |
ara::ucm service |
这是一个平台服务，用来配置和升级应用程序，提供处理软件更新请求的AP服务（AP要使用OTA） 可以接收数据包，然后负责安装，升级，卸载平台软件，汇报给PM模块，同时它通过AB分区机制，可以实现回滚保护。 可以在一个升级包中升级多个软件，也可以升级Hypervisor和操作系统 |
功能集群是功能（规范需求、软件等）的集合，而不是单个软件模块，因为有可能进行平台内优化。这种区别反映在功能集群的命名上，
例如，执行管理而不是执行管理器，因为它代表的是管理运行时组件的执行而不是活动的功能。
经典平台和自适应平台都标准化了平台和应用程序之间的接口，实现了用户软件从一个平台实例到另一个平台实例的可移植性。
然而，在自适应平台中，由于每个自适应平台实例被视为来自单个供应商，因此AUTOSAR没有定义功能集群之间的接口。这意味着可以优化平台内体系结构接口，并且不受逻辑体系结构的约束。
2.5.2 Software Architecture
与经典的平台层软件体系结构相比，自适应平台具有反映平台需求的模块化软件体系结构。主要动机是支持分配给机器的软件的增量更新——由此产生的动态平台体系结构不仅支持增量软件更新，而且还支持当软件集不再是静态时出现的灵活、动态、通信和调度的紧急需求。
自适应平台软件体系结构利用了面向服务的应用程序（SOA）体系结构。因此，自适应应用程序通过网络上的通信协议提供和要求服务（一个具有良好定义接口的独立功能单元）。服务可以远程访问、操作和更新，而不依赖于支持松散耦合分布式应用程序开发的其他服务。
客户机根据定义服务功能的（半）正式服务描述来发现和访问所提供的服务。在AUTOSAR中，服务描述是ARXML服务接口（RTA-VRTE还支持DSL，以便更容易地定义服务–请参阅第13.2节）。
面向服务的体系结构（SOA）支持有效、灵活和适应性强的解决方案，因为它内在地促进模块化设计和部署高度内聚和松散耦合的服务。模块化得到了保证，因为服务描述表示服务的功能，因此是服务客户机的唯一访问机制。因此，只要服务描述保持不变，服务就可以被新的实现替换，或者可以被不同的服务替换而不影响用户。所需的高内聚性和松耦合源于需要“定义的结果”的服务定义，该结果自然地创建执行单个任务的服务，并避免紧耦合的解决方案。
SOA对可伸缩性也有很好的支持。提供的服务可以自动复制以利用其他硬件，例如，在运行时创建其他服务实例以确保使用特定平台变体上的所有处理单元。有了SOA，就可以很容易地添加新的服务来支持新的功能，因为提供的服务独立于任何现有的服务。
Adaptive AutoSAR旨在为这两个世界架起桥梁，提供具有灵活软件和高资源可用性的实时执行环境。
自适应平台ECU的特点是软实时（截止时间可能在毫秒范围内，偶尔错过的最后期限不会造成灾难性后果）和一些安全要求–AUTOSAR希望ASIL-B，尽管实现可以选择符合更高的ASIL。
但是与Classic不同的是，它是为使用基于POSIX标准的多核动态操作系统的高资源环境而设计的。自适应平台的实现可以使用“计划动态”来限制平台的动态方面，从而有利于可预测的执行或资源消耗。
计划的动态可能会将动态内存分配限制在启动阶段、预先确定服务发现过程、将应用程序分配到特定的核心或确保仅访问文件系统中预先存在的文件。
一个服务可以远程访问、操作和更新，独立于支持松散耦合分布式应用程序开发的其他服务。相比之下，自适应平台有一个模块化的软件体系结构。
Function Cluster (FC)
功能簇可以理解为进程的集合，每个功能簇有自己的状态和过程，成为功能组Function Group States，功能组的最小单位就是一个进程，一个功能组可以配置一组进程，当SM请求相应功能组进入到对应状态时，配置在该状态下的进程都会被启动。
Adaptive 平台特征
- C++开发
- 面向服务架构
- 并发处理
- 复用已有标准
- safety and security
- 计划动态
- 可以动态的管理资源和通信来降低软件开发和集成的工作量。
本文图片来源 博世ETAS AP AUTOSAR ，如有侵权，请留言联系作者删除，谢谢。