Model Design Examples¶

This section shows several examples of both good and poor model designs.

Good Model Designs¶

Example 1 - EnOS Edge¶

EnOS Edge is an intelligent edge computing platform, where, through the integration and inheritance of traditional OT technology and deep collaboration with EnOS Cloud, provides powerful device management, device control, edge computing, local analysis, and decision-making capabilities.

The Edge model is designed for a device gateway product. The gateway product is the main device where sub-devices can be mounted. The gateway has a sub-device management module to maintain and synchronize the topological relationship of the sub-devices to the cloud. In order to cope with large amounts of data processing, the Edge model only uses the attributes, measurement points, and services features to enable the proxy to upload other device data to the IoT Hub.

The model features are designed as per the below.

Feature Type	Definition	Description
Attribute	version, edge_type	The version and Edge type.
Measurement Point	collect_status, debug_data, resource_ver,update_result, debug_datav2, pipeline_status, ping_point, common_status, work_status	The running measurement points, mainly related to data status update.
Service	debug_command, debug_switch, update_resource, arbitrament	Services such as debugging and resource updates.

It can be seen from the above that the design of the gateway product model is simple and straightforward and does not need to take the design of its sub-devices into consideration.

Example 2 - Solar Inverter¶

Solar inverters are inverters that can convert variable DC voltage generated by solar panels into AC, which can be fed back to commercial power trasnmission systems or used by off-grid power grids.

Due to the wide variety of solar inverters available in the market, different brands may be used in different projects. EnOS Solar has designed a standard public main inverter model where sub-models can inherit the features of the main model and add other features that are unique to the brand, simplifying the management of inverters with different brands and characteristics. The figure below shows some of the features of the main model.

../../_images/solar_inv_model_features.png

The above figure shows that the design of the inverter is complicated, involving the feature design of both attributes and measurement points. Through the advice of domain experts, the common characteristics of a wide variety of inverters are abstracted into the main inverter model.

The following are some tips for a good design.

Naming the measurement points: As the data is mainly obtained through the direct collection of SCADA data through the Edge, or through the API or SFTP, an “INV.” prefix is added to the measurement points to enable the Edge to effectively manage multiple sub-devices and identify the corresponding inverter measurement points when configuring the template.
Using the public model and sub-models: When using the public models, EnOS Solar requires that all devices can only be created based on the sub-models, and not directly on the public main model. There is a standard naming convention, where the public sub-models are named EnOS_Solar_XXX_Generic, and EnOS_Solar*INV*{vendor code}_{model} for specific manufacturer models.
Using private models: If users need to create a special private model, the model manager in the IoT delivery and implementation team will be the one to create and maintain the model in the OU. The model must be inherited from a public sub-model and must comply with the model ID and measurement point naming specifications. Overall, the solar private model is recommended to have a three-layer structure: Public Main Model > Public Sub-model > Private Sub-model.

Poor Model Designs¶

Example 1 - Not Using Public Models to Create Devices¶

EnOS Edge is a standard public model, named as EnOS_Edge_Standard_Model, with its basic information and features viewable in the list of public models.

Two kinds of poor model designs are commonly seen:

Users create their own private Edge model.
Exporting the features of the standard Edge model and importing them to a private model.

The recommended method is to directly use the public Edge model EnOS_Edge_Standard_Model and create a device named EnOS_Edge_Standard_Product under each OU instead of creating a private model from scratch. This enables you to upgrade and manage the Edge model under the system management account and use the Edge management function in the DevPortal for configuring functions such as templates and specifications.

Note

The product name should be EnOS_Edge_Standard_Product in order to distinguish it as an EnOS standard Edge.
The asset type of the product must be selected as a Gateway in order for it to be found in Edge management.

Example 2 - Different Device Types Under One Model¶

When designing a model, it is necessary to identify and abstract the common features of the device assets that will be connected. A poor design would be to create assets that have different features under the same model.

For example, an electric meter model Meter with the measurement points Ua, Ub, and Uc is created, and an electric product and its corresponding devices are created based on this Meter model. As the project progresses, the next requirement is to have a water meter. As there is already a Meter model with the capacity to add more features such as the water meter measurement points, a water meter product and its corresponding devices are created based on this Meter model. The above would repeat for the next requirement, a gas meter, and the next requirement, and so on, with the Meter model having more and more features added to it until it has so many features that it becomes very hard to maintain.

The above situation arose because different types of meters (electric, water, and gas) with different types of measurements are created based on a single model. The right way to design it is to differentiate the meters, and create different models such as an Electric Meter model, a Water Meter model, and a Gas Meter model, instead of just a single Meter model.

Example 3 - Too Many Similar Models¶

There are some scenarios where projects put a lot of focus on collecting and processing device data, which may neglect the abstraction of the devices during model design, and create one model, one product, and one device for each device type for processing data. This would result in a lot of models with similar features, which is not advisable.

The maximum number of private models that each OU can have is 1,000. The above scenario, if continued unchecked, could easily hit the 1,000 limit.

Therefore, the recommended method is to identify and abstract the features of similar devices and group them under one model. This can prevent the creation of too many models that are similar in features and avoid a situation where there are not enough resources for model creation.

Example 4 - Create Irrelevant Stream Computing Measurement Points¶

During the device data development stage, measurement points that are required for stream computing are usually added to models due to businesss requirements.

Two kinds of poor model designs are commonly seen in this situation:

The measurement points for stream computing are added only after the designing of the model is completed.
The measurement points for stream computing are added to the model but the data values are not saved.

As output points for stream computing are part of device modeling, it is recommended that these measurement points are taken into consideration during the model design stage, instead of doing it at the data development stage. Model management and data development are two different stages, and the involved permissions are also different. When considering stream computing, the focus should be on the computing logic and not on modeling. Other than the above, stream computing measurement points that do not require any outputs are considered intermediate measurement points, and thus do not need to be created as model measurement points.