Validation of Sensors

Validation of Sensors

Validation is configured in the sensor properties and defines interdependence of the sensors.

Validator is a sensor whose value affects the current sensor. It is selected from the list of available sensors previously created for the same unit. Validation type is the way the validator affects the current sensor. The following validation methods are available:

  • Logical AND: values of both sensors are analyzed, and the logical function AND is applied. It means, the output is true (1) if both values are not null. As a result, current sensor value can be either 0 or 1.
  • Logical OR: both values are analyzed, and the logical function OR is applied. It means, the output is true if at least one value is not null. As a result, current sensor value can be either 0 or 1.
  • Not-null check: if validator is not null, current sensor value is considered true and displayed without transformations. Otherwise, it is blank.
  • Mathematical AND: the mathematical function AND is applied.
  • Mathematical OR: the mathematical function OR is applied.
  • Sum up: values are summed up.
  • Subtract validator from sensor: the validator value is subtracted from the sensor value.
  • Subtract sensor from validator: the sensor value is subtracted from the validator value.
  • Multiply: values are multiplied.
  • Divide sensor by validator: the sensor value is divided by the validator value.
  • Divide validator by sensor: the validator value is divided by the sensor value.
  • Replace sensor with validator in case of error: if the main sensor has no available data, all values are taken from the validator.

 Note.
Validation chain can consist of any number of sensors. So, one sensor can be a validator for another sensor and at the same time depend on the third sensor.

Examples


Logical OR

The example is the following: every door of a vehicle is equipped with a sensor. Every sensor indicates whether the door is opened or closed. It is necessary to know if the vehicle is opened or closed, and it does not matter which door is open.

For this purpose the sensor with Custom digital sensor type should be created in gTrack for every door. Then, one by one, validate the sensors indicating Logic OR as the validation type. When using the Logic OR function, the vehicle is considered to be opened if any of its doors is opened (the 1st, or the 2d, or the 3d, etc.). For convenience, we can remove the Visibility checkbox for all used sensors, except for the last validated sensor. Therefore the visible sensor shows whether the vehicle is closed or opened.

Mathematical AND

Suppose, there is a vehicle with the sensors installed on every door, and these sensors show whether the door is opened or not. In this example it is necessary to know the state of every door individually. The equipment used in our example sends a value about the state of the doors in one parameter (each bit represents the door).

The sensor with the Custom sensor type is created in gTrack and the parameter for incoming value of the state of the doors is indicated. Then the sensor with the Customer digital sensor type is created for every door individually indicating constant parameter (for the first — const1, for the second — const2, for the third — const4, for the fourth — const8). The earlier created custom sensor should be indicated as the validator with the validation type Mathematical AND for every created custom digital sensor. Therefore, using Mathematical AND the verification of a received parameter is implemented, and we find out the state of every door.

Mathematical Operations Usage

Example 1

Suppose, a unit has three different kinds of equipment installed (brush, plough, and thrower). Each of them is connected to a digital input which shows whether it is active at the moment or not. Using the validation system, we can control all three pieces of equipment not separately from each other but at once, in one sensor.

For each piece of equipment, we create a sensor, so, as a result we have three sensors — А, B and С. Let them all be custom digital sensors. With this, each sensor must have a calculation table adjusted in such a way that each sensor has a unique value. For example, when one sensor (brush) is activated, it sends 1, as usual; the second sensor (plough) sends 10; and the third sensor (thrower) sends 100. Thus, if you sum up the received values, you can easily estimate which sensor(s) are activated. Possible values:

  • 0 — all equipment is off;
  • 1 — the brush is on;
  • 10 — the plough is on;
  • 11 — the brush and plough are on;
  • 100 — the thrower is on;
  • 101 — the brush and thrower are on;
  • 110 — the thrower and plough are on;
  • 111 — all equipment is on.

To make this scheme work, adjust dependency between the sensors. Let us make Sensor A basic. Then the validator for Sensor A will be Sensor B, with the validation type Sum up. Sensor C will be validator for Sensor B (with the same validation type).

It is also useful to assign a color to each possible value (see Advanced Properties) so that these colors could be used to visualize sensor in the Monitoring panel, on the map or in tacks.

Example 2

Supposedly, there is a vehicle with two fuel tanks. Each tank has its own fuel level sensor. We need to know total fuel level of the two tanks.

In gTrack create a sensor with the type Custom sensor for one tank, and the Fuel level sensor for the other. For the latter, activate the validation by the sensor with the Custom sensor type, validation type — Sum up. If it is more convenient, the visibility checkbox for the validated sensor can be kept, for the other — can be removed. Therefore we can see the validated sensor value which is the total fuel level for these fuel tanks.

 Using any mathematical operation as a validation method is equal to indicating sensor parameter using formula. In other words, any mathematical operation as a method of validation has an alternative without validation usage. In order to understand how it works, we shall use the above mentioned example with two tanks where we should know the total fuel level of two tanks.

In gTrack create two sensors with Custom sensor type (Tank1 and Tank2) and a fuel level sensor (Total). In the parameter of the Total sensor, enter the formula [Tank1]+[Tank2]. The Tank1 and Tank2 sensors show their own fuel level, and the Total sensor shows the total fuel level of both tanks.

The advantage of using formulas is in the amount of information received. For example, if Tank2 is validated by Tank1, we would know Tank1 fuel level, but Tank2 would show us only the total fuel level for these two tanks. Using formulas, we also know Tank2 fuel level.

The disadvantage of using formulas is the creation of a greater amount of sensors than with the use of validation.


    • Related Articles

    • Sensors

      On the Sensors tab of the Unit Properties dialog, displays a list of all the sensors created for this unit. The table shows the name of the sensor, its type, unit of measure, the parameter on which the sensor is based, description, visibility and ...
    • Digital Sensors

      Usually, digital sensors have two states: on/off, activated/deactivated, etc. For example, it can be an ignition or cargo load sensor. All sensors are configured in Unit Properties => Sensors. In the report template you can select up to four sensors ...
    • Counter Sensors

      This table shows the operation of the Counter type sensors. In the template, set the mask (filter) for sensors or select All sensors. A table can consist of the following columns: Sensor — the name of the sensor. Activated — the time of activation. ...
    • False Thefts or Fillings

      When the tracker is cut off power, FLS sends zero values. As a result, false fuel fillings and thefts appear in reports. How to avoid that? If FLS does not provide data for some reason, the tracker may send zeroes instead. Those zeroes will be ...
    • Sensor Properties

      ...