软件定义汽车（1-3合集）
引⾔
作为⼀个技术的爱好者，搞算法，玩芯⽚，攒系统，并不只是⼯作，也是⾃⼰所追
求的很重要的部分。写这个系列，是为了梳理这⼏年的所学、所思、所想，从⽽形
成⼀个完整的知识体系，也供⼤家参考。这是⼀个横向跨度很⼤的新领域，⼤家都
还在探索，⽔平有限，难免疏漏，不对之处请⼤家指正，也欢迎各领域的专家参与
讨论。
由于⾃⾝电⼦设计和机器视觉的背景，早期的项⽬经历，让我涉猎了各领域的技
术，包括电⼦设计、嵌⼊式软件、互联⽹全栈、移动端 app、操作系统、渲染引
擎、内核驱动、⼯业控制现场总线等，每⼀个部分都不敢说有多么精通，但都经历
过实际的项⽬。对车这个领域，并不是专业出⾝，之前了解并不多，但为了能理解
⼀帮传统汽车⼈在想什么，也是恶补了博世系列的⼗⼏本关于车辆⼯程、汽车电
⼦、电⼦电⽓架构、动⼒系统等⽅⾯的书。多领域的涉猎也给这个系列的主题，提
供了不同的视⾓。
第⼀篇
⼀、互联⽹与传统汽车⼈的碰撞
在这个领域探索了⼏年，⼀个感悟就是，百年汽车⼯业，任何⼈也不要妄谈颠覆，但是也绝对不能拒绝进化。汽车界⼀直都有所谓的“传统派”与“互联⽹派”之间的话题争论。传统派与互联⽹派都有⾃⼰的优点，但却是有明确的领域限制的，⽐如互联⽹所倡导的以⽤户为中⼼，持续打磨产品和服务的设计理念，对于传统汽车⾏业的确有⾮常⼤的帮助。但是对于过程中所惯⽤的敏捷开发，快速迭代，却并不能完全套⽤，⾄少是有⼀定前提的。敏捷开发的前提有两个，标准化的基础设施的⽀持，并且需要有良好的架构设计。
互联⽹领域，部署代码的主要有，电脑端、移动端、服务端。每个端操作系统、应⽤开发框架、开发⼯具都⾮常标准，但如果是⼀辆传统架构的汽车，有⼏⼗上百个 ECU，⽽且还来⾃于不同的供应商，系统集成的复杂度不是线性⽽是指数级别的增加，不得不有⼀套严苛的流程去规范整个开发流程。
⼆、从电⼦电⽓架构的演进看软件开发分⼯的变化
电⼦电⽓架构EEA（Electrical/Electronic Architecture），最先是由德尔福公司提出的。汽车作为⼀个复杂的电⼦系统，按照传统定义，可以划分为车⾝、底盘、动⼒、信息娱乐、辅助驾驶等⼏⼤⼦系统；每个⼦系统⼜由多个电控单元 (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操作系统的定义
操作系统是⼀种管理计算机硬件与软件资源的计算机程序，⼤众所知道的其实都是很泛化的操作系统概念，常见的概念分为四个层次。
类型代表特点
内核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结合了微内核与宏内核的好处
微内核的好处是⼩、稳定，可以实现 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场景下⼤家探索的⽅向，对于车载环境有很强的借鉴意义。
⾃动驾驶
以算法与数据的积累为核⼼驱动⼒，可以在技术上形成壁垒，但是需要巨额的研发投⼊，能否快速落地主要受制于数字系统架构。短期来讲⼤家可能都差不多，但是积累到⼀定时间，后发玩家可能就再也追不上了。
数字系统
以架构设计与资源整合为核⼼驱动⼒，其包含了传统意义上的电⼦电⽓架构，但需要横向整合多个软硬件架构部门，才能定义完整的系统架构。是否采⽤新架构从根本上决定了，智能座舱与⾃动驾驶究竟能⾛多快⾛多远。
良好的数字系统架构，能够屏蔽底层车型平台的差异，多个车型共⽤⼀套基础软硬件平台，能够缩减开发资源，⼀套架构持续５年，可以留出充⾜的资源研发下⼀代。
第⼆篇
上⼀篇⽂章主要介绍了电⼦电⽓架构、车载操作系统、基础软件平台等之间的关系，以及软件定义汽车的基本概念，本篇将继续深⼊，重点阐述三个问题：
智能电动汽车软件范畴
软件+硬件升级的基础
⾯向服务的软件架构设计
⼀、智能电动汽车软件范畴
按照新能源汽车的特点以及中央计算电⼦电⽓架构的发展趋势，可以按照以下三个类别，对智能汽车软件进⾏分类：动⼒与底盘控制器、车⾝控制器、中央计算单元。
智能电动汽车软件分类.jpg
动⼒与底盘控制器
底盘类的功能，包括电⼦转向（EPS）、电⼦驻车（EPB）、车⾝稳定（ESP）、集成动态制动（IDB）
等等，都是牢牢的掌握在了⼀线Tier⼿⾥，这部分软件都是和机械零部件绑定在⼀起的，在其整个⽣命周期内不会发⽣功能的改变（可能会重新标定新的参数），实现的是车辆运⾏最基本的、有最⾼功能安全等级要求的、微秒级时延的功能。所以即使是在集中式的电⼦电⽓架构下，未来很长⼀段时间，这部分功能都会以独⽴ECU的⽅式存在，遵守Classic AutoSAR标准进⾏开发。
在“动⼒与底盘”控制器中，整车⼚唯⼀可以做并且⾮常有必要的是，提供⼀个底盘域的适配层，为中央计算单元提供标准的线控服务，这样以来，中央计算单元就不⽤单独和各个底盘ECU通信（不同车型可能使⽤了不同Tier1的产品），可以做到中央计算单元和车型平台解耦。
动⼒类包含了新能源三⼤核⼼技术，整车控制器（VCU）、电机控制器（MCU）和电池管理系统（BMS），其中VCU通过采集油门踏板、挡位、刹车踏板等信号来判断驾驶员的驾驶意图；通过监测车辆状态（车速、温度等）信息，向动⼒系统、动⼒电池系统发送车辆的运⾏状态控制指令。BMS负责估测动⼒电池组的荷电状态 SOC，即电池剩余电量，保证SOC维持在合理的范围内，同时监测电池充放电过程中的温度、电流、电压等，保持整组电池运⾏的可靠性和⾼效性。MCU系统根据数学模型，采集位置、电流信号，对IGBT进⾏通断控制，形成交变磁场，从⽽控制电机按⽬标进⾏运转。这三⼤部件对整车性能有着重要影响。越来越多的主机⼚选择⾃⼰进⾏开发，也就有了往集成化⽅向发展的基础，可以逐步将功能迁移到“底盘与动⼒”控制器当中去。
车⾝控制器
传统也叫BCM，车⾝控制相关的功能包括，车门、车窗、天窗、⾬刮、照明、空调、空⽓净化、⽆钥匙进⼊等等，整车⼚对这部分具有很⾼的决定权，现存的绝⼤部分ECU上的功能都可以搬到车⾝控制器上去，按照开关、传感器、执⾏器的维度对原有ECU的功能进⾏分解，主机⼚可以⾃⼰开发，也可以要求Tier1按照规范提供软件模块，由主机⼚进⾏集成。
中央计算单元
中央计算单元的集成的三个重要模块分别是⾃动驾驶、智能座舱、通信单元。为什么把这三块放在⼀起，下⼀章会详细介绍，本节重点介绍其内容。
⾃动驾驶，软件上具体的要做的事情，上⼀篇有过介绍，其核⼼是算法和数据的积累，稍微有点实⼒的主机⼚都不会放弃⾃主研发，因为⼀旦掉队，短时间追不上来，也将彻底沦为硬件的代⼯⼚，这是⼀个需要长期⾼投⼊的领域，在这个领域当中，主机⼚、算法商、Tier1等各⾃
的分⼯，也都还在探索当中。传感器与芯⽚算⼒，是发展中的主要制约因素。
智能座舱，各个主机⼚都在做，其技术和⽣态是消费电⼦在车场景的延展，⼀般会选择⼀家互联⽹公司合作，其核⼼还是围绕了⼈机交互展开，探索⼈与设备之间的关系，⽬前最主要的两⼤交互⽅式就是触屏+语⾳，对整车硬件的智能化的⽔平有很⾼的要求，但是车载硬件算⼒的滞后特性，导致功能体验不如消费电⼦。
通信单元，也叫TBOX，是车与外界联系的枢纽，⽬前主要实现的功能，如远程车控、远程诊断、整车OTA、国地标数据采集等等，与车的联系⾮常紧密，主机⼚⼀般都会⾃⼰开发上⾯的应⽤软件。其发展和通信标准的强相关，⽐如4G到5G的切换，未来技术上影响较⼤的因素是V2X，其发展会改变⽬前的软硬件架构。
⼆、软件+硬件皆可升级的基础
软件OTA的能⼒，各家主机⼚⽬前都已经具备了，相⽐于传统的汽车，软件OTA在⼀定周期上给汽车注⼊了新的活⼒，但依然会碰到算⼒的天花板。汽车的机械零部件，出⼚之后，其功能整个⽣命周期都不会发⽣变化，但是中央计算单元，其发展始终跟随最新的ICT技术，在车的⽣命周期当中，算法、芯⽚、通信标准等会不断的更迭换代，车的⽣命周期都在5年以上，但相关的ICT技术，基本2年就会有⼀个⼤变样。⽤户不可能像换⼿机去⼀样去换汽车，既然不能换车，为什么不能让⽤户可以升级中央计算单元呢？升级中央计算单元硬件，特斯拉已经在这么做了！为什么传统主机⼚以前在这⽅⾯不作为呢？
还是卖硬件的⽼思维，⼀次性买卖，没有升级零部件的动⼒！
喜欢搞各种花式车型，每个车型为了体现差异，还要改改硬件、⽐如多装⼀块屏，改改屏幕分辨率，竖屏改横屏，等等！
底层车型电⼦电⽓架构还不统⼀，换⼀家⼚商的零部件，信号就得重新适配！
对智能化不重视，软件能⼒差，⽆能⼒架构跨平台的软件基础设施
以上⼏个原因，导致了软硬件⽆法形成平台化，原本羸弱的资源，全部耗散在了⽆限的车型适配⼯作当中，根本没有资源提前去研发下⼀代平台，如此产⽣恶性循环。写这段的时候，我还是有点激动，曾经加班加点，就是为了把同样的⼯作适配到⼗多款车型，毕竟也是为此耗散过青春！Tier1的朋友们倒是很开⼼，反正只要给钱，主机⼚愿意改，他们就愿意接！
不仅要在⽤户看得到的功能上下功夫，还要在软件的⼯程能⼒上下功夫，重视架构设计，否则⼀旦历史的包袱积累到⼀定程度，连重构的勇⽓都会丧失！作为中国⾼科技公司的代表，连任正⾮都喊出了华为要加⼤投⼊，提⾼软件能⼒的⼝号！
如何能够做到中央计算单元的软硬皆可升级，才是真正考验软硬件架构能⼒的课题，特斯拉已经开了个好头，就看接下来追上去的是谁。
动⼒与底盘控制器、车⾝控制器，其核⼼软硬件设计⽬标，是要为中央计算单元提供良好的服务接⼝，让中央计算单元既能够灵活调⽤，同时也保持松耦合关系，终极⽬标是实现软硬件皆可升级。
三、⾯向服务的架构设计
在传统的离散架构下，车内的ECU通过总线相互通信，但是它们之间的信号收发关系和路由信息都是静态的，是在编译阶段写死的。各个ECU会周期性的发出各种信号，如果需要在另外⼀个⼦⽹当中使⽤，还需要⽹关进⾏转发，出于负载的考虑，⽹关通常不会把所有信号都转发，如果预先定义功能中，不包含某个信号，⽽后续⼜要使⽤，除了修改业务所在单元之外，还需要对⽹关的配置进⾏修改。
如果车辆上市后，想在某个控制器上新增功能，可以通过OTA更新该控制器的软件，但是这个功能需要的其他控制器的信号怎么解决呢？当然，也可以把所依赖的控制器都OTA⼀遍，但这个⼯作量与同时OTA的控制器的数量是指数关系，新架构上升级⼀个控制器，⼀个⽉就能解决的事情，在⽼的架构上可能需要⼀年。
⾯向服务的架构（Service-Oriented Architecture，SOA），是⼀种架构设计思想，它将应⽤程序的不同功能单元（称为服务）通过这些服务之间定义良好的接⼝和契约联系起来。接⼝是采⽤中⽴的⽅式进⾏定义的，它应该独⽴于实现服务的硬件平台、操作系统和编程语⾔。这使得构建在各种这样的系统中的服务可以以⼀种统⼀和通⽤的⽅式进⾏交互。SOA在互联⽹IT 中有很多应⽤案例，和微服务的架构有相似的地⽅，具体可以参考SOA和微服务架构的区别。
简单来说，SOA就是要求各个控制器，把⾃⼰的能⼒，以服务的⽅式提供出来，以此来构建⼀个与车型、芯⽚、操作系统⽆关的灵活可变的平台系统。
服务内⾼内聚，功能完整，可复⽤
服务间低耦合，⽆依赖
服务通信接⼝标准化，不依赖于平台实现。
下⾯举个例⼦来说明，在中央计算电⼦电⽓架构下，以以太⽹为通信⽅式，把各个控制器提供的功能按服务的维度进⾏拆解（以下只是⽰意，主要为了讲清楚原理，服务的分类、拆解、分层，是⼀个架构设计的细活⼉，是⼀个系统性的⼯作）。