Bringing Condition-Based Monitoring into the Unified Namespace: A Practical Approach

After an exciting week at #ICCbreakthrough, I couldn't help but notice how much more mainstream the #UnifiedNamespace (#UNS) has become. As a 4.0 community and advisory board member, it's fantastic to see how Walker Reynolds & 4.0 Solutions have generated growth around the concept and created a thriving community. Everyone is talking about UNS, and that's a good thing—even if interpretations may be varied and diverse. After leaving the conference, it struck me that more conversations about use cases are needed. So here we go. Please bear with me; writing is not my strong suit, but I'm interested in pushing my boundaries. Hopefully, some of you will find this useful. If this conversation is new to you then Check out the material at 4.0 Solutions to become familiar with the material. Thanks to Dylan DuFresne a fellow community member for feedback on this one. I hope to write more expanding out discussion on use cases and adjacent topics like data modeling, knowledge capture and other digital topics tying back to factory operations.

Understanding Condition-Based Monitoring

Condition-Based Monitoring (CBM) is a proactive maintenance strategy that monitors the actual condition of assets to decide what maintenance needs to be done. Instead of following a fixed schedule, maintenance is performed when indicators show signs of decreasing performance or impending failure. This approach not only extends the life of equipment but also prevents unexpected downtime.

So why should you care? Because integrating CBM into your operations can significantly enhance efficiency, reduce costs, and improve overall productivity.

Embarking on the journey of condition-based monitoring is simpler than you might think. You don't need to invest in yet another domain-tailored Software as a Service (SaaS) offering or commit to a specific vendor's technology. It's about finding the right fit for your needs. Most applications rarely need in-depth analysis of nth-order harmonics, contrary to what many point solution providers would like end-users to believe. Sometimes, just having adequate data and applying basic statistical techniques solves 80% of vibration monitoring applications. I'll save my rants on how machine learning is often just applied statistics and how marketers hype it up as the solution to all other solutions.

We seem to be living in an age of death by a thousand subscription fees. As software vendors have shifted to subscription-based licensing, coupled with an explosion of narrow domain-based software solutions coming to the market—some centered around CBM—organizations are now taxing their operations with escalating OPEX costs. While this may be viewed as a balance sheet rounding error for large-cap companies, being selective in where you spend your OPEX dollars as a small-cap can be a sensitive issue.

This is largely why I am a massive advocate of the Unified Namespace design philosophy. Its open architecture and data-as-a-first-class-citizen approach set the stage to optimize operational costs, negating the need for all of these boutique domain solutions. One of the fundamental philosophies in executing digital transformation using UNS principles is that the overall value gained by digitally transforming should be greater than the sum of all the parts or iterations in the journey.

Condition-based monitoring sensors should seamlessly integrate into your systems, like pieces of Lego that effortlessly lock into other components of your digital infrastructure. Integration should be guided by a digital strategy rooted in fundamental principles.

Leveraging I/O-Link and MQTT with the Unified Namespace

Enter technologies like I/O-Link and MQTT, which can help when leveraged with concepts like the Unified Namespace, utilizing a capable IIoT platform.

Pictured above is an IFM AL1322 I/O-Link master with a Balluff BCM-00001 3-Axis Vibration sensor with integrated contact temperature. As a special bonus, the unit with the big green light is a Bluetooth module that can be used to commission sensors in the field with your smartphone. The master costs approximately $500 CAD and can support up to 8 I/O-Link capable sensors. The Balluff vibration sensor costs around the same. No subscription fees and ready to publish data into your infrastructure upon connection.

The I/O-Link master has two communication ports for interfacing systems. One is an EtherNet/IP fieldbus capable of connecting to EtherNet/IP-capable masters—but let's face it, you know we're connecting it to a Rockwell Logix controller. The second port is a standard IP port that hosts the master's IoT API and can produce MQTT protocol messages to available brokers connected to the port or accept HTTP REST calls.

Note: While this article focuses on I/O-Link and MQTT, they are not the only foundational technologies that can be employed in a Unified Namespace architecture. Other technologies and protocols can also meet the Minimum Technical Requirements (MTRs) essential for a successful UNS implementation.

Foundational Technologies and Minimum Technical Requirements

The Unified Namespace isn't tied to specific technologies; rather, it's built upon key Minimum Technical Requirements (MTRs) that ensure seamless integration and interoperability:

• Open Architecture: Systems should be designed using open standards to facilitate interoperability and avoid vendor lock-in.
• Lightweight Protocols: Efficient data transfer protocols minimize bandwidth usage and improve performance.
• Report by Exception: Systems should communicate only when there is a change in data, reducing unnecessary network traffic.
• Edge-Driven: Data processing should occur at the edge (closer to the source) to reduce latency and improve responsiveness.

By adhering to these MTRs, organizations can build a flexible and robust UNS that accommodates a variety of technologies beyond just I/O-Link and MQTT.

Understanding I/O-Link's Universal Approach

I/O-Link is an industry-standard wire protocol used by all major sensor manufacturers within the automation industry, including vendors such as IFM, Balluff, Keyence, Sick, and hundreds of others. For me, I/O-Link is the closest thing the automation industry has to a USB port on a computer. If you're unfamiliar with I/O-Link, it's best to start here to get educated.

Because of I/O-Link's universal approach, we can mix and match vendor sensors with other vendors' I/O-Link masters to connect and collect data. If Vendor A has a better purpose-built sensor than Vendor B, I can still connect Vendor A's sensor to my I/O-Link master that happens to be from Vendor C.

From Wikipedia on IODD:

"I/O-Link device manufacturers are required to publish an IODD file containing information about the device's identity, parameters, process data, diagnosis data, communication properties, and the design of the user interface of engineering tools. The IODD comprises different data files: the main file and several optional language files are in XML format, and optional graphical files are in PNG format."

Because of the universal approach adopted by I/O-Link, we can now build the required intelligence into our data operations pipelines and IIoT platforms to autonomously map new devices just by plugging sensors in.

How Does UNS Play into This Discussion?

Well, if I arbitrarily plug a new sensor into an open port on an I/O-Link master, my IIoT platform could monitor for new devices. An alert or workflow can be generated to onboard a new instance of a particular device profile. Data operations can map the sensor's namespace into the Unified Namespace structure, which now has additional context.

Before, we may have had a structure that looked like this in some sort of OPC or MQTT namespace, simplified for explanation:

Mixer 001 Motor

• RPM: 1750
• Voltage: 224 V
• Current: 12.2 A

Now, ideally in a Pub/Sub architecture, we have:

Mixer 001 Motor

• RPM: 1750
• Voltage: 224 V
• Current: 12.2 A
• Vibration Velocity RMS X: 0.35 mm/s
• Vibration Velocity RMS Y: 0.23 mm/s
• Vibration Velocity RMS Z: 0.05 mm/s
• Contact Temperature: 38 °C

Note: This is a simplified example to illustrate the concept. In practice, individual models can be tailored to meet specific user requirements, including additional parameters or different structures within the namespace.

The IIoT platform also provides alarming and notification functionality for configured data points. Once the sensors are onboarded, alarm limits can be set and notification profiles enabled to alert plant personnel whenever a data point exceeds the configured limits.

Expanding Possibilities with the UNS Concept

Aside from data mapping to gain better contextualization, we now have various options due to the nature of the UNS concept. If this data is being published into an MQTT broker using a hierarchical unified structure, subscribing nodes or other software solutions can access this data. Those subscribing nodes could publish data to local data stores or hyperscaler services like Snowflake, Kinesis, or Redis. They could also provide a subset of data for consumption in other ecosystem applications like MES, CMMS, ERP, WMS, and others.

In this specific case of condition-based monitoring, the UNS provides organized, clean, contextualized data ready for normalization & consumption in higher-level machine learning algorithms, when basic statistics fall short of solving the problem at hand. It fundamentally sets end-users up for success far better than other architectural approaches.

So Why Is This Important?

Why go through the detailed explanation to get here? I've seen so many times where we become so solution-centered that we fail to achieve these architectural patterns. We end up investing in point solutions that invariably create additional data silos, which then have to be cobbled back together like Frankenstein's monster. This is the beauty of leveraging emerging technologies and using a data-centric approach to infrastructure design.

The inherent problem with point solutions is they tend to be proprietary and do not follow the open architecture principles we teach within the community. Many of the CBM solutions applicable to this discussion require you to use their sensors that communicate back to their home base in their cloud. If you're lucky, they have a modern API where you can at least bring the data back into your environment. This is as far from unified as it gets.

For those who are of the opinion that it can all be fixed in the data lake/swamp—this article is not for you. Some of the cases I've heard in my lifetime are borderline insanity, yet it continues to happen every day. In a Unified Namespace architecture, solutions are developed around a common framework. All solutions have access to the same infrastructure, and all solutions should publish back into the infrastructure, creating additional context when applicable.

In Conclusion

Embracing a Unified Namespace and leveraging universal protocols like I/O-Link and MQTT isn't just a technical preference—it's a strategic imperative for modern industrial operations. By adopting these open and interoperable technologies and adhering to the Minimum Technical Requirements (MTRs)—Open Architecture, Lightweight Protocols, Report by Exception, and Edge-Driven principles—we empower our systems to be more adaptable, scalable, and future-proof.

We move away from vendor lock-in and the pitfalls of fragmented data silos, steering instead toward a cohesive, data-centric infrastructure that can evolve with our needs. The real beauty lies in the simplicity and efficiency this approach brings. Adding new sensors, devices, domains or platforms becomes a plug-and-play experience, reducing downtime and integration costs. It allows us to focus on deriving actionable insights from our data rather than wrestling with incompatible systems.

So, as we continue to navigate the complexities of Industry 4.0, let's prioritize solutions that promote openness and interoperability. Let's invest in architectures that not only meet our current needs but also position us to capitalize on future technological advancements. After all, the goal isn't just to keep up with industry trends—it's to set ourselves up for long-term success by building flexible, resilient systems that can adapt to whatever comes next.

Feel free to share your thoughts or experiences with implementing a Unified Namespace or leveraging I/O-Link, MQTT or other technologies in your operations. Let's keep the conversation going!