想问一个Matlab问题？

来源：蜘蛛抓取(WebSpider) 时间：2022-06-02 01:02 标签： 用matlab解决应用题

前面我大概论述了为什么要做基于模型的设计，或者说基于模型的设计可以给我们带来哪些好处。这些好处，最终会大大提高开发效率，并且改善软件品质。

下面，我在说说基于模型的设计里有哪些事情要做，刘博士说的没错，基于模型的设计，自然模型最重要，如何建模，毫无疑问是最为重要的环节。

在软件产品开发中，建模活动里，耗时最多的，就应该是需求分析了，需求分析不仅包括如何正确理解软件需求，而且要考虑如何通过模型实现，真正的画模型的时间，相比之下并不多，如果Simulink/Stateflow用的熟的话，真正打开MATLAB画模型的时间占建模阶段总时间的1/3都不到。

建模之后，接下来就是模型验证，验证，英文单词Verification，英文里面还有另外一个词Validation，确认，很多人不清楚这两个词之间的区别，

通俗点讲：Verification是考察你是否正确的做了一件事，而Validation，则是考察你是否做出了正确的东西。一个强调的是过程，一个在乎的是结果。

闲话少说，咱们继续回到模型验证上来，通常模型验证包含如下活动：建模标准的检查、评审、单元测试、快速原型。（如果说的不完善，欢迎大家补充）

建模标准的检查，可以通过模型检查工具自动完成，建模标准检查的意义，和传统开发模式里C编码标准的意义一致，这里不展开了。

有关评审和单元测试，再专门开贴说吧。

  • 模型验证之后，接下来就可以做代码生成了，有关代码生成，也专门讨论吧。
  • 代码生成之后，需要做代码验证，基于模型的开发过程里面，SIL、PIL都是常用的代码验证方式。
  • 在代码做完SIL或者PIL测试之后，要考虑软件集成了，即应用层软件，也就是通过Simulink模型生成的软件，和底层驱动软件之间的集成。
  • 软件集成之后，后面的事情，基本上和传统的开发模式差不多了，当然，相对于传统的开发模式，你可以多一个HIL环节出来，不过话又说回来，即便是传统的开发模式，也一样可以有HIL这个环节的。

有关HIL的实现及目的，以后再说。

再说说模型验证的必要性。

我在进入MathWorks之后，接触过很多客户，不少客户在最初引入基于模型设计的时候，根本不在意模型验证工作，他们经常在模型编译通过之后就拿去生成代码，有了代码之后将代码下载到各种快速原型设备上去测试算法，Simulink的仿真功能基本上成了摆设。并且在这个阶段，不管我如何苦口婆心的给他们介绍模型验证的重要性，在他们那边，却总有各种各样的借口去省略模型验证环节，“项目时间太紧，模型来不及测”，“我们知道规范的开发流程，但是现在人手不够”。

当然，这类用户经常在这样折腾了一段时间之后，还是要回到模型测试上来，他们最终会发现，在HIL设备上测试算法，实在太难，当然，也有坚持的，坚持的结果就是他们所谓的基于模型的设计，开发效率比传统的开发模式高不了多少。

其实，这个问题我们可以这么去看，模型阶段的测试，我们是可以分模块进行的，而HIL上测试，基本上是集成之后的软件。比如，一个软件有10个模块，在HIL设备上，你很难分离出每个模块的bug，而如果是按模块做单元测试，则就是针对的一个具体的模块。打一个不算恰当的比方，我们都知道一块2克拉的钻石，价格肯定不是一块1克拉钻石的两倍。类似的，如果每个软件模块有2个bug，那么你从集成好的软件里去消除这20个bug，耗费的精力肯定不是从每个单元模块里去消除bug所耗精力的总和。
说白了，早期验证是非常重要的，很多软件工程的教材里都有相关的统计数据说明早期验证的重要性，对应到基于模型的开发过程，能在模型级别做的验证，一定不要拖到后续的环节中。

中国有句老话，“心急吃不了热豆腐”，“项目时间紧”或者“人手不够”不能成为我们忽略模型测试的借口。

继续说一下MBD开发过程中都有哪些验证工作要做。

模型出来并且可以编译之后，首先要做建模标准检查，这个过程使用工具（比如MathWorks公司的Simulink Verification & Validation提供的model advisor）自动化的完成，检查过后，修改模型中不符合公司建模规则的项目。

接下来，就可以进行模型评审了，也就是说，评审的模型有两个前提，一是可以编译的，二是符合公司建模规则的。这两个前提可以帮助我们消除模型中的一些低级错误，避免在评审过程中有太多的时间花费在这些错误上。因为评审是建模的工程师和其他同事共同参与的活动，做到上述两个前提，也是对其他同事工作时间的一种尊重。

评审之后，建模的工程师会修改评审中发现的问题，问题多的话，一般会要求修改之后再进行“再评审”，直到在评审中不会发现大量问题。

借助于Simulink Design Verifier自动生成测试用例的功能，去检查结构上是否存在问题，比如是否有不合理的逻辑设计，是否有运行不到的分支等。

再往后，就可以进行模型单元级别的功能测试了。软件开发过程中，对单元测试的要求是很高的，一般会根据应用的安全性、可靠性要求，给出测试的覆盖率要求。

这个过程中工作量最大的应该是测试用例设计以及测试向量的生成。测试用例设计，我们一般会根据需求去设计测试用例，当然，也会结合模型结构设计测试用例，这样说来，这里的测试，已经包含了黑盒测试和白盒测试。有了测试用例，如何把测试用例转换为测试向量，这也是非常重要的环节。我们知道，在MBD开发过程中，代码都可以自动生成，其他环节，我们要努力做到自动化实现。我们可以使用MATLAB脚本开发一些转换工具用于将测试用例转换为测试向量，我们还可以通过脚本实现测试过程的自动化。

测试的指标，即测试覆盖率是否达到公司的要求或者行业的要求。

单元级别的功能测试完成之后，我们自然会进行集成测试，当然，集成测试是分阶段、有步骤的，我们可以先把一些单元模块集成为组件级，进行组件级的集成测试，然后再将组件集成为系统级，进行系统级测试。集成测试和单元测试关注的内容不同，集成测试，我们更关注于单元模块之间的借口关系、调用关系等等，所以，单元测试中要求的判定覆盖率、MCDC覆盖率等，在集成测试中没有这样的要求。

条件允许的情况下，集成测试之前或者之后，可以通过快速原型的方式和实物相连，进行测试。

集成测试通过之后，我们基本上可以认为模型或者说算法是正确的了。接下来，我们就可以进行代码生成了。

代码生成之后，会跟着做SIL、PIL、HIL等测试，所有这些In-the-Loop测试都不是必须的，工程师应该根绝项目的实际情况，选择合理的测试方案，当然，建议SIL测试不要省略，原因在于这种测试的确非常方便做，并且也的确会发现一些代码生成过程中出现的问题。    

我要回帖

更多关于 用matlab解决应用题 的文章

 

随机推荐