It is so important that the relevance of state is explained in such a generally understandable way. It requires some infrastructure though (connectors to PLCs, maybe protocol gateways from proprietary or standard protocols, secure OT-network, DMZ, SQL db on site or in cloud hosted and operated, basic data models/data ops, IIoT platform in place, data governance on how/who to access the state data, organization of OT and IT people working together,....) to get such a simple metric like state done. It is necessary and highly valuable but it needs some maturity of the organization to materialize. However it is a must-have in every manufacturing organization for sure to get the most basic KPIs for decision making and process performance optimization.
Great video! looking forward to the workshop. Can you give an example of a Business System State and would there also be a machine state or can only one state exist for a machine at a time?
For a particular Machine at any given point of time the State Register have only one unique value despite the underlying reasons could show as man (activated) , Now lets assume you have 1000-2000 alarms in a machine which results in stopping of a machine , what will be the value of your State register ? The alarm code 999 that lead to stopping of machine or just STOP CODE as 0, Even EStop can cause Stop so if the machine has been stopped by ESTOP then STOP CODE 0 wont be generated even if the machine is actually in STOP State ? Thus this leads to assumption that Stopped state can be caused by many or multiple alarms too ?? What are the reasons you are taking into account for the Stopped Status ? There are blocked and bypass states introduced by Production people to continue with the production even if the reason has not been resolved immediately but resolved much later (. How do you handle them ? As per your logic the state register should always toggle between Stop/ Estop/ Other 2000 Reason code and run Code always for this state register to be evaluated from calculating each stop stop time and aggregating them against each code. In your state table you have shown 3 fields State ! Stop Time ! Start Time, where as in reality (your logic) it will be only 2 fields per record , am i correct here? If you use similar logic for alarm analysis you will fail for sure or have a very tough time in working out the alarm state and its resolution time. How are you handling that in your MES ?
Should state be aggregated from inputs to a single integer within the PLC? Or in the IoT platform? And should an enterprise wide standard for state enums be used or just machine by machine?
Preferably in PLC, but for brownfield it makes much more sense to use the IIoT Platform. You should use enterprise wide standard for enumeration that reserves integer blocks for custom states by asset
Looking forward to the workshop!
I'm looking forward to translating Machine States to Line states...looking forward to the bootcamp
It is so important that the relevance of state is explained in such a generally understandable way. It requires some infrastructure though (connectors to PLCs, maybe protocol gateways from proprietary or standard protocols, secure OT-network, DMZ, SQL db on site or in cloud hosted and operated, basic data models/data ops, IIoT platform in place, data governance on how/who to access the state data, organization of OT and IT people working together,....) to get such a simple metric like state done. It is necessary and highly valuable but it needs some maturity of the organization to materialize. However it is a must-have in every manufacturing organization for sure to get the most basic KPIs for decision making and process performance optimization.
Well said!
Great video!
looking forward to the workshop.
Can you give an example of a Business System State and would there also be a machine state or can only one state exist for a machine at a time?
For a particular Machine at any given point of time the State Register have only one unique value despite the underlying reasons could show as man (activated) , Now lets assume you have 1000-2000 alarms in a machine which results in stopping of a machine , what will be the value of your State register ? The alarm code 999 that lead to stopping of machine or just STOP CODE as 0, Even EStop can cause Stop so if the machine has been stopped by ESTOP then STOP CODE 0 wont be generated even if the machine is actually in STOP State ? Thus this leads to assumption that Stopped state can be caused by many or multiple alarms too ?? What are the reasons you are taking into account for the Stopped Status ?
There are blocked and bypass states introduced by Production people to continue with the production even if the reason has not been resolved immediately but resolved much later (. How do you handle them ? As per your logic the state register should always toggle between Stop/ Estop/ Other 2000 Reason code and run Code always for this state register to be evaluated from calculating each stop stop time and aggregating them against each code.
In your state table you have shown 3 fields State ! Stop Time ! Start Time, where as in reality (your logic) it will be only 2 fields per record , am i correct here? If you use similar logic for alarm analysis you will fail for sure or have a very tough time in working out the alarm state and its resolution time. How are you handling that in your MES ?
Should state be aggregated from inputs to a single integer within the PLC? Or in the IoT platform?
And should an enterprise wide standard for state enums be used or just machine by machine?
Preferably in PLC, but for brownfield it makes much more sense to use the IIoT Platform. You should use enterprise wide standard for enumeration that reserves integer blocks for custom states by asset