物联网的一种参考架构-InfoQ

本文是两篇系列文章中的第一篇，我们在将这一系列文章中首先从一个抽象的角度了解 IoT 的参考架构，然后分析具体的架构与所选择的用例的实现。第一篇文章将涵盖更具体与完整的架构中的各种定义，而第二篇文章将通过实际的用例应用这种架构。

我们正处在一个崭新的互联世界的入口，处于“物联网”（IoT）或者说是“第四次工业革命”浪潮之中的公司正在开发一种新型的网络，让我们在每日生活中所接触到的事物可以实现互通。IoT 实现了“物”（Thing）的互联，通过信息交换的方式，为用户完成各种任务。各种新颖的思想将逐渐变为现实，例如让家里的冰箱不仅能够与你的智能手机通信，甚至还能够与生产者的服务器场或是能源发电厂进行通信。在背后推动这次新技术与通信变革的公司来自于各行各业，不仅像 Google、微软或 Apple 这样的大数据软件巨头正走在这条道路上，此外还有保险公司巨头、外围设备厂家乃至汽车制造商也纷纷投入 IoT 的怀抱。

在各种不同的“Thing”之间实现通信的关键在于实现标准化。标准化在研究环境中说起来很容易，但要在真实的世界中实现却是相当困难的。参考架构对于实现标准化能够带来很大的帮助，在对于 IoT 系统实现进行计划工作时，可以参考由这些架构所定义的指南。

为了实现标准化，必须创建高层次的参考架构，正如 IoT-A 所完成的工作一样。不过，由于高层次的参考架构过于抽象，因而造成了难以理解的现状。如果你正在从事咨询顾问工作就会发现，要为行业中的实际客户展示这种高层次的参考架构是不可能的。

我们希望做到更进一步，通过我们提供的指南，使你了解如何从 IoT-A 参考架构中生成一个更为具体的架构。我们的想法是为这个抽象的 IoT-A 参考架构创建一个较低层次的架构，你甚至可以将它写到“管理总结”中，这也正是这篇文章的主体。此外，我们还将选择部分用例，在这个引用架构中进行举例说明，以展示一个完整的生命周期，包括在 IoT 中实际系统的实现。这一部分将在下一篇文章中进行讲解。

首先，让我们定义一些术语：

Thing：这是我们在每日生活中所接触到的某个物体，它就存在于我们的生活环境中。Thing 既可以是一辆汽车或一台冰箱，但也可以被抽象为一个完整的房屋或是城市，这取决于我们的用例。
设备：可以表示一个传感器（Sensor）、一个制动器（Actuator）或是一个标识（Tag）。通常来说，设备是 Thing 的一个组成部分。Thing 将处理设备中的上下文信息，并将选定的信息与其他 Thing 进行通信。此外，Thing 还可以将行为传递给制动器。

在每一种 IoT 参考架构中（例如 Google 的 Brillo 、 IoT-A 或 Z-Wave ），你都会（以某种形式）发现大量“无法回避的 IoT 组件”：

Thing 与设备的互操作性以及集成组件。
上下文感知计算技术，例如上下文模型或行为模型的定义，以及规则引擎的目标定义。
与整个架构相关的安全性指南。

在某种形式上，当前的 IoT 架构可以被视为由 Anind K. Dey 所提出的 Context Toolkit 框架在更大规模上应用的一种版本。Context Toolkit 的设计属于应用层面，因为它是为地理信息系统（GIS）所设计的。而在 IoT 环境中，我们必须对 Context Toolkit 在物物互联方面进行扩展。不过，目标、上下文信息以及行为等基本概念在 IoT 世界中同样适用。

在 IoT 的世界中，不仅我们能够在用户层面（即来自于应用程序）定义目标，Thing 本身也可以在没有用户积极参与的情况下实现某种目标。最终来说，设备依然是为用户服务的，但他们可以在后台进行自治的工作，这也正是普适计算（Ubiquitous Computing）的思想。

为了更好地理解“上下文”这个术语，我们首先将介绍一个上下文模型，然后再对参考架构进行介绍。上下文定义了处于某个场合、某个时间点上的某个环境的状态（通常来说即用户环境）。上下文模型通常分为上下文元素与上下文情境。上下文元素通常会在设备层面定义特定的上下文，上下文元素的一个例子可以是处于某个具体时间与位置的温度。

(点击放大图像)

位置与时间本身就属于上下文元素，但他们还扮演了一种特殊的角色，因为要在空间与时间上定位传感器的值，必须了解这些信息。如果不了解某个温度是在哪里、在何时测量的，那么这个温度对于决策来说并没有什么帮助。

某些上下文元素是可以立即实现标准化的（举例来说，一个温度值已经被定义为一个双精度的数值加上一个测量单位，例如摄氏或是华氏温度）。而其他上下文元素则是特定于应用程序的（即“特定于Thing”），因而无法立即实现标准化。这些元素被定义为“高层次”的上下文，对于每个Thing 来说，需要一种机制以定义他们。

上下文情境（Context Situation）则是多个上下文元素的一种聚合。因此，上下文情境是对于某个环境在某一位置、某一时间的一种视角。

(点击放大图像)

正如上文所说，某些上下文元素是可以立即标准化的（因为他们已经实现了标准化），而另一些无法立即标准化（因为他们是特定于用例的）。为了了解某个Thing 与另一个Thing 之间能否进行通信，需要他们对于某种通信标准达成一致。出于这个原因，我们需要引入上下文情境模式（Schema）。上下文情境模式将以上下文的方式定义某个物的能力。

你可以进一步扩展这个上下文模型，定义某种所有的Thing 都必须具备的“标准功能”，以及需要由每种Thing 自行定义的“额外功能”，例如 Z-Wave 标准的做法。

与上下文模型类似，你也可以定义一个行为模型，该模型将定义 Thing 可以触发的行为（例如打开一个窗口，或是拍摄一张图片）。行为必须由上下文信息（例如某个上下文情境）和已定义的目标的组合所触发。目标通常由规则引擎中的规则进行描述（例如 IF temperature > 25* THEN open window）。当某个上下文情境具体对应到某个 Thing 之后，这个 Thing 就需要根据它的已定义目标（即规则）评估是否要触发某个行为。根据用例的不同，与某个 Thing 对应的上下文、行为与目标模型的复杂度也有所不同。有些 Thing 只会使用行为的信息，而不会发布上下文信息，而其他 Thing 则会发布上下文信息（甚至是目标），让其他 Thing 进行使用。

现在，我们已经理解了上下文感知计算在 IoT 世界中所扮演的角色，接下来我们可以讨论这个参考 IoT 分层架构（简称“RILA”）的定义了。在 IoT 的语境中，RILA 将连接 Thing、设备与用户，正如下图所示。

(点击放大图像)

RILA 包含 6 个层，除了这 6 个层之外，还有两个“横切面层”，他们将影响其他所有层。这两个层即“安全层”与“管理层”。

让我们来看一看 RILA 中的每个层与其中的组件。我们将从最底层（设备集成层）开始，随后逐步向上层推进。

设备集成层（Device Integration Layer）负责连接所有不同的设备类型、获取设备的测量数据，并（在设备层面上）实现行为的通信。可以将这一层视为一种能够讲多种不同语言的翻译器。传感器与标识的输出取决于他们所实现的协议，而制动器的输入同样由他们所实现的协议所定义。

(点击放大图像)

设备集成层包含三个主要的组件。最底层的组件是驱动组件，它负责通过低层次的、特定于供应商以及通信协议的方式在不同的传感器、标识以及制动器之间进行通信。对于系统已知的每种低层设备类型，它都提供了对应的驱动实例。下一个组件是设备发现组件，它能够由两种事件触发，一种事件来自于设备管理层，告诉这个组件需要添加一种新的设备。另一种事件来自于驱动组件，如果添加了某种新的设备，驱动组件就会通知设备发现组件。与之类似，设备发现组件还要处理设备的撤消注册操作。最后一个组件是设备通信组件，它负责在设备管理层与驱动组件之间起到桥梁作用。当设备管理层找到某个设备后，该组件将决定要调用哪个驱动。

设备管理层（Device Management Layer）负责从设备集成层中获取设备的注册信息以及传感器的测量数据。此外，它还负责将制动器的状态变化向下传递给设备集成层。设备集成层随后将对状态的变化进行校验（即行为），保证它与制动器相一致，并将解释后的状态变化发送给制动器。

(点击放大图像)

设备管理层负责控制设备，以了解有哪些设备已连接到系统中。对于设备注册信息的更改，以及传入的测量数据必须通过设备集成层与设备管理层进行通信，从而实现信息的更新与保存。设备集成层通过这种方式管理设备的注册（包括添加元数据，例如传感器所发送数据的单位或频度）以及设备的通信（将实际的测量数据传递给数据管理层，并将行为向下传递给制动器设备）。

可以将数据管理层视为一种中央式的数据库，它保存着一个“Thing”的所有数据，但这只是一种可能的实现方式。对于系统中较大的Thing（例如从其他Thing 中收集数据的某个设备生命周期监控系统），数据管理层可以扮演一种数据仓库，甚至是一个完整的数据场的角色。数据管理层的实现很大程度上取决于特定的Thing 的用例。

(点击放大图像)

上下文管理层（Context Management Layer）定义了 RILA 中的核心业务逻辑，并负责完成这 6 种任务：

定义 Thing 的目标。
获取其他 Thing 的上下文情境。
为 Thing 生成（自有的）上下文情境。
评估（自有的）上下文情境是否符合目标。
根据评估的规则触发各种行为，以促进目标的实现。
向其他 Thing 发布上下文情境。

(点击放大图像)

根据以上的任务，我们可以将上下文管理层分解为8 种组件，如下图所示。

(点击放大图像)

规则引擎与人工智能（AI）：定义及管理上下文评估所必需的规则。包括目标（它本质上就是规则的一种集合）及用于创建上下文情境和行为的规则。

上下文情境集成模块：侦听其他Thing 的上下文情境，并与传入的上下文情境相集成。

行为集成模块：通过这个组件对其他Thing 所传入的行为进行评估，并传递给设备管理层。在这个过程中需要考虑到规则的问题，它定义了在哪种情境下可以将来自另一个物的行为进行传递，以触发制动器。

上下文情境创建模块：从系统中收集数据，并构建上下文情境。这一过程也可以由规则进行驱动。

行为创建模块：与上下文情境创建模块相似，在规则评估过程中触发的行为必须创建相应的行为对象。

上下文情境发布模块：为Thing 集成层提供上下文情境。根据实现的复杂度不同，上下文情境发布者可以为已订阅的不同Thing 提供一系列的上下文情境，或者为所有Thing 提供一个单一的上下文情境。上下文情境发布模块必须注意其他Thing 的数据权限级别。只有可信的其他Thing 才能够收到经过选择的上下文信息。此外，该模块还要负责定义上下文情境模式，这些模式需要与其他订阅的Thing 进行通信，它将评估某个Thing 是否能够与其他Thing 进行通信。

行为发布模块：与上下文情境发布模块类似，该模块负责将行为传递给Thing 集成层，让其他Thing 能够与行为进行通信。此外，行为模式也是由这个组件负责管理的。

上下文评估模块：对使用（现有的）上下文情境的规则进行评估，并触发那些与底层的设备或行为创建模块进行通信的行为。行为创建模块将把这些创建的行为传递给行为发布者，后者负责将行为传递给其他Thing。评估规则的一种简单方式是为由规则引擎所定义的规则构建相应的决策树。

具体的架构与所提供的功能的复杂度很大程度上取决于所开发的Thing 的具体用例。对于在智能方面要求较低的Thing（例如一台冰箱），规则引擎与人工智能组件也不必设计得很复杂。而对于需要从其他设计中收集上下文信息的Thing 来说，这些组件将变得非常复杂。高复杂性的例子包括数据科学以及数据挖掘技术。

Thing 集成层（Thing Integration Layer）将负责找到其他物，并与其进行通信。

一旦两个 Thing 找到彼此之后，他们就需要经历一种注册机制。Thing 集成层必须评估与另一个 Thing 之间的通信是否可能。因此，必须对上下文情境及行为模式进行比较，这一功能是由上下文管理层所提供的。

如果对于模式匹配的评估结果是正面的，那么该 Thing 就能够向另一个 Thing 发送创建新的上下文情境或行为的通知。传递给其他 Thing 的上下文情境和行为将由上下文管理层提供。

Thing 的注册必须由一个集中式的组件，或是由 Thing 本身完成（例如自发现的网络扫描）。

(点击放大图像)

用户将通过应用集成层（Application Integration Layer）与物进行连接。（直接）建立在RILA 架构上的应用属于这一层。可以将应用的集成看做一个服务层，甚至是一个简单的UI。这一层具体的实现取决于实际的用例。

到此为止，我们终于讲完了每个层的作用。现在让我们来面对那些跨层的挑战，首先从安全层开始。在构建IoT 系统时，我们必须在每个层上全盘考虑安全性问题。系统必须找到攻击的来源，以找到合适的安全标准。

(点击放大图像)

我们可以列举出以下攻击来源：

用户：终端用户有可能会成为一种攻击来源，因为这种攻击有可能会人为地、或是无意地影响整个系统。这种类型的攻击中最常见的方式是钓鱼攻击，即尝试从受攻击者那里获取敏感信息。

Web 界面：如果应用本身提供了一个 web 界面，那么它就有可能遭受到一些“传统的”攻击，例如 SQL 注入或 XSS 攻击。 OWASP （开放式 Web 应用安全项目）列举了网站最容易遭受的 10 种攻击的场景。

Thing：智能设备经常会通过某个应用与外部系统进行通信，而这种应用依赖于某种形式的操作系统。这就存在两种主要的受攻击的可能。一是应用本身或许没有采取适当的安全机制，二是底层的操作系统可能会被侵入或感染。

低层次的硬件组件：在考虑硬件组件及其提供的安全措施时，用户必须考虑到计算能力的问题。一个主要的风险在于低运算能力的设备不具备进行安全加密通信所需的 CPU 能力。在支持多个传感器的场景中，系统可以选择消除异常值，以获得一个准确的值，但这种方式无法保证安全性。如果由传感器所提供数据的准确性对于系统来说十分重要，那么则需要使用更强大的硬件，而这将使系统的成本上升一个数量级。

通信信道：对于通信信道的安全性设置取决于所使用的协议，我们将讨论与 IoT 相关的协议，以及这些协议为通信的加密所提供的功能。

RFID 与 NFC：标识与读取装置之间的通信是通过无线连接实现的，它很容易被窃听，因此对于数据的加密至关重要。当前能够保证足够安全性的对称式加密算法包括 3DES 与 AES-128。在向新的标识写入数据时，应当更改默认的认证密钥。对于标识的密钥管理是由控制读取装置的系统所完成的。RFID 标识本身具有很大的差异性，因此在购买时必须要考虑到安全性的问题。举例来说，Mifare Plus 标识就是 Mifare Classic 标识的一个升级版本，因为前者提供了基于 AES-128 的加密功能，而 Mifare Classic 标识使用了一种具有专利权的、基于 48 位的密钥的算法，但这种算法已经被攻破了。
Zigbee： Zigbee 设备与应用之间的通信信道是安全的，因为它所采用的加密算法是 AES-128。但与对方所进行的初次密钥交换必须被视为不安全的。当某个新的设备加入网络中时，密钥将以明文的方式进行发送，只要时机掌握好，就有可能被嗅探工具所捕获。
Thread：两台 Thread 设备之间的通信将由 AES 加密保证安全性，一台新设备与应用之间的密钥生成将通过一种密钥交换算法保证安全性。

攻击来源也可以分组为更为技术性的攻击来源，它们将针对系统中的特定组件，包括：

认证
授权
真实性验证：信息的签名
密钥交换策略
加密
配置 —— 糟糕的或默认的配置可能会造成安全威胁
第三方库 —— 可能会包含安全隐患，而如果没有及时更新，还可能包含一些已为人所知的漏洞。
网络安全

下图中的安全性三角形展现了在根据用例选择合适的安全性时所遇到的困境。

这个安全性三角性一定程度上反映了每个用例都需要面对的一种妥协。你只能根据你的目的及需求，在三角形所代表的安全性、成本与业务需求之间选择其一。让我们看一下几个例子：

示例 1：Acme 银行建立了一个银行金库：在这个用例中选择安全的硬件是至关重要的，这方面没有商量的余地。为了实现对业务与安全性需求的最大涵盖，成本必然会极大地上升。

示例 2：农场主 Billy Bob 希望通过某些高大上的传感器，在他的智能手机上了解收成的情况，但他对于安全性没有很高的要求。目前来说，农场主 Billy Bob 的需求确实已经满足了，他只用了较少的成本，并且结果令他满意。不过，这种好日子等到另一个农场主小 Jimmy 的儿子小小 Jimmy 开始学习计算机工程之后就到头了……

因此，为整个架构找到合适的安全措施永远像是走钢丝一样，因为业务需求和成本总是和高度的安全措施相抵触的。此外，某些技术需求可能会限制我们使用最高级安全措施的能力，例如运算能力不足的设备在发送数据包时可能无法接受某种程度上的额外开销，因为这意味着要消耗更多的资源。

到此为止，我们即将结束对于引用架构的介绍。通过本文，我们希望能够为你展示如何将一个 IoT 系统分解为更具体的层次。上下文感知的计算技术将使这个世界中的某些部分更容易理解。在后续的文章中，我们将为你展示如何通过本文介绍的 RILA 参考架构派生出对应的用例，以更完整地了解 RILA 如何实际地帮助我们实现 IoT 系统。