8.19.1 Service Description.
The ReadDataByPacketIdentifier service ($AA) request message includes a sub-
function parameter and at least one DPID number when the request is for a one time response (sub-function
parameter $01) or periodic transmission (sub-function parameters $02 through $04). A single request to stop
sending one or multiple periodic DPIDs (sub-function parameter $00) may be sent with or without additional
DPID data and the resulting action taken by the ECU shall be different based on whether or not DPID data is
attached. It shall be possible to request the transmission of multiple DPIDs with a single request for this
service. The controller shall support multiple DPIDs in the request message for all possible data rates
implemented (slow, medium, fast, stop periodic, and one time response).
The entire request message shall be validated before any action is taken. If any error in a request message is
identified, the whole request shall be rejected and the appropriate negative response shall be transmitted to
the tester. A single message validation exception exists for the stopSending sub-function parameter where an
invalid DPID in the request message does not result in a negative response as long as the total number of
DPIDs in the request is less than the maximum number of items allowed in the periodic scheduler. Refer to the
pseudo code and Supported Negative Response Codes section for the required implementation.
A positive response to a request for this service shall always consist of one or multiple UUDT diagnostic
messages. The only USDT diagnostic responses allowed with this service are negative responses.
8.19.1.1 Requesting A One Time Response of One or More DPIDs Sub-Function Parameter = $01
(sendOneResponse).
The ECU shall send a single UUDT diagnostic response message for each DPID
included in a request for this service with a sub-function parameter = $01 (sendOneResponse). The maximum
number of DPIDs the ECU is required to support in a sendOneResponse request shall be documented in the
ECU
’s Component Technical Specification (CTS).
The tester shall wait until all responses to a sendOneResponse DPID request have been received before
issuing another sendOneResponse DPID request. The ECU is only required to handle a single
sendOneResponse DPID request at a time. If the tester sends another sendOneResponse request before the
ECU has finished responding to the first one, the results are undefined (based on the message buffering
capabilities of the receiving ECU). After issuing a sendOneResponse request to an ECU, a tester is allowed to
send another diagnostic request (except for another sendOneResponse request) to the same ECU after
receiving either the first/only UUDT DPID response, or receiving a negative response with a response code
value not equal to $78 (RequestCorrectlyReceived-ResponsePending).
The ECU shall support a sendOneResponse DPID request while the periodic scheduler is active (assuming
that the ECU supports one or more of the periodic levels of this service and provided that another
sendOneResponse request is not in progress).
If multiple DPIDs are included in a valid sendOneResponse DPID request, the ECU shall send the first UUDT
DPID response within P2
CE
(or P2
CE
* if a negative response with response code $78 is sent by the ECU within
P2
CE
).
Note:
See the application timing requirements section within this specification for further details.
The ECU shall transmit all subsequent DPID responses within P2
CE
of the previous DPID response transmitted
as a result of this request. Any deviations from the sendOneResponse UUDT timing requirements shall be
agreed upon by the DRE, Service and Manufacturing serial data engineers, and shall be documented in a
CTS, SSTS, or supplemental diagnostic specification referenced by a CTS or SSTS.
--``,,``````,``,,``,,,`,`,`,,-`-`,,`,,`,`,,`---
CameraLoops.com
Do'stlaringiz bilan baham: |