This is the second post in the series The Four Stages of IoT: A Data-Centric Taxonomy of the IoT, and it was originally posted on my website's blog.
In my previous post, I discussed the idea of dividing IoT Architectures into four stages: connectivity, processing, storage, and data access. Today we will explore the Connectivity Stage which is the first step in the journey towards value-generation from IoT Device Data. This stage is composed of the mechanisms whose purpose is to facilitate communications to and from IoT devices: these include services, applications, and communication protocols.
We will now see what some of these mechanisms are and how they are leveraged to stream data to and from backend applications. We will accomplish this by breaking the Connectivity Stage down into three main components: the Field IoT Device, the Edge Device, and the Ecosystem Backend.
THE FIELD IOT DEVICE
"IoT devices" are those collecting data about an environment and acting in response to commands and notifications from a Server: a smart thermostat, a weather station, or a current meter can all be examples of IoT devices.
In this instance, we define a "Server" as any entity which consumes IoT Device Data and pushes notifications and commands back to the device: this could be an actual server, edge device, or a cloud provider.
Connectivity at the Field IoT Device
IoT devices can connect to Servers in one of three ways.
- Some devices simply communicate directly with the server through popular protocols like LTE or Wi-Fi. Cellular-enabled fleet tracking systems like those put on cargo trucks are an example of this category of devices, which have enough CPU, memory, and hardware capabilities to transmit data through the Internet independently.
- Other devices must first go through an edge device. If you wear a fitness tracker that syncs with your phone and whose data gets uploaded to the cloud, then you have an IoT and Edge device combo (your watch and phone, respectively). Edge Devices can help with local data processing and with saving on data transfer costs through local buffering. They can also serve as a protocol intermediary to assist resource-constrained devices by receiving data in low-power protocols like Bluetooth Low Energy (BLE) and relaying it to the backend over Wi-Fi, Cellular, or Ethernet.
- Yet other IoT devices must first communicate with other IoT devices in order to relay their messages to the closest Edge device. For example, Smart Lighting systems often relay their data from light bulb to light bulb before reaching a hub device. Ad-hoc and mesh network protocols are the primary choices for enabling this type of communication.
Data Activity for IoT devices
Once the IoT Field Device is connected, data can be sent, received, and stored as illustrated in the table below.
| Data Activity | Description and Examples |
|---|---|
| Sending Data | Devices send data such as sensor measurements, execution reports, and error logs to a Server. |
| Receiving Data | Devices subscribe to data from the Server like firmware update commands and the status of job executions through messaging systems MQTT. |
| Keeping State (available memory, error count, etc.) | A device reports metrics to the Server and relies on it to store them, analyze them, and react to them by pushing commands back to the device. |
THE EDGE DEVICE
The role of Edge devices is to collect data from IoT devices and to relay that data to the ecosystem backend. As mentioned above, these devices can come in the form of Smart Lighting hubs, mobile phones, voice assistants, and more.
Connectivity at the Edge Device
Edge Devices use standard IT protocols such as Ethernet, Wi-Fi, or cellular to connect to the backend. Furthermore, they often support low-power protocols such as BLE, ZigBee, and Z-Wave to connect to resource-constrained IoT devices.
Edge Device Software such as AWS IoT Greengrass, Azure IoT Edge, and EdgeX Foundry provide frameworks to connect to IoT devices, to process their data locally, to respond to events at the edge, and finally, to pass the data on to the backend.
Data Activity for Edge Devices
When a Field IoT Device connects to the Edge Device, data can be sent, received, and stored as illustrated in the table below.
| Data Activity | Example Data Flow |
|---|---|
| Transferring data to/from IoT devices | IoT devices use an Edge Device as their Server and send it sensor readings and system logs. The Edge Device in turn may pass this data on to the ecosystem backend. |
| Keeping State (available memory, error count, etc.) | The Edge device can store a limited amount of state for both itself and the IoT devices which it communicates with. Typically, enough history is kept here to enable local decision making. For example, the Edge Device could increase the speed of a fan after identifying a high temperature excess. |
THE ECOSYSTEM BACKEND
Finally we arrive at the Ecosystem Backend where the data is analyzed, processed, stored, and made available in different formats to business intelligence and data analytics applications. The Backend can run on on-premise servers or in cloud platforms such as Amazon Web Services.
Connectivity at Ecosystem Backend
IoT and Edge Devices can both communicate with the Backend.
MQTT is a common protocol for communicating to both Field and Edge devices in solutions like AWS IoT and Azure IoT. Furthermore, in these cloud-based solutions, HTTP is available for applications which require a RESTful interface and WebSockets for integration with real-time web applications.
Data Activity for the Ecosystem Backend
When either a Field IoT Device or an Edge Device connect to the Ecosystem backend, data can be sent, received, and stored as illustrated in the table below.
| Data Activity | Description and Examples |
|---|---|
| Transferring data to/from IoT devices | Devices with sufficient hardware capabilities can send reports, logs, and alerts directly to the Backend over a robust mechanism such as Ethernet. |
| Transferring data to/from Edge Devices | Edge Devices relay data from IoT devices to the backend, and they also sync up device states, system logs, and edge decision logic. |
| Keeping State (available memory, error count, etc.) | The Ecosystem Backend is the primary location for storing device state and for applying rules to respond to state events. History of device state is also regularly kept here for auditing and anomaly detection purposes. |
Conclusion
The Connectivity Stage provides the means to load data from IoT devices into the Ecosystem backend where it can be analyzed and turned into actionable insights. We reviewed some mechanisms–including services, applications, and communication protocols–that are used to carry out this extraction throughout the entire Connectivity Stage: the Field IoT Device, the Edge Device, and the Ecosystem Backend.
To finalize, here is a diagram depicting an example IoT Architecture which uses several methods for connectivity to transfer different types of data:
In the next post, I will review the Data Processing Stage, which is where data is enhanced with contextual information and analyzed for patterns over time.
Top comments (0)