有关基于模型的设计(MBD)一些概念和理解.docVIP

. . 有关基于模型的设计（MBD）一些概念和理解 先胡乱问几个大问题： 什么叫基于模型的设计？ 为什么要基于模型的设计？ 基于模型的设计过程中，需要做什么事情？ 再问几个小问题： 模型验证是否必要？ 模型验证有哪些工作可以做？ 模型验证是否一定需要被控对象模型？ 代码生成效率如何？ 底层驱动是否要建模？ Embedded Coder（以前的RTW Embedded Coder）支持哪些芯片？ MIL、SIL、PIL、HIL的目的和实现方式？ 如何定点化？ 如何做代码集成？ 什么叫基于模型的设计？ 这是一个很大的话题，因为本人能力所限，仅讨论使用Simulink模型开发嵌入式软件的设计过程。也就是说，我只能聊基于模型的嵌入式软件设计。 我的理解是，通过对算法建模进行软件设计的过程，都可以叫基于模型的设计。当然，如果仅限于算法建模，把Simulink/Stateflow当做Visio使用，而不去进行其他环节的工作，这样的基于模型设计是不完整的，可能对你的开发效率不会有很大的提升。 如果想通过基于模型的设计提升软件开发团队的开发效率，提高软件品质，我觉得至少有如下几点可以考虑： 算法建模 算法模型的验证 文档自动化 代码生成 5. 代码和模型的等效性验证 传统的开发过程中，我们有一个环节，需求捕获，也即，从系统需求分解出软件需求。在基于模型的设计过程中，我们同样可以通过分析系统需求，获得软件需求。当然，根据系统需求的详细程度，我们可以考虑是否要写专门的软件需求。 在基于模型的软件设计中，我们主要关心的是系统的功能需求，或者说可以通过软件实现的功能需求。如果这部分需求在系统需求文档里已经有非常清楚的定义，那么我们可以以系统需求文档作为依据建立模型。 当然，如果系统需求不是足够清楚，那我们有必要编写专门的软件需求文档。如果不考虑Simulink/Stateflow的应用上的问题，也就是说，如果我们都是熟练的Simulink/Stateflow用户，那么建模过程的主要工作是需求分析，通俗点讲，需求弄清楚了，建模也就是非常简单的事情了。当然，建模的时候，要考虑未来的验证、实现以及后期维护的问题。 我个人的体会，这个阶段，不要着急建模，一定要先弄清需求，另外，建模的时候，模型架构非常重要。 有了模型之后，接下来要做什么事情？代码生成？ 这是很多比较初级的用户容易犯的错误，犯这个错误的用户，很大程度上是因为没有弄清楚为什么要做基于模型的设计？ 为什么要做基于模型的设计？我相信很多用户没有仔细考虑这个问题，很多用户做基于模型的设计的理由是：国外的公司都这么做，同行其他公司都这么做...... 弄清为什么要基于模型的设计，也就是要弄清楚基于模型的设计到底可以给我们带来哪些好处？ 很多人会非常自然的想到，代码生成，代码生成可以提高软件开发效率。没错，代码生成是一个很大的好处，但，代码生成不是唯一的，也不是最大的好处。 最大的好处是，算法的早期验证，之前NASA有研究表明，开发初期引入的bug，如果到了晚期才发现出来，那么修复这一的bug，会产生非常大的费用。所以，我们期望能够尽早的发现开发过程中引入的bug。 如何尽早的发现设计上的错误？传统的开发模式里，我们使用review的方式去发现错误，在质量体系ISO9001里面有定义，任何一份设计，都必须要评审。评审的目的，也就是为了发现这个阶段的错误，以防错误被带到后续的开发过程中。 而评审的效率，却是非常低下的。我想凡是参加评审的网友都会有体会。比如，我在做完一份设计之后，我会邀请我的同事来评审我的工作，而参加评审的这些同事，往往不能有足够的时间了解我的这份工作，而只能在评审会上听我介绍我做的工作，这样的评审，可能会发现一些非常明显的问题，除此之外的，很难发现问题。 评审作为一种非常传统的验证方式，并不能及时发现设计过程中引入的各种错误。而仿真，从效率上讲，要远高于评审，仿真更容易发现设计中的问题。仿真是可以运行的，如果我们设定一些输入，运行模型之后，我们会得到相应的输出，我们很容易观测到此时的输出是否是我们期望的输出。另外还有好处，仿真的结果是确定的，给定输入，就会得到确定的输出，当然，期望输出也是确定的。而不像评审，同样的文字，对于不同人，可能理解成不同的含义。 代码生成和早期验证之外，基于模型的设计，还可以给我们带来其他好处，比如文档自动化。我们经常听到这样的说法： 我们终于把软件发布出去了，现在可以有时间补文档了... 下个月要audit了，所有同事都在补文档.... 这里我要问：为什么要补文档？补文档，我们可以从中得到两个方面的信息：1.文档很重要，不能没有，至少从质量体系上要求我们必须有文档2.工程师都不愿意写文档，是啊，如果愿意写文档的