UPTEC F 17044

Examensarbete 30 hpAugusti 2017

Real time tracking in truck fleet management Master thesis in embedded systems

Gustav Wiklander

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

Real time tracking in truck fleet management

Gustav Wiklander

This thesis researches Scania's challenge to display the position of trucks, with high accuracy and good user experience while with minimal position transfers from the truck. This thesis presents an event triggered position update (ETPU) algorithm for sending positions from the truck along with real time estimation on the client. The key point with this system is that the truck computes the same estimation to evaluate its accuracy and sends a new position if the estimate is insufficient. This achieves a system in which position updates are only done when needed to achieve a selected accuracy. Simulations were done and metrics for: accuracy, data consumption and user experience were applied for evaluation. Results are presented to inform the readers of the ETPU's potential.

ISSN: 1401-5757, UPTEC F17044Examinator: Tomas NybergÄmnesgranskare: Christian RohnerHandledare: Jakob Palmheden

1 Populärvetenskaplig sammanfattningScania, vilket är ett premium märke inom lastbilar tillgodoser sina kunder medmjukvara för att spåra sina lastbilsflottor. Positionen av kundens lastbil är visu-aliserad på en digital karta. Det är inte lastbilens nuvarande position utan densenaste mottagna positionen. Positionen kan vara upp till en minut gammal.Detta examensarbete gjordes i syfte att hitta en lösning som uppnår högre nog-grannhet i positionen på kartan utan att skicka positioner från lastbilen oftare.I stället för att visa den senast mottagna positionen, så realtids estimerar dettaexamensprojekt lastbilens position. Denna estimering görs även på lastbilen somskickar sin position. Då vet lastbilsmjukvarar hur dess position visas hos kundenoch kan ifall den skiljer sig för mycket från dess faktiska skicka en ny position.Examensarbetet bestod också av framtagandet av en realistisk simuleringsmiljöför att utvärdera det nya systemet för realtids positionering av lastbilar. Re-sultatet visade att det var möjligt att förbättra noggrannheten och samtidigtminska den genomsnittligga frekvensen man skickar positioner från lastbilen.

1

2 AcknowledgementsWe would like to thank Scania AB and especially Jacob Palmheden our su-pervisor at Scania who made the foundation to start this thesis. I would alsopersonally thank Christian Rohner at Uppsala university who reviewed and gaveadvice during the thesis work.

2

3 Abbreviations and definitions

Position-aware applications Position based serviceFMS Fleet management system - IT system for managing a large set

of vehicles in areas such as logistics, maintenance, driver manage-ment, fuel management, tracking and diagnostics.

FMP Fleet management portal - client serviceson board Something that is permanently installed on the platform and is

communicating through a cable or wireless connection with othernodes on the platform.

off board something deployed on a server or residing in some network partwhich is not on the platform.

device mobile device with a wireless connection to the platform or amobile device with a cable connection to the platform which canbe detached by the end user.

Data center Defined as middleware is defined in paper [2].IoT Internet of ThingsSOA Service-oriented architectureIT Information technologyDPUA Decisive Positional Updating AlgorithmPDF Probability density functionReverse geocoding Translates a GPS coordinate to a readable street address.

3

Contents1 Populärvetenskaplig sammanfattning 1

2 Acknowledgements 2

3 Abbreviations and definitions 3

4 Introduction 54.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1.1 Internet of things and industrial companies . . . . . . . . 54.1.2 Scanias Fleet Management System . . . . . . . . . . . . . 54.1.3 Scania’s current algorithm for position updates . . . . . . 5

4.2 Purpose of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . 54.2.1 System architecture . . . . . . . . . . . . . . . . . . . . . 64.2.2 Event based position update . . . . . . . . . . . . . . . . 64.2.3 Real time estimation of the position . . . . . . . . . . . . 64.2.4 Investigate position message latency . . . . . . . . . . . . 6

5 System architecture 65.1 Architectural considerations . . . . . . . . . . . . . . . . . . . . . 65.2 The Architectural design . . . . . . . . . . . . . . . . . . . . . . . 7

6 Algorithm 76.1 Time interval based algorithm . . . . . . . . . . . . . . . . . . . . 76.2 Event Triggered Position Update Algorithm . . . . . . . . . . . . 8

6.2.1 Position estimation . . . . . . . . . . . . . . . . . . . . . . 86.2.2 Trigger set for position update . . . . . . . . . . . . . . . 9

6.3 Delaying the estimated position . . . . . . . . . . . . . . . . . . . 96.4 Variable ETPU parameters . . . . . . . . . . . . . . . . . . . . . 106.5 Comparison metric system . . . . . . . . . . . . . . . . . . . . . . 116.6 Position message latency . . . . . . . . . . . . . . . . . . . . . . . 11

7 Simulation methodology 127.1 Simulation data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127.2 Simulation software . . . . . . . . . . . . . . . . . . . . . . . . . . 12

7.2.1 Simulation design . . . . . . . . . . . . . . . . . . . . . . . 127.3 Simulation procedure . . . . . . . . . . . . . . . . . . . . . . . . . 137.4 Simulating latency . . . . . . . . . . . . . . . . . . . . . . . . . . 13

8 Results 158.1 Data consumption and error distance . . . . . . . . . . . . . . . . 158.2 Incorrect routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

9 Discussion 209.1 Maximum error and time . . . . . . . . . . . . . . . . . . . . . . 209.2 Average error distance and data consumption . . . . . . . . . . . 209.3 Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209.4 User experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

10 Future work 21

4

4 Introduction

4.1 Background4.1.1 Internet of things and industrial companies

Internet of things (IoT) is becoming more relevant in the logistics and the trans-portation industry because it enables a new form of IT services that relies on realtime data from end nodes such as vehicles. Tracking vehicle position, route, andpredicting future position can all be provided by IoT technologies [4]. Scania, aworld leading manufacturer of trucks has embraced IoT technologies. All trucksmanufactured today by Scania have a 3G communication unit. This global ac-cess to truck status data has resulted in development of IT services under theumbrella named Connected Services to help customers improve efficiency andmake strategic decisions. Scania describes its own benefits with providing theseservices as:

“Developing and/or sustaining competitiveness and revenue streams.“ [1]

Which is in accordance with research as to how IT services can enhance the coreproducts for industrial manufacturers [3].

4.1.2 Scanias Fleet Management System

Scania’s fleet management system (FMS), consisting of: sensors installed in thetrucks, CAN bus, driver interface units, a wireless communication unit, a datacenter to store sensor- and driver data, server processes, and client applicationsare in total Scania’s FMS. Vehicle position and tracking are the most usedservices at Scania’s fleet management portal (FMP). The position and vehicletracking services represent more than 60% of FMS usage and about 65% ofsubscriptions. Thus the algorithm for sending position data and displayingtruck positions has a significant impact on the value of Scania’s FMP platform.

4.1.3 Scania’s current algorithm for position updates

As of today Scania’s trucks send their positions to a data center with fixedintervals. The positions are used for many of the services in the FMP butmainly for displaying the truck’s latest transferred position and to track itsroute. The position data is also used for data-mining purposes internally byScania to make strategic business decisions.

4.2 Purpose of the thesisThe quality of position-aware IT services by definition depend on the qualityof the position data. The necessary level of quality differs between services.A service that retraces the route of a truck requires no more than the positionpoints at every taken turn or exit to reconstruct the correct route. In general forretracing services, transfer latency is not of a concern because the processing isdone in the aftermath. Services with real-time functionality require up-to-datepositions. However, sending position data via the cellular network costs money.A balance between data rate consumption and position quality is desired. With

5

position updates occurring occasionally real time estimates could increase theaccuracy. The quality of the estimate depends on the quality of the last availableposition. Quality in this case is not only a matter of time elapsed but also speedcontinuity and road equality. If the estimate is based on the assumptions thatthe truck continues at the same speed and along the current road, every time thetruck invalidates this assumption the on-board system triggers a new positiontransfer to keep the quality of the estimate. The comparison naturally has tobe done on-board, thus requiring the on-board to also implement the estimationalgorithm for comparison with the actual position.

4.2.1 System architecture

One of the architectural challenges involving big data in the world of IoT isscalability. Scalability in this context refers to scaling capability of volumestorage and data processing [2]. The thesis presents an architecture to handlethe scalability issue regarding positional data processing on a large set of trucks.

4.2.2 Event based position update

As mentioned the truck will do the same estimation as the client to compare withthe actual position. When an event occurs such as exiting a highway or turningleft in an intersection the estimation algorithm will not only deviate from theactual position but also display an incorrect route. The algorithm then triggersa position update to prevent displaying an incorrect route in the client. Thethesis presents the design and simulation results of a Event Triggered PositionUpdate (ETPU) algorithm using real truck position data.

4.2.3 Real time estimation of the position

An ETPU that bases it’s decision to send on the inaccuracy of the estimate, canwhen one ignores latency guarantee an upper bound of inaccuracy which doesnot grow with time. The accuracy of the estimate it self will depend on howstrict the on-board trigger set is configured. The thesis presents an algorithmfor estimating truck position given an earlier position.

4.2.4 Investigate position message latency

As stated earlier, the quality of the estimate depends on the quality of the lastavailable position. Latency when transferring positions wirelessly from on-boardto a data center will cause the availability of the updated position to be delayedfor client access and the prior position will be used as reference for an extendedduration. The upper bound inaccuracy can no longer be guaranteed. The thesispresents a realistic latency probability distribution and robustness measures toreduce the latency impact.

5 System architecture

5.1 Architectural considerationsAs stated earlier one of the challenges with big data in IoT is scalability. Asdata arrive from more than 200,000 trucks to Scania’s data center the processing

6

and insertion has to be done at a faster rate than the average rate of arrival[2]. Therefore, any data processing should if possible be delegated to the sensornodes (truck) and the client nodes (client browser). The architecture proposedplaces all processing on the sensor and client nodes. The truck applies the ETPUalgorithm and when it triggers sends a position to the data center. The clientnode retrieves the latest position from the data center and applies the sameestimation algorithm. The data center is only used for storage and retrieval toimprove the scalability.

5.2 The Architectural design

Figure 1: The proposed architectural design.

6 AlgorithmIn this section Scania’s algorithm for the decision to send and sample positionsis presented. The ETPU algorithm is presented and the design choices areexplained. A metric system for evaluating the algorithms is also presented.

6.1 Time interval based algorithmScania’s algorithm for the decision to send positions is interval based. Meaningthat position transfers occurs with a fixed time period between each transfer.The transfer does not only contain the current position of the truck but alsoa buffer of additional position samples which are sampled independently and

7

the sampling frequency depends on the velocity of the truck. Scania’s mostpremium position subscription provides position updates every minute. Theintention is to provide accurate position data but still with reasonable dataconsumption. This thesis compares the ETPU algorithm with Scania’s mostpremium position service since both have similar goals as to accuracy and dataconsumption. Scania’s algorithm:

• Transfers current position every one minute.

• Also with every transfer a position buffer is also transfered.

• Position buffer is sampled via:

– Speed < 2 km/h → sample position and wait until speed > 6 km/hand sample again.

– Speed < 30 km/h → sample next position after 60 seconds.– Speed > 30 km/h→ sample next position after 2∗ speed h

km seconds.

6.2 Event Triggered Position Update Algorithm6.2.1 Position estimation

Given a prior position with speed, heading and the time sampling. The realtime estimation is done as follows:

1. Map position to a road.

2. Estimate driving direction by comparing truck heading to road geometry.

3. Assume the truck continues along the same road.

4. Continue at the same speed.

5. If the prior position maps poorly to a road segment use the prior positionas estimate. Such instances include being in a parking lot or off road andit will be very difficult to make a good estimate and certainly mapping toa road will definitely produce an incorrect route. Simply making it standstill is a safe fall back.

6. If the speed exceeds the speed limit plus an additional percentage: thespeed of the estimate is lowered to the speed limit. The speed limit alonga road is not necessarily constant and if the speed limit drops to a lowerlevel the estimate will drive past the real truck and trigger a positionupdate at some point. Being ahead is worse than being behind becauseof the risk of displaying an incorrect route since the estimate will havealready passed the intersection or exit which might be taken.

7. If the speed falls below a minimum speed threshold: the estimate speedis set to zero. At low speeds setting the speed to zero will only leadto the error distance growing slowly. Secondly this will guarantee thatthe estimate is behind the real position and thus an incorrect route isimpossible to display.

8. If the road ends: try turning right as is done in circulations. Using adefault guess is better than nothing and it will be the correct assumptionwhen entering circulations.

8

6.2.2 Trigger set for position update

After the estimation is done the trigger set is applied to potentially trigger aposition update. To improve the reliability a trigger buffer is used, requiringone or more consecutive triggers to occur before an actual position update isfired. The trigger set is defined as:

• The distance between the real truck position and the estimated positionexceeds a threshold. Applying a maximum allowed error distance keepsthe error from growing indefinitely thus always gives a fixed estimationaccuracy independent of time.

• If the real position maps well to a road segment:

– The estimate positions road mapping does not match the actual roadand there is a slight heading difference. If the truck changes road anew position has to be transferred because the estimation will displayan incorrect route.

– The estimate position and the real position map to the same road butwith opposite headings (with some margin). This indicates that theestimate is driving in the opposite direction which is also an incorrectroute.

– The estimate does poorly map to a road segment. When the truckfor instance leaves a parking lot it is time to resume doing estimates.

6.3 Delaying the estimated positionOne problem with estimating the position in real time is instances when theestimation is ahead of the real truck. It happens when the truck slows downrelative to the last position update and thus the estimation will exceedingly beahead of the real truck. It is only a problem in combination with an unexpectedturn or exit because the estimation will for some duration travel on an incorrectroute until a new position update is done to correct this error. The duration ofan incorrect route should be reduced and preferably removed entirely.

Still doing the estimate in real time on the truck and applying the triggerset to distinctively decide if a position update is required, but on the clientside applying the estimation algorithm a fixed number of seconds behind theactual time reduces the risk of displaying an incorrect route. Since displayingan incorrect route requires the estimate to be passing by the exit/turn as thealgorithm is in the process of detecting such an event or has already passed itwhich means the estimate is ahead of the truck. Then, by adding a delay tothe client estimate the risk of the delayed estimate to fall into the mentionedscenario is less likely and because of the maximum error distance threshold theactual estimate cannot be too far ahead of the actual truck position. What willthen happen when the truck takes an exit or makes a turn in an intersectionis that a position update will probably trigger within seconds. If the delayedestimate is behind in travel time more than the time to detect the event then theposition update for that event will be available in time for the client estimateto take the exit or make the turn. The client estimation can make the correct

9

maneuver because a position update has already taken place in the future rel-ative to the client’s delayed time. Thus instead of a normal position estimateusing the past position update one can just make a route from the past positionupdate to the future position update.

An additional benefit of adding a delay of N seconds to the client is itsimpact on position update rate. For instance, when a position update occurs bythe on-board system the estimation in the client will have access to a positionN seconds ahead of the client estimation. For the next N seconds the clientcan route from the past position to the future position. During that period anyadditional position updates will not improve the estimation during that period.After a position update occurs the on-board system can wait with sending a newposition for the next N seconds even if the ETPU algorithm triggers a positionupdate during that period. Therefore, adding a delay limits the minimum timebetween position updates and by doing that also improves the average positionupdate rate.

6.4 Variable ETPU parameters

Name Type FunctionMaximum error distance [m] If error distance exceeds ’Maximum er-

ror distance’ a position update is trig-gered.

Delay [s] Amount of time the client estimation isdelayed.

Minimum speed [km/h] If speed is less or equal then speed usedfor estimation is zero.

Consecutive triggers Number The ETPU algorithm has to trigger Ntimes in a row for a position update tobe fired.

Speed limit threshold % If speeds exceeds the speed limit bymore the speed limit threshold the es-timation speed is lowered to the speedlimit.

Incorrect road Degrees Not only has the estimation map to adifferent road heading must differ morethan ’Incorrect road’.

Opposite direction Degrees In order for a opposite direction to betriggered the heading difference mustexceed ’Opposite direction’.

Matching Threshold Number HEREs API (see section 7.2) to reversegeocode also produces a match qualityof the mapping. If the matching qual-ity is not greater than the threshold theposition is deemed as not on a road.

Table 1: Variable parameters of the ETPU algorithm.

10

6.5 Comparison metric systemIn order to evaluate the ETPU algorithm and Scania’s time interval based po-sition update algorithm, a metric system is required. The metric system has toreflect the points of interest in regard to data consumption rate and estimationaccuracy. In the thesis three metrics were chosen to evaluate the algorithms:

1. Data consumption rate - The less the better because the cost of wirelessdata consumption.

2. Average error distance - Average error distance in the client in relation tothe actual position.

3. Incorrect routing - Only occurs for the ETPU since it displays an estimatewhile the time interval displays the latest available position. An incorrectroute, such as continuing forward in a intersection while the truck actuallyturned left, one could argue is a severe error since the fleet managers whoobserves the truck movement will first assume that the driver has madea mistake and later when the ETPU triggers an update will see that thedriver actually turned left and will instead loose confidence in the FMPpositioning service.

6.6 Position message latencyAfter the ETPU algorithm has triggered the need for a position update the on-board system transfers the position data wirelessly to Scanias data center. In thereal world the transfer takes some time and has to be considered in the model.Latency breaks the maximum-distance-threshold’s guarantee of accuracy sincethe client will display an incorrect estimate during the latency period. It alsoincreases the likelihood of displaying an incorrect route.

11

7 Simulation methodology

7.1 Simulation dataThe simulation used an hour of sufficiently high resolution position data of atruck driving back and forth between Södertälje and Botkyra in Sweden. Theroute consist of to a large degree of high speed motorway but also of exits,circulations, turns and speed changes. The GPS positions had a one secondresolution, speed had a higher resolution but was averaged down to one secondresolution, heading for each position was calculated as the direction from thelast position (with a successful heading calculation) to the current position, ifthe distance was greater than three meters, otherwise the last successful headingwas used instead.

7.2 Simulation softwareHERE provides a map and a navigation API made with the intent for city andvehicle navigation. HERE map was chosen as the navigation API as it providedthe necessary functionality required by the ETPU algorithm and its visualizationcapabilities. The simulation was written in JavaScript to easily interface theHERE map API and because HERE map works well in web browsers.

• Displays a map in a browser with focus on street navigation.

• Reverse geocode a GPS coordinate to a street address and its matchingquality (see section 6.2.2).

• Reverse geocode a GPS coordinate into a road segment with shape. It isneeded when estimating the position since the truck continues along theroad.

• Display custom markers on the map. Used in simulation to display thetruck’s actual position, the ETPU algorithm’s estimated position and thepositions transferred to the data center.

• Able to route between two GPS coordinates which is used in the clientestimation when using delay as mentioned in section 6.3.

7.2.1 Simulation design

The code built to run the simulation was divided into objects resembling thearchitectural design described in figure 1.

• A truck object was designed which at each tick updates its position, speed,heading and ran the ETPU algorithm to check if a position update wasnecessary.

• A data center object to store all the positions sent from the truck.

• A client object to retrieve the latest position from the data center applyingthe estimation algorithm.

12

7.3 Simulation procedureSimulations were done by replaying the one hour truck driving data, describedin section 7.1, applying the ETPU algorithm every second and updating theclient estimation every second. The metrics were calculated as follows:

1. Data consumption rate was represented by two figures:

(a) Average time between position transfers

=total time

total number of position transfers

(b) Average transferred bytes per minute

= message size ∗ total number positions transfers

total minutes

2. Average error distance

=

∑total timet=0 Distance(Truck position(t), Estimate position(t))

total time

3. Incorrect routing - Total number of incorrect routes.

Simulations were done with varying values of the parameters: maximumerror distance and the amount of delay. The parameters described in table 1.were fixed throughout all simulations.

Maximum error distance [m] 50 75 100 125 250 500 1000Delay [s] 0 5 10 15 20 30 45 60

Table 2: Parameter variations during simulation.

Name ValueMinimum speed [km/h] 6Consecutive triggers 3Street Match Quality Threshold 0.65Speed limit threshold 10%Incorrect road 10◦

Opposite direction 120◦

Table 3: Parameters with fixed values during simulation.

7.4 Simulating latencyIn order to simulate the impact of latency in a realistic manner a probabilitydistribution function (PDF) for latency was crafted. Scania’s trucks send amessage, with the name current status message, which attaches at compilationa time stamp. As the message is inserted into the database a time stamp forstorage is also added. Subtracting the time at message compilation from the

13

time of data base insertion represents the latency until available. A query wasdone on all position messages between 2015-01-01 up to present in order toproduce a PDF for transmission latency. Latencies greater than three minuteswere not included because disconnection scenarios are not part of the thesisinvestigation.

Figure 2: Latency distribution from message compilation until available. Pro-duced from a data set of more than 600 million.

For simulation purposes, probabilities and cumulative sums were derivedfrom figure 2. in order to map a random number to a latency at each positionupdate.

Latency [s] Probability [%]< 1 2.4< 2 61.3< 3 87.3< 4 91.7< 5 93.5< 10 96.1< 15 96.8< 20 97.1< 30 97.5< 60 99.1< 180 100.0

Table 4: Discrete cumulative distribution of on-board position transfer latency.

14

8 Results

8.1 Data consumption and error distance

Figure 3: Average error distance where the clusters represent different valuesof the delay parameter and the columns within each cluster represent differentvalues of the maximum error distance parameter. Latency according to table4. was part of the simulation. The black horizontal line represents the averageerror distance of Scania’s algorithm.

As seen in figure 3. Scania’s interval based algorithm had an average errordistance of 522 meters. With no delay the ETPU algorithm had an averageerror distance of 22 meters with the max error distance parameter set to 50meters and 194 meters with the max error distance set to 1000 meters. Upuntil 30 seconds delay in the client the average error distance was for the ETPUalgorithm less than that of Scania’s interval based algorithm. Adding a delayin the client will increase the error distance between the client position and thereal time position since the truck will have have traveled during the delay time.As can be seen in figure 3 as the delay increases the dependency on the maxerror distance parameter has diminished impact.

15

Figure 4: Data consumption in relation to Scania’s algorithm. The clustersrepresent different values of the delay parameter and the columns within eachcluster represent different values of the maximum error distance parameter.

Figure 5: Data consumption in bytes per minute. The clusters represent differ-ent values of the delay parameter and the columns within each cluster representdifferent values of the maximum error distance parameter. The black horizontalline represents the byte consumption of Scania’s algorithm.

As seen from figure 4 and figure 5. the data consumption is lower for theETPU algorithm in all cases except with a max error distance at 50 metertogether with the delay set to any of the values: 0, 5 or 10 seconds. A maxerror distance at 75 meters and a delay set to either 0 or 5 seconds. The lowestdata consumption was 36% in size of Scania’s interval based algorithm, in otherwords, a data reduction of 64 percentage points. It was achieved with the maxerror distance at 1000 meters and a delay of 60 seconds.

16

Figure 6: Correlation between data consumption and average error distance. Bycombining the data from figure 3. and figure 4 to produce the result set of bothaverage error distance and data consumption. The trend line is the least squareregression line of the result set. The data consumption and the average errordistance is relative to the simulation results of Scania’s interval based algorithm.

As can be seen from figure 6. in order to reduce the data consumption anincrease in the average error distance will generally be the trade off.

Figure 7: Average transfer interval between position updates where the clustersrepresent different values of the delay parameter and the columns within eachcluster represent different values of the maximum error distance parameter.Latency according to table 4. was part of the simulation. The black horizontalline represents the average transfer interval of Scania’s algorithm.

17

8.2 Incorrect routes

Figure 8: Total number of incorrect routes during a one hour simulation withoutlatency. The clusters represent different values of the delay parameter and thecolumns within each cluster represent different values of the maximum errordistance parameter.

Increasing the delay reduces the number of incorrect routes as seen in figure 8.Using a delay of 20 seconds or more removes 79-100% of all incorrect routescompared to using no delay in the simulation.

Figure 9: Total number of incorrect routes during a one hour simulation withlatency. The clusters represent different values of the delay parameter and thecolumns within each cluster represent different values of the maximum errordistance parameter. The black stacked columns are the additional incorrectroutes caused by transfer latency.

Adding latency to the simulation increase the number of incorrect routes as

18

seen in figure 9. The result of a 5 second delay without latency in figure 8. wasbetter than a 10 seconds delay with latency in figure 9.

19

9 Discussion

9.1 Maximum error and timeA major difference between a time interval based position update and the EventTriggered Position Update (ETPU) algorithm is the characteristics of the clienterror distance. For a time interval based position update the maximum errordistance, assuming constant speed, grows linearly with time in proportion tospeed. The circular area with a radius of maximum error distance thus growsexponentially with time. In the case of the ETPU algorithm the maximum errordistance is fixed since a position update is triggered if the error distance exceedsthis threshold. Thus, regardless of time since last position update the maximumerror of the estimate is constant.

9.2 Average error distance and data consumptionThe ETPU algorithm manages to improve on both the average error distancemetric and the data consumption metric at the same time. For instance, anusing a delay of 15 seconds and a max error distance of 250 meters reducedthe average error distance with 55% and the data consumption with 47%. Dueto the negative correlation between estimation accuracy and data consumption,i.e. improved the accuracy is compensated by worse data consumption and viceversa, further improvements in one of the metrics means less of an improvementin the other.

9.3 LatencyLatency has a major impact on the number of incorrect routes as seen in figure9. The latency results in that the previous position is used for estimation anextended period even though the ETPU algorithm has triggered the need for aposition update. This extended period increases the risk of incorrect routes. Theproposed solution to handle latency is to further increase the delay parameter.The results in figure 9 show an increase in delay reduces the impact of latencyon the incorrect routes metric.

9.4 User experienceSmooth movement of the truck in the client is important for user experience.The more the estimation resembles the movement of a real truck the more theuser will trust the estimated real time movement. A high number of incorrectroutes results in an equal high number of jumps in the truck position fromone route to another. These correction jumps do not resemble truck movementand reduces the user experience. Since increasing delay reduces the number ofincorrect routes and delay also reduces data consumption, the data consumptionwill be positively affected by reducing the number of incorrect routes. Thusconstructing good user experience with low data consumption are very possible.However, low error distance is in conflict with both the data consumption andthe number of incorrect routes metric and will thus suffer if data consumptionand user experience is prioritized.

20

10 Future workFuture projects which continue along this topic would suitably try to implementthe ETPU model in hardware to test its capacity and limitations in the realworld. It would also be interesting to understand how the ETPU algorithmworks in different environments such as cities and highways.

• Cities - would involve a lot of stop signs, pedestrian crossing and turns,thus making it difficult to predict the truck movement for a duration longerthan 30 seconds.

• Highways - are the most predictable because it is the environment wherethe speed is the most constant and one follows the same road for thelongest period of time.

A third point of interest would be to investigate the different industries wherethis service would be of market value.

References[1] Scania inline - connected services and solutions.

[2] C. Cecchinel, M. Jimenez, S. Mosser, and M. Riveill. An architecture tosupport the collection of big data in the internet of things. 2014 IEEEWorld Congress on Services, pages 442–449, June 2014.

[3] Anna Salonen. Service transition strategies of industrial manufacturers. In-dustrial Marketing Management, 40(5):683 – 690, 2011. Service and SolutionInnovation.

[4] L. D. Xu, W. He, and S. Li. Internet of things in industries: A survey. IEEETransactions on Industrial Informatics, 10(4):2233–2243, Nov 2014.

21