有关基于模型的设计（MBD）—些概念和理解先胡乱问几个大问题：基于模型的设计过程中，需要做什么事情？再问几个小问题：EmbeddedCoder（以前的RTWEmbeddedCoder）支持哪些芯片？如何做代码集成？什么叫基于模型的设计？这是一个很大的话题，因为本人能力所限，仅讨论使用Simulink模型开发嵌入式软件的设计过程。也就是说，我只能聊基于模型的嵌入式软件设计。我的理解是，通过对算法建模进行软件设计的过程，都可以叫基于模型的设不去进行其他环节的工作，这样的基于模型设计是不完整的，可能对你的开发效率不会有很大的提升。如果想通过基于模型的设计提升软件开发团队的开发效率，提高软件品质，我觉得至少有如下几点可以考虑：代码和模型的等效性验证传统的开发过程中，我们有一个环节，需求捕获，也即，从系统需求分解出软件需求。在基于模型的设计过程中，我们同样可以通过分析系统需求，获得软件需求。当然，根据系统需求的详细程度，我们可以考虑是否要写专门的软件需在基于模型的软件设计中，我们主要关心的是系统的功能需求，或者说可以通过软件实现的功能需求。如果这部分需求在系统需求文档里已经有非常清楚的定义，那么我们可以以系统需求文档作为依据建立模型。当然，如果系统需求不是足够清楚，那我们有必要编写专门的软件需求文档。如果不考虑Simulink/Stateflow的应用上的问题，也就是说，如果我们都是熟练的Simulink/Stateflow用户，那么建模过程的主要工作是需求分析，通俗点讲，需求弄清楚了，建模也就是非常简单的事情了。当然，建模的时候，要考虑未来的验证、实现以及后期维护的问题我个人的体会，这个阶段，不要着急建模，一定要先弄清需求，另外，建模的时候，模型架构非常重要。有了模型之后，接下来要做什么事情？代码生成？这是很多比较初级的用户容易犯的错误，犯这个错误的用户，很大程度上是因为没有弄清楚为什么要做基于模型的设计？为什么要做基于模型的设计？我相信很多用户没有仔细考虑这个问题，很多用户做基于模型的设计的理由是：国外的公司都这么做，同行其他公司都这么弄清为什么要基于模型的设计，也就是要弄清楚基于模型的设计到底可以给我们带来哪些好处？很多人会非常自然的想到，代码生成，代码生成可以提高软件开发效率。错，代码生成是一个很大的好处，但，代码生成不是唯一的，也不是最大的好处。最大的好处是，算法的早期验证，之前NASA有研究表明，开发初期引入的bug，如果到了晚期才发现出来，那么修复这一的bug，会产生非常大的费用。所以，我们期望能够尽早的发现开发过程中引入的bug。如何尽早的发现设计上的错误？传统的开发模式里，我们使用review的方式去发现错误，在质量体系IS09001里面有定义，任何一份设计，都必须要评审。评审的目的，也就是为了发现这个阶段的错误，以防错误被带到后续的开发过程做完一份设计之后，我会邀请我的同事来评审我的工作，而参加评审的这些同事，往往不能有足够的时间了解我的这份工作，而只能在评审会上听我介绍我做的工作，这样的评审，可能会发现一些非常明显的问题，除此之外的，很难发现问题。评审作为一种非常传统的验证方式，并不能及时发现设计过程中引入的各种错误。而仿真，从效率上讲，要远高于评审，仿真更容易发现设计中的问题。仿真是可以运行的，如果我们设定一些输入，运行模型之后，我们会得到相应的输出，我们很容易观测到此时的输出是否是我们期望的输出。另外还有好处，仿真的结果是确定的，给定输入，就会得到确定的输出，当然，期望输出也是确定的。而不像评审，同样的文字，对于不同人，可能理解成不同的含义。代码生成和早期验证之外，基于模型的设计，还可以给我们带来其他好处，比如文档自动化。我们经常听到这样的说法：•我们终于把软件发布出去了，现在可以有时间补文档了•下个月要audit了，所有同事都在补文档•…这里我要问：为什么要补文档?补文档，我们可以从中得到两个方面的信息:1•文档很重要，不能没有，至少从质量体系上要求我们必须有文档2.工程师都不愿意写文档，是啊，如果愿意写文档的话，在开发过程中自然会把各类文档写起来的。好，工程师不愿意写，开发过程中又不能少，如果计算机可以帮我们写，岂不是很美好的事情。基于模型的设计，可以帮助我们实现文档自动化，至少有相当大的一部分文档可以让计算机替我们写。其实，基于模型的设计，还有一个天然的优势：图形化设计。对于工程师来讲，图形化的东西，本身就比文字更容易理解，否则我们在软件开发过程中也不会去画流程图和状态机了所以总结一下，基于模型的设计可以从以下方面给我们提供便利：早期验证3•代码生成文档自动化前面我大概论述了为什么要做基于模型的设计，或者说基于模型的设计可以给我们带来哪些好处。这些好处，最终会大大提高开发效率，并且改善软件品质。下面，我在说说基于模型的设计里有哪些事情要做，刘博士说的没错，基于模型的设计，自然模型最重要，如何建模，毫无疑问是最为重要的环节。在软件产品开发中，建模活动里，耗时最多的，就应该是需求分析了，需求分析不仅包括如何正确理解软件需求，而且要考虑如何通过模型实现，真正的画模型的时间，相比之下并不多，如果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 克拉钻石的 两倍。类似的，如果每个软件模块有 个bug，那么你从集成好的软件里去消除这20 个bug， 耗费的精力肯定不是从 每个单元模块里去消除bug 所耗精力的总和。 说白了，早期验证是非常重要的，很多软件工程的教材里都有相关的统计数据说 明早期验 证的重要性，对应到基于模型的开发过程，能在模型级别做的验证，一 定不要拖到后续的 环节中。 中国有句老话，心急吃不了热豆腐”，项目时间紧”或者 人手不够”不能成 为我们忽略 模型测试的借口 继续说一下MBD开发过程中都有哪些验证工作要做 模型出来并且可以编译之后，首先要做建模标准检查，这个过程使用工具（比 MathWorks公司的 Simulink Verification &Validation 提供的 model advisor ）自动化的完成，检查过后，修改模型中不符合公司建模规则的项目。 接下来，就可以进行模型评审了，也就是说，评审的模型有两个前提，一是 可以编译 的，二是符合公司建模规则的。这两个前提可以帮助我们消除模型中的 一些低级错误，避 免在评审过程中有太多的时间花费在这些错误上。 因为评审是 建模的工程师和其他同事共同参与的活动， 做到上述两个前提，也是对其他同事 工作时间的一种尊重。 评审之后，建模的工程师会修改评审中发现的问题， 问题多的话，一般会要 求修改之后再进行 再评审”直到在评审中不会发现大量问题。 接下来，我们可以使用Simulink Design Verifier 进行模型的结构分析，借 助于Simulink Design Verifier 自动生成测试用例的功能，去检查结构上是否存 在问题，比如是否有不合理 的逻辑设计，是否有运行不到的分支等。 再往后，就可以进行模型单元级别的功能测试了。 软件开发过程中，对单元 测试的要 求是很高的，一般会根据应用的安全性、可靠性要求，给出测试的覆盖 率要求。 这个过程中工作量最大的应该是测试用例设计以及测试向量的生成。 测试用 例设计，我们一般会根据需求去设计测试用例， 当然，也会结合模型结构设计测 试用例，这样说来，这里的测试，已经包含了黑盒测试和白盒测试。有了测试用 例，如何 把测试用例转换为测试向量，这也是非常重要的环节。我们知道，在 MBD开发过程中，代 码都可以自动生成，其他环节，我们要努力做到自动化实 现。我们可以使用MATLAB脚本 开发一些转换工具用于将测试用例转换为测试 向量，我们还可以通过脚本实现测试过程的 自动化。 测试的指标，即测试覆盖率是否达到公司的要求或者行业的要求。 单元级别的功能测试完成之后，我们自然会进行集成测试，当然，集成测试 是分阶段、 有步骤的，我们可以先把一些单元模块集成为组件级，进行组件级的 集成测试，然后再将 组件集成为系统级，进行系统级测试。集成测试和单元测试 关注的内容不同，集成测试， 我们更关注于单元模块之间的借口关系、 调用关系 等等，所以，单元测试中要求的判定覆 MCDC覆盖率等，在集成测试中没有这样的要求。 条件允许的情况下，集成测试之前或者之后，可以通过快速原型的方式和实 物相连， 进行测试。 集成测试通过之后，我们基本上可以认为模型或者说算法是正确的了。 接下

　　12 化学是一门以实验为基础的科学-九年级化学上册课件（人教版）共16张PPT内嵌视频PP电子的官方网站PP电子 游戏