网站商城支付接口,微信小程序官网登陆,营销网站建设制作,建网站的网站车载软件架构 - AP AUTOSAR 设计思想及原理
我是穿拖鞋的汉子#xff0c;魔都中坚持长期主义的汽车电子工程师。
老规矩#xff0c;分享一段喜欢的文字#xff0c;避免自己成为高知识低文化的工程师#xff1a; 屏蔽力是信息过载时代一个人的特殊竞争力#xff0c;任何消…车载软件架构 - 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 的运行环境如 MachineVirtue 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 AUTOSARAdaptive Platform of AUTomotive Open System ARchitecture汽车开放系统架构的自适应平台来说其设计思想确实更多地体现为一种服务的思想旨在解决应用之间的交互问题。以下是针对您提出的问题的详细回答
- 应用会运行在什么OS上面
AP AUTOSAR平台设计是基于AUTOSAR标准的它并不直接绑定于特定的操作系统OS。然而它确实提供了一个标准化的框架使得应用可以在遵循AUTOSAR标准的各种操作系统上运行。这意味着开发者可以专注于应用的业务逻辑而不需要过多考虑底层的操作系统细节。
- 我们有哪些middleware中间件
在AP AUTOSAR平台设计中中间件是一个重要的组成部分。这些中间件提供了软件组件之间的通信机制、数据交换、错误处理等功能。通过中间件不同的软件组件可以协同工作实现复杂的系统功能。AP AUTOSAR支持多种中间件包括用于网络通信的RTERuntime Environment、用于服务调用的RVIRemote 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 上面去挂多个 MachineMachine1、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 IDProxy 引用的 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的EventMethod 及 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 VersionMethods(name/id),Events(name/id)
配置了进程的 Provided Service Instance关联的 ServiceIdInstanceIdService Discovery 的参数属性映射到 Machine 的参数属性(NetworkIP Address, Tcp/Udp PortNumber)
配置了进 程的 Required Service Instance关联的 ServiceIdInstanceIdService 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 的描述将目标文件安装到指定路径下/删除指定路径下的目标文件 搁笔分享完毕
愿你我相信时间的力量
做一个长期主义者
