To master the configuration of your DPS system, it is useful to understand the layered structure of Servitly back-end.
Indeed, we can consider Servitly back-end as divided into layers.
Imagining a hypothetical data journey from the connected product up to the user, each layer adds value to raw data.
The principle guiding the definition of these layers comes from analyzing the data journey in the user's mind:
The layers are:
Digital Twins layer: it creates and manage the digital copy of each connected product
Events layer: it processes raw data to detect and store any relevant event that occurred
Insights layer: it processes raw data and events to compute synthetic, interesting and actionable information
Alerts layer: it processes events to highlight situations requiring the attention of the user
Actions layer: it processes events to provide the user with recommendations or prescriptions that help addressing the situation
Automations layer: it evaluates rules on occurred events and triggers feedback to the product or calls external information systems
Digital Twin layer
The Digital Twin layer creates and manage the digital copy of each connected product. It collects, organizes and stores the raw data sent by them, and also manages the transmission of parameters, commands, and updates.
Connection with products, whether one-way or two-way, is established through the available IoT connectors.
You can configure all the aspects of this layer through the following sections in the Console:
in the RAW Data section you define all the metrics that a product sends to the DPS system
in the Computed Data section you can add new metrics that are computed taking RAW metrics as input
in the Remote Control section you define all the possible commands and parameters that the DPS is allowed to send to a product
Events layer
The Events layer processes raw data to detect and store any Event. An Event is any situation that occurred or is occurring right now on the product, or at a location, and that deserves to be tracked.
In the Events section you define all the possible event types you want to track and the conditions that allow the DPS system to detect them by processing raw data.
Useful terms
Event instance: a single occurrence of an event that happened at a given moment in time
Event type (or Event definition): the type of event that occurred
Event class: a higher level for classifying event types
Event classes
We classify event types in these classes:
failure → the product is blocked, down, unavailable
major anomaly → the product is still working but something wrong has happened that could potentially cause a failure in the short term; a short term action is needed to avoid this risk
minor anomaly → the product is still working and something wrong has happened; however there is no risk of short term failure, therefore a programmable action is enough to deal with this case
operation → the product is performing a normal operation or an event has occurred that is part of the normal operation of the product
work session → this class is similar to the operation, but richer; in fact, this class allows to associate to the event the measures detected during the operation and to compute its main KPIs; typically it is used to track the main operation for which the product has been designed by the manufacturer and bought by the customer
maintenance → a maintenance activity was performed on the product by an operator or technician
Event instances creation
Event instances can be created in the DPS system in two ways:
the Event is detected automatically by processing raw data → a condition is verified any time raw data is received
the Event is reported by a user → a widget is exposed to the user that allows them to report an event
Insights layer
The Insights layer processes raw data and events to compute synthetic, interesting and actionable information.
In the Insights section you find all the functions available to configure the behavior of this layer.
Data processing is done through Algorithms while the output is stored into Insight metrics.
You can use built-in algorithms or define your own.
Alerts layer
The Alerts layer processes events to highlight situations requiring the attention of the user. Such situations are highlighted through badges and widgets in the web view and also through notifications.
In the Alerts section you configure the behavior of this layer.
Actions layer
The Actions layer processes events to provide the user with recommendations or prescriptions that help addressing the situation. The DPS system then asks the user to confirm whether or not they have performed the recommended or prescribed action.
In the Actions section you configure the behavior of this layer.
Automations layer
The Automations layer evaluates rules on occurred events and triggers feedback to the product or calls external information systems (like a FSM, a CRM, a ERP, etc.).
In the Automations section you configure the behavior of this layer.