WO2023222794A1 - Update einer software eines fahrzeugs auf basis von fahrzeugfelddaten - Google Patents

Update einer software eines fahrzeugs auf basis von fahrzeugfelddaten Download PDF

Info

Publication number
WO2023222794A1
WO2023222794A1 PCT/EP2023/063318 EP2023063318W WO2023222794A1 WO 2023222794 A1 WO2023222794 A1 WO 2023222794A1 EP 2023063318 W EP2023063318 W EP 2023063318W WO 2023222794 A1 WO2023222794 A1 WO 2023222794A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
software
digital signature
machine learning
learning model
Prior art date
Application number
PCT/EP2023/063318
Other languages
English (en)
French (fr)
Inventor
Antonia Reiter
Peter Busch
Indrasen Raghupatruni
Dirk Bangel
Original Assignee
Robert Bosch Gmbh
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 Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Publication of WO2023222794A1 publication Critical patent/WO2023222794A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software

Definitions

  • the software (especially control software) for vehicles is becoming increasingly complex, not least due to the increasing automation of vehicles.
  • machine learning systems are playing an increasingly important role in vehicle software.
  • machine learning systems require training data from the field to ensure or improve their functionality. If the quality of the field data, the preparation of the field data and/or the training of the machine learning systems leaves something to be desired, this can have significant consequences for the functionality of the software (and thus the vehicles). It may therefore be necessary to be very restrictive with regard to possible data sources for the software development cycle.
  • it is desirable to integrate as many actors as possible into the process of collecting and processing field data since a larger amount of data and data diversity often leads to better training of the machine learning systems.
  • a first general aspect of the present disclosure relates to a computer-implemented method for a trusted update of a software Vehicle based on vehicle field data.
  • the method includes receiving vehicle field data that was collected during operation of at least one vehicle and that is provided with at least one digital signature of the vehicle and/or a user of the vehicle in a central system.
  • the method further includes recording the received vehicle field data in a data corpus if the vehicle and/or the user was recognized as a valid transmitter of vehicle field data using the respective digital signature and processing the data corpus of the central system in order to generate training data for a machine learning model, Training a machine learning model using the training data in a training environment and signing the trained machine learning model with a digital signature of the training environment.
  • the method further includes providing the trained machine learning model with the digital signature of the training environment for a software update to another vehicle.
  • a second general aspect of the present disclosure relates to a computer system configured to carry out the methods according to the first general aspect.
  • the techniques of the first and second general aspects may have one or more of the following advantages.
  • the origin of the respective data can be verified. In particular, this can happen automatically. In some cases, this can ensure that vehicle field data, trained machine learning models or software updates for vehicles come from trustworthy sources. This can ultimately ensure and/or improve the performance of vehicles provided with software updates (in particular at least partially autonomous vehicles).
  • digital signatures (which in some examples are generated with a decentrally generated key) can achieve scalability and extensibility to different sources of data (e.g. drivers or organizations).
  • vehicle includes any device that carries passengers and/or cargo.
  • a vehicle can be a motor vehicle (for example a car or a truck), but also a rail vehicle.
  • floating and flying devices can also be vehicles.
  • the term “User” includes any person driving, being transported by, or supervising the operation of the Vehicle.
  • a user can be a passenger of a vehicle (in particular a driver). However, a user can also be outside the vehicle and, for example, control and/or monitor it (e.g. during a parking process or from a remote control center).
  • a “digital signature” in the present disclosure is part of an asymmetric encryption system in which a sender uses secret information (e.g. a secret signature key, also referred to as a secret key or “private key”) to any data (in the present disclosure e.g. vehicle field data, machine learning models or software updates) a date is calculated, which is called a signature.
  • secret information e.g. a secret signature key, also referred to as a secret key or “private key”
  • private key e.g. vehicle field data, machine learning models or software updates
  • This date enables third parties to verify the authorship and/or integrity of any data using public information (e.g. a verification key, also known as a “public key”).
  • public information e.g. a verification key, also known as a “public key”.
  • a digital signature can therefore verifiably identify the author of the data.
  • Vehicle field data includes all data that is generated in connection with the operation of one (or a large number of) vehicles and that is used in particular for the design (e.g. training) of vehicles or their systems.
  • vehicle field data can be used to generate corresponding operating scenarios in a simulation environment for training vehicles (or the systems contained therein).
  • Vehicle field data is a corpus of field data.
  • the vehicle field data may contain the field data in a form structured according to a single predetermined schema. However, the corpus of vehicle field data can consist of different sub-data sets, each of which is structured differently.
  • a “cloud computing system” (German computer cloud system or data cloud system) is an infrastructure that is made available via a network, for example via the Internet.
  • a “cloud computing system” typically includes storage space, computing power and/or application software as a service (i.e. a user can use these resources over the network).
  • a cloud computing system is an infrastructure that is made available over a network without having to be present/installed on the local system.
  • “Cloud computing systems” can contain distributed resources (e.g. several computer systems in different locations. The resources of the “cloud computing system” are offered and used through technical interfaces and protocols, for example using a web browser.
  • FIG 1 shows an example system in accordance with the present disclosure.
  • FIG. 2 is a flowchart of the steps of the techniques of the present disclosure.
  • FIG. 1 shows an example system in accordance with the present disclosure.
  • Figure 2 is a flowchart of the steps of the techniques of the present disclosure.
  • the method includes receiving 210 vehicle field data 105 that were collected during operation of at least one vehicle 101 and that are provided with at least one digital signature of the vehicle 102 and/or a user of the vehicle 103 (e.g. a driver 107 of the vehicle 101) in a central location System 104.
  • receiving vehicle field data 105 may occur over an air interface (eg, over a cellular channel).
  • Vehicle field data 105 may include sensor data recorded during operation of the vehicle 101.
  • the vehicle field data 105 may be present as time series data, for example.
  • the vehicle field data 105 may include image data (e.g., still image or video image data).
  • the sensor data can include, for example, camera data (e.g. in the visible or infrared spectral range), lidar sensor data, radar sensor data, temperature sensor data and/or ultrasonic sensor data.
  • the sensor data can be position data (e.g. GPS data) or vehicle field data that describe an operating state of the vehicle (e.g. steering angle, speed, operating mode, load, etc.).
  • the sensor data can characterize the environment of the vehicle, its interior and/or its operating state. It is possible that the corresponding sensors that generate the sensor data are located within (i.e. moving with and through) the vehicle. In other examples, the sensors can also be located outside the vehicle (e.g. in infrastructure components or in other vehicles or road users).
  • the sensor data may be camera data from a camera of an autonomous vehicle (e.g. a camera facing in the direction of travel). This camera data is continuously processed (for example to create a model of the environment of the autonomous vehicle).
  • the method further includes recording 220 of the received vehicle field data 105 into a data corpus if the vehicle 101 and/or the user 107 of the vehicle was recognized as a valid transmitter of vehicle field data 105 by means of the respective digital signature 102, 103.
  • the received vehicle field data 105 cannot be included in the data corpus if the vehicle 101 and/or the user 107 was not recognized as a valid sender of vehicle field data 105 by means of the digital signature 102, 103.
  • the central system 104 may in this case request further information from the sender of the vehicle field data 105.
  • Public keys to the digital signatures of the vehicle 102 and/or a user of the vehicle 103 can be stored in a common register 108.
  • Checking the digital signatures of the vehicle 102 and/or a user of the vehicle 103 may include querying a public key of the respective signature 102, 103 in the common register 108.
  • a sender of the vehicle field data 105 may be considered a valid sender if the digital signature 102, 103 can be verified using the respective public key from the shared register 108. If no public key is stored in the common register 108 for a digital signature 102, 103 and/or a digital signature of the vehicle 102 and/or the user of the vehicle 103 cannot be verified with the respective public key, a sender of the vehicle field data 105 not be considered a valid transmitter.
  • the digital signatures of the vehicle 102 and/or the user of the vehicle 103 can be digital signatures that are generated with a decentrally generated key. Additional aspects of the decentrally generated keys and the digital signatures generated with them are discussed below in connection with FIG. 3.
  • the central system 104 may be a first cloud computing system.
  • the first cloud computing system may include cloud storage to receive the vehicle field data 105 and store the data corpus.
  • the vehicle field data 105 can be filtered and/or preprocessed.
  • the method further includes processing 230 the data corpus of the central system 104 to generate training data for a machine learning model.
  • the steps of generating training data may, in some examples, include one or more of the following steps.
  • the vehicle field data 105 can be converted into a machine-readable format (eg, into an input format for a training environment for a machine learning model).
  • certain information can be extracted from the vehicle field data 105 (e.g. still image data or sequences of image data and/or position data), which is then further processed.
  • the vehicle field data 105 (or information extracted therefrom) can be provided with labels 111 (for example to enable training of a machine learning model, for example a classifier).
  • the techniques of the present disclosure further include training 240 a machine learning model using the training data in a training environment.
  • the training environment is part of the central system 104.
  • the training environment may be located in another system (e.g., another cloud computing system or another system networked with the other systems of the present disclosure).
  • the machine learning model can be a classifier.
  • the classifier may be an image classifier (e.g., for detecting objects in the environment or within the vehicle and/or for classifying operating states of the vehicle and/or its environment).
  • An image classifier can classify images or objects contained therein based on characteristics of image data (e.g. pixel values, position of edges, etc.) (e.g. to detect specific objects in an environment of the vehicle).
  • the classifier may process other types of data and/or provide other classification results (e.g. regarding an operating state of the vehicle and/or a state of the vehicle's environment).
  • the machine learning model may be a regressor or another type of model.
  • the machine learning model may include one or more neural networks.
  • the method further includes signing 250 the trained machine learning model 110 with a digital signature of the training environment 109. If the training environment is part of the central system 104 (e.g. part of a first cloud computing system), the digital signature of the training environment 109 can be a be the digital signature of the central system 104.
  • the methods according to the present disclosure further include providing 260 the trained machine learning model 110 with the signature of the training environment 109 for a software update to another vehicle 120.
  • labels 111 of the training data used to train the machine learning model may also be provided become.
  • the methods of the present disclosure may include additional steps.
  • methods for a trusted update of a vehicle's software include receiving the trained machine learning model 110 with the signature of the training environment 109 in a software test environment 112.
  • the digital signature of the training environment 109 e.g., the central system
  • the trained machine learning model can be tested in the software test environment 112 if the training environment 104 was recognized as a valid sender of a trained machine learning model based on the digital signature of the training environment 109 (e.g. the central system).
  • the software testing environment resides on a second cloud computing system.
  • the second cloud computing system may be different from the first cloud computing system (on which the central system and/or the training environment is located) (e.g. the first cloud computing system and the second cloud computing system may be through different entities are managed).
  • Checking the digital signature of the training environment 109 may include querying a public key of the digital signature of the training environment 109 in the shared register 108.
  • a training environment 104 may be considered a valid sender if the digital signature of the training environment 109 can be verified with a key stored in the common register 108. If no corresponding key is stored in the common register 108 or the digital signature of the training environment 109 cannot be verified with the stored public key, a training environment 104 cannot be considered a valid transmitter.
  • the trained machine learning model 110 may be integrated into a simulation environment in the software test environment 112.
  • the trained machine learning model 110 may be tested (e.g., tested for a specified functionality).
  • the trained machine learning model 110 may be tested along with an associated software component of a vehicle in the software test environment 112.
  • the method may also include signing the tested machine learning model 117 with a digital signature of the software test environment 113 (e.g., if a specified functionality was recognized in the software test environment 112).
  • the method may also include providing the tested machine learning model 117 with the digital signature of the software test environment 113 in a software update to a control unit (not shown in FIG. 1) of the further vehicle 120.
  • a software component 116 of a vehicle may be provided as part of the software update.
  • the labels 111 can be provided as part of the software update.
  • the additional (or alternative) data may also be provided with the digital signature of the software test environment 113.
  • the method may include receiving the software update with a digital signature of the software test environment 112 and/or the digital signature of the training environment 109 in a vehicle 101, 120 (e.g., the additional vehicle 120).
  • the digital signature of the software test environment 112 and/or the digital signature of the training environment 109 can be used to check whether the software test environment 112 and/or the training environment 109 are valid senders of software updates.
  • Checking the digital signature of the software test environment and/or the digital signature of the training environment 109 may include querying a public key of the respective digital signature in the common register 108.
  • a training environment 104 may be considered a valid sender if the signature can be verified using a public key from the shared register 108.
  • no public key for a training environment is stored in the common register 108 and/or the digital signature of the training environment 109 cannot be verified using a stored public key, then a training environment 104 cannot be considered a valid transmitter.
  • a software test environment 112 can be considered a valid sender if the signature can be verified with a public key from the shared register 108.
  • a software test environment cannot be considered a valid sender if no public key for a software test environment is stored in the common register 108 and/or the digital signature of the software test environment cannot be verified using a stored public key, then a software test environment cannot be considered a valid sender.
  • receiving the software update and/or checking the digital signature of the software test environment 112 and/or a digital signature of the training environment 109 may be performed by a connectivity module 116 of the vehicle 101, 120.
  • a software component of the vehicle can be updated in the vehicle 101, 120 based on the software update. If the software test environment 112 and/or the training environment 104 are not recognized as a valid sender of software updates, the vehicle 101, 120 can prevent a software component of the vehicle from being updated based on the software update.
  • the software update can be provided to the vehicle 101, 120 via an air interface.
  • providing various data with respective digital signatures can enable the various systems involved to check the respective sender as a valid data source.
  • the exam steps can be occur automatically (ie without any user intervention). In some cases, this can improve both the safety and efficiency of the development process of software components for vehicles (particularly for at least partially autonomous vehicles).
  • the methods of the present disclosure can be more easily scalable, since the validability of the data sources means that other data sources than in prior art methods can also be integrated into the development process of the software components. This in turn can lead to a broader database being made available for the development of software components, which can increase the quality of software components based on machine learning.
  • a single training environment and a single software testing environment 112 are shown in FIG.
  • the system of the present disclosure may include multiple training environments and multiple software testing environments that exchange data using respective digital signatures.
  • the central system 104 data corpus may be processed to generate second training data for a second machine learning model.
  • a second machine learning model can be trained using the second training data in a second training environment and the trained second machine learning model can be provided with a digital signature of the second training environment.
  • the first training environment and the second training environment may be on different cloud computing systems.
  • the first training environment and the second training environment can train machine learning models for different purposes.
  • the different purposes of use can be one or more of different vehicle types and/or different control unit types and/or different control software. That in the As described above, the second machine learning model trained in the second training environment can be sent to the software test environment 112 and/or a vehicle 101, 120 and further processed there.
  • the system may include one or more additional training environments that, like the first/second training environment, can train machine learning models.
  • the system includes a second software testing environment.
  • the second software test environment can receive the trained machine learning model 110 (and possibly label 111) with the digital signature of the training environment 109.
  • the trained machine learning model 110 can be tested if the training environment is recognized as a valid sender of a trained machine learning model based on the digital signature of the training environment 109.
  • the tested machine learning model can be signed with a digital signature from the second software test environment.
  • the tested second machine learning model can be provided with the digital signature of the second software test environment as part of a software update to a control unit of another vehicle 120.
  • a software component of a vehicle may be provided as part of the software update in addition to the second tested machine learning model. Additionally or alternatively, the labels can be provided as part of the software update. The additional data can also be provided with the digital signature of the second software test environment.
  • the first and second software test environments can train software components for different purposes.
  • the different purposes of use can be one or more of different vehicle types and/or different control unit types and/or different control software.
  • the first software test environment 112 and the second software test environment may reside on different cloud computing systems.
  • the system may include one or more additional software test environments that, like the first/second software test environment, can test machine learning models and software components of a vehicle.
  • the vehicle field data 105 may be sent from a vehicle 101.
  • the vehicle field data 105 can be signed with the at least one digital signature of the vehicle 102 and/or the user of the vehicle 103 and the signed vehicle field data can be sent to the central system 104.
  • the digital signature of the vehicle 101 can be applied by the vehicle 101 itself or by the user 107.
  • a mobile device 106 e.g., a smartphone
  • a component of the vehicle (not shown in FIG. 1) may perform signing with the digital signature of the vehicle 102.
  • sending the signed vehicle field data 105 may be triggered via the mobile device 106. In other examples, sending the signed vehicle field data 105 may be triggered via a user interface of the vehicle 101, 120.
  • vehicle field data may be collected from a fleet of vehicles (e.g., more than 100 vehicles or more than 10,000 vehicles) using the techniques of the present disclosure and/or software components of a fleet of vehicles (e.g., more than 100 vehicles or more than 10,000 Vehicles) can be updated using the techniques of the present disclosure.
  • digital signatures of a vehicle, user of the vehicle, a training environment and/or a software testing environment were attached and verified at various points in a software development cycle. In other examples, this sequence can also be varied.
  • the digital signatures of vehicle field data e.g. from vehicles and/or users
  • can also be checked in other places e.g. in a software test environment or in a Vehicle.
  • additional digital signatures to the digital signatures discussed above may be used.
  • the digital signatures of the present disclosure may be decentrally generated digital signatures.
  • each participating system or at least several of the participating systems
  • can independently issue information for generating digital signatures i.e., there is no central authority that issues information for generating all of the digital signatures used in the present disclosure.
  • signature keys of the digital signature of the vehicle and/or the user and/or the digital signature(s) of the training environment(s) and/or the digital signature(s) of the software test environment may contain other information for generating digital signatures at least two different positions are created.
  • signature keys (or other information for generating digital signatures) of the digital signatures of different training environments can be generated by different locations.
  • signature keys and other information for generating digital signatures of the digital signatures of different software test environments can be generated from different locations.
  • signature keys of the signatures of different vehicles may be generated by different entities (e.g., by different organizations that operate and/or manufacture the respective vehicles).
  • locations 301 that issue signature keys for the digital signatures of the present disclosure are shown on the left. This may include generating a key pair containing a private key and a respective public key.
  • the public key can be stored in the shared register 108.
  • the private key is provided to the respective user 302 of the key.
  • 3 shows an example of a user of a vehicle who receives a private key 303 for the signature of the vehicle from a first location and the private key 304 for the user's signature from a second location.
  • the user can store the private keys in a suitable device (e.g. a mobile device). Keys to the other digital signatures of the present disclosure (particularly the training environment(s) and the software testing environment(s)) may be generated in the same manner.
  • Signing data using the signature can be done using the respective private key 303, 304.
  • the user 302 may affix a digital signature of the user using the private key 304 for the user's signature (and similarly the other systems of the present disclosure that affix digital signatures).
  • the data signed in this way can be validated by a test center 305 (e.g. the central network, the software test environment and/or a vehicle).
  • a public key of the respective signer can be queried in the common register 108. If the digital signature can be verified with the public key, it and therefore the signed data can be considered valid.
  • the present disclosure also relates to a computer system configured to carry out the methods according to the present disclosure.
  • the computer system may include a large number of distributed nodes connected to one or more networks (e.g., the Internet).
  • the individual nodes can in turn contain cloud computing systems.
  • the computer system includes a first cloud computing system configured to include the steps of receiving vehicle field data, incorporating the received vehicle field data into a data corpus, processing the data corpus, training a machine learning model, and signing of the trained machine learning model.
  • the computer system includes a second cloud computing system designed to carry out the steps of checking the digital signature of the training environment, testing the trained machine learning model and signing the validated machine learning model and/or a associated software component and providing the tested machine learning model and/or an associated software component to a control unit of another vehicle.
  • the computer system may further maintain a common registry in which the public keys to the digital signatures according to the present disclosure are stored.
  • shared register 108 may utilize a block chain method to store the public keys of the present disclosure.
  • multiple versions of the common registry may exist.
  • the shared register 108 may be a register replicated multiple times and stored in different locations, with the different replicas of the register 108 being synchronized (i.e. in the form of a “distributed ledger”).
  • the various replicas of the common register (108) may be stored in and/or managed by at least some of the systems described herein (i.e., not by a single central location).
  • the computer system further includes an onboard system of at least one vehicle (or onboard systems of a fleet of vehicles) designed to perform the steps of receiving the software update, checking whether the software test environment and/or or the training environment are valid sources of software updates and updating a software component of the vehicle based on the software update.
  • an onboard system of at least one vehicle or onboard systems of a fleet of vehicles designed to perform the steps of receiving the software update, checking whether the software test environment and/or or the training environment are valid sources of software updates and updating a software component of the vehicle based on the software update.
  • the computer system further includes a mobile device configured to provide the vehicle field data with the at least one digital signature of a vehicle and/or user of the vehicle.
  • the mobile device can further be designed to send the vehicle field data to the central system.
  • the present disclosure also relates to a computer program that carries out the steps of one of the methods of the present disclosure.
  • the present disclosure also relates to a computer-readable medium or signal that stores or contains a computer program of the present disclosure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Stored Programmes (AREA)

Abstract

Ein Aspekt der vorliegenden Offenbarung betrifft ein Computer-implementiertes Verfahren für ein vertrauenswürdiges Update einer Steuersoftware eines Fahrzeugs auf Basis von Fahrzeugfelddaten. Das Verfahren umfasst Empfangen von Fahrzeugfelddaten, die im Betrieb mindestens eines Fahrzeugs gesammelt wurden und die mit mindestens einer digitalen Signatur des Fahrzeugs und/oder eines Nutzers des Fahrzeugs versehen sind in einem zentralen System. Das Verfahren umfasst weiter Aufnahme der empfangenen Fahrzeugfelddaten in einen Datenkorpus, wenn das Fahrzeug und/oder des Nutzes mittels der digitalen Signatur als valider Sender von Fahrzeugfelddaten erkannt wurde und Verarbeiten des Datenkorpus des zentralen Systems, um Trainingsdaten für ein Maschinenlern-Modells zu erzeugen, Trainieren eines Maschinenlern-Modells unter Benutzung der Trainingsdaten in einer Trainingsumgebung und Signieren des trainierten Maschinenlern-Modells mit einer digitalen Signatur der Trainingsumgebung. Das Verfahren umfasst weiterhin Bereitstellen des trainierten Maschinenlern-Modells mit der Signatur der Trainingsumgebung für ein Software-Update an ein weiteres Fahrzeug.

Description

Figure imgf000003_0001
Titel einer Software eines
Figure imgf000003_0002
auf Basis von
Figure imgf000003_0003
Stand der Technik
Die Software (insbesondere Steuersoftware) für Fahrzeuge wird nicht zuletzt durch die fortschreitende Automatisierung der Fahrzeuge immer komplexer. Zudem nehmen Ma- schinen-Lernsysteme eine immer wichtigere Stellung in der Software für Fahrzeuge ein. An dieser Stelle ist es wünschenswert oder sogar notwendig, die Software der Fahrzeuge im Feld (d.h. im Betrieb) zu aktualisieren. Auf der anderen Seite benötigen die Maschinen-Lernsysteme Trainingsdaten aus dem Feld, um ihre Funktionsfähigkeit zu gewährleisten oder zu verbessern. Wenn die Qualität der Felddaten, die Aufbereitung der Felddaten und/oder des Trainings der Maschinen-Lernsysteme zu wünschen übriglässt, kann das erhebliche Konsequenzen für die Funktionalität der Software (und damit der Fahrzeuge) nach sich ziehen. Daher kann es geboten sein, bezüglich möglicher Datenquellen des Software-Entwicklungszyklus sehr restriktiv vorzugehen. Auf der anderen Seite ist es wünschenswert, möglichst viele Akteure in den Prozess des Sammelns und Aufbereitens der Felddaten zu integrieren, da eine größere Datenmenge und Daten-Diversität häufig zu einem besseren Training der Maschinen- Lernsysteme führt. Diese Anforderungen stellen einen gewissen Widerspruch dar.
Es ist es wünschenswert, Techniken bereitzustellen, die ein sicheres und leistungsfähiges Update einer Software eines Fahrzeugs auf Basis von Fahrzeugfelddaten ermöglichen.
Offenbarung der Erfindung
Ein erster allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computerimplementiertes Verfahren für ein vertrauenswürdiges Update einer Software eines Fahrzeugs auf Basis von Fahrzeugfelddaten. Das Verfahren umfasst Empfangen von Fahrzeugfelddaten, die im Betrieb mindestens eines Fahrzeugs gesammelt wurden und die mit mindestens einer digitalen Signatur des Fahrzeugs und/oder eines Nutzers des Fahrzeugs versehen sind in einem zentralen System. Das Verfahren umfasst weiter Aufnahme der empfangenen Fahrzeugfelddaten in einen Datenkorpus, wenn das Fahrzeug und/oder des Nutzes mittels der jeweiligen digitalen Signatur als valider Sender von Fahrzeugfelddaten erkannt wurde und Verarbeiten des Datenkorpus des zentralen Systems, um Trainingsdaten für ein Maschinenlern-Modell zu erzeugen, Trainieren eines Maschinenlern-Modells unter Benutzung der Trainingsdaten in einer Trainingsumgebung und Signieren des trainierten Maschinenlern-Modells mit einer digitalen Signatur der Trainingsumgebung. Das Verfahren umfasst weiterhin Bereitstellen des trainierten Maschinenlern-Modells mit der digitalen Signatur der Trainingsumgebung für ein Software- Update an ein weiteres Fahrzeug.
Ein zweiter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer- System, das dazu ausgelegt ist, die Verfahren gemäß dem ersten allgemeinen Aspekt auszuführen.
Die Techniken der ersten und zweiten allgemeinen Aspekte können einen oder mehrere der folgenden Vorteile haben.
Erstens können mittels des Versehens von Daten an verschiedenen Stellen eines Software-Entwicklungszyklus mit digitalen Signaturen die Herkunft der jeweiligen Daten überprüft werden. Insbesondere kann das automatisiert passieren. Damit kann in manchen Fällen sichergestellt werden, dass Fahrzeugfelddaten, trainierte Maschinenlern- Modelle oder Software -Updates für Fahrzeuge aus vertrauenswürdigen Quellen stammen. Das kann letztlich die Leistungsfähigkeit von mit Software- Updates versorgten Fahrzeugen (insbesondere von zumindest teilweise autonomen Fahrzeugen) sicherstellen und/oder verbessern.
Zweitens können durch digitale Signaturen (die in manchen Beispielen mit einem dezentral erzeugten Schlüssel generiert werden) eine Skalierbarkeit und Erweiterbarkeit auf verschiedene Quellen von Daten (z.B. Fahrer oder Organisationen) erreicht werden. Einige Begriffe werden in der vorliegenden Offenbarung in folgender Weise verwendet: Der Begriff „Fahrzeug“ umfasst jegliche Vorrichtungen, die in Passagiere und/oder Fracht transportieren. Ein Fahrzeug kann ein Kraftfahrzeug (zum Beispiel ein PKW oder ein LKW) sein, aber auch ein Schienenfahrzeug. Allerdings können auch schwimmende und fliegende Vorrichtungen Fahrzeuge sein.
Der Begriff „Nutzer“ umfasst jegliche Person, die mit dem Fahrzeug fährt, von diesem transportiert wird oder seinen Betrieb überwacht. Ein Nutzer kann ein Passagier eines Fahrzeugs (insbesondere ein Fahrer) sein. Ein Nutzer kann sich aber auch außerhalb des Fahrzeugs befinden und dieses beispielsweise Steuern und/oder Überwachen (z.B. während eines Einparkvorgangs oder von einer entfernten Zentrale).
Eine „digitale Signatur“ in der vorliegenden Offenbarung ist Teil eines asymmetrisches Verschlüsselungssystems, bei dem ein Sender mit Hilfe einer geheimen Information (z.B. eines geheimen Signaturschlüssels, auch als geheimer Schlüssel oder Englisch „Private Key“ bezeichnet) zu beliebigen Daten (in der vorliegenden Offenbarung z.B. Fahrzeugfelddaten, Maschinenlern-Modelle oder Software -Updates) ein Datum berechnet, das Signatur genannt wird. Dieses Datum ermöglicht es Dritten, mit Hilfe von öffentlicher Information (z.B. einem Verifikationsschlüssel, auch als „öffentlicher Schlüssel“ oder Englisch „Public Key“ bezeichnet) eine Urheberschaft und/oder Integrität der beliebigen Daten zu prüfen. Um eine mit einem Signaturschlüssel erstellte Signatur einem Urheber zuordnen zu können, muss der zugehörige Verifikationsschlüssel dieser Person zweifelsfrei zugeordnet sein. Eine digitale Signatur kann somit einen Urheber der Daten überprüfbar identifizieren.
„Fahrzeugfelddaten“ (oder auch einfach „Felddaten“) umfassen alle Daten, die im Zusammenhang mit dem Betrieb eines (oder einer Vielzahl) von Fahrzeugen anfallen und die insbesondere zum Auslegen (z.B. Training) von Fahrzeugen oder deren Systemen verwendet werden. Beispielsweise können Fahrzeugfelddaten dazu verwendet werden, entsprechende Betriebsszenarien in einer Simulationsumgebung zum Trainieren von Fahrzeugen (bzw. der darin enthaltenen Systeme) zu erzeugen. „Fahrzeugfelddaten“ sind ein Korpus von Felddaten. In manchen Fällen können die Fahrzeugfelddaten die Felddaten in einer gemäß einem einzigen vorgegebenen Schema strukturierten Form enthalten. Der Korpus von Fahrzeugfelddaten kann jedoch aus verschiedenen Teildatensätzen bestehen, die jeweils unterschiedlich strukturiert sind. Ein „Cloud-Computing-System“ (deutsch Rechnerwolken-System oder Datenwolken- System) ist eine Infrastruktur, die über ein Netzwerk, beispielsweise über das Internet, verfügbar gemacht wird. Ein „Cloud-Computing-System“ beinhaltet in der Regel Speicherplatz, Rechenleistung und/oder Anwendungssoftware als Dienst (d.h. ein Nutzer kann über das Netzwerk diese Ressourcen nutzen). In anderen Worten ist ein Cloud- Computing-System eine Infrastruktur, die über ein Netzwerk zur Verfügung gestellt werden, ohne dass diese auf dem lokalen System vorhanden / installiert sein müssen. „Cloud-Computing-Systeme“ können verteilte Ressourcen enthalten (z.B. mehrerer Rechnersysteme an verschiedenen Orten. Das Angebot und die Nutzung der Ressourcen des „Cloud-Computing-System“ erfolgt dabei durch technische Schnittstellen und Protokolle, etwa mittels eines Webbrowsers.
Kurzbeschreibung der Figuren
Fig. 1 zeigt ein beispielhaftes System gemäß der vorliegenden Offenbarung.
Fig. 2 ist ein Flussdiagramm der Schritte der Techniken der vorliegenden Offenbarung.
Fig. 3 illustriert das Ausstellen und Überprüfen von digitalen Signaturen der vorliegenden Offenbarung.
Beschreibung
Zunächst werden die Techniken der vorliegenden Offenbarung anhand der Fig. 1 und Fig. 2 erläutert. Weitere Aspekte der (z.B. mittels dezentral erzeugten Schlüsseln generierten) digitalen Signaturen der vorliegenden Offenbarung werden in der Folge anhand der Fig. 3 diskutiert.
Fig. 1 zeigt ein beispielhaftes System gemäß der vorliegenden Offenbarung. Fig. 2 ist ein Flussdiagramm der Schritte der Techniken der vorliegenden Offenbarung.
Das Verfahren umfasst Empfangen 210 von Fahrzeugfelddaten 105, die im Betrieb mindestens eines Fahrzeugs 101 gesammelt wurden und die mit mindestens einer digitalen Signatur des Fahrzeugs 102 und/oder eines Nutzers des Fahrzeugs 103 (z.B. eines Fahrers 107 des Fahrzeugs 101) versehen sind in einem zentralen System 104. In manchen Beispielen kann das Empfangen von Fahrzeugfelddaten 105 über eine Luftschnittstelle (z.B. über einen Mobilfunkkanal) von statten gehen.
Fahrzeugfelddaten 105 können Sensordaten umfassen, die während des Betriebs des Fahrzeugs 101 aufgenommen werden. Die Fahrzeugfelddaten 105 können zum Beispiel als Zeitseriendaten vorliegen. Die Fahrzeugfelddaten 105 können Bilddaten umfassen (z.B. Einzelbild- oder Videobilddaten).
Die Sensordaten können zum Beispiel Kameradaten (z.B. im sichtbaren oder infraroten Spektralbereich), Lidar-Sensordaten, Radar-Sensordaten, Temperatursensor-Daten und/oder Ultraschall-Sensordaten umfassen. Alternativ oder zusätzlich können die Sensordaten Positionsdaten (z.B. GPS-Daten) oder Fahrzeugfelddaten, die einen Betriebszustand des Fahrzeugs beschreiben (z.B. Lenkwinkel, Drehzahl, Betriebsmodus, Beladung etc.), sein. Die Sensordaten können das Umfeld des Fahrzeugs, seinen Innenraum und/oder seinen Betriebszustand charakterisieren. Es ist möglich, dass sich die entsprechenden Sensoren, die die Sensordaten erzeugen, innerhalb des Fahrzeugs befinden (d.h. sich mit diesem und durch dieses bewegen). In anderen Beispielen können die Sensoren sich aber auch außerhalb des Fahrzeugs befinden (z.B. in Infrastrukturkomponenten oder in anderen Fahrzeugen oder Verkehrsteilnehmern).
In einem illustrativen Beispiel können die Sensordaten Kameradaten einer Kamera eines autonomen Fahrzeugs sein (z.B. einer in Fahrrichtung gerichteten Kamera). Diese Kameradaten werden fortlaufend verarbeitet (zum Beispiel für das Erstellen eines Umfeldmodells des autonomen Fahrzeugs).
Das Verfahren umfasst weiter Aufnahme 220 der empfangenen Fahrzeugfelddaten 105 in einen Datenkorpus, wenn das Fahrzeug 101 und/oder der Nutzer 107 des Fahrzeugs mittels der jeweiligen digitalen Signatur 102, 103 als valider Sender von Fahrzeugfelddaten 105 erkannt wurde. Auf der anderen Seite können die empfangenen Fahrzeugfelddaten 105 nicht in den Datenkorpus aufgenommen werden, wenn das Fahrzeug 101 und/oder der Nutzer 107 mittels der digitalen Signatur 102, 103 nicht als valider Sender von Fahrzeugfelddaten 105 erkannt wurde. In anderen Beispielen kann das zentrale System 104 in diesem Fall weitere Informationen bei dem Sender der Fahrzeugfelddaten 105 anfragen. Öffentliche Schlüssel zu den digitalen Signaturen des Fahrzeugs 102 und/oder eines Nutzers des Fahrzeugs 103 (z.B. eines Fahrers des Fahrzeugs 101) können in einem gemeinsamen Register 108 gespeichert sein.
Prüfen der digitalen Signaturen des Fahrzeugs 102 und/oder eines Nutzers des Fahrzeugs 103 kann das Abfragen eines öffentlichen Schlüssels der jeweiligen Signatur 102, 103 in dem gemeinsamen Register 108 umfassen. In manchen Beispielen kann ein Sender der Fahrzeugfelddaten 105 als valider Sender erachtet werden, wenn die digitale Signatur 102, 103 anhand des jeweiligen öffentlichen Schlüssels aus dem gemeinsamen Register 108 verifiziert werden kann. Ist zu einer digitalen Signatur 102, 103 kein öffentlicher Schlüssel in dem gemeinsamen Register 108 hinterlegt und/oder kann eine digitale Signatur des Fahrzeugs 102 und/oder des Nutzers des Fahrzeugs 103 nicht mit dem jeweiligen öffentlichen Schlüssel verifiziert werden, kann ein Sender der Fahrzeugfelddaten 105 nicht als valider Sender erachtet werden.
Die digitalen Signaturen des Fahrzeugs 102 und/oder des Nutzers des Fahrzeugs 103 (und auch die weiteren digitalen Signaturen der vorliegenden Offenbarung) können digitale Signaturen sein, die mit einem dezentral erzeugten Schlüssel generiert werden. Zusätzliche Aspekte der dezentral erzeugten Schlüssel und der damit generierten digitalen Signaturen werden weiter unten im Zusammenhang mit Fig. 3 diskutiert.
In manchen Beispielen kann das zentrale System 104 ein erstes Cloud-Computing- System sein. In manchen Beispielen kann das erste Cloud-Computing-System einen Cloud-Speicher umfassen, um die Fahrzeugfelddaten 105 zu empfangen und den Datenkorpus zu speichern.
Der Fahrzeugfelddaten 105 können gefiltert und/oder vorverarbeitet werden.
Das Verfahren umfasst weiterhin Verarbeiten 230 des Datenkorpus des zentralen Systems 104, um Trainingsdaten für ein Maschinenlern-Modell zu erzeugen.
Die Schritte des Erzeugens von Trainingsdaten können in manchen Beispielen einen oder mehrere der folgenden Schritte umfassen. Die Fahrzeugfelddaten 105 können in ein maschinen-lesbares Format gebracht werden (z.B. in ein Eingabeformat für eine Trainingsumgebung für ein Maschinenlern- Modell). Alternativ oder zusätzlich können aus den Fahrzeugfelddaten 105 bestimmte Informationen extrahiert werden (z.B. Stand-Bilddaten oder Sequenzen von Bilddaten und/oder Positionsdaten), die dann weiterverarbeitet werden. Weiter alternativ oder zusätzlich können die Fahrzeugfelddaten 105 (oder daraus extrahierte Informationen) mit Labels 111 versehen werden (z.B. um das Trainieren eines Maschinenlern-Modells, bspw. eines Klassifikators, zu ermöglichen).
Die Techniken der vorliegenden Offenbarung umfassen weiterhin Trainieren 240 eines Maschinenlern-Modells unter Benutzung der Trainingsdaten in einer Trainingsumgebung. Im Beispiel von Fig. 1 ist die Trainingsumgebung Teil des zentralen Systems 104. In anderen Beispielen kann die Trainingsumgebung in einem weiteren System angeordnet sein (z.B. eines weiteren Cloud-Computing-Systems oder eines anderen mit den anderen Systemen der vorliegenden Offenbarung vernetzten System).
Das Maschinenlern-Modell kann ein Klassifikator sein. In manchen Beispielen kann der Klassifikator ein Bildklassifikator sein (z.B. zum Erkennen von Objekten im Umfeld oder innerhalb des Fahrzeugs und/oder zum Klassifizieren von Betriebszuständen des Fahrzeugs und/oder seiner Umwelt). Ein Bildklassifikator kann basierend auf Merkmalen von Bilddaten (z.B. Pixelwerten, Position von Kanten usw.) Bilder oder darin enthaltene Objekte klassifizieren (z.B. zur Erkennung bestimmter Objekte in einem Umfeld des Fahrzeugs). In anderen Beispielen kann der Klassifikator andere Datentypen verarbeiten und/oder andere Klassifikationsergebnisse liefern (z.B. bezüglich eines Betriebszustands des Fahrzeugs und/oder einem Zustand des Umfelds des Fahrzeuges). In wieder anderen Beispielen kann das Maschinenlern-Modell ein Regressor oder ein anderer Typ von Modell sein.
Das Maschinenlern-Modell kann ein oder mehrere neuronale Netzwerke umfassen. Das Verfahren umfasst weiterhin das Signieren 250 des trainierten Maschinenlern- Modells 110 mit einer digitalen Signatur der Trainingsumgebung 109. Wenn die Trainingsumgebung Teil des zentralen Systems 104 ist (z.B. Teil eines ersten Cloud- Computing-Systems), kann die digitale Signatur der Trainingsumgebung 109 eine digitale Signatur des zentralen Systems 104 sein. Die Verfahren gemäß der vorliegenden Offenbarung umfassen weiterhin Bereitstellen 260 des trainierten Maschinenlern-Modells 110 mit der Signatur der Trainingsumgebung 109 für ein Software- Update an ein weiteres Fahrzeug 120. In manchen Beispielen können zudem Labels 111 der zum Training des Maschinenlern-Modells verwendeten Trainingsdaten bereitgestellt werden.
Die Verfahren der vorliegenden Offenbarung können weitere Schritte umfassen.
In manchen Beispielen umfasst Verfahren für ein vertrauenswürdiges Update einer Software eines Fahrzeugs das Empfangen des trainierten Maschinenlern-Modells 110 mit der Signatur der Trainingsumgebung 109 in einer Softwaretestumgebung 112. In der Softwaretestumgebung 112 kann die digitale Signatur der Trainingsumgebung 109 (z.B. des zentralen Systems) geprüft werden. In einem weiteren Schritt kann das trainierte Maschinenlern-Modells in der Softwaretestumgebung 112 getestet werden, wenn die Trainingsumgebung 104 anhand der digitalen Signatur der Trainingsumgebung 109 (z.B. des zentralen Systems) als valider Sender eines trainierten Maschinenlern-Modells erkannt wurde.
In einigen Beispielen befindet sich die Softwaretestumgebung auf einem zweiten Cloud-Computing-System. Das zweite Cloud-Computing -System kann von dem ersten Cloud-Computing-System (auf dem sich das zentrale System und/oder die Trainingsumgebung befinden) unterscheiden (z.B. können das erste Cloud-Computing-System und das zweite Cloud-Computing-System durch unterschiedliche Entitäten verwaltet werden).
Das Prüfen der digitalen Signatur der Trainingsumgebung 109 (z.B. des zentralen Systems) kann das Abfragen eines öffentlichen Schlüssels der digitalen Signatur der Trainingsumgebung 109 in dem gemeinsamen Register 108 umfassen. In manchen Beispielen kann eine Trainingsumgebung 104 als valider Sender erachtet werden, wenn die digitale Signatur der Trainingsumgebung 109 mit einem in dem gemeinsamen Register 108 hinterlegten Schlüssel verifiziert werden kann. Ist in dem gemeinsamen Register 108 kein entsprechender Schlüssel hinterlegt oder kann die digitale Signatur der Trainingsumgebung 109 nicht mit dem hinterlegten öffentlichen Schlüssel verifiziert werden, so kann eine Trainingsumgebung 104 nicht als valider Sender erachtet wird. In manchen Beispielen kann das trainierte Maschinenlern-Modell 110 in der Softwaretestumgebung 112 in eine Simulationsumgebung integriert werden.
In der Simulationsumgebung oder einer anderen Testumgebung der Softwaretestumgebung 112 kann das trainierten Maschinenlern-Modell 110 getestet werden (z.B. auf eine spezifizierte Funktionalität hin getestet werden).
In manchen Beispielen kann das trainierte Maschinenlern-Modell 110 zusammen mit einer zugehörigen Software- Komponente eines Fahrzeugs in der Softwaretestumgebung 112 getestet werden.
Das Verfahren kann zudem das Signieren des getesteten Maschinenlern-Modells 117 mit einer digitalen Signatur der Softwaretestumgebung 113 umfassen (z.B., wenn in der Softwaretestumgebung 112 eine spezifizierte Funktionalität erkannt wurde).
Das Verfahren kann zudem Bereitstellen des getesteten Maschinenlern-Modells 117 mit der digitalen Signatur der Softwaretestumgebung 113 in einem Software -Update an eine Steuereinheit (nicht in Fig. 1 gezeigt) des weiteren Fahrzeugs 120 umfassen. In manchen Beispielen kann neben dem getesteten Maschinenlern-Modell 117 (oder alternativ) eine Software- Komponente 116 eines Fahrzeugs als Teil des Software- Updates bereitgestellt werden. Zusätzlich oder alternativ können die Labels 111 als Teil des Software- Updates bereitgestellt werden. Die zusätzlichen (oder alternativen) Daten können ebenfalls mit der digitalen Signatur der Softwaretestumgebung 113 versehen sein.
In manchen Beispielen kann das Verfahren Empfangen des Software- Updates mit einer digitalen Signatur der Softwaretestumgebung 112 und/oder der digitalen Signatur der Trainingsumgebung 109 in einem Fahrzeug 101 , 120 (z.B. dem weiteren Fahrzeug 120) umfassen. In dem jeweiligen Fahrzeug 101 , 120 kann anhand der digitalen Signatur der Softwaretestumgebung 112 und/oder der digitalen Signatur der Trainingsumgebung 109 geprüft werden, ob die Softwaretestumgebung 112 und/oder die Trainingsumgebung 109 valide Sender von Software- Updates sind.
Das Prüfen digitalen Signatur der Softwaretestumgebung und/oder der digitalen Signatur der Trainingsumgebung 109 kann das Abfragen eines öffentlichen Schlüssels der jeweiligen digitalen Signatur in dem gemeinsamen Register 108 umfassen. In manchen Beispielen kann eine Trainingsumgebung 104 als valider Sender erachtet werden, wenn mit einem öffentlichen Schlüssel aus dem gemeinsamen Register 108 die Signatur verifiziert werden kann. Ist dagegen in dem gemeinsamen Register 108 kein öffentlicher Schlüssel zu einer Trainingsumgebung hinterlegt und/oder kann die digitale Signatur der Trainingsumgebung 109 nicht mittels eines hinterlegten öffentlichen Schlüssels verifiziert werden, so kann eine Trainingsumgebung 104 nicht als valider Sender erachtet werden.
In gleicher Weise kann eine Softwaretestumgebung 112 als valider Sender erachtet werden, wenn mit einem öffentlichen Schlüssel aus dem gemeinsamen Register 108 die Signatur verifiziert werden kann. Ist dagegen in dem gemeinsamen Register 108 kein öffentlicher Schlüssel zu einer Softwaretestumgebung hinterlegt und/oder kann die digitalen Signatur der Softwaretestumgebung nicht mittels eines hinterlegten öffentlichen Schlüssels verifiziert werden, so kann eine Softwaretestumgebung nicht als valider Sender erachtet werden.
In manchen Beispielen kann das Empfangen des Software -Updates und/oder das Prüfen der digitalen Signatur der Softwaretestumgebung 112 und/oder einer digitalen Signatur der Trainingsumgebung 109 von einem Konnektivitäts-Modul 116 des Fahrzeugs 101 , 120 durchgeführt werden.
Wenn Softwaretestumgebung 112 und/oder die Trainingsumgebung 104 als valider Sender von Software- Updates erkannt werden, kann im Fahrzeug 101 , 120 ein Aktualisieren einer Software- Komponente des Fahrzeugs anhand des Software- Updates stattfinden. Wenn die Softwaretestumgebung 112 und/oder die Trainingsumgebung 104 nicht als valider Sender von Software- Updates erkannt werden, kann das Fahrzeug 101 , 120 ein Aktualisieren einer Software-Komponente des Fahrzeugs anhand des Software- Updates unterbinden.
Das Software- Update kann über eine Luftschnittstelle an das Fahrzeug 101 , 120 bereitgestellt werden.
In oben beschriebenen Verfahren kann das Versehen verschiedener Daten mit jeweiligen digitalen Signaturen den verschiedenen beteiligten Systemen ermöglichen, den jeweiligen Sender als valide Datenquelle zu prüfen. Die Prüfungsschritte können dabei automatisiert erfolgen (d.h. ohne Einwirken eines Nutzers). Das kann in manchen Fällen sowohl die Sicherheit als auch die Effizienz des Entwicklungsprozesses von Software-Komponenten für Fahrzeuge (insbesondere für zumindest teilweise autonome Fahrzeuge) verbessern. Zudem (und als Konsequenz) können die Verfahren der vorliegenden Offenbarung leichter skalierbar sein, da durch die Validierbarkeit der Datenquellen auch andere Datenquellen als in Verfahren des Stands der Technik in den Entwicklungsprozess der Software- Komponenten eingebunden werden kann. Das kann wiederum dazu führen, dass eine breitere Datenbasis für die Entwicklung von Software- Komponenten zur Verfügung gestellt wird, was die Qualität von auf maschinellem Lernen beruhenden Software- Komponenten erhöhen kann.
In Fig. 1 ist eine einzige Trainingsumgebung und eine einzige Softwaretest-Umgebung 112 gezeigt. In anderen Beispielen kann das System der vorliegenden Offenbarung mehrere Trainingsumgebungen und mehrere Softwaretest-Umgebungen umfassen, die unter Verwendung von jeweiligen digitalen Signaturen Daten austauschen.
In manchen Beispielen kann der Datenkorpus des zentralen Systems 104 verarbeitet werden, um zweite Trainingsdaten für ein zweites Maschinenlern-Modell zu erzeugen. Ein zweites Maschinenlern-Modell kann unter Benutzung der zweiten Trainingsdaten in einer zweiten Trainingsumgebung trainiert werden und das trainierte zweite Maschinenlern-Modell kann mit einer digitalen Signatur der zweiten Trainingsumgebung versehen werden.
Die in Bezug auf die Erzeugung von Trainingsdaten und dem Training des Maschinen- lern-Modells weiter oben beschriebenen Schritte können gleichermaßen bei der Erzeugung der zweiten Trainingsdaten und des zweiten Maschinenlern-Modells angewendet werden.
Die erste Trainingsumgebung und die zweite Trainingsumgebung können sich auf verschiedenen Cloud-Computing-Systemen befinden.
Die erste Trainingsumgebung und die zweite Trainingsumgebung können Maschinen- lern-Modelle für verschiedene Einsatzzwecke trainieren. Die verschiedenen Einsatzzwecke können eines oder mehrere sein von verschiedenen Fahrzeugtypen und/oder verschiedenen Steuergerättypen und/oder verschiedener Steuersoftware. Das in der zweiten Trainingsumgebung trainierte zweite Maschinenlern-Modell kann wir oben beschreiben an die Softwaretestumgebung 112 und/oder ein Fahrzeug 101 , 120 gesendet werden und dort weiterverarbeitet werden.
In manchen Beispielen kann das System ein oder mehrere weitere Trainingsumgebungen umfassen, die wie die erste/zweite Trainingsumgebung Maschinenlern-Modelle trainieren können.
In manchen Beispielen umfasst das System eine zweite Softwaretestumgebung.
Die zweite Softwaretestumgebung kann das trainierte Maschinenlern-Modell 110 (und ggf. Label 111) mit der digitalen Signatur der Trainingsumgebung 109 empfangen.
In der zweiten Softwaretestumgebung kann das trainierte Maschinenlern-Modell 110 getestet werden, wenn die Trainingsumgebung anhand der digitalen Signatur der Trainingsumgebung 109 als valider Sender eines trainierten Maschinenlern-Modellen erkannt wird. Zudem kann in der zweiten Softwaretestumgebung das getestete Maschinenlern-Modell mit einer digitalen Signatur der zweiten Softwaretestumgebung signiert werden. Das getestete zweite Maschinenlern-Modells kann mit der digitalen Signatur der zweiten Softwaretestumgebung als Teil eines Software- Updates an eine Steuereinheit eines weiteren Fahrzeugs 120 bereitgestellt werden.
In manchen Beispielen kann neben dem zweiten getesteten Maschinenlern-Modell eine Software-Komponente eines Fahrzeugs als Teil des Software- Updates bereitgestellt werden. Zusätzlich oder alternativ können die Labels als Teil des Software- Updates bereitgestellt werden. Die zusätzlichen Daten können ebenfalls mit der digitalen Signatur der zweiten Softwaretestumgebung versehen sein.
Die erste und zweite Softwaretestumgebungen können Software- Komponenten für verschiedene Einsatzzwecke trainieren. Die verschiedenen Einsatzzwecke können eines oder mehrere sein von verschiedenen Fahrzeugtypen und/oder verschiedenen Steuergerättypen und/oder verschiedener Steuersoftware.
Die erste Softwaretestumgebung 112 und die zweite Softwaretestumgebung können sich auf verschiedenen Cloud-Computing-Systemen befinden. In manchen Beispielen kann das System ein oder mehrere weitere Softwaretestumgebungen umfassen, die wie die erste/zweite Softwaretestumgebung Maschinenlern- Modelle und Software- Komponente eines Fahrzeugs testen können.
In manchen Beispielen könne die Fahrzeugfelddaten 105 von einem Fahrzeug 101 gesendet werden. Dazu können die Fahrzeugfelddaten 105 mit der mindestens einer digitalen Signatur des Fahrzeugs 102 und/oder des Nutzers des Fahrzeugs 103 signiert werden und die signierten Fahrzeugfelddaten an das zentrale System 104 gesendet werden. Die digitale Signatur des Fahrzeugs 101 kann durch das Fahrzeug 101 selbst oder durch den Nutzer 107 angebracht werden. In manchen Beispielen kann ein Mobilgerät 106 (z.B. ein Smartphone) des Nutzers 107 zum Signieren der Fahrzeugfelddaten 105 verwendet werden. In anderen Beispielen kann eine Komponente des Fahrzeugs (nicht in Fig. 1 gezeigt) das Signieren mit der digitalen Signatur des Fahrzeugs 102 durchführen.
In manchen Beispielen kann das Senden der signierten Fahrzeugfelddaten 105 über das Mobilgerät 106 ausgelöst werden. In anderen Beispielen kann das Senden der signierten Fahrzeugfelddaten 105 über eine Benutzerschnittstelle des Fahrzeugs 101 , 120 ausgelöst werden.
In den vorangehenden Beispielen wurden die Techniken der vorliegenden Offenbarung anhand von zwei Fahrzeugen erläutert. In manchen Beispielen können Fahrzeugfelddaten von einer Flotte von Fahrzeugen (z.B. mehr als 100 Fahrzeuge oder mehr als 10.000 Fahrzeuge) mit den Techniken der vorliegenden Offenbarung gesammelt werden und/oder Software- Komponenten einer Flotte von Fahrzeugen (z.B. mehr als 100 Fahrzeuge oder mehr als 10.000 Fahrzeuge) mit den Techniken der vorliegenden Offenbarung aktualisiert werden.
In den vorherigen Beispielen wurden digitale Signaturen eines Fahrzeugs, Nutzers des Fahrzeugs, einer Trainingsumgebung und/oder einer Softwaretestumgebung an verschiedenen Stellen eines Software-Entwicklungszyklus angebracht und überprüft. In anderen Beispielen kann diese Abfolge auch variiert werden. So können die digitalen Signaturen von Fahrzeugfelddaten (z.B. von Fahrzeugen und/oder Nutzern) auch an anderen Stellen geprüft werden (z.B. in einer Softwaretestumgebung oder in einem Fahrzeug). In anderen Beispielen können zusätzliche digitale Signaturen zu den oben besprochenen digitalen Signaturen verwendet werden.
Fig. 3 illustriert das Ausstellen und Nutzen von digitalen Signaturen der vorliegenden Offenbarung.
Wie oben bereits erwähnt, können die digitalen Signaturen der vorliegenden Offenbarung dezentral erzeugte digitale Signaturen sein. Jedes beteiligte System (oder zumindest mehrere der beteiligten Systeme) kann in diesem Fall selbständig Informationen zum Erzeugen von digitalen Signaturen ausstellen (d.h., es gibt keine zentrale Autorität, die Informationen zum Erzeugen aller in der vorliegenden Offenbarung verwendeten digitalen Signaturen ausstellt). Zum Beispiel können Signaturschlüssel der digitalen Signatur des Fahrzeugs und/oder des Nutzers und/oder der digitalen Signatur(en) der Trainingsumgebung(en) und/oder der digitalen Signatur(en) der Softwaretestumgebungfen) feder andere Informationen zum Erzeugen von digitalen Signaturen) von mindestens zwei unterschiedlichen Stellen erzeugt werden. Insbesondere können Signaturschlüssel (oder andere Informationen zum Erzeugen von digitalen Signaturen) der digitalen Signaturen verschiedener Trainingsumgebungen von verschiedenen Stellen erzeugt werden. Zusätzlich oder alternativ können Signaturschlüssel feder andere Informationen zum Erzeugen von digitalen Signaturen) der digitalen Signaturen verschiedener Softwaretestumgebungen von verschiedenen Stellen erzeugt werden. In wieder anderen Beispielen können Signaturschlüssel der Signaturen verschiedener Fahrzeuge von verschiedenen Stellen erzeugt werden (z.B. von verschiedenen Organisationen, die die jeweiligen Fahrzeuge betreiben und/oder herstellen).
In Fig. 3 sind auf der linken Seite Stellen 301 gezeigt, die Signaturschlüssel für die digitalen Signaturen der vorliegenden Offenbarung ausstellen. Das kann die Erzeugung eines Schlüsselpaars, das einen privaten Schlüssel und einen jeweiligen öffentlichen Schlüssel enthält, umfassen. Der öffentliche Schlüssel kann in dem gemeinsamen Register 108 hinterlegt werden. Der private Schlüssel wird dem jeweiligen Nutzer 302 der Schlüssel bereitgestellt. In Fig. 3 ist beispielhaft ein Nutzer eines Fahrzeugs gezeigt, der von einer ersten Stelle einen privaten Schlüssel 303 für die Signatur des Fahrzeugs und von einer zweiten Stelle den privaten Schlüssel 304 für die Signatur des Nutzers erhält. Der Nutzer kann die privaten Schlüssel in einer geeigneten Vorrichtung abspeichern (z.B. einem Mobilgerät). Schlüssel zu den anderen digitalen Signaturen der vorliegenden Offenbarung (insbesondere der Trainingsumgebung(en) und der Softwaretestumgebung(en)) können in gleicher Weise erzeugt werden.
Das Signieren von Daten mittels der Signatur kann eine Verwendung des jeweiligen privaten Schlüssels 303, 304 geschehen. Zum Beispiel kann der Nutzer 302 eine digitale Signatur des Nutzers anbringen unter Verwendung des privaten Schlüssel 304 für die Signatur des Nutzers (und in gleicher Weise die anderen Systeme der vorliegenden Offenbarung, die digitale Signaturen anbringen).
Die in dieser Weise signierten Daten können durch ein Prüfstelle 305 (z.B. das zentrale Netzwerk, die Softwaretestumgebung und/oder ein Fahrzeug) validiert werden. Dazu kann ein öffentlicher Schlüssel des jeweiligen Signierers in dem gemeinsamen Register 108 abgefragt werden. Falls die digitale Signatur mit dem öffentlichen Schlüssel verifiziert werden kann, kann sie und mithin die signierten Daten als valide eingeschätzt werden.
Die vorliegende Offenbarung betrifft auch ein Computer-System, das dazu ausgelegt ist, die Verfahren gemäß der vorliegenden Offenbarung auszuführen. Wie bereits beschrieben, kann das Computer-System eine große Anzahl von verteilten Knoten umfassen, die mit einem oder mehreren Netzwerken (z.B. dem Internet) verbunden sind. Die einzelnen Knoten können wiederum Cloud-Computing-Systeme enthalten.
In einem Beispiel umfasst das Computer-System ein erstes Cloud-Computing-System, das dazu ausgelegt ist, die Schritte des Empfangens von Fahrzeugfelddaten, der Aufnahme der empfangenen Fahrzeugfelddaten in einen Datenkorpus, des Verarbeitens des Datenkorpus, Trainieren eines Maschinenlern-Modells und des Signierens des trainierten Maschinenlern-Modells auszuführen.
Zusätzlich oder alternativ umfasst das Computer-System ein zweites Cloud- Computing-System, das dazu ausgelegt ist, die Schritte des Prüfens der digitalen Signatur der Trainingsumgebung, des Testen des trainierten Maschinenlern-Modells und das Signieren des validierten Maschinenlern-Modells und/oder einer zugehörigen Software- Komponente und das Bereitstellen des getesteten Maschinenlern-Modells und/oder einer zugehörigen Software- Komponente an eine Steuereinheit eines weiteren Fahrzeugs auszuführen.
Wie bereits besprochen kann das Computer- System weiter ein gemeinsames Register, in dem die öffentlichen Schlüssel zu den digitalen Signaturen gemäß der vorliegenden Offenbarung abgelegt sind. In manchen Beispielen kann das gemeinsame Register 108 ein Block-Chain-Verfahren nutzen, um die öffentlichen Schlüssel der vorliegenden Offenbarung zu speichern. In diesem Fall können mehrere Versionen des gemeinsamen Registers existieren. Zum Beispiel kann das gemeinsame Register 108 ein mehrfach repliziertes und an verschiedenen Orten gespeichertes Register sein, wobei die verschiedenen Replika des Registers 108 synchronisiert sind (d.h. in Form eines „di- sitributed ledger“). Die verschiedenen Replika des gemeinsamen Registers (108) können zum Beispiel in zumindest manchen der hierin beschriebenen Systeme gespeichert und/oder von diesen verwaltet werden (also nicht von einer einzigen zentralen Stelle).
In manchen Beispielen enthält das Computer-System weiter ein Bordsystem mindesten eines Fahrzeugs (oder Bordsysteme einer Flotte von Fahrzeugen), das (die) dazu ausgelegt ist (sind), die Schritte des Empfangens des Software- Updates, Prüfens, ob die Softwaretestumgebung und/oder die Trainingsumgebung valide Quellen von Software- Updates sind und Aktualisieren einer Software- Komponente des Fahrzeugs anhand des Software- Updates auszuführen.
In manchen Beispielen umfasst das Computer-System weiter ein Mobilgerät, das dazu ausgelegt ist, die Fahrzeugfelddaten, mit der mindestens einen digitalen Signatur eines Fahrzeugs und/oder Nutzers des Fahrzeugs zu versehen. Das Mobilgerät kann weiter dazu ausgelegt sein, die Fahrzeugfelddaten an das zentrale System zu versenden. Die vorliegende Offenbarung betrifft auch ein Computerprogramm, das die Schritte eines der Verfahren der vorliegenden Offenbarung ausführt.
Die vorliegende Offenbarung betrifft auch ein Computer-lesbares Medium oder Signal, das ein Computerprogramm der vorliegenden Offenbarung speichert oder enthält.

Claims

Ansprüche
1 . Computer-implementiertes Verfahren für ein vertrauenswürdiges Update einer Software eines Fahrzeugs (101 ; 120) auf Basis von Fahrzeugfelddaten, umfassend:
Empfangen von Fahrzeugfelddaten (105), die im Betrieb mindestens eines Fahrzeugs (101) gesammelt wurden und die mit mindestens einer digitalen Signatur des Fahrzeugs (102) und/oder eines Nutzers des Fahrzeugs (103) versehen sind in einem zentralen System (104);
Aufnahme der empfangenen Fahrzeugfelddaten (105) in einen Datenkorpus, wenn das Fahrzeug (101) und/oder der Nutzer (107) mittels der jeweiligen digitalen Signatur (102; 103) als valider Sender von Fahrzeugfelddaten erkannt wurde;
Verarbeiten des Datenkorpus des zentralen Systems (104), um Trainingsdaten für ein Maschinenlern-Modells zu erzeugen;
Trainieren eines Maschinenlern-Modells unter Benutzung der Trainingsdaten in einer Trainingsumgebung;
Signieren des trainierten Maschinenlern-Modells (110) mit einer digitalen Signatur der Trainingsumgebung (109); und
Bereitstellen des trainierten Maschinenlern-Modells (110) mit der Signatur der Trainingsumgebung (109) für ein Software- Update an ein weiteres Fahrzeug (120).
2. Verfahren gemäß Anspruch 1 , wobei Bereitstellen des trainierten Maschinen- Lernsystems (110) umfasst:
Prüfen der digitalen Signatur des zentralen Systems (109) in einer Softwaretestumgebung (112);
Testen des trainierten Maschinenlern-Modells (110) und/oder einer Software- Komponente in der Softwaretestumgebung (112), wenn die Trainingsumgebung anhand der digitalen Signatur des zentralen Systems (109) als valider Sender eines trainierten Maschinenlern-Modells (110) erkannt wurde;
Signieren des getesteten Maschinenlern-Modells (117) und/oder der Software- Komponente (115) mit einer digitalen Signatur der Softwaretestumgebung (113); Bereitstellen des getesteten Maschinenlern-Modells (117) und/oder der getesteten Software- Komponente (115) mit der digitalen Signatur der Softwaretestumgebung (113) in dem Software- Update an eine Steuereinheit des weiteren Fahrzeugs (120). Verfahren gemäß einer der Ansprüche 1 und 2, wobei die digitalen Signaturen (102; 103; 109; 113) mittels dezentral erzeugter Schlüssel generiert sind. Verfahren gemäß Anspruch 3, wobei Schlüssel der digitalen Signatur des Fahrzeugs (102) und/oder des Nutzers (103) und/oder der digitalen Signatur der Trainingsumgebung (109) und/oder der digitalen Signatur der Softwaretestumgebung (112) von mindestens zwei unterschiedlichen Stellen erzeugt werden, optional wobei die Schlüssel von dem jeweiligen System selbst erzeugt wurden. Verfahren gemäß einem der Ansprüche 1 bis 4, wobei öffentliche Schlüssel zu den digitalen Signaturen in einem gemeinsamen Register (108) gespeichert sind, optional wobei das gemeinsame Register (108) ein mehrfach replizierter und an verschiedenen Orten gespeichertes Register ist, wobei die verschiedenen Replika des Registers (108) synchronisiert sind. Verfahren gemäß einem der Ansprüche 1 bis 5, wobei das Prüfen der digitalen Signaturen (102; 103; 109; 113) das Abfragen eines öffentlichen Schlüssels der jeweiligen Signatur (102; 103; 109; 113) in einem gemeinsamen Register (108) umfasst, optional wobei ein Sender der jeweiligen Daten als valider Sender erachtet wird, wenn mit dem jeweiligen öffentlichen Schlüssel die digitale Signatur verifiziert werden kann. Verfahren gemäß einem der Ansprüche 1 bis 8, wobei das zentrale System (104) ein erstes Cloud-Computing-System ist. Verfahren gemäß Anspruch 2 und optional einem der vorangehenden Ansprüche 3 bis 9, weiter umfassend:
Prüfen der digitalen Signatur des zentralen Systems (109) in einer zweiten Softwaretestumgebung; Testen des trainierten Maschinenlern-Modells (110) und/oder einer zweiten Software-Komponente in einer zweiten Softwaretestumgebung, wenn das zentrale Systems anhand der digitalen Signatur des zentralen Systems (109) als valider Sender eines trainierten Maschinenlern-Modells erkannt wurde;
Signieren des getesteten zweiten Maschinenlern-Modells und/oder der Software- Komponente mit einer digitalen Signatur der zweiten Softwaretestumgebung;
Bereitstellen des getesteten zweiten trainierten Maschinenlern-Modells und/oder der Software- Komponente mit der digitalen Signatur der zweiten Softwaretestumgebung an eine Steuereinheit eines weiteren Fahrzeugs (120). Verfahren gemäß einem der vorangehenden Ansprüche 1 bis 10, wobei das Software-Update über eine Luftschnittstelle an das Fahrzeug (120) bereitgestellt wird. Verfahren gemäß einem der vorangehenden Ansprüche 1 bis 11 , weiter umfassend:
Empfangen des Software-Updates mit einer digitalen Signatur der Softwaretestumgebung (113) und/oder einer digitalen Signatur der Trainingsumgebung (109);
Prüfen, ob die Softwaretestumgebung (112) und/oder die Trainingsumgebung valide Sender von Software- Updates sind; und
Aktualisieren einer Software-Komponente des weiteren Fahrzeugs (120) anhand des Software- Updates. Verfahren gemäß einem der Ansprüche 1 bis 12, weiter umfassend:
Signieren der Fahrzeugfelddaten (105) durch den Nutzer (107) des Fahrzeugs (101) mit der mindestens einen digitalen Signatur des Fahrzeugs (102) und/oder des Nutzers (103); und
Senden der signierten Fahrzeugfelddaten (105) an das zentrale System (104). Computer-System, das dazu ausgelegt ist, die Verfahren gemäß einem der vorangehenden Ansprüche 1 bis 13 auszuführen.
PCT/EP2023/063318 2022-05-17 2023-05-17 Update einer software eines fahrzeugs auf basis von fahrzeugfelddaten WO2023222794A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022204862.8 2022-05-17
DE102022204862.8A DE102022204862A1 (de) 2022-05-17 2022-05-17 Update einer Software eines Fahrzeugs auf Basis von Fahrzeugfelddaten

Publications (1)

Publication Number Publication Date
WO2023222794A1 true WO2023222794A1 (de) 2023-11-23

Family

ID=86609852

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/063318 WO2023222794A1 (de) 2022-05-17 2023-05-17 Update einer software eines fahrzeugs auf basis von fahrzeugfelddaten

Country Status (2)

Country Link
DE (1) DE102022204862A1 (de)
WO (1) WO2023222794A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190303759A1 (en) * 2018-03-27 2019-10-03 Nvidia Corporation Training, testing, and verifying autonomous machines using simulated environments
US20220126864A1 (en) * 2019-03-29 2022-04-28 Intel Corporation Autonomous vehicle system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190303759A1 (en) * 2018-03-27 2019-10-03 Nvidia Corporation Training, testing, and verifying autonomous machines using simulated environments
US20220126864A1 (en) * 2019-03-29 2022-04-28 Intel Corporation Autonomous vehicle system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Digital signature - Wikipedia", 18 November 2020 (2020-11-18), pages 1 - 12, XP055809674, Retrieved from the Internet <URL:https://en.wikipedia.org/w/index.php?title=Digital_signature&oldid=989280543> [retrieved on 20210601] *

Also Published As

Publication number Publication date
DE102022204862A1 (de) 2023-11-23

Similar Documents

Publication Publication Date Title
EP3200428B1 (de) Computerimplementiertes verfahren zur implementierung einer v2x-anwendung
DE102017116017A1 (de) Kraftfahrzeug-Sensorvorrichtung mit mehreren Sensoreinheiten und mehreren neuronalen Netzen zum Erzeugen einer kombinierten Repräsentation einer Umgebung
DE102017215552A1 (de) Plausibilisierung der Objekterkennung für Fahrassistenzsysteme
EP3688742A1 (de) System zur erzeugung und/oder aktualisierung eines digitalen modells einer digitalen karte
DE102015004128A1 (de) Verfahren und System zum Testen cloud-basierter Anwendungen und Dienste in einer Produktionsumgebung unter Verwendung von getrennten Back-End-Systemen
DE102012206037A1 (de) Lernverfahren zur automatisierten Erkennung von Verkehrszeichen, Verfahren zur Bestimmung eines aktualisierten Parametersatzes für eine Klassifikation von einem Verkehrszeichen und Verkehrszeichenerkennungssystem
WO2014032660A1 (de) Verfahren zur elektronischen erkennung von verkehrszeichen
DE102019218613A1 (de) Objektklassifizierungsverfahren, Objektklassifizierungsschaltung, Kraftfahrzeug
DE102020007072A1 (de) Verfahren zur Datenerhebung über eine Mehrzahl von verbundenen Diensteanbietern
DE102017201796A1 (de) Steuervorrichtung zum Ermitteln einer Eigenbewegung eines Kraftfahrzeugs sowie Kraftfahrzeug und Verfahren zum Bereitstellen der Steuervorrichtung
DE102017116016A1 (de) Kraftfahrzeug-Sensorvorrichtung mit mehreren Sensoreinheiten und einem neuronalen Netz zum Erzeugen einer integrierten Repräsentation einer Umgebung
WO2023222794A1 (de) Update einer software eines fahrzeugs auf basis von fahrzeugfelddaten
DE102019203205A1 (de) Verfahren zum Auswerten von Fahrzeugdaten sowie Fahrzeugdatenauswertesystem zum Durchführen eines derartigen Verfahrens
DE102022001720B3 (de) Verfahren zur Anonymisierung von Fahrzeugdaten
DE102018007976A1 (de) Vorrichtung und Verfahren zum Simulieren eines Fahrzeugs
DE102017219269A1 (de) Klassifizierung mit automatischer Auswahl aussichtsreicher Lerndaten
DE102020213057A1 (de) Verfahren und Vorrichtung zum Überprüfen eines beim teilautomatisierten oder vollautomatisierten Steuern eines Fahrzeugs verwendeten KI-basierten Informationsverarbeitungssystems
DE102020203514A1 (de) Verfahren zur Erzeugung von Trainingsdaten, Fahrzeug und Trainingssystem
DE102018216036A1 (de) Verfahren zum Ausführen einer Applikation in einem Fahrzeug, Fahrzeugsystem, Computerprogramm und Datenträgersignal
DE102019208864A1 (de) Erkennungssystem, Arbeitsverfahren und Trainingsverfahren
DE102018221625A1 (de) Transfer von Zusatzinformation zwischen Kamerasystemen
DE102019219667B3 (de) Computerprogrammprodukt für ein Peer-to-Peer Computernetzwerk
DE102021126378A1 (de) Verfahren und Steueranordnung für das Verbundtraining einer Fahrzeugflotte
DE102022208614A1 (de) Rekonstruktion von Trainings-Beispielen im föderierten Training neuronaler Netzwerke
DE102021125001A1 (de) Statistische Systemvalidierung von Fahrunterstützungssystemen

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23727537

Country of ref document: EP

Kind code of ref document: A1