《(ModelBaseDesign)基于模型的设计.pdf》由会员分享，可在线阅读，更多相关《(ModelBaseDesign)基于模型的设计.pdf（16页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、什么叫基于模型的设计？为什么要基于模型的设计？基于模型的设计过程中，需要做什么事情？再问几个小问题：模型验证是否必要？模型验证有哪些工作可以做？模型验证是否一定需要被控对象模型？代码生成效率如何？底层驱动是否要建模？Embedded Coder以前的 RTW Embedded Coder支持哪些芯片？MIL、SIL、PIL、HIL 的目的和实现方式？如何定点化？如何做代码集成？什么叫基于模型的设计？这是一个很大的话题，因为本人能力所限，仅讨论使用 Simulink 模型开发嵌入式软件的设计过程。也就是说，我只能聊基于模型的嵌入式软件设计。我的理解是，通过对算法建模进展软件设计的过程，都可以叫基
2、于模型的设计。当然，如果仅限于算法建模，把 Simulink/Stateflow 当做 Visio 使用，而不去进展其他环节的工作，这样的基于模型设计是不完整的，可能对你的开发效率不会有很大的提升。如果想通过基于模型的设计提升软件开发团队的开发效率，提高软件品质，我觉得至少有如下几点可以考虑：算法建模算法模型的验证文档自动化代码生成代码和模型的等效性验证。传统的开发过程中，我们有一个环节，需求捕获，也即，从系统需求分解出软件需求。在基于模型的设计过程中，我们同样可以通过分析系统需求，获得软件需求。当然，根据系统需求的详细程度，我们可以考虑是否要写专门的软件需求。在基于模型的软件设计中，我们主要
3、关心的是系统的功能需求，或者说可以通过软件实现的功能需求。如果这局部需求在系统需求文档里已经有非常清楚的定义，那么我们可以以系统需求文档作为依据建立模型。当然，如果系统需求不是足够清楚，那我们有必要编写专门的软件需求文档。如果不考虑 Simulink/Stateflow 的应用上的问题，也就是说，如果我们都是熟练的 Simulink/Stateflow 用户，那么建模过程的主要工作是需求分析，通俗点讲，需求弄清楚了，建模也就是非常简单的事情了。当然，建模的时候，要考虑未来的验证、实现以及后期维护的问题。我个人的体会，这个阶段，不要着急建模，一定要先弄清需求，另外，建模的时候，模型架构非常重要。
4、有了模型之后，接下来要做什么事情？代码生成？这是很多比拟初级的用户容易犯的错误，犯这个错误的用户，很大程度上是因为没有弄清楚为什么要做基于模型的设计？为什么要做基于模型的设计？我相信很多用户没有仔细考虑这个问题，很多用户做基于模型的设计的理由是：国外的公司都这么做，同行其他公司都这么做.弄清为什么要基于模型的设计，也就是要弄清楚基于模型的设计到底可以给我们带来哪些好处？很多人会非常自然的想到，代码生成，代码生成可以提高软件开发效率。没错，代码生成是一个很大的好处，但，代码生成不是唯一的，也不是最大的好处。最大的好处是，算法的早期验证，之前 NASA 有研究说明，开发初期引入的 bug，如果到了
5、晚期才发现出来，那么修复这一的 bug，会产生非常大的费用。所以，我们期望能够尽早的发现开发过程中引入的 bug。如何尽早的发现设计上的错误？传统的开发模式里，我们使用review 的方式去发现错误，在质量体系ISO9001 里面有定义，任何一份设计，都必须要评审。评审的目的，也就是为了发现这个阶段的错误，以防错误被带到后续的开发过程中。而评审的效率，却是非常低下的。我想但凡参加评审的网友都会有体会。比方，我在做完一份设计之后，我会邀请我的同事来评审我的工作，而参加评审的这些同事，往往不能有足够的时间了解我的这份工作，而只能在评审会上听我介绍我做的工作，这样的评审，可能会发现一些非常明显的问题
6、，除此之外的，很难发现问题。评审作为一种非常传统的验证方式，并不能及时发现设计过程中引入的各种错误。而仿真，从效率上讲，要远高于评审，仿真更容易发现设计中的问题。仿真是可以运行的，如果我们设定一些输入，运行模型之后，我们会得到相应的输出，我们很容易观测到此时的输出是否是我们期望的输出。另外还有好处，仿真的结果是确定的，给定输入，就会得到确定的输出，当然，期望输出也是确定的。而不像评审，同样的文字，对于不同人，可能理解成不同的含义。代码生成和早期验证之外，基于模型的设计，还可以给我们带来其他好处，比方文档自动化。我们经常听到这样的说法：我们终于把软件发布出去了，现在可以有时间补文档了.下个月要
7、audit 了，所有同事都在补文档.这里我要问：为什么要补文档？补文档，我们可以从中得到两个方面的信息：1.文档很重要，不能没有，至少从质量体系上要求我们必须有文档2.工程师都不愿意写文档，是啊，如果愿意写文档的话，在开发过程中自然会把各类文档写起来的。好，工程师不愿意写，开发过程中又不能少，如果计算机可以帮我们写，岂不是很美好的事情。基于模型的设计，可以帮助我们实现文档自动化，至少有相当大的一局部文档可以让计算机替我们写。其实，基于模型的设计，还有一个天然的优势：图形化设计。对于工程师来讲，图形化的东西，本身就比文字更容易理解，否那么我们在软件开发过程中也不会去画流程图和状态机了。所以总结一
8、下，基于模型的设计可以从以下方面给我们提供便利：1.图形化设计2.早期验证3.代码生成4.文档自动化前面我大概论述了为什么要做基于模型的设计，或者说基于模型的设计可以给我们带来哪些好处。这些好处，最终会大大提高开发效率，并且改善软件品质。下面，我在说说基于模型的设计里有哪些事情要做，刘博士说的没错，基于模型的设计，自然模型最重要，如何建模，毫无疑问是最为重要的环节。在软件产品开发中，建模活动里，耗时最多的，就应该是需求分析了，需求分析不仅包括如何正确理解软件需求，而且要考虑如何通过模型实现，真正的画模型的时间，相比之下并不多，如果 Simulink/Stateflow 用的熟的话，真正翻开 M
9、ATLAB 画模型的时间占建模阶段总时间的 1/3 都不到。建模之后，接下来就是模型验证，验证，英文单词Verification，英文里面还有另外一个词 Validation，确认，很多人不清楚这两个词之间的区别，通俗点讲：Verification 是考察你是否正确的做了一件事，而 Validation，那么是考察你是否做出了正确的东西。一个强调的是过程，一个在乎的是结果。闲话少说，咱们继续回到模型验证上来，通常模型验证包含如下活动：建模标准的检查、评审、单元测试、快速原型。如果说的不完善，欢送大家补充建模标准的检查，可以通过模型检查工具自动完成，建模标准检查的意义，和传统开发模式里 C 编码
10、标准的意义一致，这里不展开了。有关评审和单元测试，再专门开贴说吧。模型验证之后，接下来就可以做代码生成了，有关代码生成，也专门讨论吧。代码生成之后，需要做代码验证，基于模型的开发过程里面，SIL、PIL 都是常用的代码验证方式。在代码做完 SIL 或者 PIL 测试之后，要考虑软件集成了，即应用层软件，也就是通过 Simulink 模型生成的软件，和底层驱动软件之间的集成。软件集成之后，后面的事情，根本上和传统的开发模式差不多了，当然，相对于传统的开发模式，你可以多一个 HIL 环节出来，不过话又说回来，即便是传统的开发模式，也一样可以有 HIL 这个环节的。有关 HIL 的实现及目的，以后再
11、说。再说说模型验证的必要性。我在进入 MathWorks 之后，接触过很多客户，不少客户在最初引入基于模型设计的时候，根本不在意模型验证工作，他们经常在模型编译通过之后就拿去生成代码，有了代码之后将代码下载到各种快速原型设备上去测试算法，Simulink 的仿真功能根本上成了摆设。并且在这个阶段，不管我如何苦口婆心的给他们介绍模型验证的重要性，在他们那边，却总有各种各样的借口去省略模型验证环节，“工程时间太紧，模型来不及测，“我们知道标准的开发流程，但是现在人手不够。当然，这类用户经常在这样折腾了一段时间之后，还是要回到模型测试上来，他们最终会发现，在 HIL 设备上测试算法，实在太难，当然，
12、也有坚持的，坚持的结果就是他们所谓的基于模型的设计，开发效率比传统的开发模式高不了多少。其实，这个问题我们可以这么去看，模型阶段的测试，我们是可以分模块进展的，而 HIL 上测试，根本上是集成之后的软件。比方，一个软件有 10 个模块，在 HIL 设备上，你很难别离出每个模块的 bug，而如果是按模块做单元测试，那么就是针对的一个具体的模块。打一个不算恰当的比方，我们都知道一块 2 克拉的钻石，价格肯定不是一块 1克拉钻石的两倍。类似的，如果每个软件模块有 2个bug，那么你从集成好的软件里去消除这 20 个 bug，消耗的精力肯定不是从每个单元模块里去消除 bug 所耗精力的总和。说白了，早
13、期验证是非常重要的，很多软件工程的教材里都有相关的统计数据说明早期验证的重要性，对应到基于模型的开发过程，能在模型级别做的验证，一定不要拖到后续的环节中。中国有句老话，“心急吃不了热豆腐，“工程时间紧或者“人手不够不能成为我们忽略模型测试的借口。继续说一下 MBD 开发过程中都有哪些验证工作要做。模型出来并且可以编译之后，首先要做建模标准检查，这个过程使用工具比方 MathWorks 公司的 Simulink Verification&Validation 提供的model advisor自动化的完成，检查过后，修改模型中不符合公司建模规那么的工程。接下来，就可以进展模型评审了，也就是说，评审
14、的模型有两个前提，一是可以编译的，二是符合公司建模规那么的。这两个前提可以帮助我们消除模型中的一些低级错误，防止在评审过程中有太多的时间花费在这些错误上。因为评审是建模的工程师和其他同事共同参和的活动，做到上述两个前提，也是对其他同事工作时间的一种尊重。评审之后，建模的工程师会修改评审中发现的问题，问题多的话，一般会要求修改之后再进展“再评审，直到在评审中不会发现大量问题。接下来，我们可以使用 Simulink Design Verifier 进展模型的构造分析，借助于 Simulink Design Verifier 自动生成测试用例的功能，去检查构造上是否存在问题，比方是否有不合理的逻辑设
15、计，是否有运行不到的分支等。再往后，就可以进展模型单元级别的功能测试了。软件开发过程中，对单元测试的要求是很高的，一般会根据应用的平安性、可靠性要求，给出测试的覆盖率要求。这个过程中工作量最大的应该是测试用例设计以及测试向量的生成。测试用例设计，我们一般会根据需求去设计测试用例，当然，也会结合模型构造设计测试用例，这样说来，这里的测试，已经包含了黑盒测试和白盒测试。有了测试用例，如何把测试用例转换为测试向量，这也是非常重要的环节。我们知道，在 MBD 开发过程中，代码都可以自动生成，其他环节，我们要努力做到自动化实现。我们可以使用 MATLAB 脚本开发一些转换工具用于将测试用例转换为测试向量
16、，我们还可以通过脚本实现测试过程的自动化。测试的指标，即测试覆盖率是否到达公司的要求或者行业的要求。单元级别的功能测试完成之后，我们自然会进展集成测试，当然，集成测试是分阶段、有步骤的，我们可以先把一些单元模块集成为组件级，进展组件级的集成测试，然后再将组件集成为系统级，进展系统级测试。集成测试和单元测试关注的内容不同，集成测试，我们更关注于单元模块之间的借口关系、调用关系等等，所以，单元测试中要求的判定覆盖率、MCDC覆盖率等，在集成测试中没有这样的要求。条件允许的情况下，集成测试之前或者之后，可以通过快速原型的方式和实物相连，进展测试。集成测试通过之后，我们根本上可以认为模型或者说算法是正
17、确的了。接下来，我们就可以进展代码生成了。代码生成之后，会跟着做 SIL、PIL、HIL 等测试，所有这些 In-the-Loop测试都不是必须的，工程师应该根绝工程的实际情况，选择合理的测试方案，当然，建议 SIL 测试不要省略，原因在于这种测试确实非常方便做，并且也确实会发现一些代码生成过程中出现的问题。前面提到模型验证，下面再说说代码生成。代码生成的前提是模型已经是验证过的模型，或者说，是正确的模型。正确的模型包含两层含义，模型做过足够多的验证，验证的结果都是正确的。前面提到的各种验证方式，都有必要做，对于功能测试来讲，还有必要到达足够高的覆盖率要求。做到以上这些，就可以考虑进展代码生成
18、工作了，代码生成是否就是按一下“Code Generation按钮的工作呢？工程工程开发中，没那么简单，代码生成过程中，工程师要做的主要工作是数据管理工作，除此之外，还会有一些代码相关的配置，比方函数原型、比方代码文件等等。数据管理主要是对 Simulink/Stateflow 模型中的两类数据进展管理，一是信号，一是参数。对应于 C 代码，我们可以简单的把信号对应到变量上，而参数，那么是不通过程序运行而发生变化的，参数的变化，一般是通过人工调节完成的，也就是参数调节，参数调节的目的是为了选择适宜的参数以得到最正确的性能。数据管理的方式，使用的是数据对象进展数据管理，这里的“对象二字，和我们经
19、常听到的“面向对象编程里面的“对象意义一样。Simulink为用户事先定义好两个包，一个是 Simulink Package，一个是 mpt Package。以 Simulink Package 为例，包里面有类，分别为和两个类。用户可以通过这两个类定义相应的对象 Object，然后通过类提供的属性 Property定义数据的属性。其实这两个类里面除了属性之外，还定义了方法Method，一般情况下，我们管理数据，使用属性就够了。当然，不管是 Simulink Package 还是 mtp Package，都不能完全满足用户的所有要求，所以，很多时候，需要用户定义自己的 Package。依然按照
20、面向对象里面的一些概念，我们可以从Simulink Package或者mpt Package继承并创立自己的包。所有我们关心的数据都通过数据对象的方式做了定义之后，接下来的工作，就是按下按钮，生成代码了。-因为前面预留的帖子不够多，所以，就继续在这个帖子里讨论一下自动生成的代码吧。首先说一下大家很关心的效率问题，代码效率，我之前做过比照，比一般的工程师写的代码效率要高，当然，我相信对于那种 C 代码高手，一定可以写出效率更高的代码。不过我想强调的是，自动生成的代码，是可以用的，不要有任何心理障碍，毕竟，我们工程开发中的多数工程师也不是绝对的 C 语言高手。另外，关于效率，我最近也做过一次比照，
21、就在这个帖子最开头提到的那个贴子里，虽然代码没有人去做编译，但从代码行数来看，和一个写了 6 年 C 代码的工程师的代码根本差不多。再说说代码可读性的问题，很多人和我强调代码的可读性不如手写的好，我有条件的成认这一点。为什么是有条件的成认呢，我想说，如果你对模型做足够多的配置，生成的代码可读性根本上可以和手写的差不多。当然，我更想强调，在基于模型的开发过程中，我们是不读代码的如果一定要读，那也是读那个.h 文件，我们有其他方式保证代码是正确的，无须读代码。再有一个问题，就是代码的集成问题，很多人也比拟关心自动生成的代码如何集成到底层代码或者如何和其他手写代码做集成的问题，我一般会问他，如果这个
22、模块的代码是手写的，你会怎么集成？他当然知道手写代码该怎么集成，好，自动生成的代码也同样可以集成。做代码集成的时候，我们关心的就是那个.h 文件。有关底层驱动的建模，我一直认为在产品化工程开发中，底层驱动是没有必要建模的。原因如下：1底层驱动在 Simulink 环境下不能仿真；2底层驱动建模需要熟悉另外一种脚本语言TLC；3产品化工程的底层软件往往很大，有些工程的底层软件甚至大于应用层软件，如此大的软件转换成 Simulink 下的 TLC实现，不容易操作。当然，有人会说，一旦有了底层驱动模型，就可以非常方便的实现 Simulink模型到单片机 hex 文件的一键式实现，确实这样做貌似让整个
23、开发过程的自动化程度得以提升，但是，不要忘记，你要开发出一个平安、可靠的底层模块库，会需要大量的时间投入，尤其在使用 TLC 设计的时候，TLC 本身就是另外一种新的语言，同时这种语言所提供的调试环境也不尽如人意；相反，如果不使用这种一键式的模式，而是采用手工集成的方式实现自动生成的应用层代码和底层代码做集成，也是非常简单，非常轻松的事情。总结一下，一键式的实现 hex 文件生成并不能明显提高开发效率，而开发出这样一个底层模块库，却需要花费大量的时间。-到 MathWorks 工作以来，经常被客户问到这样的问题：MATLAB 的代码生成支持什么芯片？支持什么芯片？MATLAB 生成的是 ANS
24、I C 代码，支持所有编译器，也就是支持所有芯片。当然，我说的是应用层代码的生成，不包括底层驱动代码。我也知道很多人问这个问题的时候，心里面想着的是Target SupportPackage 这样一个工具包，这个包里面确实提供了一些 MCU 或者 DSP 的底层驱动模块，借助于这些模块，我们可以生成底层代码。不过，继续强调一下，在很多工程化的工程里，这不是一个产品化的解决方案，这种方案更适合于做算法的快速验证。也正是因为这不是一个产品化的方案，所以这个产品的用户非常少，以至于 MATLAB 从 2021a 开场，不再单独销售这个模块，并不承诺以后会继续更新这个模块，这个模块连同 IDE Lin
25、k 被打包到 Embedded Coder 产品中，只有你购置了 Embedded Coder，你就可以使用这个模块了。-再说说 In-the-Loop 测试的问题吧。我们经常听到的有 MIL、SIL、PIL、HIL 等，在基于模型设计的开发过程中，是否都要做这些 In-the-Loop 测试？我认为所有的 In-the-Loop 都不是一定要做的，不过，我非常建议不要省略 SIL 环节。1MIL，模型在环测试，在 Simulink 环境里，除建立控制器模型之外，还需要建立被控对象模型，讲控制器和被控对象连接起来并形成闭环，让控制器去控制被控对象。是否一定要做这个 In-the-Loop 呢？
26、或者说，是否一定要有被控对象模型呢？其实不一定，这取决于模型验证的可能方式。在不少应用里，控制器模型的输出是开关量，工程师可以很方便的通过设定输入并给出期望输出，这样的情况，被控对象是没必要的，比方，汽车电子里面的车身控制，控制一个灯的开或者关，只需要知道输出是 ON 或者 OFF 即可，没必要去做一个灯泡的模型放到 Simulink 里。2SIL，软件在环测试，软件在环测试，应该说是从模型在环测试引申过来的，区别只是把控制器的模型换成了由控制器模型生成的 C 代码编译成的 S-function，SIL 的目的是为了验证生成的代码和模型在功能上是否一致，或者说验证生成的代码和模型在功能上是否等
27、效。验证等效性，是否一定需要被控对象模型？不必要，既然验证生成的代码和模型的一致性，那只需要给生成代码和用于代码生成的模型一样的输入，比拟它们在一样的输入条件下，输出是否一致即可。3PIL，PIL 有两个目的，一是为了等效性验证，二是为了测量模型生成的代码在目标处理器上的运行时间。有关运行时间的测量，如果你选择的处理器足够强大，或者你非常把握目标代码的运行不会超限，那么 PIL 的意义就要打折扣了。4HIL 测试的目的是为了验证控制器的，HIL 过程中，会把被控对象的模型生成 C 代码并编译成可执行的文件放到工控机上运行，以便工控机替代真是的被控对象，然后把控制器和工控机连接起来，实现闭环控制
28、，从控制器的角度上看，就相当于工作到实际控制系统之中。HIL 经常被用于以下几种情形：a被控对象非常昂贵，如果控制器不成熟会导致被控对象的损害；b被控对象失效会危及人身平安；c开发过程中，先开发出了控制器，而被控对象还没有开发出来。有关在环测试，通常有以下几种：模型在环测试MIL软件在环测试SIL处理器在环测试PIL硬件在环测试HIL模型在环，毫无疑问，就是 Simulink 模型里既包含控制器模型也包含被控对象模型，二者形成闭环，进展测试，用于检查控制器模型或者说控制算法里的 bug，这个阶段的测试如果足够充分，那么测试后的控制算法，在 Simulink 这个级别上，我们可以认为是正确的。算
29、法验证之后，下一步要做的事情就是生成代码，为了防止代码生成器因为自身 bug 会导致生成的代码不正确，流程中建议使用 SIL 的方式进展测试，也就是将控制算法模型生成的代码编译成 Sfunction，替换原来模型中的控制器局部，重复 MIL 阶段所做的测试，如果测试之后，Sfunction表现出来的功能和以前的模型表现出来的功能完全一致，那么我们可以推理生成的代码和用于代码生成的模型是一致的。所以，软件在环测试的目的是为了验证代码和用于生成代码的模型之间的等效性，这一个环节存在的必要性是因为我们对代码生成工具的不信任。既然 SIL 是为了测试等效性，那么我们其实可以简化所谓的 SIL 测试，不必通过闭环去做验证，而只要将控制器模型和控制器模型生成的代码编译成的 Sfunction 放到同一个模型里，给二者加载一样的输入，观测二者输出是否一致即可到达等效性验证的目的。PIL 和 HIL 就先不说了，欢送继续讨论。