SAE J1939 and Its Role in Fleet Management and Vehicle Diagnostics

SAE J1939 is a standardized, CAN-based in-vehicle communications suite widely used in heavy-duty and off-highway domains, enabling interoperable exchange of operational telemetry (e.g., speed, engine hours, fuel rate) and a structured diagnostic ecosystem (Diagnostic Messages “DMs” and Diagnostic Trouble Codes “DTCs”). Its core fleet-management value is not “a single feature,” but the practical combination of (a) standardized parameter naming/encoding (SPNs within PGNs), (b) predictable transmission behaviors (periodic broadcasts and on-request responses), and (c) well-defined addressing and multi-packet transport for larger datasets. This combination is explicitly reflected in the SAE J1939 Digital Annex concept (centralizing SPN/PGN definitions) and in industry subsets such as the FMS Standard, which curates manufacturer-neutral PGNs for mixed fleets.

In fleet operations, J1939 primarily acts as a data acquisition and normalization layer. When fused with location/time and enterprise context, J1939-derived signals support real-time monitoring (idling, harsh braking, fuel burn), cost control (maintenance planning and utilization), and compliance reporting (engine hours, distance). For example, the ACEA FMS Standard specifies PGNs, SPNs, and repetition rates (e.g., 20 ms engine-speed updates, 1 s fuel totals, 10 s VIN) and defines how an FMS gateway may respond to requests and forward certain diagnostic requests rather than rebroadcast diagnostics by default.

For single-vehicle diagnostics, J1939 provides a coherent workflow centered on DM1 (Active DTCs) and a structured DTC format using SPN/FMI plus occurrence counters and lamp states. DM1 is specified as a cyclic broadcast (commonly 1 Hz), while most other DM messages are “on request” (e.g., DM2 previously active faults, DM3 clear previously active, DM11 clear active, DM12 emissions-related active, DM28 permanent DTCs). Multi-packet transport (TP.CM/TP.DT) is essential when diagnostic payloads exceed 8 bytes.

Quantified operational impacts are typically attributed to telematics and analytics programsthat rely in part on standardized vehicle data access (often including J1939). A recent National Renewable Energy Laboratory briefing summarizes earlier quantified estimates of telematics benefits totaling about $2,307 per vehicle per year across safety, idle reduction, aggressive driving reduction, reduced miles traveled, maintenance, reporting, and inventory optimization (context: public-sector fleet evaluation). While not “J1939-only,” these outcomes depend on consistent acquisition of engine hours, distance, fuel/idle metrics, and fault data—areas where J1939 is a common enabling interface in heavy-duty vehicles.

J1939’s challenges are increasingly shaped by (1) bandwidth constraints of classic CAN (8-byte payloads at 250/500 kbit/s), (2) cybersecurity exposure (lack of native encryption/authentication and susceptibility to spoofing/flooding), (3) data volume and sampling tradeoffs, and (4) OEM variability (proprietary PGNs, differing gateway policies). The standards family has evolved toward CAN FD through SAE J1939-17 (physical layer) and SAE J1939-22 (CAN FD data link layer), enabling larger payloads and higher data-phase bit rates; however, migration introduces interoperability and architectural constraints.

Background on J1939

SAE J1939 is maintained by SAE International as a family of documents aligned to (parts of) the OSI model: physical layer(s), data link / transport services, network management, and application-layer data definitions (PGNs/SPNs) including diagnostics. An important practical implication is that “J1939” in the field often means both (a) the standardized identifier + transport behaviors over CAN and (b) the standardized semantic payload catalog (SPNs grouped into PGNs), now centralized in the J1939 Digital Annex.

Scope, architecture, and OSI-layer coverage

J1939 uses CAN (ISO 11898 family) as the underlying physical/data-link technology in classic deployments, with J1939-specific conventions for 29-bit identifiers, addressing, and higher-layer behaviors. SAE publications for J1939-11 and J1939-14 explicitly frame these as physical-layer definitions tailored to harsh heavy-duty EMI environments and higher bandwidth needs, respectively.

This layering is reflected in external standards ecosystems as well: for example, AUTOSARpublishes a Diagnostic Communication Manager specification for SAE J1939 that explicitly references J1939-73 for DM behavior and distinguishes between fixed 8-byte DM messages handled via CAN interface APIs and variable-length DM messages handled via the J1939 transport protocol.

Physical, data-link, and transport layers

Physical layer options (classic CAN):

• J1939-11 (250 kbit/s, shielded twisted pair) is positioned as robust against electromagnetic interference and suitable for harsh environments.
• J1939-14 (500 kbit/s physical layer) is defined as higher bandwidth than other J1939 physical layers, with emphasis on EMI considerations and newer transceiver technologies.
• J1939-15 (250 kbit/s, unshielded twisted pair) describes a UTP physical layer with extended stub length flexibility.

Transport over multi-packet messages (J1939-21):

• J1939-21 defines a transport protocol for payloads larger than 8 bytes, using TP.CM(Connection Management) and TP.DT (Data Transfer) parameter groups; public technical summaries describe a maximum transport payload of 1,785 bytes (255 packets × 7 data bytes per packet, with one sequence byte).
• The transport PGN identifiers commonly used are PGN 0x00EC00 (60416) for TP.CM and PGN 0x00EB00 (60160) for TP.DT; the FMS Standard explicitly references these for VIN transfers longer than 8 bytes.

CAN FD evolution:

• SAE J1939-22 describes a CAN FD data-link layer to support flexible data rate communication per ISO 11898-1 (FD frame format).
• Descriptions of the CAN FD expansion emphasize up to 64-byte payloads and operation with separate arbitration/data bit rates; Vector’s technical overview summarizes J1939-17 and J1939-22 as the CAN FD physical and data-link layers, including example rates (500 kbit/s arbitration; 2 Mbit/s data).

Key protocol concepts: PGN, SPN, DM, and common conventions

PGN (Parameter Group Number).
A PGN is an 18-bit identifier embedded inside the 29-bit extended CAN ID; common explanations describe the identifier structure as: priority (3 bits), PGN field, and source address (8 bits), with the PGN further decomposed into Reserved, Data Page, PDU Format (PF), and PDU Specific (PS).

PDU1 vs PDU2 convention (destination-specific vs broadcast).

• If PF < 240 (PDU1), PS holds the destination address and the PGN’s PS field is treated as 0 when computing the PGN value; this is why destination-specific PGNs are often written with a “00” low byte (e.g., 0x00D400).
• If PF ≥ 240 (PDU2), the message is broadcast-like and PS extends the PGN definition space.

SPN (Suspect Parameter Number).
SPNs identify individual data parameters within a PGN payload; SAE’s J1939 Digital Annex is described as containing the catalog of SPNs and PGNs (and related metadata) that were previously distributed in the “top level” document.

DM (Diagnostic Message).
DMx messages are diagnostic parameter groups defined by J1939-73; an AUTOSAR J1939 diagnostic manager lists many DM messages with their PGN hex identifiers and whether they are cyclic or on request (e.g., DM01 FECA cyclic 1s; DM02 FECB on request; DM11 FED3 clear active).

Request / acknowledgements (foundational network services).

• Some regulatory and technical materials reference PGN 59904 (0x00EA00) for on-request transmission and PGN 59392 (0x00E800) for acknowledgement / negative acknowledgement behaviors.

Connector, ELD, and FMS relationships

J1939-13 diagnostic connector.
SAE J1939-13 specifies diagnostic connectors used for off-board connection to the vehicle’s J1939 communication links.

ELD interaction (engine synchronization data).
The Federal Motor Carrier Safety Administration ELD guidance emphasizes that an ELD must synchronize with the engine and automatically record key data elements such as engine hours and vehicle miles; it also defines “engine synchronization” diagnostic events tied to loss of ECM connectivity to required data sources (engine power status, vehicle motion status, miles driven, engine hours), including a five-second update expectation when needed.

FMS Standard (a J1939-based, fleet-facing subset).
The FMS Standard (published by an ACEA task force) defines a curated interface to vehicle data using SAE J1939 encodings, including PGNs, SPNs, repetition rates, and gateway behaviors. It emphasizes that an FMS gateway may indicate whether it responds to requests and whether it supports forwarding diagnostic requests; it also notes that the gateway does not rebroadcast diagnostic messages from the vehicle network by default (instead, it can forward responses to diagnostic requests if supported).

How J1939 Supports Fleet Management

J1939 improves fleet management by making vehicle-state telemetry and fault information consistently accessible and machine-interpretable across large sets of assets and ECUs. Practically, fleets benefit when they can (1) collect comparable metrics across vehicles, (2) detect anomalies/failures early, and (3) close the loop via driver coaching, maintenance scheduling, and operational control. FMS-style standardization is especially relevant for mixed fleets because it narrows variability by specifying common PGNs/SPNs and their update rates.

Real-time telemetry and remote monitoring

Many fleet-relevant J1939 parameters are broadcast at defined repetition rates suitable for near-real-time monitoring. The FMS Standard, for example, defines:

• Engine speed (SPN 190) carried in EEC1 (PGN 0x00F004) at 20 ms repetition.
• Wheel-based vehicle speed (SPN 84) in CCVS1 (PGN 0x00FEF1) at 100 ms repetition.
• Fuel rate (SPN 183) and instantaneous fuel economy (SPN 184) in LFE (PGN 0x00FEF2) at 100 ms repetition.
• Engine hours (SPN 247) in HOURS (PGN 0x00FEE5) at 1,000 ms repetition.

In remote monitoring architectures, these high-frequency broadcasts are rarely forwarded “as-is” over wide-area networks; instead, they are commonly sampled, aggregated, exception-triggered, or edge-processed to reduce bandwidth and storage costs. The fact that J1939 messages have standardized scaling and semantics (SPNs) enables defensible aggregation (e.g., “idle minutes,” “fuel per mile,” “hard-brake events”) with consistent definitions across assets—subject to OEM variability (discussed later).

Fuel, route, driver, and maintenance optimization

J1939 supports fuel and efficiency programs by providing the input signals needed to quantify and manage fuel-waste drivers:

• Idling and anti-idling controls: J1939 can provide engine speed, vehicle speed, and (depending on configuration) fuel rate to detect “engine-on, vehicle-stationary” conditions and quantify idle fuel burn. Separately, the U.S. Environmental Protection Agency estimates that a typical long-haul combination truck eliminating unnecessary idling could save over 900 gallons of fuel per year, illustrating the magnitude of idle reduction targets that telemetry-based monitoring can support.

• Fuel consumption measurement: The FMS Standard provides multiple fuel-totalization options, including total fuel used in LFC (PGN 0x00FEE9, SPN 250) and a high-resolution fuel totalization (PGN 0x00FD09, SPN 5054, when implemented). Such signals enable fuel accounting, fuel theft heuristics (in combination with geospatial context), and trend analytics.

• Driver behavior: Brake pedal position (SPN 521) is mapped in the FMS Standard to EBC1 (PGN 0x00F001), enabling derivation of “braking intensity” or “brake applications” when combined with speed signals.

• Maintenance optimization: J1939 fault messages (notably DM1) and sensor PGNs (temperatures, pressures) can drive condition-based maintenance triggers. The FMS Standard includes brake-air pressures (SPNs 1087/1088) as AIR1 (PGN 0x00FEAE) and coolant temperature (SPN 110) as ET1 (PGN 0x00FEEE). These are direct precursors to a maintenance triage pipeline: detect → validate via live values → classify severity → schedule service.

Data standardization and interoperability

Two standardization mechanisms matter in fleet contexts:

SAE definition standardization: J1939DA is described as the consolidated catalog of SPNs and PGNs, providing the canonical encoding definitions.

Industry subset standardization: The FMS Standard operationalizes interoperability by fixing a “fleet-facing” subset (PGNs/SPNs, update rates, and gateway behaviors). It explicitly describes capability signaling (e.g., whether requests are supported; whether diagnostic forwarding is supported) and constrains the gateway to not forward non-FMS requests onto the vehicle network.

Security and privacy implications

Classic J1939 inherits CAN’s low-latency broadcast design but also its security limitations. Educational and research materials characterize typical CAN/J1939 networks as lacking native encryption and authentication and being susceptible to bus flooding and other attacks. A peer-reviewed analysis of heavy-truck attack surfaces demonstrates practical risks of unauthorized message injection and other abuses on SAE J1939 networks.

From a privacy and labor perspective, driver monitoring can create legitimate concerns about misuse. FMCSA’s historical discussion of ELD regulation highlights statutory and judicial concerns about driver harassment risks from monitoring technologies, underscoring that telemetry programs need governance (policies, access controls, retention, and purpose limitation).

How J1939 Supports Single-Vehicle Diagnostics

J1939 diagnostics revolve around diagnostic messages (DMs), a standardized DTC format, and a set of sensor/actuator parameter groups that allow technicians (or remote diagnostic systems) to validate faults with live data.

DTC format and SPN/FMI decoding

A J1939 DTC typically encodes:

• SPN (Suspect Parameter Number): what/where (the parameter or subsystem associated with the fault),
• FMI (Failure Mode Identifier): how it failed (e.g., “data valid but above normal,” “open circuit,” “shorted low”—specific meaning depends on FMI tables),
• Occurrence count: how many times the fault has become active,
• SPN conversion method: indicates which SPN alignment/conversion method applies.

DM1 additionally carries lamp status bits (e.g., malfunction indicator, stop, warning, protect) to communicate severity/driver messaging.

DM1/DM2/DM3/DM11 and related diagnostic messages

The J1939 diagnostic ecosystem includes many DM messages. The AUTOSAR J1939 diagnostic manager’s supported-DM table is useful as a concise cross-reference of DM identifiers, their PGNs, and their expected behavior (cyclic vs on-request).

Diagnostic messages table

Uncertainty note (DM coverage): Different documents and implementations cover different subsets of DM messages. The AUTOSAR table above represents supported messages for that module, not an exhaustive list of all DMs in the full J1939-73 standard.

Parameter groups for “live data” validation

A practical diagnostic workflow rarely stops at “read DM1.” Fault isolation typically requires validating the alleged failing parameter and its context using sensor/operational PGNs. In fleet-focused deployments, common validation PGNs include:

• ET1 (PGN 0x00FEEE, SPN 110 coolant temp) for thermal faults.
• AIR1 (PGN 0x00FEAE, SPNs 1087/1088 air pressures) for braking-air faults.
• EEC1 (PGN 0x00F004, SPNs 190/513) for load/speed context.
• LFE (PGN 0x00FEF2, SPNs 183/184) for fuel-rate anomalies and efficiency context.

Diagnostic workflow flowchart (mermaid)

flowchart TD
  A[Connect to J1939 via diagnostic connector or gateway] --> B[Network initialization: confirm baud, observe traffic]
  B --> C[Identify ECUs: Address Claim / NAME mapping if needed]
  C --> D[Read DM1 broadcast (Active DTCs)]
  D --> E{Any active DTCs?}
  E -- No --> F[Optionally request DM2 (history) + baseline PGNs]
  E -- Yes --> G[Decode each DTC: SPN + FMI + Occurrence + Lamp severity]
  G --> H{Safety-critical? (Stop/Protect lamps, brake/steering, etc.)}
  H -- Yes --> I[Immediate triage: derate/stop guidance + dispatch service]
  H -- No --> J[Request supporting diagnostics: DM2/DM6/DM12/DM28 as applicable]
  J --> K[Request live sensor/operational PGNs related to SPN]
  K --> L[Validate: compare measured values vs plausible range/context]
  L --> M{Intermittent or persistent?}
  M -- Intermittent --> N[Correlate with operating conditions + trend monitoring]
  M -- Persistent --> O[Pinpoint likely causes (wiring/sensor/actuator/system)]
  O --> P[Plan repair: parts + labor + schedule]
  P --> Q[Post-repair verification: confirm SPN returns to normal, DM1 cleared]
  Q --> R[If allowed: DM3 clear history, DM11 clear active, verify no reappearance]

Key protocol services that enable this flow include:

• On-request reads (PGN 59904 / 0x00EA00) and acknowledgement/NACK behaviors (PGN 59392 / 0x00E800) used in many J1939 service-tool interactions.
• Transport Protocol (TP.CM/TP.DT) for variable-size DM payloads (e.g., multiple DTC entries).

Two concrete diagnostic sequence examples

Example A: Engine over-temperature investigation (coolant temp fault)

Scenario. Driver reports warning lamp; telematics receives a DM1 with an SPN consistent with engine coolant temperature (SPN 110) and an FMI indicating an abnormal-high condition (exact FMI varies by implementation). Coolant temperature is a common standardized parameter in ET1 (PGN 0x00FEEE).

Sequence.

1. Capture DM1 and record source address (ECU identity context). DM1 is a cyclic broadcast (about 1 Hz), so it should appear without an explicit request.
2. Decode the DTC: SPN=110 (coolant temperature), FMI=“above normal” type (interpret per FMI tables), occurrence count. Record any lamp state indicating severity.
3. Request or observe ET1 (PGN 0x00FEEE) to read SPN 110 in engineering units (FMS-defined scaling: 1 °C/bit, −40 °C offset). Confirm whether the temperature is currently high and whether it is stable or rising.
4. Pull operating context using EEC1 (PGN 0x00F004) for engine speed (SPN 190) and torque/load proxy (SPN 513), plus vehicle speed (SPN 84) if available via CCVS1. This helps distinguish high-load uphill overheating vs overheating at idle (fan/flow issues).
5. Check ambient influence via AMB (PGN 0x00FEF5, SPN 171 ambient air temperature) to determine whether environmental conditions explain higher-than-normal coolant temperatures.
6. Decision logic.
   • If coolant temperature remains high while load is low (e.g., idle/low torque), suspect cooling system performance (fan, thermostat, coolant level) rather than “expected thermal load.”
   • If temperature spikes correlate strongly with load and resolve quickly, suspect marginal capacity or intermittent airflow/flow restrictions.
7. Closeout. After repairs, verify that ET1 returns to normal under similar operating conditions and that DM1 no longer reports the DTC. If permitted by OEM policy and service procedures, clear previously active faults (DM3) and/or active diagnostic data (DM11) and confirm no reappearance.

Example B: Low brake-air pressure complaint (pneumatic service brake circuits)

Scenario. Vehicle reports a braking-system warning; DM1 includes DTCs referencing service brake air pressure circuits. The FMS Standard provides AIR1 (PGN 0x00FEAE) containing SPN 1087 (circuit #1) and SPN 1088 (circuit #2), each scaled at 8 kPa/bit.

Sequence.

1. Read DM1 and decode SPN/FMI and lamp status. Treat brake-related DTCs as high severity, especially if lamp indications suggest stop/protect behavior.
2. Read AIR1 (PGN 0x00FEAE) to obtain actual pressures for both circuits. Compare values to expected operating ranges for the vehicle type (range thresholds are application-specific and not standardized in the FMS excerpt).
3. Correlate with driver control input: use brake pedal position (SPN 521) from EBC1 (PGN 0x00F001) to determine whether pressure drops occur during pedal application (demand-driven) or during non-braking states (leak/charge issue).
4. Correlate with motion state via wheel-based speed (SPN 84 in CCVS1) to determine whether the event is occurring while moving vs at standstill (important for operational triage decisions).
5. Decision logic.
   • If both circuits show persistent low values independent of braking, suspect compressor/air supply or major leak.
   • If one circuit is low and the other normal, suspect circuit-specific leak or valve issue.
6. Dispatch and verification. Given safety risk, schedule immediate inspection/repair; post-repair, confirm AIR1 pressures recover and that DM1 no longer carries the relevant SPN/FMI DTC.

Measurable Accomplishments & Industry Impacts

Quantifying “J1939’s impact” directly is challenging because J1939 is usually an enabling layer: the measurable outcomes come from telematics, analytics, driver training, maintenance programs, and regulatory monitoring systems that rely on consistent vehicle data access. The most defensible quantified statements therefore tend to be of the form: program X achieved outcome Y, supported by telemetry/diagnostics signals—where J1939 often supplies the engine/fault portion of those signals in heavy-duty assets.

Efficiency and fuel impacts (examples)

• The EPA SmartWay program’s public reporting states that participating U.S. trucking companies have saved $55.4 billion on fuel costs and helped save 397 million barrels of oil since 2004—illustrating the scale of fleet efficiency initiatives when measurement and operational practices are institutionalized.
• EPA’s idle reduction guidance estimates that a typical long-haul combination truck eliminating unnecessary idling could save over 900 gallons of fuel annually, a key target variable that can be monitored with engine-state and motion-state telemetry often derived from J1939 signals (e.g., engine speed + vehicle speed + fuel rate if available).
• An ACEEE case study notes that Brown Trucking improved fuel economy from 5.7 mpg to 6.4 mpg and reduced idle fuel consumption by 35% after joining SmartWay and implementing strategies including driver training. While the case study does not attribute the change to J1939 specifically, the ability to measure and coach idle and driving behaviors is strongly coupled to reliable vehicle operational telemetry, which in heavy-duty contexts commonly leverages J1939.

Uptime and maintenance-cost impacts (examples)

• A widely cited McKinsey analysis on predictive maintenance (industrial context) reports typical reductions in machine downtime of 30–50% and increases in machine life of 20–40%. Translating these outcomes to fleets requires vehicle-specific models, but the mechanism—using condition data to anticipate failure—maps directly to the use of J1939 fault data (DM1/DM2) and live sensor data (temperatures/pressures) for early detection and maintenance scheduling.
• NREL’s fleet-operations telematics briefing (summarizing earlier quantified analyses) lists “potential per-vehicle cost savings from telematics” totaling $2,307 per vehicle per year, with line items for idling ($143), aggressive driving ($112), reduced vehicle miles traveled ($123), maintenance ($99), reporting ($312), and inventory optimization ($695). In heavy-duty settings, these savings categories depend heavily on consistent measures such as engine hours, miles, braking behavior, fuel/idle indicators, and fault data—data types commonly sourced from standardized vehicle networks such as J1939.

Safety and regulatory compliance impacts

• FMCSA describes the ELD rule as intended to improve safety and simplify accurate tracking and sharing of hours-of-service data, with ELDs synchronizing to vehicle engines to automatically record driving time. This operational requirement creates a practical “minimum telemetry set” (engine hours, miles driven, motion status) often obtained via vehicle-network data sources.
• California’s Heavy-Duty Inspection and Maintenance specifications for J1939-based remote OBD tools explicitly require that a J1939 device comply with J1939-21 and J1939-71 when connected to a J1939 vehicle; perform address claiming per J1939-81 (claiming diagnostic-tool addresses 249 or 250); send a global DM5 request; and confirm OBD compliance after receiving DM5 support responses. This provides a concrete example of how J1939 diagnostics are operationalized into regulatory inspection workflows.

Limitations, Challenges, and Future Directions

Bandwidth, scalability, and data volume

Classic J1939 deployments over CAN face intrinsic constraints: 8-byte payloads, finite bus bandwidth (commonly 250 or 500 kbit/s), and the need for transport protocol segmentation for larger messages. While TP supports up to 1,785 bytes in a transfer, frequent multi-packet messages can increase bus load and complicate logging—especially when multiple ECUs transmit high-rate signals such as 20 ms engine updates.

This matters operationally because fleets must decide:

• which PGNs to collect continuously vs on exception,
• whether to store raw frames vs decoded SPNs,
• how to compress or aggregate high-rate signals without losing diagnostic fidelity.

The FMS Standard’s explicit repetition rates (20 ms–10 s) illustrate how quickly raw traffic volumes can grow if logged naively.

CAN vs CAN FD migration

SAE’s CAN FD extensions (J1939-17 physical layer and J1939-22 FD data link layer) aim to address limited bandwidth by enabling higher data-phase bit rates and larger payloads (up to 64 bytes). However, FD migration introduces practical issues: mixed classic/FD compatibility strategies, toolchain updates, and new segmentation/transport patterns; some technical commentary also notes that envisioned backward compatibility is not always straightforward in real implementations.

Cybersecurity exposure and evolving defenses

J1939’s broadcast control model and lack of native authentication/encryption make it susceptible to spoofing, replay, and denial-of-service attacks. Security research on heavy vehicles highlights these risks in realistic adversarial settings.

J1939-73 includes DM18 (Data Security) as a mechanism to send security entities used in cryptographic procedures, and academic security work discusses DM18 as part of approaches to securing traffic on J1939 networks. Nonetheless, the existence of DM18 does not imply uniform adoption across OEMs or fleets; security depends on end-to-end architectures (key management, secure gateways, secure diagnostic access).

Integration with telematics/IoT systems and OEM variability

Three integration challenges dominate real deployments:

1. OEM variability and proprietary content. Even with standard PGNs/SPNs, OEMs may implement proprietary PGNs, optional fields, or differing gateway policies. The FMS Standard is a mitigation strategy, but it is still a subset and includes explicit statements that some interpretations are manufacturer dependent (e.g., tell-tale semantics).

2. Gateway policy constraints. FMS gateways may restrict which requests are forwarded to the vehicle network and may not rebroadcast diagnostic messages by default, requiring explicit request/response handling for diagnostics.

3. Regulatory and human-factor constraints. Monitoring systems (e.g., ELDs) must meet regulatory rules and address privacy/harassment concerns; this shapes what data can be collected, how it is used, and what safeguards are necessary.

Assumptions & Scope Notes

• Fleet size: no specific constraint (analysis applies from small to very large fleets).
• Vehicle types: no specific constraint; discussion emphasizes heavy-duty on-highway and commercial/off-highway patterns consistent with SAE J1939 usage and FMS/ELD/HD-OBD contexts.
• Telematics architecture (edge device, cloud stack, data lake, dispatch tooling): no specific constraint; impacts are described as architecture-agnostic patterns.
• Access to SAE standards: many SAE documents are paywalled; where full text was not accessible, the report relies on official SAE document descriptions and on accessible standards-adjacent materials (e.g., AUTOSAR specs referencing SAE requirements, regulatory specifications referencing SAE procedures, and FMS Standard documentation).
• PGN/DM identifiers: PGN values are provided in the common “0x00XXXX” format; for PDU1 messages, PGN PS=0 conventions are used (e.g., DM18 PGN 0x00D400). Where different documents use shortened forms (e.g., “FECA” for 0x00FECA), they refer to the same PGN.

References

SAE and closely related official sources

• SAE International. SAE J1939DA—J1939 Digital Annex (various revisions; description pages indicating J1939DA contains SPNs/PGNs and related data).
• SAE International. SAE J1939-11—Physical Layer, 250 kbit/s, Twisted Shielded Pair(description page).
• SAE International. SAE J1939-14—Physical Layer, 500 kbit/s (description pages).
• SAE International. SAE J1939-15—Physical Layer, 250 kbit/s, Unshielded Twisted Pair (UTP) (description page).
• SAE International. SAE J1939-17—CAN FD Physical Layer, 500 kbit/s / 2 Mbit/s(description page).
• SAE International. SAE J1939-22—CAN FD Data Link Layer (description pages for J1939-22).
• SAE International. SAE J1939-13—Off-Board Diagnostic Connector (description page).
• SAE International. SAE J1939-73—Application Layer—Diagnostics (description page).
• SAE International. SAE J1939-82—Compliance / SAE J1939 Network Compliance(description pages).
• SAE StandardsWorks. J1939-73 Diagnostics Task Force (committee page describing DM usage during repair and operation).

Industry subset / interoperability documentation

• European Automobile Manufacturers’ Association Task Force HDEI/BCEI. FMS-Standard description, Version 04 (17.09.2021) (PGNs, SPNs, update rates, gateway capabilities, diagnostic forwarding constraints).

AUTOSAR

• AUTOSAR. Specification of a Diagnostic Communication Manager for SAE J1939 (AUTOSAR CP) (references DM messages, J1939-73 behavior, and lists supported DM/PGN identities).

Regulatory / government sources

• Federal Motor Carrier Safety Administration. ELD Functions (required recorded data elements including engine hours and vehicle miles).
• FMCSA. ELD Technical Specifications FAQs (engine synchronization data diagnostic events and malfunctions; five-second update expectation).
• FMCSA. Electronic Logging Devices (ELD rule intent; engine synchronization concept).
• California Air Resources Board. California Standards for Heavy-Duty On-Board Diagnostic (HD OBD) Inspection and Maintenance / HD-IM—ROBD tool specifications (J1939 device requirements: compliance with J1939-21/-71, address claim per J1939-81, DM5 request, connector/baud expectations).
• U.S. Environmental Protection Agency. SmartWay Idle Reduction (fuel savings estimate for reducing idling).
• EPA. SmartWay Program Successes (aggregate fuel cost savings, barrels of oil saved).

Peer-reviewed security and technical research

• Burakova, Y., et al. Truck Hacking: An Experimental Analysis of the SAE J1939 Standard(USENIX WOOT 2016).
• Daily, J., et al. Securing CAN Traffic on J1939 Networks (NDSS AutoSec 2021).
• Kumar, S., et al. Cybersecurity Vulnerabilities for Off-Board Commercial Vehicle Diagnostics (2023 technical paper referencing DM18/PGN 54272).

Fleet/telematics quantified impacts

• National Renewable Energy Laboratory. Kotz, E. Optimizing Fleet Operations With Telematics (2026; includes quantified per-vehicle telematics savings table and summarized case-study metrics).
• McKinsey & Company. Manufacturing analytics unleashes productivity and profitability(2017; predictive maintenance downtime and asset-life ranges).
• American Council for an Energy-Efficient Economy. EPA’s SmartWay Program: Partnering with Freight to Reduce Greenhouse Gases and Improve Air Quality (2017; Brown Trucking mpg and idle fuel reduction example).

Standards/technical conventions references used for PGN/TP explanations

• UNECE WP.29 reference document noting J1939 request/acknowledgement parameter groups (PGN 59904 request; PGN 59392 NACK/ACK context).
• Vector Informatik. SAE J1939 Know-how / SAE J1939 with CAN FD (overview of J1939 over CAN and CAN FD; illustrative bit-rate statements).