Inter-core communication method and apparatus for domain controller, domain controller, and storage medium

Abstract

The present application discloses an inter-core communication method and apparatus for a domain controller, a domain controller, and a storage medium. The method comprises: sending a session request message to a first core, and receiving a session response message sent by the first core; and when the session response message indicates that a session is successfully established, receiving a data packet sent by the first core, wherein data in the data packet is compressed data. According to embodiments of the present application, since the data in the data packet is the compressed data, the amount of transmitted data is reduced, thereby improving the data transmission efficiency. Moreover, after a session connection with the first core is established by means of the session request, the first core sends the data packet, thereby avoiding the problem of data loss caused by data transmission immediately after the first core is started, thus improving the data transmission reliability.

Description

Inter-core communication methods, devices, domain controllers, and storage media for domain controllers

[0001] This application claims priority to Chinese Patent Application No. 202510006004.9, filed on January 2, 2025, entitled “Method, Apparatus, Domain Controller and Storage Medium for Inter-core Communication of Domain Controllers”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of domain controller technology, and in particular to a method, apparatus, domain controller and storage medium for inter-core communication of a domain controller. Background Technology

[0003] With the steady development of centralized electronic and electrical architectures, many manufacturers often deploy two computing units in the central domain controller: an MPU (Micro Processor Unit) and a MCU (Micro Controller Unit). This is a combination of a real-time core and a high-performance core. Many manufacturers choose the S32G as the main control chip for their central domain controllers. The S32G is equipped with ARM Cortex-A53 (A-core) and Cortex-M7 (M-core) cores. The S32GM core, based on AUTOSAR CP, acts as an MCU, handling CAN / LIN signals, vehicle control, and other applications with high real-time requirements. The S32G A-core runs Linux or QNX systems, acting as an MPU, primarily used to run high-performance application software, such as big data collection and analysis, over-the-air (OTA) updates for vehicles, and remote diagnostics. The M-core and A-core can transmit data and collaborate via the IPCF (Inter-Processor Communication Framework) to achieve complex software function development.

[0004] In current MCU applications, log uploading is a crucial function, enabling real-time monitoring of system status and helping developers quickly identify and resolve potential problems or faults. Logs provide detailed records of system behavior, facilitating fault tracing and root cause analysis, especially when problem reproduction is difficult. Furthermore, the MPU startup time in the S32G is 5 seconds slower than that of the MCU. Adding log printing and storage functionality to the MCU can record its operational status during these 5 seconds. When controllers are geographically dispersed, log uploading allows technical support teams to remotely obtain device operating information, providing rapid response and support. Through efficient log uploading strategies, developers can not only improve system reliability and stability but also continuously optimize product functionality and user experience.

[0005] In existing technologies, when the first core (such as the M core) and the second core (such as the A core) based on IPCF communicate log data, the first core directly transmits log data to the second core after startup. At this time, the second core may not be ready, resulting in data loss. Moreover, the amount of data transmitted is large, resulting in low log communication transmission efficiency. Summary of the Invention

[0006] This application provides a method, apparatus, domain controller, and storage medium for inter-core communication of a domain controller, which helps to improve the transmission efficiency of inter-core communication and the reliability of data transmission.

[0007] To address the aforementioned problems, in a first aspect, embodiments of this application provide an inter-core communication method for a domain controller, comprising:

[0008] Send a session request message to the first core and receive a session response message sent by the first core;

[0009] If the session response message indicates that the session has been successfully established, the data packet sent by the first core is received, and the data in the data packet is compressed data.

[0010] Secondly, embodiments of this application provide an inter-core communication method for a domain controller, comprising:

[0011] Receive a session request message sent by the second core, establish a session connection with the second core, and send a session response message to the second core;

[0012] If the session connection is successfully established, obtain the data to be sent;

[0013] The data is compressed, and the compressed data is then encapsulated into a data packet.

[0014] The data packet is sent to the second core.

[0015] Thirdly, embodiments of this application provide an inter-core communication device for a domain controller, comprising:

[0016] The first handshake module is used to send a session request message to the first core and receive a session response message sent by the first core.

[0017] The data packet receiving module is used to receive data packets sent by the first core when the session response message indicates that the session has been successfully established. The data packets contain compressed data.

[0018] Fourthly, embodiments of this application provide an inter-core communication device for a domain controller, comprising:

[0019] The second handshake module is used to receive a session request message sent by the second core, establish a session connection with the second core, and send a session response message to the second core.

[0020] The data acquisition module is used to acquire the data to be sent when the session connection is successfully established.

[0021] The data encapsulation module is used to compress the data and encapsulate the compressed data into a data packet.

[0022] A data packet sending module is used to send the data packet to the second core.

[0023] Fifthly, embodiments of this application also provide a domain controller, including a second core and a first core, wherein the second core is used to execute the inter-core communication method of the domain controller described in the first aspect, and the first core is used to execute the inter-core communication method of the domain controller described in the second aspect.

[0024] In a sixth aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the steps of the inter-core communication method for a domain controller disclosed in embodiments of this application.

[0025] The domain controller inter-core communication method, apparatus, domain controller, and storage medium provided in this application embodiment send a session request message to a first core through a second core and receive a session response message sent by the first core. When the session response message indicates that the session has been successfully established, the data packet sent by the first core is received. Since the data in the data packet is compressed, the amount of data transmitted is reduced, which can improve the data transmission efficiency. Moreover, the first core sends the data packet after establishing a session connection with the first core through the session request, which can avoid the problem of data loss caused by the first core directly transmitting data after startup, thus improving the reliability of data transmission.

[0026] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 is a flowchart of an inter-core communication method for a domain controller provided in an embodiment of this application;

[0029] Figure 2a is a schematic diagram of the message format of the control command in an embodiment of this application;

[0030] Figure 2b is a schematic diagram of the format of the session request message in an embodiment of this application;

[0031] Figure 2c is a schematic diagram of the session response message format in an embodiment of this application;

[0032] Figure 2d is a schematic diagram of the format of the response result message in an embodiment of this application;

[0033] Figure 2e is a schematic diagram of the heartbeat message format in an embodiment of this application;

[0034] Figure 3 is a schematic diagram of the message format of the data packet count value sent by core A to core M in an embodiment of this application;

[0035] Figure 4 illustrates an inter-core communication method for a domain controller provided in an embodiment of this application;

[0036] Figure 5 is a schematic diagram of the format of a data packet including data to be sent in this embodiment;

[0037] Figure 6 is a schematic diagram of the structure of a circular buffer corresponding to a log type in an embodiment of this application;

[0038] Figure 7 is a flowchart of writing log data to a circular buffer in an embodiment of this application;

[0039] Figure 8 is a flowchart of the process of assembling and sending log data in an embodiment of this application;

[0040] Figure 9 is a schematic diagram of the structure of an inter-core communication device for a domain controller provided in an embodiment of this application;

[0041] Figure 10 is a schematic diagram of the structure of an inter-core communication device for a domain controller provided in an embodiment of this application. Detailed Implementation

[0042] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0043] Figure 1 is a flowchart of an inter-core communication method for a domain controller according to an embodiment of this application. This inter-core communication method can be used for communication between a first core and a second core in a central domain controller. For example, the first core can communicate with the second core via IPCF. The first core may include a microcontroller core (M core) in the central domain controller; the second core may include an application core (A core) in the central domain controller. The inter-core communication method of the domain controller in Figure 1 is applied to the second core. The method includes steps 110 to 120.

[0044] Step 110: Send a session request message to the first core and receive a session response message sent by the first core.

[0045] In an exemplary embodiment, the session request message and the session response message can be a control command message. Figure 2a is a schematic diagram of the format of a control command message in an embodiment of this application. As shown in Figure 2a, the control command message may include a Package ID field, a Data Length field, a Checksum field, and a Data field. The data in the Package ID field may include one of the following enumerated constants:

[0046] A2M_SESSION_REQ: Session start / end command sent from the second core to the first core;

[0047] M2A_SESSION_RESP: The first core replies to the second core with a success / failure instruction for session establishment;

[0048] A2M_ALIVE: Heartbeat command sent from the second core to the first core;

[0049] A2M_FEEDBACK: The data returned by the second core to the first core;

[0050] M2A_FEEDBACK: The data returned by the first core to the second core.

[0051] The data length field carries the length of the data in the data field, the check field carries the check value of the data in the data field, which can be a Cyclic Redundancy Check (CRC) value, and the data field carries the data exchanged between the second core and the first core.

[0052] Figure 2b is a schematic diagram of the format of the session request message in an embodiment of this application. As shown in Figure 2b, when the value of the packet identifier field is A2M_SESSION_REQ, it indicates that the current control command message is a session request message. At this time, the data in the data field only contains session request information, which includes one of the following enumerated constants:

[0053] SESSION_REQ_START: Session start request command;

[0054] SESSION_REQ_STOP: Session termination request command.

[0055] Figure 2c is a schematic diagram of the format of the session response message in an embodiment of this application. As shown in Figure 2c, when the value of the packet identifier field is M2A_SESSION_RESP, it indicates that the current control command message is a session response message. At this time, the data in the data field only contains session response information. The session response includes one of the following enumerated constants:

[0056] SESSION_RESP_OK: Session established successfully;

[0057] SESSION_RESP_NG: Session establishment failed.

[0058] In one exemplary embodiment, when the second core needs to access data from the first core, it can send a session request message to the first core. This session request message is a session start request message. When the first core receives the session start request message, it establishes a session connection between the first core and the second core, and sends the result of the session connection to the second core as a session response message. The second core receives the session response message sent by the first core. The session response message includes whether the session was successfully established or failed to establish.

[0059] Step 120: If the session response message indicates that the session has been successfully established, receive the data packet sent by the first core, wherein the data in the data packet is compressed data.

[0060] In an exemplary embodiment, upon receiving a session response message indicating successful session establishment, the first core sends a data packet to the second core. The data packet sent by the first core to the second core contains compressed data, which reduces the amount of data transmitted and improves data transmission efficiency. For example, the data in the data packet can be log data or other types of data. The log data refers to system operation logs. The log data sent by the first core to the second core can be categorized into three types: error logs, warning logs, and debug logs. Of course, other types of log data can also be used. The type of log data can be distinguished in the packet identifier field of the data packet.

[0061] The inter-core communication method for a domain controller provided in this application sends a session request message to a first core and receives a session response message from the first core. When the session response message indicates that the session has been successfully established, the method receives a data packet sent by the first core. Since the data in the data packet is compressed, the amount of data transmitted is reduced, which can improve data transmission efficiency. Moreover, the first core sends the data packet after establishing a session connection with the first core through the session request, which can avoid the problem of data loss caused by the first core directly transmitting data after startup, thus improving the reliability of data transmission.

[0062] Based on the above technical solution, the data packet includes a packet identifier field, a data length field, and a check field;

[0063] The method further includes: when the current period arrives, if the packet identifier is determined to be incorrect according to the packet identifier field, the data length is determined to be incorrect according to the data length field, or the checksum is determined to be incorrect according to the checksum field in the data packet of the previous period, then sending a response error message to the first core; and receiving the data packet sent in the previous period retransmitted by the first core in response to the response error message.

[0064] In an exemplary embodiment, the current period is the current data transmission period, which is the period during which the first core transmits data, and the first core periodically transmits the data packets according to the data transmission period. The previous period is the period preceding the current period. For example, the period can be a fixed time length or a time length agreed upon by the second core and the first core.

[0065] In one exemplary embodiment, the data packet includes a packet identifier field, a data length field, and a checksum field. The data packet may also include a data field and a transmission count field. The data field carries the actual data to be transmitted, such as log data. The transmission count field carries the number of data packets sent in the current period. The packet identifier field identifies the data type of the current data packet (such as log type). The data length field identifies the length of the data in the data field. The checksum field carries the checksum value of the data in the data field, which may be a cyclic redundancy check value.

[0066] In an exemplary embodiment, after receiving a data packet sent by the first core, the second core parses the data packet, determines whether the packet identifier is correct based on the packet identifier field, whether the data length is correct based on the data length field, and whether the checksum is correct based on the checksum field. At the end of the current cycle, if at least one of the following errors exists in the data packet received in the previous cycle: packet identifier error, data length error, or checksum error, an error message response is sent to the first core. The packet identifier identifies the data type of the data packet, such as the log type. When determining whether the packet identifier is correct, the data type can be determined based on the data in the data field of the data packet. If the data type is the same as the packet identifier, the packet identifier is determined to be correct; otherwise, the packet identifier is determined to be incorrect.

[0067] In an exemplary embodiment, an error message is one type of response result message. The response result message may also include a correct response message, and it is also a control command message. Figure 2d is a schematic diagram of the format of the response result message in an embodiment of this application. As shown in Figure 2d, when the value of the packet identifier field in the response result message is A2M_FEEDBACK or M2A_FEEDBACK, it indicates that the current control command message is a response result message. At this time, the data in the data field includes response result (AckResult) information and response error (AckErrReasonCode) information. The response result includes one of the following enumerated constants:

[0068] FEEDBACK_ACK_OK: Indicates that the response data is error-free;

[0069] FEEDBACK_NACK_ERR: Indicates that there is an error in the response data.

[0070] Error responses include at least one of the following three enumerated constants:

[0071] NACK_ERR_CMD: Error in identifying the packet identifier;

[0072] NACK_ERR_LEN: Indicates a data length error;

[0073] NACK_ERR_CRC: Indicates a checksum error in the data.

[0074] In one exemplary embodiment, the first core receives an error message response sent by the second core and retransmits the data packets sent in the previous cycle. By adding a verification algorithm to the communication protocol, the error detection and correction capabilities of data transmission can be enhanced, thereby improving the reliability and fault tolerance of data transmission.

[0075] Based on the above technical solution, the method may further include:

[0076] When the current cycle is reached, a data packet count value is sent to the first core, the data packet count value representing the number of data packets received in the previous cycle;

[0077] The system receives a data packet retransmitted by the first core from the previous cycle. The data packet retransmitted by the first core is when the data packet count value and the transmission count value are inconsistent. The transmission count value is the count value recorded by the first core in the last data packet sent in the previous cycle.

[0078] In an exemplary embodiment, the current period is the current data transmission period, which is the period during which the first core transmits data, and the first core periodically transmits the data packets according to the data transmission period. The previous period is the period preceding the current period. For example, the period can be a fixed time length or a time length agreed upon by the second core and the first core.

[0079] In one exemplary embodiment, the data packets sent from the first core to the second core can be sent periodically, with each period containing a separate count of the sent data packets. At the beginning of a period, the second core sends a data packet count value to the first core. This data packet count value represents the number of data packets received in the previous period. This data packet count value may be the same as the transmission count value in the last data packet sent by the first core in the previous period, or it may be different from the transmission count value, or it may be an invalid value.

[0080] Taking the first core as core M and the second core as core A as an example, Figure 3 is a schematic diagram of the message format of the data packet count value sent by core A to core M in an embodiment of this application. As shown in Figure 3, the data in the data packet is log data, and the type of log data can be error log, warning log, or debug log. The message of the data packet count value includes a packet identifier (PackageID) field, a checksum (DataCrc) field, and a data length (DataLength) field. The data of the packet identifier field includes the following enumerated constants:

[0081] A2M_DATA_CNT: The count of data packets sent from core A to core M.

[0082] The packet identifier field is used to identify the log type of this packet count value, and can be one of the following:

[0083] DataCnt_Error: The count of data packets received by core A in the error log.

[0084] DataCnt_Warn: The count of packets received in the warning log for core A.

[0085] DataCnt_Debug: The count of data packets received by the A core in the debug log.

[0086] In an exemplary embodiment, core M receives a data packet count value sent by core A, compares the data packet count value with the number of transmissions count value, and if the two are inconsistent, retransmits the data packets sent in the previous cycle, realizing intelligent retransmission, which can ensure reliable data transmission when the network is unstable and improve the robustness of the system.

[0087] Based on the above technical solution, the method may further include: sending a heartbeat message to the first core at a preset time interval, wherein the heartbeat message is used to notify the first core that it can receive the data packet.

[0088] Figure 2e is a schematic diagram of the heartbeat message format in an embodiment of this application. As shown in Figure 2e, the heartbeat message is also a control command message. When the value of the Package ID field of the control command message is equal to A2M_ALIVE, it indicates that the control command message is a heartbeat message. The data field of the heartbeat message contains the heartbeat count value. The heartbeat count value sent by the second core to the first core is incremented by 1 each time.

[0089] By sending heartbeat messages to the first core at preset time intervals, a heartbeat mechanism between the second core and the first core is implemented, which can ensure communication security and stability and guarantee communication reliability.

[0090] Figure 4 illustrates an inter-core communication method for a domain controller according to an embodiment of this application. This inter-core communication method can be used for communication between a second core and a first core in a central domain controller based on IPCF. For example, the first core can communicate with the second core via IPCF. The first core may include a microcontroller core (M core) in the central domain controller; the second core may include an application core (A core) in the central domain controller. The inter-core communication method in Figure 4 is applied to the first core. As shown in Figure 4, the method includes steps 410 to 440.

[0091] Step 410: Receive the session request message sent by the second core, establish a session connection with the second core, and send a session response message to the second core.

[0092] In one exemplary embodiment, the session request message and the session response message can be a control command message. The specific formats of the session request message and the session response message can be found in the above embodiments, and will not be repeated here.

[0093] In an exemplary embodiment, when the second core needs to obtain data from the first core, it can send a session request message to the first core. This session request message is a session start request message. When the first core receives the session start request message, it establishes a session connection between the first and second cores and sends the result of the session connection as a session response message to the second core. The second core receives the session response message sent by the first core. The session response message includes whether the session was established successfully or failed. By having the second core send a session request message to the first core, and the first core send a session response message to A, a handshake mechanism is implemented between the second and first cores, which can improve communication security and stability.

[0094] Step 420: If the session response message indicates that the session connection has been successfully established, obtain the data to be sent.

[0095] In an exemplary embodiment, when the first core successfully establishes a session connection between the second core, it retrieves the data to be sent from the data storage location. For example, the data to be sent can be log data or other types of data. The log data is the system's runtime log. The log data sent from the first core to the second core can be categorized into three types: error logs, warning logs, and debug logs. Of course, other types of log data can also be used, and the type of log data can be distinguished in the packet identifier field of the data packet.

[0096] Step 430: Compress the data and encapsulate the compressed data into a data packet.

[0097] In one exemplary embodiment, after acquiring the data to be sent, the data is compressed, and the compressed data is encapsulated in the data field of the data packet. This reduces the amount of data transmitted and improves data transmission efficiency. For example, the compression algorithm can be ASTD compression, differential compression, etc. Optionally, encryption algorithms and authentication mechanisms can be embedded in the compression algorithm to ensure data security during transmission.

[0098] Taking the first core as core M and the second core as core A as an example, Figure 5 is a schematic diagram of the format of a data packet containing data to be sent in this embodiment. As shown in Figure 5, the data packet carrying data sent by core M to core A may include a packet identifier (PackageID) field, a checksum (DataCrc) field, a data length (DataLength) field, a transmission count value (DataCnt) field, and a data (Data) field. The packet identifier field is used to identify the data type of the data to be sent. For example, when the data to be sent is log data, the data type is log type. The log type can be, for example, error log, warning log, or debug log, etc. In this case, the value of the packet identifier field can be one of the following enumerated constants:

[0099] M2A_DATA_ERROR: Error log data sent from core M to core A;

[0100] M2A_DATA_WARN: Warning log data sent by core M to core A;

[0101] M2A_DATA_DEBUG: The M core sends debug log data to the A core.

[0102] The data packet's checksum field carries the checksum value of the data in the data field, which can be a cyclic redundancy check value; the data length field carries the length of the data in the data field; the transmission count field carries the transmission count value of the data sent from core M to core A; and the data field carries the specific data sent from core M to core A, such as log data.

[0103] Step 440: Send the data packet to the second core.

[0104] The inter-core communication method for a domain controller provided in this application establishes a session connection with the second core by receiving a session request message sent by the second core, and sends a session response message to the second core. If the session connection is successfully established, the method acquires the data to be sent, compresses the data, encapsulates the compressed data into a data packet, and sends the data packet to the second core. Since the data in the data packet is compressed, the amount of data transmitted is reduced, which can improve data transmission efficiency. Moreover, by establishing a session connection with the second core through the session request of the second core before sending the data packet to the second core, the method can avoid the problem of data loss caused by the first core directly transmitting data to the second core after startup, thus improving the reliability of data transmission.

[0105] Based on the above technical solution, the step of acquiring the data to be sent includes:

[0106] Retrieve the data to be sent from the circular buffer;

[0107] Before retrieving the data to be sent from the circular buffer, the method further includes:

[0108] Activate the spinlock;

[0109] When it is determined that the circular buffer is not full based on the write index and read index of the circular buffer, the address of the write index is obtained and the write index is updated.

[0110] The spinlock is closed, and the data to be written to the circular buffer is saved to the address.

[0111] In one exemplary embodiment, the data to be sent is stored in a circular buffer, and when the data to be sent is retrieved, it is retrieved from the circular buffer.

[0112] In an exemplary embodiment, when storing data into the circular buffer, a spinlock is first enabled to ensure that only one task can access the write index (Buffer[WriteIndex]) of the circular buffer at any given time, preventing multiple tasks (including tasks from different cores) from operating on the write index of the circular buffer simultaneously. The write index and read index of the circular buffer are compared, and the circular buffer is determined to be full based on the comparison result. If data exists at the address following the write index, that is, the address of the write index is the position pointed to by the read index, it means that the circular buffer is full. Otherwise, the circular buffer is not full. When the circular buffer is not full, the address of the write index (LogDstAddr) is obtained, and the value of the write index is incremented by 1. The spinlock is then disabled, and the data to be written to the circular buffer is written to the obtained address.

[0113] In an exemplary embodiment, a corresponding circular buffer can be established for each type of data. For example, when the data stored in the circular buffer is log data, three circular buffers can be established according to three types of logs: error logs, warning logs, and debug logs. Each circular buffer corresponds to one log type. Figure 6 is a schematic diagram of the structure of a circular buffer corresponding to one type of log in this embodiment. As shown in Figure 6, each circular buffer is a two-dimensional array of strings. The first dimension represents the maximum number of log entries to be stored, and the second dimension represents the maximum length of each log entry. Each log entry stores the log printing time and log content. For the log data of the three log types—error logs, warning logs, and debug logs—the first core program (such as the M-core program) can encapsulate three functions: CMLOG_Printf_E, CMLOG_Printf_W, and CMLOG_Printf_D. The function CMLOG_Printf_E is used to write log data to the circular buffer corresponding to the error log, the function CMLOG_Printf_W is used to write log data to the circular buffer corresponding to the warning log, and the function CMLOG_Printf_D is used to write log data to the circular buffer corresponding to the debug log. Each log type has a corresponding write index and read index for its circular buffer.

[0114] Figure 7 is a flowchart of writing log data to a circular buffer in an embodiment of this application. As shown in Figure 7, the process of writing log data to a circular buffer includes the following steps:

[0115] Step 710: Activate the spinlock.

[0116] For example, when calling the CMLOG_Printf_E function, a spinlock must first be enabled to ensure that only one task can access the write index of the circular buffer at any given time, preventing multiple tasks from operating on the write index of the circular buffer simultaneously.

[0117] Step 720: Determine whether the circular buffer is full based on the write index and read index.

[0118] The circular buffer is determined by comparing the write index and the read index. If it is not full, step 730 is executed; if it is full, step 740 is executed.

[0119] Step 730: Obtain the address of the write index and update the write index.

[0120] Get the address of the write index, LogDstAddr, and increment the value of the write index by 1.

[0121] Step 740: Close the spinlock.

[0122] Step 750: Copy the log printing time and log content to the address.

[0123] Copy the time information (log printing time) and the log information (log content) to the address LogDstAddr.

[0124] Circular buffers are used during data collection (such as log collection). Due to the structural characteristics of circular buffers, read and write operations are usually circular, avoiding frequent memory movement and data copying, thereby improving read and write efficiency. Circular buffers manage data reading and writing through head and tail pointers (write index and read index), eliminating the need for complex queue management logic and simplifying implementation. At the same time, data collection considers the use of spinlocks to ensure that only one task can access the circular buffer at a time, thereby guaranteeing data integrity.

[0125] Based on the above technical solution, obtaining the data to be sent from the circular buffer includes:

[0126] If, based on the write index and read index of the circular buffer, it is determined that the data in the circular buffer has not been completely read and the data packet is not full, the address of the read index is obtained and the read index is updated.

[0127] If the remaining space of the data packet is greater than the length of the data corresponding to the address of the read index, then the data corresponding to the address of the read index is added to the data packet;

[0128] While the data in the circular buffer is not fully read and the data packet is not full, the operations of obtaining the address of the read index, updating the read index, and adding the data corresponding to the address of the read index to the data packet are executed repeatedly until the data in the circular buffer is fully read or the data packet is full.

[0129] In one exemplary embodiment, the write index and read index of the circular buffer are compared. Based on the comparison result, it is determined whether the data in the circular buffer has been completely read. If there is data at the read index position (i.e., the read index position is different from the write index position), it is determined that the data in the circular buffer has not been completely read; otherwise, it is determined that the data in the circular buffer has been completely read. If the data in the circular buffer has been completely read, or the data packet of the current group is full, the While loop is exited directly. Whether a data packet is full can be determined based on the value of the IPCFBufferSendFlag flag of the data packet. If the value of the IPCFBufferSendFlag flag is 1, it indicates that the data packet is full; if the value of the IPCFBufferSendFlag flag is 0, it indicates that the data packet is not full. If the data in the circular buffer is not completely read and the current packet assembly is not full, obtain the address of the circular buffer read index, LogSrcAddr, and increment its value by 1. Next, check if the remaining space of the packet is greater than the length of the data corresponding to the read index address, LogSrcAddr. If the remaining space is less than the length, the packet is full, and the packet's flag, IPCFBufferSendFlag, is set to 1. If the remaining space is greater than or equal to the length, the data corresponding to the read index address, LogSrcAddr, is copied into the packet. Finally, again check the write index, WriteIndex, and read index, to see if the data in the circular buffer has been completely read. If the data is not completely read and the packet is not full, repeat the process of retrieving data from the circular buffer and adding it to the packet until the circular buffer is completely read or the packet is full. If the data has been read or the data packet is full, the first core needs to compress the data packet, then calculate the check value of the data packet (such as the CRC value), and fill the check value into the check field of the data packet. Finally, the first core sends the data packet to the second core and then continues to return to the While loop.

[0130] When assembling and sending data packets, a circular buffer is used. Due to the structural characteristics of the circular buffer, read and write operations are usually circular, avoiding frequent memory movement and data copying, thereby improving read and write efficiency. The circular buffer manages data reading and writing through head and tail pointers (write index and read index), eliminating the need for complex queue management logic and simplifying implementation.

[0131] Based on the above technical solution, the data stored in the circular buffer is log data, which includes the log printing time and log content of each log entry;

[0132] The log data in the data packet includes the log printing time and the log content. If multiple consecutive log data have the same log printing time, the log printing time is included in the first log data of the multiple log data, and the log printing time is omitted in the other log data of the multiple log data except for the first log data.

[0133] In one exemplary embodiment, a timestamp is added as a prefix to each log entry in the data packet to indicate the log printing time of the current log data. If multiple consecutive log entries have the same printing time, the logging time is included in the first log entry, while it is omitted from all subsequent log entries. This reduces the amount of data sent from the first core to the second core. For example, if log 0 and log 1 have the same printing time, no timestamp is added before log 1, thus reducing the amount of data sent from the first core to the second core.

[0134] Based on the above technical solution, the log data includes error logs, warning logs, or debug logs; each log type corresponds to a circular buffer; each data packet includes log data of the same log type.

[0135] Log data can be any of the following log types: error logs, warning logs, and debug logs. For each log type, a corresponding circular buffer is established, storing only log data of that type. When assembling data packets, log data is retrieved from the circular buffer of one log type and grouped into the packet; that is, log data within a single data packet is of the same type. By classifying and grouping log information of different levels (log types) (error logs, warning logs, debug logs), decoupling between different log levels and improving flexibility across different log levels can be achieved.

[0136] Based on the above technical solution, the method may further include:

[0137] Upon reaching the current cycle, the data packet count value sent by the second core is received, the data packet count value representing the number of data packets received by the second core in the previous cycle;

[0138] If the data packet count value is inconsistent with the transmission count value, the data packet sent in the previous cycle is resent to the second core, and the transmission count value is the count value recorded in the last data packet sent in the previous cycle.

[0139] In an exemplary embodiment, the current period is the current data transmission period, which is the period during which the first core transmits data, and the first core periodically transmits the data packets according to the data transmission period. The previous period is the period preceding the current period. For example, the period can be a fixed time length or a time length agreed upon by the second core and the first core.

[0140] In one exemplary embodiment, the data packets sent from the first core to the second core can be sent periodically, with each period containing a separate count of the sent data packets. At the beginning of a period, the second core sends a data packet count value to the first core. This data packet count value represents the number of data packets received in the previous period. This data packet count value may be the same as the transmission count value in the last data packet sent by the first core in the previous period, or it may be different from the transmission count value, or it may be an invalid value.

[0141] The message format for the data packet count value can be referred to in the above embodiment, and will not be repeated here.

[0142] In one exemplary embodiment, the first core receives a data packet count value sent by the second core, compares this data packet count value with a transmission count value, and if the two are inconsistent, retransmits the data packets sent in the previous cycle. This implements intelligent retransmission, which can ensure reliable data transmission when the network is unstable and improve the robustness of the system.

[0143] Based on the above embodiments, the data packet includes a packet identifier field, a data length field, and a checksum field;

[0144] The method further includes:

[0145] Upon reaching the current cycle, a response error message is received from the second core, indicating that the packet identifier field of the data packet in the previous cycle is incorrect, the data length field is incorrect, or the check value of the check field is incorrect.

[0146] In response to the error message, the data packet sent in the previous cycle is resent to the second core.

[0147] In an exemplary embodiment, the current period is the current data transmission period, which is the period during which the first core transmits data, and the first core periodically transmits the data packets according to the data transmission period. The previous period is the period preceding the current period. For example, the period can be a fixed time length or a time length agreed upon by the second core and the first core.

[0148] In one exemplary embodiment, the data packet includes a packet identifier field, a data length field, and a checksum field. The data packet may also include a data field and a transmission count field. The data field carries the actual data to be transmitted, such as log data. The transmission count field carries the number of data packets sent in the current period. The packet identifier field identifies the data type of the current data packet (such as log type). The data length field identifies the length of the data in the data field. The checksum field carries the checksum value of the data in the data field, which may be a cyclic redundancy check value.

[0149] In an exemplary embodiment, after receiving a data packet sent by the first core, the second core parses the data packet, determines whether the packet identifier is correct based on the packet identifier field, whether the data length is correct based on the data length field, and whether the checksum is correct based on the checksum field. At the end of the current cycle, if at least one of the following errors exists in the data packet received in the previous cycle: packet identifier error, data length error, or checksum error, an error message response is sent to the first core. The packet identifier is used to identify the data type of the data packet, such as the log type. When determining whether the packet identifier is correct, the data type of the data can be determined based on the data in the data field of the data packet. If the data type is the same as the packet identifier, the packet identifier is determined to be correct; otherwise, the packet identifier is determined to be incorrect.

[0150] In one exemplary embodiment, an error message is one type of response result message. The response result message may also include a correct response message, and it is also a control command message. The format of the response result message can be referred to in the above embodiments, and will not be repeated here.

[0151] In one exemplary embodiment, the first core receives an error message response sent by the second core and retransmits the data packets sent in the previous cycle. By adding a verification algorithm to the communication protocol, the error detection and correction capabilities of data transmission can be enhanced, thereby improving the reliability and fault tolerance of data transmission.

[0152] Figure 8 is a flowchart of the process of assembling and sending log data in an embodiment of this application. As shown in Figure 8, the process of assembling and sending log data includes the following steps:

[0153] Step 810: The first core obtains the data packet count value of each log type, compares it with the send count value of error log, warning log and debug log, and determines whether retransmission is required. If retransmission is required, proceed to step 820; if retransmission is not required, proceed to step 830.

[0154] First, obtain the data where the Packet ID is equal to A2M_DATA_CNT (the count of received log packets sent from the second core to the first core), that is, obtain the packet count value to determine whether the first core needs to retransmit the data.

[0155] Step 820: The first core sends the data packets that need to be retransmitted to the second core.

[0156] Step 830 involves processing the circular buffers, including processing the circular buffers for error logs, warning logs, and debug logs.

[0157] If the data does not need to be resent, then the error logs, warning logs, and debug logs need to be packaged and sent step by step.

[0158] Step 830 may specifically include the following steps:

[0159] Step 831: Determine whether the data in the circular buffer has been completely read, or whether the data packet flag is equal to 1.

[0160] If the data in the circular buffer has been completely read, or the packet flag (IPCFBufferSendFlag) is equal to 1, the packet reassembly and transmission loop is exited directly. If the data in the circular buffer has not been completely read, and the packet flag (IPCFBufferSendFlag) is equal to 0, step 832 is executed.

[0161] Step 832: Obtain the address LogSrcAddr of the read index and update the read index.

[0162] If the data in the circular buffer has not been completely read and the packet flag (IPCFBufferSendFlag) is equal to 0, then obtain the address LogSrcAddr of the read index (Buffer[ReadIndex]) and increment the value of the read index ReadIndex by 1.

[0163] Step 833: Determine whether the remaining space of the data packet is greater than the length of the string corresponding to the address LogSrcAddr. If yes, proceed to step 834; otherwise, proceed to step 835.

[0164] Step 834: Copy the string content corresponding to the address LogSrcAddr into the data packet.

[0165] Step 835: Set the value of the data packet flag to 1.

[0166] Step 836: Determine whether the data in the circular buffer has been completely read, or whether the data packet flag is equal to 1. If yes, proceed to step 837; otherwise, proceed to step 831.

[0167] Again, determine whether the data in the circular buffer has been read completely or whether the data packet flag is equal to 1 based on the write index and read index. If the data has been read completely or the data packet flag is equal to 1, proceed to step 837; otherwise, proceed to step 831.

[0168] Step 837: Compress the data in the data field.

[0169] Step 838: Calculate the CRC value corresponding to the data in the data field and fill the CRC value into the check field of the data packet.

[0170] Step 839: Send the data packet to the second core and set the data packet flag to 1.

[0171] By using a circular buffer during log collection and packet assembly, the read and write operations are typically circular due to the buffer's structure, avoiding frequent memory movements and data copying, thus improving read and write efficiency. The circular buffer manages data read and write operations using head and tail pointers, eliminating the need for complex queue management logic and simplifying implementation.

[0172] The inter-core communication method of the domain controller provided in this application embodiment, applied to an S32G central domain controller, serves as a log application communication protocol between the second core and the first core. This allows for real-time monitoring of system status, helping developers quickly identify and resolve potential problems or faults. Logs provide detailed records of system behavior, facilitating fault tracing and root cause analysis when problems occur, especially when problem reproduction is difficult. The communication protocol incorporates a verification algorithm to improve data transmission reliability and fault tolerance. The communication protocol optimizes the data transmission process, improving data transmission speed and efficiency. The communication protocol includes a handshake protocol and heartbeat mechanism between the second and first cores, ensuring communication security and stability, and guaranteeing communication reliability. Through an efficient log upload strategy, developers can not only improve system reliability and stability but also continuously optimize product functionality and user experience. Efficient data compression, employing advanced data compression algorithms, reduces the bandwidth required during transmission, improving transmission efficiency. An intelligent retransmission mechanism is introduced to ensure reliable data transmission when the network is unstable, enhancing system robustness. By integrating encrypted transmission and authentication mechanisms into the compression algorithm, the security of log data during transmission is ensured. It supports batch log transmission, allowing data to be sent multiple times with a single request, reducing the number of network requests and improving efficiency.

[0173] Figure 9 is a schematic diagram of an inter-core communication device for a domain controller according to an embodiment of this application. This inter-core communication device is applied to a second core. As shown in Figure 9, the device includes:

[0174] The first handshake module 910 is used to send a session request message to the first core and receive a session response message sent by the first core.

[0175] The data packet receiving module 920 is used to receive data packets sent by the first core when the session response message indicates that the session has been successfully established. The data packets contain compressed data.

[0176] Optionally, the data packet includes a packet identifier field, a data length field, and a checksum field;

[0177] The device further includes:

[0178] The response error message sending module is used to send a response error message to the first core when the current period arrives, if the data packet of the previous period is determined to have a packet identifier error according to the packet identifier field, a data length error according to the data length field, or a check value error according to the check field.

[0179] The data packet retransmission module is used to receive the data packets sent in the previous cycle, which are retransmitted by the first core in response to the response error message.

[0180] Optionally, the device further includes:

[0181] The first data packet count value sending module is used to send a data packet count value to the first core when the current period arrives, wherein the data packet count value represents the number of data packets received in the previous period;

[0182] The second data packet retransmission module is used to receive the data packets sent in the previous cycle that are retransmitted by the first core. The data packets retransmitted by the first core are retransmitted when the data packet count value and the transmission count value are inconsistent. The transmission count value is the count value recorded by the first core in the last data packet sent in the previous cycle.

[0183] Optionally, the device further includes:

[0184] The heartbeat message sending module is used to send heartbeat messages to the first core at preset time intervals. The heartbeat messages are used to notify the first core that it can receive the data packets.

[0185] The inter-core communication device for a domain controller provided in this application embodiment is used to implement the steps of the inter-core communication method for a domain controller described in this application embodiment. The specific implementation of each module of the device is described in the corresponding steps, and will not be repeated here.

[0186] The inter-core communication device of the domain controller provided in this application sends a session request message to the first core and receives a session response message sent by the first core. When the session response message indicates that the session has been successfully established, the device receives a data packet sent by the first core. Since the data in the data packet is compressed, the amount of data transmitted is reduced, which can improve the data transmission efficiency. Moreover, the first core sends the data packet after establishing a session connection with the first core through the session request, which can avoid the problem of data loss caused by the first core directly transmitting data after startup, thus improving the reliability of data transmission.

[0187] Figure 10 is a schematic diagram of an inter-core communication device for a domain controller according to an embodiment of this application. This inter-core communication device is applied to a first core. As shown in Figure 10, the device includes:

[0188] The second handshake module 1010 is used to receive a session request message sent by the second core, establish a session connection with the second core, and send a session response message to the second core;

[0189] The data acquisition module 1020 is used to acquire data to be sent when the session response message indicates that the session connection has been successfully established;

[0190] The data encapsulation module 1030 is used to compress the data and encapsulate the compressed data into a data packet.

[0191] The data packet sending module 1040 is used to send the data packet to the second core.

[0192] Optionally, the data acquisition module is specifically used for:

[0193] If the session connection is successfully established, the data to be sent is retrieved from the circular buffer;

[0194] The device further includes:

[0195] Spinlock opening module, used to open spinlocks;

[0196] The write index operation module is used to determine that the circular buffer is not full based on the write index and read index of the circular buffer, obtain the address of the write index, and update the write index.

[0197] The data writing module is used to close the spinlock and save the data to be written to the circular buffer to the address.

[0198] Optionally, the data acquisition module includes:

[0199] A read index operation unit is used to determine, based on the write index and read index of the circular buffer, that the data in the circular buffer has not been completely read and the data packet is not full, to obtain the address of the read index and update the read index.

[0200] A data acquisition unit is configured to add the data corresponding to the address of the read index to the data packet if the remaining space of the data packet is greater than the length of the data corresponding to the address of the read index.

[0201] The loop control unit is used to repeatedly execute operations such as obtaining the address of the read index, updating the read index, and adding the data corresponding to the address of the read index to the data packet when the data in the ring buffer has not been completely read and the data packet is not full, until the data in the ring buffer has been completely read or the data packet is full.

[0202] Optionally, the circular buffer stores log data, which includes the log printing time and log content of each log entry.

[0203] The log data in the data packet includes the log printing time and the log content. If multiple consecutive log data have the same log printing time, the log printing time is included in the first log data of the multiple log data, and the log printing time is omitted in the other log data of the multiple log data except for the first log data.

[0204] Optionally, the log data may include error logs, warning logs, or debug logs.

[0205] Each of the aforementioned log types corresponds to one of the aforementioned circular buffers;

[0206] Each data packet includes log data of the same log type.

[0207] Optionally, the device further includes:

[0208] The data packet count value receiving module is used to receive the data packet count value sent by the second core when the current cycle arrives, wherein the data packet count value represents the number of data packets received by the second core in the previous cycle;

[0209] The first data packet retransmission module is used to retransmit the data packet sent in the previous cycle to the second core if the data packet count value is inconsistent with the transmission count value. The transmission count value is the count value recorded in the last data packet sent in the previous cycle.

[0210] Optionally, the data packet includes a packet identifier field, a data length field, and a checksum field;

[0211] The device further includes:

[0212] The response error message receiving module is used to receive a response error message sent by the second core when the current period arrives. The response error message indicates that the packet identifier field of the data packet of the previous period is incorrect, the data length field is incorrect, or the check value of the check field is incorrect.

[0213] The second data packet retransmission module is used to retransmit the data packets sent in the previous cycle to the second core in response to the response error message.

[0214] The inter-core communication device for a domain controller provided in this application embodiment is used to implement the steps of the inter-core communication method for a domain controller described in this application embodiment. The specific implementation of each module of the device is described in the corresponding steps, and will not be repeated here.

[0215] The inter-core communication device for a domain controller provided in this application establishes a session connection with the second core by receiving a session request message sent by the second core, and sends a session response message to the second core. If the session connection is successfully established, the device acquires the data to be sent, compresses the data, encapsulates the compressed data into a data packet, and sends the data packet to the second core. Since the data in the data packet is compressed, the amount of data transmitted is reduced, which can improve data transmission efficiency. Moreover, by establishing a session connection with the first core through a session request before sending the data packet, the device can avoid the problem of data loss caused by the first core directly transmitting data after startup, thus improving the reliability of data transmission.

[0216] Accordingly, this application also provides a domain controller, including a second core and a first core. The second core is used to execute the inter-core communication method of the domain controller applied to the second core as described in this application, and the first core is used to execute the inter-core communication method of the domain controller applied to the first core as described in this application.

[0217] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the inter-core communication method for a domain controller as described in this application.

[0218] This application also provides a computer program product that, when executed by a processor, implements the steps of the inter-core communication method for a domain controller as described in this application.

[0219] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus embodiments, since they are fundamentally similar to the method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0220] The foregoing has provided a detailed description of an inter-core communication method, apparatus, domain controller, and storage medium for a domain controller according to embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0221] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

Claims

1. A method for inter-core communication of a domain controller, characterized in that, include: Send a session request message to the first core and receive a session response message sent by the first core; If the session response message indicates that the session has been successfully established, the data packet sent by the first core is received, and the data in the data packet is compressed data.

2. The method according to claim 1, characterized in that, The data packet includes a packet identifier field, a data length field, and a checksum field; The method further includes: When the current cycle arrives, if the packet in the previous cycle is determined to have a packet identifier error based on the packet identifier field, a data length error based on the data length field, or a checksum error based on the checksum field, then an error message response is sent to the first core. The first core responds to the error message and retransmits the data packet sent in the previous cycle.

3. The method according to claim 1, characterized in that, Also includes: When the current cycle is reached, a data packet count value is sent to the first core, the data packet count value representing the number of data packets received in the previous cycle; The system receives a data packet retransmitted by the first core from the previous cycle. The data packet retransmitted by the first core is when the data packet count value and the transmission count value are inconsistent. The transmission count value is the count value recorded by the first core in the last data packet sent in the previous cycle.

4. The method according to any one of claims 1-3, characterized in that, Also includes: A heartbeat message is sent to the first core at a preset time interval. The heartbeat message is used to notify the first core that it can receive the data packet.

5. A method for inter-core communication of a domain controller, characterized in that, include: Receive a session request message sent by the second core, establish a session connection with the second core, and send a session response message to the second core; If the session response message indicates that the session connection has been successfully established, the data to be sent is obtained; The data is compressed, and the compressed data is then encapsulated into a data packet. The data packet is sent to the second core.

6. The method according to claim 5, characterized in that, The acquisition of the data to be sent includes: Retrieve the data to be sent from the circular buffer; Before retrieving the data to be sent from the circular buffer, the method further includes: Activate the spinlock; When it is determined that the circular buffer is not full based on the write index and read index of the circular buffer, the address of the write index is obtained and the write index is updated. The spinlock is closed, and the data to be written to the circular buffer is saved to the address.

7. The method according to claim 6, characterized in that, The step of obtaining the data to be sent from the circular buffer includes: If, based on the write index and read index of the circular buffer, it is determined that the data in the circular buffer has not been completely read and the data packet is not full, the address of the read index is obtained and the read index is updated. If the remaining space of the data packet is greater than the length of the data corresponding to the address of the read index, then the data corresponding to the address of the read index is added to the data packet; While the data in the circular buffer is not fully read and the data packet is not full, the operations of obtaining the address of the read index, updating the read index, and adding the data corresponding to the address of the read index to the data packet are executed repeatedly until the data in the circular buffer is fully read or the data packet is full.

8. The method according to claim 6 or 7, characterized in that, The circular buffer stores log data, which includes the log printing time and log content of each log entry. The log data in the data packet includes the log printing time and the log content. If multiple consecutive log data have the same log printing time, the log printing time is included in the first log data of the multiple log data, and the log printing time is omitted in the other log data of the multiple log data except for the first log data.

9. The method according to claim 8, characterized in that, The log data includes error logs, warning logs, or debug logs. Each of the aforementioned log types corresponds to one of the aforementioned circular buffers; Each data packet includes log data of the same log type.

10. The method according to any one of claims 5-7, characterized in that, Also includes: Upon reaching the current cycle, the data packet count value sent by the second core is received, the data packet count value representing the number of data packets received by the second core in the previous cycle; If the data packet count value is inconsistent with the transmission count value, the data packet sent in the previous cycle is resent to the second core, and the transmission count value is the count value recorded in the last data packet sent in the previous cycle.

11. The method according to any one of claims 5-7, characterized in that, The data packet includes a packet identifier field, a data length field, and a checksum field; The method further includes: Upon reaching the current cycle, a response error message is received from the second core, indicating that the packet identifier field of the data packet in the previous cycle is incorrect, the data length field is incorrect, or the check value of the check field is incorrect. In response to the error message, the data packet sent in the previous cycle is resent to the second core.

12. An inter-core communication device for a domain controller, characterized in that, include: The first handshake module is used to send a session request message to the first core and receive a session response message sent by the first core. The data packet receiving module is used to receive data packets sent by the first core when the session response message indicates that the session has been successfully established. The data packets contain compressed data.

13. An inter-core communication device for a domain controller, characterized in that, include: The second handshake module is used to receive a session request message sent by the second core, establish a session connection with the second core, and send a session response message to the second core. The data acquisition module is used to acquire the data to be sent when the session connection is successfully established. The data encapsulation module is used to compress the data and encapsulate the compressed data into a data packet. A data packet sending module is used to send the data packet to the second core.

14. A domain controller, comprising a second core and a first core, characterized in that, The second core is used to execute the inter-core communication method of the domain controller according to any one of claims 1 to 4, and the first core is used to execute the inter-core communication method of the domain controller according to any one of claims 5 to 11.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the steps of the inter-core communication method of the domain controller as described in any one of claims 1 to 4, or implements the steps of the inter-core communication method of the domain controller as described in any one of claims 5 to 11.

Images