Device Modeling¶
The model is the abstraction and digitization of the physical objects in the physical world. It is the summary of the features of the objects that are connected to the EnOS Cloud.
In EnOS, defining a model means defining the features of the object. The model describes what the object is, what it can do, what services it can provide, and the events that can occur from the object. On the EnOS platform, the description language of the model is in JSON format, and you can assemble and report the device data according to the syntax of the model.
Model Elements¶
You can define specific features for a model according to the actual needs of an object.
EnOS has a feature library that provides a list of industry-standard features for improved model compatibility. It is recommended that you choose from the list first before creating custom features for your model, and only create your custom features if they are not found in the library. For more details, see Model Feature Library.
The features of a model comprises 4 types of elements: attribute, measurement point, service, and event.
Element |
Description |
Instance |
|---|---|---|
Attribute |
Describes the design specifications and static information that does not change as the device runs. You can define the name and identifier of the static attribute. |
Name, model, location, design parameters, longitude, etc. |
Measurement point |
Describes the runtime state of the device. You can define the name of the measurement point as well as its identifier. |
Temperature, pressure, current, voltage, various states, etc. |
Service |
A capability or method that can be called to achieve remote operation or control. You can define its input and output parameters. Compared with an attribute, you can achieve more complex business logics through a service. |
Command to issue, job to perform, etc. |
Event |
The event that can occur when the device is running. An event generally contains notification information that needs to be externally perceived and processed, and may include multiple output parameters. |
State changes, information about the completion of a job, or the temperature of a device when a failure or alert occurs, etc. |
Data Types¶
The attributes, measurement points, services, and events are represented by data. The following types of data are supported.
int32, 32-bit signed integers
float
double
enum
string, 1 to 1024 bytes in length
timestamp, in UTC with millisecond timing accuracy
date, format: yyyy-MM-dd HH:mm:ss
struct, where it can be int32, float, double, enum, bool, string, date
array, where it can be int32, float, double, string. You must declare the types of the members when using array. The length of an array can be indefinite, with a maximum of 128 elements allowed.
file, where the value is the file path in URI format.
Note
The data type supported will vary according to the feature type and point type selected.
For attributes and measurement points, you can use EnOS built-in units for the data when the type is not enum or struct, such as kilometer, decimeter, percentage, etc. For the list of units, see EnOS Built-in Units.
For the file data type, only the HTTP protocol can be used for uploading and downloading currently.
Model Relationship¶
A model can be created from a source model through Clone and Inherit. The difference of the two creating modes are mainly reflected in the model relationship.
Clone¶
For models created from the Clone mode, the new model has exactly the same four elements as the source model. The two models are independent from each other, and changes to one model will not affect the other. Clone is mainly used to quickly create similar models with minor modifications under special circumstances.
Inherit¶
For models created from the Inherit mode, we define the newly created models as the sub-model and the source model as the parent model. Inherit is mainly used to create new models for original model expansion under special circumstances. The sub-model has the following main characteristics:
The sub-model inherits all the features of the parent model, and the inherited elements cannot be modified.
The sub-model can be inherited again, and supports multi-level inheritance relationships.
The sub-model can have independent elements, but the newly added elements in the sub-model cannot have the same name as the elements of all parent models.
When the four elements of the parent model are changed, the sub-model’s four elements inherited from the parent model are changed synchronously to remain consistent with the parent model.
Model Permission¶
EnOS provides two types of models, namely the Public Model and the Private Model, with each having their own access policy.
Public Model¶
Public models are the standard models applicable to different industries that are created from a system organization unit (OU) and accessible to all OUs on EnOS. All OUs on EnOS have read access but no OU has write access to public models.
Private Model¶
A private model is created from an ordinary OU. Private models are accessible only within the creating OU. All users of this OU have read access, and only authorized users of this OU have write access to private models.