Open Automation and Automation Languages

Author photo: Harry Forbes
ByHarry Forbes
Category:
Industry Trends
Decades ago in the 1980s (when I was a young man) a true automation guru told me that one huge barrier to growth in the automation market was the lack of a language that could fully specify an control system configuration. This period was the dawn of the Berkeley Unix era, when programming languages were advancing by leaps and bounds as computer scientists applied themselves to adding capability and applications to Unix. My guru was sure that if such an automation language could be developed, it would spur all kinds of benefits for end users, such as application portability, system interoperability, factory flexibility, and possibly automated control system validation. In the 30+ years since that conversation a great deal of work has been done on this question, both in academia and in commercial products. Many more people in the automation world have come around share the view of my 1980s guru. The apex of this effort are the IEC 61131 and IEC 61499 standards. Parts of these have been incorporated into commercial control design products in the factory and process automation space. There are also open source implementations. One of the objectives of ExxonMobil’s “Next Generation Open Automation System” program is to leverage this type of control design software, rather than using the proprietary function blocks and software tools of today’s DCS products. Last month I co-authored an ARC report entitled “ExxonMobil and Lockheed Martin - 20 Questions about Open Automation”. One of our 20 questions was this:
Control system representation using IEC 61499 seems central to this vision. Today, only a handful of industrial control software products implement IEC 61499. How mature is this technology today? What practices will maximize portability of end user control configurations?
Rethinking this, I would extend the question to both IEC 61131 and IEC 61499. These questions are important ones and ones that ARC wants to research in the near term. I welcome input on the topic from anyone, but especially from the experience of end user manufacturers. Why do I think it’s important now? First because ARC has worked with ExxonMobil for many years and by now we are pretty familiar with their vision and with their pain points. Second, because when you review the academic literature you find statements like this:
The first industrial implementations [of IEC 61499] have already shown that industry is not ready to follow all these provisions simultaneously. Driven by market reasons, implementers select priorities in addressing different target features of the IEC 61499 technology. Thus, ISaGRAF has been more concerned in extending the system-level engineering capabilities of their tool chain, rather than achieving lower level code portability through the use of XML as program representation. Therefore, this tool chain has phenomenal capabilities in distributed deployment of large complex applications, but syntax and representation are proprietary and not compatible with other IEC 61499 tools at this stage. Compatibility with the legacy IEC 61131-3 run-time environment influenced ISaGRAF’s decision to use the cyclic execution model, which differs from the execution model prescribed in the standard. However, one should note that these incompatibilities can be overcome in the future by developing software tools for automatic conversion.
Hmm. So let me rephrase ARC’s question:
Control system representation using IEC 61131 and/or IEC 61499 seems central to the Open Automation system vision. How mature are these technologies today? What practices will maximize portability, interoperability, validation, reusable engineering, and business value of end user control configurations?
Please let me know what you think.

Engage with ARC Advisory Group

Representative End User Clients
Representative Automation Clients
Representative Software Clients