模型的代码生成器的系统测式.docVIP

622 基于模型的系统的测试 代码生成程序 Ingo Stu¨ rmer, Mirko Conrad, Heiko Do¨ rr, and Peter Pepper,，成员，IEEE 摘要：不象常见命令式程序语言(如C或者ADA) 编译器，维护了基于模型的代码生成器生成的构件没有既定的方法存在尽管在形式验证领域取得进展。几种测试方法在工程实践中处于支配地位。 这篇文章为使用在基于模型开发的代码生成器描述一个通用和工具独立的测试体系。 我们通过测试TargetLink代的有效性。 TargetLink代码生成器在基于模型自动化开发中是一个被广泛地接受和复杂开发工具。 索引术语 测试和调试。 1 绪论 汽车的嵌入软件被开发方式已经改变。 可执行的模型现在被使用在开发的全部阶段，从起初设计到到实现(基于模型的发展)。用大众流行图形建模语言进行模型设计，象来自MathWorks [1]的Simulink/Stateflow。新的方法允许通过所谓的代码生成器直接从Simulink和Stateflow自动生成可控有效的代码，象dSPACE[2]的TargetLink或者MathWorks[3]的实时工作室嵌入代码编码器个代码生成器本质上是一个编译器，它把一个用图形建模语言表示的源程序翻译成象C或者ADA一样的一个命令式语言。代码生成器相当地降低软件实现的努力。也，通过在模型级早期的质量保证获得质量级别可以导致高质量代码，提供代码生成器工作正确。由于这些特征，代码生成器有一个强大工业需求。 基于模型代码生成器与传统编译器不同有几个方面。1）目标语言和源语言两者都可执行的。因此，代码生成器的可执行行为能直接与模型的仿真行为比较。2）模型语言的语义经常不是明确的定义。语义可依赖信息的布局（例，位置的状态）及内部模型设置（例，块参数，数据类型的处理）。所以，语义被嵌入在模拟器的解释算法中［4］。3）特别，象被Simulink定义数据驱动语言生成器组成一类新的开发工具。代码生成器不能简单执行逐步翻译从模型分层体系结构到一个抽象的目标语言语法树。相反，他们必须分析数据依赖源于一个适当的计算机序列，这是代码生成器的精髓。 在目前，基于模型的代码生成器不是同已制定的C或者ADA那样成熟。代码生成器的技术风险是高的，因为他们1)是被一个相当小的开发团队使用和2）面对一个高效率的技术革新引起一个新版本的出现在一个短周期内。因此，一个正式化代码生成器正确性的证据在实际中是不可实行的。因此，通过基于建模工具代码生成器的使用取得生产效率的提高不能完全开采的。代码生成器与手工写代码一样必须用同样昂贵的精力检查，即使紧张的质量度量已经花费在模型上。 这篇论文为基于建模的代码生成器介绍了一种通用、切合实际的的测试方法。该方法大量使用代码生成器的输入和输出是可执行的事实。方法的目的有三点： 1）测试案例的系统来历必须在测试包中执行的信心，因此它可以用服务于验证代码生成器。 2）测试案例必须能自动产生覆盖高可变的模型。 3）测试包必须能执行和自动评价，处理代码生成器的快发布周期。 通过确认TargetLink代码生成器执行的优化，我们评价我们测试方法的有效性。 623 这篇论文的剩余部分的结构如下： 第二节介绍基于模型的代码生成。 第三节描述了代码生成器的优化。 第四节支撑一个系统的代码器测试理论线索的概要。 第五节通过一个例了描述了系统代码生成器测试方法。 第六节介绍了从三个案例获得测试结果 第七节讨论了结果和局限性，和通过总结他的贡献和暗示未来研究方面结束论文。 图. 1基于模型的代码生成原理. 2.基于模型的代码生成 在基于模型的开发中，一个控制算法的实现通过模型的逐步求精来开发，一个所谓的的物理模型起源于软件元件（图1.左上）的功能需求说明书，物理模型捕获控制算法和依赖于（连续）输入信号和（内部或外部）事件的控制功能的描述行为。物理模型有代表性地使用浮点算法（FLP）和被用来验证关于在需求说明书规定需求的模型的功能行为。 在机动机工程领域，嵌入式系统被定义作电子控制器(ECUs)。由于硬件资源的限制，ECU需要一个很小开销（例，有限或者没有抽象）和能有效的利用系统资源的（高级）编程语言。由于经济原因，使用在一个ECU的微处理器是更适宜8，16，或者32-位固定点处理器。因此，物理模型不得不被实现专家手工精炼；例如，功能部分被分配到不同的任务和用必需的实现细节增强。而且，用在物理模型的FLP算法是适合嵌入式目标处理机（看[5]详细）的固定(FXP)算法。为了保持FXP数误差精度尽可能低，固定点的数据类型被护展以适宜伸缩信息，2.提炼的结果是实现了的模型。它包