AP AUTOSAR 平台设计总体框架全解
**01.**简介
1.1内容
本规范阐述了技术范围与方法、Au Pair的历史背景及其相关知识，并详细说明了逻辑架构与物理架构的设计思路。全文共约32,000余字左右，请读者在闲暇时间参考阅读。
02. 技术范围和方法
2.1概述 - 智能ECU的前景
传统ECU主要用于替代或强化机电系统的作用。其中嵌入式的ECU运行其软件以响应来自其他ECU的信息，并调节系统内的电气电流。大多数控制程序为特定车型量身定制，在车辆使用周期内保持稳定状态。
新增的功能包括高度自动化驾驶等技术，在汽车内部将引入具有高度复杂性并消耗大量计算资源的软件系统；该系统需严格保证系统的完整性和安全性以实现环境感知与行为规划能力，并完成与外部后端及基础设施系统的集成；随着汽车行业的持续发展及功能性优化需求不断变化；汽车内部运行的软件系统需在整个汽车生命周期内持续迭代更新以适应技术进步带来的新要求
该方案通过AUTOSAR经典平台（CP）标准成功应对了深嵌式ECU的技术挑战，在现有架构难以满足这些ECU需求的情况下提出了一种创新解决方案。为此建议采用第二个软件平台——AUTOSAR自适应平台（AP）。该平台具备高性能计算与通信能力，并且提供高度灵活的配置选项例如支持在线升级的技术能力。其中一些专为CP设计的功能模块如电信号访问与汽车专用总线系统的整合已实现并被整合进AP中但并未被列入标准化优先项目这一安排既保证了系统的灵活性又避免了不必要的标准化负担。
2.2技术驱动因素
背后有两大类技术驱动因素。一个是以太网，另一个是处理器。
车载网络带宽需求持续增长促使Ethernet技术被引入相比于传统通信技术（如CAN），Ethernet不仅提供了更高的带宽而且还支持端到端通信的能力这种特性使得其在数据传输效率上显著优于现有方案CP设备尽管支持以太网接口但主要针对的是基于传统通信技术的产品设计并且已经经过针对性优化以更好地满足传统通信需求这种架构限制使得其难以充分发挥基于以太网的技术潜力并带来相应的收益
同样近年来随着车辆变得越来越智能对处理器的性能需求显著提升同时多核处理器与中央处理单元（CPU）协同工作然而除了单纯依赖多核外硬件设计也在不断突破新的可能性具有数十到数百个内核的多核处理器通用GPU（GPGPU）以及现场可编程门阵逻辑（FPGA）等技术正迅速崛起这些新型架构能够提供远超传统微控制器（MCU）水平的能力在实际应用中我们发现越来越多的内核开始主导系统设计原本专为单核心微控制器设计的中央处理单元CP如今面临挑战因为即使在数据中心中电力效率问题日益凸显而这一问题对于智能车载电子系统（ECU）来说更为突出从半导体架构及处理器技术角度来看受限于帕拉克规则系统的频率无法无限提升因此唯一的方法就是通过采用并行计算的方式提高系统性能已知通过混合使用不同的计算资源如多核心架构协处理器GPUFPGA以及加速器等可以获得最佳的能量效率这被称作异构计算目前这种混合型计算模式正在高性能计算（HPC）领域得到广泛应用显然这种扩展方向远远超出了中央处理单元的传统范畴
还值得一提的是，在芯片设计领域中，“综合效应”体现在处理器性能与通信效率之间。随着单 chip 处理器架构的应用日益普及，在这种架构下集成更多的计算单元使得各计算单元之间的相互协作效率得到显著提升。“更快、更高效”的并行通信能力正是这一技术进步的核心体现。“其中最为先进的便是基于片上网络（NoC）的技术架构。”而这种并行计算能力与高速互联技术的应用，则进一步推动需求转向能够持续支持规模增长的新一代平台架构
2.3平台适应性 -特性
AP的特征由第3.1节及第3.2节所阐述的关键因素构成。该架构必然要求更高的计算能力而技术趋势则为此类需求提供了衡量标准尽管功耗与成本效益同样不容忽视但 sulfate同时也面临着诸多新的技术难题
为了应对这些问题，AP采用了一系列传统技术手段，并赋予其最大限度地应用创新技术的能力。
2.3.1 C++
该编程语言在软件开发领域具有广泛的应用，并且特别适用于处理性能关键型复杂问题以及学术研究中的各种挑战性任务。目前，在软件行业中处理性能关键型复杂问题以及学术界开展研究时，在处理这类任务方面具有无可替代的优势；而作为主要的高级程序设计语言之一，在算法设计与实现方面也展现出卓越的能力；如果能够正确理解和掌握该语言的基本原理与实现机制，则能够显著提升开发效率并显著提高代码质量
该编程语言在软件开发领域具有广泛的应用，并且特别适用于处理性能关键型复杂问题以及学术研究中的各种挑战性任务。目前，在软件行业中处理性能关键型复杂问题以及学术界开展研究时，在处理这类任务方面具有无可替代的优势；而作为主要的高级程序设计语言之一，在算法设计与实现方面也展现出卓越的能力；如果能够正确理解和掌握该语言的基本原理与实现机制，则能够显著提升开发效率并显著提高代码质量
2.3.2 SOA
为了支撑复杂的应用需求，在处理分发与计算资源分配方面提供了最大的灵活性和可扩展性。AP遵循面向服务的架构（SOA）。基于这样一种概念，在这种架构下构建了一个由一组特定的服务构成的应用体系：其中某个服务能够依次调用或依赖于另一个服务；而根据具体需求可能调用一个或多个相关的服务以完成特定功能。
一般情况下, SOA展现出规范化的体系结构特征, AP同样具备这些特点.具体而言, 服务可能位于运行中的本地ECU上, 或者也部署于运行中的远程ECU上, 后者此时正执行AP的另一个实例.在上述两种情形下, 应用代码保持一致, 而通过基础通信架构来实现透明化的通信功能.
从另一个角度来看这种架构，则可将其视为分布式计算系统中的一种实现模式。总体而言，在不同体系结构下所体现的核心概念是一致的。基于通信机制的消息传递架构不仅能够借助快速且高带宽通信技术（如以太网）发挥出更大的潜力，并且其核心理念随着技术的发展而得到了进一步的完善和发展。
2.3.3并行处理
分布式计算本质上是一种并行技术。因为不同应用场景倾向于采用一系列独立的服务架构，SOA设计模式便体现出这种特性。通过多核处理器和异构计算等技术进步带来的提升，在满足现有系统需求的同时也带来了更加灵活高效的解决方案的可能性逐渐显现出来。这使得基于AP平台构建系统的架构方案具备了在功能扩展性和性能提升方面应对未来挑战的能力。
事实上，在现代计算体系中硬件与平台接口规范只是整个等式的基础要素之一。其中的操作系统/虚拟机管理程序技术和开发工具（如自动并行化工具）的技术进步不仅体现在性能优化方面还体现在资源利用率提升方面。主要依赖于AP提供商以及行业/学术生态系统的支持与协作。这也使得AP能够更好地适应各种新兴技术的发展需求。
2.3.4 利用现有标准
在涉及规格而非实现的情况下，重复创造相同的工具并无实际价值。特别在第3.3.1节所提及其相关讨论的基础上，请问您是否认同这一观点？AP则采取了更为明智的战略：采用重用现有开放标准并进行必要的调整这一策略，在此过程中既促进了自身发展速度的加快又从现有的开放标准生态系统中获得了持续利益。
这表明，在制定AP规范的过程中, 一个关键的重点并非只是简单地引入现有的技术与方法, 而是要避免盲目地引入已有的标准所提供的替换功能. 例如说, 在这种情况下避免因现有标准提供了所需功能而随意增加新的 interfaces. 然而这些 interfaces 在表面上不易被理解.
2.3.5安全
AP目标系统一般具备一定的安全性要求，并且可能达到极高的水平。引入新概念和新技术时不得损害这些要求，并且确实具有较高的难度。
为解决这一难题，AP整合了架构设计、核心功能模块以及操作流程体系。该系统构建在SOA框架上的分布式计算模型，并通过混合架构实现了各子系统的动态交互与协同工作，在确保各个组件之间相互独立的同时，并且能够有效隔离外部干扰因素。系统内置的安全机制不仅保障了系统运行的安全性，并且能够有效防止信息泄露与数据篡改等潜在威胁；此外，《C++编程规范》等技术参考书籍也将作为重要的辅助文件存在
2.3.6动态规划
AP采用了应用的增量部署方案，在资源与通信方面实现了动态配置。这一做法旨在降低软件开发与集成过程中的脆弱性，并有助于缩短软件迭代的时间周期。同时这种模式为探索式软件开发提供了良好的技术支持。
对于产品交付, AP 允许系统集成商精确控制动态行为以消除潜在问题, 并实现安全鉴定目的（请参考第 4.6 节）。应用的动态行为将受相关执行清单内容的影响。
多个应用程序列表之间的交互关系可能早在设计阶段就预设了某种结果或现象的发生。然而，在运行时阶段对资源以及通信路径进行动态分配这一机制只能通过预先定义的方式来实现，并且通常是在系统配置范围之内完成这一过程。
在软件配置进行调整时, 可能会考虑移除动态功能以便应用于生产场景. 在实际应用中可以通过以下案例来进行验证.
服务发现机制的预设化配置
*
动态内存分配受限于启动期
*
除了基于优先级的任务调度外，则确保了公平性
*
固定将进程映射至CPU核心
*
仅限访问系统已存在的资源文件
*
应用对AP接口的功能进行了严格的权限限制
*
确保只允许通过身份认证后的代码执行
2.3.7敏捷开发
尽管未直接体现在平台功能中, 但AP旨在适应不同产品开发的具体流程, 特别是基于敏捷的方法。针对基于敏捷的方法, 至关重要的是, 系统的底层架构应具备可扩展性, 并能在部署后进行系统更新。因此AP架构的设计应具备相应的扩展性。作为理论验证的基础, AP规范与实施（即AP实现）均采用Scrum方法进行构建与验证
2.4集成经典、自适应和非AUTOSAR ECU
如前所述，在IVI/COTS平台中，并非自动将CP或非AUTOSAR平台替代为AP；反而是AP与这些平台以及外部后端系统（例如路边基础设施等）进行交互作用，并以此形成一个集成化的整体系统（参考图2.1及图2.2）。例如，在CP中已经包含了一些由AP支持的接口以及其他原生协议的信息。
图 2.1：不同平台的示例性部署
图 2 . 2 ：AP 和 CP 的示例性交互
2.5规范范围
AP 定义了运行为其提供的系统架构及其相关组件，并指定了该平台的功能与接口。此外，它还指定了用于开发此类系统的机器可读模型。规范则需提供有关使用该平台开发系统的必要信息，并明确该平台自身必须满足的内容。
03. 架构
3.1逻辑架构
3.1.1环境
图 3.1 显示了 AP 的架构。
自适应应用（AA） 运行在 ARA （自适应应用的 AUTOSAR 运行时） 之上。
ARAs（可用区域架构）由功能集群提供的应用接口组成，这些接口集合归类于核心组件库 或者 服务集合。
自适应平台基础支持AP的核心功能, 自适应平台服务包含AP的标准化服务
任何AA也可以向其他AA提供服务，如图中所示为非平台服务 。
不论是基于自适应平台的基础组件还是相关的服务模块，在AA视角下都不影响其核心功能设计 - 这些接口仅限于提供一个固定的C++接口框架，并且对于AP来说，在未来可能会支持更多绑定其他语言的可能性。
特别需要注意的是，在AR_A接口下，在AA上下文中被调用的AR_A库可以采用AR_A以外的其他接口来实现AP规范的具体方式，并且这一设计取决于AP实现者的具体策略。
图 3.1：AP 架构逻辑视图
请特别注意图表3.1中的那些不在当前AP版本中的功能模块描述有助于全面认识整个系统架构。这些尚未展示的新功能模块可能在未来版本中加入。
3.1.2语言绑定、C++标准库和 POSIX API
这些 API 的语言绑定基于C++，C++标准库也可作为 ARA 的一部分提供。
关于OS API仅提供PSE51接口，并将POSIX标准下的singleprocess配置文件作为 Ara 的一部分进行整合与支持。选择 PSE51 系统是为了确保现有 POSIX 应用能够获得良好的跨平台兼容性，并通过互不干扰的方式实现各应用程序间的协同工作。
请注意指出：C++标准库涵盖了遵循POSIX标准的功能模块，并提供了多线 thread API。请提醒不要将 C++ 标准库的线 thread 接口与本机 PSE51 的线 thread 接口结合应用。
令人惋惜的是，在C++标准库中未完全包含PSE51的所有功能。如设置线程调度策略，则需同时使用这两个接口来实现相关功能。
3.1.3应用启动和关闭
应用的生命周期基于执行管理（EM）进行管理。应用的加载/启动是依靠EM的功能进行管理的，并且在系统集成阶段或运行阶段需要适当配置才能启动应用。
就EM而言，在除了自身之外的功能集群都是应用，并且它们都采取相同的启动方式。图3.2展示了AP内部以及AP上不同类型的应用场景。
图 3.2：应用
请注意，在EM中不会决定应用启动或终止的时间点和时间间隔。一种特殊的FC装置（称为状态管理SM控制器），按照系统设计所指定的命令EM来处理不同状态的变化，并以调节整个系统的运行状态为目标。
因为这里的系统代表了整个机器AP及其应用的运行状态，并且其内部行为是为了满足项目需求而设计的功能模块
SM 除了与其它 FC 的协同作用外，在此协同过程中也会协整整体机器行为。为了保证不同 AP 堆栈实现间的高度可移植性 SM 应严格遵循标准 ARA 接口规范 在此规范下确保不同 AP 堆栈实现间的高度可移植性
3.1.4应用交互
在AA之间在交互方面PSE51未包含IPC（进程间通信） 该意味着AA之间没有直接的接口用于实现交互。其中通信管理（CM）是唯一指定的显式接口。
CM 也实现了机器内部通信和机器间通信面向服务的通信机制，并且这种机制对应用程序是透明的。CM 负责管理服务请求/响应的路由安排，并不考虑其具体的服务及其客户端应用的拓扑部署情况
值得特别注意的是，在其他AREA（Area）接口中可能存在AA之间相互作用的可能性；然而这并不是一个官方明确的通信渠道，而是各个AREA提供的附带功能的结果。
3.1.5非标准接口
AA 和功能群集允许使用任何非标准接口，并且必须满足它们不与标准 AP 功能冲突以及项目的安全/安保要求。如果它们是纯应用本地运行时库，则需特别注意此类应用方式保持在最低限度以内
3.2 物理架构
该文详细探讨了AP的物理架构。请注意以下几点：本节中绝大多数内容主要用于阐述目的而非作为正式需求规范，请特别注意以下几点：本节中绝大多数内容主要用于阐述目的而非作为正式需求规范
所有关于 AP 实现形式的正式规定均已明确阐述。为了获取有关 AP 内部架构的更多细节，请参考文献[4]。
3.2.1 OS、进程和线程
AP操作系统要求包含多进程式的POSIX功能模块。每一个AA都被设计成一个独立运行的过程，并各自拥有独立的逻辑内存区域以及独特的名称空间分配。
考虑到单个并发架构（AA）可能包含多个进程的情况时，请注意其部署灵活性——它可以部署至单一并行处理器实例（AP）实现集中管理与调度；同样可以在多台AP实例如集群环境下展开以提升吞吐量与响应速度。就模块化组织而言，并发单元通常由操作系统负责将独立的任务代码生成为可执行文件并进行资源分配管理；而一个可执行文件可以支持多线程或进程的并行处理以提高计算效率；值得注意的是，并发架构可能涉及多份独立的程序运行以实现复杂的业务逻辑处理功能。
一般情况下, 功能集群通常被视为进程的实现手段. 此外, 在实际应用中, 功能集群还可以通过单一进程中程或一个由多个子进程中程协同完成的方式进行构建.
自适应平台服务和非平台服务也作为进程实现。
所有这些进程都可以是单线程进程或多线程进程。
但是，它们可以使用的 OS API 会有所不同，具体取决于进程所属的逻辑层。
如果他们是在ARA上运行的AA，那么他们应该只使用PSE51 。
如果进程是功能群集之一，则可以自由使用任何可用的操作系统接口。
就操作系统的角度来看而言，在系统层面来说AP与AA本质上是相同的进程集合；每一个这样的进程都可能拥有一个或多个线程单元；这些进程在本质上没有区别；然而AP的具体实现能够支持任意类型的分区机制
这些进程确实通过 IPC 或任何其他可用的操作系统功能相互交互。
请注意，AA 进程不能直接使用 IPC，只能通过 ARA 进行通信。
3.2.2 基于库或基于服务的功能集群实现
如图所示，在图3.1中可以看到的功能群集包括自适应平台基础和自适应平台服务两种类型。据前述讨论可知这些功能通常是基于过程设计的。为了实现与AA（作为进程）之间的交互需求 系统采用了IPC作为通信协议
有两种替代设计来实现这一点：
第一种设计是基于库的方式，在该设计中由功能集群提供的接口库与AA进行接口连接，并通过调用IPC完成通信。
另一种设计是基于服务的方式，在这种设计中进程部署了通信管理功能，并实现了与AA之间的代理库连接以完成相关的通信逻辑。
通信管理接口在AA进程和服务器进程中协调传输控制协议（IPC）。值得特别指出的是，在这种机制下是AA仅仅通过通信管理直接执行IPC操作吗？还是说它是借助代理库与服务器进行IPCE方式的混合连接？这完全取决于实现的具体方案。
在选择功能集群系统的一般准则时，如果一个主要的AP实例主要依赖库的架构，则采用基于库的设计更为适合。因为这种设计不仅更为简单有效，并且能够优化资源利用率。
当将其以分布式模式从其他AP实例调用时，推荐基于服务架构进行设计。不论客户端AA及其相关服务处于何种位置，该机制都能实现统一且透明的通信管理。
Adaptive Platform Foundation中的功能集群被称为“库导向型”的概念架构，在服务层面则采用“服务导向型”的模式设计。这一命名方式经验证准确无误。
请最后注意, 当且仅当FC的实现满足其定义中的RS和SWS约束时, FC得以在AA进程中作为库运行而不具备独立进程特征. 在这种情况下, AA与FC之间的交互将遵循常规过程调用模式而非基于IPC的标准.
3.2.3功能集群之间的交互
通常情况下,功能集群能够通过专为API(AP)设计的方式来相互协作.由于它们未连接到ARA接口,在PSE51环境中IPC的操作受到了严格的限制.
它确实可能使用其他功能集群的ARA接口，这些接口是公共接口。
经典的功能群集交互模型通常通过使用受保护接口的方式，在满足特定服务权限的基础上完成对特殊功能的需求。
此外自AP18-03版本起新增了功能间集群（Interface for Functional Clustering, IFC）的概念。具体定义为FC如何向其他FC提供相应的接口。需要注意的是，并非ARa组件的一部分。这并非构成AP实现过程中的标准规范要求
这些内容旨在通过明确功能组件间的互动关系来推动应用协议规范的发展，并进一步为用户呈现更优的应用架构视图。具体细节则可在相关功能组件服务-wise（SWS）附件中找到。
3.2.4机器/硬件
AP 视其硬件为运行的机器。其核心理念在于达成统一的平台视图，并不受所采用的任何虚拟化技术的影响。这些机器包括真实的物理机、完全虚拟化的机器以及半虚拟化的操作系统等，并不限于特定类型的系统架构
从硬件角度来看,允许多台机器并行运行的同时,在单机上部署一台AP实例.一般来说,在现有技术中,'硬件'概念通常涵盖单个芯片以及支持多机部署的配置.值得注意的是,在某些高级设计中,通过优化AP实现,允许多个芯片协同工作形成一个统一的计算单元.
3.3方法论和清单
支撑功能应用的分布式、独立性与敏捷型开发必须遵循标准化的方法
AUTOSAR自适应方法基于功能单元的标准规范体系进行设计与实现，并用于定义或描述服务、应用、设备及其配置信息等结构
以及明确说明这些工作产品交互的方式以达成设计信息交换的相关任务，并针对自适应平台开发过程中涉及的各种活动制定或规划信息交换方案。
该图展示了如何实施适应性方法的概述草案。如需了解详细步骤，请参阅 [3]。
图 3.3：AP 开发工作流
3.4清单
清单用于定义一段AUTOSAR模式描述。此模式描述旨在为实现AUTOSAR AP产品配置而生成，并将被上传至AUTOSAR AP产品中使用。它可能会与其他项目（如二进制文件）协同工作以确保完整性和一致性。
基于AUTOSAR AP的标准, 单列表项的使用仅限于该标准. 但这一点并不意味着, 在基于AUTOSAR AP的开发项目中所创建的每一个ARXML都将自动被视为列表项.
事实上，AUTOSAR AP通常不专门用于车辆项目。
一辆典型的车辆很可能还配置了多种基于AUTOSAR CP研发的ECU，并因此而说整个车辆的系统设计必须包含基于AUTOSAR CP构建以及基于AUTOSAR AP开发的ECU两种类型
从理论上讲，作为术语'清单'的定义仅指一个'清单'的概念，并且每个部署方面都将在此上下文中处理。这种方法存在明显的局限性。
基于此主要动机，在邻近应用设计领域内，则有必要将术语清单的定义划分为三个不同的区域：
应用设计方面：这种描述指定了适用于为 AUTOSAR AP 创建应用软件的所有与设计相关的方面。这些设计元素不需要专门部署到 adaptive 平台机器上，但它们有助于在执行配置信息和服务实例配置信息中定义应用软件的部署。
执行配置信息：用于定义在 AUTOSAR AP 上运行的应用的部署相关信息。这些配置信息与实际运行的应用代码捆绑在一起，从而支持将可执行代码集成到机器上。
服务实例配置信息：用于定义如何根据基础传输协议的要求配置面向服务的通信。这些配置信息与实际运行的应用代码捆绑在一起，并支持实现面向服务的通信。
机器配置信息：描述与部署相关的内容，这些内容仅适用于运行 AUTOSAR AP 的基础机器（即机器上没有任何运行应用）的配置。这些配置信息与用于建立 AUTOSAR AP 实例的软件捆绑在一起。
在不同清单类型及其运用范围的时间维度上进行划分后得出结论，在大多数情况下应该采用专门的文件来保存每一种清单
除了功能模块设计和功能分类列表之外,AUTOSAR方法还支持系统架构规划, 能够在一个模型中集成两个不同的AUTOSAR平台, 其软件组件能够实现信息传递. 不过, 也可以建立信号与服务之间的映射关系, 从而在基于服务的通信框架与传统的基于信号的通信模式之间架起连接.
3.5应用设计
该应用的设计涵盖了所有与设计相关的建模方案,这些方案适用于开发AUTOSAR AP相关软件
应用设计侧重于以下几个方面：
定义数据类型以对软件的设计与实现进行分类
服务接口是实现服务间通信的基础要素
明确应用如何与服务系统进行通信连接
持久性接口用于确保应用程序能够访问持久存储的数据
定义应用如何访问加密软件的功能
确保应用程序能够了解平台运行状态的基本信息
明确应用如何处理时基信息以支持时间管理需求
序列化属性用于规范网络传输数据的具体编码规则
客户端和服务器功能详细说明文档
=
在应用设计过程中定义工件时，它们不受具体应用场景（即应用软件特定部署）的限制；从而使得不同部署方案下都能方便地复用。
3.6执行清单
执行清单的目的是提供将应用实际部署到 AUTOSAR AP 上所需的信息。
主要思路是通过最大限度地脱离部署方案来实现应用软件代码的最大化重用可能性。
通过执行清单，应用的实例化受到控制，因此可以
在同一台机器上多次实例化同一应用软件，或
将应用软件部署到多台机器，并为每台机器实例化应用软件。
执行清单侧重于以下几个方面：
用于定义如何启动应用实例的启动配置。
启动包括启动选项和访问角色的定义。
每个启动可能依赖于机器状态和/或功能组状态。
资源管理，特别是资源组分配。
3.7 服务实例清单
在网络上通过特定通信技术（如SOME/IP）来实现面向服务的通信是必要的配置方式。由于两端的基础架构在服务提供者与服务请求者的行为应当保持一致这一原则要求的存在，在设计该服务时必须确保两端的一致性
在网路面上达成面向服务通讯须针对所使用的通讯技术（如SOME/IP）进行专门设定与配置工作。因为服务基础架构在提供方与请求方的行为应当具有一致性这一前提条件的存在，在设计该通讯系统时必须保证双方的一致性要求
服务实例清单侧重于以下几个方面：
服务接口的部署旨在确定其在特定通信技术上的表示形式。
通过服务实例部署确保为特定提供的服务实例确定相应的凭证。
针对端到端保护进行相应的配置工作。
在安全防护方面进行了详细的技术配置。
对日志记录和追踪功能进行了必要的系统配置设置。
3.8 机器清单
机器清单允许配置在特定硬件（机器）上运行的实际自适应平台实例。
机器清单侧重于以下几个方面：
网络连接的配置和网络技术的基本凭据的定义（例如，对于以太网，这涉及静态IP地址的设置或DHCP的定义）。
服务发现技术的配置（例如，对于 SOME/IP，涉及要使用的 IP 端口和 IP 多播地址的定义）。
已用机器状态的定义
所用功能组的定义
自适应平台功能集群实现的配置（例如，操作系统提供具有特定权限的操作系统用户列表）。
加密平台模块的配置
平台运行状况管理的配置
时间同步的配置
文档化可用的硬件资源（例如，有多少 RAM 可用;有多少个处理器内核可用）
04. 操作系统
4.1概述
系统承担所有应用在自适应系统上的动态资源分配、内存管理和时间限制配置以及多任务处理。该系统与执行管理协同工作，在初始化阶段完成平台启动流程，并由系统协助完成应用程序的启动与关闭操作。
自适应平台未给高性能处理器分配新的操作系统的任务。反而是说，在这种架构下，系统通过定义执行环境与操作系统的接口（OSI）来实现与外部设备的交互。
OSI规范包括属于ARED（自适应应用的标准应用接口）一部分的应用接口。大多数情况下，在操作系统的支持下能够实现执行管理启动应用所需的各种接口，并非只限于创建进程这一项功能；然而，在ARED中并不允许此类功能的接口作为其一部分使用；相反地，则明确指出这些依赖于平台实现
OSI为此提供了基于C和C++的接口。针对C程序而言，其核心业务逻辑主要基于POSIX标准中的C函数调用，并由IEEE/RTAI标准[1]所定义的具体实现包含PSE51功能模块。
在编译过程中，在平台操作系统中查找并指定哪一个C库提供了这些特定的C函数；此外，在运行时阶段对应用可执行文件进行链接。
在C++程序中，软件组件的源代码包含基于C++标准及其标准C++库中定义的标准函数调用行为。
4.2 POSIX
市场上存在多种操作系统如Linux此类系统均遵循POSIX标准的接口然而应用在操作系统的使用上受到更为严格的限制
通常情况下，默认情况下，默认用户应用应采用PSE51作为操作系统接口。而平台层则可采用完整的POSIX架构。当在应用级需求增加时，在现有标准的基础上进行扩展，并尽量避免新增功能。
自适应平台基础及其服务功能的开发可能会采用更多的 POSIX 调用方案。这些调用将由实现者负责编写和提交代码，并非标准化方案
4.3调度
操作系统的多线程与多进程功能得到了充分的支持。基于POSIX标准的框架下，默认提供了First Come, First Served（即SCH_FIFO）以及Round Robin（即SCHRR）的调度机制，并允许用户根据需求采用诸如Shortest Job Next或者Any Other OS特有的调度算法等其他选项；然而需要注意的是，并非所有的调度算法都能在不同体系结构上实现良好的移植性
4.4内存管理
多进程支持的一个重要原因在于负责实现不同功能集群与AA之间的互不干扰性。操作系统的多进程支持通过机制确保每个进程位于独立的空间地址中。其他进程分别隔离并得到保护。
同一个可执行文件的两个实例运行于不同的地址空间中，在启动时能够共享同一个入口点地址及相同的代码和数据值；然而，在内存中这些数据将分布在不同的物理页区域之中。
4.5设备管理
设备管理主要基于操作系统。特意为之，则自适应平台的基础倾向于提供公开的主要系统功能。
虽然目前尚未计划对设备驾驶员的具体 API 进行标准化配置, 但此类驾驶员所实现的高级功能可以通过自适应平台服务实现标准化
4.6网络
多台机器之间以及与其他传感器之间的主要互连机制主要依靠以太网实现。这些连接关系将被详细说明其所依据的协议类型及其应用。系统有望配备一套完整的网络架构来支持这些连接需求。
基于通信管理机制的应用将公平地受益于网络支持，并为其提供了一种可靠的服务保证。作为自适应平台的重要组成部分,VLAN、IPSEC等安全功能正在保障系统内部以及各系统之间的安全通信。
05. 执行管理
5.1概述
执行管理涵盖了系统的全部执行管理方面。
执行管理与操作系统协同工作，在规划或优化进程中运行时行为。
执行管理涵盖了系统的全部执行管理方面。
执行管理与操作系统协同工作，在规划或优化进程中运行时行为。
5.2系统启动
在机器启动的过程中, 系统会先进行操作系统的初始化, 随后会开始执行管理流程作为平台初始阶段的一部分. 接着会开始自适应平台基础下的其他平台级流程运行（这些流程代表功能集群），它们也会由执行管理进行处理.
当自适应平台的基础启动并运行之后, 执行管理将继续发起启动自适应应用流程的操作. 平台级与应用级进程的具体启始次序将依据机器配置文件与任务调度表中所列明的关系来安排.
图 5.1：AP 启动顺序
自适应应用由多个可执行文件元素构成,这些元素一般对应于文件系统中的可执行文件.每个可执行文件可能包含多个进程配置(包括启动配置),具体情况取决于该可执行文件处于活跃状态时所处的功能组的状态.
执行管理可在身份认证的基础上提供启动选择权，在基于信任锚的机制下实现自适应平台功能的同时确保信任链的安全性与完整性。当系统进行身份验证并完成启动流程时，在符合规范的前提下（非强制性的）防护措施能够有效阻止恶意行为发生，并在检测到违规操作时采取相应限制措施以保障系统的正常运行状态。采用一系列防护措施后最终构建了一个具有高度安全性的可信环境系统框架。
5.3执行管理职责
执行管理负责自适应平台执行管理和应用执行管理的各个方面，包括：
平台生命周期管理 执行流程主要负责在自适应平台起始阶段执行操作，并对已部署的应用进行基础搭建。
执行管理负责对已部署的应用实施有序的启动与终止操作。
执行管理基于机器清单以及执行清单的信息来确定当前已部署的应用集合。
并依据预设的执行依赖关系推导出相应的启动与关闭序列。
根据机器状态以及功能组的状态分析情况来决定各阶段的任务分配。
这些预先部署的应用将在自适应平台开始运行之前或之后投入运行。
然而，并非所有这些预先部署的应用都会立即投入活跃工作状态；因为许多这样的应用将提供服务给其他系统，并处于等待状态以接收传入的服务请求。
执行管理对此类应用的运行时调度并不负责。这归因于操作系统的自身设计定位。然而，在配置操作系统方面，执行管理负有不可推卸的责任。为了实现这一目标，在配置过程中需要充分考虑系统资源分配策略，并通过分析机器清单和任务清单中的相关信息数据来制定相应的运行时调度策略。
5.4确定性执行
通过该机制确保基于同一输入数据集的所有计算结果一致，并不受外界干扰影响。执行管理将时间和数据确定性区分为两个方面：时间确定性关注生成结果的时间限制；而数据确定性则确保相同的输入生成相同的结果。前者规定所有输出均需在截止时间前完成；后者则确保从同一输入数据集及内部状态出发得到完全一致的结果。
在数据方面的可靠性上得到了充分重视，在实际操作中能够保证系统的稳定运行。该系统的核心组件包括用于可靠性的监控以及相关的控制机制。其中充足资源能够确保在处理过程中得到有效的应用，并且该系统的核心组件包括用于可靠性的监控以及相关的控制机制
确定性客户端与通信管理交互，以将数据处理与周期激活同步 。
确定性客户端支持的 API 及其与应用的关联如图 5.2 所示。
图 5.2：确定性客户端
除了基于进程本地实现的确定性客户端之外，在执行管理中还支持提供同步协调功能的SyncMaster管理器。该管理器通过建立各实例间的协调机制，在确保各实例间的确定性执行能够实现同步运行的同时提升了系统的整体性能。
5.5资源限制
同一台机器上可并行运行多个自适应应用，并非无害操作是系统设计必须考虑的关键点之一。为了避免异常行为带来的连锁反应, 应当限制异常行为对相关联服务的影响范围, 例如, 防止应用程序占用超出预期的CPU时间, 这种做法能够有效避免可能导致其他应用程序出现性能问题的情况发生
执行管理通过设置或安排资源组来支持应用进程无阻碍地运行。
然后，在每个资源组中指定一组时间与内存的使用上限, 以便确保应用受限使用资源.
5.6应用恢复
执行管理涉及进程启动/停止的相关信息管理, 因此它必须具备启动和停止进程的特殊权限.
平台运行状态管理系统负责监控进程活动情况；当任何一个进程的行为超出预设参数范围时，则可能触发系统恢复机制的操作流程；该恢复方案需由集成商依据平台运行状态管理所规定的软件架构规范来制定，并将其配置记录录入系统执行清单中
5.7可信平台
为了保障系统的正常运行功能，在平台上运行的所有代码都必须拥有可追溯的合法来源。这一特性得以保留将使集成商能够可靠地信任该平台的操作环境。
可信平台系统的关键属性可由信任锚（亦称信任根）构成。这种技术手段通常以安全环境中存储的公钥形式存在。例如，在不可更改的持久内存或 HSM 中。
系统设计人员负责保证以信任锚为基础的系统，并同时确保信任得以持续维持直至执行管理启动
基于系统设计人员为了建立信任链而采用的选择机制，在这种情况下可能已经评估了整个系统的完整性和真实性。然而，在以下情况中：当仅确保已执行软件被评估其完整性与真实性时，则接管系统控制权时执行管理需承担起继续信任链责任。在这种情况下，则由集成商负责正确配置执行管理。
通过从信任锚向操作系统和自适应平台转移信任（即构建信任链）的一个具体实施案例如下所示：
信任锚 - 按照定义 - 作为真实存在的实体，在引导加载程序初始化阶段对其进行身份验证。在整个引导流程的所有后续阶段中, 应始终对将要运行的可执行文件进行身份验证以确保其安全性和有效性
该真实性的核查需由已获得身份认证的实体执行；亦即真实性的核查可借助预先启动的有效程序文件或依赖外部实体（如HSM）进行；比如示例
当操作系统的真正启动完成后，在其运行过程中将首先启动并负责执行管理。在开启执行管理之前，操作系统必须确保该执行管理具有真实性和身份认证
特别注意：如果信任锚本身的功能（根据定义是真实的）未预先进行身份验证，则应在应用可执行文件之前对用于确认可执行文件真实性的软件实施身份认证。
例如，在使用该加密接口之前，请确保它已经被可信机构进行了身份认证。如果该接口被用来验证可执行文件的身份认证，则该加密接口在使用前必须由可信机构完成身份认证过程。
执行管理目前承担了启动自适应应用之前实施身份验证的责任。然而，在验证可执行代码的完整性和真实性方面，并非只有一种可行的方法。参考文献[6]列举了几种可能实现该功能的方式。
06.状态管理
状态管理是一个独特且专业的功能集合, 专为ECU开发项目的特定需求设计. 一般情况下, 最终实现将由系统集成商完成. 它涵盖AUTOSAR自适应平台操作状态的所有方面, 包括处理并评估传入事件及其优先级, 以设置相应的内部状态.
状态管理可能由一个或多个状态机组成，具体取决于项目需求。
状态管理采用项目特有 ara::com 服务接口与自适应的应用程序进行通讯。该接口由一组关键数据项构成,具体包括:字段标识符、数据类型说明以及字段访问权限设置等信息,以下将详细阐述其具体实现细节。在与其他功能集群之间进行互动时,应当基于各自独立设计的标准接口来进行通讯
图 6.1：状态管理交互
状态管理可以请求以下效果：
请允许功能组被指定为专用状态
（部分）请允许取消或重新启用网络连接
请提供关闭或重启机器的操作选项
其他自适应（平台）应用的行为可能会受到影响
请允许执行与项目相关的特定操作
请从平台运行状况管理或执行管理通知（监控）错误中恢复
根据诊断请求，在指定地址上执行与项目相关的重置操作
请准备并验证软件集群以便根据更新和配置管理中的请求进行安装、更新或删除
影响正在运行的进程的行为 以便实现机器（部件）内的同步行为 比如电源模式等
为实现同步行为, 状态管理基于通信管理的通信组范围创建ara::com方法及字段, 以输出定义消息与响应消息.
状态管理通过 ara::com 提供一组“触发器”和“通知程序”字段。
SM 主要通过检测“触发器”来监控事件 ，并在内部执行特定于实现的统计处理，并根据是否存在“通知程序”字段来输出相应的数据。
因为状态管理功能占据核心地位，
因此需要确保来自其他功能集群或应用的所有访问都经过 IAM 的安全控制。
平台运行状况管理系统负责对状态进行持续监控与评估。
状态管理功能具有显著的项目特定性，在AUTOSAR体系下暂不对自适应平台分配如BswM等经典功能模块。规划仅包括一组基础服务接口，并将行为仲裁逻辑整合至具体项目的代码架构中。
仲裁逻辑代码可以单独开发，也可以（部分）基于标准化的配置参数生成。
7. 通信管理
7.1概述
通信管理适用于分布式实时嵌入式环境中应用之间通信的各个方面。
背后的理论概念基于实际运行机制提炼而成，并指导识别并建立与通信伙伴之间的联系。这使得应用软件开发者能够专注于其应用的具体目标。
7.2 面向服务的通信
服务的内涵主要体现在其向应用提供的新增功能上,这些功能超越了传统操作软件的功能.该通信管理软件承担着实现内部网络设备间以及外部设备之间高效数据传输的责任.
服务由以下各项组合组成：
事件
方法
字段
在设计阶段、启动前或运行中建立通信参与者之间的通信路径。其中一项关键功能是通过代理实例实现的服务注册功能，并作为其中一部分存在。
图 7.1：面向服务的通信
所有为Service的应用都在其Service Registry中进行了相关Service的Register。为了获取所需Service的信息,各个Application通常会通过访问其所属的Service Registry来检索所需的特定Service类型。
7.3语言绑定和网络绑定
通信管理采用了系统化的策略来规范服务的实现过程。具体而言：
一种是为上层应用提供的服务（语言绑定），另一种则是网络层面的表示形式。
这确保了源代码的可移植性和跨平台不同实现的编译服务的可比较性。
通过目标编程语言的高效功能将服务的方法、事件与字段映射到可直接使用的标识符？性能与类型安全性（前提是目标编程 language 支持）是首要考量？因此通常由 service interface 定义馈送 source code generator 来完成该过程。
Figure 8.2：示例语言和网络绑定
网络绑定定义说明了如何将配置的服务实例的数据信息按照一定的编码规则进行处理，并与其关联地绑定到特定的网络地址上。
它可以基于通信管理配置（AUTOSAR 元模型的接口定义）根据其需求实现特定功能
它可以基于通信管理配置（AUTOSAR 元模型的接口定义）实现
它可以基于通信管理配置（AUTOSAR 元模型的接口定义）实现
它可以基于通信管理配置（AUTOSAR 元模型的接口定义）实现
它可以基于通信管理配置（AUTOSAR 元模型的接口定义）根据其需求实现
目前的通信管理模块涵盖了SOME/IP、DDS和IPC（先进进程间通信机制）以及支持信号PDU（基于信号机制的网络绑定）和基于信号的静态网络绑定
本地服务注册表也是网络绑定的一部分。
请注意：
7.4 C++语言绑定的生成代理和骨架
C++语言绑定的顶层接口能够实现AUTOSAR元模型中的服务集合，并通过面向对象的方式建立这些服务之间的对应关系
作为通信管理系统中一个关键组件的一部分，在软件开发过程中扮演着重要角色。该系统能够创建用于表示各个服务功能的C++类代码，并且每一个相关服务都通过其属性（字段）、事件以及定义的方法来实现对数据的安全性控制。
在开发中，在服务实现端上命名这些类为"服务提供框架"。在客户端上，则将这些类称为"服务请求代理"。
服务请求代理采用了在服务器返回结果前阻止调用方执行的同时进行异步操作的方法。这种设计允许同时启动其他不干扰的任务，并且当服务器返回Core Type ara::core::Future类型的值时，在不影响原有操作的前提下及时获取处理结果（请参见第16.1.4节）。
可以通过平台配置来实现相应的功能设置,从而让生成器能够创建模型类.当相应的服务器当前不可用性受到限制时,该系统仍然能够轻松地开发出客户端功能.同样的机制也可以适用于对客户端进行单元测试.
虽然客户端可以直接调用代理类,然而通过C++绑定实现的服务提供框架仅是抽象基类.服务实现必须继承自生成的基类,并且实现相应的功能.
ara::com的API接口还可实现安全层面的端到端保护通信代理功能并构建框架结构。这些接口的设计重点在于保证与其他系统组件的良好交互能力，并支持在E2E防护模式下完成数据传输任务。不论E2E防护功能是否启用，在开发过程中我们都需确保系统的稳定性和功能性。
7.5静态和动态配置
通信路径的设置可在设计阶段、启动阶段和运行阶段进行，并因此可被分类为静态或动态
全局静态配置：完全无需进行服务定位工作，在这种架构下各终端设备均能识别该服务。
应用层无服务发现机制：各终端设备均能识别该服务（即客户端），但该服务方无法感知这些关联终端（即 server）。基于事件订阅的方式构成了应用程序中唯一的一种动态通信模式。
支持全面的服务定位机制：在配置阶段并未设定明确的服务定位路径。通过API接口，在运行时阶段可自定义选择对应的服务实例。
7.6服务协定版本控制
在SOA环境中,服务的客户端和提供者被建立在包括服务接口及其行为的契约之上.
在服务开发过程中，服务接口或行为可能会随时间而变化。
因此，在AUTOSAR平台中采用了基于服务版本的区分方法。该平台负责处理服务在设计与部署阶段的协定版本管理。为了确保兼容性需求，在客户端实现'基于 versions 的 service discovery'功能以满足 backward compatibility 的要求。
当应用程序的服务版本与其所需的旧版本支持相容时，则该应用程序能够实现与不同旧版本服务提供商之间的连接。
7.7 原始数据流接口
除了面向服务通信功能之外（...），通信管理还提供了一个独立的API（API），用于处理指向外部ECU（Electronic Control Unit）的原始二进制数据流（binary data stream），例如，在ADAS系统中部署了多种传感器设备（sensor devices）。该静态API（static API）的功能包括为客户端应用建立与服务器端的通信通道，并为服务器应用实现等待接收来自客户端传入连接的功能。
此API为客户端及服务器提供实现关闭通信通道以及通过通信通道读取与写入原始数据（字节流）的功能。原始数据流通道可由供应商基于应用部署参数进行配置 ，例如指定网络端点位置与选用的数据传输协议。
目前采用TCP/IP协议族中的socket作为传输层组件，在未来可能会引入其他替代方案以增强系统扩展性。原始数据流接口位于名称空间ara::com::raw中
08. 诊断
8.1概述
诊断管理（DM）实现了基于ISO 14229-1（UDS）和ISO 13400-2（DoIP）的ISO 14229-5（UDSonIP）。
诊断管理表示基础层上自适应平台的功能群集。
该配置基于经典AUTOSAR平台的诊断提取模板（DEXT）。
该系统采用了DoIP作为其传输层技术。该协议是一种基于虚拟发现的技术，并专为诊断客户端、生产/车库测试人员等用户提供板外通信服务。
车载或远程诊断系统一般采用其他专用数据传输协议进行通信。为此特意开发并提供了相应的API接口以支持自定义化的网络层架构。
UDS通常用于车辆的生产和车库内，以便能够修理车辆。
8.2软件集群
软件集群s（SWCL）负责管理和维护所有原子可更新/可扩展组件。该集合包含与更新现有安装或部署的一组特定功能或应用相关的所有内容。
基于此，自适应诊断系统能够给所有已部署的软件组别分配独立的诊断地址。
该系统不仅支持单个机器地址的自我定位与监控配置实现，并且能够灵活地在任意两个设备之间建立远程监控部署通道；由此可见，在每个设备上都可独立设置相应的自我定位与服务管理配置信息。
每一个软件集群都拥有独立的诊断服务实例来为整体诊断提供支持，并附带了独特的ODX文件以供详细分析。特别地，在结合UCM软件包后，则能够实现对现有设备的更新维护以及新机器的顺利引入以确保系统的高效运行
8.3 诊断通信子集群
诊断通信子集群具备诊断通信能力（例如基于经典平台的DCM）。目前覆盖的服务较为有限，在后续版本中计划逐步扩展对uds的支持
DM 遵循 ISO 14229-1 标准处理多客户端。能够满足现代车辆架构所需的各种需求。通过从后端访问的方式支持多种经典车库配置及生产场景的应用。
8.4 自适应应用中的诊断（AA）
DM分发器负责处理来自diagnostic service的请求（例如program control或DID服务）至相应的AA，并将端口映射给相应的AA。
为了实现这一点，AA需要提供专门的诊断端口接口。
8.5类型接口与通用接口
诊断端口接口有不同的抽象级可用：
例程控件消息可用作
基于规范化的API标识符（API签名）包含了所有请求与响应的消息参数及其基元数据类型。该组件负责处理API中的编码过程。此API专为特定类型的事件或消息设计。
标准接口API签名仅包含表示请求与响应的消息字节向量。请求与响应的消息序列化由应用处理。同一个API可被多个程序段使用以控制消息。
数据标识符消息可用作
该接口定义包含所有请求-（用于写入）以及响应消息（用于读取）的参数，并包含相应的基元类型。该系统负责将数据转换为相应的格式以供后续处理。
该标准接口的API标识符仅由请求与响应的消息字节向量构成。应用负责将这些消息进行序列化处理。
独立的数据单元 每个请求与响应的消息参数都具有独立的接口。这种设计代表了诊断通信接口最顶层的设计模式——即无论消息结构中的任何部分发生更改都不会影响到API的行为。另外需要注意的是，在同一诊断消息中各个参数可能分布在不同进程之间。
8.6诊断对话
因为 DM 依赖于如前所述的伪并行处理机制, 所以它能够支持建立诊断对话, 以便反映出诊断客户端与诊断服务之间的不同对话内容. 这些诊断服务通过相应的UDS请求的目标地址标识符来进行识别, 并且能够在自适应平台的运行时根据需求进行动态分配.
8.7事件内存子集群
事件内存子集群负责诊断故障代码（DTC）管理（类似于经典平台的 DEM）。
活动 DTC 表示车辆中肯定检测到的问题（通常对生产或车库很重要）。
DM负责管理DTC及其配置的镜像记录（包含基于DTC发生事件的一组已配置环境参数集合）以及/或扩展数据日志（包含属于DTC的相关统计数据信息如重复发生次数等统计结果）的数据存储工作
DTC 检测逻辑可定义为诊断监视器。\n此类监控系统负责将最近测试结果报告给 DM 中的诊断事件。\nUDS DTC 状态源自一或多个诊断事件.
DTC 可以被分配给系统内存（自 2006 年 4 月 19 日以来可用）或可定制的个人存储空间（自 0x19 次及后续访问）。
支持计数器和时基反跳。此外，DM 还提供有关内部转换的通知：
相关方将收到关于DTC状态字节修改的需求，并对监视诊断事件重新启动前的校准需求及快照器扩展数据记录变更情况的反馈通知
当 DTC 处于非活跃状态时，在配置的操作周期数内未完成设置，则其可能会无法继续存在于 DTC 内存中。
DM具备对启用条件进行统一管理的能力。启用条件作为调节机制，在特定情况下可以用来控制DTC的状态变化。举例而言，在电压欠压的情况下，则会暂时关闭所有网络负载相关的DTC设置。
09. 持久性
9.1概述
该机制通过自适应平台的应用以及功能集群实现了将信息存储于自适应机器的非易失性内存中的能力。数据可在启动阶段及点火循环中获取。该接口使用户能够访问自适应机器的非易失性内存
该系统通过将存储位置标识符作为参数，在不同存储位置间建立联系；这类存储位置可分为两种类型；其中一种是基于文件系统的持久性API；主要依赖于文件系统的特性；而另一种则是基于数据库的持久性API；则利用数据库的技术。
键值存储
文件存储
每个应用都可以使用多个这些存储类型的组合。
图 9.1：自适应应用中持久性的典型用法
持久性数据始终专注于单一应用的单一进程。不存在能够实现不同进程间共享持久性的机制。此决策是为了防止在通信管理提供的功能下出现第二条通信路径。
该系统已准备好处理来自同一应用环境下的多个高并发操作。
这些操作在同一进程中运行。
为了实现对键值存储或者文件存储的数据共享访问，
OpenKeyValueStorage 和 OpenFileStorage 返回的对象均可被其他线程进行复制使用。
此外，
OpenKeyValueStorage 和 OpenFileStorage 这两个接口还可以分别应用于独立运行的不同线程，
从而实现对相同类型的存储资源的安全共享。
持久性能够管理数据存储的完整性和一致性。它通过冗余信息识别数据损坏情况，并采用校验码（CRC）、哈希值以及基于M of N架构的数据冗余方案构成。这些方法既可以作为整体应用也可单独配置以适应不同需求。
持续时间也包含安全的数据保护措施。这种系统主要是基于冗余设计的，并且具备额外的功能：能够检测数据异常状态，并利用冗余数据进行恢复。
持久性提供有关已用资源数的应用统计信息。
为了实现对存储数据的长期保存安全保护，在物理设备部署前需对敏感数据进行加密处理。
9.2键值存储
键值存储提供了一种功能模块，在内存中建立了一个数据容器以实现键值对的快速插入、查找和删除操作；该技术能够处理以下几种数据类型：
SWS_AdaptivePlatformTypes [7] 中定义的数据类型。
由应用中复杂类型的流式处理生成的简单字节数组。
通过 dataType引用的所有实现数据类型由
PersistencyKeyValueStorage作为应用设计中的关键值存储接口或专用于该关键值存储接口的基础数据元素
在每个键值存储中，这些键必须保证唯一性，并且是由应用所指定的方法来进行持久化操作以实现唯一标识。
9.3文件存储
并不仅限于所有与持久性存储相关的数据都采用该种方法进行构建
采用文件存储机制对一类数据进行管理。该类数据可通过特定的设备接口实现对存储位置的访问，并在此基础上建立相应的访问入口。这些入口将被唯一标识，并以字符串格式命名以确保数据的安全性与可追溯性。
通过对比文件系统结构有助于更好地理解相关概念：值得注意的是，在网络环境中通常使用的是网络存储端口而非文件存储端口。具体而言，在Windows环境下如果要实现类似的行为可以通过配置共享适配器来达到目的
9.4使用案例处理 UCM 的持久性数据
一般情况下，在ECU或自适应机器运行的全生命周期阶段进行管理的UCM架构会涵盖三个核心功能模块。
将新的应用软件安装到自适应机器
将现有应用软件更新到自适应机器
从自适应机器卸载现有应用软件
在前两种场景下，UCM 根据 EM 引发应用的安装/更新验证，并随后触发持久化功能以基于预先设定的持久性配置信息进行部署和更新应用的持久性数据。
在第三种情况下，UCM 使用持久性配置中的 URI 删除剩余的持久性数据。
持久性支持以下方案，用于将持久性数据部署到键值存储和文件存储。
在自适应应用安装阶段中, 持久性应能够在该阶段由应用设计师预先定义的持久性数据存储结构中进行部署。
持久性应能够部署由集成商更改的持久性数据。
持久性应能够部署由集成商定义的持久性数据。
该应用在安装新版本时应具备根据键值存储或文件存储配置的更新策略以覆盖并保留其持久性数据
通常，在应用设计和部署期间设置持久性层。然而，在这种情况下，系统应具备从部署阶段获取的能力以覆盖应用设计的配置需求。当缺乏必要的部署阶段配置时，则应采用与之兼容的应用开发环境中的相关设置来完成数据持久化工作
10. 时间同步
10.1概述
当关联分布在不同系统的事件时，在不同应用和/或ECU之间的高效时间同步机制（TS）对于确保能够及时追踪此类事件至关重要，并且以精确的时间间隔触发相关事件。
为此为应用提供了时间同步接口API, 从而该系统能够访问与其他实体/ECU 同步的时间信息
基于不同‘时基资源’（现定为TBR）实现时间同步功能；这些资源以预先配置的形式存在于系统中。
10.2设计
对于自适应平台而言，在选择合适的解决方案时需要综合涵盖多种先进方法以确保实现精确同步需求
经典平台的 StbM
库 chrono - std::chrono （C++11）或 boost::chrono
时间 POSIX 接口
在深入研究了这些模块的接口及其涉及的时间同步功能之后，在此过程中产生的动机是为了开发一个围绕经典平台的StbM模块的时间同步API。这一API不仅整合了StbM模块的核心功能，并且其设计风格与std::chrono这一库具有相似之处。
时间同步模块考虑以下功能方面：
启动行为
关机行为
构造函数行为（初始化）
正常运行
错误处理
在后续版本中将考虑以下功能方面：
错误分类
版本检查
10.3架构
应用将有权访问每个 TBR 的不同专用类实现。
TBR包括不同的类别。这些类别遵循同步时基管理器规范[8]中所定义的基础时间基准类型。这一设计确保了与现有标准的一致性。
同步主时基
偏移主时基
同步从时基
偏移从时基
同样地，在当前时段内，在时钟同步模块（SB-M）中提供的定时基准关系（TBR）也与分布式系统各节点上的基准一致。
借助此句柄, 该应用能够通过调用指定方法来获取所需的时间基准类型（具体来说, 这属于上述介绍的四种类型之一）, 并进一步获取该时间基准类型的专用类实现. 此外, 该应用还可以直接生成计时器实例.
TS 模块本身不具备实现将 TBR 同步化到其他节点及 ECU 上的时间基方法，并且无法采用网络时间协议或时间同步协议来进行同步。
TBR的实现特设了定期功能模块；该功能由时间同步以太网模块或其他相关模块获取实时信息用于同步TBR。
应用使用 TBR 提供和管理的时间信息。
因此，在充当时基代理期间（或：同时），TBR 赋予了同步时基的访问权限。在执行此过程中（或：在此阶段），TS 模块被剥离出作为‘真实’时基提供程序的功能。
11. 网络管理
11.1网络管理算法概述
AUTOSAR NM遵循一种分布式的网络管理策略，在这种架构下每个节点能够自主执行其任务并仅受通信系统内接收和/或传输的NM消息的影响
该算法采用周期性 NM 消息作为基础，在整个集群的所有节点上通过多播机制接收这些消息。
通过响应NM消息（NM），发送节点的目标是维持NM群集的唤醒状态。一旦所有节点准备就绪并决定退出活跃状态，在收到其他节点的相关响应之前会暂停向该群集发送NM消息。然而，在任何情况下若获得来自其他参与者的响应指示，则会延缓至进入休眠阶段的时间安排。最终若该专用计时器因缺乏必要的NM消息而失效，则整个群体将被强制引导至进入休眠模式的状态。
当NM集群中的每个节点需要进行总线通信时（该集群将通过发送NM消息来实现），该集群将通过启动传输NM消息以维持其激活状态）。
11.2架构
自适应平台的设计遵循不依赖于所使用的底层通信媒介的原则，并涵盖AUTOSAR自适应平台的功能、API设计、配置方案以及网络管理方面的内容。当前阶段主要基于以太网进行支持，并确保了总线架构的独立性。
网络管理（NM）的目标是通过状态管理来进行控制操作；这是因为某些网络的控制依赖于SM所支持的功能组的状态与相关应用集之间的协调工作。目前本章中所讨论的内容未能充分反映出设计方面的考量。
图 11.1：NM概览
该方法旨在通过内部状态机管理（包括部分网络、VLAN 和物理信道）的正常运行与休眠模式之间的切换。
该服务接口专门负责状态管理相关功能，并支持执行以下操作：包括但不限于网络请求、资源释放以及状态信息查询等任务。该接口能够处理不同实例之间的通信请求，并通过特定机制实现多个机器需求的集成处理功能。
当采用分网功能时，则Nm消息将能够包含相应的PN请求信息，并使得ECU能够忽略那些与之无关联的PN所发送的所有Nm消息。这一机制为实现对ECU或其一部分的关闭提供了可能性，并且即使在其他分网继续通信的情况下也能正常运行。
12. 更新和配置管理
12.1概述
AUTOSAR自适应平台的主要目标之一是通过无线更新（OTA）支持对软件及其配置的支持能力。为了实现对软件更改操作的支持，在UQM中提供了一种能够处理软件更新请求的自适应平台服务
UCM负责在自适应平台上管理软件的更新、安装、删除以及保留相关记录。类似于Linux系统中的dpkg或YUM等已知包管理工具,UCM具备额外功能,并能以安全可靠的模式更新或修改自适应平台上的软件
UCM Master支持主流的自适应平台方案，并通过无线通信或诊断测试仪进行车辆软件更新。该系统能够处理不同UCM之间数据包的传输，并可将其视为AUTOSAR标准下的客户端应用。
图 12.1：车辆更新架构
12.2更新协议
UCM 和 UCM Master 服务专为车辆诊断的软件配置管理而设计，并旨在以安全、可靠且高效的方式实现自适应系统的更改。为了满足来自多个客户端的快速更新需求以及支持快速下载的要求，在软件包处理与数据传输之间必须确保能够实现良好的分离与协调。
12.2.1数据传输
数据传输基于 ara::com 实现。从而可以将数据传输至UCM或UCM Master，并且无需在从后端或诊断测试仪的数据传输过程中进行缓冲操作。UCM能够将接收的数据包暂存至本地存储库，并在此存储库内按照来自UCM客户端或U_CM Master的要求依次处理这些包。
传输环节可独立于处理环节开展；UCM能够从多个客户端接收数据无限制
UCM Master 的运行依赖于采用了与 UCM 相同传输 API。然而可以通过其专用服务接口来访问。它支持执行 UCM 功能操作例如暂停或恢复现有的并行传输过程。
12.3程序包
12.3.1软件包
作为 UCM 输入的安装单元是软件包。
该软件集合了单个或多个（自适应）应用程序的可执行文件以及操作系统或固件更新版本；此外还应将其安装到适配平台上的一系列更新配置与校准数据一并包含在内。这些内容构成了该软件包中的可更新组件，并提供了应用于自适应平台的实际修改参数及所需信息。除了常规的应用程序与配置数据外，在每个软件包中还附带了一个列表文件；此文件列出了所有相关的软件包名称及其版本号等关键元数据；同时它还包括了在处理相关软件包时可能涉及的各种供应商相关信息。
避免对未指定格式的软件包进行规范,从而为采用不同类型的解决方案提供了实现UCM的可能性。这些软件包包含要在其软件以及元数据中执行的具体更新操作,该内容由 UCM 供应商工具被压缩成一个可被目标 UCM 处理的形式。
图 13.2.. 概述软件包
UCM 基于提供的元数据管理特定的供应商公司软件组合。
通用信息
包名称：完全符合条件的短名称。
软件群集模型的版本标识符需遵守https://semver.org语义版本控制规范；然而在调试与追踪过程中，则有必要使用内部版本号作为辅助标识。所采用的原始名称为StrongRevisionLabelString。
deltaPackageApplicableVersion：可以应用此增量包的软件群集版本
支持的最低 UCM 版本：确保 UCM 可以正确解析软件包。
软件集合之间的相互依存关系：按照TPS清单规范文档所规定的内容包含了这样一个体系模型，在该模型中明确阐述了一个系统组件与其运行环境组件之间建立、维护以及更新维护过程中的完整知识体系构建方法学
允许检查是否有足够的可用内存的大小：
未压缩软件集群大小：目标平台中软件的大小
压缩软件集群大小：软件包的大小
用于信息和跟踪目的
供应商：供应商 ID
供应商身份验证标记
打包程序：供应商 ID
包装程序中的身份验证标识符旨在完成一致性的校验过程，并确保系统安全（该机制特别适用于UCM环境下的软件构建管理）。
型号批准：可选认证信息。如联合国欧洲经委会WP.29的RXSWIN。
发行说明：此版本更改的说明
许可证：例如，MIT，GPL，BSD，专有。
估计的操作持续时间：估计的持续时间，包括，传输，处理和验证。
要将程序包分发到车辆内的正确 UCM，请执行以下操作：
诊断地址：来自软件集群模型，用于包通过UDS检查来自测试人员的情况
操作类型：更新、安装或删除
激活操作：可以不执行任何操作，重启（机器）并重启应用
12.3.2后端包
为使OEM 后端能够掌握来自多个包供应商的详细内容信息，请参考图12.3中所展示的后端包格式作为设计基础。
图 12.3.后端包概述
基于供应商设计的软件包格式具有专属性。然而，在后端开发中使用的软件包与供应商无关的情况下，则需要根据图 12.3 中所示的颜色标记生成相应的软件包清单，并且这些清单必须采用 ARXML 文件格式。
12.3.3车辆包
车辆套件一般由OEM系统后端进行组装。该套件包含从基于后端数据库存储的后端包中获取的软件组件集合。此外,它还包括一个车辆组件列表,其中包含了活动安排以及用于将UCM Master发布到车辆内的其他字段。
车辆程序包清单中应包含的字段的描述参考：
存储库：uri、存储库或诊断地址，用于历史记录、跟踪和安全目的
支持的最低 UCM Master 版本：确保 UCM Master可以正确解析车辆包。
对于更新活动编排：
UCM标志符：特定的车辆架构标志，在此框架下可唯一标识与之关联的所有子单元，并赋予UCM Master负责识别并管理与之相关的子单元的能力
软件包的关联，用于描述传输、处理和激活的顺序
驾驶员通知：与驾驶员沟通，请他在接受车辆更新时同意采用这些安全措施；同时，在每个更新阶段向他说明可能采取的安全措施。
例如说，在下载或更新过程中遇到汽车问题时，请问您是否能将车辆包移至车库进行修复？因此，在选择车辆包清单时，请确保其采用ARXML文件格式。
12.3.4软件发布和打包工作流程
为了创建后端包，在集成过程中必须选用与目标 UCM 相容的打包工具。这种程序套装通常可由自适应平台供应商（其中包括目标 UCM 本身）来提供支持。
集成商在完成可执行文件、清单以及持久性等的组装后，在打包程序的帮助下按照UCM供应商指定的格式包装软件包；随后将这些经过整合的软件包与ARXML软件包清单一同注入到后端软件构建中
软件包可以通过来自软件包集成商或集成商签名的应用程序进行创建，并且其中会包含用于身份验证的标记信息。
因为后端包可能通过互联网向集成商和OEM后的端发送数据内容，
为了确保不会因后续操作导致修改出现风险，
建议将所有软件包及其版本列表与相应的认证标记一并注册至容器中，
从而避免因后续操作导致的变更
图 12.5：打包步骤
然后, 集成商组装后的后端软件包会被放置在后端数据库或存储库中. 当车辆进行升级或首次安装时, 后端服务器会从后端软件包数据库中获取软件包, 并将其相关软件列表关联到对应的车辆软件包中.
在本软件包内，在嵌入于后端服务器的架构下，系统会根据车辆特定电子架构自动选择合适的活动编排方案；例如，在处理车辆识别码时会扣除相关的标识信息
图12.6：向车辆分发的程序包
图 12.7：向车辆分发的程序包
12.4 UCM 处理和激活软件包
UCM根据元数据分析并确定需要执行的操作步骤，在此过程中由ProcessSwPackage接口完成相应的部署、升级以及移除操作
UCM序列旨在提供如A/B版本更新或本地更新的可能性。其中包管理器能够回滚至先前版本，在必要时。
图 12.8. 软件包的处理和激活概述
为了简化且可靠的实现, 每次只能由一个客户端发起ProcessSwPackage方法来处理软件包, 将其UCM状态切换至PROCESSING阶段, 并让其他多个客户端依次请求处理传输中的包裹. 当采用A/B分区更新方案时, 多个客户端能够共同协作完成当前处于更新过程中的非活动B/A区;而在存在软件集合依赖关系的情况下, 每个客户端都必须按照预定流程先完成" B 区域"的具体更新工作. 当进程完成时，默认情况下UCM的状态会被设置为READY以便启动激活或其他相关操作
采用Activate方法对所有已处理过的包完成激活操作，并非与客户端有任何关联。UCM Master负责协调这一多客户端方案。UCM可能无法确认是否处理了所有目标软件包，但必须进行依赖关系检查以确保系统符合‘B分区’中已安装软件的要求。如果系统不满足‘B分区’中已安装软件的依赖关系要求，则UCM不应激活并应切换至就绪状态。
激活更新时，UCM 会通过 ara::com 在 SM 打开更新会话。对于每个受影响的软件群集中的每个功能组，将调用 PrepareUpdate 方法。它执行 Function Group 特定的准备步骤。成功后，状态将更改为“正在验证”。然后，UCM 通过 SM 接口请求机器重置或功能组重新启动，具体取决于更新类型。例如，如果更新包括正在运行的系统或功能群集更新，则 UCM 可能希望重置机器。但是，如果更新仅涉及低关键度功能，则只需重新启动功能组即可，从而减少对驾驶员的打扰。在此阶段，来自 SM 的 UCM 请求验证目标功能组是否正常运行。成功完成这些重新启动后，UCM 将切换到“已激活”状态。
在激活更新完成之后，在此之前将被拒绝的所有处理请求将在激活问题得到解决之前被拒绝。在此阶段中（在此阶段中），在此阶段（在此阶段）/ 在此期间（在此期间）/ 在此阶段期间（在此阶段期间）/ 在此阶段期间内（在此阶段期间内），UCM 客户端或 UCM Master可以调用 Finish 来确认更改，并且也可以调用回滚以忽略更改并返回到以前版本的软件。例如，在这种情况下：如果此类更新是由 UCM Master 协调的一个全局更新活动的一部分进行的，并且在该过程中出现故障，则在Finish被调用后UCM将清除所有不需要的资源并返回到 IDLE状态。
当发生回滚操作时，在UCM中将切换至'回滚'状态以便通过为每个受影响的软件群集的功能组调用PrepareRollback方法恢复旧版软件群集的状态。在此状态下如果采用A/B分区方案UCM将在下次重启动前准备好恢复'A分'区域。随后当使用SM接口重启动系统并恢复'A分'区域状态时UCM将切换至'已回滚'状态。
在这两种情况下，回滚和成功激活，UCM 都必须在 SM 完成更新会话。
UCM设计专注于传输过程中的处理工作,从而降低自适应平台中的存储操作成本以及更新频率。例如,在一个仅包含自适应应用的应用程序集群中,UCM系统能够接收并解压 incoming software modules,并将这些解压后的文件直接分配到指定目录位置进行管理,最终完成对整个软件包内容的有效性验证以确保数据完整性和一致性。
12.5 UCM Master更新活动协调
由于UCM Master在管理车辆的各种元素，
可以通过从CampaignState或TransferState字段获取状态机信息，
从而可以减少UCM Master API的复杂度。
UCM Master通过ara::com服务不断发现并识别车辆中的UCM服务实例。
图 12.9：UCM Master状态机
UCM Master 的 state machine 与 UCM 的 state machine 不完全匹配, 由于需要考虑到特殊的 vehicle 方面. 例如, 在 package transmission 方面, 在 vehicle 和 backend 中同步或更新后的 software compatibility 检查, 是 specific 到 UCM Master 的.
12.5.1与 UCM Master节点交互的适用应用
基于OEM特性对车辆更新进行处理，并将OE M特定内容通过设计推送至自适应应用端。为了实现跨平台互操作性和兼容性目标，在现有架构基础上引入标准化的UCM Master接口，并将其作为统一的服务进行扩展（例如UCM）。该接口将分别与以下三类应用进行交互，并详细说明其功能机制。
12.5.1.1 OTA 客户端
通过配置OTA客户端与UCM Master及后-end系统建立通信渠道。未预先设定双方之间的通信协议。OTA客户端包含一个调度机制，在固定时间触发数据同步（由后-end系统或UCM Master负责），其中涉及来自后-end系统的可用软件以及车辆现有的软件配置项。支持更新、安装或卸载的软件版本将基于两者间的差异进行计算得出。
当UCM Master出现故障时，则可以将其替换为车辆中存在的另一个Master。随后, OTA客户端应当配备决策机制来决定与哪一个UCM节点进行交互.
当UCM Master出现故障时，则可以将其替换为车辆中存在的另一个Master。随后, OTA客户端应当配备决策机制来决定与哪一个UCM节点进行交互.
12.5.1.2车辆驾驶员
在更新期间，可能需要与车辆人类驾驶员进行交互，以便：
获得下载同意（影响数据传输成本），处理或激活软件（安全措施确认）
安排车辆处于特定状态（以确保在关键更新期间的安全，请注意停车并熄火）
12.5.1.3车辆状态管理器
车辆状态监测系统正通过全部ECU或机器采集当前运行状况信息。基于这些采集到的状态数据信息以及按照UCM Master的标准进行评估后确定具体的运行参数值，并将其作为关键信息保存于系统数据库中。一旦评估结果发生变动就需要立即触发CU MMaster的相关安全校验流程以确保系统稳定性与安全性之间达到最佳匹配关系。若检测到当前系统的安全性无法满足要求CU MMaster可能会选择推迟执行新的操作程序临时停运或者彻底终止整个更新过程以保障系统的稳定运行不受影响
12**.5.1.4刷写适配器**
适配器是一种能够自我调整的应用程序。其接口与UCM Master下的UCM具有相同的功能，并且支持通过诊断接口进行OEM级刷写的特定序列。该适配器采用基于ISO 22900标准中的D-PDU API的应用编程接口实现，并与其Classic ECU设备之间建立通信。
12.6软件信息报告
由UCM提供的服务接口专门用于获取自适应平台相关的软件信息数据包名称及版本号。基于UCM更新过程具备明确状态的事实，在此过程中可获取每个软件包的信息状态数据。
UCM Master还提供服务接口以公开软件信息，并在车辆级整合来自多个UCM的信息。然后通过OTA客户端与后端交换这些信息以确定车辆可升级的软件版本。此外UCM Master还提供一种访问其操作日志的方法例如激活时间和包处理的结果。后端则可利用这些日志从车队收集更新活动的数据或者借助诊断测试仪解决车库中的问题
12.7软件更新一致性和身份验证
UCM及其Master版本应在每个软件包上应用全面覆盖的认证标记以实现独立认证功能（如图12.2所示）。自适应平台必须配备必要的校验过程、加密签名或其他特定于供应商及OEM的技术以确保软件包的有效性；否则, UCM及其Master版本将返回错误信息。实际上,所有软件包应当采用与目标开发项目的相关工具来自同一供应商进行压缩,从而确保所使用的身份验证算法能够兼容并协同工作。
基于哈希算法的设计理念下，在对程序包进行身份验证的过程中也会保证一致性这一目标得以实现。这些方法（包括TransferData、TransferExit以及ProcessSwPackages）均可用于评估程序包的一致性与身份验证。然而，在处理任何包之前必须执行相关操作以确保系统处于安全状态之前完成这些步骤以便于后续操作的顺利开展
12.8更新过程安全
UCM 和 UCM Master 使用 ara::com 服务。在 UCMA 和 UCMM 的更新协议中均未包含客户端的身份验证步骤。反而是通过 ara::com 请求服务的客户端经过身份和访问管理认证后才被允许。
12.9更新过程中的专有状态管理
UCM通过状态管理中的UpdateRequest服务接口实现对可能因竞态关系或安全性问题而被拒绝的更新会话进行请求。此外还能够通过PrepareUpdate方法对功能组进行激活前的必要准备以及VerifyUpdate方法对更新安装或删除操作进行确认操作。当确认操作失败时UCM能够通过回滚方法修改相关功能组的状态；如果有必要UCM还能够向SM提交机器重置指令并且在系统激活后需重新审查配置清单以确保平台配置的一致性
图 12.10 更新过程中的状态管理
13. 身份和访问管理
IAM的核心概念是由安全性需求的增长而产生的, 因为AUTOSAR自适应平台需要与应用之间构建紧密而明确的信任机制
IAM 实现了对自适应应用的权限分离，并在攻击中防止了权限提升。此外，IAM 集成商得以在部署阶段完成资源访问权限的验证。
身份与权限管理为源自于服务接口层的自适应应用、自适应平台基础的功能集群以及相关资源模式的请求所构建的一体化访问控制机制负责处理。
13.1术语
为了深入理解框架的工作原理，请提前明确几个关键概念。为便于查阅，请参考文献中'基于策略的管理术语'一节。
RFC3198 （https://tools.ietf.org/html/rfc3198）.
访问控制决定： 访问控制决定表示一个布尔值，用于指示是否允许执行请求的操作。该决定取决于调用方的身份以及采用的访问控制策略。
访问控制策略： 该策略旨在确定访问特定对象（如服务接口等实例）所需遵循的条件。
战略决策点（PDP）： 战略决策点负责制定访问权限管理规则。该系统通过评估访问控制策略来判断权限申请资格，并智能地处理权限申请请求。
策略实施点（PEP）： PEP 通过主动获取自适应应用所需的控制决策，在其请求期间临时中止当前流程以接收这些决策，并确保贯彻执行此决定。
意图： 该属性属于自适应应用标识系统中的一个核心特征。只有在请求者AA拥有该资源所需全部预定义的核心意图时才允许对其AUTOSAR资源（如服务接口）进行权限授权。这些核心意图将被分配到对应的AA应用列表中。
授权： 在部署自适应应用期间，在设计阶段应核对每个需求项。授权元素可在元模型中获取。拨款将协助集成商进行需求项审查工作，并不鼓励集成商主动接受非核心需求项。
中间标识符（IntID）： 一个核心标识符用于将运行中的 POSIX 进程与建模中的 AUTOSAR 进程对应起来。该标识符的具体特性和所依赖的身份验证机制紧密相关。
自适应应用标识（AAID）： 自适应应用的标识模型由 AUTOSAR 进程表示。
自适应应用标识符： AAID 的引荐来源，即 AUTOSAR 进程，仅指向一个 AAID。
13.2 IAM 框架的范围和重点：
IAM 框架专为AUTOSAR自适应平台栈及自适应应用的开发人员提供了某种机制,基于每个应用的意图进行建模,在处理相关请求时自动做出访问权限决定,从而确保了严格的权限管理.
IAM 覆盖了从可自适应的应用程序到自适应平台基础这一系列限定访问接口、服务接口以及与功能集群相关的明确定义资源（如 KeySlots）的方法论研究，并特别强调 IAM 不会介入对 CPU 或 RAM 等系统资源进行硬性规定的保护措施问题
在运行期间, IAM 过程对自适应应用具有透明性, 除非请求被拒绝并触发通知.
该框架的目标是在运行时被强制性地访问AUTOSAR资源。该设计假定自适应应用在启动过程中将进行身份验证，并且当前的安全运行时环境能够提供适当的隔离以避免权限升级（即绕过传统的访问控制机制）。
13.3 AUTOSAR 规范的保留
下表将展示IAM框架的关键组成部分及其功能划分，并明确指出哪些技术细节将在AUTOSAR标准中进行统一定义。开发人员则将在具体的实现阶段根据项目需求对相关技术参数进行个性化设置和优化处理。
表 13.1：IAM 框架部件概述
13.4 IAM 框架的架构
13.4.1整体框架
IAM 架构在逻辑上将授权实体划分为两个部分：一部分负责判定是否允许自适应应用接入资源（PDP），另一部分则负责执行相应的权限管理（PEP）。这些对接口访问进行严格限制的功能集群必须确保PEP能够执行PDP所发出的所有访问控制决策。为此，在自适应应用发起此类接口请求时PEP会主动与PDP取得联系以交换相关决策信息由此确定具体的权限分配依据要求和应用场景需求获取的所有权信息最终由策略来确定所需的前提条件即自适应应用为了获得所需的权限而需满足的一系列先决条件这些条件构成了对相应资源的所有权定义并以规范的形式加以记录
初步假设
应用被设计/配置为具有意图（允许它们访问某些资源的属性）。
在部署期间将确认每个意图。
部署的应用将进行加密签名，以便验证真实性。
应用与包含意图的应用清单一起部署。
基于IAM机制的自适应系统应按照预定流程进行真实启动操作，并确保其操作列表能在部署阶段通过身份验证程序。由PEP进行请求解析，并指示PDP制定相应的策略（可能在同一过程中实施）
13.4.2自适应应用的识别
为了向 PDP 提交策略决策方案并明确识别自适应应用的使用场景，请 PEI 确保能够准确标记此类应用实例。由于每次调用都会通过进程间通信机制实现中介功能，则中间件必须具备支持该标识的能力。
标识本身源自建模 AA。意图依次被绑定至PortPrototypes和SWComponentType，请参考清单规范。
IAM 框架未能充分指定 AA 标识符。最理想的解决方案往往取决于栈供应商所选的操作系统及其平台配置。许多现代操作系统确实能够识别通信端点上的对等体（如 Linux 中的 SO_PEERCRED、getpeerid() 函数或 QNX 系统中的 Message Pass）。对于缺乏此类机制的支持平台，在消息级别实现协议可能更为合适
基于AUTOSAR进程模型, 执行管理生成自适应应用的操作实例. 从而负责跟踪运行中的进程属性(如PID值以及赋予特定标识), 并根据需求动态分配属性(例如分配专用标识符(如UID)或者用于消息级别的键值对(如UUID)). 执行管理需确保PEP能够识别并定位到与之通信的所有适配型应用模型.
PEP须在自适应基础中实现，并同时应与调用自适型应用适当隔离。DPI不可以由自适型应用提供，并且自我适用层自身受到请求操作访问权限的制约。
13.4.3 IAM 时序
自适应应用（AA）发起对资源（例如服务接口）的请求。
PEP 中断控制流。
PEP 通过 EM 解析请求进程的身份。
PEP 将调用方的标识和请求参数传递给 PDP。
PDP 检查 AA 的意图是否足够，并将访问控制决策返回给 PEP。
PEP 通过阻止或允许请求来强制执行访问控制决策。
图 1431：IAM 序列
传输库与 EM 用于识别 AA 的机制并保持一致性。
使用 POSIX-Process-ID 作为手段跟踪在 fork（）调用过程中由操作系统获取的 PID。EM 通过受保护的功能群集接口的信息传递机制向 PEP 传输此数据。当采用 UID 时，在新 POSIX 进程创建过程中应将其 UID 设置为默认值以避免冲突。
14. 密码学
该平台提供了一系列API来执行常见的加密操作和安全密钥管理任务。这些API能够根据运行需求动态生成密钥，并处理相关加密任务及数据流。为了减少存储开销，在设计架构时可以选择将密钥存放在后端加密模块内；或者将其存放在外部设备上并根据需要进行加载。
该API专为将安全敏感的操作与决策整合到独立组件而设计。其核心功能包括但不限于：1)通过遵循IAM报告的结果，并限定在特定用途内（如仅限于解密功能），同时确保单个应用无法访问非授权数据等特性。
该 API 基于应用支持；此外，在处理 TLS 和 SecOC 等加密协议的过程中能够防护会话密钥和中间机密。
FC Crypto支持多种自适应AUTOSAR功能集群，并为其提供标准化接口以实现对加密过程及相关计算的操作。这些操作涵盖了加密操作、密钥管理以及证书处理等内容。该平台负责所有操作的实际执行，并确保其与请求应用及堆栈提供的实现之间完成必要的配置与代理工作。CryptoAPI作为标准接口对外公开
X.509 证书管理提供程序命名为 ara::crypto::x509 负责 X.509 证书的解析功能、验证流程以及真实存储位置，并根据属性进行本地搜索功能。此外，在线操作中该模块还承担存储操作、管理流程以及处理相关数据的工作。针对在线状态协议 OCSP 的请求处理阶段进行前处理，并完成响应解析过程。
14.1安全架构
尽管AUTOSAR AP仅提供了面向应用的高级加密栈API，并在此过程中充分考虑到系统的安全性与功能性需求，在设计阶段就已明确了这一目标
如图14-1所示的通用架构展示了这一结构，在顶层结构中,AUTOSAR AP与本地及混合应用均通过其Crypto Stack API接口相连。其中,API的实现通常涉及一个核心组件——加密服务管理器,该管理器负责统一协调各子系统的操作,涵盖权限管理和证书存储等功能。此外,通过这种架构设计,我们可以将部分功能性转移至专门的硬件安全模块（HSM）以提升安全性。实际上,以这种方式分流Crypto Stack API的功能有望成为一种典型的实施策略：即通过将部分操作交由专用硬件执行来优化性能并增强安全性。
图 14.1：加密栈 - 参考架构
为了实现这种分层的安全架构,Crypto Stack API不仅实现了传统的加密与解密功能,并且还提供了对其以下功能的支持
使用加密密钥或密钥句柄进行操作
尽管可能存在应用危害，但仍可安全地管理密钥
限制应用对密钥的访问和允许对密钥的操作
14.2密钥管理架构
尽管存在潜在的应用危害但为了实现对密钥的安全远程管理Crypto Stack集成了一个可靠的密钥管理架构该架构将所有相关的数据与私有秘钥一起作为端到端加密的形式加以保护允许通过可信赖的已有公钥直接导入系统或者通过生成本地私有秘钥匙导入系统假设有一个经过严格验证的安全加密后端或驱动程序只有在经过严格授权的情况下例如进行秘钥更新或撤销操作才能修改当前系统的公有秘钥匙
图 14.2：CKI 密钥管理交互
14.3 API 扩展备注
为了实现新增或更新权限/策略验证逻辑的关键功能，并将这些关键交互与新的密钥管理策略关联起来。举个例子来说，在所有涉及这些新增密钥的操作中强制应用新的逻辑机制，则能够确保相应的安全特性得到充分保障。
15. 日志和跟踪
15**.1概述**
该集群负责管理及监控AUTOSAR自适应平台的日志记录能力，在开发阶段以及生产阶段前后均可部署日志记录与监控功能
AUTOSAR自适应平台与日志记录功能集群对平台稳定性进行管理，并避免导致系统资源超负荷运行
日志及跟踪系统主要依赖于AUTOSAR联盟内标准化实施的日志传输协议LT（Log and Track）。该协议通过将日志记录信息打包成统一的标准格式来实现可靠的数据传递与展示。此外，在标准日志消息中还可以附加重要元数据如ECU设备标识符（ECU ID），以便于日志接收端进行关联分析及后续处理操作。
此外还提供了实用的方法例如说将十进制数值转换为十六进制数据体系或者二进制数据体系这些是为了使应用按照LT协议标准化序列化格式向日志和跟踪提供符合规范的数据而必需
该集群提供了两种类型的消息：一种是具备模型化的特征（即被称为模型化消息），另一种则不具备这种特性（即被称为非模型化消息）。这些类型的消息均能接受一个或多个附加的参数。那些未携带任何附加信息的消息会被视为无用数据而被淘汰。
非模型化的常见做法用于编写日志消息：将所有参数整合至内部缓冲区后进行序列化处理，并输出至终端或存储介质，并可通过网络传输。这类在DLT协议中的信息被统称为"详细"信息。
建模消息的目标是通过去除网络消息中的某些固定属性来降低数据传输量。根据名称原则,这些固定属性被纳入ARXML应用模型中。在DLT协议中,这些消息被称为'非详细'消息。日志查看器应用程序能够整合模型中的恒定特征与接收到的消息动态内容以呈现完整的交互记录。
在开发阶段中主要采用非模型化的消息形式，在当时的技术条件下受限于可用信息量的限制。然而，在生产环境中通常优先选择模型化的消息以确保高效运作
15.2架构
在 ara::log 命名空间中包含了 Log 和 Trace 接口，在此命名空间中应用能够将日志记录传输给定的日志记录接收器。
日志和跟踪接口基于作为日志记录框架一部分的后端部分的实现。日志记录框架可以通过其他功能群集来实现某些功能,例如用于时间同步的功能或用于通信管理的功能。
图 15.1日志和跟踪概述
Functional Cluster 提供了一组基于生成器模式设计的 API 以创建非模型化消息 同时提供了一个名为 ara::log::Log 的成员函数来发送模型化消息
相较于基于非模型化的消息接口，在该方案中单个函数调用即可完成所有参数的传递至 Logger 实例，并通过一次性操作完成必要操作以生成及发送消息。这一设计的优势在于即使最终这些模型化消息并未被输出（因它们的日志级别未达到配置的日志级别阈值），它们的运行时开销也会非常小：在完成参数传递及函数调用后会立即进行日志级别的检查并返回。这与基于非模型化的消息接口形成鲜明对比，在后者中通常需要通过多次函数调用来构建复杂的消息对象（即便该对象最终会被丢弃）。
16.功能安全
16.1功能安全架构
AUTOSAR通过提供安全感描述与功能需求规范来支持自适应平台在安全性层面的功能整合，在当前版本中已明确将这些内容分别以解释性文件框架（A UTOSAR_EXP_SafetyDescription框架[12]）与标准需求文档形式[RS_Safety标准][13]进行组织与表示
这些文件旨在帮助功能安全工程师在AUTOSAR自适应平台上识别与功能安全相关的主题。该列表包含有关如何将RS_Safety[13]和AUTOSAR_EXP_SafetyOverview[12]中的内容映射至ISO 26262[14]内容及其结构的通用指导：
AUTOSAR自适应平台基于其理论基础与核心任务之间的关系展开研究，并将其在不同适用范围下的应用案例进行了详细阐述（AUTOSAR_EXP_Sa fetyOverview [12]）
系统定义、系统上下文和故障注意事项（AUTOSAR_EXP_SafetyOverview [12]）
危害分析（AUTOSAR_EXP_SafetyOverview [12]）
安全目标（AUTOSAR_EXP_SafetyOverview [12]）
功能安全概念和功能安全需求（RS_Safety [13]）
技术安全需求（RS_Safety [13]）
该文档（AUTOSAR_EXP_SafetyOverview [12]）旨在陈述顶级安全目标以及相关假设的具体用例或场景。作为解释文件，它包含了假设、示例性项目（例如参考模型）以及/或对示例性技术解决方案、设备、过程或软件的引用。该文档中的此类假设或示例性项目仅用于说明目的。值得注意的是，这些假设并非AUTOSAR标准的一部分。
需求规范RS_Safety[13]对RS_Main[2]中的高级安全功能进行了详细说明。该规范建立在本文档所描述的功能预期之上，并依据EXP_SafetyOverview中所述的安全目标与危害来源形成了明确的技术保障框架。其中涉及的技术保障不仅涵盖了AUTOSAR功能集群本身的技术要求，并且还延伸至与其相关的所有安全应用领域。
以下内容计划在以后发布：
技术安全概念和技术安全需求
安全需求验证、安全分析和典型用例
最后指出的是：不能保证其完全符合 ISO 26262 [14] 标准。即使采用AUTOSAR自适应平台的安全功能组件构建系统时，在理论上也存在违反该标准的可能性。即使是在最优设计的情况下，在构建基于 AUTOSAR 自适应平台的安全系统时，在某些方面仍可能无法满足 ISO 26262 的严格要求。
16.2信息交换保护（E2E保护）
支持AUTOSAR平台中的端到端（E2E）分析功能，并允许AUTOSAR应用程序（AP）和概念节点（CP）实例之间的所有组合间实现安全通信。无论这些实例位于同一ECU还是不同的ECU中，在必要时提供相应的机制和支持服务接口等技术手段以实现自适应平台环境下的更强大的功能集以保障安全通信的有效性。通过提供的功能验证确保信息传输过程中的完整性并实现对数据完整性和传输安全性的监控与管理能力。该方案仅关注于数据处理与通信层面并未涉及对数据完整性和传输安全性的确认
E2E 处理通信故障，如文档 AUTOSAR_PRS_E2EProtocol [15] 中的 ISO 26262 [14] 所述。
在采用双向通信策略时，在发布者的执行过程中会同步实施 E2E 保护措施；而在订阅端的部分，则负责接收来自订阅者的进程数据以完成相应的保护任务。系统中的 E2E 检查机制能够识别并检测到通信中的故障情况，并提供相应的检查结果；然而它不会主动触发对这些故障的进一步响应或处理。
对于此版本，E2E 支持：
轮询模式下的定期和混合周期事件
方法（有关限制，请参阅 AP SWS 通信管理）
事件（有关限制，请参阅 AP SWS 通信管理）
字段（有关限制，请参阅 AP SWS 通信管理）
在 E2E 保护周期机制中, 原理在于发布者通过将事件数据顺序编码, 并附加特定于 E2E 的标记头来实现数据传输. 当接收事件时, 在线订阅方会调用或运行 E2ECheck 函数/过程, 并返回相应的结果. 该结果指示传输过程中是否存在可被检测到的故障状况, 请参阅由预先配置好的 E2E 配置文件所定义的标准和范围. 一旦完成上述检查流程, 则可以进行反向解码或反序列化处理以恢复原始消息内容.
尚不支持以下操作：
标注模式下的事件
非周期性事件
方法（无约束）
详细说明了适用于全链路防护的配置参数文件及其相关消息流图这些内容详细说明在AUTOSAR E/E协议栈[15]和AUTOSAR通信管理器[16]中
16.3平台健康管理
该平台运行状态监测与管理软件负责对平台运行状态进行实时监控与评估。该软件具备多种独立运行的实时监控模块（所有模块均能够独立工作）：
活动的监督
截止时间监督
逻辑监督
健康通道监管
图 16.1：PHM 接口与其他组件
请注意健康通道（健康通道外部状态）已标记为不再使用，并将重新启用该功能于下一个版本的状态管理模块。
活动监督检查受监督实体是否运行得太频繁或不够频繁。
截止时间监督检查受监督实体中的步骤需在配置的最低与最高时间范围内执行。
逻辑监督检查执行期间的控制流是否与设计的控制流匹配。
活动、截止时间和逻辑监督是由API ReportCheckpoint报告检查点负责进行的应用/非平台服务或功能集群中的相关操作
健康通道监控具备了将外部监控数据（如RAM测试和电压监控等指标）为平台健康管理提供支持的可能性。
该通道的运行状态监控依赖于API ReportHealthStatus 用于收集并反馈运行状况的状态信息。
平台运行状况管理会在受监督的实体中检测到故障时通知状态管理器。
一旦发现执行流程或状态监控失效时，平台运行状态的监控与维护将启动重新配置监视程序。
此版本的已知限制：
•尚未定义对诊断管理器的依赖性
CP 和 AP 共享的功能被基础文档进行了详细说明，并被命名为'运行状况监视'（RS_HealthMonitoring [17] 和 ASWS_HealthMonitoring [18]）。AP 文档专门介绍了 AP 的其他规范，并被命名为'平台运行状况管理'（RS_PlatformHealthManagement [19]、SWS_PlatformHealthManagement [20]）。
请注意，关键组件EM（电子管理系统）、SM（软件管理系统）和PHM（物理 health management）与系统安全高度关联; 安全执行管理和运行状况监视构成了自适应应用安全运行的核心支撑. EM、PHM、SM 元件间相互依存并协调运作, 以保证AUTOSAR自适应平台的功能性安全保障.
16.4 系统健康监控
系统健康监控（System Health Monitoring, SHM）实现了与平台无关的运行状态监控。该系统致力于在多控制器和机器间跨越多个平台实现系统的-wide错误处理协调机制。
该组件可依需求选择作为主实例或客户端实例进行部署。通过传递平台关键状态数据至主节点实现状态监控的任务由SHM客户端完成。从子系统层到功能层再到域层逐步确定各层级的状态指示指标，并最终在车机端完成这一过程。所得的状态指标不仅可用于平台层面的故障恢复操作，同时可结合服务运行质量参数（类似于服务质量）进一步优化服务性能。
基础文档中的RS_HealthMonitoring编号[17]详细阐述了系统健康监控的要求。该规范则具体涵盖了系统健康监控接口及其运行状态指示符格式的抽象规范描述内容，并可在ASWS_HealthMonitoring编号[18]中找到相关技术细节说明。
图 16.2：SHM 概述
17. 核心类型
核心体系确定了多个功能集群之间相互作用的核心类与功能模块作为它们之间的公共接口基础部分。在设计核心体系时的一个基本原则就是包含那些在接口定义文档中频繁出现的常规复杂数据类型的集合体。
17.1错误处理
17.1.1概述
错误处理被视为任何软件开发的核心议题。在安全关键软件领域中，则显得尤为重要——因为生命的可靠性与之紧密相连。然而，在C++ 异常机制方面所面临的挑战尤为突出。对于 ASIL 应用而言，则面临一个根本性的问题：由于这些编译器缺乏对 异常的支持而导致开发者无法直接利用 C++ 的 异常处理功能
该自适应平台引入了新的概念，在未触发C++异常的情况下完成错误处理，并定义了一系列相关的C++数据类型以辅助实现这一目标。
从应用程序员的视角出发，在这个概念的核心类型中使用 ara::core::ErrorCode 和 ara::core::Result 是最有效的选择。
17.1.2错误代码
在软件中使用ara::core::ErrorCode的具体实例表明了其代表特定错误情况的作用。与std::error_code不同的是，在某些关键方面它们采用了不同的机制。
ErrorCode 必须包含枚举值（去除整数类型的指针）以及对错误域的引用。枚举值明确标识了不同类型的错误信息，并通过指针指定该信息与相应的问题关联起来。另外一种情况是存在其他可选成员的情况：例如，在这种情况下系统可能会显示额外的信息提示或警告信息，并结合当前问题提供更多的帮助功能支持。这些额外的信息提示通常由两种来源提供：一是用户自定义的消息字符串；二是供应商提供的额外详细的错误描述信息。
在自适应平台上，在每组功能集群可配置一到多个错误域。例如，在'核心类型'功能集群中设置了两个领域：'core'和'Future'；这些领域涵盖不同类型的误差码。
17.1.3结果
该类 ara::core::Result 作为容器类型，能够容纳成功值或错误信息。基于其模板化设计的特点，在使用该类时，默认情况下所定义的异常状态可以采用任意数据类型来表示结果或出现的问题信息。然而，默认情况下该类所定义的异常状态可以采用任意数据类型来表示结果或出现的问题信息，并预计这一配置将在 Adaptive 平台的广泛应用中持续保留下来。
由于错误类型已设置默认值，在大多数情况下，默认设置下使用的ara.core.Result实例只需指定其值的类型。例如，在ara.core.Result
受控值或错误可通过Result中的成员函数访问/获取Result::Value和Result::Error。调用方负责确保只有当Result实例分别包含值或错误时才会调用这些功能。要确定结果是否包含值或错误，请使用Result::HasValue方法。由于这些方法不会触发异常处理机制，在没有C++异常支持的环境中也能正常运行。
除了前述无异常的工作流之外
17.1.4 Future与Promise
与 ara::core::Result 类似地用于同步函数调用的广义返回类型中 ara::core::Future 则用于异步函数调用的广义返回类型。
ara::core::Future完美地模仿了std::future，并实现了与其他类型如Result的无缝集成。
类似于 ara::core::Result 的是 ara::core::Future ，它既包含一个值也可能伴随错误信息 。可以从两个途径获取相关信息：
通过调用 ara::core::Future::get，它返回包含的值（如果存在），否则会引发异常
通过调用 ara::core::Future::GetResult, 这个函数会返回一个 ara::core::Result 对象, 其中包含与来自 Future 的值或相关的错误信息。
这两个调用都将阻塞，直到异步函数调用提供值或错误为止。
17.2高级数据类型
除了在上一节中提及的错误处理的数据类型之外，在自适应平台中还包含了多种其他的数据类型以及相关的程序辅助功能。
其中某些类型已经在C++11标准中存在；然而，在ara::core命名空间中会重新定义那些具有近似行为的类型。其原因在于std::类型的内存分配行为通常不适合汽车用途。因此，ara::core自定义了自身的内存分配策略
此类数据类型的示例包括 Vector、Map 和 String。
在 ara::core 中定义的其他类型的定义已迁移到较新版本的C++标准库中，并已被迁移至 ara::core 命名空间以实现某种功能需求。这些关键类型被整合进 ara::core 命名空间的原因在于其对支持一些关键构造而言不可或缺，并且由于它们被认为对API实现大有裨益
此类数据类型的示例包括 StringView、Span、Optional 和 Variant。
17.3主要数据类型
该文档AUTOSAR_SWS_AdaptivePlatformTypes[7]规范了可在ServiceInterface描述中使用的基元类型。未来有可能将其纳入核心类型文档的范畴。
17.4全局初始化和关闭函数
这些函数可用于处理启动与终止自适应应用的初始化过程中的相应数据结构和线程：
ara::core:: Initialize
ara::core::Deinitialize
ara::core:Initialize负责初始化AUTOSAR AA运行时的数据结构和线程。在此前无法与Autosar运行时进行交互，在主程序入口处必须调用此函数即静态内存已完全初始化之后根据功能集群规范应用需提供额外配置数据如为日志记录设置应用ID或执行额外初始化如启动FindService即可完成其他API操作此类操作须在其后执行若在此前执行任何与Autosar运行时相关的API操作将会导致未定义的行为如果在此期间执行任何操作将会被功能集群拒绝并显示错误
ara::core::Deinitialize会导致AUTOSAR Adaptive Runtime for Applications的所有数据结构和thread被破坏。在此调用之后将无法与ARA进行交互。该调用必须在main函数内部执行，在其完成静态初始化且静态初始化数据尚未销毁之前进行。在调用ara::core::Deinitialize之后，在销毁静态初始化的数据之前对 ARA API 的调用将被拒绝并返回错误信息或者未定义的行为；如果未定义错误将会导致未定义的行为发生；而一旦销毁了静态初始化数据则对该系统的API进行任何操作都将导致未定义的行为。
18. 检测系统管理器
IdsM是AUTOSAR入侵检测系统（Intrusion Detection System, IDS）的一部分。
IdsM配置了用于接收安全事件的通知机制。这些事件可借助其他功能集群和自适应应用中的安全感知系统来进行报告。除了收集之外,IdsM还具备根据可配置规则对这些事件进行资格认证的功能。IdsM会对收集到的安全事件进行审核,并将其转换为合格的QSEV。这些QSEV将被进一步处理以实现存储或转发的目的。基于整体安全概念,QSEV可以从ECU本地存储或者通过IdsR发送至SOC
注意：IDSR 和 SOC 不属于 AUTOSAR 的官方认可部分。SEM 在下一个版本中将采用 IDSM for Classic Platform 进行描述。
概念文件中的下图演示了 IDS 架构概述。
图 18.1：分布式 IDS 架构
参考文献：
[1] 词汇表
AUTOSAR_TR_Glossary
[2] 主要要求
AUTOSAR_RS_Main
[3] 自适应平台的方法
答UTOSAR_TR_AdaptiveMethodology
[4] 自适应平台软件架构说明
AUTOSAR_EXP_SWArchitecture
[5] 4+1视图架构模型
[6] 执行管理规范
AUTOSAR_SWS_ExecutionManagement
[7] 自适应平台的平台类型规范
AUTOSAR_SWS_AdaptivePlatformTypes
[8] 同步时基管理器规范
AUTOSAR_SWS_SynchronizedTimeBaseManager
[9] 身份和访问管理 AUTOSAR_RS_IdentityAndAccessManagement要求
[10] 身份和访问管理规范
AUTOSAR_SWS_IdentityAndAccessManagement
[11] 清单规范
AUTOSAR_TPS_ManifestSpecification
[12] 安全概述说明
AUTOSAR_EXP_SafetyOverview
[13] AUTOSAR Adaptive Platform 和 AUTOSAR Classic 的安全需求平台
AUTOSAR_RS_Safety
[14] ISO 26262-2018（所有零件）道路车辆.功能安全 http://www.iso.org
[15] E2E 协议规范
AUTOSAR_PRS_E2EProtocol
[16] 通信管理规范
AUTOSAR_SWS_CommunicationManagement
[17] 运行状况监视的要求
AUTOSAR_RS_HealthMonitoring
[18] 运行状况监视规范
AUTOSAR_ASWS_HealthMonitoring
[19] 平台健康管理要求
AUTOSAR_RS_PlatformHealthManagement
[20] 平台健康管理规范
免责声明：由AUTOSAR 官方文档转译，仅供学习交流