软件定义汽车(1-3合集) .pdfVIP

软件定义汽车（1-3合集）

引⾔

作为⼀个技术的爱好者，搞算法，玩芯⽚，攒系统，并不只是⼯作，也是⾃⼰所追求的很重要的部分。写这个系列，是为了梳理这⼏年的所

学、所思、所想，从⽽形成⼀个完整的知识体系，也供⼤家参考。这是⼀个横向跨度很⼤的新领域，⼤家都还在探索，⽔平有限，难免疏漏，

不对之处请⼤家指正，也欢迎各领域的专家参与讨论。

由于⾃⾝电⼦设计和机器视觉的背景，早期的项⽬经历，让我涉猎了各领域的技术，包括电⼦设计、嵌⼊式软件、互联⽹全栈、移动端app、

操作系统、渲染引擎、内核驱动、⼯业控制现场总线等，每⼀个部分都不敢说有多么精通，但都经历过实际的项⽬。对车这个领域，并不是专

业出⾝，之前了解并不多，但为了能理解⼀帮传统汽车⼈在想什么，也是恶补了博世系列的⼗⼏本关于车辆⼯程、汽车电⼦、电⼦电⽓架构、

动⼒系统等⽅⾯的书。多领域的涉猎也给这个系列的主题，提供了不同的视⾓。

第⼀篇

⼀、互联⽹与传统汽车⼈的碰撞

在这个领域探索了⼏年，⼀个感悟就是，百年汽车⼯业，任何⼈也不要妄谈颠覆，但是也绝对不能拒绝进化。汽车界⼀直都有所谓的传“统派”与互联⽹“

派”之间的话题争论。传统派与互联⽹派都有⾃⼰的优点，但却是有明确的领域限制的，⽐如互联⽹所倡导的以⽤户为中⼼，持续打磨产品和服务的设计理

念，对于传统汽车⾏业的确有⾮常⼤的帮助。但是对于过程中所惯⽤的敏捷开发，快速迭代，却并不能完全套⽤，⾄少是有⼀定前提的。敏捷开发的前提

有两个，标准化的基础设施的⽀持，并且需要有良好的架构设计。

互联⽹领域，部署代码的主要有，电脑端、移动端、服务端。每个端操作系统、应⽤开发框架、开发⼯具都⾮常标准，但如果是⼀辆传统架构的汽车，有

⼏⼗上百个ECU，⽽且还来⾃于不同的供应商，系统集成的复杂度不是线性⽽是指数级别的增加，不得不有⼀套严苛的流程去规范整个开发流程。

⼆、从电⼦电⽓架构的演进看软件开发分⼯的变化

电⼦电⽓架构EEA（Electrical/ElectronicArchitecture），最先是由德尔福公司提出的。汽车作为⼀个复杂的电⼦系统，按照传统定义，可以划分为车⾝、

底盘、动⼒、信息娱乐、辅助驾驶等⼏⼤⼦系统；每个⼦系统⼜由多个电控单元(ECU)组成，这些ECU连接起来就形成了⼀个⽹络结构；EEA的主要职

责就是定义这些ECU之间的连接⽅式与⽹络拓扑结构。

电⼦电⽓架构.jpeg

2.1传统的分布式的电⼦电⽓架构的问题

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

ECU冗余，算⼒浪费，且⽆法形成协同

ECU由不同的供应商开发，框架⽆法复⽤，⽆法统⼀OTA

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

⽆法进⾏硬件升级

2.2不同架构主机⼚扮演的⾓⾊

基于传统分布式架构，主机⼚只是架构的定义者，核⼼功能是由各个ECU完成，其软件开发⼯作主要是由Tier1完成，主机⼚只做集成的⼯作，这也是为

什么⼤部分传统主机⼚基本没有软件开发能⼒的根本原因，就靠DRE搞定供应商就能集成⼀辆车，为什么还要花⼤量的成本养⼀个庞⼤的软件团队。

基于域控制器架构，属于过渡形态，DCU减轻了中央⽹关的压⼒，也可以实现部分业务逻辑，但⼤部分业务还是由各ECU实现，主机⼚可能会参与部分

DCU的开发，但与Tier1的整体分⼯⽆太⼤变化。

基于中央计算的架构，此时⼤部分ECU消失，各种传感器与执⾏器，被中央计算单元所⽀配，原本属于Tier1的⼤部分策略层⾯的软件需要由主机⼚去主

导，需要⼀只专业的软件团队，或者定义某种规范，让Tier1实现，最后以软件模块的⽅式集成进来，这需要⼀只⾼⽔平的软件架构团队。

2.3基于中央计算电⼦电⽓架构的优点

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

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

该架构是软件定义汽车的硬件基础，并不是有了新的电⼦电⽓架构就能够实现软件定义汽车，这还只是万⾥长征第⼀步，还需要有⼀个经过良好架构设计

的基础软件平台。

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

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

系统

系统

3.1操作系统的定义

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

类型代表特点