The edge of the IoT
As the Internet of Things grows ever larger, data analysis and decision-making will have to localize—shifting from the cloud to the edge.
Jain Marble Temple pillar Frescoes, Ranakpur, Pali district, India (source: Matthew Laird Acred on Wikimedia Commons)
The edge of the IoT is where the action is. It includes a wide array of sensors, actuators, and devices—those system end-points that interact with and communicate real-time data from smart products and services.
By 2020, it’s projected there will be anywhere from 25 to 50 billion1 Things2 connected to the IoT—that’s up to seven connected Things for every person on planet Earth. On our way to this milestone, we can anticipate that these billions of connected objects will generate data volume far in excess of what can easily be processed and analyzed in the cloud, due to issues like limited bandwidth and network latency (among others).
Learn faster. Dig deeper. See farther.
Living on the Edge
Edge computing or fog computing—a paradigm championed by some of the biggest IoT technology players, including Cisco, IBM, and Dell—represents a shift in architecture in which intelligence is pushed from the cloud to the edge, localizing certain kinds of analysis and decision-making. Edge computing enables quicker response times, unencumbered by network latency, as well as reduced traffic, selectively relaying the appropriate data to the cloud.
Regardless of whether system intelligence is ultimately located in the cloud or the fog or some hybrid of the two, development for the Internet of Things requires technologists to have a clear understanding of edge architecture and how information is both gathered from devices and communicated.
An Abstract Edge Architecture Model
While specific solutions—from smart homes to smart grids to smart factories—may have their own unique variations, for the purpose of discussion, let’s abstract a basic edge architecture that describes the key elements.
The foundation of our stack, pictured in Figure 1-1, is the “Thing,” that critical product or environment that is the core reason for our IoT system build.
In the next layer, sensors and actuators provide the Thing’s “read and write” capabilities. These sensing and actuating components may either be built into the smart product or environment, or, in the case of a retrofit, they could be added after the fact.
Sensors
Sensors read and report on the real-world status of connected products, machines, and local environments. They are the eyes and ears of the system, monitoring environmental elements like temperature, light, and moisture. Ongoing sensor innovation, an often-overlooked area of IoT technology, will be critical for evolving and improving solutions.
While we might think of sensors only as physical objects, anything that can be read—from files to product-specific data—can and should be considered sensor input. For example, a piece of industrial equipment may have hundreds of data points unique to that product, and every one of them could be considered a sensor.
Sensors may be physically hardwired, built into the product, or communicate via a short-haul communication protocol like Bluetooth Low Energy (LE) or ZigBee.
Examples of sensors include:
-
Temperature sensors
-
Light sensors
-
Moisture sensors
-
GPS receivers
-
Vehicle on-board diagnostics
-
Files
-
Product-specific data
For instance, the Grove water flow sensor, shown in Figure 1-2, is part of Seeed Studio’s hardware innovation platform for technologists to take new ideas from prototype to production. It reads liquid flow rate using a water rotor, whose speed changes depending on how fast the water is moving. The signal output comes from a Hall effect sensor, which pulses as the rotor turns.
Actuators
Actuators affect the electromechanical or logical state of a product or environment. They are the system’s hands and feet. Actuators might include a light that can be turned on and off, or a valve that can be opened and closed.
System commands sent to embedded applications—such as remote reboot, configuration updates, and firmware distribution—should also be considered actuation because, by changing its software, the system is in fact changing the physical reality of a product.
Examples of actuators include:
-
Lights
-
Valves
-
Motors
-
Commands (“soft” actions, file distribution, firmware updates)
For instance, the 6000 series indexing valve from K-Rain, pictured in Figure 1-3, is a robust distribution valve that can be used for high-flow city water, irrigation, and even wastewater applications. The valve acts as a manifold, directing the flow of water from zone to zone, and can be coupled in an IoT solution with an intelligent valve monitor to ensure even water distribution and alert operators to potential malfunctions.
Controller
The next layer in our stack is the controller, a hardware or software component that interacts electrically or logically with sensors and actuators. It is in the controller that we’ll find our low-level, short-haul communication.
While in many instances the controller may be fused within other elements of the stack, it is always present logically. For example, a controller may be a simple circuit that reads an analog signal from a temperature sensor and digitizes the signal into discrete transmissions that the upper layers of the stack can understand.
Over short distances, local communication from sensors can come via a simple serial connection between devices, or short-haul wireless technologies like ZigBee. Industries may define standard protocols for interfacing with equipment—for example, OBD-II for automobiles, or DEX and MDB for vending machines. All of these represent short-haul protocols, because they are meant for local communication between sensors, control systems, and an agent.
Agent
The next layer in the stack is the agent, an embedded program that runs on or near the IoT device and reports the status of an asset or environment. The agent acts as a bridge between the controller and the cloud, deciding what data to send and when to send it. This process operates in reverse as well, as the agent processes and responds to cloud-based commands and updates.
As an example of the controller and agent working in concert, imagine that we’re engineering a proof-of-concept device for an IoT system using a Raspberry Pi and an Arduino with a breadboard. The Arduino is the controller running LEDs and servos, and acquiring data from a sensor. The Raspberry Pi is interfacing with the Arduino, and running a software agent that decides when to send the sensor data to the cloud, via a long-haul connection to WiFi / Ethernet.
Long-haul communication
On the top layer of our architecture, we find our long-haul communication to the Internet. IoT solutions invariably require that environment or device status be made available to a cloud-based application for consumption by a variety of stakeholders. Once an agent has received information via short-haul, it must retransmit that information to the cloud. The desired characteristics of these long-haul protocols are much different than short-haul, particularly in the categories of security, footprint, and reliability. There are a wide variety of long-haul options for IoT solutions, dependent on the use case; they include cellular and satellite, WiFi and wired Ethernet, as well as subgigahertz options like LoRa and SigFox.
Networking protocols for long-haul communication are similarly diverse; they include TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) for the transport layer, and HTTP (Hypertext Transfer Protocol) and CoAP (Constrained Application Protocol) for the application layer, among many others.
Device Types
To further our understanding of how the edge of the IoT works, let’s look at some typical examples of the key hardware components that make up our devices. While it’s true there can be an overwhelmingly wide variety from which to choose, the basic component types—from modules to microcontrollers—provide us with concrete examples of the elements required for edge connectivity and logic. The examples that follow are largely focused on cellular technology, although devices using WiFi, wired Ethernet, etc., for connectivity are also considered.
Modules
Communication modules are components for connecting to WiFi, cellular, or long-range wireless networks. While modules typically have little to no programmability, vendors do provide a variety of configurable options and even lightweight scripting.
Original equipment manufacturers (OEMs) and custom solution providers building IoT capabilities directly into their products often incorporate communication modules into a custom board design. For instance, the AirPrime MC Series communication module from Sirerra Wireless, pictured in Figure 1-4, is incorporated into both connected consumer electronics, as well as industrial grade solutions like Itron’s OpenWay Smart Grid.
Vendors that build modems and routers also use modules in their products. However, because manufacturers don’t pre-certify communication modules, any custom products incorporating the module must be certified by the carrier prior to usage.
SoCs and microcontrollers
For building connectivity and logic into your IoT product, you’ll need a microcontroller like the CC3200 from Texas Instruments, pictured in Figure 1-5, or a system on a chip (SoC) like Qualcomm’s Snapdragon processor (designed originally for mobile computing but now able to be embedded just about everywhere).
While both SoCs and microcontrollers are integrated circuits that include many of the components of a complete computer, SoCs typically have greater amounts of RAM and more powerful processors. As a result, SoCs are capable of running robust operating systems such as Linux or Windows and more complex software. Microcontrollers and SoCs are used in a wide variety of IoT applications, from wearables to connected cars, among others.
Modems and routers
At its core, a modem is essentially a communication module on a board, enclosed in a physical housing, with a serial connection to plug into a computer. Since modems are pre-certified by the manufacturer, they can be used right away after purchase, as long they’re on a carrier’s certified list. In scenarios where PCs are already controlling high-value units—industrial machines in factories or large medical devices in hospitals—modems can be the right fit for adding connectivity.
Routers are similar to modems. However, instead of a single serial connection to one PC, routers allow for multiple computers to share a cellular data connection. A router can also initiate the connection to the cellular network itself, as opposed to a modem, which needs to be explicitly controlled by the serial-connected PC.
For instance, Cisco’s Connected Grid Router, shown in Figure 1-6, built specifically for IoT applications like smart cities and smart grids, can be installed outdoors to support sensor networks.
Gateways
Gateways from companies like Dell, Intel, Multi-Tech, and others are essentially small form factor computers. They have built-in connectivity (WiFi or cellular), capable CPU architectures, and plenty of memory, running full-featured operating systems such as Windows or Linux. Figure 1-7 shows Dell’s Edge Gateway 5000.
Gateways are great for retrofitting unconnected Things, enabling the connectivity of industrial devices and other systems to the IoT. Gateways provide a place to put your IoT agent code and often include an SDK to make the coding and deploying of an agent straightforward. They connect legacy and new systems, and enable data flow between edge devices and the cloud.
Trackers
A tracking unit is an excellent example of a fixed-purpose, machine-to-machine device engineered to perform a specific set of functions for a vertical market. Trackers, like the CalAmp LMU 3030 pictured in Figure 1-8, can track vehicle speed and location as well as access vehicle diagnostic data. They’re useful for fleet tracking, car rental driver monitoring, and other automotive applications.
Trackers are essentially modems coupled with a CPU. As such, they have built-in connectivity, GPS, and advanced configurability to dictate behavior. Trackers have built-in agents, as well as their own long-haul protocols.
Prototyping boards
This list of edge components would not be complete without a discussion of prototyping boards and their impact on ideation and design for the IoT.
Prototyping boards such as the Arduino Uno (shown in Figure 1-9), Intel Galileo (shown in Figure 1-10), and Raspberry Pi are ideal for proof-of-concept work. They have just about everything a designer or engineer needs to start creating for the Internet of Things:
- Connectivity
- A prototyping board comes equipped with a wireless module or an Ethernet chip and RJ-45 port to connect to the wired Internet.
- Application development stack
- Prototyping boards have a way to load code, whether it be Arduino Sketch, Java, or a C programming language.
- Expandability
- You can easily add breadboards, expansion boards, and sensors to prototyping boards.
While it’s commonplace for IoT product companies to use prototyping boards to test out new ideas, these boards usually are not appropriate for deployment scale usage from a cost standpoint. When manufacturing a high-volume production run of a product, product engineers and designers will necessarily be concerned with the keeping the bill of materials (BoM) in check. To conserve costs, it’s often necessary to alter the prototype design for a production build, tossing out the parts of the board that are not actually being used.
For example, if the prototyping board has a powerful CPU with a 1.1 Ghz processor, but the product really only requires a 400 Mhz processor, appropriately specifying a less powerful processor will positively affect the bottom line. In these cases, finding the right prototyping board vendor to help you transition from the prototype stage to production can be critical.
In the end, it’s unlikely that your dishwasher will be connected to the IoT by a Raspberry Pi inside of it. However, it’s quite likely that the dishwasher manufacturer may embark on its IoT journey by creating a proof-of-concept with a Raspberry Pi.
Edge Architecture Examples
To make our abstract edge architecture a little more real, let’s compare and contrast two different solutions, one using an embedded agent with WiFi for long-haul communication, and another using a gateway with cellular connectivity.
For this exercise, we’ll use a common, but surprisingly transformative IoT solution: the smart, connected vending machine. This example typifies the potential of the IoT to provide real business value to industries that might seem unadventurous from a technological perspective.
From inventory management to better provide customers with popular food options, to remote diagnosis and repair to maintain the machines, to power consumption and temperature monitoring for increased energy savings, the connected vending machine provides a great example of how the IoT can bring business transformation through data transparency.
The connected vending machine solutions pictured in Figure 1-11 and Figure 1-12 use the same foundational edge architecture.
The sensors and actuators for the vending machine include the internal electromechanical units, such as a bill validator for receiving payment, and motors for manipulating and moving product inventory.
The controller layer uses the vending industry standard control busses:
- MDB (multi-drop bus)
- Allows transactional devices like the aforementioned bill validator to communicate with the vending machine’s brain.
- DEX (digital exchange)
- The means by which the product inventory is tracked.
The agent interfaces with the DEX and MDB control layer to determine the amount of products the vending machine has in inventory, as well as how much money it has collected over the course of the day. It then relays that data to the cloud.
Real-World Deployment
From this point on, our two example architectures differ. Where the agent resides and how it connects to the cloud is determined in part by the topography and nature of the machines’ real-world deployment.
If the vending machine is located by itself, perhaps in the middle of a theme park, we’ll need a solution where connectivity can be embedded directly inside the machine itself, as in Figure 1-11. In this instance, our agent can be loaded on to a microcontroller and our long-haul communication handled through the local Wi-Fi network.
However, in contrast, if there are 10 vending machines co-located in a single environment, perhaps in a skating rink, it’s unnecessary for each one to have its own agent and long-haul transport. Instead, all 10 machines can be wired together with one IoT gateway, as depicted in Figure 1-12. In this case, each vending machine can talk to the local gateway, where the aggregation logic, other business logic, and agent logic reside, as well as the long-haul connectivity. In this example, our agent is loaded onto the gateway and long-haul communication is handled through cellular.
From these examples, we can see how embedded and gateway architectures can be equally valid and have their place, depending on the real-world circumstances that bound the IoT solution.
1“Gartner Says 4.9 Billion Connected ‘Things’ Will Be in Use in 2015; In 2020, 25 Billion Connected ‘Things’ Will Be in Use.” http://www.gartner.com/newsroom/id/2905717, accessed Mar. 24, 2016.
2“Cisco Global Cloud Index: Forecast and Methodology, 2014–2019.” http://bit.ly/25wqkDN, accessed Mar. 24, 2016.