软件在汽车中正发挥着越来越重要的作用。但是对于汽车企业来说，开发软件和维护软件正变得越来越耗时，若放任不管迟早将爆发“软件危机”。其中主要原因是软件变型的数量太多。因此，急需在软件领域进行'复杂度管理'。
汽车中的软件正变得越来越重要，越来越复杂。这是由于汽车网联、自动驾驶、辅助驾驶系统的使用和新的人机界面等趋势所致。汽车的使用者从中得到了新的、高科技般的体验，以及额外的舒适和安全功能。例如使用亚马逊的Alexa云服务、谷歌和苹果的语音助手。此外，越来越多的车辆被永久连接到云端（'Always-on'）。用户可以通过云平台预订个别服务，如汽车共享服务或获取充电站的位置。在未来，软件更新也可以通过云端OTA进行。用OTA更新的安全功能，保护车辆免受黑客攻击。
但这种发展也给汽车企业带来了软件上的挑战:
开发新的软件功能以及和现有的软件功能适配所需的人力正在增加，并且正在成为汽车行业的一个严重的成本因素。
车型和配置的数量和复杂性在不断增加，另外ECU、处理器和软件架构的复杂性都在增加，使得需要管理的软件变型变得越来越多。
多年来积累的众多的软件功能都要进一步开发和维护。因此，软件维护工作量在不断增加。
车辆中E/E架构的演变：发展正朝着面向服务的软件架构（SOA）迈进
这些因素说明，软件和E/E部件（ECU、传感器、执行器）在汽车中的份额正在显著增加。根据咨询公司麦肯锡2019年的研究报告《2030年汽车软件和电子》，这两个领域的解决方案的价值份额将从2020年的2380亿美元增加到2030年的4700亿美元左右。软件部门（功能、操作系统和中间件）在未来十年将以平均每年9%的速度增长。软件集成、测试等服务的支出将增加10%。
软件的日益复杂化产生了进一步的影响。根据麦肯锡的说法，在软件专业人员的生产力和快速提供更丰富的程序的需求之间，存在着越来越大的差距。从长远来看，用越来越大的团队开展软件项目的方法将不再可行。比如，开发一个信息娱乐系统需要三年的时间，并捆绑了数百名开发人员。大约30%至50%的时间和精力必须花在将各供应商的软件组件集成到解决方案中并对其进行测试。
有几个因素导致了汽车行业软件的复杂性增加
问题点1：多种多样的软件变型
另一个问题点是大量的软件组件的功能和应用变型，它们实际上实现的功能却相同。导航和信息娱乐系统就是一个例子。许多汽车制造商对这些解决方案的要求是相似的，但软件中的功能实现往往仅在细节上有所不同，例如，由于使用不同的接口或车企的个别要求。即使是像Autosar这样的标准软件组件，也有许多车企对标准进行了扩展而产生了自身特有的方案。因此，现有的软件模块必须适应每个汽车企业的个别要求。完全不变地重复使用软件模块实际上是不可能的。这增加了软件的开发、适配和长期维护的努力和成本。
此外，当车型换代时，还需要努力进行软件适配。虽然人们认为大部分精力应该用于开发新功能，但调查显示，只有约40%的开发预算用于新功能，但60%用于维护现有功能。
问题点2：硬件部件和平台太多
由于各个汽车企业之间存在大量的硬件和平台变型，减少软件版本的数量变得非常困难。通过引入灵活的平台概念（如大众的MQB、MEB平台），汽车企业近年来已经设法相对容易地衍生出新的车型。40年前，戴姆勒有大约10个车型，到2000年已经增加到20个，2020年计划有多达40个车型。这意味着，所使用的软件也必须反映这种多样性。这是通过对车辆上百个ECU中使用的程序进行适配来实现的。
这个因素增加了开发软件的工作量。软件变型同样需要进行集成和测试。虽然汽车企业拥有处理不同汽车零部件的复杂物流体系，但他们往往缺乏处理软件变型的概念。
降低平台复杂度的方法。
思路1：采用标准化软件
可以通过提高汽车软件的标准化来降低复杂度，例如采用Autosar架构。Autosar已经被确立为一种标准，并使标准软件的成本得到了相当大的节省，并提高质量。然而，由于仍有大量的变型，其潜力还没有被挖掘出来。比如对于Autosar 4.x，仍有大量针对车企的变型和扩展组件。这意味着软件只能在有限的范围内被重复使用。因此，标准软件的质量只能一步一步地提高，必须有新的方法。
思路2：开源软件
开放源码的方法可以成为快速和有效开发标准的模式。开放源代码能促使新的软件解决方案进行相对简单的评估并进行进一步开发。
思路3：对软件变型进行主动管控
另外，对软件变型进行主动管理也是个选择。这必然涉及到软件架构。一种可能性是在软件中尽可能少地创建分支。使在不同系统上使用标准化的软件模块更加容易。软件重用本身并不是目的，目的是成本降低和质量提高。这必须在软件架构上进行主动管控。然而，在许多项目中，优先考虑的是与ECU、车辆架构和功能软件的单独优化。这是以牺牲软件的长期质量和稳定性为代价的，并导致了更高的成本。
思路4：使用敏捷的开发方法
引入敏捷开发方法也是个办法，如精益开发、Scrum、Kanban和DevOps。可以在实践中快速测试结果的可用性。精益开发侧重于工作流程的持续改进和加强开发团队的个人责任，而敏捷开发则特别处理风险最小化问题，以便通过提高开发过程的透明度，使产品更快达到系列成熟度。Scrum是这两个概念在软件项目的管理中的实现。在这里，即将到来的任务被结构化为较小和可管理的部分，以减少其复杂性。最后，看板通过将现有的工作流程可视化来减少并行任务的数量。这使得项目的进展和瓶颈问题都能更快地被看到。可以使用补充方法，如DevOps。DevOps旨在改善软件开发和IT基础设施之间的互动。
思路5：包括软件的总体成本观
然而，独立于各种优化措施，提高汽车企业对 '软件成本因素 '的认识是至关重要的。例如，在项目规划期间，已经检查了实际需要多少新的软件变型，以及如何减少对现有组件的变型和适配的人力消耗。为此，在 '总体成本'的背景下，全面考虑软件成本是有意义的。
然而，今天的情况往往还不是这样。例如，更换一个MCU会使每个ECU节省大约1块钱。在这种情况下，由于计划有800万辆汽车的市场规模，这可是相当可观的一笔成本的费用节省。但另一方面，更换MCU也需要重新验证操作系统和相关的持续集成工作，以及在项目期间需要更多的测试。对于适配、测试和集成，开发团队规模可能会在三年内增加30名员工。这样一来，所需的软件适配工作就耗费了大约1000万。这将使硬件方面的节省效果变得很荒谬。
汽车行业要共同努力降低软件复杂性
归根结底，这意味着该行业必须重新思考软件的使用。不仅应考虑到控制系统的部件和机械零件的成本，也应考虑到软件的开发和变更费用。换句话说，业界需要对软件开发有一个新的看法，并一起努力积极降低软件的复杂性和多样性。IT行业的软件公司正在积极努力，以保持较低的维护产品版本数量。新功能只在最新的软件版本中开发；只为旧的软件版本提供错误修复。这些软件公司还试图将他们的软件对硬件或系统的依赖性隔离开来，以尽量减少适配工作。整个行业一同反思是必不可少的。这是因为软件的复杂性正日益成为整个汽车生态系统的问题：由于软件的实现和维护，OEM和供应商面临着不断增长的成本。鉴于汽车行业的竞争日益激烈，这种趋势是不可接受的。
本文部分图文引用子《汽车电子》
联系客服
