12
From a server point of view, there is no difference in the timing handling compared to a physically addressed
request message that requires enhanced response timing, but the client shall handle the timing differently
compared with physical communication.
a) The diagnostic application of the client starts the transmission of the functionally addressed request
message by issuing a N_USData.req to its network layer. The network layer transmits the request
message to the servers. A functionally addressed request message shall only be a single-frame message.
b) The completion of the request message is indicated in the client via N_USData.con. When receiving
N_USData.con, the client starts its P2
CAN
timer, using the default reload value P2
CAN
. For the response
message, the value of the P2
CAN
timer shall consider any latency that is involved based on the vehicle
network design (e.g. communication over gateways, bus bandwidth, etc.). For simplicity, the figure
assumes that the client and the server are located on the same network.
c) The completion of the request message is indicated in the servers via N_USData.ind.
d) The functionally addressed servers shall start with their response messages within P2
CAN
after the
reception of N_USData.ind. This means that in case of a multi-frame response messages, the FirstFrame
shall be sent within P2
CAN
and for single-frame response messages, that the SingleFrame shall be sent
within P2
CAN
. In case any of the addressed servers cannot provide the requested information within the
P2
CAN
response timing, it can request an enhanced response-timing window by sending a negative
response message including response code 78 hex (this is not allowed for service $01).
e) Upon the reception of the negative response message within the client, the client network layer generates
a N_USData.ind. The reception of a negative response message with response code 78 hex causes the
client to continue its P2
CAN
timer in order to observe other servers to respond within P2
CAN
. In addition,
the client establishes an enhanced P2*
CAN
timer for observation of further server #1 response(s). The
client shall store a server identification in a list of pending response messages. Once a server that is
stored as pending in the client starts with its final response message (positive response message or
negative response message including a response code other than 78 hex), it is deleted from the list of
pending response messages. For simplicity, Figure 5 only shows a single negative response message
including response code 78 hex from server #1.
f) Server #2 transmits a FirstFrame of a multi-frame response message within P2*
CAN
. The reception of the
FirstFrame is indicated in the client network layer by a N_USDataFF.ind. Figure 5 shows when the client
receives the start of the response message of the second server.
g) Server #1 previously indicated to the client (e) enhanced response timing. Once server #1 can provide
the requested information, it starts with its final response message by issuing a N_USData.req to its
network layer. If server #1 can still not provide the requested information within the enhanced P2*
CAN
,
then a further negative response message including response code 78 hex can be sent. This will cause
the client to reload its P2*
CAN
timer value again. A negative response message including response code
78 hex from a server that is already stored in the list of pending response messages has no affect to the
client internal list of pending response message.
h) Server #1 transmits a FirstFrame of a multi-frame response message within P2*
CAN
. The reception of the
FirstFrame is indicated in the client network layer by a N_USDataFF.ind. Figure 5 shows when the client
receives the start of the response message of the server #1. The client removes server #1 from the
internal list of pending response messages.
i) The client network layer will generate a N_USData.ind.
j) The server network layer will generate a N_USData.con based on the completion of the transmission.
5.2.3 Minimum time between requests from external test equipment
5.2.3.1 ISO 9141-2, ISO 14230-4 — Minimum time between requests from external test equipment
For ISO 9141-2 (K-line) interfaces, the required times between request messages are specified in ISO 9141-2.
Licensed Copy: Institute Of Technology Tallaght, Institute of Technology, Tue Oct 10 10:58:33 BST 2006, Uncontrolled Copy, (c) BSI