网站地图
【www.arisingsemi.com--软件系统】
基于是什么意思 有关基于模型的设计（MBD）一些概念和理解先胡乱问几个大问题：
1. 什么叫基于模型的设计。
2. 为什么要基于模型的设计。
3. 基于模型的设计过程中，需要做什么事情。
再问几个小问题：
1. 模型验证是否必要。
2. 模型验证有哪些工作可以做。
3. 模型验证是否一定需要被控对象模型。
4. 代码生成效率如何。
5. 底层驱动是否要建模。
6. Embedded Coder（以前的RTW Embedded Coder）支持哪些芯片。
7. MIL、SIL、PIL、HIL的目的和实现方式。
8. 如何定点化。
9. 如何做代码集成。
什么叫基于模型的设计。
这是一个很大的话题，因为本人能力所限，仅讨论使用Simulink模型开发嵌入式软件的设计过程。
也就是说，我只能聊基于模型的嵌入式软件设计。
我的理解是，通过对算法建模进行软件设计的过程，都可以叫基于模型的设计。
当然，如果仅限于算法建模，把Simulink/Stateflow当做Visio使用，而不去进行其他环节的工作，这样的基于模型设计是不完整的，可能对你的开发效率不会有很大的提升。 如果想通过基于模型的设计提升软件开发团队的开发效率，提高软件品质，我觉得至少有如下几点可以考虑：
1. 算法建模
2. 算法模型的验证
3. 文档自动化
4. 代码生成
5. 代码和模型的等效性验证
传统的开发过程中，我们有一个环节，需求捕获，也即，从系统需求分解出软件需求。
在基于模型的设计过程中，我们同样可以通过分析系统需求，获得软件需求。当然，根据系统需求的详细程度，我们可以考虑是否要写专门的软件需求。
在基于模型的软件设计中，我们主要关心的是系统的功能需求，或者说可以通过软件实现的功能需求。如果这部分需求在系统需求文档里已经有非常清楚的定义，那么我们可以以系统需求文档作为依据建立模型。
当然，如果系统需求不是足够清楚，那我们有必要编写专门的软件需求文档。如果不考虑Simulink/Stateflow的应用上的问题，也就是说，如果我们都是熟练的Simulink/Stateflow用户，那么建模过程的主要工作是需求分析，通俗点讲，需求弄清楚了，建模也就是非常简单的事情了。
当然，建模的时候，要考虑未来的验证、实现以及后期维护的问题。
我个人的体会，这个阶段，不要着急建模，一定要先弄清需求，另外，建模的时候，模型架构非常重要。
有了模型之后，接下来要做什么事情。
代码生成。
这是很多比较初级的用户容易犯的错误，犯这个错误的用户，很大程度上是因为没有弄清楚为什么要做基于模型的设计。
为什么要做基于模型的设计。
我相信很多用户没有仔细考虑这个问题，很多用户做基于模型的设计的理由是：国外的公司都这么做，同行其他公司都这么做......弄清为什么要基于模型的设计，也就是要弄清楚基于模型的设计到底可以给我们带来哪些好处。
很多人会非常自然的想到，代码生成，代码生成可以提高软件开发效率。
没错，代码生成是一个很大的好处，但，代码生成不是唯一的，也不是最大的好处。
最大的好处是，算法的早期验证，之前NASA有研究表明，开发初期引入的bug，如果到了晚期才发现出来，那么修复这一的bug，会产生非常大的费用。
所以，我们期望能够尽早的发现开发过程中引入的bug。
如何尽早的发现设计上的错误。传统的开发模式里，我们使用review的方式去发现错误，在质量体系ISO9001里面有定义，任何一份设计，都必须要评审。评审的目的，也就是为了发现这个阶段的错误，以防错误被带到后续的开发过程中。
而评审的效率，却是非常低下的。我想凡是参加评审的网友都会有体会。比如，我在做完一份设计之后，我会邀请我的同事来评审我的工作，而参加评审的这些同事，往往不能有足够的时间了解我的这份工作，而只能在评审会上听我介绍我做的工作，这样的评审，可能会发现一些非常明显的问题，除此之外的，很难发现问题。
评审作为一种非常传统的验证方式，并不能及时发现设计过程中引入的各种错误。
而仿真，从效率上讲，要远高于评审，仿真更容易发现设计中的问题。仿真是可以运行的，如果我们设定一些输入，运行模型之后，我们会得到相应的输出，我们很容易观测到此时的输出是否是我们期望的输出。另外还有好处，仿真的结果是确定的，给定输入，就会得到确定的输出，当然，期望输出也是确定的。而不像评审，同样的文字，对于不同人，可能理解成不同的含义。
代码生成和早期验证之外，基于模型的设计，还可以给我们带来其他好处，比如文档自动化。我们经常听到这样的说法：
l 我们终于把软件发布出去了，现在可以有时间补文档了...
l 下个月要audit了，所有同事都在补文档....
这里我要问：为什么要补文档。补文档，我们可以从中得到两个方面的信息：1.文档很重要，不能没有，至少从质量体系上要求我们必须有文档2.工程师都不愿意写文档，是啊，如果愿意写文档的话，在开发过程中自然会把各类文档写起来的。
好，工程师不愿意写，开发过程中又不能少，如果计算机可以帮我们写，岂不是很美好的事情。基于模型的设计，可以帮助我们实现文档自动化，至少有相当大的一部分文档可以让计算机替我们写。
其实，基于模型的设计，还有一个天然的优势：图形化设计。
对于工程师来讲，图形化的东西，本身就比文字更容易理解，否则我们在软件开发过程中也不会去画流程图和状态机了
所以总结一下，基于模型的设计可以从以下方面给我们提供便利：1. 图形化设计2. 早期验证3. 代码生成4. 文档自动化
前面我大概论述了为什么要做基于模型的设计，或者说基于模型的设计可以给我们带来哪些好处。这些好处，最终会大大提高开发效率，并且改善软件品质。下面，我在说说基于模型的设计里有哪些事情要做，刘博士说的没错，基于模型的设计，自然模型最重要，如何建模，毫无疑问是最为重要的环节。
在软件产品开发中，建模活动里，耗时最多的，就应该是需求分析了，需求分析不仅包括如何正确理解软件需求，而且要考虑如何通过模型实现，真正的画模型的时间，相比之下并不多，如果Simulink/Stateflow用的熟的话，真正打开MATLAB画模型的时间占建模阶段总时间的1/3都不到。
建模之后，接下来就是模型验证，验证，英文单词Verification，英文里面还有另外一个词Validation，确认，很多人不清楚这两个词之间的区别，通俗点讲：Verification是考察你是否正确的做了一件事，而Validation，则是考察你是否做出了正确的东西。一个强调的是过程，一个在乎的是结果。
闲话少说，咱们继续回到模型验证上来，通常模型验证包含如下活动：建模标准的检查、评审、单元测试、快速原型。（如果说的不完善，欢迎大家补充）
建模标准的检查，可以通过模型检查工具自动完成，建模标准检查的意义，和传统开发模式里C编码标准的意义一致，这里不展开了。
模型验证之后，接下来就可以做代码生成了，有关代码生成，也专门讨论吧。
1. 代码生成之后，需要做代码验证，基于模型的开发过程里面，SIL、PIL都是常用的代码验证方式。
2. 在代码做完SIL或者PIL测试之后，要考虑软件集成了，即应用层软件，也就是通过Simulink模型生成的软件，和底层驱动软件之间的集成。
3. 软件集成之后，后面的事情，基本上和传统的开发模式差不多了，当然，相对于传统的开发模式，你可以多一个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进行模型的结构分析，借助于Simulink Design Verifier自动生成测试用例的功能，去检查结构上是否存在问题，比如是否有不合理的逻辑设计，是否有运行不到的分支等。
再往后，就可以进行模型单元级别的功能测试了。软件开发过程中，对单元测试的要求是很高的，一般会根据应用的安全性、可靠性要求，给出测试的覆盖率要求。
这个过程中工作量最大的应该是测试用例设计以及测试向量的生成。
测试用例设计，我们一般会根据需求去设计测试用例，当然，也会结合模型结构设计测试用例，这样说来，这里的测试，已经包含了黑盒测试和白盒测试。有了测试用例，如何把测试用例转换为测试向量，这也是非常重要的环节。我们知道，在MBD开发过程中，代码都可以自动生成，其他环节，我们要努力做到自动化实现。我们可以使用MATLAB脚本开发一些转换工具用于将测试用例转换为测试向量，我们还可以通过脚本实现测试过程的自动化。。