I find Internet of Things (IoT) quite fascinating. After some reading, prototyping, and thinking, I put an end-to-end flow of an IoT scenario on paper. Then I tried to generalize various components to come up with a pattern. The pattern that I believe will fit most of the service offerings related to IoT. In this article, I would like to walk you through that pattern using a real-life scenario of connected cars.

A connected car is a regular car with a device attached to its on-board diagnostic or OBD port. The device reads vehicle data like odometer reading, speed, check-engine light status, location etc. and transmits it to the cloud. Then a driver can use a web or mobile app to keep track of things like trips, mileage, car location etc.

The following diagram depicts the pattern. The choice of single-word labels is intentional to keep things implementation-neutral.

A Pattern for IoT Services


Let us start by following the components that are numbered 1 thru 12:

  1. Getter — A program that reads the data from the device and stores it in a local data store e.g. the device reads ignition status of the connected car.

2. Data — A data store local to the device, primarily for caching e.g. the ignition status gets stored even if the connected car is out of range of the cellular network.

3. Sender — A program that periodically sends device data to the cloud e.g. the device sends ignition status to the cloud.

4. Collector — A component that collects data from a bunch of devices and stores it in a cloud data store e.g. a service collecting ignition status of all the connected cars.

5. Data — A data store in the cloud containing raw data received from devices e.g. a data store containing ignition status of all the connected cars.

6. Processor — A component that converts the raw data into actionable insights e.g. a series of data points starting with an ignition status ON and ending with an ignition status OFF means the connected car completed a trip.

7. Insights — A data store in the cloud containing actionable insights obtained by processing the raw data received from devices e.g. check-engine light status of ON means it’s time to provide the driver more information on what’s wrong or to schedule an appointment with a car servicing shop.

8. Commander — A component that sends commands to the device e.g. send a command to set ignition switch to ON because the driver asked to start the connected car remotely.

9. Setter — A program that receives device-specific commands and executes them e.g. set ignition switch to ON.

10. Reader — A program that reads the raw data or insights from the cloud and displays it to the user e.g. a mobile app showing current location of the connected car on a map.

11. Modifier — A program that takes user input and sends commands to the device via cloud e.g. a driver remotely starting the connected car using her smartphone.

12. Tracker — A component that keeps tracks of devices and users (think of directory or registry) to ensure that only authorized devices can transmit data to the cloud and only authorized users can send commands to the devices.


Now let us look at the three actors:

1. Developer — An actor that develops programs that run on the device. Also develops web/mobile applications that provide actionable insights to users.

2. Administrator — An actor that on-boards devices and users for management.

3. User — An actor that uses web or mobile app to get insights and takes actions by sending device commands.


After covering the components and actors, let us look at the interfacesThese are represented with the blue lines in the diagram and enable interactions between different components.

  1. Collection endpoint— An interface that the devices use to send the data to the cloud.
  2. Data endpoint — An interface that the applications use to read the raw data.
  3. Insights endpoint — An interface that the applications use to read the insights.
  4. Tracker endpoint — An interface that administrators use to on-board devices. Also the interface that applications use to send the device commands.
  5. Setter endpoint— An interface for sending commands to the devices.


Hopefully, you got the overall idea of the pattern. Now try replacing the connected car scenario with an oil pipeline with sensors scenario, elevators with sensors scenario, or thermostats in homes scenario, or your favorite scenario. The components, actors, and interfaces — and thus the pattern — should remain largely the same!