利用汽车开发标准规范汽车应用程序的软件开发

当普通的非工程师消费者想到汽车中的电子系统时，他们可能会想到集成 GPS、信息娱乐系统，并且可能会想到汽车某处有一台计算机控制某些安全功能的模糊概念。当然，现实情况是现代汽车要复杂得多，软件在功能的各个方面发挥着越来越大的作用，包括许多对安全至关重要的功能。事实上，几十年来，汽车一直在利用电子系统实现关键功能，而市场变化，例如推动“物联网”，推动汽车制造商嵌入更多运行关键范围的复杂计算机系统。

与系统开发相关的业务结构和供应链进一步增加了复杂性。很少有制造商从头开始设计和构建汽车中的每个组件和子系统，这会导致潜在的集成问题。变速箱取自该模型，该模型具有良好的制动系统。虽然它们可能在以前的环境中运行良好，但在一个全新的复杂系统中，它们很可能会产生意想不到的结果。因此，汽车软件通常是复杂的系统大杂烩，可能经过充分测试，也可能未经过充分测试。在没有适当测试的情况下以临时方式实现组件，尤其是在安全关键应用程序中，成本可能非常高。

不过，好处是，有一些已知的做法可以帮助汽车制造商通过将软件质量构建到他们的开发过程中来降低失败的风险。在本文中，我们将讨论导致汽车软件复杂性的一些问题，以及与汽车软件开发相关的风险。我们还将讨论实施已知的开发最佳实践（例如 ISO 26262）如何帮助组织降低这些风险。

更多代码会带来更多风险吗？

根据一些估计，一辆标准的中档汽车可以有超过一百个电子控制单元 （ECU） 处理数百万行代码——而且这个数字还在增加。对于制造商来说，拥有几款代码超过 1 亿行的汽车并不少见。

人们认为，汽车越贵，嵌入的软件就越多——而且大多数软件都专用于高端信息娱乐组件。虽然随着模型线的升级，这些系统确实会变得越来越复杂，但即使是汽车的入门线也使用软件来控制转向、制动系统、电力分配等。即使是蓝牙、气候控制、巡航控制等功能看似微小的变化，也会导致代码呈指数级增长。

我们可以假设更多的代码会转化为更多的复杂性——因此会带来风险——但影响可能不一定很大。与汽车软件相关的业务风险的更大贡献者是从多个层级的各种来源开发的代码的集成。大多数组件，包括基于 ECU 的组件，都分包给二级供应商，而二级供应商又分包给三级供应商，依此类推。前面的每一层都有与他们正在开发的组件相关的特定要求。组织通常（但并非总是）有分析传入代码的实践，以确保组件按预期运行。

但这假设供应链上的每个组件都是新的发展。实际上，下游层正在分支为特定品牌、型号和年份编写的代码。代码的变异和重用发生在整个供应链中，这导致了测试问题。制造商如何在如此混乱的软件开发生态系统中实施端到端测试？当方向盘中的 ECU 最初是为一辆车开发的，而仪表板中的 ECU 是为另一辆车开发的，而这两个 ECU 都不是为当前嵌入的车辆而设计的，那会产生什么影响？您如何确保整个系统按预期运行？两个系统完全有可能通过功能测试，但在所有情况下都无法正常通信。

软件质量成本

当组织试图衡量软件开发的成本时，他们倾向于查看一般指标：工程师的开发时间；QA的测试时间；以获取工具许可证、编译器和其他基础设施组件的形式“构建材料”。这些是重要的指标，但经常被忽视的是失败的成本。

如果制动系统中的软件出现故障，企业在返工、召回、审计、诉讼和库存价值损失方面的成本是多少？如果有生命损失怎么办？我们认为质量成本是开发和测试软件的成本，包括我们确定的所有正常指标以及与现场失败相关的非常有形的成本。

缺陷使汽车制造商付出了很多钱。NHTSA 估计，整个行业的召回和修复每年使汽车制造商损失 30 亿美元。当谈到与软件相关的问题的成本时，IEEE 2005 年估计制造商的成本为每辆车 350 美元。当您考虑到一系列车辆的低利润率时，可以想象一个足够严重的软件缺陷会严重损害业务。

底线很重要，但更重要的是，人们可能会因软件缺陷而受重伤甚至死亡。无论缺陷可能起源于供应链多远，缺陷及其所有相关后果都成为汽车制造商的责任。因此，任何围绕软件开发的成本分析都需要考虑失败的潜在成本。

软件开发的现状

我们认为，汽车软件分层供应链的复杂性会导致与安全关键系统相关的整体风险。我们还重申了汽车业务的潜在成本。但是这个问题的另一个方面在于工程和软件开发之间的文化差异。

软件开发几乎从来都不是工程。也就是说，来自工程原理的某些概念，例如可重复性、良好实践的最佳实践和对构建标准的依赖，尚未在软件开发中牢固确立。此外，对软件开发人员的培训可能不一致——甚至根本不存在——组织必须竭尽全力来验证他们的开发人员是否拥有足够的知识来构建安全关键型软件。

这与工程形成对比，在工程中，与软件开发相比，学科的态度、思维方式和历史强制执行的过程不太容易出现缺陷。这并不是说工程师知道他们在做什么而软件开发人员不知道。而是说，汽车工程作为一个领域的成熟度是软件开发的两倍，软件的无形的、时间性的特性使一种傲慢的态度永存，如果它有效，那么它就完成了。

软件开发的重点是更快的交付和功能需求——我们能多快拥有这个功能？管理层几乎没有动力在软件开发生命周期中实施良好的工程实践。在软件中实现功能安全需要实施某些工程原则：

功能安全必须是主动的

过程必须是可控的、可测量的和可重复的

应通过执行标准来预防缺陷

测试必须有效且具有确定性

应对复杂的内存问题进行测试

好消息是围绕软件开发的态度一直在演变。ISO 26262、MISRA 和其他标准旨在通过为在软件开发过程中实施工程概念提供基础来规范汽车应用程序的软件开发。一些组织将遵守 ISO 26262 和其他标准视为增加开销的负担，没有任何直接价值，但事实是，与软件缺陷相关的失败成本远远高于确保质量的成本。与指定特定规格的电线以承载已知电压的电气标准一样，编码标准可以提供有助于避免灾难的指南。

作者：Arthur Hicken，Adam Trujillo

审核编辑：郭婷