Method and system for processing status data from a vehicle

Abstract

The invention relates to a computer-implemented method (100) comprising the steps of: receiving (110) status data (F), in particular vehicle status data, from control software of a vehicle (10) by means of a data-processing system (20); generating (120) data specifications (D) for the status data (F) on the basis of source code data (Q) of the control software using a large language model (31); retrieving (130) the data specifications (D) and the status data (F), preferably via a program interface, by means of a data consumer unit (40); processing (140) the status data (F) using the data specifications (D), preferably to generate a control signal (S), by means of the data consumer unit (40). The invention also relates to a corresponding system (20) for processing said status data (F).

Description

[0001] Method and system for processing vehicle condition data

[0002] The present invention relates to a computer-implemented method and a system for processing vehicle status data using a Large Language Model.

[0003] Technological background

[0004] Systems that analyze and evaluate source code data, or human-written program code, are well-known. For example, static code analysis and white-box testing methods perform error detection in source code. These methods are based on analyzing the source code data, for instance, with regard to formal aspects or programming standards, such as a return value per function and boundary tests that check the program for edge cases and verify its integrity. Such methods are often known as software testing procedures and aim to analyze the source code for problems that can arise after transformation / compilation by a compiler.

[0005] The continuous development of machine learning and the associated natural language processing, for example through transformers, also makes it possible to analyze source code, test the program based on the source code and identify errors or weaknesses in the source code.

[0006] While static code analysis and general white-box testing methods focus on examining and detecting errors in source code, machine learning enables the analysis of a wide variety of source code data and the identification of patterns and relationships. These approaches allow for the completion and evaluation of source code, as well as the translation of source code from one programming language to another.

[0007] Both approaches allow for an extensive and detailed analysis of the source code to find potential errors. However, programs are often based on a multitude of different program versions and thus also on different source code versions, which can be tested and analyzed independently. This constant version changes become problematic when values ​​or variables change their meaning, assignment, and / or calculation method in different source codes. For example, a variable X might be instantiated as a floating-point number in version 1.0 of the source code, but declared as an integer in a new version 2.0. This change doesn't cause any problems or errors when comparing the two source codes, but the variable's specification and possibly its calculation also change. These properties of a variable or...An attribute's data specifications can be described as such, providing the user and / or any other instance with information about that variable. This can include the data type, scope, value range, attribute assignment, calculation formula, meaning, default value, attribute dependencies, and / or other specifications. Previously, these data specifications had to be created and maintained manually, resulting in additional costs and effort during software versioning. Furthermore, if the source code lacks (correct) documentation, it becomes problematic to deduce the calculation method and unit of measurement from the source code when evaluating the data.

[0008] EP 2 223 213 B1 discloses a method for performing a static analysis of software code written in multiple programming languages. The claimed method analyzes the software code and aims to identify problems and / or errors more efficiently, thereby reducing software development costs.

[0009] DE 11 2016 003 335 T5 discloses a system for natural language processing (NLP) and natural language generation (NLG). Furthermore, this also enables translation (natural language translation, NLT) and question answering (natural language processing question and answer, NLP Q&A).

[0010] DE 10 2005 055 208 A1 discloses a traffic warning system for providing information about hazards on roads, with devices in vehicles which automatically generate warning information for occupants of other vehicles, for example, based on sensors. The invention aims to provide further possibilities – apart from radio stations – for obtaining and disseminating warning information for drivers.

[0011] A problem with current analytical methods is that they only indicate errors but do not generate the aforementioned data specifications. Similarly, current methods do not address influencing traffic situations based on automatically read vehicle data.

[0012] Based on the described prior art, an object of the present invention is to enable improved analysis of vehicle data. In particular, the object is to reliably distinguish between different source codes of a vehicle. Furthermore, a method is to be provided which reliably retrieves vehicle data from a human-machine interface, which, for example, represents the source code for a vehicle. Finally, it should be possible to use vehicle data to improve traffic situations.

[0013] Summary of the invention

[0014] These tasks are solved by a computer-implemented method according to claim 1 and a system according to claim 9.

[0015] According to one aspect of the invention, a computer-implemented method is proposed which comprises at least the following steps. In one step, state data, in particular vehicle state data, is received from a vehicle's control software by a data processing system. A subsequent step comprises generating a data specification for the state data based on source code data of the control software using a Large Language Model. A subsequent step comprises retrieving the data specification and the state data, preferably via a program interface, by a data acquisition unit. A subsequent step comprises processing the state data using the data specification, preferably to generate a control signal, by the data acquisition unit.

[0016] In other words, the source code data can be analyzed using a large language model trained through machine learning. This analysis generates data specifications for the status data. This allows for a more precise characterization and processing of the status data transmitted by the vehicle. Furthermore, this characterization of the status data using the data specifications enables the data acquisition unit to process the status data. This unit analyzes the data specifications and applies predefined rules. Depending on these predefined rules, a control signal can be generated. These predefined rules can include, for example, deviations from a target value (voltage, speed, temperature, etc.) and / or pattern fulfillment (adherence to defined ranges) and / or other specific observations (traffic flow, accident events, etc.).The control signal can control an actuator, causing it to change or maintain its mechanical state. The actuator can be located inside the vehicle or in a traffic area of ​​the vehicle or another vehicle. To receive the state data, the vehicle can include one or more transmitter and receiver units and / or control units and / or sensors. Furthermore, the vehicle can include an actuator that can be controlled by the control signal.

[0017] The computer-implemented method enables the error-free determination of data specifications and thus the correct interpretation of the status data. Based on a calculation derived from the status data, the vehicle or other road users can be warned of a potential hazard in road traffic, or they can be warned via, for example, existing visual systems in the road.

[0018] According to one embodiment of the computer-implemented method, the condition data includes speed, software version, speed, fuel consumption, engine status, battery status, vehicle position, mileage, as well as weather conditions, traffic situation, sign analysis, road condition, geographical terrain, ambient noise and / or air quality data.

[0019] The status data preferably includes all time-varying technical data. A broad database can help to locate faulty status data.

[0020] According to another embodiment of the computer-implemented method, the data specifications are attribute-specific properties, such as data type, scope, value range, attribute assignment, calculation formula, meaning, default value, attribute dependency, and / or other vehicle-related specifications. However, this list is not limited to the properties mentioned and may also include other properties.

[0021] Another embodiment of the computer-implemented method includes the additional step of storing the status data in a status database. In other words, the status data is stored in at least one status database. Optionally, the status data can also be retrieved and / or modified. Optionally, the status data is stored using a key that meets the criteria (e.g., the PRIMARY KEY restriction in SQL) for unique identification. However, this key provides no information about the origin of the status data. Optionally, the data is anonymized and / or delivered to the status database already anonymized. This means that the status data contains no information from which conclusions could be drawn about the driver's identity (personal data).Using a state database has the advantage of fulfilling the FAIR principles (Findability, Accessibility, Interoperability, and Reusability).

[0022] Another embodiment of the computer-implemented method includes the step of modifying and / or maintaining the vehicle's condition data to modified and / or unchanged condition data located in the condition database.

[0023] In other words, it is optional to interact with the state data to modify it. This is then referred to as modified state data. The state database can consist of one or more state databases.

[0024] According to another embodiment, the computer-implemented method includes the step: influencing the state of an actuator of the vehicle by the control signal.

[0025] The vehicle's actuator may optionally be a display device, such as a warning symbol or animation, particularly in an instrument panel area, and / or a means of adjusting the vehicle speed, such as cruise control, brakes, or adaptive cruise control.

[0026] Another embodiment of the computer-implemented method comprises the step of changing the state of a visual representation in road traffic, in particular an electromechanical sign system, by an actuator of road traffic, in particular an actuator of an electromechanical sign system.

[0027] Optionally, the actuator can be a visual actuator embedded in the road surface, in particular a display, which is triggered by the control signal. Optionally, the actuator can issue a warning message. Optionally, the actuator can be located at a GPS position determined by the data acquisition unit from the status data. This enables timely warning of a hazardous situation for approaching drivers.

[0028] Another embodiment of the computer-implemented method comprises the following further steps: acquiring the condition data by the vehicle using at least one sensor and / or control unit; and transmitting the condition data to the data processing system, in particular the condition database, by the vehicle using at least one transmitter and receiver unit.

[0029] Optionally, sensors can be selected from the group of infrared, ultrasonic, laser, lidar, camera, and / or radar sensors. This list is not exhaustive, however, and other sensors can also be used. Optionally, the acquired status data can be transmitted to the status database via a transmitter and receiver unit, such as a mobile communication unit and / or car-to-car communication or similar technology. Optionally, status data can also be read directly from the control unit, such as temperature or control unit utilization (CPU, memory, network).

[0030] The aforementioned task is further solved by a system for processing state data. The system comprises at least one state database for storing state data from a vehicle and a large language model configured to generate data specifications for the state data based on source code data from the vehicle's control software. Furthermore, the system is configured to receive state data from a vehicle and transmit data specifications and state data, preferably via a program interface, to a data acquisition unit. The system is also preferably configured to receive a control signal for the vehicle from the data acquisition unit and transmit it to the vehicle.

[0031] The system enables the same beneficial effects as the process.

[0032] According to another embodiment, the system includes a software database which is preferably configured to store source code data from a programming workstation.

[0033] Optionally, the programming workstation serves as an interface between a human (e.g., a programmer) and a machine, preferably an external programming workstation. Source code data created by a human can be transferred from the programming workstation to the software database. The programming workstation can be hardware through which a programmer enters and / or inputs data in any programming language. Preferably, new source code data, from which a new software version is compiled, is transferred by the programmer to the software database via the programming workstation. Optionally, this data is stored using a key that meets the criteria (e.g., a PRIMARY KEY restriction in SQL) for unique identification.This allows the program version and its associated source code data to be retrieved from the software database using a key. Optionally, the key provides information about the temporary rank of the software version and / or source code data, which can be used to identify the latest software version and / or source code data.

[0034] According to another embodiment, the system for processing state data comprises first source code data and second source code data for a type of vehicle, wherein the first source code data generates first state data and the second source code data generates second state data.

[0035] In other words, depending on whether the vehicle or its control software operates with first-order source code data or second-order source code data, a vehicle type can generate first-order state data with the first-order source code data and second-order state data with the second-order source code data. Optionally, the first-order state data can be a first version of the control software and / or the second-order state data can be a second version of the control software. Optionally, the first-order source code data can include the first sub-source code for a first electronic component and the first sub-source code for a second electronic component. Optionally, the second-order source code data can include the first or second sub-source code for a first electronic component and / or the first or second sub-source code for a second electronic component. The first-order source code data and the second-order source code data are not identical.Even if the first and second source code data differ, the system can reliably generate the data specifications and transmit them to a data recipient unit for processing state data.

[0036] In a further embodiment of the state data processing system, a data extraction unit is included, which is specifically configured to assign the state data to first or second source code data. The data extraction unit is preferably configured to retrieve state data from the state database and the associated source code data from the software database. The data extraction unit can forward the source code data and the state data to the Large Language Model. The data extraction unit can be configured to retrieve and / or process state data and / or the source code data from the state database and / or the software database. Optionally, the data extraction unit prepares the state data and / or the source code data for the Large Language Model.

[0037] In another embodiment of the system for processing state data, a specification database is included, which is specifically designed for storing data specifications.

[0038] Optionally, the specification database is configured to receive data specifications from the Large Language Model and / or to transmit data specifications to a data consumer unit. Optionally, the data consumer unit can also be directly connected to the specification database.

[0039] In a further embodiment of the system for processing state data, a data receiver unit is included which is configured to receive data specifications and state data and to evaluate the data specifications and the state data and preferably to generate a control signal.

[0040] Optionally, the data acquisition unit is connected to the status database and / or the specification database, preferably directly connected.

[0041] In another embodiment of the system for processing state data, the data receiver unit has an evaluation application which is designed to compare the data specifications and the state data, to compare a result of the comparison with reference values, and to generate a control signal depending on the result of the comparison.

[0042] Optionally, the evaluation application is configured to characterize a data point of the state data or a series of state data points and to determine its specification. This can be done using data specifications, which are optionally retrieved from the specification database using a key. The data receiving unit is configured to receive the state data, which optionally contains the key for the specification database. Using this key, the data specifications corresponding to the state data can be accessed.

[0043] Optionally, the control signal can be configured to directly or indirectly control an actuator. The actuator can be an actuator within the vehicle itself or an external actuator in road traffic that can influence other vehicles.

[0044] This allows the evaluation application to specify the state data, that is, to establish and characterize the mapping to data specifications. Characterizing here means determining what a data point represents. Subsequently, (predefined) rules can be applied to the state data.

[0045] In another embodiment of the computer-implemented method, the Large Language Model determines the data specifications directly from the source code data.

[0046] The Large Language Model can have any structure and / or architecture suitable for a Large Language Model. According to one structure, the Large Language Model can include a transformer, which incorporates a deep learning architecture and uses a multi-headed attention mechanism to analyze the source code for patterns and relationships. The Large Language Model can be trained, its parameters then optimized via backpropagation and subsequently validated. All these steps can be applied to independent or multiple parts of the state data. Optionally, the steps can also be generated using other approaches, such as K-fold cross-validation, stratified sampling, and time-based splitting. A self-supervised methodology can also be used, optionally. These data specifications are then transferred to a specification database.The specification database can be structured similarly to the source code database and / or the state database.

[0047] According to another embodiment of the computer-implemented method, the state database, the software database and / or the specification database are located in a database and / or on a server.

[0048] Furthermore, the aforementioned task can be solved by a computer-readable storage medium that contains executable machine instructions which cause a computer to implement the described procedure.

[0049] Further advantageous embodiments are described in the dependent claims.

[0050] Brief description of the figures: The following section explains the revelation in more detail using exemplary embodiments and with reference to the figures. Here, it shows

[0051] Figure 1 shows the process of a method according to the invention in a first embodiment;

[0052] Figure 2 shows the process of a method according to the invention in another embodiment;

[0053] Figure 3 shows a block diagram of the method according to the invention;

[0054] Figure 4 shows an exemplary detailed block diagram of a data processing system which can be used for the method according to the invention.

[0055] Figure 5 shows an example of a vehicle which can be used for the method according to the invention;

[0056] Figure 6 shows an example of a detailed block diagram of a data transfer between a programming workstation and a system for processing state data;

[0057] Figure 7 shows an example of data transfer between a programming workstation, a software database, a data extraction unit and a specification database;

[0058] Figure 8 illustrates the interaction between a programmer's workstation and a vehicle;

[0059] Figure 9 shows an example of data transmission between a data receiver unit, a software database, a specification database and a vehicle;

[0060] Figure 10 shows an example of data transmission between a data receiving unit, an evaluation application and an actuator;

[0061] Figure 11 shows an example of a block diagram of the data transmission between a data receiver unit, an evaluation application and an actuator.

[0062] Detailed description of the invention

[0063] In the following description, the same reference numerals are used for identical and equivalent parts. Figure 1 shows the sequence of the method 100 according to the invention in a flowchart according to a first embodiment. The computer-implemented method 100 comprises, in a first step 110, the reception of (vehicle) state data F from a vehicle control software 10 by a data processing system 20. In a second step 120, a data specification D for the state data F is generated based on source code data Q of the control software using a Large Language Model 31. In a third step 130, the data specification D and the state data F are retrieved by a data acquisition unit 40. The retrieval can be carried out via a program interface.In a fourth step 140, the state data F is processed using data specifications D by the data receiver unit 40. Optionally, a control signal S can be generated in this process.

[0064] Figure 2 shows the sequence of another method 100 according to the invention in a flowchart according to a second embodiment. The steps described with reference to Figure 1 are identical unless explicitly stated otherwise. The additional steps according to this embodiment are to be considered optional. In other words, individual steps described in this embodiment can be omitted, or other undescribed steps can be added, provided that the essential steps according to the first embodiment are included.

[0065] According to a first optional intermediate step 112, after the first step 100, the state data F is stored in a state database 21.

[0066] According to a second optional intermediate step 114, after the intermediate step 112, the condition data F of the vehicle 10 is modified and / or continued 114 to changed and / or unchanged condition data F', which are located on the condition database 21.

[0067] After the fourth step 140, a step 150 is optionally performed, after which the control signal S influences a state of an actuator 13 of the vehicle.

[0068] Optionally, that is, in addition to or as an alternative to step 150, step 152 is executed, according to which a state of a visual representation in road traffic is changed by an actuator 42 of the road traffic, in particular an actuator 42 of an electromechanical sign system. The visual representation in road traffic can be an electromechanical sign system. This can be manipulated by an actuator 42 to influence road traffic.

[0069] Optionally, the procedure 100 includes the upstream steps 106 and / or 108. In step 106, the vehicle 10 acquires the status data F by means of at least one sensor and / or control unit 11. In step 108, the vehicle 10 transmits the status data F to the system 20 for data processing, in particular the status database 21, by means of at least one transmitter and receiver unit 12.

[0070] Figure 3 shows an example block diagram on the basis of which the previously described method 100 can be carried out. The above description continues to apply unless otherwise stated. Figure 3 shows the method for acquiring state data F. The state data F can be vehicle- and / or environment-related data. In this embodiment, state data F from one vehicle 10 and from another vehicle 10' are received by the system 20 for processing state data. The number of vehicles is chosen here as two for illustrative purposes and can be in the range of > 1000, > 100,000, or > 1,000,000. The state data F, which is located in the state database 21, can be edited (modified) or left unchanged. The edited state data F' are labeled F' in the figures and in the description.The (processed) state data F, F' and the associated data specifications D are transferred to a data receiver unit 40.

[0071] In this embodiment, the state data F is transmitted anonymously to system 20 for processing state data F. System 20 analyzes and processes the state data F, F' and transmits it upon request from the data receiving unit 40. System 20 is explained in detail below. The associated data specifications D are automatically transmitted to the data receiving unit 40 along with the state data F, F' or requested by the data receiving unit 40 from system 20.

[0072] In this embodiment, the transmission of the vehicle 10's status data F to the system 20, the transmission of the data specifications D from the system 20 to the data receiver 40, and / or the transmission of the status data F, F' to the system 20 can be carried out via a wireless connection, e.g., via mobile network or car-to-car communication. In this embodiment, the system 20 for processing status data F comprises a status database 21 for storing status data F from a vehicle 10 and a Large Language Model 31, which is configured to generate data specifications D for the status data F based on source code data Q of the vehicle 10's control software. Furthermore, the system 20 is configured to receive status data F from a vehicle 10 and to transmit data specifications D and status data F, F' to a data receiver 40.In this embodiment, the Large Language Model 31 is trained to directly output corresponding data specifications D. Optionally (dashed line in Fig. 3), the system 20 can receive a control signal S for the vehicle 10 from the data acquisition unit 40 and transmit it to the vehicle 10.

[0073] Figure 4 shows an exemplary detailed block diagram of a system 20 for data processing according to another embodiment, which can be used for the method 100 according to the invention. The above description continues to apply unless otherwise stated. The following section explains a detailed sequence of data analysis and processing within the system 20 for processing state data, as well as the querying of the state data F, F' and the associated data specifications D by the data acquisition unit 40.

[0074] The optionally anonymized status data F is transmitted from vehicle 10 to system 20 and stored within it on the status database 21. This central storage makes it possible to provide data from multiple vehicles 10, 10'.

[0075] Furthermore, according to this embodiment, system 20 comprises a software database 22, which is preferably configured to store source code data Q from a programming workstation 2. In other words, the software database 22 contains older and newer source code data Q (also called software versions). Alternatively, the software compiled from the source code data Q can also be stored in the software database 22. This software can then be tested, for example, in a vehicle simulator.

[0076] Furthermore, according to this embodiment, the system 20 comprises a data extraction unit 30, which is configured to assign the state data F to the first or second source code data Q. The data extraction unit 30 is configured to extract the source code data Q from the software database 22 and the vehicle data F from the state database 21 and forward them to the Large Language Model 31.

[0077] The Large Language Model 31 is a trained model that, through training with suitable training data, is capable of determining or generating corresponding data specifications D based on the source code data Q and the vehicle data F. The model is trained and validated on existing data. In particular, it is validated to such an extent that an erroneous output of data specifications D is impossible.

[0078] Furthermore, according to this embodiment, the system 20 includes a specification database 23, set up for storing data specifications D. Similar to the state database 21, storing the data specifications D in the specification database 23 allows this data to be retrieved and further processed via a data receiving unit 40 or another external client.

[0079] In this embodiment, the data acquisition unit 40 is connected to the system 20 via two program interfaces. However, the disclosure is not limited to this example, and any other implementation of the data transmission is also possible. The data acquisition unit 40, which is located outside the system 20, can access the state data F, F' in the state database 21 and the associated data specifications D in the specification database 23 and process them internally.

[0080] Figure 5 illustrates by way of example a vehicle 10, 10' which can be used for the method according to the invention. The above description continues to apply unless otherwise stated. The vehicle 10, 10' has at least one sensor and / or a control unit 11, at least one transmitter and receiver unit 12 and at least one actuator 13.

[0081] The sensor and / or the control unit 11 enable the vehicle 10, 10' to acquire status data F. This status data F is then transmitted to the transmitter and receiver unit 12 and can thus be sent to a non-physically connected system 20 for processing status data. Referring to Figures 3 and 4, it is therefore possible for several vehicles 10, 10' to simultaneously send their status data F to the system 20.

[0082] Figure 6 shows an exemplary detailed block diagram of a data transfer between a programming workstation 2 and a system 20 for processing status data. The above descriptions remain valid unless otherwise stated. Figure 6 shows an embodiment in which source code data Q is transferred from a programming workstation 2 to the software database 22. In this embodiment, the software database 22 stores the new source code data Q, which corresponds to a new software version. A new software version is assigned an ascending new software version number. This allows the source code data Q and / or the software to be queried using the software version number. With reference to Figure 4, Figure 6 illustrates the transfer of new source code data Q to the software database 22 using at least one programmer workstation 2.

[0083] According to one embodiment, for a given vehicle type, there are 10 first source code data sets Q (e.g., an earlier software version number) and 10 second source code data sets Q (e.g., a newer software version number), wherein the first source code data sets Q generate first state data sets F, and the second source code data sets Q generate second state data sets F. This difference can arise because a component required a firmware update or had to be replaced due to problems. Even if the software functions correctly based on both the first and second source code data sets Q, different functional sequences occur within the software when the respective software is executed based on the first and second source code data sets Q. These different functional sequences can lead to differences in the state data sets F.These differences can be at least partially compensated for by using the corresponding data specifications D. Therefore, different data specifications D may be required for the correct interpretation of the values ​​in the state data F. For this reason, in this embodiment, the corresponding data specifications D for all state data F are stored in a specification database 23.

[0084] Figure 7 illustrates an example of data transfer between a programming workstation 1, a software database 22, a data extraction unit 30, and a specification database 23. The previously described details remain valid unless otherwise stated. The software database 22, the data extraction unit 30, and the specification database 23 are assigned to system 20. With reference to Figures 4 and 6, which also illustrate other components of system 20, Figure 7 aims to explain the information and data transfer visually and with consideration of the temporal aspect. First, source code data Q is transferred from the at least one programming workstation 2 to the software database 22. In other words, source code data Q is first generated in a programming workstation 2, for example, by a programmer, and then transferred to the software database 22.

[0085] A query A from the data extraction unit 30 to the software database 22 subsequently transmits the source code data Q to the data extraction unit 30. In this embodiment, this data query can be performed using the aforementioned software version number. This enables transitive source code data exchange between the programming workstation 2 and the data extraction unit 30. The intermediate step of generating data specifications D via the Large Language Model 31 is not shown here and has already been described with reference to Figures 3 and 4. Furthermore, it is illustrated how the determined data specifications D are transmitted to the specification database 23.

[0086] Figure 8 shows an example of the interaction between a programmer workstation 2 and a vehicle 10. The above descriptions continue to apply unless otherwise stated. Similar to the explanation given with regard to Figure 6, the source code data Q is transferred to the vehicle 10 using the programmer workstation 2. In this embodiment, this process can be understood as the transfer of a new software version (vehicle software). In this embodiment, the new software version includes new software (firmware) for the vehicle's sensors and / or control units.

[0087] Figure 9 illustrates an exemplary data transmission between a data acquisition unit 40, a software database 21, a specification database 23, and a vehicle 10, taking into account the temporal aspect according to an exemplary embodiment. The above description continues to apply unless otherwise stated. After the transfer of the status data F from the vehicle 10 to the system 20 or the status database 21, this data is stored and saved, thus enabling later use. The data acquisition unit 40 can therefore retrieve and process the stored status data F, F'. As already described in Figures 4 and 6, the Large Language Model 31 is configured to determine or generate corresponding data specifications D based on the source code data Q and the vehicle data F. The generated data specifications D are stored in the specification database 23.Alternatively, if the data specifications D determined by the Large Language Model 31 are already stored in the specification database 23, a direct reference can be made to the data specifications D. The illustrated data transmission demonstrates that the data consumer unit 40 has access to the vehicle data F, F' and the associated data specifications D. For example, the consumer unit 40 can send a query A to the state database 21, whereupon the state database 21 transmits the vehicle data F, F' to the consumer unit 40. Similarly, the consumer unit 40 can send a query A to the specification database 23, whereupon the specification database 23 transmits the data specification(s) D to the consumer unit 40. In other words, the data specifications D can be retrieved by the data consumer unit 40.

[0088] By comparing the vehicle data F, F' with the data specifications D, the data acquisition unit 40 can determine attribute properties. The state data F can initially include speed, software version, engine speed, fuel consumption, engine status, battery status, vehicle position, mileage, as well as weather conditions, traffic situation, sign analysis, road surface, geographic terrain, ambient noise, and / or air quality data. Attribute properties are characteristics such as data type, scope, value range, attribute assignment, calculation formula, meaning, default value, attribute dependency, and / or other vehicle-related specifications. In other words, the data specifications D precisely define individual values ​​of the state data F, F'. For example, in one embodiment, the tire pressure is included as an integer value in the vehicle data F.Only the data specifications D reveal how this value is converted into the unit bar. Without knowledge of the data specifications D, it could be a different unit. Furthermore, it may be specified which temperature value refers to which tire, in order to verify pressure changes.

[0089] In another embodiment, the determined data specifications D can include information about a variable X, indicating that this variable is the tire pressure of the right front tire and that in an initial software version (e.g., V1.0), this pressure is given in bar. For the same vehicle type of a different model year and a subsequent software version (e.g., V2.0), other data specifications D may be relevant, which, for example, define that the variable X is given in PSI (pounds per square inch). This is fundamental for further calculations, as both units would have to be converted (1 bar corresponds to 14.5 PSI).

[0090] Figure 10 shows an example of data transmission between a data collection unit 40, an evaluation application 41, and an actuator 13, 42. The above description continues to apply unless otherwise stated. In this embodiment, the system 20 within the data collection unit 40 comprises an evaluation application 41, which is configured to compare the data specifications D and the status data F, compare the result of the comparison with reference values, and generate a control signal S depending on the result of the comparison. Optionally, the collection unit 40 can also be located externally from the system 20 and only be in communicative contact with the system 20.

[0091] Figure 11 shows an example block diagram of the data transmission between a data receiver unit 40, an evaluation application 41 and an actuator 42.

[0092] Figures 10 and 11 are explained together below. First, vehicle data F, F' and the data specifications D flow to the at least one evaluation application 41, which is located in the data receiving unit 40. As already described, the evaluation application 41 is configured to combine the data specifications D and the state data F to obtain reliable state data that can provide the basis for further processing. Further processing can consist of applying predefined or derived rules and / or comparing this reliable state data with reference values. Furthermore, reliable state data can be chained into a series to obtain a transient trend of a value, e.g., tire pressure. Values ​​can also be analyzed in relation to other values. For example, when the airbag is deployed (e.g.,The variable “airbag_activated” = “1”), along with the restraint systems and a sudden (negative) acceleration, strongly suggests an accident situation. Evaluation application 41 can thus directly locate this accident situation using position information, which may also be contained in the state data of the corresponding vehicle. If this occurs, for example, on a highway, evaluation application 41 is configured to generate a control signal S, which activates, for example, an actuator 42 in a signage system. This allows traffic behind on this highway to be warned in order to prevent further accidents.Additionally and / or alternatively, a control signal S can be sent via the system 20 for processing status data back to one or more vehicles 10, 10' in order to manipulate an actuator 13 of the vehicle, for example to warn the driver on a display and / or to indicate and / or request and / or carry out a reduction in speed.

[0093] Furthermore, the evaluation application 41 can be configured to receive a feedback signal R from the actuator 13, 42, which can prompt the evaluation application to query further status data F, F'. Based on this additional status data F, F', further calculations and / or analyses of the situation can be performed to validate it and / or to observe it in more detail.

[0094] Reference symbol list

[0095] 2 programming workstations

[0096] 10 vehicles

[0097] 10' additional vehicle

[0098] 11 Sensor and / or control unit

[0099] 12 Transmitter and receiver unit

[0100] 13. Vehicle actuator

[0101] 20 System for processing status data

[0102] 21 Status Database

[0103] 22 Software Database

[0104] 23 Specification Database

[0105] 30 Data Extraction Unit

[0106] 31 Large Language Model

[0107] 40 data collection units

[0108] 41 Evaluation application

[0109] 42 external actuator

[0110] A request

[0111] F status data

[0112] F' processed state data

[0113] D Data Specifications

[0114] Q Source code data

[0115] R feedback signal

[0116] S control signal

Claims

Claims 1. Computer-implemented method (100), comprising at least the steps of: Receiving (110) status data (F), in particular vehicle status data, from a vehicle control software (10) by a data processing system (20); Generating (120) data specifications (D) for the state data (F) based on source code data (Q) of the control software using a Large Language Model (31); Retrieval (130) of the data specifications (D) and the status data (F), preferably via a program interface, by a data receiving unit (40); Processing (140) the state data (F) using the data specifications (D), preferably to generate a control signal (S), by the data receiver unit (40).

2. Computer-implemented method (100) according to claim 1, wherein the state data (F) comprise speed, software version, speed, fuel consumption, engine status, battery status, vehicle position, mileage, as well as weather condition, traffic situation, sign analysis, road condition, geographical terrain, ambient noise and / or air quality data.

3. Computer-implemented method (100) according to one of the preceding claims, wherein the data specifications (D) are attribute properties such as data type, scope, range of values, assignment of the attribute, calculation formula, meaning, default value, attribute dependency and / or other vehicle-related specifications.

4. Computer-implemented method (100) according to any one of the preceding claims, comprising the step: Storing (112) the state data (F) in a state database (21).

5. Computer-implemented method (100) according to the preceding claim, comprising the step: Modifying and / or continuing (114) the vehicle's condition data (F) to modified and / or unchanged condition data (F') which is located on the condition database (21).

6. Computer-implemented method (100) according to any one of the preceding claims, comprising the step: Influence (150) of a state of an actuator (13) of the vehicle by the control signal (S).

7. Computer-implemented method (100) according to any one of the preceding claims, comprising the step: Changing the state of a visual representation in road traffic (152), in particular an electromechanical sign system, by an actuator (42) of road traffic, in particular an actuator (42) of an electromechanical sign system.

8. Computer-implemented method (100) according to any one of the preceding claims, comprising the further steps: Acquisition (106) of the condition data (F) by the vehicle (10) using at least one sensor and / or control unit (11); Transmission (108) of the status data (F) to the system (20) for data processing, in particular the status database (21) by the vehicle (10) by means of at least one transmitter and receiver unit (12).

9. System (20) for processing state data (F), in particular vehicle state data, comprising: a state database (21) for storing state data (F) of a vehicle (10); a Large Language Model (31) configured to generate data specifications (D) for the state data (F) based on source code data (Q) of a control software of the vehicle (10); wherein the system (20) is configured to To receive status data (F) from a vehicle (10); Data specifications (D) and status data (F, F') are preferably transmitted via a program interface to a data receiving unit (40); and preferably to receive a control signal (S) for the vehicle (10) from the data acquisition unit (40) and to transmit it to the vehicle (10).

10. System (20) for processing state data (F) according to claim 9, further comprising: a software database (22) which is preferably configured to store source code data (Q) from a programming workstation (2).

11. System (20) for processing state data (F) according to claim 9 or 10, wherein for a type of vehicle (10) first source code data (Q) and second source code data (Q) are available, wherein the first source code data (Q) generate first state data (F) and the second source code data (Q) generate second state data (F).

12. System (20) for processing state data (F) according to claim 11, further comprising: a data extraction unit (30), in particular configured for assigning the state data (F) to first or second source code data (Q).

13. System (20) for processing state data (F) according to any one of claims 9 to 12, further comprising: a specification database (23), in particular configured for storing data specifications (D).

14. System (20) for processing state data (F) according to any one of claims 9 to 13, further comprising: a data receiving unit (40) which is configured to, to receive data specifications (D) and state data (F, F'); and to evaluate the data specifications (D) and the state data (F, F') and preferably to generate a control signal.

15. System (20) for processing state data (F) according to claim 14, wherein the data receiving unit (40) comprises an evaluation application (41) configured to compare the data specifications (D) and the state data (F); and to compare a result of the comparison with reference values ​​and to generate a control signal (S) depending on the result of the comparison.

Images