SOA（面向服务的架构）成为了“软件定义汽车”时代的热门话题，对于什么是SOA？为什么汽车要做SOA？传统车和智能车在架构上有哪些本质变化？业内的讨论很多，同时还出现部分企业盲目跟风开发的现象。但是目前对于SOA的内涵、价值潜力、发展路径等，普遍缺乏系统全面的认知，如果企业没有认清SOA的真正本质并做好布局，就着急下场，有可能事倍功半，达不到预期的效果。
其实，SOA是决定智能汽车产品体验的基础，也是智能汽车技术架构的演进方向。而开发SOA需要车企内部体系能力和外部生态的支撑，因此需要系统布局和规划。对于业内最关注的汽车SOA系列问题，盖斯特咨询研究团队在本文中进行了详细解析，不仅包括汽车SOA的概念和价值潜力分析，还有汽车SOA发展趋势研究，并为企业推进SOA落地提供相应的建议。
一、什么是架构？
SOA作为一种汽车架构，在讨论其之前，首先要对汽车的“架构”做一个概念界定。“架构”是基于“系统”衍生出来的概念，用于描述系统内组件之间的组织关系，汽车架构的本质就是系统内软、硬件的组织关系。
对于传统汽车，汽车架构主要指的是硬件主导的平台架构，即硬件模块化平台和决定硬件之间连接关系的EEA（电子电气架构），这是大家非常熟悉的架构。因为传统汽车由硬件主导功能的实现，车上的软件均是嵌入硬件，辅助硬件发挥性能，与硬件之间是强绑定关系。而且软件之间是相互独立和割裂的，所以没有“软件架构”的概念。
与传统汽车不同的是，智能汽车将依靠软件实现产品的差异化和快速迭代，这就要求软件与硬件必须解耦，将软件集中形成分层系统，并通过相互调用实现不同的、可迭代的功能组合，这些软件模块彼此连接就形成了“软件架构”。因此，智能汽车的“架构”不仅包括硬件架构EEA，还包括软件架构，并且软件架构占据主导地位。由软件架构定义硬件架构，硬件架构则变为基础支撑，为软件架构运行提供计算和通信能力的支撑。
二、智能汽车的架构内涵有什么变化？
从传统汽车架构向智能汽车架构的演变，本质上就是一个物理与逻辑的分离过程。从内涵角度来看，汽车架构可以分为物理视图与逻辑视图。物理视图通常以物理实体（硬件）为组件，以具体的线束或机械结构来连接实体组件；逻辑视图通常以“功能”等抽象概念为组件，以逻辑交互关系来连接抽象组件。
具体参见图1，传统汽车架构的内涵包括功能架构、电气架构和网络架构，三个架构统称为EEA。其中功能架构负责系统功能的定义与设计，电气架构负责系统及组件的供电配电，网络架构负责系统及组件的信息交互。由于传统汽车中软件嵌入硬件的特征，不仅功能架构的设计思路由硬件主导，电气架构和网络架构的逻辑视图与物理视图也是强绑定关系，所以逻辑层面的功能实现与物理实体保持高度一致。
在智能汽车中，随着软件与硬件的解耦，功能架构的设计由软件思维主导，并由软件负责实现，原本电气架构和网络架构中的能量管理策略、通信协议等逻辑关系，也将由与硬件解耦后的软件组件独立实现。而当所有的软件组件连接构成软件架构，就使汽车架构的逻辑视图与物理视图分离。也就是说，智能汽车的逻辑视图完全由软件实现，软件架构成为了产品开发的顶层设计。
为了方便表述，本文将智能汽车EEA的内涵定义在物理（硬件）层面，仅包括原有电气架构和网络架构的物理视图，从而与软件架构的概念进行区分。
汽车架构的演变意味着整车产品定义流程的变革，软件架构变得更加重要。软件架构将作为顶层设计，优先于硬件架构EEA进行设计，即所谓的软件先行。
传统汽车与智能汽车产品定义流程对比如图2所示。可以看出，智能汽车用户需求的分解和实现都将先在软件层面进行定义和开发，这是与传统汽车完全不同的。汽车产品定义由用硬件语言描述整体功能性能并拆解落实到各硬件系统及零部件上，变为用软件语言描述实现场景化用户体验的功能组合与性能需求。此外，EEA的设计也从只考虑硬件的物理连接关系转向“逻辑定义物理、硬件配合软件”的思路。
三、什么是SOA？
前面谈到，SOA是面向服务的架构，但是目前业内对于SOA的概念范围没有统一的界定，常有人将SOA、EEA、中间件等概念混为一谈。笔者认为，SOA作为一种软件架构设计理念，在智能汽车的七层架构图中（如图3所示），SOA的核心内涵是在中间件和应用软件之间构建一层支持实现软件灵活调用各功能硬件的软件架构。
第一，以“服务”为基本组成要素。“服务”的底层能力来源是智能汽车中功能硬件的抽象化、知识化，即将硬件抽象成为知识模型，并用软件语言表述出来，将其封装成为调用它就可控制相应硬件的软件包。业内普遍认为硬件知识化是实现SOA的前提。
第二，采用“面向服务”的通信方式来实现信息与数据交互。所谓“面向服务”即开发者只需通过“服务接口”了解该服务可提供的功能或性能，而不需要了解服务内部的具体实现方式，从而以一种更加灵活、可拓展的方式建立连接。
第三，通过“服务”分层排列组合的架构，为上层应用提供更灵活、更轻量化的软件开发基础。“服务”集合为上层应用开发者提供了一系列可供调用的基本能力，灵活的通信方式使得开发者能够灵活地创建服务之间的连接，不同的交互连接就可以实现不同的服务排列组合，从而创造出不同的应用。
四、SOA与其他技术要素之间是什么关系？
除SOA自身以外，软件定义汽车的其他技术要素也与SOA紧密关联。
其一，计算平台和EEA分别为SOA提供了计算与通信的硬件支撑。SOA对于软件的集中需要更高的计算能力来支撑其运行，同时对于硬件的频繁调用则需要更大的通信带宽来支撑其交互，因此需要计算平台和EEA的共同支撑。
其二，OS（操作系统）内核和中间件构成了SOA的软件运行环境。一方面通过管理调度软硬件资源、屏蔽底层软硬件差异，实现了不同硬件平台与服务的适配；另一方面定义了一套服务的交互规则，提供了一个供服务运行和开发的环境。
其三，应用软件是SOA的服务对象。开发者利用SDK（软件开发工具包）调用服务来开发应用软件，从而实现完整的场景化体验。
五、SOA具有哪些要素与特征？
SOA设计的关键在于标准化服务层的分层、分解、组合与适配。笔者以一个应用软件——车载地图导航APP为案例，来说明SOA的具体要素。
标准化服务层主要分为三层：最上层是业务服务层，例如导航、语音交互或地点推荐等；第二层是逻辑服务层，例如定位、语音播报、语音识别、路线规划等；最底层为原子服务，即最小的功能实现单元，主要来源有两个，一是硬件的知识化和抽象化，例如扬声器对应的声音播放服务、GPS对应的车辆位置信息；二是源自纯软件，例如云端数据库对应的地图或词库服务等。具体如图4所示。
业务服务层的服务，是通过排列组合逻辑服务层的服务，形成共性业务流程的服务，例如，导航服务就需要调用定位和路线规划服务；而逻辑服务层又通过调用原子服务作为输入或输出，同时进行逻辑判断或处理而形成服务，例如定位服务需要调用车辆位置信息服务和地图服务。
纵观整个标准化服务层，从上到下可以理解为共性部分的逐步拆解，从下到上可以理解为多元服务的个性化组合，这样的分层设计使SOA具备如下三大特征：
（1）灵活访问，上层服务或应用可以直接调用下层的所有服务，而不需要了解其具体实现原理；
（3）高内聚低耦合，每个原子服务封装的都是一个相对完整独立的功能，其运行与更新不依赖或者少依赖其他的同层级服务。
六、汽车SOA的价值与潜力
为什么汽车软件架构要走向SOA？实际上，在SOA应用于汽车领域之前，早已在互联网等实现软硬件充分解耦的领域内得到了广泛应用。因此，在汽车软硬解耦的趋势下，开发者基于技术惯性而采用SOA似乎是顺水推舟的，但是汽车行业并非简单地借用其他领域的开发理念。智能汽车的架构更加复杂，所以汽车研发人员，特别是车企的管理者和决策者，更应该站在战略高度思考，SOA真正会对用户和企业产生怎样的影响。
1.从用户体验视角来看，SOA能够及时满足用户需求并实现场景创新
传统汽车产品开发主要关注功能和性能，功能指产品能够完成的目标任务，性能是评价任务完成好坏的指标。而在智能化时代，用户体验成为产品开发的重心，其核心是产品能够结合场景需求为用户创造因时而异、因人而异的良好的综合感受，这就要求产品能够快速响应用户需求，实现全新的功能组合与性能优化。图5展现了不同汽车架构下的功能实现方式。
图5中的左侧是传统汽车架构，一个功能对应一套软硬件，各功能之间相互独立。这种分布式架构和嵌入式软件的组合方式，使产品升级难度大，所以以往的传统汽车产品一经推出，整体功能性能就是固化的，而且随着时间推移，整体功能或性能逐渐退化。
那么在汽车软硬解耦之后，如果继续延续传统架构的设计理念，虽然应用算法可以脱离硬件做到独立升级，但架构不变，仍是一个功能对应一套硬件和一个应用软件，各种软件之间没有打通，所以功能实现仍然是由“硬件主导、软件辅助”模式，即图5中间部分所示。这样设计虽然能够支持部分单一维度的性能提升（如制动特性、动力性等），但是无法支持功能的快速重构和拓展，那么带给用户的体验提升有限。
如果软硬解耦且采用SOA的架构设计（详见图5右侧），把整车硬件抽象为标准化服务，应用软件面向场景需求来调用服务，能够进行各种服务的排列组合，那么汽车的功能实现方式将变为“软件定义，硬件支撑”，而且整车功能可以跨域融合，各种服务也可以灵活组合。
也就是说，在软硬解耦和SOA架构设计中，软件可以独立于硬件进行迭代和在线优化，硬件也可以实现可插拔式替换或升级，同时支持软硬件进一步协同，从而更充分地释放出硬件的性能潜力。也意味着将全面支持智能汽车实现功能的快速重构与性能的快速迭代，并在数据驱动下实现场景的自我迭代创新，由此满足“因人而异、因时而异”的用户个性化体验需求。
当前传统汽车的硬件已呈现出同质化趋势，如果软件依旧面向特定硬件进行开发，且整车采用以往开发模式，必然导致汽车产品的功能固化和同质化。而SOA支持将产品开发的共性需求转化为服务中台能力，通过共享中台去灵活适配底层硬件与上层应用，实现硬件的货架式组合和应用的灵活多变，将使企业的产品开发效率显著提高、开发成本大幅降低。具体体现在以下五方面：
（1）加速应用迭代：在服务中台不变的情况下，应用软件可以灵活重组，大幅缩短产品迭代周期；
（2）降低应用开发门槛：硬件知识被封装成为原子服务，应用软件的开发者不需要深入掌握硬件技术，只要按服务所需调用相应的原子服务，硬件即可被调用来实现相应的功用；
（3）软件架构持续演进：各个原子服务之间是松耦合关系，因此可以持续地对软件架构进行拓展，接入新的服务或者更新优化已有服务；
（4）软件架构可迁移：在硬件实现标准化之后，接口统一，就可更换不同型号或版本的产品，甚至更换更好的硬件供应商，那么同一套SOA即可适配不同的车型和硬件平台；
（5）减少软硬件冗余：由于共性服务可以被高度复用，就可以减少大量的冗余的软硬件，不仅降低了系统的复杂度，还可大幅降低成本。
综上所述，SOA作为一种面向服务的架构设计理念，被智能汽车使用，绝对不是盲目迁移其他领域的技术和方法，而是切实从用户需求和企业需求思考而做的选择。企业只有真正认识到SOA的内涵、价值与潜力，才能设计好并用好SOA。
汽车企业若想实现SOA，必须经历三个步骤的开发：第一步是SOA开发设计，应确保面向服务的架构具备实现的可能；第二步是SOA的设计优化，确保SOA能够满足用户和企业开发的需求；第三步是SOA的生态构建，应确保能够吸引足够多的供应商和开发者参与构建此生态。如图6所示，其中每一步都需要技术能力和体系能力的强力支持,可汇总为以下四种能力或要素：
汽车SOA最终的目标是软件能够灵活调用不同硬件来实现功能组合，因此硬件知识化、软硬件有效解耦是前提条件。同时还需要计算平台、OS内核以及中间件等基础技术的支撑与配合。需要澄清的是，硬件知识化不等于硬件白盒化，车企不用必须掌握所有的硬件知识（Kown-how），只通过控制接口调用供应商提供的软件包也可以完成SOA的搭建。
解耦之后的软件和硬件必须有效协同，才能实现SOA通过软件调用充分发挥硬件性能。例如，服务的部署需要做好软件的性能与硬件的成本之间的平衡。另外，随着原子服务数量的增多，功能安全、信息安全等方面的机制设计也需要更加完善，中间件的通信调度性能要求也越高，这些均需要软硬协同能力的支撑。从体系角度看，一方面，软硬协同的设计优化依赖于开发团队的积累与迭代，因此长期稳定的软件团队是重要的组织人才支撑；另一方面，合理有效的产业分工是必要的生态支撑，毕竟一家车企不可能自主掌握汽车相关的所有技术，车企应与其重要合作伙伴建立起伴生式合作关系，具体细节将在下文中介绍。
软件架构具备灵活性和可拓展性，才能为汽车产品持续不断的成长迭代预留空间，SOA开发的关键在于前瞻性的架构设计。这对企业的架构设计能力提出很高的要求。尤其对总架构师的能力要求最高，其既要了解硬件的功能性能特征以定义硬件抽象；又要了解软件的开发方法，以合理定义接口与软件基础设施；还要了解用户需求，从而保障各方协同，使架构真正具备能够满足用户全维度需求的潜力。
SOA为汽车产品开发提供了一个全新的方法论，但最终能否创造出好的用户体验，还与生态构建密切相关，必须有足够多的供应商和开发者参与到生态之中。丰富多样的生态系统将用户体验创新渗透到汽车各个部件及用车的各个场景。
那么SOA怎样吸引更多参与者参与生态构建呢？一方面，SOA需要提供应用软件开发工具链来降低开发门槛，那些自动化、模块化、界面友好，以及便于应用开发者理解和使用的工具链，将更受开发者欢迎。例如图形化拖拽式编程工具；另一方面，需要设计标准的服务接口。如果接口标准在业界达成共识，得到功能生态内合作伙伴的广泛认可与支持，将确保SOA能够实现跨平台、跨车型兼容。
可以看出，SOA作为一种全新的架构，涉及到汽车上诸多的软硬件系统，往往需要从单个功能域开始逐渐向跨域融合，乃至整车打通发展，同时相关的生态也需要逐步导入。因此，汽车SOA的理想状态不可能一蹴而就，需要一个不断完善和丰富的过程。笔者预测，SOA的发展将分三个阶段，分别支撑实现不同的场景体验，具体如图7所示。
1.0阶段：SOA主要实现基于少量预设场景或模式的基础体验，这是目前大多数宣称已落地SOA的车企们所处的阶段。车企针对用户强感知的少量高频场景，进行碎片化的应用开发，例如小憩模式、露营模式、移动影音室等。在这一阶段中，汽车架构通常需要实现功能域集中的EEA以及单个功能域内的软硬解耦。需要注意的是，此阶段的SOA服务层通常只是几个预设场景对应固定的组合服务，因为尚未拆解成为原子服务，所以难以做到自由组合的服务。
2.0阶段：SOA主要实现有限数量的差异化场景体验，即基于丰富的原子服务集，通过场景库的升级，可创造更多的新场景，满足一定程度的个性化需求。此阶段的汽车将具备跨域融合、区域式集中的EEA，并与软件打通；同时SOA形成具有标准化接口的原子服务集；中间件和系统软件深度定制，并实现跨域打通。在此阶段，企业的开发重心落在拓展原子服务集和场景库上，目的是把服务层做厚、应用层做薄，通过原子服务的灵活组合来创造新场景、定义新体验。不过，此阶段受限于基础软硬件技术的限制，仍然无法实现完全的服务自由组合，只能满足一定程度的个性化需求，创造有限的场景。
3.0阶段：将实现无限的连续场景体验，这也是汽车SOA的理想形态。此阶段的汽车将具备中央集中式EEA和面向跨生态融合的全新物联网OS，从而支持应用可迁移、设备可互联、数据可互通，使汽车SOA的原子服务集能够不断丰富、架构可以灵活拓展。在此基础上，企业通过构建数据闭环实时采集用户、车辆和环境数据，驱动产品能够实现主动联想、主动服务、自我进化的“主动智能”，真正打造生态共创、用户共创、无缝场景衔接的极致体验。
目前宣布已实现SOA的大部分车企基本仍停留在上述的SOA 1.0阶段，只完成了座舱域和车身域中部分简单硬件功能的服务化，而真正允许排列组合的服务往往限于车门、车窗、座椅、多媒体和灯光等，所实现的场景大多属于休闲娱乐而非驾乘体验。SOA的开发现状如此，并非车企不想采用更先进的架构，而是普遍受制于以下两方面的问题：
汽车上大多数零部件及其控制软件都是供应商提供的，车企对于控制硬件的软件了解有限。虽然前文已经提及，从技术角度看，实现SOA并不要求车企全部掌握硬件的技术Know-how，但是从用户体验的角度看，如果车企对于硬件缺乏深入的理解，那么将其功能服务化的意义是有限的。例如，博世的iBooster（一款电子制动助力器）实际上已经为车企开放了调节其制动参数的接口，但行业内对此知之甚少，目前仅有特斯拉通过OTA（在线升级）了汽车的制动性能。也就是说，如果车企对于硬件的控制缺乏了解，那么在后续的软件优化迭代上仍将继续依赖供应商，并不能充分发挥SOA的灵活性。
在车企追求自主研发智能驾驶软件的背景下，智驾域的传感器往往软硬解耦的程度比较高，但是很少有车企真正把智驾传感器开放给SOA应用去调用。一个原因是目前中间件技术难以满足智驾传感器在大规模数据传输调度下的灵活性需求；另一个原因，由于不同功能域在安全方面的要求不同，如果开放智驾传感器接口，也给相关联的智驾域应用带来了潜在的安全风险。
也就是说，目前SOA开发存在的共性问题及需要突破的难点主要在企业的技术能力和体系能力支撑上。
未来智能汽车的产业生态一定“多要素协同、多主体协作”，而描述这种“协同”和“协作”关系的关键恰恰就是基于SOA的汽车软件架构平台。因为SOA向上支撑汽车应用生态，并与EEA共同向下适配汽车功能生态，从而定义了智能汽车的生态参与规则。笔者认为，围绕SOA的产业分工与生态建设是车企当前面临的最大挑战之一，下面为车企提供汽车SOA的落地建议。
首先，车企应成为SOA生态分工的主导者和操盘者。汽车产业要形成多要素协同、多主体协作的关系，前提必须有一个统一、清晰的规划，来为不同要素定义需求、为不同主体分配任务。车企作为汽车所有相关技术的最终集成者，必须承担起生态分工的主导者、操盘者的责任。车企通过自主掌握SOA和EEA的设计与开发，一方面促成产业的合理分工与生态的繁荣发展，另一方面也推动自身从制造型企业向生态型企业转型。汽车SOA的产业分工概览详见图8。
其次，车企应通过与供应商深度合作努力掌握软硬解耦的能力。前文提到，车企想要充分利用SOA实现软件的灵活升级，就要深入到硬件知识化的过程中。即使对于底盘、动力等专业性较高的硬件，也应通过与供应商共同解耦开发、共享知识产权的方式，自主掌握围绕该硬件的软件优化迭代。
最后，汽车SOA的真正落地离不开一个可持续迭代优化的软硬件平台，而大多数车企又难以做到全栈自研，因此车企应该将目标设置为打造一个“全栈可控”的软硬件平台。对于影响SOA关键性能的技术，例如SOA中间件、核心芯片等，车企至少应做到自主定义需求；对于自身能力无法主导的技术，例如OS内核、基础中间件等，应寻求伴生式合作伙伴，以建立长期稳定的合作关系。
笔者建议，车企应密切关注行业标准的进展情况，积极参与共性标准的制定。服务接口及其背后绑定的工具链对于汽车SOA开放生态的构建起到了关键作用，只有实现了接口的标准化，才能获得更多的生态支持。笔者判断，汽车SOA接口标准的发展会经历三个阶段：
由于当前行业标准不够成熟，且产业生态处于变革初期，各家车企为获得行业领先地位与话语权，都在探索制定自己的SOA接口标准并试图向全行业推广。但是目前各家车企的进度差距较小。
对于行业组织所做SOA技术标准，有中国汽车工业协会SDV工作组、中国基础软件生态委员会（AUTOSEMO）推出相应的标准。两个行业组织的标准化工作侧重点略有不同，反映出其核心成员对于未来汽车SOA生态格局的不同判断与价值主张。但是标准尚未得到广泛认可。
今后随着车企间在产品销量和盈利能力方面差距的扩大，行业标准背后对应的生态也将逐渐分化，那时SOA标准将开始逐渐融合。笔者预测将形成两类标准，一是巨头企业主导型接口标准。强势车企将通过自主定义、引入朋友圈合作伙伴参与开发的方式，形成巨头主导型标准；二是行业共创型接口标准。除强势车企之外，其他车企与供应链企业组成行业联盟，将逐渐向主流行业组织提出的标准看齐，形成行业共创型标准。
最终，各种标准之间将进一步融合，形成汽车SOA的开放标准(类似手机中的安卓)和半开放标准（类似苹果的IOS）。笔者判断，未来中国市场除2-3家拥有全栈自研能力的巨头企业坚持其半开放标准以外，其余车企最终都会采用统一的开放标准，共性服务的接口标准化基本成熟，而个性服务的接口设计可体现出差异化。
需要强调的是，SOA服务接口的标准化并不代表SOA架构的标准化，即使在统一的开放标准下，各车企仍然可以根据自身不同的目标客户和企业能力构建具有差异性的架构平台。
对于企业来说，今后对于已经成熟的行业接口标准，车企应全面兼容，以减少定制化开发成本；对于尚不成熟的部分，车企应根据自身能力积极探索接口标准的制定，并将自身实践经验反哺于行业标准。
笔者相信，汽车行业将很快接受并认同SOA这一新事物和新理念，并以“多要素协同、多主体协作”为主导，快速构建起SOA的架构平台和产业生态，向真正的“软件定义汽车”目标迈出坚实的一步。
七、实现汽车SOA需具备的能力和要素
八、汽车SOA的理想状态及实现路径
九、目前主流车企SOA开发中的共性问题
十、对车企SOA开发的落地建议
