Thing Definitions Configuration

Servitly allows products to be described using the concept of Thing Definition and Product Models that are associated with the products (Things) registered in the DPS.

A Thing Definition is the digital representation of a physical product, and this includes:

Metrics: the definition of the Raw data sent by the connected product to the cloud, or compute on the cloud side (Computed Data, Insights).
Events: the definition of any relevant event occurred on the product and that must be registered in the cloud (Failures, Anomalies, Operations, Work Sessions).
Remote Controls: if supported you can remotely control the product by sending Commands to execute or Parameters to update.
User Involvements: the definition of Action that a technician user must perform to keep the product healthy, and Alerts to notify users in case of an event occurs.
Interfaces: the set of Views and Templates used to display all the above elements in the most valuable possible way.
Automations: the definition of Automations to trigger feedback to the remote products or call third-party systems upon an event occurs.

For each specific product model you want to connect to the DPS, you can create a dedicated Thing Definition, but this approach is not effective and not recommended.
To simplify the Console user's activities to define and maintain thing definitions, you can organize them in a hierarchy, where each level automatically inherits elements from its parent level recursively.
For more details about how extending thing definitions you can refer to the Thing Definition Inheritance article.

To design an effective hierarchy of thing definitions for a catalog composed by heterogeneous products, which may have different metrics, events, and visualization dashboards, it is useful to follow a structured approach that takes into account both the similarities and differences between products.

Here are the recommended steps you can follow to configure your thing definitions.

Product catalog analysis

Collect data specifications for each type of product you plan to connect to the DPS.

For each product, you should list:

Available metrics (e.g. temperature, consumption, status).
Relevant events (e.g. alarms, power on/off, errors).
Command and parameters for remote control.
Main physical characteristic (e.g. sensors, actuators, motors) that may affect how views will be defined.

Grouping common elements

Find the elements shared by most product models, for instance:

all models have a metric providing the status of the product (e.g. Status, Power)
most of the events and problems are shared among different models (e.g. Power-On/Off, Error)
like for Events, Actions can also be shared (e.g. Cleanup)
different models may have the same visualization panel (e.g. Energy Consumption)

Group these common elements in such a way that groups are incremental like layers.
These groups will become the abstract thing definitions that will form the backbone of the thing definition hierarchy.

Here is an example of a hierarchy of thing definitions for a refrigerator manufacturer:

With reference to the hierarchy reported above:

Fridge is the root definition that should declare all the elements that are common to Door and Industrial Fridges.
Small Fridge is the abstract definition for any fridge with doors for commercial and domestic usage (e.g. home kitchen fridge, restaurant fridge).
Large Fridge is the abstract definition for fridges used by industry (e.g. frozen food warehouse).

As defined in the hierarchy, the Double Door Fridge is based on the Single Door Fridge definition, as metrics and events for the common compartment (e.g. cooling 5°C) stay the same, while an additional set of metrics and events is added for the second compartment (e.g. freezing -18°C).

Product Models association

In the Product Models definition page, you are free to register any model you need and organize them into structured categories, in the same way your public products catalog is defined. Note that, Thing Definitions will remain hidden to DPS users, instead for Product Models there will be several touchpoints in the DPS.
As end-users are more familiar with your brand naming and catalog, the better you describe the Product Models according to the public catalog, the better the DPS experience will be.
Once the catalog of product models has been defined, you can associate each Product Model to the right Thing Definition (e.g. Family Fridge 350L → Double Door Fridge).

When the product models with the relative thing definitions have been configured, in the DPS you are ready to register products (things) and associate them with the product models.

Modeling complex products

A complex product may consist of several parts, and some of them may be present several times (e.g. fridge compartment).
Instead of struggling to define the same element (e.g. metric) multiple times, you can leverage the concept of Model Part and Sub Thing.

For example, consider a fridge, with several compartments equal to each other; instead of defining a temperature metric for each compartment (e.g. Temp C1, Temp C2… Temp CN), a Sub-thing Definition that models the compartment can be defined. In the DPS, multiple compartments will be registered under the main thing as sub-things.

For more details about how to deal with complex product models, you can refer to the Composite Thing Management article.