Method for using unknown new system services in a vehicle application

Abstract

The invention relates to a method for using new system services (S31,..., S3n) unknown to a vehicle application (3) at the time of design in order to resolve a service request. For this purpose, a service request is formulated that is transmitted to a computer system (6) together with no input variable or at least one input variable for the system services (S31,..., S3n), a definition of the format of this input variable and a definition of the expected response variable. Using a base model (FM): a) the system services (S41,..., S4n) matching the service request (5) and the sequence of said system services (S41,..., S4n) matching the service request (5) are determined; b) the at least one input variable, if present, is converted into a parameter format matching the input parameters of the at least one first system service (S41,..., S4n); c) a conversion of the output parameters to be expected by the system service or services (S41,..., S4n) into the response variables is determined. The result is compiled to form a source code (10) which is transmitted to the vehicle application (3) in order to carry out the service request. This then carries out the service request (5) using the source code (10).

Description

[0001] Method for using unknown new system services in a vehicle application

[0002] The invention relates to a method for using unknown new system services in a vehicle application, at least some of the system services and / or their input and / or response parameters are unknown.

[0003] Nowadays, system services to which requests are transmitted are becoming increasingly important. Such a request or service request is a task that is solved by using one system service or a combination of several system services. The system services used for this can be, in particular, network-based system services provided by various service providers in local, fully or partially private networks, or even on the Internet. Mixed forms of networks are conceivable. These system services can include various services, for example traffic services, weather services, navigation services, parking space booking, the transmission of information to a requesting system or a person requesting indirectly through this system, and the like. A multitude of different services are conceivable here.In practice, the number of available services changes, as does the content delivered by these system services. Different system services can have different input parameters or do without them and typically always deliver (different) output parameters. The problem, and this applies particularly to a vehicle application, is that these system services must already be known at the time the vehicle application is developed in order to be able to request the appropriate system services within the vehicle application using the appropriate parameters. In practice, this is problematic because it only allows services that were known at the time the vehicle application was designed and only with the interface parameters known at that time.If the service changes, is replaced by one (or more) new services, or if the service changes its interface parameters, it can no longer be used by the vehicle application. In practice, this requires the vehicle application to be reprogrammed if only one of the required services changes, or if a switch from one service to another is required, for example, to optimize costs, optimize functionality, or similar.

[0004] Due to the large number of vehicles with integrated vehicle applications, it is extremely complex to distribute such a programmed update to all vehicles via workshops or as an over-the-air (OTA) update. This is associated with very high costs and leads to a long transition period, for example, from the time a required service is no longer available until the vehicle application is reprogrammed and the corresponding update is delivered to all vehicles. This transition period can be quite lengthy depending on the complexity of the changes. In the worst case, a system service relevant to the people using the vehicle may not be available or may only be available to a very limited extent during this period.

[0005] In principle, it is known from the state of the art that the composition of various system services that together resolve a service request can be achieved using so-called Large Language Models. The composition of the corresponding system services is referred to as service composition. In this context, reference can be made to the article Pesl, RD, Stötzner, M., Georgievski, I., Aiello, M. (2024). Uncovering LLMs for Service-Composition: Challenges and Opportunities. In: Monti, F., et al. Service-Oriented Computing - ICSOC 2023 Workshops. ICSOC 2023. Lecture Notes in Computer Science, vol 14518. Springer, Singapore. https: / / doi.org / 10.1007 / 978-981-97-0989-2_4. The Large Language Model represents a special case of a so-called foundation model.

[0006] For further prior art, reference can also be made to CN 117 709 352 A, which describes a method for preventing the output of potentially falsified information from a large language model.

[0007] The object of the present invention is to improve the use of network-based service services in a vehicle application by specifying a technical method for automated service integration at runtime, so that an update of the vehicle application does not have to be carried out with each change / modification of a required system service.

[0008] According to the invention, this object is achieved by a method having the features of claim 1. Advantageous embodiments and further developments of the method according to the invention emerge from the dependent claims.

[0009] The method according to the invention serves to use network-based, unknown new system services in a vehicle application, to which at least some of the new system services and / or their input and / or response parameters are unknown. The “new” system services within the meaning of the invention also comprise system services which have been modified, whose address has changed and / or whose input and / or output parameters I / O-1 - l / On have changed. It offers the possibility of integrating the new system services into the vehicle application during its runtime to resolve current service requests, without the vehicle application having to be adapted accordingly. Using the method according to the invention, system services which only became known or were only implemented after the design time of the vehicle application can also be used to resolve or process current, complex service requests.which can be addressed via changed addresses or whose input and / or output parameters have been changed since the design time of the vehicle application.

[0010] According to the invention, a service request is formulated, which is then transmitted to a computing system. The computing system can be integrated into the vehicle or, according to an advantageous embodiment of the invention, can be designed entirely or partially as an external computing system and connected to the vehicle via a communications link.

[0011] The computing system here thus forms a tool for carrying out the method according to the invention or has implemented such a tool. It can preferably be at least partially outsourced to a server external to the vehicle and / or a cloud server in order to easily provide the required computing power there. Such a server preferably includes graphics cards or AI accelerators. In particular, the server can be a backend server of the vehicle manufacturer, which in most cases is already available or present and has a communication connection with the vehicle.

[0012] In this computing system, with the aid of a foundation model: a) the system services used that match the service request and the sequence of these system services used that matches the service request are determined; b) if several system services are used one after the other, the output parameters of the previously used system service are transformed into a parameter format that matches the input parameters of the subsequently used system service; and c) a conversion of the output parameters expected from the system service(s) used into a format suitable for the vehicle application is determined.

[0013] This establishes a solution concept for the service request, which is then compiled into source code, e.g., in Python, using the base model, such as a large language model. This source code then resolves the current service request using suitable new system services and converts all input variables, input parameters, output parameters, and response variables—ultimately, the programming interfaces or APIs (Application Programming Interfaces)—into each other as required.

[0014] Although this source code is generated based on the service request transmitted by the vehicle application, this generation occurs completely independently of the vehicle application and is therefore also independent of its design time, its software version, etc.

[0015] The source code thus generated is then transmitted to the vehicle application to process the service request. A compiler / interpreter converts the source code into executable program code, which is then executed by the vehicle application to process or resolve the service request.

[0016] The method according to the invention thus makes it possible to provide the vehicle application with executable program code for the service request, with which it can request current, new system services that were unknown at the time of design of the vehicle application, and whose address and / or input and / or response parameters have since changed. The vehicle application is thus able to use current, new system services without the need for an update. This eliminates the need for a general redesign of the vehicle application. This also eliminates the need for the vehicle applications of individual or all vehicles in the field to receive updates, resulting in significant resource savings.

[0017] Even though service requests are fundamentally conceivable without a dedicated input variable, such as a bundled query for errors from various error logs using a simple "are there any errors?", the service request will often be made with input variables, such as a position specification or similar. For this purpose, an advantageous further development provides for the input variable for the system services and a definition of the format of this input variable to be transmitted along with the service request. In step b), the at least one input variable is then always transformed into a parameter format that matches the input parameters of the at least one first system service used.

[0018] With regard to the conversion of the response, it can be provided according to a very advantageous embodiment that the service request is transmitted to the computing system together with a definition of the expected response variables, in order then to define in step c) a conversion of the output parameters expected from the system service(s) used into the response variables for the vehicle application.

[0019] A very advantageous development of the invention provides that a large language model, a further trained model trained with suitable data or a model created solely for the purpose of the inventive method serves as the base model. Such models are then, strictly speaking, no longer large language models, since they are by definition designed as "general purpose" models. The specially created and / or trained models can deliver better results. Thus, in addition to general large language models, specially trained variants can also be used. These can also be so-called small language models, language processing models, machine learning models or other small models, which may offer the advantage of a simpler architecture and / or smaller size.

[0020] The interpreter or compiler with which the source code, for example Python code, is converted into executable program code can in principle be present in the vehicle or be implemented as part of the vehicle application or part of the system on which the vehicle application is running. In order to avoid having to provide such an environment in which, for example, the Python code can be executed, it would in principle also be conceivable to provide the interpreter or compiler on the computer system so that the executable program code rather than the source code is delivered to the vehicle application. However, to prevent the risk of potentially safety-critical code being introduced into the vehicle application, the first variant, in which the program code is interpreted or compiled within the vehicle, would be preferable.

[0021] According to two advantageous developments of the method according to the invention, documentation of the system services and their input and output parameters can be loaded either before or alternatively after the selection and before the determination of the sequence of the system services in order to know their programming interfaces or their current status. The corresponding documentation can in principle be loaded from the network or from a corresponding storage device. In practice, it will often be the case that frequently used services have their documentation cached, so that this documentation is already available, for example, on the vehicle manufacturer's backend server, which can be used as an external vehicle server.If a system service is used for the first time or hasn't been used for a long time, so that the stored information is no longer available on the server, this information can also be loaded from the network. In principle, it would be conceivable to store the information using a first-in, first-out system, so that the documentation for a specified number of recently used system services is always available on the server, allowing it to be loaded without having to retrieve it from the Internet.

[0022] According to an advantageous embodiment of the method according to the invention, the source code generated using the base model is subjected to an analysis before being transmitted to the vehicle application. Such an analysis using an analyzer is generally common practice when creating program code. The analysis can focus on various aspects, such as identifying programming errors or errors related to the task to be solved, i.e., the correct response to the submitted service request.

[0023] Accordingly, according to an advantageous further development, to purely locate errors or safety-critical code, the analysis can be performed as a static and / or dynamic code analysis. If faulty code is found during such a static and / or dynamic code analysis, the generation of the source code can be initiated again, at least partially. However, if malicious or safety-critical code is detected, which could in principle lead to enormous security problems in vehicle applications, the source code is discarded, regenerated, or improved at the relevant points. In this case, a corresponding warning can be sent, for example, to a vehicle manufacturer operating the server, to clarify the extent to which this malicious or safety-critical code has entered the system.If this code entered the system as part of a service request, it is sufficient to modify the service request accordingly. However, it is also possible that the system or parts of it have been hacked to inject this malicious or security-critical code, so the warning can be used to respond accordingly.

[0024] Static and / or dynamic code analysis can be performed using a conventional (computer) code analysis program, the original base model, or an alternative model that differs from the one used to generate the source code, in order to detect and correct as many errors as possible. The alternative model also offers the opportunity to identify errors inherently caused by the base model.

[0025] In principle, in the event of an error, preferably one that is neither malicious nor security-critical, the source code can be adapted for the service request. The interpretation of the service request can thus be changed to correct the error. According to a particularly advantageous design of the method, the error analysis of the source code and the subsequent adaptation of the service request can be repeated repeatedly, until either no more errors can be detected or the number of errors remains at a minimum. Common similarity analyses can be used to identify such errors, for example, or a base model can be used.

[0026] Ultimately, this creates a type of self-learning system within the method according to the invention that can react to corresponding service requests in order to directly intercept potential errors in future service requests by optimizing the interpretation of the service request based on past experience with similar service requests. According to a very advantageous embodiment of the method according to the invention, the service request itself is generated as a textual description, so that the corresponding system services can be used simply on the basis of formal text components or continuous text components. The textual description can preferably be in natural language. The system services can be or include network-based services, although the system services can of course also be offered by the vehicle manufacturer, a fleet operator, or similar.In reality, it can be assumed that mixed variants will often occur, i.e. that some of the system services will be provided by the vehicle manufacturer or a fleet operator and the other required services will be requested from the network.

[0027] According to an advantageous further development, it can be provided that the computing system checks or filters the services under vehicle-related security aspects. As already mentioned above, the security of the vehicle's internal computer system is of crucial importance. This applies both to protecting the system against unauthorized access and to the security of the functions performed by the system, such as safety-relevant decisions and controls. For example, this can include environmental monitoring during assisted or automated driving or similar. For this reason, it certainly makes sense to check and filter corresponding system services that are directly integrated into these levels of the vehicle system in order to ensure that no malicious aspects are introduced into the system.

[0028] A further very advantageous embodiment of the method according to the invention can provide for vehicle-to-vehicle communication and / or vehicle-to-X communication to be integrated into the source code. Such vehicle-to-vehicle communication or communication between a vehicle and other elements, such as stationary components, is highly relevant for future vehicle applications. For example, safety-relevant aspects can be exchanged; a vehicle can warn another vehicle that hazards are emerging in the area of ​​its environmental sensors that are not yet visible to the other vehicle, and the like. Aspects of stationary elements, such as traffic lights, which transmit their switching status to the vehicle and send the vehicle a message about this a corresponding period of time before switching, can also become increasingly relevant.Such aspects of communication, which typically include a request, the negotiation of a communication channel, and the actual communication, can also be implemented in the source code as part of such system services or to supplement these system services, enabling efficient use of such aspects without requiring updates to the vehicle applications. A special feature of such use cases is that the service request is specific to the current situation and therefore cannot be developed prior to the design of the vehicle application.

[0029] Further advantageous embodiments of the method according to the invention also emerge from the exemplary embodiment, which is described in more detail below with reference to the figures.

[0030] Showing:

[0031] Figure 1 shows a schematic system architecture to illustrate the state of the art and the associated problems;

[0032] Figure 2 shows a schematic representation of the quantities to illustrate the existing and used system services; and

[0033] Figure 3 shows a solution using the method according to the invention, based on the sketch shown in Figure 1. The illustration in Figure 1 shows a very schematic representation of a vehicle 1 in which there is a platform for applications, designated 2, a so-called in-car app platform. Within this platform 2, three individual vehicle applications 3 are shown purely as an example. The system in the illustration to the left of the dashed line shows what takes place within the vehicle 1. A service request can now be generated via a communication connection 4 and sent to various original system services S11, S12-S1n, which is shown to the right of the dashed line in the area outside the vehicle 1, for example on a server external to the vehicle, in the cloud or the like.Each of these original system services S11 - S1n represents a service that can be used to resolve or contribute to the solution of the service request. Each of these original system services S11 - S1n includes its own format for its input and output parameters, which is indicated by the ovals labeled 1 / 0-1, 1 / 0-2, and 1 / On. Of course, individual input and / or output parameters can also be identical or empty.

[0034] In the actual state shown in Figure 1, one or more external original system services S11 - S1n are to be integrated into one of the vehicle applications 3. At the time of development of the vehicle application 3, i.e., at its design time, the respective original system service S11 - S1n and an interface description of its input and output parameters 1 / 0-1 - 1 / On must be known. The conversion of the data into the format expected by the original system service S11 - S1n must be implemented, typically manually. Figure 2 illustrates the set U of these original system services S11 - S1n. From this set U, some or all of the original system services S11 - S1n are now used for the service request. These form the subset gU of the used system services S21 - S2n.The call to the system services S21 - S2n used from the set U of original system services S11 - S1n must be implemented in the correct order in the vehicle application 3. This order can include both sequential and parallel processing of the system services S21 - S2n used. Mixed forms of sequential and parallel processing are also possible and frequently occur in practice. In addition to the correct order, a conversion of the response from the system services S21 - S2n used into a form understandable for the vehicle application 3 or for further processing in the next system service S22 - S2n+1 must also be implemented.

[0035] This means that a dynamic integration of new system services S31 - S3n or system services S31 - S3n which have been modified, whose address has changed and / or whose input and / or output parameters 1 / 0-1 - 1 / 0-n have changed, is not possible. Such system services, which are referred to below for the sake of simplicity as new system services S31 - S3n, are illustrated in a set N indicated in Figure 2. The new system services S31 - S3n lie in an area of ​​the set N which contains at least one new system service which is not contained in U. Purely as an example, the sets N and U are shown in Figure 2 as separate, non-overlapping sets. The new system services S31 - S3n are therefore not usable for the vehicle application 3. If they are to be used nevertheless, a new development orChange development of the vehicle application 3 is necessary, which then has to be rolled out to the individual vehicles 1, for example via OTA updates.

[0036] Typically, this can result in a period of time during which neither the original system services S11 - S1n, for example, due to a change of address, nor the new system services S31 - S3n can be used. This is correspondingly time-consuming, difficult, expensive, and often inconvenient for vehicle users, as usual service requests cannot be resolved for certain periods of time or, in the worst case, a visit to the workshop is necessary to install the update.

[0037] This problem is now to be remedied by using an interface description with formal and / or continuous text components of, for example, network-based services, to generate, in conjunction with a base FM model, e.g., a large language model, a source code 10 that resolves even complex service requests by calling one or, in particular, several new system services S31 - S3n. This solution is illustrated in Figure 3, although the components and elements present in Figures 1 and 3 are not described in detail again.

[0038] Essentially, instead of a complex implementation of calling individual new system services S31 - S3n in the vehicle application 3, which would force an update of the vehicle application 3, the service request is transmitted in text form from the vehicle 1 according to arrow 5, along with a schema of the input variables and a target schema for the response variables expected from the vehicle application 3. The complex request is therefore not executed directly according to the line labeled 4 in the illustration in Figure 1, since in the new concept it is no longer programmed in the vehicle application 3. Instead, it is transmitted via arrow 5 to a computing system 6, in particular a computing system external to the vehicle, such as a cloud server or the backend server of a vehicle manufacturer.The computing system 6 also has access to the documentation of the available new system services S31 - S3n, which in the simplest case can be a list of these system services, and in particular the interface description of the input and output parameters 1 / 0-1 - 1 / On of these system services S31 - S3n. This is indicated by the dot-dash arrows 7 and 8, respectively. Within this computing system 6, based on the available information and with the aid of the base model FM, a source code 10 is generated that solves the task of the service request with the aid of one or more of the new system services S31 - S3n. For this purpose, a subset vN of the system services S41 - S4n used for this purpose is used, analogous to the representation in Figure 2 on the left.This also defines and implements the calls, the order of the calls, and the conversion of the respective responses into the input formats of the dependent system services S42 - S4n. Finally, the result is converted into the target schema of the response variables for vehicle application 3.

[0039] Such a comprehensive source code 10 can now be delivered to the vehicle application 3 according to the arrow marked 9, preferably after it has undergone appropriate analysis or filtering for potential errors, malicious code, etc. This can be done, for example, in the form of Python code, which the vehicle application 3 can then execute independently. Alternatively, interpretation or compilation already takes place in the computing system 6, so that an executable program code 10' is delivered to the vehicle application 3. The service request can then be executed automatically by the vehicle application 3 by executing this code 10, 10'.

[0040] Using this method, a corresponding service request can now be made for each vehicle application 3 at any time, without this vehicle application 3 having to be updated, taking into account the current new system services S31 - S3n and the current formats of their input and output parameters 1 / 0-1 - 1 / On. Of course, all or some of the original system services S11 - S1 n can also continue to be used here. These preferably form their own new system services, e.g., by S14 becoming the new system service S34. The complex service composition is solved here with the aid of the base model FM in the computing system 6, and a suitable code 10, 10' is generated with the aid of the large language model LLM and transmitted to the vehicle application 3, which then automatically executes the service request.

Claims

Patent claims 1 . Procedure for using unknown new system services (S31,...,S3n) in a vehicle application (3), wherein at least one of the new system services (S31,...,S3n) and / or its input and / or output parameters (1 / 0-1 .,l / On) were unknown at the time of development of the vehicle application (3), for which purpose a service request is formulated which is transmitted to a computing system (6), after which in the computing system (6) with the aid of a basic model (FM) a) the system services (S41,...,S4n) used that match the service request and the order of these system services (S41,...,S4n) used that match the service request are determined, after which b) if several system services (S41,...,S4n) used are used one after the other, the output parameters of the respectively previously used system service (S41,...,S4n-1) are converted into a model corresponding to the input parameters of the subsequently used system service (S42,...,S4n) appropriate parameter format, and after which c) a conversion of the output parameters to be expected from the system service(s) used (S41,...,S4n) for the vehicle application (3) is determined, wherein the result of steps a), b) and c) is compiled into a source code (10) which is transmitted to the vehicle application (3) to carry out the service request, wherein the source code (10) is converted via a compiler / interpreter into executable program code (10') which is executed by the vehicle application (3) to carry out the service request.

2. Method according to claim 1, characterized in that the service request together with at least one input variable for the system services (S31,...,S3n) and a definition of the format of this Input variable is transmitted to the computing system (6), wherein in step b) the at least one input variable is brought into a parameter format matching the input parameters of the at least one first system service used (S41,...,S4n).

3. Method according to claim 1 or 2, characterized in that the service request is transmitted to the computer system (6) together with a definition of the expected response variables, wherein in step c) a conversion of the output parameters to be expected from the system service(s) used (S41,...,S4n) into the response variables is defined.

4. Method according to claim 1, 2 or 3, characterized in that a Large Language Model (FM), a model trained or further trained with suitable data or a specially created model is used as the base model.

5. Method according to one of the preceding claims, characterized in that the computing system (6) is designed wholly or partly as a vehicle-external computing system (6) and is connected to the vehicle (1) via a communication connection.

6. Method according to one of the preceding claims, characterized in that the interpretation / compilation takes place within the vehicle (1).

7. Method according to one of claims 1 to 6, characterized in that before the selection and before the determination of the sequence of the system services used (S41,...,S4n) a documentation of at least the system services used (S41,...,S4n) and / or their input and output parameters (1 / 0-1,...,l / On) is loaded or sent to the computer system (6).

8. Method according to one of claims 1 to 6, characterized in that before the selection and before the determination of the order of the system services used (S41,...,S4n), a documentation of at least the system services used (S41,...,S4n) and / or their input and output parameters (1 / 0-1 .,l / On) is loaded or transmitted to the computer system (6).

9. Method according to one of the preceding claims, characterized in that the source code (10) or the executable program code (10') generated by means of the basic model (FM) is subjected to an analysis.

10. The method according to claim 9, characterized in that the analysis is carried out as static and / or dynamic code analysis.

11. Method according to claim 9 or 10, characterized in that the analysis is carried out with a model that differs from the base model (FM).

12. Method according to claim 9, 10 or 11, characterized in that in the case of detected syntax errors, malicious or security-critical components, the generated source code (10) is corrected or discarded.

13. Method according to one of claims 9 to 12, characterized in that in the event of an error, the service request is adapted.

14. Method according to claim 13, characterized in that the error analysis of the source code (10) and the subsequent The service request is adapted repeatedly until no more errors can be detected or their number remains at a minimum.

15. Method according to one of the preceding claims, characterized in that the service request is generated as a textual description.

16. Method according to one of the preceding claims, characterized in that the new system services (S31,...,S3n) are web Services are or include such services, wherein the computing system checks or filters the web services under vehicle-related security aspects.

17. Method according to one of the preceding claims, characterized in that vehicle-to-vehicle communication and / or vehicle-to-X communication is integrated into the source code (10).

Images