A Horizontal Taxonomy for the Industrial IoT
Figure 3: IIoT Reliability-Critical Applications
Hydropower dams can quickly modulate their
significant power output by changing water flow
rates, and thus help balance the grid. Even a few
milliseconds of unplanned downtime can
threaten stability.
Air-traffic control faces a similar need for
continuous operation. A short failure in the
system endangers hundreds of flights.
A proton-beam radiation therapy system must
guarantee precise operation during treatment.
Operational
dropouts
threaten
patient
outcomes.
Applications with severe consequences of short
interruptions in service require a fully-redundant
architecture, including computing, sensors,
networking, storage, and software.
3.2
Thus, we define “continuous availability” as the
probability of a temporary interruption in service
over a defined system-relevant time period. The
“5-9s” golden specification for enterprise-class
servers translates to about 5 minutes of
downtime per year. Of course, many industrial
systems cannot tolerate even a few milliseconds
of unexpected downtime. For a power system,
the relevant time period could span years. For a
medical imaging machine, the active time period
could be only a few seconds.
The consequences of violating the requirement is
also meaningful. A traffic control system that goes
down for a few seconds could result in fatalities.
A website that goes down for those same few
seconds would only frustrate users. These are
fundamentally different requirements.
Reliability thus defined is an important
characteristic because it greatly impacts the
system architecture. A system that cannot fail,
even for a short time, must support redundant
computing, sensors, networking, storage,
software, and more. Servers become
troublesome single-point-of failure weak points.
When reliability is truly critical, it quickly becomes
a---or perhaps the---key architectural driver.
Real Time
Metric: Response < 100ms
Architectural Impact: Peer-to-peer data path
There are many of ways to characterize “real time”. All systems should be “fast”. To be useful,
we must specifically understand which timing requirements drive success.
“Real time” is much more about guaranteed response than it is about fast. Many systems require
low average latency (delivery delay). However, true real-time systems succeed only if they always
respond “on time”. This is the maximum latency, often expressed as the average delay plus the
- 32 -
December 2015