前言

搞SOA、搞 AP & CP AUTOSAR、搞异构SoC、搞车载以太网、搞车载OS等就找搞一下汽车电子。


全系内容可在《搞一下汽车电子》后台回复 “系列”，或进入菜单栏 “分享平台” --> “系列分享”


本系列请点击：《搞一下 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的设计思想就是一个方法论，它通过描述一个应用的具体行为，通过中间件的方式，让其被系统加载起来。以及描述服务消费者和服务提供者之间如何对接的问题。

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的描述将目标文件安装到指定路径下/删除指定路径下的目标文件

本期分享就到这里，下期见。


AP & CP工具链、咨询、培训、外包；SOA方案；车载OS；工具链及设备租赁等，也可以随时跟我们联系哦。

跳转阅读

建议解锁2022 全45期内容，还可以语音Q & A，详情点击：
2022 年度 | AP、CP、Eth、SoC、SOA 实战系列 | 线上研讨会


跳转阅读：AP AUTOSAR 设计思想及原理

联系我们

微信：shactiontech
邮箱：support@shactiontech.com

最后

以上就是害羞心情为你收集整理的搞一下 AP AUTOSAR 原理及实战 | 01 AP AUTOSAR 设计思想及原理前言AP AUTOSAR 的设计思想Machine Manifest 的定义及使用创建应用程序清单创建服务接口及服务接口部署Provided/Required 服务实例模型创建及配置的生成产物AP AUTOSAR 核心组件跳转阅读联系我们的全部内容，希望文章能够帮你解决搞一下 AP AUTOSAR 原理及实战 | 01 AP AUTOSAR 设计思想及原理前言AP AUTOSAR 的设计思想Machine Manifest 的定义及使用创建应用程序清单创建服务接口及服务接口部署Provided/Required 服务实例模型创建及配置的生成产物AP AUTOSAR 核心组件跳转阅读联系我们所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。