引言
上一篇文章对智能汽车软件的范围、软硬件升级、SOA的内涵进行了介绍，本篇将围绕 SOA的实现细节，重点阐述以下问题：
- SOA 基础软件框架
- SOA 参考实现
- SOA 实现所需相关技术
一、SOA 基础软件框架
上一篇中，介绍了面向服务的软件架构设计SOA，但它只是一架构种设计思想，本身并不是一个软件模块。工程中需要一个基础软件框架去实现其架构设计思想，下图中的 SOA Framework 就是我所说的基础软件框架。
上图中所表示的就是一个典型的中央计算电子电气架构，几十个 ECU 的功能，集中到少数计算单元上，大部分 ECU 消失了，但是由于底盘域的特殊性，依然保留了部分 ECU 的功能。几大控制器，选用的都是高性能的 SOC（画3个只是示意），由于工作任务的不同，选用了不同的操作系统。SOA Framework 是这个分布式软硬件系统运行的关键，具有以下特点：
- 它是一个操作系统中间件
- 运行在不同的OS 内核之上，可以跨平台。
- 除了基于以太网，最好还能兼容传统 AutoSAR
- 需要为上层应用提供良好的开发接口。
- 需要与多个 SOC 上的 SOA Framework 进行分布式协同。
SOA Framework 整体架构如上图所示，其主要功能如下：
- 本地服务、远程服务（运行在另外一个 SOC 上的服务），相互之间以统一的接口描述语言IDL为契约。IDL 是一种中立的语言，与 OS 以及开发语言无关。
- 通过Service Development Framework，为开发者提供服务开发的基本框架。
- Service Manager 管理本地服务，并负责与远端的 Service Manager 进行同步。
- Policy Manager 负责控制各个服务间的访问权限。
- Network Manager 负责网络通信管理，有可能会使用不同的通信协议。
- Startup Manager 定义服务间的依赖关系与启动顺序。
- Update Manager 负责服务的更新与升级。
- OS Abstraction Layer 负责抽象各个 OS 的差异。
实际实现过程中，还需要很多其他服务作为支撑，比如持久化、加解密等，以上架构图，只是为大家讲明原理。
在这个基础框架之上开发的服务，相互之间都是松耦合关系，通过我们上一篇中讲的，重新定义新的组合服务和流程服务，就能产生新的软件功能。不同芯片的差异会在操作系统层面屏蔽掉，而基础软件框架又屏蔽了操作系统的差异，在此架构下，即使更换新的 SOC，软件上的改动也会很小，也为硬件可升级也提供了软件基础。
二、SOA 参考实现
ROS与Adaptive AutoSAR 都是遵循 SOA 架构设计思想的一种操作系统中间件。为什么放在一起讲，是因为他们都有可能发展成为一种适用于车载环境的分布式通信与计算框架。
ROS（Robot Operating System）主要目标是为机器人研究和开发提供代码复用的支持。是一个分布式的进程（也就是“节点”）框架，这些进程被封装在易于被分享和发布的程序包和功能包中。
ROS 之前更多的用于学术研究，随着这几年人工智能和自动驾驶的发展，在很多自动驾驶的原型系统中都能够看到 ROS 的身影，百度 Apollo 最初也是使用了 ROS。在发展过程中，ROS原先架构设计上的缺陷也慢慢暴露出来，为了解决这些问题，2017年，采用新架构的 ROS2 问世。
ROS2 最大的改变是，取消Master中央节点，实现节点的分布式发现，发布/订阅，请求/响应通；底层基于DDS通信机制，支持多操作系统，包括Linux、windows、Mac、RTOS。要把 ROS2改造的完全适合车载，还有不少工作要做，之前提到的 APEX.AI公司，就是在做这个事情。
Classic AutoSAR 是开发 ECU 的主要标准 ，相关的介绍网上很多，就不多做介绍，Adaptive AutoSAR 2017年才发布第一个release 草案，主要用于高性能 SOC，运行在兼容 POSIX的操作系统之上，其也运用了 SOA 的架构设计思想。
从Adaptive AutoSAR 和 ROS 当中，能够看到德系与美系架构设计思想之间鲜明的差别。我的第一感受是，美系架构设计更加简洁、灵活，追求开源。而德国人喜欢把简单的问题复杂化，喜欢过度设计，搞很深的抽象层次，喜欢搞代码生成，喜欢强绑定 IDE，这可能与他们工程师思维的严谨性有关系，总之搞得看起来门槛特别高，相关的公司还可以卖标准，卖工具，赚的盆满钵满。
传统 ECU 开发中，Classic AutoSAR 依然会占主导地位， 德系公司是毫无疑问的主导者，但是我个人并不看好 Adaptive AutoSAR 的发展，主要有以下几点:
- 其标准的推进事实上已经落后于行业应用。
- 在自动驾驶的发展方面，中美是主导，德国已经无法实现他在传统汽车领域的霸主地位。
- 开源软件，成就了人工智能、自动驾驶相关行业的繁荣，德系软件商这种设置高门槛，通过标准挣钱的做法，很难继续下去，一套基础软件收费超过千万，没实力的会选择开源，有实力的也会自己去开发，大家顶多借鉴一下其设计思想。
三、DDS 与 SOME/IP
DDS(Data Distribution Service) 与SOME/IP(Scalable service-Oriented MiddlewarE over IP)，都是基于TCP/IP 实现的一种应用层通信协议，主要实现以下功能：
- 数据序列化
- 服务发现
- 数据的发布订阅机制
DDS 主要用于工业互联网、军工等领域，车载领域也有一些使用，比如 Nvidia 的 Drive AV 平台，底层通信就是基于 DDS，也是 ROS2的底层通信协议。SOME/IP是随着 AutoSAR 发展起来的，目前已经被纳入进了 AutoSAR 的标准当中，是 Adaptive AutoSAR 的底层通信协议。DDS 与 SOME/IP两者功能大同小异，SOME/IP 与 AutoSAR 生态兼容良好，但是 DDS 功能更强大，比如能够实现 QoS(Quality of Service,服务质量，是网络的一种安全机制, 是用来解决网络延迟和阻塞等问题的）。
在CAN总线中，通信过程是面向信号的，发送方周期性的发布信息，而不考虑接收者是否有需求。DDS与 SOME/IP则不同，收发双方是一种订阅/发布机制，它是在接收方有需求的时候才发送，优点在于总线上不会出现不必要的数据，从而降低负载。
DDS 与 SOME/IP的实现，是以以太网为基础的，为什么要用车载以太网，除了大家都知道的传输带宽问题，其实从软件的角度来讲，以太网最大的好处，在于它的网络模型层次比CAN要全，能够在此基础上定义比较复杂的应用层协议。
结语
本篇主要对SOA 软件框架进行了介绍，对常见的技术概念，车载以太网、SOME/IP、DDS、Adaptive AutoSAR、ROS2 等，梳理各自所处的技术层次与要解决的问题，阐述其与SOA的关系，下一篇主要聊聊一些非技术性的问题，比如行业现状，落地中实际会碰到的困难等。
