Four kinds of device get specified for a remote site, and the names overlap. They differ in where the data ends up and who it is for. Picking the wrong one is how a project ends up with a gateway and nothing to send the data to, or a SCADA outstation on a point nobody polls.
| Does | Data goes to | Fits | |
|---|---|---|---|
| RTU | Outstation for a SCADA system, answering a master over a SCADA protocol | The SCADA master | Utilities with a SCADA system already running |
| Data logger | Records readings locally, sometimes with a modem | A file or the maker's software | Surveys and studies where the record matters more than alerts |
| Protocol gateway | Converts one protocol to another, for example Modbus to a network protocol | Whatever system you point it at | Integrators who already have the platform |
| Cellular IoT controller | Reads sensors, holds the record, alerts, and can switch outputs | A cloud with alerts, export and an API | Distributed points with no network and no platform yet |
Then the outstation has to speak its protocol. That is an RTU job.
Then a gateway that delivers raw values may be all you need, and the platform does the rest.
Then the box has to bring one: the record, the alerts and the access. That is what a cellular IoT controller with its own cloud does.
Genesis is the fourth kind: it reads the sensors, keeps the record through outages, alerts people and switches outputs, with a cloud and a REST API included.
It is not a SCADA RTU and not a transparent gateway. If the site needs either of those, it needs a different box.
No. It reads defined values from supported sensors and delivers them through its cloud and API. A transparent Modbus bridge is a different product.
Through the REST API, a SCADA or historian that can pull from an HTTP API can collect the readings.
Tell us what has to be measured or switched, where, and what it has to report into. We say which approach fits, including when it is not ours.
Talk to us →