关于基于模型的设计（MBD）一些概念和理解

本文转载于MathWorks 中国高级工程师董淑成的帖子内容。

之前有网友引发了一些讨论，为了方便大家进一步讨论，专门开贴，讨论基于模型的设计。题目有点大，以我的个人经历，我只能说说基于模型的嵌入式软件设计，我先抛砖引玉吧。

先胡乱问几个大问题：

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

再问几个小问题：

模型验证是否必要？
模型验证有哪些工作可以做？
模型验证是否一定需要被控对象模型？
代码生成效率如何？
底层驱动是否要建模？
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. 文档自动化

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

下面，我在说说基于模型的设计(MBD)里有哪些事情要做?

刘博士说的没错，基于模型的设计，自然模型最重要，如何建模，毫无疑问是最为重要的环节。

在软件产品开发中，建模活动里，耗时最多的，就应该是需求分析了，需求分析不仅包括如何正确理解软件需求，而且要考虑如何通过模型实现，真正的画模型的时间，相比之下并不多，如果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开发过程中都有哪些验证工作(verification)要做。

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

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

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

接下来，我们可以使用Simulink Design Verifier进行模型的结构分析，借助于Simulink Design Verifier自动生成测试用例的功能，去检查结构上是否存在问题，比如是否有不合理的逻辑设计，是否有运行不到的分支等。

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

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

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

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

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

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

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

前面提到模型验证，下面再说说代码生成。

代码生成的前提是模型已经是验证过的模型，或者说，是正确的模型。

正确的模型包含两层含义，模型做过足够多的验证，验证的结果都是正确的。前面提到的各种验证方式，都有必要做，对于功能测试来讲，还有必要达到足够高的覆盖率要求。

做到以上这些，就可以考虑进行代码生成工作了，代码生成是否就是按一下“Code Generation”按钮的工作呢？工程项目开发中，没那么简单，代码生成过程中，工程师要做的主要工作是数据管理工作，除此之外，还会有一些代码相关的配置，比如函数原型、比如代码文件等等。

数据管理主要是对Simulink/Stateflow模型中的两类数据进行管理，一是信号，一是参数。对应于C代码，我们可以简单的把信号对应到变量上，而参数，则是不通过程序运行而发生变化的，参数的变化，一般是通过人工调节完成的，也就是参数调节，参数调节的目的是为了选择合适的参数以得到最佳的性能。

数据管理的方式，使用的是数据对象进行数据管理，这里的“对象”二字，和我们经常听到的“面向对象编程”里面的“对象”意义相同。Simulink为用户事先定义好两个包，一个是Simulink Package，一个是mpt Package。以Simulink Package为例，包里面有类，分别为Simulink.Signal和Simulink.Parameter两个类。用户可以通过这两个类定义相应的对象（Object），然后通过类提供的属性（Property）定义数据的属性。其实这两个类里面除了属性之外，还定义了方法（Method），一般情况下，我们管理数据，使用属性就够了。

当然，不管是Simulink Package还是mtp Package，都不能完全满足用户的所有要求，所以，很多时候，需要用户定义自己的Package。依然按照面向对象里面的一些概念，我们可以从Simulink Package或者mpt Package继承并创建自己的包。所有我们关心的数据都通过数据对象的方式做了定义之后，接下来的工作，就是按下按钮，生成代码了。

------------------------------------------------------------------------------------

因为前面预留的帖子不够多，所以，就继续在这个帖子里讨论一下自动生成的代码吧。

首先说一下大家很关心的效率问题，代码效率，我之前做过对比，比一般的工程师写的代码效率要高，当然，我相信对于那种C代码高手，一定可以写出效率更高的代码。不过我想强调的是，自动生成的代码，是可以用的，不要有任何心理障碍，毕竟，我们项目开发中的多数工程师也不是绝对的C语言高手。另外，关于效率，我最近也做过一次对比，就在这个帖子最开头提到的那个贴子里，虽然代码没有人去做编译，但从代码行数来看，和一个写了6年C代码的工程师的代码基本差不多。

再说说代码可读性的问题，很多人和我强调代码的可读性不如手写的好，我有条件的承认这一点。为什么是有条件的承认呢，我想说，如果你对模型做足够多的配置，生成的代码可读性基本上可以和手写的差不多。当然，我更想强调，在基于模型的开发过程中，我们是不读代码的（如果一定要读，那也是读那个.h文件），我们有其他方式保证代码是正确的，无须读代码。

再有一个问题，就是代码的集成问题，很多人也比较关心自动生成的代码如何集成到底层代码或者如何与其他手写代码做集成的问题，我一般会问他，如果这个模块的代码是手写的，你会怎么集成？他当然知道手写代码该怎么集成，好，自动生成的代码也同样可以集成。做代码集成的时候，我们关心的就是那个.h文件。

有关底层驱动的建模

我一直认为在产品化项目开发中，底层驱动是没有必要建模的。

原因如下：
1）底层驱动在Simulink环境下不能仿真；
2）底层驱动建模需要熟悉另外一种脚本语言——TLC；
3）产品化项目的底层软件往往很大，有些项目的底层软件甚至大于应用层软件，如此大的软件转换成Simulink下的TLC实现，不容易操作。

当然，有人会说，一旦有了底层驱动模型，就可以非常方便的实现Simulink模型到单片机hex文件的一键式实现，的确这样做貌似让整个开发过程的自动化程度得以提升，但是，不要忘记，你要开发出一个安全、可靠的底层模块库，会需要大量的时间投入，尤其在使用TLC设计的时候，TLC本身就是另外一种新的语言，同时这种语言所提供的调试环境也不尽如人意；相反，如果不使用这种一键式的模式，而是采用手工集成的方式实现自动生成的应用层代码与底层代码做集成，也是非常简单，非常轻松的事情。

总结一下，一键式的实现hex文件生成并不能明显提高开发效率，而开发出这样一个底层模块库，却需要花费大量的时间。

----------------------------------------------------------------------------------------

到MathWorks工作以来，经常被客户问到这样的问题：MATLAB的代码生成支持什么芯片？

支持什么芯片？MATLAB生成的是ANSI C代码，支持所有编译器，也就是支持所有芯片。当然，我说的是应用层代码的生成，不包括底层驱动代码。

我也知道很多人问这个问题的时候，心里面想着的是Target Support Package这样一个工具包，这个包里面的确提供了一些MCU或者DSP的底层驱动模块，借助于这些模块，我们可以生成底层代码。不过，继续强调一下，在很多工程化的项目里，这不是一个产品化的解决方案，这种方案更适合于做算法的快速验证。也正是因为这不是一个产品化的方案，所以这个产品的用户非常少，以至于MATLAB从2011a开始，不再单独销售这个模块，并不承诺以后会继续更新这个模块，这个模块连同IDE Link被打包到Embedded Coder产品中，只有你购买了Embedded Coder，你就可以使用这个模块了。

--------------------------------------------------------------------------------------------

再说说In-the-Loop测试的问题

我们经常听到的有MIL、SIL、PIL、HIL等，在基于模型设计的开发过程中，是否都要做这些In-the-Loop测试？

我认为所有的In-the-Loop都不是一定要做的，不过，我非常建议不要省略SIL环节。

1）MIL，模型在环测试，在Simulink环境里，除建立控制器模型之外，还需要建立被控对象模型，讲控制器和被控对象连接起来并形成闭环，让控制器去控制被控对象。

是否一定要做这个In-the-Loop呢？或者说，是否一定要有被控对象模型呢？其实不一定，这取决于模型验证的可能方式。在不少应用里，控制器模型的输出是开关量，工程师可以很方便的通过设定输入并给出期望输出，这样的情况，被控对象是没必要的，比如，汽车电子里面的车身控制，控制一个灯的开或者关，只需要知道输出是ON或者OFF即可，没必要去做一个灯泡的模型放到Simulink里。

2）SIL，软件在环测试，软件在环测试，应该说是从模型在环测试引申过来的，区别只是把控制器的模型换成了由控制器模型生成的C代码编译成的S-function，SIL的目的是为了验证生成的代码和模型在功能上是否一致，或者说验证生成的代码和模型在功能上是否等效。

验证等效性，是否一定需要被控对象模型？不必要，既然验证生成的代码和模型的一致性，那只需要给生成代码和用于代码生成的模型相同的输入，比较它们在相同的输入条件下，输出是否一致即可。

3）PIL，PIL有两个目的，一是为了等效性验证，二是为了测量模型生成的代码在目标处理器上的运行时间。有关运行时间的测量，如果你选择的处理器足够强大，或者你非常把握目标代码的运行不会超限，那么PIL的意义就要打折扣了。

4）HIL测试的目的是为了验证控制器的，HIL过程中，会把被控对象的模型生成C代码并编译成可执行的文件放到工控机上运行，以便工控机替代真是的被控对象，然后把控制器和工控机连接起来，实现闭环控制，从控制器的角度上看，就相当于工作到实际控制系统之中。HIL经常被用于以下几种情形：
a）被控对象非常昂贵，如果控制器不成熟会导致被控对象的损害；
b）被控对象失效会危及人身安全；
c）开发过程中，先开发出了控制器，而被控对象还没有开发出来。