Remote Monitoring

The Remote Monitoring allows your customers to remotely monitor their products and receive notifications about relevant events.

If not yet done, we suggest you follow the Initial DPS Configuration guide, which provides you with the basic configuration to be extended with the Remote Monitoring use case.

This guide is composed of the following steps:

Select the Product Model you want to start from.
Configure the Product Model, Thing Definition, and Metrics.
Configure Events to be monitored
Create a thing definition view for your customer users.

Below you can find more details for each step.

Selecting the Product Model to start from

In case you are planning to connect your entire product catalog, which may contain potentially dozens or hundreds of models grouped into product families, we suggest you to start from a product model that is not too complex, but not too simple either. It should be the right mix, which you can use as a basis for the configuration of more complex products.

For instance, if you are an industrial machine tool, you can start from your medium or best-selling model.

You will not need to model every single product, but thanks to thing definitions, you can optimize your configuration work by reusing common elements.

Once you have identified the product model to start from, you can now create its definition in the Console.

Configuring the Thing Definition and Product Model

Create the Thing Definition
In the Catalog / Thing Definition page, you can create the Thing Definition that represent your product in an abstract way.
You can define a hierarchy of thing definitions, where each level inherits common elements from the parent level.
In this way, you can create a generic Thing Definition that is extended by more specific ones.
For instance, below you can see a generic Machine Tool definition, inherited by others, like Drilling Machine, Sawing Machine, and so on.
Define RAW Data metrics
By entering the RAW Data page, you can define Simple metrics modelling the data published by the connected products. For each thing definition, you can define a specific set of metrics. So if you are using inheritance, try to define metrics in an increasing manner as you specialize your thing definition.

Metrics can be created manually one-to-one, or you can use the CSV import functionality to create all the metrics in bulk. We suggest creating a single metric manually to become familiar with the required information. When done, you can export metrics and edit the generated CSV by adding the remaining metrics you want to add to the thing definition. The CSV with all metrics can be imported by using the Import button. During import, metrics already present by name are updated.
Create the Product Model
By entering the Catalog / Product Models page, you can register your own catalogue of product models.
Compared to thing definitions that remain visible only in the Console, product models will be visible to users in the DPS.
Product Models are organized into categories recursively to fit the structure of your unique catalogue.

Categories can be structured as you need, and product models can be moved from one category to another without any limitations.
Once you have created the Product Model by providing the main information, like Name and Description, you can also select the Thing Definition implementing the model.
You can use the same Thing Definition among multiple product models.

Configuring Events to monitor

Event monitoring allows DPS users to be informed of relevant situations that have occurred or are still ongoing.
There are different types of events that can be tracked:

FAILURE: identify the presence of critical problems, for instance, the product is blocked, down, and unavailable to work.
ANOMALY: the machine is not working as expected, for instance, some metrics are out of range, performances are low, or too much energy/resources are consumed.
OPERATION: the machine is working normally, but it is necessary to keep track of what is happening (e.g. startup/warmup completed, consumable refill).

Maintenance and Work Session events are not relevant for the time being and will be considered in other use cases.

To configure the event monitoring

Within the Console, in the Events section, you can define all the event types described above, but before starting, we recommend you make a list of all the events you want to track, and for each one, define:
1. Name that is used to uniquely identify the event.
2. Description giving a short info about the event.
3. Type of the event, one of FAILURE, MAJOR_ANOMALY, MINOR_ANOMALY, OPERATION.
  Try to consider the impact of a problem (risk, urgency, loss), to assign the right type to an event.
  If everything is critical, nothing is considered critical!
4. Group used to better organize the events.
5. Topic used by the system to filter events and compute insights.
6. Active condition used to activate the event when a specific metric value is received.
Once your list is ready, you can focus on each type at a time.
We suggest you to start from the FAILURE events, but be careful to include only the events that match this type.
As for RAW Data metrics, events can also be many, and to help you configure them, you can leverage the CSV file import functionality.
In case you have a metric providing the active code(s), you can use it for all events, but with a different condition value.
Note that only Simple Conditions can be declared in the CSV file; Expression Conditions must be manually defined.
Once FAILURES are registered, you can move to ANOMALIES
Finally, you can define all the OPERATION events, if present.

Configuring the Thing Definition View

Once the initial configuration is verified, you can start defining a more complex user interface by using the entire set of built-in components.

In this use case, we are focused on remote monitoring, so the configuration can be divided into these steps:

You must define how to subdivide information into the thing's details page.
We suggest you to define multiple tabs, the first one will be the Overview tab, and the others will provide more details on different aspects (e.g. Diagnostic, Events, Processing, Uptime, Maintenance).

In the View page, select Thing Definitions (switch the thing definition if necessary), open Customer view, and finally edit the template associated with the Overview sub-page.

Overview tab

The Overview tab is designed to provide at a glance the main information of the thing, and this includes:

Product static information like the Name, Serial Number, Model, GPS Position, and other relevant properties.
Status information like the Connection Status (online, offline) or the Operating Status (e.g. standby, working).
Main metrics like the current value of any important metric of the product (e.g. Temperature, Processing Progress).
Active events highlight the user on the presence of critical ongoing situations.

To define a synthetic and effective overview, you can use these widgets:

Thing Details: used to display static properties of the thing and related context (e.g. location, partner, customer).
You can format date/time and numbers as you prefer.
You can display properties by using filters, for instance: Connection Status, Status Badge and Dictionary.
Value: used to display the latest value of a metric.
The metric value can be highlighted according to Dictionary and Thresholds configured on the metric.
In this way, a critical level is immediately visible by entering the page.
Event List: used to display active events.
This way, when the customer user enters the details page of his product, he will know at a glance if there is any relevant active event.

Less is more!
The overview does not have to show everything, it only has to show what is important at a glance to inform the user about the status of his product.

Once the overview has been defined, you can deepen the details by creating new subpages, navigable via a tabbed menu.

You can create the following details tabs:

Status tab

The page where the historical operating status of the product is displayed.

In the View page, select Thing Definitions tab (switch the thing definition if necessary), open the Customer view and add a new sub-page named Status.
In the template property, write the name of the template that will be used as page content, for instance, thing_status_customer.
When you save the sub-page, a new template is also created.
In the newly created template, place the Status Diagram widget and configure it over the metric that provides the operating status (e.g. standby, working, error).
A good practice when displaying the machine status over time is to correlate statuses with events.

Historical Data tab

The page where the historical values of relevant metrics are displayed.

In the View page, select Thing Definitions tab (switch the thing definition if necessary), open the Customer view, and add a new sub-page named Historical Data.
In the template property, write the name of the template that will be used as page content, for instance, thing_historical_data_customer.
When you save the sub-page, a new template is also created.
In the newly created template, place the Time Series Chart widget and configure it over the metrics (e.g. Temperature, Pieces, Working Time).
Also, the time series, like the status diagram, can display events along metric data.
Alternatively, you can use the Multi Metric List widget if you want a table layout.

You are free to create multiple tabs and give them a more specific name rather than Historical Data.
Note that this tab should display metrics that are useful for customer users; internal metrics must be included in a Technician view.

Here are some examples of names based on product types:

Temperature(s): reports the temperature trends (e.g. fridge, temperature sensor, boiler).
Pressure(s): reports the pressure trends (e.g. compressor, gas generator, boiler).
Cut/Blade/Tool: reports historical position/velocity/force of a tool (e.g. sawing, milling, drilling).
System Status/Measures: reports all the historical data that is relevant to the customer user.

Historical Events tab

The page where the historical events occurred on the product are displayed.

In the View page, select Thing Definitions tab (switch the thing definition if necessary), open the Customer view, and add a new sub-page named Historical Events.
In the template property, write the name ofthe template that will be used as page content, for instance, thing_historical_events.
When you save the sub-page, a new template is also created.
In the newly created template, place the Event List displaying historical events.
This allows the customer user to inspect the events that occurred on the product.