Intelligent low footprint agent, which runs close to sensors and machinery, collects data, automates and communicates with the upper layer 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.
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
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.
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.
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).
- Temperature Sensor
- Smart Meter
- Diesel Fuel Tank
- Video Camera
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.
|Fuel Level 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.
|Sensors||Resulting Virtual Sensor|
|Power = (Voltage x Current)|
Average Fuel Level = avg(Fuel Level)
Minimum Fuel Level = min(Fuel Level)
Fill Level in % = Current Fuel Level / (Overall Fuel Level / 100)
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.
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.
Check out this simplified structure tree of the individual elements and their relation and inheritance.
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