'域'见SOA

正如上次'域测未来'文章所提到，我们目前已经在开发基于新架构下车载电脑+区域控制器(VCP+ZONE)的产品；而在软件层面，也已经开始着手于研究整车功能的分配以及基于服务实现的软件架构。

原子服务

说到服务架构，关于原子服务的话题非常火，那么，什么是原子服务？原子服务有哪些特征？在系统层面如何拆分业务服务并且定义原子服务？原子服务对我们的软件又有什么影响呢？他和服务的关系又是什么呢？

我们先从服务的最小单元——原子服务讲起。原子服务的定义是：业务上最小粒度的一系列操作。原子服务的特点是松耦合，相对独立，且在可预见的范围内不会对其他原子服务造成影响。任何一项都划定了自己的业务范围；他们不用关心非自己业务范围是如何实现，对于调用其他原子服务，只需要考虑调用场景及返回结果如何处理即可。

举一个例子，先看看下面三句话：

• 现金存款是金融账户发生现金交易的收费服务行为。

• 信用卡还款是金融账户发生的，可能有银联参与的、信用卡的现金交易。

• 现金转账是金融账户与交易对手金融账户发生现金交易的收费服务行为。

这三句话中的，现金存款、信用卡还款和现金转账就是服务，现金交易就是原子服务，而金融账户、银联卡和信用卡则是服务的业务参与方，也是大家熟知的服务消费者和提供方。

通过这个例子，大家应该对原子服务已经有了一个基本的概念。那么，服务是由原子服务构成的，SOA是不是只是简单地由服务构成的呢？

1. SOA 架构的特性

答案很显然，要实现真正完整的 SOA 架构，只靠原子服务和服务是不够的。首先，我们看一下SOA的基础定义：

SOA基于服务的架构，继承了来自对象（指的是“面向对象的架构”）和构件设计的各种原则，例如，封装和自我包含等。那些保证服务的灵活性、松散耦合和复用能力的设计原则，对 SOA 架构来说同样是非常重要的。

关于服务的基本特性如下：

标准接口

服务提供方以统一的方式即标准的接口向消费者提供服务信息，比如车载服务软件一般会使用SOME/IP协议作为实现基础。

自主和模块化

服务封装了那些在业务上稳定、重复出现的活动和构件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。

松耦合

服务请求者可见的是服务的接口，其位置、实现技术、当前状态和私有数据等，对服务消费者而言是不可见的。

互操作性、兼容和策略声明

为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。例如，一个服务对安全性方面的要求；也可以是与业务有关的语义方面的内容，例如，需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。

而服务的最小颗粒度则是上文提到的不可拆分的原子服务。那原子服务的颗粒度是不是越小越好呢？答案肯定不是的，如何定义合理的原子服务，如何把握颗粒度的大小，在服务架构设计中至关重要。举个更形象的例子，原子服务就类似于电路设计中的电容和电阻，他们有着统一的标准，看似一样却又有着不同的封装，在不同的ECU控制器中组合成不同的应用电路，适当调整又能实现非常多的新的功能。

2. SOA架构的实现基础

有了理论基础，下一步就是看实现服务架构的必要条件。很多同学其实会问，为什么服务总是和以太网，DDS或SOME/IP绑定的呢？CAN网络上是否可以实现完整的SOA架构？

首先，以SOME/IP举例，因为SOME/IP的完整名称其实能回答上面的大多数问题，SOME/IP = Scalable service-Oriented MiddlewarE over IP。即“运行于IP之上的可伸缩的面向服务的中间件”。可见，并不是SOA必须和SOME/IP绑定，而是SOME/IP天生就是为了SOA架构而生。SOME/IP的精华在于“Middleware中间件”，这是一种独立的系统软件或服务程序，分布式应用软件可借助Middleware在不同的技术之间共享资源。分布式应用软件，在这里指的就是“服务”；不同的技术之间，在这里指的就是不同的平台或操作系统，比如Linux系统或AUTOSAR OS OSEK等。而Scalable Middleware，顾名思义，则是“可伸缩中间件”，指的是该中间件能够适配于不同的平台及操作系统，其支撑的平台可大可小。

简单来说，SOA是软件架构的一种设计理念；SOME/IP是一种将软件接口进行打包的打包方式，是一种中间件。而汽车行业通常所指的'以太网'是泛化之后的概念，涵盖了基于以太网技术所实现的各种相关技术手段，包括TCP/IP协议、DoIP协议、SOME/IP协议等。当然若通过其他非以太网的通信方式来实现SOA也是可行的，但通常大家不那么用。比如基于CAN总线的架构，由于其基础的架构和通信协议栈里不存在Middleware中间层的概念，所以要实现SOA的代价是非常巨大的。

3. SOA 应用的优势

正如大家所知，早期的车内嵌入式软件没有统一标准，基础软件和应用软件强耦合，不具可移植性；AUTOSAR Classic 的应用，对嵌入式基础软件的接口进行标准化，让应用开发者基于统一的基础软件接口进行应用开发。目前采用SOA软件服务架构的应用打通了车内的电子电气架构的壁垒，进一步对嵌入式应用软件的接口(即服务接口)进行了标准化，让APP开发者基于统一基础服务接口进行应用的迭代开发，隐藏了不同车型配置下应用软件的差异，真正做到了整车级软件接口的'标准'和'开放'。

• 平台架构升级更便于实现，通过服务设计的方式，能够有效降低架构升级带来的复杂度；同时，由于操作系统跨平台的难度大幅度降低，能够大幅提升用户体验，能够实现更为便捷的联网功能，实现不同平台间的各种APP共享等功能；

• 通过“服务Hub”区域控制器的引入，各种新功能能够灵活地与其他域功能，乃至互联网接口集成，而无需各个控制器各自进行信号到服务的转换；

• 一些相对独立的域开发能够打破界限，找到新的上限，例如自动驾驶功能不再是电子电气架构“孤岛”，通过区域控制器进行服务互通，可以轻松实现高清地图的创建、更新及路线预测等功能，便于实现车辆信息的上传及云端指令的下达；

4. SOA 的应用实例

正如上文提到的，一旦自动驾驶域不再成为电子电气孤岛，那么他的传感器、雷达、摄像头都能成为整车功能体验提升的利器。同时，由于区域控制器ZONE具有服务转换能力，ADAS计算中心也不需要拖着大量的传感器，雷达或摄像头一一连接，只需要简单从服务中间层直接发起调度请求即可。下面是一个潜在的开发实例：

第一阶段

也就是目前90%的E/E架构中所使用的平行式分布，由于ZONE在初期无法实现LVDS和摄像头视频的处理能力，所以暂时不会动AD的“孤岛”。但是其他的比如车身等相关的会通过区域控制器的服务转换能力，将信号打包成业务服务。

当然，ZONE区域控制器并不是简单的hub，在拆分和打包服务的同时，也会同步进行原子服务的开发和丰富，后续随着整车的FOTA更新，我们的原子服务越来越完善，同步也会有更多丰富的业务服务在互联互通的大环境下呈现给用户。

第二阶段

在这个阶段，随着区域下一代产品的发展，会在硬件上具备一些特殊接口的集成能力，例如上图中原来AD的专属武器如雷达或分布式摄像头等可以直接连接到区域控制器，这一步看上去仅仅是硬件兼容的一小步，但却是E/E架构升级的一大步。因为这意味着，环境感知服务的使用权被平等地交付到了每个域手中。

如果说过去的车身域是电子域，一旦环境感知信号的引入，会让车身域真正地进化出“眼睛”，灯光、雨刮、天窗、门锁、防盗不再是冷冰冰的电子功能，他们会成为整车人工智能的新入口，从电子域进化为智能域。一些过去只存在想象中的功能，例如视觉识别天气自动调整雨刮、根据周围行人和车辆自动调整灯光方向、单人使用车辆的时候仅解锁离车主最近的一扇门，这些功能都不再是幻想。

第三阶段

也是BOSCH体系定义的电子电气架构最终阶段，区域控制器会“返璞归真”，将所有特殊接口的能力打包成真正统一的虚拟服务接口，而这其中的关键条件则在于区域控制器是否具备了完整的原子服务，例如，一旦区域能够提供“视频解析”的原子服务，那么我们无需在区域上接入LVDS信号，直接通过千兆以太网将视频服务“原封不动”地传递到区域上，然后在区域控制器里会有对应的“解码器”，将这些信号解析、解码、重构、并打包成服务，以极低的延时和极高的保真率提供给不同的处理单元和控制模块。

而这个阶段一旦实现，接口的标准化和统一化会上升到新的高度，整车电子电气架构的成本也可以大幅度下降，主干网通过以太网传递服务，支路通过CAN/LIN等传统总线收集原子服务需要的信号流，所有的系统、软件、硬件有条不紊地在自己的服务领域中开发。未来，一辆既便宜、又智能的“温馨智能移动起居室”指日可待。