The DPS is a Web application configured in the Servitly platform that leverages several concepts and elements, each one covering a specific aspect and serving a specific user.
In this article, you will find a practical description of the main concepts that compose the DPS.
For a more business-oriented perspective of the DPS, you can take a look at the article What is a DPS (Digital Product-Service) system?.
Who is the DPS intended for?
The DPS is designed to be accessed by all the users involved in the ecosystem of the OEM.
In the DPS, users can be associated with these business entities:
An Organization that represents a structured group of people and resources working together to achieve business goals, like selling products.
A Partner, which is a company or individual that collaborates with the main organization to deliver value, expand, or enhance the overall offer.
A Customer who is the recipient of products and services, who pays for or uses what the organization delivers.
For more details on entities and their relationships, see the article Business Entities.
User Types
According to the job-to-be-done, each DPS user has their own roles and responsibilities, so in the DPS, a user can be associated with a specific User Type (e.g. Technician, Operation Manager).
A User Type defines permissions and profiles what the user can see and do in the DPS.
User Types are associated with specific groups (Service, Customer).
Frontend
The Frontend is the presentation layer where information is displayed, and user interaction takes place.
It is composed of a set of static resources (e.g., HTML, JS, CSS, images) loaded and executed in the user’s browser or app.
The Frontend is composed of a set of predefined pages offering common functionalities (e.g., Login, User Profile Management), but according to the logged-in user, there will be other specific pages defined in Views.
For a more technical overview, you can refer to the article DPS Architecture.
Views and Pages
Instead of giving all users the same experience, the DPS provides different Views, each one offering a tailored user experience according to the job-to-be-done of the user (e.g., Service, Customer).
A View defines the pages composing the DPS for a specific User Type, and how they are interconnected to each other (e.g., navigation menus).
Metrics
A Metric defines a type of information provided by a connected product.
It models a measurable aspect of the product (e.g., temperature, pressure, or energy consumption), or a logic variable (e.g., status, error code, uptime, or counter of pieces), and establishes how individual data points are to be collected and stored.
Each data point is an instance of the metric at a specific moment in time, while the metric itself provides the semantic context that gives meaning to those values.
In the DPS, there are several types of metrics:
Raw Data metrics, which are used to store as is any data point provided by the product (e.g., Temperature).
Computed Data metrics to compute additional values on the cloud side to cover a specific lack of data (e.g., the sum of two Raw Data metrics).
Insight metrics, which are based on algorithms computed on the cloud side to provide additional valuable and actionable data (e.g., Uptime).
Insights
An insight is a specialized type of metric that is computed daily by running an algorithm on data from other metrics.
Its primary purpose is to generate synthetic indicators and actionable information.
For example, the Uptime insight calculates the percentage of daily operational time for a machine by processing values from the Standard System Status, which itself is derived from raw machine status metrics.
Insights can be based on predefined algorithms (e.g., Connection Index, Uptime) or custom algorithms.
Compared to other metrics, insight data is retained for up to 10 years because it is computed daily. For more details, refer to the data retention article.
This extended retention enables long-term comparison and aggregation (e.g., yearly), whereas raw metrics may have a shorter retention period (e.g., 6 months).
Commands and Parameters
Other than receiving data, the DPS also allows sending data to the connected products.
This is made leveraging an IoT Connector with a bidirectional communication channel, and leveraging the concept of:
Command: it represents an operation or task that must be executed on the product side and that is triggered by a simple button (e.g., Start Cleaning Procedure).
Parameter: similar to a command but with a manually provided value (e.g., Temperature set point).
Events
An event represents a noteworthy situation that has happened (e.g., [INFO] Batch operation completed) or is still happening on the connected product (e.g., [FAILURE] Power failure).
There are different types of events:
FAILURE when the machine is blocked and requires immediate intervention (e.g., Inlet blocked).
MAJOR ANOMALY when the machine is working, but action is needed to prevent it from stalling (e.g., Water shortage).
MINOR ANOMALY when the machine is working, but performance or quality may be affected (e.g., Calibration needed).
OPERATION when the machine works properly (e.g., Processing Started).
Events can be automatically created or cleared in case a specific condition occurs on a metric (e.g., temperature > 100°C), or manually to report special situations that cannot be detected by the machine due to a lack of sensors (e.g., High Vibration Detected).
When an event is cleared, it is automatically archived and remains available for browsing or computation of statistics.
An event instance (active or historical) is associated with a thing or a location.
Alerts and Notifications
The event allows you to keep track of everything important that happens, but that's not enough. You also need to notify the right people so they can intervene promptly.
Any event can be associated with an Alert that is user-profiled and visible in the DPS.
An alert can also be notified to the DPS users (e.g., via email or push notification), providing the information necessary to take action as soon as possible.
Actions
When an event occurs, an Action can be created to remind the user that a certain operation must be performed (e.g., Clean the Filter).
In addition to events, actions can be triggered based on time (e.g., every month) or usage (e.g., every 1000 working hours).
An action is associated with a specific thing and addressed to a particular group of users.