Process management

Defining a process

The first step to get started is to define a process. Go to Admin → Insight → Flows and click on the 'Create process' button

A process is fundamentally a graph with nodes and edges. In the platform we call the nodes steps and the edges transitions. Start by defining all the steps in the process. You do this by giving them a unique id and name

When all the steps are defined the transitions rules should be configured too. A rule transition contains a set of conditions which will be evaluated: e.g. the asset should be in a geozone with a certain tag. Before we can do that we should first explain how transition rules are evaluated

The system supports two set of transitions:

• direct transitions: these rules are evaluated without taking the current process state of the device into account. Typically they are used for steps which are valid without looking at any other context. A good example is a geozone match with the home base.
• transitions to other steps: those transitions are evaluated for a process step pair. These rules are used to enforce a certain sequence between process steps

The general approach is that transitions between steps are considered more precise and as such they are evaluated first. So the system will first evaluate all the transitions to other steps from the current step. If no match is found the direct transitions will be evaluated.

Linking a process to devices

In the process definition assets are linked to processed by specifying to which assets they apply. The choice is either all assets, enumerate the assets or filter by asset tag.

Advanced transitions: high priority

The system supports the special case of 'high priority' direct transitions. Transitions which are marked as high priority are evaluated before the transitions to other steps.

High priority transitions are typically transitions which are 100% certain.

Advanced transitions: delayed transitions

A transition can be marked as delayed with a timeout expressed in minutes. Where this can be relevant is best explained with an example.

Imagine we have a process with the states 'Home', ' Home-outbound' and 'Customer'. The 'Home' and 'Customer' steps have direct rules based on a geozone match. The 'Home-outbound' step represents the transit from the Home location to the Customer location. It is entered with a transition from Home with as rule a START event. In many cases that is the right logic however it is perfectly possible for a device to report a START but then a stop again in the Home zone. This happens when it is just moved on site. In order to avoid a false process transition we can put a delay on that transition rule. A good delay timeout would be something which is longer than the stop timeout, for example 40 minutes. If a transition with a delay is triggered the new step is only taken when the timeout expires and no new process step has been taken. If the asset would stop again in the Home geozone nothing happens. The downside of the delayed transition is of course that the transition is effectively delayed.

Linked to the delayed transitions there is also the concept of activating a delayed steps when a step is entered. Let's reuse the same example. Image we got that START event but the timeout has not yet expired. Then we enter the customer site. By entering the customer site it is confirmed that we were in transit. So we can model on the Customer step that any delayed ' Home-outbound' steps should be effectively activated which means they will be visible in the history.