- March 29, 2011
- Feature
Summary
-
Automation.com, March 2011
By PLCopen North America
The use of skid mounted equipment has become popular for a number of reasons but they pose some unique automation and control challenges that can be solved by using IEC 61131-3 and PLCopen standards.
March 2011
By PLCopen North America
The use of skid mounted equipment has become popular for a number of reasons but they pose some unique automation and control challenges that can be solved by using IEC 61131-3 and PLCopen standards.
Skid mounted systems are factory built modules designed to provide a specific function needed in a plant. The name, skid, refers to the fact that the equipment is built up on a metal platform so the entire unit may be delivered to a manufacturing or process location and set in place as a unit. Building a skid in a factory rather than onsite provides a number of advantages. The specialty supplier has more and better tools and materials right at hand, and the work is performed by multi-discipline crews who work together on every project. The result is work can be performed far more efficiently with higher quality and shorter project schedules. These systems are generally built to the user’s standards and specifications. The unit is built on a platform and frame designed to be shipped and delivered to the location in a plant where it is required. Examples of skid mounted equipment including lift stations, heat exchangers, power generators, cogeneration units, filter systems, pumping systems, DI Water, assembly machines, packaging machines, chemical processing, boilers, and other process equipment. Physical, electrical, and automation network connections are made to the unit for integration with the production plant.
Control Dilemma
The controls and automation on a skid become part of the plant just as much as site installed controls and automation. Ideally the manufacturing company needs to be able to efficiently maintain, troubleshoot, and do continuous improvement on the control and automation embedded in the skid. This cost should be factored into the lifecycle cost analysis of purchasing skids to expose the real cost tradeoffs.
The skid supplier delivers the functional unit with controls and automation onboard and this is where there needs to be standardization. The dilemma is that the skid vendor has typically standardized on one brand and model of controller and the plant is using another vendor. In the case of a process plant, they are likely to have a DCS and the skid systems are delivered with PLC controls further complicating the situation. The plant people must spend the time to learn a new control and its interfaces.
The skid vendor wants to use the controls they have standardized upon. The alternative is for the customer to demand a specific brand and model control be supplied which generally results in a large increase in price from the skid vendor. The skid vendor must spend the time to learn a new control and implement the control in this platform.
Standardization without Suffocation

The first requirement is that the controllers specified are certified to the PLCopen Conformity and Reusability levels to provide uniformity of functions used to perform the control.

Skid System Function Standardization
The PLCopen standard includes the capability to build user created objects to encapsulate functions. The buyer of the skid module can insure functional requirements and uniformity are met by specifying functions to be provided by the suppliers. Simply define the inputs, outputs, and behavior of major control elements that the supplier must provide. This insures that plant people can easily troubleshoot the controller and process when problems occur.
Depending on the functions required in the skid system, the skid vendor should be required to supply controllers that are certified to other PLCopen standards.
Motion Control

This lowers development, maintenance, and support costs while eliminating confusion. In addition, engineering becomes easier, training costs decrease, and the software is reusable across platforms. Effectively, this standardization is done by defining libraries of reusable components. In this way the programming is less hardware dependent, the reusability of the application software increased, the cost involved in training and support reduced, and the application becomes scalable across different control solutions. Due to the data hiding and encapsulation, it is usable on different architectures, ranging from centralized to distributed or integrated to networked control. It is not specifically designed for one application, but will serve as a basic layer for ongoing definitions in different areas. As such it is open to existing and future technologies.
Fluid Power
The new PLCopen Fluid Power initiative is part of the motion control working group to define standard functions for the control of fluid power devices. This enables logical integration of electrical and fluid power functions.
Safety

The combination of logic, motion, and safety in one environment provides the user with a harmonized view of the total application within one environment. And with multiple implementations, this is also valid across platforms. This means less educational efforts, and simpler transfer of knowledge and application software between different controls. This standardizes safety integration reducing programming errors and avoids unnecessary cost overruns on projects. This is accomplished by using tested modules for programming, including language definition with subsets.
The PLCopen Technical Committee 5 (TC5) has published Safety Software User Guidelines, a reference for control people implementing safety control systems. The document is available at no cost on the PLCopen Web site. This is a companion publication to PLCopen Technical Committee 5 - Safety Software Technical Specification; also available on the Web site. This document illustrates the ease of use of the defined function blocks in real life applications.
The Safety Software User Guidelines document provides a wealth of information for control engineers on safety applications including: Creating a Safety Plan, Terms and Definitions, Example of Safety Functions in a Production Line, Description of the PLCopen Function Blocks, PLCopen Function Blocks and Connection to the Periphery, Graphical Overview of Safety Application Examples, Use of Safe Drives, Diagnostics Conceal I/O Interface, and Two-Hand Control. Included are examples of the combination of Logic, Motion, and Safety, making it easier and more natural for the user to integrate safety in their motion and logic application. Safety functionalities like mode selector, safely reduced speed, and several stop functionalities, have a direct link to the motion control application. The published document provides examples and guidance for the combination of the different technologies.
Certified Training

OPC UA
The OPC Foundation and PLCopen have combined their technologies to form one platform for manufacturer-independent information and communication architecture. The mix of OPC Unified Architecture (UA) and IEC 61131-3 is thus the future-safe basis for the realization of automation tasks. The objective is to increase the reusability of controller and visualization modules and their communication and, as a result, considerably increase efficiency in the engineering process.
The new OPC UA technology provides an efficient and secure infrastructure for communications - from sensor to business enterprise computing for all automation systems in manufacturing and process control. OPC UA leverages web services to provide a single programming paradigm in a scalable architecture that can be implemented in a range of devices - from embedded to enterprise.
The implementation of this IEC61131-3 software model on an OPC UA server address space is defined in the common specification adopted by both organizations. Corresponding OPC UA object types are created from declarations of function blocks in the PLC and corresponding OPC UA objects from instances of the function blocks. This results in the advantage that a control program, regardless of the controller on which it is executed, and the OPC UA server, via which the data is accessed, is always implemented in the same structure of objects in the address area. For UA clients, this results in always identical UA access at the semantic level.

OPC UA is also platform-independent by design allowing it to be implemented easily in embedded systems and enterprise systems in any operating system environment.
The OPC Information Models define unique functions such as Data Access, Alarm & Events, and Historical Access and rely on the Base Services. The new architecture is easily extensible as illustrated by new implantations based on OPC UA; including PLCopen IEC 61131-3 functions, MIMOSA, IEC 61850, S95, and others.
XML Interchange Standard

The PLCopen XML standard capitalizes on the open IEC 61131-3, Safety, Motion Control, and other standards to support interchange of applications software for different controllers. The PLCopen XML standard provides on open architecture interchange with using Product Life Cycle Management (PLM), Machine & Process Simulation, CAD, documentation software, and other systems. As a result, manufacturers can expect to reduce the cost of engineering and ramp-up time, and continually optimize their manufacturing operations with accurate, real-time, simulation models.
The PLCopen XML schemas and documentation as well as an introduction are available free to anyone on the internet at www.control-xml.com. The downloadable files include a 156 page Explanation of the PLCopen XMLSchema, 58 page document on XML Formats for IEC 61131-3, and XML Schema files.
The PLCopen standard has gained acceptance by the AutomationML Organization. The AutomationML group accepted the PLCopen XML format for the description of control. This cooperation closes the gaps between production design (virtual factory) and the shop floor resulting in reduced time to market and lower costs for manufacturers.
Require PLCopen Certified Skid Controls
PLCopen member suppliers understand the value of open software standards and have made a commitment to improving quality and productivity of the industry. By having standard software, users can select the best of breed control and automation hardware. The benefits include common specification, common commissioning, lower life cycle costs, improved productivity, improved quality, and improved availability.
PLCopen member suppliers are committed to open standards and believe that locking customers into closed proprietary technology is not good for themselves, industry, or the customer. Proprietary technologies are expensive and limiting over time. These companies recognize they must deliver value in their products rather than milking money out of customers by locking them in with proprietary technology.
What industry has ever embraced open systems, only to later change its mind, turn around, abandon the pursuit, and revert to former proprietary ways?
Learn More
Did you enjoy this great article?
Check out our free e-newsletters to read more great articles..
Subscribe