Control Engineering

David Chappell

Why are we doing this? Greater efficiency
December 11, 2007

In a telephone and Web-based meeting last week and in our live meeting in Dayton (today through Thursday), I’ve explained some of the many reasons why we’re working on this Part 5 effort. Some of the discussions go like this.

What we’re doing here is at the core of most basic control. There is some higher level sequencing type control. S88 and the IEC 61499 standard encourage linking function blocks or modules in such a way that they’ll carry out a control strategy. We want to support a structure that can acquire and release components as necessary to carry out the control strategy. If something goes wrong, it turns over control to manual so humans can leverage what’s there, fix it, and then turn it back over to the automation.

Everyone’s doing this kind of code, but a 1,000 different ways. Standard languages are used, but one vendor implements the pieces differently than another vendor. In integrating systems, implementation also can differ using the same vendor’s hardware. In that diversity, you lose any benefits if attempt to reuse or reconfigure the code because the customization required is overwhelming. This lack of standardization and consistency confuses things and increases the need for training. Plus, from application to application, the programming structure is so radically different, there’s little benefit to be had from the prior investment. Let the art be how the software objects, the function blocks, are assembled, rather than in the custom code. (Proprietary algorithms still can be hidden as internal and invisible components.) It’s always easier to assemble from reusable parts than to create from scratch… hours instead of months.

The unbridled diversity is what we’re trying to remedy. Why? For greater efficiency and interoperability among vendors, across platforms, and applications within the same software; time and cost savings, through greater scalability, reuse, faster startups, significant reduction in validation requirements, and quicker job changeovers.

And automation vendors also will benefit (that’s why so many are involved on this committee) because end-users, OEMs, and system integrators will have more time and resources to be more efficient and have resources to purchase and apply more automation for other areas. Many apply these structures, but at a huge investment. Having a standard set of structures will free resources for their core missions.

Using the modular designs and examples that we’re assembling and clarifying from other sources will be a greater enabler all around. Part 5 will contain examples and models, showing why this is so, some of which previously discussed, below.

Comments? Questions? Click into the tool provided, and let me (and those involved in this effort) hear from you. A lot of what we’re talking about has been done. Share some examples with the comments tool on this page. R.M. (Bob) Steele, GE Fanuc; David Bell, Wonderware; Dennis Brandl, BR&L Consulting; and Mark T. Hoske, Control Engineering, added to the thoughts above.

Posted by David Chappell on December 11, 2007 | Comments (0)