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 composing 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 user involved in the ecosystem of the OEM.
In the DPS, users can be associated to these business entities:
Organization: it is a structured group of people and resources working together to achieve business goals, like selling products.
Partner: it is a company or individuals that collaborate with the main organization to deliver value, expand or enhance the overall offer.
Customer: it is the recipient of products and services, who pay for or use 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 its own roles and responsibilities, so in the DPS a user can be associated to 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 to specific groups (Service, Customer).
Frontend
The Frontend is the presentation layer where information is displayed, and user interaction takes place.
It is composed by 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 by a set of predefined pages offering commons functionalities (e.g. Login, User Profile Management), but according to the logged-in user, there will be other specific pages defined into Views.
For 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, 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: any data point provided by the product and stored as is (e.g. Temperature).
Computed Data: additional metrics that can be computed on the cloud side to cover specific lack of data (e.g. sum of two Raw Data metrics).
Insight: algorithm-based metrics computed on the cloud side, and providing additional valuable and actionable data (e.g. Uptime).
Commands and Parameters
Other than receive 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 command but with a manually provided value (e.g. Temperature set point).
Events
An event represent a noteworthy situation happened (e.g. [INFO] Batch operation completed) or still happening on the connected product (e.g. [FAILURE] Power failure).
There are different types of events:
FAILURE: the machine is blocked and requires immediate intervention (e.g. Inlet blocked).
MAJOR ANOMALY: the machine is working, but action is needed to prevent it from stalling (e.g. Water shortage).
MINOR ANOMALY: the machine is working, but performances or quality may be affected (e.g. Calibration needed).
OPERATION: 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).
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 remember to 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).