🎓 Lesson 4
D3
OEM Protocol Mapping: MineStar™, FleetForce™, and Custom APIs
OEM Protocol Mapping is how different mining software systems—like MineStar™ and FleetForce™—talk to each other by translating commands and data so autonomous haul trucks can operate safely and efficiently across platforms.
🎯 Learning Objectives
- ✓ Analyze MineStar™ and FleetForce™ API documentation to identify equivalent telemetry fields (e.g., 'engine_rpm' vs. 'rpm_engine')
- ✓ Design a protocol mapping table that resolves semantic mismatches between OEM payloads using ISO 15143-3 asset health conventions
- ✓ Apply latency budgeting principles to validate end-to-end command propagation time (<250 ms) across mapped interfaces
- ✓ Explain how CRC-16 checksums and sequence numbering prevent message corruption in UDP-based OEM telemetry streams
📖 Why This Matters
When a mine deploys mixed-fleet autonomous haulage—say, CAT 797Ps running MineStar™ alongside Komatsu 930E-12s on FleetForce™—a single dispatch command must reach *all* trucks reliably, with synchronized status feedback. Without precise OEM protocol mapping, mismatched units (e.g., speed in km/h vs. m/s), missing fault codes, or unacknowledged brake commands can cause operational delays—or worse, safety incidents. This lesson bridges the gap between software integration theory and field-deployable interoperability.
📘 Core Principles
Protocol mapping operates at three layers: syntactic (message format: JSON vs. binary CAN), semantic (meaning of fields: 'brake_pressure' may represent hydraulic pressure in bar or % full-scale), and pragmatic (timing constraints: max 200 ms round-trip for emergency stop acknowledgment). Industry practice distinguishes between 'passive mapping' (one-way telemetry translation) and 'active mapping' (bidirectional command/state synchronization with handshake protocols). Critical success factors include adherence to ISO 15143-3 for equipment health data, use of SAE J1939 parameter group numbers (PGNs) where applicable, and validation against IEC 61508 SIL-2 for safety-related mappings.
📐 End-to-End Latency Budget Calculation
Total system latency must remain below 250 ms for closed-loop AHS control (per ISO 22181:2022 Annex B). This budget is allocated across network hops, serialization/deserialization, mapping logic, and OEM stack processing.
Latency Budget Allocation
L_total = L_network + L_serialization + L_mapping + L_OEM_stackCalculates total end-to-end latency across protocol mapping layers to ensure compliance with real-time AHS control standards.
Variables:
| Symbol | Name | Unit | Description |
|---|---|---|---|
| L_total | Total system latency | ms | Maximum allowable time from command issuance to confirmed actuation |
| L_network | Network round-trip time | ms | Measured latency over industrial Ethernet or cellular link (e.g., 4G/LTE private network) |
| L_serialization | Data encoding/decoding time | ms | Time to convert between JSON/XML and binary CAN frames or vice versa |
| L_mapping | Mapping logic execution time | ms | CPU time spent applying field transformations, unit conversions, and safety checks |
| L_OEM_stack | OEM software stack processing time | ms | Time taken by MineStar™ or FleetForce™ internal dispatcher to process and route the mapped command |
Typical Ranges:
Private 4G LTE network: 35 – 65 ms
REST-to-CAN gateway: 15 – 40 ms
Field-level mapping engine (x86): 20 – 50 ms
MineStar™ Command Dispatcher: 50 – 90 ms
💡 Worked Example
Problem: A mine integrates FleetForce™ dispatch with MineStar™ truck control via a REST-to-CAN gateway. Measured components: network RTT = 42 ms, JSON parsing = 18 ms, mapping logic execution = 33 ms, MineStar™ CAN frame queuing = 67 ms. Does total latency meet ISO 22181 requirement?
1.
Step 1: Sum all latency components: 42 + 18 + 33 + 67 = 160 ms
2.
Step 2: Compare against ISO 22181 maximum of 250 ms
3.
Step 3: Confirm margin = 250 − 160 = 90 ms remaining for jitter and failover
Answer:
The result is 160 ms, which falls within the safe range of 0–250 ms.
🏗️ Real-World Application
At Rio Tinto’s Pilbara Operations (2022), integration of Hitachi EX1200-12 shovels (using FleetForce™) with CAT 797F trucks (MineStar™) required mapping 142 telemetry fields and 28 command types. A critical issue arose when FleetForce™ sent 'target_speed_mps' while MineStar™ expected 'speed_setpoint_kph'. Engineers resolved it by deploying a field-programmable mapping engine with unit-aware transformation rules and real-time validation against ISO 15143-3 Asset Health IDs—reducing dispatch latency variance from ±142 ms to ±11 ms.