Standard profits: Make2Pack and ISA88 
Recent Posts
- Make2Pack ISA88 Part 5 Dayton meeting demo, scope, interoperability
- Refinement for the line in the sand between ISA88 Part 1 and Part 5
- Make2Pack definitions and descriptions for types of control
- A line in the sand: Equipment Phase
- Bigfoot, Lock Ness Monster sighted! Control types
- Upcoming Make2Pack meetings; get involved
- A Device is a Device is a Device; But what if it is not?
- Meeting: Replace babble of Control Components with understandable language, OPC help
- 1000s of solutions to any automation opportunity
- Machine modes, procedures, execute state
Recent Comments
- Jay Rouse on It’s elemental Mr. Watson: control system terms
- Another S88 Blogger on A Device is a Device is a Device; But what if it is not?
- Francis on 1000s of solutions to any automation opportunity
- Francis on Machine modes, procedures, execute state
- Francis on Mode is a many-splendored thing
Most Commented On
- Mode is a many-splendored thing (6)
- It’s elemental Mr. Watson: control system terms (2)
- 1000s of solutions to any automation opportunity (1)
- A Device is a Device is a Device; But what if it is not? (1)
- Machine modes, procedures, execute state (1)
Archives
Blog
Link This | Email this | Blog This | Comments (1)
Make2Pack ISA88 Part 5 Dayton meeting demo, scope, interoperability
For three days in the Dayton Airport Hotel, April 15-17, 10 Make2Pack ISA88 Part 5 committee members have gathered. We’re continuing to develop Working Draft 5 and deliver related explanations for Phase Interface, Data Control Component, the role of Custom Logic, and refine and deliver the Control Component Command interface.
A tabletop equipment demonstration (see screen shot above; photo below added on April 16) has controllers, two conveyors, photoelectric sensors, safety interlocks, terminal blocks, and an HMI interface using the latest in Part 5 thinking. Bob Steele of GE Fanuc developed the screen and code (structured text and ladder logic) and Dave Bell of ATR Distributing (Wonderware Cincinnati) helped with integration with some equipment on loan from P&G.
In addition to the demonstration, first part of the meeting helped catch us up with terms, scope, and intent of the standard, reviewing diagrams and language, especially as related to Part 1, now being updated as Part 5 is being drafted. Also important is how this effort fits in with other standards efforts, such as PackML (part of OMAC). Other standards mentioned in discussions include OPC DA, OPC UA (OPC’s Tom Burke joined the committee today), IEC 61131, and various industrial networks.
One point discussed for some time was if a Resource Manager (RM) always has to be present as a doorway for inputs and outputs of Functional Manager (FM) or if the FM can interact directly with something external to the module. Diagrams now used to support the standard show that direct interactions are possible without a RM. When a RM is used, a model is defined for consistency. Other discussions included scope and detail of the standard—whether the intent is to create guidelines or if certifiable, interoperable devices and controllers will result. Clear guidelines allowing for scalability and collapsibility are a minimum. Interoperability is the hope.
Review prior postings (see column at right) to get an idea of Part 5 scope. Comments, questions, or advice? Please add some below.
Make2Pack ISA88 Part 5 Dayton meeting demo, scope, interoperability
April 15, 2008
For three days in the Dayton Airport Hotel, April 15-17, 10 Make2Pack ISA88 Part 5 committee members have gathered. We’re continuing to develop Working Draft 5 and deliver related explanations for Phase Interface, Data Control Component, the role of Custom Logic, and refine and deliver the Control Component Command interface. |
| ISA88 Part 5 demonstrations such as this one aim to ensure the models work before they’re made part of the standard. |
 |
| Conveyors help demonstrate orderly hand off of control from one resource to another. |
One point discussed for some time was if a Resource Manager (RM) always has to be present as a doorway for inputs and outputs of Functional Manager (FM) or if the FM can interact directly with something external to the module. Diagrams now used to support the standard show that direct interactions are possible without a RM. When a RM is used, a model is defined for consistency. Other discussions included scope and detail of the standard—whether the intent is to create guidelines or if certifiable, interoperable devices and controllers will result. Clear guidelines allowing for scalability and collapsibility are a minimum. Interoperability is the hope.
Review prior postings (see column at right) to get an idea of Part 5 scope. Comments, questions, or advice? Please add some below.
Posted by David Chappell on April 15, 2008 | Comments (1)
Advertisement
Advertisements
