Log storage method, computing device, storage medium and computer program product
By replacing the DLS identification field in the DLS data stream on the microcontroller side with the DLT storage header field, the problem of incomplete log data storage and dependence on specific tools in the prior art is solved, and an efficient and portable log storage solution is realized.
Patent Information
- Application Number
- CN202411709796.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-27
- Publication Date
- 2025-03-14
AI Technical Summary
The prior art lacks a simple and efficient solution to store log data generated on the microcontroller side to the system controller side, and there are problems of data loss, multiple data copies, and dependence on a specific operating system or tool.
By receiving the DLS data stream, identifying the DLS identification field in the DLS stream packet and replacing it with the DLT storage header field, obtaining the corresponding DLT data packet, thereby realizing the storage of the DLT log file.
It realizes complete storage of MCU-side log data, avoids data loss and multiple data copies, reduces the risk of relying on specific tools, improves log storage efficiency and improves portability.
Smart Images

Figure CN119621693A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of computer technology, and in particular, to a log storage method, a computing device, a computer-readable storage medium, and a computer program product. Background Art
[0002] In some electronic systems, there may be several microcontrollers and a unified system controller. These microcontrollers may be configured to perform different functions or tasks, and may generate or collect log data during operation. The system controller may obtain data from each microcontroller, and perform functions such as analysis, decision-making, and storage based on the acquired data. Taking an automotive electronic system as an example, there are usually several MCUs (Microcontroller Units) and SoCs (System on Chips) coupled to these MCUs for communication, wherein different MCUs may be present in ECUs (Electronic Control Units) for performing different functions. Since the storage space at the microcontroller is usually small, generally speaking, the log data generated on the microcontroller side such as the MCU needs to be forwarded to the system controller side (such as the SoC side) for storage. However, there is currently a lack of a simple and efficient solution for storing the log data generated on the microcontroller side to the system controller side. Summary of the invention
[0003] In view of this, the present disclosure provides a log storage method, a computing device, a computer-readable storage medium, and a computer program product, which can alleviate, mitigate, or even eliminate the above-mentioned problems.
[0004] According to one aspect of the present disclosure, a log storage method is provided, including: receiving a DLS data stream, wherein the DLS data stream includes at least one DLS stream data packet, and each of the at least one DLS stream data packet has a DLS identification field; for each DLS stream data packet, replacing the DLS identification field in the DLS stream data packet with a DLT storage header field to obtain a DLT data packet corresponding to the DLS stream data packet; and storing a DLT log file based on the obtained DLT data packet.
[0005] In some embodiments, the log storage method further includes: in the DLS data stream, determining a DLS stream data packet based on each data segment starting with a DLS identification field.
[0006] In some embodiments, in a DLS data stream, determining a DLS stream data packet based on each data segment starting with a DLS identification field includes: storing the DLS data stream in a target container; searching for the DLS identification field in the target container; in response to searching for two adjacent DLS identification fields, determining a DLS stream data packet based on the data segments defined by the two adjacent DLSs.
[0007] In some embodiments, storing the DLS data stream to the target container includes: adding the DLS data stream to the end of the target container, and, wherein searching the target container for the DLS identification field includes: searching the target container for the DLS identification field in order from the beginning to the end.
[0008] In some embodiments, replacing the DLS identification field in the DLS stream data packet with the DLT storage header field includes: using a method provided by the DLT open source library for setting the storage header field to replace the DLS identification field with the DLT storage header field.
[0009] In some embodiments, receiving the DLS data stream includes: receiving the data stream; and in response to detecting the DLS identification field in the data stream, acquiring the DLS data stream based on the data stream.
[0010] In some embodiments, the DLT storage header field includes: a DLT identifier, a timestamp, and an identifier indicating the source of the corresponding DLS stream data packet.
[0011] According to another aspect of the present disclosure, a computing device is provided, comprising: a memory configured to store computer-executable instructions; and a processor configured to execute the method described in any one of the embodiments of the foregoing aspects when the computer-executable instructions are executed by the processor.
[0012] According to another aspect of the present disclosure, a computer-readable storage medium is provided, which stores computer-executable instructions. When the computer-executable instructions are executed, the method described in any one of the embodiments in the aforementioned aspects is executed.
[0013] According to another aspect of the present disclosure, a computer program product is provided, comprising computer executable instructions, wherein the computer executable instructions implement the steps of the method described in any one of the embodiments in the aforementioned aspects when executed by a processor.
[0014] In the log storage solution provided by the present disclosure, a DLS data stream including at least one DLS stream data packet can be received from a microcontroller. For each DLS stream data packet, the DLS identification field therein can be replaced with the DLT storage header field to obtain the corresponding DLT data packet, thereby realizing the storage of the DLT log file. Through the above solution, the corresponding DLT data packet can be obtained simply and efficiently based on the received DLS stream data, which helps to improve the storage efficiency of the DLT log file. In addition, the above operation does not depend on a specific operating system or tool, so it has good portability.
[0015] These and other aspects of the disclosure will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] Further details, features and advantages of the present disclosure are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which:
[0017] Figure 1 An example flow chart of a DLT log file storage solution in the related art is schematically shown;
[0018] Figure 2 An example flow chart of a log storage method according to some embodiments of the present disclosure is schematically shown;
[0019] Figure 3 Schematically illustrates an example data structure of a DLS stream data packet;
[0020] Figure 4 Schematically illustrates an example data structure of a DLT data packet;
[0021] Figure 5 An example of an abnormal DLS flow data packet is schematically shown;
[0022] Figure 6 An exemplary block diagram of a computing device according to some embodiments of the present disclosure is schematically shown. DETAILED DESCRIPTION
[0023] DLT (Diagnostic Log and Trace) is a logging and communication protocol for diagnosis and tracing, which is widely used in fields involving logging, such as automotive electronic systems. For example, it can be used in automotive electronic systems based on the AUTOSAR architecture (AUTomotive Open System Architecture). In the present disclosure, a DLT data packet should be understood as a data packet that complies with the DLT protocol, which can be stored as a DLT log file, such as a "*.dlt" file, where "*" is a customizable file name. DLS (DLT stream) is a data stream format for recording and transmitting diagnostic information, suitable for automotive electronics, embedded systems and other environments that require logging. In the present disclosure, a DLS stream data packet should be understood as a stream data packet that complies with the DLS data stream format, and a DLS data stream may include one or more DLS stream data packets.
[0024] Taking the car cockpit system based on the QNX operating system as an example, the MCU in the system usually generates log data in DLT format. Due to the limited storage space on the MCU side, the generated log data needs to be transferred to an external storage device or transmitted to an external device for storage. Exemplarily, the log data generated on the MCU side can be forwarded to the SoC side in the form of a DLS data stream via inter-domain communication. On the SoC side, the DLS data stream can be received by a module, then parsed and processed, and finally stored as a DLT log file.
[0025] In order to store the DLS data stream from the MCU as the corresponding DLT log file on the SoC side, some technicians have adopted Figure 1 The DLT log file storage method 100 shown. Specifically, in step 110, a DLS data stream from an MCU can be received. In step 120, the data frame information in the DLS data stream can be read, for example, the data frame information can be read by the method dlt_message_read provided by the DLT open source library. In step 130, the data content can be read based on the data frame information, for example, the data content can be read by the method dlt_message_payload provided by the DLT open source library. In step 140, the read data content can be written to Slogger2, wherein Slogger2 is a log management tool supported by the QNX system. In step 150, the data in Slogger2 can be read by the DLT-Daemon process, and in step 160, the read data can be written to a DLT log file, wherein DLT-Daemon is one of the implementations of the DLT protocol and can be used to receive, parse and process DLT log files.
[0026] By analyzing the relevant technologies, the applicant found that although Figure 1 The scheme shown can realize the storage of log data generated by MCU to the SoC side, but it has obvious shortcomings. First, in the above scheme, there is a data loss problem, and the MCU log information cannot be restored truly and completely. Specifically, the log data in DLT format generated on the MCU side will be converted into Slog2 log format after being forwarded to the SoC side for subsequent processing and storage. Compared with the original log content, the converted log content will lose some data information, such as the fields such as TimeStamp, Count, and Subtype in the DLT log field. Second, in the above scheme, there are multiple data copies, which will cause obvious performance waste. For example, on the SoC side, after receiving the log data from the MCU, it needs to be written to the QNX native Slogger2 system. At this time, data copying will occur from the receiving port or receiving module of the log data to the shared memory. Subsequently, DLT-Daemon needs to read data from the Slogger2 shared memory and write it to the pipe or file. At this time, data copying from the shared memory to the pipe or file will occur again. Third, the above scheme depends on the QNX Slogger2 tool and DLT-Daemon, and it is difficult to be transplanted to other systems. From the above analysis, we can see that Figure 1 The solution shown cannot completely store the log information generated by the MCU side, and is relatively cumbersome, inefficient, and poor in portability.
[0027] In order to improve the performance of storing the log data generated on the microcontroller side to the system controller side and provide good portability, the present disclosure proposes a new log storage solution. By analyzing the log viewing and processing logic on the MCU side and the SoC side, the applicant found that on the microcontroller side, the real-time DLT data can be viewed using the DLT-Viewer through the serial interface of the microcontroller, wherein the DLT-Viewer is one of the implementations of the DLT protocol and can be used to view and analyze log files in the DLT format; on the SoC side, the log data can be received without using the DLT-Viewer. For the logs stored on the SoC side, the data can be printed in real time through tools such as Slogger, without starting DLT-related processes to copy and forward data. Based on the above analysis, in some embodiments of the present disclosure, Figure 2 The log storage method 200 shown in the figure is used to store log data from the microcontroller side. Exemplarily, the log storage method 200 can be implemented by a system controller (such as a SoC side) in an electronic system (such as an automotive electronic system) and is used to store log data in a DLT format from at least one microcontroller (such as an MCU side). Figure 2As shown, the log storage method 200 may include steps 210 to 230, which are specifically as follows.
[0028] In step 210, a DLS data stream may be received, wherein the DLS data stream may include at least one DLS stream data packet, and each DLS stream data packet in at least one DLS stream data packet may have a DLS identification field. Exemplarily, at each microcontroller in the electronic system, a DLT log module may be provided, which may record information during the operation of the microcontroller for use in debugging and fault analysis, etc. Each microcontroller may periodically transmit the recorded log data to the system controller in the form of a DLS data stream, and the transmitted DLS data stream may be received by a certain receiving module or receiving port on the system controller side. The system controller may obtain at least one DLS stream data packet included therein by parsing the received DLS data stream. In the present disclosure, the DLS identification field may be understood as a field that identifies that the current data or data packet conforms to the DLS data stream format. For example, in the DLS data stream format, each DLS stream data packet may have a DLS. data header, such as starting with {'D', 'L', 'S', 0x01}. Therefore, this DLS. data header may be used as a DLS identification field.
[0029] Indicatively, Figure 3 An example data structure of a DLS stream data packet according to some embodiments of the present disclosure is shown, wherein the first line is the field name (Name), the second line is the corresponding byte (Bytes), and the third line is the corresponding structure (Struct). Figure 3As shown, a DLS stream data packet may include: DLS.Data beginning (bytes 0 to 3), which may be used to indicate the type (type) of the data packet; Standard Header (bytes 4 to 7), which may include fields such as header type (htyp), message count (mcnt), and message length (len), wherein htyp may indicate general information of the corresponding DLT message, mcnt may indicate the cumulative number of DLT messages received by the DLT module in the ECU as of the corresponding DLT message, and len may indicate the total length of the corresponding DLT message; Standard Header Extension (StandardHeaderExtra, bytes 8 to 19), which may include ECU identification (ecu), session identification (seid), and timestamp (tmsp ), among which, ecu can indicate the ECU that sends the corresponding DLT message, seid can indicate the message source in the ECU, and tmsp can indicate the message generation time; extended header (ExtendedHeader, 20th to 29th bytes), can include message information (msin), number of parameters (noar), application identifier (apid), user-defined identifier (ctid), etc., among which msin can indicate message classification, noar can indicate the number of consecutive parameters in the payload segment, apid can indicate the application that generates the corresponding DLT message, and ctid can indicate message grouping; others (other, 30th-35th bytes), can contain other message information; payload (pyload), can contain specific log parameters, etc.
[0030] In some embodiments, the DLS data stream can be identified based on the above-mentioned DLS identification field, such as the above-mentioned DLS. beginning. Specifically, the aforementioned step 210 may include: receiving a data stream; in response to detecting the DLS identification field in the received data stream, acquiring the DLS data stream based on the data stream. Exemplarily, on the system controller side, data streams from one or more microcontrollers can be received, and these data streams can be data in binary format and can involve different data stream types. The system controller can call a parsing interface to parse the received binary data stream and detect the field information therein. When the DLS identification field is detected, the data stream containing the DLS identification field can be determined as a DLS data stream. In some embodiments, each DLS stream data packet can be further identified in the DLS data stream based on the above-mentioned DLS identification field, such as the above-mentioned DLS. beginning. By detecting the DLS identification field, the DLS data stream can be accurately and conveniently identified, and each DLS stream data packet in the DLS data stream can be further identified.
[0031] In step 220, for each DLS stream data packet in at least one DLS stream data packet, the DLS identification field in the DLS stream data packet may be replaced with the DLT storage header field to obtain a DLT data packet corresponding to the DLS stream data packet.
[0032] Exemplarily, the DLT storage header field may contain information related to the DLT data packet format and the corresponding DLS stream data packet, for example, it may include: a DLT identifier, a timestamp, and an identifier indicating the source of the corresponding DLS stream data packet. Specifically, the DLT identifier may be understood as a field that identifies that the current data or data packet complies with the DLT protocol, such as {'D', 'L', 'T', 0x01}; the timestamp may be the time when the system controller receives the corresponding DLS stream data packet, and may be generated or determined by the system controller, and may include subfields such as seconds and milliseconds; the identifier indicating the source of the corresponding DLS stream data packet may be, for example, an identifier of a microcontroller or electronic device that generates or sends the DLS stream data packet, such as an identifier of an MCU or ECU. Optionally, the identifier of each microcontroller or electronic device may be unique within the entire electronic system.
[0033] Indicatively, Figure 4 An example data structure of a DLT data packet according to some embodiments of the present disclosure is shown. Figure 4 The DLT data packet shown is the same as Figure 3 Compared with the DLS stream data packet shown in the figure, the only difference between the two is that the DLS. field in the DLS stream data packet is replaced by Figure 4 The StorageHeader structure shown. The StorageHeader structure may include: a DLT pattern, which may be, for example, {'D', 'L', 'T', 0x01}; a timestamp, including seconds and microseconds, which may indicate the time when the SoC side receives the corresponding DLS stream data packet; an ECU identifier (ecu), which may indicate the ECU that sends the corresponding DLS stream data packet. Exemplarily, the above DLT storage header field may be Figure 4 The StorageHeader structure shown.
[0034] In some embodiments, the method for setting the storage header field provided by the DLT open source library can be used to replace the DLS identification field in the DLS stream data packet with the DLT storage header field. Optionally, dlt_set_storageheader can be used to fill the StorageHeader structure to implement the above replacement. Using the method provided by the DLT open source library to perform the above replacement can, on the one hand, reduce development costs and improve development efficiency. On the other hand, it does not need to rely on a specific operating system or related tools, which helps to achieve good portability.
[0035] In step 230, a DLT log file may be stored based on the DLT data packet obtained in step 220. Optionally, each DLT data packet may be directly stored as a DLT log file, such as a "*.dlt" file. Alternatively, the obtained DLT data packet may be written into an existing DLT log file. Optionally, the DLT log file may be stored in a local memory of the system controller or an external storage device according to specific requirements.
[0036] exist Figure 2 In the method 200 shown, the DLT log file can be stored by replacing the DLS identification field in the DLS stream data packet with the DLT storage header field to obtain the corresponding DLT data packet. In this process, the original log data and information will not be lost, so the original log content can be accurately restored, and there is no need to store files through processes such as DLT-Daemon, nor is there a need to write data to tools such as Slogger2, but the processed data stream can be directly stored as a file, so the loss caused by data copying can be avoided, while reducing the complexity of log storage operations and improving log storage efficiency, thereby greatly optimizing performance. At the same time, since tools such as DLT-Daemon and Slogger2 are not involved, the above method 200 can have good portability and a wider range of applications.
[0037] In some abnormal situations, the data stream from the microcontroller may have problems such as data packet damage and multiple packets of data sticking together. Figure 5 Two examples of abnormal DLS flow packets are shown. Figure 5 As shown, packet 0 is a normal DLS stream data packet, and packets 1 and 2 are abnormal DLS stream data packets, wherein packet 1 contains two contiguous DLS stream data packets, and packet 2 is a damaged DLS stream data packet that does not start with DLS. In addition, there may be more cases of contiguous packets or other forms of packet damage, or there may be other types of abnormal stream data packets.
[0038] In order to parse out a single valid DLS stream data packet and avoid the impact of multiple packets of data being stuck together, each DLS stream data packet can be identified based on the DLS identification field. In some embodiments, after receiving the DLS data stream in step 210, in the received DLS data stream, a DLS stream data packet can be determined based on each data segment starting with a DLS identification field (such as the aforementioned DLS. field). Figure 5 As shown, if depending on the packets in the data stream, two or more packets that are stuck together may be identified as one stream data packet. By detecting each data starting with the DLS identification field, each DLS stream data packet can be accurately identified. For example, the two DLS stream data packets in packet 1 will be accurately identified as two DLS stream data packets. Therefore, the problem of multi-packet data sticking can be effectively solved.
[0039] Optionally, the received DLS data stream can be temporarily stored with the help of a container, so as to identify each DLS stream data packet. Specifically, the received DLS data stream can be stored in a target container. The target container can be a container that exists in the relevant technology or is designed by itself and can be used to store data. For example, std::vector can be used as the target container, wherein std::vector is a container in the C++ standard library that provides a dynamic array function, allows the use of continuous storage space to store data, and supports efficient addition and deletion of elements at the end of the container. Exemplarily, the received DLS data stream can be continuously added to the end of a target container such as std::vector, so that the received DLS data can be stored in the target container in an orderly manner in the order of reception, to be identified and processed. Subsequently, the DLS identification field can be searched in the target container, and in response to searching for two adjacent DLS identification fields, a DLS stream data packet can be determined based on the data segment defined by the two adjacent DLSs searched. Taking the case of using std::vector as the target container as an example, std::search can be used to search for DLS identification fields, such as the DLS. field, in the data stored in std::vector. Optionally, in the target container, the DLS identification field can be searched in order from the head to the tail of the container. Exemplarily, in the process of searching for the DLS identification field in the target container in order from the head to the tail, when a DLS identification field is searched, optionally, the invalid data before the DLS identification field can be discarded, and the search for the next DLS identification field can continue. When the next DLS representation field is searched, a complete DLS stream data packet can be determined based on the data between the positions of the two DLS identification fields. In this way, the problem of multi-packet adhesion can be solved relatively efficiently and conveniently.
[0040] In addition, with regard to the aforementioned packet damage problem, when parsing the received data stream, parsing will fail for damaged packets, and such damaged packets will be directly discarded. Therefore, the packet damage problem usually does not affect the subsequent operation of storing DLT log files based on each DLS stream packet.
[0041] The present disclosure also provides a computing device, in which the aforementioned log storage method can be implemented. Figure 6 Schematically shows an exemplary block diagram of a computing device 600 according to some embodiments of the present disclosure. Figure 6 As shown, the computing device 600 may include a memory 610 and a processor 620, wherein the memory may store computer executable instructions, and the processor may execute the computer executable instructions to execute the log storage method according to any of the above embodiments. Optionally, the memory may be RAM, ROM, EEPROM, flash memory, CD-ROM, DVD or other memory. Optionally, the computing device 600 may also be configured to perform other methods or functions, or may be integrated into other devices or systems.
[0042] Exemplarily, the computing device 600 can be implemented as a domain controller in an automotive electronic system, such as a domain controller (Domain Control Unit, DCU) in a car cockpit domain or other domains. Further exemplarily, the domain controller may include software and hardware such as a main control chip, an operating system, and an application algorithm. The main control chip may be, for example, a SoC chip, wherein the SoC chip may integrate multiple functional modules, such as a processor, memory, and peripheral interfaces, and may efficiently process various data and control tasks. Alternatively or additionally, the main control chip may also include other types of chips. In such examples, the SoC side or system controller side mentioned in the various embodiments described above may also be understood to correspond to the domain controller side.
[0043] The present disclosure also provides a computer-readable storage medium on which computer-executable instructions are stored. When the computer-executable instructions are executed, any embodiment of the above-mentioned log storage method is implemented.
[0044] The present disclosure also provides a computer program product or computer program, which includes computer executable instructions. The computer executable instructions can be stored in a computer readable storage medium. The processor of the computing device can read the computer executable instructions from the computer readable storage medium and execute the computer executable instructions, so that the computing device performs the above-mentioned log storage method provided in the above-mentioned various embodiments.
[0045] By studying the drawings, the disclosure and the appended claims, those skilled in the art will be able to understand and implement various variations of the disclosed embodiments in practicing the claimed subject matter. In the claims, the word "comprising" does not exclude other elements or steps, and "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
Claims
1. A log storage method, comprising: Receive a DLS data stream, wherein the DLS data stream includes at least one DLS stream data packet, and each DLS stream data packet in the at least one DLS stream data packet has a DLS identification field; For each DLS stream data packet, replace the DLS identification field in the DLS stream data packet with the DLT storage header field to obtain a DLT data packet corresponding to the DLS stream data packet; Based on the obtained DLT data packets, a DLT log file is stored.
2. The method according to claim 1, further comprising: In the DLS data stream, a DLS stream data packet is determined based on each data segment starting with the DLS identification field.
3. The method according to claim 2, wherein: In the DLS data stream, determining a DLS stream data packet based on each data segment beginning with the DLS identification field comprises: storing the DLS data stream into a target container; Searching the target container for the DLS identification field; In response to searching for two adjacent DLS identification fields, a DLS stream data packet is determined based on the data segments defined by the two adjacent DLSs.
4. The method according to claim 3, wherein: The storing the DLS data stream into the target container comprises: adding the DLS data stream to the end of the target container, and The step of searching the target container for the DLS identification field includes: The DLS identification field is searched in the target container in order from the first to the last.
5. The method according to claim 1, wherein: The replacing the DLS identification field in the DLS stream data packet with the DLT storage header field comprises: The DLS identification field is replaced with the DLT storage header field by using the method for setting the storage header field provided by the DLT open source library.
6. The method according to claim 1, wherein: The receiving the DLS data stream comprises: Receive data stream; In response to detecting the DLS identification field in the data stream, the DLS data stream is acquired based on the data stream.
7. The method according to any one of claims 1 to 6, wherein: The DLT storage header field includes: a DLT identifier, a timestamp, and an identifier indicating the source of the corresponding DLS stream data packet.
8. A computing device comprising: a memory configured to store computer-executable instructions; A processor configured to perform the method according to any one of claims 1 to 7 when the computer executable instructions are executed by the processor. 9 . A computer-readable storage medium storing computer-executable instructions, wherein when the computer-executable instructions are executed, the method according to claim 1 is performed.
10. A computer program product comprising computer executable instructions, wherein: The computer executable instructions implement the steps of any one of claims 1 to 7 when executed by a processor.