Driver-Box : 基于物联网开源框架 Edgex 打造的楼宇智能化网关

Driver-Box 是美的楼宇科技研究院基于物联网开源框架 Edgex 打造的一款泛化协议接入服务， 以插件化的形式融合了 Modbus、TCP、HTTP、MQTT 等主流协议，同时也支持基于TCP的各类私有化协议对接。

我们期望 Driver-Box 能够为相关人士提供更加高效、舒适的设备接入体验。通过对各类设备的通信协议和数据交互形式进行抽象，定义了一套标准流程以涵盖泛化协议的共性处理逻辑，并结合动态解析脚本（Lua、Javascript、Python）填补其中的差异化部分。

最终，解决楼宇智能化场景中不同供应商设备接入存在的驱动工程数量爆炸，接入标准难以规范化等问题。

01

楼宇智能整体方案架构

基于 DriverBox 边缘网关的楼宇智能化技术方案架构如下：

标准

在距离设备最近的地方实施物模型标准化，适配 Modbus、Bacnet、Http、MQTT以及各种私有TCP协议。

高效

标准协议配置化接入，非标协议动态解析。开发/调试无需重启驱动服务，设备接入便捷、高效。

稳定

为不同的通信模式提供定向优化策略，提升数据可靠性和服务稳定性。

02

Driver-Box 相关概念

在Driver-box中，我们引入了模型(model)、设备(device)、连接(connection)、协议(protocol)的概念。以下将分别阐述这些概念在Driver-box中的作用。

模型(model)

模型(model)是针对某一类设备的抽象，其包含着一个个具体的点位，每个点位表示着这一类设备的某一个具体属性，从而为上层应用提供统一的操作语言，比如：灯就可以抽象成包含了一个点位是开关的模型。 另外，在具体实施过程中，模型的设计应该充分考虑到业务的需求。比如：对于一类白色灯和另一类的红色灯，实施人员既可以把他们抽象成包含一个颜色点位的模型，也直接抽象成表示两个不同颜色的灯的模型，具体按照实际业务需求自行斟酌。

设备(device)

设备(device)是指现实中具体的某一个具体的设备，一个设备只能对应到唯一的模型并且至少具有该模型一个以上的点位，比如一个极简的只具有开关功能的灯也可以映射到一个非常复杂的模型上，但是不推荐这么做。 在Driver-box中，每一个设备都有一个唯一的名称或者说序列号(以下简称sn)与之对应。当然，在实际接入过程中有可能会出现需要将多个实际设备的点位数据映射到一个虚拟设备的情况，在这种情况下，Driver-box同样支持将这多个设备设置为同一个sn从而进行组合的操作。

连接(connection)

连接(connection)是指网关与设备在通信层面建立的连接，多个设备可以共享同一个连接，同样的，一个设备也可以通过使用多个连接来采集不同点位的数据，需要注意的是，单独设备的特定点位点位数据仅能从一个连接去获取。Driver-box通过这些连接获取设备相关数据。

协议(protocol)

协议(protocol)是指连接的通信类型。目前Driver-box可支持的协议类型包括http server、http client、 tcp、 modbus、mqtt，后续更新中会陆续支持其他类型的通信协议。

Driver-box是以模型(model)为切入点，面向连接(connection)的并向上层应用提供统一数据通道的设备接入工具。它会根据不同类型的通信协议使用对应的插件，创建出设备与驱动的连接。驱动通过根据设备以及点位来调用对应的连接来进行南向与北向的数据传输。上层应用则通过标准化的模型来对设备进行点位级别的操作。

03

Driver-Box 系统实现原理

Driver-Box整体上分为4层架构：接口层(interface)、核心层(core)、解析层(parser)和插件层(plugin)，以下将会分别阐述每一层的具体实现和作用。

接口层(interface)

接口层(interface)为上层应用提供统一的操作接口来实现设备点位级别的读写操作。

核心层(core)

核心层(core)主要包含了：配置(config)、任务(task)、影子(shadow)、通知(notice)这些模块。以下将分别阐述这些模块的内容。

配置(config)

配置模块主要负责对配置文件的处理工作。

• 加载配置文件

配置模块会从指定的路径目录加载所有配置文件。该路径下的每一个目录都被视为一个单独的插件的配置信息。配置模块会将它们分别读取并组合成完整的配置对象。

• 验证配置文件

在加载配置文件后，配置模块需要验证配置文件的正确性。这部分不仅仅包含了针对配置中每个字段的验证，同时包含了对配置文件整体完整性的验证。

• 解析配置文件

在验证配置文件的正确性后，配置模块会将配置文件解析成一个个方便其他模块访问的标准数据结构。

• 缓存配置数据

为了提高性能，配置模块需要将解析后的配置数据存储在缓存中。这样，其他模块在访问配置数据时，就不需要重新加载和解析配置文件。

• 提供访问接口

配置模块为其他模块提供了一套访问接口实现，使得其他模块可以方便地访问配置数据。其他模块通过这个接口，可以查询和修改配置数据。

• 监听配置文件变化

为了支持动态配置，配置模块需要能够监听配置文件的变化。当配置文件发生变化时，配置模块需要重新加载和解析配置文件，并更新缓存中的配置数据同时触发其他模块的更新动作。

任务(task)

任务模块主要是负责调度和管理配置文件中设置的每一个任务的生命周期，包括任务创建、任务监控以及任务销毁。

• 任务创建

通过配置内容，如执行时间、重复周期、优先级等，任务模块创建出相对应的执行任务。

• 任务监控

提供实时的任务状态监控功能，让用户可以随时了解任务的执行情况。对任务的执行时长和结果等信息进行监控。

• 任务销毁

统一管理任务的销毁工作，为提供使用者接口进行手动对任务的终止操作。

影子(shadow)

影子模块主要数据降噪以及设备在离线判断。

• 数据降噪

影子模块存储每个设备的点位信息。在完成数据的读操作之后，所读取的点位数据被缓存到影子模块当中，并更新点位的读取时间。当点位更新时间超出超时时间或者与影子服务中的点位值不同时，才会被写入到消息总线当中。因此，该功能只有在启用消息总线的情况下才有效果。

• 在离线判断

影子模块对设备的在离线判断的主要根据是设备的点位读取结果。当点位读取失败次数达到设定阈值的时候，当前设备就会被认定为离线状态并且持续至点位的成功读取。

通知(notice)

通知模块主要负责向上层应用发送通知信息，例如影子模块判断出设备的在离线状态之后便可以通过通知模块完成事件的通知。

解析层(parser)

解析层(parser)负责对解析脚本的加载和调用工作。 在解析层中，解析脚本可以是不用的编程语言进行编写的，如Lua、JavaScript、Python等脚本语言（目前仅支持Lua）。每个脚本被存放在每个插件的配置目录，与配置文件同级。 解析脚本中的内容可以动态修改并生效，从而提高调试效率。 针对不同的接入协议，解析脚本的入参结构可能会有不同，这是由各个插件的实现来决定的。

插件层(plugin)

插件层(plugin)包含3个接口实现：驱动插件(plugin)、适配器(adapter)和连接器(connector)。

驱动插件(plugin)

驱动插件(plugin)接口定义了插件的初始化、连接器和适配器的获取以及插件销毁的流程。初始化过程中，驱动插件根据配置文件中的协议信息决定连接器和适配器的初始化以及对连接池的管理。

连接器(connector)

连接器(connector)是系统与设备的通讯连接。初始化过程中，驱动插件根据配置文件中的协议信息初始化每一个连接器。该接口定义了Send和Release方法，分别用于数据的南向传输以及连接器的释放动作。

适配器(adapter)

适配器(adapter)与设备无关，一共包含了2个方法：decode()与encode()。适配器的主要任务是将上层统一的数据结构与对应协议的数据结构进行相互转化。

总体上来说，连接器和适配器从属于驱动插件。适配器承担了对不同协议的适配工作，连接器负责数据传输。南向数据通过encode方法转化成协议的合法结构在通过对应的连接器进行下发，而北向数据在接收到之后经过decode方法转化为同一的数据结构交付给上层应用。

04

官网和源码

官网：https://ibuilding-x.gitee.io/driver-box

Gitee：https://gitee.com/iBUILDING-X/driver-box

快速开始

1.下载发行包，现支持架构包括：Windows、Linux、Mac

2.解压发行包(Windows环境为zip包)

tar xvf driver-box-<os>-<arch>.tar

3.启动 driver-box

./driver-box -broker=mqtt://82.157.162.230:1883 -clientId=123456 -exportTopic=/driverbox/export/

4.启动 MQTTX 客户端，充当物联网云平台的角色，并订阅  

topic： /driverbox/export/

5.发送模拟请求

# 模拟 “开”
curl http://localhost:8080/sensorModel/sensor_1/on
 
 
# 模拟 关“”
curl http://localhost:8080/sensorModel/sensor_1/off

6.观察 MQTTX 客户端接收到的报文

topic: /driverbox/export/
payload: {"device_name":"sensor_1","values":[{"name":"onOff","type":"","value":1}]}
 
 
topic: /driverbox/export/
payload: {"device_name":"sensor_1","values":[{"name":"onOff","type":"","value":0}]}

---

​

往期推荐

☞ 十年回望，中国物联网平台消亡史

☞ 2022年 IoT物联网平台趋势: 私有化

☞ 5个值得分享的物联网创业失败教训

☞ 国内 4 大 IoT物联网平台选型对比

☞ 云厂商的 [IoT物联网平台] 不香了吗？