|
GM WORLDWIDE ENGINEERING STANDARDS
GMW3110
© Copyright 2010 General Motors All Rights Reserved
February 2010
Page 212 of 336
8.19.1.2 Requesting Periodic DPID Scheduling - Sub-Function Parameters ($02 sendAtSlowRate, $03
sendAtMediumRate, and $04 sendAtFastRate).
If the Node supports any of the levels that allow a tester to
schedule periodic DPID transmissions (sub-function parameters $02 through $04), it shall have a Periodic
DPID Scheduler (PDS). The maximum number of simultaneously scheduled DPIDs that the Node is required
to support shall be documented in the ECU Component Technical Specification (CTS). Each DPID in the PDS
shall be capable of being scheduled at one of the allowable periodic rates independent of the rate applied to
the other DPIDs in the PDS. The ECU shall be able to support in a single periodic DPID request, as many
DPIDs as there are items in the PDS. Refer to parameter PDS_Length in pseudo code.
The default periodic rates (scheduling rates) for the periodic DPID scheduler are
1000 ms
for slow,
200 ms
for
medium, and
25 ms
for fast. Periodic rate is defined as the time between any two consecutive messages of
the
same DPID
when it is scheduled by this service.
Note:
This service does not require an ECU to transmit ALL scheduled DPIDs at the same time. It is allowable
to have a minimum time between different DPIDs. The periodic rate is the time between consecutive
transmissions of a single given scheduled DPID, NOT the time between transmission of ALL scheduled DPIDs.
The default rates are guidelines and may be modified based on ECU capabilities. The actual data rates
associated with slow, medium, and fast, shall be documented in the CTS.
Note:
The actual rate at which a
specific
periodic DPID is transmitted can vary from the requested periodic
rate based on the number of DPIDs in the PDS, the rate at which the ECU services the PDS, and the amount
of bus traffic. Reference the pseudo code (paragraph 8.19.6.2) and the examples (paragraph 8.19.6.3) for
specifics on how the number of DPIDs in the PDS and the rate at which the PDS is serviced affects the
periodic transmission rate.
Each time a valid $AA request for periodic transmission is received the PDS shall be started (if not already
active) and the corresponding DPID(s) shall be put into the PDS or be updated with the requested (new) rate.
Multiple copies of the same DPID are not allowed in the PDS (i.e., if the ECU receives a request to schedule a
DPID already present in the PDS, only the scheduling rate will be updated). If a $AA request for periodic
transmission does not include a DPID already active for periodic transmission, this DPID shall remain
unaffected (e.g., if DPIDs 1, 4 and 5 are periodically sent and a new $AA request for periodic transmission only
includes DPIDs 1 and 4, the scheduled rate for DPID 5 shall remain unaffected while the scheduling rate for
DPIDs 1 and 4 are set to the new requested scheduling rate).
It shall be possible to request additional DPIDs to be scheduled at any allowed rate while the periodic
scheduler is active provided that the request does not attempt to place more DPIDs in the PDS then the PDS
supports. It shall also be possible to request scheduling DPIDs while a sendOneResponse DPID request is in
progress provided that the initial UUDT DPID response to the sendOneResponse DPID request has been
received. It shall be possible to redefine the rate of one or several DPID(s) while periodic transmission is
active. If dynamic DPIDs are supported by a Node, the Node shall allow redefinition of any/all dynamic DPID(s)
(via the $2C service) while periodic transmission is active.
When a P3
C
(TesterPresent) time-out occurs, the ECU shall stop periodic transmission of all DPIDs (stop the
PDS) and the entire PDS shall be cleared. No UUDT response shall be sent on this action. See TesterPresent
($3E) service regarding actions at tester present time-out.
After issuing a request for this service using one of the supported periodic rates, the tester must wait before
issuing any new diagnostic requests until one of the following occur:
Note:
The exception to this is the possibility of interleaving a functionally addressed TesterPresent ($3E)
request message to keep certain diagnostic services active. See TesterPresent service description and the
section on Diagnostic Communication Implementation Rules for more information.
A UUDT DPID response is received for a DPID which was not previously in the PDS, or
The tester receives any negative response message, or
The tester receives at least one previously scheduled UUDT DPID response from the periodic request
after P2
C
.
Note:
The tester is allowed to send a new diagnostic request after receiving a negative response that contains
a request service Id of $AA and a negative response code $78 (RequestCorrectlyReceived-ResponsePending)
because no further USDT response (either positive or negative) shall follow. All positive responses are UUDT
messages and no additional USDT negative response shall follow in this case because the ECU is required to
verify that the entire request for this service is valid before sending any response. This means that the negative
--``,,``````,``,,``,,,`,`,`,,-`-`,,`,,`,`,,`---
CameraLoops.com
Do'stlaringiz bilan baham: |
