Introduction

Automobile transportation has always been of interest to researchers because of its key role in land freight transportation. Among research subjects those connected with minimizing transportation costs by optimizing travel routes (Hangbin et al. 2022; Qingquan et al. 2011), or driver behavior (Wenhao and Quingdong 2022) were especially numerous. Another, however less widely recognized branch of research touches security of cargo. The studies conducted by Brandt et al. (2019) confirm that the latest issue is a significant problem in modern logistics. According to Ekwall and Lantz (2017), the annual value of cargo theft in the European Union account for at least €8 billion loss. About 41% of incidents occur during the driving phase of transportation. Arway (2013) points out the fundamental role of GNSS-based solutions in modern supply chain security, with an increasing number of telematic- and fleet management systems offering vehicle tracking. This is also confirmed by Transported Asset Protection Association (TAPA) Trucking Security Requirements with more and more attention being paid to tracking and tracing protocols in the following editions (TSR 2020a, 2017) of certification standards.

When transporting high-value theft-targeted (hereinafter: HVTT) goods, the highest standards are required. According to TAPA TSR (2020a, b), the cargo must be transported along a precisely selected route, with planned stops, and continuously tracked by the security centre. Any unscheduled stops, road disturbances (accidents, road works, traffic) or bypassing must be reported by drivers immediately. Response protocols for handling emergencies must be documented. TAPA TSR (2020a, b) include technical requirements for tracking devices. Among others, the tracker must utilize at least two signalling methods, must contain battery backup maintaining the signalling capacity for at least 24 h, must report tampering with any installed security systems, truck stoppage, battery status, cargo area door status, etc. Reporting interval must be not fewer than one report every:

  • five minutes for level 1 security certificate

  • thirty minutes for level 2 security certificate.

Therefore, the TAPA-approved tracking system must be characterised by the continuity and security of truck and cargo positioning data. No technical requirements for positioning accuracy had been defined, however. The goal of this research was to provide empirical data for TAPA TSR 2020a Level 1 certification in terms of tracking vehicles during typical operating conditions (cargo loading, routing, transportation, stopover, unloading) as well as detecting any geofencing violations. The Dynamic Geofencing Algorithm (DGA) presented in this article was developed for this specific purpose. Thisis the first known pulication to examine and fulfill TAPA Standarization requirements in terms of cargo positioning.

Research problem

GNSS positioning is embarked with inaccuracy (commonly 'GPS drift') that is dependent on both internal and external factors. Internal factors occur due to the hardware used (modem, antenna, etc.) and are usually specified by producers (for example with the CEP parameter). External factors, such as continuous changes in the position of satellites, terrain, land coverage, the occurrence of high objects (i.e. urban canyons), bad weather conditions, etc. differentiate the number of satellites viewed and used for calculations. Several sources confirm these circumstances are unique for a particular time and space and therefore positioning errors are more difficult to measure and handle (Barrios and Motai 2011; Bezcioglu 2023; Cui and Ge 2003; Chao et al. 2020; Goodchild 2018; Jin et al. 2022; Kim et al. 2017; Kubicka et al. 2018; Kumar et al. 2020; Min et al. 2019; Ponomaryov et al. 2000; Saki and Hagen 2022; Singh et al. 2023; Yalvac 2021; Yumaganov et al. 2021; Zhang et al. 2021).

The precision of trackers can be evaluated in two ways. One is the comparison of obtained results with the device technical parameters and the second is the statistical analysis of the measured values and comparing it with map data. In the article (section 3.1), both ways were followed.

In civilian use, GPS drift up to a few meters is regarded as minor, insignificant, naturally accepted technological drawback (Bezcioglu 2023; GARMIN Support Center 2023; Geospatial Innovation Facility 2023). This problem is commonly solved with map-matching algorithms (Jin et al. 2022; Kubicka et al. 2018; Saki and Hagen 2022; Singh et al. 2023; Yalvac 2021; Yumaganov et al. 2021; Zhang et al. 2021). Commercial map data providers require additional fees for the use of real-time map-matching functionality.Footnote 1In addition, at the map-matching stage, information on the actual distance from which the raw data was captured is lost (Gelb et al. 2021; HERE Developer 2022). Unfortunately, this issue has been one of the major concerns when considering the challenges of HVTT cargo security. The research team faced the fundamental question if the accuracy of market-available GNSS receivers is sufficient for handling security requirements, especially while tracking vehicles along a predefined route, at low speeds and stops (Mu et al. 2021). In section 5, the authors discuss the possiblity to use the distance between the raw GNSS position and map-matched position as a quantitative security factor for TAPA certification (TSR 2017, 2020a).

The research problem in this article is the analysis of positioning inaccuracy and its estimation with the use of the proposed dynamic geofencing algorithm (sections 4 & 5). The methodology used is complex. It consists of: developed hardware, data transmission, server architecture, algorithms for designed software, etc.(Fig. 1). This article is limited to data processing challenges caused by GNSS positioning inaccuracy, its estimation and handling. The research presented consists of collecting, analysing and processing data registered by tracking devices (hereinafter: trackers).

Fig. 1
figure 1

The cargo monitoring scheme. The article is focused on the data processing phase. Own work

Full size image

Methodology

In the research, a Dynamic (adaptive) Geofencing Algorithm (DGA) was proposed. The algorithm was developed based on the theoretical assumptions and equations derived from existing map-matching algorithms described, among others, by Chao et al. (2020), Hashemi and Karimi (2014), Kubicka et al. (2018), Quddus et al. (2007), Singh et al. 2023, White et al. (2000) and own field tests. Most modern map-matching algorithms focus on determining the location of a tracked vehicle on a particular segment of all possible roads from the whole road networkFootnote 2 (Barrios and Motai 2011; Gelb et al. 2021; Hangbin et al. 2022; Jin et al. 2022; Kumar et al. 2020; Lupa et al. 2023; Mu et al. 2021; Saki and Hagen 2022; Wenhao and Qinghong 2022; Yumaganov et al. 2021; Zhang et al. 2021). Dynamic eofencing is a special case where only one selected route of the road network is relevant (Fig. 2).

Fig. 2
figure 2

The dynamic (adaptive) geofencing scheme. In phase 1 route A-N is selected. In phase 2 raw GNSS data is collected. Phase 3 includes consequent detecting and solving equations for exceptions (section 4.2). Positions are projected on the road vector and returned to the database. Own work

Full size image

The problem can be illustrated by walking the dog on a leash, similarly to the example presented by Dolan (2016). While the tracked vehicle is moving along a predefined route (multiple vertex linear geometry) with variable positioning error, the real position is somewhere near both the measured position (raw GNSS data) and map-matched position (perpendicular projection of the raw data on the road geometry). Questions answered by dynamic geofencing are:

  • What is the nearest segment of the predefined route? (the vicinity selection problem);

  • How far is the raw positioning data from the nearest segment? (the buffering problem).

Knowing raw positioning data ('the dog'), with estimated accuracy ('the leash') one can calculate the map-/route-matched position ('the master') and therefore determine whether the vehicle is following the predefined route ('the dog is on a leash') or moving away. The mathematics of dynamic geofencing is less complicated than in most modern map-matching algorithms, yet the problem resolved by the proposed algorithm is quite different than in most published cases (Chao et al. 2020; Hashemi and Karimi 2014; Jin et al. 2022; Kubicka et al. 2018; Kumar et al. 2020; Mu et al. 2021; Quddus et al. 2007; Saki and Hagen 2022; Singh et al. 2023; White et al. 2000; Yumaganov et al. 2021; Zhang et al. 2021).

Hardware

Developed tracking assets were equipped with a 9.7 × 10.1 mm GNSS module. The chipset supports all existing GNSS constellations—GPS signal can be received and processed concurrently with Galileo and GLONASS or BeiDou. According to the producer, horizontal position accuracy measured as CEP 50%, 24 h static roof antenna, is at worst < 1,8 m (STMicroelectronics 2019), so 50% of points collected should fall within a 1.8-m radius of the true location. The manufacturer claims to achieve this during 24 h of static recording with a roof antenna (the parameters of the antenna are unknown). The nominal frequency of the time pulse is 1 Hz, and tracking is possible at -163 dBm. The technical specification of the GNSS modem is listed in Table 1.

Table 1 GNSS module - Technical Specification. STMicroelectronics 2019.
Full size table

As part of the tests, we attempted to evaluate the accuracy of the tracker with the GNSS modem by comparing the manufacturer's CEP (1.8 m) with the results of our measurements carried out in a 24-h static position using a roof-mounted antenna with full sky visibility. We compared the data recorded with the actual position of the receiver on the map and calculated the difference in horizontal position (Fig. 3A). There are several points with large differences (> 4 m) in horizontal position. These points were recorded during the cold start of the GNSS receiver within the first two minutes. Removing these points resulted in asymmetric statistical distribution of the position within a radius of 1.4 m (Fig. 3B). This partially confirmed manufacturer's statement.

Fig. 3
figure 3

(A) Horizontal position difference, 24-h static measurements with full sky visibility—all data. Own work. (B) Horizontal position difference, 24-h static measurements with full sky visibility—120 s. cold-start data filtered. Own work

Full size image

Another test was carried out under the target operating conditions of the device, i.e. using a GNSS receiver mounted on a truck performing routine shipping activities: carriage, loading/unloading and parking. A 12-h position measurement recorded during a stopover showed significant discrepancies compared to tests carried out stationary using a roof-mounted antenna. Nearly 2,700 continuous position measurements were recorded during the test, with an average pooling time interval of 16 s. A cloud of points with a 14.26 m diameter was recorded (Fig. 4). The average distance from points to the centre of the cloud was 2.82 m. The distribution of the distance from the centre point is close to Gaussian (Fig. 5). The total GNSS drift counted from consecutive records was 574.87 m. The average displacement was 0.21 m per record (Fig. 6). The distribution of displacements between consecutive records is asymmetric, dominated by zero values (1728 records = 64% of total), with displacements generally occurring once every three records (48 s). The problem of assessing the accuracy of the GNSS module while the vehicle was moving was incorporated into the algorithmic process described in sections 4–5.

Fig. 4
figure 4

GNSS drift recorded during a 12-h truck stop at the loading bay car park. Total of 2682 points recorded with V = 0 km/s. The diameter of the recorded cloud (yellow) is over 14 m, the total movement is 574.87 m, mean drift value is 0.21 m per record. Own work

Full size image
Fig. 5
figure 5

GNSS drift recorded during a 12-h truck stop—histogram and statistics of distance from each point to mean point. Own work

Full size image
Fig. 6
figure 6

GNSS drift recorded during a 12-h truck stop—histogram and statistics of distance covered record-by-record. Own work

Full size image

Software

Tracking assets transmit data to the server via the GSM network. The polling time is software-dependent. The interval was irregular. When the vehicle was on the move the signal with the current position was triggered every 100 m or every 15-degree turn. At stops the rate was set regular with one record per 30 s. Also 'save battery' mode was tested with an interval reduced to one record per 5 min. The mean pooling time interval for all assets used for tests was 20 s.

The data is stored in the Postgre SQL database. The user interface allows filtering data with asset ID and time reference and exporting to popular formats such as.CSV,.JSON or.GEOJSON. Data for selected travelling events (hereinafter: voyages) were processed with RStudio 1.3.1099 (operating on R 4.0.3 software). QGIS 3.16 was used for geographical visualization of data and geostatistic exploration. Both RStudio and QGIS are open-source programs that easily process the above-mentioned types of data.Footnote 3The data postprocessing of the data was computed with an eight-core 3,7 GHz AMD Ryzen 7 2700X processor, 32 GB RAM, 4 GB NVIDIA Quadro K2200 graphic card, 500 GB Samsung SSD 860 EVO drive, configured at 64-bit Windows 7 Professional.

Input data

The primary research data were sets of GNSS positioning fixes (point data) collected in 2020–2021 (see supplementary materials). Tracking assets record multiple attributes, from which the following were considered relevant: field ID [recorded on track], record ID [assets' total count], p_long [longitude in recorded, DD], p_lat [latitude recorded, DD], velocity [km/h], azimuth [degrees clockwise]. Several test voyages were selected for the analysis to provide information about the performance of tracking assets in different environments. The six most promising tests were selected for the analysis (Tables 2, 3, 4, 5, 6, and 7). These include one cross-city route [14 km], two expressway voyages between different cities [150–350 km], one cross-country in the Polish mountains [320 km] and two long international routes with regular cargo [first within the EU and second Europe-Asia, both ca. 19,000 km].Footnote 4During tests, various types of vehicles were used (car, medium truck, large truck with a trailer). Details of tested routes are listed in Table 2.

Table 2 Tests 1–6 data collecting details: date, vehicle, terrain, length, duration, satellite & GSM coverage, signal transmission time. Own work
Full size table
Table 3 Principles of geometrical map-matching (orthogonal projection of point P on polyline ABC…) with exceptions detected and solved by the dynamic geofencing algorithm. Own work
Full size table
Table 4 Tests 1–6 data processing details: route, raw GNSS records and matching characteristics. Own work
Full size table
Table 5 Maps of tested routes 1–6 displayed with HERE Maps general map tiles. Own work
Full size table
Table 6 Histograms and statistics of map-matching distance during the tests 1–6. Own work
Full size table
Table 7 Off road deviations mapped with dynamic geofencing. Own work
Full size table

Route geometry is represented by a polygonal chain, which is an organised sequence of 'n' coordinate pairs (X1, Y1; X2, Y2; …; Xn, Yn).Footnote 5Several authors discuss the use of various online mapping aplications as a base roadmap data – among others the most frequently mentioned are Google Maps, Bing Maps and OpenStreetMap (Chao et al. 2020; Hashemi and Karimi 2014; Jin et al. 2022; Lupa et al. 2023; Mu et al. 2021; Singh et al. 2023; Yumaganov et al. 2021). The highest available zoom of the map is level 19 and may be referred to as the scale around 1:2000 (at the equator).Footnote 6Usually, the level of detail of the road data is comparable to the standards of the 1:10,000 topographic objects database (eg. Polish BDOT10k database – see: Rozporządzenie 2021). The study conducted by Urbański (2021) revealed that on average Google Maps road segments have 3-times more vertexes than HERE Maps or OSM. Unfortunately, that does not indicate the quality of hosted road network, as there was no certain relation between number of vertexes and actual roadmap accuracy. Following White et al. (2000, p. 92), our desire was to develop a simple map matching algorithm "to reconcile inaccurate locational data with an inaccurate map/network." In this research, raw positioning data of particular voyages were compared with routes generated with the HERE Maps online mapping application (see: supplementary materials).Footnote 7

Calculation

Geometrical map-matching includes three types of procedures: point-to-point, point-to-curve and curve-to-curve. These procedures were thoroughly discussed by many authors, with the most accessible descriptions provided by Hashemi and Karimi (2014), Quddus et al. (2007) and White et al. (2000). In elementary terms, the point-to-point procedure would change the original coordinates of raw GNSS positioning (point data) into coordinates of the closest vertex of the road. The idea of point-to-curve matching is based on an orthogonal (perpendicular) projection of raw data onto a linear model of the road (QGIS Documentation v. 3.28). The definition of the problem in the 2-dimensional Cartesian coordinate system and simplified equations are presented in Table 3A and Eq. 1.

The formulae for calculating the coordinates X and Y of the point Q being the orthogonal projection of point P on segment |AB|, derived from the directional equations of the line AB and of the perpendicular line passing through point P. Own work.

$$\begin{array}{c}X_Q=\frac{\lbrack(tg\beta^\ast(Y_P-Y_B))+X_P+(X_B^\ast(tg\beta^2))\rbrack}{\lbrack(tg\beta^2)+1\rbrack}\\Y_Q=\frac{\lbrack(tg\beta^\ast(X_P-X_B))+Y_B+(Y_P^\ast(tg\beta^2))\rbrack}{\lbrack(tg\beta^2)+1\rbrack}\end{array}$$
(1)

where:

$${\displaystyle \begin{array}{c}{X}_A,{X}_B,{X}_P,{X}_Q\hbox{--} X\ coordinate\ of\ point\ \left(A,B,P,Q\ respectively\right),\kern10em \\ {}{Y}_A,{Y}_B,{Y}_P,{Y}_Q\hbox{--} Y\ coordinate\ of\ point\ \left(A,B,P,Q\ respectively\right),\kern10.5em \\ {}\begin{array}{c}\textrm{tg}\upbeta =\left({Y}_B-{Y}_A\right)/\left({X}_B-{X}_A\right)\text{-- tangent Beta is a directional coefficient of the line AB},\\ {}\textrm{tg}\upbeta \hat{\phantom{i}} 2\text{-- tg}\upbeta\ \textrm{squared} \end{array}\end{array}}$$

The curve-to-curve matching is an extended version where the heading (azimuth) of the vehicle is additionally compared to the direction of the closes road segment, for example, to eliminate snapping to the opposite direction line when these are separated (Saki and Hagen 2022; White et al. 2000). This can be done with simple SQL data filtering commands. According to Gade (2016) information on heading angle obtained solely with GNSS is not fully reliable—especially at low speeds and stops.Footnote 8Buffers should be applied so that the filtering does not disqualify possible driving manoeuvres (turning, lane changing, overtaking, parking).

White et al. (2000) noticed, that projected point Q may not fall into line segment (AB) but on its linear extension and that would disqualify point Q as a properly matched position of a point (P). This can be tested with a simple Boolean test for the A-B bounding box (Eq. 2):

Boolean test for X and Y coordinates of point Q falling within the range of |AB| segment. Own work.

$${\displaystyle \begin{array}{c} if \\ {}{X}_Q>=\mathit{\min}\left({X}_A,{X}_B\right)\ AND\ {X}_Q<=\mathit{\max}\left({X}_A,{X}_B\right)\\ {}\begin{array}{c} AND \\ {}{Y}_Q>=\mathit{\min}\left({Y}_A,{Y}_B\right)\ AND\ {Y}_Q<=\mathit{\max}\left({Y}_A,{Y}_B\right)\ \end{array}\end{array}}$$
(2)

If not, Q should be snapped to the nearest vertex (A or B). Therefore in certain situations, point-to-curve matching is reduced to point-to-point matching. Unfortunately, this knowledge is gained at the end of the process. One may notice that curve-to-curve is the most general matching procedure whereas point-to-curve and point-to-point may be regarded as specific cases: point-to-curve is a special case where initial segment length is 0 and heading is unknown, point-to-point is a special case where both the initial and referential segments lengths are 0 and headings are unknown (Saki and Hagen 2022).

Standard procedure

Along with the growing complexity of the arc more complicated procedure is needed. Defining which segment of the 'n-vertex' polyline is the closest to point P is not obvious, as multiple exceptions occur (White et al. 2000). Exceptions diagnosed for DGA will be discussed in Sect. "Exceptions". Taking that into account the proper point-to-curve matching would require solving equations (Eq. 1-2) between point P and all segments in the chain. This however would be computationally ineffective and there is no point in calculating distances between raw positioning data and segments that are nowhere near their reasonable vicinity.Footnote 9The process called 'initial matching' assumes that at least one vertex of the route can be selected within a reasonable distance from point P.Footnote 10If the condition of initial matching is met, the distance between point P and each of the selected vertexes is computed and sorted ascending. If not, the algorithm would duplicate the initial proximity buffer and repeat the process.

Assuming that the vehicle is moving somewhere along the route that is represented by 'n-vertex' polyline (Table 3B), the standard procedure projects raw GNSS point (P) on both segments connected to the closest vertex (AB, BC). The equation (Eq. 2) is used to calculate the coordinates of projected points (Q1, Q2) and distances from the initial point (P). It is necessary to use Eq. 3 qualify whether one of the projected points (Q1, Q2) falls on the corresponding line segment. If both are 'false', exception 3 should be considered. If both are 'true', exception 4 should be considered.

When none of the strategies is successful for the first of the initially selected vertex, the algorithm would process the following vertexes in the proximity, one by one, until a positive result is achieved. Tests prove, that this simple method allows to properly match 95% of records along examined routes. The other 5% of records are exceptions described in the next section.

Exceptions

During the research, five categories of exceptions were diagnosed: device start-up, start/endpoint, outer angle, sharp angle and loop.

  1. 1)

    device start-up—the standard procedure is vulnerable at the start-up of the tracker. Initial GNSS fixes are burdened with high inaccuracy in terms of position, speed and heading. The producer-declared time to first fix was 1.5–2.5 s for the hot start and 30–36 s for the cold start (Table 1). Field tests proved several fixes after the start-up inaccurate in terms of position (CEP) and heading. The usual delay for reliable measurements was 90–120 s (section 3.1).

  2. 2)

    start/endpoint—this case occurs every time the raw positioning point (P) is close to the route's first or last vertex. It occurs anytime the movement of a vehicle begins off the mapped road, e.g. at the parking lot or facility. Since the first/last vertex is connected to only one segment (AB), the distinction of whether the projected point Q is outside or inside of the bounding box is made (Table 3C). The relationship between the direction of the segment and the heading of a vehicle is loose—a lot of unpredictable manoeuvres may be completed at low speed until the road is reached. At speeds below 5 km/h, the role of the GPS drift factor increases—rapid changes in the recorded heading are observed. Point-to-point matching initialised at a certain proximity to the first vertex seems a reasonable solution.

  3. 3)

    outer angle dead zone—it occurs whenever a GNSS point is recorded in the vicinity of a vector kink, on the external side of the ABC angle (Table 3D). The perpendicular projection of point P on line AB (Q1) is outside the segment bounded by the vertices of AB. The perpendicular projection of P on BC (Q2) is also outside the segment bounded by the vertices of BC. As a result, none of the points Q1, and Q2 belong to the vector of the road. Even though one or both the distances PQ1 or PQ2 are shorter than the distance PB, vertex B is a correctly matched position.

  4. 4)

    acute angle—this exception is caused when a relatively long straight road section is followed by a sudden road curvature (turn, intersection, roundabout, Table 3E). If the angle between sections AB and CD is less than or equal to 90 degrees, the erroneous point P may be closer to BC than to AB, even if the vehicle is in front of the turn. Correct matching can be achieved by azimuth filtering (curve-to-curve matching).

  5. 5)

    self-intersection (loop)—the last exception is registered when the predefined route is led through non-topological intersections (interchange, loop ramps), especially when a long straight section is non-topologically crossed by a shorter one (e.g. flyover). With the point-to-curve approach used, GNSS data is matched to the wrong section because the PQ1 distance is longer than the PQ2 distance (Table 3F). The curve-to-curve matching should be used instead.

Dynamic/Adaptive projection

Finally, the problem of cartographic projection was addressed. GNSS receivers acquire positioning coordinates in World Geodetic System 1984 (EPSG: 4326) angular units.Footnote 11The NMEA 0183 Standard defines a protocol for transmitting GNSS coordinates in 8-bit Degrees-Minutes Decimal (DMM) format, which for practical use must be converted to Decimal Degrees (DD). Coordinates in decimal degrees cannot be used for simple Cartesian calculations, because of the way the spheroid is plotted on the plane (Snyder 1987). The distortion of distances in different directions, angles and areas is generally latitude dependent. Several programming libraries (e.g. geosphere for R, Hjimans et al. 2019) handle the computation of geodesic (ellipsoidal) distances quite well, but the calculation of courses and intersections of non-Euclidean lines is difficult to implement.

Most studies address this problem using azimuthal projection of GPS data onto locally tangent planes, like azimuthal equidistant or azimuthal conformal (stereographic) (Snyder and Voxland 1989; Mu et al. 2021; Wang et al. 2023). This solution is straightforward and efficient, but azimuthal projections have a limited radius of allowable distortion up to 20–30 km from the centre point. Min et al. (2019) used the Universal Transverse Mercator (UTM) projection for local (static) conditions, howewer we decided to take a step further by constructing a Dynamic Transverse Mercator (DTM) projection. This idea uses transverse Mercator formulae (Proj.org 2022; Spatial Reference 2023) in the way it is used in Universal Transverse Mercator (UTM) projections or Polish state geodesy (Rozporządzenie 2012, 2021), but with central meridian 'longitude_0' as a dynamic parameter (Fig. 7, Eq. 3). As a result, the position of the GNSS receiver is projected on a conformal plane with little distortions of ± 0,003% at the edges of 3-degree meridian band (Snyder and Voxland 1989; Meert and Verbeke 2018; Meert 2022; Rozporządzenie 2012).Footnote 12This solution can be easily implemented for forward-reverse projection with EPSG-based WKT definitions:

Fig. 7
figure 7

Illustration on forward and reverse projection of GNSS coordinates with EPSG, Proj.4 and WKT definitions. A common approach is to convert geographical coordinates (angular units) onto a Cartesian plane (linear units) with oblique azimuthal projection. Our approach uses Dynamic (adaptive) Transverse Mercator projection (outlined in red) for better distortion handling. Own work

Full size image

WKT definition for dynamic transverse mercator projection (forward). Own work.

(3)

Results

The Dynamic Geofencing Algorithm (DGA) was designed to optimize the computation efficiency while sustaining the reliability of map-matched positions (Jin et al. 2022; Mu et al. 2021). In the first step, the algorithm eliminates the start/endpoint exception with the vicinity filtering. This is an important step because azimuth filtering (curve-to-curve matching) is not possible at exceptions 1) and 2). With exceptions 1) and 2) handled, the algorithm turns into eliminating exceptions 4) and 5), where azimuth filtering is needed (curve-to-curve matching). Having that done, the algorithm returns to standard procedure with point-to-curve matching. Fixed positions are presented in supplementary materials (.CSV files, columns q_long [new longitude, DD], q_lat [new latitude, DD], q_dist [projection distance, metres]).

Field tests conducted in 2020–2021 tested the algorithm in different environments and on different vehicles (Tables 2 and 5). Tests present several stages of the system development, with hardware and software malfunctions and upgrades along the process. The efficiency of map-matching at short (few km) and medium (one day) voyages was very high – 99% and better (Table 4). On long, regular transport routes (around one week), the efficiency dropped to 81% (Poland-Spain) and 61% (Kazakhstan-Poland). An inverse correlation was observed between the effectiveness of the algorithm and the percentage of records at stops. The algorithm seems vulnerable at very low speeds when the heading registered by GNSS does not correspond with the heading of the road due to the drift (Tables 4, 6, and 7).

In field tests 1–6, the matching distance of >  = 50 m was used as a threshold for detecting geofencing violations (Table 8). The typical percentage of geofencing violations on short and medium routes ranged from 1.5 to 5.7% of all records. Geofencing violations of long multi-day routes ranged from 0.7% (Poland-Spain) to 25.5% (Kazakhstan-Poland) of total records, which is surprising given the comparable length, operating conditions and stage of hardware development (Table 4). The most common causes of geofencing violations were: 1) unscheduled stops; 2) detours due to road works; 3) out-of-date road data; 4) GNSS drift; 5) other unusual manoeuvres at car parks, motorway and border gates, traffic jams, etc. (examples in Table 8).

Table 8 Examples of geofencing violations in tests 1–6. Radius express matching distance: records within the 50 m geofencing bufffer—green, records violating 50 m geofencing buffer—red. Opacity 10%. Own work. See supplementary material for more
Full size table

Multi-day routes are far more difficult to plan and execute the same way, therefore a large percentage of unmatched data was caused by drivers themselves. This is also confirmed by the maximum matching distance, which is 3–4 times larger on multi-day routes than at short routes. Raw data reveal manoeuvres up to 10 km off the planned route (e.g. Moscow bypass), which is 10-times larger than the proximity buffer used for selecting vertexes. Tests 5 and 6 prove that the dynamic geofencing procedure is correct and 100% deviations within the vicinity buffer were detected (Tables 4, 5, 6, 7, and 8). On the other hand, some data were registered too far off so projecting them onto the predefined road made no sense (Tables 4 and 7 – particularly tests 5 & 6). This problem may be completely eliminated when introducing autonomus vehicles in cargo transformation (Cui and Ge 2003; Goodchild 2018).

The computation time performed on a PC (section 3.2) ranged from 45.5 ms (test 6) to 67.1 ms (test 2) per record. The majority of time is consumed by the initiation of the script, not by the calculations (Table 4). There is no clear correlation between computation time and the number of exceptions detected. With a matching average of 56 ms per record, the algorithm is fast enough for real-time implementation.

Conclusion

According to the latest research, cargo security is one of the most critical issues in modern logistics, with billions of dollars being lost every year due to theft all over the globe (Brandt et al. 2019; Ekwall and Lantz 2017; Arway 2013). The driving phase of transportation takes up a major part of these statistics, especially in terms of HVTT cargo (section 1). Despite over thirty years of availability of GNSS for civilian applications (Chao et al. 2020; Goodchild 2018), existing tracking solutions barely meet the requirements of the TAPA TSR 2020a level 1 standard. Taking into account all problems with the aliveness, communication stability and redundancy of such a system, GNSS-based positioning inaccuracy adds up to another one (section 2). Introduction of gyroscope and other onboard sensors, Inertial Navigation (DR), Extended Kalman Filtering (EKF) and Hidden Makarov Models (HMM) in map-matching algorithms developed in the two latest decades present valuable ideas on handling shortcomings of the hardware (Barrios and Motai 2011; Bezcioglu 2023; Cui and Ge 2003; Chao et al. 2020; Goodchild 2018; Jin et al. 2022; Kim et al. 2017; Kubicka et al. 2018; Kumar et al. 2020; Min et al. 2019; Ponomaryov et al. 2000; Saki and Hagen 2022; Singh et al. 2023; Yalvac 2021; Yumaganov et al. 2021; Zhang et al. 2021).

Unfortunately, most commercial map data providers require additional fees for the use of real-time map-matching functionality. In addition, at the map-matching stage, information on the actual distance from which the raw data was captured is lost—the authorso of this paper saw this as even more unfortunate. Collecting and comparing raw GNSS data with map-matched data can be used as quantitative values for fleet monitoring—certain threshold values may be parameterized for the system to switch into "increased security" mode or to trigger alarms (section 5, Tables 6, 7, and 8).

The research conducted (section 4) revealed that curve-to-curve is the most general matching procedure whereas point-to-curve and point-to-point may be regarded as specific cases, therefore efficient algorithms should use these procedures interchangeably depending on identified circumstances(Saki and Hagen 2022). The main difference between the proposed Dynamic Geofencing Algorithm (DGA) and existing map-matching algorithms is a priori route selection done by the transport supervisor and therefore, the position can be matched solely with the geometrical approach (Jin et al. 2022; Mu et al. 2021; White et al. 2000). Less complicated mathematics results in faster computation (section 5). On the other hand, the DGA presented can be implemented for any purpose where it is relevant to compare raw GNSS positioning data with map-matched data, including: emergency, public transport, on-demand transport, money transport, military logistics, etc. (Gunay et al. 2014; Lupa et al. 2023). Exceptions presented in the paper (section 4) prove the case was not that straightforward after all.

The Dynamic Geofencing Algorithm (DGA) presented in the article (sections 4 & 5) was developed for the specific purpose of HVTT security and is the first known publication to deal with the newest TAPA Standarization requirements in terms of cargo positioning. There are several innovative parts of the work:

  1. 1)

    Introducing Dynamic (adaptive) Transverse Mercator Projection (DTM) to improve the accuracy of forward-reverse transformations between angular GNSS units and Euclidean reference frame (section 4.3);

  2. 2)

    Introducing interchangable curve-to-curve, point-to-curve, point-to-point geometrical matching to improve the calculation speed based on detected circumstances (sections 4.1-4.2);

  3. 3)

    Using the distance between the raw GNSS position and map-matched position as a quantitative security factor to introduce dynamic geofencing (section 5, Table 8).

Field tests 1–6 resulted in 99.9% success rate in detecting any geofencing violations caused by GNSS drift, roadwork detours, unscheduled stops and other atypical manoeuvres in miliseconds – thus fast enough to implement in real-time use (Tables 4 and 7). Achieving this fairly exceeds the TAPA TSR 2020a Level 1 safety certification criteria for vehicle tracking.