Wrong Hours/Runtime Data

Overview

Accurate runtime tracking is critical for maintenance scheduling. If maintenance counters show incorrect hours, accumulate too quickly/slowly, or don't match physical hour meters, troubleshooting is needed. This guide addresses common runtime data issues and their solutions.

Common Symptoms

• Maintenance counter doesn't match physical hour meter on equipment
• Counter accumulating too quickly (more than 24 hours per day)
• Counter accumulating too slowly or not at all
• Counter reset unexpectedly
• Runtime shows negative values
• Sudden large jumps in counter value

Issue 1: Counter Doesn't Match Hour Meter

Why This Happens

ARMOR maintenance counters and physical hour meters track runtime independently:

• Physical Hour Meter: Built into equipment, tracks total lifetime hours
• ARMOR Counter: Tracks hours since last maintenance completion (resets to zero)

Expected Behavior

When It's a Problem

Issue exists if:

• Physical meter = 5,247 hours, but ARMOR counter = 523 hours (way off)
• Physical meter increased by 10 hours today, but ARMOR counter only increased by 2 hours
• Rate of accumulation significantly different

Solution: Initialize Counter Correctly

1. After performing maintenance, manually verify:
   • Physical hour meter reading
   • Record this value in maintenance completion notes
2. When marking maintenance complete in ARMOR, counter should reset to zero
3. From this point forward, ARMOR counter tracks hours since that maintenance
4. For next maintenance check, compare:
   • Current physical meter - recorded physical meter = hours since last maintenance
   • Should match ARMOR counter within a few hours

Issue 2: Counter Accumulating Too Fast

Symptoms

• Counter shows 30 hours accumulated in single day (impossible)
• Maintenance due much sooner than expected
• Counter increasing even when equipment not in use

Possible Causes

Cause A: Wrong Telemetry Field

• Maintenance rule tracking wrong data field
• Example: Tracking cumulative "total_seconds" instead of "engine_hours"
• Seconds accumulate 3,600 times faster than hours

Cause B: Field Reported in Different Units

• Device reports "engine_minutes" but ARMOR interprets as hours
• Results in 60x too fast accumulation

Cause C: Duplicate Data Sources

• Multiple devices reporting same telemetry field
• ARMOR accumulating from both sources
• Doubles the accumulation rate

Diagnosis

1. Check maintenance rule configuration
2. Note the dataField being tracked (e.g., "engine_hours")
3. Navigate to asset telemetry/live data
4. Find that specific data field
5. Compare its value and rate of change to expected
6. Check if multiple similar fields exist (engine_hours, runtime_hours, etc.)

Solution

1. Verify correct field:
   • Edit maintenance rule
   • Change dataField to correct field name
   • Common correct fields: "engine_hours", "runtime_hours", "operating_hours"
   • Avoid: "engine_seconds", "timestamp", "total_runtime_minutes"
2. Check unit configuration:
   • Contact support if field reports in minutes but needs to be interpreted as hours
   • Support can apply conversion factor
3. Reset counter:
   • After fixing field configuration, manually reset counter to accurate value
   • Monitor for 24 hours to verify correct accumulation rate

Issue 3: Counter Accumulating Too Slow or Not At All

Symptoms

• Equipment clearly running but counter not increasing
• Counter stuck at same value for days
• Maintenance never becomes due despite heavy use

Possible Causes

Cause A: No Telemetry

• Device offline or not connected
• No data flowing to ARMOR
• See "Maintenance Not Triggering" for telemetry troubleshooting

Cause B: Wrong Field Mapped

• Maintenance rule tracking field that doesn't update
• Example: Tracking "initial_hours" which is static, not "current_hours" which accumulates

Cause C: Field Only Updated Periodically

• Some devices only report runtime during ignition off events
• Counter appears stuck but will jump when equipment powered down
• This is normal for some device types

Diagnosis

1. Check asset telemetry status
2. Verify device connected and sending data
3. Check "Last Updated" timestamp on relevant telemetry field
4. Note field value now, then check again after equipment used
5. If field value changes in telemetry but not in maintenance counter, field mapping issue exists

Solution

1. Fix connectivity: (See telemetry troubleshooting guide)
2. Correct field mapping:
   • Edit maintenance rule
   • Change dataField to field that actively accumulates
   • Save and monitor
3. For periodic update devices:
   • Verify counter does update after ignition cycle
   • If so, this is expected behavior for that device type
   • Consider time-based maintenance if runtime tracking too delayed

Issue 4: Counter Reset Unexpectedly

Symptoms

• Counter was at 200 hours, now shows 10 hours
• No maintenance completion recorded
• Hours "lost"

Possible Causes

• Maintenance marked complete by mistake: Someone accidentally clicked "complete"
• Manual counter adjustment: Administrator manually reset counter
• Telemetry field reset: Device or backend reset the runtime field
• Rule reinitialized: Maintenance rule disabled and re-enabled, causing reinit

Diagnosis

1. Check maintenance completion history
2. Look for completion entry at time counter reset
3. Check system logs (if available) for manual adjustments
4. Review telemetry data to see if source field also reset

Solution

1. If accidental completion:
   • Use "Undo Completion" feature if available
   • Or manually adjust counter back to approximate correct value
2. If manual adjustment:
   • Determine why adjustment made
   • If mistake, readjust to correct value
3. If telemetry reset:
   • This indicates device issue
   • Contact device vendor or ARMOR support
   • Manually set counter to last known good value
   • Consider switching to time-based maintenance if runtime unreliable

Issue 5: Sudden Large Jumps in Counter

Symptoms

• Counter jumps from 50 hours to 500 hours instantly
• Maintenance suddenly shows overdue
• Counter increased by impossible amount in short time

Possible Causes

• Initialization mode inherited cumulative value: Rule set to "inherit-current" and picked up lifetime hours instead of zero
• Device reported lifetime value: Telemetry field switched from incremental to cumulative
• Data backfill: Historical data loaded, causing counter to jump
• Field units changed: Field switched from hours to minutes, causing 60x jump

Solution

1. Reset counter:
   • Manually adjust counter to correct value
   • Based on known maintenance history and current actual hours
2. Fix initialization mode:
   • Edit maintenance rule
   • Change initMode to "start-at-zero" if appropriate
   • Or verify field being tracked is incremental (resets after maintenance) not cumulative (lifetime total)
3. Verify field configuration:
   • Contact support to verify correct telemetry field and units
   • May need field mapping adjustment on backend

Validation and Monitoring

After Fixing Issues

1. Baseline check:
   • Note current counter value
   • Note current physical hour meter
   • Record time/date
2. Monitor accumulation:
   • After 8 hours of equipment operation, check both values again
   • ARMOR counter should have increased by ~8 hours
   • Physical meter should also have increased by ~8 hours
   • Values should be within 1-2 hours of each other (small variance OK)
3. Longer-term validation:
   • Check weekly for first month
   • Verify consistent, accurate tracking
   • Adjust if drift occurs

Expected Variance

Small differences between ARMOR counter and physical hour meter are normal:

Variance	Status	Action
0-3 hours difference	✓ Normal	No action needed
3-10 hours difference	⚠ Monitor	Acceptable but monitor for drift
>10 hours difference	✗ Issue	Investigate and correct

Best Practices for Accurate Runtime Tracking

• Record hour meter at maintenance: Always note physical hour meter when performing maintenance
• Verify counter reset: After marking maintenance complete, verify ARMOR counter reset to zero
• Spot check monthly: Compare ARMOR counter to physical meter monthly
• Consistent field naming: Use same telemetry field names across all equipment of same type
• Test new devices: When adding new device type, monitor runtime tracking closely for first few weeks
• Document configurations: Keep notes on which telemetry fields used for which maintenance rules
• Train technicians: Ensure techs understand importance of accurate hour meter recording

Alternative: Time-Based Maintenance

If runtime tracking proves unreliable, consider switching to time-based maintenance:

Pros of time-based:

• No dependency on telemetry accuracy
• Fixed, predictable schedule
• Easy to plan and coordinate

Cons of time-based:

• Doesn't account for actual usage variations
• May perform maintenance too early (low use) or too late (high use)
• Less optimal than accurate runtime-based tracking

What's Next?

• Maintenance Not Triggering - Fix issues with maintenance alerts
• Maintenance Showing Incorrect Status - Resolve status display problems
• Types of Maintenance - Understanding time vs runtime vs distance-based maintenance
• Understanding Maintenance Rules - Configuration deep dive

Getting Help

For assistance troubleshooting runtime tracking issues, contact the ARMOR Support Team with:

• Asset ID or name
• Maintenance rule description
• Current ARMOR counter value
• Current physical hour meter reading
• Device type and model