始于模型，不止于仿真-使用 MATLAB 和 Simulink 进行验证、确认和测试 系列技术文章（3）

在Simulink中轻松实现大型复杂项目的需求管理

为了让广大用户更加深入地了解如何使用 MATLAB 和 Simulink 进行验证、确认和测试，MATLAB推出了《始于模型，不止于仿真-使用 MATLAB 和 Simulink 进行验证、确认和测试》系列技术文章，旨在以三个典型的行业案例，详细阐述如何利用MATLAB and Simulink，在基于模型的设计方式下，开展验证、确认和测试工作，实现开发工具和开发流程的深度融合。该系列包含三篇技术文章，面向嵌入式控制软件开发流程中的不同工作和角色，将共同助力用户产品的设计、实现与测试，具体如下图所示。

文章将以逻辑监控算法为例，阐述如何在Simulink中创建、编写大型复杂项目中不断演变的开发需求，管理需求变更，并将需求双向追溯到设计和测试中。

不管从事什么项目的开发，设计的起点都是需求。在产品生命周期中，需求是一个动态变化的过程，会随着项目的推进而发生变更。需求变更后，与之相对应的设计也需要发生相应的变更。对于大型复杂项目，需求条目众多，涉及部门广泛。客户方需求，公司/研制机构内部需求，市场需求，功能需求，安全性需求，可维护需求，可移植性需求等等交织在一起，如何高效地进行需求管理就成为很多人面临的难题。

如果你参与过大型复杂项目的开发，是否曾经碰到过这样的情况：自己看着辛辛苦苦做了半天就快成型的功能单元差点笑出声来的时候，突然某一天辗转得知，总体需求已经变更好几周了，并且涉及到你的部分，但你却完全没得到消息……项目规模太大，变更了的需求涉及到的利益相关者众多，而你不幸被遗忘了。这时无论你的心情如何，都得加班加点儿改设计了，而最可惜的是，那个被你捧在手心的功能单元很可能要大变样。

又或者，你站在巨人的肩膀上工作，对已有大项目进行改型，系统中的功能太过繁杂，如何知道哪些功能单元需要保留而哪些可以在改型中去除呢？你的反应会不会是：还是不要动前人的设计吧，我只加那些需要增加的部分？

再或者，产品需要过行业认证，但你之前工作重点都在提高产品性能上了，需求文档不规范，和设计测试的追溯关联也没及时做好，为了认证能顺利通过，你化身文档小能手，没日没夜的补文档。

如何避免因为沟通不畅带来的额外工作，又如何避免系统中的冗余设计，这些都是每个人需要考虑并重视的问题。如果上面的坑都没踩到过，哎呀呀你的运气真是太好了，但不妨也看看下面的内容，毕竟项目越做越大是个大概率事件。

MATLAB软件通过基于模型的设计，帮助用户贯穿需求、设计、测试等产品化的每个阶段，轻松实现其间的双向追溯，并允许使用者在Simulink中创建、编写大型复杂项目中不断演变的开发需求，管理需求变更。

Simulink Verification and Validation在2017b版本进行了重大变革，由一个产品拆分成3个产品，其中就有全新推出的Simulink Requirements。该工具包可以让用户：

• 在Simulink中编写，分析和管理需求，并将其链接到设计，代码和测试。
• 可以从外部来源导入需求，当需求更改时，可以收到自动通知。
• 可以显示何时对链接的需求，设计或测试进行了更改并统计需求的设计实现和验证状态，使用户便于评估项目的完整性。
• 可通过IEC认证套件（针对ISO 26262和IEC 61508）和DO认证套件（针对DO-178）获得对行业认证的支持。

接下来，让我们从设计人员的视角，以逻辑监控算法为例（非本主题重点，不涉及模型及算法内容），看看Simulink Requirements的使用步骤和方式。

1. 从外部来源导入high level需求

Simulink Requirements支持导入Microsoft Word， Microsoft Excel，IBM Rational DOORS，以及符合Requirements Interchange格式（ReqIF）的需求文件。当你将外部需求导入MATLAB时，可以选择两种导入方式：导入成可编辑的需求或是导入成只读的引用需求。这两种形式的区别在于：当选择导入成可编辑的需求时，Simulink Requirements在导入外部需求时打断了和外部需求源的链接，将来如果要编辑或更新需求，需要在Simulink中完成，如果你希望Simulink Requirements作为首选的需求管理工具，就使用这种导入方式。当选择导入成只读的引用需求时，Simulink Requirements在导入外部需求时保留着和外部原始需求的链接关系，将来如果要编辑或更新需求，需要在Simulink外完成，如果你希望外部软件作为首选的需求管理工具，就使用这种导入方式。

那么导入的需求放在什么文件中呢？

用户需要先在MATLAB命令行中键入指令slreq.editor，它会打开一个叫做Requirements Editor的需求编辑环境，定义一个新的需求集后，可以保存成.slreqx格式的需求集文件。当你有了Simulink环境中的需求集文件后，它就可以作为容器，承载来自于外部软件的high level需求了。

导入如图2所示的high level需求后，除了看到需求的条目，当你鼠标点击具体的需求，还可以在右侧的详细信息域内，看到需求的具体描述，是否与low level需求有链接关系等信息。

2. 在Simulink Requirements中定义low level需求

设计人员在对high level需求进行解读分析后，会推演得到具体设计所需的low level需求，low level需求是具体设计的直接依据，每一条low level需求都需要在模型设计中被实现，而每一个设计模块/分系统/独立可运行的模型也都需要去响应某个/某些low level的需求。如果我们经过周密的初步设计，确认了low level的需求之后，需要将这些low level需求也定义在需求集文件中。在设计流程中，这通常被成为需求分解。

还是在Requirements Editor中，添加一个新的需求集，并将其命名为MW_CruiseControl，随后可以在这个需求集下添加需求以及子需求，并对每个需求起名字，定义类型，增加描述等具体信息，如图3所示，形成对应于high level需求的包含功能性需求，安全性需求以及接口需求的low level需求。

3. 关联high level与low level需求

为了便于日后对需求变更的追溯，我们还需要将high level需求和low level需求关联起来，为此，仅需要在high level需求项上点击右键，选择‘‘Select for Linking with requirement’’,如图4所示，然后找到与之对应的low level 需求，右键点击后，上下文菜单中会出现选项‘‘Create a link from XXX1 to XXX2’’, 如图5所示，选项中会自动出现你选中的high level需求以及low level需求名字，然后你就能在需求集中看到两个需求的双向追溯，并且在Requirements Editor的右下角，还能看到从high level需求到low level需求，是用“Derives”来体现的，如图6所示，在这种不同层级需求的对应上，既可以一对一，也可以一对多和多对一。

4. low level需求和设计的关联

确定low level需求后，就可以通过建模仿真来设计为实现需求所需的系统了。假设我们已经完成了系统的模型设计，运用和步骤3类似的操作，或利用直接拖拽的方式，就可以方便地将需求和设计关联并双向追溯起来。如图7所示，需求和设计的追溯是用”Implemented by”来体现的。在Simulink Requirements中，支持下列元素和需求的关联与追溯：

• Simulink 模块
• MATLAB code
• Stateflow Charts, States 以及Transition
• 数据字典Data dictionaries
• Signal Builder groups
• Simulink Test 中的测试用例以及test suites（步骤6会详述）

5. 需求和设计关联性检查

Simulink环境中模型设计完成后，我们需要确保每一条需求都有设计与之对应，而每一部分设计也体现着某个（些）需求。这样，才能保证既不发生功能的缺失，也不会出现冗余的设计。为此，先选择模型的需求视图（如图8所示），然后软件会自动为关联有需求的设计项打标记（如图9所示，框出的模块未关联需求，其他右上角带标记的模块关联了需求，），通过此方式，来查看需求和设计是否对应。

6. 需求和测试的关联追溯

设计完成之后，功能需求需要某种形式的验证，以证明系统可以满足预设的行为。 通常，这是通过大量测试来完成的，MATLAB可以让用户在Simulink Test 中通过Test Manager进行批量的功能性测试，

关联需求和测试的过程和上述类似，分别选择Requirements Editor中的需求项以及Test Manager中对应的测试项，通过上下文菜单即可轻松完成。需求和测试的追溯是用”Verified by”来体现的，如图10所示。

在第5步中，用户可以在模型上直观地看到需求在设计中的实现程度，当测试也被关联起来后，在Requirements Editor中还可以通过“显示实现和测试的状态”，方便地查看每个需求项被实现和测试的情况。为了测量测试被验证的情况，可以从Requirements Editor端，也可以从Test Manager端运行所有的测试用例，然后刷新状态栏后就可以得到图10 所示的测试通过情况进度条。

7. 需求和代码的关联追溯

充分的测试后，你想把做好的算法生成代码，以便算法从桌面仿真过渡到真实的硬件实现。在代码生成时，可以在code generation中配置选项，让需求出现在生成的代码中，从而在生成的代码和需求之间实现方便的双向追溯。

8. 需求变更的管理

第一步中我们在导入外部需求时使用了只读的引用需求，因此当外部需求变更后，可以在Requirements Editor中同步更新这些变更。

修改并保存外部的需求文档后，Requirements Editor中high level需求的顶层会出现一个黄色的三角形图标，代表来自外部的需求发生了变更，然后，通过‘‘update’’选项，即可同步更新Simulink环境中的需求项，并呈现具体的变更信息。选择” change information”显示后，还可以高亮变更了的high level需求，进而高亮与之相对应的low level需求，如图11所示。

如果变更的外部需求不影响具体设计的话，用户可以方便地清除所有变更，高亮显示随之消失；如果变更的外部需求确实影响设计的话，就像前面几步所介绍的那样，修改或添加相应的详细设计，并完成必要的链接。

至此，从设计人员的角度，按照系统开发的步骤顺序，粗浅梳理了Simulink Requirements的功能，如果你对这个工具感兴趣，更多信息，可以查看 Simulink Requirements 帮助文档。

如果想大致学会它的使用，可以参考网上教学视频 Simulink Requirements Demo 视频 与 Simulink Requirements 入门视频。