IoT engineering challenges pave way for new trade offs

Moving beyond the hype of the potential for the IoT, there are some real engineering challenges that must be addressed in order to satisfy the intoxicating market predictions of IoT uptake across industrial and commercial markets. ABI Research estimates that the volume of data captured by IoT-connected devices exceeded 200 exabytes in 2014, and its annual total is forecast to grow seven-fold by the decade's end, surpassing 1,600 exabytes—or 1.6 zettabytes—in 2020. So, how do we successfully create the devices that will handle all of this data?

Besides the obvious challenges of keeping costs low for IoT devices, there area a number of design and verification challenges that are primarily driven by finding the balance between functionality and the limitations of the hardware and software.

Qian Yu, technical marketing manager at ARM says that from the physical implementation perspective, the design and production challenges come about due to functionality requirements, the limitations of flash technology, and economics.

In terms of functionality, one of the things that makes IoT SoC designs unique is their low power requirements, even as compared to mobile devices. And, their sleep-to-wake ratio is much higher. They still have similar frequency requirements, though, in order to ensure functionality. "As a result," Yu says, designers need to focus on peak power and sleep leakage power optimisation without sacrificing too much performance."

Christian Légaré, CTO and EVP, Micrium, notes that connectivity issues are also significant for IoT, as communication stacks may require their own processor. Légaré also emphasizes the importance of defining an identity in hardware for security purposes, adding "It's the only place where it can't be modified or hacked." Other security concerns for the IoT include maintaining privacy, anti-tampering, secure boot, and remote upgrades.

Obviously, small, single purpose, low-power IoT devices cannot handle all of these power management, connectivity, and security requirements, so what is the way forward? Légaré suggests an overall IoT approach that incorporates edge nodes (hubs or gateways). He says in this type of deployment, designers must answer questions like: Where do you put the required computing resources in the system? How do you design the system so that it is future-proof? To be successful here, Légaré believes that embedded engineers need to work more closely with their colleagues further down the line, in IT. "This is not simple," he says, "because both fields have their own set of technologies and vocabulary. However, for the IoT to be successful, embedded and IT engineers must come to understand each other."

Moving into the realm of performance, Yu notes that some of the implementation and verification challenges include noise isolation, analogue to digital timing closure, and mixed-signal modelling. Also, he points out that the existing embedded flash technologies do not scale well below the 40 nm process. They require higher voltage than other types of logic blocks, so they consume more power.

How to pick a platform
Perhaps one of the biggest early challenges in IoT design is to pick an implementation platform. Mike Anderson, CTO and Chief Scientist for The PTR Group, Inc., notes that the choices between the ARM Cortex M0/M0+/M3/M4 (and soon M7) are plentiful. As with all design projects, engineers weigh which platform gives them the most features for their design constraints. But, more frequently, they tend to make their selections based on the availability of the prototyping platform. Anderson points to the TI MSP432, Freescale Kinetis series, and the ST Micro ST32 as some examples. He also suggests that compatibility with the Arduino platform offers advantages of inexpensive sensor modules, numerous communications options, and an easy to use, open-source development environment.

Another concern with platform selection is the debugging environment. Anderson offers this advice, "The commercial development platforms like Keil and IAR do a great job at integrating the development/debug features into a common IDE—for a price. If you're a start-up or one of the DIY/maker crowd, then there are open-source tools that, with a little bit of integration on your part, can serve yeoman's duty without the initial sticker shock of the commercial products. Additionally, many of the FPGA vendors have embeddable Cortex-M cores with verification tools included if you feel the need for some custom hardware."

Anderson adds that while you can look at specifications to determine the platform of choice, he has found that lately selection is more likely based on anecdotal evidence. For example, someone's friend at another company had a good experience with application support, so that's the product other people are choosing.

How to balance power, functionality, and reliability
First, define the system architecture and put the computing resources where they make the most sense, advises Légaré. So, that's the reasonably simple part, then what?