UDS (iso14229-2006) Translation (No.6 Application layer Service)

6.1 Overview

application-tier services are often used as diagnostic services. The application-tier service is used to perform functions in a client-server-based system (client-server Base system), such asdetection, inspection, monitoring, and diagnostics for in-vehicle servers (ECUs). The client usually refers to an external test device. The application-tier service sends a request for diagnostic functions to several ECUs. part of the ECU's functionality feeds the diagnostic data to the client through the application-tier service when the diagnostic service is requested. The client is generally a non-vehicle tester connected to the can bus, and in some systems it is also the role of a vehicle tester. The Application Layer service use case is independent of the on-board or non-vehicle diagnostic instrument as a client. More than one diagnostic instrument may be present in the same vehicle system.

The diagnostic application-level access point provides a defined amount of services with a similar overall structure, and defines six service primitives for each service:

--The service request primitive (primitive), which is used for client diagnostics, transmits the diagnostic service's request data to the diagnostic application layer's functionality.

--Service Request Confirmation Primitives (a service request-confirmation primitive), which is used for client diagnostics to instruct the request service primitive data to be fully transmitted to the server.

--Service indicator primitives (a servicesindication primitive), which are used to diagnose the function of theapplication layer to transmit data to the server's ECU diagnostic application.

--Service response primitives (a servicesresponse primitive) for ECU diagnostic applications in the server pass data from the request diagnostic service to the diagnostic application layer.

--Service Response Confirmation Primitives (a service response-confirmation primitive) for the server's ECU diagnostic application function, This function indicates that the data emitted by the response service primitive is intact transmitted to the client.

--Service Confirmation Primitives (a service confirmation primitive) for diagnosing the application layer sending data to the diagnostic instrument.

Figure 4--application Layer Service primitives--confirm service ( Application Layer Services primitive-validation service)

Figure 5--Application layer service primitive--unconfirmed service ( Application Layer Services primitive-non-confirmation service)

For a given service, the request primitive and the instruction primitive usually have the same service data unit . ISO 14229 lists only the parameters of the Service data unit that are subordinate to each request primitive . The user should assume that the same parameters correspond exactly to each corresponding Service indicator primitive .

For a given service, the response primitive and the acknowledgment primitive usually have the same service data unit. ISO 14229 lists only the parameters of the Service data unit SDU that are subordinate to each response primitive . The user should assume that the same parameters correspond exactly to each corresponding instruction service primitive .

For each response service primitive (and the Response service acknowledgment primitive), two different SDU (two service data units, two different sets of parameters) were developed. When the diagnostic service request is successfully executed by the ECU's diagnostics, a set of parameters is used by the positive response of the service primitive, and if the diagnostic service request is not executed in a timely and successful manner by the ECU's diagnostics, the other set of parameters for the negative response is used.

For a given service, the request - service acknowledgment primitive and the response - service acknowledgment primitives generally have the same SDU. The purpose of these service primitives is to indicate that a call to the previous request / Response Service Primitive was completed. The services described by ISO14229 do not use these service primitives, but the specific implementation documentation for the data link may be defined using these service primitives, such as the base point for service execution (for example, the Ecureset service performs an ECU reset after the ECU responds fully to the client), Then the Ecureset is being responded to in the server - confirming the service declaration.

6.2 Application Layer Service format definition

The application-tier service has two different formats depending on the configuration of the vehicle diagnostic system.

If the servers and clients are directly connected to a configured vehicle system diagnostic network, the default (normal, standard) Application Layer Diagnostic service format will come in handy. This format is compatible with diagnostic system formats running on K or L lines. The default application-tier service format will be presented in 6.3 ways.

The application-layer service remote format is suitable for vehicle systems implementing local and remote server concepts. The remote format has an additional address parameter, called the remote address. Remote formats are used to access servers that do not directly connect to the primary diagnostics network. The application-tier service remote format is described in 6.4.

6.3 Format description for standard service primitives

6.3.1 General Definitions

All application-tier services have the same general format, and the service primitives are written as follows:

Service_name.type (
Parameter A, parameter B, parameter C
[, Parameter 1, ...]
)

Explain:

--"service_name" means the name of the diagnostic service (e.g., diagnostic reply control Diagnosticsessioncontrol)

--"Type" indicates the service primitive type (e.g.: request)

--"Parametera, parameter B, parameter C" the necessary parameters contained in the service invocation

--"[Parameter1, ...]" Some parameters that depend on a particular service (for example: Parameter1 as the Diagnosticsession small item for the Diagnosticsessioncontrol service). Parentheses indicate that the part parameter is an optional parameter.

6.3.2 Service request and service indication primitives

For each application-tier service, the service request and service indicator primitives are specified according to the following general format:

Service_name.request (
Sa
Ta
Ta_type,
[, Parameter 1, ...],
)

The request primitive is used for diagnostic instrument application function, which describes the service and data sending of the request Diagnosis Service to the application layer .

Service_name.indication (
Sa
Ta
Ta_type,
[, Parameter 1, ...]
)

Indicates that the primitive is used by the application layer to specify an internal event from the application layer to the ECU Diagnostic application , and transmits the request diagnostic function to the ECU to diagnose the application's server function data.

The request and indicator primitives for the specific application-tier service typically have the same parameters and parameter values, which means that when data is transferred from the client to the server, the values of each parameter should not be changed by the communication Peer protocol entity of the application layer. The same value is transferred to the application tier by the client application's client functionality in the service request and is received by the server feature of the diagnostic application (the diagnostic application is part of the service acknowledgment of the diagnostic application side. ）

6.3.3 Service response and service acknowledgement primitives

For each identified application-tier service, the service response Primitives and service acknowledgment primitives are specified according to the following format:

Service_name.response (
Sa
Ta
Ta_type
Result
[, Parameter 1, ...]
)

The response primitives are used in the ECU diagnostic application's server function to start the service and transmit response data from the request diagnostic service to the application tier.

Service_name.confirm (
Sa
Ta
Ta_type,
Result,
[, Parameter 1, ...]
)

Confirm that the primitive is used for the application layer to specify an internal event from the application tier to the client application, and the event transmits the results of the client functionality in the previous Service request diagnostic instrument. It does not necessarily indicate any active remote interfaces, such as: The request service is not supported by the server, or the communication is interrupted.

For a particular application layer, the response primitive and the confirmation primitive often have the same parameters and parameter values. This means that when data is transferred from the server to the client, the values of each parameter should not be changed by the communication Peer protocol entity of the application layer. The same value is transferred to the application tier by the client application's client functionality in the service request and is received by the server feature of the diagnostic application (the diagnostic application is part of the service acknowledgment of the diagnostic application side. ）

Two different service data units [SDU](two sets of parameters) are defined for each response and acknowledgment primitive:

-If the ECU's server function correctly performs the request diagnostic service, the affirmative response and confirmation primitives should be used for the first service data single element.

-A negative response primitive and confirmation primitive will be used for the second service data unit if the request diagnostic service fails or is not completed at the specified time by the ECU's server function.

6.3.4 Service Request Confirmation primitives and service response confirmation primitives

For each application-tier service, the service request confirmation primitives and service response acknowledgment primitives are specified in the following general format.

Service_name.req_confirm (
TAK
Ta
Ta_type,
Result
)

The request confirmation primitive is an application layer-to-client internal event defined by the application layer, which transmits the results of the last service request to the diagnostic instrument-the client function.

Service_name.rsp_confirm (
Sa
Ta
Ta_tpye,
Result
)

The response acknowledgment primitive is used by the application layer to specify an internal event from the application layer to the client and transmits the results of the previous service response to the ECU Application-server function .

6.4 Format description for remote service primitives

6.4.1 General Definitions

If you use the application-layer remote format, you can diagnose communication between the local client and the remote server. All defined default formats that are used as application-tier services apply.

UDS (iso14229-2006) Translation (No.6 Application layer Service)