Страница 1 мировой engineering стандарты общая спецификация

Page 141
GM WORLDWIDE ENGINEERING STANDARDS
GMW3110
© Copyright 2010 General Motors All Rights Reserved
February 2010
Page 141 of 336
8.10 DynamicallyDefineMessage ($2C) Service. 
This service is used to dynamically define the contents of
diagnostic data packets which are formatted as UUDT messages and can be requested via the
ReadDataByPacketIdentifier ($AA) service. The use of dynamic data packets allows a test device to optimize
its diagnostic routines and bus bandwidth utilization by packing messages to only contain the diagnostic
signal/parameter information that is required for the current test.
8.10.1 Service Description. 
Diagnostic data packets contain a one byte Data Packet Identifier (DPID #) and
one to seven bytes of signal/parameter data. UUDT diagnostic messages contain a message number and up
to seven bytes of data. The DPID# for a diagnostic data packet shall be the same as the message number
used when the diagnostic UUDT message is transmitted (i.e., DPID# $FE will be identified as diagnostic UUDT
message # $FE). Dynamically definable data packet Identifiers shall start with $FE and be numbered
sequentially backwards. No DPIDs are allowed to occupy the range of UUDT message numbers from $80
through $8F as these UUDT message numbers are reserved for the Diagnostic Trouble Code (DTC) services.
Dynamic data packets will be referenced in subsequent sections of this service as a DPID.
Each diagnostic signal/parameter is assigned a 2-byte Parameter Identifier (PID) number which is used to
build the dynamic DPIDs. The term PID will be used to reference diagnostic signals/parameters in subsequent
sections of this service.
All of the PIDs packed into a dynamic DPID shall be defined with a single request of this service. This request
may be a single-frame or multiple-frame message depending on the number of PIDs being packed in the
DPID. Once the test device receives a positive response from a $2C request, the PIDs in each subsequent
transmission of the corresponding UUDT message (as requested via service $AA) shall match those of the last
$2C service request message. A dynamic data packet shall be capable of being initially defined or modified
any time a node is capable of communications and shall only require a $2C service request to do so (i.e., no
key cycles or any other special events can be required). It shall also be possible to redefine a DPID while it is
currently being scheduled by the periodic scheduler. See Service $AA description for more detail on the ability
to schedule periodic UUDT messages. If the tester redefines a DPID without stopping the scheduler, the PIDs
in the response message may not be correct until the 2nd response of that message. This is the case because
a message may be queued for transmission at the time the DPID is being redefined and may not gain access
to the link until after successful completion of the $2C service. If the tester wants to guarantee that the next
transmission of the corresponding UUDT message contains the correct information, then the tester should
remove that DPID from the scheduler prior to redefining it.
If a $3E (TesterPresent) time-out occurs, or upon receipt of a $20 service (ReturnToNormalMode) request
message, the device shall retain the contents of all dynamic DPIDs. In addition, the periodic message
scheduler may be stopped and started without affecting the contents of any dynamic DPIDs.
A device which implements this service shall be capable of buffering a 3-frame request message. This is the
maximum number of frames needed to define a single dynamic DPID.