🎓 Lesson 12
D5
Telematics Data Architecture: CAN Bus, GPS & Edge Processing
Telematics data architecture is how machines like haul trucks send real-time data—like location, speed, and engine health—to computers that help engineers make smarter decisions about mining transport.
🎯 Learning Objectives
- ✓ Analyze CAN bus message timing to identify packet loss thresholds affecting payload estimation accuracy
- ✓ Design an edge processing filter to reduce GPS position noise below ±1.5 m RMS in open-pit environments
- ✓ Apply ISO 11783-7 message structure to decode engine torque and fuel rate signals from a Komatsu 930E haul truck
- ✓ Calculate required uplink bandwidth for 50-truck fleet transmitting telematics at 1 Hz with 95% confidence interval
📖 Why This Matters
In modern open-pit mines, haul trucks generate over 2 GB of raw sensor data per shift—but only 3–5% is actionable without intelligent architecture. Poorly designed telematics pipelines cause delayed dispatch decisions, inaccurate cycle time reporting, and missed fatigue alerts. At Rio Tinto’s Pilbara operations, upgrading to edge-processed GPS/CAN fusion reduced average cycle time variance by 22% and cut fuel waste by 4.7%—proving this isn’t just ‘data collection’; it’s the nervous system of autonomous and semi-autonomous haulage.
📘 Core Principles
Telematics architecture operates across three layers: (1) The physical layer—CAN bus (Controller Area Network) provides robust, deterministic, multi-master serial communication between ECUs (engine, transmission, brakes); its differential signaling resists EMI in high-vibration mining environments. (2) The positioning layer—GPS augmented with RTK (Real-Time Kinematic) or SBAS (Satellite-Based Augmentation Systems) delivers sub-meter accuracy critical for payload verification and dump/stockpile targeting. (3) The edge layer—onboard microcontrollers (e.g., NVIDIA Jetson Orin) run lightweight ML models (e.g., anomaly detection on vibration spectra) and apply temporal-spatial filtering *before* data leaves the vehicle—reducing cloud load and enabling sub-second response for collision avoidance or grade control feedback loops.
📐 Required Uplink Bandwidth Calculation
Bandwidth estimation ensures reliable transmission of compressed telematics streams under constrained satellite/cellular links. It accounts for message frequency, payload size, protocol overhead, and redundancy for lossy networks.
Uplink Bandwidth Requirement
BW = N × f × P × (1 + OH) × RCalculates minimum sustained uplink bandwidth (bps) needed for reliable telematics transmission across a fleet.
Variables:
| Symbol | Name | Unit | Description |
|---|---|---|---|
| BW | Required bandwidth | bps | Minimum sustained data rate for reliable transmission |
| N | Number of vehicles | unitless | Size of monitored haul fleet |
| f | Transmission frequency | Hz | How often each vehicle sends a full telemetry bundle |
| P | Base payload size | bytes | Sum of all sensor messages before overhead |
| OH | Protocol overhead factor | unitless | Fractional increase due to TCP/IP headers, encryption, framing |
| R | Retransmission factor | unitless | Redundancy multiplier for target reliability (e.g., 2.0 for 99.9% link uptime) |
Typical Ranges:
Satellite uplink (Iridium Certus): 128 – 700 kbps
LTE-M in pit coverage zone: 1 – 10 Mbps
💡 Worked Example
Problem: A fleet of 30 CAT 797F trucks transmits 12 CAN messages (each 8 bytes) + 1 NMEA GGA sentence (120 bytes) + 1 RTK correction packet (40 bytes) every 2 seconds. Protocol overhead (TCP/IP + encryption) adds 35%. Assume 99.9% reliability requires 2x retransmission buffer.
1.
Step 1: Calculate base payload per transmission = (12 × 8) + 120 + 40 = 236 bytes
2.
Step 2: Apply overhead: 236 × 1.35 = 318.6 bytes ≈ 319 bytes
3.
Step 3: Include retransmission buffer: 319 × 2 = 638 bytes per transmission
4.
Step 4: Transmission rate = 1/2 Hz → 0.5 transmissions/sec per truck → 30 × 0.5 = 15 transmissions/sec fleet-wide
5.
Step 5: Total bytes/sec = 638 × 15 = 9,570 B/s = 76.56 kbps
Answer:
The minimum required uplink bandwidth is 76.6 kbps, which fits within standard Iridium Certus 200 (128 kbps) or LTE-M (1 Mbps) links—validating feasibility for remote deployment.
🏗️ Real-World Application
At Newmont’s Boddington Mine (Western Australia), legacy telematics sent raw CAN logs to cloud servers every 10 seconds, causing 8–12 second delays in payload estimation. Engineers deployed NVIDIA Jetson edge nodes running Kalman-filtered GPS/CAN fusion: engine torque + wheel speed + incline angle were combined with RTK position to compute real-time payload (±0.8% error vs. scale tickets). Edge-processed payloads triggered dynamic loading adjustments via DISPATCH® interface—reducing underloading by 14% and overloading-related tire failures by 31% in Year 1.
📋 Case Connection
📋 Canadian Gold Mine: Steep Ramp Optimization in Narrow Vein Underground
Excessive truck cycle times and premature tire/brake wear due to suboptimal ramp gradient (15%) combined with tight hori...
📋 South African Platinum Mine: Waste Dump Reclaim Optimization
Inefficient haulage routing and underutilized fleet capacity during waste dump reclamation, resulting in excessive diese...