What does it look like? If we borrow from OMAC, then the structure is broken down into areas (Figure 1).
OMAC just uses machine(unit), equipment and component(control), but adding system allows flexibility because you may have more than one line in a system.
In the system, you may create equipment components for sharing between machines that supports each machine. This would be the air, water, utility type support or maybe a robot or the safety. It also allows one supervisory control and data acquisition (SCADA)/human-machine interface (HMI) software to be used for the whole area. Remember, flexibility.
Equipment is exactly what it says: filler, generator, robot, turn table, conveyor, boiler. Components would be valves, switches, temperature or pressure gauges, all of which may be programmed as an object to be called out under the equipment module.
What does our equipment do? PackML defines four modes as standard:
- invalid
- production
- maintenance
- manual.
The names might automatically set people to grumbling, but they can be described as fault, auto, maintenance and manual. This is where the suggestion to adapt the PackML definition to industry and machine is inserted. Why? The idea is good, but it may not match where the original equipment manufacturer (OEM) is in machine building. However, the point is standardization and that is what the OOP tools allow you to do.
There are also 32 total modes in the PackML protocol, and OEMs may create a machine using one mode or all of them. The four standard modes are just a starting point.
PackML state models include a predefinition of state, state command and mode. There are also transitions. Transitions are where modes may be changed. Stopped, aborted, completed and held are transition states.
