Adaptive AutoSAR 标准介绍

关于自适应AutoSAR 平台

自适应AutosAR平台为 adaptive applications 提供了运营环境的支持。该平台提供两类接口：一类是服务接口（Service），另一类是API接口。平台的功能模块划分为两大类：一类是服务模块（Service），另一类是基于 自动化扩展的AutosAR核心（Adaptive AUTOSAR Basis）。

功能集合包括

1. 自适应平台的功能集合

2. 定义需求描述

3. 从应用和网络角度描述软件平台的行为

然而，并不意味着 adaptive 系统受限于特定的软件架构设计

每个（虚拟化）机器上只需要配置一个自适应式AUTOSAR平台的基础组件实例即可满足需求。其中的服务模块不需要有具体实现细节，并且可以在车载网络内部空间中进行设置。

相较于classic AUTOSAR方案，在运行时能够动态地实现服务连接这一特性上 Adaptive AUTOSAR方案具有显著的优势，并且这种设计能够充分结合实时性与灵活性的特性，在支持客户端与服务端之间进行灵活配置资源以满足不同业务需求的同时 也能确保系统能够高效可靠地运行

19-03 Adaptive AUTOSAR 架构概述(2)

2.1 智能ECU的前景

传统的ECU主要承担替换成或增强机电系统的功能。通过接收特定指令来调节电信号的输出。这些输入和信号来源于车内网络中的其他ECU。大多数软件的设计目的是应用于汽车，并在整个汽车使用周期中保持不变。

新增的汽车功能例如自动化驾驶将在此过程中引入高度复杂的计算资源为此"车内"软件需具备完整性与安全性这些软件负责实现环境感知与行为规划等功能并将该车整合到外部后端及基础设施系统中随着外界系统的升级"车内"中的软硬件需定期进行升级以确保车辆稳定运行

传统上采用AUTOSAR架构来满足嵌入式ECU的需求；然而这一架构却无法满足上述所提到的需求。为此，在此基础上开发出了自适应AUTOSAR(AP)平台；该平台具备高性能计算能力和可靠的通信机制；此外还支持灵活的软件配置方案；针对CP设计的独特特性（如接入电信号与汽车专用总线系统），这些特性可以通过模块化的方式集成到AP中进行扩展应用）。

2.2 技术驱动

主要有两个技术驱动，一个是ethernet,一个是处理器。

随着汽车网络日志的增长带来的带宽需求上升，ethernet因此被引入。与传统的车内[通信技术]（如CAN）相比，在提升带宽的同时提供更高效的信道资源分配能力。能够实现高效传输长消息并支持端到端通信。尽管cp支持ethernet协议，并且在一定程度上与其兼容性良好；然而由于其主要针对传统通信技术进行了优化设计，在发挥Ethernet潜力方面仍有提升空间。

随着汽车在dynamically evolving intelligence capabilities, the processing power demands for their processors are increasingly elevated. The conventional multi-core processors have been integrated into the system, yet the processing capacity requirements exceed those of a multi-core architecture.

2.3 Adaptive 平台特征

C++开发

面向服务架构

并发处理

复用已有标准

safety and security

计划动态

可以动态的管理资源和通信来降低软件开发和集成的工作量。

2.4 可以继承AP,CP和非AUTOSAR ECU

19-03 Adaptive AUTOSAR 架构 概述(3)-架构

3 架构

3.1 逻辑层架构

展示了AP系统的整体架构设计。其中一些功能源自于Adaptive平台基础组件和服务，并通过AUTOSAR运行时整合了各类功能组件的接口。任何自适应应用都可以向其他自适应应用提供服务。

从应用程序的角度看, 这些功能接口在本质上没有区别, 无论这些功能来自 Adaptive Platform Foundation 还是 Adaptive Platform Service. 仅提供 C++ API 或者未来 AP 可能会支持的其他语言 interface. 这两部分内部实现必然存在差异, 并且在 ARuntime API (ARA) 库中可以使用除 Ara 以外的语言或 interface 来实现 AP 规范, 这取决于 AP 实现的具体方式

需要特别注意的是，在图3-1所示的AP架构逻辑层所包含的功能集合并非当前发布版本的一部分。这些未在本图中展示的功能将在未来的版本中逐步加入

语言绑定， C++标准库和POSIX API

这些API采用的语言是C++...并且其所属的标准库属于C++编程框架中的核心组件之一

C++ 标准库整合了大量基于 POSIX 协议的标准接口，并包含了多线程 API 功能。不建议将 C++ 标准库中的 线程 接口与 PSE/51 的 标准 实现混用。鉴于此，在这种情况下混用应用将带来显著的风险

应用程序启动和关闭

从执行管理角度来看，程序的生命 cycle 由 EM 管理。程序启动与终止则依赖于 EM 提供的相关功能。为启动一个应用程序，在系统集成阶段必须完成相应的配置设置。从 EM 的视角来看，默认情况下所有功能都是相同的，并且它们采用相同的加载机制。图 3-2 展示了 AP 内不同类型的程序类型

实际上，并非EM而是其他机制决定了应用程序的启动与停止。状态管理（State Management）负责这一职能。状态管理会根据系统的整体设计指令来协调不同状态的变化，并以此调节整个系统的运行模式。这里指的就是由机器AP及其内部应用构成的整体运行环境，在特定项目背景下实现这一机制。同时与其他功能模块协同工作以确保整体系统的协调运行。为了确保不同AP栈之间的兼容性与可移植性，建议采用 industry-standard ARINC接口进行配置与管理

应用程序交互

主要关注的是AA之间的交互关系问题上,PSE51系统并未包含IPC（inter process communication）这一功能,因为该系统中并未设计任何明显的接口来实现不同组件AA之间的直接交互.通过通信管理模块CM（Communication Management），实现了内部机与机之间基于服务的通信.无论服务与客户端程序在架构部署上的具体分布情况如何,该系统都能够有效地处理各种服务请求及相应回复的消息路由.值得注意的是,除了上述提到的服务级协议机制外,其他一些高级功能模块（AREA相关）也能够通过特定的方式触发不同组件间的互动,但这些额外功能并非系统设计时特意提供的显式通信接口,而是这些高级模块作为附加功能所自然具备的功能

非标准接口

AA与其他功能组也可调用非标准接口,但前提是它们与标准AP功能不产生冲突,而且这些组合也必须满足项目对safety及security方面的需求.特别地,在大多数情况下,那些仅用于纯应用程序本地运行库应尽量保持最小化应用范围,因为这可能会导致其他AP实现中软件移植性的受到影响.

3.2 物理架构

本研究关注的物理层架构主要出于阐述目的，并未涉及任何AP形式化的软件需求。对于所有经由AP实现的形式化需求均需详加说明

OS, 进程和线程

AP操作系统需具备支持多进程中置的能力，在模块化架构下每个AA实际运行单位都构成独立的操作系统，并各自拥有独特的逻辑存储区域与名称标识。单一AA架构可能同时支持多线程或分布式服务，并发单元可在单一实例中运行或分散配置至多个AP节点上。基于组件化架构设计的原则下，系统将每个功能模块编译生成相应的程序实体，并通过共享资源实现协作运行；这些程序实体可在同一实体内协同运行，并且整体架构允许整合多种功能组件与服务模块

功能簇被视为一种特殊的进程类型。每个功能簇能够由单一或多个进程来执行。Adaptive平台提供的服务项以及非Adaptive平台提供的服务项同样构成相应的进程中继任务模块。

每一个这样的进程都可以选择是否采用单一处理器或多线程架构。根据其所在的逻辑层次别别采用相应的操作系统API。当运行于Ara之上时，则应选用PSE51.当属于某个功能簇时，则可自由地应用 OS 的API.

总体来说，在操作系统（OS）层面来看，AP与AA实际上构成一个基础集合体的组成部分。每个进程中可能包含一个或多个线程体核以执行特定的任务。然而需要注意的是其功能实现基于AP的具体实现情况以提供不同类型的分区管理能力，在此过程中并未体现出明显的差异性特征。在数据传输机制方面，则主要依赖于Inter-Process Communication (IP C)或其他操作系统提供的通用接口功能进行交互操作。进一步指出的是，在某些情况下（如AA进程中），可以通过Area-Restricted Addressing (ARA)来进行通信而不依赖于Inter-Process Communication (IP C)机制。

基于库或基于服务的功能簇的实现

如图3-1所示的AP架构中，一个功能簇既可以被视为Adaptive平台的一个功能组件，也可以被视为平台提供的服务。这些组件都需要通过Inter-Process Communication（IPC）和Agent Authentication（AA）进行交互。实现这些组件的方法有两种途径：一种是基于库的设计方法，在这种情况下功能簇会提供一个接口库，并通过该接口与AA直接进行通信；另一种是基于服务的设计方法，在这种设计下进程会利用CM提供的服务功能——其中包含一个代理库来连接到AA系统，并由代理库负责协调与Server进程之间的通信流程。在实际应用中可以选择是否仅在AA中直接调用CM来实现IPC通信，或者采用代理机制并通过代理库来完成对Server进程的协调任务以实现IPC通信

在选择功能簇设计时，请遵循以下通用指导原则：如果该功能簇具有本地单一AP实例的能力，则建议采用基于模块化架构的设计方案。这种方案不仅更加简洁直观，并且能够显著提升运行效率；而如果该功能簇由各自独立的是AP实例构成，则应考虑采用基于服务级别的协议（QoS）机制进行配置。通过这种机制能够实现异步的数据传输与负载均衡管理；属于Adaptive 平台的功能簇主要采用基于模块化架构的设计方案，并且Adaptive平台主要采用基于服务级别协议（QoS）机制来实现功能管理。

最后指出, FC的具体实现方式并非必须严格遵循库的形式或进程的方式,而是可以在满足FC定义所规定的RS和SWS需求的前提下采取其他方式.具体而言,在这样的实施策略下, AA与FC之间的互动机制本质上相当于一般的进程调用,而非像先前所描述的那种基于IPC机制的交互.

功能簇之间的交互，

一般而言 FC 之间可以交互采用 AP 特定的方式, 因为它们不受 AR 共享接口的限制. 例如 PSE51 不允许选用 PIC. 它能够利用其他 FC 的 AR 共享 interface 进行通信. 为了实现某些特别的功能, 这些 interface 可以通过保护性地提供优先访问权限来实现.

并且自第18版开始新增的一个概念Inter-Functional-Cluster(IFC)被引入其中用于指明功能组件之间如何建立连接点需要注意的是该概念并不是ARE的一部分也不是用于定义API形式的需求仅为为了更好地明确功能组件之间的关系从而促进API规范体系的发展这一术语为用户提供了更加直观的功能组件架构理解这种架构体系在功能组件的服务定义文档附录中有详细的描述

机器/硬件

AP允许的硬件相当于一个machine。其背后的根本原理在于无论采用何种虚拟化技术手段都能实现统一的基础。这个机器既可以是真实的物理设备也可以是虚拟机甚至包括半虚拟化的操作系统或者基于OS级别的容器以及各种其他形式的虚拟环境

在硬件上可以安装一个或多个机器，在每个机器上运行一个CP实例。一般情况下等同于一台芯片，在这个基础上可以安装并运行多个机器实例。如果AP实现支持的话，则可以采用多片式架构来构建更大的计算单元。

3.3 方法论和清单 methodology and manifest

为实现分布式系统的功能性应用及独立性要求,需采用Agile development作为基础. AUTOSAR Adaptive Methodology提供标准化定义并对应的服务,应用程序,机器与配置等关键元素的任务. 相关任务定义了在Adaptive平台上如何交互不同活动以实现信息交换的目的. 图3－4是一个详细说明Adaptive方法论实现过程的草图. 其具体细节可在附录3中找到.

3.4 清单

这个清单是对AUTOSAR 模型的说明。这个清单配合着为AUTOSAR AP产品配置参数。Manifest可以通过某种方式导入到AP 产品，并将其与相关的文件（如二进制文件）集成到一起。

其应用受限于Autosar平台。然而这并不意味着即使在Autosar平台开发的应用程序中生成的ARXML也不会直接被视为一个 manifestation. 实际上值得注意的是，在汽车相关项目中并非所有Autosar AP 都会被采用。

一个典型的汽车也包含了多个集成相应的CP单元的ECU模块。基于此可知，整车的系统设计必须整合了两种类型的ECU：分别集成相应的CP单元和AP单元。

按照惯例, manifest这个词被定义为在概念上仅包含一个实例. 所有的应用实例都可以在这个语境下进行处理. 显而易见地, 这种做法并不合理. 因为模型相关的元素始终包含于典型项目开发的不同阶段.

这部分是应用设计的主要驱动力之一。将manifest划分为三类是极其重要的。

该系统涉及的应用设计不仅涵盖使用AP 软件构建各类设计方案的具体步骤，并且这一过程详细阐述了使用AP 软件创建所有相关设计方案的方法。然而，在执行列表和服务实例列表中所定义的应用程序部署策略有助于明确应用程序布局。

执行列表。这种列表的位置是用来详细说明AP应用程序运行时部署相关数据的。执行列表与实际执行的代码紧密关联以支持可执行程序在机器上的集成。

服务实例清单列表。这种清单用于描述按照传输协议要求如何配置面向服务通信的方式。该列表与实际可执行代码以某种方式连接起来，并用于实现基于服务的方法的应用。

机器列表用于说明运行AP应用程序所需的机器及其部署配置这些配置将与构建AP实例所需的软件关联起来

这种临时定义的不用清单会引起困惑。大多数情况下每个文件各自存储三种清单。

除了采用基于程序设计的方法以及三种不同的清单之外,AUTOSAR方法论还支持系统的整体性设计,它被广泛应用于汽车智能化领域。用于描述AUTOSAR平台下的相关软件模块,这些模块通常在同一个系统中的同一个模型里运行,不同 AUTOSAR 平台下的相关软件模块通常采用面向服务的方式进行交互,然而在将信号与服务之间的映射关系通过两种不同的方式——即面向服务通信与信号通信——进行关联时

3.5 应用程序设计清单

应用程序的设计描述了所有AP应用软件创建的设计相关的模型。

应用设计关注一下几个方面。

• 数据类型用来说明软件设计和实现的信息

*服务接口作为面向服务的通信的关键元素。

*定义应用如何访问面向服务的通信。

*持久接口是访问持久数据和文件的关键元素

*定义用用程序如何访问持久存储。

*定义应用程序如何访问文件。

*定义应用程序如何访问加密软件

*定义应用程序如何访问PHM模块

*定义应用程序如何访问时间基数

*序列化属性用来定义如何序列化网络传输上的数据

*REST服务接口是通过REST模式与web服务通信的关键元素

*客户端和服务器功能的描述

*分组应用程序以简化软件的部署

在应用程序设计过程中所定义的构件不受应用程序软件具体部署方式的影响，并因此使得在不同部署场景下实现应用程序功能时能够更加高效地复用相关实现部分

3.6 执行清单

执行清单的主要目的在于包含AP应用程序实际部署所需的关键信息内容。这种设计思路旨在尽可能减少代码对特定部署场景的高度依赖性。

使用可执行清单可以控制应用程序的实例化， 因此，

*在同一台计算机上多次实例化相同的应用程序软件

将应用程序软件部署到多台服务器上，并为每台服务器创建独立的运行环境以运行应用程序软件。

执行清单关注一下几个方面

配置信息旨在确定应用程序实例的起始方式。该起始过程涉及设定起始选项以及授权角色。每个起始流程主要取决于机器运行状态以及相关的功能组件。

*资源管理，特别是资源组分配。

3.7 服务实例清单

在网络环境中实施基于特定通信技术（如SOME/IP）的服务式通信。因为服务提供者与请求者的行为应保持一致的一致性需求下, 服务的设计必须满足互操作性要求.

服务实例清单关注以下几个方面。

*服务接口部署，以定义如何在特定的通信技术上表示服务。

*服务实例部署，为特定的服务实例定义所使用的通信技术要求的证书

*E2E保护的配置

*信息安全保护的配置

*Log和trace的配置

3.8 机器清单

机器清单允许配置在特定硬件(机器)上运行的实际AP实例。

机器清单关注以下几个方面

*设置网络连接的建立并设定基础证书参数(例如，在以太网中,这涉及赋予固定IP地址并配置 DHCP 服务)。

• 服务发现技术的设置（例如，在SOME/IP的情况下，这涉及到采用特定的IP端口以及定义相应的组播地址）

*定义使用的机器状态

*定义使用的功能组

可自适应平台的功能集群配置实现(例如，在系统中设置具有不同授权类型的系统用户)

*配置密码平台模块

*配置PHM

*配置时间同步

*可用硬件资源的文档(例如可用内存大小;有多少个处理器核可用)

19-03 Adaptive AUTOSAR 架构 架构概述(4)-操作系统

4. 操作系统

4.1 概述

该系统负责执行时间调度任务，并与所有AP应用之间实现了进程间的通信。其中，OS组件与EM组件协同运作。平台初始化过程由EM完成，并通过调用OS来启动和终止应用程序。

AP平台不会为高性能处理器提供新的操作系统。而是它规范了adaptive 程序使用的执行上下文和操作系统的接口（OSI）。

OSI规范包含了程序接口。这些程序接口构成了AP标准API AR部分的基础。操作系统能够很好地支持创建进程。这些界面用于满足EM启动应用的需求。然而这些功能的界面仅能作为AR部分使用这一定义基于平台实现

OSI同时也支持基于不同编程语言的操作系统接口设计，并提供了相应的开发框架支持。针对基于C语言的应用程序而言，在其主要业务逻辑实现中会包含遵循POSIX标准所定义的一系列基础函数调用操作（具体参考IEEE 1003.13 [1] 中关于PSE51的标准定义）。在编译阶段通过编译器选择合适的本地操作系统提供的本地化开发库来完成相应功能模块的具体编码实现（通过编译器选择合适的本地操作系统提供的本地化开发库来完成相应功能模块的具体编码实现）。在运行时阶段进行链接以整合本地库以确保各子系统的协调运作（在运行时阶段进行链接以整合本地库以确保各子系统的协调运作）。针对基于C++开发的应用程序而言，在其核心组件设计中会包含遵循ANSI C++标准以及相关的STL（Standard Template Library）组件集合来进行功能扩展与数据处理（在核心组件设计中会包含遵循ANSI C++标准以及相关的STL（Standard Template Library）组件集合来进行功能扩展与数据处理）。

4.2 POSIX

在市场中存在多种操作系统支持POSIX兼容接口，并非仅限于Linux这一类系统。然而，在平台服务和基础功能方面相对而言较为完善的情况下，在应用层面使用操作系统API却受到一定的限制。

基于一般性的假定，在用户的应用程序中建议采用PSE51作为操作系统接口，在平台层则采用完整的POSIX系统。若在应用程序层次上需求增加特性，则这些新增特性将源自POSIX标准而非通过新定义的方式引入。

其功能的实现可能采用未来版本中的POSIX API。这些API的操作权将授予开发人员而非按照标准化的方式。

4.3 调度

该操作系统能够运行多个线程与进程。其调度机制遵循POSIX标准中的SCH\!FIFO与SCRR两种方式。此外，还有如SCHEME\!DEADLINE等其他操作系统特化的调度策略也是可接受的方式需要注意的是，各API实现之间无法互相移植

4.4 内存管理

多进程支持的背后原因之一是由于实现了不同功能集合与AA间的互不干扰。由于OS的多进程支持而迫使每个进程独立运行于各自专用的内存空间，并与其他进程保持隔离并得到保护。同一可执行文件可以在不同的内存区域运行，并能够共享相同的入口地址、代码库以及起始数据值。然而，在启动时的数据却存放在内存的不同物理页面上。

4.5 设备管理

设备管理将在POSIX PSE51接口中提供。有关详细信息，请参阅POSIX规范。

19-03 Adaptive AUTOSAR 架构概述(5)-执行管理 (EM)

5 执行管理。execution management (EM)

5.1 概述

EM承担着对系统的全面管理职责，在这个过程中涵盖了平台初始化、应用程序启动以及程序退出等环节。在日常运作中，EM与操作系统的协同作用使得应用程序的时间资源得到有效调度。

5.2 系统调度

当机器开始运行时，在其执行过程中首先进行操作系统初始化。随后以EM作为操作系统启动的第一个核心进程。这些功能集合及AP foundation平台级的应用则由EM发起启动。当AP foundation建立并稳定运行后，在其完成任务的基础上EM继续负责启动AA进程的具体安排。具体启动顺序则由EM依据预先编排的机器列表和任务清单来动态安排。

5.3 EM的责任

EM负责AP 执行管理的所有方面。应用程序执行管理包括：

1. 平台生命周期管理

执行管理被视为Adaptive平台启动阶段的一个组成部分，并在该阶段开始运行；同时负责初始化Adaptive平台以及已部署的应用程序。

2. 应用程序生命周期管理

执行管理负责承担已部署应用程序的有组织启动与正常停止运行。依据机器清单与执行清单中的信息内容确定了已经部署的应用程序集合，并基于已经声明的应用程序依赖关系来推导出启动或关闭的顺序。当机器的状态以及功能组的状态变化时，在自适应平台开始运行之前或者之后进行应用部署。然而由于许多应用会向其他应用提供服务需求 并非所有这些应用都能立即开始活跃工作 因此系统必须持续监控 incoming service requests.

应用程序运行时间的调度不是EM的职责而是由OS来完成。然而, EM承担了为操作系统设置初始条件和配置参数的任务;这使得系统能够在基于机器清单和执行清单的信息下进行必要的时间管理。

5.4 决定执行

确定执行实现了某种计算方式，在给定的输入数据集上能够在有限时间内生成统一的结果。这种执行管理不同于时间驱动型和数据驱动型。前一种状态是在最后截止日期之前持续生成的产物；而后一种状态则能通过相同的输入集合及其内部状态生成一致性结果。对于此类场景下的支持策略，则主要关注于实现确定性驱动的设计模式。为了满足这一需求，在软件封锁的情况下,DeterministicClient将与可选软件封锁框架交互,从而保证冗余执行行为的一致性,DeterministicClient则与CM交互,以实现同步的数据处理与周期激活行为

图5-2 为确定 DeterministicClient 支持的服务端客户机及其与应用程序之间的交互提供了详细说明

5.5 资源限制

该平台允许多个Adaptive应用程序在同一台机器上运行从而确保无干扰成为系统的特征。因此应当限制行为异常的Adaptive应用程序以避免对其它应用程序造成干扰。例如应尽量避免让应用程序占用超过规定时间的CPU资源因为这可能导致其它程序无法正常运转。

通过将应用程序进程合理分配至一个或多个ResourceGroup来实现对执行过程的有效管理。每个ResourceGroup被指定限定的CPU时间与内存以约束应用使用的资源总量。

5-6 应用恢复

执行管理机构在状态启动/停止时依赖于状态管理机制。因此该系统必须具备足够的权限来控制进程的启停。为了监控运行中的过程情况,本系统引入了PHM模块用于实时分析各关键指标。当任何一个运行中的过程超出预设参数范围时,会触发恢复程序的具体实施步骤。具体而言,恢复操作的具体实现由软件集成商基于其自身需求进行定义,并将在任务调度系统中进行预先配置

19-03 Adaptive AUTOSAR 架构概述(7)-通信管理

7 Communication Management 通信管理

7.1 概述

在分布式的实时嵌入式环境中，CM模块负责应用之间通信的所有方面。

其背后的概念是从实际机制中提炼出识别并建立通信伙伴关系的方式, 便于程序开发人员专注实现特定功能

7.2 面向服务的通信

服务的内涵是指向应用程序提供的功能超越了基础操作软件所呈现的功能。通信管理软件承担了实现机内与机间通信所需的技术支持功能。

服务由Event, Method, Field 组合组成

在设计、启动以及运行的过程中可以建立通信路径。其中关键的部分是Service Registry. 在CM软件体系中扮演代理角色的则是Service Registry。

在设计、启动以及运行的过程中可以建立通信路径。其中关键的部分是Service Registry. 在CM软件体系中扮演代理角色的则是Service Registry。

为每个应用提供服务的系统在Service Registry中进行登记。 而一个消费型的应用系统则需要通过查询 Service Registry来找到所需的服务，并将这一过程称为Service Discovery。

7.3 语言绑定和网络绑定

通信管理采用了系统化的手段（即通过将定义的服务呈现给应用程序实现者（上层），以及展示服务在网络数据中的各自表示形式（下层）），从而保证了源代码的移植性和不同平台实现间的兼容性

语言绑定基于目标编程语言的便捷特性实现了将服务中的方法、事件和字段转换为可直接访问的标识符。性能与类型安全性（只要目标编程语言支持）是主要追求的目标。因此通常由服务接口定义提供的源代码生成器实现。

网络绑定定义用于将配置服务的实际数据与特定网络进行关联。这种关联可以通过两种方式实现：一是通过解释性生成特定针对服务的配置配方；二是直接生成相应的序列化代码以完成数据绑定功能。

本地Service Registry也是网络绑定的一部分。

note: 语言绑定与网络绑定之间的接口属于CM软件的机密接口。因此此类接口不在讨论范围内。然而，在他们的平台内部独立定义这样的接口被视为一种鼓励，并且这种做法也被认为是为了实现除了C++以外的语言绑定和其他网络功能的支持。

7.4 生产C++绑定的代理和框架

C++绑定机制支持基于AUTOSAR元模型的接口描述中的面向对象服务映射实现。

该工具的一部分创建C++类，并包括field、event、method以及类型安全的表示方式各服务的方法。

在服务实现端中, 这些创建的类被称作**.... 在客户端中, 他们被称为service request proxy**.

对于服务方法而言，在线查询代理模块能够提供同步与异步的操作方式。使用该模块时，在线查询者不仅具备启动多个任务的能力，并且能够在服务器返回结果时通过其核心数据类型ara::Core::future的独特属性来处理响应数据。参考第18.1节

平台需要设置以便在生成器各服务器不可用时生成相应的模拟类以方便客户端功能开发。同样的方法也可以应用于客户端单元测试

开发人员可以将代理类直接用于系统设计，并将其与现有的业务逻辑集成。然而, 该C++绑定的框架仅是一个抽象化的基础结构,其核心功能尚未具体化。为了实现完整的服务体系,开发人员应创建基于生成基类的新服务,并在其基础上实现所需功能。

ara::com的接口不仅承担代理功能并构成通信框架；同时这些接口的设计确保了应用程序在不论E2E保护处于开启状态还是关闭状态下都保持兼容性。

7.5 静态和动态配置

通信路径的配置可以发正在设计，启动和运行阶段。因此考虑静态或动态

• 全静态配置

服务发现不再需要因为服务器知道所有的客户端，客户端也知道服务端。

*应用程序没有发现代码

客户端能够识别服务器身份,但服务器无法识别客户端的身份.Event 订阅是唯一的形式,其基于事件驱动机制进行动态配置.

*应用程序中的完整服务发现

在配置时未预先规划通信路径的情况下可能会遇到问题。通过API机制，在运行时阶段允许应用程序动态选择服务实例以解决这一问题

19-03 Adaptive AUTOSAR 架构概述(8)-Restful Communication

8 Restful Communication

8.1 概述

两个通信方案 ara::com 和 ara::rest可以在 Adaptive 应用之间实现通信路径的建立。ara::rest 是构建基于 Restful API 及其之上特定服务的框架。它未提供定义开箱即用的特定API 来直接构造 RESTful 服务。该框架具有模块化设计，在允许开发人员直接访问 Restful 消息事务中涉及的不同层次方面表现突出。另一个显著区别在于 ara::rest 确保与非 AUTOSAR 节点之间的兼容性。比如说, ara::rest 服务可与移动 HTTP/JSON 客户端实现通信, 相反的情况同样适用.

8.2 架构

ara::rest遵循模块化架构，适用于API级别和服务架构开发人员。该部分展示了一个通用的设计方案。详细阐述了如何构建基于ara::rest的服务应用程序。

ara::rest层作为RESTful接口的基础架构仅包含三个核心抽象：一种基于树状架构的消息payload类型、URI地址空间以及支持GET或POST等标准请求方法的数据传输机制。基于这些基础功能规范了特定领域内的RESTful API设计原则及实现方式，在对象图与URI地址空间交互方面形成了统一的技术规范体系。这种架构旨在为特定数据域提供规则规范并为应用系统提供统一化的接口服务（C++风格）。此外，在无需进一步抽象的情况下，Adaptive应用程序可以直接调用ara::rest进行操作。

8.2 组件

ara::rest 由以下模块组成

Object Graph represents a tree-like data structure bound to specific protocols, forming the foundation for all communications within the ara::rest framework. Its primary objective is to facilitate the mapping of protocol formats, such as JSON, into C structures, ensuring seamless interaction with non-ARA communication nodes and Classic AUTOSAR standards. Object Graph propagates messages abstracted from specific lower-level protocols across the system, enabling efficient data exchange while maintaining compatibility with diverse platforms. If necessary, users can still access protocol-specific details when needed.

信号负责处理请求/应答通信周期全部内容，并将其打包到 ara::rest 的异步编程模型中去。

该系统通过路由概念实现了对请求（包括不同的请求方法和URI）与用户自定义处理函数之间的映射，并且能够有效地管理网络流量分配与路径选择问题。该技术方案以路由为核心机制，在将通用REST架构升级至特定类型RESTful API方面发挥了关键作用。

Uri是一种通信的与RFC兼容但高效的URI表示。

该接口（称为ara::rest）作为服务器与客户端之间的通信渠道提供了一个网络端点。这些端点均具备较为充足的资源控制能力。然而，在某些特定场景下（如单核与多核系统），这种架构可能无法满足高性能需求。

整个框架的总体架构旨在充分提高资源利用率与效率。所有计算及资源分配过程均按照规范化管理执行，并基于应用程序（部署）的具体运行需求进行定制优化。

19-03 Adaptive AUTOSAR 架构概述(9)-诊断

9 诊断

9.1 概述

诊断管理实现了基于ISO 14229-1 (UDS)和ISO 13400-2 (DoIP)的ISO 14229-5 (UDSonIP)。

在诊断管理中采用基于ara::com的技术来构建服务层上的自适应平台功能集群系统。该功能集群系统不依赖于特定的语言实现，并在未来可能会与其他编程语言（如Java）协同工作来实现自适应应用程序。

配置基于Classic平台的AUTOSAR诊断提取模板（DEXT）。自DEXT发布以来逐步进入市场，并已广泛应用于多个OEM和供应商。

该平台采用基于DoIP的传输层。预计Adaptive平台将采用基于CAN等其他传输层。也可能计划引入定制化的传输层方案，由于DoIP在车载应用中较少使用。

该范围源自于从Adaptive应用程序中抽取的诊断协议设计。这些接口在功能上与Classic平台保持一致，并参考了如SetEventStatus这样的典型操作来确保兼容性和易用性。

In the AUTOSAR Classic platform, diagnostic functions are specifically designed for ECUs equipped with microcontrollers, enabling the execution of DCM and DEM functionalities. However, the AUTOSAR adaptive platform takes into account the future integration of multiple processing units, such as microcontrollers, processors, GPUs, and other devices. This necessitates the development of a new mechanism to address the diverse components within AP machines.

原子更新/扩展部分由软件集群SoftwareCluster(SWCL)负责处理。该软件集群整合与更新安装或部署一组特定的新功能/应用程序相关的所有内容。因此，Adaptive\ Diagnostics\ Manager为每个已安装的SoftwareCluster独立建立一个自含且专门配置过的诊断服务器实例。这些实例均具备独特的诊断地址标识，并且在架构设计上充分考虑到了系统的可扩展性需求。值得注意的是，该软件集群不仅具备完整的管理能力，并且通过与其他系统组件进行深度集成，在功能实现上实现了无缝对接。

9.2 诊断通信子集

诊断通信子集群类似于Classic平台采用的DCM架构，并完成了对诊断服务器的功能实现。当前系统支持的服务较为有限，在后续版本中将增强对统一设备状态（UDS）服务的支持

除了现有ISO 14229-1半自动平行客户机处理方案外，在功能模块上进一步发展了诊断管理器(DM)，使其能够实现对所有不同类别的诊断客户机进行全面且高效的并行支持。这一升级彻底满足了现代汽车架构所需的各种功能需求：涵盖多终端的数据采集（由测试人员执行），提供后端系统的访问接口，并实现了基于SOTA（软件无线传输技术）的最佳通信策略；最终目标是通过整合经典研讨会成果与实际生产案例来完善整个系统架构设计。

诊断感知Adaptive应用程序(AA)

在这种情况下，由DM将传入的一个诊断请求（通常属于常规控制或与DID相关的各项服务）发送至AA，并由其提供相应的展示功能（即UDS服务类型下的特定服务接口）。其中日常控制服务接口具体包括'start'、'requestResult'及'Stop'等功能，并且对于程序中可能出现的各种应用错误情况也都设置了相应的UDS错误码标识。

AA从UINT8-Array解析参数或序列化成UINT8-Array

在这个用例中，在请求中的data-parameter#1位置的所有UDS数据参数与正响应中的data-parameter#1位置的所有UDS数据参数共同构成服务方法的输入-输出端口，并采用(UINT8)Vectors的形式进行输入/输出操作。对于这种类型的用例，并未与任何特定的UDS请求建立映射关系而是直接进行转发处理，并且由于其能够灵活地处理各种不同的请求模式因此有必要引入了GenericUDSService接口。

方法参数以输入/输出形式给出

基于与DiagExt中相关数据参数#N直接关联的diagnostic dataelement的类型规范，在此用例中将从请求中起始的数据块start-node#1延伸至end-node#1的所有UDS数据字段进行处理，并将其与响应中起始的数据块start-node#2延伸至end-node#2的所有UDS对应字段进行对比分析

9.2.1 诊断对话

如上所述, 因为DM需要实现伪并行及全并行客户端处理, 所以该系统能够建立在诊断客户端与诊断服务器之间映射一个独特的对话. 该系统的诊断服务器将根据UDS请求的目标地址来确定其位置信息, 并且在Adaptive平台运行期间会自动配置位置信息.

请注意：涉及ara::diag的部分开发讨论正酣。截至目前为止，并未确定具体内容。

9.3 时间内存子集

时间内存自己就像Classic平台的DEM一样，它负责DTC的管理

支持的功能及接口与Classic平台一致。诊断监控以(诊断)事件的形式可与DTC集成。DTC可作为配置主内存的依据，并基于日期格式（如19.02.04.06）进行主内存分配；同时用于配置用户内存，则采用特定的地址格式（如0x19.17.18.19）。DTC具备存储SnapShot- 和ExtendedDataRecords的能力。

采用基于Counter debounce和Timebase debounce的方法进行去抖动处理。此外，在内部转换过程中将相关信息传递给各相关方：DTC的状态字节发生变化会被告知，并且监控诊断事件重新启动的需求也会被报告；此外还需要确认Snapshot- 或ExtendedDataRecord是否有变化发生

操作周期变化对老化和敏捷计算非常重要，需要转发给DM。

不仅适用于存储以及启用条件。变化内容应由DM接收。启用条件可调节DTC的关键参数。例如，在电压条件下应关闭所有网络相关监视器。

19-03 Adaptive AUTOSAR 架构概述(10)-持久性

10 持久性

10.1 概述

持久性通过提供一种机制，在Adaptive平台的应用程序与功能簇之间实现了信息存储至Adaptive机器的非易失内存。这些数据在其启动及热启动期间同样可存取。该系统支持通过标准接口访问Adaptive机器中的非易失内存区域。

该持久性API通过接收应用程序生成的存储位置标识符来确定多个存储位置。

可用的存储位置分为两类

*键值存储

*文件存储

每个应用程序都可以使用多种存储类型的组合。

private data within a single application is inherently protected. there is no existing mechanism that allows for the interchange of Persistency data across separate applications. The decision was made to prevent the creation of an alternative communication pathway within the communication management framework.

该系统确保了敏感数据的安全性，并且在将其存储至物理设备之前就已经进行了加密处理。

10.2 键值存储

键值存储通过一种方式在一个单一存储单元中存取多个键值对。键值存储直接支持以下三种数据类型：数值型、字符型和布尔型。

• 在SWS_AdaptivePlatformTypes中定义的数据类型

• 由应用程序中复杂类型流产生的简单字节数组。

所有通过 PersistencyKeyValueDatabaseInterface 引用 dataTypeForSerialization 实现的数据类型，在程序设计中被特别使用用于 PersistencyDataElements 的情况

每一个键值对在各自的数据库中都是独一无二的；这些键值是由应用程序通过Persistency提供的方法来定义的。

对于包含在应用层面的AUTOSAR数据类型，在计划中实现根据应用和平台特性的编码逻辑。

10.3 文件代理存储

并不存在一种适用于所有与持久性存储相关数据的存储机制是基于键值对的构造方式。

针对这类数据信息体系结构设计了一种基于文件存储的机制。每个文件存储端口都赋予了一个应用程序访问特定存储位置的能力，并在此基础上实现了应用层面的多评估者并发访问机制。每个评估者的唯一性标识符都是基于字符串形式的唯一键值对。

跟文件系统进行比较有助于更深入地理解这种机制。在存储端口的位置上等同于一个目录，在这个目录中应用实例能够创建多组数据(assessors).

因为数据存储和传统文件系统在访问方式上相似，在C++ std::iostream中提供了类似的功能作为其子集的API。

10.4 UCM模块处理持久性数据的用例

在UCM阶段利用Peristency进行持续集成的管理，在这种情况下，所有与存储相关的操作都受限于特定的存储配置参数

一般而言，在绝大多数 CAR ECU 和 adaptive 设备的运行周期内，UCM能够支撑多种典型的应用场景来实现对 adaptive 系统的支持。

• 在Adaptive机器上安装新的adaptive 应用软件

*在Adaptive机器上更新存在的adaptive 应用软件

*从Adaptive机器上卸载存在的adaptive 应用软件

在所有这三种不同的情况下, Persistency通过UCM用于管理应用程序的持久性数据存储, 包括部署、删除和更新.

Persistency 支持下面提到的场景

Persistency 支持在 Adaptive 应用安装过程中将持久性数据部署至应用程序开发者指定的键值存储系统或文件代理中

Persistency 实现了在 Adaptive 应用安装时将持久性数据部署到集成人员修改的键值数据库或文件代理中的功能

Persistent ability of the Adaptive application to deploy persistent data can be configured by the integration team, either through key-value databases or file proxies, when installing the Adaptive application.

在升级过程中，在安装新版本的应用程序时，在应用运行时可以通过特定的更新策略来覆盖/保持所需的数据于键值数据库及文件代理中。

Peristency在处理应用卸载过程时能够有效清除键值数据库或文件代理中的持久性数据项

一般情况下，在应用开发及部署阶段都会设置Persistent性层。建议采用基于部署阶段设置的方式去覆盖应用层面的设计参数。当应用层面参数出现丢失情况时，则会默认将这些参数视为持久化存储数据。

Persistency会在整合前进行操作，在整合时会检查新增或更新的关键数据存储。

19-03 Adaptive AUTOSAR 架构概述(11)-时间同步

11 时间同步

11.1 概述

当处理分布式系统中不同事件之间的关联时，在不同应用程序或ECU之间实现精确的时间同步（TS）是最重要的任务。无论是在跟踪这些事件时还是在准确的时间点开始时进行操作都会影响系统的整体性能。

鉴于此原因, 为应用程序提供时间同步API, 进而能够获取与其它实体/ECU同步的时间数据。

时间同步功能由系统预构建的不同的时间基础资源（TBR)来提供。

11.2 设计

为了满足Adaptive平台所需的时间同步要求，可以通过选择以下几种不同的技术方案来实现时间同步需求。

• Classic平台的StbM

• chrono库-无论是std::chrono(C++11)或boost::chrono

• Time POSIX 接口

在分析各个模块接口及其覆盖功能之后, 时间同步的设计动机是为了模仿std::chrono风格, 从而封装 Classic 平台中的 StbM 模块所具备的功能.

时间同步模块考虑下面几个方面的功能：

*启动行为

*构建行为（初始化）

*正常操作

• 错误处理

在将来的发布版本会考虑下面几个方面的功能

• 关闭行为

• 错误分类

• 版本检查

11.3 架构

应用程序能够访问每个时间基础资源（TBR)不同的专用类实现。

借助该句柄, 应用程序可用来获取由Time Base支持的各种类型信息（包括上述提到的五种类型）, 然后可用来获取对应Time Base类型的专用类实现. 借助该句柄, 则能方便地生成定时器实例.

在其他节点或ECU中，并不采用基于网络时间协议的方式遵循Time Base同步TBR

该系统具备特定的功能模块，并通过时间同步以太网获取时间数据，并与同步TBR机制进行协调

该应用通过TBR获取并管理时间数据。由此可见，TBR充当了一个基于时间的基础代理角色，并实现了同步访问。由此可知，在实时Time Base 服务提供者的基础上构建TS模块是可行的。

19-03 Adaptive AUTOSAR 架构概述(12)-网络管理

12 网络管理

12.1 网络管理算法概述

AUTOSAR NM基于分散式网络管理策略，在通信系统接收并转发NM信息的基础上实现各网络节点独立的操作

该算法利用按照固定周期发送的NM消息，并通过多播机制使所有节点均接收这些信息。

接收NM消息的行为表明发送端希望维持NM集群在唤醒状态。若某台设备有意进入休眠状态，则该设备将停止发送相关通知；但一旦其他设备持续发送此类信息，则该设备需延迟完成转机操作。最终若因无法收到此类信息而导致专用计数器超时，则所有设备将执行转入休眠的状态转移过程。

当NM集群中的每个节点发起总线通信请求时，则该集群的所有节点均需通过启动传输相应的NM消息以维持整体运行状态

12.2 架构

Adaptive平台详细规定了AUTOSAR Adaptive平台的功能、API设计以及网络管理的配置；所有这些设置均不受所使用的底层通信媒体的影响。当前阶段仅限于以太网的应用，并非针对所有总线架构；体系结构则不受制于总线

网络管理（NM）采用了基于状态管理的方式来实施，在实际操作中发现部分网络节点的控制依赖于SM对EM功能组状态进行协调，并与相关应用程序集进行交互。目前本章的内容尚未充分反映出这一设计思路。

其核心目标是通过内部协调实现状态机机制下对底层通信网络（包括部分网络、VLAN或物理信道）正常运行与总线休眠模式之间的转换。

该服务接口由其支持完成发布网络并查询实际运行状态。这些实例被整合管理以生成统一的机器请求。

当采用部分网络特性时，则Nm消息可以携带部分网络(PN)请求。从而使得ECU有可能选择性地忽略相关联的PN Nm消息。此方案使得关闭整个ECU或其一部分成为可能。尽管通信仍在其他地方运行。

当采用部分网络特性时，则Nm消息可以携带部分网络(PN)请求。从而使得ECU有可能选择性地忽略相关联的PN Nm消息。此方案使得关闭整个ECU或其一部分成为可能。尽管通信仍在其他地方运行。

19-03 Adaptive AUTOSAR 架构概述(13)-更新配置管理(UCM)

13 更新配置管理

13.1 概述目标

Adaptive AUTOSAR声明的一个主要目标之一是通过OTA（无线传输）实现软件和服务配置的灵活更新。为了以适应Adaptive平台上的软件更改需求，在这种情况下UCM提供了一种基于OTA Adaptive服务来负责处理相关的软件更新请求。

UCM承担Adaptive平台的应用更新工作，并负责包括安装/移除以及维护软件记录功能。此外还具备以安全可靠的机制来实现对自适应平台上的软件进行更新或修改的能力。

13.1 更新协议

UCM服务致力于为诊断通信子软件集群提供诊断用例，并在安全、可靠且资源消耗低的情况下对自适应平台进行调整。为了解决能够处理多个客户端的更新以及快速下载的问题，UCM必须区分软件包（UCM输入）与其相应的处理过程。

13.2.1 数据传输

U的数据传输借助于ara::com的数据流实现。该系统能够有效地将数据输入至UCM系统中，并无需额外设置外部data buffer. UCM系统将接收的包件存入本地存储库，并确保了 UCMM 手段根据请求处理相应的数据

基于这一分隔性设计的UCM架构中，在两个独立的环节（即传输环节与处理环节）之间实现了数据的有效交互与协调。该架构支持多客户端的数据接入过程，并且这种架构设计没有任何限制或约束。

13.3 包

13.3.1 软件包

UCM中的安装组件将作为软件包进行输入。这些软件包通常包含一个或多个可执行程序（具有Adaptive功能的应用程序），操作系统更新、固件版本以及可更新配置数据等。这些内容共同构成了软件包的可更新组件以及Adaptive平台上的实际变更内容。除了传统的应用程序和配置数据外，在每个软件包中还包含一份软件 manifest文件。该文件列出了软件包的基本信息包括名称、版本、依赖关系以及其他可能的相关生产厂商消息等信息。这些信息用于处理和管理相应的软件包内容。

由于软件包的具体格式未做明确规定，在UCM实现层面可采用多种解决方案。由用于在软件及元数据中执行更新的组件构成的软件包内容可通过供应商工具生成，并经目标端UCM处理。在将软件部署至目标端时,OEM可将其打包至预装于容器机上的OEM容器中。当特定于OEM的应用程序运行时,该应用程序会接收预装于容器机上的OEM包裹,并在传输至UCM前进行解压与解密操作。

UCM根据提供的元数据处理生产商特定的软件包。

13.3.2 后端包

软件组件遵循厂商特定的标准格式。
然而, 尽管后端组件由厂商自主开发,
但根据规定,
其清单(如图13-2所示中的标注的部分)
必须采用ARXML格式

你可以在以下找到必须包含在软件包清单中的字段的描述，以供参考:

通用信息

• Package name：完全合格的简写

• Version：软件簇的版本需遵守https://semver.org 的语义版本规范，在此规范下异常构建号对于调试和跟踪而言是必要的。StrongRevisionLabelString 原子类型

• isDeltaPackage: boolean, 如果内容是按照增量包处理的，该字段激活

*Dependencies: 该清单模型包含了描述软件包更新或安装后的依赖关系信息。在进行增量更新时，这个依赖关系会表示当前软件簇版本与前一版本之间的依赖性情况。以下是一些具体的示例：

大小，以允许检查是否有足够的内存可用:

• uncompressedSoftwareClusterSize: 目标平台的软件簇大小

• compressedSoftwareClusterSize：软件包大小

用于信息和跟踪目的

• Vendor: vendor id

• Vendor signature

• Packager: vendor id

Package signature: 为了确保软件包的一致性和安全性, 包签名机制能够为后端环境下的软件包及其相关组件提供身份验证功能. 这一机制不仅适用于对软件包清单ARXML中包含的数据进行签名, 还能用于对可执行文件等关键组件进行验证.

• Type approval: 可选的，homologation information

• Release notes: 描述本次发布变化

• License: 比如MIT， GPL，BSD，专有的

为了在车内将包分发给正确的UCM

• Diagnostic address: 比如以防包通过UDS来自tester

• UCM identifier: 车辆架构中的唯一标识符

• Activation action: 可以重新启动，重新启动应用程序还是什么都不做

• Action type: 更新，安装或删除

13.3 汽车包清单

车辆多由OEM后端整合，并涵盖软件组件汇总。这些组件从存储于该数据库中的相应部分提取。此外还包括一个汽车分发清单，该清单由活动安排以及完成车辆内包装发所需的各种字段组成。（图13-4）

下面信息描述在汽车包清单中必须包含的字段。

 List of backend packages: SWCL names 列表

Dependencies: 软件簇之间会否决已存在于软件包中的特定依赖关系。这是车辆系统集成商常用策略以引入更多技术细节便于后续开发。

 Origin: uri, 存储库或诊断地址，用于历史记录、跟踪和安全目的

 Version

 Vehicle target: 版本描述

 Campaign orchestration: 下面是模型例子

例如，在下载并更新时出现的问题中

13.3.4 软件发布和打包流程

为了构建后端组件集（APF），继承方必须选用与目标UCM兼容的打包引擎。此打包引擎可由Adaptive平台栈厂家提供配置。当集成商完成可执行程序、列表以及持久性组件的装配后，则可通过该打包引擎按照Adaptive平台栈厂家指定的标准格式生成一个软件组件集合（SPK）。随后该软件组件集合将与ARXML组件集合一同嵌入到APF中。Adaptive平台栈厂家提供的打包引擎或集成商均可对这一软件组件集合进行数字签名，并将数字签名包含于组件集合列表之中。为避免后续修改需求带来的影响，在传输至集成商及OEM末端时应确保所有组件及其数字签名均被封装至同一个容器内

集成到后端系统的软件组件可以存储于后端数据库中。每当汽车需要进行软件更新或安装新增文件时, 后台服务器系统会从该数据库中获取相应的软件列表, 并将这些列表整合到汽车自身的软件配置清单中。在该清单中, 后台服务器会根据车辆的具体电子架构预设的活动安排进行整合, 如从车辆识别号信息中扣除相关参数

13.3.5 处理激活软件包

由该ProcessSwPackage接口处理三种操作：安装、更新和卸载。UCM能够在该接口所涉及的操作中解析相关元数据。

UCM序列设计能够涵盖A/B类型的更新方案或基于OSTree的设计方案（例如in-place场景）。这种设计为包管理者提供了向后恢复至先前版本的能力。

为了让实现更加简便可靠，在同一个时间段内仅有一个客户端能够利用ProcessSwPackage方法来处理软件包，并将UCM状态调整为BUSY状态。多个客户端可依次提交除传输之外的各项数据。当A/B分区处于更新场景时，请注意以下几点：首先，在非活动状态下（即B分区），多个客户端可同时处理相关业务数据；其次，在跨依赖关系的软件组件中，则需严格按照业务流程对各节点进行操作以确保正确性与稳定性。完成之后，请确保所有相关操作均已完成并返回结果列表中对应的位置之后，请等待系统完成后续初始化操作并返回结果列表中对应的位置之后，请等待系统完成后续初始化操作以确保一切正常运行

无论哪个客户端发起请求，在该系统中都会使用Activate方法来激活所有已处理过的包。为了在多个客户端之间正确协调场景（client端），建议使用master client这一术语。UCM可能并不清楚当前系统是否已经处理了所有的软件（software），但它会进行一个依赖性检查以确认当前系统状态与B分区安装的软件需求一致。如果无法满足这些依赖性条件，则UCM将不会激活该进程并将其切换至READY状态。

当更新被激活时,UCM的状态会转换为VERIFYING阶段。随后,UCM根据更新的类型对机器进行重置或重启功能组合。例如,在这种情况下（如果更新包含功能簇操作系统更新）,UCM可能需要重启机器。但是,如果这个更新仅与低重要性的功能相关,则仅需重启相应的功能组合即可减少不必要的麻烦。在这个阶段,UCM可以从PHM和EM中验证该目标软件簇是否能够正常运行。一旦这些操作顺利完成,则将系统切换至ACTIVATED状态

在启动更新过程中，在激活问题得到解决之前会暂停所有其他请求处理。UCM可选择调用Finish以完成任务、确认变更状态或避免回滚（例如该更新属于全局范围内的调整, 而另一台ECU的更新已失败）。

调用Finish后，UCM 会清理所有不需要的资源并返回IDLE。

当发起rollback操作时, UCM将切换至滚动回滚（ROLLING-BACK）的状态, 以重新激活旧版本的软件. 例如, 在此状态下, 如果是A/B分区的分区内, UCM将在下次重启前准备好并完成对旧版本软件的重新激活和执行.

13.4 软件信息报告

为了尚未完成提交以及最终完成提交的任务, UCM系统为不同阶段的任务配置了统一的服务接口.该系统不仅实现了对可自适应平台软件信息的有效获取,而且还特别列举了已传输文件包的具体名称以及版本号.在系统更新过程中会清除旧的状态记录,从而使得系统能够明确分配每个任务所处的具体运行阶段.

13.5 软件更新一致性和身份验证

UCM会采用加权签名的方式进行校验, 如图所示。Adaptive 平台采用了多种机制来验证该软件包, 包括加密后的校验码和其他特定厂家/ OEM提供的方法, 否则系统将返回错误提示。实际上, 为了确保认证算法的兼容性, 软件打包工具必须与目标 UCM 来自同一生产厂

基于哈希算法的认证机制下，在验证软件包时需确保其一致性。系统可通过调用TransferData、TransferExit及ProcessSwPackages等方法来验证软件包，并确保其一致性以覆盖各种测试场景。然而，在UCM系统处理任何软件包之前必须执行上述步骤以确保最大的安全性。

13.6 保护更新过程

UCM利用ara::com支持其服务。在UCM更新协议中缺乏认证步骤。另一方面，基于身份和访问管理概念能够保证通过ara::com请求UCM服务的客户端具有合法性。

UCM禁止在处理时间段内升级较旧版本的软件集合（如果攻击者尝试升级一个存在已知缺陷的老版本包，则会引发安全漏洞）

13.7 更新进程期间的安全状态管理

与系统设置相关的安全状态的确定由OEM负责完成。根据相关系统的设置和应用需求，在必要时系统可能会切换至一个'更新状态'以确保在更新期间不会错过任何重要但被忽略或出现错误的消息。

在更新完成后必须执行一个基本检查以确保一切正常工作状态。该OEM特定诊断应用程序将机器设置为'验证状态'并随后检查所有相关进程的状态以确认它们均处于运行状态。如果发现某些进程未被正确配置为运行状态则有可能执行回滚操作来恢复系统稳定性图13-9展示了这一流程的基本框架

19-03 Adaptive AUTOSAR 架构概述(14)-身份及访问管理(IAM)

随着信息安全需求日益增长,身份和访问管理(IAM)的概念应运而生.由于AUTOSAR Adaptive平台与应用程序之间必须建立健壮且良好定义的信任关系,因此IAM通过赋予Adaptive应用程序特权分离功能,并在攻击发生时提供针对特权升级的防护措施.此外,在部署阶段,IAM能够帮助集成者提前验证Adaptive应用程序所需的资源访问权限.最后,在服务接口、Adaptive平台基础功能簇以及相关模型资源的应用程序中,IAM提供了实现权限控制的关键架构框架.

14.1 术语

为了深入掌握该框架的工作原理, 需要明确关键术语. 同时也可以参考 RFC3189 中的 'Terminology for Policy-Based Management' (https://tools.ietf.org/html/rfc3198).

Access Control Decision: 该布尔量用于判断操作请求的权限是否被授权。其依据包括调用者身份信息及其相关的访问权限策略。

Access Control Policy: 该值则用于限制对特定对象（如服务接口）的访问权限。

*Policy Decision Point(PDP): PDP负责访问控制决策。该机制通过审查访问控制策略来判断应用程序是否能够执行相应的请求任务。

*Policy Enforcement Point(PEP): PEP将负责从PDP请求中访问控制策略以阻止来自应用程序请求的控制流程。

*Capability: capability作为Adaptive应用程序身份的一项特征存在。仅当请求AA具备所需资源的所有功能时, 才会允许对AUTOSAR资源（如服务接口）进行授权获取. capability则记录于该程序的manifest中.

Grant: During the Adaptive application deployment phase, all design capabilities must be validated. The Grant element exists within the metamodel framework. We are authorizing review of functionalities but prohibit partial acceptance.

Intermediate Identifier (IntID): 一种标识符,它能够识别并映射正在运行的 posix 进程,并将这些 posix 进程映射到已建立模型中的 AUTOSAR 进程.

Adaptive Application Identity (AAID): 基于自适应的自适应应用程序的建模标识符由AUTOSAR进程生成

Adaptive Application Identifier: 该系统中的一个引用机制, 即AUTOSAR进程, 在其运行过程中仅与单个AAID相关联.

14.2 IAM框架的范围和重点

该框架为支持Adaptive AUTOSAR 栈和Adaptive应用程序提供了一种机制。这种机制通过建模每个应用程序的功能来根据访问请求作出访问控制的决定，并执行相应的控制访问。该方案侧重于提供方法来限制Adaptive应用程序对Adaptive平台基础的接口、服务接口以及与功能集群相关的良好定义资源（例如KeySlots）的访问权限。特别地，在该方案中不包括系统资源（如CPU或RAM）的强制配额。

当请求被允许处理时, IAM组件会向Adaptive应用程序呈现透明的操作流程. 只有在请求被拒绝并发出通知时才会触发异常处理.

远程Adaptive平台支持的服务实例请求由IAM包含。传入请求中的PDPs应由Adaptive应用程序实现。

这个框架可以在运行期间内实现AUTOSAR资源的访问控制。假设Adaptive应用程序在启动阶段完成身份认证，并且现有的受保护的运行时环境通过隔离机制确保Adaptive应用程序被正确隔离，并阻止其非正常权限升级（例如旁路访问控制）。

14.3 AUTOSAR规范的内容

该表格列出了IAM框架中哪些部分是AUTOSAR所规范的；哪些部分是开发人员所决定的。

涉及领域：IAM需求规范；所属标准体系：AUTOSAR规范；涵盖于RS_IdentityAndAccessManagement中

涉及领域：IAM需求规范；所属标准体系：AUTOSAR规范；涵盖于RS_IdentityAndAccessManagement中

行为特征描述（涉及接口交互）；归依于：AUTOSAR规范；嵌入于SWS_IdentityAndAccessManagement模块中

该平台提供了基于AA PDP和PEP 之间的通信接口，并且该接口遵循AUTOSAR规范，在SWS_IdentityAndAccessManagement模块中进行了嵌入式集成。

描述：该平台开发了API用于PDP与PEP间的通信；AUTOSAR未提供相关信息

描述：涉及应用功能模块与权限管理方案（Manifest文件信息）；归类于AUTOSAR规范；包含于TPS_MANIFEST_Specification中。

描述：系统检测到认证失败的应用程序收到的告警信息及其异常事件数据的呈现形式及其细节；遵循AUTOSAR规范；涉及其中SWS_IdentityAndAccessManagement

描述：活动日志记录的API；隶属于：AUTOSAR规范；还没决定

描述：日志信息的内容；隶属于：AUTOSAR规范；还没决定

描述：Adaptive 应用程序和功能簇之间的接口；AUTOSAR没有说明；

描述：Adaptive应用程序在运行期间的标识；AUTOSAR没有说明；

14.4 IAM 框架的架构

14.4.1.1 通用架构

按照逻辑划分后分为两个实体。其中一个是负责判断Adaptive应用程序是否可访问资源（即基于权限数据保护机制中的数据保护计划或DPI——Decision Policy Interface），另一个则是负责执行实际的权限判定操作（即基于政策执行计划中的PEPlan或PEPlan实例——Policy Execution Plan）。那些对应用程序接口访问有限制的功能集群必须配置PEPlan以执行基于DPI的数据保护计划中的决策流程。由于这一原因，在Adaptive应用程序发起此类接口请求时必须确保PEPlan与相应的DPI保持通信状态。根据请求类型及应用功能的不同需求设置相应的策略规则即可实现数据保护计划中所需的各种操作流程。例如，在完成相关权限下的准备工作之后系统会根据应用清单中的功能信息动态生成相应的策略规则并将其分配给相关的业务处理单元以便后续的操作执行。

准备工作和假设

*应用程序被设计/配置为具有功能(允许它们访问某些资源的属性)。

*每一个功能都将在部署期间得到确认。

*部署的应用程序将进行加密签名，以使真实性验证成为可能。

*应用程序与包含功能的应用程序清单一起部署。

*遵循IAM约束的Adaptive应用程序须依次启动认证流程并维护其清单，在部署期间完成身份验证工作。PEP解析请求后指示PDP制定相应策略（可在同一进程中执行）。

14.4.1.2 Adaptive 应用程序的识别

在基于PDP的请求策略下，在线程层面实现身份认证的过程中存在一定的挑战性问题。由于每个调用都依赖于进程间通信作为中介机制，在这种情况下相应的中间件也必须能够处理此标识以确保身份验证的一致性与安全性。

标识符本身是基于已经建模好的AA进行引用。功能被关联到portprototype，并因此也被关联到SWComponentType（参见清单规范）。

IAM架构未明确定义AAs标识符。最理想的解决方案往往受到所选操作系统的架构及平台设计的影响程度较大。许多现代操作系统确实支持通信端点上对等点的标识（参见Linux中的SO_PEERCRED、getpeerid()或QNX中的消息传递）。对于无法采用该机制的情况而言，在消息层面实现协议可能成为一个可行的选择。

由于EM通过基于建模的方式生成AUTOSAR进程以支持Adaptive应用程序的功能实现，并赋予这些进程相应的执行权限（即运行Adaptive应用程序所需的PID值或其他关键属性），同时确保这些进程能够独立配置参数并提供独特的标识符（如UUID）。此外，在必要时EM还负责向这些进程分配密钥或唯一标识符（UUID），从而确保PEP能够通过建立相应的上下文关系来实现其功能需求。

PEP应旨在通过适配基础框架实现功能，并与其调用的应用程序进行适当隔离。因此，在调用时必须确保这些组件不会暴露敏感信息。

14.4.1.3 IAM序列

1. Adaptive 应用程序(AA)发起对资源的请求（比如服务接口）

2. PEP打断控制流

3. PEP通过EM解析请求进程的标识。

4. PEP将调用者的标识和请求参数传递给PDP。

5. PDP检查AA的功能是否足够，并将访问控制决策返回给PEP。

6. PEP通过阻止或允许请求来执行访问控制决策。

传递机制与EM用于识别AAs的方式是相同的。例如，在使用POSIX-Process-IDs时，在EM调用fork()的过程中会记录操作系统检索到的PID值。这些信息会被通过一个安全的功能组件接口传递给PEPs。当应用UID时, EM应负责设置新的POSIX进程的UID。

14.4.1.4 策略决定点的实现

决策点通过接口实现二进制策略决策处理的清单管理。这些决策基于规范设计的自适应应用功能及其应用程序清单。

该系统的功能可依据单个功能集群所具有的特定语义进行portprototype建模。由此可知PDP必须为此类功能性提供专门化的接口。与IAM框架相比，在处理此类功能性时，并不建议也不鼓励采用单独的方法。与此相反，在能力构建方面，则采取了以资源为中心的方式。在策略决策过程中,PDP主要关注于所请求资源相关的AAs引致情况。

Crypto API 提供了一个典型的 Crypto 功能示例。
当 KeyOwner 被分配一个参考特定建模密钥时，
支持对 key 的修改操作。

可信赖的自适应应用程序有可能实现PDP应用情境，并通过SWS_IdentityAndAccessManagement平台进行描述。该方案的具体实例可在AP18-10文档中找到。

14.5 平台之间的通信

由于应用程序被分布在不同的ECU或虚拟机上，在身份和访问管理方面存在跨平台的需求成为我们必须面对的问题。以下展示了一个具体的案例说明。

如同右侧所描述的那样, 平台实例A实现了用于核实程序A权限访问权的一种机制.在此处假设OEM特定的应用程序具备Adaptive功能.在左侧平台实例B中, 我们旨在构建第二个PEP, 它也连接到OEM特定的应用程序具备Adaptive功能.为了防止系统出现不可逆转的问题, 第二个PEP具有不可或缺的作用.随后, 第二个PEP会进行如下检查:首先确认至少允许一个来自程序A的应用程序访问系统Y;其次再次确认同样的条件.

一个实例的所有功能集必须与其他实例同步以确保第二个PEP能够正确实施。鉴于Adaptive平台缺乏标准化的数据交换格式，在此情况下我们建议采用OEM特定的协议来描述功能。为此建议OEM定义自定义的同步协议以适应非Autosar平台的需求

14.6 IAM的实现和使用

请看下面列表，它列出了在FC实现或系统设计中采用IAM所必需的步骤。其中详细 IAM相关细节可见 AUTOSAR\_EXP\_FCDesignIdentityAndAccessManagement.pdf 。特别注意上述文档中描述的信息源自AUTOSAR论证者，请将其视为实现建议而非直接方案。

准备步骤（在设计的时候）：

该应用经过设计与配置（拥有相应的权限），具备功能（允许程序访问资源属性），仅限于显示特定的服务接口。

*部署的应用程序将进行加密签名，以使真实性验证成为可能。

*应用程序和包含功能的执行清单一起部署

*执行列表还包括诸如app ID、多少个app instances以及这些app instances的ID之类的信息。

*FC实现PEP的实施逻辑。

*FC和策略一起部署。这些策略描述了那些功能需要访问提供的服务接口。

使用知道（运行期间）

当Adaptive平台启动时，在此期间OEM将给出一个应用程序（实例）ID与进程ID之间的对应关系表

当一个Adaptive应用程序发起请求访问配置为拥有访问权限的服务时,必须对其进行身份验证以便使其能够被引用

*PEP 将查询实现PDP进程的请求（可以是同一个进程）

随后, PDP会执行对应用程序ID及其相关功能的检查, 并将其与FC的存储策略进行对比.

*PDP发送访问控制请求（yes/no）回答PEP

*PEP实施访问控制请求（基于这个决定授权访问）

总结上述步骤，至少应考虑以下几点:

FC实现者需要：

*提供下面放在服务清单中的规则

1. 访问某些服务需要哪些功能(单个或多个功能的组合)

*访问实现PDP进程的逻辑实现

*实施收到的访问控制决定的逻辑实现

应用程序开发者需要：

*配置允许访问服务的功能。

19-03 Adaptive AUTOSAR 架构概述(15)-加密

15 加密

AUTOSAR Adaptive平台提供广泛的安全性功能与通用的安全密钥管理方案。API负责自动生成动态密钥，并在运行过程中执行加密操作以及对数据流进行处理。为了减少存储需求量，在设计时可以选择将秘密信息存放在内部硬件设备中；或者在外设中进行存储，并按需导入到主系统中使用。

该API旨在通过将安全敏感操作打包并作出决策来增强组件的安全性；例如，在硬件安全模块（HSM）中就可以实现这一功能。为了加强密钥管理能力, 可以采取限定特定功能的密钥使用（如仅解密）或基于IAM监控结果控制单机应用的密钥访问权限等措施, 从而实现对系统运行状态的有效监控与保护.

基于应用程序的支持，在处理诸如TLS和SecOC等加密协议时，API同样用于保护会话密钥以及中间层的隐私。

安全架构

尽管AUTOSAR API仅限于面向应用程序暴露高级加密堆栈接口（API），然而该API在设计之初就充分考虑了安全架构（architecture）的需求。其体系架构（architecture）旨在满足上述安全性与功能性要求（requirements）。

图15-1展示了通用架构的核心结构。在最顶层层次结构中, AUTOSAR AP与本地及混合应用通过连接至AUTOSAR AP的加密堆栈API进行交互。该系统的API实现可以通过调用一个中心单元（加密服务管理器）来执行平台级的任务,例如跨应用的安全权限管理和证书存储功能。这种设计还可以利用该中心单元协调涉及硬件安全模块（HSM）等资源的功能,从而执行密钥管理和加解密操作相关的任务。实际上,采用这种方式来进行卸载过程中的转移操作是一种典型的方案:通过加速特定的操作并保护托管密钥免受恶意程序威胁,从而实现了密钥管理和加解密功能的有效结合。

为了负责构建并维护这个层级的安全架构,Crypto Stack API不仅处理加密数据的批量处理,还支持本地功能运行:

（1）使用加密密钥或密钥句柄进行操作

（2）安全管理密钥，以防可能有些程序不合格

（3）限制应用程序对密钥的访问并允许对密钥进行操作

密钥管理架构

为实现安全远程密钥管理和防止潜在的应用威胁，在Crypto Stack的基础上沿用了一个新的密钥管理架构，并采用了基于端到端安全的方式来保护这些关键元素及其相关数据。这些秘密信息可以预先配置好的可信密码进行导入，并且也可以通过生成本地密码的形式进行导入。假设有一个足够安全的加密组件可用，则应用程序无法直接修改这些密码；但可以通过授权请求（例如更新或撤销）来进行相应的更改。

API扩展备注

增添新的权限或修改现有策略验证逻辑的关键新增功能模块应与对应的新密钥使用策略标志相关联。例如：配置新增安全策略并确保所有涉及这些新增安全策略的相关操作均严格实施新的逻辑处理机制；通过这种方式可引入具有独立所有权与访问权限划分的替代安全密钥以满足不同安全需求

19-03 Adaptive AUTOSAR 架构概述(16)-日志跟踪

16 日志跟踪

16.1 概述

日志跟踪功能集合承担管理及整合AUTOSAR Adaptive 平台的日志功能体系。该平台在开发过程与生产环节均可进行相应的配置设置。这两个用例存在差异性。通过设计的日志与跟踪组件系统可实现灵活的集成与定制化配置方案以满足全面的需求。根据具体配置参数设定的日志信息可向多个不同的接收端发送包括通信总线、系统内部文件以及串行控制台等多个应用场景下的数据流。所有输出的日志信息都会被明确标注不同优先级水平同时保证更高优先级的日志信息仅能被更高层次的日志客户端访问从而实现对潜在问题的有效识别与快速响应这一机制有助于防止系统资源超负荷运转从而确保平台整体运行效率。

基于AUTOSAR联盟内标准化的LT协议（Long Tracking protocol），日志与跟踪系统得以建立。该协议负责将日志信息打包为标准发布与展示格式，并提供了将ECU ID等附加信息纳入日志数据的选择。这些附加数据能够利用ECU ID等附加数据来关联、分类或筛选接收的日志帧。

此外，请呈现一种通用的方法：例如将十进制数据转换为十六进制或二进制形式。为了便于应用程序将日志和跟踪数据以符合LT协议的标准化序列化格式进行编码与存储这些是必要的

16.2 架构

命名空间ara::log包含了日志追踪接口功能。通过这一接口功能的应用程序能够将生成的日志信息转发给已提及的接收器。

基于后端的架构设计的日志追踪接口是日志框架的一个组成部分。它是由一系列功能模块组成的系统结构，并能够利用这些模块组合来实现特定功能如时间同步与通信管理等需求。

19-03 Adaptive AUTOSAR 架构概述(17)-功能安全

17 安全

17.1 安全概述

AUTOSAR包含了Adaptive平台的安全概述文档来促进在安全项目中Adaptive 平台的集成。该安全概述发布在一个专门解释Adaptive平台安全性的解释文档中（AUTOSAR_EXP_SafetyOverview）。

该文档旨在为Functional Safety Engineers提供识别Functional Safety-related Topics on the AUTOSAR Adaptive Platform. 本文件的章节划分目前尚未完全确定，在遵循ISO 26262标准时需注意内容与结构的一致性.

• AUTOSAR Adaptive平台目标，用例和使用场景

• 系统定义，系统上下文和假设

• 危害分析

• 安全目标

• 功能安全概念和功能安全需求

这个功能概述旨在从顶级安全目标以及假设中的用例或场景中提取安全需求并将其归入项目的架构元素或对应到外部度量。采用AUTOSAR Adaptive平台并不意味着必须遵循ISO 26262标准。该平台的安全措施与机制可能会导致构建不安全的系统，在最佳情况下,AUTOSAR Adaptive平台的架构通常被视为SEooC。

该解释文档基于特定条件包含若干假设，并采用代表性案例如参考模型、用例、场景等进行说明；其中提及的各种嘉禾或参考项仅用于阐述说明目的，并非AUTOSAR标准所涵盖的内容

本章的功能安全概念与初始功能安全要求仍处于探讨阶段，并不能被视为最终定稿

本章：

• 技术安全概念和技术安全需求

• 安全需求的验证、安全分析和典型用例将安排在以后的版本中。

17.2 信息交互的保护（E2E-Protection)

基于Autosar架构设计的应用程序能够实现复杂的通信需求。该应用通过支持所有AP与CP实例之间的组合连接，在同一台ECU或是分布在不同ECUs上均可以实现安全的数据交换。为此目的提供了机制来实现Adaptive平台中更高级的安全通信功能。这些功能能够确保发送到发布者的数据包以及接收到的数据包的完整性。该机制仅限于不提供传输确认，并且确保数据完整性。

当在发布者与订阅者之间实施E2E保护时，在同步阶段相应的发布进程会在同步过程中自动触发该保护机制；而从接收端的角度来看，在处理来自订阅者的进程数据时，则会自动执行相应的安全检查。

这次发布E2E支持：

• 轮询模式中的周期事件和混合周期事件

周期性事件的端到端(E2e)保护原则涉及将事件编码为二进制数据并附加头信息。当系统接收到事件时, 子系统会解码消息并授权执行 E2eCheck 检查. E2eCheck 通过返回指示来确认传输过程中是否存在可检测的错误（这些指示由 E2e配置文件规定）。

还没有支持的有

• callout模式中的事件

• 非周期性事件

• 方法

E2E保护使用的配置文件在AUTOSAR基础中描述（AUTOSAR_PRS_E2EProtocol）。

17.3 平台健康管理

该平台上的健康管理监管软件执行过程为该系统的核心组件之一。该软件能够展示全部功能均支持独立使用

• Alive 监管

• Deadline 监管

• 逻辑监管

• 健康频道监管

Alive监管检查被监管实体的运行不是太频繁，也不是太罕见。

Deadline监管审查被监管实体的步骤是否处于最大和最小限定事件范围内执行。

逻辑监管检查执行期间的控制流是否和 设计的控制流皮皮额。

健康频道检查可整合外部监控结果（如RAM测试、电压监控等）作为平台健康管理的重要组成部分，并为平台管理提供反馈机制的可能性

如果在被监管实体中发现失败事件，则平台健康管理能够触发一个可配置的恢复动作。

对AUTOSAR Adaptive平台来说，下面的恢复动作是可用的：

• 请求状态管理切换到特地的机器状态，功能组合状态或应用程序状态。

• 管理强制要求执行系统进入一个预先定义好的机器态或功能组别和功能组合态（EnterSafeState API）。若监管机制在运行过程中发现了问题，则可设置替代的安全态并对应配置另一个备用的安全API。

• 请求执行管理重启特定的进程（ProcessRestart API）。

• 请求watchdog驱动执行watchdog重置（实现者特定API）。

• 给诊断管理报告错误信息：在本次发布中没有说明。

• 转发错误信息给其他的PHM实体或应用程序：在本次发布中没有说明。

本次发布中已知的限制

*当前仅限于创建一个PHM实例。系统目前无法同时管理多个PHM实例以及它们之间的菊花连接配置。

• 诊断管理的依赖性还没有定义

• 监管模式相关的健康管理配置在本次发布中还没有完全支持。

AP和CP共同拥有的功能作为基础文档中的内容进行说明，并正式命名为"Health Monitor"（RS_HealthMonitoring, SWS_HealthMonitoring）。

其他规范仅在AP文档中以'平台健康管理'(RS_PlatformHealthManagement, SWS_PlATFORM_HEALTHAGEMENT)的方式进行描述和命名。

19-03 Adaptive AUTOSAR 架构概述(18)-核心类型

18 核心类型

核心类型构建了多个功能集合所使用的通用类与功能体系，并作为其公共接口的组成部分存在。在一个系统架构中，默认情况下会将所有子系统的共同特性集中存储于该核心类型之中，并在此基础上进行统一管理与协调运作。一个确定核心类型的原则在于其内部通常会采用那些在接口定义中频繁出现的通用复杂数据类型的特性与表现形式

18.1 错误处理

概述

在任何软件开发过程中,错误处理都是一个核心议题.关键安全软件的重要性在此凸显,因为它直接关系到系统的可靠性与稳定性.然而,目前广泛采用的安全关键软件开发标准对构建工具链施加了诸多制约,特别是在C++异常领域.基于此,在ASIL应用程序中采用C++异常变得极为困难

Adaptive 平台引入了新的概念以使错误处理无需处理C++异常，并且开发并实现了大量支持功能的C++数据类型来辅助。

从程序开发者的视角定义这个概念的核心类型体系归因于 ara::core::ErrorCode 和 ara::core::Result.

错误码

在C++代码中，一个实例代表软件内部的一个特殊错误状态。与std::error_code类似，在多数方面存在显著差异。

一个错误码始终包含一个整型类型（将类型从枚举转换为整型）以及对错误域的引用部分。其中枚举值代表了一个特定的错误类型；而错误域则决定了该错误在应用中的上下文背景。除此之外，默认成员还包括一个用户自定义的信息字符串以及一家厂商提供的额外错误描述值。

在Adaptive 平台内部的功能集合均设置了至少一个至多个错误域。例如，在功能集合‘Core Type’中设置了错误域‘Posix’。该错误域包括了根据POSIX 1规范所定义的标准代码。这些代码等同于C++ 11标准中所定义的std::errc类型。

在Adaptive 平台内部的功能集合均设置了至少一个至多个错误域。例如，在功能集合"Core Type"中设置了错误域"Posix"。该错误域包括了根据POSIX 1规范所定义的标准代码。这些代码等同于C++ 11标准中所定义的std::errc类型。

结果

该Result包装类被定义为一种复合类型，并且能够携带一个有效值或一个错误信息。由于使用了模板机制（template mechanism），该复合类型能够支持任意类型的值或错误信息（error information）。该默认的错误类型设定为 ara::core::ErrorCode ，并旨在保持在Adaptive平台上的统一性（coherence）。

因为错误类型存在一个默认值的原因，则在ara::core::Result中绝大多数的生命仅限于为值指定一个类型。例如，在ara::core::Result中包含一个整数或是一个错误码（Error Code）。

包含的值或错误可通过Result::Value和Result::Error这两个成员函数来获取；同时，在结果实例分别拥有一个值或一个错误时调用这些方法属于调用者的责任范围；例如使用Result::HasValue方法即可检索到结果中的相应信息；由于这些成员函数不会抛出异常因此它们可以在任何不支持C++ 异常处理环境里安全使用

除了前面所述的无需异常的工作流程外，在本类中可以通过调用ara::core::Result::ValueOrThrow方法将ara::core::ErrorCode转换为C++中的异常。该操作会按输入直接返回任何未出现错误的数据或对象，并会将错误信息包装成相应的异常类型进行处理。其中所使用的异常类型直接继承自被检测到的错误编码类型。

将来和承诺

与 ara::core::Result 类似地用于表示同步操作的结果时，在进行异步操作时使用 ara::core::Future 作为一种表示非同步任务结果的方式

ara::core::Future与std:: Future极为接近，在功能上极为相似，并且现支持与ara::core::Result互操作

和ara::core::Result具有类似的结构，ara::core::Future代表了一个成功的结果或一个失败的状态。这些内容可以通过主要途径提取:一种是通过显式指定结果或错误的方式实现的；另一种则是通过捕获异常并将其包装在一个Future中进行处理的方式实现的。

通过获取ara::core::Future::get对象，在其具有值时将该值放入集合中。否则，并抛出异常

通过调用ara::core::Future::GetResult方法会返回Result对象，并且该对象要么包含成功值要么包含错误信息。

这两条调用会block直到这个值或错误通过异步调用方法可用。

18.2 高级数据类型

除了前面部分涉及的AUTOSAR设计类型的外，在 Adaptive 平台中还拥有丰富的通用数据类型。

其中这些类别已经涵盖在C++11标准中；然而，在ara::core命名空间中重新定义了具有相同行为的类别。归因于std::types内存分配策略对汽车行业的不适用性问题，在ara::core专门制定了它们自己的内存分配策略。

这种数据类型的例子是vector, map, 和string。

其他类型的 ara::core 定义已经在 C++ 标准库中得到了明确指定。 Adaptive 平台将其整合进 ara::core 命名空间以满足特定构建需求；这一做法是因为它们对于构建某些关键组件不可或缺；同时这一选择也因其在 API 设计中具有重要价值而被采纳；例如常见的类型包括 string_view、span、optional 以及 variant 等数据结构类型。

18.3 原始数据类型

该文档中定义了另一份名为AUTOSAR_SWS_AdaptivePlatformTypes的文件，其中明确明确了若干基础数据类型用于服务接口描述。该文件将纳入核心类型相关的工作

18.4 全局初始化和关闭功能

该函数对于那些采用Adaptive技术的应用程序而言，在处理初始化相关的数据模型以及反初始化相关的数据模型时所涉及的AUTOSAR运行事件相关的线程模块具有重要的意义。

• ara::core::Initialize

• ara::core::Deinitialize

通过调用Initialize函数实现应用程序数据结构以及AUTOSAR Adaptive运行时线程的初始化，在此函数调用之前不允许与ADA进行交互。该函数的调用必须嵌入到main()函数内部，并且仅能在静态内存初始化完成的地方执行这些操作以确保系统的稳定性。为了满足个人功能集合规范的要求，在进行应用程序功能集成时需要附加必要的配置信息（例如日志记录所需的应用程序ID）或执行额外初始化步骤（例如启动相关服务模块）。所有后续操作必须在Initialize函数调用之后完成以保证系统的正确性。若在此阶段提前使用ADA API可能会引发不确定的行为，并且会被功能集合实现拒绝并返回相应错误提示信息。若未报告相关错误信息可能导致系统运行异常。

The Deinitialize method in ara::core will destroy all data structures and threads associated with the AUTOSAR Adaptive runtime. This method must be called within the main() function, specifically after static initialization has completed but before the destructors for static initialization have started. Using the API after Deinitialize has been executed but before the static initialization destructors have run will result in errors being detected and reported by the system. If no errors are defined, undefined behavior will occur when attempting to use the API after the static initialization destructors have executed.

19-03 Adaptive AUTOSAR 平台接口使用指南

1 本文的介绍

1.1 内容

尽管FC的SWS采用了ARA接口规范,然而,在某些情况下,则需要特定的指导文件来说明其使用方法.这些指导文件与该规范体系具有密切关联,其中一些则是较为间接的应用,并且在每一个SWS中都会包含相关信息.这使得读者难以准确把握其具体应用范围.从另一个角度来看待这个问题时,则关注于AA方对这一需求的要求.然而,从另一个角度出发考虑的话,则认为FC方的需求应当以需求规格说明书的形式加以描述.因此,在这种情况下将其纳入到一个SWS中并不十分合理.

在上述背景中, 这份文档的核心内容是应用程序遵循的指南。
并非所有FC都在这份文档中。
当一个FC据认为有效时, 它们将被添加

内容依据相关主题进行分类管理，并非全部统一编排为FC组合形式。通常情况下，默认会将各主题独立成章地进行编写。特别提示：这些内容均包含在单独编写的AUTOSAR AP文档中。在这种情况下，请参考相关的这份指南。

1.2 预读

这份文件是关于AP SWS的补充材料。此份文档中涉及AP SWS的相关话题应同步阅读。并建议首先阅读Explanations of Adaptive Platform Design, AUTOSAR_EXP_PlatformDesign.pdf. 该文件简要介绍了AP的整体架构.

1.3 和其他AUTOSAR规范的关系

参考内容和预读

2. 核心类型

2.1 错误处理

在任何软件开发过程中进行错误处理都是一个重要的议题。特别是在涉及信息安全的关键系统中这一问题更为突出这是因为系统的可靠性和稳定性直接取决于此类系统的正确运行。然而 现有的标准在开发安全关键系统时施加了许多限制条件 例如 在构建工具链方面这些规定要求极为严格 特别是对涉及C++异常的情况更是如此 因为现有的标准并不支持针对可证式体系结构（ASIL）的应用程序使用C++异常 这一做法由于缺乏相应的支持而显得不可行

Adaptive平台提出了一种创新性解决方案使得在遵循C++编程规范的情况下实现对异常处理的有效管理，并通过构建完善的C++数据体系框架框架实现对相关操作的支持功能

从程序编码者的视角出发来看，这些关键数据类型的实现涵盖了 ara::core::ErrorCode和ara::core::Result。

2.1.1 ErrorCode

ara::core::ErrorCode代表软件内部的一个特定错误状态。如同std::error_code一样使用，在许多方面都存在差异。

该段代码中包含一个枚举类型（类型为整型）以及一个错误域引用。该枚举类型用于标识特定类型的错误信息。而错误域引用则指明了该错误在应用中的具体情境或背景信息。此外，在可选组件中还包括一个由用户自定义的消息字符串以及一个由厂商提供的额外错误描述值。

2.1.2 Result

该类遵循C++建议 p0786中'ValueOrError'概念的实现。该类包含一个value或一个error对象。基于模板特性设计的该类允许其value和error参数可为任意数据类型。值得注意的是，默认情况下该类的错误类型定义为 ara::core::ErrorCode，并期望这一配置在整个Adaptive平台上得到一致应用。

由于ErrorType被定义为其默认值为ara::core::ErrorCode，并且在ara::core::Result的大多数声明中只需指定一个ValueType即可实现相关功能。例如，在Result这样的类型中包含了单个int变量或是一个错误码（errorCode）。

该接口采用ara::core::Result类型来返回可恢复错误函数的结果。该类型既可从对象中生成C++异常供处理,也可通过非异常处理的方式获取错误信息。

教你如何应对从ARA接口返回的Result对象，并教你如何在本系统的Adaptive应用中建立新的Result对象。

2.1.2.1 Result的创建

通过将嵌入值注入到Result中，并利用具有从ValueType进行隐式转换的构造函数进行操作。这种方式使得通过value定义Result变得异常直接

Result res1(42);

Result res2 = 42;

从声明返回Result的函数中返回一个value也是同样的直接。

Result myfunction()

{

return 42;

}

把error放进Result中需要调用显示构造函数，比如：

ErrorCode ec = MyEnum::some_error;

Result res2(ec);

另外，在静态成员函数中构造Result对象也是可能的。比如：

Result res1 = Result::FromValue(42);

Result res2 = Result::FromError(ec);

当Value Type或ErrorType复制操作成本高昂时，这些形式具有显著的价值。例如，在结果包中替换一个BigClass实例。这个BigClass包含两个构造参数："a1"和"a2"用于构建对象。具体来说：

return Result::FromValue(a1, a2);

对于ErrorType类而言，在处理其实例时也能够实现对ErrorCode类型的隐式构造功能。这种功能不仅允许在创建实例时指定自定义错误信息，并且还可以选择性地包括与数据值相关的支持功能。

return Result::FromError(

MyEnum::some_error, // ErrorCode enum value

"this operation did not work", // custom error message

0x12345678 // support data value

);

这种形式构建仅需执行一次构造函数。与普通的方式相比，在线构建至少需要进行两次操作：因为预先生成的数据对象必须被复制或移动至Result实例中。

2.1.2.2 提取value和error

当从Result中获取value和error时，在进行操作之前首先要确保这些值或错误真正可用。由于在多数情况下这种状态是未知的性质，则必须谨慎地处理这两种可能性。

在未启用异常工作的场景中，在Result对象中查找是否有value字段，并确定是否存在error字段。

Result some_function() { … }

Result res = some_function();

if (res.HasValue()) {

int theValue = res.Value();

} else {

ErrorCode const& ec = res.Error();

}

这段代码在没有异常的情况下也能正常运行，并且编译器对于异常操作没有任何支持

当处理异常工作流是，查询代码看起来更像普通的异常代码：

Result some_function() { … }

int theValue = some_function().ValueOrThrow();

经过some_function()返回的Result对象调用其ValueOrThrow()成员函数迅速转换为其ValueType（int）。当Result携带一个ErrorCode时,会立即触发与嵌入该ErrorCode对象相对应的一个异常类型。因此，在代码中适当的位置合理地加入try-catch块。

2.1.2.3 高级话题

获取内置于结果中的value或error实例的方法是 Result::Value 和 Result::Error 。然而，在使用这些方法时（即调用任何这些函数），必须确认结果对象是否确实包含了所需的信息。在上文中，请确保先执行 HasValue 、 Value 或 Error 方法的相关操作之前，请确保后续操作的结果将依赖于对该处操作的后续处理。

另一种替代嵌入value的更简便方式，在之前的段落中已经介绍过。通过使用Result::ValueOrThrow方法，则无需进行if判断逻辑。这一操作仅需一行代码即可完成（注意不涉及try-catch块）。

除了Result::ValueOr提取value之外，在找不到值时可采用默认值

int res = some_function().ValueOr(42);

Result :: ValueOr的一般化称为Result :: Resolve（该Callable），它不采用默认值作为参数，并且是一个Callable类型（该Callable可通过需求生成相应的默认值）：

int res = some_function().Resolve([](ErrorCode const& ec){ return 42; });

对于这种特殊的案例，在采用Result::Resolve而非Result::ValueOr时并无意义。然而，在常见默认值成本高昂的情况下，则可能经过深思熟虑。因此，在采用Result::Resolve时，默认值仅会在必要时生成。

另一种便捷的方式是Result::Bind方法,它能够实现将包含的内容转换为另一种形式,并且还可以转换为另一种数据类型.

Result res = some_function().bind(
[](int v) { return ++v; }
).bind(
[](int v) { return std::toString(v); }
).bind(
[](String const& s) {
return "''" + s + "''";
}
);

通过首次调用Result::Bind()从Result对象中获取value，并将其增加1后放入一个新的Result对象并返回。

第二次调用Result::Bind()从Result对象中提取出value，并将其转换为String类型，并返回一个新的Result对象。

最后一条指令用于将字符串值提取出来，并将其包裹起来后返回一个新的Result实例。

如果Result未包含value，则这些可调用项都不存在；Result对象将仅完成类型转换过程，并保留原有的errorCode值。

Callables传递到Result::Bind必须使用适当的类型作为参数，并且也可以直接返回一个ValueType（如同文所述），或者与前一个相同的ValueType、或者是新的、不同的ValueType），或是Result。

3 执行管理

3.1 执行状态

执行状态体现了任何进程的内在生命周期。每个进程必须向执行管理提交关于其执行状态变化的报告，并通过调用...接口完成此操作。

当进程启动时，在达到KRunning状态后（如[SWS_EM_01053]所示），执行管理视为进程已初始化完成。请注意ServiceDiscovery可能导致不确定延迟的影响，请在报告kRunning状态之后采取行动；这意味著进程中可能尚未完全初始化。

执行管理采用向进程发送 SIGTERM 信号作为启动终止进程的机制。当接收 SIGTERM 信号时，进程将通过将 kTerminating 状态报告给执行管理来确认其状态变化请求（参见 SWS_EM_01070）。

当一个进程是自终止时（见[SWS_EM_01071]），它会触发管理报告kTerminating状态以启动自终止。

系统报告kTerminating事件后会自动执行以下操作：首先将持久化数据完整保存至存储介质，并彻底释放系统内部占用的所有资源。随后系统将通过正常的退出流程表明已成功完成终止状态（通常带有指定的退出代码）。在执行层管理中无需主动获取或处理进程终止的通知。

3.2 确定性执行

执行管理负责确保严格控制所有多线程进程。由于这些措施的有效实施，在规定时间内处理给定输入数据将产生稳定且一致的输出。其中一项典型表现是行为具有可重现性。

在AUTOSAR Adaptive平台中规定，在高安全目标系统中的软件Lockstep框架下涉及这种确定性的用例需满足以下技术要求：即系统需实现冗余运行并复用经过验证的有效软件方案。详细信息可参见Specification of Execution Management, AUTOSAR_SWS_StateManagement.pdf中的"Deterministic Execution"部分。

能够精确无误地被执行的过程必须通过特定的方式进行设计，并实现其实施并纳入整体系统中。这些过程不应受到其他功能或计算的影响。同时应考虑一些无关紧要的小事件、竞争性情况以及偏差随机数等因素所引起的处理器负载。

可能导致不确定行为的原因可能多种多样。例如，在计算资源紧张或数据读取冲突的情况下，在不同处理器内核上运行多线程通常会导致这种情况发生。此外，在多线程环境中进行的数据操作顺序也会直接影响最终的结果。

完全确定的执行包括：

*时间得到了明确确定。
计算输出被限制在指定的时间范围内生成。
为了确保进程能够获得足够的资源支持，在描述资源需求时必须遵循标准规范。（见Specification of Execution Management, AUTOSAR_SWS_StateManagement.pdf，“Real-Time Resources”部分）

*数据达到了稳定状态。给定相同的输入和系统参数，在相同的时间段内进行多次运行时会得到一致的结果。这部分将介绍如何实现这一目标的具体方法

执行管理提供DeterministicClient库功能来支持确定执行。

• 利用等待点API（[SWS_EM_01301]）来管理流程内部周期WaitForNextActivation()的操作。
• 当API返回后，在其结果基础上立即进入循环处理逻辑，并再次调用该API以触发下一次激活。
• 该API返回的结果将直接影响进程的生命历程（例如：初始化、运行、终止），因此必须在每次调用前做好相应准备。（[SWS_EM_01302]、[SWS_EM_01303]及[SWS_EM_01304]）

该系统会阻塞固定性的 worker pool API RunWorkerPool() ，负责处理一批容器元素 SWS_EM_01306 ，这些容器元素由同一个 worker 执行处理，并行或按顺序进行。

该系列API GetActivationTime() ([SWS_EM_01310]) 和 GetNextActivationTime() ([SWS_EM_01311]) 详细描述了它们的功能与作用机制。这些功能与作用机制确保了系统对时间同步的需求。

• 该API通过函数GetRandom()生成([SWS_EM_01308])标识的随机数值。当从工作进程池调用时，在指定的容器元素上分配生成的随机数值有助于确保冗余计算的一致性。

为了确保明确行为, 确定性用户进程仅能采用由所有可用API构成的"确定性"子集, 并包含工作程序运行对象

进程必须避免通过普通POSIX进程中生成线程，并且不得调用任何其他POSIX APIs以规避潜在问题。

*进程仅限于可访问的所有ara::com机制中的'确定型子集'。随后将介绍此类API及相关的机制。

仅限于那些采用ara::exec接口的应用中包含DeterministicClient与ExecutionClient两个类。

• 用户进程不允许访问其他ARA接口。

如果采用工作程序池API RunWorkerPool()来管理容器元素的工作程序运行对象，则需遵循相应的实现规范以保证数据的一致性和确定性：

运行对象在运行时被禁止交换任何信息。例如，在这种情况下, 它无法访问其他实例中的可修改数据, 并且通过这种方式来防止出现竞争问题.

原理：运行对象既可在物理层实现并行执行也可按任意顺序进行调度。单个工作流程的执行时间不可预知。每个操作系统仅支持一个调度线程。当多个操作单元同时处理相同数据时可能出现不可预测的结果。

除了利用RunWorkerPool返回的通用连接外，在处理所有工作程序时均不涉及任何锁或同步机制（例如，在操作过程中不使用信号量或互斥量机制以及不涉及任何锁或阻塞机制）。

原理：通过锁定或阻止机制确保Process在运行时保持确定性。通过提供工作程序来提高运行时资源利用率。 若需同步操作，则必须从RunWorkerPool（）中获取所需资源。

工作程序池不适合同时处理多个不同类型的作业。在实际应用中采用多种不同功能的显式函数（指可执行的工作单元）可能会带来额外的复杂性和较低的时间效率。这也增加了资源分配和规划的难度，在黑盒集成环境中这是必不可少的。

工作程序池用户的实现例子。比如：工作程序运行对象的例子：

class MyWorker1

: public DeterministicClient::WorkerrunnableBase<myContainer::

value_type, MyWorker1>

{

public:

void worker_runnable(myContainer::value_type& container_element,

DeterministicClient::WorkerThread& t)

{

// Get a unique and deterministic pseudo-random number}

uint64_t random_number = t.GetRandom();

}

};

工作程序线程对象：

class DeterministicClient::WorkerThread

{

// returns a deterministic pseudo-random number}

// which is unique for each container element}

uint64_t GetRandom();

...

};

4 状态管理

4.1 AUTOSAR Adaptive（平台）应用程序的交互

4.1.1 基本的状态管理功能

状态管理通过ara::com支持一组名为"Trigger"和"Notifier"的字段配置。该系统本质上响应"Trigger"事件，并根据这些触发器自动完成相应的操作；当具备"Notifier"字段时，则会根据其内容进一步执行相应的功能。此外，该系统还能够与其他组件FC进行交互，并利用其提供的标准接口来实现功能。

使用这个机制还可以达到下面的效果：

• 可以要求将功能组设置为专用状态。

• （部分）可以请求取消/激活网络

• 可以请求机器关闭或重启。

• 其他Adaptive（平台）应用程序的行为可能会受到影响

• 可以执行项目特定的动作

其某些关键功能具有重要意义。因此集成者应妥善地通过IAM进行管理以防止意外更改状态管理内部的状态同时避免由此引发的影响

状态管理内部的状态依据其提供的Notifier字段向系统发出通知。它们是否可读或可访问并不关键, 并且当状态管理的状态发生变化时, 每个Adaptive平台的应用程序均可注册相应的事件以接收到相关通知。

由此可见，在状态管理的状态发生变化的时候，在每一个Adaptive（平台）应用中都可能执行相应的操作。

4.1.2 高级状态管理功能

AUTOSAR Adaptive中的一些用例需要应在相应的状态管理机制中支持同步操作。。例如，在一个典型的低功耗模式下：只有当所有参与该低功耗模式场景的所有Adaptive（平台）应用程序都最终准备好并能够进行低功耗操作时，则应确保状态机能够最终切换至低功耗状态（例如，在持续存在其相关信息的情况下）。

为此，在采用Adaptive（平台）架构时，所有实现同步工作模式的应用程序必须能够通过ara::com接口提供必要的配置参数。这些配置参数可以通过FindService服务获取，并且状态管理器能够在注册后自动关注这些变化。当Adaptive（平台）应用程序执行相关操作时，状态管理器将根据实时数据更新并发送相应的通知信息。

Adaptive（平台）应用程序必须完成的三件事，才能支持同步方案：

基于Adaptive平台的应用程序应配置对应的状态管理器以响应相关事件（当达到相应的状态管理条件时提供反馈或提示）。

• Adaptive（平台）应用程序应为最终状态做任何准备工作

• Adaptive（平台）应用程序应将先前操作的结果写入其提供的字段

为使状态管理识别一个Adaptive平台应用希望加入同步场景而努力,Adaptive平台应用必须尽最大努力提供其服务以满足必要性;当决定退出时它必须停止提供服务（例如通过完成某个操作）

Adaptive（平台）应用程序的接口应遵循状态管理系统中的“TriggerOut”接口的标准模式。

19-03 Adaptive AUTOSAR 通信管理需求规范(2)-面向服务通信

4.2.2 面向服务通信

4.2.2.1 应用程序之间的通信

[RS_CM_00200]通信管理应将全合格的服务ID转换成通信协议特定的服务ID

【类型：草稿

该系统应采取措施将所有经过验证的有效服务标识符重新编码为与特定通信协议相匹配的有效标识符。开发人员在应用程序代码中误用了经过全面验证的有效服务标识符，在这种情况下必须为其创建新的标识符以支持跨供应商的合作机制。该类标识符可以在网络消息中使用；然而，在某些情况下当现有通信协议标识符空间并未预先设计用于接收经过全面验证的有效标识符时就需要特别注意以避免可能出现的问题

原理：应用程序的二进制文件应不知道通信协议特定的服务ID。

依赖：–

用例：多个汽车生产线上共用一个平台系统。然而，在这种情况下（针对两个汽车生产线），Service ID在平台上并不一致。在通信绑定过程中，则全部采用经过严格筛选的服务ID。其中负责通信管理的部分则会将这些经过筛选后的ID转化为专门的SOME/IP服务标识符。

支持材料：见Adaptive平台场景。】

[RS_CM_00204]通信管理系统应负责将协议独立化的服务化通信映射到已配置的协议绑定，并相应地执行该绑定

【类型：草稿

描述：通信管理负责将独立实现面向服务制式的通信映射到现有配置下的协议绑定，并负责执行相应的协议。应用代码块与现有配置无关地使用面向服务制式的通信。通信管理的主要职责在于确保特定协议得以实现。

原理：应用程序的二进制文件应不知道通信协议特定的服务ID。

依赖：–

案例说明：若干个汽车生产线共享同一个应用程序，但位于不同汽车生产线上的通信协议各不相同。例如，在一个案例中采用SOME/IP，在另一个案例中采用本地IPC。

支持材料：–】

[RS_CM_00315] 通信管理应支持协议绑定的变化而不必导致Adaptive应用程序进行再编译。

【类型：草稿

由于特定网络协议绑定的选择由集成商驱动的部署决策所决定，在不涉及重新编译的情况下即可实现对特定网络协议绑定的选择及其相关属性和参数的所有修改。对于所涉及的所有Adaptive应用程序的要求变更应当局限于这些应用本身的静态或动态重链接操作。

原理：应用程序的二进制文件不具备明确配置协议的具体绑定；必须在应用程序二进制文件部署期间进行可配置或可更改设置。

依赖：–

用例：程序的二进制文件可在多种部署环境中运行。例如，在某个环境中可绑定SOME/IP协议，在另一个环境中则采用本地IPC协议。

支持材料：见Adaptive平台场景。】

[RS_CM_00205]通信管理应实现SOME/IP服务发现协议，SOME/IP协议和E2E监控（E2E协议）。

【类型：草稿

通信管理应当支持某种基于SOME/IP的服务发现机制，并且同时支持基于该机制的端到端监控（E2E）方案。在AUTOSAR相关的标准规范中对基于SOME/IP的服务发现机制及其相关功能进行了详细规定，在AUTOSAR标准规范中对基于该机制的具体实现进行了明确的规定，并对基于该机制的端到端监控（E2E）方案也做出了相应的规定。此外，在设计过程中要求所采用的SOME/IP 协议与 E2E 协议作为独立的功能模块，并且两者之间不存在依赖关系

原理：Classic 和 Adaptive AUTOSAR 都支持SOME/IP协议和E2E协议。

依赖：–

案例：雷达、摄像头及SensorFusion系统采用SOME/IP协议基于以太网实现通信；而与之相对应的安全应用则采用非安全相关的总线（如以太网、CAN）进行数据传输。

支持材料：–】

[RS_CM_00222]通信管理应将其符合标准的服务编号、实例、事件编号或操作方法编号转换为端到端数据标识符。

【类型：草稿

通信管理部门应负责将符合要求的服务ID及其相关实例、事件数据编码信息或者服务方法编码信息统一编码为统一通信端到端的数据标识符。

原理：E2E监管独立于总线，并根据数据ID进行操作。

依赖：–

用例：E2E监管用于通信保护和文件系统保护。

支持材料：请参阅基础中的PRS E2E监管】

4.2.2.2 服务发现

[RS_CM_00101]通信管理应提供提供服务的接口

【类型：草稿

描述：应用程序开发人员应能够为其他应用程序提供其应用所提供的服务，并非为了便于识别而采用完全合格的服务ID来提供这些服务。

原理：为实现通信目的而必须具备某种机制以利用其服务功能向其他应用程序提供相应的服务。

依赖：–

用例：应用程序“ A”为其他应用程序提供挂钟服务。

支持材料：–】

[RS_CM_00102]通信管理应提供发现服务的接口。

【类型：草稿

应用开发者可在运行时识别其他app提供的所有服务实例

原理：旨在通过分析服务类型和具体实例来识别提供的服务，并认为这种机制具有必要的性。

依赖：–

用例：应用程序A发起查询以访问其他应用提供的时钟功能模块。通信管理系统识别出所有可选的服务实例，并将它们传递给应用进行进一步操作以完成任务分配。

支持材料：–】

[RS_CM_00103]通信管理应当创建一种机制供某个服务实例注册并接收其定义的特定事件类型

【类型：草稿

应用程序开发人员会被允许在一个选定的服务实例中注册或关注其发生的一个特定的事件。

原理：找到服务类型的实例后，应该可以订阅特定实例的某些事件。

依赖：–

用例：应用程序“ A”订阅了控制点火锁的应用程序的开机事件。

支持材料：–】

[RS_CM_00104]通信管理应提供一个接口，以停止对服务实例事件的订阅

【类型：草稿

开发人员应具备暂停应用程序对服务实例中的事件进行注册的能力

原理：在订阅了特定服务实例的事件之后，以后应该可以停止订阅。

依赖：–

用例：应用程序“ A”停止订阅开机事件，并且不再接收此类事件。

支持材料：–】

[RS_CM_00106]通信管理应提供一种手段来监视事件的订阅状态

【类型：草稿

应用程序开发人员具备查询应用程序对服务实例事件预设状态的能力，并且他们也可以通过相关服务实例事件预设状态的变化而收到相应的通知

原理：应当可以监视/查询预订的实际状态。

依赖：–

用例：应用程序希望跟踪开机事件的订阅状态，并在发生更改时得到通知。

支持材料：–】

[RS_CM_00107]当服务被重新启动时,通信管理应实现一种自动更新代理实例的功能.

【类型：草稿

通信管理应自行负责更新服务的代理实例，并非由客户端进行操作；然而客户端无需进行再创建或重新初始化其代理实例即可正常运行。同样的机制也适用于其他相关组件的操作中

原理：该方法能够独立地在服务器实例未重新启动且不涉及代理实例句柄更改的情况下继续使用代理实例

依赖：–

用例：客户端应用数据的持久化存储，在避免服务器端重复监控订阅状态的同时，在无需在服务器端重新启动以维持订阅的情况下完成。

支持材料：–】

[RS_CM_00105]通信管理应提供停止提供服务的接口

【类型：草稿

描述：应用程序开发人员应能够停止该应用程序之前开始提供的服务。

原理：提供服务后，以后应可以停止提供服务。

依赖：–

用例：应用程序“ A”停止提供挂钟服务。

支持材料：–】

19-03 自适应AUTOSAR自适应通信管理系统第二版 - 以服务为中心 - 简书