From distributed to true edge: 4 edge computing examples

4 edge computing examples

The best way to understand where edge computing comes into play is to pick some realistic examples that reflect the evolution of edge computing applications.

1. Point of sale

At first glance, point of sale seems to fall within the boundaries of protective local processing. However, point of sale has a subtle difference: Application latency can impact worker or customer behavior.

When a cashier or customer is scanning barcodes on goods, they expect positive feedback -- usually in an audio tone, an item description on a screen or both. This remote site activity has potential latency constraints, but they're less stringent than constraints found in automated manufacturing applications.

Point of sale, therefore, is a mix of distributed and edge computing. Although using remotely located computing resources for applications could introduce latency issues through connection or resource congestion in the data center, it's rare that local applications need any special techniques to further manage latency. Still, developers should check scan response time constraints carefully, since missed scans create retail losses.

2. Warehousing

This edge computing example is on the other side of the distributed-edge divide: warehousing applications that involve a combination of human and automated movement and accounting of goods.

In these applications, trucks arrive and depart from a facility, and workers move goods onto and off of these trucks. The goods are either withdrawn from or added to inventory and are linked or unlinked with the truck transportation inventory. The goods themselves are packaged and barcode labels attached, and when they are moved on or off shelves or on conveyor belts, scanners record their barcodes to help create a model that shows the movement of goods.

The pace of activity can be high, and because movement has to be coordinated between humans and automated facilities, it's not possible to stop and recover information lost -- the system can't keep up. In many cases, automated package handling shifts goods onto new paths as they flow past, and any delay can result in moving the wrong package.

Traditional local inventory processes are at work here, but so are automated processes. In addition, latency management is very important. This makes warehousing an edge computing application that local controller and server resources are most likely to support. Consequently, developers should consider it an embedded control application.

3. Versatile transportation

The transportation edge computing example is valid for road, rail, air and maritime companies. Versatile transportation exposes the issues that could convert an on-premises edge hosting application into an edge services application.

In transportation applications, both content and conveyance are important. Barcodes, QR codes and RFID can identify objects of either type as sensors read them during loading, unloading and even movement. Telemetry devices that include sensors can provide other details, such as temperature and GPS location.

The normal application structure for reading these metrics is to collect data at many points and then send it inward: a perfect model of an edge/cloud or edge/data-center application. Because transportation applications naturally obtain sensor data in batches at key points, latency management is critical to ensure that no data is lost and that problems are quickly analyzed.

Today, a series of facility-linked appliances support applications under this use case, but there is increased use of mobile services (including 5G) and interest in edge hosting services. The same batched nature of sensor reports means that transportation applications tend to be sporadic in terms of usage, making them ideal for support via edge hosting.

4. The smart city

In a way, the final example is the sum of the rest. The smart city might indeed be a city, but it could also be a campus, stadium or even battlefield. What characterizes the smart city is a combination of variety and unpredictability, coupled with the fact that in many cases, property and lives could be at risk if something goes wrong.

The smart city illustrates that the world is big. Inherently, handling it at the application level requires decomposing it into interdependent systems. Each of these is still a real-time component of the broader picture, and so each processes its local events and contributes events to broader systems in succession. The event-centric nature of operations at each level means low-latency local processing, and the synchrony of the whole system depends on consistent and rapid movement of events.

Some elements of the smart city could be other edge use cases viewed as distributed computing if considered alone. Even protective local processing, in a smart-city context, could require real-time integration with a system that alerts shoppers to deals as they pass a store. This would require understanding both price and inventory. The smarter the city -- or city-like collection of facilities -- the more real-time, edge-centric the system elements of that collection must be.

Tom Nolle is founder and principal analyst at Andover Intel, a consulting and analysis firm that looks at evolving technologies and applications first from the perspective of the buyer and the buyer's needs. By background, Nolle is a programmer, software architect, and manager of software and network products, and he has provided consulting services and technology analysis for decades.