AP AUTOSAR 的设计思想

今天给大家分享一下在AP AUTOSAR 里面我们怎么样去做一个设计，整个AP的设计思想及原理性的东西。

AP比较抽象，如果不是针对一个具体问题来讲AP的一些设计的话，会比较难以理解，所以本期我们尽量地去阐述在AP下面，它有些什么功能，一般我们在AP下面去做设计的话，它会涉及到哪些东西，以这个方向带大家一步步进入，后期带大家回顾下可能会更有感觉些。

首先看下AP的一个设计思想，它的中心的点是什么？其实就AP来说，它是一种通用的系统性的一个方法论，它描述了在POSIX这个系统下面怎么样去做应用的一个开发。

相信很多人都已经做过类似的开发，其实我们在做应用开发的过程中避不开的讨论就是：

我们的应用会跑在什么OS上面？

我们有哪些middleware（中间件）？

这些应用要跟其他的应用有怎样的一个交互？

这个交互又怎样去定义他们之间的一个接口？

他们之间的是以什么样的方式去通讯？

其实上述问题对应用开发来说，都是要去考量的一些问题。如果只是做自己的开发，相对比较简单。

但是，应用最大的问题就是怎么跟别人去做交互，交互问题在应用开发中是一个比较窄的点，所以就AP AUTOSAR而言，它的一个设计思想更多的是一种服务的思想。

比如说我们在做自己的一个应用，那这个应用肯定不是一个孤立存在的，你肯定会调用别人的东西。

同时如果我们把自己定位成一个服务的话，肯定会开放一些东西给到别人去使用，让别人去call 我们的一些服务，所以AP AUTOSAR 要解决一个问题就是要做一个Adaptive Application（简称AA）应用。

那么在AP AUTOSAR中如何来描述我们的AA呢，需要从以下几个方面进行描述：

描述AA的运行环境，如Machine（Virtue ECU)及CPU Core ID

描述AA的启动配置及启动依赖

描述AA的加载及通信端口，应用如果要存在的话，首先要解决的就是通信的问题。当我们在做通信时，我们需要知道，通信端口是什么、ID是什么？所以我们需要明确自己的通信方式跟ID。

描述AA的Log Trace的方式、配置及打印级别，因为我们需要做Debug

描述CP及AP之间通信的方式、端口及接口定义

当我们把AA定义为一个服务时，我们需要描述Service AA的身份标识，可提供的物理连接端口及其及接口定义。对于接口定义的 "消息通知" 来说，当然也包括我们的 " Event ID "以及 Event 所携带的 Data Type等。当我们在描述文件中对我们的服务接口进行详细描述后，对方获取我们的接口后，就知道如何来对接了。

描述 Proxy AA的身份标识，及通过何种物理端口与Service AA进行连接并完成接口定义的 "消息通知" 及 "方法" 调用。

描述AA归属的哪些功能组

需要注意的是，上述描述性的东西，其实就是我们建模的东西。输出产物为ARXML文件。这个ARXML后期会生成 ".json" 文件。

我们可以通过创建模型或者修改我们的".json" 文件来完成对我们想要的应用的描述。因为只有有了这些描述，执行管理（EM）才能知道如何来加载我们的应用。在通信（如使用SOME/IP）的时候，别人才能找到我们以及我们才能知道怎么发现别人。

总而言之，AP AUTOSAR的设计思想就是一个方法论，它通过描述一个应用的具体行为，通过中间件的方式，让其被系统加载起来。以及描述服务消费者和服务提供者之间如何对接的问题。

Machine Manifest 的定义及使用

下面我们看一些更具体一点的，这里涉及到了 Machine Manifest 的定义。

下图做了比较清晰的一个描述。

那么Machine是什么？我们的应用都是运行一个Machine上面的，其实我们现在的SOC都是很强大的，可以在我们的一个SoC上面去挂多个Machine，Machine1、Machine2、Machine3。

然后我们可以把某些应用运行在 Machine1、Machine2或者Machine3里面，所以Machine它是在硬件的基础上的一个虚拟的概念，它映射的是用于描述CPU/内存/物理单元的一个硬件资源。

无论怎么样，我们的应用一定是运行在某个Machine上，Machine可能用到了当前的这个SoC里面其中某一个Core，比如说我们有八个A72的Core，把前面两个Core配置成Machine1，中间的两个core配置Machine2，通过这种方式可以让你的应用把它归属到某个具体的一个Machine上面，那具体的 Machine 上就绑定了具体它跑在哪个Core上面。

同样的话，这种用法的还有一种叫虚拟机的用法。也就是说在我们的SoC之上再去挂Hypervisor，在 Hypervisor 上再挂 Guest OS，在 Guest OS 上面再挂接 Machine。

实际上这就实现了对Soc分层次的虚拟的一个用法。对一个应用来说，它一定要把自己挂接在某个Machine上的。

那么Machine的定义是什么？是用于描述如CPU/内存/物理连接等硬件资源，包括：

ECU的 Resource 描述，如CPU可用的 Processor 类型及数量

Machine定义了所有可用的物理通信 Connector，比如 EthernetConnector ，及其对应通信端口NetworkEndpoint的描述（IPAddress or Domain & Port)

ServiceDiscovery Configs描述通过可用物理通信端口监听来自 Multicast 地址信息定义的 SOME/IP Protocol报文

定义Machine的状态机，应用能不能工作都是跟着 Machine 状态机走的。

配置 AP AUTOSAR 的OS（当前很多供应商都还没实现）

对于AA来说，需要绑定某个配置好的Machine，设置AA可以工作或禁止工作在哪个或哪些CPU Processor上，并指定其使用Machine定义的哪个通信Connector。

创建应用程序清单

Application Manifest用于描述实例化运行在Machine之上的可执行的Process：

我们一般从以下几个方面对应用清单进行描述。

配置Executable启动选项，包括以下内容

配置进程启动依赖关系

配置进程的调度策略

配置进程的线程优先级

配置进程所在的功能组（Function Groups）

配置进程工作/不工作在哪个或哪几个Processor上

配置Executable的Provided/RequiredPort及Port所绑定的Service Interface

每个Process都对应有一个专属的Manifest配置

同一个Executable可以被实例化到多个Process对应的Manifest，也就是说，一个Process至少要包含一个Executable，一个Executable可以被多个Process引用。

总的来说，这里面最重要的就是Executable 启动选项的配置。

创建服务接口及服务接口部署

Service Interface（服务接口）是什么？服务接口定义了Skeleton/Proxy之间的接口关系，主要包括以下交互方式：

Notify: 定义消息event_id及对应的消息所携带的数据结构

Method Call：定义方法调用供Proxy使用，需定义所有输入参数的数据结构，及返回值的数据结构；Skeleton在完成Method Call调用执行后，Skeleton会发送执行结果的返回值给Proxy

Fire & Forget：定义方法调用供Proxy使用，需定义所有输入参数的数据结构，无返回值；Skeleton在完成Method Call调用执行后，不会Response给Proxy

Field: 为所定义的数据结构可以同时提供Service Notifier，及Proxy Getter/Setter 的Method Call功能

Service Interface Deployment 描述了如何部署Service Interface

为 Service Interface 分配指定的 Service id

为 Service Interface 分配 major_version 及 minor_version，某一个服务可能会存在多个版本，每个版本里面的服务接口可能是不一样的。

我们在做服务设计时，很重要的一步就是如何定义服务接口。

Provided/Required 服务实例

定义和配置服务实例的元模型如下：

服务实例相关的设计主要包括以下内容。

创建Service Instance：

为Provided Service绑定对应的Service Interface，配置发送Offer Service报文的周期，分配Instance Id

为Required Service绑定对应的Service Interface，配置发送Find Service报文的周期，分配Instance Id

Instance ID：Proxy引用的Required Instance Id一定要与对应的Skeleton提供的Provided Instance Id保持一致

Mapping Service InstanceTo Machine：

配置Provided/Required Service Instance使用哪个Machine里的哪个物理通信Connector，即选用哪个Machine用于执行该Service Instance

配置TCP/UDP Port

Mapping Service Instance To Provided/Required Port：

为Provided/Required Service Instance配置使用哪个Excutable定义的Provided/Required Port，即把该Service Instance挂在哪个进程，绑定哪个Port而执行

模型创建及配置的生成产物

在我们建模完之后，会生成以下产物。

生成Skeleton/Proxy通信框架的基类源代码，供Application开发者继承基类使用以直接获取通信能力：

生成Notification/Field/Method Call所关联datatype的数据结构，及对应数据结构payload的基于Someip Protocol的Serialize/Deserialize实现

生成Skeleton/Proxy的Event，Method及Field的函数接口及对应的Message Builder的Serialize/Deserialize实现

Skeleton/Proxy Pattern生成所有Provided/Required Service Instance及SOMEIP/IPC binding等初始化实现，以及Offer/Find Serviced的具体实现

启动配置JSON文件描述，供Execution Manager启动加载应用时使用：

进程的启动依赖

进程的调度策略及线程优先级§进程所属的功能组及其Machine状态机的所有可用状态

SOME/IP JSON配置文件，供SOME IP_Daemon使用：

配置进程所有用到Services的属性：Service Name, Service Id,Service Version，Methods(name/id),Events(name/id)

配置了进程的Provided Service Instance：关联的ServiceId，InstanceId，Service Discovery的参数属性，映射到Machine的参数属性(NetworkIP Address, Tcp/Udp PortNumber)

配置了进 程的Required Service Instance：关联的ServiceId，InstanceId，Service Discovery的参数属性，映射到Machine的参数属性(NetworkIP Address, Tcp/Udp PortNumber)

✦✦

模型生成产物如何被Middleware Platform模块使用

下图就是上述模型生成的最主要几个产物，这些产物会被如何使用我们会在之后的内容中进行分享。

AP AUTOSAR 核心组件

下图为AP AUTOSAR 的核心组件，也叫功能集群，简称FC。

上图中，Execution Manager、Communication Middleware 是这些组件里最核心的组件，IAM是做权限管控的，Diagnostic Manager是做诊断，Network Manager 是做网络管理，Update Manager 是做升级，Log Manager 是做Log的一些管理，Health Manager 是做健康状态监控的。

✦✦

核心组件功能描述

下面对上述核心组件的功能进行一个简单的描述。

Execution Manager：负责对进程的生命周期进行管理

搜寻指定路径下所有可用的Executables并加入进程列表中，启动阶段按进程依赖顺序加载所有配置在默认功能组的进程

当发生功能组状态切换时，终止未定义在新功能组的进程，并按照进程加载依赖顺序重新加载新功能组的所有进程

当功能组内的状态发生迁移时，驱动所有被加载的进程往相应的状态迁移

IAM：为应用访问及控制Autosar资源提供身份鉴权

用户需实现PolicyDecision Point (Grant或Deny的Policy）策略

IAM把应用Application的身份鉴权的请求，对接到用户的Policy策略，并给出鉴权结果回给Application

Platform Health Manager：管理被监控运行实体的健康状态

监测及判断运行实体的运行状态

当检测到异常状态时，按照定义执行RecoveryAction

管理各个被监控进程报告的健康状况，并报告PHM的监控及状态切换结果给到用户Application，以便用户执行最终如Watchdog等自定义的决策

Log Manager：提供Log前台打印API及后台Log存储服务

可提供CONSOLE/FILE/DLT/SYSLOG等工作模式

可配置多级别Verbose/ Debug/ Info/ Warn/ Error/ Fatal的打印控制

Communication Manager：提供SOME IP Protocol的通信功能

支持以SOME IP/IPC binding模式为Offer Service及Find Service提供发送及接收Service Discovery Message的能力

管理着所有Provided Services及Required Services，并为每个Service Interface定义的Event/Method/Field建立映射列表

作为所有基于SOME IP Protocol Message(Communication & Service Discovery)的Broker，为sender和receiver提供router服务

Diagnostics Manager：提供诊断服务处理及内存地址管理功能

支持多种诊断传输协议，如DoIP或者用户自定义的传输协议

提供多个诊断服务，并支持多个诊断会话并行处理

支持UDS定义的标准服务及用户自定义服务

Persistence：提供存储服务

提供基于文件存储的读写功能

提供基于Key-ValueDatabase的访问及保持功能

UCM：负责对AdaptiveApplication的安装、更新和删除

升级包自身需包含完整的如版本、依赖、认证及签名等信息

UCM接收来自AA的升级请求，传输用于升级的目标软件包，对软件包进行验签及完整性校验，根据Manifest的描述将目标文件安装到指定路径下/删除指定路径下的目标文件