软件会给汽车带来哪些变化？

尽管软件的流行并没有达到“定义汽车”般的统治力，但它仍然在许多方面已经（或即将）改变汽车行业。这些改变对于汽车行业从业者的影响远比一句口号更深远。我们不妨把格局拉高，思考一下几百年后人类总结我们这个时代的汽车时，会如何评价软件带给行业最具开创性的改变？

改变一：汽车从一次性交付转变为持续服务，从而改变了汽车的产供研模式和汽车行业的思维方式

依靠OTA持续升级的软件、二次付费软件、订阅服务的出现，让汽车不再仅是一次性交付的产品，还需要在车辆全生命周期内提供持续服务。车辆的价值也不仅依赖于看得到、BOM明确的机械装置，还包含了隐形的、价值增值的、持续性盈利的软件服务上。于销售端，这将改变汽车产品的售价模式，如何评估软件的价值，量化其市场贡献度，将成为全新的挑战。于供应端，这将影响车企的原有基于BOM+软件白嫖的成本管理模式；于研发端，这将影响传统车企的质量保证方法论。
同时，一次交付向持续服务的转变也将一定程度上改变汽车行业的基因。原先的汽车行业以劳动密集型制造业为主要特征，解决就业人口问题是国家赋予它的重要使命，而就业质量则被长期忽视。随着软件的流行，汽车行业将具备一部分知识密集型服务业的属性，这对行业的工作开展方式及思维提出了新要求。

改变二：汽车从逻辑驱动转化为数据驱动，从而带来一系列巨大的挑战

数字化、智能化时代背景下出现的AI等新技术、新算法通过软件与汽车融合，推动了一系列依赖于状态估计和主动决策的功能出现。这些功能的“血管”不再是非黑即白的逻辑，而是数据。这将带来多方面的挑战：
1、数据驱数据驱动为汽车首次引入了非确定性（non-deterministic）组件，将传统的车辆驾控模型和非确定性概率估计模型在汽车软件中有机结合成为了新挑战。仅靠if else逻辑枚举法实现的劳动密集型代码开发方式将难以成为衡量软件成败的关键。同时，原先整车控制所共同遵循、可用于将软件需求清晰分解到不同控制器的“扭矩结构”将难以再发挥“大脑”的作用，这就意味着软件架构的圈复杂度将大幅提升，功能间解耦愈发困难，软件开发的合作边界将变得模糊，对开发效率及质量挑战极大。
2、汽车功能与消费者需求间的复杂性自我强化循环（Self-reinforcing complexity cycle）因为数据的加入不断提速，车企对市场的反应将更直观、更敏感，整车开发周期将不断被缩短。

3、数据将改变原有的汽车相关规则制定体系。原先基于物理原理和经验推导出的规则，未来可能将直接基于真实行驶数据确定，由此得出的标准更符合实情，但行业权威的作用将逐渐降低。它所影响的不仅是法规制定（如排放法规RDE循环等），也会影响到汽车全生命周期需制定的各种规则（如特斯拉的UBI车险模式）。
4、数据本身带来了网络安全和隐私等问题。首先，随着服务器、无钥匙进入、车载App的网络攻击数量增多，行业出台WP.29及ISO21434等法规，网络安全已成为汽车的重要话题。而隐私方面，在个人数据保护法及网络安全法生效的背景下，行业相继出台的ISO 21434，ISO 24089，UNWP29 R156及《汽车数据安全管理若干规定》也将数据安全的重要性提升到了新的高度。

改变三：安全性和灵活性将不得不实现兼容

原有车辆控制软件和新加入的智能座舱等消费体验类软件在工程化方面存在冲突，但又不得不融合。
一方面，过去汽车软件在整车价值中所占的比重较小，用户可直接感知的功能有限。与那些以软件为主导的、已在开发范式上有着成熟积累的产业相比，汽车软件在面对即将到来的数据驱动、以消费者体验迭代为导向的产品开发时，仍略显稚嫩。
但另一方面，汽车的软件又高度重视安全，当其他领域已经非常成熟的“更敏捷”的软件开发范式应用于似乎“更笨拙”、却对安全性要求异常严格的汽车软件开发场景时，势必会经历一段“水土不服”的阵痛期。
行业里也出现了许多尝试，比如上汽零束打造的SOA平台，将侧重安全和偏向娱乐的功能以软件生态开发者的形式集合，并在平台后台提供统一的车规级安全验收，一定程度上实现了安全和非安全软件的和谐共处。
如果流程上的兼容尚可通过机制保证，那么开发理念上的冲突则更难解决。以传统动力域和底盘域的控制为例，软件中用于诊断、安全冗余、多级监控的代码占比超过三分之一，笔者所参与过的最复杂的软件开发曾经历了30余种不同类型的测试，每个测试撰写Case到测试软件的制作、开展测试到Review甚至二轮测试、二轮Review、Troubleshooting，耗时极长。研发人员宁可拉长研发周期，也不敢承担将车辆置于危险境地的失职风险，这是来自消费电子领域的软件团队短期内难以理解的。
而从另一个角度看，当前尚且容易解耦的软件都需如此繁琐应对，未来面对耦合度更高、迭代更快的软件时，这种极其强调安全的思路是否也会像我们正在经历的某些地区防疫工作一样，面对快速繁殖且错综复杂的关系链条，陷入无止的资源投入却又狼狈不堪？又或者，行业也许最终不会将强调安全的软件和强调体验的软件统一管理；而是会向更传统的医药行业看齐，将软件按SOA架构划分为“安全关键”（处方药）及“非安全关键”（非处方药），前者必须经过专家问诊、参考驾驶人的习惯及过往驾驶数据、问诊后“对症下药”，同时必须严格控制这类软件的数量以避免研发资源的无止境投入；后者才可以“无门槛”研制和售卖。何去何从，行业还有待探索。