Server session timer¶
Requirements governing the server’s tS3_Server timer, which keeps a non-default
diagnostic session active while the client that requested it continues to communicate.
The server’s session state¶
The server holds three facts. The first is whether the active session is the default
session, one bit. The identifier of the active session is not state: UDSS_LLR_0065’s
selection does not carry it and nothing in this set reads it. The second is the
controlling client, the S_AI[SA] and, where S_Mtype carries one, the
S_AI[AE] of the client whose request produced the active non-default session, held only
while a non-default session is active. The third is the tS3_Server timer.
Which client a given input came from is read from a different parameter in each case. On a
T_Data.conf it is the confirmation’s own S_AI[TA] and, where S_Mtype carries
one, its S_AI[AE], which UDSS_LLR_0046 marks valid on a confirmation and which
UDSS_LLR_0088 and UDSS_LLR_0093 already rely on. On a completion report it is the
addressing UDSS_LLR_0074 carries. On a T_DataSOM.ind or a T_Data.ind it is
S_AI[SA].
The keep-alive that bypasses the request¶
ISO 14229-1:2020 8.7.6 exempts one message from the rule that a server handles one request
at a time: the functionally addressed TesterPresent whose positive response is suppressed,
which the clause defines as keep-alive logic to be handled by bypass logic so that it
cannot block the server’s application layer. The server’s caller marks that message
keep-alive under UDSS_LLR_0065.
The standard shows TesterPresent in two figures, one per message. ISO 14229-2:2021 10.1.4.1
Figure 12 is the functionally addressed one without a response: key m has it reload a
running tS3_Server, and key j lets the server ignore one received while another service
is in progress. 10.1.4.2 Figure 13 is the physically addressed one with a response, which
keys l and p have stop the timer as any request does. The marker picks between them: marked,
UDSS_LLR_0095 and UDSS_LLR_0096 apply; unmarked, UDSS_LLR_0087 does.
ISO 14229-2:2021 9.5 says the server has no need to distinguish the two kinds of TesterPresent handling, and that holds for the restart both readings end in.
Assumptions of use¶
Five obligations fall on the caller rather than on the session layer, and are recorded as assumptions of use in the qualification repository.
The caller marks
keep-aliveexactly the functionally addressed TesterPresent whose positive response is suppressed, marks nothing else so, and never marks a message that carries a session selection.UDSS_LLR_0065states that the session layer does not verify the marker against the addressing;UDSS_LLR_0067rejects the marker with a selection onS_Data.reqandUDSS_LLR_0068on the completion report ofUDSS_LLR_0074, the two inputs the caller composes; an indication so classified is forwarded underUDSS_LLR_0036.The caller supplies the completion report of
UDSS_LLR_0074for every request, from any client, for which no response message is transmitted. Two are excepted: a marked keep-alive, whose report is optional and whichUDSS_LLR_0096makes inert if supplied, and a request aborted under ISO 14229-1:2020 8.7.6’s OBD-range exception, whose report is optional because the same clause has the OBD request start the default session, which the bullet below obliges the caller to carry as a session selection, soUDSS_LLR_0098disables the timer and the aborted request’s own restart underUDSS_LLR_0089is moot.Whether to answer a session-selecting request from a client other than the controlling one positively is the application’s decision. ISO 14229-1:2020 Annex J (informative) J.4 Table J.2 shows a server answering NRC 0x21 instead while it is in a non-default session a different client requested.
The caller supplies a session selection under
UDSS_LLR_0065on every message by which the server changes session, whichever service carries it: DiagnosticSessionControl, ECUReset, or the OBD-range request that ISO 14229-1:2020 8.7.6 has abort the active service and start the default session outside the programming session, on its response where one is sent and on the request otherwise.ISO 14229-2:2021 9.5 Table 5’s tolerance on
tS3_Server, and the application-layer session transition itself, are the application’s.
What this document does not cover¶
The application-layer consequences of a session change. UDSS_LLR_0100 sets the
precedent: the session layer returns its own state to the default session and reports what
happened, and the application applies what the change means above it.
tP2_Server is Server response timing’s, including the marked keep-alive’s
non-effect on it. The client’s timers are Client session timer’s.
ISO 14229-2:2021 9.5 Table 6’s last row refers the tS3_Server handling of unsolicited
responses to the data link specific documents of the ISO 14229 series. Nothing beyond what
UDSS_LLR_0091 transcribes from ISO 14229-5:2022 is stated here.
A session change the server makes with neither a message nor a completion to classify. A
real ECU reset re-initialises the instance, which UDSS_LLR_0083 covers; a reset that
leaves the instance running is covered by the session selection on the ECUReset positive
response, which UDSS_LLR_0098 acts on.
The timer’s state¶
Low-Level Requirement: The server keeps one session fact, one controlling client and one session timer UDSS_LLR_0082
|
The server shall keep, in the instance, whether the active session is the default
session, the controlling client while a non-default session is active, and one
Table 8 allocates a single Throughout this document a message is from the controlling client, and a response is
to the controlling client, where its |
On initialisation the server shall be in the default session, shall hold no controlling
client, and Rationale: clause 9.2 has the server start the default session when powered up, which is
the one fact the standard states; that is the initial state an earlier requirement of
this document stated until it was retired into this one. None of the requirements
permitted to change the controlling client or |
Low-Level Requirement: What changes the session fact, the controlling client and the session timer UDSS_LLR_0084
|
After the server is initialised, the session fact and the controlling client shall change
only as Rationale: |
Low-Level Requirement: A confirmed response selecting a non-default session starts the session timer UDSS_LLR_0085
|
On The later-request exception is The solicitation qualifier is The requester is the confirmation’s This requirement widens Table 6, and says so here. Table 6’s initial-start rows cover the
transition from the default session to a non-default one only, and The condition is a session selection, not a service. The session layer cannot know which
service a message carries ( |
Low-Level Requirement: A completed session-selecting request without response starts the session timer UDSS_LLR_0086
|
On the completion report of This is Table 6’s second initial-start row: successful completion of the requested action
for a transition to a non-default session, where no response message is required or
allowed. The widening beyond that row’s transition out of the default session, and the
reasons for it, are |
Low-Level Requirement: Session timer stops when a request from the controlling client begins UDSS_LLR_0087
|
While in a non-default session, on a Both primitives are named without asking whether a The marked message is |
While in a non-default session, on The 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. Without the qualifier this requirement and The exception covers a non-default selection as well as the return to default because
The later-request exception keeps Table 6’s order of events. Table 6 pairs the stop on
reception of a request with the restart on completion of the final response, and
ISO 14229-2:2021 9.2 REQ 5.19 has the server process a new request immediately after the
|
Low-Level Requirement: Session timer restarts on completion of a request with no response UDSS_LLR_0089
|
While in a non-default session, on the completion report of Table 6 gives completion of the requested action, where no response message is required
or allowed, as a subsequent start condition, and 10.1.4.1 bounds when that completion
occurs: a diagnostic service is in progress until the completion of any action caused by
the request, the point in time that would otherwise have started the response. The same
clause states that any diagnostic service, TesterPresent included, restarts the timer.
The exception widens with |
Low-Level Requirement: A response-pending negative response does not restart the session timer UDSS_LLR_0090
|
While in a non-default session, on |
While in a non-default session, on A transmission triggered by a periodic scheduler or an internal event, rather than by a client request, must not keep a session alive. Otherwise a periodic transmission with an interval shorter than the session timeout would hold a non-default session open indefinitely. ISO 14229-5:2022 8.9.2 states the rule for any unsolicited transmitted response message
without asking whether the transmission succeeded, and the failed case is named here so
that a periodic transmission that keeps failing cannot hold the session open through
|
While in a non-default session, while The guard on the timer is Table 10’s own precondition. Its restart is stated “because it
has been stopped based on the previously received StartOfMessage indication”, and the
corresponding row of 9.5 Table 6 names an error during the reception of a multi-frame
request message, the case in which a Table 10 says the server shall ignore the request. That is read as the request having no
effect on the session or its timer beyond the restart Table 10 itself requires, and as
there being nothing for the application to act on: The marked message is excluded because a failed reception of it while another service is
in progress would otherwise restart the timer mid-request, the harm |
While in a non-default session, on Table 10 gives the reason for the restart: the timer was stopped by the request that
the failed response answers. Where that request came from any other client the timer
was never stopped, The later-request exception is An unsolicited response is excluded because Table 10’s reason never holds for it: no
request stopped the timer on its behalf, and ISO 14229-5:2022 8.9.2 forbids any
unsolicited transmitted response message to restart The exclusion stops there: a failed transmission of a response-pending message restarts the timer as Table 10 states. Table 6’s sentence that a negative response with code 78 does not restart the timer is written for a completed transmission, and Table 10’s row names any response with a negative result. The reading is coherent with the client’s side: a pending message that never arrived leaves the client’s default window to expire, and 9.7 Table 9 has the client repeat the request, so from the peer’s side the exchange is over. |
On ISO 14229-2:2021 9.7 Table 10 states the prohibition in terms. Its response-transmission
row gives, for a This requirement carries none of the three qualifiers ISO 14229-5:2022 8.9.2, which |
On ISO 14229-1:2020 8.7.6 is cited because it defines the message: the functionally addressed TesterPresent with its positive response suppressed, which the clause names keep-alive logic to be processed by bypass logic so that it cannot block the server’s application layer. The timer behaviour itself is ISO 14229-2’s. The figures distinguish three situations. A running timer is reloaded, which is Figure 12
keys m and o; “reload” is read here as a restart of a running timer only, a declared
reading, key m stating the effect for a message received during an activated timer. A
stopped timer, the service in progress having stopped it, is left alone, which is Figure
12 key j and Figure 20 key d, both saying such a message “can be ignored” because the
service in progress restarts the timer on its own completion under The permission to ignore is taken rather than declined because an early restart would let
The marker is what picks between the bypass handling of Figure 12 keys j and m and Figure
20 key d, transcribed here, and the ordinary request handling of Table 6 under
|
On Rationale: where Where it is not from the controlling client, No completion report is needed for the marked message, |
While in a non-default session, a request message not from the controlling client shall
not start, stop, or reload the Clause 9.5 gives this requirement its purpose: only the client that requested the
non-default session controls it, and no other client can affect the The two exceptions are session selections the application made. Returning the server to
the default session is neither keeping that session alive nor taking it over, and Table 6
states without qualification that the timer is disabled while the default session is
active. Moving the server to a non-default session is a hand-over the application chose
by answering positively, and |
While in a non-default session, on Table 6 states that the The condition is the selection, not the service, because the session layer cannot tell
services apart ( |
While in the default session, reception of a request, marked Figure 12 key p and Figure 20 key j state the TesterPresent case. The requirement is
stated for any request because the session layer cannot recognise a TesterPresent
( |
While in a non-default session, when the elapsed time since the Rationale: the session layer standard specifies only that this timer keeps a non-default
session active while no request is received; it does not specify the resulting
transition, which belongs to the application layer. ISO 14229-1:2020 10.2.2.2 Table 25 is
where that layer states it, naming a session layer timeout in the server as one of the
ways the programming session is left. This requirement declines to implement that
application-layer consequence, leaving it to the application on the session-timeout
indication, exactly as |