IoT and reliability
When talking about reliability with regard to mechanical and electronic products, there is a tendency to treat it the same way as thermo-mechanical effects and faults related to product ageing and wear. But which new types of fault are introduced with the Internet of Things (IoT), and what can be done to prevent them?
As late as October 2016, web services such as Twitter and Spotify were victims of a Distributed Denial of Service attack. This kind of attack uses many devices to send false enquiries to a specific website. When the website no longer has the capacity to deal with the wave of enquiries, many users find that they can no longer access the website. But what has this to do with IoT? Two things:
- To a great extent, the attack came from IoT devices: This happened because they were infected with a botnet, which is malware designed to take control of a device.
- Such an attack can also strike IoT devices: When the internet becomes loaded, it is no longer certain that even important information reaches its destination.
The reason why so many devices could become infected was due to two very basic security flaws. The software used on many IoT devices is not updated, so they have old security flaws, and their default passwords are not changed to strong passwords when they are installed. By using botnets that utilise the brute force/dictionary method to ‘guess’ the correct password, the attackers can install software on the IoT devices. When malware uses resources on a device, it can become slow, the same way a PC operates slowly with a mouse or other input, and therefore no longer operates as intended and becomes unreliable. The other risk of course, is that the attack focuses on IoT devices that are well protected, so that communications are blocked. It is therefore very important that even when the device is protected, you assess the effects that this could have on the product. One way of testing cyber security is therefore to expose the IoT devices to this type of attack and ensure that there are procedures for password management and software updates at the end user.
Another risk for the users’ perception of reliability of the products is the wireless coverage for the device. Here there can be several types of faults: Individual packet faults and persistent faults. We can take a case from the IBIZ TechLab project as an example. Here, FORCE Technology and other GTS institutes worked on a smart door, which by using different sensors could register when individual customers entered or left a particular store. If a person entered the store, the total number of people registered inside the store increased by one, and if a customer left the store, the total number declined by one. If an event-based communication was used here, with a message being sent to a server whenever someone entered/left the store, it would require that all of the messages from the sensor reached the server, otherwise the total number of people registered inside the store would become increasingly inaccurate every time transmission failed. To ensure that such deviation was corrected, you can send a packet, e.g. every hour, to correct for any lost packets. Because this packet is not sent as frequently as others, there can be for example, greater security in the transmission by using better error-correcting code, better spreading factors in the wireless modulation or several re-transmissions. All together, this increases the overheads for communication, so it takes longer. This means it cannot be implemented for every single customer, since it would drain the battery and use too much bandwidth, but perhaps the budget can allow it to be done once an hour. The effect is that the user experiences a reduced but not unreliable performance.
Shared responsibility and use
This is not directly related to the individual product, but arises from the basic concept behind IoT. When an IoT device becomes connected to the net, it will deliver value to the user by functioning together with IoT devices from other manufacturers. For example, we can take the button Flic from Shortcut Labs and a Phillips Hue light bulb. These two devices are made independently of each other, but if you have set up the system to do it, a press of the button through a website like IFTTT.com will switch on the light. But what if it does not work? Who is responsible for the problem? Who shall provide support? Who shall describe how long you must wait for the light bulb to switch on after you have pressed the button? 100 milliseconds, 1 second, or 1 minute?
At the same time, you need to be aware that it is no longer obvious which application the IoT device is used for. For example, if you use the button to control the light bulb in a home, it must meet the residential requirements for immunity of 3 V/m in a radiation immunity test. But if we use the button as an emergency stop in a large machine or to activate a fire alarm, then it has to be tested in accordance with EN 50130-4, and this requires a test level of 10 V/m. This means that it will be illegal to use the button as a fire alarm if it has only been tested to 3 V/m. The challenge is that it requires that the manufacturer of the button is made aware of which applications may not be used with this device, and which devices it may be connect to.
Do you have some input into the new IoT requirements?
FORCE Technology would really like to hear from companies that have further input about the new requirements that IoT places on their products, so that action plans can be made that solve such needs. For example, one of the effects of those needs is that a new option has been created for Danish electronics developers, who can now personally test antennae radiation patterns, ESD and adjust the antennas in FORCE Technology's facilities through the Nordic IoT Centre, and more types of tests are on their way.
To learn more, contact Senior Specialist Anders P. Mynster, tel.: +45 43 25 14 25.