Method for processing log file, data processing system and vehicle

Abstract

The invention relates to a method for processing a log file (1) using a computer-aided data processing system (2). The method according to the invention is characterized by the following method steps: a coding module (6) reads in a coding instruction (5); -performing a system monitoring and generating a diagnostic data stream (7) during the system monitoring by means of a diagnostic module (8); reading in the diagnostic data stream (7) by the coding module (6); -generating an encoded log file (1. KOD); a decoding module (9) reads in the encoded log file (1. KOD); a decoding module (9) reads in the encoded instruction (5); and-generating a decoded log file (1. DEK); wherein the encoding module (6) assigns a version marker of the used encoding instruction (5) to the header (3) of the encoded log file (1. KOD); -when the encoding module (6) recognizes in the diagnostic data a logging event (11) that relates for the first time to a particular logging parameter (12) or that describes a change in the corresponding logging parameter (12), the encoding module (6) affixes a logging entry (10) as a payload (4) to the encoded log file (1. KOD); and-when the encoding module (6) has attached the log entry (10) to the encoded log file (1. KOD), or when a certain time has elapsed without attaching a further log entry (10), the encoding module (6) saves the encoded log file (1. KOD) in the current state during the system monitoring.

Description

Technical Field

[0001] The invention relates to a method for processing log files using a computer-aided data processing system of the type defined in the preamble to claim 1, a corresponding data processing system and a vehicle. Background Art

[0002] The basic prerequisite for the correct operation of IT systems is the perfect interaction of hardware and software. Due to hardware defects or errors in the program code (also known as bugs), the correct functioning of IT systems may be limited, erroneous or impossible.

[0003] For this reason, log files are generated, in particular during the development of hardware or software components, but also during the operation of IT systems, in order to record the processes carried out by the IT systems. By analyzing these log files, it is often possible to identify the cause of a fault and to take appropriate measures to eliminate it, for example by adjusting the program code.

[0004] There are some problems in the processing of log files:

[0005] 1. Based on the design of IT systems and the software for process monitoring (also known as debugging programs) running on IT systems, only incomplete log files are generated when a fault occurs, which do not cover all relevant system parameters and / or the complete relevant time period. They usually only contain the most important parameters within a certain time window close to the fault (e.g. the last minute before the fault occurred). However, if the root cause of the fault is an unrecorded system parameter, especially outside the output time window, a comprehensive problem analysis cannot be carried out.

[0006] 2. Log files may have a very large number of system parameters, especially when the observation period is long. Then, it may be very laborious to find a specific system parameter at a specific moment. Generally speaking, even if a search algorithm is used, it takes a long time to search to get the desired result, because in order to find the relevant log file fragment, it is first necessary to analyze the system behavior saved and recorded in the log file. In this way, even if the user uses a search and / or sorting algorithm, it still requires manual costs.

[0007] 3. Log files are usually only available for IT systems that are in operation, for example in volatile storage media such as working memory (random access memory). The expressions "operation" or "operation time" hereinafter are to be understood as the length of time that the respective IT system is active between the boot process and the shutdown process or a crash. The time during which an IT system performs monitoring and saves the relevant information in a log file is referred to as "system monitoring" hereinafter. During operation, one or more system monitorings can be performed. If an IT system is shut down or crashes, the log files for this runtime may also be lost. This makes it impossible to reconstruct the system state of the IT system before the crash.

[0008] Methods and devices for creating log files are well known. For example, WO 2012 / 106969 A1 and CN112286896 A disclose methods and devices for generating and saving log files in a compressed and converted format. This can reduce the storage space requirements for the corresponding log files and make reading and writing faster. Here, the log files can also be converted in an encrypted manner to prevent unauthorized third parties from processing the log files. However, the problems with log file processing mentioned at the beginning of the article are not solved by this. Summary of the invention

[0009] The object of the present invention is to provide an improved method for processing log files using a computer-aided data processing system and a corresponding data processing system, so as to at least alleviate and preferably solve the above-mentioned problems.

[0010] According to the invention, this object is achieved by a method for processing log files using a computer-aided data processing system having the features of claim 1 and a corresponding data processing system having the features of claim 10. Advantageous embodiments and developments and a vehicle having such a data processing system or components of such a data processing system are described in the dependent claims.

[0011] Based on the method for processing log files using a computer-aided data processing system of the aforementioned category, the data processing system generates, processes and / or at least temporarily stores the log files in an encoded format, and the log files include a header and a payload, and according to the present invention, the following method steps are performed:

[0012] -The encoding module reads the encoding instructions;

[0013] - performing system monitoring and generating diagnostic data streams with the aid of diagnostic modules during system monitoring;

[0014] -The encoding module reads the diagnostic data stream;

[0015] - the encoding module applies the encoding instruction to the diagnostic data stream, and then generates an encoded log file;

[0016] -The decoding module reads the encoded log file;

[0017] -The decoding module reads the encoded instructions; and

[0018] - Considering the encoding instructions, the decoding module generates a decoded log file from the encoded log file; wherein,

[0019] -The encoding module assigns a version identifier of the encoding instruction used to the header of the encoded log file;

[0020] - when the encoding module identifies in the diagnostic data the first logging event involving a particular logging parameter or describing a change in a corresponding logging parameter, the encoding module appends the logging entry as a payload to the encoded log file; and

[0021] - The encoding module saves the encoded log file in the current state during system monitoring when the encoding module has appended a log entry to the encoded log file or when a determined period of time has passed without appending any log entry.

[0022] The method according to the invention makes it possible to collect all log record parameters that need to be recorded during system monitoring into a log file and to make the log file available for later analysis, including in the event of an unexpected shutdown of the computer-aided data processing system. By storing the log file in coded form, it is ensured that the individual log record entries can be located in the log file particularly quickly and easily with the aid of a decoding module. As a result, the labor costs in log file analysis can be reduced.

[0023] The data processing system is an information technology system. One or more computer-aided data processing systems may participate in the processing of log files. For example, the first data processing system may be designed as an embedded system. For example, the embedded system may be integrated into a vehicle, such as a passenger car. For example, it may be a host actuation control unit. Then, the diagnostic module monitors the embedded system, thereby collecting its state, and deriving the information processed by the embedded system in the form of diagnostic data. The diagnostic module may be a component / part of the embedded system, or may be integrated in another data processing system. Similarly, another data processing system may also be a component of the vehicle, or may be temporarily connected to the vehicle, for example, in the form of a mobile terminal device connected to the vehicle via a CAN bus, a USB interface, or an Ethernet interface, such as a tablet or a laptop computer. The coding instruction contains information on how the coding module should process the diagnostic data so as to generate a log file in a coded format. Depending on the design of the data processing system to be monitored and the information processed by each or the log recording parameters to be monitored, the coding instruction may be designed differently. In this way, the coding instruction can be named specifically for a specific data processing system.

[0024] Then, the encoded log file can be decoded by a decoding module using the same encoding instructions. The decoding module can be a component of an embedded system, or can also be a component of another data processing system. For example, the decoding module can be provided by a developer system, or run on it. For example, the developer system can be a personal computer. Any of the modules described above can be implemented in the form of hardware, software, or a combination of hardware and software.

[0025] The encoded log file generated by the encoding module includes a header and a payload attached to the header. Here, the header includes a version identifier of the encoding instruction used. This facilitates the decoding module to determine what encoding instruction should be used to decode the encoded log file when decoding the encoded log file. Therefore, the header of the encoded log file becomes a component of a log file that is independent of system monitoring and uses the same design. Then, if the analysis result of the diagnostic data by the encoding module shows that a new log record parameter to be recorded returns a value or a changed value for the first time, the encoding module attaches the new entry to the log file. To this end, the encoding module identifies the occurrence of a log record event in the diagnostic data. Such a log record event can also be referred to as a function call. Examples here include the startup or exit of a data processing system, the loading of specific software, the change of sensor values ​​collected and processed by the data processing system, the completion of a task, and the like. Each log record parameter can be any parameter describing the state of the data processing system, or a parameter of information processed by the data processing system. Examples of log record parameters include system time, date, ignition status of the vehicle, received signal strength, speed value, mass flow, IP address, and the like.

[0026] The encoded log file generated by the coding module can be stored in any data processing system. For example, the encoded log file can be stored on the physical storage medium of the same data processing system that also contains the coding module, or it can be transferred to another data processing system by the data processing system. This transmission can be wireless or wired. For this reason, it is possible to consider using any communication technology, such as Ethernet, USB connection, wireless network, Bluetooth, NFC, ZigBee, etc.

[0027] Since a logging event only identifies the first occurrence of a corresponding logging parameter or a change in the corresponding value of a corresponding logging parameter and then appends the logging entry as a payload to the log file, the file size of the encoded log file is kept extremely small. This ensures efficient use of computer resources.

[0028] The system always re-saves the encoded log file if a new log record entry is appended to the encoded log file, or appended after a specified time period has expired. The specified time period may be arbitrarily selected and may be a fixed time interval, such as five milliseconds, one second, or five minutes, or may be an adaptive time period, such as a variable time period depending on logging parameters or logging events. By frequently saving the encoded log file (i.e., writing the encoded log file to a non-volatile storage medium), it is possible to ensure that the encoded log file is still available for further analysis after an unexpected shutdown or crash of the data processing system.

[0029] The encoded log file, in particular a text file, stores the header and payload as an alphanumeric string and adds special characters and / or mathematical symbols, etc., if necessary. The decoding module then reads the text file and converts it into another format. For example, the decoding module can generate a table based on the encoded log file. If a log record parameter appears in the corresponding table for the first time or changes, the table cell entry corresponding to the log record parameter can be highlighted for a specific point in time, for example, by color marking. This can simplify manual analysis of the log file.

[0030] An advantageous modification of this method is:

[0031] - at least temporarily buffering the first encoded log file in the data processing system after it is generated during the first system monitoring; and

[0032] During the second system monitoring period, the encoding module links the first encoded log file and the second encoded log file together when generating the second encoded log file.

[0033] Therefore, the two encoded log files can be merged into one log. Therefore, if a system crash occurs in the data processing system after restart, the information recorded during the first system monitoring during the previous running time can be provided for analysis. Therefore, the corresponding data processing system saves the first encoded log file, especially at least during the shutdown period of the data processing system or the diagnostic module and the encoding module. If the data processing system is restarted afterwards and the second system monitoring is performed during another running time, a second encoded log file is generated, and the first encoded log file is linked to the second encoded log file. For example, linking refers to prepending the first encoded log file, or attaching it to the end of the second encoded log file.

[0034] Another advantageous design according to the method is to reserve a large number of different versions of coding instructions in the first database. The first database can be a component of any data processing system. That is, the first database can be integrated in the same data processing system as the diagnosis module, the encoding module and / or the decoding module. However, the first database can also be provided on a separate data processing system. For example, such a separate data processing system can be a server or a server cluster.

[0035] New software versions are often generated during the development of hardware and / or software components. For this purpose, versions of coding instructions can be managed. Then, the log files are encoded and decoded using the matching version of the coding instructions according to the corresponding hardware or software version. For example, the data processing system hardware monitored by the diagnostic module may change and / or the corresponding data processing system may process new parameters, such as new sensor data. Therefore, it is necessary to specify new log record parameters to be monitored. New versions of coding instructions can be generated, which also contain these new log record parameters.

[0036] These different versions of the coded instructions may also be executed for specific diagnostic modules.

[0037] In addition, in another advantageous design of the method according to the present invention, a large number of coding instruction modules are reserved in the second database, and in order to generate the coding instruction, the data processing system reads at least two coding instruction modules from the second database and merges them. The operation steps of providing different coding instructions can be simplified thereby. According to the data processing system actually monitored or according to the actual design of the diagnostic module, each coding instruction of different versions can contain the same components. These coding instruction components can be reserved in the second database, so that different coding instructions, especially different versions of coding instructions, can be generated particularly quickly and conveniently. Similarly, the second database can also be preferably provided on a data processing system designed as a server or a server cluster. For example, a programmer who generates corresponding coding instructions for different data processing systems and diagnostic modules can then access the server or server cluster.

[0038] According to another advantageous design,

[0039] - when a specific logging parameter is mentioned for the first time by a logging event, the encoding module appends the value of the logging parameter described by the diagnostic data as a logging entry to the encoded log file;

[0040] - before each subsequent appending of a log entry involving the corresponding log parameter, the encoding module checks whether the current value of the log parameter or the difference between the current value and the previous value results in a smaller file size of the encoded log file; and

[0041] - The encoding module appends the specific entry resulting in a smaller file size as a logging entry to the encoded log file.

[0042] Thus, the storage space required for preserving the encoded log file can be reduced. Then, the corresponding encoded log file can also be sent more quickly through a wireless or wired network. For example, if the log file is a text file, the difference between the value or the current value and the previous value can be checked by the encoding module very conveniently and quickly to see if it will lead to a smaller file size. For this reason, only the number of characters of the value or the difference need to be compared. Then, the value or difference that leads to less number of characters is selected.

[0043] In addition, in another advantageous design of the method according to the present invention, the encoding module applies a calculation rule to the log record entry to be attached to the encoded log file, and the calculated log record entry is attached to the encoded log file. Thus, the storage space required for saving the encoded log file can be further reduced. The calculation rule can be an arbitrary formula. For example, if the log record parameter is an IP address, it can be converted into a hexadecimal format with the help of the calculation rule. In this way, the IP address can be reduced from 15 characters to eight characters without including a dot. This operation step is similar to generating a hash value with the help of a hash function. Generally, any log record parameter or log record entry can be arbitrarily converted. Similarly, the encoded log file can also be encrypted so that an attacker cannot obtain a decoded log file based on the encoded log file without corresponding encoding instructions.

[0044] According to another advantageous design of the method, the encoding module checks whether there is a deletion event in the log record event, and when a deletion event is identified, all log record entries related to the corresponding log record parameters mentioned in the deletion event are removed from the encoded log file. A deletion event is a specific log record event. In the encoding instructions, it can be determined which log record events should be understood as deletion events, and which log record parameters should be removed accordingly from the encoded log file. For example, a deletion event can be specified as a log record event reaching a certain number, or a specific log record parameter returning a specific value. The end of a specified time period can also be a deletion event. If it can be determined that the corresponding log record parameter to be deleted is no longer needed for further analysis, then a deletion event is particularly specified. In this way, the file size of the encoded log file can be reduced.

[0045] Furthermore, in another advantageous embodiment of the method, a maximum size is defined for the encoded log file, and when the encoded log file reaches the maximum size, the encoding module starts to generate a second encoded log file after the last saved encoded log file, or at least no more log files are generated for the system monitoring. The maximum size of the encoded log file can be defined in different formats, for example in the form of file size, i.e., for example in the form of kilobytes, megabytes, gigabytes, etc., or also in the form of character string length, the form of the maximum number of entries, etc. Once the maximum size of the encoded log file is reached, another encoded log file can be generated from the beginning, or the logging can be suspended and ended.

[0046] According to another advantageous embodiment of the method according to the invention, for the encoded log file, a maximum number of log entries is specified for a specific log parameter, and when a log entry is again appended to the encoded log file, if the maximum number of the log parameter is reached, the corresponding oldest log entry is overwritten with the latest log entry corresponding to the log parameter. In this way, despite the continuous progressive logging, the file size of the encoded log file can be kept constant while the latest log events are still collected. Older, in particular no longer relevant log events and the corresponding log entries are then removed from the encoded log file.

[0047] According to the invention, a data processing system is provided to perform the aforementioned method. As described, the data processing system can be an information technology system of any design, such as an embedded system, a mobile terminal device, a personal computer, a server, a quantum computer, etc. Preferably, multiple data processing systems can be used to implement the method according to the invention. The data processing systems here are in particular networked with each other. Here, the data processing system can also be simulated or emulated, for example on a virtual machine.

[0048] The vehicle according to the invention has a data processing system as described above or a component of such a data processing system. Thus, it is possible to check the system behavior of a computing system used in the vehicle, such as a vehicle subsystem control unit, by means of the method according to the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The embodiments also illustrate further advantageous designs of the log file processing method and the data processing system according to the present invention, and these embodiments will be described in more detail below with reference to the accompanying drawings.

[0050] in:

[0051] Figure 1 The structure of one or more data processing systems for executing the method according to the present invention is shown;

[0052] Figure 2 The working principle of the encoding module is schematically shown; and

[0053] Figure 3 The flowchart of the working principle of the encoding module is shown. DETAILED DESCRIPTION

[0054] A method according to the invention describes how to process a log file 1 with the aid of one or more data processing systems 2. Figure 1 In the example shown in , the diagnostic module 8 is integrated in the first data processing system 2, the encoding module 6 is integrated in the second data processing system 2, the decoding module 9 is integrated in the third data processing system 2, and the first database 13.1 and the second database 13.2 are integrated in the fourth data processing system 2. Generally, it is also possible to integrate all modules 8, 6, 9 and the two databases 13.1 and 13.2 into the same data processing system 2. The modules 8, 6, 9 and the two databases 13.1 and 13.2 can be distributed in any possible way to any number of data processing systems 2. Particularly preferably, the diagnostic module 8 and the encoding module 6 are integrated into the same data processing system 2 (not shown).

[0055] The diagnostic module 8 performs a system monitoring of the data processing system 2 in which it is integrated. The diagnostic module 8 then returns / provides a diagnostic data stream 7 for analysis by the encoding module 6. The encoding module 6 then generates a coded log file 1.KOD on the basis of the diagnostic data stream 7, taking into account the encoding instructions 5. The decoding module 9 reads in the coded log file 1.KOD and converts it into a decoded log file 1.DEK, likewise taking into account the encoding instructions 5.

[0056] Here, the first database 13 . 1 may contain a large number of different versions of coding instructions 5 . The second database 13 . 2 may contain coding instruction modules that can be merged into new coding instructions 5 .

[0057] Figure 2The working principle of the encoding module 6 is schematically shown. Here, the encoding module 6 processes a diagnostic data stream 7 received from a diagnostic module 8. For example, the content of the data stream includes state values ​​describing the system state of the data processing system 2 monitored by the diagnostic module 8 and / or (sensor) data collected and / or processed in another way by the corresponding data processing system 2. The diagnostic data stream 7 can be understood as a parallel list of logging events 11, each logging event 11 containing, for each logging parameter 12, a value 14 corresponding to the logging parameter 12. Depending on the specific design of the hardware and / or software used, all existing logging parameters 12 can always be listed in the corresponding logging event 11 in the diagnostic data stream 7, or only the logging parameters 12 showing the changed value 14 can be listed.

[0058] Taking into account the encoding instructions 5, the encoding module 6 converts this information into an encoded log file 1.KOD. The encoded log file 1.KOD contains a header 3 describing the version identifier of the encoding instructions 5 used and a payload 4, which contains a parallel list of corresponding log record entries 10. For example, the encoded log file 1.KOD is a text file, so the header 3 and the payload 4 are corresponding strings stored in the text file. The string can contain any combination of numbers, letters, special characters, mathematical symbols, etc. In order to keep it simple, only some log record entries 10 are added with figure marks. In Figure 2 In the embodiment shown, vertical lines separate the individual log entries 10. Generally, other characters or symbols, or fixed character lengths, may also be used for this purpose.

[0059] Figure 3 The flowchart of the working principle of the encoding module 6 is shown.

[0060] The method starts at step 301 , for which the encoding module 6 analyses the diagnostic data stream 7 and identifies the presence of logging events 11 and corresponding logging parameters 12 and corresponding values ​​14 .

[0061] In step 302, the encoding module 6 repeatedly checks for each logging event 11 in the diagnostic data stream 7 whether the value 14 occurs for the first time for the corresponding logging parameter 12 or whether the value 14 has already been logged. For this purpose, the encoding module 6 can also read the encoded log file 1.KOD, for example.

[0062] If the value 14 has already been recorded, it is checked in step 303 whether the value 14 has changed compared to the previous value 14. If the value 14 has not changed, no new log record entry 10 is generated in step 304. However, if the value 14 has changed, the difference between the two values ​​14 is calculated in step 305. In step 306, the encoding module 6 checks whether the value 14 or the difference between the current value and the corresponding previous value 14 will result in a smaller size of the encoded log file 1.KOD, for example due to a smaller number of characters.

[0063] If the diagnostic data stream 7 contains the value 14 for the first time for a particular logging parameter 12, or if the value 14 results in a smaller file size, the value 14 is appended as an attachment to the string to be imported into the encoded log file 1.KOD in step 307. On the other hand, if the difference between the current value and the previous value 14 is small, which will result in a smaller file size, the difference is appended as an attachment to the string in step 308.

[0064] In step 309, the character string or the information that should be attached to the character string as a log record entry 10 is written into the encoded log file 1.KOD. The encoded log file 1.KOD is then saved. In addition, a timer is run, and a check is made in step 310 to see whether the timer has expired. If the timer has expired, step 309 is performed again. Since no new characters are added to the character string of the encoded log file 1.KOD, the encoded log file 1.KOD is only saved again next.

[0065] For analysis, the encoded log file 1.KOD can be accessed in step 311. For this purpose, the encoded log file 1.KOD is decoded by the decoding module 9.

Claims

1. A method for processing a log file (1) using a computer-aided data processing system (2), wherein: The log file (1) is generated, processed and / or at least temporarily stored in an encoded format by the data processing system (2), and the log file (1) comprises a header (3) and a payload (4), The method is characterized by the following steps: - The encoding module (6) reads the encoding instruction (5); - performing system monitoring and generating a diagnostic data stream (7) during the system monitoring with the aid of a diagnostic module (8); - the encoding module (6) reads in the diagnostic data stream (7); - the encoding module (6) applies the encoding instruction (5) to the diagnostic data stream (7), and then generates an encoded log file (1.KOD); - The decoding module (9) reads the encoded log file (1.KOD); - the decoding module (9) reads the encoding instruction (5); and - generating a decoded log file (1.DEK) from the encoded log file (1.KOD) by the decoding module (9) taking into account the encoding instruction (5); wherein, - the encoding module (6) allocates a version identifier of the encoding instruction (5) for use in the header (3) of the encoded log file (1.KOD); - when the encoding module (6) identifies in the diagnostic data a logging event (11) that involves a specific logging parameter (12) for the first time or describes a change in the corresponding logging parameter (12), the encoding module (6) appends the logging entry (10) as a payload (4) to the encoded log file (1.KOD); and - when the encoding module (6) has appended the log entry (10) to the encoded log file (1.KOD) or when a certain period of time has elapsed without appending a further log entry (10), the encoding module (6) saves the encoded log file (1.KOD) in a current state during system monitoring.

2. The method according to claim 1, It is characterized in that - at least temporarily buffering a first encoded log file (1.KOD) in the data processing system (2) after its generation during the first system monitoring; and - During the second system monitoring period, the encoding module (6) links the first encoded log file (1.KOD) and the second encoded log file (1.KOD) together when generating the second encoded log file (1.KOD).

3. The method according to claim 1 or 2, It is characterized in that A large number of different versions of coding instructions (5) are reserved in the first database (13.1).

4. The method according to claim 3, It is characterized in that A large number of encoding instruction modules are reserved in the second database (13.2), wherein the data processing system (2) reads at least two encoding instruction modules from the second database (13.2) and merges the at least two encoding instruction modules to generate encoding instructions (5).

5. The method according to any one of claims 1 to 4, It is characterized in that - when a specific logging parameter (12) is mentioned for the first time by a logging event (11), the encoding module (6) appends the value (14) of the logging parameter (12) described by the diagnostic data as a logging entry (10) to the encoded log file (1.KOD); - before each subsequent appending of a log entry (10) involving the corresponding log parameter (12), the encoding module (6) checks whether the current value (14) of the log parameter (12) or the difference between the current value (14) and the previous value results in a smaller file size of the encoded log file (1.KOD); and - The encoding module (6) appends the specific entries that result in a smaller file size as logging entries (10) to the encoded log file (1.KOD).

6. The method according to any one of claims 1 to 5, It is characterized in that The encoding module (6) applies a calculation rule to a log entry (10) to be attached to the encoded log file (1.KOD), and attaches the calculated log entry to the encoded log file (1.KOD).

7. The method according to any one of claims 1 to 6, It is characterized in that The encoding module (6) checks whether there is a deletion event in the logging event (11), and when a deletion event is identified, removes all the logging entries (10) related to the corresponding logging parameters (12) mentioned in the deletion event from the encoded log file (1.KOD).

8. The method according to any one of claims 1 to 7, It is characterized in that A maximum size is specified for the encoded log file (1.KOD). When the encoded log file (1.KOD) reaches the maximum size, the encoding module (6) starts to generate a second encoded log file after the encoded log file (1.KOD) is saved for the last time, or at least no further log files (1) are generated for this system monitoring.

9. The method according to any one of claims 1 to 8, It is characterized in that For the encoded log file (1.KOD), a maximum number of log entries (10) is specified for a specific log parameter (12). When the maximum number of the log parameter (12) is reached, when the corresponding log entry (10) is attached to the encoded log file (1.KOD) again, the corresponding oldest log entry is overwritten by the corresponding latest log entry of the log parameter (12).

10. A data processing system (2), It is characterized in that Device for carrying out the method according to any one of claims 1 to 9.

11. A vehicle, It is characterized in that A data processing system (2) according to claim 10 or a component of a data processing system (2) according to claim 10.

Images