第一个问题
智能汽车到底需不须要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
