Unified Diagnostic Services

Last updated

Unified Diagnostic Services (UDS) is a diagnostic communication protocol used in electronic control units (ECUs) within automotive electronics, which is specified in the ISO 14229-1. [1] It is derived from ISO 14230-3 (KWP2000) and the now obsolete ISO 15765-3 (Diagnostic Communication over Controller Area Network (DoCAN) [2] ). 'Unified' in this context means that it is an international and not a company-specific standard. By now this communication protocol is used in all new ECUs made by Tier 1 suppliers of Original Equipment Manufacturer (OEM), and is incorporated into other standards, such as AUTOSAR. The ECUs in modern vehicles control nearly all functions, including electronic fuel injection (EFI), engine control, the transmission, anti-lock braking system, door locks, braking, window operation, and more.

Contents

Diagnostic tools are able to contact all ECUs installed in a vehicle which has UDS services enabled. In contrast to the CAN bus protocol, which only uses the first and second layers of the OSI model, UDS utilizes the fifth and seventh layers of the OSI model. The Service ID (SID) and the parameters associated with the services are contained in the payload of a message frame.

Modern vehicles have a diagnostic interface for off-board diagnostics, which makes it possible to connect a computer (client) or diagnostics tool, which is referred to as tester, to the communication system of the vehicle. Thus, UDS requests can be sent to the controllers which must provide a response (this may be positive or negative). This makes it possible to interrogate the fault memory of the individual control units, to update them with new firmware, have low-level interaction with their hardware (e.g. to turn a specific output on or off), or to make use of special functions (referred to as routines) to attempt to understand the environment and operating conditions of an ECU to be able to diagnose faulty or otherwise undesirable behavior.

Services


SID (Service Identifier)

Function groupRequest   SIDResponse   SIDServiceDescription
Diagnostic and Communications Management0x100x50Diagnostic Session ControlUDS uses different operating sessions, which can be changed using the "Diagnostic Session Control". Depending on which session is active, different services are available. On start, the control unit is by default in the "Default Session". Other sessions are defined, but are not required to be implemented depending on the type of device:
3 sub functions 

1) 0x10 01-Default session 2) 0x10 02-Programming session 3) 0x10 03-Extended Diagnostic session

  • "Programming Session - 02" used to upload software.
  • "Extended Diagnostic Session- 03" used to unlock additional diagnostic functions, such as the adjustment of sensors.
  • "Safety system diagnostic session" used to test all safety-critical diagnostic functions, such as airbag tests.

In addition, there are reserved session identifiers that can be defined for vehicle manufacturers and vehicle suppliers specific use.

0x110x51ECU ResetThe service "ECU reset" is used to restart the control unit (ECU). Depending on the control unit hardware and implementation, different forms of reset can be used:
  • "0x11 01 Hard Reset" simulates a shutdown of the power supply.
  • "0x11 02 key off on Reset" simulates the drain and turn on the ignition with the key.
  • "0x11 03 Soft Reset" allows the initialization of certain program units and their storage structures.

Again, there are reserved values that can be defined for vehicle manufacturers and vehicle suppliers specific use.

0x270x67Security AccessSecurity check is available to enable the most security-critical services. For this purpose a "Seed" is generated and sent to the client by the control unit. From this "Seed" the client has to compute a "Key" and send it back to the control unit to unlock the security-critical services.
0x280x68Communication ControlWith this service, both the sending and receiving of messages can be turned off in the control unit.
0x290x69AuthenticationAn update (2020) of the standard added this service to provide a standardized approach to more modern methods of authentication than are permitted by the Security Access (0x27) service, including bidirectional authentication with PKI-based Certificate Exchange.
0x3E0x7ETester PresentIf no communication is exchanged with the client for a long time, the control unit automatically exits the current session and returns to the "Default Session" back, and might go to sleep mode. Therefore, there is an extra service which purpose is to signal to the device that the client is still present.
0x830xC3Access Timing ParametersIn the communication between the controllers and the client, certain times must be observed. If these are exceeded, without a message being sent, it must be assumed that the connection was interrupted. These times can be called up and changed.
0x840xC4Secured Data Transmission
0x850xC5Control DTC SettingsEnable or disable the detection of any or all errors. This is important when diagnostic work is performed in the car, which can cause an anomalous behavior of individual devices.
0x860xC6Response On Event
0x870xC7Link ControlThe Service Link Control is used to set the baud rate of the diagnostic access. It is usually implemented only at the central gateway.
Data Transmission0x220x62Read Data By IdentifierWith this service, it is possible to retrieve one or more values of a control unit. This can be information of all kinds and of different lengths such as Partnumber or the software version. Dynamic values such as the current state of the sensor can be queried. Each value is associated to a Data Identifier (DID) between 0 and 65535; for example, the VIN DID is 61840d (0xF190). Normal CAN signals are meant for information that some ECU uses in its functionality. DID data is sent on request only, and is for information that no ECU uses, but a service tool or a software tester can benefit from.
0x230x63Read Memory By AddressRead data from the physical memory at the provided address. This function can be used by a testing tool, in order to read the internal behaviour of the software.
0x240x64Read Scaling Data By Identifier
0x2A0x6ARead Data By Identifier PeriodicWith this service, values are sent periodically by a control unit. The values to be sent must be defined to only using the "Dynamically Define Data Identifier".
0x2C0x6CDynamically Define Data IdentifierThis service offers the possibility of a fix for a device specified Data Identifier (DID) pool to configure another Data Identifier. This is usually a combination of parts of different DIDs or simply a concatenation of complete DIDs.

The requested data may be configured or grouped in the following manner:

  • Source DID, position, length (in bytes), Sub-Function Byte: defineByIdentifier
  • Memory address length (in bytes), Sub-Function Byte: defineByMemoryAddress
  • Combinations of the two above methods through multiple requests.
0x2E0x6EWrite Data By IdentifierWith the same Data Identifier (DID), values can also be changed. In addition to the identifier, the new value is sent along.
0x3D0x7DWrite Memory By AddressThe “Write Memory By Address” service allows the external diagnostic tool to write information into the ECU at one or more contiguous memory locations.
Stored Data Transmission0x140x54Clear Diagnostic InformationDelete all stored DTC
0x190x59Read DTC InformationDTC stands for "Diagnostic Trouble Codes". Each DTC handled by the control unit fault is stored with its own code in the error memory and can be read at any time. In addition to the error, additional information will be stored, which can also be read.
Input / Output Control0x2F0x6FInput Output Control By IdentifierThis service allows an external system intervention on internal / external signals via the diagnostic interface.

By specifying a so-called option bytes additional conditions for a request can be specified, the following values are specified:

ReturnControlToECU: The device must get back controls of the mentioned signals.

ResetToDefault: The tester prompts to reset signals to the system wide default value.

Freeze Current State: The device shall freeze the current signal value.

ShortTermAdjustment: The device shall use the provided value for the signal

Remote Activation of Routine0x310x71Routine ControlControl routine services of all kinds can be performed. There are three different message types:
  • With the start-message, a service can be initiated. It can be defined to confirm the beginning of the execution or to notify when the service is completed.
  • With the Stop message, a running service can be interrupted at any time.
  • The third option is a message to query the results of the service.

The start and stop message parameters can be specified. This makes it possible to implement every possible project-specific service.

Upload / Download0x340x74Request DownloadDownloading new software or other data into the control unit is introduced using the "Request Download". Here, the location and size of the data is specified. In turn, the tester specifies how large the data packets can be.
0x350x75Request UploadThe service "request upload" is almost identical to the service "Request Download". With this service, the software from the control unit is transferred to the tester. The location and size must be specified. Again, the size of the data blocks are specified by the tester.
0x360x76Transfer DataFor the actual transmission of data, the service "Transfer Data" is used. This service is used for both uploading and downloading data. The transfer direction is notified in advance by the service "Request Download" or "Upload Request". This service should try to send packets at maximum length, as specified in previous services. If the data set is larger than the maximum, the "Transfer Data" service must be used several times in succession until all data has arrived.
0x370x77Request Transfer ExitA data transmission can be 'completed' when using the "Transfer Exit" service. This service is used for comparison between the control unit and the tester. When it is running, a control unit can answer negatively on this request to stop a data transfer request. This will be used when the amount of data (set in "Request Download" or "Upload Request") has not been transferred.
0x380x78Request File TransferThis service is used to initiate a file download from the client to the server or upload from the server to the client. Additionally information about the file system are available by this service.
0x7FNegative ResponseThis response is given when a service request could not be performed, for example having a not supported Data Identifier. A Negative Response Code will be included.

Negative response codes

Negative response from ECU contains SID 0x7F and two payload bytes: request's SID and error code. These codes can be found in freely available software (for example, BusMaster) as well as in the ISO itself.

NRCDescription
0x10General reject
0x11Service not supported
0x12Subfunction not supported
0x13Incorrect message length or invalid format
0x14Response too long
0x21Busy, repeat request
0x22Conditions not correct
0x24Request sequence error
0x25No response from subnet component
0x26Failure prevents execution of requested action
0x31Request out of range
0x33Security access denied
0x34Authentication failed
0x35Invalid key
0x36Exceeded number of attempts
0x37Required time delay not expired
0x38Secure data transmission required
0x39Secure data transmission not allowed
0x3ASecure data verification failed
0x50Certificate validation failed, invalid time period
0x51Certificate validation failed, invalid signature
0x52Certificate validation failed, invalid chain of trust
0x53Certificate validation failed, invalid type
0x54Certificate validation failed, invalid format
0x55Certificate validation failed, invalid content
0x56Certificate validation failed, invalid scope
0x57Certificate validation failed, invalid certificate
0x58Ownership verification failed
0x59Challenge calculation failed
0x5ASetting access right failed
0x5BSession key creation/derivation failed
0x5CConfiguration data usage failed
0x5DDeauthentication failed
0x70Upload download not accepted
0x71Transfer data suspended
0x72General programming failure
0x73Wrong block sequence number
0x78Request correctly received, response pending
0x7ESubfunction not supported in active session
0x7FService not supported in active session
0x81RPM too high
0x82RPM too low
0x83Engine is running
0x84Engine is not running
0x85Engine run time too low
0x86Temperature too high
0x87Temperature too low
0x88Vehicle speed too high
0x89Vehicle speed too low
0x8AThrottle/pedal too high
0x8BThrottle/pedal too low
0x8CTransmission range not in neutral
0x8DTransmission range not in gear
0x8FBrake switch not closed
0x90Shifter lever not in park
0x91Torque converter clutch locked
0x92Voltage too high
0x93Voltage too low
0x94Resource temporary unavailable

See also

Related Research Articles

<span class="mw-page-title-main">OSI model</span> Model of communication of seven abstraction layers

The Open Systems Interconnection model is a reference model from the International Organization for Standardization (ISO) that "provides a common basis for the coordination of standards development for the purpose of systems interconnection." In the OSI reference model, the communications between systems are split into seven different abstraction layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application.

<span class="mw-page-title-main">KNX</span> Standard in building automation

KNX is an open standard for commercial and residential building automation. KNX devices can manage lighting, blinds and shutters, HVAC, security systems, energy management, audio video, white goods, displays, remote control, etc. KNX evolved from three earlier standards; the European Home Systems Protocol (EHS), BatiBUS, and the European Installation Bus.

A controller area network is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other. It is a message-based protocol, designed originally for multiplex electrical wiring within automobiles to save on copper, but it can also be used in many other contexts. For each device, the data in a frame is transmitted serially but in such a way that if more than one device transmits at the same time, the highest priority device can continue while the others back off. Frames are received by all devices, including by the transmitting device.

<span class="mw-page-title-main">Electronic control unit</span> Automotive control system

An electronic control unit (ECU), also known as an electronic control module (ECM), is an embedded system in automotive electronics that controls one or more of the electrical systems or subsystems in a car or other motor vehicle.

A vehicle bus is a specialized internal communications network that interconnects components inside a vehicle. In electronics, a bus is simply a device that connects multiple electrical or electronic devices together. Special requirements for vehicle control such as assurance of message delivery, of non-conflicting messages, of minimum time of delivery, of low cost, and of EMF noise resilience, as well as redundant routing and other characteristics mandate the use of less common networking protocols. Protocols include Controller Area Network (CAN), Local Interconnect Network (LIN) and others. Conventional computer networking technologies are rarely used, except in aircraft, where implementations of the ARINC 664 such as the Avionics Full-Duplex Switched Ethernet are used. Aircraft that use AFDX include the B787, the A400M and the A380. Trains commonly use Ethernet Consist Network (ECN). All cars sold in the United States since 1996 are required to have an On-Board Diagnostics connector, for access to the car's electronic controllers.

Society of Automotive Engineers standard SAE J1939 is the vehicle bus recommended practice used for communication and diagnostics among vehicle components. Originating in the car and heavy-duty truck industry in the United States, it is now widely used in other parts of the world.

General Motors Local Area Network (GMLAN) is an application- and transport-layer protocol using controller area network for lower layer services. It was standardized as SAE J2411 for use in OBD-II vehicle networks.

<span class="mw-page-title-main">On-board diagnostics</span> Automotive engineering terminology

On-board diagnostics (OBD) is a term referring to a vehicle's self-diagnostic and reporting capability. In the United States, this self-diagnostic is a requirement to comply with Federal Emissions standards to detect failures that may increase the vehicle tailpipe emissions to more than 150% of the standard to which it was originally certified.

AUTomotive Open System ARchitecture (AUTOSAR) is a development partnership of automotive interested parties founded in 2003. It is focused on creating and establishing an open and standardized software architecture for automotive electronic control units (ECUs). Goals include the scalability to different vehicle and platform variants, transferability of software, the consideration of availability and safety requirements, a collaboration between various partners, sustainable use of natural resources, and maintainability during the product lifecycle.

<span class="mw-page-title-main">ISO 11783</span> Computer network protocol

ISO 11783, known as Tractors and machinery for agriculture and forestry—Serial control and communications data network is a communication protocol for the agriculture industry based on the SAE J1939 protocol.

OBD-II PIDs are codes used to request data from a vehicle, used as a diagnostic tool.

ISO 11992 is a CAN based vehicle bus standard by the heavy duty truck industry. It is used for communication between the tractor and one or more trailers. Its full title is "Road vehicles -- Interchange of digital information on electrical connections between towing and towed vehicles".

Keyword Protocol 2000, abbreviated KWP2000, is a communications protocol used for on-board vehicle diagnostics systems (OBD). This protocol covers the application layer in the OSI model of computer networking. The protocol is standardized by International Organization for Standardization as ISO 14230.

<span class="mw-page-title-main">CANape</span> Software tool by Vector Informatik

CANape is a software tool from Vector Informatik. This development software, widely used by OEMs and ECU suppliers of automotive industries is used to calibrate algorithms in ECUs at runtime.

CANoe is a development and testing software tool from Vector Informatik GmbH. The software is primarily used by automotive manufacturers and electronic control unit (ECU) suppliers for development, analysis, simulation, testing, diagnostics and start-up of ECU networks and individual ECUs. Its widespread use and large number of supported vehicle bus systems makes it especially well suited for ECU development in conventional vehicles, as well as hybrid vehicles and electric vehicles. The simulation and testing facilities in CANoe are performed with CAPL, a programming language.

ISO 15765-2, or ISO-TP (Transport Layer), is an international standard for sending data packets over a CAN-Bus. The protocol allows for the transport of messages that exceed the eight byte maximum payload of CAN frames. ISO-TP segments longer messages into multiple frames, adding metadata (CAN-TP Header) that allows the interpretation of individual frames and reassembly into a complete message packet by the recipient. It can carry up to 232-1 (4294967295) bytes of payload per message packet starting from the 2016 version. Prior version were limited to a maximum payload size of 4095 bytes.

<span class="mw-page-title-main">INCA (software)</span> Application software published by ETAS

INCA is a measurement, calibration and diagnostic software published by ETAS. With its large installation base in the auto industry, this development software is deployed during all phases of the development of electronic control units (ECUs) and ECU software programs for measuring, calibration, diagnostics and programming.

CAN FD is a data-communication protocol used for broadcasting sensor data and control information on 2 wire interconnections between different parts of electronic instrumentation and control system. This protocol is used in modern high performance vehicles.

Automotive security refers to the branch of computer security focused on the cyber risks related to the automotive context. The increasingly high number of ECUs in vehicles and, alongside, the implementation of multiple different means of communication from and towards the vehicle in a remote and wireless manner led to the necessity of a branch of cybersecurity dedicated to the threats associated with vehicles. Not to be confused with automotive safety.

References

  1. "Iso 14229-1:2020 Unified diagnostic services (UDS) Part 1: Application layer".
  2. "Iso 15765-3:2004 Diagnostics on Controller Area Networks (CAN) Part 3: Implementation of unified diagnostic services (UDS on CAN)".