Server response timing¶
Requirements governing the server’s tP2_Server timer, which bounds the time the server
may take to begin its response to a request it has received.
This is the second of the server’s two timers. tS3_Server, in
Server session timer, keeps a non-default session alive across requests;
tP2_Server bounds the response to one request. They are independent, and unlike
tS3_Server the response timer runs in every session. ISO 14229-2:2021 9.5 states that
the timing parameter definitions of Tables 3 and 4 hold for a non-default session too, and
permits the server to change tP2_Server and tP2*_Server on transitioning into one.
Under UDSS_LLR_0040 both are caller-supplied protocol parameters, read each time the
timer is loaded.
One request at a time¶
ISO 14229-1:2020 8.7.6 states that one diagnostic protocol instance can handle only one
request at a time, and that any received message, physically or functionally addressed,
occupies that resource until the request has been processed. ISO 14229-2:2021 9.2 agrees,
requiring the server to be able to process a new request immediately after the
T_Data.conf of the response to the preceding one.
The requirements below are written against that model, which is why one timer suffices. The model is not restated as a requirement here. It is an application layer rule that ISO 14229-2 does not impose on the session layer, 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.
ISO 14229-1:2020 8.7.6 excepts two cases. The first is the functionally addressed
keep-alive TesterPresent, which the caller marks keep-alive under UDSS_LLR_0065.
Server session timer handles it instead.
The second is a request in the OBD service range that, for a server supporting that range
and not in the programming session, aborts the active service and starts the default
session. That is an application-layer action: UDSS_LLR_0108 ends the service in progress
on the reception of the OBD request, and Server session timer’s assumptions of
use state how the session change is classified and why the aborted request’s completion
report is optional.
Throughout this document, the service in progress is the service, if any, whose
request the server has begun handling and not yet finished handling. ISO 14229-2:2021
10.1.4.1 fixes its extent, and gives the term itself: a diagnostic service is in progress
at any time between the start of the reception of the request message, T_DataSOM.ind
or T_Data.ind, and the completion of the transmission of the final response message
where a response message is required, or the completion of any action caused by the
request where none is required. UDSS_LLR_0089 already cites that clause for the same
definition.
A request marked keep-alive is excluded from the term: ISO 14229-1:2020 8.7.6 puts it
outside the one-request-at-a-time model, and no requirement in this set treats it as the
service in progress, so ISO 14229-2:2021 10.1.4.1’s extent is read here as bounding the
requests the model admits.
The model above is what guarantees there is at most one such service at a time.
What this document does not cover¶
tP4_Server, ΔtP2 and ΔtP6. ISO 14229-2:2021 9.2 Table 3 types tP2_Server
a performance requirement too, so being one is not what excludes them: what excludes them is
that no clause asks the session layer to time them. 9.1.1 REQ 5.1 requires a tP2_Server
timer implementation and 9.6 Table 7 allocates the resource for it, while neither does
anything of the kind for these three, whose bounds fall on the server’s application and on
the vehicle network. No requirement transcribes them.
Their consequence is excluded with them. ISO 14229-2:2021 9.1.1 makes a response-pending
message inadmissible for a service whose tP4_Server_Max equals tP2_Server_Max, and
requires that equality for services the server does not support. Whether a given service may
go response-pending at all is therefore fixed by a per-service value the session layer
neither holds nor can derive: UDSS_LLR_0073 forbids inspecting message data, and
UDSS_LLR_0042 supplies every parameter a timer loads with the instance or with the
caller-supplied storage it belongs to, never with a service. ISO 14229-2:2021 9.3 Figure 7
confirms the reading, applying the equality “for a certain T_Data.ind”.
UDSS_LLR_0119 spaces consecutive response-pending messages; whether the first was
admissible binds the application.
The origination of a response-pending message is excluded on the same ground as its
admissibility. Every response-pending message reaches this layer as an S_Data.req the
caller supplies on the application’s behalf: the session layer permits or refuses it and
keeps the bookkeeping the window and the spacing need, and never composes one of its own.
Whether a response-pending message is the right answer to a given request, and the octets
that carry it, belong to the ISO 14229-1:2020 clause 8.7 layer, which is also the layer that
knows whether the service is supported — the predicate ISO 14229-2:2021 9.1.1 makes the
admissibility turn on.
A caller’s exit from a service in progress that never ends. The client has the channel reset
of its error handling document; the server has nothing, deliberately: the assumption of use
that the caller supplies a completion report for every request it does not answer is what
ends such a request, and a server whose application neither answers nor reports has broken
that assumption, not exhausted the standard. An association of UDSS_LLR_0059 whose
T_Data.conf never arrives likewise has no server exit, as UDSS_LLR_0060 records; the
assumption of use that the transport reports a T_Data.conf for every T_Data.req,
recorded on Open questions beside the start-of-message assumption, is what bounds it.
The response window¶
The server shall maintain a single Neither cited locator asks the server to record which parameter is loaded; that conjunct
is derived, and exists to serve Clause 9.1.1 requires a single timer implementation and names Table 7 gives the reason one timer suffices: it is required for the enhanced response
timing, to ensure a subsequent response-pending message is transmitted before
|
On initialisation the Rationale: none of |
After the server is initialised, the Rationale:
|
Low-Level Requirement: The server keeps a service in progress and a response-pending anchor UDSS_LLR_0104
|
The server shall keep, in the instance, whether a service is in progress and, while one
is, the Rationale: The anchor holds the time of the confirmation because That is a declared reading rather than the footnote’s words. ISO 14229-2:2021 9.2 Table 4
footnote b requires the minimum “between the transmission of consecutive negative
messages (each with negative response code 78)” during the enhanced response timing, in
order to avoid flooding the data link; it does not say whose service those messages
answer. The per-service reading is taken because the enhanced response timing the
footnote is stated within is opened per request under The state is instance-resident because it is fixed in size, one fact, two addresses and
one timestamp, as The state is named service in progress rather than named for the request, because ISO 14229-2:2021 10.1.4.1 itself says a diagnostic service, not a request, is in progress. |
On initialisation no service shall be in progress and the anchor shall be clear. Rationale: the initial state is stated because none of the conditions |
An input answers the service in progress where the identity formed by its target
address and, where its Rationale: a request replaced under ISO 14229-1:2020 8.7.6 does not say which client sends the OBD-range request. Where it is
another client the match is exact. Where it is the same client and a response of the
aborted request is unconfirmed under The match also presumes the caller supplies a |
A service shall become in progress on Rationale: the start transcribes what the standard gives. ISO 14229-2:2021 10.1.4.1
Figure 12 key k places it at the reception of the request, and ISO 14229-5:2022 8.7.6
Figure 6 key l names the primitive, a service being in progress from “the reception of
the request message (T_Data.ind receive)”. The start is the successful |
Where a service becomes in progress under Rationale: a new request replaces the service in progress because ISO 14229-1:2020 8.7.6
has one request abort another, its OBD-range exception, and the reception of the new
request necessarily precedes the abort it causes; were the fact merely left true, the
aborted request’s ending would be read as the new one’s. The replacement applies to every
request indicated while a service is in progress, because The requirement governs the requests a caller indicates, not every request a transport
delivers. ISO 14229-1:2020 8.7.6 has any other received message occupy the protocol
instance until processed, so a caller enforcing that rule indicates no request while it
is still processing the service in progress: it answers one with a |
A service shall cease to be in progress on Rationale: ISO 14229-2:2021 10.1.4.1 Figure 12 key k places the end at the completion of
the transmission of the final response, or at the completion of the action where no
response is required, and the completion report of ISO 14229-5:2022 8.7.6 Figure 6 key l states the same extent without key k’s “final”,
putting a service in progress until “the completion of the transmission of the response
message”, and compensates with “This includes negative response message(s) including
negative response code 0x78”. That sentence is read here as saying the span includes
those messages, so a request survives its response-pending messages and ends at the final
one, which is what this requirement states. It is a declared reading: on its face the
sentence also admits folding a 0x78 message into the response whose completion ends the
service. That construction is rejected because key l’s own opening ties the restart to
the service being “completely processed”, because ISO 14229-2:2021 9.5 Table 6, which
The outcome of the transmission is immaterial because ISO 14229-2:2021 9.7 Table 10 has
a failed transmission of the response restart A failed transmission of a response-pending message ends the service for that same
reason. Table 10’s row names a The anchor is cleared with the service because A confirmation answers only the service that submitted the transmission because
addressing alone does not tell two requests from one tester apart. ISO 14229-2:2021 9.2
REQ 5.19 has a server process a new request immediately after the |
While a service is in progress, the anchor shall be set to the timestamp of a
A confirmation answers the service in progress here as Rationale: A failed response-pending transmission sets no anchor: ISO 14229-2:2021 9.2 Table 4 footnote b counts transmissions, and one that failed did not reach the data link the footnote protects. |
The facts Rationale: a closed list of the requirements that may change these facts is what makes a
“changes nothing” claim elsewhere in the set checkable, and what lets The closed list also settles a request marked |
A response-pending message answering the service in progress is unconfirmed while
the association Rationale: |
On Table 3 defines The reception must be successful because 9.7 Table 10 requires the server to ignore a request whose reception failed. The marker is the filter for the first of ISO 14229-1:2020 8.7.6’s two exceptions, the
only conformant request that arrives while a response window is open and leaves the
service in progress running. The second exception, the OBD-range request, ends
the service in progress on its own reception under |
Low-Level Requirement: The response timer stops when a response is passed to the transport UDSS_LLR_0114
|
On Figure 11 stops the timer for both kinds: where the application does not have the positive response ready and issues a response-pending message, and where it issues the final response that concludes the service. Figure 10 states the same for a service that never goes response-pending. The final response must be solicited, meaning transmitted as the direct result of processing a request message, because a positive response may also be unsolicited: a periodic transmission is both, and stopping the timer for one would end the response window of the service actually in progress. The qualifier attaches to the final response alone. The response must answer the service in progress, as A response answering the service in progress so is the transmission whose confirmation
answers that service under |
Low-Level Requirement: The response timer stops on completion of a request with no response UDSS_LLR_0115
|
On the completion report of Figure 19 has a server that determines it need not answer a functionally-addressed
request stop the No response message is transmitted in either case, so no The marker is the filter that |
On Rationale: ISO 14229-1:2020 8.7.6 has a received message occupy the one diagnostic
protocol instance until it is processed, so a request arriving while a service is in
progress, other than the keep-alive TesterPresent, is refused with The association is still taken because the transmission still occupies the transport’s
addressing; |
Enhanced response timing¶
On The confirmation answers the service in progress as Table 3 defines The guard keeps a late confirmation from re-arming the timer for a service that has
ended: a completion report under A failed response-pending transmission opens no window. Table 3’s “transmission of a
negative response message (indicated via |
Low-Level Requirement: The server's response timer overrun is indicated to the application UDSS_LLR_0117
|
When the elapsed time since the Rationale: ISO 14229-2:2021 specifies The indication comes before the window closes rather than at its close because the
standard has the server act inside it. 10.1.3 Figure 11 note d has the application issue
the response-pending message by a The indication names the parameter because the application’s position differs between the
two. After The indication names the service in progress because after a replacement under
The timer is stopped so that one overrun yields one indication, rather than a further
indication for every timestamp the caller supplies thereafter. Elapsed time is computed
as |
The server shall have a response-pending lead: a protocol parameter, in the unit and
width Rationale: The first bound keeps the default window meaningful: a lead of |
Low-Level Requirement: A response-pending message is rejected while one is unconfirmed UDSS_LLR_0118
|
While a service is in progress under Rationale: the unconfirmed case fills a gap in ISO 14229-2:2021 9.2 Table 4 footnote b,
the footnote
This requirement refuses a transmission the caller has asked for. It obliges no server to
send a response-pending message, and states no time at which one is owed: the session
layer is the gatekeeper of a transmission the application originates. Whether a
response-pending message may be sent for the service in progress at all is fixed by that
service’s An |
While a service is in progress under Table 4 footnote b requires a minimum time of 0,3 × The footnote says “between the transmission of” without saying which end of a
transmission it means. This requirement measures from the completion, The spacing is rounded up because The interval between a This requirement refuses a transmission the caller has asked for. It obliges no server to
send a response-pending message, and states no time at which one is owed: the session
layer is the gatekeeper of a transmission the application originates. Whether the first
such message was admissible at all is fixed by the service’s |