基于模型的自动化软件设计及其实现的设计模式外文翻译资料

 2022-01-29 19:03:43

英语原文共 12 页，剩余内容已隐藏，支付完成后下载完整资料

基于模型的自动化软件设计及其实现的设计模式

作者：Marcello Bonfe

摘要

本文介绍了面向对象的建模技术在复杂制造系统控制软件开发中的应用，特别对从包装行业中获取的案例进行研究和从这些案例研究分析中抽象出来的设计模式。 推荐的控制软件建模和实施方法是基于控制工程师的现场经验和参与开发项目的基础上改进的较为实用的方法。

1. 简介

面向对象概念（O-O）在工业控制软件建模及实现中的适应和应用是工业界和学术界的热门话题。 关于逻辑控制建模（即可编程控制器软件，PLC）与面向对象语言，在过去的15年里PLC编程工具的面向对象扩展或从面向对象模型到现有PLC语言的自动代码生成之间的科学和技术出版物的数量（至少有一个方面）一直在稳步增长。 从更广泛的角度来看，生产系统设计的机电一体化方法（Tomizuka，2002）为基于组件和面向对象的设计方法的应用有一定的推动作用，增加信息技术，控制和物理系统的协同整合，促进工件的模块化思想和产品复用。

面向对象被认为是管理软件复杂性的关键因素，这在制造业中也是一个日益严重的问题。 事实上，对象和类的封装特性可防止软件部件和数据的错误使用或操作，而实现软件复用和扩展设计（Bonfe，Fantuzzi，＆Secchi，2006）。 正如一些作者所指出的那样，面向对象设计也从机电一体化的角度提高了重复使用的可能性（Luder，uml;Hundt，Foehr，Wagner，＆Zaddach，2010; Thramboulidis，2008），这一前提是机电系统的发展是由规范工具建模和设计支持，允许捕获应用程序域的概念特性。

在软件和系统的面向对象建模的环境下，UML（统一建模语言）和UML方言（对象管理语言，2009,2010）是目前的主要标准。 许多作者提出在工业应用中使用UML或至少使用UML状态图（包含在UML中用于基于状态的行为规范）。这些提议大多数将在第2节中进一步讨论，通过其天然的扩展机制的装置（即定型和型材）定义UML的特定于域，然后或者正规化语言的验证其目的的语义 （即模型检查，Bonfe和Fantuzzi，2003）或开发用于工业目标的自动模型到代码生成器（Vogel-Heuser，Witsch，＆Katzke，2005）（即支持IEC 61131-3编程语言，国际电工委员会，2003）。

然而，解决实际应用的控制工程师不仅需要建模语言和设计方法，还需要参考示例和设计模式来解决制造系统控制设计中的常见问题（例如警报处理，协调运动，生产重新配置和配方管理）。此外，PLC和运动控制软件的最终实施时，如果基于模型的代码发生器不可用，应当由很容易地应用甚至可以通过手动编码实现的规则和模式支持。

本文的主旨是描述工业控制软件开发的设计模式，这些模式是在与开发自动化机器和包装解决方案的公司多年合作中收集的。面向对象的范例通过UML建模应用，而实现阶段是指IEC 61131-3兼容目标。但是，本文不涉及UML模型来PLC代码的全自动转换，但提供有用的实用规则（即使是必需的手动转换），重点是通过UML状态图指定的分级状态机的实现。

本文的其余部分安排如下：第2节提供了相关文献的概述，而第3节回顾了作者先前提出的基于模型的工业控制软件设计方法。 然后，第4节介绍了相关的案例研究，第5节显示了工业控制软件设计中常见问题的解决方案，而第6节则包含了IEC 61131-3代码实现的不同解决方案的比较分析。最后本文提出了一些结论性意见和未来工作建议。

2. 相关工作

工业控制软件领域几乎由曾经的IEC 61131-3标准中定义的编程模型和其最近的对应IEC 61499（国际电工委员会，2005）主导分布式系统。 IEC 61131-3和IEC 61499都通过功能块（FB）概念支持模块化和可重用性，类似于现代编程语言的对象概念。 更准确地说，可以定义两个IEC标准基于对象：FB被定义为类型并用作实例，它们封装私有算法和数据，并通过定义良好的接口与输入和输出信号组成的其他软件模块进行通信。 但是，IEC 61131-3和IEC 61499目前的形式都不是面向对象的，因为它们不支持继承。

这种空白并没有阻止许多作者应用面向对象设计技术和UML等建模语言，引入了对抽象设计概念和解决方法的适当的特定领域解释来解决实现框架的局限性。已经提出了集成IEC功能块的UML扩展在Storr，Lewek和Lutz（1997），Heverhagen，Tracht和Hirschfeld（2003），Thramboulidis（2004），Katzke和Vogel-Heuser（2005），Dubinin，Vyatkin，and，Pfeiffer（2005），Younis和Frey（2006），以及Ritala和Kuikka（2007）。通常，对象的解释是制造系统环境中最显着的特定于领域的方面。如果设计为机械部件，传感器，致动器和控制软件程序的紧密集合，制造机器模块是可重复使用的，特别是与在不同项目中重复出现的制造过程的给定部分相关。这种聚合可以被认为是机电一体化物体，如Bonfe和Fantuzzi（2003）中所介绍的那样。在Thramboulidis（2008）中已经提出了非常类似的概念元素，其中MTC（机电组件）通过UML扩展来描述。用于MTC的接口（称为MTConnectors）可以定义材料，能量或信息交换通道，而Bonfe和Fantuzzi（2003）中定义的机电对象接口实际上更加面向软件。 UML扩展的其他提议，包括模型中的物理部分，可以在Burmester，Giese和Tichi（2005）以及Secchi，Bonfe和Fantuzzi（2007）中找到。使用统一的语言进行控制和工厂建模，即使后者抽象于纯逻辑层次上，也是闭环形式验证的可行方法，如Lobov，Lastra和Tuokko（2005）以及Klotz，Fordran所讨论的，Straube和Haufe（2009年）。引用作品中阐述的许多概念都嵌入在SysML（对象管理组，2010）中，这是一种将UML与系统工程方法相协调的语言，其在机电领域的应用在Thramboulidis（2010）和Bassi，Secchi，Bonfe和Fantuzzi（2011）。但是，对象管理组不如统一建模语言成熟，而且现成的工具支持较少，因此具有特定于域的扩展的UML仍然是工业软件设计的最佳选择。

另一种反复出现的可以在文献中找到方法涉及复杂制造系统的架构规范。大多数论文侧重面向对象或基于模型的设计的实际应用（Cengic，Ljungkrantz，＆Akesson，2006; Ferrarini＆Veber，2005; Hametner，Zoitl，＆Semo，2010; Vyatkin，Karras，＆Pfeiffer，2005）使用自上而下的方法和与Douglass（2006）和Gomaa（2011）中描述的所谓的分层控制兼容的架构模式来解决复杂性问题。根据该模式，控制系统的每个组件通过概念上执行状态机来在系统的给定部分上操作。此外，高级组件通过协调其从属组件来提供整个系统（或子系统，如果定义了多个层级）控制。这种设计模式的严格解释可能通过避免部件之间的直接相互作用在一个整体，委托给各等级级别的协调器或主管行为规格为整体的执行增加低层组件的可重用性。事实上，正如Pazzi（2000）所讨论的那样，提出了一种称为部分整体状态图的建模框架，用于显式组合状态机，通过禁止不同部分之间的通信和相互知识来实现​​自包含和封装，从而允许它们重用在不同的背景下。如IEC 61499所支持的那样，分层控制模式甚至应用于分布式系统，这表明它是复杂制造系统最合理的设计方法。第5节将介绍这种模式在实际案例研究中的应用（见第4节）。

总结这篇文献综述，有趣的是，许多作者已经解决了IEC 61131-3与IEC 61499之间的比较或某种意义上的争议（Zoitl，Strasser，Sunder，uml;＆Baier，2009）。 。一方面，如Thramboulidis（2009）和Zoitl和Vyatkin（2009）所述，IEC 61499尚未显着改变工业实践，因为它得到了太少的成熟参考实现和集成开发环境（IDE）的支持。另一方面，学术研究在IEC 61499开发方面一直非常活跃，正如Thramboulidis（2009）和IEC 61131-3提到的IDE原型或运行时环境的数量所证明的，相反，它具有以下事实：该标准基于非最先进的软件工程概念（Zoitl＆Vyatkin，2009）。此外，尽管PLCOpen组织的努力及其在促进IEC 61131-3代码（PLCOpen技术委员会6,2009）和运动控制应用程序（PLCOpen技术委员会2，2010）的可移植性的其他标准方面的工作，工业控制软件的直接从PLC或运动控制供应商迁移到另一个供应商今天根本不可能。尽管这一事实并不依赖于IEC 61131-3本身，并且在不久的将来不太可能发生变化，但在第三版中对标准的修订存在一种很有希望的趋势，其中预期会有实质性的改进。特别是，IEC 61131-3的面向对象扩展已经在过去几年中进行了讨论（Gonzalez，Diaz，Fernandez，Junquera，＆Bayon，2010; Schunemann，uml;2007; Werner，2009），甚至还有一种工具已经上市支持这些功能（3S智能软件解决方案，2010），这肯定会促进UML在工业应用中的使用（Witsch＆Vogel-Heuser，2009）。

3. 基于模型设计的工业控制软件

Bonfe和Fantuzzi（2003）中介绍的机电一体化对象的概念指导控制软件设计朝向制造系统的适当模块化思维。 将重点放在软件方面突出了面向对象工业控制模块，如嵌入式系统设计领域的普遍提议（Douglass，1999; Selic，Gullekson，＆Ward，1994），应该具有：

（1）同步和配置输入/输出信号和数据的接口;

（2）感知信息和执行器命令的接口，连接到物理组件;

（3）私人数据（即内部状态）;

（4）控制算法。

上述特征由IEC 61131-3和IEC 61499 FB实现。 即使这两个文档提出了不同的执行语义。

由类图和状态图组成的UML的子集将允许完全指定工业控制系统的结构和行为。特别是，类图显示了类之间的结构关系，图形链接称为（简单）关联，聚合/组合（部分 - 整体关系）和泛化（类派生自另一个），涉及继承。可以与类关联的一个重要属性是其构造型，它定义了它在特定于域的模型中的概念角色。在工业控制应用中，应从机电一体化的角度指定结构方面。允许描述机电对象分类器的UML构造型可以被标记为机电整合，对于具有公共可见属性的接口的类，其被定型为输入或输出，如IEC FB所要求的。机电整合类不应该具有公共操作，而私有操作可以用于模拟复杂的数据处理活动。

机电类的一部分与连接有关在类的帮助下指定物理组件定型为硬件。从机电一体化的角度来看，与给定机器模块关联的物理元素是实际上是机电类的一部分。因此，硬件类应该通过与机电类的组合链接相关联。专注于控制软件设计，物理部件减少到传感器/执行器I / O信号，其中意味着硬件类及其输入和输出属性表示硬件I / O端口为机电类的私人部分。请注意，硬件类的输入是控制器的输出，反之亦然。分开的定义软件部分和硬件部分的类构造型机电一体化物体离开了实施阶段物理I / O的封装机制的定义控制模块，根据执行的特征平台（例如VAR_CONFIG变量，具有特定于实例的位置分配，在IEC 61131-3或服务接口功能块中在IEC 61499中）。

定义系统的行为规范，用UML状态图描述每个类的内部行为。这种模型来自Harel（1987）状态表s，为嵌入式系统设计人员所熟知其吸引人的特征：状态层次，并发和层间转换（即跨越状态边界的转换）层次。即使没有正式描述，UML State Diagram语义与最初提出的语义有很大的不同Harel和Naamad（1996）和Chan等人（1998），所谓的陈述语义。特别是，UML语义要求要排队的事件，以便一次处理一个触发转换并相应地更新状态配置，而陈述语义允许同时进行事件处理。由于在两种语言中都有多个冲突的过渡可以在同一个执行步骤中启用，必须具有确定性由基于状态等级的优先权计划确保。在UML，更优先考虑来自状态的转换层次结构的较低层次，而在陈述语义中，优先级方案是相反的。背后的理由不同的优先方案没有详细记录（Crane＆Dingel，2007），但UML看起来更受O-O的启发方法：子类覆盖超级元素就像子类操作覆盖它们的超类那样。另一方面，通过基于状态的逻辑（即中断）进行异常处理离开他们的超级基质的基质的行为更多直观采用陈述语义，实际上非常类似于Stateflow（Mathworks Inc.，2010b），嵌入式系统工程师熟知的工具。一些作者建议，如果使用UML，则应该处理异常作为特定事件队列管理的更高优先级事件算法（Pinta#39;nd Majziker，2005）。但是，同时事件处理，而不是事件排队，本质上与经典的基于扫描的执行模型兼容PLC程序。出于这些原因，类似于陈述的语义，优先考虑退出超市的转型要求用户定义的优先级用于退出相同的转换建议的UML扩展中采用了一种状态（参见Bonfe，Fantuzzi，＆Secchi，2005年正式详情）。类似的方法，包括用户定义的转换优先级，由其他人采用作者（Klotz等，2009; Witsch等，2010）等。后一个参考文献甚至旨在使一种全新的语言形式化称为PLC-S状态图。但是，PLC-状态图独立地为模型中的任何转换强制执行用户定义的优先级来自层次结构，这可能会给设计过程带来负担没有利用状态图的图形表达能力。从句法的角度来看，很少有相关的修改文本表达（即转换标签和状态动作）是建议。特别是，他们的规范与IEC 61131-3兼容的语法可以简化工业代码生成控制器。因此，我们需要使用字符串标记转换格式如下：<!--

全文共10331字，剩余内容已隐藏，支付完成后下载完整资料

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

原文和译文剩余内容已隐藏，您需要先支付 30元 才能查看原文和译文全部内容！立即支付

以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。

您可能感兴趣的文章