【干货】一篇文章读懂物联网具体架构，推荐收藏！

导读：本文将为你分析物联网的架构方法，全文分为两部分，第一部分从一个抽象的角度了解IoT的参考架构，将涵盖更具体与完整的架构中的各种定义，而第二篇文章将通过实际的用例应用这种架构，然后分析具体的架构与所选择的用例的实现。

第一篇

完整的架构中的各种定义

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

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

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

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

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

　　1.Thing：这是我们在每日生活中所接触到的某个物体，它就存在于我们的生活环境中。Thing既可以是一辆汽车或一台冰箱，但也可以被抽象为一个完整的房屋或是城市，这取决于我们的用例。

　　2.设备：可以表示一个传感器(Sensor)、一个制动器(Actuator)或是一个标识(Tag)。通常来说，设备是Thing的一个组成部分。Thing将处理设备中的上下文信息，并将选定的信息与其他Thing进行通信。此外，Thing还可以将行为传递给制动器?/p>

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

　　1.Thing与设备的互操作性以及集成组件。

　　2.上下文感知计算技术，例如上下文模型或行为模型的定义，以及规则引擎的目标定义。

　　3.与整个架构相关的安全性指南。

　　在某种形式上，当前的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种任务：

　　1.定义Thing的目标。

　　2.取其他Thing的上下文情境。

　　3.为Thing生成(自有的)上下文情境。

　　4.评估(自有的)上下文情境是否符合目标。

　　5.根据评估的规则触发各种行为，以促进目标的实现。

　　6.向其他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相关的协议，以及这些协议为通信的加密所提供的功能。

　　1.RFID与NFC：标识与读取装置之间的通信是通过无线连接实现的，它很容易被窃听，因此对于数据的加密至关重要。当前能够保证足够安全性的对称式加密算法包括3DES与AES-128。在向新的标识写入数据时，应当更改默认的认证密钥。对于标识的密钥管理是由控制读取装置的系统所完成的。RFID标识本身具有很大的差异性，因此在购买时必须要考虑到安全性的问题。举例来说，Mifare Plus标识就是Mifare Classic标识的一个升级版本，因为前者提供了基于AES-128的加密功能，而Mifare Classic标识使用了一种具有专利权的、基于48位的密钥的算法，但这种算法已经被攻破了。

　　2.Zigbee：Zigbee设备与应用之间的通信信道是安全的，因为它所采用的加密算法是AES-128。但与对方所进行的初次密钥交换必须被视为不安全的。当某个新的设备加入网络中时，密钥将以明文的方式进行发送，只要时机掌握好，就有可能被嗅探工具所捕获。

　　3.Thread：两台Thread设备之间的通信将由AES加密保证安全性，一台新设备与应用之间的密钥生成将通过一种密钥交换算法保证安全性。

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

　　1.认证

　　2.授权

　　3.真实性验证：信息的签名

　　4.密钥交换策略

　　5.加密

　　6.配置 —— 糟糕的或默认的配置可能会造成安全威胁

　　7.第三方库 —— 可能会包含安全隐患，而如果没有及时更新，还可能包含一些已为人所知的漏洞。

　　8.网络安全

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

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

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

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

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

第二篇

架构的实际应用

为了将RILA与实际用例相互对应，我们从不同行业挑选了两个用例，这两个用例可能很快就会变为现实。下图展示了第一个用例，就叫它“冰箱”用例吧：

这个用例的基本想法是在可能出现电力峰值(电网丢负荷)的时候自动触发(全城或部分地区的)电冰箱的制冷操作，借此降低电力峰值对电厂造成的危险。因此该用例的目标在于由电厂触发大量智能电冰箱的“制冷”操作。上图显示的虚线代表冰箱到电厂的(可选)反馈环路，借此电厂可以评估共可以触发多少电冰箱进行制冷，并借此确定冰箱的数量是否足以降低峰值，或是否有必要采取其他(可选)措施。下表列出了该用例涉及的对象，用例想要实现的目标，前提条件，成功场景概括，以及后续情况：

　　涉及的对象最终用户，冰箱制造商，供电局，冰箱的板载系统，电厂的控制系统。

　　目标电厂控制系统 向 冰箱板载系统 发送制冷工作信号，让冰箱在某个同一控制的集中时间点开始制冷，避免出现电网丢负荷的情况。

　　前提条件冰箱制造商 和 供电局 共同制定一套通信协议，通过这个协议让冰箱接收控制信号，并发送相关状态信息。

　　成功场景概括最终用户 购买 冰箱制造商 生产的冰箱。

　　最终用户 配置冰箱连接到互联网。

　　冰箱的板载系统 连接到 电厂的控制系统 。

　　供电局的电厂控制系统 发现出现电力峰值，向 冰箱的板载系统 发送控制信号。

　　冰箱的板载系统 收到这个信号，判断冰箱内部温度是否足够低。

　　冰箱的板载系统 将即将制冷的信息发送给 电厂控制系统 。

　　电厂控制系统 收到 冰箱板载系统 发送来的信息，对其进行处理并保存起来。

　　冰箱板载系统 启动冰箱压缩机开始制冷。

　　后续情况冰箱板载系统 开始制冷， 电厂控制系统 知道冰箱已经开始制冷了。

　　冰箱板载系统和电厂控制系统需要构建并监视相关的上下文情境条件。这个用例中主要涉及两种条件：

　　电厂控制系统的上下文情境

　　冰箱板载系统的上下文情境

　　冰箱板载系统需要管理的上下文情境更为简单一些，通过这种上下文，冰箱板载系统可以决定是否需要制冷。电厂控制系统的上下文情境更为复杂，需要通过冰箱的上下文情境做出相应决策。然而在这个场景中，电厂的上下文情境无需对外发布，只要将操作命令发送至冰箱即可。

　　看过第一个用例后，可以考虑将我们的参考架构RILA与其进行对应。我们定义了包含下列6层内容的架构：

　　应用程序集成(Application Integration)

　　物件集成(Thing Integration)

　　上下文管理(Context Management)

　　数据管理(Data Management)

　　设备管理(Device Management)

　　设备集成(Device Integration)

　　下图展示了架构中不同层与这个用例的对应关系。

　　上图不同层使用不同颜色显示，分为黑色和灰色。灰色层通常可以用非常简单的方式设计而来，甚至在某些场景中是不需要的。

　　大致来看，两端都存在所有6层内容，冰箱和电厂需要通过某种方式实施这6层。然而具体实现的复杂度取决于可用条件和用例要实现的功能。为确定每种物件每层的设计和实施范围，需要对每种物件(或每种物件对应的领域，如果采用领域驱动的设计方法的话)都有所了解。这里需要注意，上图所示场景在具体描述上可能有所差异，对冰箱的上下文情境进行管理只是一个范例，实际情况可能更加复杂，因此用黑色表示。这个用例中需要使用“智能”的冰箱，而本例中我们设想的冰箱是相当“笨”的。参考架构与场景的映射是一回事，每一层的设计是另一回事。下文将介绍该场景中不同层面的具体设计。

　　在这个场景中，我们假设用户可以使用自己的智能手机与冰箱通信。为了与智能手机应用通信，冰箱必须具备应用程序集成层。另外可能还需要在供电局一端实施某种程度的应用程序集成。不过依然有必要考虑该用例是否需要涉及这个问题(毕竟本例只需要考虑电厂控制系统向冰箱发送控制信息)。

　　两端都需要实现物件集成，具体方式并不复杂。在这样一个原型中，物件发现模块可能相当简单，我们可以假设冰箱随时都能与电厂通信。最终通信连接的建立则可以使用成熟的规范。

　　在上下文管理方面，首先需要在冰箱的上下文情境和要向冰箱发送的操作指令之间达成一致。电厂端的上下文管理略显复杂，但冰箱端相对简单一些。电厂端在这里可以视作一个黑盒子，大部分情况下我们只需要将其与检测和预测峰值的现有系统集成即可。一旦检测到峰值便触发冰箱执行制冷操作，并通过物件集成将指令下发至已注册的冰箱。冰箱接到操作指令后开始判断是否需要制冷(在首个原型中可通过简单的时间约束实现)并将判断结果发回给电厂。

　　类似的数据管理机制在冰箱上实现起来很简单，但在电厂端略微复杂。冰箱基本上只需要记录什么时候温度足够低，什么时候需要再次制冷(可通过温度传感器实现)。电厂需要决定冰箱制冷到足够低的温度之后所耗费的电力是否可以降低峰值。如果还不够，则需要进一步执行后续的其他操作。

　　冰箱端还需要设备管理和设备集成层。电厂端可以假设已具备负责处理峰值预测和决策的系统，但该系统需要与我们的架构集成在一起(可通过应用程序集成或物件集成的方式实现)。

　　这里需要注意，为了让这个方案设计投入实用，还需要与两端(电冰箱制造商和供电局)的领域内专家进行合作，才能更好地理解这两个领域并开发出足够好的设计。

　　尽管我们的设计距离完善还很远，不过依然可以先来看看实现方面的创意(也许可以开始快速创建第一个原型)。上文提过，我们希望最开始的设置尽可能简单。目前已经有装备显示器和各种功能的冰箱，例如新一代 Samsung Family Hub ，此类型号的功能已经远远超出需求(不过依然可以用)。在这个场景中，制造商并没有为冰箱提供完整的平台，但提供了可与冰箱通信的智能手机应用。这样的冰箱需要具备：

　　自带互联网连接和通信接口，这样才能随时与电厂通信(物件集成)。

　　供用户通过智能手机访问的接口，这样才能让用户打开或关闭与电厂通信的功能(应用程序集成)。

　　相关传感器和逻辑，这样才能让冰箱在接到电厂指令后决定是否可以开始制冷。

　　实现首个原型的平台可以考虑配合使用Google App Engine和Google Brillo。虽然Brillo尚未正式发布，但已经可以开始设想基于Brillo操作系统的冰箱了。这里可以使用Google Cloud Messaging在智能手机、云冰箱，以及电厂之间实现通信。下图展示了使用Google Brillo和Cloud Messaging搭建的简化环境。请注意，在这里Google只是范例，使用Apple HomeKit、Windows Azure或开源平台也可以实现类似的效果。

　　在冰箱端我们将整个栈打包到Brillo中。对于物件集成层的通信，可以使用Cloud Messaging API。不过电厂在这里依然被看作黑盒子，因为电厂具体使用什么技术无关紧要(反正电厂里通常已经具备现成的系统)，我们只需要确保电厂的控制系统(或以此为基础的集成组件)能够实现Brillo和Cloud Messaging API所实施的通信标准即可。

　　当然整个系统也可以用相互独立的方式实现。拆箱即用的标准化，是诸如Google Brillo这样的平台所提供的优势之一，用户可以借此对整个系统轻松进行缩放。

　　至此已经完整介绍了第一个用例。为了证明这套参考架构的灵活性，下文将介绍第二个用例。从中也可以看到RILA所定义的“必备IoT组件”是如何融入整个场景的。

　　在第二个用例中，有一家销售汽车保险的保险公司希望更清晰地预测(从保险业务的角度来看)哪些客户是“良性”的，哪些是“恶性”的。这家保险公司希望使用驾驶行为数据实现这一目标(也就是所谓的 数据科学 )。该用例的大致情况如下图所示。

　　在第一个场景中，这家保险公司需要获得大量数据，并通过数据科学为保险业务定义“良性”和“恶性”司机的类别。这些数据并不需要对应到具体司机，匿名数据就够了。数据越多结果越精确。因此这家保险公司希望与汽车制造商合作以获得所需数据。

　　在第二个场景中，(通过对第一个场景进行扩展)这家保险公司需要根据投保人的个性化驾驶行为进一步定制每份车险的保险策略。这一过程由上图中虚线箭头所代表。

　　下表描述了该用例涉及的对象，用例想要实现的目标，前提条件，成功场景概括，以及后续情况：

　　涉及的对象保险公司、保险公司的系统、汽车制造商、汽车制造商的系统、车主、车载计算机

　　目标保险公司 收集有关具体车型尽可能多的匿名驾驶行为数据，借此针对具体车型的驾驶行为数据调整保险策略。

　　前提条件保险公司 和 汽车制造商 确定数据交换策略和涉及的车型。 保险公司 为 汽车制造商 提供的数据支付一定费用。 车主 通过匿名分享自己数据得到一定好处(例如 汽车制造商提供的低价维修服务)。

　　成功场景概括车主 购买一辆车。

　　车载计算机 询问 车主 是否要将驾驶行为数据匿名分享给 汽车制造商 (以及可能的第三方)。

　　车主 同意分享某些数据。

　　车载计算机 按照预定义的时间间隔，定期将匿名驾驶行为数据发送到 汽车制造商的系统 。

　　汽车制造商的系统 存储驾驶行为信息，并通知 保险公司的系统 某一车型有新数据可用。

　　保险公司的系统 通过 汽车制造商的系统 收集驾驶行为数据，并将其存入决策工作使用的数据池。

　　保险公司 的系统将新数据以功能的形式集成于保险策略使用的预测模型。

　　后续情况保险公司 可以使用驾驶行为数据更详细地计算保险策略。(随后即可将其用于为保险公司销售人员提供指导等用途。)

　　这里我们打算专注于第一个场景。与冰箱的用例类似，我们可以将RILA的不同层面映射为下图所示的系统组件。

　　对于保险公司的用例，只需要在汽车中实施完整的RILA堆栈，因为需要集成的设备都在汽车中，其他操作都是在数据传输层面上进行的。在这里可能有人会质疑我们对“物件”的定义。只有设备才算是“物件”吗?我们的定义并不这样认为，并非只有设备才是物件。不过此处的合理推论是，并非所有物件都必须具备设备集成和设备管理层(没有设备，当然也就不需要进行设备集成和管理)。

　　汽车需要在应用程序集成层具备一些接口，这样车主才能与系统通过某种形式通信(车载系统通常已经具备这样的能力)。数据传输至汽车制造商的系统后，只需要进行少量的上下文情境管理、数据管理，以及物件集成工作即可实现用例需求。保险公司(以及汽车制造商的系统)可能也需要进行应用程序集成，因为还需要使用这些数据执行某些任务，例如运行预测模型的软件必须能通过某种方式访问这些数据。

　　这个保险公司用例的实现想法在于：汽车的车载计算机可以充当一种应用平台。随后用户即可下载保险公司(与汽车制造商合作)提供的应用，借此让用户控制什么可以分享，什么不能分享。取决于用户的分享意愿，可以由保险公司或汽车制造商为车主提供一定的好处(这就为我们提供了一种理想的业务模式)。一旦实现最终的个性化，就可以通过了解上下文情境的保险策略实现“驾驶即付费”的业务模式，并进一步扩展为“按照驾驶方式付费”的模式。

　　本文介绍的这两个用例较为宽泛，除了所描述的场景外，通过本文提供的用例还可以构思出很多不同使用场景。为了针对不同用例打造真正实用、有价值的设计，还需要对相关领域有所了解。

　　确定用例场景后，就可以确定要在参考架构(例如RILA)中使用哪些IoT组件。通信和安全措施的实施方式所实现的标准化程度越高，就能越容易地将IoT系统与以后部署的其他IoT系统相集成。无论其他保险公司或汽车制造商打算使用保险公司用例，或其他电厂或冰箱(制造商)打算使用冰箱用例，只要具备确认有效的合适结构(例如类似Google Brillo这样的机制)，集成工作就会变得更简单。参考架构只是为了向大家提供一种通用的模式，帮助大家避免在实际开发中“漏掉”某个重要的组件或设计因素。

　　总之需要强调的是，最重要的第一步始终是一开始就从功能层面上定义要实现的用例，随后再考虑具体的技术规范细节。

　　为了确定希望通过系统实现的最终目的，还要明确定义涉及的对象和想要实现的目标。虽然这是一种众所周知的范式，但对IoT世界中的应用程序和系统开发工作，这一点尤为重要，因为具体用例通常更复杂，包含的场景也更多样。领域驱动的设计指南可以帮您实现更有价值的灵活设计。

　　通过诸如RILA等参考架构，我们可以了解实现IoT应用程序的过程中必不可少的一些组件。通过明确具体用例所要实现的功能规范，就可以确定参考架构中不同组件的具体设计方式。通过功能层面上对用例和设计进行结合，即可确定最终的技术规格和实现方法。随后便可结合专业技能确定将现有平台用于何处才能提供一个或多个参考架构组件所要实现的功能，甚至如何使用现有平台组成某些用例所需的整个技术堆栈。