面向 IoT 软件工程的关键抽象

关键总结

• 当今 IoT【译注 1】系统的设计运用了诸多常见的概念。例如，想要连接的各种“事物”、进行事物连接的基础设施以及允许调节和配置系统的服务和应用程序。
• 对于定义 IoT 系统来说，首要的抽象是系统利益相关者，其中包括本地管理者、全局管理者以及用户。
• 利益相关者和用户定义了系统的一系列需求，可以被分为政策、目标和功能这几类。
• 单个的事物或者一组事物可以被看做是虚拟身份（avatars），它来提供统一身份认证、服务的接入点以及管理目标和事件的方法。规模更大的一组虚拟身份能够组成联盟（coalitions），它们用于统筹更广泛的目标和政策：联盟是针对更广泛的目标和政策编排起来的更大组的虚拟身份。

这篇文章首次刊发于 IEEE Software 杂志。 IEEE Software 对当前战略性技术问题提供可靠的、业内同行的评述信息。为了应对可靠、灵活地运行企业的挑战，IT 管理者和技术领导者需要依靠 IT 专家来获得最先进的解决方案信息。

综合目前 IoT 的一系列研究可以帮助我们构建与 IoT 系统和相关应用程序系统开发的关键抽象。这样的框架能够作为面向 IoT 的软件工程的指导方针。

尽管目前对 IoT 进行了大量研究，但是将 IoT 进行系统实现的技术还远未成熟。早期的研究主要集中在通信和交互操作性上 1。最近，研究人员试图促进将资源和服务整合至规范软件定义的分布式服务中。例如，WoT【译注 2】的视角 2 是，旨在采用标准的 Web 技术来开发统一的 IoT 服务。WoT 可能会与基于代理计算 3，4 的概念相结合，这可能会成为未来 IoT 技术的基石。同样地，存在几种方法（例如，在支持中间件 5，6 和编程 7 方面）来协助 IoT 系统的构建和相关应用程序的开发。然而，目前仍然缺失一种基于同一套抽象、模型和方法论的统一的开发方法 8。

在这里，我会综合现有的提议和场景，来构建与复杂 IoT 系统和应用程序相关的关键共同特性。之后，我会利用这些特性来确定出一些关键的软件工程抽象，IoT 系统和应用程序可以围绕着这些抽象进行开发。也就是说，这些抽象可能会成为一般的面向 IoT 软件工程学科的基础，其中包括详细的模型、方法论和开发准则（尽管这个分析和定义不在本文的范围之内）。

为了进行举例说明，我提出了一个具体的案例研究场景：一个部署了 IoT 的酒店和会议中心。假定酒店的基础设施（例如照明和供暖系统）和各种服务设施（客房、会议室机器相关电器设备等）都密集地连接着传感器和执行器。在这个场景中，不同的角色（从酒店经理到酒店客人或者会议的参加者）都可以为建立 IoT 服务做出自己的贡献。尽管这个场景看起来很简单，但是它仍然展现出了更为复杂的场景中的特征和挑战，例如像智能城市的能源管理或者城市交通管理这样的复杂场景。

共同特征

在当前 IoT 系统设计和开发中，我找出了如下共同特征。

事物（Things）

IoT 视角中的“事物”可能包括大量物理对象、有关场所和人员。

我们可以通过使用低成本的无线设备来追踪和控制物理对象和场所。我们可以将基于低成本通信协议的简易 RFID 标签或者蓝牙模块附加到任何类型的物理对象上，用于跟踪其位置和状态，使其具有数字信息的属性。集成了环境传感器或者运动传感器的更先进设备能够监测与物理对象相关的之前的或者当前的活动。另外，物理对象可以包含能够远程控制它们的配置或状态的数字执行器，它们也有可能进行自主决策和控制。

例如，酒店场景可能具有以下功能。房间中的物理对象，如遥控器，可以包含有 RFID 标签来传达它的存在和位置。会议室的投影屏幕可以包含有类似 Arduino 的控制器，它可以让人们使用手机就可以控制它的升高和降低。会议室窗帘能够根据室内的活动自动调节。屋内的墙壁能够根据需要改变其布局。从这个角度来说，自主机器人（机器人化的物理对象 9）能够被看作是智能事物界的顶端生物。

人除了作为物联网技术中的用户之外，还是物联网视角中的首要的实体。仅仅因为人们只要有一个手机，他们的活动和位置就能被感知到，并且他们可以被要求在该环境中从事各种活动或者提供这些被感知的信息。在酒店的场景中，酒店管理层可以持续监测人员的位置和活动，以最有效的方式来应对紧急情况。

软件基础架构

为了使得各种事物能够服务于我们的需求，我们需要能够支持不同事物“粘合在一起”的软件基础架构（IoT 中间件 1），并且它还需要提供访问物联网系统及其功能的方法。

粘合（Gluing）：把不同的事物粘合到一起涉及到四个主要的技术问题。第一个是互操作性。异构事物的交互需要一套共享通信协议和一套数据表示方案，这涉及到了不止一种识别事物 1 的方法。对于这个问题的研究可以追溯到早期对 IoT 的研究，那时存在几种提议，为之后通过的标准奠定了基础。

第二个问题是语义。必须要为各种概念定义通用的语义，以实现事物间的合作和整合。关于定义通用语义的各种提议已经提出了，它们是基于标准 Web 技术而提出的，同时也是基于适用于物理环境以及社会场景的本体论【译注 3】而提出的 10。

第三个问题是发现、组织形成和协调。IoT 系统功能来源于对于各种事物的协调开发，这可能涉及到了不同的用户和利益相关者。在酒店场景中，配置会议室中幻灯片的放映涉及到投影仪、照明系统、会议组织者和演讲者。这就需要一种发现和建立事物与事物、事物与人物之间联系的方法来协调他们之间的活动 11。

最后一个问题是环境感知和自适应。系统组件具有不可靠性和移动性（例如，酒店会议中心的椅子或者活动展板可能会来回移动、被挪走或者被放在没有无线网络连接的地方），这使得预测哪些事物可用以及可用多久变得不可能。这就需要一种能够动态适应其环境的发现和协调机制 4。

访问（Access）：用户访问事物的功能和能力的方法目前由 WoT 视角所主导。这个想法是要暴露出在 REST（Representational State Transfer，具象状态传输）服务方面的事物的服务和功能，从而采用 Web 技术来发现事物以及提供协调的群组服务。关于中间件基础架构，大多数提案都意识到需要对三个关键功能进行整合。第一个关键功能是，支持 WoT 视角的基本基础架构（即使用简单的服务来暴露出事物）。第二个关键功能是，根据具体的协调模型来支持事物的发现（以及相关服务的发现）和事物群组活动的协调。第三个关键功能是，使服务和应用程序能够以环境感知、无监督的方式来进行调整 1，5，7，12。

服务和应用程序

术语“IoT 系统”通常是指一组 IoT 设备及其中间件基础架构，中间件是用来管理其网络和交互的。特定的软件能够合理地部署于 IoT 系统之上，以便协调系统活动，来提供具体的服务和通用应用程序（或者应用程序套件）。

提供具体的服务指的是使利益相关者和用户能够访问和利用事物并且管理它们的传感信息或者执行能力。这包括能够访问一组事物并且协调其能力的协调服务。例如，在酒店会议室中，除了提供对于单独电器的访问和控制之外，协调服务还需要访问和调节照明系统、光传感器和窗帘，例如将会议室由演示模式切换到讨论模式。

另一方面，通用应用程序或者软件套件是更全面的软件系统，它能够：

• 调节整个 IoT 系统（或者其中的某些部分）的正常运作，来确保其具体的整体行为。
• 提供统一的服务，以便访问整个系统和其配置（可能会对其进行访问）。

在酒店场景中，应用程序能够控制整个供暖和照明系统，并且会为酒店工作人员重新配置其服务以及相关的参数。

根据这个场景，你可以考虑下其中服务仅存在于某些通用应用程序的 IoT 系统或者作为独立软件进行部署的 IoT 系统。

关键抽象

通过对共同特征的分析，我找出了以下对于 IoT 系统开发的关键抽象（如图 1）。

(点击放大图像)

图1. 物联网（IoT）系统工程的关键抽象。这些抽象能够作为通用的面向IoT 软件工程的基础，其中包括详细的模型、方法论和指南。

利益相关者和用户

分析一个系统首先要做的就是找出其中的参与者：系统利益相关者和用户。这些人员或者组织拥有、管理或者使用这个系统和它的功能。系统的需求应该从他们那里获得。

在IoT 系统中，IoT 服务和应用程序的不同以及支持它们和管理事物的中间件的存在使得能够识别出以下三个针对行为者的关键抽象类别。

第一个，全局管理者是IoT 系统和其基础设施的拥有者或者是具有控制权的代表，他们针对应用程序和服务的配置和功能进行控制并且制订相应的政策。在酒店场景中，全局管理者对应于按照酒店管理层的指令对酒店IoT 系统进行控制的系统经理，例如，控制供热水平或者监控策略。

第二个，本地管理者是对IoT 系统的某一部分进行控制的管理者或者代表（或是永久的，或是临时的）。他们有权在该部分进行本地控制和制订政策。在酒店场景中，本地管理者可能是酒店客人，他们可以控制他们房间内的IoT 系统，他们可以根据自己的需求调整本地参数并且享受服务。或者，本地管理者也可能是会议组织者，他们负责管理和配置会议室中的服务。

最后一个，用户是对IoT 应用程序和服务的整体配置访问受限的人员或者群组。也就是说，他们不能对IoT 强加政策，但是他们仍然有权利享受服务。在酒店场景中，用户包括有权访问会议设施（例如，将演示文稿上传到投影仪）的会议代表，但是他们无权修改会议室的配置。

这三类人员是具有通用性质的，在酒店场景之外也同样适用。例如，在智能城市的能源管理场景中，他们可以分别对应于城市管理者、房主或者店主、私人公民或者游客。在城市交通管理场景中，他们可以分别对应于交通管理者、停车场所有者或者共享汽车公司、私人司机。

需求：政策、目标和功能

一旦确定了关键参与者，对IoT 系统的分析就不能简单简化为仅仅了解事物或者一组事物需要提供的服务。分析还必须要考虑到更全面的需求获取方法。

对于功能性需求，分析应当考虑到那些具有基本传感或者执行功能的事物：那些能够自主执行与其社会物理环境的特性和角色相关长期活动的更智能的事物。这些事物包括简单的清洁机器人到更复杂的自主个人助理9。

对于非功能性需求，IoT 应用程序不应该仅仅提供一套协调工作的功能。它们还应当根据系统利益相关者的政策和目标持续全面监管IoT 系统活动。

因此，除了分析需要提供的具体功能之外，分析还必须确定与服务和应用程序相关的政策和目标，也就是说，要在系统操作场景努力达到各种事务的理想状态。

因此，要找出的需求的关键抽象类别是政策、目标和功能（详见图2）。

(点击放大图像)

图2. IoT 参与者以及它们在定义和发掘IoT 系统需求中的角色。需求的通用类别分别是政策、目标和功能。

政策体现的是整个IoT 系统的（全局政策）或者其中一部分的（本地政策）所需的长期配置或者正常运行状态。在酒店场景中，我们可以定义全局政策，比如说，指定每个房间的最大占有率并且使用本地摄像机对其进行监控，在必要的时候监控人们在不同房间之间的走动。政策总是积极主动地执行。全局和本地政策的定义一般由全局管理者决定，尽管本地管理者也可以被授权在系统的本地部分执行临时的本地政策（如果这个政策与全局管理者所执行的政策没有冲突的话）。

目标表示的是在具体情况下可以或者应该达到的理想状态。目标的激活可能依赖于具体的前提条件（某些特定事件的出现）或者一个特定的用户操作（也就是说，目标的激活可以作为一项服务进行调用）。典型的后置条件（停止对目标的追求）是实现了目标本身。例如，在酒店场景中，当检测到火灾（前提条件）时，疏散程序就会被激活；它的目标（和后置条件）就是将建筑物中的人们进行快速疏散。为了达到这个目标，程序的激活可以触发电子屏幕和可控制的门来合理地引导大家出去。对全局目标和本地目标的定义一般会分配给全局管理者，有时也会分配给本地管理者。用户有时会被授权激活简单的本地目标（或与单独事物相关的目标）以作为服务。

功能定义了各种单个事物、一组事物或者可用的特定资源的传感、计算或者执行能力。功能通常能够以服务的形式进行访问，有时会涉及到协调对众多事物的功能的访问。在酒店场景中，例如，会议室中电器的各个功能（拉开、拉上窗帘或者显示、更改投影仪中的幻灯片），以及通过协调各个事物来实现更复杂的功能（例如，通过拉上窗帘和关闭灯光来布置演示环境）。功能和相关服务通常由全局管理者进行定义，也有可能由本地管理者进行定义，但是它也会由IoT 系统的日常用户所发掘出来（例如酒店客人和会议参与者）。

虚拟身份（Avatars）和联盟（Coalitions）

实现功能、目标、政策所涉及到的事物可以对应于各种各样的对象和设备（除了地点和人员），每一个对象或设备都依赖于大量的技术和能力。因此，从“粘合软件基础架构”和软件工程的观点来看，有必要定义更高层次的抽象来处理应用程序和服务的设计与开发以及协调利用IoT 的各系统组件。

有关于编程模型和中间件的大多数提议通过在某种软件抽象2 下虚拟化单独的事物来承认有定义更高层次抽象的必要。WoT 视角根据通用资源来抽象出事物及其功能，并且通过RESTful 调用进行访问 ，如果外部HTTP 网关不直接支持HTTP 接口13，则可能会将外部HTTP 网关直接关联到单个事物上。另外的一些方法提出可以采用标准的面向服务的架构（SOA）14。此外，一些提议还考虑将自主软件代理（autonomous software agents）与单个事物3 关联起来，这种方案尤其适合于某些被自主追求的目标可能同事物有所关联的情况。

除此之外，考虑到提供特定的服务和应用程序，一些事物作为单独的个体就像我之前所说的那样，是毫无意义的。这些事物应该被视作一个整体中的一部分，并以一个协调整体的方式提供服务。这适用于各功能相辅相成并且必须协调工作的情况3。它同样适用于多个等效设备必须一同工作、需要从个体存在中抽象出来的情况4，12。

考虑到这些因素，为了综合不同的提议，我建议统一对虚拟身份（avatars，或者一组虚拟身份）和联盟（coalitions）的抽象（见图3）。

(点击放大图像)

图 3. 虚拟身份的组合。 （a）单独的虚拟身份。（b）一个虚拟身份组。（c）一个虚拟身份联盟。 虚拟身份是对用于定义独一无二的功能或服务的单个事物或一组事物的一般抽象。

虚拟身份和群组。借用 Michael Mrissa 及其同事的术语 6，我将虚拟身份（avatar）定义为用于定义独一无二功能或服务的单独事物以及一组事物（也有可能是一组其它虚拟身份）的一般抽象。虚拟身份是从特定的物理、社会、技术特性中所抽象出来的。它们有四个主要特点：

• 虚拟身份具有独一无二的身份，并且虚拟身份是可寻址的。代表着一个群组的虚拟身份并不一定会隐藏内部所包含的虚拟身份，但是它会具有自己独一无二的身份。
• 服务表示的是利用虚拟身份独特功能的接入点。根据一个服务抽象出的事物和功能，这种对功能的利用可能涉及到触发和指导传感、计算或执行功能，或访问被管理的资源。
• 从希望事物达到的状态的意义上来说，目标与虚拟身份是有所关联的。目标可能具有自主活动的前提条件，或者可能被用户或其它虚拟身份显式激活。
• 事件（Event）表示的是虚拟身份能够检测到的特定状态，并且有可能是其它虚拟身份或者用户感兴趣的特定状态。那些虚拟身份或用户可以订阅这些事件。

在酒店场景中，单独的虚拟身份可能会与会议室设备以及各个物品相关联，例如投影仪和窗帘。虚拟身份群组可以通过协调几个设备或物品来帮助搭建一个演示会议室。这样的群组可能能够感知房间内的事件（例如门被打开）并作出相应的响应（例如，保持特定的照明条件）。

显然，虚拟身份群组需要一个内部协作方案来协调它所包含的事物（或者其它的虚拟身份）的活动或者功能。这样的方案定义了事物和虚拟身份之间其活动的内部工作流程以及它们受到限制或条件。该方案也可能涉及到上下文信息，为的是使群组活动能够做到上下文感知（例如，用于搭建演示会议室的服务必须要适应当前的照明条件）。大多数的 IoT 中间件和编程方法都需要明确其需求以定义协作方案以及有关访问和使用事物（或事物群组）的限制 4，5，14。

联盟（Coalitions）。借用多代理系统领域的术语 3，我将联盟定义为一组虚拟身份（a group of avatars），这一组虚拟身份能够协调彼此的活动以达到具体的目标或制订具体的政策。因此，联盟不同于虚拟身份群组（avatar groups），它不一定具有唯一的身份，也不一定提供服务。

联盟必须按照协作方案来进行定义，其中包括：

• 成员规则（membership rules）规定了虚拟身份能够或应该进入联盟的条件。从单个虚拟身份的角度来说，进入联盟的行为可以通过激活特定的目标来表示，这些目标的前提条件都是对应于成员规则的。
• 协作模式（coordination pattern）定义了交互协议以及联盟中成员进行交互的共享策略。这个模式可能包含激活联盟的目标的显式表示。然而，这样的一个目标也可能隐含于协议和策略的定义中。
• 协作法则（coordination law）表示的是联盟中虚拟身份的行为和交互的制约因素。这包括了订阅联盟中发生的事件并对其做出反应的可能性。

虚拟身份联盟的观点有助于实现政策，或者依据虚拟身份的相似性将它们聚集成群组，从而使它们以面向任务的方式共同工作，而不必强制它们以特定的以身份为中心的协调模式进行工作。这与传感器网络以及 IoT 系统中的集体自组织编程的思想是吻合的，这样能够动态形成专注于短期目标的服务集合。

在酒店场景中，根据酒店管理的政策，酒店公共区域内所有的恒温器和空调风扇的固定联盟可以不断协作来保持特定的气候条件。除此之外，当火灾报警器激活时，酒店电子屏幕的临时联盟能够进行协作以提供撤离指示。对于这两个例子，这些联盟中的成员不会依赖它们虚拟身份的唯一性而是依赖于它们的属性（例如，publicarea = true）和相应的前提条件。

从设计到实现

虚拟身份、群组以及联盟的设计从实现细节中抽象而来。我认为，基于我对目前技术水准的分析，这种设计理念是足够抽象的，能够满足大多数现有系统以及基础架构的实现。

尽管对于具体实现的相关问题超出了本文的讨论范围，但以下这些通用注意事项仍然值得一提。

基础架构需求。越来越多的新的 IoT 应用程序和服务必须部署在现有的 IoT 硬件基础架构上，其中可能还包括相关的中间件。因此，分析基础架构的特性以及其局限性将成为软件开发的前提条件。这是因为部署所需的 IoT 服务和应用程序可能需要增添和升级硬件基础架构和相关设备。

例如，在酒店场景中，会议室照明开关可能需要更新才能做到使用无线网络对其进行控制，并且才能将其虚拟化为具有相关亮度调节（set-light-level）服务的虚拟身份。

对虚拟身份的实现。对虚拟身份的抽象是很普遍的特性，但是具体的实现模型显然取决于采用的中间件基础架构以及相应的编程模型。通过采用基于代理的模型和相关的中间件，开发者可以直接实现一个虚拟身份，将其作为软件代理，它具有服务、目标以及能够感知事件的能力 3，15。采用 RESTful WoT 方案也是可行的。尽管 RESTful 架构不能直接适应虚拟身份目标和事件的状态型概念。但是大多数的 WoT 模型以及其中间件都意识到了需要以某种方式将类似概念进行结合 2。

对协调器的实现。对于虚拟身份群组的协调以及协调方案的实现主要取决于采用的中间件及其基础协调模型。然而，一般的指导方针，对于具有明确的、可预测的协调需求的小型群组和联盟（例如，搭建演示会议室），最佳解决方案可能需要通过 SOA 协调模型 14 或者基于规则的协调引擎（rule-based orchestration engines）5 进行评估。对于大型群组以及联盟（例如紧急撤离活动中的电子屏幕联盟）的动态解决方案，我们需要优先考虑基于总体规划的（aggregate programming）12 或者基于自然启发机制的（nature-inspired）4 协调模型。

随着技术的成熟和现实世界经验的积累，需要对 IoT 系统的软件工程进行更多的研究。这项研究可能会在相关的工程领域中得以反复地挖掘利用，最终将导致面向 IoT 软件工程的一般模型、方法以及相关工具的一致。

参考文献

1. M.A. Razzaque et al., “Middleware for Internet of Things: A Survey”, IEEE Internet of Things J., vol. 3, no. 1, 2016, pp. 70–95.
2. J. Heuer, J. Hund, and O. Pfaff, “Toward the Web of Things: Applying Web Technologies to the Physical World”, Computer, vol. 48, no. 5, 2015, pp. 34–42.
3. N. Spanoudakis and P. Moraitis, “Engineering Ambient Intelligence Systems Using Agent Technology”, IEEE Intelligent Systems, vol. 30, no. 3, 2015, pp. 60–67.
4. F. Zambonelli et al., “Developing Pervasive Multi-agent Systems with Nature-Inspired Coordination”,Pervasive and Mobile Computing, vol. 17, part B, 2015, pp. 236–252.
5. L. Yao, Q.Z. Sheng, and S. Dustdar, “Web-Based Management of the Internet of Things”, IEEE Internet Computing, vol. 19, no. 4, 2015, pp. 60–67.
6. M. Mrissa et al., “An Avatar Architecture for the Web of Things”, IEEE Internet Computing, vol. 19, no. 2, 2015, pp. 30–38.
7. E. Latronico et al., “A Vision of Swarmlets”, IEEE Internet Computing, vol. 19, no. 2, 2015, pp. 20–28.
8. P. Patel and D. Cassou, “Enabling High-Level Application Development for the Internet of Things”, J. Systems and Software, May 2015, pp. 62–84.
9. H. Agrawal, S. Leigh, and P. Maes, “L’evolved: Autonomous and Ubiquitous Utilities as Smart Agents”, Proc. 2105 ACM Int’l Joint Conf. Pervasive and Ubiquitous Computing (UbiComp 15), 2015, pp. 487–491.
10. C. Perera et al., “Context Aware Computing for the Internet of Things: A Survey”, IEEE Communications Surveys & Tutorials, vol. 16, no. 1, 2014, pp. 414–454.
11. L. Atzori, D. Carboni, and A. Iera, “Smart Things in the Social Loop: Paradigms, Technologies, and Potentials”, Ad Hoc Networks, July 2014, pp. 121–132.
12. J. Beal, D. Pianini, and M. Viroli, “Aggregate Programming for the Internet of Things”, Computer, vol. 48, no. 9, 2015, pp. 22–30.
13. G. Bovet and J. Hennebert, “Offering Web-of-Things Connectivity to Building Networks”, Proc. 2013 ACM Conf. Pervasive and Ubiquitous Computing Adjunct Publication, 2013, pp. 1555–1564.
14. C. Sarkar et al., “A Scalable Distributed Architecture towards Unifying IoT Applications”, Proc. 2014 IEEE World Forum on Internet of Things, 2014, pp. 508–513.
15. J.P. Jamont, L. Médini, and M. Mrissa, “A Web-Based Agent-Oriented Approach to Address Heterogeneity in Cooperative Embedded Systems”, Trends in Practical Applications of Heterogeneous Multi-agent Systems: The PAAMS Collection, Springer, 2014, pp. 45–52.

关于作者

Franco Zambonelli是摩德纳大学的计算机科学教授。他的研究领域包括普适计算、群集适应系统（collective adaptive systems）以及大型系统的软件工程。Zambonelli 从博洛尼亚大学取得了计算机科学与工程博士学位。他是 ACM Transactions on Autonomous and Adaptive Systems 期刊的主编，并且是 Journal of Pervasive and Mobile Computing、Computer Journal、Journal of Agent-Oriented Software Engineering 这几个期刊的编委会成员。同时，他也是 IEEE International Conference on Self-Adaptive and Self-Organizing Systems 会议的指导委员会成员。他是美国计算机学会杰出科学家 (ACM Distinguished Scientist)、欧洲科学院院士并且是 IEEE 院士（IEEE Fellow）。你可以通过 franco.zambonelli@unimore.it 联系到他。

这篇文章首次刊发于 IEEE Software 杂志。 IEEE Software 对当前战略性技术问题提供可靠的、业内同行的评述信息。为了应对可靠、灵活地运行企业的挑战，IT 管理者和技术领导者需要依靠 IT 专家来获得最先进的解决方案信息。

译注 1：IoT，Internet of Things，物联因特网。IoT 意味着所有设备能够通过各种方式进行连接，例如蓝牙、ZigBee、WiFi 等。

译注 2：WoT，Web of Things，物联万维网，WoT 是 IoT 的最后阶段，设备所有的连接都通过统一 Web 标准的方式来达成。

译注 3：Ontology，本体论，又译为存在论。本体论就是研究到底哪些名词代表真实的存在实体，哪些名词只是代表一种概念。本体论是某些哲学分支的基础。近年来，人工智能及信息技术相关领域的学者也开始将本体论的观念用在知识表达上，即借由本体论中的基本元素：概念及概念间的关连，作为描述真实世界的知识模型。针对此一趋势，W3C 组织也开始定义了许多本体论的相关语言，如 RDF、DAML+OIL、OWL 等。

查看英文原文： Key Abstractions for IoT-Oriented Software Engineering

感谢冬雨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。