以支持为中心的企业控制:模板设计策略

以支持为中心的控制系统的主要目的是产生易于技术人员理解的可编程逻辑控制器(PLC)程序。因此，需要简单的基于规则的控制，为移动物体的传送带和移动机械的机器提供通用的电路结构。输送机和机器应用与大多数离散输入和输出相互作用。大多数制造商都有一个流程设计团队，专注于开发应用程序，以尽量减少技术人员感到困惑的机会。他们认识到设计引起的混乱会延长停机时间。

另一方面，许多控制器专家和信息技术(IT)指定的系统集成商没有这个重点。焦点的差异是专家对设计的重要特征有独特看法的结果。无论如何，选择提供基于模板的应用程序的专家可能会采用以下两种编程策略之一:

• 独立编程策略关注于程序员认为完成的应用程序的重要特征。
• 相互依存的编程战略强调使许多工程师和贸易人员能够理解、接受和支持完成的应用程序。

高生产率的制造过程依赖于标准的、基于控制器的系统应用。这些应用程序必须吸引技术人员和工程师，他们需要理解、交互和支持功能程序。因此，设计师必须了解他们的支持用户。特别是，设计人员必须尽一切可能确保支持人员在与应用程序交互时不会感到困惑。

专注于支持用户的设计人员将自动提供相互依赖的应用程序。不幸的是，大多数设计人员在开发应用程序时从不期望别人会支持他们。相反，它们的重点是使设计人员易于安装、配置和复制。因此，独立的应用程序总是吸引少数能够理解、交互和支持功能程序的高智商专家。

设计人员用于开发应用程序的依赖或相互依赖的编程策略对代码培训、操作文档和可接受的复杂性级别有不同的影响。当设计人员使用独立编程策略生成应用程序时，人们就会认识到只有志同道合的设计人员才需要了解代码的细节。这意味着设计人员不会对机器或流程支持人员进行关于代码如何工作的培训。因此，大多数培训文档将集中于如何安装、配置和复制代码。

当设计人员使用相互依赖的编程策略生成应用程序时，期望控制系统人员将为代码提供操作支持。这意味着相关的培训文档将描述代码的功能和工作方式。当设计人员确定上层系统缺陷时，可接受的复杂程度会发生变化。独立设计师通常愿意通过将功能和相关的复杂性转移到他们的程序中来纠正缺陷。相互依赖的设计人员更有可能为纠正缺陷而争论，因为他们认识到相关的复杂性将使应用程序难以支持。

当独立的设计师进行代码调整以纠正系统缺陷时，最终的设计就会成为公认的规范。这使得修复未来系统设计的工作变得复杂。当相互依赖的设计人员抵制增加复杂性时，更多的设计人员将开始关注问题，理解支持含义，并请求系统级更改以纠正缺陷。

独立应用程序的设计者经常开发软件模块和模板作为许多类似应用程序的构建块。使用构建块，他们能够创建许多高度可配置的应用程序。为了配置每个应用程序，他们创建了特殊的电路，并将它们带到应用程序的最前沿，让每个人都能看到。一些配置电路决定应用程序的行为。在相互依赖的环境中，组态电路在程序中占据不太突出的位置。

在大多数情况下，应用程序变量是在应用程序利用信息时硬编码的。其次，相互依赖应用程序的设计者定制每个应用程序以获得所需的站点行为。自定义应用程序消除了对行为控制配置电路的需要。没有这些配置电路消除了支持人员可能感到困惑的可能性。这些电路的缺失也使得困惑的支持人员不可能修改它们来改变应用程序的行为。

许多设计人员声称，只要代码按照规定执行，“代码就是代码”。如果用于生成代码的设计规范只定义了应用程序必须做什么，那么开发过程将留给每个程序员如何编写代码的机会。在这一点上，程序员的职业和教育编程经验将决定应用程序是采用独立还是相互依赖的编程策略。

控制专家了解过程、设备及其固有的支持需求，因此他们的编程风格强调满足这些需求。相比之下，控制器专家在PLC的操作及其功能方面具有高度的专业知识。因此，控制器专家的编程风格将利用设备的细微差别，以最大限度地减少开发应用程序所需的工作量。控制器专家在隔离的实验室环境中测试他们的应用程序，使他们专注于使完成的应用程序易于安装、配置和复制。制造商总是要求控制器专家只根据应用程序必须做的事情来开发代码。控制专家已经知道他们的机器和流程是做什么的，所以设计规范决定了代码风格。

大多数机器和输送机供应商生产的控制应用程序都遵循客户编写的详细规格。由经验丰富的设计人员编写的规范将试图控制代码必须做什么，但它也将控制代码的风格。为了帮助控制应用程序的风格，规范描述了设计的“该做和不该做”。规范的这一部分决定了应用程序的独立或相互依赖的特性。

设计人员制作独立的应用程序有几个潜在的原因。最大的因素是职业经验和设计师的热情。热心的控制器专家倾向于开发独立的应用程序，认为他们是创新的。这意味着他们很少或根本不关注用于管理控制应用程序开发的编程标准和规范。还有一些控制器专家，他们没有动力去理解设计规范，只是决定按照自己的方式去做。

由此产生的独立应用程序要么是由于幼稚而产生的意外，要么是由于懒惰而导致的错误。其次，安全设计人员的工作水平有时会驱使他们开发独立的应用程序。缺乏安全感的设计师往往想要炫耀或故意把自己放在一个突出的辅助角色。对于这两种情况，所产生的独立应用程序不是偶然的，而是故意向其他人证明它们是不可或缺的。可悲的是，迷恋经验不足的用户看到了这些程序的短期魅力，却没有认识到这些设计对可支持性和生产力有长期的负面影响。

对于系统设计人员来说，了解大多数制造商总是期望控制专家遵循控制应用程序风格的规范是很重要的。他们还必须知道控制应用程序的风格必须与目标支持用户的技能相匹配。大多数控制专家都明白技术人员是听众。他们还认识到，当出现问题时，技术人员必须与他们的应用程序交互以关闭制造过程。这意味着要认识到技术人员必须能够有效地与应用程序交互，以便使机器或过程恢复正常运行。

确保应用程序不会混淆电工，使他们能够快速交互以恢复操作是至关重要的。控制专家认识到，通过消除应用程序引起的混乱，他们可以最大限度地减少机器或过程停机时间。设计师应该编写相互依赖的代码有六个原因:1)消除引起的混淆;2)提高支持效率;3)尽量减少停机时间;4)最大化正常运行时间;5)提高生产产量;6)增加公司利润。通常，控制专家意识到保住他们的工作是生产高度可支持的应用程序的第七个重要原因。

许多为制造商工作的管理人员不知道“该做什么和不该做什么”，也不知道如何控制控制器应用程序的风格。因此，它们将无法控制具有独立或相互依赖性质的PLC程序。如果系统战略家想要避免这种困境，他们必须了解应用程序的设计特征以及开发它们的设计者背后的动机。请记住，设计出志同道合的设计师都能理解的代码是很容易的，而编写出每个人都能理解的代码是很困难的。接下来的小节试图描述和比较使用独立和相互依赖编程策略开发的应用程序之间的差异。

独立的应用程序

设计人员使用未经批准的、非常规的和复杂的编程技术开发独立的应用程序。制造商通过规范禁止控制系统设计人员使用这些技术，因为它们使他们阅读、理解、部署和支持完成的应用程序的能力过于复杂。无论如何，复杂的编程技术通常涉及设计人员使用循环逻辑、高级指令、间接指针、别名信号和变量、局部信号和变量、分层显示对象和多路复用例程。

控制器应用程序规范通常禁止使用复杂的编程技术而不解释原因。循环逻辑是一种编程技术，它在控制应用程序通常循环执行非控制任务时中断该应用程序的执行。不熟悉循环逻辑的支持人员可能会意外地更改它并将其置于无限循环中。将任何控制器应用程序置于无限循环中都可能对机器或进程产生灾难性的影响。高级指令有时是设计人员定制的指令。大多数支持人员不了解或不熟悉其具体操作。

当支持人员遇到高级指令时，他们会对其目的或操作感到困惑。当支持人员不认识到一个变量的值会间接影响另一个变量时，间接指针应用程序就会造成混乱。与循环逻辑一样，指针变量值的不正确更改可能会损害正常操作。别名信号和变量会引起混淆，因为大多数支持人员更喜欢以一种通用的方式引用每个信号。

消除混叠信号和变量消除了它们混淆支持人员的可能性。类似地，具有相同名称的局部和全局信号和变量增加了在两个不同逻辑例程中发现它们具有相同名称的概率。分层显示对象使支持人员感到困惑，因为大多数人更喜欢用一个应用程序变量来控制显示屏幕上的特定区域。当支持人员不能认识到一个例程正在共享输入信息以生成分时片输出信息时，多路复用例程会导致混乱。

开发独立应用程序的设计师似乎总是能够证明他们的设计是合理的。大多数设计师都直截了当地说，没有人需要知道他们的应用程序是如何工作的。他们说他们的应用程序就像黑盒子或设备。他们认为只有志趣相投的设计师才需要了解代码的工作原理以及如何修改代码。不知何故，他们让自己和其他人相信他们正在开发某种战略。支持者指出:1)高效的代码执行，2)易于部署，以及3)模块化复制是开发独立应用程序的战术原因。

实际上，与使用相互依赖编程策略开发的应用程序相比，这些说法都没有什么价值。大多数独立应用程序的支持者都喜欢在自顶向下、“统一的IT”、跨功能的设计环境中工作。与自顶向下的设计师一样，独立设计师总是相信他们开发应用的理由是正确的。

通常，独立的应用程序为操作人员提供不需要的功能和信息。这些额外的功能和信息来自于“既然我能提供，我就会提供，然后我就会”的理念。通常，设计人员授权自己提供他们认为可以帮助操作人员的非必需功能。许多人认为，额外的功能和信息将使操作人员更加了解不相关的过程。制造商必须认识到，他们提供的不需要的功能和信息可能会引起混淆，当他们导致人们对错误的“为什么会这样”信息采取行动时。

只有少数系统设计人员了解和重视独立应用程序，而经验丰富的控制专家则拒绝它们。那些拒绝它们的人没有花必要的时间去理解它们。理解它们的人觉得应用程序是“优雅的”，而不理解它们的人则认为它们是“花哨的”!

设计人员将独立的应用程序移植到其他机器控制器类型总是很困难的。这种困难源于应用程序使用复杂的编程实践，这些实践对于一个控制器来说是独一无二的，因此不能被其他控制器所采用。例如，当设计人员将控制器应用程序与特定控制器的人机界面设备的独特功能紧密集成时，就会发生这种情况。不难理解，当设计将应用程序的一部分分配到特定控制器的接口设备时，移植控制器应用程序的机会就会减少。

相互依赖的应用程序

设计人员使用认可的、传统的、易于理解的编程技术开发相互依赖的应用程序。控件应用程序的设计者使用这些技术，因为它们在提高应用程序的可读性和可支持性的同时，防止了应用程序的过度复杂化。只有当高级指令提高了其他人理解已完成的应用程序的能力时，才可以接受使用高级指令。无论如何，简单的编程技术通常涉及设计人员创建易于被控制系统人员识别、理解和支持的逻辑。大多数相互依赖应用程序的支持者都喜欢在自底向上、由领导者指导、跨功能的设计环境中工作。

控制应用程序规范鼓励使用简单的编程技术而不解释原因。大多数规范描述了普通逻辑电路必须是什么样子。设计规范还描述了各种控制电路和它们必须包括的工作模式。在启用事件之前对事件作出反应的相互依赖的系统应用程序的行为与启用离散设备的控制应用程序不同。然而，设计师总是构建他们的逻辑来模仿特定的例子。这意味着它们将逻辑分类为基于状态或事件的代码。

基于状态的代码必须不断执行，才能最终触发基于事件的代码。基于状态的控制应用程序启用一个离散信号，该信号依次为输出设备供电。基于状态的系统应用程序激活一个离散信号，使其能够跳转到子程序。子程序类似于用于激励分立器件的外部电路。子例程不是激活设备，而是启动事件。除了驻留在子例程中的基于事件的代码之外，模拟的基于状态的控制应用程序使许多控制系统人员可以理解相互依赖的应用程序。这种基本的理解使他们对自己成功地交互、更改和支持系统应用程序的能力充满信心。

开发相互依赖应用程序的设计人员似乎总是与不开发相互依赖应用程序的设计人员发生冲突。大多数设计人员都直截了当地描述了简单、直接的设计如何使支持人员更容易理解应用程序的工作原理。他们说他们的应用程序就像黑盒子。然而，与独立的应用程序不同，它们假设大多数技术人员和工程师将了解每个黑盒中的代码如何工作以及如何更改它。他们从不欺骗自己或欺骗他人，让他们相信自己正在开发某种战略。支持者指出:1)易于理解，2)高效执行，3)易于部署，4)模块化复制，这些是开发相互依赖应用程序的关键原因。实际上，与使用独立编程策略开发的应用程序相比，他们的应用程序易于理解是唯一的优点。

相互依赖的应用程序从不向操作人员提供不需要的功能或信息。设计师忽略了这些功能，因为他们有一种“如果你不需要它，我就不应该提供它”的设计理念。设计师声称不需要的功能和信息只会使操作人员感到困惑。许多人明确表示，额外的信息不会增强本地进程。制造商必须认识到，不提供不必要的功能和信息可以最大限度地减少混淆，否则会导致某些人对错误的功能信息采取行动。

许多控制系统设计人员对相互依赖的应用程序感到满意，而许多控制器专家则是这样。那些拒绝他们的人没有花时间去认识他们为什么被接受。理解它们的人认为这些应用程序是“可支持的”，而不理解它们的人则认为它们笨重且难以复制。

丹尼尔·卡迪纳尔作为Insyte公司的工程顾问，在汽车行业实施集成调度和零件识别应用。克里斯·瓦夫拉编辑，制作编辑，控制工程，cvavra@cfemedia.com．

更多的建议

关键概念

Support-focused控制系统的设计目的是产生易于技术人员理解的可编程逻辑控制器(PLC)程序。

独立编程关注程序员认为已完成的应用程序的重要特征。

相互依赖的应用程序强调使许多工程师和贸易人员能够理解、接受和支持完成的应用程序。

考虑一下这个

什么原则以支持为重点的控制系统是否可以应用于其他领域?

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