MUNIK解读ISO26262-软件复用

有过ISO26262实际应用经验的人都知道，ISO26262标准将软件、硬件或完整ECU的复用当成是一个重点话题，在很多地方都有加以讨论。原因是因为有两个方面在实际开发中至关重要：一方面是从经济角度来看，组件的重复使用非常有吸引力，开发成本可以显著降低，开发速度可以提高；另一方面出于安全考虑，重复使用组件可以提供显著的优势。因为在现场使用多年且没有显示出安全相关故障的控制单元可以被重复使用，并且新版本在继承旧版本的基础上进行改进时，可以认为其风险较低，这一点是毋庸置疑的。

软件复用的场景：

在对ISO26262标准十多年的研究和实施之后，我们对于汽车行业可以进行复用的场景了然于心，下图首先显示了各种可能性。注意并非所有路径都同样频繁地出现，而且并非所有场景在实践中发生的可能性都是一样的：

图一 软件复用的场景和分类

如果我们看第一个层次，关于确定应该复用什么，这里提供了软件、硬件或完整的控制器单元三种可能性。第二个层次涉及可重复使用要素的功能安全要求的考虑。第三个层次确定软件是否会在不变的情况下重复使用，或者是否需要进行调整。

图二 软件组件和软件单元的定义（来源：ISO26262 Part1）

ISO 26262的要求：

ISO26262 8-Clause 12：“软件组件的鉴定”定义了根据ISO 26262已经开发的软件组件的再利用程序。对于根据ISO 26262开发的要素，应提供适用于再利用的证明。合格软件组件的重新利用避免了具有相同或相似功能的软件组件再次开发。

ISO26262 8-Clause 14：定义了使用在用证明的程序。这里是指现场已经在使用的组件，并且有足够的故障数据。如果满足标准中定义的要求，则可将在用证明用作满足ISO 26262的替代方法。

在准备在用证明时，必须考虑以下两个标准：

1） 观测期间现场数据的相关性

2） 自观察期开始以来对产品的更改（如果有）

鉴于现场数据的相关性，“在用证明”旨在识别ECU的系统性和随机性错误，而不是识别由于ECU的使用年限而导致的错误。另外除了上面两个与复用有关的章节外，当然还有很多来自ISO26262不同部分的应用要求，比如影响分析、集成策略和验证策略等。

ISO26262的具体实践案例：

通过上面的讲解，我们能意识到与安全相关的软件的复用可以有很多实际应用场景，接下来必须在ISO26262中确定与特定项目相关的重复使用的具体实践，这里将通过几个例子来讨论。

案例1：软件符合ISO 26262，新系统具有相同的ASIL级别

在这个例子里，我们假设现有的软件已经符合ISO 26262。现在，它打算将这个软件原封不动地转移到一个新的系统中，ASIL保持不变。在这种情况下，ISO 26262第8部分Clause 12“软件组件的鉴定”定义了要执行的任务，即必须检查以前开发的组件在多大程度上对软件的新用途有效和完整。理想情况下，检查的结果是所有组件都可以在不修改的情况下被采用。根据ISO 26262第6部分Clause10“软件集成和验证”，集成测试是必要的，以证明软件在新环境中也能完美工作。

图三 案例1：软件复用的要求

一个来自航天行业的例子是阿丽亚娜5号，它在1996年6月4日发射后不久自毁，调查结果从一定程度上说明，当软件已经被转移到新系统中，但集成测试仍然不完整时，可能会出现哪些错误。比如当时系统崩溃的原因是软件在将水平速度从64位浮点转换为16位值时内存溢出。因为火箭新型号的水平速度值明显高于上一个型号，所以这种转换导致了16位值的溢出。

案例1a：软件符合ISO 26262，但已更改，新系统具有相同的ASIL级别

如果现有软件是根据ISO26262开发的，ASIL保持不变，但对软件进行了修改，则可以部分应用标准第8部分Clause12“软件组件鉴定”。在这种情况下，保持不变的软件部分的工作产出物可以被复用。此外需要进行影响分析，以分析更改的影响。

然而，在复杂更改的情况下，分析的结果可以是必须对现有工作产出物的大部分进行调整，以满足ISO26262的要求。如果软件的更改还包括开发新的部分，则必须根据标准的要求重新创建工作产出。像这样的情况下，集成测试肯定是必要的。

图三 案例1a: 软件复用的要求

案例2：软件符合ISO 26262，新系统具有更高的ASIL级别

这个案例与案例1的不同之处在于，新系统必须满足更高的ASIL。现有软件是为较低的ASIL级别开发的。在这种情况下，必须依据ISO26262进行影响分析，以确定哪些组件需要额外开发。现有的工作成果物也可能需要进行调整以满足更高的ASIL等级。

例如，依据ISO26262的影响分析可能表明，必须重新创建用于验证的检查单（Inspection checklist）（因为检查/Inspection对ASIL B、C和D来说是必要的），因为分析前是以走查（Walkthrough）的形式进行的验证（对于ASIL A来说足够）。

另一个例子是源代码所需要满足的结构覆盖度要求。对于ASIL B和C，分支覆盖就足够了。对于ASIL D，则还需要满足MC/DC（修改条件/判定覆盖率）的要求。

案例3：软件是在ISO 26262生效之前开发的

这个案子很简单。ISO26262不适用于此类软件，因此不需要应用。

然而，很明显，这种情况越来越罕见，因为标准已经生效几年了（自2011年以来）。而在引入ISO 26262之后，我们希望避免在引入的时间点已经存在的系统随后必须适应该标准，这恰恰是ISO PAS 8926所关注的问题。

案例4：COTS软件

对于汽车行业中使用的商用现货（COTS）软件，可以应用所谓的“在用证明”（A proven in use, ISO26262第8部分Clause 14）。对于此类软件，通常几乎不可能创建ISO26262的必要产出物，原因是我们无法访问源代码。因此在这里在用证明是满足标准要求的一种非常有用的方法。从根本上来讲，一个在用证明是使用历史数据来预测功能故障模式的未来趋势，因此有可能是不准确或者不具有鲁棒性的假设。只有在极少数情况下，在用证明能足以证明受信任的软件要素实现了必要的安全完整性。

故而如开头所言，标准中对这种情况的要求相当苛刻：

1. 必须证明现场数据在规定的观测期内是可用的，且这些数据实质性地与功能安全相关（必须进行详细分析）；
2. 如果在观察期内进行了变更，则必须证明这些变更不会影响数据的相关性；
3. 必须采用系统性集成的方法；
4. 必须给出计算观察期（服务期）的理由。

总结

在本文中我们分析了软件复用的众多场景，使用开发当中的实践为不同场景定义了明确的措施，以符合ISO26262标准的要求。在这部分我们可以得出结论，只有同时拥有专业的配置管理和较高的测试自动化程度，软件的复用才能从经济学的角度获益。