Metrics
Metrics are canonical, normalized measurements extracted from raw telemetry. They form the foundation of ModularIoT’s data model and enable cross-device analysis, symptom detection, and operational intelligence.
The Problem Metrics Solve
Different devices report the same data differently:
- A Teltonika tracker reports speed in a field called
speed - A Queclink device uses
spdwith different precision - An OBD-II reader provides PID 0D as a raw byte value
- A J1939 truck reports SPN 84 in different units
Without normalization, you’d need custom logic for every device type, making cross-fleet analysis impossible.
Metrics solve this problem. One canonical key (vehicle.speed), one unit (km/h), one meaning—regardless of source.
Metric Anatomy
Every metric consists of:
| Component | Description | Example |
|---|---|---|
| Key | Hierarchical identifier | engine.rpm |
| Value | The measurement | 2500 |
| Unit | Canonical unit (implicit in key) | rpm |
| Timestamp | When measured (device time) | 2024-01-15T10:30:00Z |
The unit is implicit in the key. When you see engine.coolant_temp, you know it’s Celsius. Always.
Metric Categories
ModularIoT organizes metrics into functional categories:
Powertrain Metrics
Engine health and performance indicators.
| Key | What It Measures |
|---|---|
engine.rpm | Engine speed |
engine.load | Calculated engine load percentage |
engine.coolant_temp | Coolant temperature |
throttle.position | Throttle opening percentage |
Fuel & Energy Metrics
Cost and efficiency indicators.
| Key | What It Measures |
|---|---|
fuel.level | Tank level percentage |
fuel.rate | Instantaneous consumption |
fuel.used | Cumulative fuel consumed |
battery.voltage | System voltage |
Motion & Usage Metrics
Behavior and operational context.
| Key | What It Measures |
|---|---|
vehicle.speed | Ground speed |
odometer | Total distance traveled |
idle.state | Engine running but not moving |
brake.state | Brake pedal active |
Diagnostics Metrics
Maintenance and health signals.
| Key | What It Measures |
|---|---|
dtc.mil_on | Check engine light status |
dtc.codes | Active trouble codes |
dtc.count | Number of active faults |
Metrics vs Telemetry vs Events
Understanding these distinctions is essential:
| Concept | Nature | Example |
|---|---|---|
| Telemetry | Raw device data (proprietary) | {"spd": 72, "lat": 37.77} |
| Metrics | Normalized measurements (canonical) | vehicle.speed = 72 km/h |
| Events | Discrete occurrences | ”Ignition turned on” |
Telemetry is what devices send. Metrics are what ModularIoT understands. Events are what happened.
Sparsity by Design
Not all vehicles support all metrics. A basic GPS tracker might only provide position. An OBD-II reader adds engine data. A J1939 truck provides fuel consumption.
This is expected. Metrics are sparse—drivers send only what they have. ModularIoT doesn’t require a fixed schema; it accepts whatever canonical metrics are available.
From Metrics to Symptoms
Metrics alone are just numbers. The power comes from what ModularIoT does with them:
Metrics → Detection Rules → Symptoms → Operator ActionsWhen engine.coolant_temp exceeds 105°C for 5 minutes, that’s not just data—it’s a symptom that triggers operator attention.
See Symptoms to understand how metrics become operational intelligence.
Key Takeaways
- Metrics are canonical: one key, one unit, one meaning
- Metrics are sparse: send only what you have
- Metrics are the foundation: symptoms and analysis depend on them
- Conversion happens at the edge: SDKs and drivers handle unit normalization