Connecting Remote I/O Devices Over Any Distance with Cellular
By: Mike Fahrion, CTO of IIoT Solutions for Advantech Industrial IoT Group
There are situations where you could benefit from a simple piece of information from a remote location as an input to a local system. For example, knowing if a remote pump is running, if a tank is empty, or simply the temperature in a remote facility can either eliminate truck rolls or trigger a workflow for needed maintenance. There are three traditional solutions for the challenge of acquiring an input signal from a remote site:
- Create your own connection—either wired or wirelessly—between locations. This can be done with fiber, copper, or specialized wireless solutions. With this solution, costs can be high and feasibility will depend on the distance and terrain.
- “Lease” a connection using a dedicated leased line from a Telco carrier, who likely has much of the wired infrastructure already in place. This used to be a common solution, but today “leased lines” have become extremely expensive or not available at all.
- Create an “Internet of Things” (IoT) solution where you publish data from the remote location over an Internet connection, linking in to your local network, then consuming that data at the local site. While effective, this requires re-engineering the system, installing intelligent devices, and software integration.
A simpler, less intrusive solution is to use Advantech’s wide range of I/O products with an Advantech LTE gateway running the low-code, open-source programming tool, Node-RED. This combination provides a large degree of adaptability with I/O products available to support almost any number and type of inputs. Additionally, Node-RED provides an easy-to-use programming tool that can be easily modified to fit a variety of applications.
This paper will describe the solution and provide a link to download the Node-RED “flow” used to provide a remote tank monitoring function required for a particular customer use case. Readers can download that flow and use it as-is or easily modify it to adapt to similar use cases.
The Customer’s Leased-Line Dilemma
A petroleum terminal and distribution company used leased lines to read the status of their customer’s remote tanks before beginning to pump product from the terminal site. The monthly cost of those lines had grown expensive, and that service was no longer available in some of their terminal locations. An alternative solution was required to get the tank level signal from their customer’s tanks to the terminal pumping station.
The petroleum terminal and distribution company called its Telco carrier looking for an alternative to its leased line solution. Knowing Advantech had expertise in both I/O products and cellular gateways, the carrier introduced Advantech to the company.
To build a solution, we selected an ADAM module with digital inputs to read the digital relay outputs of the remote tank, indicating when the tank was either approaching full or was full. Then, to provide remote communications, the Ethernet port of the ADAM module connected to the Ethernet port of the Advantech LTE gateway. On the terminal side, we selected an ADAM module with digital outputs that connected into the existing alarm inputs and connected the module’s Ethernet port to a second Advantech LTE gateway.
From a hardware perspective, we now have a system that can read data from remote signals or sensors and leverage the cellular network to send it to any location Then, it replicates that signal as an output, creating a virtual tunnel that can reach anywhere in the world with cellular service.
Using Node-RED as Software Solution
Software is then required to read and publish that remote signal and, on the local side, to receive the incoming message and set the local outputs to the desired state. To solve this, we installed the open source, low-code Node-RED software on both gateways. We also installed an open source MQTT broker on the local gateway. For the remote end of the system, within Node-RED we created a “flow” to perform the following basic functions.
- Read the input status of the ADAM that indicates the tank status.
- If the input status has changed, publish an MQTT message to the MQTT broker with the state of those inputs.
- If the input status has not changed for a customer’s determined period of time, we publish an MQTT message to the MQTT broker with the current state of those alarms as a “heartbeat” function. This way, we can tell the difference between an unused tank that hasn’t changed its status for days apart from a system failure.
- MQTT publishes data over an IP connection. In order to add some fail-over redundancy, if the remote device is unable to establish an IP connection it fails over to SMS and sends the payload data over a text message. It also sends a text message to an administrator’s mobile phone indicating that the system has failed over to SMS. Although this fail-over is using the same physical layer, the cellular connection, it is a significantly different network layer.
- To prevent excessive messaging over SMS, which can have associated data charges, the remote system counts messages sent in a monthly period and stops sending them before causing a cellular plan overcharge.
On the local, terminal end of the system within Node-RED we created a second “flow” to perform the following functions.
- Subscribe to the MQTT message topics generated by the remote site.
- Decode that message and translate it into a command to the local ADAM digital output device, which provides that tank status to local operators.
- Reset the local “watchdog timer” function on receipt of a message. If that watchdog timer does not receive any signal via MQTT or SMS for a customer determined period of time, we assume a system failure and set the local ADAM module outputs to an alarm state.
Lightweight and Adaptable
Caveats and Assumptions
This solution works well for remote signaling that is not highly latency sensitive and where a system problem would not cause a critical or safety issue. In this case, there is an operator who uses the “alarm state” and the “fail state” as the trigger to call a human operator at the remote site and verify status.