《浅谈整车SOA架构》：我眼中的SOA.docVIP

《浅谈整车SOA架构》第3篇：我眼中的SOA 我眼中的SOA 前两篇发布后，大家的反响非常强烈，这里要感谢大家的支持，大家的认可是我不断前行的最大动力。如果说前几篇是开胃小菜，那么接下来，让我们正式进入主题，来说说《我眼中的SOA》。 在过去很长一段时间里，我们都在低调并有序的做着研发工作，并没有想过跟业内分享我们的经验，但随着设计的SOA架构日趋成熟，再加上业内同仁们貌似都在焦虑，就想着是不是可以跟业内其他同仁分享一些经验，说说自己的想法，安抚一下大家焦虑的心，当然如果我的文章有一定的指导作用，那自然是极好的。另外，我们既然已经做好要分享的打算，肯定也会虚心接受业内人士的审视，有不足的地方，欢迎大家一起探讨，如果有的内容引发激烈的讨论，那也是我喜闻乐见的。不管怎样我们会始终保持初心，砥砺前行，不断从实践中总结经验，不断推陈出新！ 01 SOA概念 什么是SOA：一种粗粒度小、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。 SOA是一种架构理念，不单单指某一种基于SOA理念的协议，所以千万别把SOA等同于SOME/IP协议，SOME/IP只是SOA的众多选择之一，而SOA本身的协议选择有很多，我相信未来车内能够支持的SOA协议，会越来越多，主机厂可以发挥的空间会越来越大。 SOA和AUTOSAR：正如上面所说，SOME/IP是SOA协议之一，而SOME/IP是专门用于汽车行业，SOME/IP通过AUTOSAR规范来具体定义SOME/IP协议细节，Classic Platform AUTOSAR(CP)和Adaptive Platform AUTOSAR(AP)都可以运用SOME/IP协议来通信，而AUTOSAR Foundation规范则定义了CP和AP必须同时遵循的SOME/IP需求。虽然SOME/IP定义于AUTOSAR，但SOME/IP并不仅仅用于AUTOSAR，目前GENIVI提供的一种SOME/IP实现，称为vSOME/IP，是开源代码，可以做到很好的适配AUTOSAR需求。 对于SOME/IP协议，想要AUTOSAR系统和GENIVI系统能够正常通信，必须遵循同一套规范，所以在整车SOME/IP通信中，不管是不是AUTOSAR系统，SOME/IP相关实现必须依据AUTOSAR规范开发，这才是AUTOSAR的意义所在，而不是强制ECU必须所有软件模块都遵循AUTOSAR，这样反而被局限。 对于AUTOSAR规范，大家要理性的看待，合理的利用，适当的发挥：《AUTOSAR的生与死》一文中，指出了一堆AUTOSAR弊端，但却恰恰忽视了最现实的问题，没有AUTOSAR，不同系统如何协作通信，当前并没有一种规范可以取代AUTOSAR，哪怕有了可以和AUTOSAR相媲美的规范，谁又能保证不会出现第二个AUTOSAR呢，所以规范就只是一个参考，说到底还是取决于你怎么用。你如果只把它当做参考，那它只是你的一个工具而已，但如果你完全指着AUTOSAR，而没有自己的思考，自己的见解，那只能被AUTOSAR拖着走，早晚有崩的时候。 02 ? SOA对EEA的影响 1).过去 对于汽车行业从业人员来说，电子电器开发V模型并不陌生，但理想很丰满，现实非常骨感，我们常常阻碍重重，常常折服于现实： （1）Tier1提供ECU，往往是平台件居多，功能已定，ECU需要哪些信号，其实已经确认； （2）OEM更侧重于提炼这些确定的信号，进行网络信号排布设计； （3）OEM高度依赖供应商，也造成了技术强势的Tier1几乎垄断了相关ECU，导致这方面OEM话语权极低； （4）基于目前现状，ECU的功能极为固定，行业变革也举步维艰。 在我有限的工作经验中，对Tier1做妥协那是时有发生，已经足够习惯和麻木，常常一个供应商的零部件无法满足系统设计需求，而需要整网跟着调整参数来实现，做好新的策略之后，还得跟其他零部件系统工程师，架构工程师、供应商等一系列人去协调解决方案的落地，如果遇到另外一个强势的Tier1不愿意配合，那这个时候就又得发挥我“强大”的设计能力，重新给这个不配合的Tier1做另一个解决方案，就这样解决方案叠加解决方案，到最后我自己都不知道设计了一个什么出来。 2).现在 长久以来的反向开发流程，极大的压抑了主机厂的主动权，主机厂受控于平台化的零部件，功能无法突破，话语权不大，使得越来越多的主机厂开始想要变革，从最近的软件中心如雨后春笋就可以窥探一二，另一方面，软件定义汽车这个概念也越来越热门，大家的需求都非常迫切，都在寻求突破，我觉得这些都是极好的现象。 软件定义汽车变迁中，SOA理念将会发挥极为重要作用，它是这次变革的马前卒，可以让这场变革变得水到渠成。但如何引入SOA理念呢，大家是不是一头雾水？首当其冲