The Vocabulary Behind The Visibility

The vision of a “smart” digital factory where machines and processes are networked and managed using data and advanced IT (IoT, AI, cloud). It enables real-time decision-making, greater automation and agility, and better quality/output. For example, IBM notes Industry 4.0 (“smart manufacturing”) uses IoT sensors, cloud and analytics to transform production, improving defect detection by ~50% and yield by ~20%. Industry 4.0 leads to higher uptime and efficiency by combining shop-floor data with enterprise data for visibility and predictive insights.

Using digital technologies (IIoT devices, AI, analytics, cloud) to make manufacturing more efficient and flexible. Smart factories use advanced sensors and robotics to collect and analyze data for process optimization, maintenance and responsiveness. As IBM explains, smart factories leverage IoT and analytics to optimize operations and maintenance, reducing errors and costs.

The application of IoT concepts to industry. IIoT deploys connected sensors and devices on equipment and lines to monitor operations and feed data into IT systems. IIoT underpins smart manufacturing by providing the data needed for analytics, digital twins and other applications.

The integration of traditional operational technology (OT) systems (PLCs, DCS, SCADA, sensors) with IT systems (enterprise networks, cloud, analytics). The goal is seamless data flow from the plant floor to business and analytics systems. Convergence lets plant devices use TCP/IP networks and modern protocols to send data to central systems for analysis and control. As one source explains, IT/OT convergence “seeks to bring physical OT equipment into the digital IT realm” – for example by fitting machines with IoT sensors and sending real-time data back for analysis, enabling more autonomous operation and improved maintenance. Convergence improves efficiency, reduces downtime and enables data-driven decision-making.

A digital twin is a virtual model of a physical asset, process or system. In manufacturing, a twin lets you simulate and analyze equipment or processes without touching the physical machine. For example, a pump or entire production line can have a “twin” fed by sensor data; engineers can test changes or run predictions on the twin. This helps with predictive maintenance and optimization: the twin can predict failures and suggest fixes before real downtime occurs. In practice, digital twins enable predictive maintenance and yield/energy optimization, driving down maintenance costs and increasing uptime.

A single hierarchical address space or “data dictionary” for all plant data. In an UNS architecture, every data point from OT systems (PLCs, sensors, historians) is published into one common namespace. This becomes a “single source of truth” for data, so all applications (MES, analytics, visualization) can use consistent data identifiers. A unified namespace ensures data is classified, structured and accessible consistently across the enterprise. (Matrikon’s Unified OT Data Layer extends this concept by adding modeling and secure connectivity on top of a UNS.)

Matrikon’s term for an enterprise-wide data architecture that integrates OT data across all layers of a company. UODL encompasses a unified namespace plus tools for data modeling, mapping and secure bridging of OT and IT networks. In effect, UODL is a strategy where all OT data (from PLCs, SCADA, historians, etc.) is made seamlessly available to any authorized user or system enterprise-wide. Matrikon’s Data Broker is designed to help build a UODL, providing a single point for federating diverse data sources and sharing them across departments.

A term Matrikon uses for next-generation OT/IT software (like the Matrikon Data Broker) that bridges the gap between industrial control data and enterprise needs. Data Technology covers functionality such as standardized connectivity, semantic data modeling, secure communication and integration. Matrikon defines DT as the functionality needed by modern OT/IT-aware software to meet both sides’ requirements, filling the long-standing void between plant controls and business systems and bridging the IT/OT Gap.

Matrikon’s flagship software platform for OT data integration. It connects to many OT data sources (PLCs, SCADA systems, historians, etc.) and provides a single, secure service for enterprise applications. MDB uses open standards like OPC UA and MQTT under the hood to overcome connectivity challenges and IT/OT silos. It supports OPC UA data modeling and mapping via a GUI, and can run on Windows or as a Linux container. (See “Matrikon Technologies” below for more MDB components.)

The ability to connect to external or legacy systems and devices (for example PLCs, DCS, SCADA, databases, historians or external APIs). In practice, it means using protocol drivers or adapters (OPC servers, MQTT bridges, etc.) to bring in data from equipment made by many vendors. Matrikon addresses 3rd-party connectivity by providing OPC UA Servers (also called adapters) for hundreds of industrial data sources, and by allowing MDB to federate all these data sources through one interface. This lets companies funnel high volumes of data from many sources via a single connection, simplifying architecture and reducing duplicate connections.

A ruggedized industrial computer used to control machinery and processes. PLCs read inputs from sensors or switches, execute programmed logic, and drive outputs to actuators. They form the basic automation controllers on a factory floor. PLCs often communicate with higher-level systems via OPC or native industrial protocols

Software and hardware for centralized monitoring and control of industrial processes. A SCADA system collects real-time data from field devices (PLCs, RTUs, sensors) and displays it on dashboards or HMIs for operators. It can also send control commands back to equipment. SCADA improves visibility and efficiency: for example, if a machine shows anomalies, the system can alert operators to intervene and prevent loss. In short, SCADA “allows organizations to control and monitor industrial processes by interfacing with plant-floor machinery and viewing real-time data.” Modern SCADA often uses OPC UA or MQTT to aggregate data from diverse devices.

The graphical interface (screens, dashboards) through which operators interact with a machine or process. HMIs display real-time data, trends and status, and allow control commands. They are essentially user interfaces (often touchscreen panels or SCADA graphical screens) for the plant floor. For example, an HMI might show a tank level or conveyor speed, and let an operator adjust controls. As one resource explains, an HMI “connects a person to a machine, system or device” and is commonly used in industrial processes to display data and controls. Matrikon’s solutions feed HMI/SCADA software by providing the underlying OPC UA or MQTT data.

The older (pre-UA) OPC standards for data exchange on Windows. OPC Classic includes sub-protocols like OPC Data Access (DA) for real-time values, OPC Alarms & Events (A&E), and OPC Historical Data Access (HDA). All of these use Microsoft’s COM/DCOM technology for communication, which ties them to Windows and requires complex configuration. OPC Classic is widely deployed in legacy plants, but it has well-known security and connectivity limitations: DCOM traffic is hard to secure and firewall-traverse. (For example, newer Windows patches may break OPC DA clients.) Because of this, OPC Classic is often used only on tightly controlled intranets.

A Microsoft protocol used by OPC Classic. It allows remote procedure calls between software components on different Windows machines. However, DCOM is notoriously insecure and firewall-unfriendly: it involves dynamic TCP ports and cannot easily traverse firewalls. In practice, using DCOM means exposing many inbound ports, which is a security risk. Because of DCOM’s drawbacks (and Microsoft’s phasing it out), OPC Classic is gradually being replaced by OPC UA. Matrikon addresses DCOM’s limitations by offering OPC-to-UA bridging: its OPCtoUA MDB Adapter converts legacy OPC DA/HDA servers into OPC UA endpoints, bypassing DCOM. For example, Matrikon’s OPC UA Server for Modbus (MDB Adapter) runs natively on Windows/Linux and avoids DCOM altogether.

The modern, platform-independent OPC standard. OPC UA is a service-oriented architecture that combines all the OPC Classic features into one extensible framework. Unlike Classic, OPC UA does not rely on Windows DCOM: it works on any OS (Windows, Linux, etc.) and supports binary or XML/JSON over TCP or HTTP, which are firewall-friendly. OPC UA adds much more: it has a rich information model (typed data and hierarchies), built-in discovery, subscriptions and eventing, and strong security (encryption, authentication, signing). In summary, OPC UA is “functionally equivalent to OPC Classic, yet capable of much more.” It supports complex data types, methods, and fine-grained access control. Because of these advantages, OPC UA is the recommended long-term standard for enterprise-wide OT systems. (However, migrating from OPC Classic may require bridges/adapters as noted above.)

An OPC UA extension for asynchronous data distribution. In addition to the classic client–server model, OPC UA now includes a Pub/Sub model, where publishers send messages to a message broker or via multicast (including MQTT or UDP). This allows efficient broadcasting of data changes to many subscribers. OPC UA Pub/Sub is used for high-volume real-time data streaming. (Matrikon’s Data Broker can take OPC UA data and publish it via MQTT brokers, effectively supporting pub/sub.)

An OPC Foundation standard that defines industry- or domain-specific data models on top of OPC UA. Companion Specs use OPC UA’s information modeling to describe objects, variables and types for a particular field (e.g. PLCopen for motion control, ISA-95 for factory data models, MTConnect for manufacturing data, etc.). They ensure interoperability of data semantics across different vendors. Matrikon’s Data Broker supports importing OPC UA companion spec files via drag-and-drop and mapping data to those semantic models.

A Matrikon adapter that modernizes OPC Classic data. It connects to legacy OPC DA/HDA servers and republishes their data as OPC UA. This removes the need for DCOM and allows older devices to join a UA-based architecture. The OPCtoUA MDB Adapter runs on Windows or Linux and becomes an OPC UA Server for Classic data.

A lightweight publish/subscribe messaging protocol designed for IoT. MQTT uses a central broker: devices (publishers) send data to the broker under certain topics, and applications (subscribers) receive updates for topics they subscribe to. MQTT is extremely simple and efficient for low-bandwidth or high-latency networks. In IIoT, MQTT lets edge devices push data to cloud or central systems. (Matrikon offers an MQTT Publisher extension that takes data from MDB and sends it to an external MQTT broker.)

A specification on top of MQTT for industrial applications. Sparkplug defines a common topic namespace and payload format for MQTT so that different OT devices and systems can interoperate without custom coding. It adds features like automatic discovery and state management to basic MQTT. In practice, Sparkplug B ensures that an MQTT message carries full context (device metadata, payload, state). As one source puts it, “Sparkplug is an open standard that uses MQTT to specify how all system components… communicate through an MQTT broker.” Sparkplug greatly simplifies integrating legacy devices with MQTT brokers. Matrikon’s Data Broker can publish OPC UA data in MQTT-friendly formats, facilitating Sparkplug-based architectures.

An architectural style for web APIs using standard HTTP. RESTful systems expose “resources” (data objects) via URLs; clients GET, POST, PUT, DELETE to interact. REST is stateless and widely used for integrating systems. For example, many IoT and cloud services provide REST APIs for data access. In OT/IT integration, REST APIs let IT applications retrieve plant data or send commands. We define REST as “an architectural style for developing web services… to easily communicate with each other” using HTTP operations on resources.

Common field-level communication standards:

• Modbus (RTU/TCP): A simple, open protocol often used on serial (RTU) or Ethernet.
• PROFIBUS/PROFINET: German standards by Siemens (PROFINET is Ethernet-based, PROFIBUS is older fieldbus).
• EtherNet/IP: An Industrial Ethernet standard by Rockwell/ODVA (uses CIP on Ethernet).
• EtherCAT: A real-time Ethernet protocol often used for motion/control networks.
• CC-Link, CC-Link IE: A Japanese/East-Asian industrial network family (fieldbus and gigabit Ethernet versions).
• HART, ISA100, WirelessHART: Protocols for field instruments and wireless sensors.

Processing and analysis at or near the data source (the “edge” of the network, e.g. on the factory floor) rather than in a central datacenter. Edge computing minimizes latency and bandwidth use by doing some computing close to sensors. For example, an edge gateway might run analytics on sensor data and only send alerts or aggregated results to the cloud. As TechTarget explains, edge computing moves storage and computes out of the central data center “closer to the source of the data itself,” so only valuable results are sent back to headquarters. (See image below: edge servers collect factory data locally while the cloud oversees at a high level.)

A concept related to edge computing, where additional network nodes (like routers or local servers) provide computing between the edge devices and the cloud. Fog computing distributes control and storage closer to where data is produced, often forming a multi-tier architecture (device → edge/fog → cloud). It supports decentralization and can be seen as an extension of edge.

Hosting applications, databases or computing on remote servers (the cloud) instead of on-premises. The cloud offers on-demand scalability and broad network access. According to NIST, cloud computing provides “on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications) that can be rapidly provisioned and released.” In IIoT, factories use cloud services to store/process large data sets, run analytics, or connect globally. For example, AWS IoT SiteWise, Microsoft Azure IoT, and Google Cloud IoT are popular cloud platforms for ingesting plant data. Matrikon Data Broker can send OT data to these clouds: it’s been tested with AWS IoT SiteWise, Azure IoT, Honeywell Forge and others.

Software as a Service (SaaS) offers ready-to-use applications over the internet (e.g. a cloud SCADA or analytic app). Platform as a Service (PaaS) provides a platform (OS, middleware) for customers to deploy their apps. Infrastructure as a Service (IaaS) provides raw computing resources (servers, storage) on demand. Many modern OT/IT integrations use SaaS (e.g. cloud analytics dashboards) so plants can scale without buying servers.

Packaging software in lightweight “containers” (e.g. Docker) that bundle an application with its runtime environment. Containers are portable across servers and boots up quickly. This enables modern deployment practices: for example, Matrikon Data Broker is available as a Linux container, so it can run on any container platform (like Kubernetes). Containerization helps companies easily deploy OT integration software on edge hardware or cloud.

An architectural style where an application is divided into small, independent services communicating over APIs. Each service does one job well. In IIoT, microservices can help scale and update components (e.g. separate services for data acquisition, for analytics, etc.). This contrasts with monolithic software.

Middleware that collects, translates, and routes data between systems. A broker can ingest data from many sources and republish it uniformly. Matrikon Data Broker is an example: it connects to multiple OT systems and provides a single OPC UA endpoint for downstream clients. It effectively acts as an enterprise data hub for OT, federating sources and consolidating connections.

The process of defining how data from different sources corresponds to a common model. Mapping associates raw data points with standardized information models. Modeling defines the structure (types, hierarchy, semantics) of data. Matrikon’s MDB allows users to import OPC UA information models (companion specs) and drag-and-drop map data from multiple sources into those models. This lets businesses work with data in context (e.g. as part of a “pump” or “motor” object) instead of raw tags. Well-defined models and mappings improve understanding and analytics.

Encryption protocols that secure network communication. OPC UA and MQTT both typically run over TLS to encrypt data in transit and authenticate endpoints with certificates. This ensures data from OT devices to enterprise systems cannot be easily intercepted or spoofed. (Matrikon’s products support TLS certificates for secure connections.)

A network firewall controls traffic between trusted (e.g. corporate) and untrusted (e.g. Internet) zones. A DMZ is a demilitarized zone – a separate network (or subnet) that isolates and protects control networks. In OT, it’s best practice to put SCADA/PLCs in an OT zone behind firewalls. However, opening firewall ports for remote data access is risky. Matrikon’s solutions use OPC UA ReverseConnect (FireBridge) to avoid opening inbound ports: the client and server initiate connections outwards, so no open port is needed.

A mechanism where the server (inside the OT network) initiates the connection to the client (in the IT network), allowing secure data exchange without inbound firewall rules. Matrikon calls its implementation “FireBridge”: it establishes cross-firewall OPC UA links without opening ports, a cybersecurity best practice. This lets third-party users connect securely to on-site data (e.g. external consultants can access OPC UA data without direct access to the plant network).

As mentioned, DCOM is being deprecated by Microsoft for security reasons. This affects OPC Classic systems, as Windows now forces strict DCOM authentication by default. The fallout: many older OPC DA/A&E/HDA clients fail. The workaround is to migrate to OPC UA or use tunneling/adapters. Matrikon’s OPCtoUA adapter sidesteps DCOM entirely by converting Classic to UA.

Best-practice frameworks for industrial cybersecurity. The ISA-99 standard (IEC 62443) defines security policies and measures for industrial control networks. Plants should follow IEC 62443 (e.g. network segmentation, access control, monitoring) to protect OT assets. This glossary entry is not a deep dive, but note that OPC UA was designed with IEC 62443 in mind (it provides layered security controls). Matrikon’s secure connectivity features (TLS, ReverseConnect, etc.) help meet these standards.

Using real-time and historical data (often via digital twins and analytics) to predict equipment failures before they happen. By analyzing sensor data patterns, the system can alert maintenance teams to service machines proactively. This reduces unplanned downtime and maintenance costs. For instance, McKinsey notes that asset twins enable predictive maintenance and throughput optimization. Similarly, IBM notes that AI on factory data can predict breakdowns, yielding more uptime and efficiency. Matrikon’s data infrastructure feeds into predictive algorithms by reliably delivering clean OT data.

Algorithms that learn from data to find patterns or make decisions. In the OT context, ML/AI can optimize processes (quality control, yield), detect anomalies, or plan maintenance. For example, analyzing sensor data with ML can reveal subtle trends that humans might miss. Industry 4.0 often combines big data from the plant with AI – IBM points out that AI/ML can leverage factory data (and enterprise data) to automate decisions, like triggering maintenance based on sensor analytics. While glossaries often keep AI/ML high-level, the key is that these tools depend on having the OT data available in the first place (which Matrikon enables).

The collection and analysis of large, diverse data sets to support decision-making. In smart manufacturing, OT data is often streamed to data lakes or analytics platforms where it’s aggregated with business data. Tools like data warehouses or streaming analytics perform real-time and historical analysis. For example, a plant might store all historical sensor logs (big data) and use analytics to detect quality trends. Matrikon’s Data Broker can push data into big data platforms (e.g. via its MQTT extension or cloud connectors) for this purpose.

A measurable value used to evaluate how well a process is performing (e.g. yield rate, energy consumption per unit, uptime percentage). While more of a business term, effective KPIs in manufacturing rely on accurate data collection and integration.

A specialized database for time-series data (e.g. sensor readings, tag values). Historians store high-frequency data and provide retrieval for trend analysis. In modern architectures, historians often feed data into higher-level systems via OPC UA or APIs. Matrikon’s tools can interface with historians (e.g. reading OPC HDA) and include that data in the enterprise layer.

Cloud or on-prem applications (often SaaS) that analyze OT data. Examples include AWS IoT Analytics, Azure Time Series Insights, or Honeywell Forge (all supported by Matrikon). These platforms can run advanced analytics or visualization on incoming data streams.

(See “Matrikon Data Broker” above.) MDB is the core software that connects to multiple OT data sources and presents them in unified ways. It supports data modeling/mapping, secure connections, and can run as a container or Windows service. MDB can also simulate data sources and manage many brokers remotely. Matrikon positions MDB as the heart of the Unified OT Data Layer.

Pluggable OPC UA Servers that connect specific OT devices or protocols to the Matrikon Data Broker. Each MDBA natively communicates with one type of device or network and presents it as an OPC UA server to MDB. For example, Matrikon offers an “OPC UA Server for Modbus (MDB Adapter),” as well as upcoming adapters for EtherNet/IP, PROFINET, Siemens PLCs and more. Using MDBAs lets companies bring any OT source (even legacy or proprietary) into the unified data platform. MDBAs can run on Windows or Linux containers, making them flexible for modern IT/OT infrastructures.

An add-on for Matrikon Data Broker that publishes chosen OPC UA data to MQTT brokers. It converts MDB’s data into MQTT messages (in JSON format), enabling easy integration with cloud IoT services or any MQTT-based system. For example, shops can use this extension to send OT data to Azure IoT Hub, AWS IoT, or other MQTT endpoints without writing custom code.

Matrikon sells a line of OPC UA SDK libraries that empower 3rd party developers to OPC UA enable native OPC UA connectivity to their devices and applications.

A graphical configuration tool bundled with MDB. It is used to set up Data Broker instances, register MDB Adapters, and configure data mappings. (Not to be confused with generic OPC UA discovery tools; this is Matrikon’s GUI.)

Matrikon’s solution for cross-firewall OPC UA connectivity. It leverages the OPC UA ReverseConnect mechanism to let secure connections traverse firewalls without open inbound ports. In practice, a FireBridge link means an offsite system (or another MDB) can pull data from an on-premises MDB without breaching the plant network’s defenses

While not a standalone product, Matrikon’s MQTT Publisher can work with Sparkplug. The publisher can format messages to comply with Sparkplug’s namespace and payload conventions. This enables out-of-the-box interoperability with Sparkplug-enabled clients and brokers.

Matrikon also provides connectors (or example guides) for popular cloud services. For instance, there are guides for connecting MDB to AWS IoT Greengrass/SiteWise and to Azure IoT. This makes sending OT data to big cloud ecosystems straightforward.

In modern IIoT, a common design is to use an enterprise message bus (e.g. MQTT broker or Kafka) as a backbone. Applications publish and subscribe to this bus for real-time data. A unified namespace can be implemented on top of such a bus. Matrikon’s vision of UODL is compatible with the idea of a central data bus where all OT data lands.

Emerging data management patterns. Data fabric refers to technologies that provide integrated data services across platforms, often with metadata to give context. Data mesh emphasizes decentralized ownership (domain-specific data products). A UODL/UNS approach is more like a centralized fabric, but organizations may adopt mesh principles (e.g. each department owning its data pipeline). In any case, underlying connectors like Matrikon’s ensure the raw data can flow into these architectures.

Software suites that perform high-level analysis on OT/IT data, often including dashboards, AI/ML tools and reporting. Examples include Microsoft Azure Data Explorer, AWS IoT Analytics, or industrial data platforms. These platforms rely on upstream systems (like MDB) to supply clean data.

Tools for managing many containers. Companies using Docker containers often use Kubernetes to scale and manage them. Since Matrikon’s products can run in containers, they can be deployed on Kubernetes clusters at the edge or in the cloud for high availability.

Various regions have dominant automation standards. For instance, in North America, EtherNet/IP and Modbus are common; Europe favors PROFINET and EtherCAT; Asia (especially Japan) uses CC-Link. Matrikon’s broad adapter lineup covers all major regional protocols, making global deployments easier.