确保ISO 26262合规:模型与代码测试的权衡与优化

2024-07-08 09:42:57·  来源:功能安全  
 

在基于模型的软件开发中,测试可以在模型或代码级别运行


但是我们应该把测试重点集中在哪个层面呢?


两者结合可实现高效且符合 ISO 26262 标准的测试流程


在汽车行业中,使用 Simulink 和 Targetlink 等工具的基于模型的软件开发 (MBD) 在过去几年中不断发展,如今已成为一种成熟的开发方法。尽管 MBD 具有诸多优势,但不可否认的是,它在开发过程中增加了一个步骤。除了生产 C 代码外,还有模型级别,并且可以在这两个级别上执行测试用例。但为了获得高效且符合 ISO 26262 标准的流程,我们应该专注于模型还是代码测试。让我们来看看我们的选择:


仅测试代码


由于许多开发团队过去都是手动编写代码,因此他们非常习惯在代码级别进行测试。他们可能仍会使用与以前相同的测试解决方案,因为他们对此很熟悉。由于代码最终会投入生产,因此这种方法符合 ISO 26262 标准,因此对于安全关键项目来说是一种有效的方法。


然而,代码仍然像过去的手写代码一样被处理。模型像某种 PowerPoint 一样被处理,在测试期间不起作用。这首先意味着我们错过了 MBD 的最大优势之一,因为在模型上进行测试和调试比在代码级别上更透明、更方便。更糟糕的是,如果在代码测试期间检测到问题,开发人员必须在模型中找到产生问题的位置并在那里修复它。完成此操作后,需要再次生成代码,然后才能进行测试以检查问题是否已修复(或未修复),这会导致耗时的迭代。


仅测试模型


模型或代码测试比较中的第二个选项是仅测试模型。我们考虑了基于模型的开发带来的所有优势,而不关心生成的代码。测试和调试直观且透明,看起来是一种一致的方法。


这种方法的缺点是不清楚代码将如何表现。模型和代码之间通常至少存在微小差异,因为您可能在模型上使用浮点,而在代码上使用定点表示。即使两者使用相同的数据类型,行为也可能不同,并且集成在 Matlab/Simulink 中的代码生成器(例如 Targetlink 或 EmbeddedCoder)并未经过认证,无法始终保证模型和代码级别的相同行为。这意味着我们没有关于投入生产的代码正确性的证据


这种方法也不符合 ISO 26262 标准,该标准要求测试尽可能接近最终产品。


测试模型和代码


在模型和代码层面进行测试结合了前面提到的两种测试方法的优点,并形成了一种直观的基于模型的测试工作流程,该工作流程还考虑了代码,因此也考虑了最终产品。这是一种符合 ISO 26262 的方法,涵盖了测试的所有方面。首先,如果您在模型上进行测试,并且同时关注代码,则可以快速获得响应。功能测试是在模型上进行的。背对背比较可确保正确转换为代码。


ISO 26262 标准也明确推荐了这一点。第 6 章第 9.4.6 节注释 4 指出,如果在模型和代码之间进行连续比较,则可以在模型级别进行软件单元测试。因此,这不是模型或代码测试的问题,而是两者兼顾的问题。


但是,由于我们现在考虑了两个实现级别,这种方法的效率取决于模型和代码的处理以及测试数据的处理。这可能会变得非常复杂,并导致不同应用程序和脚本的工具链集成不佳。如果为模型配备一个测试工具,为代码配备另一个测试工具,那将是非常低效的。首先,这意味着您必须为它们两个创建一个测试环境。如果问题已修复,您需要返回并使用这两个工具再次进行测试,除了额外的测试工作之外,您还必须注意保持两个工具之间的测试数据一致。这会花费很多精力,并且很容易出错。


为了应对这些挑战,需要一个高效且集成良好的工具支持,该工具支持考虑模型 和 代码,集成不同的测试方法进行功能测试和背靠背比较,提供自动化功能以减少人工工作量,并应符合 ISO 26262 标准。


结论


总结模型或代码测试的比较,我们可以清楚地看到,基于模型的开发如今已经很成熟,并且会得到进一步传播和完善。


为了在测试过程中享受基于模型的开发方法的好处,同时仍符合 ISO 26262 标准,测试工作流程需要考虑模型和代码。为了应对测试模型和代码的额外工作,测试工具必须经过彻底设计,以支持基于模型的测试以及代码测试。

分享到:
 
反对 0 举报 0 收藏 0 评论 0
沪ICP备11026620号