What is MTConnect?

MTConnect is the communication standard of choice for manufacturing. It allows organized retrieval of data from shop floor equipment in a structured XML.

The adjacent diagram depicts the key components of MTConnect. Let us start with the shop floor equipment shown at the bottom of the diagram – a CNC lathe.  Above that, we have an optional adapter component that converts machine-specific data into a MTConnect defined format. The adapter component is optional as most manufacturers are building this capability directly into their machines.  On the top is the agent component responsible for converting MTConnect data into XML. Additionally the agent also exposes a RESTful service that can be used to retrieve data.

MTConnect and Azure IoT

With the recent emphasis on Internet of Things (IoT) and Machine Learning (ML), manufacturing companies want to retrieve MTConnect data from a large number of machines on the shop floor and then use ML algorithms on the collected data. The goal is to use ML to optimize the efficiency of the shop floor machines. This is where the Azure platform with services such as Azure ML, IoT Hub and SQL can come in handy.

So how do we transport the data from the MTConnect agent to Azure? The easiest approach is to place a driver program, alongside the agent, that periodically calls the MTConnect REST API and sends the data to Azure via IoT Hub. This incoming data can then be processed using Stream Analytics and placed in Azure Blog storage.

Unfortunately, as we found out on a recent project, hosting the aforementioned driver program on-premises comes with its own set of challenges. Shop floor infrastructure is typically constrained – both in terms of infrastructure resources that are available and the flexibility to choose tools and languages. Additionally, the management of a driver program (installation, monitoring and updates) becomes a challenge as it needs coordination with the teams managing the shop floor network. All of these are impediments to the seamlessness offered by the rest of back-end Azure Services like IoT Hub, Azure ML and Stream Analytics.

This led us to refactor our approach for the driver program. We moved the driver program to Azure (as depicted in the diagram above). Moving the driver program to Azure allows us to host it within a cost-effective compute capability like WebJobs (versus paying for a dedicated VM). WebJobs allow for running a batch program or a script. Using the WebJobs SDK we developed the driver program to invoke the MTConnect REST API.

Of course the agent is behind the firewall. So how does the Webjob access it? This is where the Hybrid Connections service of Azure comes in. It provides an easy and convenient way to connect the WebJobs to on-premises resource (in our case, the MTConnect Agent) behind your firewall.

The code for the WebJobs driver program is available here.