车载软件架构 - AP AUTOSAR 设计思想及原理
我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。
老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：
屏蔽力是信息过载时代一个人的特殊竞争力，任何消耗你的人和事，多看一眼都是你的不对。非必要不费力证明自己，无利益不试图说服别人，是精神上的节能减排。
无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事.而不是让内心的烦躁、焦虑、毁掉你本就不多的热情和定力。
时间不知不觉中，快要来到春末的六月。清晨起来，抬望眼处那份嫩绿，还是能让人心生欢喜。
本文主要分享车载软件架构 - AP AUTOSAR 设计思想及原理
1、AP AUTOSAR 的设计思想
2、Machine 清单的定义及使用
3、创建应用程序清单
4、Provided/Required 服务实例
5、模型创建及配置的生成产物
6、AP AUTOSAR 核心组件
正文如下：
一、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 的设计思想就是一个方法论，它通过描述一个应用的具体行为，通过中间件的方式，让其被系统加载起来。以及描述服务消费者和服务提供者之间如何对接的问题。
在应用开发中，特别是在涉及到多系统、多应用协同工作的环境中，您提到的几个关键问题是至关重要的。针对AP AUTOSAR（Adaptive Platform of AUTomotive Open System ARchitecture，汽车开放系统架构的自适应平台）来说，其设计思想确实更多地体现为一种服务的思想，旨在解决应用之间的交互问题。以下是针对您提出的问题的详细回答：
-> 应用会运行在什么OS上面？
AP AUTOSAR平台设计是基于AUTOSAR标准的，它并不直接绑定于特定的操作系统（OS）。然而，它确实提供了一个标准化的框架，使得应用可以在遵循AUTOSAR标准的各种操作系统上运行。这意味着开发者可以专注于应用的业务逻辑，而不需要过多考虑底层的操作系统细节。
-> 我们有哪些middleware（中间件）？
在AP AUTOSAR平台设计中，中间件是一个重要的组成部分。这些中间件提供了软件组件之间的通信机制、数据交换、错误处理等功能。通过中间件，不同的软件组件可以协同工作，实现复杂的系统功能。AP AUTOSAR支持多种中间件，包括用于网络通信的RTE（Runtime Environment）、用于服务调用的RVI（Remote Vehicle Interface）等。
-> 这些应用要跟其他的应用有怎样的一个交互？
在AP AUTOSAR中，应用之间的交互是通过软件组件和中间件来实现的。每个软件组件都有自己的功能和接口，通过中间件提供的通信机制与其他组件进行交互。这种交互可以是数据交换、服务调用、事件通知等。AP AUTOSAR通过标准化的接口和协议来确保不同应用之间的顺畅通信。
-> 这个交互又怎样去定义他们之间的一个接口？
在AP AUTOSAR中，接口的定义是通过AUTOSAR规范来完成的。AUTOSAR定义了一系列标准化的接口，包括用于SWC（软件组件）之间通信的AUTOSAR接口、用于BSW（基础软件）与SWC之间通信的标准化AUTOSAR接口以及基于特定编程语言的标准化接口等。这些接口定义了数据交换的格式、通信协议、错误处理机制等，确保了不同软件组件之间的兼容性和可互操作性。
-> 他们之间的是以什么样的方式去通讯？
AP AUTOSAR支持多种通信方式，包括基于以太网的通信、CAN总线通信等。具体的通信方式取决于应用的需求和系统的配置。通过中间件提供的通信机制，不同的软件组件可以通过网络或总线进行通信，实现数据的交换和服务的调用。
二、Machine 清单的定义及使用
下面我们看一些更具体一点的，这里涉及到了 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 的描述将目标文件安装到指定路径下/删除指定路径下的目标文件
