AUTOSAR AP 硬核知识点梳理（2）—— 架构详解 （上）

作者：刘向

出品：汽车电子与软件

AUTOSAR 平台逻辑体系结构

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

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

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

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

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

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

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

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

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

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

1.设计阶段：设计ARXML

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

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

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的生命周期内有独立更新应用程序的能力。

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可以提供多种功能供应用程序调用来实现软硬件解耦、为上层应用提供服务。

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)

状态金字塔

文章转载自公众号：汽车电子与软件