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