Standardization has long been considered an industrial automation best practice when programming programmable logic controllers (PLCs, PACs). Implementing and documenting PLC standards is crucial to achieving the most outstanding value from this investment. Nevertheless, why does standardization bring value, and what are the benefits?
What are the Benefits of PLC Standards?
First, why should we implement PLC standards at all? Why not simply rely on the programmer to be consistent in their work? Clearly, programming styles between individuals are likely to differ, but even a single programmer typically changes styles across programs or even within a single program. Standards allow for universal consistency and for changes, upgrades, or even replacements to be made more smoothly and efficiently. Formally documenting PLC programming standards allows expectations to be clearly communicated to programmers.
Though standards are incredibly valuable, implementing them takes considerable initial effort. However, the initial work literally pays off; standardization saves money in the long run. The work and discussions at the beginning of the standardization process reveal complex details of how the system will be used. These discussions also determine how changes can be made to benefit the client. While the effort initially may seem tedious, it will ultimately save your organization time and money when implementing future projects. Because standardization leaves a documented trail, changes can be made quickly and with minimal effort.
Increased Speed of Processes
Any effort to upgrade sites with missing documentation must start with extensive reverse engineering and control strategy review. Established standards avoid this issue. Time can be saved during the programming and design stages by pre-determining how particular functions will work. Our team will sit down with the operations and management teams to thoroughly discuss how each process should work. During this discussion, the team will be able to find similar components that can be duplicated rather than individually programmed (such as buttons, functions, alarms, etc.). This reduces the cost of the programming and development time.
Reduced Risk
Programming with well-defined standards means the code is less prone to error, and there is no need to retest validated standards—this provides additional time savings. Not only does having well-defined standards reduce development time, but it also means that deadlines are more likely to be met because reusable code minimizes unknowns and allows for more accurate schedule forecasting.
Consistency
When processes function predictably and consistently, they are easier to manage. Without proper standardization, they can become a hindrance; navigating an undocumented process leads to longer development time and even potential downtime. With a lack of standardization comes a lack of dependability, and PLCs must be dependable so that everything runs properly, preventing downtime for maintenance.
Ease of Maintenance
When PLCs are standardized, troubleshooting is faster because the code is easier to read and interpret. Instead of spending hours figuring out what is causing the code to glitch by pouring over the ad hoc undocumented changes implemented years ago, it is much easier to refer to standards to solve the problem. Not having standards means there are no easy solutions. Determining the problem and applying the proper fix when a system is well-documented is much simpler.
What Should PLC Standards Include?
PLC Standards are far more than just code blocks. Each of the following components should be thought through and defined:
- Automation devices
- PLC programming environment
- PLC code specification
- Programming workflow
- Change management
Automation Devices
Before deciding how your PLC and the rest of your control system will be programmed, decide what equipment you will use.
Select a single automation manufacturer for your automation platform. This facilitates ease of duplication and maintenance.
PLC Specification: Within the selected automation platform, choose the PLC models and configurations to base your standards.
Field equipment: This can be as basic as choosing an MCC specification but can include selecting drives, valve actuators, field instruments, and more.
Even if you do not specify an exact model of field equipment, you must specify the I/O profile for each device (i.e., VFD I/O).
Choose the communication structure that forms the communications bus for your automation platform. Consider I/O, PLCs, smart devices, and SCADA.
PLC Environment
Decide upon software settings. These are the configuration settings specific to the programming environment (i.e., Ecostruxure Control Expert or Studio 5000) and project-specific settings.
Choose a preferred programming language as the default. Minimize the number of languages and decide which should not be used. By having fewer languages and choosing ones that fit your system best, there will be more flexibility in future programming of additional PLCs.
An approved (or excluded) function list helps optimize the PLC environment. Though it is unlikely to be complete, including the preferred Elementary Functions (EFs) or Elementary Function Blocks (EFBs) that are part of most logic is essential. Furthermore, you should note functions that are obsolete or that you wish to avoid.
Layout and logic play a large part in the consistency and readability of a PLC setup. This can include size, object placement, alignment, spacing, comments, connections, and more.
PLC Code Specification
Naming standards are essential. Names are critical not only to PLC Standards but also to the automation system. They allow for traceability and easy identification.
Data interfaces define the standard’s inputs and outputs. These include physical I/O, interfaces to other logic, setpoints, and diagnostic values.
Functions will include a functional specification for how each device defined by the standards is supposed to operate.
Alarming is critical to operations. Therefore, it is often called out separately from the functional specification. These elements must be clearly defined.
Programming Workflow
English-to-code translation is when standard English text describing the system functionality is turned into PLC code. When standards are correctly implemented, this process is smooth. This process becomes much more difficult without standards, and the translation rarely goes well.
Testing – Desk Checking
During and after the code translation has been completed, the code should be regularly desk-checked against the PLC Standards. Desk checks ensure that the code is accurate and ready for use.
Testing – Full Validation
When the code has been completed, the next testing phase fully validates the standard. This should capture every aspect defined by the standard and every aspect of the PLC that has been documented.
Testing – Physical Devices
For some PLC Standards, it is a good idea to include testing against physical, real-world devices to minimize future risk. This type of testing reduces the risk of failed deployments.
Revision Numbering
Finally, PLC Standard programming should be numbered clearly and logged via a revision number. That is the key to change management. It is also a good practice to update this regularly during the programming phase.
Change Management
Having and enforcing standards for change management is critical to keeping your high-performance system performing at its best. Quick-fix, undocumented changes are the biggest culprits in creating unrecognizable code.
A robust change management plan is guided by the questions of who, what, when, why, and how.
- Who can make changes? Who must be notified when changes are necessary?
- What is the mechanism for implementing changes?
- Why is it important that everyone follows the plan?
- When can changes be made?
- Where are the changes stored and tracked?
- How do you manage change control?
Discussing and establishing standards through hardware selection or change management is critical to ensuring a well-maintained system running smoothly for years.
When and How NOT to Use PLC Standards
While having clear standards for the above five components is of the utmost importance, more of any good thing can be beneficial. One of the most challenging aspects of utilizing PLC Standards is determining how far to take them. Standards can often be too complex, and their design may need to be more flexible to accomplish the client’s goals or deliver standardization benefits. Following is a list of ways that PLC Standards can negatively affect automated programs.
Overcomplication
Too much flexibility can turn the creation process into a nightmare. Even worse, too much flexibility works against the reasons for having standards. Overcomplication increases the time spent configuring each instance, increases the risk that an instance needs to be configured correctly, and makes maintenance more difficult. Keeping standards simple is the most efficient.
Other’s Standards
Be cautious of pre-developed standards or standards provided by those who have yet to involve you in the creation process. Creating your own PLC Standards allows you to configure the details for your specific needs. While using set standards developed by an outside entity may save time, you lose the benefits of tailoring the standards to your system. Furthermore, other sets of standards may contain configurations that could be more efficient for your process, which may ultimately create a need for unnecessary maintenance.
One-off Designs
Only create a standard if there are enough instances to be effective. Developing such a standard ultimately creates more work that provides minimal benefit and will merely clutter your standards library. If the standard is not likely to be used again or only once, it should likely not be a standard.
Tips for Success
The Project Must Have a Champion
Though creating PLC Standards may seem tedious, it is an important task. A project champion on the end-user team must be present to keep everyone focused on completing the standards properly and emphasize their benefits to ensure everyone is committed to the process.
Understand the Full Scope
The initial discussions surrounding standards are designed to understand the project’s scope and the system’s intentions as early as possible. Early decisions ensure the completeness of standards. Postponed decisions and a partial scope can mean incomplete (and possibly useless) standards.
Document All Decisions
The discussions about scope and function can be long, and it can be easy to forget what was decided and why. To avoid making decisions multiple times or forgetting what decisions were already made, immediately document all decisions with their reasoning.
Change Management
Maintaining a straightforward, enforceable change management process is the most important part of keeping the standards useful. Part of the standards’ intentions is to facilitate new changes with ease.
It Takes Time
PLC Standard creation and adoption are rarely perfected instantly. Patience throughout the process will be rewarded with benefits that last for years.
Building Blocks of FB Programming
The following are traits of the functions used to create PLC programs.
Elementary Function (EF)
The basic functions within IEC programming software, like (ECE), do not possess internal status. If the input values are the same, the output value will be the same, and elementary functions cannot be named.
Elementary Function Block (EFB)
EFBs are less basic than EF functions. Like elementary functions, they cannot be named but have an internal status. EFBs offer greater flexibility. If the input values are the same, the output values can have another value during an individual execution.
Derived Function Block (DFB)
DFBs perform user-defined functions and are developed and customized to meet specific needs. Though they have the same properties as elementary function blocks, they are built upon EFs, EFBs, or possibly other DFBs or DDTs. Additionally, DFBs can be named.
Derived Data Type (DDT)
A structure comprising of a group of individual elements or variables is called a DDT. Generally, DDTs are used with, for, or incorporated within DFBs. They have user-defined definitions; some are included within IEC programming software, like ECE.
PLC Tips, Tricks, and Advice
Organize DFB Pins
Grouping input and output pins in subsections facilitates ease of programming and readability. The subsections can include field I/O, HMI variables, data items used by other standards, diagnostic outputs, and other private and public variables. This ultimately drives consistency between standards.
Use Optional DDT Structures
An optional DDT allows a DFB to use default values instead of the DDT. When this method is used, the optional DDT structure contains a tag that informs the DFB when to use the DDT values instead of the DFB default values. This technique is helpful for scaling and setpoint applications.
The Graphics Impact
PLC Standards must be developed with graphics in mind. When defining PLC Standards, it is essential to consider what interfaces with the SCADA system as it relates to the physical environment. A balance must be achieved between complexity and functionality.
Conclusion
The PLC Standards Development Summary provides a guideline for observing best practices when implementing PLC Standards. As we have detailed, each step in implementing PLC Standard components creates a PLC Standards-based program that optimizes efficiency when automating a machine or process.
