我的书签
添加书签
移除书签Device Controller
The device controller makes use of device model and device instance to implement device management :
- Device Model: A describes the device properties exposed by the device and property visitors to access these properties. A device model is like a reusable template using which many devices can be created and managed.Details on device model definition can be found here.
- Device Instance: A instance represents an actual device object. It is like an instantiation of the and references properties defined in the model. The device spec is static while the device status contains dynamically changing data like the desired state of a device property and the state reported by the device.Details on device instance definition can be found .
Note: Sample device model and device instance for a few protocols can be found at $GOPATH/src/github.com/kubeedge/kubeedge/build/crd-samples/devices
Device Model
- Upstream Controller: Synchronize the device updates from the edge node to the cloud using device twin component
The upstream controller watches for updates from the edge node and applies these updates against the API server in the cloud. Updates are categorized below along with the possibleactions that the upstream controller can take:
The mapper watches devices for updates and reports them to the event bus via the MQTT broker. The event bus sends the reported state of the device to the device twin which stores it locally and then syncs the updates to the cloud. The device controller watches for device updates from the edge ( via the cloudhub ) and updates the reported state in the cloud.
The downstream controller watches for device updates against the K8S API server. Updates are categorized below along with the possible actions that the downstream controller can take:
| Update Type | Action |
|---|---|
| New Device Model Created | NA |
| New Device Created | The controller creates a new config map to store the device properties and visitors defined in the device model associated with the device. This config map is stored in etcd. The existing config map sync mechanism in the edge controller is used to sync the config map to the egde. The mapper application running in a container can get the updated config map and use the property and visitor metadata to access the device. The device controller additionally reports the device twin metadata updates to the edge node. |
| Device Node Membership Updated | The device controller sends a membership update event to the edge node. |
| Device Twin Desired State Updated | The device controller sends a twin update event to the edge node. |
| Device Deleted | The controller sends the device twin delete event to delete all device twins associated with the device. It also deletes config maps associated with the device and this delete event is synced to the edge. The mapper application effectively stops operating on the device. |
Device Downstream Controller
The idea behind using config map to store device properties and visitors is that these metadata are only required by the mapper applications running on the edge node in order to connect to the device and collect data.Mappers if run as containers can load these properties as config maps . Any additions , deletions or updates to properties , visitors etc in the cloud are watched upon by the downstream controller and config maps are updated in etcd.If the mapper wants to discover what properties a device supports, it can get the model information from the device instance.Also, it can get the protocol information to connect to the device from the device instace. Once it has access to the device model,it can get the properties supported by the device. In order to access the property, the mapper needs to get the corresponding visitor information.This can be retrieved from the propertyVisitors list. Finally, using the visitorConfig, the mapper can read/write the data associated with the property.
