软件定义汽车，变的到底是什么?

我们现在常听人说车上的软件代码要奔着2-3亿行的量级去，并且列举软件价值在车内占比来形容“软件定义汽车”。我们感觉这还是个不容易让人产生概念的形容方式。

其实“软件定义XX”这个样式的短语一点都不稀奇。对于电子产品而言，软件和硬件都必须同时存在——只是随时代变迁，这两者的角色在发生变化。我们认为，软件定义XX的本质，是软硬件逐步脱钩、解耦合的过程，在任何提这个词的领域皆如是。换句话说，应该是将原本的硬件平台、硬编码的固件/ROM之能力，带入软件层——而该软件层跑在标准化的硬件上，也就实现了软件定义。

“软件定义XX”最具说服力的例子就是手机从功能机向智能机的转变。早期，手机的硬件和软件是在产线上就做了捆绑的——除非手机在售出后遭遇重大BUG才考虑做软件更新。当年诺基亚手机的主芯片(CPU)就是这样持续数代不换，依然无人置喙，与软硬捆绑还是有很大的关系。汽车的情况又何尝不是如此：想要汽车拥有新功能吗?就再买辆新车吧!

如今，智能手机通过解耦软硬件改变了这样的模式，智能手机本身成为硬件平台。手机制造商能够打造定制的操作系统，并定期推送OTA更新;而更上层的应用，则千变万化，负责着大量功能的实现。

可以说智能手机本质上就是一种“软件定义手机”。至少在大方向上，它与“软件定义汽车”“软件定义网络”“软件定义测试测量”是一样的。

而软件定义XX，本身就是一个类型的设备在电子化、数字化过程中发展到高级阶段的表现。汽车在电动化、电子化之路上，也要迎来这种转变。只不过汽车这样的复杂大件，及行业、产业链的特殊性，又令“软件定义汽车”多少有些与众不同。

软件定义汽车，变的到底是什么?

更早年的汽车经历了机械定义、硬件定义的时代，到如今软件定义的说辞风生水起，实则反映的是电子科技话语权在汽车产品上的提升，以及汽车产业、电子科技二者的发展。这每一次革新，首先都意味着电子电气(E/E)架构的变化。

从内部连接的角度来看，机械定义汽车是将车内的各种物件(如ECU、传感器、仪表等)有需要的就点对点连起来——在E/E架构变复杂的情况下，这种方案是不可持续的;硬件定义汽车则增加了总线的概念，以分布式控制的方式来打造一个开放式系统，具备了显著增强的灵活性。

图1：汽车 E/E架构的演进。

但这样的方案也逐渐不再适用当代数字化转型的大趋势，不同的组件各自为政，可扩展性差。就像早年的功能手机那样，当软硬件捆绑在一起、可扩展性又极度欠缺之时，应对需求变化就显得相当迟缓。软件定义汽车首先需要对E/E架构进行革命性的改变：将不同的总线、控制等做合并，做更统一的部署——也就是这两年经常看到来自博世的E/E架构演进的一张图(图1);将150多个ECU做各种融合，同时还要软硬解耦，实现更强的灵活性。

举个简单的例子：软件定义汽车时代，整车厂现在不再是要求传统Tier 1供应商设计各自带ECU的电动座椅系统出来，而是需要协调软件开发，以通用、标准化的方式做个车内平台——电动座椅不过是其中的一环罢了。

从另一个更抽象的角度来看，SBD Automotive将这样的变化称作汽车1.0到汽车4.0的发展。

汽车1.0时代是没有任何“连接”的基础功能汽车;汽车2.0则发展出了数字化技术，引入了信息娱乐系统(infotainment)以及数字座舱，而且提供高速连接，甚至音乐流媒体、某种程度的软件更新——这类车目前仍然活跃于市场。

汽车3.0就是可升级的汽车了。相对重要的一些特性包括自动驾驶、ADAS、智能座舱以及车联网等特性的引入。体现“软件定义”的核心则在于，其中的很多特性、体验可以更新升级;而且软件更新会以更常规的节奏来推送。如此一来汽车也就成为并非一次性销售产品，软件服务和数字经济也将成为整车厂或其它供应商的重要收益构成。

而所谓的汽车4.0，在SBD Automotive的定义中是“真正的”软件定义汽车。届时汽车将成为云的延伸，跑在车上的软件可由云上的中央运行环境来进行主导控制，或者协同其它车联网内的汽车算力，来进行高性能计算，实现自动驾驶、智慧城市等特性。这就是对未来的展望了。

技术上的变

实现软件定义汽车，最底层的E/E架构转变、诸多ECU融合、有个核心骨干负责整个计算域的过程，这个过程就是让汽车从传统E/E架构，某种程度让汽车变身到往高性能计算机接上四个轮子的过程。绝大部分相关用户体验组件的软件都放在这个高性能计算机里面。

除了E/E底层架构需要变，对应的软件定义汽车的上层构建过程也就起来了。平台与中间件、操作系统与虚拟化都随之而来。毕竟在底层准备就绪以后，软硬解耦的软件部分也需要重新整合堆砌。或者说就像数据中心的工作方式，对外服务的过程，就需要诸多软件层面的技术。

其中平台与中间件层的主要功能，是对硬件进行抽象，做到软硬解耦。那么开发者就能利用中间层的接口，来开发功能、特性，也确保这些功能特性不需要与底层硬件直接挂钩。随着这部分的成熟，汽车应用开发者因此可以脱离于汽车之外进行软件的开发测试;而且不需要太多汽车方面的专业知识。与此同时，硬件迁移也变得更简单、高效。最终实现降本增效。

图2：AUTOSAR的参与者。

当代软件定义汽车发展的中间件代表为AUTOSAR(Automotive Open System Architecture)——这是个由诸多整车厂、零部件企业联合制定的软件标准化接口，或者说开放式系统架构标准。加入标准中的企业不仅有传统汽车产业相关的企业，也有工具与服务及半导体相关厂商，比如说英飞凌、瑞萨、恩智浦、Arm、西门子 EDA等等。因为这本身就是需要上下游充分协同的。值得一提的是，中间件相关的一个重要组成部分是SOA(Service Orimented Communication)模型通信中间件，这是另一个很大的话题了。

理想情况下，平台与中间件层出现的另一个重要价值，也在于构建更为统一的平台。车企、开发者不需要忙于去处理各种类型的硬件。用其他行业的话来说，叫尽可能地解决“碎片化”问题，虽然这可能也只是理想情况。

至于操作系统与虚拟化，很多车企如今都在这方面发力，比如说大众汽车的vw.os。软件定义汽车可能会跑多个操作系统，负责不同的工作——比如说会有实时操作系统，会有通过AUTOSAR-Adaptive提供传感器数据处理的Linux操作系统等。

前两年我们撰文谈过BlackBerry QNX，这似乎是个更能表达软件定义汽车的、介于底层硬件和上层应用之间的组成部分的技术。当时面向汽车领域的BlackBerry QNX至少包括了QNX Neutrino OS(操作系统)、QNX Platform for ADAS(针对ADAS的平台)、QNX OS for Safety(安全操作系统)、QNX CAR Platform for Infotainment(针对汽车信息娱乐系统的平台)、QNX Hypervisor、QNX acoustics middleware(声学中间件)。

图3：BlackBerry QNX技术及各部分所在的层级。

藉由图3这张来自BlackBerry的图，可简单窥见其中部分软件的层级结构。

当然这其中实则也出现了其他层级，在往上层还牵扯到车厂品牌差异化的组成部分，涵盖信息娱乐系统、数字座舱系统、ADAS系统等。这些应用的发展也配合着对云服务的支持。而云会是整个架构的最上层，包括了ADAS服务、OTA服务等。当然支撑这个最上层的，也需要5G、V2X等基础设施。

图4：汽车未来的层级架构。(图片来源：McKinsey&Company)

对这部分技术感兴趣的读者，可以去看一看2019年麦肯锡发布的《重新思考汽车软件与电子设备架构》报告，其中提到ECU加速融合、不同栈的标准化、中间件层对硬件做抽象等趋势。这些趋势都是在持续行进中的。从中我们也能够看出，为什么软件的价值在整车中占比越来越高，以及2-3亿行代码缘何而来。

新的参与者，和产业链结构的变

或许很多驾车者认为软件更新没什么了不得，并不值得大书特书。但我们展望中的OTA对于软件的更新，并不仅限于信息娱乐系统、远程信息处理或车辆诊断系统(而且传统的这些软件更新还并非OTA)，更多的会往汽车核心功能的监控、调节去走，比如说动力系统。或许在未来的OTA更新过后，转向系统就能实现更精准的控制，ADAS获得辅助公路驾车的新特性，甚至基于电池循环周期的分析来实现续航里程的增加，以及在汽车发售之初根本没有想到，或受限于开发生命周期、尚未完成的新特性。

比较典型的例子是特斯拉曾经通过OTA更新，降低了Model 3的制动距离。这种转变事实上带来前文提到的，汽车不再是一次性消费产品，汽车产业也能够开始从提供的数字服务甚至更新中获利。去年Arm曾表示软件定义汽车，可以为车厂创造每辆车“多达2600-7500美金的额外利润”。对车企而言，OTA也意味着部分特性、功能开发周期的放宽(典型如自动驾驶这类很难与整车研发周期配合到位的组成)。

未来、甚至今天的汽车消费用户会更加注重“软件定义”部分，比如说驾驶辅助特性、信息娱乐系统上的数字内容，乃至智能连接解决方案;而将更少的注意力放在诸如排气系统之类的机械特性上。前不久我们在采访黑芝麻智能之时，黑芝麻就谈到，一些4S店反馈现在已经开始有购车者问车的算力是“多少T了”——AI芯片本身也可认为是软件定义汽车的重要组成部分。

以上这两点：软件更新带来的新特性、消费者注意力转变，都能够管中一窥地发现，汽车产业正在发生变化。至少这是业务模型的变化。

从最简单的层面来看，汽车电子化及软件定义的特性，为行业带来了新的参与者。比较典型的除了前文提到的BlackBerry，还有像是Red Hat。Red Hat将软件定义汽车比作边缘计算服务器，且明确这样的边缘设备理应包含现代基于Linux的操作系统和生态——必须包含开源与专有组件。Red Hat自认可从行业分一杯羹的根源在于其擅长包括Linux、容器、中间件集成、DevOps架构等在内的能力，甚至把原本构建企业开源层的经验带到汽车上。

图5：SOAFEE框架结构及组成。(图片来源：Arm)

另一个我们认为颇具代表性的市场参与者是Arm。去年我们也特别报道了Arm提出的SOAFEE(Scalable Open Architecture For Embedded Edge)架构：这是在软件定义汽车一词正火之际，趁热打铁提出的统一的软件定义汽车平台。毕竟软件定义汽车的技术栈复杂度、投入是相当高的。SOAFEE构建起了框架，和整个软件栈中的基础软件部分和参考实施方案;且明确了功能与服务在云端环境中开发、测试和验证——这和前文谈到SBD定义的汽车4.0趋势相符。

SOAFEE的本质是要实现硬件和软件界面的标准化。而且作为一个开放、开源的架构，底层硬件部分Arm也准备吸收不同的硬件、IP。这个架构据说也得到了不少包括整车厂、Tier 1供应商，乃至软件、半导体和云技术相关企业的关注和加入。SOAFEE的出现至少让我们能看到，软件定义汽车步入成熟的开端(虽然由Arm这个传统意义上的芯片设计IP供应商提出，还是让人感觉颇为意外)。

这些新角色的加入，事实上就会造成产业链价值分配的变化，乃至产业链结构的重整。在“软件定义汽车”的“软件”一词上，越来越多的车企开始投入人力物力：造车新势力本就在这方面发力，传统车企也不甘落后。比如去年下半年，丰田就宣布要投入超过18000人进行软件和连接计划。

要知道其中的某些工作原本应该是由Tier 1供应商承担的。以前整车厂会对Tier 1供应商提出具体的组件需求，供应商不仅要整合包括控制器在内的硬件，也需要进行软件开发和测试。那么在软件定义汽车大趋势展开后，汽车制造商可能会选择开发大部分所需软件，甚至有自己的平台、特定的一群软件合作伙伴;则Tier 1供应商此后就需要对自己做重新定位。

现在Tier 0.5这个词也被时常提起，某些Tier 1供应商会让企业内的专家与整车厂的开发团队协作，联合开发软件并做运维(也有Tier 2也在变身Tier 0.5)。在此，供应商几乎成为OEM厂商的一部分，也从系统集成中产生营收。博世就有这样的例子。在软件定义汽车做标准接口、整车厂自己解决软件问题或找三方软件合作伙伴开发应用之际，许多传统的Tier 1特别害怕自己沦为单纯的硬件供应商。

去年年末的Aspencore国际汽车电子创新发展论坛上，均胜电子曾表示从过去OEM厂商直接拿turn-key方案，到如今主导软件硬件定义。从过去Tier 1负责40%个性化开发、60%标准开发，到现在做100%的标准开发;“Tier 1将专注于模块化、平台化的开发，模块迭代速度大幅提升;更高的标准化支持，同时服务更多客户;且Tier 1将逐渐头部化”。而对Tier 2而言，“集成化程度越来越高，技术难度越来越大，通过技术壁垒才能形成行业优势”。

可见汽车产业链的不同角色职能是在发生变化的，尤其传统汽车产业的供应链上游似乎变得更不好“混”了。

技术难度之外的发展阻碍

具备“革命”能力的事物，在革命的同时必然遭遇阻碍。诸多传统车厂存在历史悠久，组织机构庞大复杂，有些还牵扯很多品牌。他们早有一套特定的工作方式在推进。而软件定义汽车，如前文所述需要全新的方式和思维来重新考虑汽车开发生命周期的问题，还需要车厂具备全新的能力。

则对传统车厂而言，转变的第一步就是自我调整，打造新的工作流程和业务模型;而且需要进行现有员工的技能培训，以及扩招原属于其他领域的人才;并寻找新的合作伙伴。这些大约都不是一朝一夕的。单是在E/E架构上做大改，技术之外更多面临的可能仍是现实中人的阻碍。

与此同时，如前文所述旧时代的产业链和配合方式很可能已经不再适用于软件定义汽车时代。则整车厂、Tier 1、Tier 2、Tier 3等不同层级供应商之间的合作、博弈还将做出新的调整，市场或许还会有新的发展方向。

另外本文仍有许多相关软件定义汽车的关键部分未曾提及，比如说网络安全(cybersecurity)——这必将成为软件定义汽车时代的技术热点与难点。不仅是改变开发流程，而且也会引入新的市场参与者和发展热点。

“软件定义汽车”这一局的“变”属实还有的瞧。

审核编辑 ：李倩