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 by 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.

Here 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 more complex products’ configuration.

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

You will not need in the Console 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, here 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 instead you can use the CSV import functionality to create all the metrics in a bulk way. 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 events 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, also events can be many, and to help you to 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 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 defined 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 details page.
We suggest you to define multiple tabs, the first one will be the Overview tab, instead 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 to 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 highlighting 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 thing details tabs:

Status tab

A page were to display the historical operating status of the product.

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 template that will be used as page content, for instance thing_status_customer.
When you save the sub-page, also a new template is created.
In the newly created template, place the Status Diagram widget and configure it over the metric providing 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

A page where to display the historical values of relevant metrics.

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 template that will be used as page content, for instance thing_historical_data_customer.
When you save the sub-page, also a new template is 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 metrics 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 metric 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 are relevant to the customer user.

Historical Events tab

A page were to display the historical events occurred on the product.

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 of template that will be used as page content, for instance thing_historical_events.
When you save the sub-page, also a new template is created.
In the newly created template, place the Event List displaying historical events.
This allows the customer user to inspect the events occurred on the product.