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.
Revised ISA88 Part 5 draft definitions
January 20, 2011
We've revised the Oct. 25 posted ISA88 Part 5 draft language on definitions using comments, suggestions, and questions received. See what you think of the revised language, below, and let me know if you have any further questions or comments or suggestions.
For the purposes of this part of this draft, the following definitions apply. Definitions and concepts expressed in the Part 1 standard apply, except where differences are explicitly stated in this part.
3.1 Automation Object (AO)
The grouping of engineered control components that will carry out the requirements of a module. This must include one or more functional strategy components and may include a function manager and a resource manager. An automation object provides public methods to interact with its components.
3.2 Command Processor
The functionality of an AO that will receive commands from a public source and evaluate them to determine what actions to take. Appropriate commands will be passed to the active functional strategy in whatever form the functional strategy requires. The command processor provides public status results of any requested activity.
3.3 Control Strategy (CS)
The actions required to carry out the control described by an operating scheme for any equipment or control module or grouping of such modules.
A Device is a piece of physical equipment, such as a sensor or actuator, and has no control associated with it. Part 1 refers to this as a Control Module. When control is associated with a device it becomes a Control Module Entity.
Example – the valve body, actuator and limit switch are devices that when paired with the functional strategy of a control module form an on/off block valve.
Example – (From Pierre)
3.5 Engineered Control Component
The part of an automated implementation that provides the control to create an entity as defined in the Part 1 entity model. These components are generally created in the automation environment as part of an engineering effort and will be used to form a control strategy.
3.6 Function Manager
If the AO functional strategy supports command and control capabilities in a public method the AO function manager provides the public interface and methods to process commands and manage control that is applied to the functional strategy.
3.7 Functional Strategy
The part of an AO containing the control function specifically engineered to carryout the control required by an operating scheme. This AO component must as a minimum provide predefined information in a public way.
3.8 Mode of Action
The mode of action is used to define the behavior of the functional strategy independent of the source of commands. A functional strategy may support the part 1 defined modes of automatic, semi-automatic, manual. Other modes that pertain to the functional strategy may also be supported, for example simulation.
3.9 Mode of Control
Where an AO has more than one functional strategy and/or more than one source of command and control the mode of control will define the behavior of the entire automation object as to who or what can issue commands and which functional strategy will react to those commands.
3.10 Resource Manager
If the AO has multiple functional strategies and/or supports multiple users/owners the AO resource manager will provide a public method to manage the other components of the AO to see the required functional strategy that is active and insure the commands and control are accepted only from approved sources.
David A. Chappell, Complete Manufacturing Automation associates - LLC
Not seeing the comments box? Click here to comment on Revised ISA88 Part 5 definitions, and scroll to the bottom of the page.
Thursday, 14-04-11 08:30
You raise some good points Rick. Let’s start a dialog about this to make sure we understand each other. I've responded in length in another blog posting here:
- David Chappell
See the posting: ISA88 Part 5 draft: Resource Manager implementation question, answer
Friday, 08-04-11 08:29
I've been following the progress of ISA-88 and applying its priciples since its creation, and I'm glad that Part 5 is nearing completion (it standardizes all the details I've had to develop on my own), but I'm confused about implementation of the Resource Manager. I've always seen this as a global utility component, since allocation of ownership seems simpler and more unified if managed in one place. When forced down into each AO, management seems disjointed and more difficult to coordinate and control (each AO has to have a common understanding of the model of ownership required by the process for any given control mode, state, or condition). Beyond the ability to generally define which commands should the AO listen to (Operator or Program as set locally in the AO), specific ownership, like that required for recipe execution, seems better handled centrally. If I'm missing the point, please explain. Thank you for listening.