您好,欢迎来到中国汽车电子电气架构发展论坛2020!

猴哥私房菜-座舱域控制器:变化、一颗SoC,多个OS, 功能安全、敏捷开发

发布日期:2020-10-07

泛舟江南 汽车电子电气架构创新发展论坛 今天 

手机阅读



点击上方蓝色字体,关注我们

一:趋势

随着汽车智能化的发展,汽车电子领域的用户需求越来越复杂,技术趋势上要求把传统上诸多电子控制器(ECU)集中到一个或者几个大的域控制器(DCU)上,实现软件定义汽车(SDV),达到降低成本,优化整车电子电气架构等目的。

猴哥曾挑灯拜读了很多知乎大咖的文章,大咖们对这一趋势的解读,真是高屋建瓴,讲的透彻极了。作为一名好学生,猴哥难免心痒痒,临渊羡鱼,不如退而结网,是不是?于是猴哥想从一个技术小白的小角度,做一点小分析,发表一点小观点

老师常教导学生,读书学习要懂得问:WHAT, HOW,WHY,要通过现象看本质。网上对于WHAT已经讲的很多,本文不再多赘述,猴哥更多地想思考WHYHOW

不过由于猴哥眼界不高,经验不足,写的不好的地方请大家多多指教!

( Tips: 把握风口,准备起飞,是不是有点小激动呢?)

二:WHY-谁是幕后推手

2.1:汽车厂商的需求

推动这一趋势的 "幕后黑手"之一是汽车厂商

( Tips: "黑手"?还想混车厂吗,明明人家是正当生意,赶紧掌嘴!)



图1,展示了传统汽车电子电器架构设计。一辆车有多达70多个简单或者复杂的控制器,各个不同控制器的连接依赖复杂的线束布局。对于汽车厂商而言,需要对这么多不同节点的控制器进行管理是一件痛苦的事情。

(Tips: 多么痛的领悟啊!)

图2,显示了未来汽车的理想电子电器架构图。在未来的汽车电子域控制器(DCU)中,主要包含两部分功能单元:

  • 一类是输入输出(I/O)单元, 此类单元主要有以下功能特点:

  1. 作为I/O接口,感知和连接物理世界。

  2. 作为网关,通过CAN-LIN连接传统各个ECU节点。

  3. 常用使用成本*优的微控制器(MCU)。

  4. 运行的软件通常是精干短小的实时操作系统(RTOS/AUTOSAR)或者裸机(Bare Metal)系统,主要支持I/O接口管理和网关功能。

  • 一类是中央计算单元,此类单元主要有以下功能特点:

  1. 为增强其处理性能,中央计算单元上通常部署了具有较强运算力的系统级芯片(SoC),用来运行较复杂的操作系统(比如:Linux或者Android),处理复杂的业务逻辑。

  2. 具有大存储(典型使用eMMC作为介质)。

  3. 具有大内存(典型使用DDR作为介质)。

(Tips:没错,你看到了一台电脑的架构!)

通用,安全,开放 是未来的E/E架构的主要特点;这将有利于车厂将控制成本,提升质量和生产周期,并大幅度提高效率。

显而易见,简化架构设计的原因,就是为了车厂解决痛点,就是提高生产力

( Tips: 老师敲黑板啦!生产力,生产力,生产力!重要的事情讲三遍!)

2.2:芯片厂商的助力

汽车多核芯片的发展是推动这一变化趋势的主要催化剂。

“多核技术已经不是在实验室的一项研究,它已经应用到了工业领域。”

车载域控制器的开发,包括汽车的驾驶辅助系统、数字式仪表、信息娱乐系统,自动驾驶系统等,都需要基于非常强大的处理器架构来支持。域控制器的发展趋势需要依赖集成了多核处理器的系统芯片(SoC)方案。

现在,强大的计算能力,加上不断增加的专用车载域控制器的开发,使得汽车应用领域有了新的发展方向。这种趋势在未来会更加明显。对于未来汽车来说,现有架构系统彻底变革的时代即将来临。

( Tips:众人拾柴火焰高,掏出真心干,不能坐着盼。)


下一章,将讨论“怎么干”,也就是HOW。尽请期待!


一:需求


在前一章,简单介绍了汽车EE架构的未来架构,那是一种基于中央计算(central computing)的架构。但是往往前途是美好的,道路是曲折的。目前大多数车厂,包括Tesla在内,都还在域控制器阶段,即:集成了某些强相关的ECU成一个DCU。

很多车厂落后的原因,主要是软件能力的落后,而非硬件层面的落后。如果说硬件是“躯体”, 那么 软件就是“灵魂”

(Tips: 呵呵,在写诗呢!此处要严肃!)

接下来的章节,猴哥将和大家一起解密DCU的系统软件架构

在硬件/芯片的变革的同时,也需要软件方面的同步发展。为了能让多核处理器架构在未来的车载系统中工作得更加有效,这里有几个主要的因素需要考虑:

  • 不同级别的应用程序独立工作

不同的功能需要在不互相影响的前提下同步工作(也可以称作并行工作)。如果某些应用是关系到安全的关键功能,那么这些应用应该比其他非安全功能具有更高的优先级,在确保这些应用程序工作的情况下,其他应用才能运行。

(Tips:同学,有人问你是什么级别?记得一定要低调!)
  • 多操作系统的支持和集成

由于不同的应用在不同的操作系统中才能发挥*大的性能(例如,关键安全功能基于AUTOSAR系统;车载娱乐功能基于Genivi Linux系统;用户应用程序基于Android系统等)。这些多核系统需要同时运行不同的操作系统。因此,车载域控制器*主要的考虑在于灵活性,以及运行不同操作系统的能力。

  • 有效利用系统芯片资源

不同的功能通常通过同一个专用系统资源来实现。这方面的例子包括:针对不同功能的图像加速器,通信信道的共享等。

  • 支持各个操作系统之间的通信框架

保证各个操作系统之间同步工作并有一个好的系统性能,一套架构于在多核上的高效同步框架必不可少,该框架需要具有以下特点:

  1. 时间服务(time services):保证各个操作系统的时间同步到同一个时间基准,这是实现全局的时间事件触发的前提。

  2. 低延迟性通讯(Low latency):实现消费者和生产者之间的数据零拷贝,尽可能的减少从截获数据到执行动作整个过程所需时间。

  3. 实时性调度(real-time schedule):能在准确预估的时间里,完成从事件触发到执行的一系列动作调度。

  4. 安全性(safety and security):能进行用户认证,能防止恶意入侵,防止数据丢失等,冗余设计等,ISO26262标准有比较详细安全的定义。

  5. 嵌入式(embedded):具有OS抽象层,适配不同操作系统;支持多种异构/同构多核之间的通讯。

  6. 面向服务的架构(Service oriented architecture):提供本地服务、远程服务,以及之间的统一接口描述语言。

  7. 容易部署(Easy distribution):由于涉及到多个不同的操作系统环境,必须要有一套方便的机制来部署这样一套框架,方便各自环境下的应用程序的使用。



通过适当的配置,在一个多核系统芯片上运行多个不同的系统软件(OS),来处理不同的业务逻辑,这也为多个传统ECU集成到一起奠定了基础。

(Tips: 不想当将军的士兵不是一个好士兵,不想做架构师的程序员不是一个好程序员!你没秃,你还可以学。)

二:想法

我们以座舱域控制器的设计为例,来看域控制器系统软件的架构如何实现。

从业务逻辑上,我们可以把一些业务比较紧密相关的功能在一个控制器上完成。比如数字座舱业务,车辆网关业务,以及辅助驾驶业务,三块业务整合在一起,以往需要三家零部件供应商,现在只需要一家供应商即可。

(Tips: 传统单一零件供应商表示已经哭晕在厕所... ... )

图1:座舱域控制器概念图

三:架构

我们以TI Jacinto™ 7(J7) 系统芯片为例。TI J7同时集成了2x ARM Cortex-A72内核,2x MCU_Cortex-R5F内核, 2x Main_Cortext-R5F内核,同时还集成了以太网关模块,以及多个DSP模块。

(Tips:请同学们原谅,此处并非广告植入!)

基于J7的芯片架构,我们来看下面的系统软件架构图:

图2:座舱域控制器的系统软件架构

  • ACF:Application communication framework(应用层通信框架)

  • ECF:Embedded communication framework(嵌入式通信框架)

在2x MCU_Cortex-R5内核上:

运行安全等级为ASIL-B的经典AUTOSAR OS,主要处理:

  • 传统车辆控制业务

  • 以太网/CAN网络等网关功能

  • 监视整个域控制器每个系统(Automotive Linux,RTOS,TEE OS)的运行,当其他系统崩溃时,能够重新启动该系统。

在2x Main_Cortext-R5 和 DSP上:

  • 运行安全等级ASIL-B/D的RTOS系统软件,用于安全图形渲染,或者用于接收并处理实时性高的传感器数据,比如高清摄像头,雷达,激光等数据。

在2x Cortex-A72内核上:

  • 运行汽车级别Linux系统软件,处理运算量比较大的一些业务,比如绘图,逻辑判断,数据分析/识别等。

另外:

  • ECF/ACF:通信框架构建在每个操作系统上,支持各个操作系统之间的安全有效的同步操作。

这种域控制器的系统架构,对于用户而言具有以下好处:


一句话概况: “一颗SoC,多个OS, 功能安全(Safety & Security)。”


Tips: 有人问:那这个缺点是什么呢?答:“什么缺点?没缺点的,这辈子都不可能有缺点!”呵呵,开玩笑的,没缺点是不可能的。不过在工程师眼里没有缺点,只有挑战!这种架构对于供应商的技术集成能力**挑战,传统的供应商往往要么只了解中控的开发,要么只了解仪表的开发,要么只了解动辅助驾驶系统的开发,很难有全才。
下一章,工程师们将迎接这些挑战,改变世界。

上一章的话题,我们一起谈谈复杂汽车软件开发的挑战是什么。

在一个复杂的域控制器(DCU)里集成不同的软件,主要的挑战有:

  • 如何解决系统的复杂性和软件质量的矛盾?

  • 如何满足各个子系统的不同功能安全级别的要求?

  • 如何做到实时可靠的通讯?

  • 如何满足多样化的定制需求?

  • ... ...

Tips: 不要问我是怎么知道上面这些的,说多了都是泪。


  1. “工业设计的简单和复杂”

我们举一个汽车“启动/停止”功能的例子,来说明一个汽车工业 "简单即是复杂,复杂即是简单。" de设计理念。

图一:工业设计的简单和复杂

根据冰山理论:一个人的"自我"就像一座冰山一样,我们能看到的只是表面很少的一部分——行为,而更大一部分的内在世界却藏在更深层次,不为人所见,恰如冰山。

在汽车工业设计中,这么说也不过分。我们看到的简洁的用户操作界面(HMI),背后却是极其复杂的技术逻辑系统工程的支撑。作为工程师,我们追求一个表象简单的需求背后的本质,和实现它的复杂逻辑。透过表象看本质,才能在汽车这样一个产品开发设计上考虑周全。

Tips:猴哥也趁此机会,也帮汽车工程师们倒一倒苦水。"哪有什么岁月静好,不过是有人替你负重前行。"


2“工欲善其事,必先利其器”

一个复杂的汽车软件工程,开发模式上的选择决定了迎接挑战的正确姿势

多年前,猴哥曾经有幸参与一个复杂的汽车ECU开发。当时开发队伍遍布全球7个国家,10多个地区,需要同时为多款车型定制不同的软件,头疼的地方是:

  • 涉及到多方人员协调,多模块集成和管理

  • 不同软件团队使用的设计工具、验证工具,数据、工作流程多且难以控制

  • 跨域依赖性和关系无法共享同步

  • 需求变更,需求变种难以控制

  • 软件质量,开发时间难以保证

  • *终交付时间压力大

现在想想,项目之所以*后成功,我觉得很重要的一点是当时借鉴了敏捷迭代的开发思想。

Tips: 是的,在汽车电子软件开发中,敏捷迭代开发也适用。做互联网软件的同学是这方面的老专家,我们要向这些同学学习!

当时我们所有团队召开每日站立视频会议(stand-up meeting),每日提交代码到统一代码库(continuous integration),每日统一编译 (daily build),每日自动测试(daily test),每日更新Bug状态,环环相扣,基本上达到了全球所有开发部门的实时协作,工作和沟通效率极大提高。

回想起来,迭代开发真是这个项目成功自我救赎的关键,没有之一。

图二:敏捷迭代开发模型


图三:敏捷迭代开发在项目计划上的优化


而且在敏捷开发的每一个迭代周期,我们当时都遵循了ISO26262推荐的V字型开发小模式

图四:V字型开发模型


在每一个开发阶段,都配置有相应的工具,

图五:让工具代替人,从工程角度保证软件的质量和安全


现今提出的软件定义汽车(SDV)的概念,实施这种敏捷迭代开发模式并兼顾汽车ISO26262建议流程,是非常适合汽车软件特点的,特别是复杂的软件,更是如此。

把一件复杂的事分解成很多件简单的事,把大风险分解成很多个小风险,才能有利于控制项目,按计划实施项目。

而传统的软件开发周期短,并且一写好,然后好多年不会变化。但是复杂的软件系统不一样,如果想把所有的功能都实现了, 把所有的bug都解决后,再发布给车厂,估计车厂等的花儿都谢了。

这里不得不拿Tesla举例。人家一会儿搞出一个”狗狗模式”,一会儿更新一次软件就能增加里程,诸如此类,让人看得眼花缭乱。正是这种靠着软件迭代式开发,Tesla不断的吸收新的需求,不断的及时地实现它,验证它。Tesla已经获得了互联网思维的精髓:“天下武功,唯快不破!”

Tips:猴哥作为一名汽车人,真的很担心传统汽车工业这头大象,能不能快起来。大众汽车似乎已经觉醒了,他们成立了car.software部门,组织了上万软件工程师的队伍来实施新EE架构下的vw.os软件开发。不过猴哥自幼熟读历史(自吹),任何变革都会被传统顽固势力和包袱所束缚,大众的大象之舞将不会那么灵动。


来源:知乎@泛舟江南




相关文章

域控制器的当前与将来
《论文翻译》汽车域控制器架构-一种大规模软件集成汽车系统的新方法
域控制器和汽车未来的电子架构




SELECTED EVENTS




 

长按二维码识别关注


 

/长按二维码申请加入 EEA 技术交流群/ 


我就知道你“在看”


  • 电话咨询
  • 021-22306692
  • 15021948198
None