作者：王彬丞、杨志佳、刘家伟
随着万物互联时代快速到来，5G网络普及导致边缘设备产生的数据量快速增长。普通的边缘设备计算能力不足，因此传统方法会将边缘侧数据集中汇聚到云端数据中心进行处理，容易对响应实时性、网络稳定性以及数据安全性产生挑战。
为满足用户在大规模设备场景中更高的可用性需求，KubeEdge Device-IoT在1.12版本推出设备管理框架（Device Management Interface，DMI）。DMI整合设备管理接口，将管理面和业务面数据解耦，优化边缘计算场景下的设备管理能力，打造基于云原生技术的设备数字孪生管理平台。
在 1.15 版本中，我们根据边缘设备管理的用户需求迭代更新 v1beta1 版本的设备管理 API，并以此为基础完善 DMI 数据面功能，承载于南向的 Mapper 开发框架 Mapper-Framework 中。Mapper-Framework 提供了全新的 Mapper 自动生成框架，框架中集成了 DMI 设备管理面与数据面能力，能够自动生成 Mapper 工程，用户只需实现其中的设备驱动的功能即可使用 Mapper 管理边缘设备，简化用户设计开发 Mapper 的复杂度，提升开发效率。针对新版本 Device-IoT 领域的更新，我们计划推出一系列的文章对这些特性进行详细的介绍，大致的文章大纲为：
基于物模型的设备管理 API 设计与实现
DMI 数据面能力设计与实现
Mapper 开发框架 Mapper-Framework 设计与实现
如何使用 Mapper 完成视频流数据处理
如何使用 Mapper 实现设备数据写入
如何从头开发一个 Mapper（以 modbus 为例）
本篇文章是系列文章的第一篇，主要介绍基于物模型的设备管理 API。
基于物模型的设备管理 API
▍1. Device Model
// ModelProperty describes an individual device property / attribute like temperature / humidity etc.
type ModelProperty struct {
// Required: The device property name.
// Note: If you need to use the built-in stream data processing function, you need to define Name as saveFrame or saveVideo
Name string `json:"name,omitempty"`
// The device property description.
// +optional
Description string `json:"description,omitempty"`
// Required: Type of device property, ENUM: INT,FLOAT,DOUBLE,STRING,BOOLEAN,BYTES,STREAM
Type PropertyType `json:"type,omitempty"`
// Required: Access mode of property, ReadWrite or ReadOnly.
AccessMode PropertyAccessMode `json:"accessMode,omitempty"`
// +optional
Minimum string `json:"minimum,omitempty"`
// +optional
Maximum string `json:"maximum,omitempty"`
// The unit of the property
// +optional
Unit string `json:"unit,omitempty"`
}上图展示了 Device Model 的核心 ModelProperty 字段，其中 Type 字段定义该属性的数据类型，AccessMode 定义该属性的访问方式，包括读写和只读两种。当访问方式设置为只读时，Mapper 会直接返回采集到的设备数据，反之当设置为读写后，Mapper 会对采集到的设备数据进行归一化等处理后再返回。Minimum 与 Maximum 则定义了设备属性的最大最小值，Unit 字段定义了设备属性的单位。下图展示了一个 Device Model 配置文件的示例：
apiVersion: devices.kubeedge.io/v1beta1
kind: DeviceModel
metadata:
name: beta1-model
spec:
properties:
- name: temp # define device property
description: beta1-model
type: INT # date type of device property
accessMode: ReadWrite
maximum: "100" # range of device property (optional)
minimum: "1"
unit: "Celsius" # unit of device property
protocol: modbus # protocol for device, need to be same with device instance
▍2. Device Instance
一个 Device Instance 代表一个实际的设备对象。v1beta1 版本中，Device Instance 中内置的协议配置全部移除，包括 Modbus、OPC-UA、Bluetooth 等。用户可以通过可扩展的 Protocol 配置来设置设备协议，能够实现任何协议的设备接入。Modbus、OPC-UA、Bluetooth 等内置协议的 Mapper 仍会保留在 Mappers-go 仓库中，同时也会不断增加其他协议的内置 Mapper。
type ProtocolConfig struct {
// Unique protocol name
// Required.
ProtocolName string `json:"protocolName,omitempty"`
// Any config data
// +optional
// +kubebuilder:validation:XPreserveUnknownFields
ConfigData *CustomizedValue `json:"configData,omitempty"`
}
type CustomizedValue struct {
Data map[string]interface{} `json:"-"`
}
type DeviceProperty struct {
...
// Define how frequent mapper will report the value.
// +optional
ReportCycle int64 `json:"reportCycle,omitempty"`
// Define how frequent mapper will collect from device.
// +optional
CollectCycle int64 `json:"collectCycle,omitempty"`
// whether be reported to the cloud
ReportToCloud bool `json:"reportToCloud,omitempty"`
// PushMethod represents the protocol used to push data,
// please ensure that the mapper can access the destination address.
// +optional
PushMethod *PushMethod `json:"pushMethod,omitempty"`
}ReportCycle 字段定义了 Mapper 向用户数据库、用户应用推送数据的频率； CollectCycle 字段定义了 Mapper 向云端上报数据的频率； ReportToCloud 字段定义了 Mapper 采集到的设备数据是否需要上报云端； PushMethod 字段定义了 Mapper 推送设备数据的方式。
目前提供 HTTP、MQTT 以及 OpenTelemetry 等方式向用户应用推送数据，并内置集成 InfluxDB、MySQL、Redis、TDengine 数据库。用户能够通过配置文件控制Mapper 向用户应用、用户数据库中定时推送设备数据，也能够通过 API 主动拉取设备数据，实现设备数据处理方式的多样化，相比于将所有数据推送至云端再行处理的传统方法，能够有效减少云边通信阻塞的风险。
下图展示了一个 Device Instance 配置文件的示例：
apiVersion: devices.kubeedge.io/v1beta1
kind: Device
...
spec:
properties:
- name: temp
collectCycle: 2000 # The frequency of reporting data to cloud, 2 seconds
reportCycle: 2000 # The frequency of data push to user applications or databases, 2 seconds
reportToCloud: true # Decide whether device data needs to be pushed to the cloud
pushMethod:
mqtt: # Define the MQTT config to push device data to user app
address: tcp://127.0.0.1:1883
topic: temp
qos: 0
retained: false
visitors: # Define the configuration required by the mapper to access device properties (e.g. register address)
protocolName: modbus
configData:
register: "HoldingRegister"
offset: 2
limit: 1
protocol: # Device protocol. The relevant configuration of the modbus protocol is defined in the example.
protocolName: modbus
configData:
serialPort: '/dev/ttyS0'
baudRate: 9600
基于 v1beta1版本的设备管理 API，我们以 Kubernetes CRD 的形式将 Device Model 与 Device Instance 引入 KubeEdge 集群。如需要更多详细的信息，可以参考设备管 API 的 proposal 文件[1] 以及相关 PR[2]。在本系列的下一篇文章中，我们会对 DMI 数据面能力的支持进行详细的介绍。
https://github.com/kubeedge/kubeedge/pull/4983
KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。
KubeEdge网站 : https://kubeedge.io
GitHub地址 : https://github.com/kubeedge/kubeedge
Slack地址 : https://kubeedge.slack.com
邮件列表 : https://groups.google.com/forum/#!forum/kubeedge
每周社区例会 : https://zoom.us/j/4167237304
Twitter : https://twitter.com/KubeEdge
文档地址 : https://docs.kubeedge.io/en/latest/
进入技术交流群
文章转载自KubeEdge。点击这里阅读原文了解更多。
CNCF概况（幻灯片）
扫描二维码联系我们！
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请关注CNCF微信公众号。
