MBD下的软件开发模式.doc

MBD下的软件开发模式.doc

《MBD下的软件开发模式.doc》由会员分享，可在线阅读，更多相关《MBD下的软件开发模式.doc（6页珍藏版）》请在冰点文库上搜索。

MBD模式下的软件开发流程介绍

王淳

（联创汽车电子有限公司，上海浦东201203）

【摘要】

以模型为基础的软件开发，我们称之为MBD（Model-BasedDesign）。

和传统的嵌入式软件开发模式相比，MBD模式无疑是一个巨大的进步，肯定会在今后几年内普及，并完全代替现有嵌入式软件的开发模式。

【主题词】MBD，软件开发流程及工具，MIL，SIL，PIL，HIL

一、变革的力量：

上次的变革：

90年代，国内嵌入式软件开发还停留在汇编语言的层次，汇编语言虽然灵活、效率高，但是在处理浮点计算、复杂逻辑运算等问题上，软件开发的工作量相当大。

而同期国外已经大面积普及了以C语言为基础的嵌入式系统开发流程。

当年很多程序员对于C编译器的正确性、可靠性、效率还都抱有过怀疑的态度，但是随着keil、tasking等公司不断推出的优质的C编译器，这种疑虑很快被打消。

C代码不需要程序员关心浮点算法；对复杂逻辑的设计也很方便；而且针对于嵌入系统硬件资源有限的情况，很多专用的C编译器都提供各种优化选项；通过对堆栈的灵活运用，解决了RAM空间不足的问题；代码的可移植性、可继承性也远强于汇编语言。

短短几年时间，C语言编程在国内嵌入式系统的开发中已经普及。

先进工具可以大大提高劳动生产率，这一点在这次变革中体现的非常明显。

现在的革命：

而基于模型进行嵌入式系统开发流程，其优越性以及对传统开发方式的颠覆，一点也不比当年的变革小。

对于嵌入式系统开发而言，存在以下一些具体的问题：

l现在嵌入式系统的复杂程度，比起几年前又上了一个台阶，传统C语言开发采用流程图的辅助设计方式，已经很难表达复杂的程序逻辑；

l以手工编写C代码，还是会出现很多低级错误；

l现在的系统开发周期越来越短，再沿用过去那种硬件设计->软件设计->集成调试的流程，无法开展硬件和软件的并行开发；

l随着系统复杂性的增加，用户对最终功能的确定也越来越模糊，很多情况下，用户都需要在得到样机后，才能开展测试，并提出修改意见，从而导致开发的反复，大大增加了开发成本和时间。

l虽然C代码已经在各个嵌入平台上普及，但是因为代码设计者设计思路的局限，加之传统流程图的单线设计思路，软件模块的可继承性还是比较差。

国外的企业已经从90年代后期，逐步开始采用MBD开发流程，使用建模工具对复杂嵌入式系统进行分析设计。

随着建模工具及配套设备的完善，使得自动代码生成的工具链也逐渐清晰。

现在已经有很多极复杂系统，如电喷控制器等等，全部采用了MBD的设计流程。

MBD工具链的可靠性、稳定性已经无需怀疑。

l以建模工具对复杂逻辑进行设计、分析、仿真，使得系统需求分析和软硬件开发结合得更加紧密，系统分析不再仅仅停留在文档阶段，而是直接和设计挂钩。

l采用了MBD的设计流程后，在硬件设计的同时，软件设计即可全面展开，大大缩短了开发周期。

l从软件开发的第一步开始，工程师就可以观察结果，调试逻辑，大大加快调试进度。

l采用成熟工具，可以实现代码自动生成，完全避免了手工编码的低级错误。

并且在设计修改后，极短时间内即可重建系统软件，而无需进行多次反复测试。

l采用建模工具及辅助设备，可以在模型建立后，立即实现快速原型仿真，用户马上可以看到设计运行的结果，工具可以协助用户及时修改需求，在最短的时间内完善需求设计。

l模型的可移植性，远强于C代码，可以方便的建立公司内的系统设计模型库，节约开发成本。

二、MBD开发流程的环节和作用：

2.1系统设计定义阶段

系统设计定义阶段的目的是：

针对用户提出的初步需求，逐步细分，将功能需求拆解为可实现功能定义，并且建立系统级模型，包括控制器模型（controller）、被控对象模型（plant）、测试案例模型（referenceposition）。

其中，测试用案例模型和被控对象模型，是系统设计工程师根据用户需求设计的。

在整个开发流程中会多次使用，也是系统设计定义阶段重点关注的内容。

系统设计定义环节本身也将在整个设计流程中反复迭代，用户需求会在不同的阶段逐步完善，这些修改最终都需要反馈到系统设计定义中，主要是反馈至测试用案例模型中。

控制器模型也在系统设计定义阶段直接输出，这样后续的工作都可以在统一的模型上完成，而不需要在代码、模型、文档之间频繁切换，一方面可以节约时间，一方面可以始终得到最准确的需求文档。

控制器模型的详细设计可以由后续的环节完成，在系统设计定义阶段可以只定义为顶层模型。

不必细究。

系统设计定义阶段，建议使用MATLAB提供的SimulinkVerificationandValidation（V&V）工具，使用这个模块，可以将需求与模型关联起来，通过SignalBuilder（SimulinkLibraryBrowser->Sources->SignalBuilder）来设计测试案例，通过V&V工具，对模型执行覆盖度分析；也可以用工具（DesignVerifier）自动为模型生成符合模型覆盖度要求的测试用例。

这种测试用例和需求文档（doors），可以做一一对应的关联。

2.2模型设计阶段

在MBD开发流程中，模型设计阶段的主要工作就是设计控制器模型，根据系统需求的要求，采用MIL技术，对控制器的控制逻辑进行细化。

细化的过程从顶层模型开始，直接使用系统设计定义阶段设计的案例模型和被控对象模型，对细化后的控制器模型进行仿真测试，这个步骤就是MIL（ModelInLoop）模型在环仿真。

MIL的最终结果，是得到一个可以实现所有控制逻辑的控制器模型，这个模型可以不必关系具体的硬件接口，因为被控对象模型及案例激励都是以模型形式存在的，整个环路的仿真可以直接在MATLAB环境下运行。

模型设计阶段的目的是：

算法设计，完成算法有效性检验；

比例扩放设计，溢出检测，为后续定点化取得基础数据；

用例跟踪，对测试用例的结果进行记录，并反馈不合理值，修改系统设计定义。

模型设计阶段，整个模型都以浮点运行，所以保证了计算的精度和合理的取值范围。

建议使用第三方提供的RCP工具，如dSpace公司的AUTOBOX等，对MIL的结果进行实际验证。

这类工具不需进行模型定点化，硬件IO定制也非常简单，可很方便地将模型下载运行。

通过简单电路调整，即能直接控制被控对象。

在RCP工具的帮助下，软件设计阶段时用户已经能够参与系统开发，直观地看到系统运行的结果，并及时地修改完善系统需求。

2.3C代码生成及调试阶段

在模型开发完毕后，需要将PC机上运行的浮点模型，转换为可以在定制嵌入CPU上运行的模型代码，考虑到现阶段嵌入式CPU的资源还不够丰富，系统开发对成本的限制需求等等，直接在CPU上进行浮点运算的方案还是比较少。

C代码生成及调试阶段，要通过SIL（softwareinLoop），对模型进行定点化验证。

所谓SIL，就是在保证代码效率、兼顾计算精度和数据表达范围的情况下，采用autoscaling等技术，将模型进行定点化。

然后用自动代码生成工具，把模型转换为标准C代码，再将C代码封装为可以在MATLAB环境中执行的模块，代替原有浮点模型，进行软件在环仿真。

浮点运算和定点运算在精度和数据表达范围上存在巨大差异，不进行验证直接转换模型肯定会带来无法估量的误差；MATLAB模型中，如果不加强制限制，各个模块的计算顺序是由MATLAB自己设定的，可能和工程师的看法完全不同；而在MATLAB的模型内，对各个环节的算法，是以MATLAB自己的M语言、库函数、采样周期、时序结构来进行的，其计算步长可能是变化的，而这些都和实际嵌入式C代码存在很大差异（由简单的积分环节组成的常微分方程，在MATLAB中可能采用龙格库塔法等迭代算法进行计算，而在普通嵌入式C代码中，总是对一个个的积分进行累加计算），这种算法上的差异，也会导致最终结果的完全不同，这也是必须要进行SIL仿真的原因。

这个阶段非常关键，也是国内走MBD路线进行嵌入式系统软件开发时比较容易忽略的一环。

正常情况下，设计一个可以正确运行的模型并不难，但是要进入工程设计，将模型转换为实际的嵌入式C代码，就必须按部就班地完成以上步骤。

在SIL环节，采用自动代码生成工具，将控制器模型转换为标准C代码，算法和时序都可以由工程师确定，再将模型生成的C代码（仅限于控制逻辑部分，IO部分暂不包括），以S函数的方式（或其他方式）封装为模块，这种模块可以直接在MATLAB里运行，其内部运行机制取决于C代码本身。

然后再取代原模型中的控制器模型，联合测试用案例模型和被控对象模型，进行仿真。

这一步目的是为了检查定点化以后代码的计算精度、算法是否合理、是否产生溢出等，然后及时修改原模型，反复进行SIL仿真后，保证模型定点化的正确性。

C代码生成及调试阶段，建议使用MATLAB内自带的RTW，或者dSpace公司的TargetLink等工具。

2.4硬件代码生成调试阶段

在这个阶段，硬件设计必须已经完成。

所谓PIL，就是将经过SIL设计的模型，在工具的协助下，生成可以在指定CPU上运行的嵌入式C代码，并下载至指定CPU的DEMO板上直接运行，通过数据接口，和MATLAB上的测试用案例模型及被控对象模型进行数据交互，进一步验证代码准确性。

因为SIL环节的C代码是在INTEL系列CPU的PC机上运行的，虽然C代码的正确性得到了验证，但是如果转换为汇编机器码，INTEL芯片代码和我们嵌入式系统的指定芯片的代码还是有差别的。

进行PIL的目的就是为了检验这两种代码间差异是否可以接受。

同时，在PIL环节，模型生成的嵌入式C代码直接在指定CPU上运行，模型逻辑控制部分的代码和最终实际运行的代码完全一致，并且运行环境也大体相当，可以对代码时序的精确性进行进一步验证。

PIL的技术过程是，建模工具提供接口，通过串口之类的通道，和下载到DEMO板上的控制逻辑代码进行交互，把测试用例模型的输出数据下载到DEMO板，把控制逻辑代码的计算结果返回到被控对象模型，形成一个完整的闭环仿真。

PIL需要有特殊硬件支持，部分芯片可能无法进行PIL环节仿真。

接下来需要把经过SIL、PIL验证的模型，生成特定CPU的机器码，再加入部分和硬件相关的IO驱动代码，一起编译，下载至我们自己设计的硬件运行。

主要目的，是将自动生成的代码将和硬件一起联调，解决IO驱动和模型代码之间的接口问题，并形成稳定的IO驱动代码库，保证后续修改模型时，不用再次修改底层驱动。

这个阶段建议使用RTW及TargetLink，以及专用的C编译器、PIL仿真用DEMO板。

2.5硬件在环

HIL（hardwareinLoop），是指控制器采用实际硬件，加上由模型生成的C代码（也许有部分手工设计的底层驱动程序）。

而被控对象，可以由模型仿真实现。

这个步骤主要是针对那些被控对象复杂、实验费用高昂、有着繁琐测试逻辑的系统设计而言。

在这类系统中，采用模型仿真被控对象，可以大大加快实验进度，覆盖诊断案例（如发动机飞车处理等）。

如果被控对象简单，可以不用软件进行仿真，而采用labcar之类的实物直接验证。

HIL阶段，可以发现设计中被忽略的问题，如实际线缆的干扰、人工输入的错误等等，将这类问题及处理方法需要及时反馈到测试用例、被控对象模型、控制器模型中，进一步完善系统设计定义。

硬件在环阶段，建议使用labcar或者AUTOBOX之类工具，模拟实际被控对象，自动测试、自动记录，对控制逻辑进行覆盖性测试。

2.6实车测试

实车测试阶段和传统开发流程的实车测试阶段并无区别，只是在发现问题后，需要返回对系统定义设计阶段的相关模型进行修改，并在控制器模型的基础上，修改控制策略，解决问题，经过仿真迭代后再回到实车测试。

这样可以保证模型的正确性，代码和模型的统一。

三、总结语

在整个设计开发流程中，所有的文档都可从模型工具直接生成，任何对模型的修改，都能立即反应到文档中。

模型本身也可以作为一个最详细设计文档，只要加入适当的变量说明和必要注释，这种文档包含的内容非常清晰，其可理解性、准确性、一致性，远远超过普通的文本文档。

MBD模式下的嵌入式软件开发流程，虽然看起来很复杂，但是只要正确使用合理的工具链，诸如MIL、SIL、PIL、HIL等环节，并不会占用研发工程师的太多时间。

整个工具链合理配置后，所有的工作都自动进行，大大提高了测试效率。

采用MBD模式下的嵌入式软件开发流程，上面介绍的环节，都强调“在环仿真”的概念，设计修改好的模型，都需要在有控制对象、固定的测试用例的条件下，反复多次仿真验证，保证设计一贯性、完整性、正确性。

浮点模型和定点代码之间的转换，以及和硬件相关部分代码的集成，是传统开发流程中不存在的部分，需要小心谨慎。

工程师的主要工作集中在模型设计、仿真验证、以及和用户沟通上，不再去担心代码本身质量。

模块化的测试用例、模块化的被控对象、模块化的控制逻辑，都以模型的形式存在，不同的项目间可以很方便的移植，最终在硬件代码生成调试阶段，和特定编译器的集成即可。

【参考文献】

[1] SoftwareDevelopmentProcessforaDrive-by-wirePowertrain——DaimlerChryslerAG2002

[2] UsingSimulink——TheMathWorksInc.

作者简介：

王淳，男，毕业于哈尔滨工业大学自动控制专业,研究方向为发动机控制器。

通讯地址：

中国上海祖冲之路899号11号楼

邮编：

201203

联系电话：

（0）50797828-639（王淳）

Email:

wangchun@