随着汽车智能化、网联化、共享化的趋势，终端用户对车辆功能的预期也悄然发生着改变，汽车在实现高等级自动驾驶/辅助驾驶功能的同时，也更趋向于提升用户体验，例如满足快速的功能更新和升级，可以提供个性化、人性化、差异化的功能与服务等。

面向服务的软件架构(Service-Oriented Architecture)正为未来的车辆软件服务提供良好的解决方案。不同于传统汽车电子电气架构中面向信号的架构，面向服务的软件架构(SOA)通过标准化的服务接口，松耦合的服务机制以及可组合扩展的服务特性，结合未来以高性能计算平台——域控制器——为核心的集中化电子电气架构，将成为未来汽车领域“软件驱动创新”的技术基础。

第一部分：面向服务架构(SOA)的汽车软件及其开发方法

一. 为什么要引入SOA汽车软件?

SOA是一种软件架构，同时也是一种软件设计方法和理念，在IT领域已有数十年的应用经验。SOA具备”松耦合”、”接口标准可访问”和”易于扩展”等特点，使得开发人员能以最小的软件变更应对迭代多变的客户需求。

在智能网联汽车中，大量的功能需要控制器（ECU）间的协调工作来实现，当前ECU 间基于信号(Signal-Oriented)的点对点通讯将会变得异常复杂，且不具备灵活性和扩展性，微小的功能改动都会引起整车通讯矩阵的改动(图1)。

因此，联合电子将SOA引入到当前汽车软件设计中(图2)，车辆功能被以面向服务的设计理念架构为不同的服务组件，有别于面向信号的传统架构，SOA中的每个服务都具有唯一且独立互不影响的身份标识(ID)，并通过服务中间件(Service Middleware)完成自身的发布，对其他服务的订阅以及与其他服务的通讯工作。由此，SOA良好的解决了传统架构中因个别功能增减/变更而导致整个通讯矩阵与路由矩阵都要变更的问题。更进一步，由于其”接口标准可访问”的特性，服务组件的部署不再依赖于具体特定的操作系统和编程语言，在一定程度上实现了组件的”软硬分离”。

图1 面向信号的架构(Signal-Oriented Architecture)

图2 面向服务的架构(Service-Oriented Architecture)

二. 如何有效的开发SOA汽车软件？

对于汽车行业而言，SOA是一套新引入的技术，需要一套有效的流程、方法和工具，用以解决如下三个问题：1) 如何分析和设计服务架构，2) 如何建模和记录服务架构，3)如何部署和实现面向服务的软件。

如何分析和设计面向服务的架构?

“分析和设计服务架构”的过程是从客户需求到SOA软件架构产出的分析过程，相对于传统汽车软件开发采用的基于功能分解的面向过程分析方法，“用例驱动的开发方法”和“面向服务架构的设计方法”是SOA软件架构开发的两个主要特点。

用例(Use Case)驱动的开发方法(图3)指从用户的角度而非开发人员的角度考虑功能需求和系统实现，重视从系统外部观察对系统的使用。由用例驱动的开发活动，可以建立需求和系统功能之间清晰的追溯关系，更好的应对智能网联产品需求的快速迭代更新。

面向服务的分析方法(图4)则是以业务为中心，在由用例分析得到系统功能需求的基础上，对业务逻辑进行抽象和封装，从业务角度寻找候选服务（Service Candidate），从架构角度强调服务的重用性(reusable)、自主性(autonomous)以及组合扩展性(composable)特点，充分发挥SOA设计理念的优势，而不是仅仅作为技术实现方式。

图3 用例驱动的开发方法

图4 面向服务的分析方法

如何建模和记录面向服务的架构?

标准化的建模语言和统一化的文档结构，对提升架构的开发质量、实现架构内容的有效传递具有重要作用。SysML语言和Arc42模板可以作为SOA软件架构的标准语言和文档结构模板。

系统建模语言SysML（System Modeling Language）是由统一建模语言UML（Unified Modeling Language）扩展而来的标准化系统建模语言，能够准确表达系统及其组件的需求、行为、结构和属性。Rhapsody软件支持SysML建模，并提供了自动化功能，提高建模效率，同时保证与用例的追溯关系。Arc42明确定义了架构文档的结构，通过统一化的文档，提升开发团队中的信息传递效率和质量。

如下图5显示，联合电子使用SysML语言，Rhapsody建模工具以及Arc42架构模板进行应用服务架构的开发。

图5 SysML语言，Rhapsody工具和ARC42开发模板

如何部署和实现面向服务的软件

“部署和实现面向服务架构的软件”的过程是以SOA软件架构为设计输入，最终开发实现出软件产品的工作过程(图6)。主要包括 1)对服务接口行为的开发和实现，完成服务接口与服务主体逻辑的绑定；2) 针对目标运行环境，完成对服务接口参数，服务主体运行参数的配置；3)服务接口与应用程序策略逻辑的集成编译。

AUTOSAR Adaptive 组件封装了SOA软件底层的通讯细节(包括SOME/IP协议，IPC等)，同时提供代理(Proxy)-骨架(Skeleton)模型，该模型以C++面向对象语言描述，方便上层应用开发人员调用标准服务接口(API)进行开发。Application Design Model是该模型另一种可配置的呈现，开发人员通过使用相应的配置工具对Application Design Model进行描述和配置，即可实现基于SOA服务架构的软件落地和部署。联合电子使用AUTOSAR Adaptive组件完成SOA服务架构软件的开发(图7)：

图6 部署和实现面向服务的软件

图7 应用软件设计模型

三. SOA汽车软件创新平台

联合电子开发的域控制器XCU ，提供了部署SOA汽车软件的平台。在硬件方面，XCU具备高算力处理器芯片和多路车规级以太网通道；在软件方面，XCU搭载POSIX操作系统和AUTOSAR Adaptive平台。

根据SOA软件开发方法，可从两个切入点开展SOA汽车软件平台的开发。

1)自下至上，从车辆基础功能/信号出发，将已有的应用功能逻辑/信号(eg:车辆车速信息)抽象或封装成服务组件，这类组件被称为基础服务层(Basic/Platform ServiceLayer)组件，具有最高的可复用性和可组合性，这些组件将为上层(业务服务层Business Service Layer)的服务组件提供最基础的支持。

2)自上而下，从整车业务逻辑和用例出发，结合各领域的核心业务知识，设计业务服务层(Business Service Layer)的服务组件；同时，遵循服务组件的复用性和自主性等原则，向下设计规划基础服务层(Basic/Platform Service Layer)的服务组件(图8)。

图8 基于域控制器(XCU)的SOA服务架构

四. SOA架构的核心要素与优势

SOA作为一种面向服务的架构，是一种设计思想和方法论。在SOA架构中，服务是最核心的抽象手段和系统最基础的描述单元。

每个服务组件具备独立的功能，且可被复用；服务组件之间的接口遵循统一标准，可互相访问，可组合扩展。业务过程则是带有状态和服务调度策略的服务组件的组合与扩展(图1)。

通过SOA架构，可整合规划OEM在不同操作系统，硬件平台上(控制器)上的业务功能，实现对功能的快速迭代和重组，应对灵活多变的智能网联趋势下的业务需求。

图9：SOA架构模型

结合未来汽车域导向型电子电气架构(Domain-Oriented)和区域导向型电子电气架构(Zone-Oriented)，应用SOA架构可实现业务过程(功能)的快速迭代与灵活重组，为智能网联趋势下的软件个性化与创新需求提供了良好的平台性解决方案。SOA架构应用于汽车新电子电气架构下的优势(图2):

车辆功能软件实现软硬分离

由于服务组件接口“标准可访问”，且描述方式独立于硬件平台和操作系统，因此组件功能可脱离硬件平台任意部署移动，对于算力有要求的复杂功能组件可向具备高带宽大算力的域控制器移动。

车辆功能可被大范围复用

一些使用频度很高且基础的功能可作为基础服务组件先被开发，由于服务组件的独立性以及接口的标准可访问，基础服务开发完成后可向服务中间件注册，并供所有电子电气架构中的控制器订阅使用。

车辆功能在SOP后可新增(扩展)

“小”的基础服务可组合成为“大”服务，“大”服务可进一步组合扩展并最终构建出新的业务过程，实现OEM的业务目标。结合OTA技术，用户可在车辆使用期限里，订阅一个类似，“预测性能量管理”的新功能并安装于域控制器上，新功能的业务逻辑依赖于一些已有的服务组件(eg:预测性能量管理依赖于能量管理策略，地图预测信息等基础服务)。

图10 新汽车电子电气架构中的SOA架构应用

第二部分：面向服务架构（SOA）的汽车软件分析和设计

面向服务架构的开发过程从整体上可以概括为6个步骤，分别是：面向服务分析、面向服务设计、服务开发、服务测试、服务部署和服务权限管理，如图11所示。其中，分析和设计面向服务的架构是开发SOA软件的开端，也是判断系统是否基于SOA架构的最重要且核心的环节。

联合电子对分析和设计面向服务架构汽车软件的具体流程与方法进行了探索，将面向服务的分析分解为系统需求分析、系统功能分析、候选服务分析三个子步骤，将面向服务的设计分解为系统架构设计和软件架构设计两个子步骤。经过架构师的良好分析，车辆功能(业务逻辑/业务过程)将结合实际实现情况，按不同业务领域完成解耦，并分解得到候选服务组件。后续，经过详细且不断迭代的设计，在候选服务的基础上，最终会产出面向服务(SOA)的软件架构。

图11 面向服务的分析与设计是服务架构开发的核心环节

接下来本文将围绕这5个子步骤对面向服务的分析与设计过程进行介绍。

系统需求分析

如图12所示，整个SOA架构模型分为业务过程层，服务接口层和应用程序层三部分。SOA业务过程层专注于业务逻辑的分析；服务接口层聚焦于候选服务的设计和分析；应用程序层则体现面向服务的系统架构和软件架构设计。

系统需求分析聚焦SOA架构的最上层——业务层。概括来说，需求分析指的是设计和充分理解在用户具体使用场景下的真实业务过程，为后续抽象和封装服务提供充足的语境信息。

图12 需求分析聚焦SOA架构业务过程层

系统功能分析

如图13所示，系统功能分析搭建起了SOA架构的业务层和服务层之间的桥梁，其过程就是从第一步系统需求分析的产物——业务过程和系统用例，向服务过渡的过程，目的是得出构成候选服务的服务操作（operation）。系统功能分析具体可描述为：设计用例的实现场景步骤，对系统用例逐个进行分析细化，描述系统如何与参与者（actor）一起实现每个用例，从而得到系统与参与者、与外部系统的界限及信息交互，最终得出对系统的功能要求，这些功能要求直接作为候选服务操作（business service operation candidates）。

图13 系统功能分析：从业务过程到服务

候选服务分析

候选服务分析聚焦SOA架构的中间层——服务接口层。候选服务分析的目的是对业务逻辑进行抽象和封装，从业务角度寻找候选服务（Service Candidate）。值得强调的是，分析候选服务需要跳出特定功能开发，从架构角度强调业务的重用性(reusable)、自主性(autonomous)以及组合扩展性(composable)等特点，特别考虑候选服务在企业业务范围内潜在的重用可能，充分发挥SOA设计理念的优势，而不是仅仅作为技术实现方式(图14)。

图14 候选服务分析聚焦SOA架构的服务接口层

系统架构设计

系统架构设计的目的是设计和得到服务到架构要素的映射，以及要素间服务调用关系。下图中蓝色小圆圈代表分析得到的服务，通过系统架构设计，被映射至不同的架构要素( Platform A~C)(图15)。在这里，架构要素对应汽车上搭载不同控制器平台(Platform)。

图15 系统架构设计：服务与系统要素的映射

软件架构设计

软件架构设计的目的是设计和得到服务（service）到服务组件（Service Component）的映射关系，过程与系统架构的设计过程类似，但需要将关注点转移到控制器内部。

软件架构的设计受到诸多因素的限制(以太网通讯Port口资源，客户具体用例场景的迭代变更等等)。总体设计思想上，高内聚，低耦合仍是设计的通用原则和架构评价的关键指标。额外需要强调的，应对智能网联软件需求迭代多变的特性，在SOA服务架构的设计中，还需强调重用性和扩展性，充分的灵活度才能以最小的软件变更应对大量的需求输入。

“分析和设计面向服务的架构”、“实现和部署面向服务的软件”是有效开发SOA汽车软件的关键环节，“分析和设计服务架构”的过程是从客户用例场景/需求到SOA软件架构产出的分析过程。

联合电子认为，相对于传统汽车软件开发采用的基于功能分解的面向过程的分析方法，“用例驱动的开发方法”和“面向服务架构的设计方法”是SOA软件架构开发的两个主要特点。

联合电子具备相关项目经验，可以帮助具备业务逻辑的厂商(OEM/第三方)完成基于服务的用例分析和架构设计工作，并最终协助客户输出面向服务的软件架构。

第三部分：面向服务架构（SOA）的汽车软件实现和部署

根据SOA架构层级模型(图16)，业务逻辑经过面向服务架构(SOA)的软件分析和设计过程后，被分解为单个服务并绑定相应的可执行软件单元。以服务软件架构为输入，汽车服务软件的实现和部署工作主要在服务组件层(Service Components)完成(图1红色箭头)。

图 16 SOA 层级架构模型

01 满足 SOA 架构的服务组件架构 (Service-Component-Architecture)

针对服务组件，SOA定义了服务组件的架构模型(SCA)(图17)，在SCA的框架下，服务组件内部被分为业务逻辑(Service)与基础设施逻辑(Interface和Message)两部分，并互相解耦：

服务软件单元(Service)：业务/功能逻辑，不关心操作系统和编程语言，可由熟悉业务逻辑的相关方开发

接口(Interface)：决定对外提供哪些服务以及自身服务依赖哪些服务，不关心操作系统和编程语言，可由SOA架构设计方完成开发和部署

消息(Message)：接口数据的通讯链路/环境绑定，不关心操作系统和编程语言，可由SOA架构设计方完成开发和部署

整个服务组件层的工作是对服务组件进行规范型描述，描述内容主要包含两个部分:

服务组件架构模型SCA的配置描述

服务组件内部业务逻辑和基础设施逻辑的集成

图17 SOA服务组件架构模型(SCA)

02 服务组件架构SCA的配置描述

通过SCA架构模型，每个服务软件单元(Service)以标准的接口形式(Interface)向消费方提供服务内容，以统一的通讯协议传递序列化消息(Message)。对于SOA架构设计和应用人员，需要通过工具配置SCA架构模型中的参数，使其与服务管理组件一同实现SOA软件的部署和运作。

图18 SCA架构模型中的配置信息

SCA架构模型中的主要元素分为“服务接口”和“服务实现”两大类。其中，“服务接口描述”包含服务软件单元(Services)，组件接口(Interface)和消息通讯(Message)；“服务实现”则包括通讯协议绑定(Binding)和服务端口信息等(Endpoint)(图18)。

WebService的SCA架构模型配置描述

以IT行业SOA封装使用较为广泛的WebService为例，其对SCA架构模型的描述遵从如下标准协议:

表1 SCA架构模型中的配置信息

在IBM公司发布的SOA系统解决方案- 企业服务总线(Enterprise-Service-Bus)中提供了WebSphere Integration Developer开发环境，该环境支持配置生成符合WSDL规范的服务组件描述文档。

汽车软件的SCA架构模型配置描述

在汽车软件领域，当前，联合电子采用AUTOSAR Adaptive组织提供的模型描述规范。AUTOSAR Adaptive组织对SCA架构模型的描述遵循如下标准:

表2 SCA架构模型中的配置信息

03 汽车SOA软件的实现方案

如上文所述，汽车软件领域，联合电子遵循AUTOSAR Adaptive标准来完成SOA中间件的部署和应用，AUTOSAR Adaptive组件采用经典的代理(Proxy)-框架(Skeleton)模式来完成SCA架构模型的描述(如图19)。

图19 Proxy(stub)/Skeleton架构模式

这种模式将原本直接交互的调用者(Client)与被调用者(Server)分离，由代理负责传递信息来完成调用，client和server不需要处理通信层详细信息。同时，AUTOSAR Adaptive厂商基于C++语言具体实现代理-框架模式，确保应用服务开发人员可以灵活配置自定义的服务接口，并结合对应工具生成SCA架构模型代码(.cpp/.cc)和配置文件(.json)。具体的，这些代码：

封装了SOME-IP协议栈和底层通讯细节(Middleware Transport Layer)

提供了相应的服务虚接口(virtual function)

通过1)，服务组件开发人员不必再关心服务Message对应的协议如何实现；通过2)，服务组件开发人员基于C++的语言特性，可继承(inherit)虚接口并覆写(override)虚接口的具体实现(函数体)。该机制保证了“基础设施逻辑”和“业务(功能)逻辑”的解耦，服务内部业务逻辑的改动不影响服务组件向外的接口提供。

04 SOA服务组件实现和部署的具体步骤

SOA服务组件“实现和部署”的整个过程以面向服务(SOA)的软件架构为输入，内容上除完成第二章提到的“基础设施逻辑”配置工作外，还需将业务(功能)逻辑与基础设施逻辑集成，最终编译成可执行的服务组件单元(Service Component)(图20)。

图20 服务组件单元(Service Component)

如第一章中对服务组件的SCA描述，整体服务组件(Service Component)由服务单元(Service)提供的“业务逻辑”和适配目标系统环境相关的“基础设施逻辑”两部分组成。在开发过程中，这两部分是解耦的，可同时进行的，且软件形态是灵活的。

服务单元(Service)的逻辑可以是源码或被封装为SDK形式，且不关心具体的编程语言；基础设施逻辑 (Interface和Message) 则以C++的形态编码，与服务管理中间件一起确保服务的动态响应性和服务自身的可扩展性，其软件形态同样可以是源码或SDK形式提供。

在流程上方法论上，”实现和部署”工作主要分为服务组件接口设计，服务组件集成实现和安装部署三个步骤：

组件接口设计阶段: 联合电子编写arxml完成对服务组件SCA中“基础设施逻辑”的配置开发，并经由AUTOSAR Adaptive中间件供应商提供的代码框架和生成器(Generator)，最终得到相关的配置文件(.json)和源代码(.cc/.cpp)；对“服务单元逻辑”，联合电子可同步基于建模工具进行开发；

组件集成实现阶段: 联合电子编写APP框架，完成“服务单元逻辑”与“基础设施逻辑”的软件集成工作；

组件安装部署阶段: 联合电子编写编译和安装脚本，完成源码的编译链接和可执行文件(App)的安装，同时，对APP安装部署权限和系统环境做适配调整。

“分析和设计面向服务的架构”、“实现和部署面向服务的软件”是有效开发SOA汽车软件的关键环节，“实现和部署面向服务软件”的过程是SOA软件可以“落地”不可或缺的环节

第四部：面向服务架构（SOA）的应用

1. 原子服务

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

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

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

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

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

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

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

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

2. SOA 架构的特性

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

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

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

标准接口

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

自主和模块化

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

松耦合

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

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

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

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

3. 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的代价是非常巨大的。

4. SOA 应用的优势

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

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

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

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

5. SOA 的应用实例

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

第一阶段

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

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

第二阶段

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

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

第三阶段

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

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