今天给大家分享一下在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
- 当我们把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的安装、更新和删除
