Hello‎‎ Readers,
My‎‎ name‎‎ is‎‎ Aravind‎‎ B‎‎ N,‎‎ and‎‎ I‎‎ work‎‎ at‎‎ "Luxoft‎‎ India"‎‎ as‎‎ a‎‎ Junior‎‎ Software‎‎ Developer.‎‎ Luxoft‎‎ has‎‎ given‎‎ me‎‎ several‎‎ opportunities‎‎ to‎‎ work‎‎ on‎‎ various‎‎ projects,‎‎ which has inspired me to discuss the important processes involved in developing and learning the Universal Measurement and Calibration Protocol in detail Part-1. This is part 2 continuous part of Universal Measurement and Calibration Protocol

Model‎‎ of‎‎ communication‎‎ XCP
Communication, in the XCP model involves the interaction between a master and slave through exchanging data using a message based approach. This method includes encapsulating the XCP message frame within a transport layer frame, including the XCP header and tail. It is commonly seen in XCP implementations on Ethernet with UDP protocols

The diagram illustrates that‎‎ XCP‎‎ Packet

The structure of an XCP packet consists of three elements regardless of the transport protocol used; the Identification Field, Timestamp Field and Data Field. Each element starts with a Packet Identifier (PID) for identification purposes.

Data exchange in XCP occurs between a master and slave on either a frame or packet basis. This exchange involves two types of communication; Command Transfer Objects (CTOs) for command exchange to establish connections between master and slave and Data Transfer Objects (DTOs) for exchanging measurement and stimulation data. Both methods ensure that the slave responds with either RES or ERR as necessary.

The abbreviations mentioned here refer to terms or concepts;

1. Send commands using CMD Command Packets.
2. Receive command responses using RES Command Response Packets.
3. Obtain answers through packets.
4. Receive error responses through ERR Error Packets.
5. Manage events using EV Event Packets.
6. Make service requests using SERV Service Request Packets.
7. Transmit measurement data via DAQ Data Acquisition.
8. Stimulate the slave with STIM Stimulation commands.
9. Perform debugging tasks through DBG Debugging via XCP slaves.
10. Flash new data into control units indicated by PGM Programming status changes.
11. Change calibration pages, with CAL Calibration/Paging switches.

XCP‎‎ Master-Slave‎‎ Status‎‎ Exchange

In electronic control units (ECUs) the XCP slave and the ECU application can function independently. The XCP slave may remain active when the ECU application is not running or it may be inactive. It communicates its status to the XCP master using the GET_STATUS command. The XCP slave shares information, about its status, protected resources, authentication, through seed and key and other relevant details. If the XCP slave is capable of sending event messages it will transmit an EV_ECU_STATE_CHANGE event to the XCP master allowing the master to obtain updated details using the GET_STATUS command.

Mode‎‎ of‎‎ Standard‎‎ Communication

The diagram illustrates the‎‎ standard‎‎ exchange

The individual, in charge initiates a request. Awaits the response, from the subordinate before issuing another directive.

Mode‎‎ of‎‎ Master‎‎ Block‎‎ Transfer

The diagram illustrates the Master Block Transfer Mode

where the master can issue commands to a slave without waiting for responses. The block transfer mode is an option to speed up data transfers. Its crucial to consider performance factors and communication settings like time intervals, between commands and the maximum number of commands sent before receiving a response. The master has the ability to obtain these configurations from the slave by utilizing the GET_COMM_MODE_INFO command.

Mode‎‎ of‎‎ Slave‎‎ Block‎‎ Transfer

The diagram illustrates the Mode‎‎ of‎‎ Slave‎‎ Block‎‎ Transfer

Next we have the Slave Block Transfer Mode depicting how the slave can send frames to the master to optimize time especially when updating data status. The command used for this is UPLOAD, in XCP. It's worth mentioning that the restrictions discussed for Master Block Transfer Mode don't come into play when we talk about Block Transfer Mode from the masters end as the master consistently delivers performance.

Mode‎‎ of‎‎ Interleaved‎‎ Communication

Lastly we have Interleaved Communication Mode illustrated in another diagram.

In conversations we often pause to let each other speak before responding. However in communication mode data transmission happens faster as the master can send requests one, after another while considering the buffer size of the slaves. Similarly slaves can respond consecutively without restrictions from the master. It's worth noting that this mode cannot coexist with block mode since it is optional and not relevant.

In XCP there are three modes. Standard, Block and Interleaved. That facilitate the exchange of commands and responses between the Master and Slave.

The CAN communication model adheres to a standard where each request to a Slave elicits one response. This ensures that each XCP message can be easily traced back to its Slave.

While the block transfer mode is optional it proves advantageous, for handling data transfers involving amounts of data. However performance considerations should be taken into account when utilizing this mode. Specific time intervals (MIN_ST) should be maintained between commands and the total number of commands should not exceed a set limit (MAX_BS). The Master can obtain communication settings from the Slave using the GET_COMM_MODE_INFO function. Nevertheless these limitations do not apply to block transfer mode as PCs typically have capabilities to manage data from a microcontroller.

Interleaved mode can also be selected as an option. It doesn't hold importance.

This‎‎ concept‎‎ will‎‎ be‎‎ covered‎‎ more‎‎ in‎‎ the‎‎ next‎‎ article,‎‎ with‎‎ examples.

Do‎‎ let‎‎ me‎‎ know‎‎ if‎‎ you‎‎ have‎‎ any‎‎ queries‎‎ in‎‎ the‎‎ comments‎‎ below.

Thanks‎‎ for‎‎ reading.