Control Engineering - The Next Level

While I have not investigated university-level engineering curricula recently, I have the impression that most engineers that work with industrial controls graduate with some level of competence in computer programming. I don't want to diminish the value of the skills these engineers possess, but I do want to make and observation: an engineer who writes software is not the same thing as a software engineer.  This observation comes not just from personal experience working with industrial control developers for many years, but from conversations with other professionals with similar experiences.

Some comparisons:

• An engineer who writes software believes the current revision of the source code is what is currently running on the controller; anything on a PC or network storage is a snapshot of the current version and should not be relied upon to function in the same way as the version running on the controller.  A software engineer believes the current revision of the code resides in a version control repository with official release records.  If what is running on the controller varies from the official version, it is considered an illegitimate release.
• An engineer who writes software is highly pragmatic; the goal is to make a process or machine work.  A software engineer accepts the goal of making the process/machine work as one of numerous requirements to ensure optimal business value.
• An engineer who writes software sees each project as a unique problem set requiring a unique solution.  A software engineer looks for design patterns and implements reusable objects/modules to not only provide a solution for the current problem set, but to reduce the cost of future solutions as well.
• As long as production and regulations are not impacted, an engineer who writes software may not be constrained by existing standards.  A software engineer embraces standards because they improve code maintainability, reusability, improve enterprise integration, and reduce the life cycle costs of the solution.

Why it Matters

Before the proliferation of PLC-based controls, production equipment was driven by relay logic.  After the introduction of microprocessor-based controllers, ladder logic was implemented to provide a familiar "relay emulation" approach to control programming.  In the relay-driven world, getting the machine to function correctly was the main requirement - this did not change with the introduction of the PLC.  But PLCs have vastly more capabilities than the relay-driven control systems, and ladder logic evolved into the IEC-61131 standard which provides for higher-level programming capabilities.  Then came graphical user interfaces and a variety of SCADA tools to provide even greater capabilities, but with added layers of complexity as well.  With complexity comes cost and the need for management.

Controlling Costs

Accounting practices vary from organization to organization, but source code (whether for industrial control or any other function) can be considered a capital asset.  Studies have shown that the initial cost of development is 20% or less of the total life cycle cost.  This has implications for everyone developing software: find ways to optimize your organization's software development practices to reduce the long-term costs associated with maintenance.

Risk Management

In addition to maintenance costs, business risks must also be taken into consideration.  Relay-driven equipment is not threatened by internet viruses, but nearly every PLC or PAC being sold today has an Ethernet connection, and the number of controllers being connected to the enterprise network grows daily.  There are also downtime risks associated with controller failure; if the "current software release" is only available on the controller on the plant floor (as opposed to a version control repository), it will take much longer to get production going again after a controller failure. 

There are also risks associated with system upgrades.  Many modern control platforms have a server-based footprint in addition to the controllers on the plant floor.  Not only do control engineers need to be concerned with firmware revision management on the plant-floor controllers, but must also be concerned with operating system patches in the server room.

Enterprise Integration

Controllers are becoming a bigger part of the manufacturing business, because they contain valuable production information, including production history, machine health, asset effectiveness, parameter change history, and more.

In Summary…

All of these factors point to the need for controls engineers to become proficient software engineers rather than engineers who write software.  It would be easy to place the accountability for this transition on management, but this really is more a leadership challenge than one of management.  Control system professionals cannot simply accept status quo, but must actively seek to improve and they should not wait for management to direct them.  If anything, they should be teaching management what changes are necessary to meet the business demands.  Standards (such as ISA-88, ISA-95, and ISA-99) exist that help establish the necessary disciplines; it's time for software engineers to step up in industrial controls!