HighByte Blog
|
Read company updates and our technology viewpoints here.
|
|
Time to read: 8 minutes  Posted by Jeffrey Schroeder 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  Posted by John Harrington 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 Posted by John Harrington 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: Time to read: 7 minutes  Posted by Torey Penrod-Cambra For the past several months, 55 beta testers in 13 countries have been kicking the tires on HighByte Intelligence Hub version 3.0 and generously providing their feedback. Today, I’m excited to announce this major release is now available.
Version 3.0 is a step change for the Intelligence Hub and for the Industrial DataOps market. It raises the bar for what a DataOps solution can be at Enterprise scale. It introduces a powerful new Pipelines builder to curate complex data pipelines. It makes the often-vague concept of the Unified Namespace (UNS) tangible and achievable with an embedded MQTT broker—reducing additional software, cost, and administration overhead for our customers. I sat down with HighByte Chief Product Officer John Harrington to talk about some of these advancements available in Version 3.0, including Pipelines. His thoughts are below. I also provide insights from our partner Goodtech, a deep dive on the embedded broker, a review of new project management capabilities, and more. |
