I am in Plymouth, Indiana today at the latest MTConnect Technical Advisory Group to work on the latest Ver 1.3 MTConnect XML schema. I thought I would add in this blog entry the notes for this meeting to show what the MTConnect members are thinking at this point. The general feeling is the MTConnect is now broad enough to offer real value as a universal connectivity standard on the factory floor.
Introduction:
The meeting has several thrusts - namely solidifying Ver 1.3 of the standard, getting ready for IMTS in Chicago Sept 10-15, 2012 and introduce the new Parts and Production Information Working Group led by Jim Smith of Nexas America. Courtney Hill from GE Aviation (retired) and the MTConnect board member gave the intro.
Session 1 - OPC Discussion
Will Sobel of Systems Insights, started talking about the MTConnect-OPC UA Companion Specifications. The integration of the OPC standard will help address the limited information from the PLC tag map for MTConnect purposes. The SDKs of the PLCs are dependent on which type of PLC you have, which makes integration tough. MTConnect linked with Randy Armstrong from the OPC Foundation - but he is now a consultant these days.
OPC has traditionally been a window of access to PLC data, but control information may be possible to access - but it can be limited and case specific. MTConnect should look into this to address the process industry including automotive which often bridges the CNC/PLC technologies. PLCs are embedded into CNCs, but they are often used in conjunction with discrete manufacturing so addressing this market will make sense. Also the process world has a host of well developed software applications that can be leveraged with MTConnect.
OPC UA uses XML and runs out of the controller these days, rather than leveraging the external DCOMM market so it is a natural fit with MTConnect and the XML schema it is based upon. Legacy integration may also be aided here. Call for interest by Dave Edstrom (MTConnect Chair) - time, money, expertise...
Session 2 - Mobile Assets Group
Major changes for Ver 1.3 include the inclusion of the Cutting Tool Archetype.
Points included:
Archetypes vs. Instances
The Archytype contains the static information that is the same for the entire class of tools. This is information from tool libraries. The Archetype is an abstract tool. The Cutting Tool (instance) contains the life cycle data for the physical tool. This will correspond to a single assembly with ID, life cycle data etc - hard data from a specific tool.
The need to represent Cutting Tool Data when information about individual assemblies is not present. Archetype has the same structure as the Cutting Tool except for the following:
Cutting Tool (instance) has the CuttingToolDefintion now deprecated - it can only be used in a Cutting Tool Archetype.
ISO 13399 Part 28 XML (versus Schema is in EXPRESS format as represented in Part 21) is the ISO standard for tool definitions.
A machine tool may only know the following:
- asset ID
- Location
- Length & Diameter
- Time in Use
Separating the Archetype allows for a much lighter data package - better for RFID.
Asset Removal
- an asset can now be removed from the agent
- the assets are marked as removed, so that they can still be accessed
- an AssetRemoved event is sent when the asset is removed
- an application can request the agent provides both removed and active
assets using the "removed=true" URL argument
- when an asset is removed it is not moved to the front if the MRU list
- an attribute has been added to the Asset as well as any sub-type of Asset (like cutting tool)
- helps with tracking
Retention Knobs and Locations
Questions From The Floor
What about work holding?
Can this asset group handle people resources - or where does this resource fit?
Session 3 - Accessory Equipment & Inter-Device Connectivity
Started with bar feeder integration - simplified interface model with minimal changes to MTConnect. There are Open Source tools available for implementation, Two successful proof-of-concept implementation with y LNS/Mazak and EDGE/OKUMA.
Right now the Legacy Digital IO Protocol is used there - 10-16 I/O points needed - but limited. Current model is Read/Write by the bar feeder to the CNC. The MTConnect model is passing data, not bits. We need a common vocabulary for all vendors. Make a less brittle interface (to "Future-Proof" yourself) by decoupling from the decoupling from the static register mapping. MTConnect supports "near-real-time" data monitoring. The protocol supports report by exception to optimize resources - using the MTConnect push protocol with a request at 0 milliseconds - send when a change occurs in other words.
MTConnect provides a higher degree of failure detection:
MTConnect is self-healing - states asserted once connection is re-established.
Simplified Interface
- moved away from new category of data item - using events with CDATA indicating state;
- moved all data describing the Stock into the Assets model:
- there was no performance or reliability degradation using MTConnect here
Benefits
Rich data means better decision making - better monitoring, better use of stock, better scheduling and processing, better (and easier) integration, tunable failure detection, less downtime, etc...
Neil Desrosiers from Mazak shared that the benefits of MTConnect far outweighs the costs and that customers have already enjoyed the additional data available in additional to the legacy I/O interface. customers want more and MTConnect is the answer to their needs - and it is expandable for the future.
Check out Mazak's MTConnect offering at:
http://www.mazakusa.com/MTConnect/MTConnect_Brochure_7_15_2011_For_Viewing.pdf
And Beyond...
Adding asset monitoring and control of bar feeder manufacturing assets, extend to other factory components:
What is Still Needed?
- MTConnect needs a Discovery Model for MTConnect devices
- SSDP (Simple Service Discovery Protocol) is widely used and could be adopted here
- need to work on UUID scheme
- this is really needed
- dynamic, distributed, lower maintenance than LDAP
- limited broadcasts to sub-net which is great using multi-cast
- it routes (and is widely accommodated in current IT paradigm)
---
Stay tuned for the Parts Group Next....
Introduction:
The meeting has several thrusts - namely solidifying Ver 1.3 of the standard, getting ready for IMTS in Chicago Sept 10-15, 2012 and introduce the new Parts and Production Information Working Group led by Jim Smith of Nexas America. Courtney Hill from GE Aviation (retired) and the MTConnect board member gave the intro.
Session 1 - OPC Discussion
Will Sobel of Systems Insights, started talking about the MTConnect-OPC UA Companion Specifications. The integration of the OPC standard will help address the limited information from the PLC tag map for MTConnect purposes. The SDKs of the PLCs are dependent on which type of PLC you have, which makes integration tough. MTConnect linked with Randy Armstrong from the OPC Foundation - but he is now a consultant these days.
OPC has traditionally been a window of access to PLC data, but control information may be possible to access - but it can be limited and case specific. MTConnect should look into this to address the process industry including automotive which often bridges the CNC/PLC technologies. PLCs are embedded into CNCs, but they are often used in conjunction with discrete manufacturing so addressing this market will make sense. Also the process world has a host of well developed software applications that can be leveraged with MTConnect.
OPC UA uses XML and runs out of the controller these days, rather than leveraging the external DCOMM market so it is a natural fit with MTConnect and the XML schema it is based upon. Legacy integration may also be aided here. Call for interest by Dave Edstrom (MTConnect Chair) - time, money, expertise...
Session 2 - Mobile Assets Group
Major changes for Ver 1.3 include the inclusion of the Cutting Tool Archetype.
Points included:
- protocol enhancement to support a lighter framework for actual usage in the field
- retention knob detail
- material removal
- tool (asset) location information
Archetypes vs. Instances
The Archytype contains the static information that is the same for the entire class of tools. This is information from tool libraries. The Archetype is an abstract tool. The Cutting Tool (instance) contains the life cycle data for the physical tool. This will correspond to a single assembly with ID, life cycle data etc - hard data from a specific tool.
The need to represent Cutting Tool Data when information about individual assemblies is not present. Archetype has the same structure as the Cutting Tool except for the following:
- status
- tool life
- CuttingItemLife
- measured values will be only nominal values
Cutting Tool (instance) has the CuttingToolDefintion now deprecated - it can only be used in a Cutting Tool Archetype.
ISO 13399 Part 28 XML (versus Schema is in EXPRESS format as represented in Part 21) is the ISO standard for tool definitions.
A machine tool may only know the following:
- asset ID
- Location
- Length & Diameter
- Time in Use
Separating the Archetype allows for a much lighter data package - better for RFID.
Asset Removal
- an asset can now be removed from the agent
- the assets are marked as removed, so that they can still be accessed
- an AssetRemoved event is sent when the asset is removed
- an application can request the agent provides both removed and active
assets using the "removed=true" URL argument
- when an asset is removed it is not moved to the front if the MRU list
- an attribute has been added to the Asset as well as any sub-type of Asset (like cutting tool)
- helps with tracking
Retention Knobs and Locations
- part of manufacturing process no currently covered in ISO13399 standard
- process specific information needed to be added to MTConnect
- tool location needs to be addressed - carousel on the CNC, racks, carts, bleachers, cribs etc...
Questions From The Floor
What about work holding?
Can this asset group handle people resources - or where does this resource fit?
Session 3 - Accessory Equipment & Inter-Device Connectivity
Started with bar feeder integration - simplified interface model with minimal changes to MTConnect. There are Open Source tools available for implementation, Two successful proof-of-concept implementation with y LNS/Mazak and EDGE/OKUMA.
Right now the Legacy Digital IO Protocol is used there - 10-16 I/O points needed - but limited. Current model is Read/Write by the bar feeder to the CNC. The MTConnect model is passing data, not bits. We need a common vocabulary for all vendors. Make a less brittle interface (to "Future-Proof" yourself) by decoupling from the decoupling from the static register mapping. MTConnect supports "near-real-time" data monitoring. The protocol supports report by exception to optimize resources - using the MTConnect push protocol with a request at 0 milliseconds - send when a change occurs in other words.
MTConnect provides a higher degree of failure detection:
- Heartbeats on all communications
- Immediate detection of failure
- Real-time push protocol - with minimal overhead, only get what you need when it changes
MTConnect is self-healing - states asserted once connection is re-established.
Simplified Interface
- moved away from new category of data item - using events with CDATA indicating state;
- moved all data describing the Stock into the Assets model:
- Now we don't have to create a lot of additional data items that will have static values for a given piece of bar stock;
- It creates a richer document model for representing bar stock;
- It will be synchronized with work done in the Parts Group
- It has a small delta to existing specification
- there was no performance or reliability degradation using MTConnect here
Benefits
Rich data means better decision making - better monitoring, better use of stock, better scheduling and processing, better (and easier) integration, tunable failure detection, less downtime, etc...
Neil Desrosiers from Mazak shared that the benefits of MTConnect far outweighs the costs and that customers have already enjoyed the additional data available in additional to the legacy I/O interface. customers want more and MTConnect is the answer to their needs - and it is expandable for the future.
Check out Mazak's MTConnect offering at:
http://www.mazakusa.com/MTConnect/MTConnect_Brochure_7_15_2011_For_Viewing.pdf
And Beyond...
Adding asset monitoring and control of bar feeder manufacturing assets, extend to other factory components:
- robots
- chip conveyors
- high pressure coolant
- pallet systems
- etc...
What is Still Needed?
- MTConnect needs a Discovery Model for MTConnect devices
- SSDP (Simple Service Discovery Protocol) is widely used and could be adopted here
- UPnP or DLNA uses it for service discovery
- All networking issues have been solved
- Many open source implementation are free to use
- Multicast based
- need to work on UUID scheme
- this is really needed
- dynamic, distributed, lower maintenance than LDAP
- limited broadcasts to sub-net which is great using multi-cast
- it routes (and is widely accommodated in current IT paradigm)
---
Stay tuned for the Parts Group Next....
No comments:
Post a Comment