|
汽车界一直都有所谓的“传统派”与“互联网派”之间的话题争论。传统派与互联网派都有自己的优点，但却是有明确的领域限制的，比如互联网所倡导的以用户为中，持续打磨产品和服务的设计理念，对于传统汽车行业的确有非常大的帮助。
引言：作为一个技术的爱好者，搞算法，玩芯片，攒系统，并不只是工作，也是自己所追求的很重要的部分。写这个系列，是为了梳理这几年的所学、所思、所想，从而形成一个完整的知识体系，也供大家参考。这是一个横向跨度很大的新领域，大家都还在探索，水平有限，难免疏漏，不对之处请大家指正，也欢迎各领域的专家参与讨论。
由于自身电子设计和机器视觉的背景，早期的项目经历，让我涉猎了各领域的技术，包括电子设计、嵌入式软件、互联网全栈、移动端 app、操作系统、渲染引擎、内核驱动、工业控制现场总线等，每一个部分都不敢说有多么精通，但都经历过实际的项目。对车这个领域，并不是专业出身，之前了解并不多，但为了能理解一帮传统汽车人在想什么，也是恶补了博世系列的十几本关于车辆工程、汽车电子、电子电气架构、动力系统等方面的书。多领域的涉猎也给这个系列的主题，提供了不同的视角。
一、互联网与传统汽车人的碰撞
在这个领域探索了几年，一个感悟就是，百年汽车工业，任何人也不要妄谈颠覆，但是也绝对不能拒绝进化。汽车界一直都有所谓的“传统派”与“互联网派”之间的话题争论。传统派与互联网派都有自己的优点，但却是有明确的领域限制的，比如互联网所倡导的以用户为中，持续打磨产品和服务的设计理念，对于传统汽车行业的确有非常大的帮助。但是对于过程中所惯用的敏捷开发，快速迭代，却并不能完全套用，至少是有一定前提的。敏捷开发的前提有两个，标准化的基础设施的支持，并且需要有良好的架构设计。 互联网领域，部署代码的主要有，电脑端、移动端、服务端。每个端操作系统、应用开发框架、开发工具都非常标准，但如果是一辆传统架构的汽车，有几十上百个 ECU，而且还来自于不同的供应商，系统集成的复杂度不是线性而是指数级别的增加，不得不有一套严苛的流程去规范整个开发流程。
二、从电子电气架构的演进看软件开发分工的变化
电子电气架构EEA（Electrical/Electronic Architecture），最先是由德尔福公司提出的。汽车作为一个复杂的电子系统，按照传统定义，可以划分为车身、底盘、动力、信息娱乐、辅助驾驶等几大子系统；每个子系统又由多个电控单元 (ECU)组成，这些ECU连接起来就形成了一个网络结构；EEA 的主要职责就是定义这些ECU之间的连接方式与网络拓扑结构。
电子电气架构.jpeg
2.1 传统的分布式的电子电气架构的问题
2.2 不同架构主机厂扮演的角色
2.3基于中央计算电子电气架构的优点
三、车载环境下的操作系统
提到基础软件平台，很多人的第一反应就是要做一个操作系统，操作系统的确是非常关键的一个组件，但是打造一个基础软件平台绝对不是再造一个操作系统。
3.1操作系统的定义
操作系统是一种管理计算机硬件与软件资源的计算机程序，大众所知道的其实都是很泛化的操作系统概念，常见的概念分为四个层次。
类型 代表 特点
3.2内核分类
内核（kernel） 是操作系统最核心的部分，可以理解为操作系统的心脏，分为三种类型： 类型 代表 特点
微内核的好处是小、稳定，可以实现 RTOS，但是如果所有服务都在用户态实现，其运行效率是会打折扣的。通常讲车载上 QNX 比 Linux 稳定，不是因为它技术有多先进，而是其技术架构决定的。
3.3选择操作系统的核心因素
业务类型： 如果业务有实时性要求，必然需要使用 RTOS，比如航天军工用的比较多的 VxWorks，车载用的比较多的 QNX。 芯片类型： 使用什么操作系统，往往取决于选择的芯片支持什么，没有芯片厂商的支持，一个操作系统走不远。嵌入式领域是ARM 的天下，处理器类型也决定了使用的操作系统类型，Cortex-A/M/R 用于应用处理器、低功耗、实时处理三个方面。 系统生态： 面向C 端用户的操作系统，应用生态决定了生死。面向行业的操作系统，比如汽车仪表、自动驾驶系统、网关，C 端用户是无法感知到底用了什么操作系统，开发者的态度决定了使用什么系统，没有人愿意在一个工具、库都支持不全的系统上开发软件。
3.4车载场景的操作系统选择
汽车上的绝大部分ECU 都是 AUTOSAR 的天下，有些就是简单的单片机，甚至都不用跑操作系统。剩下的需要操作系统主要是信息娱乐、自动驾驶、复杂网关、TBOX 等。
娱乐系统，其核心是多媒体和互联网应用，主要关注应用生态和开发者生态，国内大部分都是Android，少部分AliOS，特斯拉用linux，所以娱乐这块儿国内做的更好，但这并不是他的核心竞争力。由于生态的问题，针对车载的娱乐系统去开发一套操作系统，没有实际意义，以车的体量，也撑不起这样一个生态。这一块儿跟着消费电子走就行了，任何鼓吹系统底层能力的行为，都是隔靴搔痒，没有搞清楚重点。
自动驾驶，其核心是算法设计和数据积累，没有人会把算法的软件实现和操作系统绑死，其设计一定是跨平台的，有成熟稳定的 RTOS 即可，目前主流的有三种 RT-Linux、QNX、VxWorks。由于深度学习构建在开源软件的基础上，也需要生态，这也是linux 虽然不是硬实时系统，但依然在自动驾驶领域用的比较多的原因 。自动驾驶这块，倒是缺一个类似于 ROS 的能够跨平台的分布式开发框架 ，虽然ROS2进化许多，但是在低延时、功能安全、信息安全方面还有很多路要走，国外有家创业公司APEX.AI，正在基于ROS2分支，把它往车规级方向做。NVIDIA 构建了一整套的框架，做的非常不错，但是和自家芯片绑死，限制了其使用范围。
网关以及以后的大吞吐的以太网交换机，虽然算力要求也高，但是任务相对单一，架构也很简单，现有系统就能满足，也没必要去开发一个针对网关的操作系统。TBOX由于主芯片来源单一，目前基本是都是 Linux。
经过以上的分析，大家可以知道，目前根本就不是因为操作系统的短板限制了软件化的水平， 车载架构的特殊性，决定了无法使用单一操作系统来实现所有功能，多个操作系统并存的局面还会持续很久 。
四 中央计算电子电气架构下的基础软件平台
前面提到，新的电子电气架构是软件定义汽车的硬件基础，并不是有了新的电子电气架构就能够实现软件定义汽车，还需要有一个经过良好架构设计的基础软件平台。下面我们就来对这个问题进行重新定义。
4.1 问题描述在新的电子电气架构下，多个中央处理单元、多个传感器、执行器、交换机等，在以太网的连接下，组成了一个复杂的分布式系统 ，由于工作任务的不同，多个中央计算单元运行着不同的操作系统。
4.2 核心诉求
“软件定义汽车“，其核心内涵就是，能够通过软件的方式，动态改变上述系统当中网络节点之间的聚合关系，从而产生新的业务功能，因此对软件平台的要求如下：
搞互联网后端的或者 IT 系统的人，看到“软件定义汽车“的描述，第一反应可能是，这不是就是我们搞微服务架构的思路吗？ 这就是我想说的第二点，互联网的开发流程虽然不能直接套用在车上，但是其在软件工程领域的实践经验对于解决车载软件领域的问题还是很有帮助的。看起来是汽车电子软件开发的门槛高，其实是因为封闭和从业人员少。当前的机遇就是，大家都想往这个方向走，但是也都是摸着石头过河，可以有机会将这些理论经验用于实践。
前段时间梳理了一下，面向下一代智能汽车的关键技术，分为智能座舱、自动驾驶、与数字系统。今天讲的主要数字系统当中，我认为最重要的软件基础设施，基础软件平台，下一篇将重点阐述，面向服务的架构设计与车载软件相结合的一些思考， 以下思维导图仅供参考！ next_EE.png
智能座舱 以产品设计为驱动力，但目前同质化现象比较严重，主要以硬件差异为基础，只能利用先发优势，无法形成技术与产品壁垒！ 基于用户画像，使用AI技术，构建具有情景感知能力的引擎，是智能座舱产生质变的前提，但技术上短期无法突破(行业普遍问题，不是车行业特有）。 多设备协同、多模态融合交互，是消费电子IOT场景下大家探索的方向，对于车载环境有很强的借鉴意义。
自动驾驶 以算法与数据的积累为核心驱动力，可以在技术上形成壁垒，但是需要巨额的研发投入，能否快速落地主要受制于数字系统架构。短期来讲大家可能都差不多，但是积累到一定时间，后发玩家可能就再也追不上了。
数字系统 以架构设计与资源整合为核心驱动力，其包含了传统意义上的电子电气架构，但需要横向整合多个软硬件架构部门，才能定义完整的系统架构。是否采用新架构从根本上决定了，智能座舱与自动驾驶究竟能走多快走多远。良好的数字系统架构，能够屏蔽底层车型平台的差异，多个车型共用一套基础软硬件平台，能够缩减开发资源，一套架构持续５年，可以留出充足的资源研发下一代。
免责声明：本网站的部分内容，来源于其他网站的转载，转载目的在于传递和分享更多信息，并不代表本平台赞同其观点和对其真实性负责，版权归原作者所有，如有侵权请联系我们删除。 |
