995
面向服务架构（SOA）是一个典型的从IT／互联网行业引入到汽车的软件技术，现在汽车行业围绕SOA有很多讨论和实践，主要集中于SOA本身的概念和在智能汽车中的实际应用，有些观点把SOA捧得很高，认为SOA是一劳永逸的方案，用了SOA就可以具备和特斯拉一较高下的软件能力，也有人觉得SOA比较虚，上了SOA用户也没什么直接的体验，不见得能多卖几辆车。
毫无疑问，新技术的引入总是伴随着争议，主要还是专业背景的不同，站在汽车电子，通信或者电气工程师的角度去看待一个软件问题，总会有各种怀疑，也有很多与SOA无关的需求和问题，想让SOA来解决，这些都跨专业的理解偏差。而汽车软件，毕竟还是软件，不是信号、电子或芯片，很多疑问还得回到软件的领域，才能正确理解SOA的概念以及它能解决的问题。
第一个问题
智能汽车到底需不需要SOA？这里需要先看一下智能驾驶时代的汽车架构和汽车软件的实际需求：
传统的整车架构，尤其是电子和电气部分，主要就是分布式ECU，嵌入式软件和现场总线级别的通信网络，传统的EEA很大程度上是一套硬件集成方案（当然复杂度比手机高出几个量级），如果没有特斯拉，可能这套成熟的体系还能用上很多年，没有人考虑过把IT行业的软硬件架构直接套用到汽车上，但现在这事被特斯拉做成了，而且类似科技公司背景的入局者和模仿者越来越多，各类汽车软件也大幅增加。对于传统OEM，根据自己的专业背景，在这一轮技术升级中，基本都能看到域控制器、新型传感器、车载以太网、操作系统、APP和各种算法等新技术，但如何把它们有效地集成在一起，做成用户体验卓越的智能产品，还能保证成本可控，是一个比较大的挑战。新硬件好学，拆来看看，大概也能明白对手怎么做的，但是软件和代码，还有基于这些软件的运维方式和盈利模式，对于传统汽车行业来说，是所谓的虚拟经济和“灵魂”，既看不太懂也有内部变革的阻力。所以OEM需要的是在现有EEA基础上，想办法把这些五花八门的新技术用更快更有效的方式集成到一起，而且采用成本和风险可控的迭代方式，而不是推倒现有架构和供应链重来。这个目标从软件的角度来看，其实就是要求OEM要具备整车软件的集成能力。
但大型系统软件的集成正是传统EEA缺失的能力，因为现有零部件都是软硬件耦合的，传统车内嵌入式软件的集成基本是零部件和CAN网络调通即可，由于CAN是基于广播的，所以各个零部件软件之间实际并没有直接对接。而随着新的非嵌入式的软件越来越多进入到车内，相互之间会通过基于以太网的软件接口(API)来直接传输数据，API调用和CAN信号广播完全是两回事，API设计是软件问题不是通信问题，同时新的汽车软件会有独立的生命周期线，为了保证让大量的新软件能通过以太网络在一起协同工作，OEM必须引入全新的独立于硬件的大型软件集成能力，相当于需要一套单独的整车软件架构。
这套软件架构的基本作用是：
能集成整车各个ECU、DCU(域控制器)、ZCU(区域控制器)、分布式网关/中央网关等的软件，而软件集成最重要的环节就是，设计一套统一的软件接口和数据传输格式，当然还有安全、性能等一系列规范。有了这套整车软件集成方案，OEM才能让各个供应商或服务商的软件按事先约定好的统一标准来传输数据。否则就会演变成各供应商自行定义接口名称和参数，输出各式各样的数据，安全标准也不一致，最终还得由OEM来适配和对接，成百上千的新软件集成到车内，接口联调和适配的复杂度和工作量是OEM无法承受的，这会比CAN矩阵设计高出几个量级。
那么现在汽车行业选择了面向服务架构(SOA)来作为汽车的整车软件架构，主要是为了解决各个零部件间的数据交换和通信。这个方向对不对？我们可以从IT行业设计SOA的初衷来分析。
广义的面向服务架构，或者广义的“服务”本身，是从单机软件到网络软件都一直存在的最基本的概念。传统汽车的ECU嵌入式软件，都算是单机软件，功能界面数据处理基本都在同一个硬件上，没有前台界面+后台服务的概念，但在IT/软件行业，从局域网到广域网、互联网、物联网等，软件早已完成了分层架构，从最早局域网软件的Client/Server(C/S)架构，到web时代的B/S架构，最近十几年又迭代出SOA、微服务、无服务架构等等，服务这个概念始终存在且保持进化，贯穿了整个软件发展。简单来讲，软件的复杂业务代码都是运行在所谓的“服务器”上，这些服务器都是远程部署在机房的高性能计算机，运行在这些服务器上的软件被统称为“后台服务”，而运行在用户终端上的，比如PC、手机或智能硬件的软件，都叫做“前台界面”，其实就是汽车行业经常提的HMI。这种把交互界面和业务模块(算法)分离的主要原因是终端算力有限，同时为了避免重复开发可共用的复杂模块，才把这类模块都放到后台服务器上去做成“服务”来共享使用。
所以汽车软件从嵌入式逐步升级为大型系统软件的趋势下，只要有网络，那么基于服务的架构是不可避免的。高算力平台或域控制器就是车内的服务器，这些服务器把各种汽车零部件的控制权以软件接口的方式，提供给车内或车外以太网的其他软件使用。
但狭义上的SOA (Service-Oriented Architecture), 尤其是汽车行业目前多从IBM借鉴的那套SOA和企业总线理念，是不是必须的呢？并不是，而且IBM的SOA解决方案已经是过时的技术了，原因有很多，总的来说，和商业软件公司的没落有关系。
在IT时代(1995年-2005年间) 是商业软件公司的天下，IBM、Oracle、微软及SAP这样的IT软件公司达到巅峰，那时候互联网商业模式和技术才萌芽，当时的新技术和软件理念都是商业软件公司引领的，特点就是代码封闭，按License收费，数据不在线等等，最关键的是商业模式很封闭，如果想在一个企业内部使用IBM的方案来实现业务数字化，需要很复杂的咨询、采购、实施流程，无论软件还是硬件，成本都很高，好处是一站式服务，也就是汽车行业习惯的“交钥匙”模式，当时还衍生出带资质认证的各类细分领域的工程师，需要各种考核，否则没法落地这些公司的软件，这类商业软件公司把闭源生态玩到了极致(和现在的汽车行业的软件工具商，Autosar联盟搞的这套闭环很类似)。
从2000年之后，互联网公司崛起，最早也是用这些商业公司的软件，发现成本太高，技术也无法支持海量用户(商业软件多是企业用户，用户数量从几万几十万的情况居多，像互联网这样动辄几千万上亿的用户量，传统的商业软件架构支持不了，这类公司的升级思路是scale up），谷歌亚马逊率先开始大规模创新架构，采用开源技术和分布式计算(通过scale out提供扩展性)，到后来国内兴起的去IOE浪潮（很重要的一次技术浪潮，改变了整个软件业的方向），基本就把所有的商业软件从产品软件栈中剔除了，采用了大量开源方案和二次开发来自研。
2005年开始，传统IT公司就开始明显走下坡路，IBM针对企业IT提出的这套狭义上的“SOA”架构，与它的企业总线ESB一起，变得鲜有人问津。而过去十几年，大多数软件架构都基本是采用互联网公司创建的软件架构，实际也是基于服务的，比如用的最多的“微服务”，是广义的面向服务架构的最新迭代，也算是狭义的SOA的实际“量产”案例，所以广义的SOA一直在使用并迭代。而服务这个概念过于普及和基础，导致大多数科技行业的开发人员基本都不提这事了。（有一点需要注意的是，从之前的去IOE浪潮来看，汽车行业现在这些商业工具提供商，是有可能被替代的，尤其是特斯拉和一些科技公司造车，都基本不会使用Autosar这样学习门槛高，价格贵，封闭体系，还得等工具商缓慢迭代的软件方案。）
上面讲了面向服务架构的来龙去脉，就比较容易澄清SOA的用处，面向服务架构是在IT行业软硬件运行环境都很成熟的基础上出现的架构，用于软件模块之间分层，对于部分公用的，消耗计算资源的代码，被抽象成服务，单独运行在专门的服务器上，被其他软件模块共享使用。十几年前SOA的提出显然没有考虑过汽车行业现在还需要先实现车载以太网通信，域控制器和操作系统升级的情况。如果说IT行业搞SOA是从0到1，那么汽车行业搞SOA就是从-1到0，再从0到1，因为还得先解决硬件升级的问题，-1到0就是OEM先得补齐的硬件功课（当然自动驾驶或者座舱应用本来也需要升级这些硬件），这里面又涉及到成本和长期ROI，以及传统OEM如何看待SOA的价值问题。从整车成本的角度来看，SOA会给OEM每次新车换代节省一定比例的零部件开发费，但是在使用了SOA的第二代车开始才会节省，而第一代使用SOA的汽车，又要升级网络又要引入中间件，各种新增成本，OEM未必能买单，所以如果对软件架构的长期价值理解不清楚，这个总账算起来很有难度。而从技术上看，OEM其实需要在短时间内同时完成通信网络升级、硬件升级、软件升级(生态建立,盈利模式)的三步走，这三步可能在其他行业都经历了十年以上的时间，所以汽车行业面临的挑战要复杂不少。
第二个问题
SOA本身能解决哪些问题，不能解决哪些问题，到底能带来什么好处？
SOA的范围包括：
设计和实现全车各个零部件的软件（用以太网通信的软件）的接口定义和数据格式。需要注意的是，软件接口的定义，从来没有强制的标准，虽然有所谓的六大接口设计原则，也有Restful接口风格之类的规范，但都不是非实现不可，实际需由软件架构师根据业务情况和经验来设计，这点对于传统OEM和非软件开发人员来说尤其难受，因为接口定义没有行业标准可参考，参考互联网行业，各公司的系统架构和接口基本都是自己的技术骨干设计的，汽车行业几乎没有这样的人，因为原来嵌入式软件并不需要这类架构师，传统汽车需要的CAN通信矩阵实际是通信或者电子专业的工程师来负责，他们几乎没有软件开发经验，而IT行业的软件工程师又不懂整车架构，所以找到对汽车网络和软件都精通的经验丰富的软件团队才是OEM需要解决的首要问题。
全车的数据安全规则，统一的加密算法，密钥管理机制，权限管理体系等
备份和冗余机制：如果是中心化的架构，中间件要考虑很多负载均衡，故障切换的功能，如果是去中心化的架构，需要考虑各节点的选举机制和资源占用
CAN信号转化为服务API的数据报文
SOA最重要的作用：
SOA能保证车内和车外所有使用以太网通信的软件采用同一套数据格式进行数据交换，避免大量的软件接口适配和数据不兼容，给OEM和供应商双方都省去大量的集成成本。长期来看，SOA会是未来汽车开放平台的基础，如果有一天特斯拉开放和苹果类似的应用商店，面向服务架构必然是最底层的技术基础。
SOA不包含：
车载以太网升级（以太网通信是SOA的前置条件，但本身这是两件事），以及车内网络管理，比如网络休眠唤醒、功耗节能等等，这些属于网络和操作系统范畴。
TSN以及网络延时解决方案，这些和SOA没有直接联系。另外还有方案还希望通过SOA去定义不同软件的通信优先级，保证部分高安全等级功能的信道通畅，思路是好的，但是实际应用很难实现，具体原因可以参考十年前基础运营商和通信巨头想搞的SDN（软件定义网络），最后都不了了之。
以太网应用层协议的选择：这也只是SOA的前置条件，SOA是针对软件分层的架构，和使用的通信协议无直接关系，要实施SOA确实要先选一个以太网应用层协议，但是选哪个并不影响SOA的实现，不管是DDS、MQTT、SOME/IP还是HTTP、Socket、SOAP，都可以实现SOA，如何选择还是主要看SOA中间件的具体功能是否强大和车载以太网的成本情况，（目前很多工具商和供应商在推SOME/IP，但实际上SOME/IP无论从协议定义和测试情况来看，并没有比其他协议更有特别的优势，对应的软件甚至问题更多，同时汽车行业的厂商绝大多数并不太清楚一个软件中间件应该具备哪些功能才能量产，花了大量时间去讨论应用层协议）其实争论哪个以太网应用层协议更好，对于有经验的软件开发者来说，就像争论C++, JAVA, PHP谁是最好的编程语言一样没什么意义。应用软件功能是否强大，性能是否最优，从来都取决于开发者，而非开发语言，更非通信协议。应用层协议是上层协议，目的是为最终的应用场景服务，并不会像底层通信协议一样，是一个非此即彼的选择，只要能让应用层软件提供最终的用户价值，上层协议的差别并不大，而且很容易切换。
自动驾驶中间件的功能，自动驾驶有专门用于传感器数据传输和融合的中间件ROS，ROS也是面向服务架构的，但由于设计的初衷是机器人使用，机器人就一个大脑，所以ROS更适合单域控制，并不适合解决跨域通信问题，加上全车应用DDS的成本和资源消耗，短期内ROS还很难从ADAS/AD域拓展到整车。
另外OEM需要的软硬件解耦能力，须由操作系统和SOA中间件开发商共同提供，操作系统可以通过驱动模型、硬件抽象和设备树等方式把常用的标准零部件转成系统接口，但各OEM的零部件很多都是非标准化的，操作系统并没自带这些零部件系统接口，所以还需要SOA这样的架构来补充这部分零部件的协议转化和为应用层提供API。
在实际SOA项目落地过程中，会有各种车载网络和硬件的限制条件，尤其是SOA整体性能问题，会牵涉到车内现有网络和ECU的性能和负载瓶颈，需要OEM和零部件厂商共同解决，都是有不小的挑战。另外SOA虽然是后台架构，但也会被质疑能带来什么用户体验，这涉及到应用层开发，确实需要一些新的APP或新场景来验证SOA的作用。
总结
汽车行业的工程师多年来习惯了先找行业标准，工具，然后才是研发，制造，最后再用标准来测试验证的闭环，这套流程是典型的制造行业的模式，凡事都得先看看有没有行业标准和成熟工具，上下游各公司都用同一套标准，最后以最小的成本和最低的风险把汽车造出来，流程很稳定，但这种思维模式会让工程师过分依赖标准和工具，失去真正的研发和创新能力，尤其是整车架构中很多标准和协议都是欧美日定义的，大量的资金都投给了国外的工具商和外资Tier-1，给到工程团队的研发费用反而很少。现在这套闭环被特斯拉带头用更先进的理念和技术打破了，还造出了跨代领先的产品，证明了开源软件在车内的可行性。而且新的智能软件并不像硬件或者嵌入式软件需要那么多规范，传统汽车软件开发类似于做填空题，题干都被固定了，我们只能做最没有技术含量的部分，而智能软件都是根据用户需求自行开发，更像是写作文，就一个题目，剩下的自由发挥。这个变化对于新一代智能汽车或者新一代的汽车软件供应商，都是研发能力升级的最佳机会，也有充分的商业动机去完成新一代核心软件和工具的国产化。
作者：Luke Chen
快控科技 CEO
