一种使用基于模型开发方式的引擎控制系统的自定义设计框架外文翻译资料

一种使用基于模型开发方式的引擎控制系统的自定义设计框架

摘要

在复杂系统的基于模型的设计中，会产生许多设计数据，如不同的形式和设计相关的文档模型，这些设计数据包括规格、测试结果和设计决策。这些设计工件的一致处理和整合是一个在工业实践中尚未解决的挑战。本文阐述了一种在基于模型的设计开发引擎控制系统中所采用的一种基于软件的设计框架（DF）在工业上的可用性[1]，这一控制系统在欧洲最近的研究项目中被开发出来[2]。设计框架的目标是，减少设计工作，因此，在在基于模型的设计过程中，通过不断整合产生的工件和工具，在提高系统质量的同时需要考虑成本，为了确保设计的不一致和错误被尽可能早检测到（例如，在纠正这些错误的代价较小时）。该框架提供结构化数据和模型管理，还有自动设计的一致性检查和设计参数的传播

关键词——基于模型的设计；设计支持；工具集成；内燃机

1. 介绍

在复杂技术系统的基于模型的设计中，产生了许多工件，这些工件可以在不同的形式下构成模型，正式或非正式的文件规格，设计和测试结果。通常，在一个层次的细节上的不同类型的模型，对于他们被用来回答不同问题的目标来说是足够的。至关重要的是，这些不同的模型是一致的，为了节省建模工作，并避免错误，将它们从一个形式过渡到另一个自动形式是有用的。非正式文件往往是有组织的单独的基于模型的设计工具，在设计流程中变化出现时，可能不会被更新。这导致了一个分散的设计流程，这可能会导致一个不一致的设计数据，并导致设计错误，往往在后期的设计过程中，甚至在调试才能检测到，在欧洲研究项目MULTIFORM中，一个设计框架（DF）的开发，克服了这些挑战。本文阐述了在一个工业设置的设计框架的适用性。为此，实际的工业案例研究中，一个发动机控制系统是由小型公司vemac [ 3 ] 在DF建模中设计开发的。结果表明，DF可提高一致性，设计步骤，并对现有的vemac工作流比较重用。

设计框架由嵌入式系统研究所[ESI]开发，埃因霍温,NL, 在范德兰德工业合作仓储系统下由一个高层次的工业工作流程和一个具有挑战性的学术案例研究产生灵感，基于模型设计的移动机器人微型无管厂，DF设计的目标可以很容易地定制任意工业设计流程[14,15]，而它的能力已经在学术和高水平的工业环境中得到认可，本文阐述了在实际的工业案例研究使用低级DF。对于vemac的压电控制软件开发的控制化油器（PCC）应用现有的工业应用来定制工作流程的详细描述。通过定制的设计框架，改进了现有的开发流程，提高了正式的使用方法，由于使用了正式的方法，在更大程度上提供一个更好的记录和更一致的总体设计过程。更进一步的优点是可视化的整体流程和可以对每个设计决策，以及使在项目团队中存储和共享信息成为可能。

Ⅱ.设计框架

Design Framework的整体设计流程（参见图1上部）可以为多个设计步骤（DS），它不仅代表了当前设计阶段，还有一些设计决策（DD）。该设计流程的概念是通用的，可以适用于任意的设计过程。基于模型的设计方法，在这里被认为是自上而下的设计方法，这种设计方法已经被建立在工业实践中。

图 1 Design Framework的概念模型

设计过程开始于完整的系统的抽象模型，这个模型主要用于用于粗略估计所需的硬件性能，并确定关键的设计问题和潜在的瓶颈，在随后的设计步骤中，使用了更精细的模型对这些问题进行了研究，并对该系统进行了详细的设计和验证。在这样一个设计流程中产生了大量的设计信息，每个设计步骤都采用一个或多个设计视图（图1中的中心部分）。在该系统中每一个设计视图都代表特定的视图，例如它的结构组成或控制系统结构层次。

使用系统模块构建视图，可以包含任意的设计信息，，如在不同抽象层次下的文档或模型。系统模块可用于模型和子分区粗结构系统中的物理，逻辑或任何其他领域。此外，每一个设计步骤提供了设计师去写下应该在这一设计步骤要解决的问题的机会。当设计步骤的目标已经实现时，相应的答案可以被回答。在与其他利益相关者沟通过程中，该机制支持设计人员构建和记录设计过程。

在实际的设计过程中，不同类型的模型往往是采用不同的模型形式构建的。DF提供了一种集成在设计过程中所需的不同工具的模型交换框架。它目前支持基于模型的工程工具如UPPAAL [ 6 ]，Matlab/Simulink，Modelica [ 7 ]，[ 8 ] gPROMS，和基于生亲[ 9 ]，以及文字处理工具。不同形式的模型之间的交流是通过自动模式的转换来实现的，这种转换是通过组合交换格式（CIF），使设计人员能够使用最好的工具来完成给定的任务。

为了存储设计信息和参数，DF采用的设计参数是在不同的模型和设计层之间可以传播的值，其中的一致性是由DF监测。一致性和可追溯性可以方便的通过实验概念来存储参数（即输入，工具，工具参数，模型和结果），这种参数是在DF任何工具下执行的（见下方图1）。这些实验可以通过DF的脚本程序来重复执行。实验的输入参数，以及结果可以直接存储和检索的系统参数，提供一个集成的模型，设计决策和文件。所有的设计流程、设计步骤、设计视图和其他工具作为用户数据被储存在所谓的DF后用的知识核心领域中。此外，在工作流程实验中所使用的所有工具必须在核心知识领域中注册。这是定制一个DF的第一步。进一步的定制步骤，例如创建专门的设计步骤或模块，甚至是为了适应现有的工作流程，可以应用图形化的用户界面定制。

DF的设计和DF的原型是嵌入式系统研究所（ESI）的荷兰人埃因霍温基于开源的Eclipse框架来完成的。 VEMAC设计流程原型的截图在图5和6中来显示

Ⅲ.VEMAC设计流程

VEMAC在亚琛，德国的一家小型公司，为汽车和其他领域的研究和发展提供服务。在这里考虑的工作流，电子控制单元（ECU）的一四冲程内燃机的压电控制化油器，这个控制化油器通常是在两轮车上发现和发展的。一个可靠和最佳配置控制器可以帮助节省燃料和减少二氧化碳排放。目标是从可用控制库的元素中构建软件控制器，这个软件控制器将在指定的免费、可批量生产的ECU的微控制器系统中运行误差。

图 2 PPC的设置方案

VEMAC开发过程包括基于V模型的设计流程的不同阶段[ 17 ]，见图3。每一个项目从分析客户的要求开始，这些要求是这是在文本格式下被记录的非正式规范，因为大多数的客户需要估算他们的项目投资，包括必要的硬件和软件模块，以及，在早期的开发过程中必要的估计。

VEMACs压电控制化油器（PCC）项目是建立在一个统一的软件平台上的，软件模块可以在新项目中重复使用。这些模块可以在一个变管理系统中组合，形成一个可部署的单元。在UPPAAL利用定时自动机模型建立一个可调度性分析可以利用信息来执行，这些信息是在需要时所使用的模块和估计的需求，以及新模块的要求。为此，调度程序的定时模型，通用任务模型，以及关于每个任务的执行时间的信息都需要作为UPPAAL模型检测过程的输入端。基于该结果，可以选择一个符合双方的实际要求和成本效益要求的合适的微控制器。

图 3 VEMAC PPC控制设计流程

VEMAC框架提供了一个变量管理系统，去处理所有可能的变量。在不同软件模块中的变量被用于覆盖功能需求。图4显示了包括变量管理的VEMAC框架。变量系统将一个已经存在的软件功能组合到一个新系统中。它是基于变量管理工具 Pure Variants的。每个函数被定义为一个模块，该模块包含它的元数据和具体的实施步骤。这个模块被储存为一个C 代码模块，并且被提供给不同的变量管理系统。XML数据库提供的元数据被传递到变量管理中，该管理系统同变量模型一起被用于产生新的变量。之后XML数据通过工具转换处理后，就可以生成结果文档。其中一个文件是UPPAAL模型以及它相应的信息，这些信息包括所产生系统中使用的任务。这个模型可以用来为完整的系统提供调度分析。另一个结果文档是系统的C代码，这些结果将会被编译和上传到单片机系统。最后，CTL公式将会在变量管理系统中根据选定的软件模块产生。这些公式通过二进制代码模型检验程序ARCADE来验证特定的系统需求。

所有的验证过程被成功的完成后,可以将二进制代码部署到ECU。在后面的步骤中，开发控制器将会在公司测试平台的真正产品中测试。

图 4 VEMAC 变量框架

Ⅳ.设计框架方法的应用

设计框架下的设计流程旨在通过一种严格的工具和信息集成去改善和支持典型的VEMAC开发过程，同时也可以保持现有的开发流程。使用设计框架的目的是在一个地方的发展过程中使不同的步骤自动化。此外，开发过程中不同模型的参数需要被分配到相应的设计决策。这些决策应该是直观的和有记录的去提供可理解的项目进展过程。此外，完整的数据管理（模型参数、文档、模型等）应该是与完整的项目一致的。因此这个过程开始于需求分析。

1. 需求分析

通常来说，一个客户对一个项目的预期结果有一些想法。因此，每一个项目都从客户的需求分析入手。有一些典型的文档使用非正式的方法，比如自然文本文档。在设计框架下，第一个设计步骤就产生了。连接到这一设计步骤的文档是需求文档，通常是一个ASCII文本文件。

B.特征选择

根据需求，系统设计者从公司的构建工具里选择一套可用的软件模型。这个过程在VEMAC 工作流程中通过Pure Variants支持。Pure Variants同时也是一个基于Eclipse的工具，因此它可以很容易的被Design Framework集成。这个模块的软件库被储存在Design Framework 的Core Domain Knowledge中，并且可以被复制到所需的 Design Step中。该模型可以直接在Eclipse 中通过使用Pure Variants视图修改。 Feature Selection step的结果是一组特定的模块，这组模块要求满足规格。

图 5 UPPAAL模型的定时验证

图 6 其他的设计步骤

C.定时验证

当模块被选择以后，接下来就是Timing Verification步骤，在这个步骤中所选功能的时序，都要对硬件的速度和必要的响应时间进行验证。在如图5所示的例子中，相应的 UPPAAL 模型的输入参数，由不同的变量管理重新集成，并且以一个链接的形式储存在新的Design Step中。 UPPAAL是通过DF脚本程序自动执行，并且结果同样以一个链接的形式储存在 Design Step中，如图6。这组数字也显示了Design Step 的结果并不令人满意。在这种情况下，Design Step被标记为一个Dead End，并且从 Feature Selection step中重新创造一个新的。在新的Timing Verification Design Step中，变量系统的软件模型被修改，并且一个新的优化系统被定义。之后，使用UPPAAL及其相应的模型用过执行保存实验配置对可调度性分析进行重新执行。

D.代码生成

当Timing Verification提供了允许的结果后，所选择的模型对ECU的一个可展开的二进制代码使用C 进行编译。代码文件以一个链接的形式被保存在相应的Design Step Code Generation中。在这一点上，设计决策是缺乏的，尽管所创建的工件对于保持剩下的工作流程是非常重要的。

E.C代码验证

在二进制代码被下载到硬件上之前，该代码需要通过模型检验器ARCADE的验证。验证代码的CTL公式是在Design Framework 中通过 Core Domain Knowledge 库调用的，该公式是根据所选择的软件模块通过变量管理产生。ARCADE之后会在Design Framework 中通过一个脚本自动执行，通过命令行和适当的查询文件以及模型文件。为了在开发进程中使用ARCADE需要在Core Domain Knowledge创建和注册一个新的脚本输入。

图 7 在DF原型中执行完整的VEMAC PCC设计流程

如果ARCADE验证了CTL 公式，结果将会储存在项目目录中，这样就完成了Design Step。如果CTL公式没有被验证，那么ARCADE 输出反例也可以被储存在项目中。在后者的情况下，通过模型检查器检测出的错误会被固定在实施阶段开发的C代码上。此后，一个新的C代码验证步骤实验将会被执行。修改编译后的二进制文件被作为输入使用。

F.试验台

在最后的设计阶段，新的系统会在真正的测试平台上测试。测试人员在硬件设备和协议测试结果执行一系列的操作测试。这些都是可以被储存在最后的 Design Step Test Bench上的纯文本文件。因此，完整的工作流程被保存为一个逻辑单元，并且所有先前的步骤都是可用的，在需要的时候可以进行重复和分析。与手工完成数据管理的原始系统相比，DF方法提供了一种更加结构化的方式去根据相应的步骤储存数据。

最终的设计流程如图7所示。每一个设计步骤都有各自的文档和模型。个性化的设计步骤和完整的设计流程可以在设计流程和新项目的不同部分中被重复使用。此外，完整设计流程的过程可以通过分析相应的设计决策被重新构造。

V.结论

在这个工作中，Design Framework 是在欧洲的设计项目MULTIFORM 中被开发的，为了定制工业 VEMAC发展过程。预定义工具（Pure Variant Management, UPPAAL, ARCADE，和通用的文本处理器）的自动执行和设计流程的内在文档，设计决策，以及该工

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[146992]，资料为PDF文档或Word文档，PDF文档可免费转换为Word