新闻资讯

汽车软件工程师-软件究竟如何定义汽车？从电子电气架构的演进看软件开发分工的变化

汽车软件工程师-软件究竟如何定义汽车？从电子电气架构的演进看软件开发分工的变化?

汽车界一直都有所谓的“传统派”与“互联网派”之间的话题争论。传统派与互联网派都有自己的优点，但却是有明确的领域限制的，比如互联网所倡导的以用户为中，持续打磨产品和服务的设计理念，对于传统汽车行业的确有非常大的帮助。

引言：作为一个技术的爱好者，搞算法，玩芯片，攒系统，并不只是工作，也是自己所追求的很重要的部分。写这个系列，是为了梳理这几年的所学、所思、所想，从而形成一个完整的知识体系，也供大家参考。这是一个横向跨度很大的新领域，大家都还在探索，水平有限，难免疏漏，不对之处请大家指正，也欢迎各领域的专家参与讨论。

由于自身电子设计和机器视觉的背景，早期的项目经历，让我涉猎了各领域的技术，包括电子设计、嵌入式软件、互联网全栈、移动端 app、操作系统、渲染引擎、内核驱动、工业控制现场总线等，每一个部分都不敢说有多么精通，但都经历过实际的项目。对车这个领域，并不是专业出身，之前了解并不多，但为了能理解一帮传统汽车人在想什么，也是恶补了博世系列的十几本关于车辆工程、汽车电子、电子电气架构、动力系统等方面的书。多领域的涉猎也给这个系列的主题，提供了不同的视角。

一、互联网与传统汽车人的碰撞

在这个领域探索了几年，一个感悟就是，百年汽车工业，任何人也不要妄谈颠覆，但是也绝对不能拒绝进化。汽车界一直都有所谓的“传统派”与“互联网派”之间的话题争论。传统派与互联网派都有自己的优点，但却是有明确的领域限制的，比如互联网所倡导的以用户为中，持续打磨产品和服务的设计理念，对于传统汽车行业的确有非常大的帮助。但是对于过程中所惯用的敏捷开发，快速迭代，却并不能完全套用，至少是有一定前提的。敏捷开发的前提有两个，标准化的基础设施的支持，并且需要有良好的架构设计。

互联网领域，部署代码的主要有，电脑端、移动端、服务端。每个端操作系统、应用开发框架、开发工具都非常标准，但如果是一辆传统架构的汽车，有几十上百个 ECU，而且还来自于不同的供应商，系统集成的复杂度不是线性而是指数级别的增加，不得不有一套严苛的流程去规范整个开发流程。

二、从电子电气架构的演进看软件开发分工的变化

电子电气架构EEA(Electrical/Electronic Architecture)，最先是由德尔福公司提出的。汽车作为一个复杂的电子系统，按照传统定义，可以划分为车身、底盘、动力、信息娱乐、辅助驾驶等几大子系统;每个子系统又由多个电控单元 (ECU)组成，这些ECU连接起来就形成了一个网络结构;EEA 的主要职责就是定义这些ECU之间的连接方式与网络拓扑结构。

电子电气架构

2.1 传统的分布式的电子电气架构的问题

网络结构复杂，形成信息孤岛，中央网关会是性能瓶颈

ECU冗余，算力浪费，且无法形成协同

ECU 由不同的供应商开发，框架无法复用，无法统一 OTA

外部开发者无法对 ECU 进行编程，无法由软件定义新的功能

无法进行硬件升级

2.2 不同架构主机厂扮演的角色

基于传统分布式架构，主机厂只是架构的定义者，核心功能是由各个 ECU 完成，其软件开发工作主要是由 Tier1完成，主机厂只做集成的工作，这也是为什么大部分传统主机厂基本没有软件开发能力的根本原因，就靠 DRE搞定供应商就能集成一辆车，为什么还要花大量的成本养一个庞大的软件团队。

基于域控制器架构，属于过渡形态，DCU 减轻了中央网关的压力，也可以实现部分业务逻辑，但大部分业务还是由各 ECU 实现，主机厂可能会参与部分 DCU 的开发，但与 Tier1的整体分工无太大变化。

基于中央计算的架构，此时大部分 ECU 消失，各种传感器与执行器，被中央计算单元所支配，原本属于 Tier1的大部分策略层面的软件需要由主机厂去主导，需要一只专业的软件团队，或者定义某种规范，让 Tier1实现，最后以软件模块的方式集成进来，这需要一只高水平的软件架构团队。

2.3基于中央计算电子电气架构的优点

算力集中到为少数几个中央单元，可以留有冗余便于后续软件功能升级

经过良好的平台化设计之后，硬件单元也可以升级，如特斯拉的 AP

该架构是软件定义汽车的硬件基础，并不是有了新的电子电气架构就能够实现软件定义汽车，这还只是万里长征第一步，还需要有一个经过良好架构设计的基础软件平台。

三、车载环境下的操作系统

提到基础软件平台，很多人的第一反应就是要做一个操作系统，操作系统的确是非常关键的一个组件，但是打造一个基础软件平台绝对不是再造一个操作系统。

3.1操作系统的定义

操作系统是一种管理计算机硬件与软件资源的计算机程序，大众所知道的其实都是很泛化的操作系统概念，常见的概念分为四个层次。

类型 代表 特点

内核	Windows NT、Unix、Linux、QNX、IOS（发源自 Unix）	有自己独立研发的内核，
发行版	Android、AliOS、Ubuntu、各种国产桌面系统、AGL	在内核之上构建了应用开发框架，包管理，核心服务等组件
ROM	MIUI、EMUI、各种 xxx.OS	在 Android 上修改过了系统服务和系统UI
中间件	ROS、DurerOS Apex.OS	具有某种功能集合的操作系统中间件

3.2内核分类

内核(kernel) 是操作系统最核心的部分，可以理解为操作系统的心脏，分为三种类型：

微内核	QNX、LiteOS、VxWorks	只实现基本的任务管理、内存管理、进程通信等，其他包括驱动等都在用户态实现
宏内核	Linux、Unix	除了基本组件之外，还有网络、设备管理、文件系统等放在内核态实现
混合内核	Mac OS	结合了微内核与宏内核的好处

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 系统的人，看到“软件定义汽车“的描述，第一反应可能是，这不是就是我们搞微服务架构的思路吗?

这就是我想说的第二点，互联网的开发流程虽然不能直接套用在车上，但是其在软件工程领域的实践经验对于解决车载软件领域的问题还是很有帮助的。看起来是汽车电子软件开发的门槛高，其实是因为封闭和从业人员少。当前的机遇就是，大家都想往这个方向走，但是也都是摸着石头过河，可以有机会将这些理论经验用于实践。

前段时间梳理了一下，面向下一代智能汽车的关键技术，分为智能座舱、自动驾驶、与数字系统。今天讲的主要数字系统当中，我认为最重要的软件基础设施，基础软件平台，下一篇将重点阐述，面向服务的架构设计与车载软件相结合的一些思考， 以下思维导图仅供参考!

智能座舱

以产品设计为驱动力，但目前同质化现象比较严重，主要以硬件差异为基础，只能利用先发优势，无法形成技术与产品壁垒!

基于用户画像，使用AI技术，构建具有情景感知能力的引擎，是智能座舱产生质变的前提，但技术上短期无法突破(行业普遍问题，不是车行业特有)。

多设备协同、多模态融合交互，是消费电子IOT场景下大家探索的方向，对于车载环境有很强的借鉴意义。

自动驾驶

以算法与数据的积累为核心驱动力，可以在技术上形成壁垒，但是需要巨额的研发投入，能否快速落地主要受制于数字系统架构。短期来讲大家可能都差不多，但是积累到一定时间，后发玩家可能就再也追不上了。

数字系统

以架构设计与资源整合为核心驱动力，其包含了传统意义上的电子电气架构，但需要横向整合多个软硬件架构部门，才能定义完整的系统架构。是否采用新架构从根本上决定了，智能座舱与自动驾驶究竟能走多快走多远。

良好的数字系统架构，能够屏蔽底层车型平台的差异，多个车型共用一套基础软硬件平台，能够缩减开发资源，一套架构持续5年，可以留出充足的资源研发下一代。

本文作者：leo_huang_

本文系作者投稿文章，任何形式的转载都请联系作者获得授权并注明出处。