本文是两篇系列文章中的第一篇，我们在将这一系列文章中首先从一个抽象的角度了解IoT的參考架构，然后分析详细的架构与所选择的用例的实现。
第一篇文章将涵盖更详细与完整的架构中的各种定义。而第二篇文章将通过实际的用例应用这样的架构。
我们正处在一个崭新的互联世界的入口，处于“物联网”（IoT）或者说是“第四次工业革命”浪潮之中的公司正在开发一种新型的网络。让我们在每日生活中所接触到的事物可以实现互通。IoT实现了“物”（Thing）的互联，通过信息交换的方式。为用户完毕各种任务。各种新颖的思想将逐渐变为现实，比如让家里的冰箱不仅可以与你的智能手机通信，甚至还可以与生产者的server场或是能源发电厂进行通信。
在背后推动这次新技术与通信变革的公司来自于各行各业。不仅像Google、微软或Apple这种大数据软件巨头正走在这条道路上，此外还有保险公司巨头、外围设备厂家乃至汽车制造商也纷纷投入IoT的怀抱。
在各种不同的“Thing”之间实现通信的关键在于实现标准化。
标准化在研究环境中说起来非常easy。但要在真实的世界中实现却是相当困难的。參考架构对于实现标准化可以带来非常大的帮助，在对于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应用安全项目）列举了站点最easy遭受的10种攻击的场景。
Thing：智能设备常常会通过某个应用与外部系统进行通信，而这样的应用依赖于某种形式的操作系统。这就存在两种基本的受攻击的可能。
一是应用本身也许没有採取适当的安全机制，二是底层的操作系统可能会被侵入或感染。
低层次的硬件组件：在考虑硬件组件及其提供的安全措施时。用户必须考虑到计算能力的问题。一个基本的风险在于低运算能力的设备不具备进行安全加密通信所需的CPU能力。
在支持多个传感器的场景中。系统能够选择消除异常值。以获得一个准确的值，但这样的方式无法保证安全性。
假设由传感器所提供数据的准确性对于系统来说十分重要，那么则须要使用更强大的硬件，而这将使系统的成本上升一个数量级。
通信信道：对于通信信道的安全性设置取决于所使用的协议，我们将讨论与IoT相关的协议，以及这些协议为通信的加密所提供的功能。
-
RFID与NFC：标识与读取装置之间的通信是通过无线连接实现的。它非常easy被窃听。因此对于数据的加密至关重要。
当前可以保证足够安全性的对称式加密算法包含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開始学习计算机project之后就到头了……
因此。为整个架构找到合适的安全措施永远像是走钢丝一样。由于业务需求和成本总是和高度的安全措施相抵触的。
此外，某些技术需求可能会限制我们使用最高级安全措施的能力，比如运算能力不足的设备在发送数据包时可能无法接受某种程度上的额外开销。由于这意味着要消耗很多其它的资源。
到此为止。我们即将结束对于引用架构的介绍。通过本文，我们希望可以为你展示怎样将一个IoT系统分解为更详细的层次。上下文感知的计算技术将使这个世界中的某些部分更easy理解。在兴许的文章中，我们将为你展示怎样通过本文介绍的RILA參考架构派生出相应的用例。以更完整地了解RILA怎样实际地帮助我们实现IoT系统。