Download this article in PDF format.
Building up frameworks and services to accelerate product delivery for the Internet of Things (IoT) takes lots of time and effort. It also often involves a skill set that developers don’t have or want to develop given how difficult it is to concentrate on specific aspects of a solution, be it an IoT end device like a sensor system, a gateway, or an app for a smartphone or embedded controller.
Part of the challenge of moving from a standalone device or one with a limited networking repertoire to an IoT solution is due to the increasing number of hardware and software components needed in a solution—complexity that causes issues in everything from design and debugging to long-term management and security. Issues can range from connectivity to security to latency.
For example, pressing a virtual button on a smartphone running an IoT control app may affect an IoT device. How long this takes depends on a variety of factors, including sending a message up to the cloud and back down to the device. This may be suitable for flipping a light on or off, but might not be fast enough when controlling a drone. On the other hand, a “smart” drone may be able to work well with higher latency, since it would be handling chores like obstacle avoidance and flight stability.
Choosing an IoT Walled Garden
Many companies promise an “end-to-end” IoT solution. They provide stacks running on microcontrollers that link to cloud services. Developers need to incorporate the stack and link their application to it. Services provided by the stack can range from basic communication with the cloud to handling secure over-the-air (OTA) updates.
Regardless of the breadth and depth of support, the IoT solution requires a cloud component, of which there are many options. Some of the big players include Amazon Web Services (AWS) IoT, Microsoft Azure IoT Hub, Google Cloud, Oracle IoT Cloud, IBM Watson Cloud, CISCO IoT Cloud Connect, Salesforce IoT, Bosch IoT Suite, General Electric Predix, and SAP IoT Platform. Some of these provide specialized services such as General Electric’s Predix targeted at industrial IoT (IIoT) applications. Many of these organizations provide generic cloud-computing services as well, which often obfuscates the discussion because the IoT services are typically built on top of the computing services.
In general, IoT cloud services tend to be a walled garden. There may be some ability to link IoT entities, including applications, services, or devices, to third-party entities on the same platform. Using data and commands outside of the service is sometimes possible. This may be done using remote procedure call (RPC) or representational state transfer (REST)-style interfaces. The protocols involved are as varied as the number of platforms and services.
Just about everyone is getting into the IoT cloud solution mix. For example, Mbed OS and Mbed Cloud are two components of Arm’s IoT solution. Arm actually sells intellectual property (IP) for processors and graphics processors. The MbedOS is a lightweight operating system designed to run on low-end Arm microcontrollers. It can actually be used by itself, but it’s really designed to support the Mbed protocol stacks to communicate with the Mbed Cloud. The Mbed Cloud provides remote management of devices, including updates. It supports a range of connectivity solutions like the Constrained Application Protocol (CoAP), and can interface with other systems using REST APIs.
Advantech is a major hardware solutions provider. Its WISE-PaaS Alliance partner program includes participants like Microsoft Azure IoT and Arm Mbed. Advantech takes a more modular approach to IoT. Other services in that mix include the WISE-PaaS/SignageCMS, which is a digital signage content-management system. Likewise, McAfee endpoint security and integrity control are additional services developers can utilize on Advantech hardware.
Of course, selling what one already offers is the IoT approach being taken by many. Dell’s Edge Gateways for IoT look to bring compute to the edge instead of the cloud. The EdgeX Foundry is an interoperability foundation designed to support Dell’s partners, including systems integrators, contractors, and developers.
1. The AWS IoT Button from Amazon is a dongle with a Wi-Fi connection. It’s designed to hook into AWS IoT support that can fire off a lambda function running on AWS Services.
Having working example always helps, and this even extends to major players like Amazon. Its AWS IoT Button (Fig. 1) is a simple Wi-Fi dongle with a button. Though it appears to simply be a button to turn a device on and off, there’s much more going on under the covers. As with most secure IoT devices, it has its own private key. The AWS IoT cloud support has rules that are invoked by clicking the button. These, in turn, initiate a lambda function in a “serverless” cloud environment. The serverless environment essentially runs small applications within a secure environment that is lightweight even for containers. Rules and lambda functions are yet another new idea for many developers to contend with.
IoT frameworks or collaboration can align along components of the system like LoRa Alliance’s LoRaWAN. One way to connect LoRaWAN devices to the cloud is to use the The Things Network (TTN). Another is to use Comcast’s machineQ service. These highlight how the choice of an underlying wireless technology can dictate the IoT framework options available to developers. These services normally terminate in a cloud service like Amazon AWS IoT or Microsoft Azure IoT.
Almost all frameworks will note that they’re “built on standards,” but that normally means they use standard communication stacks like TCP/IP and may build on these with protocols like MQTT. Quite a bit more is involved with IoT communication, since everything from security to service and device discovery is part of the overall communication protocol. Much of this higher-level communication tends to be non-standard. Usually, that means two different IoT frameworks can coexist on the same network and communication infrastructure, but are islands unto themselves.
The Voice Connection
2. Apple’s HomePod (a), Amazon’s Echo (b), Microsoft/Harman Kardon’s Cortana (c), and the Google Home (d) smart speakers are building the audio walled gardens.
Voice control just adds another wrinkle into the IoT framework walled garden mix. The “smart speaker” craze is fueled by platforms like Apple’s HomePod, Amazon’s Echo/Alexa, Microsoft/Harman Kardon’s Cortana, and Google’s Google Home (Fig. 2). These consumer devices recognize a user’s voice commands, which are analyzed in the cloud. Auditory feedback, such as answering a question or playing music, can be handled by the speakers. However, commands can invoke other actions associated with other IoT devices like smart lightbulbs or washing machines. Even security systems and other types of systems can be controlled by a voice-based solution.
Such frameworks provide a level of configuration and interoperability that normally crosses the other IoT frameworks for non-smart speaker devices. The interaction is typically in the cloud with the onus placed on the developer to make the connection between their service and the smart speaker service. Amazon calls these Alexa “skills.”
Requiring a smart speaker for your IoT device is probably not a great idea, but it’s possible to incorporate that technology into things like a voice-managed washing machine. I have tried a number of development kits that work with Amazon’s Alexa Voice Service (AVS). This includes XMOS’s xCORE VocalFusion 4-Mic Kit and Cirrus Logic’s Alexa Voice Capture Development Kit for Amazon AVS (Fig. 3). Both hook up to AVS and provide the same functionality as an Amazon Echo. They can process voice commands and play back responses and music. Each requires a free Amazon Developer account.
3. XMOS’s xCORE VocalFusion 4-Mic Kit (a) and Cirrus Logic’s Alexa Voice Capture Development Kit for Amazon AVS (b) provide Alexa-enabled smart speaker support.
XMOS’s platform uses the multicore xCORE VocalFusion processor to handle the audio-processing chores. Developers will also need to obtain and install a Rasberry Pi 3 plus power supply along with a speaker. The system has a four-PDM (pulse density modulation) microphone array that handles far-field processing.
Cirrus Logic equips the Raspberry Pi 3 with a kit to link its CS47L24 smart codec to the internet. The system is designed for low-cost applications using a pair of CS7250B digital MEMS microphones. The company also has a graphical, web-based interface that makes setup and configuration significantly easier. On top of that, it offers solutions that handle more microphones for higher-end platforms.
In general, the Raspberry Pi is overkill for handling the AVS support. It does offer a good platform for implementing other services, although the device would typically implement a “skill” that could be initiated via AVS while sharing the network connection and providing communication support for the codecs. Developers looking to implement local voice control will face a tougher challenge.
This type of voice command support is going to wind up in everything from television sets to refrigerators. The challenge for developers is which one to support, since consumers will likely want to have all of their devices work together and the creators of the vocal walled gardens aren’t really on speaking terms.
Voice control is only one type of service for an IoT solution that will likely be handled in the cloud. Artificial intelligence (AI) and machine learning (ML) tends to require more horsepower and data, making it a useful adjunct to a local IoT device. The smart speakers are already using this for voice recognition and natural language processing. For example, Watson is part of IBM’s solution.
Discovering IoT
The initial connection between an IoT device and a cloud-based service using the various developer’s kits is designed to be flexible but not necessarily simple, whereas a final consumer or industrial device needs to have a very easy installation process. Some IoT frameworks provide this type of service.
4. Secure Device Onboard (SDO) developed by Intel securely links a device to a cloud service when it’s initially set up.
Another possibility is Intel’s Secure Device Onboard (SDO) approach (Fig. 4). SDO assumes that the chip supplier has secure hardware support built-in, including an Enhanced Privacy ID (EPID)—essentially a private key. The device and its EPID are paired with a 128-bit Globally Unique Identifier (GUID) that’s usually presented on a bar code associated with the device. The GUID is used to tell the SDO server what service will handle the device. The EPID and other keys make sure the transaction is secure and authenticated.
The SDO support is only used when a device is initially provisioned or if it needs to be reprovisioned. The latter can occur if the device is sold or set to other uses.
IoT devices may be designed to simplify set up and use by consumers and companies, but it’s complex: Everything from provisioning to long-term management is in the mix. Even something as simple as the AWS IoT Button involves a lot of software for any transaction, even though it’s simply linked to another IoT device to turn it on and off. Doing all of this securely and reliably is what makes the development process interesting.
