Connected Data Is Not the Same as Usable Information

TL;DR

The challenge: Industry 4.0 requires more than systems exchanging data. A message can follow the right format and still leave the recipient unable to tell which object it describes, what the values mean or whether the information can be trusted for a decision.

The approach: Keep three questions separate: identity (which object or function), meaning (what the information describes, made explicit through shared concepts and, where needed, ontologies) and quality (whether it is accurate, complete and current enough for the intended use).

The effect: Information requirements become testable, deliveries become acceptable on evidence, and new applications need less re-interpretation each time systems, suppliers or analyses change.

The connection is the beginning, not the acceptance criterion

A machine sends a temperature and a status. The connection works and the message follows the required format. Yet the recipient may lack essential information: which temperature, from which part of the process, in what unit and when it was measured. A status also needs a definition that distinguishes, for example, the equipment’s operating state from a communication fault.

Being able to transmit information does not establish that it can be used for its intended purpose.

Keep three questions separate

Identity: Which object or function does the information refer to? Different systems may use different identifiers, but the mappings between them need to be explicit and maintained.

Meaning: What does the information describe? Concepts, properties and relationships need to be sufficiently explicit for the use case. An ontology can help describe and process them in machine-readable form.

Quality: Is the information sufficiently accurate, complete and current for the task? The assessment also needs to consider its source, context and how it has been verified.

Semantics and data quality are not limited to industrial applications. This article focuses on manufacturing and technical facilities, where information needs to work across disciplines, systems and suppliers.

Start with the intended use

Production analysis may depend on different machines describing downtime reasons in comparable ways. Building energy analysis requires measurements to be linked to the correct meter, service area and time period. These examples do not require identical models or quality thresholds.

Start with the decision or function. Then establish which objects, concepts, relationships and facts are needed, and which deficiencies would make the result unusable.

Make requirements testable

Information requirements need to be verifiable. Checks might establish whether mandatory fields exist, units are permitted, timestamps are sufficiently recent and mappings point to known objects.

However, a model can be structurally valid while describing the wrong physical connection. Data validation therefore needs technical review or physical verification where necessary. It must also be clear who can approve and correct the information.

HubMind’s viewpoint: proportionate structure, clear accountability

Standards and ontologies can reduce the need for bespoke definitions and support interoperability. They do not replace local decisions about source authority, acceptance and change. Sometimes clear definitions and mappings are sufficient; sometimes a more explicit semantic model is needed.

HubMind recommends starting with a defined use case and combining the information model with quality checks and accountability. The goal is not the largest possible model, but information that can be used, verified and maintained.

HubMind participates in standardisation work for industrial data and interoperability (SIS/TK 280, connected to ISO/TC 184), which keeps this perspective aligned with the international development around Industry 4.0.

Next step

Which decision needs better information? Start by defining the task and assessing the sources, relationships and quality requirements it actually needs. Our information architecture and data governance service describes how we structure that work.

Continue reading

Contact us