Communication Control (0x28) Service in UDS Protocol

Leave a Comment / Protocols / By piembsystech

s://piembsystech.com/uds-protocol/" target="_blank" rel="noreferrer noopener">UDS (Unified Diagnostic Services) protocol – the Communication Control (0x28) service. This service plays a crucial role in managing how and when communication happens between an ECU and diagnostic tools. Whether you’re developing, testing, or debugging vehicle ECUs, understanding this service is essential for ensuring safe and effective communication handling. In this article, I’ll explain what the 0x28 service is, its main sub-functions, and where it’s commonly used in real-world applications. You’ll also learn how this service helps prevent unintended disruptions during critical operations. By the end, you’ll gain a clear and practical understanding of Communication Control in UDS. Let’s dive in!

Introduction to Communication Control (0x28) Service in UDS Protocol

Welcome to this deep dive into one of the essential services in UDS – the Communication Control service (0x28). This feature allows diagnostic tools to control the flow of communication with an ECU, especially during sensitive operations like programming or testing. By using this service, certain types of communication can be enabled or suppressed as needed. This is useful for preventing unintended interactions and maintaining system stability. In this article, we’ll explore the purpose of this service, how it works, and where it fits into the UDS framework. If you’re involved in automotive diagnostics or ECU development, this is a must-know concept. Let’s get started with understanding the mechanics of Communication Control in UDS!

What is Communication Control (0x28) Service in UDS Protocol?

The Communication Control (0x28) service is a part of the UDS (Unified Diagnostic Services) protocol, defined in the ISO 14229 standard. It allows a diagnostic tester (like a scan tool or PC-based software) to enable or disable certain types of communications on an Electronic Control Unit (ECU) during diagnostic sessions.

• This service is particularly useful when:
  • Performing sensitive operations like ECU programming or flashing.
  • Avoiding conflicting communication from other ECUs or devices on the same network.
  • Reducing bus traffic during testing or diagnostics.

• There are 3 types of communication types available which are,
  • 1. Normal communication message (0x01)
  • 2. Network management communication message (0x02)
  • 3. Both Normal communication messages and Network management communication messages (0x03)

Why do we need Communication Control (0x28) Service in UDS Protocol?

The Communication Control (0x28) service is essential in the UDS protocol because it allows precise control over ECU communication behavior during diagnostic sessions. Without this control, the ECU could send or receive messages that might interfere with critical operations like reprogramming, calibration, or testing.

1. Prevent Communication Interference

When performing critical tasks like ECU flashing or firmware updates, unwanted communication from other ECUs can interrupt or corrupt the process. These background messages can overload the CAN bus or cause the diagnostic session to fail. By using the Communication Control service, we can disable the transmission and reception of regular messages from the target ECU. This creates a controlled environment for the operation. It ensures that the diagnostic tool communicates without interference.

2. Ensure Safety During Diagnostics

Some ECUs are responsible for safety-critical systems such as braking or airbags. Sending or receiving messages during certain diagnostic procedures might cause unexpected behavior or system activation. The Communication Control service allows the tester to mute the ECU temporarily, ensuring that no unintended actions are triggered. This is especially useful during tests that should not affect the real-time operation of the vehicle. It helps maintain a safe diagnostic environment.

3. Reduce CAN Bus Traffic

A vehicle’s CAN network can be very busy, with multiple ECUs exchanging real-time data constantly. This traffic can overwhelm diagnostic tools or slow down operations. By using the 0x28 service to suppress unnecessary messages, we can reduce overall network load. This results in faster and more stable diagnostics, especially during system-level testing. It also helps testers focus on the ECU of interest without noise from others.

4. Support for Silent Mode Testing

In some scenarios, engineers want to monitor the behavior of the ECU without letting it interact with the rest of the network. This is called silent or passive testing. With Communication Control, the ECU can be configured to stop both transmitting and receiving messages. This lets testers observe internal operations without affecting or being affected by the surrounding environment. It’s ideal for debugging and performance evaluation.

5. Avoid Message Collisions

When multiple diagnostic tools are connected or when several ECUs respond at the same time, message collisions can occur on the bus. These collisions can lead to data corruption, missed messages, or diagnostic failures. The 0x28 service helps by temporarily disabling unnecessary communication from specific ECUs. This minimizes conflicts and ensures that only the intended messages are processed. It’s especially helpful in multi-ECU testing setups.

6. Control Specific Communication Types

The Communication Control service is versatile because it allows targeting specific communication types – such as normal communication or network management messages. This means you can disable one while keeping the other active, depending on the need. For example, you might stop normal data frames but keep session control messages running. This level of fine-grained control helps tailor diagnostics without fully disconnecting the ECU from the network.

7. Maintain Diagnostic Session Stability

During long-running diagnostic sessions, background communication or automatic responses from the ECU can unintentionally trigger session timeouts or errors. For example, unsolicited responses might clash with the tester’s expected replies, causing the session to reset. The Communication Control (0x28) service can help stabilize the session by disabling such unnecessary communication. This ensures that the tester maintains control over the session without disruptions, improving reliability during detailed diagnostics or programming.

Syntax of Request Message Frame Format of 0x28 SID

Data byte	Parameter Name	Byte Value
#1	Communication Control Request SID	0x28
#2	sub-function = [ control Type ]	0x00 – 0xFF
#3	Communication Type	0x00 – 0xFF
#4	Node Identification Number (high byte)	0x00 – 0xFF
#5	Node Identification Number (low byte)	0x00 – 0xFF
a The presence of the C parameter requires the control Type either being 0x04 or 0x05.

Request Message Data-Parameter

CommunicationType

This parameter is used to specify the type of communication to be controlled. The communicationType parameter is a bit-coded value, enabling the control of multiple communication types simultaneously.

NodeIdentificationNumber

This 2-byte parameter is used to identify a node on a sub-network within the vehicle that cannot be addressed using the addressing methods of the lower OSI layers 1 to 6. This parameter is only included if the sub-function parameter controlType is set to 0x04 or 0x05.

Syntax of 0x28 SID Positive Response Message Frame Format

Data byte	Parameter Name	Byte Value
#1	Communication Control +Ve Response SID	0x68
#2	sub-function = [ control Type ]	0x00 – 0x7F

Response Message Data-Parameter

ControlType

This parameter is an echo of bits 6 to 0 from the sub-function parameter of the request message.

Syntax of 0x28 SID Negative Response Message Frame Format

Data byte	Parameter Name	Byte Value
#1	Communication Control –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID = [ byte#1 ]	0x28
#3	Negative Response Code [ byte#1 ]	NRC

Sub-Function ID of (0x28) SID

0x28 Service provide following sub-functions.

Bits 6 – 0	Description
0x00	Enable Rx And Tx This value indicates that the reception and transmission of messages shall be enabled for the specified communication Type.
0x01	Enable Rx And Disable Tx This value indicates that the reception of messages shall be enabled and the transmission shall be disabled for the specified communication Type.
0x02	Disable Rx And Enable Tx This value indicates that the reception of messages shall be disabled and the transmission shall be enabled for the specified communication Type.
0x03	Disable Rx And Tx This value indicates that the reception and transmission of messages shall be disabled for the specified communication Type.
0x04	Enable Rx And Disable Tx With Enhanced Address Information This value indicates that the addressed bus master shall switch the related sub-bus segment to the diagnostic-only scheduling mode.
0x05	Enable Rx And Tx With Enhanced Address Information This value indicates that the addressed bus master shall switch the related sub-bus segment to the application scheduling mode.
0x06 – 0x3F	ISOSAE Reserved This range of values is reserved by this document for future definition.
0x40 – 0x5F	Vehicle Manufacturer Specific This range of values is reserved for vehicle manufacturer specific use.
0x60 – 0x7E	System Supplier Specific This range of values is reserved for system supplier specific use.
0x7F	ISOSAE Reserved This value is reserved by this document for future definition.

Supported Negative Response Codes (NRCs) of 0x28 SID

NRC	Description
0x12	sub-function Not Supported This NRC shall be sent if the sub-function parameter is not supported.
0x13	Incorrect Message Length Or Invalid Format This NRC shall be sent if the length of the message is wrong.
0x22	Conditions Not Correct Used when the server is in a critical normal mode activity and therefore cannot disable/enable the requested communication type.
0x31	Request Out Of Range The server shall use this response code, if it detects an error in the communication Type or node Identification Number parameter.

Example of Communication Control (0x28) Service in UDS Protocol

Here are the Examples of Communication Control (0x28) Service in UDS Protocol:

Communication Control Request Message Flow Example SBFID (0x01)

(disable transmission of network management messages):

The client requests to have a response message by setting the suppress Pos Rsp Msg Indication Bit (bit 7 of the sub-function parameter) to “FALSE” (‘0’).

Message direction	Client → Server
Message Type	Request
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Communication Control Request SID	0x28
#2	Control Type = Enable Rx And Disable Tx,                        suppress Pos Rsp Msg Indication Bit = FALSE	0x01
#3	Communication Type = network management	0x02

Communication Control Positive Response Message Flow Example SBFID (0x01)

Message direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Communication Control +Ve Response SID	0x68
#2	Sub-Function = [Control Type]	0x01

Communication Control Negative Response Message Flow Example SBFID (0x01)

Message direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Communication Control –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID = [ byte#1 ]	0x28
#3	Negative Response Code [ byte#1 ]	NRC

Communication Control Request Message Flow Example SBFID (0x04)

(switch a remote network into the diagnostic-only scheduling mode where the node with address 0x000A is connected to):

The client requests to have a response message by setting the suppress Pos Rsp Msg Indication Bit (bit 7 of the sub-function parameter) to “FALSE” (‘0’).

Message direction	Client → Server
Message Type	Request
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Communication Control Request SID	0x28
#2	Control Type=                                       enable Rx And Disable Tx With Enhanced Address Information, Suppress Pos Rsp Msg Indication Bit = FALSE	0x04
#3	Communication Type = normal messages	0x01
#4	Node Identification Number (high byte)	0x00
#5	Node Identification Number (low byte)	0x0A

Communication Control Positive Response Message Flow Example SBFID (0x04)

Message direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Communication Control +Ve Response SID	0x68
#2	Control Type =          enable Rx And Disable Tx With Enhanced Address Information,                 suppress Pos Rsp Msg Indication Bit = FALSE	0x04

Communication Control Negative Response Message Flow Example SBFID (0x04)

Message direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Communication Control –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID = [ byte#1 ]	0x28
#3	Negative Response Code [ byte#1 ]	NRC

Communication Control Request Message Flow Example SBFID (0x05)

(switch to application scheduling mode with enhanced address information, the node 0x000A, which is connected to a sub-network, is addressed):

The client requests to have a response message by setting the suppress Pos Rsp Msg Indication Bit (bit 7 of the sub-function parameter) to “FALSE” (‘0’).

Message direction	Client → Server
Message Type	Request
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Communication Control Request SID	0x28
#2	Control Type =            enable Rx And Tx With Enhanced Address Information, suppress Pos Rsp Msg Indication Bit = FALSE	0x05
#3	Communication Type = normal messages	0x01
#4	Node Identification Number (high byte)	0x00
#5	Node Identification Number (low byte)	0x0A

Communication Control Positive Response Message Flow Example SBFID (0x05)

Message direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Communication Control +Ve Response SID	0x68
#2	Control Type =           enable Rx And Tx With Enhanced Address Information, suppress Pos Rsp Msg Indication Bit = FALSE	0x05

Communication Control Negative Response Message Flow Example SBFID (0x05)

Message direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	Communication Control –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID = [ byte#1 ]	0x28
#3	Negative Response Code [ byte#1 ]	NRC

// Below example shows how to use the UDS commands over the CAN data field as per the DoCAN
// Example for Positive Response for SID-0x28
Request: Client --> Server
02 28 01
Positive Response: Server --> Client
02 68 01
// Example for Negative Response for SID-0x83
Request: Client --> Server
03 28 01
Positive Response: Server --> Client
03 7F 28 13

CAN Data Format for UDS (DoCAN Protocol)

UDS over CAN follows a specific format where the first byte indicates the length of the data, followed by the SID and sub-functions.

UDS Communication Control (SID: 0x28) – Command Explanation

In Unified Diagnostic Services (UDS), Service ID 0x28 (Communication Control) is used to enable or disable communication messages from the ECU. This is particularly useful during diagnostic operations to prevent unnecessary messages on the bus that might interfere with critical tasks.

Let’s break down the examples:

✅ Positive Response for SID 0x28 (Communication Control)

Request:

Client → Server: 03 28 01 01

• 03 → Indicates the length of the data following the PCI byte (3 bytes of actual data).
• 28 → Service ID (SID) for Communication Control.
• 01 → Sub-function of 0x28.
• 01 → Communication control type. In this case, 01 may mean “Enable Rx and Tx” (depends on OEM specification).

Positive Response:

Server → Client: 03 68 01 01

• 03 → Length of the response data.
• 68 → Positive response code for SID 0x28 (0x28 + 0x40 = 0x68).
• 01 → Sub-function of 0x28.
• 01 → Echoed communication control type (same as requested).

This confirms that the ECU successfully processed the request and the specified communication mode is now active.

❌ Negative Response for SID 0x28 (Communication Control)

Request:

Client → Server: 02 28 01 01

• 02 → Length of the data (2 bytes follow).
• 28 → SID for Communication Control.
• 01 → Sub-function of 0x28.
• 01 → Communication control type.

This might appear valid, but here, the data or the context of the request could be incorrect (e.g., unsupported session or control type), which leads to a negative response.

Negative Response:

Server → Client: 03 7F 28 13

• 03 → Length of the data.
• 7F → Indicates a negative response.
• 28 → Original service that caused the error (SID).
• 13 → Negative Response Code (NRC). Here, 0x13 means “Incorrect message length or invalid format.”

This means the ECU rejected the request either due to the incorrect message length or due to invalid parameters being sent. It’s a feedback mechanism that helps the diagnostic tool correct its behavior.

Summary of the 0x28 SID Example:

• SID 0x28 (Communication Control) is used to control the message transmission of the ECU.
• A positive response (0x68) confirms that the command was successfully accepted.
• A negative response (0x7F + SID + NRC) helps the diagnostic tester understand what went wrong.
• NRC 0x13 specifically indicates issues with message length or format, guiding developers to review the structure of the request.

Advantages of Communication Control (0x28) Service in UDS Protocol

Here are the key advantages of the Communication Control (0x28) Service in UDS Protocol:

1. Improves Diagnostic Accuracy: The Communication Control service filters out messages from unnecessary ECUs, allowing only the targeted ECU to communicate. This reduces noise and irrelevant data on the bus, making the diagnostics more focused. It becomes easier to identify faults without external interference. This precision helps in quicker fault detection and resolution. Especially during root cause analysis, clean data is vital.
2. Enhances Network Stability: By silencing non-essential ECUs, the communication bus is relieved of excess traffic. This improves the speed and reliability of diagnostic commands and responses. Reduced load also means fewer transmission errors. It ensures smooth performance during heavy testing scenarios. This is important in multi-ECU systems or during extended test cycles.
3. Increases Safety During Testing: Critical systems like airbags or braking ECUs can be temporarily silenced to avoid unintentional activation. This protects technicians and the vehicle from unexpected behavior during testing. It ensures a controlled environment, especially in garages or testing facilities. This feature adds a layer of safety during invasive diagnostic work. Safety-critical functions remain isolated.
4. Supports Controlled Testing Environments: Engineers can silence all ECUs except the one under test, creating a focused setup. This reduces background noise and helps simulate specific scenarios. It also allows repeatable testing conditions for verification. Controlled environments improve test result accuracy. It’s especially useful in development or debugging phases.
5. Prevents Message Conflicts: When multiple ECUs try to send messages simultaneously, collisions can occur. Communication Control ensures that only desired ECUs are active, minimizing overlap. This helps in maintaining data integrity on the CAN network. It reduces error frames and ensures smoother operation. Conflict-free communication is vital in high-speed data networks.
6. Facilitates Safe ECU Programming: Background messages can disrupt ECU flashing or firmware updates. This service creates a silent communication environment, allowing updates without interruptions. It minimizes the risk of corrupted files or failed uploads. It’s especially important during remote diagnostics or over-the-air updates. A clean network ensures programming reliability.
7. Provides Granular Communication Control: The service lets you disable either reception, transmission, or both for selected ECUs. This flexibility is useful when partial communication is needed. For example, an ECU can receive commands but not respond. It gives testers more control over communication flow. This level of customization enhances diagnostic precision.
8. Enables Silent Mode Testing: In silent mode, the ECU doesn’t transmit but still receives and operates internally. This allows developers to observe how it behaves in isolation. It’s helpful for logging internal errors or passive data monitoring. No network disturbances occur during this mode. It’s useful in test benches or live vehicles under observation.
9. Improves System Integration Testing: During integration, isolating a single ECU with this service helps detect interaction issues. Developers can identify which ECU causes failure during multi-module operations. It ensures each ECU performs correctly before full system testing. This step-by-step approach reduces debugging time. It’s crucial in large automotive systems.
10. Maintains Diagnostic Session Stability: Some ECUs may send unsolicited messages that disrupt diagnostic sessions. Disabling them ensures continuous communication between tester and target ECU. This helps avoid unexpected timeouts or session drops. It’s especially important during long tests or data logging. Stable sessions mean more efficient diagnostics.

Disadvantages of Communication Control (0x28) Service in UDS Protocol

Here are the key disadvantages of the Communication Control (0x28) Service in UDS Protocol:

1. May Cause Incomplete Network Behavior: Silencing certain ECUs can prevent normal interactions from occurring, leading to test results that don’t represent real-world behavior. Some functions depend on the communication between multiple ECUs, and disabling a few may affect the logic flow. This might lead to overlooked faults or misdiagnosis. Therefore, results must be interpreted carefully when communication control is active.
2. Risk of Misuse During Testing: Improper use of this service, such as disabling the wrong ECUs, can result in false errors or system instability. For example, disabling ECUs responsible for system clock or data synchronization may halt dependent modules. Such misuse can slow down testing or even damage the test environment. It requires experienced personnel to operate correctly.
3. Can Mask Existing Communication Faults: If some ECUs are silenced, it becomes harder to identify issues like communication dropouts or data corruption that occur during full system operation. These problems may go undetected until later stages. This can lead to late-stage development issues or post-deployment bugs. Full testing without communication control is also essential.
4. Not Supported by All ECUs: Some ECUs might not implement the 0x28 service or may respond unpredictably to the request. This inconsistency can make it difficult to apply this feature across all modules in a vehicle. It limits its use in certain projects or systems. Compatibility must be confirmed before relying on this service.
5. May Interrupt Safety Features: Disabling communication for safety-critical ECUs can halt safety mechanisms such as ABS, ESC, or airbag deployment logic. In real vehicles, this is dangerous if not properly managed. It must only be used in controlled environments like test labs. Caution is essential during live vehicle diagnostics.
6. Potential for Session Timeout: If communication is stopped from the tester ECU or session-control ECUs, the UDS session might timeout. This can break ongoing diagnostic tasks, leading to the need for reinitialization. Repeated resets may impact productivity. Proper timing and sequencing are necessary to avoid interruptions.
7. Increased Complexity in Test Automation: Automated test frameworks must account for active/inactive ECUs when using this service. Managing communication states programmatically adds complexity. This can increase development time and costs for automated systems. It also requires robust test logic to avoid inconsistency.
8. Difficulty in Multi-ECU Debugging: During issues involving multiple ECUs, communication control can obscure the root cause. If ECUs are silenced, cross-communication bugs might not surface. This could delay identification of critical interaction errors. It’s better to use this service selectively during such cases.
9. Can Affect Real-Time Behavior Analysis: Disabling live communication affects timing and synchronization, especially in systems requiring real-time data exchange. This may lead to unrealistic performance benchmarks. In time-critical systems like infotainment or ADAS, real-time analysis is compromised. Accuracy is lost without full communication.
10. May Lead to Over-Reliance During Development: Developers may get too comfortable using this feature to isolate ECUs, avoiding proper system-level testing. This habit can create gaps in testing that show up later in production. A balance between isolated and full-network testing is necessary. It should be used as a support tool, not a dependency.

Future Development and Enhancement of Communication Control (0x28) Service in UDS Protocol

Below are the Future Development and Enhancement of Communication Control (0x28) Service in UDS Protocol:

1. Improved Granular Control Over ECUs: Future updates may allow even more precise control over individual message types within an ECU rather than just enabling or disabling full transmission or reception. This will allow testers to manage specific signals or PIDs selectively, offering better diagnostics and debugging efficiency without silencing useful data.
2. Integration with Secure Diagnostics: As cybersecurity becomes crucial, Communication Control could integrate with secure diagnostic sessions to prevent unauthorized activation. Enhanced authentication mechanisms may be built-in before allowing any communication changes. This will ensure safer testing environments, especially in remote or over-the-air diagnostics.
3. Dynamic Communication Adjustment: Upcoming implementations might support real-time communication toggling based on network traffic or system load. ECUs could automatically adjust their communication behavior to prioritize critical messages. This dynamic nature would improve efficiency in complex vehicle networks without human intervention.
4. Advanced Logging During Silence Mode: Future ECUs might log internal behavior while being in silent mode, allowing post-analysis even when external communication is disabled. This will help engineers study how ECUs behave internally without affecting the CAN bus. Such features could be vital in autonomous vehicle diagnostics.
5. User-Friendly Test Interface Integration: OEM diagnostic tools may offer better graphical interfaces for enabling/disabling communication with drag-and-drop ECU selection. This enhancement will simplify usage and reduce the chance of operator error. It’s a key improvement for workshops and test engineers with less experience.
6. Support for Higher Bandwidth Protocols: As automotive networks move towards Ethernet and CAN FD, Communication Control services may evolve to support faster data rates and larger payloads. This will ensure consistent operation across mixed-protocol networks and make UDS more scalable for future vehicles.
7. AI-Based Communication Suggestions: In the future, diagnostic tools could use AI to analyze past sessions and suggest which ECUs to silence for efficient testing. This intelligent decision-making will streamline test plans and avoid unnecessary manual decisions. It will be helpful in large-scale validation setups.
8. Session-Scoped Communication Control: Enhancements could include automatic reset of communication states after a session ends, ensuring that no ECU remains unintentionally disabled. This prevents persistent miscommunication after diagnostics. It will safeguard against issues that arise from leftover configurations.
9. Cloud-Based Communication Management: With the rise of connected vehicles, cloud diagnostic platforms may include remote communication control capabilities. Engineers can manage ECU communication from anywhere during over-the-air diagnostics. This enhances convenience and support for fleet-wide updates or monitoring.
10. Improved Compatibility Across OEMs: Future UDS protocol updates may standardize Communication Control behavior across different vehicle manufacturers. This will reduce inconsistencies and allow better interoperability between tools and vehicles. A more unified approach ensures smoother workflow for multi-brand service centers.