工程师的工作实践:SOA 开发基础 (上)
软件定义汽车,E/E架构是关键
汽车电子电气架构(简称E/E架构)是指整车电子电气系统的总布置方案。在智能网联汽车产业大变革背景下,软件定义汽车理念已成为共识。传统汽车采用的分布式E/E架构因计算能力不足、通讯带宽不足、不便于软件升级等瓶颈,已经不能满足现阶段汽车发展的需求,E/E架构的变革已成为智能网联汽车发展的关键,其升级主要体现在硬件架构、软件架构、通信架构三个方面:
硬件架构升级:由分布式ECU向域控制/中央集中架构方向发展,汽车E/E架构的升级路径表现为分布式(模块化→集成化)、域集中(域控制集中→跨域融合)、中央集中式(车载电脑→车-云计算)。好处在于:提升算力利用率,减少算力设计总需求;数据统一交互,实现整车功能协同;缩短线束,降低故障率,减轻质量。
![](http://pic.ikafan.com/imgp/L3Byb3h5L2h0dHBzL2ltYWdlMTA5LjM2MGRvYy5jbi9Eb3dubG9hZEltZy8yMDIxLzA1LzEzMDcvMjIyMDIzODUxXzFfMjAyMTA1MTMwNzM4MDEzNDg=.jpg)
图片来自网络
软件架构升级:通过 AutoSAR 等软件架构提供标准的接口定义,模块化设计,促使软硬件解耦分层,实现软硬件设计分离;Classic AutoSAR架构逐步向Classic AutoSAR+Adaptive AutoSAR混合式架构发展。好处在于:可实现软件/固件 OTA 升级、软件架构的软实时、操作系统可移植;采集数据信息多功能应用,有效减少硬件需求量,真正实现软件定义汽车。
通信架构升级:车载网络骨干由 LIN/CAN 总线向以太网方向发展。好处在于:满足高速传输、高通量、低延迟等性能需求,同时也可减少安装、测试成本。
中央计算单元——E/E架构的核心
中央计算单元是E/E架构中最关键的部分,不管是按区域的架构,还是以后的纯中央计算平台,其硬件构型从根本上决定了软件架构的设计方向。中央计算单元可以分为以下三种形态:
![](http://n4.ikafan.com/assetsj/blank.gif)
SOC分离式:将多个不同的芯片集成到一个中央计算单元上去,每个运行不同的操作系统,只是在形态上集中到了一起,各单元依然独立的完成各自任务;
硬件隔离式:在统一的计算平台上采用虚拟化方案,同时运行多个操作系统,但是各个系统依然在硬件上进行隔离,每个系统都有自己的专属硬件资源;
软件虚拟式:在统一的计算平台上采用虚拟化方案,同时运行多个操作系统,每个操作系统所使用的硬件资源,由Hypervisor层动态调配,每个系统并没有专属的硬件资源。
硬件隔离式和软件虚拟式,都采用了虚拟化方案,唯一不同点在于硬件资源是否专属,如果是专属的,就意味着资源无法动态调配,容易产生资源浪费。虚拟化方案最大的好处是,硬件上的可拓展性,如果中央计算单元采用刀片式的设计结构,可以很方便地拓展计算单元的算力,而不用替换整个计算单元。
在中央计算单元中,只需要两个操作系统即可,用于自动驾驶、车控、网关的RTOS,以及用于娱乐的普通OS(如Android、Linux)。用于娱乐的OS完全可以通过虚拟机的方式运行,用于自动驾驶、车控、网关的RTOS,可以直接运行在Hypervisor层,既能兼顾实时计算的要求,也能获得丰富的娱乐系统功能。
SOA——解决软件定义汽车中服务间通信的分布式架构
![](http://n4.ikafan.com/assetsj/blank.gif)
![](http://n4.ikafan.com/assetsj/blank.gif)
这只是一个很简单的例子,想表达的是,每个服务将自己的功能,以接口的方式提供,基于这些服务和接口,便可以设计出应用场景,以满足各种用户需求,提升驾车体验。可以想象,应用场景的需求一定是丰富且变化的,面向信号的话,新增一个需求,可能要等上一年,但如果服务也能够方便地进行开发、扩展和更新,是不是好多了,是不是挺有价值呢~
个人觉得,汽车SOA的设计难点,主要在于以下几点:
服务的定义和划分,要把业务需求分析透彻,从中提炼出服务的功能,数据流向理清,定义服务的边界,把握服务的粒度,怎么做到“低耦合,高内聚”,我以前很讨厌研究需求,觉得那些不过就是些业务,没啥技术含量,后来才慢慢认识到,这种想法很危险啊,脱离需求的软件设计不可能很好地满足需求,如果不能很好地服务于产品功能,那么再牛逼的技术都没有机会实现它应有的价值,事实上,能够把需求文档转化为可实施的软件设计,也是一种能力; 不同系统中,要实现中间件框架或者底层通信基础设施,Adaptive AutoSAR有ARA::COM组件,Android有Framework,但不能跨域,QNX/Linux就不用说了。要实现一个中间件框架,本身并不是件容易的事,需要比较强的技术实力,一旦出了问题一般都是重大问题; 服务接口标准化,接口描述语言化(IDL),能够通过工具自动生成RPC桩的代码(最好能够关联整车通信矩阵,e.g. ARXML->C++ API),能够跨平台,支持多语言,毕竟UI层可能不是C++写的,时至今日,没几个应用愿意去解析原始消息,远程调用接口不香嘛~; 如何兼容一些没有与时俱进的设备和模块,如何兼容旧的传输通道,如何尽可能复用以前的业务逻辑,理论上任何兼容都是可以实现的,抽象一层不够,那就再来一层,但兼容得越多,系统就越复杂,出问题的概率就越大,维护起来就越费劲,这意味着成本的升高,质量却不见得变好; 评估性能影响,怎么保证安全性,……,如果是基于开源项目,可能还要做二次开发,来满足这些非功能性质的需求~;
所以,汽车SOA真不是SOME/IP,也不是DDS,更不是Adaptive AutoSAR,这些都是汽车SOA技术栈中的一环,并不是全部。
很多时候,纯技术的部分并不是最难的,新的架构方案要达成共识,要真正落地,需要博弈和取舍,需要天时地利人和。作为一名工程师,心态是极为重要的,要分清理想与现实,技术与工作,所以在这里我只想谈技术,本来打算梳理一下做汽车SOA开发的基础知识体系,以后公众号的内容大致也会围绕着这个体系去写,没想到写着写着这么长了,于是分成上下篇了,下面先开个头吧。
问题:如果你要成为一名架构师,你需要明确地区分几组词语,否则你不可能成为一名合格的工程师或架构师。这几组词语是简单vs.简陋、平衡vs.妥协、迭代vs.半成品。如果你不能很清楚地定义出其中的区别,那么你将很难做出正确的决定,也就不可能成为一名优秀的工程师或架构师。
陈皓,《架构整洁之道》推荐序一
![](http://n4.ikafan.com/assetsj/blank.gif)
声明:本文内容及图片由BC-AUTO转载至网络,信息来源于公众号拖拉机日记。