Log collection method and system based on multi-core communication

Abstract

The invention provides a log collection method and system based on multi-core communication, the method is applied to the log collection system based on multi-core communication, the log collection system based on multi-core communication comprises a master core and a slave core, the master core comprises a master core log component, and the slave core comprises a slave core log component. The master core log component and the slave core log component are in communication connection through an SR interface, and the SR interface communicates through a target communication protocol format; the method comprises the following steps: acquiring a plurality of slave core log requests by a slave core log component, integrating the plurality of slave core log requests to obtain at least one first log request, and sending the first log request to a master core log component through an SR interface; and the main core log component obtains a plurality of main core log requests, integrates the plurality of main core log requests to obtain at least one second log request, and sends the first log request and the second log request to the basic software layer.

Description

Technical Field

[0001] The present invention relates to the field of multi-core communication technologies, and in particular, to a log collection method and system based on multi-core communication. Background Art

[0002] With the development of automotive intelligence and networking, the complexity of multi-core MCUs (multi-core microcontrollers) in electronic control units (ECUs) has increased significantly. During the development, mass production, and after-sales stages, the log system needs to meet characteristics such as high real-time performance, low resource occupancy, and multi-core collaboration.

[0003] In the prior art, the log system generally uses a CS (Client-Server) interface to implement log printing. However, when multiple SWCs (such as sensor drivers, communication modules, task schedulers) concurrently request log operations through the CS interface, they need to compete for the log service resources of the main core, resulting in resource competition and blocking. The CS interface is based on a request-response model, and each log transmission needs to go through a complete communication handshake process, which cannot support batch data transmission. In high-frequency log scenarios, the communication link is likely to become a performance bottleneck. In addition, without a caching mechanism or only relying on volatile memory, the loss of unpersisted logs may occur when the main core service is abnormal. Summary of the Invention

[0004] The present invention aims to solve at least one of the technical problems in the related art to some extent. For this purpose, the first object of the present invention is to propose a log collection method and system based on multi-core communication, which integrates the log requests of the main core and slave cores through the SR interface, and improves the log collection efficiency and reliability by combining online / offline buffer areas.

[0005] The second object of the present invention is to propose a log collection system based on multi-core communication.

[0006] To achieve the above object, the first aspect embodiment of the present invention proposes a log collection method based on multi-core communication, which is applied to a log collection system based on multi-core communication. The log collection system based on multi-core communication includes a main core and slave cores. The main core includes a main core log component, and the slave cores include slave core log components. The main core log component and the slave core log components are communicatively connected through an SR interface, and the SR interface communicates through a target communication protocol format;

[0007] The method includes:

[0008] The slave core log component obtains multiple slave core log requests, integrates the multiple slave core log requests to obtain at least one first log request, and sends the first log request to the main core log component through the SR interface;

[0009] The main core log component obtains multiple main core log requests, integrates the multiple main core log requests to obtain at least one second log request, and sends the first log request and the second log request to the basic software layer.

[0010] In addition, the log collection method based on multi-core communication according to the above embodiments of the present invention may further have the following additional technical features:

[0011] As an optional embodiment, before the slave core log component obtains multiple slave core log requests and the main core log component obtains multiple main core log requests, the method further includes:

[0012] The main core log component sends a registration request to the basic software layer so that the basic software layer establishes a communication channel with the main core log component based on the registration request; wherein, the communication channel is used to transmit the first log request and the second log request.

[0013] As an optional embodiment, the slave core log component is communicatively connected to multiple software components through an SR interface;

[0014] Before the slave core log component obtains multiple slave core log requests, the method further includes:

[0015] The slave core log component periodically checks the update identifier of the target communication protocol format, and determines whether the software component sends a slave core log request to the slave core log component according to the update identifier;

[0016] The slave core log component determines that the software component sends a slave core log request to the slave core log component in response to the update of the update identifier;

[0017] The slave core log component obtains multiple slave core log requests through the SR interface.

[0018] As an optional embodiment, the main core log component is communicatively connected to multiple software components through an SR interface;

[0019] Before the main core log component obtains multiple main core log requests, the method further includes:

[0020] The main core log component periodically checks the update identifier of the target communication protocol format, and determines whether the software component sends a main core log request to the main core log component according to the update identifier;

[0021] The main core log component determines that the software component sends a main core log request to the main core log component in response to the update of the update identifier;

[0022] The main core log component obtains multiple main core log requests through the SR interface.

[0023] As an optional embodiment, integrating multiple slave core log requests includes:

[0024] Obtain the valid request data in multiple slave core log requests, and reorganize the valid request data based on the target communication protocol format to obtain a first log request; wherein, the first log request includes at least one set of standard headers in the target communication protocol format and the valid request data of all slave core log requests.

[0025] As an optional embodiment, integrating multiple master core log requests includes:

[0026] Obtain the valid request data in multiple master core log requests, and reorganize the valid request data based on the target communication protocol format to obtain a second log request; wherein, the second log request includes at least one set of standard headers in the target communication protocol format and the valid request data of all master core log requests.

[0027] As an optional embodiment, the master core includes a first online log buffer and a first offline log buffer; the first online log buffer is used to store the real-time master core log requests of the master core; the first offline log buffer is used to store the historical master core log requests of the master core; the first online log buffer and the first offline log buffer are connected to the operating environment of the log collection system based on multi-core communication through the CS interface, and the master core log component is connected to the operating environment of the log collection system based on multi-core communication through the CS interface; wherein, the historical master core log requests include the second log requests that failed to be sent.

[0028] As an optional embodiment, the slave core includes a second online log buffer; the second online log buffer is used to store the historical slave core log requests of the slave core; wherein, the historical slave core log requests include the first log requests that failed to be sent; the second online log buffer is connected to the operating environment of the log collection system based on multi-core communication through the SR interface.

[0029] As an optional embodiment, the master core log component obtains multiple real-time master core log requests stored in the first online log buffer and / or obtains multiple historical master core log requests stored in the first offline log buffer, integrates the multiple real-time master core log requests and / or multiple historical master core log requests and the first log request to obtain at least one third log request, and sends the third log request to the basic software layer.

[0030] As an optional embodiment, the slave core log component obtains multiple real-time slave core log requests stored in the second online log buffer, integrates the multiple real-time slave core log requests and the second log request to obtain at least one fourth log request, and sends the fourth log request to the basic software layer.

[0031] As an optional embodiment, the log collection system based on multi-core communication further includes a communication support component, which is used to support the basic software layer to establish a communication channel with the main core log component based on a registration request.

[0032] The log collection method based on multi-core communication according to an embodiment of the present invention is applied to a log collection system based on multi-core communication. The log collection system based on multi-core communication includes a main core and slave cores. The main core includes a main core log component, and the slave cores include slave core log components. The main core log component and the slave core log components are communicatively connected through an SR interface. The SR interface communicates through a target communication protocol format. The slave core log components obtain multiple slave core log requests, integrate the multiple slave core log requests to obtain at least one first log request, and send the first log request to the main core log component through the SR interface. The main core log component obtains multiple main core log requests, integrates the multiple main core log requests to obtain at least one second log request, and sends the first log request and the second log request to the basic software layer. The present invention integrates the log requests of the main core and the slave cores through the SR interface, batches the integration of log requests, and reduces the cross-core communication frequency. Combining the online / offline buffer improves the log collection efficiency and reliability. By defining the target communication protocol format of the SR interface, the main core can dynamically schedule the processing order according to the priority, optimize the resource allocation, and facilitate the parsing of the basic software layer. In addition, the main core only needs to process the integrated logs, reducing the computing load.

[0033] To achieve the above object, an embodiment of the second aspect of the present invention proposes a log collection system based on multi-core communication. The log collection system based on multi-core communication includes a main core and slave cores. The main core includes a main core log component, and the slave cores include slave core log components. The main core log component and the slave core log components are communicatively connected through an SR interface. The SR interface communicates through a target communication protocol format. The slave core log components are configured to obtain multiple slave core log requests, integrate the multiple slave core log requests to obtain at least one first log request, and send the first log request to the main core log component through the SR interface. The main core log component is configured to obtain multiple main core log requests, integrate the multiple main core log requests to obtain at least one second log request, and send the first log request and the second log request to the basic software layer.

[0034] A log collection system based on multi-core communication according to an embodiment of the present invention includes a master core and slave cores. The master core includes a master core log component, and the slave cores include slave core log components. The master core log component and the slave core log components are communicatively connected through an SR interface, and the SR interface communicates in a target communication protocol format. The slave core log components are configured to obtain a plurality of slave core log requests, integrate the plurality of slave core log requests to obtain at least one first log request, and send the first log request to the master core log component through the SR interface. The master core log component is configured to obtain a plurality of master core log requests, integrate the plurality of master core log requests to obtain at least one second log request, and send the first log request and the second log request to the basic software layer. The present invention integrates the log requests of the master core and the slave cores through the SR interface, batches and integrates the log requests, reduces the cross-core communication frequency, and improves the log collection efficiency and reliability in combination with the online / offline buffer. By defining the target communication protocol format of the SR interface, the master core can dynamically schedule the processing order according to the priority, optimize the resource allocation, and facilitate the parsing of the basic software layer. In addition, the master core only needs to process the integrated logs, reducing the computing load.

[0035] Additional aspects and advantages of the present invention will be given in part in the following description, become apparent in part from the following description, or be learned through the practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only those of the present invention, and for those of ordinary skill in the art, other drawings can be obtained according to these drawings without creative efforts.

[0037] Figure 1 It is a schematic diagram of the framework of the log collection system based on multi-core communication provided by an embodiment of the present invention.

[0038] Figure 2 It is a schematic diagram of the target communication protocol format provided by an embodiment of the present invention.

[0039] Figure 3 It is a schematic diagram of the process flow of the log collection method based on multi-core communication provided by an embodiment of the present invention.

[0040] Figure 4 It is a schematic diagram of the interaction process between the master core and the slave cores provided by an embodiment of the present invention.

[0041] Figure 5 It is a schematic diagram of the structure of a log collection system based on multi-core communication provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0042] To make the objectives, technical solutions, and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to specific embodiments and the accompanying drawings.

[0043] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the present invention should have the ordinary meanings understood by those with ordinary skills in the field to which the present invention pertains. The "first", "second", and similar terms used in the present invention do not denote any order, quantity, or importance, but are only used to distinguish different components. The terms such as "comprising" or "including" mean that the elements or items appearing before this term cover the elements or items listed after this term and their equivalents, without excluding other elements or items. The terms such as "connected" or "coupled" are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The terms such as "upper", "lower", "left", "right", etc. are only used to represent relative positional relationships, and when the absolute position of the object being described changes, the relative positional relationship may also change accordingly.

[0044] As described in the background art section, with the development of automotive intelligence, the logging system of the multi-core MCU in the ECU needs to meet the requirements of high real-time performance, low load, and high reliability. The traditional logging solution uses the CS (Client-Server) interface to implement logging printing, and has the following defects:

[0045] Resource competition and blocking: When multiple software components (SWCs) make concurrent requests through the CS interface, the main core needs to process them serially, resulting in the slave core being blocked and waiting, and the CPU load increases significantly.

[0046] Low communication efficiency: In high-frequency logging scenarios (such as thousands of ADAS logs per second), the request-response model of the CS interface cannot support batch transmission, and the communication link becomes a performance bottleneck.

[0047] Risk of log loss: Relying on the cache mechanism of volatile memory, the logs that are not persisted when the main core fails are likely to be lost.

[0048] The applicant found in the process of implementing the present invention that although the existing improvement solutions reduce part of the load, they do not solve the problems of multi-core cooperation, log integration, and priority control. Therefore, there is an urgent need for a logging collection solution that takes into account efficiency, reliability, and development convenience.

[0049] Based on this, the present invention proposes a log collection method based on multi-core communication, which is applied to a log collection system based on multi-core communication. The log collection system based on multi-core communication includes a master core and slave cores. The master core includes a master core log component, and the slave cores include slave core log components. The master core log component and the slave core log components are communicatively connected through an SR interface, and the SR interface communicates through a target communication protocol format. The slave core log components obtain multiple slave core log requests, integrate the multiple slave core log requests to obtain at least one first log request, and send the first log request to the master core log component through the SR interface. The master core log component obtains multiple master core log requests, integrates the multiple master core log requests to obtain at least one second log request, and sends the first log request and the second log request to the basic software layer. The present invention integrates the log requests of the master core and the slave cores through the SR interface, batches the integration of log requests, and reduces the cross-core communication frequency. Combining the online / offline buffer improves the log collection efficiency and reliability. By defining the target communication protocol format of the SR interface, the master core can dynamically schedule the processing order according to the priority, optimize the resource allocation, and facilitate the parsing by the basic software layer. In addition, the master core only needs to process the integrated logs, reducing the computing load.

[0050] Hereinafter, the technical solution of the present invention will be further described in detail through specific embodiments.

[0051] Reference Figure 1 , which is a schematic diagram of the framework of the log collection system based on multi-core communication provided by the embodiment of the present invention.

[0052] As Figure 1 shown, the log collection system based on multi-core communication includes a master core (Core0) and slave cores (Core1). The master core (Core0) includes a master core log component (Appl_Log_Master), and the slave cores (Core1) include slave core log components (Appl_Log_Slave). The master core log component (Appl_Log_Master) and the slave core log components (Appl_Log_Slave) are communicatively connected through an SR interface, and among them, the SR interface communicates through a target communication protocol format.

[0053] Specifically, the master core is responsible for managing and coordinating the entire log collection process, while the slave cores are responsible for specific log collection tasks. In the master core, there is at least one master core log component, and in the slave cores, there is at least one slave core log component. These two log components are communicatively connected through the SR interface to achieve data transmission and interaction.

[0054] The main core log component communicates and connects with the software components within the main core through the SR interface. The slave core log component communicates and connects with the software components within the slave core through the SR interface. An SWC (Software Component) is a software entity with specific functions, capable of independent deployment and reuse. It typically includes code, data, and related documentation for implementing specific functions.

[0055] The main core log component can be responsible for receiving and processing log collection requests from software components, managing and configuring the collection tasks of the slave core log component, and performing preliminary processing and storage on the collected log data. The slave core log component can execute specific log collection tasks according to the configuration of the main core log component and send the collected log data to the main core log component through the SR interface.

[0056] The SR interface is a key part of the communication between the main core log component and the slave core log component. It communicates using the target communication protocol format to ensure the correct transmission and parsing of data. The target communication protocol usually includes regulations on data format, transmission method, error handling, etc., to ensure the reliability and efficiency of communication.

[0057] Continue to refer to Figure 1 , according to the common automotive electronic system architecture, these components can belong to the elements within the AUTOSAR (Automotive Open System Architecture) framework.

[0058] Among them, SWC (Software Component) is a software component, SR (Sender-Receiver) and CS (Client-Server) are communication interface types. RTE (Runtime Environment) is the runtime environment in AUTOSAR, and DLT (Diagnostic Log and Trace) is the data link channel for diagnostic logs and tracing. NVM (Non-Volatile Memory) is non-volatile memory, CDD (Complex Device Driver) is a complex device driver, MCAL (Microcontroller Abstraction Layer) is the microcontroller abstraction layer, and Eth, Dio, Port, Spi are specific communication support components (such as Ethernet, digital input / output, port, SPI bus).

[0059] Based on the above structure, the CS interface is used for service calls of other types, such as the communication between the RTE and the DLT. The NVM (offline log buffer) is used to store persistent log data (historical main core log requests). The CDD (online log buffer) is used to store non-persistent log data (real-time main core log requests) and interact with hardware interfaces such as Eth, Dio, Port, and Spi.

[0060] In specific implementation, the basic component DLT itself has a part of cache, but there are some limitations in this part of the cache. If only relying on the data in this part of the cache, it will cause the data not to be sent. When there is still cache space, the data will be stored in the cache first. However, if it cannot be sent, it will cause the loss of some log data. In addition, the data cache does not distinguish the severity level, which may cause the loss of serious log data.

[0061] Based on the above considerations, an NVM cache and a RAM cache are added inside the log component. Different caches are used for data storage in different scenarios, which can not only delay the life consumption of the NVM but also ensure that the log data is not lost. After the sending condition permits, the cached data will be reissued as log data in a first-in, first-out manner, thus ensuring the reliability of data sending in this link.

[0062] As an optional embodiment, the main core includes a first online log buffer and a first offline log buffer; the first online log buffer is used to store the real-time main core log requests of the main core; the first offline log buffer is used to store the historical main core log requests of the main core; the first online log buffer and the first offline log buffer are connected to the operating environment of the log collection system based on multi-core communication through the CS interface, and the main core log component is connected to the operating environment of the log collection system based on multi-core communication through the CS interface; among them, the historical main core log requests include the second log requests that failed to be sent.

[0063] Specifically, the first online log buffer (CCD) can store real-time main core log requests (such as system monitoring data, task scheduling status). The storage is implemented using RAM (Random Access Memory), which supports high-speed reading and writing (nanosecond-level response). The first offline log buffer (NVM-Flash) stores historical main core log requests, including the logs that failed to be sent due to network interruption or unavailable DLT services. The storage is implemented using non-volatile memory (NVM, such as Flash) to ensure that the data is not lost during power-off or system crash.

[0064] It should be noted that when the DLT communication resumes, the main core log component can preferentially read the high-priority logs (such as error logs) in the offline cache and retransmit them through the CS interface.

[0065] As an optional embodiment, the slave core includes a second online log buffer; the second online log buffer is used to store the historical slave core log requests of the slave core; wherein, the historical slave core log requests include the first log requests that failed to be sent; the second online log buffer accesses the operating environment of the log collection system based on multi-core communication through the SR interface.

[0066] Specifically, similar to the first offline log buffer (NVM-Flash), the second offline log buffer (NVM-Flash) stores historical master core log requests, including the logs that failed to be sent due to network interruption or unavailability of the DLT service. The storage is implemented using non-volatile memory (NVM, such as Flash) to ensure data is not lost during power failure or system crash.

[0067] It should be noted that when the DLT communication resumes, the slave core log component can preferentially read the high-priority logs (such as error logs) in the offline cache and retransmit them through the CS interface.

[0068] Reference Figure 2 , which is a schematic diagram of the target communication protocol format provided by the embodiment of the present invention.

[0069] In the embodiment of the present invention, the SR interface is adopted to replace the CS interface, and non-blocking communication is implemented based on the producer-consumer model. A standard log protocol format is defined, including fields: MessageID (SWC identification), UpdateFlag (update flag), Length (data length), parsing identification (data semantics), Data (log content), etc.

[0070] Specifically, the target communication protocol format includes messageID (component name), Updata flag (incremented by 1 when transmission is required), Length (data length), parsing identification (data meaning), data (data content). The log component periodically detects the Updata flag of each SWC component to determine whether the SWC has a transmission requirement. If there is a transmission requirement, all SWC log interfaces of this component are checked, and log data is packaged based on the inspection results and uniformly sent to the log component of the master core, thereby further reducing the number of inter-core interactions. This action can reduce the CPU and bus load.

[0071] Inside the log component, the operation of relevant log level codes is controlled by the externally controlled log level. While ensuring the function, it ensures that the useless consumption of CPU Load is reduced, and further ensures the stability of the system.

[0072] Among them, the messageID (component name) is used to identify which software component (SWC) the log data comes from, which helps to quickly locate the source of the problem during log analysis. The Update flag (update flag) is used to increment this flag by 1 when the component has new log data to send, and the log component determines whether there is new log data to collect by checking this flag. The Length (data length) represents the length of the log data content, which helps the log component to correctly parse and transmit the log data. The parsing identifier (data meaning) is used to identify the specific meaning or type of the log data, which helps the log receiver to correctly parse the log data. The data (data content) is the actual log data, which can be in text, binary or other formats, depending on the type of log data.

[0073] Reference Figure 3 , which is a schematic flow diagram of the log collection method based on multi-core communication provided by the embodiment of the present invention.

[0074] Step S301, obtain multiple slave-core log requests from the slave-core log component, integrate the multiple slave-core log requests to obtain at least one first log request, and send the first log request to the master-core log component through the SR interface.

[0075] Specifically, the slave-core log component is responsible for collecting and processing log requests from each slave-core software component (SWC), and these log requests can contain different log data, such as errors, warnings, information, etc. Further, the slave-core log component integrates the multiple collected log requests. The integration can include merging log requests with the same or similar attributes into one request, or performing operations such as sorting and priority assignment on the log requests. Further, the integrated log request (the first log request) is sent to the master-core log component through the SR interface (application target communication protocol format). The SR interface ensures that the log request can be reliably transmitted from the slave-core log component to the master-core log component.

[0076] Step S302, the master-core log component obtains multiple master-core log requests, integrates the multiple master-core log requests to obtain at least one second log request, and sends the first log request and the second log request to the basic software layer.

[0077] Specifically, in addition to receiving the first log request from the slave core log component, the master core log component can also receive log requests from other software components on the master core. The master core log component integrates multiple received log requests (including the first log request and other log requests on the master core). The integration process is similar to that of the slave core log component, including operations such as merging, sorting, and priority assignment. Further, the integrated log request (the second log request) is sent to the basic software layer. The basic software layer can be a system component responsible for log storage, analysis, display, or further processing.

[0078] As an optional embodiment, before the slave core log component obtains multiple slave core log requests and the master core log component obtains multiple master core log requests, the method further includes: the master core log component sends a registration request to the basic software layer, so that the basic software layer establishes a communication channel with the master core log component based on the registration request; wherein, the communication channel is used to transmit the first log request and the second log request.

[0079] Specifically, before starting the processing and integration of log requests, the master core log component first sends a registration request to the basic software layer. This registration request can include information such as the identity information of the master core log component, the type and parameters of the communication channel expected to be established, etc. Further, after receiving the registration request, the basic software layer will verify the validity of the request and configure the corresponding communication resources according to the information in the request. If the registration request is valid and the resources are available, the basic software layer will accept the registration request and establish a communication channel with the master core log component. The established communication channel will be used for subsequent transmission of the integrated log request, which means that once the communication channel is successfully established, the master core log component can send the first log request and the second log request to the basic software layer through this channel.

[0080] As an optional embodiment, the slave core log component is communicatively connected to multiple software components through the SR interface; before the slave core log component obtains multiple slave core log requests, the method further includes: the slave core log component periodically checks the update identifier of the target communication protocol format, determines whether the software component sends a slave core log request to the slave core log component according to the update identifier; the slave core log component determines that the software component sends a slave core log request to the slave core log component in response to the update of the update identifier; the slave core log component obtains multiple slave core log requests through the SR interface.

[0081] Specifically, the slave core logging component needs to ensure that it can respond to the logging requests sent by the software component in a timely manner. For this purpose, a periodic check mechanism is adopted, that is, the slave core logging component will periodically check one or more update identifiers. These update identifiers can be stored in specific memory locations or registers to indicate whether the software component has new logging requests to send. The slave core logging component will read the value of the update identifier and determine whether the software component has sent a logging request to it according to the preset logic or rules. Among them, the value of the update identifier can represent various states, such as "no new request", "new request to be processed", etc. When the slave core logging component detects a change in the value of the update identifier, that is, a new logging request, it will trigger the corresponding response mechanism. Among them, the response mechanism can include preparing to receive data, allocating memory space, starting the data reception process, etc. Once the slave core logging component is ready to receive the logging request, it will communicate with the software component through the SR interface. The SR interface ensures that data can be transmitted between the slave core logging component and the software component in the correct format and order. The slave core logging component will receive and store these logging requests for subsequent integration and processing.

[0082] As can be seen from the above, by periodically checking the update identifier, the slave core logging component can manage its communication with the software component more efficiently, reducing unnecessary waiting time and resource waste. This mechanism ensures that the slave core logging component can respond to the logging requests of the software component in a timely manner, thus improving the reliability and stability of the entire system.

[0083] It should be noted that the embodiments of the present invention allow the slave core logging component to flexibly adjust its behavior according to the value of the update identifier to adapt to different working scenarios and requirements.

[0084] As an optional embodiment, the master core logging component is communicatively connected to multiple software components through the SR interface; before the master core logging component obtains multiple master core logging requests, the method further includes: the master core logging component periodically checks the update identifier in the target communication protocol format, and determines whether the software component has sent a master core logging request to the master core logging component according to the update identifier; the master core logging component determines that the software component has sent a master core logging request to the master core logging component in response to the update identifier update; the master core logging component obtains multiple master core logging requests through the SR interface.

[0085] Specifically, to ensure that the main core log component can respond promptly to main core log requests from different software components, a strategy of periodically checking and updating identifiers is also adopted. The main core log component will regularly (for example, at a preset time interval) check the status of one or more update identifiers. These update identifiers are usually stored in specific memory locations or registers and are used to indicate whether there are new log requests pending processing. The main core log component will judge whether there are new main core log requests waiting to be processed based on the value of the read update identifier through preset logic or rules. The value of the update identifier can represent states such as "no new request" and "new request pending processing". The main core log component will trigger corresponding operations based on these states. When the main core log component detects a change in the value of the update identifier, that is, it indicates that there is a new main core log request, it will trigger a corresponding response mechanism. The response mechanism can include preparing to receive data, allocating memory space, starting the data reception process, etc., in order to receive log requests from the software component. Once the main core log component is ready to receive log requests, it will communicate with the software component through the SR interface (a format of an application target communication protocol). The SR interface ensures that data can be transmitted between the main core log component and the software component in the correct format and order. The main core log component will receive and store these log requests for subsequent integration and processing.

[0086] As can be seen from the above, by periodically checking the update identifier, the main core log component can respond more quickly to log requests from software components and reduce waiting time. This mechanism ensures that the main core log component can promptly process all log requests from software components, thereby improving the reliability and stability of the entire system. By avoiding unnecessary waiting and polling, the embodiments of the present invention help to optimize the utilization of system resources and improve overall performance.

[0087] As an optional embodiment, integrating multiple slave core log requests includes: obtaining valid request data in multiple slave core log requests, and reorganizing the valid request data based on the target communication protocol format to obtain a first log request; wherein, the first log request includes at least one set of standard headers in the target communication protocol format and the valid request data of all slave core log requests.

[0088] Specifically, the slave core log component first extracts valid request data from multiple slave core log requests. This valid request data is the log information that actually needs to be processed and transmitted. During the extraction process, the slave core log component may filter the valid request data according to preset rules or conditions to ensure the accuracy and integrity of the data. To transmit the valid request data to the master core log component in the correct format, the slave core log component needs to reorganize the data according to the target communication protocol format. The reorganization process may include adding necessary protocol headers, check codes, data delimiters and other elements, or eliminating duplicate elements to ensure the integrity, accuracy and simplicity of the data during transmission. At the same time, the slave core log component also needs to sort and package the data according to the requirements of the protocol. The reorganized data will form the first log request. This request includes at least one set of standard headers in the target communication protocol format, as well as the valid request data of all slave core log requests. The standard headers usually contain basic information about the log request, such as the request type, the identifiers of the sender and receiver, the data length, etc. This information is crucial for the master core log component to correctly parse and process the log request. In the first log request, the valid request data of all slave core log requests will be organized in an orderly manner so that the master core log component can easily extract and process it.

[0089] As an optional embodiment, integrating multiple master core log requests includes: obtaining the valid request data in multiple master core log requests, reorganizing the valid request data based on the target communication protocol format to obtain a second log request; wherein, the second log request includes at least one set of standard headers in the target communication protocol format and the valid request data of all master core log requests.

[0090] Specifically, the main core log component first extracts valid request data from multiple main core log requests. This valid request data is the log information that actually needs to be processed or transmitted subsequently. During the extraction process, the main core log component performs necessary filtering and verification to ensure that the extracted data is accurate, complete, and meets expectations. In order to integrate the valid request data into a log request in a format that conforms to the target communication protocol, the main core log component also needs to reorganize the data according to the format specified by the protocol. The reorganization process can also include adding protocol headers (including request type, data length, check information, etc.), delimiters, padding bytes, etc., or deleting duplicate elements to ensure the integrity and parsability of the data. At the same time, the main core log component also performs operations such as sorting, segmenting, or packing the data according to the protocol requirements. The reorganized data will form the second log request. This request includes at least one set of standard headers in the format of the target communication protocol, as well as the valid request data of all main core log requests. The standard headers provide basic information about the second log request, such as request type, sender and receiver identifiers, data length, check information, etc. This information is crucial for the receiver to correctly parse and process the log request. In the second log request, the valid request data of all main core log requests is organized in an orderly manner so that the receiver can easily extract and process it.

[0091] As can be seen from the above, by integrating multiple slave core log requests and generating the first log request and the second log request that conform to the target communication protocol format, the number of data transmissions and overhead can be reduced, thereby improving the data transmission efficiency. Reorganizing and packing the data according to the target communication protocol format can ensure the integrity and accuracy of the data during transmission and reduce the risk of data loss or damage. By integrating the log requests, the occupation of system resources such as memory and processor time can be reduced, thereby optimizing resource utilization.

[0092] As an optional embodiment, the method further includes: the main core log component obtains multiple real-time main core log requests stored in the first online log buffer and / or obtains multiple historical main core log requests stored in the first offline log buffer, integrates the multiple real-time main core log requests and / or multiple historical main core log requests and the first log request to obtain at least one third log request, and sends the third log request to the basic software layer.

[0093] The embodiment of the present invention further expands the function of the main core log component, enabling it to process and integrate log requests from different sources, including real-time log requests, historical log requests, and the previously mentioned integrated log request (the first log request), and sending the integrated result (the third log request) to the basic software layer.

[0094] Specifically, the main core log component retrieves multiple real-time main core log requests from the first online log buffer. These requests are usually generated in real time by active components in the system, reflecting the current state of the system. At the same time, the main core log component can also retrieve multiple historical main core log requests from the first offline log buffer. These requests record the past activities and states of the system and are usually applied to issue tracking, performance analysis, etc.

[0095] Furthermore, the main core log component further integrates the retrieved real-time log requests, historical log requests, and the previously integrated first log request (which may contain log data from slave cores). The integration strategy can include sorting, merging, or segmenting the data according to factors such as the timestamp, importance, and source of the logs. In addition, the main core log component may also need to add additional metadata or tags to distinguish log data from different sources in subsequent processing. The integrated data will form at least one third log request. This request may contain log data from multiple different sources but is organized in a manner that conforms to the format of the target communication protocol. The format and structure of the third log request will follow the requirements of the target communication protocol to ensure that the data can be correctly parsed and processed when transmitted to the basic software layer. The main core log component sends the generated third log request to the basic software layer. The basic software layer can be a key component in the system responsible for further processing, storing, or forwarding log data. The sending process can be carried out through a specific communication interface or protocol to ensure the reliable transmission and reception of the data

[0096] As an optional embodiment, the slave core log component retrieves multiple real-time slave core log requests stored in the second online log buffer, integrates the multiple real-time slave core log requests and the second log request to obtain at least one fourth log request, and sends the fourth log request to the basic software layer.

[0097] In the embodiments of the present application, the functions of the log processing system are further extended, especially for the slave core log component. The slave core log component not only processes the log data generated by the slave core, but also is responsible for further integrating these data with the previously integrated log requests (the second log requests, which may contain log data from other slave cores or the master core), and sending the integrated result to the basic software layer. The slave core log component retrieves multiple real-time slave core log requests from the second online log buffer. These requests are generated in real time by the slave core and reflect the current active state and log information of the slave core. The second online log buffer serves as a temporary storage area for temporarily storing the log requests generated by the slave core until they are processed by the slave core log component. The slave core log component further integrates the retrieved real-time slave core log requests with the previously integrated second log requests (which may contain log data from other slave cores or the master core). The integration process includes operations such as sorting, merging, segmenting, or adding additional metadata to the log data to ensure that the integrated log requests can clearly reflect the overall operating state of the system. The second log request serves as the benchmark for integration and may already contain data from other log sources. The slave core log component needs to combine these newly retrieved real-time slave core log requests with the data in the second log request to form a more complete and accurate log record. The integrated data will constitute at least one fourth log request. This request may contain real-time log data from multiple different slave cores and other previously integrated log data. The format and structure of the fourth log request will follow the requirements of the target communication protocol to ensure that the data can be correctly parsed and processed when transmitted to the basic software layer. The slave core log component sends the generated fourth log request to the basic software layer. The sending process may be carried out through a specific communication interface or protocol to ensure the reliable transmission and reception of the data.

[0098] As can be seen from the above, by integrating log requests from different sources, the master core log component can provide more comprehensive and detailed log information, which helps system administrators or developers better understand the operating state and problems of the system. Integrating multiple log requests into one or a few third log requests and fourth log requests for transmission can reduce the number and overhead of data transmission, thereby improving the transmission efficiency. This embodiment enables the system to more flexibly process log data from different sources and types, which helps to enhance the maintainability and scalability of the system.

[0099] As an optional embodiment, the log collection system based on multi-core communication further includes a communication support component, which is used to support the basic software layer to establish a communication channel with the master core log component based on a registration request.

[0100] The communication support component is a key part of the log collection system, which is specifically responsible for supporting the communication between the basic software layer and the main core log component. The core function of this component is to process registration requests and assist in establishing and maintaining a communication channel between the basic software layer and the main core log component. This channel is the bridge for data transmission, ensuring that log data can be accurately transmitted from the main core log component to the basic software layer.

[0101] Specifically, during the system initialization or configuration phase, the basic software layer will initiate a registration request to the communication support component. This request usually includes the identity information of the basic software layer, desired communication parameters (such as port numbers, communication protocols, etc.) and other necessary configuration information. After receiving the registration request, the communication support component will verify it to ensure the validity and legality of the request. Once the verification is passed, the communication support component will register the information of the basic software layer in the internal database and assign a unique communication identifier to it. After the registration is completed, the communication support component will use the registered communication parameters and identifiers to establish a stable communication channel between the basic software layer and the main core log component. This channel can be a TCP / IP-based network connection, shared memory, message queue, etc., depending on the system design and requirements.

[0102] The communication support component will continuously monitor the status of the communication channel to ensure its stability and reliability. Once a channel failure or anomaly is detected, the component will immediately take measures to repair or rebuild the channel. After the communication channel is established, the main core log component can transmit the integrated log data (such as the third log request, the fourth log request, etc.) to the basic software layer through this channel. After receiving the data, the basic software layer will perform further processing, storage or forwarding.

[0103] As can be seen from the above, by introducing the communication support component, the system can more effectively manage the communication between the basic software layer and the main core log component, thereby improving communication efficiency and reliability. As the number of log sources in the system increases or the log requirements change, the communication support component can easily adjust the communication strategy and resource allocation to meet the new requirements. This enables the system to more flexibly adapt to the changing environment and requirements. The communication support component provides a centralized communication management interface, enabling system administrators to more conveniently configure and manage communication channels. This helps to reduce the complexity of system configuration and improve the maintainability of the system.

[0104] Reference Figure 4 , is the schematic diagram of the interaction process between the main core and the slave core provided by the embodiment of the present invention.

[0105] Slave core side log collection (Core1):

[0106] After the software component SWC generates a log, it is asynchronously sent to the slave core log component Appl_Log_Slave through the SR interface.

[0107] The slave core log component Appl_Log_Slave integrates the logs of multiple SWCs in the protocol format (including fields such as MessageID and UpdateFlag) to generate the first log request.

[0108] The integrated log is sent to the master core log component Appl_Log_Master through the SR interface to avoid blocking the operation of the slave core.

[0109] Master core side log processing (Core0):

[0110] The master core log component Appl_Log_Master merges the master core's own logs (such as system monitoring data) with the first log request uploaded from the slave core to generate the second log request.

[0111] The integrated log is submitted to the DLT module through the CS interface. If the network is abnormal, the log is temporarily stored in the NVM and automatically resent after recovery.

[0112] Underlying hardware interaction:

[0113] The microcontroller abstraction layer drives hardware interfaces such as digital input / output (Dio), port (Port), and SPI bus.

[0114] The complex device driver manages Ethernet communication and supports remote log transmission (such as reporting to the cloud).

[0115] Combined Figure 3 and Figure 4 , the implementation example of the present invention is different from the traditional way of implementing handwritten stub code. The implementation example of the present invention realizes the printing of log data through the interaction of the SR interface, reduces the requirement for handwritten code in the subsystem, ensures the integrity of the SWC model design, reduces the requirement for log development skills of the SWC, and can further improve the efficiency of application layer development. The log component will packetize the log content of each SWC based on the unit of the subsystem, and shift the packetization workload to the log component for unified management, thereby reducing the complexity of log development for each SWC and making it more convenient for subsequent problem troubleshooting.

[0116] As can be seen from the above, the log collection method based on multi-core communication provided by the present invention is applied to a log collection system based on multi-core communication. The log collection system based on multi-core communication includes a master core and slave cores. The master core includes a master core log component, and the slave cores include slave core log components. The master core log component and the slave core log components are communicatively connected through an SR interface, and the SR interface communicates in a target communication protocol format. The slave core log components obtain a plurality of slave core log requests, integrate the plurality of slave core log requests to obtain at least one first log request, and send the first log request to the master core log component through the SR interface. The master core log component obtains a plurality of master core log requests, integrates the plurality of master core log requests to obtain at least one second log request, and sends the first log request and the second log request to the basic software layer. The present invention integrates the log requests of the master core and the slave cores through the SR interface, batch-integrates the log requests, and reduces the cross-core communication frequency. Combining with an online / offline buffer improves the log collection efficiency and reliability. By defining the target communication protocol format of the SR interface, the master core can dynamically schedule the processing order according to the priority, optimize the resource allocation, and facilitate the parsing by the basic software layer. In addition, the master core only needs to process the integrated logs, reducing the computing load.

[0117] It should be noted that the method of the embodiment of the present invention can be executed by a single device, such as a computer or a server. The method of this embodiment can also be applied to a distributed scenario, and is completed by multiple devices cooperating with each other. In this case of a distributed scenario, one of the multiple devices can only execute one or more steps of the method of the embodiment of the present invention, and these multiple devices will interact with each other to complete the described method.

[0118] It should be noted that some embodiments of the present invention have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be executed in a different order from that in the above embodiments and still achieve the desired results. Additionally, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0119] Based on the same inventive concept, corresponding to the method provided in any of the above embodiments, the present invention also provides a log collection system based on multi-core communication.

[0120] Refer to Figure 5 , which is a schematic structural diagram of a log collection system based on multi-core communication provided by an embodiment of the present invention.

[0121] The log collection system 500 based on multi-core communication includes: a main core 502 and a slave core 501. The main core 502 includes a main core log component, and the slave core 501 includes a slave core log component. The main core log component and the slave core log component are communicatively connected through an SR interface, and the SR interface communicates in a target communication protocol format. The slave core log component is configured to obtain a plurality of slave core log requests, integrate the plurality of slave core log requests to obtain at least one first log request, and send the first log request to the main core log component through the SR interface. The main core log component is configured to obtain a plurality of main core log requests, integrate the plurality of main core log requests to obtain at least one second log request, and send the first log request and the second log request to the basic software layer.

[0122] A log collection system based on multi-core communication according to an embodiment of the present invention includes a main core and a slave core. The main core includes a main core log component, and the slave core includes a slave core log component. The main core log component and the slave core log component are communicatively connected through an SR interface, and the SR interface communicates in a target communication protocol format. The slave core log component is configured to obtain a plurality of slave core log requests, integrate the plurality of slave core log requests to obtain at least one first log request, and send the first log request to the main core log component through the SR interface. The main core log component is configured to obtain a plurality of main core log requests, integrate the plurality of main core log requests to obtain at least one second log request, and send the first log request and the second log request to the basic software layer. The present invention integrates the log requests of the main core and the slave core through the SR interface, batches and integrates the log requests, and reduces the cross-core communication frequency. Combining with an online / offline buffer improves the log collection efficiency and reliability. By defining the target communication protocol format of the SR interface, the main core can dynamically schedule the processing order according to the priority, optimize the resource allocation, and facilitate the parsing of the basic software layer. In addition, the main core only needs to process the integrated logs, reducing the computing load.

[0123] For the convenience of description, when describing the above system, various modules are described separately according to their functions. Of course, when implementing the present invention, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0124] The system of the above embodiment is used to implement the corresponding method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be described herein again.

[0125] In addition, although the operations of the method of the present invention are described in a specific order in the drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart can be changed in the order of execution. Additionally or alternatively, some steps can be omitted, multiple steps can be combined into one step for execution, and / or one step can be decomposed into multiple steps for execution.

[0126] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, any one or a combination of the following techniques well known in the art can be used: discrete logic circuits having logic gate circuits for implementing logical functions on data signals, application specific integrated circuits having appropriate combinational logic gate circuits, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0127] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present invention should have the ordinary meanings understood by those of ordinary skill in the art to which the present invention pertains. The "first", "second", and similar terms used in the embodiments of the present invention do not denote any order, quantity, or importance, but are only used to distinguish different components. Words such as "comprising" or "including" mean that the elements or items appearing before this word cover the elements or items listed after this word and their equivalents, without excluding other elements or items. Words such as "connected" or "coupled" are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "Up", "down", "left", "right", etc. are only used to represent relative positional relationships, and when the absolute position of the object being described changes, the relative positional relationship may also change accordingly.

[0128] Although the spirit and principles of the present invention have been described with reference to several specific embodiments, it should be understood that the present invention is not limited to the specific embodiments disclosed, and the division of various aspects does not mean that the features in these aspects cannot be combined for benefits. This division is only for convenience of description. The present invention aims to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. The scope of the appended claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.

Claims

1. A log collection method based on multi-core communication, which is applied to a log collection system based on multi-core communication. The log collection system based on multi-core communication includes a main core and slave cores. The main core includes a main core log component, and the slave cores include slave core log components. The main core log component and the slave core log components are communicatively connected through an SR interface. It is characterized in that, The SR interface communicates in the format of the target communication protocol; The method includes: Obtaining a plurality of slave core log requests from the slave core log component, integrating the plurality of slave core log requests to obtain at least one first log request, and sending the first log request to the master core log component through the SR interface; The master core log component obtains a plurality of master core log requests, integrates the plurality of master core log requests to obtain at least one second log request, and sends the first log request and the second log request to the basic software layer.

2. The log collection method based on multi-core communication according to claim 1, characterized in that: Before the slave core log component obtains a plurality of slave core log requests and the master core log component obtains a plurality of master core log requests, the method further includes: The master core log component sends a registration request to the basic software layer, so that the basic software layer establishes a communication channel with the master core log component based on the registration request; wherein, the communication channel is used to transmit the first log request and the second log request.

3. The log collection method based on multi-core communication according to claim 2, characterized in that: The slave core log component is communicatively connected to a plurality of software components through the SR interface; Before the slave core log component obtains a plurality of slave core log requests, the method further includes: The slave core log component periodically checks the update identifier of the target communication protocol format, and determines whether the software component sends a slave core log request to the slave core log component according to the update identifier; The slave core log component determines that the software component sends a slave core log request to the slave core log component in response to the update of the update identifier; The slave core log component obtains the plurality of slave core log requests through the SR interface.

4. The log collection method based on multi-core communication according to claim 2, characterized in that: The master core log component is communicatively connected to a plurality of software components through the SR interface; Before the master core log component obtains a plurality of master core log requests, the method further includes: The master core log component periodically checks the update identifier of the target communication protocol format, and determines whether the software component sends a master core log request to the master core log component according to the update identifier; The master core log component determines that the software component sends a master core log request to the master core log component in response to the update of the update identifier; The master core log component obtains the plurality of master core log requests through the SR interface.

5. The log collection method based on multi-core communication according to claim 3, wherein The integration of the plurality of slave core log requests includes: Obtaining the valid request data in the plurality of slave core log requests, and reorganizing the valid request data based on the target communication protocol format to obtain the first log request; wherein, the first log request includes at least one set of standard headers in the target communication protocol format and all the valid request data of the plurality of slave core log requests.

6. The log collection method based on multi-core communication according to claim 5, characterized in that The integration of the plurality of master core log requests includes: Obtaining the valid request data in the plurality of master core log requests, and reorganizing the valid request data based on the target communication protocol format to obtain the second log request; wherein, the second log request includes at least one set of standard headers in the target communication protocol format and all the valid request data of the plurality of master core log requests.

7. The log collection method based on multi-core communication according to any one of claims 1-6, characterized in that The main core includes a first online log buffer and a first offline log buffer; the first online log buffer is used to store real-time main core log requests of the main core; the first offline log buffer is used to store historical main core log requests of the main core; the first online log buffer and the first offline log buffer are connected to the operating environment of the log collection system based on multi-core communication through a CS interface, and the main core log component is connected to the operating environment of the log collection system based on multi-core communication through a CS interface; wherein, the historical main core log requests include the second log requests that failed to be sent.

8. The log collection method based on multi-core communication according to any one of claims 1-6, characterized in that, The slave core includes a second online log buffer; the second online log buffer is used to store historical slave core log requests of the slave core; wherein, the historical slave core log requests include the first log requests that failed to be sent; the second online log buffer is connected to the operating environment of the log collection system based on multi-core communication through an SR interface.

9. The log collection method based on multi-core communication according to claim 7, wherein The method further includes: The main core log component obtains a plurality of real-time main core log requests stored in the first online log buffer and / or obtains a plurality of historical main core log requests stored in the first offline log buffer, integrates the plurality of real-time main core log requests and / or the plurality of historical main core log requests and the first log request to obtain at least one third log request, and sends the third log request to the basic software layer.

10. The method for collecting logs based on multi-core communication according to claim 8, wherein The method further includes: The slave core log component obtains a plurality of real-time slave core log requests stored in the second online log buffer, integrates the plurality of real-time slave core log requests and the second log request to obtain at least one fourth log request, and sends the fourth log request to the basic software layer.

11. The method for log collection based on multi-core communication according to claim 2, wherein The log collection system based on multi-core communication further includes a communication support component, and the communication support component is used to support the basic software layer to establish a communication channel with the main core log component based on the registration request.

12. A log collection system based on multi-core communication, characterized in that: The log collection system based on multi-core communication includes a main core and a slave core, the main core includes a main core log component, the slave core includes a slave core log component, the main core log component and the slave core log component are communicatively connected through an SR interface, and is characterized in that the SR interface communicates through a target communication protocol format; The slave core log component is configured to obtain a plurality of slave core log requests, integrate the plurality of slave core log requests to obtain at least one first log request, and send the first log request to the main core log component through the SR interface; The main core log component is configured to obtain a plurality of main core log requests, integrate the plurality of main core log requests to obtain at least one second log request, and send the first log request and the second log request to the basic software layer.

Images