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
1000s of solutions to any automation opportunity
February 8, 2008
As suggested by yesterday's comments, "Machine modes, procedures, execute state," any automation opportunity can have thousands of solutions. One solution applied to packaging machines is the PackML State Model.
The PackML State Model applies to a packaging machine and not a batch unit, as such it uses ISA88 concepts and may not, nor is required to, use all of the ISA88 Batch guidelines as a Batch Unit might. The PackML concept applies to the entire physical machine and its associated control.
PackML's recommendation is that the procedure(s) required to satisfy the intent of the model be separated from the control code that is in direct control of the physical devices that carry out the functions of that machine. The procedure(s) also should be implemented as Equipment Operations, organized and managed as an Equipment Unit Procedure.
At this time the PackML concept provides no guidance as how to do that and how to structure the underlying control of the equipment. The intent is that ISA88 Part 1 rewrite and the ISA88 Part 5 will provide that guidance.
Want to learn more? Committee members have access to latest documents in process and under discussion. Contact me using the email link at the top of the page.
Have a view about this posting? Share a comment using the tool below.
Posted by David Chappell on February 8, 2008 | Comments (1)
In response to: 1000s of solutions to any automation opportunity
Francis commented:
Of course there are thousands of ways Some will be better, some worse. Before a single line of Part 5 is written, I suggest that there should be some detailed analysis of past projects to determine if any patterns can be found that will help to determine the ‘best’ ways. There are plenty of projects out there. Instead Part 5 is being written without any such basis, and then apparently deciding for itself what the best way is. This could be an opportunity for WBF members and others to share their experience and perhaps for research projects for Academics too. Some things to consider include Can we define Metrics for the level of functionality in an application? For example, IO Counts, Module counts, numbers of parameters etc. Is there a way of defining operability? Can we determine how much effort the projects involved, versus the functionality and operability achieved? Of course there will be problems obtaining the information. For example, large companies that have had massively overspent projects (I know of a few) will be reluctant to share that information. Others will have hidden their costs whether they realise it or not. Consequently a degree of confidentiality will be required. And such a survey could be costly. But not as costly as the result would be if Part 5 gets it wrong.