Standard Profits: Make2Pack and ISA88
David Chappell is chair of the Make2Pack/ISA88 Part 5 standards development effort, with Complete Manufacturing Automation Associates - LLC, and retired Proctor & Gamble section manager for batch technologies. Help ISA88 committee members increase dialog about, completion of, interest in, and use of Make2Pack. Join in with your comments or questions to help the standard along, on your way to gaining competitive advantage, reducing overall costs by half. David A. Chappell, Make2Pack chair, and other ISA88 Part 5 committee members provide intelligence and specific links for this effort, spanning OMAC, WBF, and ISA standards efforts.
NOTE: ISA grants permission to post portions of the ISA88 (or other applicable standards) in this blog for comments and discussions and postings (or comments) from this blog may be used for ISA and related standards development.
ISA88 Part 5 draft: Command, control, status, and functional strategy
May 13, 2011
A series of discussions follow seeking input on possible language in ISA88 Part 5 draft standard. Figures 6-12 follow with diabrams on functional strategy, and other concepts. Please provide comments to ensure the standard is understandable, appropriate, and useful across industries and areas of control, machine control, batch control, and continuous control, as well as flexible and scalable, across hybrid applications.
Interactions between modules are generally not managed and are deeply imbedded within the FS as indicated in Figure 6: Traditional Modular Interactions. In Module A of the Figure 6 example interaction with Module Z occurs from within the body of the FS automation and requires detailed knowledge of the interfaces provided by Module Z.
- Command and control can be implemented using simple logic or more sophisticated interfaces based on data types other than Boolean for exchange of command and control as represented in Figure 7 and Figure 8.
- Not all traditional implementations of commands by a module are fault tolerant, often providing little to no error checking or error recovery.
- Not all modules are traditionally designed with a command and control interface that manages access by external entities as indicated in Figure 9: Interactions of multiple entities.
- Traditional approaches generally require that if more than one entity requires the use of a module, those external entities must interact in a way that prevents unintended actions by the FS.
- Traditional approaches often avoid using small reusable modules because they lack a standard approach for managing their interactions. Figure 10 and Figure 11 represent two approaches to automate the same system. The 2 module implementation minimizes module interaction where the 12 module implementation maximizes reusable modules.
- The separation between equipment phase and equipment module procedural, coordination and basic control across modules is not always pure as represented in Figure 12. For the purposes of Part 5, procedural control is identified as any control that has a quiescent state that requires an external entity to issue a command to cause it to leave that state and carry out the intended functional strategy, at the conclusion of the execution of the functional strategy the quiescent state will be reentered. Basic control does not have a quiescent state as part of its functional strategy and is capable of self direction from and to any state.
Do you understand the draft language? Is it useful across disciplines? Does anything confuse you or require additional explanations? Please comment below. Don't see the comment box? Click here and scroll down.
- David A. Chappell, Complete Manufacturing Automation associates - LLC