前言:
汽 车的智能化和软件化,就像一个巨大的漩涡,吸引着各方势力卷入其中。 就像上一篇文章提到的一样,在大家构建软件能力过程中,一些危机也正在酝酿之中,在缺乏良好设计的框架下,一旦进入正常的车型迭代,就会被以前历史的版本束缚住手脚。 前面的系列文章从各个角度阐述了如何构建软件驱动的硬件平台能力:- 《概述》
- 《面向服务的架构设计》
- 《SOA基础软件框架与参考实现》
- 《行业现状》
- 《中央计算单元架构》
- 《开发人才从何而来》
- 《高性能计算单元架构》
- 《构建开源软件生态系统》
- 《危机是如何酿成的》
技术在这场变革中很重要,但是不是最关键的,从全局的角度去思考打造体系化的能力,首先必须知道要做的事情是什么。
对于产业链上的朋友来讲也可以理解,究竟OEM客户需要什么,自己所提供的产品,扮演了什么样的角色。
对于投资圈朋友来讲,参考这张图可以了解到,感兴趣的投资标的究竟处在什么样的行业位置当中,想解决什么样的问题,未来想发展成什么样。
新平台的开发,技术链路非常长且复杂,所以我非常希望看到产业链上的各个环节能够形成合力。在这次变革当中,能够帮助到各方玩家,更快的完成架构的升级和转型。
整个工程就像一个庞大的战役,如果各方都能清楚,自己在这个战役当中的位置,作为执行者来讲,也能够发挥自己的主观能动性,去更加积极主动的解决相关问题,也能知道如何去配合上下游开展工作。
架构总览
整个架构可以总结为“6+4”:6层逻辑架构构建起了一个软硬解耦的系统;4层服务架构完成了服务的抽象与适配,建立了一个标准化的服务体系;六层逻辑架构包括:可拓展电子电气架构,也叫计算与通信架构
可拓展硬件计算平台
操作系统内核
分布式服务中间件
标准化服务层
可编排应用层
基于标准服务的开发,能够提高应用的迭代速度,让产品经理更加深入的介入产品的开发过程。
分层的架构设计,便于进行分层测试与验证,减少集成测试的压力,问题发现的更充分,也能够提高版本发布的速度。
便于形成产品线和平台线的分工,产品线负责具体车型项目,平台线,负责构建技术中台。
可拓展的硬件计算平台,可以兼容多种传感器和外部设备,同时支持芯片和硬件的可升级。
可拓展的计算通信架构,可以加快车型开发的速度,平台能够快速地适配到新的车型之上,分层的结构,把车型之间的差异化缩到最小,能够减少后期多产品线维护的压力。
1. 可拓展计算与通信架构
主要目的是,提供一个与车型无关的统一平台,在此之上构建的所有车型都将采用统一架构。可拓展中央计算平台与模块化Zonal Controller 是构建这个标准电子架构的核心。中央计算单元将整合自动驾驶,智能座舱和车辆控制三大域的核心业务功能,标准化的区域控制器主要有三个职责:- 电力分配
- 数据服务
- 区域网关
2. 可拓展中央计算平台
中央计算平台需要拥有统一的传感器及外设接口,同时需要能够兼容各家的芯片产品。随着整车智能化的提高,越来越多的芯片玩家进入到了车载芯片领域,在此之前,车载芯片的迭代速度非常慢,然而最近几年,车载芯片的迭代速度越来越快,各种高性能的芯片层出不穷。 如果每次换芯片都要进行换骨手术,对整个技术架构进行重构,会极大的拖慢新产品的开发速度。目前来看,车载芯片的发展速度,正在向消费电子靠近,消费电子领域基本是一年一代芯片。车载领域虽然稍微慢一点,但是升级换代的诉求也非常强烈。 关于中央计算单元的架构方式,之前的文章已专门做过阐述,有三种方式:分离SOC、硬件隔离、软件虚拟化,详细可参考这篇文章, 《中央计算单元架构》 总结下来,中央计算平台需要拥有统一的传感器及外设接口,同时能够支持芯片的升级,其最终目的就是要实现在车生命周期内的硬件可升级,从而延长汽车的智能化生命周期。3. 操作系统内核
关于操作系统的概念,之前的文章已经辨析过。目前各种操作系统的概念满天飞,但大部分都只是操作系统中间件。由于车辆的复杂性以及对于实时性的要求,没法用一个操作系统来统一所有的应用场景。这并不是一个软件问题,在此不做过多阐述,详细参考这篇文章, 《软件定义汽车-概述》 在操作系统内核层面,最主要的就是要满足实时性的要求,能够保证系统的性能和稳定性。如果需要采用虚拟化的方案,很多虚拟化的工作也需要在这一层展开。这块不是车厂的强项,也不是能够体现产品差异化的地方。因为无论用谁家的,其实现的功能都非常相似。所以没必要车厂单独去开发一个内核,本身很多生态的建设靠车厂也无法完成,这个工作交给科技公司去做就好了,有很多成熟的可选的方案。 在上面的图中,也有一种类型的系统叫OS for MCU,最典型的就是Classic AutoSAR。从这个整体架构图当中,大家也可以看到,它的生与死其实根本就不关键。因为它只是整个计算系统当中非常小的一块儿。所有的代码量加起来也就几兆大小,对它的需求是成熟稳定,可用即可。在中央计算架构下,以太网是核心的通信方式,传统的MCU的网络管理、CAN通信、诊断等功能,将会被中央计算单元所吸收。未来中央计算单元的MCU承担的最主要的职责可能是电源管理。4. 分布式服务框架
很多人也把这层称为XX.OS,其本质上是一个操作系统中间件。 其最核心的作用,就是提供一个分布式的计算和通信框架。 对下屏蔽各类操作系统内核的差异,对上提供统一的服务开发框架。 其主要包含服务管理、网络管理、通信管理、升级、诊断、日志、状态等。Adaptive Autosar和ROS就是典型的分布式服务开发框架,此类中间件都是解决通用的技术问题,实质上也不是车厂的核心竞争力,当然有余力的也可以选择自己开发,详细可以参考这篇文章, 《SOA基础软件框架与参考实现》5. 标准化服务层
也有很多人把在这层也称之为XX.OS,其主要目的是把车上,硬件功能抽象为各种服务,并且进行分类分层,为上层应用提供良好的开发SDK。在上图的架构中,分为四层设计:- 最下层是服务的适配层,运行在Zonal Controller之上,将对局域网内的ECU功能进行抽象化处理,面向具体车型的信号进行适配。
- 服务适配层向上对接的是原子服务,指的是硬件的一些基本功能,比如传感器、电机控制、门窗、车灯等,最基本一些操作。
- 在原子服务之上是逻辑服务,也称为组合服务,里面有一定的判断逻辑存在。比如打开车门,打开车灯,并不是在任何状态下都无条件执行,需要判断很多条件。
- 在逻辑服务之上是业务服务,和各域的功能联系的比较紧密。
6. 可编排应用层
在服务层之上就是各域的应用功能,此处的“域”只是一个虚拟的概念,因为在中央计算的架构下,各域之间已经没有了明显的物理边界,逻辑上可以划分为以下四个:- 自动驾驶
- 智能座舱
- 车辆控制
- 智能天线
结语
同样一个问题,有多种解决的途径,分析下来会有多种解决方案。但是需要做的事情分分类,也都殊途同归。所以右边的文字部分详细的列出了各块儿需要做的事情,可以供大家参考。每一个点都是非常庞大的主题,要讲清楚,需要花很长的篇幅。后续有机会我们将围绕这些工作,进行更加细致的阐述。 很多人也在问,有没有一些书或者成熟的方案可以借鉴,很难有,因为这是一个很新的领域,很多时候需要去创造产业链上没有的东西,所以正向的研发,正向的思考是非常关键的。一切从问题出发,正向去思考,分析解决这些问题的途径,自然而然的会形成一种比较一致的判断。技术方案其实是一个非常客观的东西,大家可以理性的去分析,也欢迎大家反馈自己的想法。 本来是准备写关于芯片定制化的一些思考,但是如果不解释清楚整个技术架构,讲芯片的定制化可能会让大家感到疑惑。其实在设计中央计算单元的时候,最大的挑战就是可用的芯片。目前没有一款芯片能够同时满足几大功能域的要求,只能用多个芯片拼起来。半导体行业其实已经有了从晶元级别去集成多个芯片的能力。下一期我们可以仔细聊聊这个话题。后台回复“架构总览”,下载《汽车数字系统架构图》
《软件定义汽车》专辑
作为一个技术的爱好者,搞算法,玩芯片,攒系统,并不只是工作,也是自己所追求的很重要的部分。写这个系列,是为了梳理这几年的所学、所思、所想,从而形成一个完整的知识体系,也供大家参考。
作者:leo_huang_
加入汽车软件开发者社区(仅限技术人员):
管理员微信:18521323533
技术交流群:YasmineMiao(微信) 投稿合作:18918250345(微信)