Information Model

Each NODA customer has one or more domains on which collected data is stored.

Permission is granted per customer domain, meaning a user can access multiple customer domains. Upon logging in, users with access to numerous customer domains will arrive at a predefined home domain. In the dropdown menu at the top right, users see the domains they have permission for and can switch between domains in the menu (opens in a new window).

This structure means that EnergyView supports customers with one or more customer domains, where each domain has one or more users and one or more customer installations with various services activated.

A customer domain has several collectors, representing objects of a specific type with tags for data. A collector could, for example, mean an indoor sensor, a building, or something else. Collectors can be grouped into groups, which are used in various ways in NODA's services.

erDiagram
    CUSTOMER ||..|{ DOMAIN : "owns/has"
    CUSTOMER ||..o{ USER-ACCOUNT : "owns/has"
    USER-ACCOUNT ||--o{ DOMAIN : "has access to"
    DOMAIN ||--o{ COLLECTOR : contains
    COLLECTOR {
        text name
        text description
        lable type
        representation object
        number local-id
        UUID global-id
        text data-interface-id
    }
    COLLECTOR ||--o{ TAG : has
    TAG {
        text namne
        text description
        text unit
    }
    GROUP }|--|{ COLLECTOR : contains

Data Structure

Data points are systematised in EnergyView using the concepts of tag, protocol, device, and collector described in the sections below.

Tag

Data points are linked to tags, where a tag corresponds to a measured value or a computed value of a specific sort. Examples of a tag are indoor temperature, power, flow, etc. Measured values are saved in the database on a customer domain via tags.

Protocol

The top level of the structure for data storage on a customer domain in EnergyView is called a protocol. A protocol is a list of tags. Protocols define which tags exist and can be seen as a gross list. If a new tag is to be created, this is done by adding it to an existing or new protocol. Protocols are thus a high-level sorting of tags. They could, for example, be IoT sensors, properties, district heating systems, or similar.

Several objects and properties are used for further systematisation, described under Device and Collector below. In our environment at NODA, for example, we have used a master protocol for tags related to buildings, a protocol for indoor sensors, and a protocol for tags from the weather forecast service we use. Currently, tags are referred to as sensors, but it means the same thing.

Device

Under each protocol, devices that use the protocol are defined. A device has a limited subset of the tags on the protocol to which it belongs. Nothing prevents a device under a protocol from having all the tags on the protocol. Still, devices make it possible to systematise the structure of data. Protocols are the gross list of tags, and devices are net lists of tags. Examples of what devices can correspond to are meters, sensors, control systems, etc.

Collector

A collector is a node representing something which communicates data points with NODA, for example, a district heating substation in a multi-dwelling building, a sensor in an office, or something else. Several properties declare a collector:

  • Name: Free text.
  • Description: Free text.
  • Device (see Device above): a collector is a device.
  • Object representation: A label that describes what the collector represents, e.g., Residential building, Indoor climate sensor, Heating circuit, Network station, etc.
  • Tags: The collector has access to the Device's tags, and it is possible to choose which tags should be activated on the collector.
  • Identifiers created by the system:
    • Local identifier: A node ID, which is a serial number for the collector on the customer domain.
    • Global unique identifier: A UUID, which can be used to identify the collector via communication between different systems.
  • Data interface identifier: This is an ID the user can set themselves and is used for matching when an ID comes from an external system. It is thus an ID that an external system has set, for example, a serial number on a sensor or a MAC address.

Sub-collectors

It is possible to define affiliations between collectors according to a parent-child principle. That is, a collector can be the child of another collector. For example, room sensors can be sub-collectors to a collector representing a building.

Groups

A group consists of collectors. A collector can belong to several groups. Groups are used to describe affiliation for collectors.