(Model Base Design)基于模型的设计

什么叫基于模型的设计？

为什么要基于模型的设计？

基于模型的设计过程中，需要做什么事情？

再问几个小问题：

模型验证是否必要？

模型验证有哪些工作可以做？

模型验证是否一定需要被控对象模型？

代码生成效率如何？

底层驱动是否要建模？

Embedded Coder（以前的RTW Embedded Coder）支持哪些芯片？

MIL、SIL、PIL、HIL的目的和实现方式？

如何定点化？

如何做代码集成？

什么叫基于模型的设计？

这是一个很大的话题，因为本人能力所限，仅讨论使用Simulink模型开发嵌入式软件的设计过程。也就是说，我只能聊基于模型的嵌入式软件设计。

我的理解是，通过对算法建模进行软件设计的过程，都可以叫基于模型的设计。

当然，如果仅限于算法建模，把Simulink/Stateflow当做Visio使用，而不去进行其他环节的工作，这样的基于模型设计是不完整的，可能对你的开发效率不会有很大的提升。

如果想通过基于模型的设计提升软件开发团队的开发效率，提高软件品质，我觉得至少有如下几点可以考虑：

算法建模

算法模型的验证

文档自动化

代码生成

代码和模型的等效性验证。

传统的开发过程中，我们有一个环节，需求捕获，也即，从系统需求分解出软件需求。

在基于模型的设计过程中，我们同样可以通过分析系统需求，获得软件需求。

当然，根据系统需求的详细程度，我们可以考虑是否要写专门的软件需求。

在基于模型的软件设计中，我们主要关心的是系统的功能需求，或者说可以通过软件实现的功能需求。如果这部分需求在系统需求文档里已经有非常清楚的定义，那么我们可以以系统需求文档作为依据建立模型。

当然，如果系统需求不是足够清楚，那我们有必要编写专门的软件需求文档。

如果不考虑Simulink/Stateflow的应用上的问题，也就是说，如果我们都是熟练的Simulink/Stateflow用户，那么建模过程的主要工作是需求分析，通俗点讲，需求弄清楚了，建模也就是非常简单的事情了。

当然，建模的时候，要考虑未来的验证、实现以及后期维护的问题。

我个人的体会，这个阶段，不要着急建模，一定要先弄清需求，另外，建模的时候，模型架构非常重要。

有了模型之后，接下来要做什么事情？

代码生成？

这是很多比较初级的用户容易犯的错误，犯这个错误的用户，很大程度上是因为没有弄清楚为什么要做基于模型的设计？

为什么要做基于模型的设计？

我相信很多用户没有仔细考虑这个问题，很多用户做基于模型的设计的理由是：国外的公司都这么做，同行其他公司都这么做......

弄清为什么要基于模型的设计，也就是要弄清楚基于模型的设计到底可以给我们带来哪些好处？

很多人会非常自然的想到，代码生成，代码生成可以提高软件开发效率。

没错，代码生成是一个很大的好处，但，代码生成不是唯一的，也不是最大的好处。

最大的好处是，算法的早期验证，之前NASA有研究表明，开发初期引入的bug，如果到了晚期才发现出来，那么修复这一的bug，会产生非常大的费用。所以，我们期望能够尽早的发现开发过程中引入的bug。

如何尽早的发现设计上的错误？

传统的开发模式里，我们使用review的方式去发现错误，在质量体系ISO9001里面有定义，任何一份设计，都必须要评审。

评审的目的，也就是为了发现这个阶段的错误，以防错误被带到后续的开发过程中。

而评审的效率，却是非常低下的。

我想凡是参加评审的网友都会有体会。

比如，我在做完一份设计之后，我会邀请我的同事来评审我的工作，而参加评审的这些同事，往往不能有足够的时间了解我的这份工作，而只能在评审会上听我介绍我做的工作，这样的评审，可能会发现一些非常明显的问题，除此之外的，很难发现问题。

评审作为一种非常传统的验证方式，并不能及时发现设计过程中引入的各种错误。

而仿真，从效率上讲，要远高于评审，仿真更容易发现设计中的问题。

仿真是可以运行的，如果我们设定一些输入，运行模型之后，我们会得到相应的输出，我们很容易观测到此时的输出是否是我们期望的输出。

另外还有好处，仿真的结果是确定的，给定输入，就会得到确定的输出，当然，期望输出也是确定的。而不像评审，同样的文字，对于不同人，可能理解成不同的含义。

代码生成和早期验证之外，基于模型的设计，还可以给我们带来其他好处，比如文档自动化。我们经常听到这样的说法：

我们终于把软件发布出去了，现在可以有时间补文档了...

下个月要audit了，所有同事都在补文档....

这里我要问：为什么要补文档？

补文档，我们可以从中得到两个方面的信息：

1.文档很重要，不能没有，至少从质量体系上要求我们必须有文档

2.工程师都不愿意写文档，是啊，如果愿意写文档的话，在开发过程中自然会把各类文档写起来的。

好，工程师不愿意写，开发过程中又不能少，如果计算机可以帮我们写，岂不是很美好的事情。

基于模型的设计，可以帮助我们实现文档自动化，至少有相当大的一部分文档可以让计算机替我们写。

其实，基于模型的设计，还有一个天然的优势：图形化设计。

对于工程师来讲，图形化的东西，本身就比文字更容易理解，否则我们在软件开发过程中也不会去画流程图和状态机了。

所以总结一下，基于模型的设计可以从以下方面给我们提供便利：

1. 图形化设计

2. 早期验证

3. 代码生成

4. 文档自动化

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

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

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

建模之后，接下来就是模型验证，验证，英文单词Verification，英文里面还有另外一个词Validation，确认，很多人不清楚这两个词之间的区别，通俗点讲：Verification是考察你是否正确的做了一件事，而Validation，则是考察你是否做出了正确的东西。一个强调的是过程，一个在乎的是结果。

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

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

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

模型验证之后，接下来就可以做代码生成了，有关代码生成，也专门讨论吧。

代码生成之后，需要做代码验证，基于模型的开发过程里面，SIL、PIL都是常用的代码验证方式。

在代码做完SIL或者PIL测试之后，要考虑软件集成了，即应用层软件，也就是通过Simulink 模型生成的软件，和底层驱动软件之间的集成。

软件集成之后，后面的事情，基本上和传统的开发模式差不多了，当然，相对于传统的开发模式，你可以多一个HIL环节出来，不过话又说回来，即便是传统的开发模式，也一样可以有HIL这个环节的。

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

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

我在进入MathWorks之后，接触过很多客户，不少客户在最初引入基于模型设计的时候，