广告
确保ISO 26262合规：模型与代码测试的权衡与优化
在基于模型的软件开发中，测试可以在模型或代码级别运行
但是我们应该把测试重点集中在哪个层面呢？
两者结合可实现高效且符合 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 标准，测试工作流程需要考虑模型和代码。为了应对测试模型和代码的额外工作，测试工具必须经过彻底设计，以支持基于模型的测试以及代码测试。
广告 
广告
最新资讯
-
Plus为自动驾驶卡车功能添加了H.E.L.P.警报
2024-12-23 17:18
-
美国能源部发布最新版氢计划
2024-12-23 17:16
-
系统级封装（SiP）在新能源汽车领域的应用
2024-12-23 08:51
-
车载通信框架 --- 智能汽车车载通信架构浅
2024-12-23 08:40
-
全国首例！武汉车网智联公司完成智能网联测
2024-12-23 08:39
广告
广告
