编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。
本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。
写在前面：昨天我断更一天没有录音，因为临时出差晚上一直在飞机上，错过了录音的时间，在此向大家道歉。
自从开了这个音频栏目后，我差不多每天傍晚 7 点半左右下班，就开始想今天要录点什么内容。晚上 9 点半将文稿的提纲写好，然后对文稿信息的准确性查阅相关资料确认，大约 10 点半左右录音完成，再请编辑小伙伴制作和整理文稿。所以大家会发现，这个音频节目都是差不多接近 12 点的时候才制作完成上线的。
我发现这个制作机制太脆弱了，万一出差（或其他原因）就会断更，我本周末要多录几段儿囤着，也不能老让编辑小伙伴凌晨时候着急忙慌做音频和排版。
在此，对所有为这个小栏目付出辛劳的小伙伴表示衷心感谢。
今天分享的内容源自德国汽车制造商戴姆勒 CEO Ola Kallenius（康林松）在接受德国《商报》采访时提到：
戴姆勒计划为汽车开发软件操作系统（Windows for Cars），同时戴姆勒将开发用于导航、语音控制、音乐、电话通讯，刹车系统、安全气囊控制等一系列的汽车软件。
其实早在今年 1 月拉斯维加斯 的 CES 展上，戴姆勒已经介绍了自家操作系统 MB.OS。
戴姆勒希望在公司内部建立软件开发自研的能力，来替换来自外部的供应商的技术服务。
大概在 2024 年至 2025 年，戴姆勒车辆上的软件操作系统将完成向 MB.OS 的转换。
大家可能对「汽车软件操作系统」这个概念还比较陌生，但是对操作系统本身，应该是比较熟悉。
比如我们日常在电脑上使用的 Windows 操作系统，Linux 操作系统，又或者在手机上使用的 iOS 和安卓。
严谨一点说，操作系统是管理和调度计算机硬件与软件资源的计算机程序。
操作系统需要处理很多的任务，比如，管理与配置内存、决定系统资源供需的优先次序、控制输入设备与输出设备等等。同时，操作系统也能够提供一个让用户与系统交互的界面。
类似的，以目前智能驾驶辅助系统开发流程为例，主要包含了硬件开发、软件开发、系统集成、功能标定测试等等，在这之中软件开发中又分为应用层软件开发、中间件和系统级基础软件平台。
而戴姆勒目前计划开发的部分，几乎涵盖了软件开发中的所有部分。
可以这么讲，戴姆勒的野心是要为行业打造一个跨域的真正为智能汽车量身定制的系统。
而现阶段，我们在量产中广泛使用的 QNX 是黑莓公司当年为黑莓手机研发系统的改进版。
戴姆勒计划开发的车载操作系统 MB.OS 并不是像有些主机厂，仅仅基于安卓做 UI 的修改，通过改变用户的交互界面和操作逻辑体现个性化，它更类似于从底层创建一个汽车的安卓或者 iOS，将软件部分与硬件部分进行解耦，从而减少后期应用软件在适配不同硬件时复杂的重复性工作。
除了戴姆勒，大众集团于 2018 年宣布正在为整个产品线开发新的软件操作系统 vw.os，并从 2020 年起，大众品牌的电动汽车都将采用该操作系统。
理想汽车目前也在内部孵化一个 LiOS 项目，开发自主软件操作系统。
斑马智行基于 AliOS 系统开发了斑马智行车载操作系统，而 AliOS 系统实际的内核是 Linux。
当然，还有大家都熟悉的华为的鸿蒙操作系统。
为什么这么多企业都关注于在车载操作系统的开发呢？
科技公司做系统开发还有情可原，戴姆勒、大众这样的主机厂有必要做车载操作系统的开发吗？
我个人从技术的观点出发，认为戴姆勒、大众目前开展的软件操作系统开发是十分有必要的。
原因简要总结为以下三点：
第一，随着操作系统自主化开发，硬件和软件之间的可解耦性也变得越来越清晰。
每一个车型都会存在传感器型号不同、控制器芯片与架构不同等问题，之前部署应用软件在不同的车型中时，会针对每一款车型的硬件平台做定制化的软件适配与部署。
如果软件与硬件可以实现解耦，只需通过调整操作系统与不同硬件平台的适配，就可以将应用软件部署在新的硬件平台中，同时操作系统与不同硬件平台的适配工作量是远远小于应用软件直接和硬件平台进行适配的工作量的。
第二，未来的软件定义汽车的趋势可期。
如果车载操作系统是由主机厂主导设计的，在推向市场后会更容易对汽车进行 OTA 升级。
在功能应用场景新增与扩展，使用逻辑、人机交互策略更新时，则更容易由主机厂主导进行，而不是完全依赖于不同的供应商。
第三，数据在未来的智能驾驶上，扮演着越来越重要的角色。
主机厂如果需要保证用户在车辆使用过程中数据的所有权，车载操作系统在这其中扮演的至关重要的一环。
汽车的车载操作系统开发，只有对其内核、运转机理等研究得越深，主机厂在后续部署其应用软件时能参与的部分才越多，对应主机厂软件开发的自由度才越高。
比如说目前在研究 L4 级别的自动驾驶时，一般是选择 Linux 操作系统，在上面通过 ROS 来搭建一种信息交互的通信框架，这样在开发过程中，应用软件开发工程师可以更聚焦在节点上功能的实现。
由于 ROS 的开源、松耦合运行设计、支持多种开发语言，目前使用 ROS 进行自动驾驶开发时有着很大的便利性。
但是在真正量产的时候，因为 ROS 并没有解决数据实时性传输、数据加密以及数据传输量等问题，所以在实际使用过程中采取 Linux 和 ROS 这样的搭配较少，行业确实需要更加简单、易用、可靠、科学的车载操作系统。
除此之外，Linux 并没有拿到行业功能安全的认证，而如果使用黑莓的 QNX 车载操作系统，其虽已经获得功能安全认证，但是作为未来支持更高级别自动驾驶的系统，还是会存在信息安全、算法多核调度的优化空间。
一方面我们在等待 QNX 系统的升级，另外一方面，各个大厂开始寻找更加彻底的解决方案——自研操作系统，逐步支持未来智能座舱、车载娱乐、L2.9/L3/L4 乃至更高级的自动驾驶的软件开发。
正如大众汽车集团在 2019 年宣布将成为一家软件驱动的汽车公司，其计划通过组建一个 5000 人以上数字化专家团队来负责车辆内的软件开发，并在 2025 年实现内部车辆软件开发占比从 2019 年不足 10% 提高到至少 60%。
传统的汽车主机厂正在试图借助智能驾驶的发展，从车辆销售转变为车辆服务销售。而车辆本身更多的是一个技术的载体。
我们拿手机做类比，手机生态的利润，有不少是通过销售手机软件应用来实现的。
而汽车的利润模式，在未来很可能变成主要提供软件和数据服务，而车辆本身，不过是实现服务的场景罢了。
参考目前特斯拉的销售模式，Autopilot 的售价在中国区为 56000 元人民币，用户购买 Autopilot 后，系统的性能表现在不断地通过 OTA 升级变强，用户的购买意愿和对 Autopilot 的可感知价值都是非常可观的。
我想起 2018 年特斯拉通过 OTA 的升级，将其高速行驶时紧急制动的制动距离缩短了约 6 米。
我当时是非常震惊的，这对整车电子电器架构的支持，和底盘的一致性调教的要求是非常高的。
特斯拉能做到这一点，也是基于其内部拥有大量的软件工程师和软件开发平台的自主化。
在之前的音频中我也提到，特斯拉计划在今年打造一个类似 Uber、滴滴的智能手机应用，用户可以通过该应用呼叫 Robotaxi 自动驾驶出租车服务，并支持特斯拉车主将其车辆加入 Robotaxi 网络。
这也是软件和服务商业化的典型案例。
做一个简短的总结：从车辆制造商到移动出行提供商，未来留给车辆制造企业的想象空间还是很大的。新一代电子电器架构、域控制器的发展、车载软件操作系统等，都在技术层面让未来的汽车和商业模式更值得期待。
往期回顾：
传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？
本期制作
主讲：郭继舜 监制：王德芙
编辑：叶方 后期：陆非
设计：陈溪阳 运营：林芝芝
音频平台
喜马拉雅 | 蜻蜓 FM | 听伴
Podcasts | 小鹅通
在以上平台搜索关注汽车之心
即可收听全部节目
用户评论