在上一篇中，曾经介详细绍过IoT参考架构RILA（Reference IoT Layered Architecture）的方方面面。当时介绍了该架构的每个层面，并提到后续将有另一篇文章介绍如何将该架构的不同层面对应到现实用例中。
当时承诺的后续文章终于有下文了，本篇我们将侧重于这一参考架构中的架构和概念实现。需要注意的是，我们不能随便挑选一个参考架构并立刻“尝试实现”，而是需要将其作为一种“样式”，据此定义要在IoT“系统”中使用的不同组件。乍看之下具体实现的结果可能与参考架构本身的结构有较大差异，但如果谨慎地将架构与所要实施的组件一一对应，最终将获得完全相同的结果。
为了将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应用程序的过程中必不可少的一些组件。通过明确具体用例所要实现的功能规范，就可以确定参考架构中不同组件的具体设计方式。通过功能层面上对用例和设计进行结合，即可确定最终的技术规格和实现方法。随后便可结合专业技能确定将现有平台用于何处才能提供一个或多个参考架构组件所要实现的功能，甚至如何使用现有平台组成某些用例所需的整个技术堆栈。
转载声明：本网部分文章或图片来源于公开网络资料，本网转载使用出于传递更多信息和供人学习之目的。如转载涉及版权方面的问题，请作者及时与本网联系，本网将按法律规定予以及时删除或者采取其他方式妥善处理
