 引言： 我眼中的SOA 前两篇发布后，大家的反响非常强烈，这里要感谢大家的支持，大家的认可是我不断前行的最大动力。如果说前几篇是开胃小菜，那么接下来，让我们正式进入主题，来说说《我眼中的SOA》。 在过去很长一段时间里，我们都在低调并有序的做着研发工作，并没有想过跟业内分享我们的经验，但随着设计的SOA架构日趋成熟，再加上业内同仁们貌似都在焦虑，就想着是不是可以跟业内其他同仁分享一些经验，说说自己的想法，安抚一下大家焦虑的心，当然如果我的文章有一定的指导作用，那自然是极好的。另外，我们既然已经做好要分享的打算，肯定也会虚心接受业内人士的审视，有不足的地方，欢迎大家一起探讨，如果有的内容引发激烈的讨论，那也是我喜闻乐见的。不管怎样我们会始终保持初心，砥砺前行，不断从实践中总结经验，不断推陈出新！ 02SOA对EEA的影响1).过去 对于汽车行业从业人员来说，电子电器开发V模型并不陌生，但理想很丰满，现实非常骨感，我们常常阻碍重重，常常折服于现实： （1）Tier1提供ECU，往往是平台件居多，功能已定，ECU需要哪些信号，其实已经确认； （2）OEM更侧重于提炼这些确定的信号，进行网络信号排布设计； （3）OEM高度依赖供应商，也造成了技术强势的Tier1几乎垄断了相关ECU，导致这方面OEM话语权极低； （4）基于目前现状，ECU的功能极为固定，行业变革也举步维艰。 在我有限的工作经验中，对Tier1做妥协那是时有发生，已经足够习惯和麻木，常常一个供应商的零部件无法满足系统设计需求，而需要整网跟着调整参数来实现，做好新的策略之后，还得跟其他零部件系统工程师，架构工程师、供应商等一系列人去协调解决方案的落地，如果遇到另外一个强势的Tier1不愿意配合，那这个时候就又得发挥我“强大”的设计能力，重新给这个不配合的Tier1做另一个解决方案，就这样解决方案叠加解决方案，到最后我自己都不知道设计了一个什么出来 2).现在 长久以来的反向开发流程，极大的压抑了主机厂的主动权，主机厂受控于平台化的零部件，功能无法突破，话语权不大，使得越来越多的主机厂开始想要变革，从最近的软件中心如雨后春笋就可以窥探一二，另一方面，软件定义汽车这个概念也越来越热门，大家的需求都非常迫切，都在寻求突破，我觉得这些都是极好的现象。 软件定义汽车变迁中，SOA理念将会发挥极为重要作用，它是这次变革的马前卒，可以让这场变革变得水到渠成。但如何引入SOA理念呢，大家是不是一头雾水？首当其冲的就是，在整车功能定义初期，SOA团队就必须要参与功能定义和梳理，协助并主导将整车功能划分为不同的子系统，在子系统的基础上，将所有功能划分为最小单元的功能模块，每个功能模块都必须做到独立不重叠，这样的功能模块才能是一个基础服务。有了基础服务之后，还要反向将子系统重新通过基础服务组合起来，这样子系统才会以组合服务而存在，这一系列操作下来，我们的服务API就基本定型，而服务的组合是一个可持续的过程，会让数据源源不断的产生价值。 3).未来 如图所示，是整车电子架构开发流程。从图中可知，SOA服务的定义是高度依赖于整车功能定义，只有整车划分好子系统，SOA服务设计才会启动，服务设计好后，才能解析出软硬件需求，整车拓扑才能真正意义上的软硬件解耦。  在整车架构和SOA服务设计上，我们已经做的很超前，可以说SOA几乎规划了整车所有功能，但仍然有一些挑战要留给未来解决，目前我们完全没有办法要求供应商将各个ECU的功能逻辑上移到域控制器中，这个问题，我们势单力薄，是需要整个行业的共同努力推进，主机厂和供应商缺一不可，未来行业格局会重新洗牌。 未来，各大主机厂的软件中心将发挥极其重要的作用 03SOA优势关于SOA优势，首先得益于以太网的快速发展，使得SOA通信(SOC)优势明显，另外SOA运用发布-订阅等机制，也促进了SOA发展。 1）以太网的带宽占据绝对优势，是直接碾压CAN等传统网络的，同时以太网的带宽会随着技术的不断发展，一直是持续精进的，这点传统网络已经不具备可比性； 2）从信息安全角度，CAN大部分采用MAC和SecOC等明文传输，加密等级并不高，而SOA通信可以借助强大的以太网加密方案，甚至可以不断扩展，安全方案是不断迭代的，目前也有很多主机厂专门成立信息安全团队，加固安全策略，而CAN信息安全很难扩展； 3）SOA服务通信模式不仅支持发送者-接收者模式，同时还支持客户端-服务器模式，而CAN通信，仅支持发送者-接收者模式，单纯的发送和接收，接收端均是被动接收，而SOC可以让Client主动请求控制或者状态数据，同时也支持订阅相关数据的发送。对于CAN来说，不同的通信对，对于同一个功能，是需要定义不同的报文和信号，而这几个相同功能的信号对应的值有时还不一致，运用SOA之后，就完全可以避免这种现场，不管有多少个Client，Server可以只有一个，同时不同的Client可以调用同一个服务接口； 4）SOA的发布-订阅机制以及服务功能独立不重叠，是和互联网SOA及微服务高度契合的，使得整车SOA服务通信和后端互联，为后续开发更多的运用提供无限可能，促进汽车智能化的发展； 5）SOA架构服务通信的最核心关键词就是动态，服务可以通过OTA动态的安装，服务间调用可以动态的创建连接。 如图所示，驾驶员意图分析服务作为一个新的服务，可在车主拿到车后，购买升级包，通过OTA推送该服务相关的APP，从云端将安装APP相关的Manifest发送到对应的控制器，仅升级该服务相关功能逻辑，而不需要改变任何其他的代码。另外，从图中可以看到，驾驶员意图分析服务会调用车内很多已有服务，进行数据融合分析，这种将分析结果反馈给云端，做边缘计算等算法，这里其他已有的服务不需要更改任何内容，因为服务在开发阶段就已经确定好哪些是可以动态被访问。  这时候，有人肯定会问，说了SOA服务可以动态，但真正有几个主机厂做到了动态，哈哈， 04我们的SOA 在上一篇<大家眼中的SOA>，我分析了国内外的主机厂SOA架构落地情况，这里也简单说下我们自己的。 我们在决策电子电器架构的时候，架构专家们更多的是敢为人先，没有任何的犹豫和惆怅，直接采用了Domain架构（一群有魄力的人 我们在实现SOA架构设计的时候，具备两个前提条件： 1）从SOA架构落地角度，如果一个主机厂想要实现SOA架构，那整车SOA架构团队，必须对整个实现链路具备绝对的话语权。在我们SOA架构实现的过程中，我们具备对车内外系统规划权力的，我们可以综合决策车端SOA节点的软件系统、架构及中间件，同时也能推动娱乐系统，尤其是SOA Gateway节点实现我们的策略，另外，如何和云端进行SOA交互，我们提供解决方案，我们甚至能够支配第三方交互系统，在整个链路中，我们能够整体去把控，而不单单是车内以太网系统设计，大家别看上面看似寥寥几句，其实我们经历了好多，搞定其中一种就已经极不易，要同时做到这几点，更是难上加难，所以我们的整车SOA架构，是大家共同努力的成果。 2）整车SOA架构师必须具备十项全能，要想做到软硬件解耦，就必须从整车功能定义初期就参与其中，辅助整车功能部署，不仅要整车功能了然于心，同时具备SOA架构设计能力，还要精通整车网络系统设计和整个工具链的开发，还要精通软件架构，写得了代码，调得了板子，深入到软件实现，另外架构出身，必须熟知整车开发流程，还得做得了项目管理，因此对SOA架构师的要求是极高的。 至于我们如何运用SOA，如何实现，因为涉及公司机密，这里就不深入探讨了，但我相信时间会给出答案！ 来源：公号 “汽车电子与软件” |
|
|
来自： xingqingzl > 《SOA》
。
。
目前在我们的SOA架构中，服务已经做到了动态创建连接，也就是说，服务可以被任意一个有访问权限的节点访问，而服务动态安装，我们也有借助OTA技术实现，进一步落地。
）。当然采用Domain架构还是Zonal架构，其实对SOA并没有本质的区别，因此物理架构的决策，更多的是考虑整车硬件环境和车辆实际情况，对于SOA，理论其实是一致的，SOA的设计经验完全可以平移。
