Communication lies at the heart of the Internet of Things, but making it happen seamlessly is going to take a lot of development.
Barely a week goes by before another report declares the incredible impact of the Internet of Things (IoT), whether it’s in terms of billions of connected devices, the savings governments will make or the money that companies could make - at some point in the future.The ability to interconnect things that have some semblance of intelligence could lead to more efficient production, healthcare and transport. Levent Gürgen, an R&D project manager at French engineering research institute CEA, describes how cameras in cars or smartphones could report a defective manhole in the street, setting systems into action that organise not only repairs but automated signs to create a detour around the problem. And not just a single fixed detour, but one that adapts to congestion based on the movement data of the vehicles themselves, diverting them along different roads.
Eric Starkloff, vice president of global sales and marketing at National Instruments, claimed at the company’s NI Week conference in Austin, Texas in the summer: “We are creating a huge explosion of data. Some are comparing it to the Cambrian explosion in evolution - a good analogy because it’s not that we are just creating more data, it’s that the diversity and types of data is evolving at a rapid rate.”
The key is getting data to where it needs to be to make the system work. There are serious technical issues involved. How do you ensure that only authorised clients receive the right data updates? How does the data get to them? How can we reduce power consumption far enough to allow sensors to be scattered around the environment without worrying about battery life?
“If you read the press on IoT it sounds as though you can sprinkle the world with systems and upload the data to the cloud. You need an architecture,” Starkloff says.
And that architecture is just beginning to take form, as these four directions in IoT design show.
1. Protocol Proliferation
Remy Pottier, ARM director of strategy, sums up one major problem facing IoT developers: the tyranny of choice. “We found more than 120 standards that are relevant to the IoT,” he said at the recent DATE conference in Grenoble, France.
Many of the larger companies trying to gain a foothold in IoT services and support have joined one or more consortia, each trying to push its own collection of protocols in the hope they will become the de facto standards of the future for the ways in which devices talk to servers in the cloud.
The situation is complicated by the way in which many of these collections mix and match different supporting protocols that are considered to be open standard, such as CoAP and MQTT. Others, such as Apple’s HomeKit introduce new proprietary protocols that perform the same functions as the open standards and demand even specialised silicon. Even for some of those based on open standards, the documentation that describes what is inside means paying a licensing fee to the consortium.
Petteri Holländer, head of product management at The Qt Company says: “There will be a lot of protocols introduced and implemented. We don’t see any dominant players emerging at the moment.”
The similarity of the IoT architectures that most suppliers are proposing means that a lack of interoperability between the devices at the edge of the IoT and the servers that coordinate them may not prove an obstacle to the sharing of data once collected. A cloud server will, in principle, have access to better authentication and verification mechanisms that will check it is allowed to send data to another organisation’s network.
Gateways in the fog
“In general, the cloud is the main intersection where decisions can be made most easily. But some applications or users may want to keep the information at the local network level, and not send it up to the cloud,” says Amir Friedman, founder and CEO of ConnectOne.
In these cases, gateways in the ‘fog’ layer that lies between the edge devices and servers, will perform the analysis of who and what should be allowed access. As a result, they will have to understand multiple protocols. The hub supplied by Philips for its Hue electronically controlled light bulbs is an early example of that approach. The latest version adds support for Apple’s HomeKit protocol, translating instructions from the Siri voice-recognition services into commands that the bulbs, which run the ZigBee Light Link protocol, can understand.
Gareth Noyes, chief strategy officer at Wind River, says: “As we go to IoT don’t assume everything will be cloud centric.”
In some cases, there may be no cloud or even fog layer. Denmark-based Nabto, for example, has adopted a peer-to-peer model by which computers can interrogate devices directly, using an encrypted protocol able to tunnel through home and business firewall machines.
2. Radio Risks
The choices over wireless interfaces for IoT still seem to be growing - with the Google-backed Thread last year joining a list that includes ZigBee, 6LowPan, WirelessHart among others. But many of them use the same core radio technology. And all, apart from the recently introduced protocols for wide-area communications, use the same unlicensed frequency range - the 2.4GHz band popularised by Wi-Fi and then Bluetooth.
“The market is immature, so there are still lots of approaches,” says Tony Milbourn, vice president of strategy at module supplier u-blox.
The most visible protocols are Bluetooth and Wi-Fi today because of their prevalence in smartphones and tablets, providing an easy connection to simple body-worn and home devices. As a supplier of ready-made designs for signal processing and RF interfaces, Ceva has so far focused on these two protocols. “We do believe that standards like ZigBee and Thread or others will be complementary to Bluetooth and Wi-Fi,” says vice president of market intelligence and investor relations Richard Kingston, but before making acquisitions for other IoT-ready protocols the company “wants to be sure that there’s enough business out there”.
Benefits of choice
Milbourn says device manufacturers may not need to make an early decision: “Many semiconductor vendors are producing these multiradio chips that support Wi-Fi, Bluetooth and ZigBee. And there are some scenarios where you also have NFC for key exchange. You touch a device to get the parameters exchanged and then the link is moved to another radio channel. Multiradio chips reduce the cost burden and those costs are reducing.”
A second advantage of multiple radios is that the system designer can trade off energy efficiency against performance, with ZigBee used for regular data updates, for example, but Wi-Fi employed for short periods to handle bulk transfers such as firmware upgrades.
The biggest choice, Milbourn says, is between radio architectures. “One involves devices talking to a concentrator that has a wide-area return channel. The other has just one hop to the Internet, such as cellular.”
The one-hop architecture suits systems where the device maker does not want to piggyback on existing home or factory networks or the deployments do not have a high concentration of sensor nodes. The wide coverage of cellular makes it a prime contender, but not the only one.
Users will need to choose between protocols that use dedicated, licensed spectrum, such as the proposed narrowband-IoT form of the 4G LTE cellular standard, and free-for-all unlicensed bands. White-space protocols such as Weightless aim at the latter. But the unlicensed bands may have issues with quality of service.
“Unlicensed is where smaller, more agile suppliers are popping up. But the hazard is in if something affects the link performance. A large number of wireless microphones for an open-air concert scramble the channel enough that you can’t read the level of a reservoir. In licensed spectrum that cannot happen,” Milbourn says. “But the danger for the cellular industry is that the standardisation process is making introduction of narrowband IoT very slow.”
3. Energy Excesses
One key problem that faces many IoT devices is energy efficiency. There is a tension between the need to be always on and the reality of IoT device design which demands that much of the device needs to remain shut down for most of its lifetime to avoid draining the battery within a matter of minutes. Chris Rowen, CTO of the IP group at Cadence Design Systems, calls the resulting architecture “cognitive systems layering”.
Rowen explains: “In an IoT-class device the system is normally quiescent; it’s not doing anything. It’s waiting for something to happen.”
That something could be a change in the speed of a flow sensor or a sudden noise picked up by a microphone that the A/D converter sees as a jump in sound levels. While nothing happens, the core microprocessors can be left in a deep sleep, only powering up every few seconds for a matter of milliseconds.
“When a sensor registers any activity happening, you move from a realm of dissipating the nanowatts of power needed to check whether there is a noise that could be of interest, such as voice activity. It moves to microwatts when the system wakes up the next level of processing,” Rowen adds.
The next level could be a specialised digital signal processor that can process the data more efficiently than a generic microcontroller to find possible phrases that the software thinks are commands. “If there are, it wakes up the main applications processor, which dissipates tens to hundreds of milliwatts. Then, if it needs full voice recognition, it’s time to wake up the cloud,” Rowen says.
Even with low duty cycles, there is pressure to run some IoT devices on a single lithium cell because changing or charging the battery during its five- or ten-year lifetime could be too inconvenient. This is leading some chipmakers to investigate novel circuit design techniques that are difficult to implement but result in big energy savings.
Ambiq Micro, for example, has pursued the idea of supplying a large proportion of the transistors on its microcontrollers with voltages that are very close or below the threshold voltage at which the device can switch fully on. The resulting logic is slower than normal but the technique can lead to large reductions in power consumption when the circuit is switching - as long as the power is removed during periods of sleep.
Not all chipmakers are convinced. Texas Instruments looked at subthreshold operation for a number of years but decided against adoption. “We found that with customers, in their systems they had to put in other components that needed the voltage to be boosted, so it just became not successful,” says Jennifer Barry, microcontroller product marketing manager for TI.
4. Hack Attacks
The first wave of IoT devices possesses pretty basic security, relying on gateways and firewalls to provide protection. But manufacturers are coming to the conclusion after seeing numerous, highly publicised hacks of existing systems - from industrial controls to Barbie dolls - they need to beef up security dramatically.
Amir Friedman, founder and CEO of ConnectOne, says: “It depends on the application and how sensitive the information is, but it’s becoming quite standard that all comms from the device should be encrypted. The thinking is that you need to give the consumer peace-of-mind in knowing that their data is never transmitted openly.”
As well as ensuring that data cannot be easily intercepted by a man-in-the-middle attack, the devices and servers need to be sure they are talking to each other and not an intruder acting as an electronic cuckoo, using your own network to bug you.
Timo Grassmann, senior product marketing manager for Infineon Technologies, says: “An impostor device, such as a camera, could be transmitting to a user from inside your network so they know whether you are there or not.”
Although encryption can provide a foundation for secure communication, a major problem for IoT devices is that they will often not be well protected physically. Not only could their firmware be hacked over the Internet, an attacker can crack them open and gain access to debug ports and load a Trojan-horse program.
“The ugly truth is that, as a designer you have to find all the flaws in the system and the attacker just one. You will fail,” says ARM CTO Mike Muller. “You have to build systems on the assumption they will get hacked.”
Already a feature of point-of-sale terminals, though far from all of them, is the secure-boot process. This forces the processor loading the code at boot time to check for a valid signature and to stop if the code is wrong. And, if a system is found to be compromised, there has to be a way to roll it back to factory settings to allow a secure update to be installed.
Updated and educated
Professor Sandip Kundu of the University of Massachusetts says: “Any IoT device needs firmware that can be updated, and that firmware needs to be digitally signed. We know how this solution works but it’s not yet implemented in IoT devices, because we have to put in hardware to do security functions so it’s not impossibly slow. And we need to customise individual unit so each one has its own code.”
The approach taken by Infineon, as well as competitor NXP Semiconductors, is to use the secure manufacturing facilities they have set up to build cryptoprocessors for mobile SIM cards and smartcards to create security chips that can be built directly into a wider range of embedded devices and which run alongside the system’s application processors.
“Education is also an essential part of the system, so that the encryption keys are put on to the chip and managed effectively. If the key material gets outside, then your hardware security doesn’t help,” Grassmann concludes.