It is important to understand the basic terms and concepts to work efficiently with documentation and the azeti Stack itself.

Products

The azeti software solution consists of individual products, each offering specific functionality within particular layers.

LayerProductDescription
Sensor Layerazeti Site ControllerAgent running on edge gateways.
Communication Layerazeti EngineCentral server software for communication and management.
Application Layerazeti Control PanelUser interface for overall administration and configuration.










Site Controller

Intelligent low footprint agent, which runs close to sensors and machinery, collects data, automates and communicates with the upper layer Engine.



Engine

This is the central server application that receives the alarms and events from remote sites, provides API for integration and offers the base layer for the upper layers, such as the Control Panel.





Control Panel

Central user interface for operations and administration. Remote Site Controllers will be administered and configured centrally from within this easy to use web-UI.e


Terminology

Organization

A single Engine installation can have one to many organization, so to say tenants. Each organization will have one or more locations that represent a single Site Controller instance. Organizations are a great tool to structure installations, e.g. having a North, East, South and West organization or one per department. Each of these are treated as closed entities, users only have access to data within their own organization.

Location

One unique Site Controller instance represents a location within an organization. Each Site Controller has a unique serial which can be later on mapped to a comprehensible location name. For example Berlin-Reinhardstrasse-39.

Device

A Site Controller communicates with one or more devices to receive measurements from the attached sensors. Common examples for a device are a physical sensors, machines, bus adapters, I/O modules, relays, dry contacts or any other object to which a Site Controller can establish a communication connection One device can have multiple sensors (so to say data points or metrics).

Examples

  • Temperature Sensor
  • Smart Meter
  • Diesel Fuel Tank
  • Video Camera

Sensor

A single sensor describes one particular reading from a configured device, whereas many sensors can be derived from a single device. Sensors are the base for all further configurations and actions, such as automation, deriving virtual sensors and calculations.

Examples

DeviceSensors

Smart Meter

  • Voltage
  • Power
  • Current
Fuel Level Sensor
  • Fuel Level
  • Fuel Percentage
  • Fuel Consumption
I/O Module
  • Analog Sensors 1
  • Analog Sensors 2
  • Analog Sensors n
  • Digital Input 1...n
  • Digital Output 1..n

Virtual Sensor

Deflections of sensors can be merged into a single virtual sensors. This is especially useful to combine sensor readings and to execute post-calculations. Virtual sensors are calculated right inside of the Site Controller.

Examples

SensorsResulting Virtual Sensor
  • Voltage
  • Current
Power = (Voltage x Current)
  • Current Fuel Level
  • Overall Fuel Level

Average Fuel Level = avg(Fuel Level)

Minimum Fuel Level = min(Fuel Level)

Fill Level in % = Current Fuel Level / (Overall Fuel Level / 100)

Event

Events are triggered by a change in a state of a sensor. For example a temperature sensor can be configured to change its state to Critical above a certain threshold. When it changes the state it will send the event. Events are used as triggers for automation rules and notifications.

Severity

Each event state can have a configured numerical severity level. This level is used as the groundwork for notification delivery and for representation within the Control Panel, different levels show up in different colors.

Structure

Check out this simplified structure tree of the individual elements and their relation and inheritance.

{
  "Organization": {
    "azeti": {
      "Locations": {
        "Berlin": {
          "Devices": {
            "MODBUS Sensor 1": {
              "Sensors": {
                "Temperature": {
                  "Events": {
                    "OK": {
                      "message": "Temperature is fine",
                      "severity": 100
                    },
                    "WARNING": {
                      "message": "Temperature very high",
                      "severity": 200
                    },
                    "CRITICAL": {
                      "message": "Temperature too high",
                      "severity": 300
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}



Types of Users


There are different roles in the kind of user that can access the server. These are the possible roles (a user can have more than one role):

  • Superadmin: Is the user that administers the whole server. Not useful for displaying data. Can create/delete organizations and users.
  • Admin: The user that administers an organization. Is able to create/delete users, configure location and edit views.
  • Operator: A user that can access the server to view data but cannot reconfigure anything on it.

Additionally the following roles are available but do not have access to the server:

  • Gateway: The user/password that the local gateway will use to deliver the data.
  • Services: Used to integrate third party software via an external API
  • Access control: For sites with physical access control (like a keypad and a lock), this is used to indicate which users can have access to a site.
  • Notifications: Users that can receive any kind of notifications.


This guide will only cover the options available for the Operator type users. For the Admin users functions please see the Control Panel Administrator's Guide