防范于未然。

随着汽车公司和供应商发展越来越迅速，对汽车软件及其开发过程的需求日新月异。然而，加快的开发周期决不能导致对质量保证过程的妥协，特别是对安全关键型软件应用的忽视。对于大多数汽车公司和供应商来说， MISRA C 标准是质量保证的重要组成部分，并且通过检查程序源代码是否偏离标准，可以识别潜在错误并提高软件质量。但是，MISRA C标准的目标是什么，又如何能够在使用TargetLink进行基于模型的开发中应用该标准？

MISRA C标准简述

自1998年以来，汽车工业软件可靠性协会（MISRA）为用C语言开发软件制定了一个普遍适用的标准，以确保安全性、可靠性和代码质量。该标准的制定者从文献、公司标准和实践中广泛收集知识，以避免常见的软件错误。这些标准指南主要是为了防止人类程序员在编写C代码时犯可避免的错误。但是，如果代码是由像TargetLink这样的代码生成器生成的呢？即使这样，您是否还需要符合所有的标准？

符合MISRA C标准的、基于模型的开发

MISRA C标准可检查C代码的安全性、可靠性和质量。对于基于模型的开发，这意味着在代码中发现了违反规则的情况，就需要在模型中加以修正。因此，对于每个代码违规，您都必须确定在模型中的正确更改。为此，我们为您提供TargetLink MISRA C合规性文件，其中重点介绍了为纠正违反的规则需要在模型中进行的更改，以便系统地完成从列出发现的代码错误到最终满意的模型修改全过程。
像TargetLink这样的代码生成器对C语言结构有更深入的理解，这些结构可能不符合MISRA C标准，但在应用上下文知识时效率更高也不失安全。这意味着并非所有MISRA C规则都必须对像TargetLink这样的代码生成器有意义。MISRA C标准考虑到了这一点，并允许您创建偏离规则的情况。此外，记录和决定偏差的过程是MISRA C的一个重要要素，这在 2020年MISRA合规性发布中得到了澄清。
一个偏离规则但不失安全的情况示例是TargetLink默认应用的通过溢出计算（CTO）优化。该优化引入了从有符号整数类型到无符号整数类型的转换，反之亦然。这显著提高了代码效率，即代码大小和执行时间。CTO优化违反了MISRA C标准的第10.8条规则，该规则基于从有符号类型转换为无符号类型时引发无法识别的溢出的风险。然而，TargetLink会以明确定义的方式主动识别并利用该溢出行为，并且无论是否使用CTO，生成的位模式都是相同的。

防范于未然。

即使上述按需纠正方法有效，我们也会推荐一种更巧妙的方法。在生活中的大多数情况下，阻止问题发生比在问题开始出现后纠正它更容易。如果我们将这种方法转用到符合MISRA C标准、基于模型的开发中，那么在建模阶段检查规则违反情况比按需纠正问题会更容易、更快捷。为此，可以使用 MES Model Examiner®（MXAM）来确保对模型进行全面的静态分析。我们很高兴看到，通过与 Model Engineering Solutions（MES）密切合作，MXAM中已经包含了专门为避免在建模阶段违反MISRA标准而设计的TargetLink建模指南。这避免了按需纠正发现的问题时需要完成耗时的任务，并帮助您在第一时间获得正确的模型。
一个使用MXAM一次就获得正确模型的示例是，将信号路由到逻辑块（即 if 块）的模型。在某些情况下，TargetLink可能会生成if(NonBooleanVar)。这违反了MISRA C标准的第14.4条规则。然而，您可以通过启用 ForceBooleanOperandsInBooleanOperations 代码生成选项来避免这种情况，该选项为非布尔操作数插入额外的不等于零比较，即if(NonBooleanVar!=0)。在MXAM的静态分析期间，您将在生成代码之前获得有关此内容的信息。