Client response timing¶
Requirements governing the client’s tP_Client timer, which bounds the time the client
waits for the response to a request it has transmitted.
This is the first document in the set to specify the client. Where the server is a single
instance with a single session, the client is one instance across many logical communication
channels: ISO 14229-2:2021 9.6 Table 7 requires a tP_Client timer for each of them,
physical and functional alike. Every requirement below is scoped to one channel, and the
timers live in storage the caller supplies.
One request per channel¶
ISO 14229-2:2021 9.6 Table 7 allocates a single tP_Client timer per logical
communication channel, 9.7 Table 9 states the client’s error handling in terms of repeating
the last request, and 10.3’s note defines a request as completely handled — the condition on
transmitting the next one — in terms of the responses to a single outstanding request. One
request in progress per channel is what those resources can express.
The requirements below are written against that model. It is not restated as a requirement: the standard states the resources rather than the restriction, and this set does not write requirements the standard does not directly require. It is recorded instead as an assumption of use in the qualification repository, where it is assessed from a safety perspective. The server response timing document treats ISO 14229-1:2020 8.7.6 the same way.
The client’s own keep-alive costs no second slot. ISO 14229-2:2021 10.1.4.1 Figure 12 keys
i, l and n transmit a functionally-addressed TesterPresent each time tS3_Client expires,
and keys j, m and o restart only tS3_Client on its confirmation; no response is required
of it, so no response window opens.
The logical communication channel¶
Throughout this document, a logical communication channel is identified by the
addressing of the requests the client sends on it: S_Mtype, S_AI[TAtype],
S_AI[SA], S_AI[TA] and, where S_Mtype carries one, S_AI[AE]. That is the
addressing UDSS_LLR_0059 matches a confirmation on, so the one transmission
UDSS_LLR_0060 allows outstanding per addressing is the channel’s one outstanding
transmission; ISO 14229-2:2021 9.6 Table 7’s point-to-point communication is a pair of
addresses. A channel is a physical channel or a functional channel according to its
S_AI[TAtype], taking the two values UDSS_LLR_0049 defines. ISO 14229-2:2021 9.6
Table 7 speaks of each logical communication channel as physical or functional
communication, a property of the channel rather than of any one request on it. The
requirements below condition on the channel’s kind, not on the S_TAtype of the
indication in hand: a server answers the one client that asked, so every response arrives
physically addressed whatever the request was. That is an observation about how servers
answer, which this set relies on; ISO 14229-2:2021 states the client’s timing on that
footing without saying so.
The session layer cannot place an inbound indication on a channel by itself. A physically
addressed response answers either the physical channel to that server or a functional
channel the server was reached through, and nothing in the indication says which.
UDSS_LLR_0026 therefore requires the caller to identify the channel each
T_DataSOM.ind and T_Data.ind belongs to. A channel exists from when the caller opens
it, as UDSS_LLR_0121 states. UDSS_LLR_0045 settles which indication is the
start of a message and which its completion, and this document uses its terms first
indication and completion without restating them.
On a functional channel many servers answer one request. Each is a responder, identified
by the S_AI[SA] and, where S_Mtype carries one, the S_AI[AE] of its indications.
UDSS_LLR_0139 keeps what the client must remember about each of them.
The request in progress¶
Throughout this document, the request in progress on a channel is the request whose
response the client is waiting for: from the T_Data.conf confirming its successful
transmission until that wait ends. UDSS_LLR_0128 enumerates the endings. Each is a
point at which the client is no longer waiting: the response it waited for has arrived,
the expected responses of a functional exchange are all in, the reception failed and
ISO 14229-2:2021 9.7 Table 9 has the client repeat the request rather than wait on, the
window expired, or the caller reset the channel. A request expecting no response is never
in progress in this sense, there being no response for the client to wait for, and
UDSS_LLR_0135 starting no timer for one.
A stopped timer does not by itself mean that no request is in progress. UDSS_LLR_0136
also stops the timer at the start-of-message of a response-pending message, which
ISO 14229-2:2021 9.4 Figure 8 key c requires, and the request is still in progress across
the gap that follows. An implementation therefore cannot treat the timer’s running state as
standing for the request in progress; the two are separate.
The definition is stated here rather than borrowed from the server’s. The server response timing document’s own state, service in progress, is defined from ISO 14229-2:2021 10.1.4.1, but both of that definition’s endpoints — the start of reception of the request and the completion of transmission of the final response — are events at the server, and neither occurs at the client.
What the client declares and the server does not¶
A client’s request states how many responses it expects; a server’s states no such thing,
because a server answers the one request in front of it. UDSS_LLR_0065 carries the
declaration.
This is the substantive asymmetry between the two roles in this set. It follows from functional addressing, which has no server-side equivalent: one request reaches many servers and each may answer, so the number expected is information only the application that composed the request holds.
One reload pair, not four¶
ISO 14229-2:2021 9.1.2 divides tP_Client four ways according to whether the transport
supports T_DataSOM.ind: the timer is loaded with tP2_Client_Max or
tP6_Client_Max, enhanced to tP2*_Client_Max or tP6*_Client_Max, and stopped by
whichever of the two indications the transport provides.
The session layer cannot make that distinction. No input tells it what transport it is on,
and on a transport without T_DataSOM.ind it cannot observe a message’s framing at all,
a multi-frame message arriving as a single T_Data.ind.
It does not need to. UDSS_LLR_0132 takes one pair of reload parameters, default and
enhanced, and the stop conditions below are phrased on the first of T_DataSOM.ind or
T_Data.ind for a message. Where no T_DataSOM.ind ever arrives the rule degenerates
to the T_Data.ind case exactly. This is the standard’s own construction rather than an
inference: 10.1.3 Figure 11 key g stops the timer at the start-of-message on a transport
that provides one, and key h stops it at the completion indication on a transport that does
not.
UDSS_LLR_0045 supplies the pairing this rule depends on. A T_Data.ind that completes
no open start-of-message is its message’s first indication by that rule, not by assumption.
What this document does not cover¶
ΔtP2 and ΔtP6, and the minimum values ISO 14229-2:2021 9.2 Table 4 derives from
them for tP2_Client and tP6_Client, are performance requirements on the vehicle
network and on the caller that chooses the parameter values. The server response timing
document excludes the same class for the same reason.
ISO 14229-2:2021 9.1.2 further requires the client application to verify its own timing by comparing the live timer against the parameter. That is an obligation on the layer above this one, discharged by the application rather than by the session layer.
tP3_Client_Phys and tP3_Client_Func, which bound how soon the client may transmit
its next request, are specified in Client request spacing. tS3_Client, which
keeps the servers in a non-default session, is specified in Client session timer.
ISO 14229-2:2021 9.7 Table 9 states both what a response timeout means and what the client
must do about it — repeat the request, at most twice, restarting tS3_Client where the
request was a physically addressed, sequentially transmitted TesterPresent. This document
states the meaning, because the timer cannot be specified without it. The consequences
belong to Client error handling, which transcribes Table 9 as far as this layer
can, and to Client session timer for the restarts.
ISO 14229-2:2021 10.1.4.1 and 10.2.4 each state that the client’s reload values may differ
in a non-default session, the applicable tP_Client parameters being reported to the
client by the DiagnosticSessionControl service of ISO 14229-1. No requirement here
transcribes that. The reload values are protocol parameters the caller sets under
UDSS_LLR_0040, and which values apply in which session is settled by the application,
which reads them out of the response; UDSS_LLR_0073 forbids this layer from reading them
for itself.
The response window¶
The client shall maintain a single Table 7 requires a single timer for each logical communication channel, physical and
functional alike, and clause 9.1.2 requires a single application timer implementation
triggered by the The storage is the caller’s because the number of channels is a property of the
deployment rather than of the protocol, and the crate does not allocate, as
|
A logical communication channel shall exist from the moment the caller opens it, identified by the addressing the caller states when opening it, until the caller withdraws it. The session layer shall return a handle identifying the channel, which its outputs and per-channel inputs use. A handle identifying a channel the caller has withdrawn shall identify no channel opened afterwards. Rationale: neither clause the timer requirement A withdrawn channel’s handle identifies no later channel because |
An open of a logical communication channel for which the caller-supplied storage of
that channel’s kind has no free slot, or for which no handle remains that the client
has not already issued, shall be rejected as Rationale: the storage is the caller’s and is sized by the deployment, as
|
Opening a channel whose addressing equals that of an existing channel shall be rejected
as Rationale: two channels one |
An Rationale: naming a channel that does not exist is a caller error, not an input, and is
treated as |
A withdrawal identifying a channel the client does not have shall be rejected as
Rationale: naming a channel that does not exist is a caller error, not an input, for the
reason |
Withdrawal of a channel shall be permitted at any time and shall discard, without
output, every fact this set holds for the channel, an association outstanding on it
included, save what Rationale: withdrawal discards everything and is permitted at any time because it is the
caller’s last exit: a transmission whose confirmation never comes leaves its association
outstanding, |
Every fact a document of this set keeps per channel lives in the channel’s storage. The
same storage shall hold whether a request is in progress on the channel and, while one
is, the addressing and classification of that request and, where that classification
states an exact expected response count, the number of responses Rationale: the storage is the caller’s for the reason The request record is held because requirements read it: |
When a channel is opened its Rationale: the initial state is stated because none of the conditions |
A request shall become in progress on the Rationale: the request in progress is the condition |
Low-Level Requirement: An input that ends the request is processed while it is in progress UDSS_LLR_0129
|
An input that ends the request in progress shall be processed while the request is still in progress. Rationale: a requirement conditioned on the request in progress must be eligible to act
on the very input that ends it. Were it otherwise, |
A physical channel’s open start-of-message shall be retained past the end of the request
in progress until a Rationale: the start-of-message outlives the request because the wait on a physical
channel ends at the first indication of the final response while |
While a channel exists, the state of that channel’s Rationale: a closed list of the requirements that may change the timer is what makes a
“changes nothing” claim elsewhere in the set checkable, and what lets |
Each channel shall have a default reload parameter and an enhanced reload
parameter, supplied as protocol parameters under Where the transport supports Clause 9.1.2 makes that correspondence, loading the timer with the The session layer does not distinguish the two cases for the reason the preamble gives: nothing tells it which transport it is on, and the stop conditions below are phrased so that it does not need to know. The distinction survives in the values the caller supplies, and in the minimum values Table 4 derives for them, which differ by whether the window covers the start of the response or its complete reception. The parameters may change during the life of a channel. ISO 14229-2:2021 10.1.4.1 and
10.2.4 permit different values in a non-default session, and |
A setting of a per-channel parameter shall identify its channel — the response timer’s
default and enhanced reload parameters of Rationale: a per-channel parameter has no meaning apart from the channel it governs,
and a caller managing several channels must be able to say which one a setting is for;
|
Low-Level Requirement: A parameter setting naming no existing or wrong-kind channel is rejected UDSS_LLR_0134
|
A setting of a per-channel parameter that identifies a channel the client does not have
shall be rejected as Rationale: a parameter attached to a channel that does not exist has no storage to
carry it, so the setting cannot be honoured; |
Low-Level Requirement: The response timer starts on confirmation of a request expecting a response UDSS_LLR_0135
|
On Table 3 defines The condition on the expected response count comes from Figure 20, whose keys b and g
each state that there is no response required to be transmitted and therefore the client
does not need to start its Clause 9.1.2 disagrees, starting the timer whenever a One figure key disagrees with all of the above about the starting primitive. 10.1.4.2
Figure 13 key k has the client start The transmission must be successful because a |
On the first indication of a message on a physical channel with a request in progress,
the client shall stop that channel’s
On a Clause 9.1.2 states the stop without qualification, at either the start-of-message or the completion indication according to what the transport provides, and Figures 9, 10 and 11 show it in both forms: Figure 9 key d and Figure 11 key h stop at the completion where there is no start-of-message, Figure 10 key e and Figure 11 key g stop at the start-of-message where there is one. The requirement is phrased on the arriving primitive rather than on what the message
turned out to be, which is what the clause does. The completion of a response-pending
message does not close the window: The condition separates the channel from the indication because the session layer decides
them from different inputs. A request in progress is a property of the channel; which
messages act on the timer is settled by the classification and the reception result. The
requirement is not phrased on a response for the request in progress, which names the
right message but gives the session layer no way to recognise it: The final response must therefore be solicited. The second condition admits only the The failed-reception sentence is stated on the strength of two locators rather than
transcribed from either. Clause 9.1.2 stops the timer on the indication and says nothing
about its result, and 9.7 Table 9 gives a failed reception its own row, requiring the
client to repeat the request; between them the wait is over, and this requirement says
so. It is conditioned on the result rather than on the kind because The failed-reception stop reaches a completion as well as a first indication, unlike the
two conditions above, because a failed completion of a message whose start-of-message
stopped nothing, an unsolicited multi-frame response for instance, would otherwise leave
the timer running after |
Low-Level Requirement: A response on a functional channel extends the window; a failed reception closes it UDSS_LLR_0137
|
On the first indication of a message on a functional channel with a request in progress,
the client shall restart that channel’s
Where On a Figure 14 keys e and f and Figure 15 keys d and f each restart the timer on the first
indication of a response; Figure 16 key f does the same within an enhanced window, and
key i on its exit. Figure 15 key h takes no timer action at a completion whose
start-of-message already restarted the timer, which is why the restart is stated on the
first indication alone. Figures 14 and 15 show an exchange whose expected count is
unknown, ending by timeout at keys g and i; Figure 19 shows the known count that
This requirement and The exception for A response-pending message is admitted only at its The solicitation qualifier is carried for the reason A failed reception stops the timer on a functional channel as on a physical one, and for
the same two locators. 9.7 Table 9’s functional response-reception row requires the
client to repeat the request once it has completely received any response in progress at
the moment of the error, which makes the failure the event that ends this exchange rather
than one the exchange waits through. Letting the timer run on to expiry instead would
surface one event to the application twice, once as the failed reception and once as a
timeout, under two rows of a table that caps the client’s repeats at two. The stop is
stated on the Clause 9.1.2 states a stop for every indication, as |
On a functional channel where the request in progress declared an exact expected response
count, on the Figure 19 keys d and j both state it: the client only expected a response message from
server #1, therefore it stops its Only a solicited final response counts. A server that has requested an enhanced response
window has not yet answered, and counting its response-pending message would end the
exchange before its response arrived. An absent kind does not count either:
The responses counted are those received on the channel since the request was confirmed,
rather than those received for the request. No requirement in this set associates an
inbound indication with the request it answers, so the count is stated over what the
session layer can observe: The count advances on the A response whose reception failed does not count, that server’s response not having arrived, so the exchange runs on. Table 9 gives a failed reception a handling of its own, and this requirement does not route it through the timeout. Where the request declared an |
Responders on a functional channel¶
Each functional channel shall have a responder table in the channel’s storage under
Rationale: ISO 14229-2:2021 10.2.3 Figure 16 keys d and i, and 10.2.4 Figure 17 keys m
and t, require the client to add an entry for a server’s address when its
response-pending message completes, to remove it at the start of that server’s next
message, and to select the reload value by whether any entry remains. That is state per
responder, stated as client behaviour in both sessions. The open start-of-message is the
other fact ISO 14229-2:2021 9.6 Table 7 allocates the client one The storage is the caller’s for the reason A physical channel needs no table. One peer answers on it and one request is in
progress, so the only fact to hold is whether that peer’s start-of-message is open,
which |
In a functional channel’s responder table, an entry shall be created, where the table has
a free entry, by the indication that makes one of the two entry facts Rationale: the start-of-message creates an entry whether or not a request is in progress
because |
When the request in progress on a functional channel ends, the outstanding
response-pending fact of every entry in that channel’s responder table shall be cleared,
and an entry whose start-of-message is open shall be retained until a Rationale: ISO 14229-2:2021 9.7 Table 9 obliges the client to completely receive the
response messages in progress at a timeout or a failure before it continues, and
|
When a functional channel is opened its responder table shall hold no entry. Rationale: the initial state is stated for the reason |
Low-Level Requirement: A responder beyond the table's capacity is reported and not tracked UDSS_LLR_0143
|
Where a Rationale: an inbound indication from a responder the client has is not a caller error
The indication is how the application learns it. The session layer can observe the shortfall and cannot correct it, so it reports and the application acts. |
Enhanced response timing¶
On a Table 3 defines The requirement is conditioned on a request being in progress, as The enhanced window opens at the completion of the response-pending message, not at its
start. Every cited source places the reload there: Table 3 defines the enhanced timeout
from the reception indicated via Where such a message arrives in more than one frame, the standard stops the timer at its
start-of-message rather than reloading: Figure 8 key c does exactly that.
The reception must have succeeded. |
On a functional channel, the reload value in force shall be the enhanced reload
parameter while any entry in the channel’s responder table records an outstanding
response-pending message under Figure 16 key d adds an entry for the responding server’s address when its response-pending message completes and reloads the timer with the enhanced value; key f shows the value being read while that entry stands, another server’s start-of-message restarting the timer with the enhanced value while the list is non-empty; key i removes the entry at the start-of-message of that server’s next message, finds the list empty, and reloads with the default value. Figure 17 keys m, o and t state the same in a non-default session. |
A responder’s response-pending message shall be recorded outstanding, on a channel with
a request in progress, on a Figure 16 key d adds an entry for the responding server’s address when its response-pending message completes; key i removes the entry at the start-of-message of that server’s next message, finding the list empty. Figure 17 keys m and t state the same in a non-default session. The entry is cleared by any later message from that responder, response-pending or not, because key i clears at the start-of-message without qualifying what the message is. The record is not guarded on the responder already having an entry. In both figures the
response-pending message is single-frame, so no Where a server’s next message is a further response-pending one, the default value is in
force under The reception must have succeeded. A failed reception the caller labels
|
On a functional channel, where one indication both ends an outstanding response-pending
message under Rationale: the first sentence is what ISO 14229-2:2021 10.2.3 Figure 16 key i shows. The start-of-message that empties the responder table’s list is the same indication that restarts the timer, and the figure reloads it with the default value, so the entry is removed before the value is read. Without the sentence the same indication could be read either way. The second sentence covers a single-frame response-pending message, the usual form,
which has no separate transfer: its one Neither figure is cited as a source by this requirement: each shows one example, and reading either as a general ordering rule for every case of one indication with two effects is this requirement’s own resolution, not a fact the figures state outright. |
When a channel’s Clause 9.1.2 requires an error condition to be detected where no indication is received
within the timer’s value, and requires that condition to be flagged to the application
layer with the parameters included in the The window is exceeded rather than reached. Clause 9.1.2 states that an indication
received while The indication carries the addressing of the request rather than of the response. Clause 9.1.2 asks for the parameters of an indication that did not arrive, which would have to be constructed; and under functional addressing there is no single absent responder whose address could be named. The request’s addressing is what the session layer holds and what identifies the channel to a client operating several. The addressing parameters carry Neither cited clause requires the indication to name the reload parameter. Table 9 heads
its timeout row This requirement does not state what the client does next. Table 9’s handling — repeat the request, at most twice — belongs to Client error handling. The timer is stopped for the reason |