Key Concepts¶

The user and permission system of EnOS Onboarding Tool is inherited from EnOS Application Portal. Before you start, you need to learn about the key concepts of EnOS Application Portal.

Below are the key concepts of Onboarding Tool.

OU Template¶

An OU template is a collection of metadata such as asset types, modelling rules, topology rules, and asset elements. After an OU is bound to a template, the metadata in the template can be used to onboard and manage assets, providing data isolation between different OUs. If you need to edit the OU template, contact your system administrator.

Model¶

A model is an abstraction of a particular asset that users can manage in EnOS. Users can define four characteristics of the model: Attributes, Measurement Points, Services, and Events. For more information, see Device Modelling. An onboarded asset must be associated with a model. A model can be associated with multiple assets.

Models can be divided into the following two types:

Public model: available in all OUs. Domain experts pre-associate EnOS public models with business objects in Onboarding Tool. By default, asset administrators use public models to access assets. System administrators can associate business objects with public child models that inherit from the public models, so that asset administrators can use public child models to onboard assets.
Private model: used only within a specific OU. There are two ways to create a private model:
- Contact your system administrator to manually create private models in EnOS Management Console > Models.
- Create sites by import in batches after configuring the modelling rules, whereupon the private model is automatically created for the specified asset types within the specified range according to the modelling rules. The private models inherit from the public models associated with the business objects. For more information, see Modelling Rules.

For more information on how to use private models to onboarding assets, see Onboarding Assets Using Private Models.

Asset¶

Assets are instances of models and are onboarded based on models. Assets also have 4 properties of models: Attributes, Measurement Points, Services, and Events. An asset can be a device or a group of devices. For example:

A device: this can be a device, such as an inverter, or a component of the device, such as a battery pack. Devices and components are IoT endpoints that connect to the network and transmit data, and must be created within the site.
A group of devices: this can be a physical site or a logical site with devices and components in it, such as a solar site.

Assets that are not sites, devices, and components are referred to as groups. Groups can be created on-site or off-site.

Business Object¶

Business objects, more simply referred to as objects, are the result of abstracting asset data and its business semantics, and include site types, device types, component types, group types, manufacturers, model No.s, dimensions, and units. The business objects available within the OU are determined by the OU template.

After the system administrator associates the site types, device types, component types, and group types with the models and assigns them to the OU template, asset administrators can use Onboarding Tool to onboard assets based on the business objects and models.

Modelling Rule¶

Modelling rules are the rules that you must follow when using private models in this OU. Only the modelling rules assigned in the OU template take effect in the current OU. The modelling rules define the following for the OU’s private models:

Asset type: the type of site, device, component, and group on which the private model acts.
Effective scope: the private model of this asset type can take effect within OU or within site, or you can select No Private Model.
- Within OU: after the system administrator associates a private model with an asset type/model No., the private model is used when the asset administrator onboards assets of that type/model No. within the current OU.
- Within Site: after the system administrator associates the private model with the asset type/model No., the asset administrator uses the private model when onboarding the device/component/custom type assets of that type/model No. in the specified site. This does not affect other types or assets of the same type under other sites.
- No Private Model: only public models or public child models are supported in the current OU for onboarding assets of this type.
Creation method: the private model of devices/components must be used under the specified manufacturer and model. The private models of sites and groups are not affected by the manufacturer and model, i.e. the private models are used under the specified site/group type according to the modelling rules.

For more information on how to use private models within an OU, see Onboarding Assets Using Private Models.

Contact the system administrator if you need to create or edit the modelling rules available in the current OU.

Topology Rule¶

Topology rules are the rules that must be followed when building the topology. Only the topology rules assigned in the OU template can take effect in the current OU. Topology rules define the following for a topology:

Whether to create an independent topology: the type of topology that can be created under the current topology rule.
Cross-site onboarding support: whether the topology can be onboarded across sites, and whether cross-site devices/components assignment should be supported.
Root node object: the asset types that can be assigned on the root node of the topology.
Parent object constraints: mandatory constraints on the upper and lower levels of asset types in the topology. For example, the lower level of the constrained solar site node must assign weather station devices. When you assign a weather station device in the topology, you first must assign the solar site. If there is no weather station device under the solar site node, you cannot assign other types of assets.
Other object constraints: mandatory constraints for other types of assets that can be assigned in the topology. If they overlap with parent-child object constraints, the parent-child object constraints should be followed first.

Contact the system administrator if you need to create or edit the topology rules available in the current OU.

Topology¶

A topology is a visual form of the hierarchical relationship between assets. Assets are assigned in the topology according to the topology rules. An asset can be assigned only once in an asset tree, but it can be assigned to multiple topologies simultaneously to enable the management of assets across multiple dimensions. The usage scenarios for multiple topologies are as follows:

By location: country, province, city, district.
By application domain: wind, solar, energy storage.
By device type: wind turbine, inverter, combiner.

Three topologies can be created using the three asset organization methods above, and the assets in the different topologies can be identical. The topologies created in Onboarding Tool are synchronized with EnOS Management Console.

The types of topologies that can be created with Onboarding Tool are divided into two types: independent topology and branch topology.

Independent Topology¶

An independent topology includes topology on and off sites, and the top node of an independent topology is the root node of a topology tree. On Site Onboarding > Build Topology page, you can build the on-site parts of independent topologies based on Independent topology rules. On Topology menu page, you can build the off-site parts of independent topologies and configure automatic assignment for the site and assets within sites.

For more information, see Managing Topologies.

Branch Topology¶

A branch topology is a branch of a topology, where all nodes in Onboarding Tool are within a site. The top node of a branch topology is not the root node of a topology, and all assigned assets start at the second level. The branch topology can only be built on Site Onboarding > Build Topology page based on non-independent topology rules, and only supports the assignment of assets in the current site.

For more information, see Building Topologies.

Topology Node¶

Nodes are connection points in topologies where assets can be assigned. Assets are assigned to nodes in the topology to build the topological relationship between assets. The highest node that can be assigned in the topology displayed on the page is the top node, and the highest node in the entire topology is the root node.

Points Mapping¶

Point mapping is the process of mapping the imported device source measurement points to the model measurement points, that is, the process of giving business semantics to the source points. The mapped device measurement points can be used directly as onboarding templates in EnOS Edge.

Mapping of measurement points can be divided into the following two methods based on different mapping methods:

Automatic mapping: the names of the source measurement points are automatically matched with the names of the model measurement points in the OU. If they match exactly, the mapping is successful, and if they match partially, they are marked as fuzzy mappings. You can also manually change the results of the automatic mapping.
Manual mapping: Map the source measurement points in the OU to the model measurement points individually by manual selection.

For more information, see Points Mapping.

States Mapping¶

State mapping is the process of mapping the imported device state to the standard state in the standard state library, which is typically used to handle a device’s fault measurement points. The mapped device state can be used directly in some processes such as device state calculation, alarm categorization, shutdown record calculation, and availability calculation.

State mapping can be divided into the following two methods based on different mapping methods:

Automatic mapping: all source states are automatically matched with the standard state in the OU. If they match exactly, the mapping is successful, and if they match partially, they are marked as fuzzy mapping. You can also manually change the results of the automatic mapping.
Manual mapping: map the source state to the standard state individually by manual selection.

For more information, see State Mapping.