本文给大家分享一下在 AP AUTOSAR 里面我们怎么样去做一个设计，整个 AP 的设计思想及原理。AP 比较抽象，如果不是针对一个具体问题来讲 AP 的一些设计的话，会比较难以理解，所以本期我们尽量地去阐述在 AP 下面，它有些什么功能，一般我们在 AP 下面去做设计的话，它会涉及到哪些东西，以这个方向带大家一步步进入，后期带大家回顾下可能会更有感觉些。首先看下 AP 的一个设计思想，它的中心的点是什么？其实就 AP 来说，它是一种通用的系统性的一个方法论，它描述了在 POSIX 这个系统下面怎么样去做应用的一个开发。
相信很多人都已经做过类似的开发，其实我们在做应用开发的过程中避不开的讨论就是：其实上述问题对应用开发来说，都是要去考量的一些问题。如果只是做自己的开发，相对比较简单。但是，应用最大的问题就是怎么跟别人去做交互，交互问题在应用开发中是一个比较窄的点，所以就 AP AUTOSAR 而言，它的一个设计思想更多的是一种服务的思想。比如说我们在做自己的一个应用，那这个应用肯定不是一个孤立存在的，你肯定会调用别人的东西。同时如果我们把自己定位成一个服务的话，肯定会开放一些东西给到别人去使用，让别人去 Call 我们的一些服务，所以 AP AUTOSAR 要解决一个问题就是要做一个Adaptive Application（简称 AA）应用。那么在 AP AUTOSAR 中如何来描述我们的 AA 呢，需要从以下几个方面进行描述：- 描述 AA 的运行环境，如 Machine（Virtue ECU)及CPU Core ID
- 描述 AA 的加载及通信端口，应用如果要存在的话，首先要解决的就是通信的问题。当我们在做通信时，我们需要知道，通信端口是什么、ID 是什么？所以我们需要明确自己的通信方式跟 ID。
- 描述 AA 的 Log Trace 的方式、配置及打印级别，因为我们需要做 Debug
- 描述 CP 及 AP 之间通信的方式、端口及接口定义
- 当我们把 AA 定义为一个服务时，我们需要描述 Service AA 的身份标识，可提供的物理连接端口及其及接口定义。对于接口定义的 "消息通知" 来说，当然也包括我们的"Event ID"以及 Event 所携带的 Data Type 等。当我们在描述文件中对我们的服务接口进行详细描述后，对方获取我们的接口后，就知道如何来对接了。
- 描述 Proxy AA 的身份标识，及通过何种物理端口与 Service AA 进行连接并完成接口定义的 "消息通知" 及 "方法" 调用。
需要注意的是，上述描述性的东西，其实就是我们建模的东西。输出产物为 ARXML文件。这个 ARXML 后期会生成 ".json" 文件。我们可以通过创建模型或者修改我们的".json" 文件来完成对我们想要的应用的描述。因为只有有了这些描述，执行管理（EM）才能知道如何来加载我们的应用。在通信（如使用SOME/IP）的时候，别人才能找到我们以及我们才能知道怎么发现别人。总而言之，AP AUTOSAR 的设计思想就是一个方法论，它通过描述一个应用的具体行为，通过中间件的方式，让其被系统加载起来。以及描述服务消费者和服务提供者之间如何对接的问题。
下面我们看一些更具体一点的，这里涉及到了 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 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：
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 的核心组件，也叫功能集群，简称 FC。
上图中，Execution Manager、Communication Middleware 是这些组件里最核心的组件，IAM是做权限管控的，Diagnostic Manager是做诊断，Network Manager 是做网络管理，Update Manager 是做升级，Log Manager 是做Log的一些管理，Health Manager 是做健康状态监控的。
下面对上述核心组件的功能进行一个简单的描述。
Execution Manager：负责对进程的生命周期进行管理
搜寻指定路径下所有可用的 Executables 并加入进程列表中，启动阶段按进程依赖顺序加载所有配置在默认功能组的进程
当发生功能组状态切换时，终止未定义在新功能组的进程，并按照进程加载依赖顺序重新加载新功能组的所有进程
当功能组内的状态发生迁移时，驱动所有被加载的进程往相应的状态迁移
IAM：为应用访问及控制Autosar资源提供身份鉴权
Platform Health Manager：管理被监控运行实体的健康状态
- 当检测到异常状态时，按照定义执行 RecoveryAction
- 管理各个被监控进程报告的健康状况，并报告 PHM 的监控及状态切换结果给到用户 Application，以便用户执行最终如 Watchdog 等自定义的决策
Log Manager：提供Log前台打印API及后台Log存储服务
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：提供诊断服务处理及内存地址管理功能UCM：负责对AdaptiveApplication的安装、更新和删除
