那么现在汽车行业选择了面向服务架构(SOA)来作为汽车的整车软件架构，主要是为了解决各个零部件间的数据交换和通信。这个方向对不对？我们可以从IT行业设计SOA的初衷来分析。
但狭义上的SOA(Service-OrientedArchitecture),尤其是汽车行业目前多从IBM借鉴的那套SOA和企业总线理念，是不是必须的呢？并不是，而且IBM的SOA解决方案已经是过时的技术了，原因有很多，总的来说，和商业软件公司的没落有关系。
2005年开始，传统IT公司就开始明显走下坡路，IBM针对企业IT提出的这套狭义上的“SOA”架构，与它的企业总线ESB一起，变得鲜有人问津。而过去十几年，大多数软件架构都基本是采用互联网公司创建的软件架构，实际也是基于服务的，比如用的最多的“微服务”，是广义的面向服务架构的最新迭代，也算是狭义的SOA的实际“量产”案例，所以广义的SOA一直在使用并迭代。而服务这个概念过于普及和基础，导致大多数科技行业的开发人员基本都不提这事了。（有一点需要注意的是，从之前的去IOE浪潮来看，汽车行业现在这些商业工具提供商，是有可能被替代的，尤其是特斯拉和一些科技公司造车，都基本不会使用Autosar这样学习门槛高，价格贵，封闭体系，还得等工具商缓慢迭代的软件方案。）
SOA本身能解决哪些问题，不能解决哪些问题，到底能带来什么好处？
SOA的范围包括：
CAN信号转化为服务API的数据报文
SOA最重要的作用：
SOA能保证车内和车外所有使用以太网通信的软件采用同一套数据格式进行数据交换，避免大量的软件接口适配和数据不兼容，给OEM和供应商双方都省去大量的集成成本。长期来看，SOA会是未来汽车开放平台的基础，如果有一天特斯拉开放和苹果类似的应用商店，面向服务架构必然是最底层的技术基础。
SOA不包含：
车载以太网升级（以太网通信是SOA的前置条件，但本身这是两件事），以及车内网络管理，比如网络休眠唤醒、功耗节能等等，这些属于网络和操作系统范畴。
另外OEM需要的软硬件解耦能力，须由操作系统和SOA中间件开发商共同提供，操作系统可以通过驱动模型、硬件抽象和设备树等方式把常用的标准零部件转成系统接口，但各OEM的零部件很多都是非标准化的，操作系统并没自带这些零部件系统接口，所以还需要SOA这样的架构来补充这部分零部件的协议转化和为应用层提供API。
在实际SOA项目落地过程中，会有各种车载网络和硬件的限制条件，尤其是SOA整体性能问题，会牵涉到车内现有网络和ECU的性能和负载瓶颈，需要OEM和零部件厂商共同解决，都是有不小的挑战。另外SOA虽然是后台架构，但也会被质疑能带来什么用户体验，这涉及到应用层开发，确实需要一些新的APP或新场景来验证SOA的作用。
汽车行业的工程师多年来习惯了先找行业标准，工具，然后才是研发，制造，最后再用标准来测试验证的闭环，这套流程是典型的制造行业的模式，凡事都得先看看有没有行业标准和成熟工具，上下游各公司都用同一套标准，最后以最小的成本和最低的风险把汽车造出来，流程很稳定，但这种思维模式会让工程师过分依赖标准和工具，失去真正的研发和创新能力，尤其是整车架构中很多标准和协议都是欧美日定义的，大量的资金都投给了国外的工具商和外资Tier-1，给到工程团队的研发费用反而很少。现在这套闭环被特斯拉带头用更先进的理念和技术打破了，还造出了跨代领先的产品，证明了开源软件在车内的可行性。而且新的智能软件并不像硬件或者嵌入式软件需要那么多规范，传统汽车软件开发类似于做填空题，题干都被固定了，我们只能做最没有技术含量的部分，而智能软件都是根据用户需求自行开发，更像是写作文，就一个题目，剩下的自由发挥。这个变化对于新一代智能汽车或者新一代的汽车软件供应商，都是研发能力升级的最佳机会，也有充分的商业动机去完成新一代核心软件和工具的国产化。
作者：LukeChen
快控科技CEO
佐思汽车研究：致力于汽车、TMT、新能源(特别是新能源汽车、智能汽车、车联网)领域的产业研究、专项调研、战略规划和投资咨询服务。