When addressing the first configuration of your DPS system or when performing a review to improve your existing system, we suggest you to divide the work in phases.
Each phase is characterized by:
a single layer to focus your attention on
criteria of evaluation and completion
The phases broadly correspond to the main menu items in the Servitly Console.
Establishing the IoT connection
Before starting with the actual configuration we suggest you to establish and implement the method by which the connected products communicate with the DPS system.
For this purpose Servitly offers these options:
Cloud-to-Cloud integration with a market IoT platform
If you have to choose an IoT connector, you should also consider:
Will your connected products need to receive remote updates?
If yes, we suggest you to use a connector based on MQTT.
Do your connected products have limited bandwidth or data traffic?
If so, we recommend using an HTTP-based connector, which avoids using an always open channel such as MQTT.
If you do not have a ready-to-connect product, you can take advantage of the concept of Virtual Things, which allows you to publish data to the DPS without having a physical product.
Appearance
In the Appearance section you set every single detail that affects the appearance of your DPS system, including images, graphics, labels and messages.
You also manage all the translations needed to offer your system in different languages.
Your brand
Through Images and CSS you can set your DPS as close to your brand as possible, to make you feel at home and let your users feel at your premises.
Your partners’ brand
If you associate a subdomain to a partner, with the same approach you can change here the appearance of the DPS system published at the subdomain’ address according to your partners’ brand.
Labels and translations
Through Labels you manage every single piece of text in your DPS system. You can add as many languages and translations as you want.
Messages
Through Messages you can configure all the messages the DPS system sends to the users when a certain event occurs.
Catalog
In the Catalog section you define the catalog of all the Product Models that will be connected to the DPS system.
Product models are organized into Categories, allowing you to easily manage many product families, series, models and sub models.
Every product model is represented by a Thing Definition, which declares Metrics, Events, and Views.
A Thing Definition can inherit from another one, allowing you to work only on what is different and share what is common.
Properties
In the Properties section you extend the metadata of the DPS business objects.
You can add and edit properties for these type of objects: Thing, Location, Customer, Partner, User.
Thing properties are defined for each Thing Definition.
RAW Data
In the RAW Data section you define all the metrics that a product sends to the DPS system.
Metrics are defined for each Thing Definition.
Computed Data
In the Computed Data section you can add new metrics that are computed taking other metrics as input.
Computed data are defined for each Thing Definition.
Remote Control
In the Remote Control section you define all the possible commands and parameters that the DPS is allowed to send to a product.
Commands and parameters are defined for each Thing Definition.
Events
An Event is any situation that occurred or is occurring right now on the product, or at a location, and that deserves to be tracked.
In the Events section you define all the possible event types you want to track and the conditions that allow the DPS system to detect them by processing data.
Events are defined for each Thing Definition.
Insights
The purpose of insights is to extract synthetic, interesting and actionable information from data and events.
Insights are implemented through Insight metrics defined for each Thing Definition.
An insight metric is a calculated metric that clearly and quickly illuminate and summarize a certain topic that is interesting for the product-service stakeholders.
Potentially, insight metrics can measure and illuminate on all topics of interest to product-service stakeholders: health, productivity, consumption, quality, etc.
Alerts
The purpose of Alerts is to raise the attention of the user on a particular event.
Alerts are defined for each Thing Definition.
Actions
The purpose of Actions is to ask the user to perform a particular activity that is suggested or prescribed upon an Event. The DPS system then asks the user to confirm whether or not they have performed the activity.
Actions are defined for each Thing Definition.
Automations
Automations let the DPS automatically launch commands on a connected product or trigger a workflow through an external information systems (like FSM, CRM, ERP) upon an event.
Service
In the Service section you define the Service Levels composing your service offering and their pricing.
Once you have defined Service Levels you can restrict the visibility of certain features of your DPS system only to customers who have purchased a specific Service Level.
Your connected products can also call the DPS system and request which level is associated with them. Based on the response they can unlock certain features.
Interfaces
In the Interfaces section you configure the organization, layout and content of any page of the DPS system.
Pages are organized in Views. Each View is dedicated to a single persona.
We recommend you focus on one view at a time.
Views are defined for each Thing Definition.