Sensing Nodes: The types of sensing nodes needed for the Internet of Things vary widely, depending on the applications involved. Sensing nodes could include a camera system for image monitoring; water or gas flow meters for smart energy; radar vision when active safety is needed; RFID readers sensing the presence of an object or person; doors and locks with open/close circuits that indicate an intrusion at a building; or a simple thermometer measuring temperature. Bottom line, there are many different types of sensing nodes, depending on the applications. Who can forget the heat-seeking mechanical bugs that kept track of the population of a building in the movie Minority Report? Those mechanical bugs represent potential sensing nodes of the future.
These nodes all will carry a unique ID and can be controlled separately via a remote command and control topology. Use cases exist today in which a smartphone with RFID and/or NFC and GPS functionality can approach individual RFID/NFC-enabled “things” in a building, communicate with them and register their physical locations on the network. Hence, RFID and NFC will have a place in remote registration, and, ultimately, command and control of the IoT.
Layers of Local Embedded Processing Nodes: Embedded processing is at the heart of the IoT. Local processing capability is most often provided by MCUs, hybrid microcontrollers/microprocessors (MCUs/MPUs) or integrated MCU devices, which can provide the “real-time” embedded processing that is a key requirement of most IoT applications. Use cases vary significantly, and fully addressing the real-time embedded processing function requires a scalable strategy (using a scalable family of devices), as one size will not fit all.
In the home automation example, depending on the size or type of residence, requirements could vary from a simple network to a more complex structure with hierarchical, nested sub-networks controlled at different levels. For example, in a single-family home, all windows, doors, electrical outlets and/or electrical equipment and thermostats could have simple embedded controllers that communicate with a master MCU/MPU hybrid device for command and control of the entire house. In turn, this master device can communicate via the Internet with a variety of “clients,” from the security service provider and other service providers to portals that can give the homeowner access to remotely control all of these connected “things.” In an apartment building, the same idea can be extended, with an even more complex, layered network hierarchy that includes apartment-level command and control, as well as floor-level and building-level command and control.
Wired and Wireless Communication Functions: The role of the communication function is to transfer information gathered by the sensing nodes and processed by local embedded processing nodes to the destinations identified by the local embedded processing nodes. And, once the data is remotely processed and new commands are generated, the communication function brings back the new commands to the local embedded processing nodes to execute a task.
Sometimes this could be as simple as sensing a fridge door being left open based on energy use, and after analyzing the data, automatically closing the door via a mechanical mechanism or generating a warning for the homeowners’ “home automation app.” Or, it could be as sophisticated as communication to an autonomous vehicle to avoid an accident.
Use cases could vary drastically, but what is common to these command and control communication links is that they typically only need to carry few Kilobytes of data for any given node, unless high-bandwidth image processing or video data is involved.
Software to Automate Tasks: Getting all segments of the IoT to communicate and work together is key to the success of the technology rollout, and that means deploying a lot of software (and middleware) that will enable machines to talk with each other and the infrastructure around them.
From a nuts and bolts perspective, this means lots of middleware to get various heterogeneous devices to talk to each other. For example, in a smart meter application, an analog front end (AFE) reads the meter and the MCU manages the meter to interpret and push the data through the communication pipe, which will be communicating with the house on one end and the curbside on the other end. While most developers have a clear view of the software architecture from a device, communication pipe, and application profile perspective, the service-level fabric must also be considered for a given application.
In this configuration, the sensing node (here the AFE) is using an embedded processing (MCU) node to translate and transmit the data through the communication functions to the central embedded processing node in the house, as well as the one on the curbside. A lot of middleware software is needed to enable this interaction to happen reliably, with the services delivered seamlessly.
Remote Embedded Processing Units (access to cloud computing):
Since there are not yet industry-wide IoT best practices agreed upon and deployed, many component providers are approaching the connection between devices and the cloud as a connection to their niche cloud, as opposed to the cloud. Some companies promote that all devices will be “dumb nodes,” with all processing and decision-making done within “their cloud.” Alternatively, some believe only minimal access to the cloud for basic Internet-related services will be required, with most of the “thinking” done locally. The architecture and building blocks of the IoT as described in this article allow for a number of different approaches, which will likely be necessary due to the wide variety of use cases and configurations anticipated. That flexibility will be needed to optimize system-level performance.
So, why does software
get such a big headline? Software enables the various services the IoT will provide. Services are the means by which the IoT will address certain needs. Those needs could exist today, or they may be things we don’t yet realize we need, but someday we’ll wonder why we never had them before. Many people forget that until 20 years ago, most of us lived without mobile phones and didn’t see a need for them, but now they’re the most widespread personal gadget owned by people in the western world. Along those lines, some IoT services will address needs easily identifiable today (e.g. asset tracking, smart energy, etc.), but others are yet to be defined.
Full Security Across the Entire Signal Path:
Some people bundle this topic within the software portion of the IoT, but it deserves the attention of a separate category. Without a solid security mechanism for all of the IoT building blocks mentioned above, the IoT won’t be as pervasive as it’s anticipated to become.
When we say security, we really mean security of information – the information that gets passed around by various parts of the system and is context- and service-dependent. For example, knowing the location of a person could be considered a good thing if the person was lost. However, if that person felt his or her privacy was being compromised, knowing the location information is a bad thing.