KEY TAKEAWAYS
- Drive Monitoring System behavior data originates in the vehicle’s CAN bus. InGenious reads it directly via OBD-II/J1939 and transmits via 4G/LTE to InRoute every 10 to 30 seconds.
- Raw CAN signals (throttle input, brake pressure, RPM, gear selection) are converted into structured DriveIQ scorecard data through Intangles’ risk-weighted algorithms, not simple threshold rules.
- Alert rules in InRoute are configurable per fleet, route group, driver tier, and vehicle class. One threshold does not apply to all drivers.
- DriveIQ behavior data connects to vehicle health monitoring and fuel monitoring in the same platform. An aggressive braking pattern that also correlates with ABS fault codes triggers both a driver alert and a maintenance work order.
In 2025, 88% of fleets now use telematics for safety, yet far fewer leverage the data deeply enough to understand how vehicles are actually being driven. This gap between data collection and actionable insight leaves critical risk factors, from aggressive driving to early mechanical stress, hidden until costs or incidents surface.
Traditional telematics explains where vehicles go and when events occur. It does not explain why unsafe patterns repeat or how operational decisions amplify risk. This is where driver behavior monitoring becomes essential, not as a standalone safety tool, but as an integrated data layer inside your fleet management platform.
This is where driver behavior monitoring becomes essential. In this blog, we walk through how, for fleet IT managers and operations leaders who are already past the “what is DMS” question, the more pressing evaluation is technical: how does behavior data move from the vehicle into the fleet platform, how does it connect with vehicle health, fuel monitoring, and ELD compliance, and what does each role in the organization actually see on the other end.
Layer 1: The data source — How CAN-bus behavior signals reach the platform
Every behavior event your fleet management software displays starts with a raw signal on the vehicle’s CAN bus. The CAN bus is the internal communications network that connects engine controllers, transmission systems, brakes, and sensors. For heavy trucks on US roads, the relevant protocol is SAE J1939, the commercial vehicle extension of the standard OBD-II interface. According to the Fleet Technology Alliance, J1939 CAN bus offers a greater degree of granularity in terms of data resolution and spans a much wider range of parameters than standard OBD-II, giving access to many individual sensor readings and system parameters directly from the vehicle’s ECU. For a deeper breakdown of what the OBD-II layer captures, the OBD-II guide for US fleet managers covers the protocol in full.
Intangles’ InGenious device connects directly to the OBD port, with no external wiring and no fuel tank modifications, and reads native CAN signals in real time. For driver behavior specifically, InGenious captures throttle position (acceleration input pattern), brake pressure (braking aggressiveness), steering input angle (cornering behavior), engine RPM relative to vehicle speed (gear optimization and free-running detection), and idle engine-on time. These are raw signals at the ECU level, not pre-computed summaries.
Transmission happens via 4G/LTE from InGenious to the InRoute cloud platform every 10 to 30 seconds, with the update interval configurable per deployment. InGenious runs a quad-core onboard processor that buffers data locally during coverage dead zones, so behavior records remain complete even through areas with poor cellular coverage. At the InRoute cloud ingestion layer, each data packet is timestamped, tagged with GPS location and route context, and passed to the DriveIQ scoring engine for processing.
Layer 2: Scorecard generation — How raw signals become structured driver data
Raw CAN signals tell you what the vehicle did. The DriveIQ scoring engine tells you what it means, and that distinction matters for fleet IT teams evaluating integration, because it is the structured scorecard output, not the raw signal, that downstream systems consume via API.
InRoute’s DriveIQ engine does not treat all exceptions equally. Hard braking carries a higher safety-risk weight than idling because its accident correlation is demonstrably higher across the fleet dataset. Harsh acceleration sits between the two. The scoring model applies risk weights to each exception type, reflecting actual operational impact rather than raw event count. A driver who triggers 20 idle alerts and zero hard-braking events should score differently from one with the inverse pattern, and in DriveIQ, they do.
Scores are normalized per 10 km and per engine hour, not total events. A driver covering 500 km across mountain grades in the Southwest is not benchmarked against an interstate driver doing the same distance on a flat highway. Route context from GPS is layered onto the behavior signal before scoring, so the comparison is fair across duty cycles and geographies. The FMCSA’s Large Truck Crash Causation Study established that driver-related factors were present in 33% of fatal crashes involving large commercial trucks, with speeding and distraction/inattention as the leading contributors. Scoring that accounts for the route environment reflects that complexity rather than flattening it.
The structured output from DriveIQ includes an overall grade (A through D), an overall peer rank within the fleet, per-exception scores across hard braking, overspeeding, harsh acceleration, continuous driving, free running, and unscheduled driving, plus distance covered, engine hours, and fuel consumed for that scoring period. These are the fields that external TMS, CMMS, or HR platforms consume when integrating DriveIQ data via API.
Layer 3: Configurable alert rules — How DMS triggers actions in the fleet platform
Behavior data becomes operationally useful when it triggers the right action for the right person at the right threshold. That requires configurable alert logic, not a single global setting applied to every driver, route, and vehicle class in the fleet.
In InRoute, alert rules are not one-size-fits-all. Fleet managers configure thresholds by fleet group, route type, vehicle class, and driver tier. Flagging a new driver for overspeeding at 5 mph over the posted limit is appropriate early-stage coaching. Firing the same alert for a veteran driver doing 500 km weekly across the same corridor generates noise that gets ignored. Alert fatigue in fleet management software is a documented operational problem, and threshold architecture is where it starts.
The alert types configurable in InRoute include overspeeding (adjustable mph threshold), idling (configurable duration), harsh acceleration (g-force threshold), hard braking (g-force threshold), free running (engine on, zero traction load, configurable duration), continuous driving beyond the HOS window, and unscheduled driving (vehicle movement outside assigned route or time window). Each alert type can be tuned independently per group.
Role-based routing is what separates a useful DMS integration from a noisy one. When an exception fires in InRoute, the same event produces three separate outputs: the fleet manager dashboard receives aggregate exceptions across the full fleet; the dispatcher receives vehicle-specific delay and route deviation alerts; and the driver receives an in-cab notification, configurable as a buzzer, app push notification, or dashboard message. The event is the same. The output is shaped by role.
One additional routing layer is worth noting for fleet IT evaluations: when InRoute detects that a harsh braking event correlates with an ABS fault code active on the same vehicle, the alert automatically escalates from a driver behavior event to a maintenance flag. The same platform handles both, and the correlation happens natively, with no manual cross-referencing required.
Layer 4: Cross-platform integration — How DriverIQ connects to the rest of InRoute
This is the section that most DMS evaluations miss. A standalone driver monitoring system captures behavior and produces a scorecard. An integrated fleet platform takes that behavior data and uses it to inform vehicle health, fuel monitoring, and HOS compliance decisions, without requiring a separate API call for each module. InRoute does this natively.
Behavior to vehicle health
A driver with a persistent hard-braking pattern generates a combined output: a driver coaching flag in DriveIQ and a brake pad wear-rate deviation flag on that vehicle’s predictive maintenance schedule. The two signals inform each other. Brake stress patterns from driver behavior accelerate component wear at a measurable rate, and InRoute surfaces that connect rather than keep the two data streams siloed. For fleet IT teams evaluating CMMS integration, this means a behavior event can generate a maintenance work order automatically, without a manual hand-off.
Behavior to fuel monitoring
Aggressive acceleration patterns on a specific vehicle are correlated against that vehicle’s fuel consumption baseline in InRoute. If the MPG deviation exceeds the configured threshold, the system attributes the excess fuel cost to the behavioral event, giving fleet managers a dollar figure attached to driving behavior, not just an event count. That attribution capability converts a safety metric into an operational cost conversation.
Behavior to ELD
Continuous driving alerts from DriveIQ feed into the HOS monitoring layer. If a driver is approaching their 11-hour driving limit under FMCSA rules and DriveIQ flags fatigue indicators from driving pattern data, the system can trigger a rest recommendation before the HOS clock forces a stop. The FMCSA is actively studying how driver work schedules and fatigue correlate with crash risk, reinforcing why connecting behavior monitoring to HOS compliance is an architectural decision, not just a feature. DriveTime ELD handles HOS compliance within the same InRoute environment and manages the connection between both modules.
Related Guide: What is an ELD? Compliance and Fleet Tracking
For Intangles customers, all four cross-module connections happen within InRoute. No third-party API configuration is required for behavior data to reach health monitoring, fuel monitoring, or ELD modules. External fleet software, including standalone TMS platforms, CMMS, or HR systems, can consume DriveIQ data via InRoute’s API for downstream integration.
What fleet IT teams need to evaluate: Integration readiness checklist
Before committing to any DMS vendor, five technical questions should drive the evaluation. The answers reveal whether a system will genuinely integrate with your existing stack or require ongoing manual workarounds.
1. Does the DMS read native CAN-bus/J1939 data, or only filtered OBD-II PIDs?
A filtered OBD-II connection limits you to roughly 47 standardized PIDs. Native CAN access via J1939 opens the full ECU dataset, which is where behavior signals like brake pressure, throttle position, and steering input actually live. Intangles answer: InGenious reads native CAN via J1939, not a filtered subset.
2. Are alert thresholds configurable per fleet group and route, or is it a single global setting?
A global threshold produces alert fatigue for experienced drivers and misses coaching opportunities for new ones. Intangles answer: Configurable per fleet group, route type, vehicle class, and driver tier.
3. Does the scorecard normalize per distance and time, or report raw event counts?
Raw event counts penalize high-mileage drivers and those on demanding routes. Normalized scores enable fair comparison. Intangles answer: Normalized per 10 km and per engine hour across all exception types.
4. Does behavior data connect to vehicle health and fuel monitoring natively, or is a separate API required?
If integration requires a custom API build for each module connection, the operational cost of maintaining those connections falls on your IT team. Intangles answer: Native within InRoute. No separate API for cross-module data sharing.
5. Does the system support role-based alert routing, with different views for fleet managers, dispatchers, and drivers?
A single undifferentiated alert feed creates noise at every level. Role-based routing ensures each stakeholder sees what is relevant to their decisions. Intangles answer: Three separate output layers per event, covering fleet manager, dispatcher, and driver.
See the integration in practice
Most DMS evaluations stop at the scorecard. The more consequential question for fleet IT is what happens after the score is generated: how it flows into vehicle health alerts, fuel cost attribution, and HOS compliance without requiring manual cross-referencing across separate systems.
The data pipeline described above, from raw CAN signal to structured scorecard to cross-module action, represents the difference between a DMS that tells you something happened and a platform that tells you what it cost, what it indicates about vehicle condition, and what should happen next. For fleets managing dozens or hundreds of assets, that gap in integration depth translates directly into decision lag, manual coordination overhead, and incidents that a connected system would have flagged earlier.
Intangles’ DriveIQ connects driver behavior data to vehicle health monitoring, fuel monitoring, and ELD compliance in one platform, without third-party API configuration. Behavior signals do not live in a separate module. They feed the same decision layer that manages maintenance, fuel, and operations.
Explore how Intangles’ driver behavior monitoring solution integrates across InRoute, or speak with our team to walk through the data flow for your specific fleet configuration.
KNOW MORE
Frequently Asked Questions
How does a driver monitoring system send data to fleet management software?
InGenious reads raw CAN bus signals via the OBD-II/J1939 port and transmits them via 4G/LTE to the InRoute cloud platform every 10 to 30 seconds. Data is buffered locally on the device’s quad-core processor during dead zones to prevent gaps in the behavior record. At the InRoute ingestion layer, packets are timestamped, tagged with GPS and route context, and passed to the DriveIQ scoring engine for processing before the structured output is available in the platform dashboard.
Can DMS alert thresholds be configured per fleet group or driver tier?
Yes. In InRoute, alert thresholds are configurable by fleet group, route type, vehicle class, and driver tier. Overspeeding thresholds, idling duration limits, g-force thresholds for harsh acceleration and hard braking, and free-running duration windows can all be set independently per group. A blanket threshold applied across a mixed fleet generates alert fatigue for experienced drivers while under-flagging risk in newer ones.
How does DriveIQ driver data connect to vehicle health monitoring in Intangles?
Within InRoute, hard-braking frequency and pattern data from DriveIQ are correlated with brake system fault codes on the same vehicle. When a behavior pattern correlates with an active DTC, the event escalates from a driver coaching flag to a maintenance flag and can trigger a work order in the maintenance module without manual intervention. This cross-module connection is native to InRoute. No third-party API is required.
Does Intangles require a separate API to connect driver behavior data with fuel monitoring?
No. DriveIQ behavior data and fuel monitoring data share the same InRoute platform layer. Aggressive acceleration patterns are automatically correlated against the vehicle’s fuel consumption baseline, and MPG deviations above the configured threshold are attributed to the behavioral event. This gives fleet managers a dollar figure per driving behavior, not just an event count. External platforms, like a standalone TMS or CMMS, can consume this data via InRoute’s API, but the internal cross-module connection requires no separate integration build.
What is the difference between raw CAN-bus behavior data and a processed driver scorecard?
Raw CAN bus data is the unprocessed signal from the vehicle’s ECU: throttle position values, brake pressure readings, RPM versus speed ratios, and steering angle inputs. These signals indicate what the vehicle did at a hardware level. A processed DriveIQ scorecard applies risk-weighted algorithms to those signals, normalizes the result per 10 km and per engine hour to account for route difficulty, and outputs a structured grade, peer rank, and per-exception breakdown. The scorecard is what operations teams act on. The raw signals are what the system uses to generate it fairly across different routes and duty cycles.
We’re looking forward to meeting you