At the end of 2023, the Society of Automobile Engineers (SAE) sponsored a report from consulting firm BCG called “The US Needs More Engineers. What's the Solution?” in December 2023. It showed that the United States is facing a massive shortage of engineers.
The report, which was not focused on the automotive industry, but instead all engineering fields, showed that the United States needs approximately 400,000 new engineers every year to achieve equilibrium in the workforce, yet every year, one-third of all open engineering positions remain unfilled.
At the time of the study, the trend was expected to continue into the year 2030. Recent changes to education funding and H1-B visa availability may extend this situation out further.
Two of the biggest groups seeing an employment shortfall are software engineering and industrial control programmers. Obviously, not all industrial controls need degreed engineers to program them, but that study indicated a symptom of something bigger—a shortage of skilled programmers in general in our manufacturing industries.
This situation is not completely unlike other challenges the automation industry faces regularly, such as becoming more efficient with the resources on hand. In this case, the resource is the skilled industrial programmer. And just as with equipment on the factory line, the main low-hanging fruit of increasing efficiency is reducing downtime while increasing uptime.
Downtime for industrial programming could be viewed as anything that keeps an engineer or technician from pumping out effective code, such as having to train on a new software package, learning a new programming language or set of code-troubleshooting tools. Having a standard set of programming languages is a huge step in the right direction to avoid having to sit in training classes on a new language and the inevitable learning curve that using a new language entails.
The International Electrotechnical Commission (IEC) 61131-3 programming standard was introduced in 1993 with the original intent of standardizing programming of programmable logic controllers (PLCs) across vendors through the use of five standard languages: structured text (ST), instruction list (IL), sequential function chart (SFC), ladder diagram (LD) and function block diagram (FBD). For better or worse, the IEC 61131 standard is changing, and we will be down to four languages soon. Yes, IL is going the way of Pluto and has been voted out of the solar system, or in this case, the IEC standard.
The IEC 61131 standard was initially touted to make programs fully portable from one vendor’s editing environment to another and be completely hardware-agnostic. Can you imagine being able to download a complex motion program written in one vendor’s environment into a competitor’s and have it function without a hitch? Those were lofty goals and never really saw the light of day.
One of the reasons this “program portability” never came to fruition was the way the standard itself was adopted—each vendor was able to make “enhancements” above and beyond the basics of the IEC 61131-3 standard, as long as the basic standards were followed.
Of course, new vendor-specific instructions were also needed to facilitate competitive advancements in a supplier’s drives, actuators and sensors. These loopholes were double-edged swords; they made it more appealing for additional vendors to jump on the IEC 61131 bandwagon and have a “compliant” programming package but resulted in losing the ability to freely move a program from one brand of PLC to another.
Get your subscription to Control Design’s daily newsletter.
However, in terms of portability, it is now the programmer that is the portable entity between vendors of controller programming environments. Once an engineer or technician knows IEC 61131 programming in one programming package, the vast majority of the instructions, variable declarations, ways to create custom functions or function blocks are the same in another vendor’s editor.
As a matter of fact, most IEC programming environments use one of only a handful of different editors, which are integrated into that vendor’s software package. Even then, the look, feel and tools are very similar.
A seasoned IEC programmer knows which instruction to use, but the way it’s added to the program may differ a little. No complete retraining of a programmer for a completely new and alien-looking environment is required, just learning a few new mouse clicks and menus to navigate to find the things they already know how to use—the elements for creating the logic, how to compile and how to download to the new vendor’s controller.
This may also be an impetus to finally upgrade older equipment that is nearly unsupportable, or the support engineers familiar with it are aging out of the workforce. Moving to the same or similar programming environments for the replacement equipment reduces effort when downtime for that equipment happens.
Long story short, the IEC 61131-3 standard is nothing new, but because of our continuing shortage of engineering and technical programming resources, the IEC programming environments may be the way to look at this problem from a different perspective and may result in maximizing our own uptime and making ourselves more efficient and portable between platforms.
