AI Vehicle Path Prediction Service for Smart Ports by Jongeum KimAI Vehicle Path Prediction Service for Smart Ports by Jongeum Kim

AI Vehicle Path Prediction Service for Smart Ports

Jongeum Kim

Completed work

AI Engineer

MongoDB

PyTorch

Redis

Internet of Things

← Back to projects

A real-time ML inference service that predicts the next five seconds of yard tractor movement from live GPS streams in a container terminal.

The AI Vehicle Path Prediction Service was developed as a demonstration of how a smart-port IoT integration platform could support real operational applications.

Using live GPS data from approximately 90–110 yard tractors operating at Shinseondae Container Terminal, the system continuously processed vehicle telemetry and predicted each tractor's trajectory for the next five seconds.

The project adapted a Transformer-based trajectory prediction model developed through research at Pusan National University into a real-time inference system capable of operating on live terminal data.

The predicted trajectories were designed to be visualized on a live terminal map as a demonstration of how short-term vehicle prediction could eventually support applications such as collision-risk detection.

Overview

Each active yard tractor published GPS telemetry approximately once per second through the terminal's existing IoT integration platform.

With roughly 90–110 vehicles operating simultaneously, the prediction system had to continuously process approximately the same number of incoming vehicle updates every second.

For each vehicle, the system maintained a recent five-second sequence:

t-4 → t-3 → t-2 → t-1 → t
                         │
                         ▼
                    Transformer
                         │
                         ▼
              t+1 → t+2 → ... → t+5

The primary engineering objective was not simply to run the prediction model, but to make the research model operate continuously against a real-world IoT stream with sufficiently low latency for live visualization.

My Role

I was responsible for designing and implementing the service architecture outside of the frontend, including:

Real-time IoT data ingestion

GPS preprocessing and feature transformation

Per-vehicle sequence buffering

Celery-based asynchronous processing

Model training execution

PyTorch model integration and inference

Prediction storage

Backend APIs

Cloud-facing service deployment

The Transformer architecture, training methodology, and original preprocessing methodology were developed by the Pusan National University research team. My responsibility was to implement those methods and turn the research model into an operational real-time service.

Tech Stack

Python PyTorch MQTT Celery Redis MongoDB Django Docker AWS

Problem & Constraints

Trajectory prediction in a live IoT environment introduces a different problem from offline model evaluation.

The terminal continuously produced new vehicle states every second. A prediction therefore became less useful as processing latency increased.

For a system predicting only five seconds into the future, processing stale events reliably was not necessarily more valuable than producing the latest prediction quickly.

This created an important architectural priority:

Prefer fresh predictions with low latency over delayed processing of every historical event.

The service was therefore designed around continuous low-latency processing rather than guaranteed processing of every incoming GPS message.

System Architecture

The existing terminal IoT platform supplied live GPS telemetry through a common topic containing updates from all active yard tractors.

An MQTT consumer received each message and created Celery tasks for asynchronous processing.

The processing pipeline consisted of two primary worker stages:

Preprocessing workers transformed incoming GPS data and maintained per-vehicle historical sequences.

Prediction workers consumed the processed sequences and executed Transformer inference.

Predictions were stored in MongoDB and exposed to the visualization frontend through a Django-based API deployed on AWS.

Real-Time Processing Pipeline

Redis maintained short historical sequences using the vehicle's equipment ID as the key.

This allowed workers to reconstruct the recent movement history of each tractor without keeping vehicle state inside individual worker processes.

The prediction worker then generated the next five trajectory points from the most recent five-point sequence.

Feature Engineering

The incoming messages contained standard vehicle GPS telemetry, including:

Latitude

Longitude

Altitude

Speed

Heading

Several additional features were produced during preprocessing before the sequence was passed to the model.

Circular Heading Representation

Heading was originally represented in degrees.

A raw degree representation introduces a discontinuity around north:

358° → 359° → 0° → 1°

Numerically, the transition from 359 to 0 appears to be a large change even though the physical direction changed by only one degree.

To provide a continuous representation of direction, the preprocessing pipeline generated sine and cosine components from heading:

heading
   │
   ├── sin(heading)
   └── cos(heading)

This allowed the model to represent circular direction without the artificial discontinuity between 359° and 0°.

Movement Features

Changes in vehicle speed were also used to generate an acceleration-state feature.

Together, the processed sequence represented not only vehicle position but also short-term movement characteristics used by the Transformer model.

Key Engineering Decisions

MQTT Instead of Kafka for the Live Prediction Path

The initial architecture experimented with Kafka for incoming vehicle events.

During testing, when prediction throughput temporarily fell behind the incoming event rate, messages accumulated in the stream.

For many event-processing systems this durability is desirable. For this particular service, however, processing an old GPS position several seconds later provided little value.

The application was predicting only five seconds into the future.

A delayed prediction could therefore become obsolete before it was delivered.

The architecture was changed to MQTT with a stronger emphasis on continuous delivery of fresh telemetry rather than preserving an increasing backlog of stale events.

Trade-off

The system deliberately accepted the possibility of some message loss in exchange for lower operational complexity and an architecture better aligned with the latency requirements of the demonstration.

Redis for Per-Vehicle Sequence State

Transformer inference required a recent sequence of vehicle states rather than a single GPS message.

Redis was used to maintain short FIFO-style sequences keyed by equipment ID:

vehicle_001
    └── [t-4, t-3, t-2, t-1, t]

vehicle_002
    └── [t-4, t-3, t-2, t-1, t]

...

vehicle_N
    └── [t-4, t-3, t-2, t-1, t]

This separated temporary sequence state from individual worker processes and allowed preprocessing workers to operate on messages from many vehicles.

Redis was already required for this short-lived sequence state, which also made Celery a practical choice for distributing preprocessing and prediction workloads without introducing another infrastructure component.

Separate Preprocessing and Prediction Workers

Preprocessing and inference were separated into chained Celery tasks.

GPS Message
     │
     ▼
Preprocessing Worker
     │
     ├── feature transformation
     ├── missing-value handling
     ├── anomaly handling
     └── sequence update
     │
     ▼
Prediction Worker
     │
     └── PyTorch inference
     │
     ▼
Predicted Trajectory

This separated data preparation from model execution and made the real-time pipeline easier to reason about and operate.

GPU Training, CPU Inference

GPU resources were used during model training to reduce development and experimentation time before the project deadline.

The production inference workload had different requirements.

The trajectory model was lightweight enough to perform inference on CPU-based workers without requiring dedicated GPU serving infrastructure.

Using CPU inference avoided the additional cost and operational complexity of maintaining GPU infrastructure for a demonstration-scale deployment while still meeting the latency requirements of the service.

Performance

The service was evaluated primarily as a real-time system rather than only as an offline ML model.

End-to-End Prediction Latency

Latency was measured from:

MQTT message received
        ↓
preprocessing
        ↓
sequence construction
        ↓
model inference
        ↓
prediction completed

Observed end-to-end prediction latency was approximately:

0.1–0.3 seconds

This kept processing substantially below the five-second prediction horizon and allowed predictions to remain useful for real-time visualization.

Observed Data Loss

Processing reliability was estimated by comparing the number of incoming GPS messages with the number of successfully produced prediction messages.

Observed loss during real-time processing was approximately:

1–5%

The architecture intentionally prioritized prediction freshness and latency over guaranteed processing of every message.

For the demonstration use case, receiving a current prediction quickly was considered more valuable than delaying the pipeline to recover every intermediate vehicle update.

Deployment

The compute-intensive real-time processing components and local MongoDB instance were operated separately from the cloud-facing service.

The Django backend was containerized and deployed on AWS, where it exposed stored prediction results to the frontend visualization.

This allowed the project to expose prediction results externally without requiring the entire ML processing environment to be migrated to GPU-enabled cloud infrastructure.

Limitations & What I Would Improve

The system was developed as a demonstration rather than a production safety system.

One important limitation was how the pipeline represented time.

Sequences were primarily constructed according to message order. If an individual message contained missing values, the preprocessing pipeline could apply the preprocessing methodology defined for the model.

However, if an entire GPS message was never published or received, the pipeline did not reconstruct the missing time interval.

For example:

Actual time

t=1s → t=2s → [missing] → t=4s → t=5s

Sequence interpreted by pipeline

point 1 → point 2 → point 3 → point 4

This means a sequence could implicitly represent unequal real-world time intervals while the model treated the observations as consecutive steps.

For a production collision-risk system, I would make timestamps an explicit part of sequence validation and detect gaps before inference.

Depending on the required safety and latency guarantees, this could include:

rejecting sequences with excessive gaps,

interpolation for short missing intervals,

explicit time-delta features,

freshness thresholds,

and monitoring message loss per vehicle.

The demonstration also prioritized low latency over guaranteed delivery. A production safety system would require substantially stronger reliability guarantees, observability, failure handling, and validation before predictions could be used for operational collision prevention.

Results

The project demonstrated that a research trajectory-prediction model could be integrated into a live smart-port IoT environment.

The resulting system:

processed live telemetry from approximately 90–110 simultaneously operating yard tractors,

consumed vehicle updates at approximately one-second intervals,

predicted five seconds of future trajectory from recent movement sequences,

achieved approximately 0.1–0.3 seconds of end-to-end prediction latency,

maintained observed prediction-message loss at approximately 1–5% during testing,

and exposed predictions through a cloud-hosted API for live visualization.

More importantly, the project demonstrated the engineering work required to move an ML model beyond offline experimentation and into a continuously operating real-time data pipeline.

Like this project

Completed work

Posted Sep 20, 2026

Developed real-time ML service for predicting yard tractor movement using live GPS data.

Likes

Views

Timeline

Oct 1, 2023 - Dec 31, 2023