Attachment B
State of California
California Air Resources Board
California Standards for Heavy-Duty Remote On-Board
Diagnostic Devices
Adopted: August 22, 2022
NOTE: This document is incorporated by reference in sections 2195 through 2199,
Title 13, California Code of Regulations and is being adopted with this rulemaking, the
proposed text is shown without underline for ease of readability. It contains the device
specifications and certification requirements necessary for the implementation of
vehicle compliance testing for OBD-equipped heavy-duty vehicles as part of the
California’s Heavy-duty Inspection and Maintenance Program. On page 19, Table 4,
item 16 references 13 CCR 1971.1 (h)(4.12), which is from the proposed revisions to
the On-board Diagnostic system requirements and associated enforcement provisions
for passenger cars, light-duty trucks, medium-duty vehicles and engines, and heavy-
duty engines, that was approved by the Board on July 22, 2021, as part of the heavy-
duty OBD and OBD II rulemaking, but which has not yet been approved by the Office
of Administrative Law.
PART I: Definitions.
For the purposes of this document, the following definitions shall apply:
“Authorized representative” means a person who takes responsibility for all the
information submitted for remote on-board diagnostic (ROBD) device certification and
who signs the device certification application.
“Baud rate” means the rate at which data is transmitted on a vehicle internal
communications network.
“Certification” means the process of obtaining an Executive Order with respect to an
ROBD device, complying with the device certification requirements specified in Part III
of this document.
“Controller Area Network (CAN bus)” is an International Organization for
Standardization (ISO) standard (ISO 11898) for vehicle internal communications system
(i.e., bus), designed to allow onboard controllers and external devices to communicate
with one another.
“Device model” means a grouping of similar ROBD devices made by one
manufacturer, vendor, or service provider (e.g., CC-ROBD), that are applicable to the
same vehicle makes and models, and OBD protocol(s).
“Device serial number” means a device unique serial number that the vendor
permanently assigned to a ROBD device.
“DM5” is a standardized diagnostic message in the SAE J1939 onboard diagnostics
communication protocol that reports information related to the diagnostics readiness
of vehicle’s onboard diagnostics system, as defined by parameter definition 5.7.5 of
SAE J1939-73 “Application Layer – Diagnostics”, June 2020.
“DM24” is a standardized diagnostic message in the SAE J1939 onboard diagnostics
communication protocol that reports detailed information about the data supported
by vehicle’s OBD system, as defined by parameter definition 5.7.24 of SAE J1939-73
“Application Layer – Diagnostics”, June 2020.
“Electronic Control Unit (ECU),” also known as electronic control module, is
responsible for controlling one or multiple electrical system(s) in a vehicle.
“InfoType” means the vehicle-specific vehicle information available via Mode $09, as
defined by parameter definition 8.9 of SAE J1979 “E/E Diagnostic Test Modes”,
February 2017.
“Mode $06” also known as “Service $06” is the SAE J1979 service that allows access
to the results of the on-board diagnostic monitoring tests for specific components and
B-1
systems, as defined by parameter definition 8.6 of SAE J1979 “E/E Diagnostic Test
Modes”, February 2017.
“Mode $09” also known as “Service $09” is the SAE J1979 service that provides
vehicle-specific information (e.g., Vehicle Identification Number, Engine Serial
Number), as defined by parameter definition 8.9 of SAE J1979 “E/E Diagnostic Test
Modes”, February 2017.
“Monitor ID” identifies an individual diagnostic test for a Mode $06
component/system, as defined by parameter definition 8.6 of SAE J1979 “E/E
Diagnostic Test Modes”, February 2017.
“OBD data test vehicle” means a vehicle that is used for purposes of testing a
potential ROBD device during the certification process.
“OBD protocol group” means the vehicle’s OBD communication protocol such as SAE
J1939, SAE J1979, or SAE J1979-2.
“Original purchaser” means the first person who purchases and uses a new ROBD
device.
“Owner’s manual” means a document or collection of documents prepared by the
manufacturer of a product for the owners or operators to describe appropriate
maintenance, applicable warranties, and similar information related to operating or
keeping the product. The owner’s manual is typically provided to the original
purchaser at the time of sale. The owner’s manual may be in paper or electronic
format.
“Standardized data link connector” means an OBD device connector incorporated in
each heavy-duty vehicle according to the specifications in section h(2) of the CARB
heavy-duty OBD regulation (section 1971.1, title 13, CCR).
PART II: Device Requirements.
A. Purpose
1. The purpose of Part II is to establish CARB’s requirements for remote OBD
devices in order to be used by OBD-equipped heavy-duty vehicles as a
means of demonstrating compliance with the HD I/M Regulation.
B. Reference Documents: The following sections of the California Code of
Regulations (CCR) are incorporated into this regulation:
1. Section 1968.2, title 13, CCR, “Malfunction and Diagnostic System
Requirements--2004 and Subsequent Model-Year Passenger Cars, Light-
Duty Trucks, and Medium-Duty Vehicles and Engines”, as last amended
October 3, 2019; and
B-2
2. Section 1971.1, title 13, CCR, “On-Board Diagnostic System Requirements -
2010 and Subsequent Model-Year Heavy-Duty Engines”, as last amended
October 3, 2019.
C. Documents Incorporated by Reference: The following documents are
incorporated by reference into this regulation:
1. Section 86.010-18, title 40, Code of Federal Regulations, “On-board
Diagnostics for engines used in applications greater than 14,000 pounds
GVWR”, 2009;
2. ISO 11898-1 “Road vehicles – Controller area network (CAN) – Part 1: Data
link layer and physical signaling”, 2015;
3. ISO 11898-2 “Road vehicles – Controller area network (CAN) – Part 2: High-
speed medium access unit”, 2016;
4. ISO 15031-4 “Road vehicles — Communication between vehicle and
external equipment for emissions-related diagnostics — Part 4: External test
equipment”, 2014;
5. SAE J1699-2 “Test Cases for OBD-II Scan Tools and I/M Test Equipment”,
2017;
6. SAE J1962 "Diagnostic Connector”, July 2016;
7. SAE J1978 "OBD II Scan Tool – Equivalent to ISO/DIS 15031-4", April 2002;
8. SAE J1979 "E/E Diagnostic Test Modes", February 2017;
9. SAE J1979-DA “Digital Annex of E/E Diagnostic Test Modes”, May 2019;
10. ISO 15765-4 "Road Vehicles-Diagnostics Communication over Controller
Area Network (DoCAN) - Part 4: Requirements for emission-related
systems", April 2021;
11. SAE J1939 “Recommended Practice for a Serial Control and
Communications Heavy Duty Vehicle Network – Top Level Document”,
August 2018;
12. SAE J1939-DA “Digital Annex of Serial Control and Communication Heavy
Duty Vehicle Network Data,” March 2020;
13. SAE J1939-3 “On Board Diagnostics Implementation Guide”, 2015;
14. SAE J1939-13 “Off-Board Diagnostic Connector”, October 2016;
15. SAE J1939-21 “Data Link Layer”, October 2018;
B-3
16. SAE J1939-73 “Application Layer – Diagnostics”, June 2019;
17. SAE J1939-81 “Network Management”, March 2017;
18. SAE J3005-1 “Permanently or Semi-Permanently Installed Diagnostic
Communication Devices”, February 2019;
19. SAE J3005-2 “Permanently or Semi-Permanently Installed Diagnostic
Communication Devices, Security Guidelines”, March 2020;
20. SAE J1979-2 “E/E Diagnostic Test Modes: OBDonUDS”, April 2021.
D. General Device Requirements.
1. The ROBD device shall not interfere with the normal operation of the vehicle
or any manufacturer- or third party-installed device in communication with
the vehicle’s OBD system.
2. Any ROBD device used for compliance purposes shall be capable of
performing the following tasks as further specified in the requirements
provided in section E of this Part.
2.1. Establishing connection with the vehicle and verifying vehicle’s
support of OBD at the individual ECU level;
2.2. Collecting the OBD data required to be submitted as part of the HD
I/M Regulation specified in this Part; and
2.3. Submitting data securely via the standardized data submission format
to the electronic reporting system.
3. The ROBD device shall request data from the onboard ECUs indicating OBD
support, as specified in subsection E.2 of this Part.
4. The ROBD device shall timestamp each sent request and received response
from the CAN bus in the submitted data file, as specified in subsection E.4
of this Part.
5. The ROBD device shall be capable of receiving multiple responses when
requesting information (either multiple controllers responding to a request
or a controller responding multiple times to a request).
6. The ROBD device shall support at least one OBD protocol, however it may
support multiple OBD protocols.
7. The ROBD device shall support at least one heavy-duty engine model,
however it may support multiple heavy-duty engine or vehicle models.
B-4
8. The ROBD device shall be functional in standard working and vehicle
environments and thus be resistant to shock, vibration, and environmental
exposure.
9. The ROBD device shall be tamper-resistant to make sure no alteration or
erasure can be made on the data collected.
10. The ROBD device shall have a device unique serial number that is affixed,
engraved, or stamped in a legible manner. This unique serial number shall
be displayed externally and shall match the device’s electronic unique serial
number.
11. The vendor shall warrant to the purchaser and each subsequent purchaser
that the device is designed and built free from defects in materials and
workmanship. Further, the vendor shall ensure that the devices sold for this
program shall be identical in all material respects to the part as described in
the application for device certification for a minimum of one (1) year from
the date of delivery. If a subsequent purchaser obtains the device prior to
the end of the warranty period, the warranty shall extend to the new
purchaser through the required one-year period.
12. The vendor shall ensure proper and functioning communication between the
ROBD device and the electronic reporting system.
13. Broken ROBD devices no longer meeting the requirements of this Appendix
shall not be allowed to submit vehicle compliance data to the electronic
reporting system.
E. Specific Device Requirements.
This section provides detailed specifications for ROBD devices that meet CARB HD
I/M Regulation requirements. The specifications apply to both CC-ROBD and NCC-
ROBD devices, unless indicated otherwise.
1. Diagnostics Connector.
1.1. The ROBD device shall be compliant with SAE J3005-1, J3005-2, and
ISO 15765-4.
1.2. Plug-in ROBD devices (i.e., NCC-ROBD and semi-permanently CC-
ROBD device) developed to meet both SAE J1939, SAE J1979, or
SAE J1979-2 OBD protocols, whichever applicable, shall be capable
of mating to both the connectors defined in SAE J1962/ISO 15031-3
and SAE J1939-13.
1.3. All plug-in ROBD devices shall be capable of connecting to
the standardized data link connector, as specified in subsection E.1.2
B-5
of this Part, as an alternative to any other type of connection that may
be used as the primary connection option.
1.4. The SAE J1979, or SAE J1979-2 ROBD device, whichever applicable,
shall meet the specified requirements in ISO 15765-4 for CAN on
heavy-duty vehicles using these protocols.
1.5. The ROBD device shall meet the same requirements for baud rate, as
specified for the standard OBD connector, in section (h)(2) of CARB
HD OBD regulation (Section 1971.1, Title 13, CCR).
1.6. The J1939 ROBD device shall meet the requirements and guidelines
in SAE J1939-3 for the implementation of OBD on heavy-duty
vehicles using this protocol.
2. Communication with the Vehicle.
2.1. SAE J1939 device.
2.1.1. The ROBD device shall comply with SAE J1939-21 and SAE
J1939-71 when connected to a SAE J1939 vehicle.
2.1.2. The ROBD device shall meet all the requirements in section 4,
SAE J1939-3.
2.1.3. The ROBD device shall act as a client for diagnostics services
provided by the vehicle network, including those specified in
Table 1, SAE J1939-73.
2.1.4. The ROBD device initialization shall be performed prior to
requesting diagnostic services from any ECU. Failure to
complete any of the steps in 2.1.4.1 to 2.1.4.3 shall be defined
as an initialization failure.
2.1.4.1. Address claim: The ROBD device shall meet address
claim and dynamic addressing requirements in SAE
J1939-81. The ROBD device shall only claim address
249 or address 250.
2.1.4.2. Verifying OBD compliance: The ROBD device shall
send a global DM5 request as outlined in SAE J1939-
3.
2.1.4.3. The ROBD device shall confirm OBD compliance (i.e.,
at least one of the vehicle’s onboard ECUs supports
CARB's, U.S. EPA’s (title 40, CFR, section 86.010-18),
or equivalent OBD requirements) after successful
B-6
completion of the address claim process and
receiving DM5 support response(s) from one or more
onboard ECUs.
2.1.5. Identifying the available data: The ROBD device shall send
destination-specific requests for DM24 to all OBD compliant
ECUs identified, as described in subsection E.2.1.4.3 of this
Part and record all the received responses.
2.1.5.1. As described in SAE J1939-71, the ROBD device
shall refrain from requesting data that is routinely
broadcast on the network.
2.2. SAE J1979 device.
2.2.1. The ROBD device shall be compliant with SAE J1979.
2.2.2. The ROBD device shall communicate with the vehicle OBD
system using the signaling standard, and meeting the timing
requirements, of ISO 15765-4.
2.2.3. The ROBD device shall meet the standardized communication
requirements for scan devices as illustrated in SAE J1699-2.
2.2.4. The ROBD device shall meet the requirements in SAE
J1978/ISO 15031-4 and SAE 1699/2 to avoid disturbing the
in-vehicle communication.
2.2.5. The ROBD device shall meet the requirements in SAE J3005-1
and J3005-2.
2.2.6. The ROBD device shall utilize the initialization sequence of
ISO 15765-4 in order to establish communication before
sending diagnostic requests.
2.2.7. Identifying the available data: The ROBD device shall record
all responses, including CAN source (i.e., specific ECU), to
Parameter ID (PID) availability requests in Mode $01 sent
during initialization
2.2.8. The ROBD device shall conduct an analogous scan for
available Monitor IDs (MIDs) in Mode $06.
2.2.9. The ROBD device shall conduct an analogous scan for
available InfoTypes in Mode $09.
2.3. SAE J1979-2 device.
B-7
2.3.1. The ROBD device shall be compliant with SAE J1979-2.
2.3.2. The ROBD device shall communicate with the vehicle OBD
system using the signaling standard, and meeting the timing
requirements, of ISO 15765-4.
2.3.3. The ROBD device shall meet the standardized communication
requirements for scan devices as illustrated in SAE J1699-2 or
later version, whichever is applicable for vehicles using SAE
J1979-2.
2.3.4. The ROBD device shall meet the requirements in SAE
J1978/ISO 15031-4 and SAE 1699-2 for vehicles using SAE
J1979-2, to avoid disturbing the in-vehicle communication.
2.3.5. The ROBD device shall meet the requirements in SAE J3005-1
and J3005-2.
2.3.6. The ROBD device shall utilize the initialization sequence of
ISO 15765-4 in order to establish communication before
sending diagnostic requests.
2.3.7. Identifying the available data: The ROBD device shall record
all responses, including CAN source (i.e., specific ECU), to
Service $22 Parameter ID (PID) availability requests sent
during initialization.
2.3.8. The ROBD device shall conduct an analogous scan for
supported monitor test results using Service $19, subfunction
1A.
2.4. The ROBD device shall not communicate with the CAN Bus while the
device is loading, initializing the operating system, or undergoing
firmware or software updates.
2.5. In the case of failed initialization (i.e., vehicle not responding to the
ROBD device within the required duration), the ROBD device shall
repeat the initialization sequence, up to three times.
2.5.1. The ROBD device shall meet the response time requirements
as outlined in SAE J1939-21 and SAE J1979 or SAE J1979-2,
as applicable.
2.5.2. After the third failed initialization attempt, the vendor shall
notify the vehicle owner of the failed communication between
the ROBD device and the vehicle.
B-8
2.5.3. The ROBD device shall submit a “Failed Communication”
message to the electronic reporting system.
2.6. In the case of a vehicle not supporting the relevant OBD requirement
following an initialization sequence, the ROBD device shall repeat the
initialization sequence, up to three times.
2.6.1. If all initialization attempts confirm the initial results, the
vendor shall notify the vehicle owner, as specified in
subsection E.2.5.2 of this Part.
2.6.2. The ROBD device shall submit a “Vehicle not OBD compliant”
message to the electronic reporting system.
3. Collecting the Required OBD Data from the Vehicle.
3.1. The ROBD device shall be capable of collecting all the data, as
specified in sections (h)(4) and (h)(5) of the CARB heavy-duty OBD
regulation (section 1971.1, title 13, CCR) (see Table 4 in subsection
E.6 of this Part for more detail).
3.2. The CC-ROBD device shall collect data, as specified in subsection
E.3.1 of this Part, once every 7 days or at the first engine key ON past
the 7th day, as separate data logs.
3.3. The CC-ROBD device shall collect data only when the vehicle is
stationary and in key ON, engine running status.
4. Formatting the Collected OBD Data. The ROBD device shall meet the
following data format specification for submitting the collected data.
4.1. File Structure. The file shall consist of two sections: the data header,
and the CAN Bus data in hexadecimal format.
4.1.1. Data Header. The data header shall be in ASCII text format
and contain the fields listed in Table 1.
Table 1: Contents of the header section of the submission file
Data Field Name Description of Data
Data Type
(length)
VIN
Vehicle identification number located on
the tested vehicle in CARB-specified
format
String (17)
B-9
SAE Protocol
Vehicle’s OBD communication protocol
(SAE J1939/J1979/J1979-2)
String (10)
Odometer*
Odometer reading of the vehicle at the
time the OBD data is downloaded from
the vehicle OBD system (required if
supported)
Integer (7)
Engine Total
Runtime
Accumulated engine runtime over the
lifetime of the vehicle, as specified in
subsection h(5.2.1.A) of the CARB HD
OBD regulation (section 1971.1, title 13,
CCR)
Integer (10)
Device Name
The model of the ROBD device
String (50)
Device
Manufacturer
Name of the ROBD device manufacturer
String (50)
Device Serial
Number
The serial number of the ROBD device
assigned by the vendor
String (50)
Device Firmware
Number
The firmware/version number of the
software in the ROBD device
String (20)
Firmware
Verification
Number
A number derived from
the ROBD device firmware that verifies
the firmware has not been altered
String (20)
Record ID
A unique value from an ascending
numerical sequence assigned by the
ROBD device to each submission
Integer (7)
Data Collection
Date and Time
The timestamp at the
time the ROBD device starts
downloading
OBD data from the vehicle OBD
system. The timestamp is in coordinated
universal time (UTC) and in the format
of YYYY-MM-DD hh:mm:ss.mmm.
Datetime
* PID $7F for SAE J1979, PID $F47F for J1979-2. See SAE
J1939DA for PGNs and SPNs.
B-10
4.1.2. CAN Bus Data.
4.1.2.1. The J1979 or J1979-2, as applicable, ROBD device
shall follow the formatting specification in Table 2 for
the CAN Bus data section of the submission file.
4.1.2.2. The J1939 ROBD device shall follow the formatting
specification in Table 3 for the CAN Bus data section
of the submission file.
Table 2: CAN Bus data formatting requirements for the J1979 or J1979-2, as
applicable, ROBD device
Data Field
Name
Description of Data
Data Type
(length)
Timestamp
the ROBD device to the vehicle or received from
the vehicle. The timestamp is in UTC and has
millisecond precision. The timestamp is in the
format of YYYY-MM-DD hh:mm:ss.mmm.
Datetime
Message Type The message type of the data line indicates if the
message was sent from the OBD device to the
vehicle or received from the vehicle.
"REQ" is the request messages sending to the
vehicle, and "RSP" is the response messages
received from the vehicle.
String (3)
ECU Address
ECUs that respond to the request. The REQ
messages will not have an ECU
address. The RSP messages will have the
hexadecimal address of the responding ECUs.
String (15)
Message
Data
received from the vehicle's OBD system. The
data shall be ASCII text that represents the
hexadecimal values.
String
B-11
Table 3: CAN Bus data formatting requirements for the J1939 ROBD tool
Data Field
Name
Description of Data
Data Type
(length)
Timestamp
The time that a message is sent from the
ROBD device to the vehicle or received from the
vehicle. The timestamp is in UTC and has
millisecond precision. The timestamp is in the
format of YYYY-MM-DD hh:mm:ss.mmm.
Datetime
Message Type
The message type of the data line indicates if the
message was sent from the ROBD device to the
vehicle or received from the vehicle. "REQ" is the
request messages sending to the vehicle, and
"RSP" is the response messages received from the
vehicle.
String (3)
CAN ID
CAN ID
String (15)
Message Data
The data portion of the CAN message sent to or
received from the vehicle's OBD system. The data
shall be ASCII text that represents the
hexadecimal values.
String
5. Transmitting the Collected Data to the CARB Electronic Reporting System.
5.1. Connection and Authentication: The vendor shall register the ROBD
device in the electronic reporting system as a valid testing device in
order to receive authentication to submit data as part of the HD I/M
Regulation.
5.2. All OBD data submissions to CARB must emanate from a centralized
database maintained by the vendor.
5.3. Data Integrity and Transmission.
5.3.1. Subsequent to formatting the collected data, as specified in
subsection E.4 of this Part, the ROBD device shall encrypt the
data file.
5.3.2. The data shall not be altered or tampered with during or prior
to electronically submitting to the electronic reporting system.
B-12
5.3.3. The data file shall be transmitted securely from the ROBD
device to the electronic reporting system once available.
5.3.4. The CC-ROBD device shall transmit at least one and up to the
15 most recent unsubmitted data logs collected when
submitting to the electronic reporting system.
5.4. Data Storage.
5.4.1. The ROBD device shall have enough internal storage capacity
to store, at minimum, 15 encrypted data files that have not
been submitted.
5.4.2. The collected OBD data shall be retained securely for at least
seven days following a successful submission to the electronic
reporting system.
6. Data Fields.
6.1. Table 4 specifies the OBD data required to be collected by a ROBD
device.
B-13
Table 4: Specifications of the OBD data required to be collected by a ROBD device
Item
Data Type
Corresponding
Section in CARB
HD OBD
Diagnostic
Message(s) in
SAE J1939
Diagnostic
Message(s) in
SAE J1979
Diagnostic
Message(s) in
SAE J1979-2
Comments
Regulation (CCR
Title 13, Section
1971.1)
OBD Protocol OBD Protocol OBD Protocol
1
Readiness
status of all
(h)(4.1)
DM5
Mode $01 PID
$01
Service $22 DID
$F501
OBD monitors
listed in
sections (e)
and (g) of the
heavy-duty
OBD
Regulation
2
All data
stream
parameters
(h)(4.2.2)
(h)(4.2.3)
See SAE
J1939DA for
PGNs and
SPNs (include
DM21, DM26,
and DM34)
Mode $01, see
SAE J1979DA
for PIDs
Service $22, see
SAE J1979DA for
$F400 - $F5FF
DIDs
B-14
Item
Data Type
Corresponding
Section in CARB
HD OBD
Regulation (CCR
Title 13, Section
1971.1)
Diagnostic
Message(s) in
SAE J1939
OBD Protocol
Diagnostic
Message(s) in
SAE J1979
OBD Protocol
Diagnostic
Message(s) in
SAE J1979-2
OBD Protocol
Comments
3
Freeze frame
data
(h)(4.3)
DM25
Mode $02
Service $19 $04
DTCMREC
DTC Snapshot
Record Number
= $00 (first
occurrence)
or $F0 (latest
occurrence)
DM24 is
necessary to
interpret
DM25 data.
4
Fault codes
(h)(4.4)
DM1, DM6,
Modes $03,
Service $19 $42
The union of
including DM12, DM23, $07, $0A $33 $08 $02, fault codes
active,
pending, and
permanent
DM28, DM29 Service $19 $42
$33 $04 $02,
Service $19 $55
$33
returned by
DM12 and
DM23 meet
the J1979
definition for
confirmed
fault codes.
B-15
Item
Data Type
Corresponding
Section in CARB
HD OBD
Regulation (CCR
Title 13, Section
1971.1)
Diagnostic
Message(s) in
SAE J1939
OBD Protocol
Diagnostic
Message(s) in
SAE J1979
OBD Protocol
Diagnostic
Message(s) in
SAE J1979-2
OBD Protocol
Comments
5
Test results
(h)(4.5)
DM30
Mode $06
Service $19 $06
DTCMREC $92
Use DM24 to
create ECU-
specific list of
supported
SPNs for test
results. Use
DM7 with a
Test ID value
of 247 and
Failure Mode
Indicator of
31 to obtain
test results
(DM30
responses)
for SPNs
listed in
DM24.
6
Software
calibration ID
(Cal-ID)
(h)(4.6)
(h)(4.7)
DM19
Mode $09
InfoType $04
Service $22
InfoType $F804
B-16
Item
Data Type
Corresponding
Section in CARB
HD OBD
Regulation (CCR
Title 13, Section
1971.1)
Diagnostic
Message(s) in
SAE J1939
OBD Protocol
Diagnostic
Message(s) in
SAE J1979
OBD Protocol
Diagnostic
Message(s) in
SAE J1979-2
OBD Protocol
Comments
7
Calibration
(h)(4.6)
DM19
Mode$09
Service $22
Verification
Number
(CVN)
(h)(4.7) InfoType $06 InfoType $F806
8
VIN
(h)(4.8)
PGN: 65260
SPN: 237
Mode$09
InfoType $02
Service $22
InfoType $F802
9
Engine serial
number
(h)(4.8)
PGN: 65259
SPN: 588
Mode $09
InfoType $0D
Service $22
InfoType $F80D
10
Engine family
(h)(4.2)
DM56
Mode $09
InfoType $13
Mode $09
InfoType $F813
Applies to
2024 and
subsequent
model year
engines
11
ECU name
(h)(4.9)
PGN: 60928
SPN:2848
Mode $09
InfoType $0A
Service $22
InfoType $F80A
12
Monitor in-use
performance
ratio
(h)(5.1)
DM20
Mode $09
InfoType $0B
Service $19 $06
DTCMREC $91
13
Engine run
time tracking
data
(h)(5.2)
See SAE
J1939DA for
PGNs and
SPNs
Mode $01, see
SAE J1979DA
for PIDs
Service $22, see
SAE J1979DA for
DIDs
B-17
Item
Data Type
Corresponding
Section in CARB
HD OBD
Regulation (CCR
Title 13, Section
1971.1)
Diagnostic
Message(s) in
SAE J1939
OBD Protocol
Diagnostic
Message(s) in
SAE J1979
OBD Protocol
Diagnostic
Message(s) in
SAE J1979-2
OBD Protocol
Comments
14
NOx
emissions
tracking data
(h)(5.3)
PGNs: 64258
thru 64279
Mode $09
InfoTypes $61 -
$76
Service $22
InfoTypes $F861 -
$F876
Applies to all
OBD systems
in 2022 and
subsequent
model year
diesel
engines
15
GHG tracking
data
(h)(5.4) thru
(h)(5.6)
PGNs: 64252
thru 64257
Mode $09
InfoTypes $41 -
$49, $50 - $5B
Service $22
InfoTypes $F841 -
$F849, $F850 -
$F85B
Applies to all
OBD systems
in 2022 and
subsequent
model year
diesel
engines
16
PM filter
regeneration
event data
(h)(5.8)
See SAE
J1939DA for
PGNs and
SPNs
Mode $01
PID $8B
Service $22 DID
$F48B
Applies to
2024 and
subsequent
model year
engines
B-18
Item
Data Type
Corresponding
Section in CARB
HD OBD
Regulation (CCR
Title 13, Section
1971.1)
Diagnostic
Message(s) in
SAE J1939
OBD Protocol
Diagnostic
Message(s) in
SAE J1979
OBD Protocol
Diagnostic
Message(s) in
SAE J1979-2
OBD Protocol
Comments
17
Readiness
status of each
monitor within
a readiness
group
N/A
N/A
N/A
Service $19 $56
$33 RGID
Data
available for
every OBD
monitor tied
to a
readiness
group
B-19
Part III: Requirements for Vendors.
A. Overview and Applicability.
The Executive Officer shall certify devices and provide an Executive Order for the
device to the vendor if the vendor meets the requirements specified in this appendix.
A vendor submitting a device for certification shall submit the full, complete, and
current configuration proposed for sale and consumer use and have design control of
the device.
B. Certification Application.
1. Prior to submitting a certification application, a vendor shall submit a test plan
detailing the vendor initial validation testing methodology described in subsection
C.1 of this Part. Prior to conducting testing, the vendor shall ensure the test plan is
approved by the Executive Officer.
2. A vendor shall complete and submit device certification application forms
approved by the Executive Officer and other required information for evaluation of
the application. Applications shall be submitted during a one (1) month open
collection period per year, as designated by Executive Officer.
2.1. All information included as part of an application package shall be
true, accurate, and include complete statements and information. The
application package shall not omit information relevant to the
requirements specified in this appendix.
2.2. An authorized representative of the company shall attest to the
information included in the application and approve and sign the
application.
2.3. The application shall include the following information and shall be
approved by the Executive Officer prior to CARB staff performing any
verification testing specified in subsection C.2 of this Part:
2.3.1. A detailed description of the design of the device and how
the device is consistent with and meets the requirements
specified in Part II of this document.
2.3.2. Device manufacturer, if vendor is not the manufacturer of the
device.
2.3.3. Device Model.
2.3.4. Method used for vendor initial validation testing, e.g. OBD
data test vehicles that include model year, make, model, etc.
B-20
2.3.5. Engine Original Equipment Manufacturer (OEM), engine
family and engine model year(s), vehicle makes and models
that the device can be used on.
2.3.6. Applicable OBD protocol(s) of the device.
2.3.7. Vendor shall identify if they plan to update devices already in
use in existing vehicle(s).
2.3.8. Vendor documentation of initial validation testing meeting the
requirements specified in subsection C.1 of this Part.
2.3.9. A detailed proposal for finding applicable fleets/vehicles to
test devices in the field to meet the vendor field testing
requirements specified in subsection C.3 of this Part, including
expected testing locations and the estimated number of
vehicles broken down by fleet, engine OEM, engine model
year, vehicle make and model, fuel type, and OBD protocol.
After the Executive Officer approves the detailed proposal,
any changes or deviations from the plan shall be reviewed and
approved by CARB.
2.3.10. A proposed timeline for completing the field testing
requirements specified in subsection C.3 of this Part.
2.3.11. Any additional information that may be necessary to help
verify that the device meets the requirements of this Part.
3. Vendor shall provide a copy of the warranty statement that will be provided to the
original purchaser of the device as specified in Part II subsection D.11.
4. Vendor shall provide a Statement of Compliance to unconditionally certify that all
the devices are designed with tamper-resistant components, built as described in
the certification application, and comply with the requirements of this Part.
5. Vendor shall provide a statement to the original purchaser of a certified device to
provide assurance that the device is valid for use in the HD I/M program from the
date indicated in the Executive Order until the end of the calendar year, that it
must be recertified annually, and may be decertified by CARB at any time if
deviations are identified.
6. Vendor shall provide a written document to describe the process and provide a set
schedule of performing updates to the hardware, firmware, or software.
7. Vendor shall provide a name of an agent for service located in the United States.
Service on this agent constitutes service on the vendor for any action by CARB or
otherwise by the United States related to the requirements of this Part.
B-21
C. Testing Requirements for Certification.
The following certification testing shall be performed to demonstrate that the device
meets the program requirements and shall be completed in the following phases:
1. Vendor Initial Validation Testing. Testing shall be completed by the vendor
following the required specifications and test conditions described below prior to
submitting their application package and shall be consistent with the requirements
in Part II.
1.1. Vendor shall test their device(s) using the specified test conditions
below.
1.1.1. Test at least one vehicle from every OBD protocol group
applicable to the device and provide three consecutive ROBD
submission files from each vehicle that demonstrates that the
engine revolutions per minute (RPM) is greater than zero and
the vehicle speed is equal to zero.
1.1.2. Test at least one vehicle from every OBD protocol group
applicable to the device and provide three consecutive ROBD
submission files from each vehicle where the MIL is
commanded OFF, there are no pending, active, or permanent
trouble codes, and all vehicle supported readiness monitors
are in a ready state.
1.1.3. Test at least one vehicle from every OBD protocol group
applicable to the device and provide three consecutive ROBD
submission files from each vehicle where the MIL is
commanded ON, and there is at least one stored active
diagnostic trouble code and at least one pending diagnostic
trouble code.
1.1.4. Test at least one vehicle from every OBD protocol group
applicable to the device and provide three consecutive ROBD
submission files from each vehicle where the MIL is
commanded ON and there is at least one permanent
diagnostic trouble code.
1.1.5. Test at least one vehicle from every OBD protocol group
applicable to the device and provide three consecutive ROBD
submission files from each vehicle where the MIL is
commanded OFF, there are no diagnostic trouble codes, and
at least one monitor is not ready.
1.1.6. Test at least one vehicle from every OBD protocol group
applicable to the device and provide three consecutive ROBD
B-22
submission files from each vehicle showing that the electronic
VIN is received from the vehicle and is not a user inputted
VIN.
1.1.7. Test at least one hybrid vehicle from every OBD protocol
group applicable to the device and provide three consecutive
ROBD submission files where the MIL is commanded OFF,
there are no pending, current, or permanent diagnostic
trouble codes, and all vehicle supported readiness monitors
are in a ready state.
1.1.8. Test at least one alternative fuel vehicle from every OBD
protocol group applicable to the device and provide three
consecutive ROBD submission files from each vehicle where
the MIL is commanded OFF, there are no pending current, or
permanent diagnostic trouble codes, and all vehicle
supported readiness monitors are in a ready state.
1.1.9. Test at least one vehicle from every OBD protocol group
applicable to the device and provide three consecutive ROBD
submission files from the different communication baud rates
(i.e. 250/500 kilobits per second (kbps)) supported by the
protocols.
1.1.10. Specifically for CC-ROBD devices, test at least one vehicle
from every OBD protocol group applicable to the device and
provide three submission files that contain multiple data logs
that were collected and stored every seven days as specified
in Part II subsection E.3.2.
1.2. In addition to the ROBD submission files that are submitted with the
initial validation testing, the vendor shall include the following
additional information in an organized format:
1.2.1. OBD data test vehicle(s): Year, Make, Model, VIN (or OBD
simulator)
1.2.2. The OBD protocol of the vehicle(s)
1.2.3. Engine and engine family of test vehicles
1.2.4. Additional test data or engineering evaluations if the
Executive Officer or the vendor deems it necessary to validate
the testing accuracy of the device.
2. CARB Device Verification Testing. The Executive Officer shall perform device
verification testing or review testing results to ensure the device meets all
B-23
specifications, to verify if the device successfully communicates with and collects
the requested data, or to validate the device’s ability to meet the required testing
specifications.
2.1. Vendor shall submit at least two (2) production ready devices that
have valid unique device serial numbers, as well as any equipment
that would be packaged with the devices including extension cables,
splitting cables, installation kits, or the owner’s manual, to the
Executive Officer for verification and certification.
2.2. Each device provided shall be in a configuration that is suitable for
testing. It shall have all the necessary equipment, instrumentation,
and set up information that was used for vendor initial validation
testing.
2.3. The Executive Officer shall issue results to the vendor. If the device
passes all of CARB’s verification testing, the device shall be allowed
to advance to the certification requirements specified in subsection
C.3.
2.4. If the device fails any portion of CARB’s verification testing, the
devices may be returned to the vendor. After addressing the device
deficiencies, if the vendor testing results show remediation, the
vendor may resubmit a new certification package to the Executive
Officer.
3. Vendor Field Testing. Testing shall be completed by the vendor using devices in
the exact same configuration as those that completed the CARB device verification
testing.
3.1. Vendor shall perform real-world testing by collecting data from an
applicable heavy-duty vehicle population (non-gasoline with GVWR
greater than 14,000 lbs.) and complete within 90 days from the start
of field testing.
3.1.1. Vendor shall include a representative sample of vehicle makes,
engine families, and fuel types within the tested vehicle
population that the device may be used on once certified.
3.1.2. Vendor shall use a minimum of 10 devices with the
configuration that completed CARB verification testing.
3.1.3. For NCC-ROBD devices, a minimum of 100 OBD data
submissions shall be obtained from a minimum of 100 vehicles
per OBD protocol that a device is certifying to.
B-24
3.1.4. For CC-ROBD devices, a minimum of 100 data submissions
shall be obtained from a minimum of 30 vehicles per OBD
protocol that device is certifying to.
3.1.4.1. For CC-ROBD devices specific to vehicles for one
vehicle make, a minimum of 50 data submissions
shall be obtained from a minimum of 10 vehicles.
3.2. Vendor shall electronically submit required testing data through the
electronic reporting system.
3.3. Vendor shall ensure successful communication between the device
and the vehicle.
3.4. Vendor shall obtain a successful connectivity rate of 99.9 percent for
all data supported by a vehicle’s OBD system as listed in Table 4.
3.5. The Executive Officer may adjust the connectivity rate in 0.10 percent
increments for the following reasons:
3.5.1. If it is determined through an engineering evaluation that the
stringency of the required connectivity rates needs to be
loosened or tightened
3.5.2. If it is determined that a technical or engineering issue inhibits
the ability to meet the required connectivity rates
3.6. Vendor shall ensure that the device is continuously in compliance with
the configuration that completed CARB verification testing.
3.7. If the vendor would like to exempt a vehicle(s), a request shall be
made to CARB. The request shall contain the technical reasons and
supporting data that explains why the vehicle should be exempted
from the calculation. The request shall be approved by the Executive
Officer prior to submitting the test results.
3.8. If vendor cannot complete the field testing at the end of 90 days,
vendor shall contact CARB by the 60th day and provide the reason(s)
why the field testing may not be completed on time.
3.8.1. The Executive Officer will evaluate whether the vendor shall
be allowed to continue with the testing or shall be required to
resubmit a new application and restart the certification
process. The criteria used to make this determination shall
include:
B-25
3.8.1.1. Vendor’s reasoning as to why the field testing is not
able to be completed on time;
3.8.1.2. Whether unavoidable and unexpected issues
occurred during the allotted testing period that made
meeting the required deadline infeasible;
3.8.1.3. Whether the current testing completed to this point is
consistent with the requirements that devices must
meet to obtain certification; and
3.8.1.4. Additional test data may be requested by the
Executive Officer to make this determination.
3.9. If the device fails to meet the requirements during field testing, the
vendor shall determine the reason(s) for device failure.
3.9.1. The Executive Officer shall evaluate whether the vendor shall
be allowed to retest their device in this phase after addressing
the deficiencies or shall be required to resubmit a new
application and restart the certification process. The criteria to
be used to make this determination shall include:
3.9.1.1. Vendor’s provided explanation explaining for the
cause(s) of their device failure, with supporting
information, and modifications needed to fix the
issue(s);
3.9.1.2. Whether unavoidable and unexpected issues
occurred during the allotted testing period that made
meeting the required deadline infeasible;
3.9.1.3. Whether the technical reasons the device failed and
the recommended solution require further laboratory
testing to confirm that the issue was remedied;
3.9.1.4. How close the testing device is from being approved
for certification; and
3.9.1.5. Additional test data requested by the Executive
Officer to make this determination.
3.9.2. If the device fails a second attempt of field testing, the vendor
shall be determined to have failed the certification process.
The vendor may resubmit a new certification application after
addressing any deficiencies.
B-26
D. Post-Certification Requirements.
1. Once the device meets the certification testing requirements, the Executive Officer
shall issue the vendor an Executive Order. The vendor may sell the device and use
the device for compliance purposes with this HD I/M Regulation only if the vendor
possesses a valid Executive Order. An Executive Order is valid from the indicated
effective date until the end of the calendar year for which it is issued. The vendor
may renew annually the certification for the device by following the procedure
described in section F of this Part.
2. With CARB approval, the vendor shall provide necessary device updates as
provided in the set schedule that was approved by CARB as specified in subsection
B.6 of this Part. The Executive Officer may waive the set schedule update if a
problem is detected with the device that critically impacts the compliance with the
certified configuration. Upon CARB’s request, the vendor shall provide an
approved emergency update.
3. Vendor shall notify user(s) of any changes in the certified device.
4. Vendor shall resubmit a certification application for any changes that modify the
device’s certified configuration.
E. Reporting and Recordkeeping Requirements.
1. The vendor shall electronically report certified devices via the electronic reporting
system and keep this information up to date.
2. Organize and maintain the following records:
2.1. A copy of all application documents as specified in sections B through
D of this Part, including, the test plan, application forms, test results,
warranty statement, statement of compliance, and any other
information provided to CARB such as device updates.
2.2. A list of device unique serial numbers for all devices produced and
sold including the original purchaser or user company name, original
purchaser or user contact information, and device model under each
Executive Order.
3. Keep required test data and all other information specified in this Part for five years
after CARB issues the Executive Order.
4. Records shall be readily available and stored in the same format as the submitted
certification application and on any media, as long as the vendor can promptly
send organized records in English to the Executive Officer if requested within 72
hours.
B-27
F. Recertifying Annually.
1. Prior to the conclusion of the certification period, the vendor shall submit a
recertification application for a new Executive Order provided the device continues
to meet the required specifications.
1.1. If the Executive Officer determines that the device still meets the
required specifications, the device shall be recertified for another one
(1) year period.
1.2. Devices determined not to continually fulfill the required
specifications shall not be recertified and shall be removed from use
for compliance determination for this Part.
1.2.1. After addressing the device deficiencies, the vendor may
resubmit a new certification application package to the
Executive Officer for approval.
G. Decertifying Devices.
If CARB finds that a certified vendor fails to furnish or install required software updates
to the device or fails to meet the specifications and requirements as stated in this Part,
the Executive Officer shall decertify the device in writing or by electronic mail with a
specified effective date of the decertification. After the device is decertified, the
device is considered noncompliant and shall no longer be used in the program for
compliance determination purposes. The vendor shall notify the user(s) of the change
in the device certification status.
H. Other Provisions.
1. Any person who fails to comply with these requirements or fails to submit
information, reports, or statements required by this Part may be subject to citation
as specified in section 2198.2 and their device or devices may be subject to
decertification under section G of this Part.
2. Any person who knowingly submits any false statement or representation in any
application, report, statement, or other document filed, maintained, or used for the
purposes of compliance with this chapter may be subject to citation as specified in
section 2198.2 and their device or devices may be subject to decertification under
section G of this Part.
B-28