Adaptive AUTOSAR CM模块介绍(二)

在Adaptive AUTOSAR CM模块介绍(一)中介绍了 AP CM模块的功能和定位,这一篇主要是讲解AP CM模块的ara::com API的内容:
为什么AUTOSAR发明了另一种通信中间件API/技术?在当时中间件技术有很多啊?在当时特别有名的中间件有:
• ROS API
• DDS API
• CommonAPI (GENIVI)
• DADDY API (Bosch)
1.当时工程师的设想是当时的中间件还是很复杂并且有各自的功能,AUTOSAR肯定是想要构建一个统一的接口,各个OEM都遵守的协议。它必须支持SOM/IP协议。好,又是SOME/IP。
这里稍微说一下SOME/IP的历史,后面我想要着重讲述一下SOME/IP的事情。
SOME/IP于2011年由BMW设计,2014年纳入AUTOSAR规范。不得不说当时SOME/IP是非常的好用的。
2.既然支持SOME/IP,所以就需要支持AUTOSAR服务模型,它将服务定义为所提供的方法、事件和字段,必须根据用户的需求进行改变和配置。
3.ara::com API应支持事件驱动和轮询模型。实时应用程序通常需要轮询的方法来避免不必要的上下文切换,而事件驱动方法则需要对于没有实时要求的应用程序更加方便。
4.提供端到端保护,无缝集成,满足ASIL的要求。
5.支持静态(预配置)和动态(运行时)选择要与之通信的服务。这是SOA的思想。
因此,综上所述的发考虑,AUTOSAR考虑的还是比较全面的,从实时通信、SOME/IP、安全、SOA思想等融于一体的考虑,才有了这个ara::com API的想法架构和设计。
于是,ara::com的最终考虑到的设计为:

  • Proxy (or Stub)/Skeleton的方法,这个来源于COMMON-API,Java RMI等技术
  • 独立协议的API,同样是借鉴的COMMON-API,Java RMI等技术
  • 可配置的接收器侧高速缓存的排队通信,借鉴DDS、DADDY等技术
  • 支持零拷贝的API(DADDY)
  • 数据接收过滤系统

因此,ara::com 的方法论是:ara::com提供的这些API接口是由应用程序开发人员进行调用即可,其内部的实现这些数据传输以及零拷贝等需要AUTOSAR AP供应商负责。
整体的架构图,如下所示:
Adaptive AUTOSAR CM模块介绍(二)_第1张图片
解释一下:
Proxy/Skeleton分别是客户端和给服务端的服务,这两个的服务是可以通过用户定义生成的抽象类,用户通过这些类去创建各自的对象,调用各自的方法进行通信。
都有哪些方法,这个需要下一章节来解释说明。

你可能感兴趣的:(车载相关,AUTOSAR,AP,CM)