Imagine taking a trip to the supermarket.
Selections are made based on individual tastes, dietary requirements, and price. During each trip, we take for granted that products are safe for consumption and pose no health risk. Now, imagine the same trip where one of every five items purchased could make us sick. Without standards and adherence to strict practices for food handling and processing, modern-day food distribution from farm to retail wouldn’t work. Yet for companies heavily dependent upon automated control system this is the risk faced by control engineers where programming flaws have been estimated to account for 20% of the root causes of accidents.
HOW DID WE GET HERE?
Reaching this point has been more revolutionary than evolutionary. As the world moved from mechanical controls and electrical relays to sophisticated controllers guided by software, many of those responsible for logic design failed to keep up. Control systems were based on mechanical controls with basic logical requirements for functionality. In the beginning, coding was primitive, consisting of basic ladder diagram representing relays to control mechanical components.
As the computer age advanced, so did the capabilities of software. However, programming for PLCs remained stuck in the same programming mindset. Additionally, many of the electrical engineers writing code for existing controllers were not formally trained in advanced methodologies of software coding, magnifying the problem and increasing chances for error.
DANGER OF LAGGING BEHIND
As newer and more sophisticated systems are developed, automated control systems rely as much on software to run the equipment as on the equipment itself. Efficiency, control, monitoring, and safety are affected by the programming of the software to maximize the utilization of equipment. Poor coding of PLCs can, therefore, have a powerful negative impact on the entire system.
Some of the inherent dangers in the coding lag include:
- Safety: Trying to implement sophisticated software requirements using primitive coding can result in serious—and entirely avoidable—incidents and accidents.
- System Gaps: Today’s factories are highly interconnected, and primitive programming of PLCs can lead to gaps in the system. As companies move to become connected enterprises, software required to run the different elements is becoming more complex. Without better programming, the traditional method of coding could wind up akin to trying to use a vacuum tube to repair an integrated circuit on television. At some point, the advancement of technology will diverge to the point that the old methodology simply won’t work.
- Multiplier Effect: Factories today are so sophisticated and so interconnected that the problem of using an archaic coding framework is not a linear one. The amount of software required to run modern automated control systems is so huge that the deficiency can multiply the problem exponentially.
IT’S ABOUT THE SOFTWARE
The root cause of many failures and incidents lies in the failure to understand that we are dealing with software. To close the gap between the archaic, haphazard style of coding will require adopting protocols, goals, and methodologies available to software engineers. Some variations exist, but generally, there are five goals of software design used by software engineers that should be incorporated in PLC programming:
- Correctness: The software should satisfy its requirements each time.
- Robustness: Software should tolerate misuse without catastrophic failure.
- Flexibility: Requirements may change over the lifespan of the software and it should be able to change or adapt to new functionality.
- Reusability: To save the cost of code production, the software should reuse object codes, source codes, and frameworks.
- Efficiency: Software should make use of available processing power, memory and speed.
PLC code is much more about software than it is about electrical engineering. Understanding this reality and utilizing the goals, principles, methodologies, and tools available to software engineers will allow for better and safer creation of code. This was one of the driving forces behind the development of the WonderLogix Enterprise platform and one that we’ll continue to cover in future blog posts.
If you’d like to learn more about WonderLogix and how you can get your PLC project to market 3X faster without having to code, please visit our page.