Model Card: Vehicle Vocation

Goal: Classify a vehicle's primary operational pattern or "vocation" by systematically analyzing different aspects of its behavior.

Base Model: Gaussian Mixture Clustering Model

Model Type: Unsupervised

Developed by: Geotab Geospatial Team

Primary Intended Uses: Each of the three models ("trucking model," "door-to-door" and "hub-and-spoke") is designed to identify specific characteristics of a vehicle's usage:

• Trucking Model: Broadly categorizes the vehicle's range (local, regional, long-haul).
• Door-to-Door: Pinpoints vehicles engaged in frequent, short-stop activities typical of final delivery or collection services.
• Hub-and-Spoke: Identifies vehicles operating primarily by making multiple trips to and from a central base.

A heuristic process then takes these individual model outputs (which include probabilities for each clustering process). Using a "confidence threshold," this process makes a final, more definitive decision about the vehicle's primary vocation.

Out-of-scope Uses: Any intended use other than the primary intended uses.

Target Users/User Groups: Intended for internal Geotab use by the Altitude and Safety teams.

This section outlines the key aspects of the data used to develop the model. First, we describe the data and its features. Then, the pipeline and its specifics are explained.

Description on Data and Features

This section details the data used in the vehicle vocation system, including the types of information captured and the features derived.

This is the list of customer data the three models have access to:

• CompanyGuid: A universally unique identifier representing the database in MyGeotab. Represented as 5 groups of hexadecimal digits separated by hyphens, always in lowercase.
• DeviceID: A hexadecimal number that uniquely identifies the device in a given MyGeotab database.
• HardwareID, VIN: The identifier of the device of which this GPS record belongs to and Vehicle Identification number, respectively.
• Status: Status of the GPS fragment. (Idling, Moving, Stopped, Invalid or Unknown)
• IsStatusInferred: Shows if "Status" was indirectly identified (e.g. if the vehicle speed wasn't directly reported but its location changed within the fragment's time frame.)
• DateTimeFrom, DateTimeTo: Date and time of the start and end of the fragment, respectively.
• TimeZoneName: The timezone in which the fragment was.
• Duration: Duration of the fragment in seconds.
• Distance, Displacement: Distance and displacement of the fragment in meters, respectively.
• GeographyFrom, GeographyTo: Location at the start and the end of the fragment, respectively.
• Highway: Type of road of the fragment (service, tertiary, primary, residential, etc.)

Core Datasets are foundational contextual vehicle metrics from which features are generated.

1. Duty Cycles: Raw GPS data points are analyzed to determine vehicle status (e.g., "Moving," "Idling," "Stopped"). Consecutive points with the same status are then grouped into "Duty Cycles" which record the time window, locations, and status. Importantly, no minimum time period is imposed on these cycles to capture even very short events.
2. Stop Locations (Intelligent Zones): To avoid misinterpreting short traffic stops as distinct fleet activities, a density-based clustering algorithm is applied. This algorithm groups multiple successive stops within a 30-meter radius into a single, longer stop if they meet specific criteria: stops over 90 seconds, idles over 5 minutes, or stops/idles over 5 seconds on tertiary, residential, or living streets.
3. Domiciles: This dataset determines where a vehicle "domiciles" (its longest stop of at least 4 hours) each workday. The most common domicile location over a three-month analysis period is identified as the "primary domicile". This helps differentiate long-haul from local and regional trucking patterns.

Vocations are determined by feeding explainable metrics into clustering models, allowing for clear understanding of how vehicles are grouped. The following explainable metrics are provided:

1. Geographic Range: This feature set includes metrics describing how far a vehicle typically travels and how often it returns to its domicile. It is used to differentiate Local, Regional-Haul, and Long-Haul vocations.
   Key metrics are GeographicRange, the longest straight-line distance within the convex hull of all visited locations, AvgDailyDisplacement, average crow-fly distance between the start and end of each workday, and PercentAtPrimaryDomicile, percentage of domicile stops made at the primary domicile.
2. Stop Metrics: These metrics identify vehicles that make frequent, short stops, characteristic of door-to-door delivery.
   The main metrics are the NumStops (NumStopsPerDay), total number of stops a vehicle makes, derived as stops per day and Duration_Avg (Avg_StopDuration), the average duration of each stop.
3. Round-trip-ness: This feature set measures how often a vehicle returns to its home base within a single workday, which is crucial for identifying "Hub-and-Spoke" vehicles.
   Metrics include PctDates_withMultipleRoundTrips, percentage of workdays with multiple round trips to and from domicile, RoundTripsPerDay, average number of round trips per day, and PctDistance_ByRoundTrips, percentage of total mileage accounted for by round trips. These metrics demonstrate a distinct cluster for hub-and-spoke behavior.

Data Pipeline and Preprocessing

This section describes the systematic process by which raw vehicle data is transformed and prepared for the clustering models, forming the core of the vehicle vocation system's operation. Overall, the vehicle vocation system clusters vehicles on a monthly basis. This entire process is managed by an Airflow pipeline as follows:

1. Generate Core Datasets: This initial phase focuses on generating key contextual vehicle metrics such as duty cycles, stop locations, and domiciles.
2. Generate Feature Sets (Metrics): As explained in the previous section, this step derives the specific behavioral metrics from the core datasets that are used for vocation clustering which include geographic range, stop metrics, and round-trip-ness.
3. Apply Feature Transformation and Cluster Vehicles: The generated features undergo a power transformation for normalization before being fed into the three Gaussian mixture clustering models. These models were trained once and are stored in a Google Cloud Storage bucket.
4. Push Final Vocation Clusters into BigQuery: The results of the clustering, which are the final vocation assignments for each vehicle, are then pushed into BigQuery datasets.

The system employs unsupervised Gaussian mixture clustering models. These models do not require pre-labeled data and are designed to find natural groupings in the data by assuming that variations within each vocation can be explained by Gaussian distributions.

Vocation is assigned to each active HardwareId-VIN pair. The assignment is based on activity in the previous three months. Overall coverage is about 75%, with inactivity and device-VIN swaps accounting for the remaining 25% of unassigned vehicles. Vehicles with insufficient activity are assigned an "Unknown" vocation.

Data Privacy

For each entry in the dataset, there is a unique identifier known as a Vehicle Identification Number (VIN). Despite being available in the dataset to correlate outputs, these identifiers are excluded from the direct model learning process.

In this section, we highlight some ethical challenges that were encountered during the model development,

Risks in Training

The three models are trained by running the training script on the production feature table of a region. The models in production were last trained in April 2025. A retrained model is accepted by the Geotab model users after comparison with the production model.

Data Bias Handling

A bias assessment has been completed. The model uses no personal data and no protected attribute. The assessment looked at vehicle type, region and fleet size, and found differences in coverage and in how some vocations are assigned. Because no ground-truth labels exist, these differences cannot be classified as real behaviour or model error; they are accepted and monitored. Coverage and the vocation distribution by vehicle type and fleet size are monitored monthly.

Model Assumptions and Constraints

Assumptions:

• In designing these models, the main assumption was that if vehicles do indeed fit into distinct vocations, they should form natural clusters that are easy to identify and separate. This is why the team chose an unsupervised clustering approach as opposed to a supervised learning approach.

Constraints:

• This process is only applicable to vehicles that have been sufficiently active in the previous 3 months.

The models are unsupervised, so there is no accuracy against labels. A retrained model is compared with the production model (cluster weights, label agreement, class share, coverage, retention) and reviewed against defined triggers before promotion. In production, vocation-share drift, NULL rate and coverage are monitored monthly.