Since the introduction of the World Wide Web, twenty years ago, web technology has been so overwhelmingly successful and proved so adaptable that many people, even technologists, equate web technology with the Internet as a whole. With the approaching advent of the age of the Internet of Things, it’s understandable that most people will favour applying the technologies & design techniques that they have grown up with to IoT.
To create efficient and useful systems for IoT, we need to revise both our design thinking and tools with regard to overall architecture and, especially, user experience.
To start, let’s consider some of the ways in the which the Internet of Things differs from the web systems that we have grown used to. To illustrate this we’re going to be using a domestic example, albeit a somewhat forced one, an IoT device that opens and closes a window.
Note: In this article, I’ll be using the word ‘application’ to refer to complete IoT systems of hardware, network, and software, and ‘app’ in its common usage of mobile app.
Characteristics of IoT devices and systems
While It’s pretty much a given that IoT refers to linking “things” in the physical world to the Internet, a little reflection will reveal some implications that will constrain how we implement our IoT systems.
#1: Real things take their own time
Its axiomatic that people are impatient. We are used to the fact that web sites and apps that don’t respond in fractions of a second loose customers, and so we try to make systems that react very fast.
Unfortunately, real world objects don’t necessarily always react like that, they have inertia, they have motors, and as, we’ll see, they may not be listening all of the time. Situations like do exist this in the web world as well, typically legacy systems like credit cards or ticketing systems, etc.
And the classic solution on the web is to respond positively immediately, release the user to move on, and handle errors situations like a credit refusal by a different channel like email.
Even on the web, these are hardly good solutions, and we have all been frustrated by orders that didn’t go through, or banks that didn’t transfer when the website said “it was OK”. With real-world devices the situation can be much more serious. In our window opener example, I don’t want to attempt to close my windows, leave the house, and then get an email when I’m on the train that “oops, it didn’t close”.
It obviously gets much worse with industrial processes, “shutdown the reactor” for instance, but there are plenty of examples around the home, “switch off the bath”, “turn on the oven”, etc.
We need to design user experiences that can accommodate slowly reacting physical processes and systems and still give us timely, accurate and relevant feedback.
#2: It swings both ways
Apologies for the pun, but I chose the example of the window opener to make a point about IoT: that it is about both monitoring and controlling our physical world.
It seems obvious, but if you look at many IoT articles they seem to focus on one way systems of sensor networks which just feed streams of data into huge “big data” repositories. Obviously, environmental and industrial monitoring is a huge application domain for IoT, but even systems that ostensibly just monitor need bi-directional communication, to change the frequency of data, or the settings of a sensor.
Almost all IoT applications and apps need to support efficient two-way communication with devices
#3: Lots of people, lots of things
Pretty much every electronics store now stocks “Internet of Things” kits, and many people have now experienced the thrill of switching an led on and off remotely. Depending on your kit, this can be a simple or horribly difficult journey, but it still obscures the bigger issue, that we are going to have lots of Things.
Estimates (and hype) about IoT varies widely, but it seems plausible that an average home will have tens of IoT devices, and offices and factories hundreds up to thousands, all of which may be monitored and controlled from a central point. Equally, the reverse is true, every member of the family will want to be able to open and close the window from their phone.
Exploring this a little further, it means that when you start the window app on your phone, its not obvious that the window is going to be in the same state that your left it, for instance if Little Johnny has closed it where you’d left it open. So your app will have to ensure that it is aware of the window’s state at all times, and do that efficiently, for reasons we’ll now explore.
IoT applications cannot assume sole control of a device, and equally, user interface apps must be able to talk to many devices at a time.
#4: Doubling down on Double AAs
Most of us now live in houses and offices where we are constantly looking for power sources for our devices, and there never seem to be enough. We are always looking for a socket to plug the next gadget into. IoT will almost certainly make this worse, and there are many uses for IoT devices where there is no mains power source, say monitoring crops, or valves in the public water system.
All of this means that many, if not most, IoT devices will be battery powered. This puts severe constraints on how much power they can use. Fortunately, modern microcontrollers have incredibly sophisticated features for controlling power usage by going into varying states of very low power consumption, but unfortunately it means that they cannot be connected to the network continuously.
Typically, this means that IoT devices may be effectively switched off for 90-99% of the time.
IoT devices sleep a lot. In real-world systems, some component must keep track of the last state of a device so that an app/UI can access it at all times.
#5: New networking technologies
Battery power puts other constraints on IoT devices. It’s a given that our IoT devices will almost all use some form of wireless networking. However, the existing wireless technologies are not really suited to the power constraints mentioned above.
GSM and CDMA mobile phone chips are both costly and power hungry, and its unlikely that the carriers will significantly drop the price of cellular connectivity.
Wifi is at least low to no cost, but although we’ve made a lot of progress in reducing its power usage, it’s still a fundamentally high power system.
The only other widely used technology, Bluetooth, uses the crowded 2.4Ghz band, has very limited range, and is really designed for PAN’s (Personal Area Networks) rather than integration into the wider Internet.
Enter LPWans (Low Power Wide Area Networks), a fairly tortuous acronym, but a potentially revolutionary technology.
Basically LPWans, like Sigfox and LoRa use frequencies and techniques that allow for ranges measured in kilometers, not meters, and have power requirements that allow IoT devices to operate for years on a set of AA batteries (YMMV).
However, as one might expect, all this wonderfulness comes at a cost. LPWan technology is not designed to keep continuous connections, because devices need to sleep (see above). This means that TCP/IP and higher protocols that use it cannot be directly supported and routed onto an LPWan, but need some form of gateway software to translate between the two networks.
Also, with LoRa you can forget about streaming video, data rates average between 1Kb/s and 10Kb/s, and connections are available for a small percentage of the time, that is, you can transfer data for a few seconds every several minutes.
For efficient, battery powered devices, communication to IoT devices needs to use connectionless (message-based) protocols and be very efficient in its use of bandwidth.
In part one, we’ve taken a user experience focussed view of the constraints that fundamentals of the Internet of Things puts on technologists and apps designers.
Hopefully, this review of the implications and challenges of IoT did not seem to create insurmountable problems, and in part 2 of this series, we’ll look at application architectures and protocols, as well as their pros and cons.