Redesigning PLC Development

For 18 months, I had been buried in the PLC (industrial controls) world.

My original mission was to “rethink” the approach to PLC software application development because the state of the art of these systems is perceived as dismal.  PLC systems are seen as infested with bugs, or difficult to document, difficult to maintain, difficult to expand, or some painful combination thereof.  PLC culture has encouraged “one-off” application development, disregard for re-use, disregard for team-development, and tends to be ignorant of or eschew automation in testing and debugging methods.  PLC development culture has not demanded the integration of the advances in software engineering from the past 20 years or so, both in terms of tools and technique.  It is amazing, for instance, how many PLC developers are ignorant of the concept of unit testing or even source code revision control.  The lack of this demand may stem from the intellectual insularity of the culture and innocent ignorance.

My original mission was to overcome the downside risks of the usual PLC development culture and create a new culture, a new development methodology, and new infrastructure that could bypass the usual shortcomings and help us create applications of higher quality than had been expected to date.  The implementation of this mission however is expensive and fraught with risk (e.g., time-to-completion risk), mostly because of the dismal quality of vendor-supplied tools that PLC developers have no choice but to use.  These risks were known from the beginning.  The check-writer’s tolerance for such risks were not known for sure however, only what they said they could tolerate was known.  The spoken and actual tolerance for risk turned out to be very different after all.  No one has been surprised.