That was easy? Standard profits
I'm convinced that the value of the ISA88 Part 5 standard, if widely applied as intended, will mean the difference between profitability and plant closings at many facilities. Part 5 is the core of most basic control. Despite that value, making standards isn't easy.
I love the office supply store commercial where someone pushes a button, something good happens, and it was easy. Wouldn't a profitability button be a great thing? There is one, though it's not quite as easy as button pushing. We write (the button), you adapt (actuation), and everyone's more profitable (that was easy). Standards are among the profitability buttons available.
I'm convinced that the value of the ISA88 Part 5 standard
ISA88 Part 5 standard, if widely applied as intended, will mean the difference between profitability and plant closings at many facilities. Despite that value, making standards isn't easy. Language barriers are high. (One person's “mode” is another person's “state”, for instance. An appendix in the ISA88 Part 5 standard helps translate.)
Participants practice patience. “I'd like this to be the last time we're revising these examples,” said one at a recent meeting. “Making standards can be like watching snails race,” another admitted. “By the time we're done, some may forget why they were racing anyway.” Collaboration can dismiss competitive tendencies for a time and allow committee members to learn, teach, and do what's best for as many as possible.
The Dec. 11 entry in the blog, “Standard profits: Make2Pack and ISA88 ,” explained some reasons why the Part 5 effort is at the core of most basic control. Dave Chappell and committee members are using ISA88 and the IEC 61499 standards to encourage linking function blocks or modules in such a way that they'll carry out a control strategy. The structure will acquire and release components as necessary to do that. If something goes wrong, the process goes to manual so humans can leverage what's there, fix it, and then turn the process to the automation.
Everyone's doing this kind of code in a thousand different ways, the blog says. 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.
Diversity and customization thwarts future efforts to reuse or reconfigure code, even from application to application or within the same application, the blog says. Lack of standardization and consistency confuses things and increases the need for training. The art should be in how the software objects, the function blocks, are assembled, rather than in custom code.
What do you think? Email your thoughts to Mark T. Hoske or use the comment feature on this page to share your views.