cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

ThingWorx Navigate is now Windchill Navigate Learn More

Leveraging ThingWorx for Unified Namespace (UNS) with Sparkplug B Integration

100% helpful (1/1)

Leveraging ThingWorx for Unified Namespace with Sparkplug B Integration

 

Abstract

 

The industrial IoT (IIoT) landscape demands scalable, interoperable, and real-time data architectures to enable seamless communication across heterogeneous systems. Unified Namespace (UNS) has emerged as a new approach to organizing and contextualizing data in a centralized, hierarchical structure accessible to all devices and applications. This article explores how PTC’s ThingWorx, a leading IIoT platform, can serve as a robust foundation for operationalizing a UNS, with a specific focus on integrating MQTT-based Sparkplug B messaging. Building on the open-source SparkplugB-Edge-SDK provided by the ThingWorx Customer Success team, we demonstrate how ThingWorx can bridge edge devices, industrial systems, and enterprise applications within a UNS framework, delivering real-time visibility, scalability, and operational efficiency.

 

1. Introduction

 

1.1 The Need for Unified Namespace

 

In traditional industrial environments, data silos and protocol disparities hinder operational efficiency and decision-making. A Unified Namespace (UNS) addresses these challenges by providing a single, logical, and hierarchical data structure that serves as a "single source of truth" for all systems. While customers using ThingWorx have been implementing UNS without realizing it, recently when people say UNS, they also associate it with leveraging MQTT with it.  MQTT (Message Queuing Telemetry Transport) as a lightweight messaging protocol, with Sparkplug B enhancing it by adding a standardized topic structure and payload format helps enterprises with a starting point for implementing UNS.

 

 

1.2 ThingWorx: An IIoT Platform for Modern Architectures

 

PTC ThingWorx is a comprehensive IIoT platform designed to model, connect, and manage industrial assets while providing tools for data visualization, analytics, and integration. Its extensible architecture and support for standards like MQTT make it an ideal candidate for operationalizing a UNS. This paper builds on an example implementation, the SparkplugB-Edge-SDK, to illustrate how ThingWorx can operationalize a UNS in real-world scenarios.

 

2. Understanding Unified Namespace and Sparkplug B

 

2.1 Unified Namespace Overview

 

A UNS is a hierarchical naming convention that organizes all data—sensors, machines, processes, and enterprise systems—into a structured, globally accessible namespace. For example, a UNS topic might look like:
FactoryA/Line1/Machine1/Sensor1/Voltage
This structure ensures that data is self-describing, context-rich, and universally interpretable across the enterprise.

 

2.2 Sparkplug B: Enhancing MQTT for Industrial IoT

 

Sparkplug B is an open specification that builds on MQTT to provide a standardized framework for IIoT data exchange. Key features include:

  • Topic Namespace: A predefined structure (e.g., spBv1.0/GroupID/MESSAGE_TYPE/NodeID/DeviceID) for consistent data addressing.
  • State Management: Birth and death certificates to manage device connectivity.
  • Efficient Payloads: Binary encoding via Google Protocol Buffers for compact, high-performance data transfer.

Sparkplug B aligns naturally with UNS by enforcing a structured, interoperable data model suitable for industrial environments.

 

3. ThingWorx and Sparkplug B Integration

 

3.1 The SparkplugB-Edge-SDK

 

PTC offers several connectivity options with Kepware for industrial connectivity providing protocol transformation, and ThingWorx Edge SDKs for custom connectivity in developer friendly languages such as C-SDK, .NET SDK, and Java SDK to connect any asset with ThingWorx natively using WebSocket based AlwaysOn protocol. The SparkplugB-Edge-SDK (source and executable JAR available at https://github.com/thingworx-field-work/SparkplugB-Edge-SDK) is a Java-based component developed using ThingWorx Edge Java SDK. It integrates ThingWorx with Sparkplug B-enabled edge devices, enabling bidirectional communication over MQTT. Key components include:

  • MQTT Client: Connects to an MQTT broker (e.g., Eclipse Mosquitto, HiveMQ) to publish and subscribe to Sparkplug B topics.
  • ThingWorx Edge SDK Integration: Maps Sparkplug B data to ThingWorx entities (Things, Properties, Services).
  • Configuration Flexibility: Supports customizable mappings between Sparkplug B metrics and ThingWorx data models.

This SDK serves as a reference implementation for bridging edge devices with ThingWorx in a UNS context.

 

3.2 Architecture Overview

 

The proposed architecture integrates ThingWorx with a UNS as follows:

  1. Edge Layer: Devices publish data to an MQTT broker using Sparkplug B topics
  2. Broker Layer: An MQTT broker (e.g., Mosquitto) acts as the central hub, routing Sparkplug B messages.
  3. Application Layer: ThingWorx subscribes to the broker, ingests data, and maps it to its internal data model, exposing it via REST APIs, mashups, or analytics.

This layered approach ensures scalability and decoupling of edge and enterprise systems.

atiwari4_0-1746477640230.png

 

 

4. Implementation Details

 

4.1 Setting Up the Environment

 

To implement a UNS with ThingWorx and Sparkplug B:

  1. Deploy an MQTT Broker: Install and configure an MQTT broker (e.g., Mosquitto) to handle Sparkplug B traffic.
  2. Configure the SparkplugB-Edge-SDK:
  3. Model in ThingWorx:
    • Create Thing Templates and Things corresponding to edge devices.
    • Define Properties to mirror Sparkplug B metrics (e.g., Voltage, Temperature, Pressure).

 

4.2 Mapping Sparkplug B to ThingWorx

 

The SDK maps Sparkplug B payloads to ThingWorx entities. For example:

  • Sparkplug Topic: spBv1.0/FactoryA/DDATA/Node1/Device1/Voltage
  • ThingWorx Entity: A Thing named FactoryA_Node1_Device1 with a Property Voltage.

The SDK handles:

  • Data Ingestion: Subscribes to Sparkplug B topics and updates ThingWorx Properties in real time.
  • Event Handling: Processes Birth/Death messages to manage device state in ThingWorx.

 

4.3 Extending the UNS

 

ThingWorx’s extensibility allows the UNS to evolve:

  • Services: Custom services can aggregate or transform data (e.g., calculating averages across a production line).
  • Mashups: Visualize the UNS hierarchy using ThingWorx’s UI tools.
  • Analytics: Integrate with ThingWorx Analytics to derive insights from UNS data.

 

5. Benefits of ThingWorx in a UNS

 

  • Scalability: ThingWorx’s distributed architecture supports thousands of edge devices within a UNS.
  • Interoperability: Seamless integration with edge using Sparkplug B and with different systems using REST API OR OOTB connectors ensures compatibility with diverse industrial protocols and systems.
  • Real-Time Visibility: Immediate data updates enable responsive decision-making.
  • Extensibility: Developers can enhance the UNS with custom logic, integration, and visualizations.

 

6. Case Study: Manufacturing Line Monitoring

 

Consider a factory with multiple production lines. Using the SparkplugB-Edge-SDK:

  1. Edge sensors publish data to spBv1.0/FactoryA/DDATA/Line1/Machine1/ Voltage.
  2. The SDK relays this to ThingWorx, updating the Line1_Machine1 Thing’s Voltage Property.
  3. A ThingWorx mashup displays real-time Voltage (and properties like RPM, Torque/Current, Power Factor, etc.,) across all machines, organized by the UNS hierarchy.
  4. Alerts trigger if Voltage exceed thresholds, demonstrating actionable insights derived from the UNS.

This setup provides a cohesive, scalable monitoring solution.

 

7. Challenges and Considerations

 

  • Network Reliability: MQTT requires a stable connection; ThingWorx’s data storage capabilities can mitigate disruptions.
  • Data Volume: High-frequency updates may strain resources; optimize payload sizes and subscription rates.
  • Security: Secure MQTT with TLS and enforce ThingWorx access controls to protect the UNS.

 

8. Conclusion

 

ThingWorx, offers a powerful platform for operationalizing a Unified Namespace in industrial IoT environments. By leveraging Sparkplug B’s standardized messaging and ThingWorx’s robust data management and visualization capabilities, organizations can achieve a scalable, interoperable, and real-time data architecture. This article provides a high-level blueprint for integrating these technologies, empowering industries to unlock the full potential of their data.

 

9. Road ahead

 

  • ThingWorx already ingests data over MQTT using the MQTT extension, this Sparkplug-edge SDK, Kepware, or via Azure IoT hub, but with IoT Streams capability introduced in ThingWorx v10.0, users will have the ability to send contextualized IoT data for further analysis and intelligence for end to end Industrial Data Management and UNS needs.
  • PTC plans to provide more OOTB capabilities to ingest MQTT data coming into ThingWorx, contextualize it, and make that contextualize data rapidly available over MQTT to other resources at scale. Stay tuned!

 

 

As ThingWorx community members get further along their journey of implementing UNS using ThingWorx, please do not hesitate to provide us your feedback or ask questions in the ThingWorx IoT community.

 

 

 

Cheers,

Ayush Tiwari

Director Product Management, ThingWorx.

 

Was this tip helpful? Yes No
Version history
Last update:
‎May 05, 2025 04:47 PM
Updated by:
12-Amethyst
Contributors