What Must Be Taken into Account in an IoT Project?

What Must Be Taken into Account in an IoT Project?

IoT is short for Internet of Things and typically refers to devices that function mostly on their own, but whose behavior can be queried or controlled from a remote location. The communication from and to the device thereby happens through the internet.

Alongside the well-known devices for home automation, there is, however, a wide range of industrial devices which are already Internet-enabled or which can be upgraded accordingly either now or some day soon. Such devices can be found everywhere, even if they are not apparent at first glance. Billboards with changing displays synchronise with other billboards so that they change the advertisements simultaneously. They also report faults affecting normal operation so that a technician can be automatically deployed.

Escalators and lifts report operational and safety-relevant data to the operator and manufacturer; they can also be controlled remotely. Reception desk staff are able to call the elevator for a guest and then send him or her to the correct floor. Using the same link, the maintenance company can check the system status to determine whether preventative maintenance is necessary. Vehicles like buses or trains continuously report their position to the control center. As a result, customers making scheduling inquiries close to departure can be informed in good time and redirected as needed.

Subsequently we explore the wide variety of possibilities for making devices Internet-ready, as well as the additional requirements involved, beyond the simple adaptation of the devices. For example, decisions are to be made on how the other significant part of any IoT solution, the so-called back end, is to be set up and how the communication between the device and the back end is to work. Finally, thought must also be given to how the user interacts with the system.



There are various ways of making existing and new devices Internet-ready. This depends to some extent on the size of the project. An industrial system, a hospital or home automation each have different demands with respect to networking.

There are three main methods. In most cases, the simplest way is to check when evaluating a system or device that it is, right from the start, capable of transmitting telemetric data or that it can be controlled remotely via a suitable connection. For example, there already exist a wide range of sensors for monitoring temperatures or measuring flow rates, and devices like pumps, valves and similar, that can provide readings or be controlled over the Internet, are readily available as well.

If this is not possible, most vehicles and industrial systems will usually have a central controller. A separate device (generally referred to as a concentrator) can be connected to it which handles the transfer of the telemetrical data to the back end, but is also capable of receiving control commands. The concentrator translates these into commands that are understood by the device being controlled. If a new device is developed from scratch, then a computer unit should be selected which has communication and wireless modules either already built in directly, or so that these can easily be retrofitted. In most cases, such technology is available as a "System on Chip" (short form: SoC); only the required antenna and, if needed, a SIM card have to be added to enable the device to communicate with the back end.


Which type (or maybe types) of connection to select depends on numerous factors. The required bandwidth, the required latency and power constraints are the most important factors here. When the power requirement is only of marginal interest in the case of permanently installed systems, then, in most cases, wired Internet access via dial-up, DSL and optic fiber is readily available. This is very different in the case of a sensor that floats on water for example.

An optimal wireless connections must be selected in this case, from a sizable range of options with very different characteristics.

  • Connections based on mobile networks may offer high bandwidths and comparatively low latency, but have a relatively high power toll.
  • WiFi connections are limited on the range, but offer more reliable bandwidths and latencies. However, they are not particularly energy-efficient either and are therefore not suitable for most battery-operated applications.
  • Most satellite connections are exceptionally expensive and have very high latencies, but they can be used even in the most remote areas, although sometimes only during certain times of the day.
  • Specially designed IoT protocols, such as LoRaWAN, in most cases need very little power while still covering extensive ranges. On the other hand, considerable constraints in terms of the available bandwidth have to be accepted. If such limitations can be tolerated, these setups can often be operated very independently using small solar cells.

Not all wireless connections rely on IP-based transfer between the device and the back end. This is often a compromise in order to make the data transfer more energy-efficient. For example, data transferred with LoRaWAN is only translated into IP traffic shortly before being passed on to the customer's back end by the network operator. The actual wireless transfer, however, makes use of a proprietary format.

Back end

The role of the back end is to analyze the data received from the devices and extract it’s essence. The back end also relays the users' instructions to the relevant device (or devices). Basically, any kind of computer that is permanently connected to the Internet can be used as a back end. Traditionally, entire servers were used for this purpose, but more modern approaches are focused on container technologies and ready-made Software as a Service (SaaS) solutions. A relatively new trend are the so-called Function as a Service (FaaS) platforms, also known as "Serverless Computing".

Selecting the right technology for the back end is mainly influenced by the foreseen use-cases. How much data has to be processed? What are the availability and real-time requirements? How distributed are the devices and how widespread are the users around the world? As these decisions significantly influence the architecture of the software on the devices and at the back end, an experienced service provider should be consulted early on for expert advice.

Users and other remote stations

In the case of classic home automation systems, the users tend to be the residents themselves. But already an elevator system may have a wide range of users: On the one hand, the manufacturer wants to collect telemetric data about his product in order to improve it. On the other hand, the maintenance company wants to use this data in order to deploy a service technician at the right time: ideally, before the system stops working. And the users of a lift may want to reserve or remotely control it at certain times or for certain occasions.

The data collected in the before mentioned example from the vehicles of a public transport provider, reporting their position to the control center, is also useful for many different parties at different times: The headquarter and the customers want information as close to real-time as possible, the service department wants it the same evening, and the schedule designers want averages over a lengthy period in order to prepare simulations that are as realistic as possible in order to offer improved services. Data collected from IoT-applications may even not be consumed by people altogether. Take the readings for the current flow velocity of a river for example, which may lead to altering the outflow at a dam somewhere else along the stream.

In general, careful thought needs to be given to who is allowed to remote-control the devices (if this is possible). But also at what level of granularity, and who or what is going to be consuming or having access to the collected information requires careful consideration.