Data processing

Computation of vehicle positions

The computation for positions of vehicles is done on the service layer and can be found in the vehicle service. It predicts a position for a given vehicle (and not for an app user, which uses a vehicle!) for the current time by considering the last known positions of the vehicle. Those positions can be obtained from the vehicle logs (see database model), but need to be distinguished between positions from app instances (currently a lot more frequent, but maybe less reliable) and our trackers. Also if an app requests the vehicle position, its own position maybe got sent with the request and would influence the computation.

For the actual computation the last known positions of all trackers (not app positions, can be distinguished in the database) for a specific vehicle will be considered as well as the last three positions sent by app instances (also for this specific vehicle). For each of those positions the current position will be predicted by using the original speed and heading to determine the traveled track kilometers. Thus the predicted position is calculated by projecting the original position on the track and adding the traveled distance, so the new position will also be on the track to take the pathway of the track into account. Outliers will not be detected at this stage as this is done while computing the overall position (see below).

Now each predicted position gets a weight, which represents the certainty of this position. The weight consists of different factors, that are multiplied together. For an app position an acumulating factor of 0.33 is used (correlates to three app positions, needs to be adjusted if another amount of app positions is used), so that there will be one averaged app position, which should be more robust as there is no assurance how reliable this data is (because it is not from our trackers). Furthermore there are two more factors, which influence the weight (applied to both tracker and app positions):

• time: This factor represents how long ago the original position was received (which also represents the propability for speed changes, which in turn would change the position of course). This factor is mapped (linearly, maybe exponentially decreasing would fit better) from 1 for "right now" to 0 for a maximum value. This value is calculated dynamically from the previous logs to avoid choosing a biased maximum. For this the last 10 logs or all logs from the last hour are considered (whichever is less) once for app and once for tracker positions (because they have probably different frequencies of sending and are generally not related to each other). Then the 80th percentile (to avoid outliers, but also choosing a quite high value) of the receiving intervals is used as maximum value. This value is cut off at 15 minutes to not consider positions that were received an hour ago. This is only relevant if we use LoRaWAN-trackers with TTN. Trackers, which fit more to our application, should not have this problem as well as any app instances used as trackers (because of higher sending rates).
• accuracy: This second factor represents the accuracy of the original position. A less precise position would also lead to a certain deviation for the predicted position. A simple way to calculate this is to use the distance of the original position to the track. Thus the factor is mapped (linearly) from 1 for 0m to 0 for 15m away from the track. Those 15 meters are just a visual estimation from our test data (so could be improved, e.g. also calculated dynamically) and are probably better fitted to app positions though our trackers should be more accurate than that.

In the end all weights are normalized (so their sum is 1) and applied to the predicted positions. From that the average position / track distance (i.e. the final position is still on the track) will be calculated and returned as the current position of the specified vehicle.

Note: There could be another factor that is only applied to app positions, which checks how likely the user is still using the vehicle associated in the database (by comparing app and tracker positions of the same vehicle). This would increase the trust factor for our own trackers, but is a soft requirement (see Requirements) and would be difficult with the current tracker's sending rate.