py_uds_demo
Overview
py_uds_demo is a Python package for learning and practicing the Unified Diagnostic Services (UDS) protocol. It provides a simulator with CLI, GUI, and Web interfaces, allowing users to send diagnostic requests and view responses as per ISO 14229.
Features
- UDS protocol simulation (ISO 14229)
- CLI, GUI (CustomTkinter), and Web (Gradio) interfaces
- Diagnostic session management, data transmission, input/output control, and more
- Extensible and modular codebase
source manual
UdsClient()
A client for sending UDS requests and formatting responses.
This class interfaces with the UdsServer to send diagnostic requests and process the corresponding responses.
Attributes:
| Name | Type | Description |
|---|---|---|
server |
UdsServer
|
An instance of the UdsServer to process requests. |
Initializes the UdsClient.
This creates a new instance of the UdsServer, which will be used for processing all UDS requests initiated by this client.
format_request(request)
Formats a UDS request list into a human-readable string.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
request
|
list
|
A list of integers representing the request bytes. |
required |
Returns:
| Type | Description |
|---|---|
str
|
A string representation of the UDS request, with each byte |
str
|
formatted as a two-digit hexadecimal number. |
send_request(data_stream, return_formatted_stream)
Sends a UDS request to the server and retrieves the response.
The request is logged, processed by the server, and the response is also logged. The response can be returned as either a raw list of bytes or a formatted string.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
Union[list, list[int]]
|
The request data to send to the server, as a list of integers. |
required |
return_formatted_stream
|
bool
|
If True, the response is returned as a formatted string. Otherwise, it is returned as a list of integers. |
required |
Returns:
| Type | Description |
|---|---|
Union[list, str]
|
The server's response, which can be either a list of bytes or a |
Union[list, str]
|
formatted string, depending on the value of |
UdsServer()
Implements the UDS server functionality.
This class initializes all supported UDS services, constants, and response handlers. It provides a method to process incoming diagnostic requests and route them to the appropriate service handler.
Attributes:
| Name | Type | Description |
|---|---|---|
DEFAULT_LOG_FILE |
str
|
The default path for the log file. |
logger |
Logger
|
The logger instance for the server. |
SID |
Sid
|
Service identifiers. |
SFID |
Sfid
|
Sub-function identifiers. |
NRC |
Nrc
|
Negative response codes. |
did |
Did
|
Diagnostic identifiers. |
memory |
Memory
|
Memory map and data. |
positive_response |
PositiveResponse
|
Handler for positive responses. |
negative_response |
NegativeResponse
|
Handler for negative responses. |
diagnostic_and_commmunication_management |
NegativeResponse
|
Diagnostic and communication management service handler. |
data_transmission |
NegativeResponse
|
Data transmission service handler. |
stored_data_transmission |
NegativeResponse
|
Stored data transmission service handler. |
input_output_contol |
NegativeResponse
|
Input/output control service handler. |
remote_activation_of_routine |
NegativeResponse
|
Remote activation of routine service handler. |
upload_download |
NegativeResponse
|
Upload/download service handler. |
supported_services
property
Returns a list of all supported UDS service identifiers (SIDs).
Returns:
| Type | Description |
|---|---|
list
|
A list of integers representing the supported SIDs. |
process_request(data_stream)
Processes an incoming UDS request and returns a response.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
A list of integers representing the incoming diagnostic request bytes. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of integers representing the response to the request. |
Did()
Diagnostic Identifiers (DIDs) for UDS.
This class contains constants for various diagnostic identifiers.
Memory()
A simulated memory map for the UDS server.
This class holds memory addresses, their corresponding values, and other data like DTCs and writable DIDs.
Attributes:
| Name | Type | Description |
|---|---|---|
writable_dids |
list
|
A list of DIDs that are writable. |
did_data |
dict
|
A dictionary to store data for DIDs. |
memory_map |
dict
|
A dictionary representing the memory layout. |
dtcs |
list
|
A list of Diagnostic Trouble Codes. |
ecu_installation_date
property
The ECU installation date.
ecu_manufacturing_date
property
The ECU manufacturing date.
ecu_serial_number
property
The ECU serial number.
exhaust_regulation_type_approval_number
property
The exhaust regulation type approval number.
manufacturer_ecu_software_number
property
The manufacturer's ECU software number.
manufacturer_ecu_software_version
property
The manufacturer's ECU software version.
manufacturer_spare_part_number
property
The manufacturer's spare part number.
programming_date
property
The programming date.
repair_shop_code
property
The repair shop code.
supported_functional_units
property
The supported functional units.
system_supplier_ecu_software_number
property
The system supplier's ECU software number.
system_supplier_ecu_software_version
property
The system supplier's ECU software version.
vehicle_identification_number
property
The vehicle identification number (VIN).
Nrc()
Negative Response Codes (NRCs) for UDS.
This class contains constants for all negative response codes as defined in the ISO 14229 standard. Each NRC has a long name and a short alias.
See Also
ISO 14229
Sfid()
Sub-function Identifiers (SFIDs) for UDS.
This class contains constants for all sub-function identifiers as defined in the ISO 14229 standard. Each SFID has a long name and a short alias.
See Also
ISO 14229
Sid()
Service Identifiers (SIDs) for UDS.
This class contains constants for all service identifiers as defined in the ISO 14229 standard. Each SID has a long name and a short alias.
See Also
ISO 14229
split_integer_to_bytes(value)
Splits an integer into a list of bytes (little-endian).
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
value
|
int
|
The integer to split. |
required |
Returns:
| Type | Description |
|---|---|
list[int]
|
A list of integers, where each integer is a byte. |
NegativeResponse()
Handles the creation of negative UDS responses.
Initializes the NegativeResponse handler.
check_subfunction_supported(sfid, supported_subfunctions)
Checks if a sub-function is supported.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
sfid
|
int
|
The sub-function identifier to check. |
required |
supported_subfunctions
|
list
|
A list of supported sub-function identifiers. |
required |
Returns:
| Type | Description |
|---|---|
bool
|
True if the sub-function is supported, False otherwise. |
report_negative_response(sid, nrc)
Constructs a negative response message.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
sid
|
int
|
The service identifier of the request. |
required |
nrc
|
int
|
The negative response code. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of integers representing the complete negative response |
list
|
message. |
PositiveResponse()
Handles the creation of positive UDS responses.
Initializes the PositiveResponse handler.
report_positive_response(sid, data)
Constructs a positive response message.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
sid
|
int
|
The service identifier of the request. |
required |
data
|
list
|
A list of integers representing the response data. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of integers representing the complete positive response |
list
|
message, including the positive response SID. |
AccessTimingParameter(uds_server)
Handles Access Timing Parameter (0x83) service requests.
What
This service is used to read or write the communication timing parameters between the client and the server.
Why
In certain situations, like on slow or high-latency networks, it may be necessary to adjust the default timing parameters (e.g., P2, P2*) to ensure reliable communication.
How
The client can send a request to read the current timing parameters or to set new ones.
Real-world example
A diagnostic tool is connected to an ECU over a wireless network, which has a higher latency than a direct wired connection. To prevent communication timeouts, the tool uses this service to extend the timing parameters, allowing more time for responses.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
supported_subfunctions |
A list of supported sub-function identifiers. |
|
timing_parameters |
A dictionary of timing parameters. |
process_request(data_stream)
Processes an Access Timing Parameter request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
CommunicationControl(uds_server)
Handles Communication Control (0x28) service requests.
What
This service is used to control the communication of the server (ECU) on the network. It can enable or disable the transmission and/or reception of certain types of messages.
Why
It's useful for isolating an ECU during diagnostics or to prevent interference during sensitive operations like software flashing. For example, you can stop an ECU from sending messages that might disrupt other nodes on the network while you are reprogramming it.
How
The client sends a request with the SID 0x28, a sub-function to specify the control type (e.g., enableRxAndTx, disableRx), and a parameter for the communication type (e.g., normal communication, network management).
Real-world example
Before updating the firmware on an airbag control unit, a technician's tool sends a Communication Control request to disable the transmission of normal messages from that ECU. This prevents the ECU from sending any potentially conflicting messages during the update. Once the update is complete, the tool re-enables communication.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
supported_subfunctions |
A list of supported sub-function identifiers. |
|
supported_communication_types |
A list of supported communication types. |
|
supported_sessions |
A list of sessions in which communication control is allowed. |
process_request(data_stream)
Processes a Communication Control request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
ControlDtcSetting(uds_server)
Handles Control DTC Setting (0x85) service requests.
What
This service is used to enable or disable the setting of Diagnostic Trouble Codes (DTCs) in the server (ECU).
Why
During maintenance or testing, some actions might trigger false DTCs. This service allows a client to temporarily disable DTC reporting to avoid filling the fault memory with irrelevant codes.
How
The client sends a request with the SID 0x85 and a sub-function to either enable (0x01) or disable (0x02) DTC setting.
Real-world example
A technician is replacing a sensor. To prevent the ECU from storing a DTC for the disconnected sensor during the replacement process, they first use this service to disable DTC setting. After the new sensor is installed, they re-enable it.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
supported_subfunctions |
A list of supported sub-function identifiers. |
|
supported_sessions |
A list of sessions in which this service is allowed. |
|
dtc_setting |
The current DTC setting (ON or OFF). |
process_request(data_stream)
Processes a Control DTC Setting request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
DiagnosticSessionControl(uds_server)
Handles Diagnostic Session Control (0x10) service requests.
What
This service is used to switch the server (ECU) to a specific diagnostic session. Each session can grant different levels of access to diagnostic services and data.
Why
Different tasks require different security levels. For example, reading basic data might be allowed in a default session, but reprogramming the ECU would require switching to a programming session with higher security access.
How
The client sends a request with the SID 0x10 followed by a single byte sub-function indicating the desired session.
Real-world example
A technician uses a diagnostic tool to connect to a car. The tool starts in the default session, which allows reading error codes. To perform a software update, the tool requests to switch to the programming session. If the security checks pass, the ECU switches to the programming session, allowing the update to proceed.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
active_session |
The currently active diagnostic session. |
|
supported_subfunctions |
A list of supported sub-function identifiers. |
|
P2_HIGH |
int
|
P2 timing parameter high byte. |
P2_LOW |
int
|
P2 timing parameter low byte. |
P2_STAR_HIGH |
int
|
P2* timing parameter high byte. |
P2_STAR_LOW |
int
|
P2* timing parameter low byte. |
tester_present_active |
bool
|
True if Tester Present is active. |
session_timeout |
int
|
The timeout for non-default sessions in seconds. |
__del__()
Stops the session timeout thread.
process_request(data_stream)
Processes a Diagnostic Session Control request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
EcuReset(uds_server)
Handles ECU Reset (0x11) service requests.
What
This service is used to restart an ECU. Different types of resets can be performed, such as a hard reset (simulating a power cycle) or a soft reset (re-initializing software).
Why
An ECU reset is often necessary to recover an ECU from a faulty state, to apply new settings, or to complete a software update process.
How
The client sends a request with the SID 0x11 followed by a single byte sub-function indicating the desired reset type.
Real-world example
After successfully flashing a new firmware version to an ECU, a technician sends an ECU Reset request with the 'hardReset' sub-function. This forces the ECU to restart, loading the new firmware and completing the update process.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
supported_subfunctions |
A list of supported sub-function identifiers. |
process_request(data_stream)
Processes an ECU Reset request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
LinkControl(uds_server)
Handles Link Control (0x87) service requests.
What
This service is used to control the baud rate of the communication link between the client and the server.
Why
It can be used to switch to a higher baud rate for faster data transfer, which is particularly useful for time-consuming operations like software flashing.
How
The process typically involves the client first verifying that the server can support the new baud rate and then sending a command to transition to it.
Note
This service is not fully implemented in this simulator.
process_request(data_stream)
Processes a Link Control request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A negative response, as this service is not supported. |
ResponseOnEvent(uds_server)
Handles Response On Event (0x86) service requests.
What
This service allows a client to request that the server (ECU) automatically sends a response when a specific event occurs, instead of the client having to poll for it.
Why
It's useful for monitoring real-time events without the overhead of continuous polling. For example, a client can be notified immediately when a DTC is set or a sensor value crosses a certain threshold.
How
The client sends a request to register an event (e.g., onDtcStatusChange) and specifies the response that the server should send when that event occurs.
Note
This service is not fully implemented in this simulator.
process_request(data_stream)
Processes a Response On Event request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A negative response, as this service is not supported. |
SecuredDataTransmission(uds_server)
Handles Secured Data Transmission (0x84) service requests.
What
This service is used to transmit data securely between the client and the server, providing cryptographic protection for the data.
Why
It's used when sensitive data needs to be exchanged over a potentially insecure network, ensuring confidentiality and integrity.
How
The implementation details, including the cryptographic algorithms, are typically manufacturer-specific.
Note
This service is not fully implemented in this simulator.
process_request(data_stream)
Processes a Secured Data Transmission request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A negative response, as this service is not supported. |
SecurityAccess(uds_server)
Handles Security Access (0x27) service requests.
What
This service provides a security mechanism to protect certain services from unauthorized access. It uses a seed-and-key exchange to authenticate the client.
Why
It's crucial to prevent unauthorized users from accessing critical ECU functions, such as flashing new software, changing the VIN, or modifying calibration data.
How
The client requests a 'seed' from the ECU. Using a secret algorithm, the client calculates a 'key' from the seed and sends it back. If the key is correct, the ECU grants access to protected services.
Real-world example
A manufacturer protects the engine's fuel map from being modified. To change the fuel map, a diagnostic tool must first use the Security Access service. The tool requests a seed, calculates the key, and sends it back. If successful, the tool can then use the Write Data By Identifier service to update the fuel map.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
seed_value |
The last generated seed. |
|
seed_sent |
True if a seed has been sent to the client. |
|
security_unlock_success |
True if the ECU is unlocked. |
|
supported_subfunctions |
A list of supported sub-function identifiers. |
|
supported_sessions |
A list of sessions in which security access is allowed. |
process_request(data_stream)
Processes a Security Access request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
TesterPresent(uds_server)
Handles Tester Present (0x3E) service requests.
What
This service is used to indicate to the server (ECU) that a client is still connected and that the current diagnostic session should remain active.
Why
If there is no communication for a certain period, the ECU will automatically time out and return to the default diagnostic session. The Tester Present service prevents this from happening.
How
The client periodically sends a request with the SID 0x3E. A sub-function can be used to either request a response from the server or suppress it.
Real-world example
A technician is monitoring live data from a sensor, which requires the ECU to be in the extended diagnostic session. To prevent the session from timing out while they are observing the data, the diagnostic tool sends a Tester Present message every few seconds.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
tester_present_request_received |
True if a Tester Present request has been received. |
|
supported_subfunctions |
A list of supported sub-function identifiers. |
process_request(data_stream)
Processes a Tester Present request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response, or an empty list if the |
list
|
response is suppressed. |
DynamicallyDefineDataIdentifier(uds_server)
Handles Dynamically Define Data Identifier (0x2C) service requests.
What
This service allows a client to dynamically define a new Data Identifier (DID) at runtime. This new DID can be composed of data from other existing DIDs or from specific memory addresses.
Why
It's useful when you need to read a combination of data that is not available in a single, predefined DID. Instead of sending multiple requests, you can create one dynamic DID to get all the data in a single response, which can be more efficient.
How
The client sends a request with the SID 0x2C and the definition of the new DID, which includes the source DIDs or memory addresses.
Note
This service is not fully implemented in this simulator.
process_request(data_stream)
Processes a Dynamically Define Data Identifier request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A negative response, as this service is not supported. |
ReadDataByIdentifier(uds_server)
Handles Read Data By Identifier (0x22) service requests.
What
This service is used to read data from the server (ECU), identified by a 2-byte Data Identifier (DID). It's one of the most common UDS services.
Why
It provides a standardized way to read a wide variety of data, such as sensor values, configuration settings, part numbers, software versions, and more.
How
The client sends a request with the SID 0x22 followed by one or more 2-byte DIDs. The server responds with the SID 0x62, the requested DID(s), and the corresponding data.
Real-world example
A workshop tool needs to verify the software version of an ECU. It sends a Read Data By Identifier request with the DID for the software version (e.g., 0xF188). The ECU responds with the version, which the tool then displays to the technician.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
process_request(data_stream)
Processes a Read Data By Identifier request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
ReadDataByPeriodicIdentifier(uds_server)
Handles Read Data By Periodic Identifier (0x2A) service requests.
What
This service is used to request that the server (ECU) periodically transmits the data values for one or more Data Identifiers (DIDs).
Why
It's an efficient way to monitor data over time without the need for the client to continuously send requests. This is useful for data logging or for displaying live data on a diagnostic tool.
How
The client sends a request with the SID 0x2A, specifying the DIDs to be read and the transmission rate. The server then starts sending the data periodically until instructed to stop.
Note
This service is not fully implemented in this simulator.
process_request(data_stream)
Processes a Read Data By Periodic Identifier request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A negative response, as this service is not supported. |
ReadMemoryByAddress(uds_server)
Handles Read Memory By Address (0x23) service requests.
What
This service is used to read data from a specific memory address in the server (ECU).
Why
It provides a low-level way to access the ECU's memory, which is useful for debugging, reverse engineering, or accessing data that is not available through a Data Identifier (DID).
How
The client sends a request with the SID 0x23, followed by the memory address and the number of bytes to read. The server responds with the SID 0x63 and the requested data.
Real-world example
A software developer is debugging a new feature and wants to inspect the value of a variable in real-time. They use the Read Memory By Address service to read the memory location where that variable is stored, helping them to understand its behavior.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
process_request(data_stream)
Processes a Read Memory By Address request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
ReadScalingDataByIdentifier(uds_server)
Handles Read Scaling Data By Identifier (0x24) service requests.
What
This service is used to retrieve the scaling information for a data value that is returned by the ReadDataByIdentifier service.
Why
Some data values are transmitted as scaled integers to save space or for other reasons. This service provides the necessary information (e.g., a formula or a lookup table) to convert the raw integer value into a physical value (e.g., a floating-point number with a unit).
How
The client sends a request with the SID 0x24 and a DID. The server responds with the scaling information for that DID.
Note
This service is not fully implemented in this simulator.
process_request(data_stream)
Processes a Read Scaling Data By Identifier request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A negative response, as this service is not supported. |
WriteDataByIdentifier(uds_server)
Handles Write Data By Identifier (0x2E) service requests.
What
This service is used to write data to the server (ECU) at a location specified by a Data Identifier (DID).
Why
It's used to change the ECU's behavior or update its configuration. This can include things like setting a new speed limit, updating the VIN, or changing calibration values.
How
The client sends a request with the SID 0x2E, the DID to be written, and the data to write. The server responds with the SID 0x6E and the DID that was written to confirm the operation.
Real-world example
A car manufacturer wants to update the service date in the instrument cluster. A technician uses a diagnostic tool to send a Write Data By Identifier request with the DID for the service date and the new date. The instrument cluster then updates its display accordingly.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
process_request(data_stream)
Processes a Write Data By Identifier request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
WriteMemoryByAddress(uds_server)
Handles Write Memory By Address (0x3D) service requests.
What
This service is used to write data to a specific memory address in the server (ECU).
Why
It provides a low-level way to modify the ECU's memory, which is useful for debugging, applying patches, or writing data to memory locations that are not accessible through a Data Identifier (DID).
How
The client sends a request with the SID 0x3D, the memory address, and the data to be written. The server responds with the SID 0x7D to confirm the operation.
Real-world example
A developer needs to apply a small patch to the ECU's software without performing a full reflash. They can use the Write Memory By Address service to write the patched code directly into the specified memory locations.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
process_request(data_stream)
Processes a Write Memory By Address request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
ClearDiagnosticInformation(uds_server)
Handles Clear Diagnostic Information (0x14) service requests.
What
This service is used to clear Diagnostic Trouble Codes (DTCs) from the server's (ECU's) memory.
Why
After a vehicle has been repaired, the stored DTCs related to the fixed issue need to be cleared. This service provides the means to do so.
How
The client sends a request with the SID 0x14, followed by a 3-byte groupOfDTC parameter, which specifies which DTCs to clear. A value of 0xFFFFFF is typically used to clear all DTCs.
Real-world example
A "Check Engine" light is on. A technician reads the DTCs and finds a code for a faulty sensor. After replacing the sensor, the technician uses this service to clear the DTC, which turns off the light.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
process_request(data_stream)
Processes a Clear Diagnostic Information request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
ReadDtcInformation(uds_server)
Handles Read DTC Information (0x19) service requests.
What
This service is used to read Diagnostic Trouble Codes (DTCs) and related data from the server's (ECU's) memory.
Why
It's the primary service for diagnosing vehicle problems. By reading DTCs, a technician can identify the system or component that is faulty. It also allows reading additional data, like "freeze frames" or "snapshot data," which is a snapshot of the vehicle's state at the time the fault occurred.
How
The client sends a request with the SID 0x19 and a sub-function that specifies what information to read (e.g., number of DTCs, DTCs by status mask, snapshot data).
Real-world example
A technician connects a diagnostic tool to a car with the "Check Engine" light on. The tool uses this service with the 'reportDTCByStatusMask' sub-function to retrieve all active DTCs. The tool might then use another sub-function to read the snapshot data for a specific DTC to get more context about when the fault occurred.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
process_request(data_stream)
Processes a Read DTC Information request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
InputOutputControlByIdentifier(uds_server)
Handles Input Output Control By Identifier (0x2F) service requests.
What
This service allows a client to take control of a server's (ECU's) inputs and outputs.
Why
It's used for testing and diagnostics. For example, a technician can use it to manually activate an actuator (like a fan or a motor) to verify its operation, or to simulate a sensor input to see how the ECU responds.
How
The client sends a request with the SID 0x2F, a Data Identifier (DID) to specify the I/O channel, and a control option (e.g., return control to ECU, freeze current state, short term adjustment).
Real-world example
A technician suspects a radiator fan is faulty. They use a diagnostic tool to send an Input Output Control By Identifier request to the engine control unit, commanding it to turn on the fan. If the fan starts, the technician knows the fan motor is working and the issue lies elsewhere, perhaps with the temperature sensor or control logic.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
io_control_status |
A dictionary to store the status of I/O controls. |
process_request(data_stream)
Processes an Input Output Control By Identifier request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
RoutineControl(uds_server)
Handles Routine Control (0x31) service requests.
What
This service is used to start, stop, and request the results of a routine in the server (ECU).
Why
Routines are used to perform more complex tasks than what can be achieved with a simple read or write service. This can include things like running a self-test, erasing memory, or learning new adaptive values.
How
The client sends a request with the SID 0x31, a sub-function (e.g., startRoutine, stopRoutine, requestRoutineResults), and a 2-byte routine identifier.
Real-world example
A technician wants to perform a self-test on the ABS. They use a diagnostic tool to send a Routine Control request with the 'startRoutine' sub-function and the routine identifier for the ABS self-test. After the routine completes, they send another request with 'requestRoutineResults' to check if the test passed.
Attributes:
| Name | Type | Description |
|---|---|---|
uds_server |
UdsServer
|
The UDS server instance. |
routine_status |
A dictionary to store the status of routines. |
process_request(data_stream)
Processes a Routine Control request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A list of bytes representing the response. |
RequestDownload(uds_server)
Handles Request Download (0x34) service requests.
What
This service is used to initiate a data download from the client to the server (ECU). It's the first step in the process of flashing new software or writing a large block of data to the ECU.
Why
It prepares the ECU to receive data, and the ECU can specify the maximum size of the data blocks it can accept at a time.
How
The client sends a request with the SID 0x34, the memory address where the data should be stored, and the total size of the data.
Note
This service is not fully implemented in this simulator.
process_request(data_stream)
Processes a Request Download request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A negative response, as this service is not supported. |
RequestFileTransfer(uds_server)
Handles Request File Transfer (0x38) service requests.
What
This service provides a more advanced and flexible way to transfer files between the client and the server, often with file-system-like operations.
Why
It's designed to be more powerful than the older upload/download services, supporting more complex use cases.
How
The specifics are complex and can vary between implementations.
Note
This service is not fully implemented in this simulator.
process_request(data_stream)
Processes a Request File Transfer request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A negative response, as this service is not supported. |
RequestTransferExit(uds_server)
Handles Request Transfer Exit (0x37) service requests.
What
This service is used to terminate a data transfer sequence.
Why
It signals the end of the upload or download process, allowing the server to perform any necessary cleanup or verification.
How
The client sends a request with the SID 0x37 to indicate that the transfer is complete.
Note
This service is not fully implemented in this simulator.
process_request(data_stream)
Processes a Request Transfer Exit request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A negative response, as this service is not supported. |
RequestUpload(uds_server)
Handles Request Upload (0x35) service requests.
What
This service is used to initiate a data upload from the server (ECU) to the client.
Why
It's used to read large blocks of data from the ECU, such as log files, calibration data, or the entire memory content.
How
The client sends a request with the SID 0x35, the memory address of the data to be uploaded, and the size of the data.
Note
This service is not fully implemented in this simulator.
process_request(data_stream)
Processes a Request Upload request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A negative response, as this service is not supported. |
TransferData(uds_server)
Handles Transfer Data (0x36) service requests.
What
This service is used to transfer data blocks between the client and the server during an upload or download operation.
Why
It's the workhorse of the data transfer process, responsible for moving the actual data in chunks.
How
After a download or upload is initiated, the client (for downloads) or server (for uploads) sends a sequence of Transfer Data requests, each containing a block of data.
Note
This service is not fully implemented in this simulator.
process_request(data_stream)
Processes a Transfer Data request.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
data_stream
|
list
|
The request data stream. |
required |
Returns:
| Type | Description |
|---|---|
list
|
A negative response, as this service is not supported. |