Getting Started
How it works
The MTConnect standard defines data tags and the behavior of a software agent.
Device manufacturers each use their own vocabulary. The standard is a normalized semantic vocabulary and information model that doesn’t vary by manufacturer. Translation from native vocabulary to the standard is done by a software adapter running on the device or on peripheral hardware. An MTConnect agent aggregates and serves data in a machine-readable format.
An agent usually runs at the device, on a server, or on peripheral hardware, but many other configurations are possible.
What it’s used for
Machines, controls, etc. that support the MTConnect standard provide universal data item definitions that are always the same regardless of manufacturer. The standard only specifies data definitions, schema, and rules for how an agent must operate.
This data is consumed by a wide variety of commercial and freeware software applications for things like machine monitoring (utilization, OEE), lights-out manufacturing, job scheduling, process analytics, predictive maintenance, and so on.
How to get it
Current and archive releases of the spec are free and publicly available, housed at and maintained by the MTConnect Institute. www.mtconnect.org/documents
Free, open source developer tools are on GitHub and community-maintained. github.com/mtconnect/
For machine builders
Devices require a software adapter to translate native registers/data tags to the vocabulary defined in the MTConnect spec. Adapters are developed in-house, by control builders, or by third parties.
A complete implementation of MTConnect also requires an agent working as defined in the spec. A free, open source agent in C++ is widely deployed.
See GitHub for an adapter framework and examples, the C++ agent, and many other developer tools.
For systems integrators
MTConnect reduces the expense of data acquisition, translation, and connectivity. Source adapters from equipment suppliers, third parties, or develop them in-house.
Many builders ship machines with an adapter and agent already installed. Some software vendors develop their own adapters or source them. Most have preferred network architectures and configurations for MTConnect components.
For developers
Devices that support MTConnect output data in XML via HTTP server as defined in Part 1 of the spec. A minimally valid implementation must report availability; the number of tags supported on a device varies widely by builder, model, vintage, and adapter developer.
Many developers offer both software and connectivity, in effect serving as both developer and system integrator. Some sell only software and rely on the customer or partners for system integration and device connectivity.
See GitHub for extensive developer tools. See agent.mtconnect.org for live sample data courtesy of NIST.
For shops
Device connectivity can be its own project, or part of a wider software deployment. The vast majority of MTConnect users will only access their device data via another application (OEE software, MES, etc.).
Outfitting a factory with MTConnect can be done in-house with sufficient developer and IT skills, fully outsourced, or some combination.
Supported Devices
MTConnect compatibility varies by vendor and product line. Specific connectivity options, configuration requirements, and number/type of data items supported will vary by device make, model, year, and selected options. There are solutions available for both new devices and retrofits.
The MTConnect standard is open and free-to-use for anyone; not every implementation is publicly documented. See a partial list at www.mtconnect.org/devices.
Integrators
With in-house IT, programming, and project management resources available, an MTConnect implementation can be installed from the ground up. In most cases, though, partnering with system integrators on all or part of an MTConnect implementation is likely faster or more cost-effective.
See a partial list of companies at www.mtconnect.org/integrators.
———