这个系列文章描述了一个单一的语义数据模型来支持物联网和建筑、企业和消费者的数据转换。 这种模型必须简单可扩展, 以便能够在各行业领域之间实现插件化和互操作性。 对于一个目前从事智能硬件的老码农，觉得这些文字具有积极的参考意义。这一部分讨论通用的数据格式和应用程序编程接口(API)，以及如何利用这些共同的本体。

当你刚开始尝试解决一个问题时, 
你提出的第一个解决方案是非常复杂的,
大多数人都会停下来。 但是如果你坚持下去, 
面对这个问题, 剥掉更多的洋葱层,
你会经常得到一些非常优雅和简单的解决方案。 
大多数人只是没有时间和精力去那里。 ————史蒂夫 · 乔布斯

在对象世界中管理数据

在新兴的数字世界中, 数十亿人、系统和设备将实时互动, 需要在分布式数据管理、互操作性和基于规则的事件处理方面采取新的破坏性创新方法。

除了统一本体论、"物联网标准"和"业务标准"联盟之外, 还需要汇聚在一个共同的数据交换格式和 API 模型上, 以支持基础广泛的跨行业领域用例之间的插件和播放互操作性。

分布式数据管理和互操作性依赖于一个共同的本体(语义)和通用数据格式(用于语法) , 使服务能够识别和解释在连接系统之间交换的结构化数据。

在本文中,"对象管理"是指在分布式环境中创建、存储、更新、访问和共享本体对象实例状态的机制。

什么是服务？

"服务"一词根据具体情况有不同的含义。 因此, 围绕服务的概念存在着一些混乱, 因为人们试图区分应用服务、域服务、基础设施服务、面向服务的体系结构(SOA)服务等。 在所有这些情况下,"服务"一词是有效的, 但作用不同, 可以跨越应用程序的所有层次[15]。

在领域驱动设计(DDD)中, 一个"域"服务以领域概念(本体类)为基础, 非常细粒度(如 微服务) , 可以被认为是一种过程的封装。 "应用程序"服务为域服务提供了一个托管环境, 并将域的功能作为一个 API 公开给外部服务。 应用程序服务根据一个公共信息模型的标识值和原始数据结构(在上层本体中)。

在一个模糊世界的模型服务

考虑到物联网的大量数据以及对实时通信流的需求, Gartner 预测, 到2022年, 75% 的企业生成的数据将在数据中心或云以外创建和处理。 很明显, 只有云计算的方法不再能够跟上必要的体积、延迟、可靠性和安全性的挑战。

一个分布式计算模型(如fog computing)可以通过提供一种标准的、通用的方式来管理、管理和分配必要的资源和服务, 使数字世界具有功能性和互操作性, 从云到物联系起来(图50)。

图50 语义互操作性和雾计算服务模型

该模型可以"混合"流行的体系结构样式(如 DDD、模型驱动设计、事件源和命令查询责任分离CQRS)来定义一个可互操作系统系统中对象管理的简单和可伸缩应用服务。 这些系统可以跨越物联网设备、商业、车辆和城市的子系统。 这些服务可以利用上层本体和信息模型(见第二部分)来支持系统连接、统一数据交换、事件和查询处理、单元和标识符转换以及语义注释。 为了扩展规模, 这些服务必须是稳定, 不变而且独立,从边缘控制器到云服务器，可以嵌入到任何类型的机器。

该模型可以定义一组对象管理服务(类似于 IETF 的可扩展供应协议(EPP)) , 它们没有明确地与特定对象绑定, 并且可以扩展到所有本体类中的对象。 虽然对象管理与面向对象程序设计相似, 但该服务模型可以代表类似于模型驱动开发编程中的元数据抽象。 这些服务可以创建元数据, 并在运行时解释该元数据。 代表本体的元数据可以在一个完全抽象于任何编程环境的存储库中维护。 底层代码作为服务的平台(例如 Mendix)可以利用这种服务模型, 在完全通过元数据解释执行的应用程序之间提供固有的互操作性。

虽然服务和安全模型之间存在着很强的关系, 但是该系列中的这一部分将侧重于与语义相关的服务, 这与任何特定的安全模型无关。

有效消息载荷的网格

为了创造价值, 物联网设备生成的数据越来越多地在一个时间序列内进行时间戳标注, 并在间隔或状态变化时传输。 随着业务应用程序越来越以IOT为中心, 并围绕事件驱动的架构, 来自业务事件的数据也可以构建为一个时间序列。 查询响应可以包括基于这些事件更改的设备和信息对象的当前状态。 时间序列和查询响应数据代表了大多数分布式数据交换, 并且最有效地包含在网格(表格)结构中。

一个网格(类似于Haystack网格)可以作为分布式数据管理的核心数据格式, 可以采用适合于特定通信协议的同步格式传输(图51)。 例如, 一个网格可以编码为一个 JSON数组(二维) , 用于通过 HTTP 消息传输。 或者它可以编码为一个简洁的二进制对象识别(CBOR)数组, 用于通过 CoAP 传输。

图51 连接系统交换序列化二维网格中的数据

由组织机构定义的数据交换服务支持的同步格式各不相同(图52)。 最初主要为服务器实现设计的服务(GS1 EDI 和 IETF EPP)支持 XML, 而那些针对资源受限设备的服务支持更多的压缩编码格式(如 JSON 和 CBOR)。 网格数据可以被编码到这些格式中的任何一个。

图52 消息负载的数据序列化 / 编码格式

应用服务的通用 API 网关

通用的 API 网关可以在控制器设备中实现, 作为连接系统所有入站消息的单一入口, 可以在控制器设备中实现一个通用 API 网关, 作为连接系统所有入站消息的单一入口点。 网关可以对每个消息进行身份验证, 并将去序列化的网格有效负载转发到应用服务, 这反过来又可以调用由网关处理生成出站消息的其他服务。

通过将一个普通的 API 作为所有控制器设备的前端, 可以抽象出不同设备类型和微服务分区的复杂性。 然后, 该设备可以转换为服务(device-as-a-service) , 并被其他服务使用。

基于网格数据的类型, 网关可以调用单独的事件和查询处理服务(类似于 CQRS 架构) , 该服务可以更新和检索在"事件存储"中持久存在的对象的状态(图53)。

图53 事件 / 查询责任分离和与事件存储的交互

一个时间序列的事件存储

自动驾驶的 Teslas、自主的华尔街交易算法、智能家居和同一天订单满足服务有什么共同点？

这些应用程序依赖于一种数据的形式, 这些数据可以测量事物随着时间的变化, 时间不仅仅是一个度量, 而是一个主轴。 这是时间序列数据。 它开始在我们的世界中发挥更大的作用, 远远超出传感器数据流的范围。 事实上, 时间序列数据库(TSDBs)已经成为增长最快的数据库类别之一, 可以有效地索引、查询、共享和分析。

当应用于"事件源"的概念时, 可以将 TSDB 视为一个"事件存储", 它将对象状态作为一个时间序列中的一系列状态变化事件。 当一个对象的状态发生变化时, 一个新的事件被追加到事件存储中, 这是原子本质。 通过禁止事件的更改或删除, 事件存储可以提供对对象进行所有更改的可靠审计日志。

在图54中, 一个事件存储从9 / 18的一个事件中反映了 Location 对象(实例)的创建, 该事件在9 / 18日02:15分分配给新对象的所有方。 该事件还为该对象指定了一个标识符和类, 这是它的主键。 这个密钥包含在随后的所有事件中, 这些事件通过给属性赋值来改变对象的状态。 位置对象的当前状态可以从对象的每个属性最新事件派生出来。

图54 通过在事件存储中的时间序列事件获取 Location 实例(对象)的当前状态

事件可以通过将一个布尔值分配给根对象类的"已删除"属性, 从而删除(或删除)对象。 通过这种方法, 事件和事件处理可以有效地创建、更新和删除对象, 取代对单独命令和命令处理的需求(读取可以通过查询和查询处理来处理)。

区块链 还是 事件存储

区块链和事件存储都是数据存储机制, 它们可以提供分布式环境中对象状态变化的附加审计线索。

虽然区块链正在享受最近的炒作, 但事件存储 / 事件订阅方法可以提供许多封锁链承诺的好处, 没有开销、社区建设和成为矿工的风险。

区块链是基于分类账和交易的概念, 这些概念非常适用于金融业。 然而, 这些概念是否非常适合于支持一个可互操作的设备系统呢？

"混合"可伸缩的方法可以结合事件存储中面向对象事件的粒度与区块链的反篡改验证结合起来。

事件处理服务

代表时间序列事件的网格数据可以结构化为一种通用格式, 使所有事件消费应用和在控制器设备上实现的域服务进行高效处理。 这个通用事件格式可以支持反映对象状态(属性值)更改的设备和业务事件。 图55中的顶部网格在这种格式中显示了人可读的值, 但实际值可以反映底部网格所示的机器可读标识符。

图55 使用事件处理服务来从公共格式中保持时间序列事件

通用 API 网关可以调用事件处理服务来处理入站的时间序列事件, 并可以向连接控制器系统发布出站事件。

事件处理器可以根据所有系统进程(例如微服务)的规则对事件进行处理, 这些事件可以发出新的事件(包括与 OCF post / response 类似的确认事件)。 事件处理器可以将事件发布到事件存储中以保持状态(类似于 Haystack 的写操作)。

一个基于上层本体的数据地图可以被一个事件处理器引用, 该处理器接收来自稀缺资源的传感器数据。 然后, 事件处理器可以用数据映射实例中包含的语义来注释从传感器接收到的语义, 以在公共事件格式中填充所有元数据(图56)。

图56 使用事件处理服务和上层本体来注释时间序列语义

这个注释可以包括将特定于联营集团的数据格式转换为通用事件格式(图57)。 例如, 一个温度传感器可以提交一个分隔的名称 / 值对的集合, 这些名称 / 值对提供了除了值之外的语义。 这些数据可以转换为仅包含值侧的网格, 因为网格列定位对应于特定的数据元素。

图57 使用事件处理服务将不同的事件格式转换为通用格式

一个事件处理器可以参考系统属性(图58) , 该上层本体定义了读 / 写设置(类似 OCF 的只读属性)。 基于这些设置, 事件处理器可以监视(读)和(写)与控制器相连的组件设备(传感器、执行器)的运行状态。

图58 使用事件处理服务获取 / 设置基于系统属性实例的读 / 写设置的风扇速度

例如, 如果一个系统属性可以同时读取和写入风扇的速度属性, 那么事件处理器可以从风扇中检索当前值(类似于 OCF get) , 并根据时间序列事件设置其值(类似于 OCF post)。

基于发布/订阅的系统连接

事件存储可以作为"服务注册表", 存储定义系统连接和连接系统属性的事件。 以上层本体为模型的系统连接可以表示实时数据订阅(类似于 Haystack 的"watch")。 当一个设备用另一个设备启动系统连接(EPP 会话)时, 该设备可以响应其系统属性。 设备可以交换包含系统之间共同属性的事件和查询。 这些属性代表系统进程的内部输入 / 输出。

图59 使用事件存储(注册表)的事件处理服务, 向具有共同属性的连接系统发布事件

例如, 控制器的 HVAC 系统可以连接到另一个控制器的气流控制系统。 这两个系统都可以引用在一个公共本体中定义的"风扇"设备的"速度"属性。 HVAC系统的一个过程(域微服务)可以产生一个时间序列事件, 当触发事件发生时(如气温变化)时, 可以改变风扇速度。 系统控制器的事件处理器可以将此事件发布到 Airflow 控制系统控制器, 该控制器调用其事件处理器来改变连接风扇电机的速度。

数字双胞胎的状态管理

从设计到预测分析,"数字双胞胎"的使用正变得越来越普遍。 这个概念非常简单——基本上, 双胞胎指的是一个实际物理资产的动态软件模型(数字实例化)。 该模型能够实时公开设备及其连接系统的内部工作, 并与其进行实时交互。 数字双胞胎可以整合感官和上下文信息, 使各组织能够从资产信息中受益。 最终的结果是有可能创造更高的资产业绩, 并使制造商能够管理服务设备。

一个由对象管理服务组成的共同服务模型可以通过支持同步和发布状态变化来管理数字双胞胎的状态(类似于 Eclipse Ditto)。

查询处理服务

网格数据可以表示查询请求和响应。 查询请求可以结构化为一种通用格式, 使得应用程序服务可以在控制器设备上实现。

通用 API 网关，可以调用查询处理服务来处理在公共查询格式中的入站查询请求(图60)。 查询处理器可以从符合查询条件的事件存储中检索相关对象的当前状态, 并将出站查询响应返回到请求服务。

图60 使用查询处理服务和通用查询格式从事件存储中检索对象状态

查询处理器可以在上层本体中引用词汇条款(图61) , 为全局应用程序提供多国家语言支持。 通用查询格式可以包含一个元素, 该元素指定查询响应中所包含数据的人类语言。 例如, 如果图61中所示查询指定了"西班牙语"语言, 则在响应网格中返回的楼层名称将以西班牙语而不是英文出现。

图61 使用查询处理服务和上层本体检索请求语言中的词汇项

用于标识符转换的服务

应用程序服务可以在上层本体中引用属性和单元(图62) , 以转换包含在时间序列事件中的备用标识符。

图62 使用应用程序服务和上层本体在时间序列事件中转换备用标识符

例如, 事件处理器可以调用一个服务来转换由属性标识符限定的替代单元标识符(如 "degF")。 该服务可以引用该单元对象, 该对象包含带有交替标识符("degF")的标识属性("ISO 代码")。 该服务可将事件中单位标识符的值转换为单元对象的主标识符(例如 0 华氏度)。

另一个例子是, 转换服务可以在 RFID 传感器生成的时间序列事件中转换用于识别"对象"和"值"元素的替代标识符。 图63中的"价值"元素包含一个可交替的位置识别号("0123456789012") , 该标识符符合 GS1的 EPCIS 标准(例如"urn: epc: id: sgln")。 转换服务可以引用位置对象, 其中包含带有备用标识符("012345...")的标识属性("GLN")。 该服务可将事件中的"Value"元素转换为 Location 对象的主标识符("3100 Main...")。

图63 将 GS1 EPCIS 事件与通用事件格式对齐并转换 GS1键

单位转换服务

应用程序服务可以参考以上层本体为模型的测量单位, 以转换包含在时间序列事件中的"Unit"和"Value"元素。

例如, 一个事件处理器可以通过引用相关单元对象的"转换因子"和"偏移"属性值, 从而将图64中的温度值("77.4")从华氏转换为摄氏。

图64 利用应用服务和上层本体在时间序列事件中转换测量值和单位

领域特定本体的领域微服务

虽然应用程序服务的目的是稳定和不变的, 但随着流程和规则的演变, 可以动态地实现域微服务, 以有效实现系统所有者(当事方)的目标。

每个系统都可以包含一个微服务集合(过程和规则的封装) , 其中引用了特定领域本体中的属性(例如, 医疗、零售、智能建筑等)。 这些狭义的、合作的微服务可以根据规则消耗时间序列事件, 并从它们的行动中产生时间序列事件。

事件处理器可以为复杂事件处理协调域微服务的执行。

图65提供了一个域微服务的例子, 该服务可以引用在特定领域本体中建模的场景定义, 以根据触发事件(如时间变化)改变位置的"场景"。

图65 使用域服务和本体来改变办公室套件中的"场景"

另一个域微服务可以引用以公共业务本体为模型的业务信息对象, 以生成事件来定义基于故障设备触发事件的替换顺序(图66)。 同样的控制器可以改变连接元件(图论)设备(如传感器和执行器)的状态, 也可以用来改变信息对象(如订单)与连接业务系统的状态。

图66 使用域服务和公共业务本体从设备故障中生成替换顺序

一个共同的服务模型和共同的本体论可以形成一个"公共对象管理框架", 支持系统的语义互操作、对等对等系统。 这个框架可以分解数据仓库, 消除复杂的系统集成, 并且只使用元数据来统一信息空间。

References:

15 Vernon, Vaughn, Implementing Domain-Driven Design, Addison-Wesley, 2013

16 Murdock, Paul, Davies, John, et al., "Semantic Interoperability for the Web of Things", ResearchGate, Aug 2016

17 Hambley, Lee, "Blockchain or Event Sourcing", July 2017

18 Richardson, Chris, http://microservices.io

19 Byers, Charles., Swanson, Robert, et al., OpenFog Reference Architecture, OpenFog Consortium, Feb 2017