A plant does not need another dashboard simply because it needs another measurement.

‍

Most industrial facilities already have systems for viewing process conditions, reviewing equipment performance and planning maintenance. Those environments may have been built up over years, with different suppliers responsible for instrumentation, networks, software and support. When a maintenance team identifies a measurement gap, replacing that established environment is rarely the starting point. The more useful question is whether new measurements can be introduced into the systems the team already knows.

‍

That is the purpose of a platform-agnostic approach to wireless monitoring. SENSAiO's reference architecture shows how LoRaWAN sensors can form an additional measurement layer, with data passed through compatible network and integration components toward an existing industrial platform. The principle is flexibility in how the data is delivered, not a promise that every system connects without configuration.

‍

The Problem is Often The Path to The Data

‍

Consider a maintenance team that wants to monitor the temperature of selected equipment beyond its current wired instrumentation coverage. The plant may already have a historian or IIoT application that displays measurements from other parts of the facility, but no practical way to collect readings from those additional points.

‍

A wireless sensor can address the field-communication part of that problem, particularly where extending new signal cabling would be difficult or disruptive. But obtaining the measurement is only one part of the project. The reading still needs to reach a receiving application in a usable format, with the appropriate units, timestamps and reporting behaviour, and it needs to fit the team's existing procedures for reviewing abnormal conditions.

‍

If sensor data ends up isolated in a separate interface that nobody routinely checks, the installation may create another task instead of improving visibility. Integration should therefore be considered from the beginning of the project, rather than after the devices are installed.

‍

What Platform-agnostic Means in Practice  

‍

In this context, platform-agnostic describes an architecture in which the measurement layer is not tied by design to one mandatory end-user dashboard. The components between the sensor and the receiving software can instead be selected and configured around a compatible deployment.

‍

This distinction matters for plants with established monitoring systems. An operator may want new readings to appear within an existing industrial platform, while a system integrator may need to map those measurements into a site-specific data model. At the same time, IT or OT teams may have requirements around network ownership, data location, cybersecurity or deployment arrangements.

‍

A flexible integration architecture allows those requirements to be considered without assuming that the plant must adopt an entirely new monitoring environment. Platform flexibility, however, is not the same as universal compatibility. The available interfaces and deployment choices still need to be confirmed for the actual network, application and integration components selected for the project.

‍

Following A Measurement From The Field to The Platform  

‍

SENSAiO's approved reference architecture illustrates a LoRaWAN measurement path from the field sensor to the plant's receiving environment:

‍

SENSAiO Sensors → LoRaWAN Gateway → LoRaWAN Network Server → Application / Integration Services → Existing Industrial Platform

‍

The application and integration function is shown explicitly here to explain a step that may be simplified in a high-level architecture diagram. It does not necessarily represent a separate physical server or piece of hardware.

‍

At the field level, a sensor measures a supported variable and transmits its data over LoRaWAN. A compatible gateway receives the radio message and forwards it toward the network infrastructure using an available backhaul connection. Depending on the gateway and site design, this may use Ethernet, Wi-Fi, 4G or another supported route. The SENSAiO reference architecture also depicts satellite connectivity as a possible backhaul option, but this should be treated as a deployment possibility rather than a capability of every gateway.

‍

The LoRaWAN network server manages network communication functions and passes application data toward the appropriate application services. Those services may decode the payload, organise the measurements and expose them through an interface that the receiving system can use. From there, the existing industrial platform can present, store or process the information according to its own configuration.

‍

Understanding these layers is useful when planning an integration. The sensor itself does not need to communicate directly using the same industrial protocol as the final platform. What matters is that the selected architecture provides a supported and tested route between the measurement point and the system where the data is ultimately required.

‍

‍

Connecting Measurements to Existing Industrial Software  

‍

SENSAiO's reference architecture identifies Modbus, REST API, MQTT and OPC UA as potential downstream integration interfaces. These technologies support different integration patterns, but they share a common purpose: enabling information to move between systems in a form the receiving environment can use.

‍

One site, for example, may already collect operational data through an industrial interface, while another application may rely on message-based or API-based communication. The integration team therefore needs to determine where sensor messages will be decoded, how measurement fields will be mapped, and which component will provide the interface expected by the destination system.

‍

That work may involve an application server, middleware or an integration gateway, depending on the project architecture. It may also require configuration for device identifiers, engineering units, timestamps, access permissions and reporting intervals. The named protocols are possibilities within the wider architecture and should not be interpreted as built-in interfaces on every SENSAiO sensor or every LoRaWAN network server.

‍

This is where platform flexibility becomes an engineering advantage. Instead of beginning with a mandatory end-user platform, the project team can consider the receiving system first and design an appropriate path for delivering the measurements to it.

‍

Deployment Choices Should Follow Site Requirements  

‍

The approved SENSAiO architecture presents both cloud-hosted and on-premise deployment options. For some organisations, managed infrastructure may fit naturally within the existing IT environment. Others may require site-managed services because of internal policies, operational requirements or network constraints.

‍

The choice affects more than where a server is located. It also influences who maintains the infrastructure, manages access, monitors availability and responds when connectivity is interrupted. These responsibilities should therefore be defined as part of the project architecture before commissioning.

‍

A platform-agnostic design gives the project team room to evaluate those choices rather than assuming one deployment model from the outset. It does not, however, remove the need to confirm which deployment options are supported by the components selected for the project.

‍

Keep Communication Security and Control Requirements Separate  

‍

LoRaWAN includes defined mechanisms for network security and application-payload protection. At the application level, encryption protects payload data between the end device and the application server. These protections apply to defined parts of the LoRaWAN communication architecture, but they do not automatically secure every downstream API, database, dashboard or user account. The complete installation still requires appropriate cybersecurity design.

‍

The architecture presentation also uses the term “duplex” to indicate bidirectional communication. LoRaWAN supports both uplink and downlink messaging, but this should not be interpreted as simultaneous full-duplex communication. Downlink timing and availability depend on the device class and network configuration, and bidirectional communication is separate from the protocol's encryption mechanisms.

‍

For industrial monitoring projects, the operational boundary is equally important. Additional wireless measurements can support visibility and maintenance decisions, but this architecture should not be presented as a replacement for established process-control, protection or safety systems.

‍

Five Questions Worth Answering Before Installation  

‍

A useful integration review begins with the receiving system and the operational need, rather than with a list of sensor features.

‍

What measurement is missing, and what decision will it support?
Define the variable, relevant operating conditions and reporting behaviour needed to make the information useful.

‍

Where should the data appear?
Identify the existing dashboard, historian or application, and confirm which interfaces and data formats it accepts.

‍

Which components will deliver it?
Confirm the gateway, LoRaWAN network service, application services and any middleware needed to complete the path.

‍

Who owns and maintains the system?
Agree on deployment location, cybersecurity responsibilities, connectivity, access and support.

‍

How will the result be tested?
Verify the complete route from sensor to receiving application, including measurement units, timestamps, reporting intervals and behaviour during interruptions.

‍

Taken together, these questions help prevent a common integration mistake: confirming that a sensor can transmit data without also confirming that the intended users can receive and use that information within their existing workflow.

‍

Extend The Measurements, Not The Complexity  

‍

Wireless sensing is most useful when it adds information to an existing operational process. The objective is not to introduce another isolated technology stack, but to make selected measurements available where they can support inspection, maintenance and asset review.

‍

SENSAiO's platform-agnostic approach is intended to support that flexibility. The final architecture still depends on the selected components and site requirements, and interface compatibility should be demonstrated before deployment. When those decisions are made early, operators can evaluate additional wireless measurement points without treating replacement of the existing monitoring platform as the default.

‍

Discuss your measurement requirements and existing monitoring architecture with SENSAiO.