1从SOA-RM到AP AUTOSAR
在《AP AUTOSAR基础简介》之《AP AUTOSAR & SOA》视频中，我们提到：AP AUTOSAR是一种面向服务的架构！在《SOA点映》中也提到：SOA不是具体的技术实现，而是一种模板软件架构！ 那么，怎么来理解SOA是一种模板软件架构？又如何理解为什么AP AUTOSAR是SOA？以下是笔者的一些理解分享给大家，如有不对之处，还请指出。 SOA的全称是：面向服务的架构（Service Oriented Architecture），从SOA的概念中，我们比较容易产生一个问题：这个架构怎么来的？要想搞清楚这个点，我们需要先理解以下SOA参考模型（SOA-RM）
①SOA-RM到SOA
SOA参考模型（SOA-RM）描述了SOA环境中的各个组件（或者实体）及其之间的关系。当前对SOA-RM的研究大致分为以下几类： 1. 以W3C的Web服务架构工作组为代表：
它是通过定义一些具体的功能组件和其他抽象实体来研究这些组件和实体之间的关系。但是，它定义于Web服务技术背景，故其架构分析具有局限性。
2. 以OASIS成立的SOA-RM技术委员会为代表：
它主张以SOA中相关的抽象概念和实体为出发点，来研究它们之间的关系。它认为SOA涉及的元素包括服务与服务的描述，服务的发布与发现机制，服务的相关规范，数据模型和服务协议等！
3.以软件组件为基础进行系统架构的研究
主要有IBM、微软等企业为代表，它们进行着自己的应用平台以及解决方案的SOA研究。但是这样的模型依赖于特定的技术平台，因此，不是理想的SOA通用模型。
笔者比较认可OASIS的观点，且与汽车行业相关度大，因此笔者将以OASIS为代表的SOA-RM出发进行分析。 PS：《搞一下汽车电子》也为各位解锁全系的朋友准备了中文版的OASIS《soa-rm-v1.0》，在公众号菜单栏联系我们进行获取 笔者基于OASIS的观点，整理了SOA-RM与SOA的关系如下：
SOA-RM是一种抽象框架
SOA-RM并不与任何标准、技术和其他的具体实现细节关联
与标准技术和其他具体实现细节相关联的是SOA
SOA是SOA参考模型的一种应用
图：OASIS SOA-RM 简单来说：SOA-RM只是一个框架，架构师可以使用现有的协议（如web服务协议）、标准以及规范等来构建具体的架构实现，那么根据SOA-RM，并结合一定协议、标准以及规范等构建出来的架构便是一种面向服务的架构SOA！ 到此，我们知道了SOA的构建来自SOA-RM。那么，接着下一个问题，SOA到底是什么？上文笔者也说明了笔者眼中的SOA：SOA是一种模板软件架构，这怎么理解？AP AUTOSAR是SOA又如何理解呢？我们往下看：
②SOA到AP AUTOSAR
在《AP AUTOSAR & SOA》中，我们主要介绍了SOA的通信机制，并简单介绍了SOA的概念。知道了它不是具体的技术实现，那么SOA是一种模板软件架构如何理解呢？ 我们将模板软件架构拆开来理解：
模板：基于现有标准、技术等实现一套用于设计和开发应用程序的原则和方法
软件：这里的软件代表着一种软件设计模式，可以使用互操作服务的形式来开发软件
架构：这里的架构是指一种架构设计模式，按照服务所属所指定的约束和策略来执行
软件架构：是指由系统元素及其外部可见属性以及他们之间的关系组成。
所以，笔者认为SOA是一种模板软件架构，并不是具体的技术实现。因为SOA不涉及具体技术实现的内容！这也能对应了SOA是SOA-RM的一种应用！ 这里对SOA中服务的概念进行一个简单说明：
服务是最基本的单元，一种能够访问一个或多个功能的机制
理解了SOA是一种模板软件架构，那么为什么AP AUTOSAR是一种SOA，笔者认为主要体现在以下方面： 从模板的角度出发来理解，AP AUTOSAR提供了一套开发应用程序的方法即AP AUTOSAR方法论，主要分为三部分：
架构与设计（下图蓝色框），包含：
开发一个服务接口描述
通过Machine Design开发通信结构
软件开发（下图绿色框），包含：
开发Application-Level类型的软件
开发Platform-Level类型的软件
集成与部署（下图黑色框），包含：
定义和配置Machine
定义和配置Service Instance
等等
图：AP AUTOSAR方法论概览 从软件方面理解： AP AUTOSAR使用互操作服务的形式进行软件开发，机制如下： 主要包含两个角色：
服务提供者
服务消费者
两者之间是通过通信管理中间件（CMM）传输层进行通信。 通信管理中间件主要以下通信方式（协议约束）：
SOME/IP
DDS
服务提供者和服务消费者之间的连接是CMM在运行时动态创建的！
图：Proxy Skeleton Pattern 需要提到的是，AP AUTOSAR中采用了服务骨架（Service Skeleton）与服务代理（Service Proxy）模式，服务骨架与服务代理是根据 ”服务接口定义 “ 生成的。 PS：那么SOME/IP如何设计，DDS又如何设计？我们将会在后期《搞一下SOA》系列与《搞一下整车以太网》系列中进行分享（需解锁全系哦！） 笔者认为，单一个软件通信还不足以成为软件架构，AP AUTOSAR除了通信之外，还有其他的系统元素，如：与存储相关的ara::per 功能集群。详细的架构图如下，我们也在《What AP AUTOSAR》中对上述每个功能集群进行了简单的描述。 因此，笔者认为，AP AUTOSAR是SOA（注意这里是SOA，不是SOA-RM），是一种模板软件架构！
图：AP AUTOSAR架构概览 上图中需要提到的是，AP AUTOSAR规定，Application只能直接访问POSIX的PSE51接口，不能直接访问非PSE51接口。 PS：《搞一下汽车电子》也为各位解锁全系的朋友准备了原版的《IEEE1003.13》，在公众号菜单栏联系我们进行获取 解释了为什么AP AUTOSAR是SOA，我们再来总结一下what AP AUTOSAR？
SOA：动态创建连接
中间件：承上启下
标准：规范API及功能、规范交互方式、规范开发方法
详细内容，请查阅《What AP AUTOSAR中》
图：What AP AUTOSAR 这里笔者也总结了一下AP AUTOSAR的特性：
灵活的软件配置
Security & Safety
并行处理
与现有标准及规范的兼容
基于POSIX标准
动态分配内存
SOA
我们从SOA-RM出发，分析了AP AUTOSAR。AP AUTOSAR也刚发布了R2011版本，本系列后期也会结合AP AUTOSAR R20-11的新特性来分享《搞一下AP AUTOSAR进阶应用》，因此，这里笔者为大家整理了一下AP AUTOSAR R20-11的一些更新！
2AP AUTOSAR R20-11
我们将从文档、平台设计以及新增特性等方面进行分享。
①文档变更
R2011文档方面的变更还是很大的，《搞一下汽车电子》按照之前的分类方式将R2011进行了整理，大家可以后台回复" AP点映"进行查看。 我们还是将其分为以下几个文件夹：
Adaptive Foundation：与基础功能集群相关的文档
Adaptive Service：与服务功能集群相关的文档
General：AP AUTOSAR General文档
Methodology And Manifest：与方法论、元模型以及Manifest等相关的文档
Release Documentation：Release相关文档
其中Adaptive Foundation增加了很多Foundation中功能集权的解释性说明文档，主要包括：
AdaptiveService部分，增加了以下内容：
其中： 《AUTOSAR_RS_AutomatedDrivingInterfaces》规定了传感器接口上AP AUTOSAR的要求。 《AUTOSAR_SWS_SensorInterfaces》描述了传感器接口的功能说明与接口 Adaptive General部分进行了以下更改：
需要说明的是，R2011标准文档中，没有《AUTOSAR_SWS_General》等，笔者认为是缺少了，而不是被删除了。 Methodology And Manifest部分进行了以下更改：
其中《AUTOSAR_TPS_AdaptivePlatformTimingExtensions》是通过AUTOSAR元模型对时间扩展正式定义的补充。 这里需要特别说明的一个文档是《AUTOSAR_SWS_AdaptiveIntrusionDetectionSystemManager》。 笔者认为，上述文件入侵检测系统管理（Idsm）应该是一个属于Foundation部分的功能集群（FC），但是，其他文档中，都没有与Idsm相关的内容。即使是《平台设计》中也没有。属于标准的问题，可能会在下个版本中有所体现。
②平台设计变更
《平台设计》是AP AUTOSAR中对AP AUTOSAR进行概述的文档，这里，对平台设计中主要的改动进行说明如下： 1. 在《持久性》章节进行了以下更改： 持久性主要的三种应用场景有：
在Adaptive Machine上安装新的应用程序软件
将现有应用程序软件更新到Adaptive Machine
从Adaptive Machine卸载现有的应用程序软件
图：Persistency 在R1911中，对上述三种应用场景进行了以下说明： UCM都使用持久性来部署/删除/更新应用程序的持久性数据 在R2011中，对其进行说明如下： 在前两个场景中，持续性由UCM通过EM触发，以部署/更新应用程序的持久性数据 在第三个场景中，UCM可以使用uri从持久性配置中删除剩余的持久性数据 2. 在《UCM》章节，更改了UCM Master 的状态机： 我们也会在后期基于此分享" AP AUTOSAR & OTA"
图：UCM Master状态机 3. 在《Crypto》章节更改了密钥管理交互，如：增加独立且受信任的环境等：
图：密钥管理交互 当然，还有其他更多更改内容，可参考《AP AUTOSAR 平台设计》文档。 PS：《搞一下汽车电子》也为各位解锁全系的朋友准备了中文版的AP AUTOSAR R2011《平台设计》，在公众号菜单栏联系我们进行获取
③新增特性
从Safety方面来说，新增了系统健康监控，主要用于系统协调健康状况/错误。主要包含以下内容：
SHM Client交流平台健康状况
SHM Master确定健康指标
根据健康指标进行的机器恢复（例如降级）
图：系统健康监控 从上图也可以看出，SHM Client是在AP AUTOSAR端，SHM Master是CP AUTOSAR端。这也是AUTOSAR官方在AP AUTOSAR 功能安全方面的又一考虑吧。有关AP AUTOSAR & Safety更多内容，可查看《AP AUTOSAR & Safety》 在Safety方面，也增加了确定性同步的内容，描述了同步行为和周期性激活的要求，包括时间同步和数据同步。
图：确定性同步 从Security方面来说，增加了入侵检测系统管理，有标准化的接口来报告安全事件，有标准化的过滤机制，来通过网络来传输合格的安全事件。 PS：还是如前所说，除了一份Idsm文档外，无更多描述
在Security方面，也增加了Crypto API的描述：
软件和硬件独立开来
支持分离式非耦合开发
应用程序独立于加密解决方案
上述，便是R2011主要的变更，当然还有很多变更，我们会在后期的系列分享中，与大家进行分享，那么为什么要分享《搞一下AP AUTOSAR进阶应用》
3Why AP AUTOSAR应用
从流程来说：
需要一套标准化的开发流程，我们会分享" AP AUTOSAR 方法论"
从架构来说：
汽车EEA从分布式到域集中式再到车辆集中式发展过程中，需要新的技术、协议来作为支撑，我们会分享" AP AUTOSAR & EEA"。
当然我们也有《搞一下SOA》系列。
从功能需求来说：
为了避免召回，需要整车OTA功能，我们会分享"AP AUTOSAR & OTA "
汽车高度自动驾驶等需要基于POSIX OS运行具有ASIL 要求的实时Application，系统需要确定性行为，我们会分享 " AP AUTOSAR & 确定性执行"
AP标准中无XCP协议，那么如何基于AP来做标定，我们会分享" AP AUTOSAR & 标定 "
在AP AUTOSAR中能否使用基于视觉的算法？我们会分享" AP AUTOSAR & AI "
如何在AP AUTOSAR中使用DDS的网络绑定？我们会分享" AP AUTOSAR & DDS "
从应用来说：
自动驾驶平台涉及哪些软件技术？AP扮演什么角色？我们会分享 " AP AUTOSAR & 自动驾驶"
智能座舱涉及哪些技术？AP 扮演什么角色？我们会分享" AP AUTOSAR & 智能座舱 "
如何基于AP AUTOSAR开发中央计算单元？我们会分享" AP AUTOSAR & 中央计算单元"
如何基于现有物联网技术与AP解决昂贵的车辆更新缓慢问题？我们会分享" AP AUTOSAR & IoT "
从兼容适配来说：
系统应能够支撑应用程序分离，我们会分享" AP AUTOSAR & Hypervisor"
当然，上述内容会根据实际情况进行一定的调整。最后再回答一个大家比较关心的问题：如何学习AP AUTOSAR？
首先，请在公众号《搞一下汽车电子小助手》后台回复 " 系列 " 查看《搞一下 AP AUTOSAR基础简介》《搞一下 AP AUTOSAR平台设计》
接着，请具备cpp编程能力
然后，从《AUTOSAR方法论》进行突破
接着，研究标准文档，如果工具链，基于工具链进行研究最好。
文章出处：【微信公众号：汽车电子设计】
