A Practical Taxonomy for Industrial Internet of Things (IIoT) Systems

Remember the phrase: 'Kings Play Chess On Fine Glass Stools'? While it might sound whimsical, it's a mnemonic that helps recall the classic biological classification: Kingdom, Phylum, Class, Order, Family, Genus, Species.

The sheer diversity of life on Earth is staggering. A well‑structured taxonomy is essential for biologists; it groups organisms by shared traits, enabling scientists to identify patterns and formulate universal rules.

Industrial Internet of Things (IIoT) systems are just as diverse. Without a comparable taxonomy, architects struggle to select appropriate architectures, protocols, and technologies.

Choosing top‑level categories is the first challenge. In biology, one might group animals by habitat—land, sea, or air—but that offers little insight into their structure. Instead, organisms are divided by morphology and function, which directly influence their design.

Similarly, industry labels such as 'medical' or 'energy' do not dictate the underlying architecture. The true drivers are the challenges that the system must address, not the sector it operates in.

This insight may seem radical: industry‑specific standards and protocols are often irrelevant when designing the next generation of IIoT architectures. The enterprise Internet taught us that generic, reusable technologies ultimately prevail.

So what criteria should define IIoT categories? We need a handful of key characteristics that split the landscape into actionable groups.

While thousands of functional and non‑functional requirements exist, we must focus on those that have a direct impact on architecture—unambiguous, measurable, and consequential.

Drawing on RTI’s experience with nearly 1,000 real‑world IIoT deployments, the following taxonomy uses quantitative metrics to create clear boundaries. The numbers are not arbitrary; they reflect practical thresholds observed across many projects.

IIoT Taxonomy Proposal

Reliability [Metric: Continuous availability must be better than "99.999%"]

“Highly reliable” is a vague promise. To translate reliability into architecture, we ask: what are the consequences of a 5‑minute outage per year? Industrial systems often cannot tolerate even milliseconds of downtime.

Systems that must avoid any interruption require redundant computing, sensors, networking, and more. In such cases, reliability becomes the primary architectural driver.

Real Time [Metric: Response < 100 ms]

Speed matters, but the threshold that shapes design is typically in the tens of milliseconds. A 100‑ms limit aligns with the maximum jitter introduced by a typical server or broker.

Architectures that need to respond faster than this usually adopt peer‑to‑peer approaches, which represent a significant design shift.

Data Set Scale [Metric: Data set size > 10,000 items]

When the number of distinct data items exceeds about 10 000, broadcasting every update becomes impractical. These systems demand a data‑centric design that models the data and enables selective filtering.

Team or Application Scale [Metric: Number of teams or interacting applications > 10]

Multiple independent development teams or applications introduce complex interoperability challenges. A data‑centric architecture that explicitly manages interfaces is essential.

Device Data Discovery Challenge [Metric: > 20 types of devices with multi‑variable data sets]

In environments where devices are numerous and heterogeneous, runtime introspection is critical. When more than 20 device types are present, manual configuration becomes untenable, necessitating automated discovery mechanisms.

Distribution Focus [Metric: Fan‑out > 10]

Fan‑out measures how many recipients must be informed of a single data change. If more than ten, a simple 1:1 connection model fails; the architecture must support efficient multicast or publish‑subscribe patterns.

Collection Focus [Metric: One‑way data flow with fan‑in > 100]

Systems that primarily collect data for storage or analysis—often sending information to a cloud back‑end—can leverage hub‑and‑spoke or cloud‑centric designs, simplifying the architecture.

Taxonomy Benefits

A well‑defined IIoT taxonomy is not a luxury—it is a prerequisite for informed design. By clarifying the core challenges, architects can choose the right protocols, network topologies, and compute resources, avoiding costly missteps such as misplaced server locations or ill‑suited real‑time claims.

The Industrial Internet Consortium is poised to take on this task. Its new Working Group aims to distill these fundamental business and technical imperatives. I am excited to co‑launch the group at the next IIC Members meeting in Barcelona. If you’re interested, reach out to me at stan@rti.com, Dirk Slama (Dirk.Slama@bosch‑si.com), or Jacques Durand (JDurand@us.fujitsu.com). Together, we can bring our collective experience to shape the future of IIoT.