General Specification Electrical Function gmw3110 General Motors Local Area Network Enhanced Diagnostic Test Mode Specification

GM WORLDWIDE ENGINEERING STANDARDS 
GMW3110 
© Copyright 2010 General Motors All Rights Reserved 
February 2010 
Page 106 of 336 
operation within 30 ms after the request. In addition, the test device must wait at least 50 ms before attempting 
communication at low speed. 
Note:
The tester should wait for approximately 1 s before attempting normal communications after exiting a 
programming event in order to allow the nodes adequate time to perform a software reset and reinitialize 
communications. 
--``,,``````,``,,``,,,`,`,`,,-`-`,,`,,`,`,,`---
CameraLoops.com

---

GM WORLDWIDE ENGINEERING STANDARDS 
GMW3110 
© Copyright 2010 General Motors All Rights Reserved 
February 2010 
Page 107 of 336 
8.6 ReadDataByParameterIdentifier ($22) Service. 
The purpose of the ReadDataByParameterIdentifier 
service is to allow a tester access to ECU data by requesting one or multiple Parameter Identifier(s) (PID). This 
service is intended to be used during a device
’s development cycle and for special test conditions. It is not 
intended to be used in lieu of service $AA for manufacturing and/or field service diagnostics. 
8.6.1 Service Description. 
The ReadDataByParameterIdentifier service provides a means for a tester to 
request ECU data by Parameter Identifier (PID). A PID number is a unique 2-byte value that the ECU 
translates into a specified piece of data (e.g., ABS left front wheel speed, or engine rpm). The length (number 
of data bytes in the response message for a given PID) and scaling of the response data (associated with a 
PID) must be documented in a CTS, SSTS, supplemental diagnostic specification, or another document or 
database referenced by any of the proceeding documents. PID response data can range from one to seven 
bytes in length per PID (not including the PID number). 
Note:
The 7-byte maximum results from the fact that PIDs can be packed into DPIDs and requested via the 
$AA service. The $AA service uses UUDT responses. UUDT responses are limited to seven bytes. For the 
purpose of service $22, the 7-byte maximum refers to the maximum number of bytes in the dataRecord for 
each PID. Reference the positive response message definition table. 
This service only provides a single USDT positive response to a request for one or multiple PIDs provided that 
the request message is properly formatted and at least one of the requested PIDs is supported in the ECU. If a 
tester needs to retrieve PID data periodically then the tester must first pack the PID (or PIDs) into a DPID via 
the $2C service and then request the data periodically via the $AA service. 
If a tester requests multiple PIDs with a single request of this service, the ECU shall include data in a positive 
response for all of the PIDs that it supports. No data shall be included in a positive response for unsupported 
PIDs, or for secure PIDs unless security access has been granted (ECU is unlocked) via service $27. See 
paragraph 8.8 for more details on service $27. 
A functional request for this service containing only unsupported PID(s) shall result in no response being sent. 
A physically addressed request shall result in a negative response if none of the requested PIDs are supported 
in the ECU. 
The maximum number of PIDs that the ECU supports with a single request shall be documented in the ECU 
CTS, SSTS, or supplemental diagnostic specification referenced by either of the preceding documents. 
This service can also be used to retrieve emission related PIDs as specified in SAE J1979/ISO 15031-5. 
Because SAE J1979/ISO 15031-5 uses a single byte PID number, a tool must request these emission PIDs 
with the most significant byte (MSB) of the PID number set to $00 when using this service, to ensure request 
message compatibility. See paragraph 8.6.5 for example.