EP4666149A1 - Verfahren zur nutzung von unbekannten neuen systemdiensten in einer fahrzeuganwendung - Google Patents

Verfahren zur nutzung von unbekannten neuen systemdiensten in einer fahrzeuganwendung

Info

Publication number
EP4666149A1
EP4666149A1 EP24817283.5A EP24817283A EP4666149A1 EP 4666149 A1 EP4666149 A1 EP 4666149A1 EP 24817283 A EP24817283 A EP 24817283A EP 4666149 A1 EP4666149 A1 EP 4666149A1
Authority
EP
European Patent Office
Prior art keywords
vehicle
services
service request
system services
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24817283.5A
Other languages
English (en)
French (fr)
Inventor
Robin D. Pesl
Kevin Klein
Marco Aiello
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Universitaet Stuttgart
Mercedes Benz Group AG
Original Assignee
Universitaet Stuttgart
Mercedes Benz Group AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Universitaet Stuttgart, Mercedes Benz Group AG filed Critical Universitaet Stuttgart
Publication of EP4666149A1 publication Critical patent/EP4666149A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45508—Runtime interpretation or emulation, e g. emulator loops, bytecode interpretation

Definitions

  • 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.
  • system services to which requests are submitted are becoming increasingly important. Such a request or service request is a task that is solved through the use of one system service or the combination of several system services.
  • the system services used for this can, in particular, be 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 information 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.
  • CN 117 709 352 A describes a method for preventing the output of potentially falsified information from a large language model.
  • 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.
  • 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 include system services that 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 for resolving current service requests during its runtime, without the vehicle application having to be adapted accordingly.
  • the method according to the invention thus allows for the resolution or processing of current complex service requests also use system services that only became known or were created after the design time of the vehicle application, which can be accessed via changed addresses or whose input and/or output parameters have been changed since the design time of the vehicle application.
  • 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.
  • 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.
  • a server preferably includes graphics cards or AI accelerators.
  • 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.
  • 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.
  • 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.
  • the source code generated in this way 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.
  • the method according to the invention thus makes it possible to provide the vehicle application with an executable program code for the service request, with which it can request current new system services which were not known at the time of design of the vehicle application, and whose address and/or whose input and/or response parameters have changed since then:
  • the vehicle application is thus able to use current new system services without an update being necessary. This eliminates the need for a general redesign of the vehicle application. This also eliminates the need to update the vehicle applications of individual or all vehicles in the field, resulting in significant resource savings.
  • an advantageous refinement 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.
  • 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.
  • 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.
  • 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.
  • models are 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.
  • special large language models such specially trained variants can also be used.
  • These can also be so-called small language models, natural language processing models, machine learning models, or other small models that may offer the advantage of a simpler architecture and/or smaller size.
  • the interpreter or compiler used to convert source code, such as Python code, into executable program code can, in principle, be present in the vehicle or implemented as part of the vehicle application or part of the system on which the vehicle application is running. However, to avoid having to provide such an environment in which, for example, Python code can be executed, it would also be conceivable, in principle, 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.
  • 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 order of the system services in order to know their programming interfaces or their current status.
  • the loading of the corresponding documentation can in principle take place from the network or from a corresponding storage.
  • services that are used frequently have their documentation temporarily stored, so that, for example, this documentation is already available on the backend server of the vehicle manufacturer, which can be used as a vehicle-external server.
  • a system service is used for the first time or has not been used for a longer period of time, so that the stored information on the server If the service is no longer available, this information can also be loaded from the network.
  • it would be conceivable to store it using a first-in, first-out system so that the documentation of 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.
  • the source code generated using the base model is subjected to an analysis before being transmitted to the vehicle application.
  • 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.
  • the analysis may 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, in order to clarify the extent to which this malicious or safety-critical code has entered the system. If this code has entered the system as part of a service request, it is sufficient to modify the service request accordingly. However, it could also be that the system or parts of the system have been hacked to inject this malicious or security-critical code, so that the warning can be used to react accordingly.
  • 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.
  • the source code 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.
  • 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.
  • 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 network-based services or include such services, whereby 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 frequently arise, i.e. that some of the system services are provided by the vehicle manufacturer or a fleet operator, and the other required services are requested from the network.
  • the computing system checks or filters the services under vehicle-related security aspects.
  • 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.
  • a further very advantageous embodiment of the method according to the invention can provide that a vehicle-to-vehicle communication and/or a vehicle-to-X communication is integrated into the source code.
  • vehicle-to-vehicle communication or the communication between a vehicle and other elements such as stationary components, is highly relevant for future vehicle applications. This can be used, for example, to exchange safety-relevant aspects; a vehicle can warn another vehicle of hazards 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 certain amount of time before switching, may 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 in order to enable efficient use of such aspects without the need for 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.
  • Figure 1 shows a schematic system architecture to illustrate the state of the art and the associated problems
  • Figure 2 shows a schematic representation of the quantities to illustrate the existing and used system services
  • Figure 3 shows a solution explained by 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 which can be used to solve or contribute to solving 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.
  • the call of the The system services S21 - S2n used from the set U of the 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.
  • 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.
  • new system services S31 - S3n or system services S31 - S3n that 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 simply referred to below as new system services S31 - S3n, are illustrated in a set N indicated in Figure 2.
  • the new system services S31 - S3n lie in a range of the set N that contains at least one new system service that is not contained in U. Purely by way of 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 or modification of the vehicle application 3 is necessary, which must then be rolled out to the individual vehicles 1, for example via OTA updates, which is complex.
  • 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. Rather, 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.
  • 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.
  • 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.
  • 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.
  • 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 are also defined or implemented. Finally, the result is converted into the target schema of the response variables for the vehicle application 3.
  • 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'.
  • a corresponding service request can now be made for each vehicle application 3 at any time, without requiring an update of this vehicle application 3, taking into account the current new system services S31 - S3n and their current formats of their input and output parameters 1/0-1 - 1/On.
  • all or some of the original system services S11 - S1n can also continue to be used.
  • these form their own new system services, for example, by converting S14 into the new system service S34.
  • a complex service composition is solved here with the help of the basic model FM in the computing system 6 and a suitable code 10, 10' is generated here with the help of the large language model LLM and transmitted to the vehicle application 3, which then executes the service request automatically.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung betrifft Verfahren zur Nutzung von zum Designzeitpunkt einer Fahrzeuganwendung (3), für diese unbekannte neue Systemdienste (S31,...,S3n) zur Lösung einer Serviceanfrage. Dazu wird eine Serviceanfrage formuliert, welche zusammen mit keiner oder wenigstens einer Eingangsgröße für die Systemdienste (S31,...,S3n), einer Definition des Formats dieser Eingangsgröße und einer Definition der erwarteten Antwortgröße an ein Rechensystem (6) übermittelt wird. Unter Zuhilfenahme eines Basismodells (FM) werden dort: a) die zu der Serviceanfrage (5) passenden Systemdienste (S41,...,S4n) und die zu der Serviceanfrage (5) passende Reihenfolge dieser Systemdienste (S41,...,S4n) festgelegt, b) die wenigstens eine Eingangsgröße - wenn vorhanden - in ein zu den Eingabeparametern des wenigstens einen ersten Systemdienstes (S41,...,S4n) passendes Parameterformat gebracht, c) eine Konvertierung der von dem oder den Systemdiensten (S41,...,S4n) zu erwartenden Ausgangsparameter in die Antwortgrößen festgelegt. Das Ergebnis wird zu einem Quellcode (10) zusammengestellt, welcher zur Durchführung der Serviceanfrage an die Fahrzeuganwendung (3) übermittelt wird. Diese führt die Serviceanfrage (5) dann unter Nutzung des Quellcodes (10) durch.

Description

Verfahren zur Nutzung von unbekannten neuen System diensten in einer Fahrzeuganwendung
Die Erfindung betrifft ein Verfahren zur Nutzung von unbekannten neuen Systemdiensten in einer Fahrzeuganwendung, welche zumindest einige der Systemdienste und/oder deren Eingangs- und/oder Antwortparameter nicht bekannt sind.
In der heutigen Zeit werden Systemdienste, an welche Anfragen übermittelt werden, immer wichtiger. Eine solche Anfrage bzw. Serviceanfrage ist dabei eine Aufgabe, die durch die Verwendung eines Systemdiensts oder der Kombination mehrerer Systemdienste gelöst wird. Die dafür genutzten Systemdienste können insbesondere netzbasierte Systemdienste sein, welche von verschiedenen Diensteanbietern in lokalen, ganz oder teilweise privaten Netzwerken oder auch im Internet bereitgestellt werden. Mischformen der Netzwerke sind dabei denkbar. Diese Systemdienste können verschiedene Dienste umfassen, beispielsweise Verkehrsdienste, Wetterdienste, Navigationsdienstleistungen, die Buchung von Parkraum, die Übermittlung von Informationen an ein anfragendes System bzw. eine durch dieses System mittelbar anfragende Person und dergleichen. Hierbei ist eine Vielzahl von verschiedenen Diensten denkbar. In der Praxis ist es so, dass die Anzahl der zur Verfügung stehenden Dienste sich ebenso ändert wie die von diesen Systemdiensten gelieferten Inhalte. Dabei können verschiedene Systemdienste unterschiedliche Eingangs-Parameter haben oder auf diese auch verzichten und liefern typischerweise immer (unterschiedliche) Ausgangs-Parameter. Die Problematik besteht nun, und dies gilt speziell bei einer Fahrzeuganwendung, darin, dass diese Systemdienste zum Zeitpunkt, zu welchem die Fahrzeuganwendung entwickelt worden ist, bereits bekannt sein müssen, um so innerhalb der Fahrzeuganwendung über die geeigneten Parameter die geeigneten Systemdienste anfragen zu können. In der Praxis ist dies problematisch, weil damit nur Dienste genutzt werden können, die zum Design-Zeitpunkt der Fahrzeuganwendung bekannt waren und auch nur mit den zu diesem Zeitpunkt bekannten Schnittstellenparametern. Ändert sich nun der Dienst, wird durch einen (oder mehrere) neue Dienste ersetzt oder verändert dieser seine Schnittstellenparameter, kann er durch die Fahrzeuganwendung nicht mehr genutzt werden. In der Praxis führt dies dazu, dass eine Neuprogrammierung der Fahrzeuganwendung erfolgen muss, wenn sich nur einer der benötigten Dienste ändert, oder weil von einem Dienst auf einen anderen gewechselt werden soll, beispielsweise zur Kostenoptimierung, zur Optimierung der Funktionalität oder ähnliches.
Durch die Vielzahl von Fahrzeugen mit integrierten Fahrzeuganwendungen ist es dabei außerordentlich aufwändig ein solches programmiertes Update über die Werkstätten oder als Over-The-Air- Update (OTA-Update) an alle Fahrzeuge zu verteilen. Dies ist mit einem sehr hohen Kostenaufwand verbunden und führt zu einer langen Übergangszeit, beispielsweise vom Wegfall eines benötigten Services bis zu dem Zeitpunkt, an dem die Fahrzeuganwendung neu programmiert und das entsprechende Update an alle Fahrzeuge ausgeliefert ist. Diese Übergangszeit kann je nach Komplexität der Veränderungen ein recht langer Zeitraum sein. Schlimmstenfalls steht in diesem Zeitraum ein für die das Fahrzeug nutzenden Personen relevanter Systemdienst nicht oder nur sehr eingeschränkt zur Verfügung.
Prinzipiell ist es aus dem Stand der Technik bekannt, dass die Zusammenstellung von verschiedenen Systemdiensten bzw. Services, welche zusammen eine Serviceanfrage lösen, über sogenannte Large Language Models gelöst werden können. Die Zusammenstellung der entsprechenden Systemdienste wird dabei als Service-Composition bezeichnet. In diesem Zusammenhang kann auf den Artikel Pesl, R.D., 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 hingewiesen werden. Das Large Language Model stelle dabei einen Spezialfall eines sogenannten Basismodells dar, welches auch mit dem englischen Begriff Foundation Model bezeichnet wird.
Zum weiteren Stand der Technik kann ferner auf die CN 117 709 352 A verwiesen werden, welche ein Verfahren beschreibt, um eine Ausgabe mit potenziell gefälschte Informationen aus einem Large Language Modell zu verhindern.
Die Aufgabe der hier vorliegenden Erfindung besteht nun darin die Nutzung von netzbasierten Servicediensten in einer Fahrzeuganwendung zu verbessern, indem ein technisches Verfahren zur automatisierten Service-Integration zur Laufzeit angegeben wird, so dass nicht mit jeder Änderung/Abwandlung eines benötigten Systemdienstes ein Update der Fahrzeuganwendung erfolgen muss.
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merkmalen im Anspruch 1 gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen des erfindungsgemäßen Verfahrens ergeben sich aus den hiervon abhängigen Unteransprüchen.
Das erfindungsgemäße Verfahren dient zur Nutzung von netzbasierten unbekannten neuen Systemdiensten in einer Fahrzeuganwendung, welcher zumindest einige der neuen Systemdienste und/oder deren Eingangs- und/oder Antwortparameter nicht bekannt sind. Die „neuen“ Systemdienste im Sinne der Erfindung umfassen dabei auch Systemdienste, welche verändert worden sind, deren Adresse sich geändert hat und/oder deren Eingabe- und/oder Ausgangsparameter I/O-1 - l/O-n sich verändert haben. Es bietet dabei die Möglichkeit, die neuen Systemdienste zur Lösung aktueller Serviceanfragen während der Laufzeit der Fahrzeuganwendung in diese zu integrieren, ohne dass die Fahrzeuganwendung dazu angepasst werden muss. Über das erfindungsgemäße Verfahren lassen sich so zur Lösung bzw. Abarbeitung aktueller komplexer Serviceanfragen auch Systemdienste nutzen, die erst nach dem Designzeitpunkt der Fahrzeuganwendung bekannt geworden bzw. entstanden sind, welche über geänderte Adressen ansprechbar sind oder deren Eingangs- und/oder Ausgabeparameter seit dem Designzeitpunkt der Fahrzeuganwendung verändert wurden.
Gemäß der Erfindung wird dazu eine Serviceanfrage formuliert, welche an ein Rechensystem übermittelt wird. Das Rechensystem kann dabei in das Fahrzeug integriert sein oder es kann gemäß einer vorteilhaften Ausgestaltung der Erfindung ganz oder teilweise als fahrzeugexternes Rechensystem ausgebildet und über eine Kommunikationsverbindung an das Fahrzeug angebunden sein.
Das Rechensystem bildet hier also ein Tool zur Durchführung des erfindungsgemäßen Verfahrens aus oder hat ein solches implementiert. Es kann bevorzugt zumindest teilweise in einen fahrzeugexternen Server und/oder einen Cloudserver ausgelagert sein, um dort die benötigten Rechenleistungen einfach zur Verfügung stellen zu können. Vorzugsweise umfasst eine solcher Server Grafikkarten oder Kl-Beschleuniger. Insbesondere kann es sich bei dem Server um einen Backend-Server des Fahrzeugherstellers handeln, welcher in den meisten Fällen ohnehin verfügbar bzw. vorhanden ist und mit dem Fahrzeug in einer Kommunikationsverbindung steht.
In diesem Rechensystem werden nun, unter Zuhilfenahme eines Basismodells (Foundation Model): a) die zu der Serviceanfrage passenden verwendeten Systemdienste und die zu der Serviceanfrage passende Reihenfolge dieser verwendeten Systemdienste festgelegt; b) wenn mehrere verwendete Systemdienste nacheinander genutzt werden, die Ausgangsparameter des jeweils vorhergehenden verwendeten Systemdienstes in ein zu den Eingabeparametern des nachfolgenden verwendeten System dienstes passendes Parameterformat transformiert; und c) eine Konvertierung der von dem oder den verwendeten Systemdiensten zu erwartenden Ausgangsparameter in ein für die Fahrzeuganwendung geeignetes Format festgelegt.
Damit steht also ein Lösungskonzept für die Serviceanfrage fest, welches nun mit Hilfe des Basismodells, wie z.B. eines Large Language Models, zu einem Quellcode, z.B. in Python, zusammengestellt wird. Dieser Quellcode löst damit die aktuelle Serviceanfrage unter Nutzung von dafür geeigneten neuen Systemdiensten und konvertiert alle Eingangsgrößen, Eingabeparameter, Ausgangsparameter und Antwortgrößen, letztlich also die Programmierschnittstellen bzw. APIs (Application Programming Interfaces), in der erforderlichen Art ineinander.
Dieser Quellcode wird dabei zwar anhand der von der Fahrzeuganwendung übermittelten Serviceanfrage generiert, diese Generierung erfolgt jedoch komplett unabhängig von der Fahrzeuganwendung und ist damit auch von deren Designzeitpunkt, ihrer Softwareversion, etc. unabhängig.
Der so erzeugte Quellcode wird dann zur Durchführung der Serviceanfrage an die Fahrzeuganwendung übermittelt. Dabei wird der Quellcode über einen Compiler/Interpreter in ausführbaren Programmcode umgewandelt, welcher von der Fahrzeuganwendung ausgeführt wird, um die Serviceanfrage durchzuführen bzw. zu lösen.
Das erfindungsgemäße Verfahren ermöglicht es so, der Fahrzeuganwendung einen ausführbaren Programmcode für die Serviceanfrage zur Verfügung zu stellen, mit welchem sie aktuelle neue Systemdienste anfragen kann, welche zum Designzeitpunkt der Fahrzeuganwendung nicht bekannt waren, deren Adresse und/oder deren Eingangs- und/oder Antwortparameter sich seither verändert haben: Die Fahrzeuganwendung ist somit in der Lage aktuelle neue Systemdienste zu nutzen, ohne dass hierfür ein Update notwendig geworden ist. Damit ist nun also kein generelles Re-Design der Fahrzeuganwendung mehr nötig. Somit müssen auch nicht die Fahrzeuganwendungen einzelner oder aller im Feld befindlichen Fahrzeuge ein Update erhalten, was zu einer großen Einsparung an Ressourcen führt.
Auch wenn natürlich Serviceanfragen ohne eine eigene Eingangsgröße grundlegend denkbar sind, wie z.B. eine gebündelte Abfrage nach Fehlern aus verschiedenen Fehlerspeichern, über ein Einfaches „liegen Fehler vor?“, wird die Serviceanfrage häufig mit Eingangsgrößen, wie z.B. einer Positionsangabe oder ähnlichem, erfolgen. Dafür sieht es eine vorteilhafte Weiterbildung dann vor, dass Eingangsgröße für die Systemdienste und eine Definition des Formats dieser Eingangsgröße zusammen mit der Serviceanfrage übermittelt wird. Im Schritt b) erfolgt dann in jedem Fall eine Transformation der wenigstens einen Eingangsgröße in ein zu den Eingabeparametern des wenigstens einen ersten verwendeten System dienstes passendes Parameterformat.
Bezüglich der Konvertierung der Antwort in kann es gemäß einer sehr günstigen Ausgestaltung vorgesehen werden, dass die Serviceanfrage zusammen mit einer Definition der erwarteten Antwortgrößen an das Rechensystem übermittelt wird, um dann im Schritt c) eine Konvertierung der von dem oder den verwendeten Systemdiensten erwartenden Ausgangsparameter in die Antwortgrößen für die Fahrzeuganwendung festzulegen wird.
Eine sehr günstige Weiterbildung der Erfindung sieht es dabei vor, dass als Basismodell ein Large Language Model, ein mit passenden Daten trainiertes weitertrainiertes Modell oder ein nur zum Zwecke des erfindungsgemäßen Verfahrens erstelltes Modell dient. Solche Modelle sind dann streng genommen keine Large Language Models mehr, da diese definitionsgemäß als „general purpose“ Modelle ausgebildet sind. Die speziell erstellten und/oder trainierten Modelle können dabei bessere Ergebnisse liefern. Es können also neben allgemeinen Large Language Models auch solche speziell trainierten Varianten Verwendung finden. Es kann sich hierbei z.B. auch um sogenannte Small Language Models, Sprachverarbeitungsmodelle, Modelle des maschinellen Lernens oder andere Kl-Modelle handeln, die ggf. den Vorteil einer einfacheren Architektur und/oder kleineren Größe bieten.
Der Interpreter bzw. Compiler mit dem der Quellcode, beispielsweise ein Python- Code, in einen ausführbaren Programmcode umwandelt wird, kann hierfür prinzipiell in dem Fahrzeug vorhanden sein bzw. als Teil der Fahrzeuganwendung oder Teil desjenigen Systems, auf dem die Fahrzeuganwendung läuft, ausgeführt sein. Um eine solche Umgebung, in welcher z.B. der Python-Code ausgeführt werden kann, nicht mit anbieten zu müssen, wäre es jedoch prinzipiell auch denkbar, den Interpreter bzw. Compiler auf dem Rechensystem vorzusehen, sodass nicht der Quellcode, sondern der ausführbare Programmcode an die Fahrzeuganwendung geliefert wird. Um jedoch die Gefahr des Einschleusens von potenziell sicherheitskritischem Code in die Fahrzeuganwendung zu unterbinden wäre die erste Variante, bei welcher der Programmcode innerhalb des Fahrzeugs interpretiert bzw. kompiliert wird, zu bevorzugen.
Gemäß zweier vorteilhafte Weiterbildung des erfindungsgemäßen Verfahrens können dabei entweder vor oder alternativ hierzu nach der Auswahl und vor der Festlegung der Reihenfolge der Systemdienste Dokumentation der Systemdienste und Ihrer Eingangs- und Ausgangsparameter geladen werden, um deren Programmierschnittstellen bzw. deren aktuellen Stand zu kennen. Das Laden der entsprechenden Dokumentationen kann dabei prinzipiell aus dem Netzwerk erfolgen oder auch aus einem entsprechenden Speicher. In der Praxis wird es häufig so sein, dass Dienste, die häufig verwendet werden, bezüglich ihrer Dokumentation zwischengespeichert werden, sodass also beispielsweise auf dem Backend-Server des Fahrzeugherstellers, welcher als fahrzeugexterner Server verwendet werden kann, diese Dokumentationen bereits verfügbar sind. Wird ein Systemdienst zum ersten Mal genutzt oder ist er über eine längere Zeit nicht genutzt worden, sodass die gespeicherten Informationen auf dem Server nicht mehr vorhanden sein, dann können diese Informationen auch aus dem Netzwerk geladen werden. Prinzipiell wäre es hier denkbar die Speicherung über ein First In-First Out-System vorzunehmen, um so immer die Dokumentationen einer vorgegebenen Anzahl an zuletzt genutzter Systemdienste in dem Server verfügbar zu haben, sodass diese geladen werden können, ohne sie aus dem Internet beziehen zu müssen.
Grundsätzlich ist es gemäß einer vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens dabei vorgesehen, dass der mittels des Basismodells erzeugte Quellcode vor dem Übermitteln an die Fahrzeuganwendung einer Analyse unterzogen wird. Eine solche Analyse über einen Analyzer ist bei der Erstellung von Programmcode prinzipiell gängig. Dabei können verschiedene Aspekte im Mittelpunkt der Analyse stehen, beispielsweise das Auffinden von Programmierfehlern, oder auch das Auffinden von Fehlern bezüglich der zu lösenden Aufgabe, also der korrekten Antwort auf die gestellte Serviceanfrage.
Zum reinen Auffinden von Fehlern oder sicherheitskritischem Code kann es dementsprechend gemäß einer vorteilhaften Weiterbildung vorgesehen sein, dass die Analyse als statische und/oder dynamische Code-Analyse durchgeführt wird. Wird bei einer solchen statischen und/oder der Testung in Form einer dynamischen Code-Analyse fehlerhafter Code gefunden, kann die Erzeugung des Quellcodes, zumindest partiell, erneut initiiert werden. Wird dahingegen bösartiger oder sicherheitskritischer Code erkannt, was bei Fahrzeuganwendungen prinzipiell zu enormen Sicherheitsproblemen führen könnte, wird der Quellcode verworfen, neu erzeugt oder an den entsprechenden Stellen verbessert. In diesem Fall kann eine entsprechende Warnung beispielsweise an einen den Server betreibenden Fahrzeughersteller ergehen, um zu klären, inwieweit dieser bösartige oder sicherheitskritische Code in das System gekommen ist. Ist dieser im Rahmen einer Serviceanfrage in das System gekommen, reicht es aus, die Serviceanfrage entsprechend zu verändern. Es könnte jedoch auch sein, dass das System oder Teile des Systems gehackt worden sind, um diesen bösartigen oder sicherheitskritischen Code einzuschleusen, sodass hier aufgrund der Warnung entsprechend reagiert werden kann.
Die statische und/oder dynamische Codeanalyse kann dabei durch ein klassisches (Computer-)Programm zur Codeanalyse, dem ursprünglichen Basismodell oder mit einem alternativen, von dem für die Erzeugung des Quellcodes abweichenden Modell erfolgen, um so möglichst viele Fehler erkennen und korrigieren zu können. Das alternative Modell bietet dabei die Chance auch durch das Basismodell prinzipbedingt verursachte Fehler identifizieren zu können.
Prinzipiell ist es so, dass im Falle eines Fehlers, vorzugsweise dann, wenn dieser weder bösartig noch sicherheitskritisch ist, eine Anpassung des Quellcodes für die Serviceanfrage erfolgen kann. Die Interpretation der Serviceanfrage kann also verändert werden, um den Fehler zu beheben. Gemäß einer besonders günstigen Ausgestaltung des Verfahrens kann es dabei vorgesehen sein, dass die Fehleranalyse des Quellcodes und die daraufhin erfolgende Anpassung der Serviceanfrage immer wieder durchlaufen wird, und zwar so lange, bis entweder kein Fehler mehr erkannt werden kann oder die Anzahl von Fehlern auf einem Minimum verharrt. Zur Ermittlung derartiger Fehler lassen sich beispielsweise gängige Ähnlichkeitsanalysen einsetzen, oder es kann auch hier wieder ein Basismodell zum Einsatz kommen.
Im Endeffekt wird damit eine Art selbstlernendes System innerhalb des erfindungsgemäßen Verfahrens geschaffen, welches bei entsprechenden Serviceanfragen reagieren kann, um potenzielle Fehler auch in zukünftigen Serviceanfragen direkt abzufangen, indem die Interpretation der Serviceanfrage aufgrund der zurückliegenden Erfahrungen mit ähnlichen Serviceanfragen optimiert wird. Die Serviceanfrage selbst wird dabei gemäß einer sehr vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens als textuelle Beschreibung generiert, sodass also einfach auf der Basis von formellen Textkomponenten oder Fließtextkomponenten die entsprechenden Systemdienste genutzt werden können. Die textuelle Beschreibung kann dabei vorzugswese eine in natürlicher Sprache sein. Die Systemdienste können dabei netzwerkbasierte Services sein oder solche umfassen, wobei die Systemdienste selbstverständlich auch durch den Fahrzeughersteller, einen Flottenbetreiber oder ähnliches angeboten werden können. In der Realität ist davon auszugehen, dass häufig Mischvarianten auftreten werden, also dass ein Teil der Systemdienste durch den Fahrzeughersteller oder einen Flottenbetreiber zur Verfügung gestellt wird und die weiteren benötigten Dienste aus dem Netzwerk abgefragt werden.
Gemäß einer vorteilhaften Weiterbildung kann es dabei vorgesehen sein, dass in dem Rechensystem eine Überprüfung oder Filterung der Services unter fahrzeugbezogenen Sicherheitsaspekten erfolgt. Wie oben bereits erwähnt ist bei einem Fahrzeug die Sicherheit des fahrzeuginternen Computersystems von entscheidender Bedeutung, dies betrifft sowohl die Absicherung des Systems gegen einen unberechtigten Zugriff als auch die Sicherheit der vom System ausgeführten Funktionen, wie sicherheitsrelevante Entscheidungen und Steuerungen. Beispielsweise kann dies eine Umgebungsüberwachung beim assistierten oder automatisierten Fahren oder Ähnliches, umfassen. Aus diesem Grund ist es sicherlich sinnvoll hier entsprechende Systemdienste, welche unmittelbar in diese Ebenen des Fahrzeugsystems integriert werden, zu überprüfen und zu filtern, um so sicherstellen zu können, dass keine bösartigen Aspekte in das System eingeschleust werden.
Eine weitere sehr vorteilhafte Ausgestaltung des Verfahrens gemäß der Erfindung kann es dabei vorsehen, dass in den Quellcode eine Fahrzeug-zu-Fahrzeug Kommunikation und/oder eine Fahrzeug-zu-X Kommunikation integriert wird. Eine solche Fahrzeug-zu-Fahrzeug Kommunikation oder die Kommunikation eines Fahrzeugs zu anderen Elementen wie beispielsweise stationären Komponenten ist für zukünftige Fahrzeuganwendungen hochrelevant. Hiermit können beispielsweise sicherheitsrelevante Aspekte ausgetauscht werden, ein Fahrzeug kann ein anderes Fahrzeug davor warnen, dass im Bereich seiner Umfeldsensorik Gefahren auftauchen, welche für das andere Fahrzeug noch nicht einsehbar sind, und dergleichen. Auch Aspekte von stationären Elementen wie beispielsweise Ampeln, die ihren Schaltzustand an das Fahrzeug übermitteln und dem Fahrzeug eine entsprechende Zeitspanne vor dem Umschalten eine Nachricht hierüber zukommen lassen, können zunehmend relevant werden. Auch derartige Aspekte der Kommunikation, welche typischerweise eine Anfrage, das Aushandeln eines Kommunikationskanals und die eigentliche Kommunikation umfassen, können im Rahmen derartiger Systemdienste oder zur Ergänzung dieser Systemdienste in den Quellcode mit implementiert werden, um auch derartige Aspekte ohne erforderliche Updates der Fahrzeuganwendungen durch die Fahrzeuganwendungen effizient nutzen zu können. Eine Besonderheit solcher Anwendungsfälle ist, dass die Serviceanfrage individuell für den aktuellen Sachverhalt ist und daher gar nicht über eine vorherige Entwicklung während der Designzeit der Fahrzeuganwendung möglich ist.
Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens ergeben sich dabei auch anhand des Ausführungsbeispiels, welches nachfolgend unter Bezugnahme auf die Figuren näher beschrieben ist.
Dabei zeigen:
Figur 1 eine schematische Systemarchitektur zur Verdeutlichung des Standes der Technik und der damit verbundenen Probleme;
Figur 2 eine schematische Mengendarstellung zur Verdeutlichung der jeweils existierenden und genutzten Systemdienste; und
Figur 3 eine basierend auf der in Figur 1 dargestellten Skizze erläuterte Lösung durch das erfindungsgemäße Verfahren. In der Darstellung der Figur 1 ist sehr stark schematisiert ein Fahrzeug 1 angedeutet, in welchem eine mit 2 bezeichnete Plattform für Anwendungen, eine sogenannte In-Car App Platform vorhanden ist. Innerhalb dieser Plattform 2 sind dabei rein beispielhaft drei einzelne Fahrzeuganwendungen 3 gezeigt. Das System in der Darstellung links der gestrichelten Linie zeigt dabei, dass was innerhalb des Fahrzeugs 1 erfolgt. Über eine Kommunikationsverbindung 4 kann nun eine Serviceanfrage generiert und an verschiedene ursprüngliche Systemdienste S11 , S12-S1n versandt werden, was rechts der gestrichelten Linie im Bereich außerhalb des Fahrzeugs 1 , beispielsweise auf einem fahrzeugexternen Server, in der Cloud oder dergleichen dargestellt ist. Jeder dieser ursprünglichen Systemdienste S11 - S1 n stellt dabei einen Service dar, welcher zur Lösung oder zu einem Beitrag zu der Lösung Serviceanfrage genutzt werden kann. Jeder dieser ursprünglichen Systemdienste S11 - S1 n umfasst dabei ein eigenes Format seiner Eingabe- und Ausgangsparameter, was durch die mit 1/0-1 , I/0-2 und l/O-n bezeichneten Ovale entsprechend angedeutet ist. Selbstverständlich können sich dabei einzelne Eingabe- und/oder Ausgangsparameter auch entsprechen oder leer sein.
In diesem in Figur 1 gezeigten Ist-Zustand ist es so, dass für den Fall, dass ein oder mehrere externe ursprüngliche Systemdienste S11 - S1 n in eine der Fahrzeuganwendungen 3 eingebunden werden sollen. Zum Zeitpunkt der Entwicklung der Fahrzeuganwendung 3, also zu ihrem Designzeitunkt, muss der jeweilige ursprüngliche Systemdienst S11 - S1 n und eine Schnittstellenbeschreibung seiner Eingabe- und Ausgangsparameter 1/0-1 - l/O-n bekannt sein. Die Umwandlung der Daten in das von dem ursprünglichen Systemdienst S11 - S1 n erwartete Format muss, typischerweise manuell, implementiert werden. Figur 2 veranschaulicht die Menge U dieser ursprünglichen Systemdienste S11 - S1n. Aus dieser Menge U werden nun einige oder alle der ursprünglichen Systemdienste S11 - S1 n für die Serviceanfrage genutzt. Diese bilden die Teilmenge gU der genutzten Systemdienste S21 - S2n. Der Aufruf der aus der Menge U der ursprünglichen Systemdienste S11 - S1 n genutzten Systemdienste S21 - S2n muss in der richtigen Reihenfolge in die Fahrzeuganwendung 3 implementiert werden. Die Reihenfolge kann dabei sowohl eine sequentielle als auch eine parallele Abarbeitung der genutzten Systemdienste S21 - S2n umfassen. Auch Mischformen aus sequentieller und paralleler Abarbeitung sind hier möglich und kommen in der Praxis häufig vor. Neben der richtigen Reihenfolge muss ferner eine Umwandlung der Antwort aus den genutzten Systemdiensten S21 - S2n in eine für die Fahrzeuganwendung 3 oder die Weiterverarbeitung im nächsten Systemdienst S22-S2n+1 verständliche Form implementiert werden.
Damit ist eine dynamische Integration von neuen Systemdiensten S31 - S3n oder Systemdiensten S31 - S3n, welche verändert worden sind, deren Adresse sich geändert hat und/oder deren Eingabe- und/oder Ausgangsparameter 1/0-1 - l/O- n sich verändert haben, nicht möglich. Solche Systemdienste, welche nachfolgend vereinfachend als neue Systemdienste S31 - S3n bezeichnet werden, sind in einer in Figur 2 angedeuteten Menge N veranschaulicht. Die neuen Systemdienste S31 - S3n liegen dabei in einem Bereich der Menge N, welche mindestens einen neuen Systemdienst enthält, der nicht in U enthalten ist.. Rein bespielhaft sind die Mengen N und U in der Figur 2 als eigene sich nicht überlappende Mengen dargestellt. Die neuen Systemdienste S31 - S3n sind damit für die Fahrzeuganwendung 3 nicht nutzbar. Sollen sie dennoch genutzt werden, ist eine Neuentwicklung bzw. Änderungsentwicklung der Fahrzeuganwendung 3 notwendig, welche dann aufwändig beispielsweise über OTA-Updates an die einzelnen Fahrzeuge 1 ausgerollt werden muss.
Typischerweise kann es dabei zu einer Zeitspanne kommen, in welcher weder die ursprünglichen Systemdienste S11 - S1n, beispielsweise durch eine Adressänderung, noch die neuen Systemdienste S31 - S3n genutzt werden können. Dies ist entsprechend aufwändig, schwierig, teuer und für die Nutzerinnen und Nutzer des Fahrzeugs häufig nicht komfortabel, da gewohnte Serviceanfragen für gewisse Zeiträume nicht gelöst werden können oder schlimmstenfalls für das Einspielen des Updates ein Werkstattbesuch notwendig wird.
Dieser Problematik soll nun abgeholfen werden, indem eine Schnittstellenbeschreibung mit formellen und/oder Fließtextkomponenten von z.B. netzbasierten Services dazu genutzt werden kann, um in Verbindung mit einem Basismodell FM, hier nachfolgend z.B. mit einem Large Language Model einen Quellcode 10 zu generieren, der auch komplexe Serviceanfragen durch den Aufruf eines oder insbesondere mehrerer neuer Systemdienste S31 - S3n löst. In der Darstellung der Figur 3 ist diese Lösung dargestellt, wobei die in den Figuren 1 und 3 vorhandenen Komponenten und Elemente nicht nochmals im Detail beschrieben werden.
Im Wesentlichen ist es nun so, dass an die Stelle einer aufwändigen Implementierung des Aufrufs einzelner neuer Systemdienste S31 - S3n in die Fahrzeuganwendung 3, welche ein Update der Fahrzeuganwendung 3 erzwingen würde, die Serviceanfrage in Textform zusammen mit einem Schema der Eingangsgrößen und einem Soll-Schema für die von der Fahrzeuganwendung 3 erwarteten Antwortgrößen gemäß des Pfeils 5 aus dem Fahrzeug 1 übertragen wird. Die komplexe Anfrage wird also nicht direkt entsprechend der mit 4 bezeichneten Linie in der Darstellung der Figur 1 durchgeführt, da sie bei dem neuen Konzept nicht mehr in der Fahrzeuganwendung 3 programmiert ist. Vielmehr wird sie stattdessen über den Pfeil 5 an ein Rechensystem 6, insbesondere ein fahrzeugexternes Rechensystem wie beispielsweise einen Cloudserver oder dem Backend-Server eines Fahrzeugherstellers, übertragen. Dem Rechensystem 6 stehen dabei zusätzlich die Dokumentationen der verfügbaren neuen Systemdienste S31 - S3n, welche im einfachsten Fall eine Auflistung dieser Systemdienste sein kann, und insbesondere die Schnittstellenbeschreibung der Eingabe- und Ausgangsparameter 1/0-1 - l/O-n dieser Systemdienste S31 - S3n zur Verfügung. Dies ist durch die strichpunktierten Pfeile 7 bzw. 8 entsprechend angedeutet. Innerhalb dieses Rechensystems 6 wird nun basierend auf den vorliegenden Informationen und unter Zuhilfenahme des Basismodells FM ein Quellcode 10 generiert, der die Aufgabenstellung der Serviceanfrage unter Zuhilfenahme eines oder mehrerer der neuen Systemdienste S31 - S3n löst. Dazu wird analog zur Darstellung in Figur 2 links nun eine Teilmenge vN der dafür verwendeten Systemdienste S41 - S4n herangezogen. Dabei werden auch die Aufrufe, die Reihenfolge der Aufrufe sowie die Umwandlung der jeweiligen Antworten in die Eingabeformate der hiervon abhängigen Systemdienste S42 - S4n festgelegt bzw. implementiert. Am Ende wird das Ergebnis in das Soll-Schema der Antwortgrößen für die Fahrzeuganwendung 3 umgewandelt.
Ein solcher all dies umfassender Quellcode 10 kann nun, vorzugsweise nachdem er eine entsprechende Analyse bzw. Filterung nach potenziellen Fehlern, Schadcode etc. durchlaufen hat, entsprechend des mit 9 bezeichneten Pfeils an die Fahrzeuganwendung 3 geliefert werden. Dies kann beispielsweise in Form eines Python-Codes erfolgen, welchen die Fahrzeuganwendung 3 dann selbstständig ausführen kann. Alternativ dazu erfolgt eine Interpretation bzw. Kompilierung erfolgt bereits in dem Rechensystem 6, sodass der Fahrzeuganwendung 3 ein ausführbarer Programmcode 10‘ geliefert wird. Die Serviceanfrage kann von der Fahrzeuganwendung 3 dann durch die Ausführung dieses Codes 10, 10‘ selbsttätig ausgeführt werden.
Über dieses Verfahren lässt sich nun also für jede Fahrzeuganwendung 3 zu jedem beliebigen Zeitpunkt, ohne dass ein Update dieser Fahrzeuganwendung 3 erfolgen muss, eine entsprechende Serviceanfrage unter Einbeziehung der aktuellen neuen Systemdienste S31 - S3n und deren aktueller Formate ihrer Eingabe- und Ausgangsparameter 1/0-1 - l/O-n durchführen. Selbstverständlich können hier auch alle oder einige der ursprünglichen Systemdienste S11 - S1 n weiterhin mitverwendet werden. Vorzugsweise bilden diese dabei eigene neue Systemdienste aus z.B. indem aus S14 der neue Systemdienst S34 wird. Die die komplexe Servicekomposition wird hier mit Hilfe des Basismodells FM in dem Rechensystem 6 gelöst und ein geeigneter Code 10, 10‘ wird hier unter Zuhilfenahme des Large Language Modells LLM generiert und an die Fahrzeuganwendung 3 übermittelt, welche dann die Serviceanfrage damit selbsttätig ausführt.

Claims

Patentansprüche
1 . Verfahren zur Nutzung von unbekannten neuen Systemdiensten
(S31 ,...,S3n) in einer Fahrzeuganwendung (3), wobei zumindest einer der neuen Systemdienste (S31 ,...,S3n) und/oder deren Eingangs- und/oder Ausgangsparameter (1/0-1 .,l/O-n) zum Entwicklungszeitpunkt der Fahrzeuganwendung (3) nicht bekannt waren, wozu eine Serviceanfrage formuliert wird, welche an ein Rechensystem (6) übermittelt wird, wonach in dem Rechensystem (6) unter Zuhilfenahme eines Basismodells (FM) a) die zu der Serviceanfrage passenden verwendeten Systemdienste (S41 ,...,S4n) und die zu der Serviceanfrage passende Reihenfolge dieser verwendeten Systemdienste (S41 ,...,S4n) festgelegt wird, wonach b) wenn mehrere verwendete Systemdienste (S41 ,...,S4n) nacheinander genutzt werden, die Ausgangsparameter des jeweils vorhergehenden verwendeten Systemdienstes (S41 ,...,S4n-1) in ein zu den Eingabeparametern des nachfolgenden verwendeten Systemdienstes (S42,...,S4n) passendes Parameterformat gebracht werden, und wonach c) eine Konvertierung der von dem oder den verwendeten Systemdiensten (S41 ,...,S4n) zu erwartenden Ausgangsparameter für die Fahrzeuganwendung (3) festgelegt wird, wobei das Ergebnis der Schritte a), b) und c) zu einem Quellcode (10) zusammengestellt wird, welcher zur Durchführung der Serviceanfrage an die Fahrzeuganwendung (3) übermittelt wird, wobei der Quellcode (10) über einen Compiler/Interpreter in ausführbaren Programmcode (10‘) umgewandelt wird, welcher von der Fahrzeuganwendung (3) ausgeführt wird, um die Serviceanfrage durchzuführen.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass die Serviceanfrage zusammen mit wenigstens einer Eingangsgröße für die Systemdienste (S31 ,...,S3n) und einer Definition des Formats dieser Eingangsgröße an das Rechensystem (6) übermittelt wird, wobei im Schritt b) die wenigstens eine Eingangsgröße in ein zu den Eingabeparametern des wenigstens einen ersten Systemdienstes verwendeten (S41 ,...,S4n) passendes Parameterformat gebracht wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Serviceanfrage zusammen mit einer Definition der erwarteten Antwortgrößen an das Rechensystem (6) übermittelt wird, wobei im Schritt c) eine Konvertierung der von dem oder den verwendeten Systemdiensten (S41 ,...,S4n) zu erwartenden Ausgangsparameter in die Antwortgrößen festgelegt wird.
4. Verfahren nach Anspruch 1 , 2 oder 3, dadurch gekennzeichnet, dass als Basismodell ein Large Language Model (FM), ein mit passenden Daten trainiertes oder weitertrainiertes Modell oder ein speziell erstelltes Modell verwendet wird.
5. Verfahren nach nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Rechensystem (6) ganz oder teilweise als fahrzeugexternes Rechensystem (6) ausgebildet und über eine Kommunikationsverbindung an das Fahrzeug (1) angebunden ist.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Interpretation/Kompilierung innerhalb des Fahrzeugs (1) erfolgt.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass vor der Auswahl und vor der Festlegung der Reihenfolge der verwendeten Systemdienste (S41 ,...,S4n) eine Dokumentation zumindest der verwendeten Systemdienste (S41 ,...,S4n) und/oder Ihrer Eingangsund Ausgangsparameter (1/0-1 ,...,l/O-n) geladen oder an das Rechensystem (6) übermittelt werden.
8. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass vor der Auswahl und vor der Festlegung der Reihenfolge der verwendeten Systemdienste (S41 ,...,S4n) eine Dokumentation zumindest der verwendeten Systemdienste (S41 ,...,S4n) und/oder Ihrer Eingangsund Ausgangsparameter (1/0-1 .,l/O-n) geladen oder an das Rechensystem (6) übermittelt werden.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der mittels des Basismodells (FM) erzeugte Quellcode (10) oder der ausführbare Programmciode (1O‘)einer Analyse unterzogen wird.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Analyse als statische und/oder dynamische Code-Analyse durchgeführt wird.
11 . Verfahren nach Anspruch 9 oder 10, dadurch gekennzeichnet, dass die Analyse mit einem vom Basismodell (FM) abweichenden Modell durchgeführt wird.
12. Verfahren nach Anspruch 9, 10 oder 11 , dadurch gekennzeichnet, dass im Falle von erkannten Syntaxfehleren, bösartigen oder sicherheitskritischen Bestandteilen der erzeugte Quellcode (10) nachgebessert oder verworfen wird.
13. Verfahren nach einem der Ansprüche 9 bis 12, dadurch gekennzeichnet, dass im Falle eines Fehlers eine Anpassung der Serviceanfrage erfolgt.
14. Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass die Fehleranalyse des Quellcodes (10) und die daraufhin erfolgende Anpassung der Serviceanfrage so lange wiederholt wird, bis keine Fehler mehr erkannt werden können oder deren Anzahl auf einem Minimum verharrt.
15. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Serviceanfrage als textuelle Beschreibung generiert wird.
16. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die neuen Systemdienste (S31 ,...,S3n) Web-
Services sind oder solche umfassen, wobei in dem Rechensystem eine Überprüfung oder Filterung der Web-Services unter fahrzeugbezogenen Sicherheitsaspekten erfolgt.
17. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in den Quellcode (10) eine Fahrzeug-zu-Fahrzeug Kommunikation und/oder eine Fahrzeug-zu-X Kommunikation integriert wird.
EP24817283.5A 2024-03-21 2024-11-29 Verfahren zur nutzung von unbekannten neuen systemdiensten in einer fahrzeuganwendung Pending EP4666149A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102024108126.0A DE102024108126A1 (de) 2024-03-21 2024-03-21 Verfahren zur Nutzung von unbekannten neuen Systemdiensten in einer Fahrzeuganwendung
PCT/EP2024/084027 WO2025195624A1 (de) 2024-03-21 2024-11-29 Verfahren zur nutzung von unbekannten neuen systemdiensten in einer fahrzeuganwendung

Publications (1)

Publication Number Publication Date
EP4666149A1 true EP4666149A1 (de) 2025-12-24

Family

ID=90923329

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24817283.5A Pending EP4666149A1 (de) 2024-03-21 2024-11-29 Verfahren zur nutzung von unbekannten neuen systemdiensten in einer fahrzeuganwendung

Country Status (3)

Country Link
EP (1) EP4666149A1 (de)
DE (1) DE102024108126A1 (de)
WO (1) WO2025195624A1 (de)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117709352A (zh) 2023-12-13 2024-03-15 维沃移动通信有限公司 信息处理方法、信息处理装置和电子设备

Also Published As

Publication number Publication date
WO2025195624A1 (de) 2025-09-25
DE102024108126A1 (de) 2024-05-23

Similar Documents

Publication Publication Date Title
EP3217236B1 (de) Verfahren und system zur generierung eines bedienprogramms in form einer auf einem mobilen gerät lauffähigen mobilen applikation
DE10260250A1 (de) Hilfesystem, Automatisierungsvorrichtung mit einem Hilfesystem sowie Verfahren zum Bereitstellen von Hilfedaten
EP3076633A1 (de) Verfahren zur konfiguration eines webservice-gateways sowie webservice-gateway
WO2004104836A2 (de) Telediagnose-viewer
EP4160390B1 (de) Verfahren und anordnung zur inbetriebnahme einer aktualisierten anwendung für eine industrielle automatisierungsanordnung
EP4412183B1 (de) Verfahren und system zum transformieren aufgezeichneter kommunikations-daten
EP3977668B1 (de) System zur erzeugung von kryptografischem material
DE102010044039A1 (de) Verfahren und Vorrichtung zur Qualitätsanalyse von Systemmodellen
EP4666149A1 (de) Verfahren zur nutzung von unbekannten neuen systemdiensten in einer fahrzeuganwendung
DE102008059197A1 (de) Verfahren und Vorrichtung zur verteilten Konfiguration von Telematik-Diensten in Kraftfahrzeug-Systemen
AT526816B1 (de) Verfahren zum Adaptieren von Testfällen für eine Sicherheitsüberprüfung
DE202012013449U1 (de) System für In-Line-Einfügung von Scriptabhängigkeiten
DE102018216036A1 (de) Verfahren zum Ausführen einer Applikation in einem Fahrzeug, Fahrzeugsystem, Computerprogramm und Datenträgersignal
DE102012007321A1 (de) Verfahren zum Betreiben eines Diagnosesystems und Diagnosesystem
DE102018202626A1 (de) Verfahren zur rechnergestützten Parametrierung eines technischen Systems
DE102022113112A1 (de) Verfahren und System zum Sammeln von Daten für Fahrzeuge
WO2021047970A1 (de) Software-komponenten für eine software-architektur
Wehinger et al. Software Defined Vehicle–It’s all about Execution and Implementation
WO2022117305A1 (de) Verfahren zum hinterlegen von programmdaten in einer datenbank
DE102023107067A1 (de) Computerimplementiertes Verfahren zum Absichern eines ein Fahrzeug und/oder ein System des Fahrzeugs repräsentierenden Signalnetzwerkes, Computerprogramm und/oder computerlesbares Medium und Datenverarbeitungsvorrichtung
DE102024125558A1 (de) Verfahren und Vorrichtung, insbesondere zur Vorabverifikation einer durchzuführenden Zustandsaktualisierung
WO2022117306A1 (de) Verfahren zum bereitstellen von programmdaten aus einer datenbank
DE102022113111A1 (de) Übertragen einer Lognachricht mit Sicherheitskennung in einem Datensystem für Fahrzeuge
DE102016207768A1 (de) Vorrichtung und Verfahren zum Bereitstellen einer Menge von Modultypen
DE102022113103A1 (de) Übertragen einer Lognachricht mit Datenschutzkennung in einem Datensystem für Fahrzeuge

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250725

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR