HighByte Blog
Read company updates and our technology viewpoints here.
|
Read company updates and our technology viewpoints here.
|
Time to read: 10 minutes One of the most common concerns I hear regarding the Unified Namespace (UNS) is the architecture lacks the versatility needed to address diverse downstream data consumers. Suppose quality, maintenance, and process engineers are all doing their part to support a production line. Quality teams need inspection results, maintenance teams need asset performance data, and process engineers need lot and process parameters. The teams need data sets that both overlap and differ by use case. These engineers are using different applications and services—anything from ERP modules for quality and maintenance to specialized ML platforms in the cloud—that each require very different data structures. Many of these applications and services do not easily interoperate with the UNS and its architectural conventions. They may not natively interface with MQTT brokers, nor should one expect them to. They may not consume payloads that were oriented around rigid asset hierarchy and publishing telemetry data from process control nodes. They may have completely different needs than what was envisioned when factory automation was installed and integrated. Their data needs can transcend how the UNS was initially architected and organized. HighByte Intelligence Hub can overcome these challenges. Through data modeling and pipelines, the Intelligence Hub enables the full potential of the UNS, delivering contextualized manufacturing data to the cloud. Let’s look at a sample architecture to see how. Time to read: 9 minutes In an earlier blog, “The power of payloads in your unified namespace,” I discussed the use of complex payloads combining multiple unified namespace (UNS) data streams to make the architecture more responsive to the diverse needs of consuming personas and systems. In this post, I want to show what these complex payloads might look like, how data models can enable a UNS architecture, and how easily HighByte Intelligence Hub can provide consuming systems with the necessary data—when and how it’s needed. Time to read: 8 minutes For quite some time, people have been asking us how the Intelligence Hub relates to a Unified Namespace (UNS). Is it a specific part of a UNS architecture, a platform by which one might build a UNS, or a UNS architecture itself? Over time, our answers have developed alongside the capabilities of the Intelligence Hub. From the beginning, the Intelligence Hub could connect to third-party MQTT brokers as well as model the data going in and out of them. And recently, we added an embedded MQTT broker to the Intelligence Hub to address brokering and provide the ability for MQTT clients to connect to the Intelligence Hub directly. These provided the functionality needed for much of what might facilitate or be considered a UNS, but it was missing a critical part: a way to visualize the contents. Time to read: 7 minutes The Unified Namespace (UNS) architecture pattern has proven to be an effective means to opening industrial data access up to the entire business, but the road to implementation is not without a few speed bumps. First, as industrial companies start to establish their hierarchy and build their UNS, they may find it difficult to get their data to follow their own rules. By its nature, UNS architecture draws from a multitude of different data sources, most of which present data in unique formats. Even superficially similar assets can format the data they generate in completely unique ways, and differences in data generated by wholly different machines, systems, and PLCs are even more stark. To limit problems in creating and operating a UNS, some industrial companies simply publish data from each system and device directly to an MQTT broker in their own topic namespace. This practice is not truly a UNS, and it offers little of the data accessibility and usability promised by this architectural pattern. Second, the UNS topic space typically follows the hierarchy: Site, Area, Line, Zone, Cell, and Asset. At each level, the information may include data from multiple systems including PLCs, SCADA, MES, CMMS, QMS, ERP, etc. On the consuming side, many users have unique needs that the UNS alone may not be able to meet. These challenges are what make consistent, easily scalable abstraction a critical part of your UNS. Time to read: 7 minutes The Unified Namespace (UNS) is among the fastest-growing data architecture patterns for Industry 4.0, promising easy publish-subscribe access to hierarchically structured industrial data. At HighByte, we define a UNS as a consolidated, abstracted structure by which all business applications can consume real-time industrial data in a consistent manner. A UNS allows you to combine multiple values into a single, structured logical model that can be understood by business users across the enterprise to make real-time decisions. But many industrials are finding that though they’ve loaded their device telemetry data in their UNS, they are struggling to use it. The UNS’ uniform data standards, hierarchical structure, and publish-subscribe pattern do an excellent job of providing easy, logical access to data, but business and analytics users often discover that they must subscribe to multiple data streams from separate levels of the hierarchy to get what they need for their applications. There are two problems with this approach: |
|