控制全球通用的软件需求

通用汽车动力总成(GMPT)的业务驱动力
以更快的速度和更低的成本向全球市场推出更高质量的新产品的竞争压力，推动了以全球通用的方式改进控制工程过程、标准和工具的需求。影响操作的子目标包括减少停机时间和质量损失。影响工程成本的子目标包括软件组件等资产的重用。为此，GMPT已指派专家团队为制造自动化控制的工程、设计、文档和编程定义未来的远景、需求和迁移计划。

有很多挑战。缩短交货期的力量在产品工程、制造工艺工程和控制工程中重叠，需要对机器/过程控制程序进行更改。生产控制方面的其他差异源于全球范围内工厂复制时间、应用特性、区域法规、公约、标准和技能基础限制的差异。快速的技术过时迫使在产品程序完全实现之前对平台组件和工具进行升级。由于相对于制造设备的生命周期较短，计算机技术必须在设备的生命周期内进行多次升级。因此，许多版本的平台组件和工具在生产中使用，增加了维护难度和更新培训成本。

为了应对这些挑战，GMPT的通俗化工作将把来自世界各地的最佳实践和经验教训汇集到一个通用的全球规范中。关键技术概念包括:(1)使用主流技术;(2)基于模块化组件的体系结构，使软件重用最大化，并使需求、技术、执行平台和表示形式的变化成本最小化;(3)统一的工程和编程工具和环境;(4)国际标准的协调。

使用主流技术
解决方案应该尽可能多地利用主流大容量应用程序中使用的计算和通信/网络硬件、平台软件、工具和软件组件。以特定于制造自动化行业的方式创建和维护等效功能是不经济的。产量太小，摊销单位成本高，所需的专业技能基础供应不足，维护成本高。

当主流计算和网络服务以可靠的、可维护的方式满足应用程序的需求时，接口应该对主流计算和网络服务(例如web工具、通信服务和操作系统服务)是通用的。在任何情况下，接口都应该映射到主流服务。因此，有必要选择一种符号或“语言”，用于主流的、经济的、得到良好支持的转换工具和技能。语言结构和范式不应该特定于制造自动化。

模块化的基于组件的体系结构
控制逻辑软件应该是模块化的、可移植的，并由可重用的库组件和语言元素组成，这些组件和语言元素具有公共的、与供应商无关的接口，并在各自的应用领域和用户之间进行标准化。用户组织，在其制造操作中，应该能够重用这些库，并管理版本和配置控制、分发和维护，以确保整个程序的一致性。

参考该图，底部附近显示的公共元素包括通用元素(相当于IEC 61499附件B和E)，它们不特定于任何表示形式或应用程序领域或行业。上面的“公共元素”块描述了独立于应用程序的系统服务(根据IEC 61499服务接口类型的概念)，它由公共元素和系统服务原语构建而成。服务包括与网络I/O的通信，包括人机接口。从这些元素中，形成了面向应用领域的基本构建块，例如，具有两个稳定状态的简单单轴运动设备或复杂的伺服控制运动轴。这些组件独立于机器周期控制流。因此，它们可以跨许多项目、机器和工作站重用。

应用程序类库组件可以来自控制器、编程工具、机床、硬件组件供应商、控制集成商或第三方软件组件供应商的供应商。控制逻辑序列，建模为状态转换网络，由这些类的实例的功能组成。特定应用程序域中控制周期的重复模式可以作为库类重用。整个机器控制逻辑程序由上述可重用的库组件组成，根据需要进行专门化或实例化。通过这种方式，最小化了特定于机器的编程。类库的重用还有助于保持一致的结构，并减少后续的培训时间。在电子硬件领域，使用标准组件和高级语言设计系统的思想已经确立。

Video-dependent数据库
所有库组件及其在状态转换网络中的组装，包括整个程序，都应该可以通过一组定义的软件接口在视图无关的数据库中获得和访问。这种结构允许灵活地集成用计算机编程语言(如C/ c++、IEC 61131表示语言)或通过流程图实现的预先存在的库组件。应该隔离与控制逻辑数据相关联的特定于视图的数据。这种分离允许视图或表示以最适合使用的形式出现。例如，在某些情况下，程序数据可以更有效地以列表、表格、电子表格的形式提供，或者通过“表单”和“对话框”来构建“与视图无关的数据库”。

工程和编程工具和环境
应该消除不必要的工程工具和编程语言的多样性。例如，需要一个统一的编程环境，以便在给定的工作单元中对所有功能进行编程。可编程功能包括操作的总体顺序，多个运动元件(伺服控制或双位置)的协调运动，工件的过程检查，工作保持和处理，工具状态监测以及这些功能之间的相互作用和联锁。集成的范围包括可编程外设功能，例如，人机交互，诊断，设置和配置。考虑一下机器运动的自动循环意外停止的情况。控制程序应通知操作员它在哪个周期停止的状态，主动运动元件，未实现的使能条件，以及该输入设备的识别，位置和状态(如果相关的话)。这种诊断信息应该呈现给操作员，而不需要任何特定应用程序的编程。应提供上下文相关的帮助和文档作为进一步的帮助。故障排除不应要求研究原来的控制逻辑程序。

典型的高生产率制造工作站集成了各种处理和支持功能，而用户组织面临着获取、维护和集成多种编程环境、语言和使用技能的负担。应该可以在同一个编程环境中指定各种相互作用的混合进程。

需要协调国际标准
不幸的是，对于“不同”类型的制造自动化有单独的编程语言标准，例如，用于数控的ISO 6983或EIA RS 274，用于尺寸测量和检查的DMIS，用于离散逻辑控制的IEC 61131，用于通信的ISO 9506。这些差异已在标准化委员会结构中制度化，例如ISO TC 184(制造自动化技术委员会)。每种语言的词汇在表达能力上都局限于其传统的狭窄焦点。在功能上存在显著的非增值重叠。对于同一个概念，两种语言在语义上存在不必要的混淆差异。此外，人机界面和通信的编程(占总工作量的最大份额)仍然是特定于供应商的。离散逻辑控制的数量在编程和维护成本中所占的比例越来越小。它的编程环境不足以有效地指定当前使用的控制功能的广度。

需要统一这些标准，以促进必要的效率改进和一体化。然而，正在进行的标准工作仍然不协调。例如，ISO 14649 (ISO 6983的目标继任者，使用ISO 10303、STEP形式的路径轨迹数据)中用于指定操作序列(包括同步、条件分支和并发性)的模型与IEC 61499中考虑的模型不协调。两者都不与ISO 10303 AP224协调，负责定义工艺计划的流程结构。IEC 61499引入了基于状态和事件的控制流的概念，这是朝着正确方向迈出的一步。在ISO TC 184和IEC 65各自的未来标准中，需要一个通用的控制流模型。不同的编程语言是另一个分歧的例子——ISO 14649中提出了“C”的子集，而IEC 61131-3中相应的语言是“ST”。它们都没有面向对象的能力，而面向对象在主流计算中是普遍使用的。IEC 61499在其功能块类型中利用了抽象数据类型的概念——这是朝着正确方向迈出的又一步。然而，没有利用泛化专门化层次结构(继承)。需要一个跨ISO TC 184和IEC 65的通用对象模型(例如，对象管理组采用的模型)。

为了控制应用程序和工具的软件生命周期成本，我们需要非常有效地将高级过程计划转换为更细粒度的过程计划，直到最终转换为控制制造机床或单元的程序。转换(映射)越简单、越直接，效果就越好。因此，流程计划或操作序列的等价物应该可以分解并尽可能直接映射到控制器api中。然而，没有协调语言体系结构和控制器体系结构规范开发的一致努力。作为整合的第一步，标准化工作应寻求不同表达形式的语义对等。

当前的标准不能保证应用软件的可移植性，也不能保证多源组件的互换性和互操作性。在开发必要的标准、一致性测试和合格的认证设施方面，需要付出更多的努力。

总结
通过自动化控制、监测和诊断，制造操作有巨大的改进机会。在主流计算机应用中出现了关键的使能技术。然而，在制造自动化中使用的编程技术和标准并没有跟上。作为解决这个问题的第一步，我们敦促主要用户按照电子硬件设计的成功模式，共同制定一套共同的未来需求。

苏希尔·伯拉，甄子丹，弗兰克·斯凯瑞，戴夫·伯杰，
通用汽车公司(General Motors Corp.)

您是否具有本内容中提到的主题的经验和专业知识?您应该考虑为我们的CFE媒体编辑团队做出贡献，并获得您和您的公司应得的认可。点击在这里开始这个过程。