《浅谈整车SOA架构》第4篇:整车SOA系统设计
引言:
01
1)架构是什么
首先,SOA架构师在整车项目开发过程中,承担着整车SOA系统设计的职责,而系统设计过程,需秉承一套可以被分享,可以被评审,可以被记录,可以被流程化的设计思路,这就是“架构”,它是一套如何以服务的形式组织整车功能的 决策 集合。
架构师要确保设计好的架构风格可以指导整车功能的组织和划分,并确保整个功能架构在汽车生命周期中可持续进化,此外架构设计需要关注功能性,复用性,性能,兼容性,经济和技术限制,商业等,而系统的具体功能信号和算法并不在架构的职责范围内,这些必须留给专业的功能架构团队。
2)为什么需要SOA架构
和任何其他复杂架构一样,整车软件必须建立在坚实的基础上,如果不考虑关键方案,不识别出常见问题,或者没有意识到好的决策能够带来长期受益,这些都将使整车应用架构面临高风险,整车功能变得不稳定,不易扩展,也很难适应不断变化的用户需求。
当前汽车发展面临着两大难题,如下图,一个是不断增加的汽车数量,预计到2025年,网联汽车可达到4.7亿量级,这其中8百万辆将是自动驾驶汽车,由此可见,云端互联和自动驾驶需求急剧增加。
自动驾驶需求,导致汽车内软件代码到达几亿行,整车软件代码出现井喷式的增长,这样整车相当于20台个人电脑以每小时超过25G的数据在运行,而传统CAN等网络极大的限制了汽车行业的发展,因此以太网作为车内主干网是必然趋势;云端互联需求,使汽车成为数字世界的一部分成为可能,这样智能汽车可以像手机一样,即使销售后,依然可以持续升级性能,整车功能可以持续创新,让汽车成为一种服务平台,这才是软件定义汽车的真正价值。
当前整车电子电器架构,功能不集中,分散到不同ECU,使得功能和信号交互异常复杂,代码和逻辑冗余相当严重,而互联网思路不断涌入汽车行业,汽车电子电器开发也必须要拥抱变革,并尽快适应变革,与时俱进。
SOA架构理念,来源于软件技术,在互联网行业已经应用了很多年,是一种非常成熟的技术,从全球角度,中国互联网的水平已经可以说全球领先,而汽车引入SOA理念,是一种全新的尝试,如果在汽车内落地好SOA,同样能够让中国汽车弯道超车,赶超世界先进车企。另一方面,各大互联网企业蜂拥而上进入汽车行业,也验证SOA引入汽车行业的必然,说明SOA的发展趋势是对的,也是大有可为,毕竟资本都是趋利。
为了和云端能够很好的互联,车端软件、通信、信息安全等必须能和云端环境很好的协同,实现一整套车云生态环境,因此车端采用可扩展到云端的基于服务通信SOA是最有效的落地方案,而设计SOA架构时需要先关注以下问题:
-
应用需要如何应用到产品中?
-
用户需要如何使用这些应用?
-
服务如何做到松耦合,以允许复用性和扩展性?
-
性能属性需求有哪些?
-
考虑现在或者未来的架构发展趋势,需要提前兼顾未来发展趋势,如果不兼容未来架构,那这个架构就不具复用性,从而违背SOA架构设计初衷。
3)SOA架构的目标是什么
架构是产品需求和技术需求之间的一座桥梁,必须准确理解产品需求,理解应用用例,并将对于产品需求的理解通过最合适的方法,落实到软件上,以实现这些应用用例,因此架构需要识别影响应用结构的需求。好的设计是在软硬件技术发生变革,用户需求发送变化的情况下,依然能够保持架构的灵活性。那什么是好的设计呢?好的设计是可以公开系统结构,隐藏实现的详细信息,可以实现所有用例方案,并协调解决和落实各个利益相关方的关注点,兼顾功能和质量需求,并保持架构可持续的被复用,同时能够支持不断进化。
4)架构设计方法
首先,SOA架构设计首先应该识别整车都有哪些类型的应用,以及理解这些应用将如何实施,只有这样才能将架构理念落实到实际的架构风格和技术,最后还得关注一些全局设置,比如场景,性能属性,需求,限制,安全等。
比较抽象的是架构风格和性能属性,其中架构风格就是一整套设计原则和规则,比如设定需要集成的系统所用到的服务类型,服务交互关系,以及交互限制,又如基于规划策略,协议栈限制,资源限制等待选择合适的技术和协议,简言之,架构风格就是限定如何集成系统。性能属性,主要涉及认证、安全,和易维护性,重点关注架构中涉及的严重问题,并和需求进行综合评估和权衡,同时性能属性要和功能系统完全独立,从架构角度来说,实施性能属性规划可以极大的提升系统性能。
架构设计原则大致有包含:
-
从最上 层分解整车和功能,将系统划分为不同的子系统
-
整车功能完全独立不重叠,一个子系统只承担特定的一个功能特性,同时一个功能特性也只能在一个子系统中,不能在其他系统中重复定义
-
子系统通过接口来交互从而不关心其他子系统的内部功能逻辑
-
在功能细节不明确,或者功能不断进化的情况下,需要避免过早的进行大量设计工作
-
服务进行分层管理,将相同类型的服务打包到相同的服务层,决不允许将不同类型的服务放到同一逻辑层,尽可能做到服务组合,而非迭代继承服务
-
在严格服务分层下,服务之间不能跨层调用,同时要保持服务的独立性
-
不同服务分层中,避免数据类型格式的转换,比如频繁的物理值和信号值之间转换是必须要避免的
-
性能属性代码必须尽可能的从应用功能逻辑代码中抽离,如果将两种代码混杂在一起,会导致架构难以扩展和维护,性能属性代码的更新,需要同步修正功能逻辑代码
-
建模分析和可视化仿真工具分析:提前识别风险和漏洞,尽可能简化软件开发
整车开发过程中,SOA架构师需要参与的阶段如下:
1)电子电器架构
SOA架构依托于车载以太网,以太网拓扑是所有SOA设计工作的前提条件,必须在项目启动时,首先确保是可落地SOA的电子电器架构,因此SOA架构师需要结合产品部门提供的产品特性,梳理出整车以太网架构的需求,从架构关注点、功能需求、兼容性和发展趋势等方方面面出发,和产品,功能架构、平台软件等相关同事共同确认电子电器架构,确定以太网主控芯片、通道数量、带宽等信息,现阶段,讨论最多的是域控制器架构或者Zonal架构,如下图所示,至于如何选择,这边就不介绍了,毕竟不同的OEM有自己的不同考量,关注点区别很大,但如果OEM暂时还没有域控制器架构或者Zonal架构的需求,也可以在座舱域率先落地局部SOA服务设计。
域控架构图(来自网络)
Zonal架构图(来自网络)
2)协议栈和软件架构
当整车SOA架构通信协议完成既定的以太网拓扑和选定的SOA服务协议,SOA架构师需要参与协议栈和软件架构的设计,通信关注点主要有:
-
整车 软件架构设计
-
通信协议相关软件选择
-
是否需要AUTOSAR系统
-
工具选择
SOA架构师主导的过程如下:
1)SOA协议选择
作为整车SOA策略设计者,需要根据实际应用和条件选定合适的SOA服务通信协议,制定初步的服务通道策略,当下可供选择的SOC(Service-Oriented Communication)协议有SOME/IP,DDS,MQTT,HTTP,协议区别如下:
当然协议的选择,很大程度上依赖供应商能够提供哪些SOC协议,这其中涉及很多妥协,因此最好在零部件定点前完成协议选择,以便针对所选择的SOC协议,对供应商提出一些具体的需求,同时作为定点供应商的依据。
2)SOA架构设计
SOA架构设计是整车开发的中间过程,需要遵循严格的输入输出模式,形成流程,确保刷选出所有影响架构的因素,提前规避架构风险和漏洞,同时在重新设计架构时,设计流程可以循环使用。
-
Use case和应用场景
-
功能需求描述文档
-
非功能需求,如性能,安全,详细软件架构等文档
-
以太网系统设计
-
CAN网络拓扑和系统设计
-
云端资源
-
SOA架 构重新定义后的use case文档
-
SOA架构重新定义后的功能描述文档
-
SOA架构策略规范
-
服务定义文档
-
服务开发文档
架构设计步骤,每个步骤都可以分开细化成更详细的过程,并支持不断迭代,最终产生最优化的应用架构:
I)梳理整车功能:将整车功能按照SOA架构思路,设计成独立可复用的服务,重构功能体系II)规划SOA架构:根据梳理后的整车功能,设计详细的SOA架构,设置性能属性,比如服务升级策略、安全策略、异常处理III)服务定义:定义不同类型的服务、服务接口、数据类型等IV)服务矩阵和Arxml设计:针对不同服务协议,定义服务之间的交互和通信行为,创建服务通信模型V)服务验证和仿真:服务矩阵和Arxml释放前,需要保证正确性,因此必须进行服务验证和仿真
在整个SOA架构设计过程中,SOA架构师需要将自己的设计思路,设计成果不断的同步和分享给相关方,从5个不同角度——4+1,不断评审和修正SOA架构:
-
从功能逻辑角度,梳 理后的SOA服务架构提供真实的软件框架
-
从过程角度,从服务设计到服务落地
-
从物理角度,将对应的服务和服务架构分配到对应的硬件ECU中
-
从开发角度,矩阵可明确指 导开发,同时Arxml可以大大缩短服务开发时间
-
对服务进行开放,为未来应用提供可能
3)服务实现
完成SOA架构设计之后,SOA架构师的工作并没有就此结束,需要同步规划服务实现、联调和测试计划,制定和发布合理的时间计划,组织不同部门同事和供应商确认细节,不断的介绍、解释、分析自己的设计,直至所有相关工程师理解和认可释放的服务和策略,同时跟踪解决SOA架构和服务实现问题,指导服务软件开发,把控整个实现进度。
至此,《浅谈整车SOA架构》四篇内容都已经分享完毕,感谢大家支持,这个系列的技术分享过程,我收获了很多,不仅对自己的技术体系有了更清晰的认识,也交到了很多朋友,从各位朋友身上学习到了很多很多,当然也更希望我的分享能带给大家一些启示。
未来,我将依然坚持在纯粹的技术分享道路上,同时脚踏实地的做我的技术,欢迎大家找我技术交流。
技术交流群:YasmineMiao(微信)