IIoT 分类法

国王在精美的玻璃凳子上下棋。有谁记得这个吗？

对于大多数人来说，这可能是胡言乱语。但不适合我。这个助记符帮助我记住生命的分类：界、门、纲、目、科、属、种。

地球上生命的广度、深度和多样性令人难以抗拒。分类法根据系统的特征在逻辑上划分系统类型。如果没有良好的分类法，生物学科学将是不可能的。它使科学家能够将植物和动物按逻辑类型进行分类，确定共性，并构建用于理解整个生命系统类别的规则。

工业物联网 (IIoT) 的广度、深度和多样性也是势不可挡的。 IIoT 系统科学需要对应用程序类型进行类似组织的分类。只有这样，我们才能继续讨论合适的架构和技术来实现系统。

第一个问题是选择顶级部门。在动物王国中，您可以给大多数动物贴上“陆地、海洋或空中”动物的标签。然而，这些环境描述对理解动物没有多大帮助。鲸鱼的“建筑”不像章鱼，但很像熊。要理解，动物必须按其特征和结构进行划分。

按“医疗、交通、电力”等行业划分应用也是没有用的。虽然这些环境很重要，但适用的架构和技术并没有按照行业划分。同样，我们需要更深入地了解定义主要挑战的特征，而这些挑战将决定架构。

我意识到这是一个强有力的，甚至令人震惊的主张。例如，这意味着每个行业的定制标准、协议和架构并不是设计 IIoT 系统未来架构的有用方法 .尽管如此，这是该领域系统的一个明显事实。正如在成为企业互联网的转型中一样，通用技术将取代专用方法。为了加深我们的理解并实现 IIoT 的承诺，我们必须摒弃旧的行业特定思维。

那么，我们可以用什么来划分呢？我们可以使用哪些定义特征来区分 IIoT 的哺乳动物、爬行动物和昆虫？

有成千上万的需求，无论是功能性的还是非功能性的，都可以使用。就像在动物中一样，我们需要找到将空间划分为有用的主要类别的少数要求。

通过实现目标是划分空间以便我们可以确定系统架构，该任务被简化了 .因此，好的划分标准是 a) 明确和 b) 对架构有影响。这听起来可能很简单，但实际上非常重要。做到这一点的唯一方法是通过经验。我们很早就开始了我们的探索。然而，重大进展在我们的集体掌握之中。

根据 RTI 在近 1000 个实际 IIoT 应用程序方面的丰富经验，我建议在下面进行一些早期划分。为了尽可能清晰，我还为每个部门选择了“指标”。当然，线条并不是那么鲜明。但数字迫使清晰，这是至关重要的；没有数字标尺（米尺？），意思经常丢失。

IIoT 分类建议

可靠性[指标：持续可用性必须优于“99.999%”]

我们不能满足于“高度可靠”的陈词滥调。几乎所有东西都“需要”它。为了有意义，我们必须更具体地了解实现这种可靠性的架构需求。这需要了解故障引起问题的速度有多快以及这些问题的严重程度。

我们发现，对可靠性进行分类的最简单、最有用的方法是问：“每年 5 分钟意外故障的后果是什么？” （我们这里选择 5 min/yr 只是因为这是企业级服务器的“5-9s”黄金规格。许多工业系统甚至无法容忍几毫秒的意外停机时间。）

这是一个重要的特性，因为它极大地影响了系统架构。一个即使在短时间内也不会出现故障的系统，必须支持冗余计算、传感器、网络等。当可靠性真的很重要时，它很快就会成为——或者可能是——关键的架构驱动因素。

实时[指标：响应 <100 毫秒]

有数以千计的方式来表征“实时”。所有系统都应该“快速”。但要发挥作用，我们必须具体了解哪些速度要求驱动架构。

一个能满足人类用户不愿意等待超过 8 秒的网站的架构永远不会满足必须在 2ms 内响应的工业控制。我们发现，当响应速度以几十毫秒 (ms) 甚至微秒 (µs) 进行测量时，就会出现对设计产生重大影响的“曲线拐点”。我们将选择 100 毫秒，因为这与数据路径中的服务器或代理施加的潜在抖动（最大延迟）有关。响应速度比这更快的系统通常必须是点对点的，这是一个巨大的架构影响。

数据集规模[指标：数据集大小> 10,000 项]

同样，有数千个维度需要扩展，包括“节点”的数量、应用程序的数量、数据项的数量等等。我们不能用所有这些参数来划分空间。在实践中，它们是相关的。例如，一个有很多数据项的系统可能有很多节点。

尽管空间广阔，但我们发现有两个简单的问题与架构要求相关。第一个是“数据集大小”，曲线中的拐点大约是10k项。当系统变得如此庞大时，将每个数据更新发送到每个可能的接收器不再可行。因此，管理数据本身成为一项关键的架构需求。这些系统需要“以数据为中心”的设计，明确地对数据建模，从而允许选择性过滤和交付。

团队或应用程序规模[指标：团队或交互应用程序的数量>10]

我们选择的第二个尺度参数是“项目”上的团队或独立开发应用程序的数量，断点在 10 左右。当许多独立的开发人员组构建必须交互的应用程序时，数据接口控制主导了互操作性挑战。同样，这通常表明需要一种以数据为中心的设计，明确地对这些接口进行建模和管理。

设备数据发现挑战[指标：具有多变量数据集的>20 种设备]

一些 IIoT 系统可以（甚至必须）在运行之前进行配置和理解。这并不意味着每个数据源和接收器都是已知的，而只是该配置是相对静态的。

但是，当 IIoT 系统集成机架和机器或设备机架时，通常必须在操作期间对其进行配置和理解。例如，工厂控制器 HMI 可能需要发现已安装设备或机架的设备特性，以便用户可以选择要监控的数据。 “20”个不同设备的选择是任意的。重点是：当机架中的设备有许多不同的配置时，这种“内省”成为避免手动操作的重要架构需求。大多数具有此特性的系统有超过 20 种设备类型。

分发重点 [指标：扇出> 10]

我们将“扇出”定义为在更改单个数据项时必须通知的数据接收者数量。这会影响架构，因为许多协议通过单个 1:1 连接工作。大多数企业界都以这种方式工作，通常使用 TCP，一种 1:1 会话协议。示例包括将浏览器连接到网络服务器、将手机应用连接到后端，或者将银行连接到信用卡公司。

但是，IIoT 系统通常需要将信息分发到更多目的地。如果单个数据项必须到达多个目的地，则架构必须支持高效的多次更新。当扇出超过 10 个左右时，通过管理一组 1:1 连接来进行这种分支变得不切实际。

收集焦点 [指标：单向数据流，扇入> 100]

本质上仅限于收集问题的系统不会在设备之间共享重要数据。相反，它们传输大量信息，以便在更高级别的服务器或云端进行存储或分析。

这具有巨大的架构影响。收集系统通常可以使用轴辐式“集中器”甚至基于云的服务器设计。

分类优势

定义 IIoT 分类法并非易事。这个博客只是触及了表面。然而，好处是巨大的。解决这些需求将有助于系统架构师选择协议、网络拓扑和计算能力。今天，我们看到设计人员在服务器位置或配置等问题上苦苦挣扎，而正确的设计甚至可能不需要服务器。诸如“实时”和“事物”之类的重载术语会导致技术之间出现大量混淆，而没有实际用例重叠。

工业互联网联盟是时候接受这一重要挑战了。其最新的工作组将解决这个问题，目的是澄清这些最基本的业务和技术要求。我很高兴能在下一次在巴塞罗那举行的 IIC 成员会议上帮助启动这个小组。如果您有兴趣，请联系我 ([email protected])、Dirk Slama ([email protected]) 或 Jacques Durand ([email protected])。我们将首先分享我们在 IIoT 范围内的广泛联合经验。