Embedded sensors and processors built into assets enable condition monitoring data to be collected and used for asset health management and process optimization. Managing data storage, transmission, and security at all levels of the technology stack is crucial for original equipment manufacturers (OEM) and their customers. The federated nature of the product value chain with software and hardware components coming from external suppliers presents challenges when managing this data. The OEM must have assurance processes to confirm that software upgrades provided by their suppliers do not adversely afect the outputs delivered to customers. The output of sensor measurements have a precision determined by the storage space of data registers in a controller's electronics. One technical challenge for OEMs is tracking changes and settings in software code that afect measurement precision when these settings are embedded in hardware components from external suppliers. For this we use a semantic asset model based on the Industrial Data Ontology (IDO). Entities that impact the reported precision are captured in the model.
This paper describes a use case in which a semantic model is used to manage information about the sensor components (data I/O capabilities), the firmware developed by the OEM, and the information handover to the customer as a WoT (Web of Things) TD (Thing Description) file. The model delivers business-critical insights and technical IoT metadata using standardised modelling and reasoning without bespoke analytic scripts. This solution was developed as a collaboration between an equipment manufacturer (Grundfos) and a software/hardware manufacturer (Siemens AG) supplying parts to Grundfos. An existing industrial upper ontology (IDO) enables reasoning, reuse and extension of the model.
We consider the case of a pump manufacturing company (ACME) that designs, manufactures, sells and provides life-cycle support services for pumps. Their pumps are sold to thousands of customers and installed in many countries. ACME sells a centrifugal cooling pump to a dairy facility. The pump is of type E-78-130-F-M-270 (material master). ACME also has a department called ACME DigitalDairy. ACME DigitalDairy sells an energy optimization and predictive maintenance monitoring service to the dairy facility that relies on IoT data on pumped liquid temperature. The cooling pump has a controller, supplied by the software/hardware manufacturer. The controller contains firmware compiled by the pump manufacturer. This ifrmware holds software that is updated over time.
ACME DigitalDairy uses the pump as an IoT Device to request liquid fluid temperature as a WoT TD file. The data comes from a temperature sensor installed in the pump housing; the sensor is supplied by a sensor manufacturer. Data is captured and stored in the pump’s control system and can be transmitted directly to ACME DigitalDairy using IoT by means of an open data communications protocol. This temperature reading is needed by ACME DigitalDairy for the predictive monitoring service.
In this use case, the pump’s temperature sensor has 16 bit resolution on the range of 0–95 ℃ (based on the calibration settings of the sensor). The 16 bits can represent 65,536 diferent values. However, the chosen memory on the pump controller electronics only handles 8 bit resolution, corresponding to 256 diferent values (i.e., storing a temperature range of 0–95 ℃ in steps of approx. 0.4 ℃). The resolution of the sensor, the controller constraint of 8 bit register for the data, the firmware liquid temperature from housing temperature estimation algorithm version, and the temperature range that the sensor is calibrated to operate within puts a deterministic lower bound on the resolution of the IoT datum presented through the communications protocol, multipleOf 0.4. ACME, based on these insights, reports a precision in the WoT TD of 1 ℃, adding a small safety margin. These information artifacts are crucial to ACME for compliance with precision requirements on the temperature reading.
In July 2023 the IDO was approved by the ISO TC 184/SC4 Industrial Data committee as a new
work item for international standardisation. IDO is an evolution of ISO TR 15926-14 [
In the semantic model there are two physical objects (individuals) that enable the IoT call for reporting of a “Liquid Temperature”. These are 1) the ACME pump which includes both hardware and software elements, and 2) the pumped fluid that has the fluid temperature of interest to ACME DigitalDairy. IDO allows us to model that 1) the pumped fluid is contained in the pump, and 2) the reported temperature represents a quality of the pumped fluid, using the IDO object properties contains and hasPhysicalQuantity.
The pump controller has installed (concretizes) firmware that initiates a temperature sensing activity on a regular schedule. An IDO ActivityProfile is used to represent that part of the sensing activity that varies only in the housing temperature quality, producing a set of "raw" readings classified as QualityDatum. Each 16 bit temperature sensor reading acts as input to a down-sampling software process, producing a datum that still corresponds to the housing temperature, but with an 8 bit resolution.
Next, a diferent firmware component on the pump controller estimates the liquid temperature, based on the 8 bit pump housing temperature input together with knowledge about the pump design and heat transfer characteristics. The resulting datum directly quantifies (quantifiesQuality) the temperature of the fluid on the Celsius scale. This datum is timestamped and transferred to a connected system, either another controller at the same site, or in the cloud, in this use case via the communications protocol commonly used in IoT industrial applications.
The semantic model developed uses the IDO model as an upper ontology and adds additional classes, relations and instances as needed for the ACME use case. The use case model supports tracking the data as it moves from the sensor through various transformations to the IoT communication. A key challenge is the management of information about measurement resolution and precision of sensors and the storage space of data registers (8 bit versus 16 bit). The IDO model allows the OEM to explicitly detail each data transformation step, capturing units and values, as well as the versions of software components, which may be updated independently of each other, used to efect each transformation. Being in control and able to model these details is crucial to managing a large portfolio of pumps with diferent sensor types, resolution, and ifrmware over time.
Technical data is commonly exchanged between stakeholders by means of unstructured documents and semi-standardized data sheets, requiring significant manual eforts to ensure data is integrated and up to date. The adoption of a standardized information model, based on IDO, for technical data exchange from the sensor-in-the-pump-housing to a WoT TD reading for the pump customer represents a step-change in current practice.
The development process identified a number of ontology design patterns. These include, among others: physical and functional partonomies, physical containment and connections, software deployment on hardware, sensing activities and their observations, and software processes with their inputs and outputs. These patterns enable the approach described here to be scaled to other IoT sensing applications.
The business outcomes for the two equipment manufacturers involved in this product value chain are 1) the scalability of this solution, 2) traceability as part of risk management practice and 3) the elimination of bespoke, stand-alone and human dependent quality control processes as code and components are updated through the life of the products.