使用基于模型的设计进行早期验证和确认

中对整个系统进行建模，您可以快速了解组件功能与其他组件的交互方式，以及集成组件在已部署的系统或环境中的行为方式。可能会发现对组件或其他方面的遗漏需求。通过使系统模型还原为迭代一个组件时的状态，可以评估设计迭代对系统功能的影响。

与设计和开发同时进行测试有助于检测出潜在问题，并可显著减少修复这些问题的成本和时间。通过在开发模型期间考虑测试，可使设计更适合于进行测试，从而确保可对设计进行完整测试。此原则的应用范围远不止嵌入式系统领域，但是嵌入式系统开发人员却常常忽视了此原则。原因是用户以为可以在软件中完成任何事情，也可能是文档化的开发流程忽视了此原则。然而，与新型灵活的软件开发流程一样，在设计模型之前或与设计模型并行开发测试是最佳做法。

几乎每种测试方案都涉及到某些变数：输入、对象参数、环境因素或其他要素。时间和开支通常限制了测试方案的灵活度；然而，通过在仿真环境中进行测试，您可以更加快速且并行（如果处理能力够用）地仿真测试案例。在仿真中探查整个参数空间还可以缩小要实时运行的关键测试的范围。

每个组织都有针对设计和实现的标准或最佳做法。这其中有许多标准并未形成文档，但是却被关键人员铭记在心。使标准书面化并将标准检查加入模型开发流程是很简单的做法，但却可以产生巨大的影响，因为这样做可尽早减少"愚蠢"错误的数量，确保模型在团队成员之间共享时更具可读性，并且更加容易在将来进行维护。对标准进行建模可以非常简单（如验证所有输入和输出是否已连接），也可以非常复杂（如是否满足行业标准）。关键在于开发一致的检查，然后在整个组织中推动对这些检查的遵从性。

确定测试组件何时能够满足需要通常不仅是一门科学，更是一门艺术，因为您通常要根据设计或测试工程师的判断来确定。对于软件组件，许多团队使用代码覆盖率作为更客观的标准来衡量测试的完整性。您同样可以将模型覆盖率用于模型测试。覆盖率用于衡量您在测试过程中测试了模型中（或源代码中）的多少逻辑。修改的条件/决策覆盖率是一种针对覆盖率的严格衡量标准，得到广泛接受。

大多数质量标准的核心原则是进行文档化。把需求，流程。结果记录下来。如果不进行记录，则不可能跟踪做过的事情；不可能向别人（如客户）证明您满足了他们的需求；也不可能重复您的结果。虽然记录通常很单调乏味，但是有许多工具可通过生成标准报告，来帮助自动记录活动。在您以后发现问题或希望重复使用设计时，良好的记录可帮助您节省时间，这也是非常重要的。

代码验证

这些做法是在模型级别开始早期验证的良好起点。最后，需要实现并部署到产品化硬件上。此时，代码验证成为重点。基于模型的设计可以提供哪些帮助呢？

自动代码生成是一种非常有用的方法。通过在模型级别验证您的设计，然后直接从模型生成代码，您只需要验证模型和代码是否等效。这是一种理想状态的工作流程。在实际情况中，有时不可能从模型生成需要的所有代码。您可能使用传统流程开发了一些中间件和设备驱动程序代码，或是可能将旧有代码用于某些功能。对于这些情况，可通过一些其他的最佳做法来验证代码。

用户几乎可以在任何位置测试硬件；然而，硬件通常没有与仿真中的测试有连接。许多因素都可能导致这种没有联系的情况：在硬件上运行测试的小组与对设计建模的小组不是同一批人，在实验室中运行的软件与设计中的软件也不相同。然而，当您在模型上运行的测试与在实验室中运行的测试相同时，您就可以确切地了解设计在实验室中的执行情况。若要验证代码是否等效于设计模型，您可以将相同的测试工具用于模型测试，来测试已编译并在嵌入式目标上运行的模型软件实现。同时对组件设计模型和嵌入式目标上的代码运行测试是一种协同仿真步骤，称为 PIL（处理器在环）测试。现在，可以使用一些工具在软件上执行测试（开发人员在主机（如 PC）上创建的测试），同时也在嵌入式处理器上运行测试。将嵌入式代码与原始模型的测试结果进行比较，可帮助您确保组件的行为在编译和下载后保持不变，并确保代码可正确运行。

嵌入式代码中的运行时错误特别难以发现，一旦发现后，又难以进行调试。这类例子包括溢出和下溢、被零除和其他算术错误、超出范围的数组访问、非法取消引用的指针、对非初始化数据的只读访问以及危险的类型转换等。直到最近，基本上只有三种选择可用于检测嵌入式软件中的运行时错误：代码检查、静态分析器和试错法动态测试。代码检查所需的人工工作量很大，通常不适用于大型的复