Civil Engineering Reference
In-Depth Information
- Clear identification of the class of each malfunction, i.e.:
○
Hierarchical safety-related malfunctions.
○
Malfunctions that result in pollutant emissions exceeding a pre-set legisla-
tive threshold.
○
Malfunctions that do not result in pollutant emissions exceeding a pre-set
legislative threshold, but which could result in pollutant emissions exceed-
ing a pre-set legislative threshold at some time soon.
○
Malfunctions that do not need to be covered by legislation but are neces-
sary for an efficient diagnostic and maintenance function.
- Ability to communicate 'readiness' data to confirm if the vehicle is ready to
be inspected and has not had its fault memory cleared recently 1 (e.g. key
starts/warm-up cycles/distance travelled since memory cleared, how many
diagnostics have run and been completed, ability to see if a previously active
fault has been cleared by a scan tool but not fixed).
- Ability to transmit roadworthiness-related fault information (e.g. malfunction
indicator (MI) status and MI commanding 'on' fault codes, odometer read-
ings, distance travelled with MI on, emission “severity/priority” of fault).
- Ability to transmit vehicle identification information 1 (e.g. vehicle identifi-
cation number (VIN), software version, odometer reading, engine ID, trans-
mission ID, vehicle weight rating/class information).
- Ability to help combat tampering 1 (e.g. unauthorized clearing of diagnostic
information).
- Ability to help identify tampered or corrupted software at the time of
inspection.
- Ability to help identify (potentially) tampered hardware at the time of
inspection.
- Ability to identify and retrieve roadworthiness-related information from all
electronic control modules (ECM, TCM, etc.) through a single process and by
wireless connection.
- Compatibility with I/M equipment ([connector], hardware, software etc.).
- Additional specific inspection needs (e.g. mode $ 08-type commands for
smoke opacity test etc.).
- Compatibility with potential future telematics-based vehicle systems, e.g.
bluetooth, IEEE 802.11b (or later specification).
4. Needs for the technician (i.e. repairer, replacement part maker, tool maker, etc.)
are as follows:
- Data update rates (e.g. how fast can real-time sensor data be displayed for
technicians, communication speed, ability to obtain multiple PID's with sin-
gle requests etc.).
- Access to established and extendable to non-established chassis control
related fault codes and real-time data in a standardized manner.
- Mode $ 06 test results (data available in a standardized, understandable for-
mat without need to refer to a service topic).
