MTConnect in 2016

Two years ago, when my research into MTConnect began, the landscape of industrial data collection was far different than it is today. There were a few Amazon, Google, Salesforce, IBM type companies driving deliverables online with a very small percentage profiting from the often large investments in data centers, and programming. Now, all industries from your local grocery store, banks and high tech startups are all driving to a singular goal, drive customer interaction online as either self-directed or end point delivered. Not only has the value in owning data been realized, but the costs in not owning data are being recognized. The need for large data viaducts, flexible processing power, and reliable, responsive data storage all while being instantly scalable created a business in cloud computing, and evolved many services to capitalize on business opportunity and necessity. Revisiting MTConnect today reveals a different use case than even two years ago.

The influx of switchboard applications such as nifi, fluentd, and flume has diminished the requirement for standards in machine interconnection. Almost any protocol can be made interoperable with any other protocol. Moreover, industry specific standards are now detraction from the myriad of possibilities for data analytics and big data logistics freely available to everyone as open source projects. MTConnect should now be recognized as an on premise connector rather than an end to end solution. This model is far more suited to modern business intelligence than a proprietary MTConnect endpoint. Importantly, MTConnect could then be looked at as the ‘universal’ adapter for IIoT to BI property because of its interoperability with nifi, fluentd and flume, etc.

Even though the standardization through the use of a schema is depreciated, many parts of MTConnect serve a solid anchor to base extract, transform and load (ETL) operations from. Specifically, the state buffer created by the MTConnect agent greatly reduces the data throughput required. Additionally, the trapped ‘UNAVAILABLE’ state assists with tristate data that can be on/off/unknown. Furthermore, through the implementation of XSLT stylesheets available to implement in MTConnect; JSON as well as the native XML are available for consumption to upstream processes greatly simplifying the ingress of data from shop floor to cloud infrastructure.

Most certainly, the driving factor behind using MTConnect in shop floor monitoring is no longer the standardization to a communication protocol. Instead, the decision made long ago to open source the reference material will carry far more weight, as the race to data dominance ends in one place… at the bottom.