01 AUTOSAR 平台逻辑体系结构

图示逻辑体系结构描述了平台是如何组成的，有哪些模块，模块之间的接口是如何工作的。

经典平台具有分层的软件体系结构。定义明确的抽象层，每个抽象层都有精确定义的角色和接口。

对于应用程序，我们需要考虑使用的软件组件，希望它们是可重用的，因此应该尽可能小，依赖性尽可能少。组件被静态地分配给ECU，并且通过静态连接发送/接收的信号进行通信。

•AUTOSAR实现了软件和硬件的分离，使得软件可以在不同的硬件平台上运行。

•AUTOSAR采用了一种统一的XML文件格式，用于描述软件架构和配置信息。

•AUTOSAR具有很高的灵活性，可以根据不同的需求进行定制和扩展。

•AUTOSAR支持运行时软件更新，可以适应不同的应用场景。

•AUTOSAR提高了软件集成的效率和扩展性，使得软件可以更容易地进行重用和迁移。

•AUTOSAR为上层开发者提供了标准化的接口和协议，使得开发者可以专注于应用功能的开发。

在软件开发过程阶段，CP与AP都主要都包括以下三个阶段：

1.设计阶段：设计ARXML

2.代码生成：基于ARXML生成代码

3.集成：集成Application，编译调试等

02 AUTOSAR AP平台逻辑体系结构

AP AUTOSAR的核心是自适应应用程序（Adaptive Application），它是一种可以根据运行时环境动态调整的软件组件。那么，AP AUTOSAR是如何定义和管理自适应应用程序的呢？下面将为你介绍AP AUTOSAR的逻辑视图和功能集群，详解自适应应用程序的运行环境。

AP AUTOSAR的逻辑视图是一种抽象的软件架构，它描述了自适应应用程序的功能需求，接口，依赖关系和配置。逻辑视图由多个功能集群（Feature Cluster）组成，每个功能集群包含一组相关的功能需求和接口。功能集群可以进一步划分为多个功能组（Feature Group），每个功能组包含一组具体的功能需求和接口。功能需求和接口可以使用ARXML文件进行描述和生成。

AP AUTOSAR的功能集群是一种逻辑上的分组，它不代表实际的软件组件或部署单元。在实际的软件开发过程中，功能集群需要被映射到具体的软件组件或部署单元上，这就涉及到AP AUTOSAR的另一个视图：实现视图（Implementation View）。实现视图描述了自适应应用程序的软件结构，包括软件组件，部署单元，运行时对象等。实现视图和逻辑视图之间的映射关系可以使用ARXML文件进行描述和生成。

AP AUTOSAR的运行环境是一种软件平台，它提供了自适应应用程序所需的基础服务，如通信，配置，诊断，安全等。运行环境由多个服务层（Service Layer）组成，每个服务层提供了一类特定的服务。服务层之间通过面向服务架构（Service Oriented Architecture, SOA）进行交互，即通过发布-订阅模式（Publish-Subscribe Pattern）进行异步消息传递。运行环境可以在不同的硬件平台和操作系统上运行，通过硬件BSP进行适配。

自适应平台采用模块化软件体系结构。它比经典分层软件架构更模块化，反映了平台的动态特性。这种动态性也是平台的核心需求；

AP遵循面向服务的架构，SOA设计理念，充分利用各种开源软件成熟技术，重用软件市场成熟组件，缩短开发周期。在ECU的生命周期内有独立更新应用程序的能力。

03 Adaptive Platform Architecture

AP AUTOSAR的逻辑视图体现了其相应的体系结构，如下图所示：

从图中可以看出，AP AUTOSAR主要由以下几个部分组成：

lAA（Adaptive Application）自适应应用程序运行在AUTOSAR Runtime for Adaptive Applications (ARA)之上，用于实现碰撞预警、车道保持、自动驾驶等复杂的汽车功能。AA可以使用C++语言编写，也可以使用模型驱动开发（Simulink）工具生成。

lARA（AUTOSAR Runtime for Adaptive applications）自适应应用程序的运行平台：提供了AA所需的运行时环境，包括内存管理、进程管理、文件安全读写、日志记录等。ARA由功能集群（Functional Clusters，FCs）提供的应用程序接口组成，这些群集属于Adaptive Foundation或Adaptive Services。Adaptive Foundation提供了AP的基本功能，而Adaptive Services提供了AP的平台标准服务。

lAdaptive Foundation：提供了AP AUTOSAR的基础功能，如服务发现、事件发布订阅、请求回复、持久化数据管理等。这些服务主要是为了实现AA之间以及AA与外部系统之间的面向服务的通信（Service-Oriented Communication，SOC），基于以太网和SOME/IP协议。此外，还包括操作系统接口、执行管理、平台健康管理（看门狗）、网络管理、诊断通信、时间同步等。这些功能主要是为了支持ARA和AA的运行。

lAdaptive Services：提供了AP AUTOSAR的标准服务，状态管理（特定于项目实现），网络管理，更新配置管理（UCM）即我们比较熟悉的运行时软件更新（OTA）。

Adaptive AUTOSAR构建在POSIX操作系统之上，ARA可以提供多种功能供应用程序调用来实现软硬件解耦、为上层应用提供服务。

04 Adaptive AUTOSAR 术语——Machine

Adaptive AUTOSAR是一种基于服务的软件平台，它支持高性能、灵活和可更新的汽车应用程序。

Adaptive AUTOSAR的逻辑体系结构是基于Machine的概念构建的，Machine是指运行环境所需的物理资源，如处理器、内存、网络等。

一个Machine可以包含一个或多个ECU，但只能运行一个AUTOSAR Adaptive Instance（AUTOSAR平台的实例即AP实例）。每个AP实例都有自己的功能集群，可以实现不同的服务和应用。

在Adaptive AUTOSAR中，Adaptive Application是用C++编写的，它们在Machine上以进程的形式运行。进程之间通过服务进行通信和协作。

Machine可以是高性能计算机（HPC），它们提供了数据密集型应用所需的计算能力。HPC可以包含多个核心，Adaptive Application可以通过进程到Machine的映射分配到不同的核心上。

一个重要的概念是，AUTOSAR的作用域是Machine，也就是运行环境所依赖的物理资源。每个Machine都有自己独立的功能集群和服务，它们可以实现不同的汽车应用程序。AUTOSAR也允许在同一个Machine上运行一些非AUTOSAR的进程，但是这些进程不受AUTOSAR平台实例的管理和约束。

adaptive autosar machine的启动过程包括哪几个步骤？

•机器启动，操作系统最先初始化，然后执行管理（EM）作为操作系统的初始进程之一启动。

•EM负责启动其他功能簇（FC）和平台应用。

•平台基础（Foundation）启动后，EM继续启动adaptive应用（AA）。

•EM根据machine manifest和execution manifest决定启动顺序。

•如果AP从可信锚点（trust anchor）启动，并且在启动过程中维护信任链（chain of trust），则EM可以支持认证启动（authenticated startup）。认证启动启动过程中，EM验证应用的真实性和完整性，如检测出异常，则阻止应用运行。

Adaptive application（AA）：承载Service的应用实体

Executable：App的运行时实体，一个可执行程序可以包含多个服务实例

Process ：OS运行调度的实体

Machine：运行环境的物理资源

AUTOSAR使用ARXML格式文件进行建模 ：

• 通过正式定义的接口来使用服务

• 实现服务有三种方式Event Method Field

• 定义服务传输的数据类型

• App之间的通信端口，需要在component 元素中定义provide/require Port

adaptive autosar machine的启动过程涉及到以下几个概念：

清单是一种用来描述AP AUTOSAR软件系统的文件，它可以告诉我们怎么安装和运行软件。清单文件的格式是XML，它们可以通过ARXML工具进行生成和处理。

清单有三种不同的类型，分别是：

Execution Manifest

Execution Manifest在设计期间创建，提供应用部署所需的信息，定义每个可执行文件实例化几个进程（几次），每个进程的的启动参数、环境变量、UID/GID、资源组、调度策略、何时启动、停止等都可以独立配置。

在RTA-VRTE中配置Execution Manifest

添加一个AA进程我们需要做几方面的配置：

1.配置AA进程相关的FunctionGroup state

2.选择AA将要部署在哪个Machine上

3.AA进程的启动参数和环境变量（依赖的库和配置文件等信息）

4.AA进程的Log模块配置

5.AA是否向EM汇报执行状态

6.设置AA所属于的Resource Group,来控制AA所在的功能组所占用的内存和cpu使用率。

7.选择AA进程中的线程的调度算法（FIFO、RR、other）

Machine Manifest

Machine Manifest实际运行在特定硬件（机器）上的adaptive平台实例的配置，它包含了 machine属性，特性（资源，功能安全，信息安全等），例如machine state、function group state、resource group、访问权限组、SOME/IP配置、内存分区、硬件资源，如处理器和核心等等。

每个machine都配置有关function groups、software clusters和process到machine的映射等相关信息。

在RTA-VRTE中配置Machine Manifest

在ARXML文件中，我们可以配置Machine的以下属性和特征：

状态：Machine的运行状态，如启动、停止、重启等。

进程：Machine的执行单元，如应用逻辑、中断、函数等。

网络：Machine的通信方式，如Ethernet等。

服务：Machine的提供或请求的功能，如诊断、校准、更新等。

每个Machine都有自己独立的功能集群和服务，它们可以实现不同的汽车应用程序。每个Machine需要与一个Machine Design相关联，Machine Design是用来定义不同Machine之间如何协作和交互的。

下表展示了Machine和Machine Design的关系：

每个Machine都需要至少一个IP配置，因为在网络中，每个Machine都是一个独立的end point。IP配置包括IP地址、子网掩码、网关等信息，用于标识和定位Machine。没有IP配置，Machine就无法与其他Machine或设备进行通信。

软件集群（software cluster）一种原子的、可更新的、可扩展的软件单元，由一个或多个进程组成，实现了一组特定的功能或应用程序。软件集群的作用是将应用程序和服务按照功能或特性进行分组和管理，提高了开发和部署的灵活性和效率。

软件集群通常需要配置以下几项内容：

功能组（Function group）：用来说明软件集群包含了什么样的功能，比如导航、泊车、通讯等。

进程：用来执行具体的软件代码，比如导航进程、泊车进程、通讯进程等。一个软件集群可以包含多个进程，但是它们要有相同的功能组。

设计（software cluster design）：用来描述软件集群的结构和属性，比如名称、版本、大小、依赖关系等。

software cluster design需要和MachineDesign相关联

software cluster需要和software cluster design相关联

Function Group State：功能组状态，是指一个功能集群（Function Group）的整体状态，它反映了该功能集群内部所有进程或自适应应用程序的执行状态的综合情况。功能组状态由状态管理（State Management）模块控制和监视。

在ARXML文件中，我们可以配置执行管理的以下功能：

·控制进程（Process）的启动和停止，根据功能组（Function Group）的状态（Function Group State）。

·定义功能组，需要创建一个新的模式声明组（Mode Declaration Group），并将它和功能组集（Function Group Set）关联。功能组集和软件集群（Software Cluster）关联。

·在MachineFG中添加Machine的四种状态：Off、Startup、Restart、shutdown，并将MachineFG设置初始状态为OFF。

下表展示了功能组和状态的关系：

MachineFG Function Group Transitions

功能组是一种逻辑分组，用于将具有相同或相似功能的进程聚合在一起。功能组可以有多个状态，表示该功能组所包含的进程的运行情况。执行管理根据功能组的状态，决定是否启动或停止该功能组所包含的进程。这样可以提高执行效率，节省资源，实现动态调度。

Service Instance Manifest

Service Instance Manifest 主要包含面向服务通信的配置信息 ，描述针对特定的传输协议（如SOME/IP），进行面向服务通信的配置和可执行代码绑定（服务实例到机器的映射、服务实例到应用端点的映射），还包含基于服务的通信相关信息，如应用层及相应的传输层、网络层通信参数信息。

在RTA-VRTE中配置Service Instance Manifest

Processed Manifest

Execution Manifest和Machine Manifest可以从原始的标准化ARXML转换为特定于平台的格式（称为Processed Manifest处理清单），在机器启动时可以有效地读取。

格式转换可以在集成时在板外或部署时进行，也可以在安装时在机器上（通过更新和配置管理）进行。

借着状态转换图来介绍一下AP AUTOSAR中用来描述Machine和功能集群的状态和行为的process state, Execution state, Function Group State, Machine State概念。

它们的含义如下：

•process state：进程状态，是指一个功能集群（Function Group）内部的一个进程（Process）或者一个AA的生命周期状态。进程状态有四种可能的值：未创建（NotCreated）、创建中（Creating）、已创建（Created）和销毁中（Destroying）。进程状态由进程管理（Process Management）模块控制和监视。

•Execution state：执行状态，是指一个功能集群（Function Group）内部的一个进程（Process）或者一个AA的运行状态。执行状态有四种可能的值：未启动（NotStarted）、启动中（Starting）、运行中（Running）和停止中（Stopping）。执行状态由执行管理（Execution Management）模块控制和监视。

•Function Group State：功能组状态，是指一个功能集群（Function Group）的整体状态，它反映了该功能集群内部所有进程或自适应应用程序的执行状态的综合情况。功能组状态有五种可能的值：未启动（NotStarted）、启动中（Starting）、运行中（Running）、停止中（Stopping）和已停止（Stopped）。功能组状态由状态管理（State Management）模块控制和监视。

•Machine State：机器状态，是指一个Machine的整体状态，它反映了该Machine上所有功能集群的功能组状态的综合情况。机器状态有几种可能的值：未启动（Off）、启动（Startup）、关机（Shutdown）和重启（Restart）。机器状态通常会引用功能组状态。

源：Requirements of State Management (autosar.org)

状态金字塔

05 Adaptive AUTOSAR 平台架构

在AP架构下，同一台机器上的自适应应用程序都实现为一个独立的进程，都有自己的逻辑内存和命名空间相互隔离，以确保相互不受干扰。这是由操作系统的MMU内存管理单元提供的。这也是AP模块化的由来。

单个AA可能包含一个或多个进程，可以部署到单个AP实例上，也可以分布在多个AP实例上。从模块来看，每个进程都是由操作系统从可执行文件中实例化的，一个可执行文件可实例化多次。这些进程都是运行在操作系统之上的，进程是动态运行的，何时调用、进程生存周期、资源占用及进程结束等，都是系统动态管理，好比你手机上的App何时打开、运行后其会调用的资源及何时关闭都是动态进行的。

AP平台需要提供相关模块的SDK和守护进程等。应用程序可以调用SDK提供的API来调用模块的功能，比如应用程序之间的通信，我们可以调用COM模块提供的API，可以进行片内或片间通信。

这跟CP架构有着显著的区别，在CP架构下，所有应用都是静态配置的，即应用的进程在OS中被写死，软件功能在编译阶段就确定了，其调用的周期也是确定，因此基于CP架构的软件一旦有小的应用变更就得重新配置和编译。

应用程序的加载/启动是通过使用EM的功能进行管理的，并且需要在系统集成或运行时进行适当的配置才能启动应用程序，软件功能在运行时才可以确定。从EM的角度来看，所有功能集群都是应用程序。

Adaptive autosar是一种用于高性能计算ECU的软件平台，它支持自适应应用程序的开发和运行¹。它由两部分组成：基础（Foundation）和服务（Service）。基础包括了操作系统接口、执行管理、网络管理、识别访问管理、加密、更新和配置管理等功能。服务包括了通信管理、RESTful、时间同步、诊断、状态管理、持久性、平台健康管理、日志和跟踪等功能。

Adaptive autosar各模块的功能如下：

执行管理 execution management (EM)

功能描述：EM负责系统执行管理的所有方面，包括平台初始化和应用的启动和关闭。EM和OS一起工作执行应用运行时间的调度。

AP AUTOSAR执行管理模块可以实现以下功能：

1.启动和关闭Machine，配置和加载应用程序，处理启动和关闭过程中的错误和异常。

2.控制应用程序的执行状态，设置应用程序的调度参数，监控应用程序的状态、资源、性能，处理应用程序之间的同步和通信。

3.管理功能组的状态，实现功能组之间的协调和一致性，根据不同的场景和需求，动态地切换功能组的状态。

4.处理平台和应用程序中发生的错误和异常，根据不同的错误类型和严重程度，采取相应的恢复措施。

状态管理（State Management）

State Management Function Group State change request flow

功能描述：

SM模块（State Management）是一种实现状态管理和事件处理功能的软件组件。SM模块负责所有和AP平台运行状态相关的方面。

主要功能：

▸处理输入的事件，如诊断请求、唤醒事件、错误恢复等，并根据事件类型和优先级来设置内部状态。

▸ 将自适应应用程序进程分配到功能组状态(inc. the Machine State)

▸ 根据状态更改启动/停止应用程序

▸ AUTOSAR触发器接口——用于提示状态更改

▸ AUTOSAR ara::exec::StateClient API

▸ 与ara::diag, ara::exec, ara::nm & ara::ucm模块的交互

执行管理与SM的交互

核心类型：Core TYPES

功能描述：

定义了多个FCs的公共类接口和公共功能。包括接口定义中经常使用的常见复杂数据类型。

主要功能：

•由于AP平台它具有功能安全的属性，通常而言我们是不可以使用C++的异常机制的（由于ASIL认证的c++编译器缺乏异常支撑），因此AP平台它引入了ara::core::ErrorCode错误码以及ara::core::Result的概念。允许进程在不抛出异常的情况下进行错误处理。

•AP还定义了一些了增强的数据类型，这些数据类型统一封装在了ARA：：core的命名空间。包括AP自己的内存分配相关的数据类型如：Vector、Map和String，以及Manifest中一些constructs用到的类型如StringView，Span，Optional和Variant。

•全局初始化函数，ara::core::Initialize和ara::core:: Deinitialize,此调用必须在main()内部进行。

操作系统接口OSI

功能描述：

AUTOSAR Adaptive platform(AP)运行在高性能处理器上，直接基于通用的操作系统。

操作系统接口的要求如下：

1.OS提供符合PSE51标准的POSIX兼容的API接口。

2.OS支持周期性时间触发的执行功能，进程中的算法可以是时间触发的。

3.OS需要提供允许应用程序的时间触发执行的机制。触发因素需要至少但不限于包含外部计时器。

4.OSI支持C++11，AP进程是用C++编写的，接口应该符合c++11

5.OS支持把EM拉起作为第一个执行进程。

6.OS支持为进程或进程组配置内存和CPU资源预算。

7.OS提供进程绑定到CPU Core的机制。

8.OS支持软件实体对系统对象访问的权限管理机制，应用进程只能通过授权的系统调用来

9.OS提供多进程，以便支持应用程序隔离。

通信管理（Communication Management）

功能描述：

通信管理模块是一个用于实现服务导向通信的模块，它支持多种通信协议，如SOME/IP, DDS, IPC等。

主要功能：

1.将协议无关的服务导向通信映射到配置的协议绑定，并执行相应的协议。应用程序代码使用服务导向通信的API，而不需要关心底层的协议细节。

2.支持服务发现、服务注册、服务请求、服务响应等功能，实现不同的通信模式和质量，如点对点、发布订阅、可靠、实时等。

3.支持事件、方法和字段三种类型的服务，实现不同的数据交换和远程调用功能。事件用于发布和订阅数据，方法用于请求和响应数据，字段用于获取和设置数据。

4.支持端到端通信保护，使用E2E机制对通信数据进行校验和保护，防止数据被篡改或丢失。

5.支持网络管理，使用NM机制对网络状态进行监控和控制，实现网络节点的加入和退出，以及网络唤醒和休眠等功能。

6.支持安全通信，使用加密、签名、认证等技术保证通信的机密性、完整性和可信性。

诊断管理（Diagnostics）

功能描述：

诊断管理模块（DM）是一种实现基于ISO 14229-1（UDS）和ISO 13400-2（DoIP）的ISO 14229-5（UDSonIP）的诊断服务的软件组件。DM代表Foundation层上AP平台的功能集群，支持多个诊断客户端和多个软件集群。

每个SWCL是一个单独的软件更新包， SWCL都可以创建自己的诊断服务器实例，每个诊断服务器都有自己的诊断地址和服务，可以独立地进行诊断操作 。每个诊断服务器都需要一个数据库和一个文本文件（ru:candela文件）来配置其功能 。

主要功能：

1.诊断通信：实现诊断服务器的功能，支持一些标准的UDS服务，如例行控制、数据标识符、故障码读取和清除等。DM模块还可以将诊断请求调度到相应的自适应应用程序，以便执行特定的诊断操作。

2.事件存储：负责故障诊断代码（DTC）的管理，包括DTC的存储、更新、删除、启用和禁用等。DM模块还可以管理DTC相关的快照记录和扩展数据记录，以及提供内部转换的通知。

3.传输层：支持DoIP作为传输协议，实现车辆发现和诊断通信。DoIP是一种基于IP网络的车辆诊断协议，可以与诊断基础设施（如诊断客户端、生产/车间测试仪）进行车外通信。

网络管理（Network Management）

Architecture overview with example applications

功能描述：NM是一种网络管理机制，用于控制和协调负责协调内部协调状态机中基础网络（部分网络，VLAN或物理通道）的正常运行和总线睡眠模式之间的转换。它的目的是在满足ECU节点正常通信需求的情况下，又能节省汽车蓄电池电量。

Overview Of Network Management

主要功能：

1.网络请求和释放：NM模块为状态管理提供了一个服务接口，用于请求和释放网络以及查询其实际状态。NM模块协调不同实例（网络句柄）的请求，并通过网络提供汇总的计算机请求。

2.网络状态监测：NM模块通过周期性的NM消息来监测网络状态，包括唤醒、准备睡眠、睡眠等。NM消息的接收指示发送节点要保持NM群集处于唤醒状态。如果任何节点准备好进入睡眠模式，它将停止发送NM消息，但是只要接收到来自其他节点的NM消息，它将推迟过渡到睡眠模式。最后，如果由于不再接收NM消息而经过了专用计时器，则每个节点都将执行到睡眠模式的转换。

3.部分网络管理：如果使用了部分网络功能，则NM消息可以包含部分网络（PN）请求，从而使ECU可以忽略不请求与ECU相关的任何PN的NM消息。尽管在其他部分网络中仍在进行通讯，但这可以关闭ECU（或其部分）。

身份识别访问管理（Identify Access Management）

Access Matrix (图片来自AUTOSAR官网)

功能描述：

身份识别访问管理块（IAM）是一种实现基于策略的访问控制功能的软件组件。IAM模块为应用程序提供权限隔离以及受攻击时权限越级的保护功能，同时，IAM模块还能方便集成人员在部署时就能验证应用对于资源的访问权限。

主要功能：

1.访问控制决策：IAM模块通过Policy Decision Point（PDP）基于访问控制策略来决定应用是否被允许执行请求动作。访问控制策略是一些约束条件，描述了访问特定资源或服务需要哪些Capability。Capability是应用身份信息的一个属性，在定义Application Manifest时，开发者为每个应用分配对应的Capability。

2.访问控制执行：IAM模块通过Policy Enforcement Point（PEP）在应用提出请求时中断控制流，向PDP请求访问控制决策并根据决策返回的布尔值进行对应操作。PEP可以实现对Service、Foundation FC以及相关模型资源的访问控制。

3.应用身份识别：IAM模块通过Execution Management（EM）模块获取应用身份信息，以便进行访问控制决策和执行。EM模块会根据模型信息，去创建Adaptive应用的运行实例，所以EM也需要去负责追踪运行进程的属性，也即正在运行的应用的PID、UID、Key或UUID。

加密（Cryptography）

High level architecture of Cryptography

功能描述：

加密模块（Crypto）是一种实现通用加密操作和安全密钥管理的软件组件。Crypto模块支持在运行时动态生成密钥和加密作业，以及对数据流进行操作。为了减少存储需求，可以将密钥内部存储在加密后端中，也可以外部存储并按需导入。Crypto模块旨在支持将对安全敏感的操作和决策封装在单独的组件中，例如硬件安全模块（HSM）。

主要功能：

1.加密操作：Crypto模块提供了一系列标准化的加密算法和模式，用于对数据进行加密、解密、签名、验证等操作。Crypto模块支持对称加密（例如AES、DES、3DES等）、非对称加密（例如RSA、ECC等）、哈希函数（例如SHA-1、SHA-2、SHA-3等）、消息认证码（例如HMAC、CMAC等）和数字签名（例如ECDSA、RSA-PSS等）。

2.密钥管理：Crypto模块提供了一系列标准化的接口和服务，用于管理密钥的生成、存储、导入、导出、更新、删除等操作。Crypto模块支持本地密钥生成和基于现有供应密钥的端到端保护的密钥引入。Crypto模块还支持对密钥进行访问控制和使用限制，以提高密钥的安全性。

3.证书管理：Crypto模块提供了一系列标准化的接口和服务，用于管理证书的生成、存储、导入、导出、验证等操作。Crypto模块支持X.509证书格式，以及基于PKCS#7或PKCS#10的证书请求和响应。

日志和跟踪（Log & Trace）

功能描述：

一种实现日志记录和追踪功能的软件组件。Log模块可以在开发期间以及生产中和生产后使用日志记录和追踪功能，以便对自适应平台的运行状态进行监测和分析。

主要功能：

▸ 本地日志 (输出到控制台或文件)日志记录,Log模块提供了一系列标准化的方法，用于向不同的日志接收器发送日志信息，例如通信总线、系统上的文件和串行控制台等。Log模块支持多种日志级别，例如错误、警告、信息、调试等，以及多种日志格式。Log模块还可以自动在日志信息中添加时间戳和其他元数据，以便进行排序和过滤。

▸ 远程日志记录（使用DLT协议）,Log模块提供了一种基于DLT协议的追踪功能，用于对自适应平台的运行时行为进行分析和优化。DLT协议是一种标准化的交付和表示格式，可以将日志信息打包为标准化的帧，并添加一些额外的信息，例如ECU ID、软件集群ID等。Log模块可以将LT帧发送到追踪工具或其他设备，以便进行可视化和分析。

更新配置管理UCM

UCM Logical Architecture

功能描述：

为了支持Adaptive Platform上软件的更改，更新和配置管理器（UCM）提供了处理软件更新请求的Adaptive Platform服务。

主要功能：

UCM可以接收来自后端服务器或诊断测试仪的软件更新请求，负责在自适应平台上安装、更新、删除和保留软件记录。

UCM可以处理不同格式和类型的软件包，包括完整包、增量包、后端包、车辆包等，根据软件包清单中的元数据和依赖关系，执行相应的操作。

UCM可以与UCM主服务器协作，以在车辆内部分发和协调多个UCM客户端的软件包，实现软件的一致性和同步。

UCM可以在软件安装或更新后，执行激活或回退操作，确保软件的可靠性和安全性。

UCM可以提供软件的版本信息、状态信息、错误信息等，供客户端查询和监控。

PHM模块（Platform Health Management）

功能描述：

PHM是一种实现平台健康管理和功能安全功能的软件组件。PHM模块监控运行的应用程序，当受监控实体发生错误/故障时，PHM模块可以触发恢复操作。恢复操作具体由集成人员根据平台软件架构需求，在Manifest文件当中定义。

主要功能：

▸ 全局和本地监督（Global and local supervision）

▸ 逻辑监督（Logical supervision）

▸ 恢复操作 （Recovery actions）

▸ 存活监督（Alive supervision）

▸ 截止日期监控（Deadline monitoring ）

持久化（Persistence）

功能描述：

Persistence模块是一种让自适应平台的软件可以保存和读取数据的软件组件。它可以把数据存储在不会丢失的存储器中，即使车辆关机或重启也不会影响。它提供了一个统一的接口，让软件可以方便地访问不同的存储位置。

主要功能：

▸ 键值存储（Key-Value storage）

▸ 文件代理访问（File proxy access）

▸ 并行访问数据（Parallel access to data）

▸ 持久数据的安装、更新和回滚（Installation, Update and Rollback of Persistent Data）

时间同步(ara::tsync)

功能描述：

ara::tsync它提供了时间同步的功能，使得不同的节点可以共享一个全局的时间基准。ara::tsync的主要特点有：

•基于服务的架构，可以动态地发现和订阅不同的时间基准资源，如全局时间主节点或从属时间基准节点。

•支持多种网络绑定，如SOME/IP、REST、DDS等，以适应不同的通信需求和场景。

•支持即时时间同步和延迟时间同步两种模式，分别用于高精度和低精度的时间同步需求。

•支持用户数据的传输，可以在时间同步消息中附加额外的信息，如诊断数据、配置数据等。

主要功能：

▸ 启动和关闭 （Startup & shutdown）

▸ 时间校正 （Time correction）

▸ 时基提供者和使用者模式 （Time base provider and consumer modes）

入侵检测系统管理(ara::idsm)

IDS Overview

功能描述：

ara::idsm它提供了入侵检测系统管理的功能，使得不同的安全传感器可以向它报告安全事件，并对安全事件进行过滤和处理。ara::idsm的主要特点有：

•基于服务的架构，可以动态地发现和订阅不同的安全事件资源，如入侵检测系统主节点或从属入侵检测系统节点。

•支持多种网络绑定，如SOME/IP、REST、DDS等，以适应不同的通信需求和场景。

•支持用户定义的诊断事件内存，可以将安全事件存储在独立于主诊断事件内存的内存中。

•支持用户数据的传输，可以在安全事件消息中附加额外的信息，如诊断数据、配置数据等。

主要功能：

▸ 事件生成 (Event generation)

▸ 报告模式(Reporting modes)

▸ 过滤器链条 (Filter chains)

▸ QSevs的传播和认证(Propagation & authentication of Qsevs)

▸ Rate and traffic limitation

▸ 访问控制（包括诊断访问）Access control (including diagnostic access)

防火墙(ara::fw)

Architecture of the FC Firewall (图片来自AUTOSAR官网)

功能描述：

ara::FW是AP AUTOSAR中的一个模块，它提供了防火墙的功能，使得不同的节点可以根据防火墙规则来控制网络访问和通信。

ara::FW的主要特点有：

基于服务的架构，可以动态地发现和订阅不同的防火墙资源，如防火墙主节点或从属防火墙节点。

支持多种网络绑定，如SOME/IP、REST、DDS等，以适应不同的通信需求和场景。

支持用户定义的防火墙规则，可以在运行时动态地修改和应用防火墙规则，以适应不同的车辆状态或外部系统的变化。

支持用户数据的传输，可以在防火墙消息中附加额外的信息，如诊断数据、配置数据等。