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-Reinhardstrass-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

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

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

{
  "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.