本文由《汽车软件架构》译者根据译者序改写，原文撰写于2020年3月，两年过去，作者对其中一些观点补充了行业最新的实践。本文对“软件定义汽车”这一概念进行了全面概述，内容包括：
1. 对软件能否定义汽车的思辨
2. 透过历史，如何定义“定义汽车”
3. 对汽车软件生态全栈的拆分解析
4. 如何站在历史的角度看待这场变革的本质
5. 这场变革为汽车行业及企业带来的挑战
其中包含一些作者对汽车行业及汽车软件的观点，其结论未必绝对，但文中对汽车及消费电子等行业历史的思考、对出行本质的探讨、对汽车软件全景的总结，以及对汽车软件相关的行业新议题的分析仍值得借鉴，有助于相关从业者更思辨地判断行业的未来。正可谓“栽来无别用，只要引清风”。
软件能定义汽车吗？一些存在漏洞的理由
当“软件定义汽车”已经妇孺皆知，一个灵魂拷问却始终困扰着我：
软件真的能定义汽车吗？
这一问题的结论也许并不重要，但通过刨根问底，有助于我们更好的理解汽车软件，更理性的看待这个时代。支持“软件能定义汽车”的理由，最常出现的是以下三种，它们似乎都存在不妥之处：
观点一：汽车和几年前的手机发展相似，如今手机硬件同质化严重，竞争力主要来自软件生态；所以几年后的汽车也会硬件标准化，并且软件通过与标准化硬件的解耦，成为汽车竞争力的决定性因素。
观点一的漏洞：这一观点相当主流。我们姑且不谈汽车会不会成为“大手机”，但手机硬件真的已经同质化了吗？那为何苹果、三星、华为、小米、OPPO等头部手机厂都在自研芯片，又为何华为手机会被美国卡脖子？当今全球的手机都在使用App Store及Google play两个高度同质化的软件生态，为什么消费者仍然愿意花近十倍的价格购买苹果、华为等高端机？如果我们看比手机历史更久的计算机行业，直到今日CPU、内存、显卡乃至轻量化材料等硬件仍是高端PC机的差异化卖点。
事实上，早在X86架构出现后，计算机领域的软硬件就以之为界出现解耦之势，但此后硬件和软件始终在交错发展。硬件领先时软件成为发展主旋律，随后一段时间内，在消费者需求带动下软件逐渐复杂化，硬件资源又成为了瓶颈。如今哪怕摩尔定律接近失效，头部PC企业仍未停止在硬件设计上的投入。似乎从没出现“先把硬件发展到头，再靠软件定义产品”的趋势。
计算机行业尚且如此，汽车行业过犹不及。无论是自动驾驶的线控技术和芯片技术、路车协同的MEC/RSU等，都有大量与软件算法无关的基础性问题尚未解决，类似计算机领域的软硬件交错前行甚至还未开始。而如果硬件的同质化难以发生，那软硬件解耦似乎就更难推动“软件定义汽车”了。解耦后的软硬件充其量只能在时间上实现同步开发，并不代表电子/机械硬件必须围绕软件来定义。诚然，软件在满足消费者需求上更灵活，但失败的代价也比硬件更小，硬件很难仅为了一个未经市场证明的软件/算法就去投入重资源进行升级、配合其批产。所以，与其说软件定义了汽车，还不如说“功能定义了汽车，软硬件齐头并进将功能实现”。
观点二：特斯拉开创了软件商品化的先河，未来依托于面向服务架构的汽车付费软件、订阅生态将是车企的核心竞争力。
观点二的漏洞：这一观点随着近年来SOA架构的落地愈发流行。持有这一观点的人常会举苹果靠软件生态战胜诺基亚的例子，并认为特斯拉是下一个苹果，如果传统车企不效仿就会像诺基亚一样被淘汰。但首先，苹果靠软件生态战胜诺基亚到底是不是事实就值得商榷。如果回看2007-2011年间的新闻和智能手机出货量变化，会发现苹果和Android软件生态也许只是压死诺基亚的最后一根稻草。在2007年App Store还未上架时，初代iPhone的问世就已经凭借简洁的外观、优秀的人机交互设计、高灵敏度大触屏、高效上网体验打得诺基亚节节败退，这些KSF似乎与软件关系不大。
其次，尽管FSD付费软件为特斯拉创造了相当的利润，但未必是吸引消费者购车的最关键要素。笔者身为特斯拉车主，购车时也同样看重其同等价格下的续航、快充、充电桩部署、造型、加速度、高灵敏中控大屏及并不鸡肋的人机交互设计，而支撑着这些优势的除了软件，行业领先的HW3.0、行业首个量产的SiC功率半导体、大电流超充等硬件、乃至业内一流的自动化和零库存管理等先进制造能力也同样关键。
再次，尽管SOA大幅提升了汽车软件的可拓展性，但在笔者看来，汽车软件未必真的会形成诸如App Store一样繁荣的生态。毕竟在另一个与人命相关的医药领域，一直在采用强制临床实验、严格准入上市、开处方购药的全周期“集权”模式，从未形成诸如手机软件般依靠SDK散养繁殖的高度开放生态。所以，不可否认，软件商品化及其背后的SOA架构已经成为了新时代车企的“必修课”，但它很难将汽车软件生态推动到手机软件生态般的丰富度；而就算汽车软件生态达到了这一丰富度，iPhone和特斯拉的例子都启发我们，也许仅靠繁荣开放的软件生态，仍难以定义汽车。
观点三：汽车的代码长度已经超过了其他消费电子品，因此汽车已经是靠软件驱动的商品了。
观点三的漏洞：这一观点从技术角度看漏洞显而易见，但因常被引用且具有一定误导性，有必要做个澄清。汽车代码规模庞大是事实，例如发动机控制代码算上xml文件已达700万行，远超普通的计算机软件。但这种观点并没有考虑到代码效率问题。
汽车的嵌入式软件要求硬实时性，对操作系统的运行时间开销要求严格，这意味着每个任务都有明确且个性的激活时刻和截止时刻，因而任务间的调度设计也必须逐一考虑到每两个任务在时间上的相互关系，这种相互关系往往因产品功能及硬件个性而异，因此软件可复用的库较少，通常需要采取近乎枚举法的编程方式，效率显然不高。而计算机软件多采用解释型语言，大量功能场景可以复用现成的库，引用库的代码仅需寥寥数笔且不需要像嵌入式系统的编译型语言一样转化为繁琐的C代码，即可实现强大功能。这就造成了软件驱动汽车发展的“假象”。汽车软件代码产出多，但并不代表软件对汽车有决定性。
总结：
诸如此类的观点还有很多，这些观点确实说明软件在汽车中变得更加重要了，但似乎并不能说明软件能定义汽车。所以，“软件定义汽车”的本质到底是什么？想要厘清这笔账，我们有必要回到最初的起点。
以史为鉴 如何定义“定义汽车”？
出于严谨，在分析“软件能否定义汽车”前，我们有必要搞清楚，到底什么样的创新才算得上“能定义汽车”。这个问题很大，不同人观点各异，笔者在此权当抛砖引玉。
先看一个故事。在1920年代末期，在福特T型车统治下的汽车行业普遍认为硬件已经同质化，难再有大突破，业界亟须为汽车找到新的卖点。1927年，通用汽车成立艺术与色彩部，在传奇人物Harley Earl的带领下，大量造型光怪陆离的汽车被设计出，引发了汽车的造型革命。一时间，汽车制造商将注意力都放在了内外饰的设计上，并依靠“汽车能体现车主个性”的宣传，压迫消费者为奇特的造型付更多的钱。直到1965年，一本名为《Unsafe at Any Speed》的书出版，全面抨击了汽车的过度设计及对安全的忽视，这场长达二十余年的造型风潮熄灭。
当我们回忆汽车的历史，我们很难说这一风潮重新定义了汽车，因为这场风潮中的多数产物都已难在当代汽车上看到影子。相反，我们至今仍能记住百年前首次为汽车加了外壳的福特T型车、六十年前的波尔舍甲壳虫、乔治亚罗高尔夫，它们的理念在今天的汽车造型设计上得到了传承，某种意义上可以称得上重新定义了汽车。深究它们与前者的区别，这些跨世之作都在设计了个性鲜明的造型同时，恰到好处地解决了当时人们的出行痛点。
所以，到底什么样的创新才算“能定义汽车”呢？如果回到本源，人类对社交的诉求和向往自由的灵魂让出行成为刚需；而对于出行，无论交通工具怎么变，人类的要求始终都是：
1. 安全到达目的地；
2. 在出行这件事上耗费的钱、时间、精力越少越好；
3. 在出行上获得更好的舒适性和愉悦感。
1和2是基础需求，而3则是进阶需求。
图1 人类出行需求的本质及满足需求的创新举例
如果归纳那些我们认为曾定义了汽车的变革，（对照上图）它们通常都使汽车在满足某一项人类出行需求（安全、消耗、舒适/愉悦）上取得了大幅度提升，同时又没有让已经得到满足的人类基本出行需求（安全及消耗）发生倒退。
后一条件中“基础”二字尤为关键，诸如舒适性和愉悦感等进阶需求通常千人千面，很难评价何为倒退。而对于基础性的需求，消费者对“需求被更好满足”有高度一致的判断，任何出现的倒退都难以被接受。历史上未能成功定义汽车的创新，问题多数并不在创新力度不够，而在于它们牺牲了原本已经得到满足的基础出行需求，尤其是那些与心理学相关的“精力消耗”维度，因为诸如“综合出行负荷增加”等难以量化的因素在短期内未必会被消费者察觉，因此当车企面对习惯被喂养的消费者时，仍能靠“新鲜感”来维持创新带来的虚假繁荣；可时间一长，一旦消费者感知到了负荷的增加，就可能引发焦虑和挫败感，从而产生对创新失去信任、甚至超越信任的报复行为，最终将功能弃用。
这和现在的汽车软件浪潮是否有几分贴切？表面上看，汽车的软件生态在不断繁荣，但其中也创造了相当多消费者不会使用的功能，这些功能本意想提升用户体验，但却向驾驶员提供了多余且无用的反馈，反而造成了驾驶员分心和焦虑。当这些功能被强行以高溢价卖给了消费者，尽管短期内能“唬住”消费者并引发了行业大流行，但我们真的能称之为 “重新定义了汽车”吗？
软件不能定义汽车
所以，软件到底能定义汽车吗？我们不妨将汽车上所有的软件拆开做逐一分析。我们采用AutoSAR的理念，将汽车软件拆成“传统控制”、“自动驾驶”、“智能座舱”、“非车载”四个域。最终我们将问题转化为：
1. 这些域中，哪些是仅靠软件就能定义的；
2. 这些仅靠软件就能定义的域，又能否定义汽车。在每个域中，我们又将软件拆分为基础软件（硬件驱动、任务调度及其他中间件）和应用层软件。
必须说明，这种分类并不唯一，这里只是为了将汽车软件拆分为互斥穷举的若干部分，便于分析。如下图所示，笔者将不同域的软件技术和商业特点进行了简要总结，如下图（后台回复“AES14”可获取高清版）。
图2 汽车软件构成简图
传统控制域的软件
其特点见上图不再赘述。首先，该域的嵌入式软件与其所关联的设定值发生器、传感器、执行器高度相关，单独的软件难以成为功能好坏的决定因素。其次，这类软件通常由提供控制器、执行器、智能传感器的Tier1直接开发。因为在编程中要考虑很多硬件的个性特征，所以难以形成行业通用的软件场景库，而Tier 1在对自家产品的配套软件开发中已长期积累了相当数量的代码，甚至形成了企业内部的子代码库。这就导致想扛过软件大旗的主机厂或科技公司哪怕编程能力再强，也很难取代前者，最多采取software sharing的方式，在应用层与消费者直接相关的功能软件中参与部分开发。显然，传统控制域无法仅凭软件来定义，且仅具备软件能力的企业也很难在此领域掀起波澜。
自动驾驶域的软件
其特点见上图不再赘述。该域的现状是，一方面底层操作系统既要安全关键，又因数据量大而需要采用动态任务及内存分配，门槛极高，多年来也只有四五家可做，难以成为引领软件定义汽车风潮的主导因素。而另一方面，尽管自动驾驶显然可以定义汽车，但暂时还没发展到可以完全依靠算法软件来定义的阶段。它在系统及硬件方面仍有众多工程化问题待解决，且当前行业话语权之争也不仅围绕软件算法，还围绕与硬件相关的计算平台和算力展开。另外如前所述，未来该域也很可能会出现与计算机行业类似的软硬件交替式发展现象。因此，我们也无法认为自动驾驶域是靠软件来定义的。
路侧及云侧的软件
其特点见上图不再赘述。首先，尽管该域的发展主要集中在算法及信息安全等依靠软件决定的领域，但它必须依附于车端的自动驾驶功能才能发挥最大价值。其次，该域内的硬件尽管要求相对车端低，成熟度也相对高，但仍有诸如车端实时性任务卸载时的延时、车辆高速移动时的信道衰落等通信及系统性问题待解决，这些不仅依靠算法的优化，也依靠路侧设备的硬件性能。从短期来看，至少在自动驾驶未实现大规模落地前，该域也难以定义汽车。
智能座舱域的软件
上述三个域被排除后，智能座舱就成了支持“软件能定义汽车”这一观点最后的希望。事实上，大多数人谈论软件定义汽车时，往往也是在谈论该域内偏向消费电子的软件功能给汽车带来的影响。对于消费电子和资本界而言，该域和手机相似，门槛低且创新空间大，是进入汽车行业的最佳入口。为了把“局”做大，甚至提出了与智能座舱配套的滑板底盘概念，认为未来的汽车 = 滑板底盘 + 智能座舱 + 路云协同。而在汽车行业内部，因为整车的议价能力降低，其他高溢价领域的门槛又太高（比如自动驾驶），所以也将智能座舱视为提升车辆利润的首要突破口。
似乎它确实具备能定义汽车的潜力？我们不妨拆成两个问题看：1.软件能否定义智能座舱？2. 智能座舱又能否定义汽车？仅就笔者个人来看，两者的答案暂时都是否定的。
首先，软件并不能定义智能座舱。还是从与智能座舱相似的手机领域切入。手机领域硬件同质化+软件差异化的商业模式确实存在，但高端手机无论是苹果、三星还是华为，都在持续迭代硬件。甚至在全世界手机厂都在共用App Store和Google play两个同质化极其严重的软件生态时，硬件似乎反而成了核心竞争力。类比来看，硬件同质化（甚至整车代工）+ 软件差异化的商业模式确实可以在汽车中实现，这种模式降低了造车门槛，但采取该模式的造出的车却难有持久力。
在硬件同质化的前提下，依靠新颖的软件功能确实能短暂满足消费者对黑科技的猎奇心理，可对于追求品质的中高端消费者吸引却不足，这就意味着车型的售价难以提升，成本压力又会直接传导回硬件，车企将不得不采用低成本的硬件，这反过来又会限制软件功能创新的施展空间，最终这类车型的所谓软件很可能走向“华而不实”的恶性循环。
其次，当前的智能座舱也难以定义汽车。在人因工程学领域，将智能座舱所处理的功能称为次级驾驶任务。与之对应的油门刹车方向盘操作，则是主驾驶任务。当前多数车企打造智能座舱的主要动作就是将iPad装上车，并没有考虑到次级驾驶任务对主驾驶任务造成的“认知分散”，这可能会导致预期功能安全风险；或可能因为一项鸡肋设计增加了驾驶员的负荷，从而产生挫败感，最终导致驾驶员弃用功能甚至品牌口碑的降低。关于这一话题，涉及到驾驶员情景意识、反馈、负荷、信任等众多驾驶心理学问题，这里不再赘述，建议感兴趣的读者阅读笔者的另一译著《汽车人因工程学》或两篇科普文章《智能座舱人机交互的发展趋势和实践》、《把所有汽车的中控都改成iPad可行吗？》。
总之，智能座舱如果能定义汽车，也许只有两种可能：第一，自动驾驶成为现实，主驾驶任务交给机器，车辆成为第三生活空间，智能座舱将成为车型差异化的主战场；第二，自动驾驶未实现，但智能座舱的功能充分考虑到次级驾驶任务对主驾驶任务的注意力资源的占用以及预期功能安全等问题，讽刺的是，在这一点上德日系老牌车企反而比言必谈“软件定义汽车”的国内多数车企做的好的多。
总结
汽车软件数量和种类的增多已经是不可逆的趋势，而依靠软件获得更高的利润也是所有车企未来持续增长的基盘。软硬件解耦正在发生，由软件实现的AI算法是驱动汽车发展的重要课题之一，基于SOA的软件生态已经成为所有车企的必修课，基于智能座舱的个性化软件功能也在繁荣蔓延。但，这些都不足以让软件定义汽车。
如果软件不能定义汽车，那“软件定义汽车”这一“政治正确”的观点本质到底是什么？
历史的延续 一场由外界力量做的局
如果回顾历史，会发现“软件定义汽车”的与汽车历史上曾经的流行趋势在发展轨迹上有诸多相似，它并非什么“百年未遇的大变革”。本质上，它是外界力量为“自己进入汽车行业做的一个局”而设计的宣传语，但它客观上确实推动了汽车软件的大流行，也势必将改变汽车行业。至于“软件定义汽车”这句宣传语本身的正确性，也许并不重要。
“软件定义汽车”是如何流行的？
据网传，软件定义汽车的首次提出大约在2002-2007期间（尽管笔者没有找到，仅找到2002年GM的汽车SOA方案），但可以肯定的是，当时并未激起太多波澜。直到2016年由百度自动驾驶负责人提出后，该口号才成为流行语。到2017年，Adaptive AutoSAR的第一版R17-03被释放，Adaptive Car的概念被提出（图3），行业上首次给出了软件定义汽车的架构雏形，并沿用至今。之后，诸如英伟达黄仁勋及行业内外的其他意见领袖都对这一概念给出了更具体的解释，软件定义汽车逐渐成为了行业大流行。
而另一条故事线上，从2014年开始，特斯拉陆续实现了中控大屏、SOTA/FOTA、付费软件模式、大量的车载娱乐功能，并在2017年交付的Model3中实现了集中分布式电子电气架构。行业普遍觉得它为 “软件定义汽车”打了样。
图3. 2017年AUTOSAR组织提出的Adaptive Car的概念
“软件定义汽车”的流行和汽车历史上的其他大流行别无二致
把目光投向整个汽车的发展史，能明显感觉到汽车行业的大流行都遵循着相似的轨迹发展而来，“软件定义汽车”也并无例外。总结来看，一个汽车行业大流行的发展轨迹通常有两个关键要素：
第一要素：时代的火烧向汽车
在本质上，汽车并不能算一项技术，它是人类为获得更好的出行体验而集成各类新兴技术的载体。所以，汽车的流行趋势往往都由“时代的火”所点燃。
时代的“火”通常有两种方式烧向汽车。
一种方式是从需求端点燃，由行业主动完成的变革。这种需求或是时代大变革改变了人类的生活方式，让人们对出行产生了新的期许（比如1760年的工业革命让人类学会了借助机器提升生产效率，人类将这一期许带到出行领域，于1801年发明了最早的蒸汽动力汽车，人类进入汽车时代），亦或是汽车在满足人类出行需求上有明显的短板，工程师带着问题去时代趋势中寻找解决方案（例如1970年代，为解决机械断电器式点火带来的启动耗时长问题，汽车工程师去当时飞速进步的固态电子学中寻找答案，于是基于晶体管的电子点火技术被发明，汽车进入电子时代）。
另一种是从供给端点燃，由外力推动汽车行业的变革。每当跨时代的新技术出现，资本力量和新技术的利益相关企业都希望在汽车上寻找到技术的落地场景，从而在汽车这个规模巨大的市场中分一杯羹。而随着汽车已能满足人类出行的基本需求，同时资本力量在汽车产业链中愈发渗透，这种“外界先搭台吆喝，汽车行业再千呼万唤始出来”的方式逐渐成为了主流。软件定义汽车的这把“火”，正是在这种模式下被点燃的。
2000年代，当ICT行业提出软件定义汽车时，也提出了软件定义网络、软件能定义Radio等概念。那时的“时代之火”更多是由软件工程的兴起引发，软件工程界期望用软件将一切物理实体数字化，并借助软件在数字计算上的优势加快社会的发展。但在智能手机尚未出现的当年，资本界和软件工程界并不知道这把火该如何烧向汽车，转而将软件之火烧向了前景更明朗的网络/通信领域。说句题外话，当时的这把火确实点燃了通信领域，而通信领域的技术风潮也影响到了汽车行业，高带宽的Flexray总线就是在此期间被提出。
而到了2016年，数字化和智能化已经成为了时代的明确主题。5G通信、数据科学、人工智能、云计算等新兴基础技术开始崭露头角，它们与汽车的融合所带来的无限可能自然会让人类浮想联翩，而软件恰恰是这种融合得以实现的核心要素之一，这是天时。同时，智能手机和互联网行业逐渐进入成熟期，资本家和相关企业亟须寻找新的盈利曲线，这是地利。于是软件的火更旺盛地烧向了汽车。
然而，汽车作为重资产行业，身躯庞大。外界的吆喝除了“天时”“地利”加码外，还必须要“人和”才能真的将整个行业唤醒。这就是我们要讲的第二要素。
第二要素：冒险者的破局
外界的呼声要想真的撼动汽车行业这条大船，通常需要一个敢于冒险的人将梦想落地，进而引发鲶鱼效应。这时，传统车企将不得不接招，以避免被淘汰。历史上一个著名的例子是福特T型车的问世。
在1900年代，西方一二线城市的老百姓们对拥有汽车这一新鲜且更快速的出行工具充满期望。但受限于价格和制造效率，汽车仍是贵族的专享。直到1908福特T型车问世，依靠流水线作业将汽车的售价降低了80%，生产周期则从行业平均的每年百余辆提升到数十秒一辆。汽车飞入了寻常百姓家，汽车行业的大佬们这才意识到了危机，全部all in流水线生产，汽车平民化时代的大幕被掀开。
而促使“软件定义汽车”被汽车行业所重视的，则是特斯拉的出现。从2014年开始特斯拉在SOTA/FOTA、付费软件模式、车载娱乐功能上的一系列软件创新让汽车行业意识到了危机，于是欧美主流主机厂在2016年联手打造了AP AutoSAR以做好“迎敌”准备。而到了2019年，Model 3依靠卓越的软件功能及更低的售价吊打市场且市值超过GM后，传统车企真真切切地受到了冲击，“软件定义汽车”从此响彻云霄。
思考
不难察觉，“软件定义汽车”的流行与汽车历史上的其他流行存在相似性，这些流行的大前提都是由于时代的流行趋势引发了对汽车的新期许，小前提则是一个冒险家将这些新的期许落地，进而引发了全行业的大流行。所以，我们很难将“软件定义汽车”称为“百年未遇之大变革”，这一口号更像是资本和互联网界为进入汽车行业而“做的局”，但它客观上确实也推动了汽车软件成为行业的大流行。至于“软件定义汽车”本身，它只是外界力量为搭台吆喝而设计的宣传语，是不是事实也许并不重要，它也可以叫“软件驱动汽车”“软件改变汽车”“软件强化汽车”等等。
软件对汽车行业的改变
尽管软件的流行并没有达到“定义汽车”般的统治力，但它仍然在许多方面已经（或即将）改变汽车行业。这些改变对于汽车行业从业者的影响远比一句口号更深远。我们不妨把格局拉高，思考一下几百年后人类总结我们这个时代的汽车时，会如何评价软件带给行业最具开创性的改变？在笔者看来，最根本的改变主要有三个方面：
图4.汽车软件为行业带来的改变及挑战
改变一：汽车从一次性交付转变为持续服务，从而改变了汽车的产供研模式和汽车行业的思维方式
依靠OTA持续升级的软件、二次付费软件、订阅服务的出现，让汽车不再仅是一次性交付的产品，还需要在车辆全生命周期内提供持续服务。车辆的价值也不仅依赖于看得到、BOM明确的机械装置，还包含了隐形的、价值增值的、持续性盈利的软件服务上。于销售端，这将改变汽车产品的售价模式，如何评估软件的价值，量化其市场贡献度，将成为全新的挑战。于供应端，这将影响车企的原有基于BOM+软件白嫖的成本管理模式；于研发端，这将影响传统车企的质量保证方法论。
同时，一次交付向持续服务的转变也将一定程度上改变汽车行业的基因。原先的汽车行业以劳动密集型制造业为主要特征，解决就业人口问题是国家赋予它的重要使命，而就业质量则被长期忽视。随着软件的流行，汽车行业将具备一部分知识密集型服务业的属性，这对行业的工作开展方式及思维提出了新要求。
改变二：汽车从逻辑驱动转化为数据驱动，从而带来一系列巨大的挑战
数字化、智能化时代背景下出现的AI等新技术、新算法通过软件与汽车融合，推动了一系列依赖于状态估计和主动决策的功能出现。这些功能的“血管”不再是非黑即白的逻辑，而是数据。这将带来多方面的挑战：
- 数据驱数据驱动为汽车首次引入了非确定性（non-deterministic）组件，将传统的车辆驾控模型和非确定性概率估计模型在汽车软件中有机结合成为了新挑战。仅靠if else逻辑枚举法实现的劳动密集型代码开发方式将难以成为衡量软件成败的关键。同时，原先整车控制所共同遵循、可用于将软件需求清晰分解到不同控制器的“扭矩结构”将难以再发挥“大脑”的作用，这就意味着软件架构的圈复杂度将大幅提升，功能间解耦愈发困难，软件开发的合作边界将变得模糊，对开发效率及质量挑战极大。
- 汽车功能与消费者需求间的复杂性自我强化循环（Self-reinforcing complexity cycle）因为数据的加入不断提速，车企对市场的反应将更直观、更敏感，整车开发周期将不断被缩短。
图5 Hollnagel复杂性自我强化循环（图片来自《汽车人因工程学》）
- 数据将改变原有的汽车相关规则制定体系。原先基于物理原理和经验推导出的规则，未来可能将直接基于真实行驶数据确定，由此得出的标准更符合实情，但行业权威的作用将逐渐降低。它所影响的不仅是法规制定（如排放法规RDE循环等），也会影响到汽车全生命周期需制定的各种规则（如特斯拉的UBI车险模式）。
- 数据本身带来了网络安全和隐私等问题。首先，随着服务器、无钥匙进入、车载App的网络攻击数量增多，行业出台WP.29及ISO21434等法规，网络安全已成为汽车的重要话题。而隐私方面，在个人数据保护法及网络安全法生效的背景下，行业相继出台的ISO 21434，ISO 24089，UNWP29 R156及《汽车数据安全管理若干规定》也将数据安全的重要性提升到了新的高度。
改变三：安全性和灵活性将不得不实现兼容
原有车辆控制软件和新加入的智能座舱等消费体验类软件在工程化方面存在冲突，但又不得不融合。一方面，过去汽车软件在整车价值中所占的比重较小，用户可直接感知的功能有限。与那些以软件为主导的、已在开发范式上有着成熟积累的产业相比，汽车软件在面对即将到来的数据驱动、以消费者体验迭代为导向的产品开发时，仍略显稚嫩。但另一方面，汽车的软件又高度重视安全，当其他领域已经非常成熟的“更敏捷”的软件开发范式应用于似乎“更笨拙”、却对安全性要求异常严格的汽车软件开发场景时，势必会经历一段“水土不服”的阵痛期（关于这一话题，建议阅读本公众号文章《NPDS与敏捷开发能共存吗》。行业里也出现了许多尝试，比如上汽零束打造的SOA平台，将侧重安全和偏向娱乐的功能以软件生态开发者的形式集合，并在平台后台提供统一的车规级安全验收，一定程度上实现了安全和非安全软件的和谐共处。
如果流程上的兼容尚可通过机制保证，那么开发理念上的冲突则更难解决。以传统动力域和底盘域的控制为例，软件中用于诊断、安全冗余、多级监控的代码占比超过三分之一，笔者所参与过的最复杂的软件开发曾经历了30余种不同类型的测试，每个测试撰写Case到测试软件的制作、开展测试到Review甚至二轮测试、二轮Review、Troubleshooting，耗时极长（图4）。研发人员宁可拉长研发周期，也不敢承担将车辆置于危险境地的失职风险，这是来自消费电子领域的软件团队短期内难以理解的。
而从另一个角度看，当前尚且容易解耦的软件都需如此繁琐应对，未来面对耦合度更高、迭代更快的软件时，这种极其强调安全的思路是否也会像我们正在经历的某些地区防疫工作一样，面对快速繁殖且错综复杂的关系链条，陷入无止的资源投入却又狼狈不堪？又或者，行业也许最终不会将强调安全的软件和强调体验的软件统一管理；而是会向更传统的医药行业看齐，将软件按SOA架构划分为“安全关键”（处方药）及“非安全关键”（非处方药），前者必须经过专家问诊、参考驾驶人的习惯及过往驾驶数据、问诊后“对症下药”，同时必须严格控制这类软件的数量以避免研发资源的无止境投入；后者才可以“无门槛”研制和售卖。何去何从，行业还有待探索。
图6. 某传统控制器项目涉及软件的测试/检查项
车企新课题
软件改变了汽车行业，而车企为配合这种改变，在业务开展及组织人才支撑等方面面临着全新的课题（图5）。笔者能力有限，只能浅尝辄止引发各位思考，事实上每个课题都庞大到足以开展一个咨询项目了。
图7. 软件为车企带来的新课题
车企运营模式的新课题
车企的话语权将不再来自机械硬件上的核心竞争力，而将来自“数据”和“计算平台”两个方面。这对于企业的运营带来了两方面挑战：
对内部而言，原先围绕看得见摸得着的硬件技术开发的模式已经意义不大。为了提升开发效率，车企更愿意采用软硬件同步工程模式，围绕着某一需求，以数据和计算平台为媒介，将解耦后的软硬件并行开发。软硬件开发团队如何同步协作？如何确保数据在满足信息安全前提下通畅地在组织内/跨组织流通？软件和硬件的平台化策略该如何兼容，是仍然基于造车平台，还是走向诸如大众的Toolkit模式实现积木式的模块化变体管理？这些都对车企提出新的挑战。
对外部而言，传统的制造商、一级供应商、二级供应商之间的合作模式将被打破，为原有的竞合关系带来了极大的不可预测性。车企应该掌握核心技术并保密以谋求垄断，还是将技术共享以谋求共建生态合作？哪些业务可以合作开发，或外包开发或外采或自行开发？位于不同层面上的企业，尤其是采用瀑布流程及敏捷流程的企业在合作时如何无缝衔接？利润如何划分？售后的责任如何划分？这些问题都将是企业间反复拉锯和思考的。
车企研发组织的新课题
新的运营模式也将必须由新的组织及人才模式来承接，挑战依然众多。
从组织上看，软件数量增多后的汽车研发组织该以客户差异为导向还是以平台为导向来构建？是按照产品线进行盈利核算，还是按照AUTOSAR架构的理念、将组织划分为基础软件的成本中心和应用软件的产品利润中心？对于SOA平台和跨企业内外的开发者生态该如何有机授权及管控？组织改革的实施是渐变的还是重构（例如成立可拆分上市的单独软件公司）？组织的领导人应来自传统汽车行业还是IT行业，该内部提拔还是外部空降？这些都将关系到企业转变的效果和实施成本。
车企人才新课题
首先是用人标准的转变。传统的“由专业人士制定需求再逐级分解实施”的开发模式是先验主义的，每位工程师只需应对局部知识，对其能力要求往往是诸如热力学、轮胎动力学、机械原理等经典知识体系，设计方式是基于原理的演绎、推理。而“软件定义汽车”则将在很大程度上打破这种规则，企业将更多地直接从需求程度各异、性格各异的消费者群体获取相应数据，主动引领并创造需求。这种开发模式是经验（后验）主义的，对工程师的能力要求是统计学、人因工程学等知识。研发人员不能再钻逻辑的牛角尖，而应该走出办公室，善用数据的归纳总结得到结论。
其次，对用人单位而言，将面临具备架构思维的人才极度缺失的窘境。只见个别“树木”、不见整体“森林”的问题突出。在面对新时代更复杂的汽车软件架构时，这种缺失不仅会降低开发效率，也会导致在设计中缺少对功能的全盘考量，待需求拓展后引发严重的技术负债风险。
然而在汽车行业培养一位具备顶层设计思维的工程师并不容易。他不仅需要在面对自动驾驶等自身尚未成熟的技术应用时掌握相当的基础科学知识；同时还需要对汽车越来越异质化却难以再按物理原理换分边界的功能有全面的了解，有时甚至还需要辅以一些所谓的“直觉”。从实战来看，这种“直觉”对汽车工程师格外重要，但却无法在书本中习得，势必需要从小耳闻目染地坐车、开车，通过数以百万计公里的出行旅程中与车辆的“交流”，去观察、去体验、去热爱才能建立。驾驶经验匮乏却能成为优秀的系统工程师、乃至标定工程师的日子将一去不复返。
另外对于企业，原来在薪酬体系及关键绩效指标上展现出的劳动密集型产业特征也要做出改变，原本靠平台吸引力和优秀的培训体系，大企业面对人才流失并不在意，美其名曰“黄埔军校”。但未来面对稀缺的顶层架构人才，企业恐再无糟蹋人才的资本，必须对他们予以差异化的选用育留考量。
《汽车软件架构》介绍
随着汽车软件的兴起，大量新的软件及功能被引入汽车。他们或集中在某计算平台上，或分布在不同的传感器和控制器中。要想更好地、可持续地管理这些软件，我们必须在传感器、控制器、计算平台这些“骨肉”之上，为软件架设一个面向未来的“灵魂框架”。软件架构将起到决定性作用。本书就是在这一背景下由机械工业出版社引入中国的。它是国内第一本专门研究汽车软件架构的书籍，由瑞典哥德堡大学信息科学系主任Miroslaw Staron博士撰写，他是学术界少有的站在软件工程维度研究汽车软件的学者之一，也是汽车软件工程领域的知名专家。
本书共有10章，除第十章总结外，每章的内容相对独立。具体内容请参见《汽车软件架构读后感》一文，这里不再赘述。如下是我对不同的阅读群体给出的阅读建议：
对于具备一定汽车软件开发经验，希望进一步学习架构知识的工程师而言，建议购买本书，并重点阅读第一、二、四、六、七章。其中第四章AutoSAR的知识应重点学习。额外的，对于从事汽车软件质量管理工作的读友，本书第七章强烈推荐阅读。
对于有志于进入汽车领域的其他行业软件从业者而言，建议购买本书，并重点阅读三、四、五、八章，它们分别讲了汽车软件特有的流程、架构和编码要求。
对于有志于从事汽车研发工作的在校大学生，或未从事过汽车软件开发但希望转行进入汽车软件行业的汽车工程师而言，本书的内容较为抽象，笔者更推荐优先阅读机械工业出版社的另外两本译著作为基础。一本是刚出版的由德国大众资深专家撰写的《汽车软件开发实践》；另一本是即将出版的汽车软件经典教材《汽车软件工程（第六版）》。
文章转载自公众号：汽车电子与软件
