【上汽零束SOA】云管端一体化SOA软件平台系列介绍之二：数字架构篇

本篇为SOA服务软件平台系列的第二篇，零小束希望与各位分享SOA服务平台与整车数字架构的关系以及建立服务架构的设计方法。

一、SOA服务平台在整车数字架构中的应用

1.1  问题与思考

“下一代”电子电气架构是每家OEM都重点关注的项目，它如同一栋大楼的主结构，对建筑物的安全稳定、功能实用、节能环保、以及对外观造型的支撑有决定性的作用。电子电气架构的概念从总线引入汽车开始就不断更新和演化，如今一套完整的整车数字架构所考虑的内容除了传统的拓扑、网络、线束与电气分配、逻辑功能分配，还需结合整车的功能/信息安全架构、数据架构、计算架构，以及实现通讯架构与软件架构的协同，功能架构与服务架构的协同，车内服务与云端服务的协同。

那么针对SOA软件平台的问题来了，它是如何服务于整车数字架构的呢？两者是否有依赖关系呢？SOA软件平台与业内热议的域集中、区域架构又是否有关联呢？

尽管“Next Gen”架构对于每家OEM都不一样，但是参照业内公认的对于架构的演化预测，多数OEM会选择分步走的策略，分阶段进行架构设计。为了简明，本文暂以两类典型架构进行说明。

1.2 Domain Centralized Architecture

域集中架构在连接上由功能域控制器，分别通过子网与各功能域内ECU相连接，而域控制器之间则修建通讯“高速公路”，通过高带宽的骨干网络相连。拓扑结构只是架构的表象，而表象背后的核心特征是功能逻辑被抽象上移至功能域控制器中，缺少这个步骤的域集中架构是没有灵魂的（此步骤也是汽车OEM向智能设备制造商转变所要突破的重点之一，本文不多赘述）。那么回归本文的主题SOA软件平台，域集中架构对于SOA是否有依赖呢？仅从实现投产的角度来说可能仁者见仁，但从平台建设的角度，二者结合就如同齐天大圣与定海神针的相互成就，既可用来协助建立数字架构平台，又可通过SOA软件平台快速而持续地提供更新的用户体验，结论则是显而易见的。

OEM从原本分布式架构过渡到域集中架构的目的有哪些呢？

1)主导功能应用层软件，更好更快的实现迭代和优化用户体验，SOP后低成本持续更新；

2)域内功能集中控制，简化功能间协同的复杂度，解耦域间通讯；

3)在域控制器之间建立高带宽骨干网络，兼容高带宽数据流共享；

4)FOTA软件迭代是智能汽车实现软件持续生长的根本，简化软件迭代复杂度和周期；

SOA软件服务平台是否可以协助这些目标呢？

1)以服务为元素，搭建Application内外部的动态调用关系，平台之上的创新应用可大量减少非必要控制器的软件变更，从而快速更新用户体验；

2)通过服务设计解耦域间通讯，在跨域平台上通过一套标准中间件解决方案，提供标准化的服务接口；

3)服务标准化是利用高带宽骨干网络的重要手段，能够将更多数据和接口通过服务提供出来，实现跨域融合（复杂的智能场景等功能则更易实现）；

4)建立在软件架构基础上的服务平台在需要软件更新时，往往只要识别出需要动态部署的新服务，或者调整调用服务平台的应用，低耦合度的软件平台可以尽可能减少迭代复杂度；

1.3Vehicle Centralized and Zonal Architecture

整车集中和区域架构在连接上是通过分布在车内各物理区域的区域网关/控制器将车内物理I/O分别就近连接和控制，形成整车数字系统的“手”和“脚”，然后通过骨干网络与系统中的“大脑”控制单元进行连接。连接关系同样只是表象，而核心价值在于将车内软件（运算）和硬件解耦，彻底实现软件独立“生长”（或者说算力架构可以迭代，共享算力变成了可能），而硬件同样可以独立“生长”（跨车型平台，或者在车辆生命周期内为用户提供升级服务，而这些在传统架构中实现的成本是不可控的）。

OEM将“辛苦”建立的域集中架构又过渡到区域架构，究竟又是为了什么呢？

1)彻底将每个车型平台都可能调整或升级的硬件I/O从域控制器上解耦出来，避免域控制器因为I/O硬件升级而不得不迭代的问题，并让平台具备向中央计算电脑过渡的前提；

2)区域内直接控制（驱动、连接、供电等等），大大降低Physical Architecture成本，分布控制对于能耗的管控也更加智能

3)软件/算力架构可独立“生长”，与硬件平台解耦

4)硬件I/O平台可独立“生长”或“切换”，与软件架构解耦