WO2023025572A1 - Verfahren zum betreiben eines fahrzeugsteuergeräts - Google Patents

Verfahren zum betreiben eines fahrzeugsteuergeräts Download PDF

Info

Publication number
WO2023025572A1
WO2023025572A1 PCT/EP2022/072127 EP2022072127W WO2023025572A1 WO 2023025572 A1 WO2023025572 A1 WO 2023025572A1 EP 2022072127 W EP2022072127 W EP 2022072127W WO 2023025572 A1 WO2023025572 A1 WO 2023025572A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
sandbox
tested
data
regular
Prior art date
Application number
PCT/EP2022/072127
Other languages
English (en)
French (fr)
Inventor
Sebastian Kirsch
Jan PEPKE
Dimitrios Stavrianos
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 WO2023025572A1 publication Critical patent/WO2023025572A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0428—Safety, monitoring
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0256—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults injecting test signals and analyzing monitored process response, e.g. injecting the test signal while interrupting the normal operation of the monitored system; superimposing the test signal onto a control signal during normal operation of the monitored system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading

Definitions

  • the present invention relates to a method for operating a vehicle control device and a vehicle control device and a computer program for its implementation.
  • Modern vehicles have more and more functionalities that are provided by software on control devices, in particular also so-called central vehicle computers (these are particularly powerful computing systems that can cover a number of different functionalities).
  • the invention deals with the operation of a vehicle control device or with such a vehicle control device.
  • So-called embedded control devices or embedded control devices or systems are often also used here, because they are intended or set up for specific tasks in, for example, a higher-level system or a technical context such as a vehicle.
  • the computer i.e. the control unit, takes over, e.g. monitoring monitoring, control or regulation functions and/or is responsible for a form of data or signal processing.
  • a vehicle control device will be spoken of in general in this context. However, this should not only be understood to mean simple control devices for only individual or a few functions, but also so-called central vehicle computers which carry out a large number of functions, in particular also computation-intensive functions.
  • Simulative approaches can address some of the points mentioned, but do not cover them completely.
  • the present invention enables continuous learning from the field (i.e. the control units used in series operation) coupled with a flexible solution to verify and continuously improve new functions of an application or software both in the development phase and in series operation, without actively intervene in the current state of the system.
  • a regular application or software for regular operation of the vehicle control unit is performed.
  • This at least one regular application should in particular include the functions that are customary for a vehicle control unit, such as brake control functions in an ESP control unit.
  • other applications or functions such as engine control functions or driver assistance functions such as distance and/or speed control are also conceivable.
  • functions or algorithms based on artificial intelligence or machine learning methods, possibly also using artificial neural networks, are also conceivable. In general, these can be functions that have already been used up to now.
  • a sandbox i.e. an isolated environment within which every measure has no effect on the rest of the vehicle control unit and the external environment, is now provided on a second partition of the vehicle control unit, in which an application to be tested is executed.
  • the application to be tested can be, for example, an updated version of a regular application or part of it, but it can also be new or changed functions for the vehicle control unit.
  • sandbox now allows certain special features, for example in the runtime environment of a software or the local working copy of a software module stored in a version control system.
  • the application or software to be tested is shielded from the rest of the system, the regular application for regular operation, placed in the sandbox, so to speak (hence the common term "sandbox"), in which it cannot cause any damage and, if necessary, the effects of the Software can be recorded.
  • the second partition on the vehicle control unit is also separated from the first partition, which provides the sandbox.
  • Such a separation can be done, for example, by assigning the physical or logical memory to the respective partition. On the other hand, this can be done, for example, by "read only access” for the "shadow mode partition", ie the partition on which the sandbox is running. In other words, with a typical vehicle control device, an additional partition can be added as this second partition, on which the sandbox is then provided. While the first partition usually has a high security level, such as ASIL-D or even an ASIL level (ASIL stands for "Automotive Integrity Safety Level”), the second partition can have a lower security level, e.g. a lower ASIL level or just the so-called QM level.
  • the sandbox (on the second partition) is provided in such a way that read access to the application for normal operation is possible, so that signals and/or data used by the application to be tested in normal operation are also received and processed can.
  • the regular application can first be configured for this purpose, for example, so that it (also) transmits the necessary signals and/or data to the sandbox or the application to be tested or allows them to be read.
  • the application to be tested can thus use all the necessary and customary signals that the regular application also uses or must use, or at least those that are necessary for the test.
  • These signals can be received externally from the vehicle control unit or the regular application, e.g. from another control unit or a sensor. However, it can also be understood to mean signals or other data occurring when the regular application is executed.
  • the sandbox is operated in such a way that no write access to the regular application (or the first partition) is possible.
  • This prevents unwanted interventions in regular operation so that in the event of problems or errors in the application to be tested or in the sandbox, the actual functions of the vehicle control unit are not restricted.
  • the enabling of these approaches for embedded control devices or vehicle control devices in general brings with it decisive advantages. Development cycles for software or applications for such vehicle control units are becoming shorter due to the possibility of testing by the user (ie, for example, in regular operation in the field).
  • the software can be continuously further developed in the field and data-based algorithms can be iteratively developed and released in short steps. If an error occurs due to poorly developed software (e.g.
  • the (entire) control unit does not have to be switched to emergency mode or switched off; only the application under test in the sandbox is affected.
  • the vehicle can continue to be operated with its primary software.
  • OTA updates OTA stands for "Over-The-Air"
  • the sandboxes can be updated quickly.
  • Interfaces of the software parts that run in (or as) the sandbox are designed in such a way that they enable operation as a sandbox, i.e. e.g. no write access from the sandbox (second partition) to the rest of the software (regular application, first partition).
  • the sandbox parts do not intervene in the active execution, in particular in the control of the actuators or in the functional calculation rules. Errors in the sandbox or the application to be tested lead in particular to a deactivation of the sandbox, but not the primary software, i.e. the regular application.
  • the sandbox can also be exchanged independently of the rest of the software (i.e. the regular application on the first partition).
  • the sandbox can also be activated and deactivated externally.
  • the sandbox can access the internal control unit signals or data, process them and transmit the data and/or signals and/or parameters that occur directly or indirectly to a further processing unit for analysis, etc.
  • the further computing unit can be, in particular, a computing system external to the vehicle, for example in a computing center.
  • the data can be transmitted wirelessly, for example.
  • the transmission can take place via the regular application, which is typically integrated into an on-board network with other control units anyway, e.g. also one for wireless communication.
  • Pre-processing can then also take place in the regular application, so that the data can be brought into a suitable format for transmission, for example. This enables further analysis of the signals, e.g.
  • the data, signals and parameters received can then be analyzed on the computing unit, e.g. the functionality can be checked for anomalies.
  • the parameters can be optimized and optimized parameters can be transferred back to the sandbox for further use. In this way, iterative improvement can take place. In this case, therefore, updated or optimized data for further tests are received from the application to be tested by the processing unit. It is also conceivable that an updated application under test will be received (which will then replace the existing ones). In principle, this is also possible without optimizing the data previously transmitted to the processing unit; for example, new data obtained elsewhere can be transferred to the sandbox.
  • Another sandbox can also participate in the transfer.
  • it can be provided that as part of the execution of the application to be tested Application data and / or signals and / or parameters (P) are transferred to another sandbox from which write access to the regular application is possible.
  • Trigger conditions can preferably also be configured. Triggers or trigger conditions are understood to mean, for example, signal-based triggers that serve to pre-process the data generated in the sandbox or enable it. This reduces the transmission rate, e.g. to the cloud. These triggers can also be used to activate the sandbox, i.e. to perform the calculation in the sandbox. This trigger-based activation allows the control unit to be utilized as required.
  • a vehicle control unit according to the invention is set up, in particular in terms of programming, to carry out a method according to the invention.
  • Suitable data carriers for providing the computer program are, in particular, magnetic, optical and electrical memories, such as hard drives, flash memories, EEPROMs, DVDs, etc. It is also possible to download a program via computer networks (Internet, intranet, etc.).
  • FIG. 1 schematically shows a vehicle with vehicle control devices to explain a method according to the invention in a preferred embodiment.
  • FIG. 2 schematically shows a structure of a vehicle control device for further explanation of a method according to the invention in a preferred embodiment.
  • FIG. 1 shows a vehicle 100 with vehicle control devices 110, 120, 130 to explain a method according to the invention in a preferred embodiment.
  • vehicle control unit 110 is what is known as a central vehicle computer, and vehicle control units 120, 130 are simple or regular control units.
  • the three vehicle control units 110, 120 and 130 are connected to one another for data transmission by means of a communication medium 150 such as a CAN bus.
  • a sensor 140 and an actuator 142 are connected to vehicle control unit 120 and vehicle control unit 130 is set up for wireless communication.
  • a non-vehicle computing system 160 e.g. a backend, also within the framework of a so-called cloud, is shown as a computing unit, which is also (typically indirectly) set up for wireless communication and can use it to wirelessly exchange data with the vehicle control unit 130, for example. This can be done, for example, via mobile communications.
  • the other vehicle control units 110, 120 can also (indirectly) wirelessly exchange data with the computer system 160 external to the vehicle via the vehicle control unit 130.
  • FIG. 2 shows a schematic representation of a structure of vehicle control unit 110 for further and detailed explanation of a method according to the invention in a preferred embodiment. It goes without saying that vehicle control unit 110 is selected here only as an example; one or all of the other vehicle control units shown can also be designed accordingly.
  • the off-board computing system 160 is also shown.
  • the vehicle controller 110 has two partitions.
  • a first partition 112 represents, for example, a partition with a certain security level, on which a regular application (software) for the regular operation of the vehicle control device is also executed.
  • a second partition 114 has a lower (or no) security level and is used to provide one or more sandboxes, as will be discussed below.
  • the partitions 112, 114 can in particular be software levels in the vehicle control unit, which are stored in different areas of the volatile or non-volatile memory. From a sandbox provided on the second partition 114 for an application to be tested, the first partition 112 or the regular application can in particular only be accessed for reading, but not for writing.
  • the sandbox is a protected area in microcontroller (pC) and microprocessor (pP)-based control units (ECUs) in which the software, features, algorithms and services are passive, i.e. parallel to the functional software (homologated operating software), without affecting them to have, can be operated.
  • this requires a "freedom from interference" of the sandbox in relation to the functional software.
  • partitioning parts of the volatile and/or non-volatile memory are permanently assigned to the functional partition (homologated operating software) and the sandbox partition. This separation means that the operation of the homologated software is not affected by the sandbox.
  • the sandbox can also be changed, e.g. renewed (flashed), partially and independently of the homologated software.
  • the application AT to be tested and a configuration K can be provided on the non-vehicle computing system 160, e.g. by a developer, after the application AT to be tested has initially been developed, for example.
  • the configuration K is then transferred to the vehicle control device 110 and there to the first partition 112 or to the regular application AR executed there.
  • a step 202 the application AT to be tested is transferred to the vehicle control device 110 and there to the second partition 114 or the sandbox Si provided there.
  • the transmission in both steps 200, 202 can, for example, take place wirelessly as explained with reference to FIG. It is conceivable that this will take place as part of an OTA update or other security tests.
  • a configuration is carried out in the regular application AR.
  • the regular application AR is thus configured, for example, to provide certain signals and/or data D that it uses during operation (and for this purpose receives, processes, etc. from sensors, for example) for the application AT to be tested, so that it can read them out .
  • the application to be tested then reads out the necessary signals or data D during operation.
  • these data and/or signals and/or parameters P are then transferred to the regular application AR in step 206 .
  • This requires write access from the further sandbox S2 to the regular application AR or the first partition 112, but access by the testing application itself is ruled out by a separation from the first sandbox S1.
  • the sandbox S2 can “simulate” a data sink for the sandbox S1, for example a control device to which the application to be tested usually outputs its results.
  • step 208 they are then processed or pre-processed.
  • pre-processing the data generated in the sandbox, the relevant information is generated with high-resolution data.
  • the pre-processing increases the information content of the sandbox data volume to be transmitted. This results in an improved data transfer rate to the cloud.
  • This is implemented e.g. by triggers (configurable) as already mentioned. These triggers can also be used to activate the sandbox, i.e. to perform the calculation in the sandbox. Trigger-based activation allows the control unit to be utilized as needed.
  • the data and/or signals and/or parameters P are then transmitted from the regular application AR in step 210 to the computing system 160 external to the vehicle, for example again wirelessly.
  • these data and/or signals and/or parameters P are then analyzed there for the functionality of the application to be tested, for example with regard to the detection of anomalies or errors.
  • the application to be tested can then be optimized, which is then transferred in step 216 in the same way as in step 202 to the vehicle control device 110 and there to the second partition 114 or the sandbox Si provided there. If necessary, a new configuration can also be transmitted as in step 200.
  • the procedure described can then run again, in particular also with further iterations.
  • the invention thus makes it possible in particular to test new software directly in the field, that is to say on a very large number of control devices (typically several million), but without impairing regular operation in the field. If the application to be tested is considered complete, it can also replace the regular application or part of it as part of an update, or be used in addition, especially on the first partition.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • Control By Computers (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Betreiben eines Fahrzeugsteuergeräts (110), bei dem auf einer ersten Partition (112) eine reguläre Anwendung (AT) für einen Regelbetrieb des Fahrzeugsteuergeräts (110) ausgeführt wird, und bei dem auf einer zweiten Partition (114) eine Sandbox (S1) bereitgestellt wird, in der eine zu testende Anwendung (AT) ausgeführt wird, wobei die Sandbox (S1) derart bereitgestellt wird, dass daraus ein lesender Zugriff auf die reguläre Anwendung (AR) möglich ist, wobei von der zu testenden Anwendung (AT) bei der regulären Anwendung (AR) im Regelbetrieb verwendete Signale und/oder Daten (D) erhal- ten und verarbeitet werden, sowie ein entsprechendes Fahrzeugsteuergerät (110).

Description

Beschreibung
Titel
Verfahren zum Betreiben eines Fahrzeugsteuergeräts
Die vorliegende Erfindung betrifft ein Verfahren zum Betreiben eines Fahrzeugsteuergeräts sowie ein Fahrzeugsteuergerät und ein Computerprogramm zu dessen Durchführung.
Hintergrund der Erfindung
Moderne Fahrzeuge verfügen über immer mehr Funktionalitäten, die durch Software auf Steuergeräten, insbesondere auch sog. Fahrzeugzentralrechnern (dabei handelt es sich um besonders leistungsstarke Rechensysteme, die mehrere verschiedene Funktionalitäten abdecken können) bereitgestellt werden.
Offenbarung der Erfindung
Erfindungsgemäß werden ein Verfahren zum Betreiben eines Fahrzeugsteuergeräts sowie ein Fahrzeugsteuergerät und ein Computerprogramm zu dessen Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
Die Erfindung beschäftigt sich mit dem Betreiben eines Fahrzeugsteuergeräts bzw. mit einem solchen Fahrzeugsteuergerät. Hierbei ist oftmals auch von sog. Embedded-Steuergeräten bzw. eingebetteten Steuergeräten oder Systemen die Rede, weil sie für bestimmte Aufgaben in z.B. einem übergeordneten System oder einen technischen Kontext wie einem Fahrzeug vorgesehen bzw. eingerichtet sind. Dabei übernimmt der Rechner, also das Steuergerät, z.B. Überwa- chungs-, Steuerungs- oder Regelfunktionen und/oder ist für eine Form der Daten- bzw. Signalverarbeitung zuständig. Nachfolgend soll in diesem Zusammenhang allgemein von einem Fahrzeugsteuergerät gesprochen werden. Darunter sollen aber nicht nur einfache Steuergeräte für nur einzelne oder wenige Funktionen verstanden werden, sondern auch sog. Fahrzeugzentralrechner, die eine Vielzahl von Funktionen, insbesondere auch rechenintensive Funktionen durchführen.
Bei modernen Fahrzeugen nimmt, wie erwähnt, die Anzahl an Funktionalitäten, die durch Software auf einem Steuergerät bzw. generell auf Steuergeräten ausgeführt werden, immer weiter zu. Insbesondere steigt damit bei solchen softwaregetriebenen Systemen im Bereich Automotive die Komplexität der Software exponentiell. Gleichzeitig wird es aber in der Regel zunehmend schwieriger, funktionale Anteile der Software anhand von realen Bedingungen zu verifizieren, da zum Zeitpunkt der Verifikation oftmals die finale E/E-Architektur der Fahrzeuge (noch) nicht zur Verfügung steht. Ebenso sind Entwicklungsfahrzeuge selbst nicht immer mit allen notwendigen Subsystemen (die für nötige Tests nötig wären) ausgestattet und die Weiterentwicklung querabhängiger Subsysteme erfolgt oft parallel zueinander. Oftmals werden auch Annahmen über das Verhalten der Software bzw. des Steuergeräts im Serienansatz getroffen, die sich später als nicht optimal oder gar nicht zutreffend erweisen. Änderungen insbesondere in den erwähnten Embedded-Systemen benötigen dabei aufwendige Regressionstests.
Simulative Ansätze (z.B. über eine spezielle Software oder Testsoftware, oder auch HIL, sog. "Hardware in the loop") können einige der genannten Punkte adressieren, jedoch nicht vollständig abdecken. Die vorliegende Erfindung hingegen ermöglicht ein kontinuierliches Lernen aus dem Feld (d.h. den im Serienbetrieb im Einsatz befindlichen Steuergeräten) gepaart mit einer flexiblen Lösung, neue Funktionen einer Anwendung oder Software sowohl in der Entwicklungsphase als auch im Serienbetrieb zu verifizieren und kontinuierlich zu verbessern, ohne in den Ist-Zustand des Systems aktiv einzugreifen. Um dies zu erreichen, wird vorgeschlagen, dass beim Betrieb des Fahrzeugsteuergeräts auf einer ersten Partition (unter einer Partition ist insbesondere ein Teil eines geeigneten physischen oder logischen flüchtigen oder nichtflüchtigen Speichers zu verstehen) eine reguläre Anwendung (bzw. Software) für einen Regelbetrieb des Fahrzeugsteuergeräts ausgeführt wird. Diese wenigstens eine reguläre Anwendung soll dabei insbesondere die für ein Fahrzeugsteuergerät üblichen Funktionen umfassen wie z.B. Bremsregelfunktionen bei einem ESP- Steuergerät. Denkbar sind aber auch andere Anwendungen oder Funktionen wie z.B. Motorsteuersteuerungsfunktionen oder Fahrerassistenzfunktionen wie Abstands- und/oder Geschwindigkeitsregelung. Denkbar sind insbesondere auch Funktion oder Algorithmen, die auf künstlicher Intelligenz oder Maschinenlernmethoden basierend, ggf. auch unter Verwendung künstlicher neuronaler Netze. Generell kann es sich dabei um bisher schon übliche Funktionen handeln.
Zusätzlich wird nun auf einer zweiten Partition des Fahrzeugsteuergeräts eine Sandbox, d.h. eine isolierte Umgebung, innerhalb derer jede Maßnahme keine Auswirkung auf das übrige Fahrzeugsteuergerät und die äußere Umgebung hat, bereitgestellt, in der eine zu testende Anwendung ausgeführt wird. Bei der zu testenden Anwendung kann es sich z.B. um eine aktualisierte Version einer regulären Anwendung oder eines Teils davon handeln, ebenso aber auch um neue oder veränderte Funktionen für das Fahrzeugsteuergerät.
Beim Testen von Software oder Anwendungen sollte darauf geachtet werden, dass das System, auf dem getestet wird, hier das Fahrzeugsteuergerät, durch diese zu testende Anwendung nicht verändert, gestört oder in irgendeiner Form beschädigt wird. Eine sog. Sandbox erlaubt nun gewisse Besonderheiten in z.B. der Laufzeitumgebung einer Software oder der lokalen Arbeitskopie eines in einem Versionskontrollsystem abgelegten Software-Moduls. Die zu testende Anwendung bzw. Software wird vom Rest des Systems, der regulären Anwendung für den Regelbetrieb, abgeschirmt, sozusagen in den Sandkasten (daher der gebräuchliche Begriff "Sandbox") gesetzt, in dem sie keinen Schaden anrichten kann und ggf. die Wirkungen der Software aufgezeichnet werden können. In diesem Sinne ist auch die zweite Partition auf dem Fahrzeugsteuergerät von der ersten Partition entsprechend getrennt, womit die Sandbox bereitgestellt wird. Eine solche Trennung kann zum einen z.B. über die Zuweisung des physischen oder logischen Speichers auf die jeweilige Partition erfolgen. Zum anderen kann dies z.B. durch einen "read only access" (Zugriff nur für Lesen) für die "Shadow Mode Partition", d.h. die Partition, auf der die Sandbox läuft, erfolgen. Mit anderen Worten kann bei einem üblichen Fahrzeugsteuergerät eine zusätzliche Partition als diese zweite Partition hinzugefügt werden, auf der die Sandbox dann bereitgestellt wird. Während die erste Partition dabei in der Regel eine hohe Sicherheitsstufe hat wie z.B. ASIL-D oder überhaupt eine ASIL-Stufe (ASIL steht dabei für "Automotive Integrity Safety Level"), kann die zweite Partition mit einer geringeren Sicherheitsstufe, z.B. einer geringeren ASIL-Stufe oder einfach nur der sog. QM-Stufe betrieben werden.
Die Sandbox (auf der zweiten Partition) wird dabei derart bereitgestellt, dass daraus ein lesender Zugriff auf die Anwendung für den Regelbetrieb möglich ist, sodass auch von der zu testenden Anwendung von der regulären Anwendung im Regelbetrieb verwendete Signale und/oder Daten erhalten und verarbeitet werden können. Die reguläre Anwendung kann hierfür zunächst konfiguriert werden, sodass sie z.B. die nötigen Signale und/oder Daten (auch) an die Sandbox bzw. die zu testende Anwendung übermittelt bzw. deren Lesen erlaubt. Damit kann die zu testende Anwendung also alle nötigen und üblichen Signale, die auch die reguläre Anwendung verwendet bzw. verwenden muss, verwenden oder zumindest diejenigen, die zum Test nötig sind. Diese Signale wiederum können vom Fahrzeugsteuergerät bzw. der regulären Anwendung von extern, z.B. einem anderen Steuergerät oder einem Sensor erhalten werden. Ebenso können darunter aber auch bei Ausführung der regulären Anwendung anfallende Signale oder anderweitige Daten verstanden werden.
Insbesondere wird die Sandbox derart betrieben, dass daraus kein schreibender Zugriff auf die reguläre Anwendung (bzw. die erste Partition) möglich ist. Dies verhindert unerwünschte Eingriffe in den Regelbetrieb, sodass im Falle von Problemen oder Fehlern bei der zu testenden Anwendung bzw. in der Sandbox keine Einschränkung der eigentlichen Funktionen des Fahrzeugsteuergeräts folgt. Insbesondere die Ermöglichung dieser Ansätze für Embedded-Steuergeräte bzw. allgemein Fahrzeugsteuergerät bringt entscheidende Vorteile mit sich. So werden Entwicklungszyklen für Software bzw. Anwendungen für solche Fahrzeugsteuergeräte aufgrund der Testmöglichkeit beim Nutzer (also z.B. im Regelbetrieb im Feld) kürzer. Die Software kann kontinuierlich im Feld weiterentwickelt werden und datenbasierte Algorithmen können in kurzen Schritten iterativ entwickelt und freigeben werden. Wenn es zu einem Fehler aufgrund einer schlecht entwickelten Software (z.B. O-Teiler) kommt, muss nicht das (ganze) Steuergerät in den Notbetrieb versetzt oder abgeschaltet werden; es ist nur die zu testende Anwendung in der Sandbox betroffen. Das Fahrzeug kann mit seiner primären Software weiterbetrieben werden. In Kombination mit OTA-Updates (OTA steht für "Over-The-Air") können die Sandboxen schnell aktualisiert werden.
Heutige, weit verbreitete Lösungen im Bereich der Fahrzeugsteuergeräte bzw. Embedded-Steuergeräte sind eher monolithischer Art, d.h. die Änderung einer dedizierten Funktion resultiert in einer neuen Gesamtanwendung bzw. Gesamtsoftware, die verifiziert und ausgerollt wird. Demgegenüber schafft das vorgeschlagene Vorgehen die Möglichkeit, den monolithischen Ansatz zu durchbrechen, indem geänderte und/oder neue Funktionen parallel zu laufender Software ausgerollt und verifiziert werden können (durch die Verwendung der Sandbox). Die Verifikation der geänderten Funktionen wird mit im Feld erhobenen Daten gestützt, und die Erhebung der Felddaten ihrerseits kann ebenfalls als Sandbox laufen und somit ein flexibles Gesamtkonstrukt entstehen.
Durch die Sandbox in einem Fahrzeugsteuergerät besteht kein Einfluss der zu testenden Anwendung und etwaiger dabei auftretender Probleme hinsichtlich funktionaler Sicherheit. Schnittstellen der Software-Anteile, die in der (bzw. als) Sandbox laufen, sind insbesondere derart gestaltet, dass sie den Betrieb als Sandbox ermöglichen, d.h. z.B., dass keine schreibenden Zugriffe aus der Sandbox (zweite Partition) in den Rest der Software (reguläre Anwendung, erste Partition) erfolgen. Die Sandbox-Anteile greifen nicht in die aktive Ausführung, insbesondre Ansteuerung der Aktorik oder in die funktionalen Rechenvorschriften ein. Fehler in der Sandbox bzw. der zu testenden Anwendung führen insbesondere zu einer Deaktivierung der Sandbox, nicht aber der primären Software, also der regulären Anwendung. Die Sandbox kann insbesondere auch unabhängig vom Rest der Software (also der regulären Anwendung auf der ersten Partition) ausgetauscht werden. Zweckmäßigerweise kann die Sandbox auch von außen aktiviert und deaktiviert werden.
Insbesondere im Serienbetrieb kann die Sandbox auf die steuergeräteinternen Signale bzw. Daten zugreifen, diese verarbeiten und dabei anfallende Daten und/oder Signale und/oder Parameter mittelbar oder unmittelbar zur Analyse usw. an eine weitere Recheneinheit übertragen. Bei der weiteren Recheneinheit kann es sich insbesondere um ein fahrzeugfremdes Rechensystem, beispielsweise in einem Rechenzentrum, handeln. Hierzu können die anfallenden Daten z.B. drahtlos übertragen werden. Die Übertragung kann insbesondere über die reguläre Anwendung erfolgen, die typischerweise ohnehin in ein Bordnetz mit weiteren Steuergeräten eingebunden ist, z.B. auch eines zur drahtlosen Kommunikation. In der regulären Anwendung kann dann auch eine Vorverarbeitung erfolgen, sodass die Daten z.B. in ein geeignetes Format zum Übertragen gebracht werden. Dies ermöglicht die weitere Analyse der Signale z.B. in einem sog. Backend-System oder sonstigem fahrzeugfremdem Rechensystem bei gleichzeitiger Reduktion des hierfür notwendigen Datenstromes. Auf der Recheneinheit können die erhaltenen Daten, Signale und Parameter dann analysiert werden, z.B. kann die Funktionalität auf Anomalien hin überprüft werden. Weiterhin können die Parameter optimiert werden und optimierte Parameter wieder an die Sandbox zur weiteren Verwendung übertragen werden. Auf diese Weise kann eine iterative Verbesserung stattfinden. Von der zu testenden Anwendung werden in diesem Fall also von der Recheneinheit aktualisierte oder optimierte Daten für weitere Tests erhalten. Denkbar ist auch, dass eine aktualisierte zu testende Anwendung erhalten wird (die die vorhandenen dann ersetzt). Dies ist grundsätzlich auch ohne die Optimierung der zuvor an die Recheneinheit übertragenen Daten möglich; so können z.B. anderweitig gewonnene, neue Daten auf die Sandbox übertragen werden.
Bei der Übertragung kann auch eine weitere Sandbox mitwirken. Insbesondere kann vorgesehen sein, dass im Rahmen der Ausführung der zu testenden An- wendung anfallende Daten und/oder Signale und/oder Parameter (P) in eine weitere Sandbox übertragen werden, aus der ein schreibender Zugriff auf die reguläre Anwendung möglich ist.
Es können bevorzugt auch Triggerbedingungen konfiguriert werden. Unter Trigger oder Triggerbedingungen sind z.B. signalbasierte Auslöser zu verstehen, die zur Vorprozessierung der in der Sandbox generierten Daten dienen oder diese ermöglichen. Dadurch wird die Übertragungsrate z.B. zur Cloud reduziert. Diese Trigger können ebenfalls verwendet werden, um die Sandbox zu aktivieren, d.h. die Berechnung in der Sandbox durchzuführen. Durch diese triggerbasierte Aktivierung kann die Auslastung des Steuergeräts bedarfsgerecht erfolgen.
Ein erfindungsgemäßes Fahrzeugsteuergerät, ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Steuergerät noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Geeignete Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
Kurze Beschreibung der Zeichnungen Figur 1 zeigt schematisch ein Fahrzeug mit Fahrzeugsteuergeräten zu Erläuterung eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform.
Figur 2 zeigt schematisch einen Aufbau eines Fahrzeugsteuergeräts zur weiteren Erläuterung eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform.
Ausführungsform(en) der Erfindung
In Figur 1 ist schematisch ein Fahrzeug 100 mit Fahrzeugsteuergeräten 110, 120, 130 zur Erläuterung eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform dargestellt. Beispielhaft handelt es sich bei dem Fahrzeugsteuergerät 110 um einen sog. Fahrzeugzentralrechner, bei den Fahrzeugsteuergeräten 120, 130 um einfache bzw. reguläre Steuergeräte. Die drei Fahrzeugsteuergeräte 110, 120 und 130 sind mittels eines Kommunikationsmediums 150 wie z.B. einem CAN-Bus, datenübertragend miteinander verbunden.
Beispielhaft sind an das Fahrzeugsteuergerät 120 ein Sensor 140 und ein Aktor 142 angeschlossen und das Fahrzeugsteuergerät 130 ist zur drahtlosen Kommunikation eingerichtet. Weiterhin ist als Recheneinheit ein fahrzeugfremdes Rechensystem 160, z.B. ein Backend, auch im Rahmen einer sog. Cloud, gezeigt, das ebenfalls (typischerweise mittelbar) zur drahtlosen Kommunikation eingerichtet ist und darüber z.B. mit dem Fahrzeugsteuergerät 130 drahtlos Daten austauschen kann. Dies kann z.B. über Mobilfunk erfolgen. Über das Fahrzeugsteuergerät 130 können auch die weiteren Fahrzeugsteuergeräte 110, 120 (mittelbar) drahtlos Daten mit dem fahrzeugfremden Rechensystem 160 austauschen.
In Figur 2 ist schematisch ein Aufbau des Fahrzeugsteuergeräts 110 zur weiteren und detaillierten Erläuterung eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform dargestellt. Es versteht sich, dass das Fahrzeugsteuergerät 110 hier nur beispielhaft gewählt ist, ebenso kann eines der anderen gezeigten Fahrzeugsteuergeräte oder können auch alle entsprechend ausgebildet sein. Außerdem ist das fahrzeugfremde Rechensystem 160 gezeigt. Das Fahrzeugsteuergerät 110 weist zwei Partitionen auf. Eine erste Partition 112 stellt z.B. eine Partition mit gewisser Sicherheitsstufe dar, auf der auch eine reguläre Anwendung (Software) für den regulären Betrieb des Fahrzeugsteuergeräts ausgeführt wird.
Eine zweite Partition 114 hat eine geringere (oder keine) Sicherheitsstufe und dient zur Bereitstellung einer oder mehrerer Sandboxen, wie nachfolgend erläutert werden soll. Bei den Partitionen 112, 114 kann es sich insbesondere um Softwareebenen im Fahrzeugsteuergerät handeln, die in unterschiedlichen Bereichen des flüchtigen bzw. nichtflüchtigen Speichers gespeichert sind. Von einer auf der zweiten Partition 114 bereitgestellten Sandbox für eine zu testende Anwendung aus kann insbesondere nur lesend auf die erste Partition 112 bzw. die reguläre Anwendung zugegriffen werden, nicht aber schreibend.
Die Sandbox ist insbesondere ein geschützter Bereich in mikrocontroller(pC)- und mikroprozessor(pP)-basierten Steuergeräten (ECUs), in dem Software, Features, Algorithmen und Services passiv, d.h. parallel zur funktionalen Software (homologierte Betriebssoftware), ohne Auswirkungen auf diese zu haben, betrieben werden kann. Dies erfordert insbesondere ein "Freedom from interference" der Sandbox gegenüber der funktionalen Software. Dies wird einerseits erreicht durch Partitionieren: Teile des flüchtigen und/oder nichtflüchtigen Speichers werden der funktionalen Partition (homologierte Betriebssoftware) und der Sandbox- Partition fest zugewiesen. Diese Separation führt dazu, dass die homologierte Software in ihrem Betrieb nicht von der Sandbox beeinträchtigt wird. Das heißt, die Sandbox kann auch partiell und unabhängig von der homologierten Software verändert, z.B. erneuert (geflasht) werden.
Andererseits kann dies durch eingeschränkte Rechte der Sandbox-Partition erreicht werden: Die Sandbox-Partition wird in Ihrem Funktionsumfang eingeschränkt, um die homologierte Software nicht zu beeinflussen. Dies erfolgt beispielsweise, indem sie nur Leserechte und keine Schreibrecht hat bzw. erhält. Nachfolgend soll nun der Ablauf zum Betrieb des Fahrzeugsteuergeräts 110, insbesondere des Tests einer zu testenden Anwendung bzw. Software darauf, näher erläutert werden.
Auf dem fahrzeugfremden Rechensystem 160 können, z.B. von einem Entwickler, die zu testende Anwendung AT sowie eine Konfiguration K (dabei kann es sich um Konfigurationsdaten handeln) bereitgestellt werden, nachdem die zu testende Anwendung AT zunächst z.B. entwickelt worden ist. Die Konfiguration K wird dann in einem Schritt 200 auf das Fahrzeugsteuergerät 110 und dort die erste Partition 112 bzw. die dort ausgeführte reguläre Anwendung AR übertragen.
Zeitgleich oder auch davor oder danach wird, in einem Schritt 202, die zu testende Anwendung AT auf das Fahrzeugsteuergerät 110 und dort die zweite Partition 114 bzw. die dort bereitgestellte Sandbox Si übertragen. Die Übertragung in beiden Schritten 200, 202 kann z.B. drahtlos wie in Bezug auf Figur 1 erläutert, erfolgen. Denkbar ist dabei, dass dies im Rahmen eines OTA-Updates oder auch sonstiger Absicherungstests erfolgt.
In der regulären Anwendung AR wird in einem Schritt 204, basierend auf der Konfiguration bzw. den Konfigurationsdaten K, eine Konfiguration vorgenommen. Damit wird die reguläre Anwendung AR Z. B. dahingehend konfiguriert, bestimmten Signale und/oder Daten D, die sie während des Betriebs verwendet (und hierfür z.B. von Sensoren erhält, verarbeitet etc.), für die zu testende Anwendung AT bereitzustellen, sodass diese sie auslesen kann. Während des Betriebs liest die zu testende Anwendung dann die nötigen Signale bzw. Daten D aus.
Auf diese Weise wird also ein realer Betrieb mit der zu testenden Anwendung direkt auf dem Fahrzeugsteuergerät 110 simuliert, ohne dass etwaige Fehler oder Probleme in der zu testenden Anwendungen oder Folgen hiervon Auswirkungen auf die reguläre Anwendung AR und damit den regulären Betrieb des Fahrzeugsteuergeräts hätten. Ein schreibender Zugriff der zu testenden Anwendung AT bzw. aus der Sandbox Si auf die reguläre Anwendung bzw. die erste Partition 112 ist nicht möglich. Die reguläre Anwendung AR gibt im Betrieb, insbesondere basierend auf den erhaltenen Signalen, Daten und/oder Signale und/oder Parameter aus, mittels welcher z.B. Aktoren angesteuert oder Informationen übermittelt oder angezeigt werden. Ebenso wird die zu testende Anwendung AT Daten und/oder Signale und/oder Parameter, hier allgemein mit P bezeichnet, erzeugen. Diese werden nun einer weiteren Sandbox S2, die ebenfalls auf der zweiten Partition 114 bereitgestellt ist, übergeben. Diese Daten und/oder Signale und/oder Parameter P werden von dort dann an die reguläre Anwendung AR in Schritt 206 übergeben. Hierzu ist ein schreibender Zugriff aus der weiteren Sandbox S2 auf die reguläre Anwendung AR bzw. die erste Partition 112 nötig, durch eine Trennung von der ersten Sandbox S1 wird aber ein Zugriff der testenden Anwendung selbst ausgeschlossen. Auf diese Weise wird erreicht, dass die von der (ersten) Sandbox S1 erzeugten Daten und dergleichen trotzdem erfasst und weiterverarbeitet werden können. Insbesondere kann die Sandbox S2 für die Sandbox S1 eine Datensenke "simulieren", z.B. ein Steuergerät, an das die zu testende Anwendung üblicherweise ihre Ergebnisse ausgibt.
In Schritt 208 werden sie dann verarbeitet oder vorverarbeitet. Durch die Vorverarbeitung (Vorprozessierung) der in der Sandbox generierte Daten werden die relevanten Information mit hochaufgelösten Daten generiert. Durch die Vorverarbeitung wird der Informationsgehalt des zu übertragenden Sandbox- Datenvolumens erhöht. Dies hat eine verbesserte Datenübertragungsrate in die Cloud zur Folge. Umgesetzt wird dies z.B. durch Trigger (konfigurierbar) wie schon erwähnt. Diese Trigger können ebenfalls verwendet werden, um die Sandbox zu aktivieren, d.h. die Berechnung in der Sandbox durchzuführen. Durch eine triggerbasierte Aktivierung kann eine bedarfsgerechte Auslastung des Steuergeräts erfolgen.
Anschließend werden die Daten und/oder Signale und/oder Parameter P dann von der regulären Anwendung AR in Schritt 210 an das fahrzeugfremde Rechensystem 160 übertragen, z.B. wieder drahtlos. Dort erfolgt dann in Schritt 212 eine Analyse dieser Daten und/oder Signale und/oder Parameter P auf die Funktionalität der zu testenden Anwendung, z.B. hinsichtlich einer Erkennung von Anomalien oder Fehlern. In einem Schritt 214 kann dann eine Optimierung der zu testenden Anwendung erfolgen, die dann in Schritt 216 auf die gleiche Weise wie in Schritt 202 auf das Fahrzeugsteuergerät 110 und dort die zweite Partition 114 bzw. die dort bereit- gestellte Sandbox Si übertragen werden. Falls nötig, kann auch eine neue Konfiguration wie in Schritt 200 übertragen werden. In einer weiteren Iteration 218 kann das beschriebene Vorgehen dann erneut ablaufen, insbesondere auch mit noch weiteren Iterationen. Die Erfindung ermöglicht es damit insbesondere, neue Software direkt im Feld, also auf einer sehr hohen Anzahl an Steuergeräten (ty- pischerweise mehrere Millionen) zu testen, ohne jedoch den regulären Betrieb im Feld zu beeinträchtigen. Wenn die zu testende Anwendung als fertig betrachtet wird, kann sie auch im Rahmen eines Updates die reguläre Anwendung oder einen Teil davon ersetzen oder zusätzlich verwendet werden, dann insbesondere auch auf der ersten Partition.

Claims

Ansprüche
1 . Verfahren zum Betreiben eines Fahrzeugsteuergeräts (110), bei dem auf einer ersten Partition (112) eine reguläre Anwendung (AT) für einen Regelbetrieb des Fahrzeugsteuergeräts (110) ausgeführt wird, und bei dem auf einer zweiten Partition (114) eine Sandbox (Si) bereitgestellt wird, in der eine zu testende Anwendung (AT) ausgeführt wird, wobei die Sandbox (Si) derart bereitgestellt wird, dass daraus ein lesender Zugriff auf die reguläre Anwendung (AR) möglich ist, wobei von der zu testenden Anwendung (AT) Signale und/oder Daten (D), die von der regulären Anwendung (AR) im Regelbetrieb verwendet werden, erhalten und verarbeitet werden.
2. Verfahren nach Anspruch 1 , wobei die Sandbox (Si) derart betrieben wird, dass daraus kein schreibender Zugriff auf die reguläre Anwendung (AR) möglich ist.
3. Verfahren nach Anspruch 1 oder 2, wobei im Rahmen der Ausführung der zu testenden Anwendung (AT) anfallende Daten und/oder Signale und/oder Parameter (P) an eine weitere Recheneinheit (160) übertragen werden.
4. Verfahren nach einem der vorstehenden Ansprüche, wobei im Rahmen der Ausführung der zu testenden Anwendung (AT) anfallende Daten und/oder Signale und/oder Parameter (P) in eine weitere Sandbox (S2) übertragen werden, aus der ein schreibender Zugriff auf die reguläre Anwendung (AR) möglich ist.
5. Verfahren nach Anspruch 3 und 4, wobei die Daten und/oder Signale und/der Parameter (P) von der weiteren Sandbox (S2) an die weitere Recheneinheit (160) übertragen werden. Verfahren nach Anspruch 5, wobei die Daten und/oder Signale und/der Parameter (P) von der weiteren Sandbox (S2) an die reguläre Anwendung (AR) übertragen werden, und wobei die Daten und/oder Signale und/der Parameter (P) von der regulären Anwendung an die weitere Recheneinheit (160) Analyse übertragen werden. Verfahren nach einem der vorstehenden Ansprüche, wobei von der zu testenden Anwendung (AT) von einer Recheneinheit (160) aktualisierte oder optimierte Daten für weitere Tests erhalten werden, und/oder wobei von der Recheneinheit (160) eine aktualisierte oder optimierte zu testende Anwendung erhalten wird. Verfahren nach einem der vorstehenden Ansprüche, wobei die reguläre Anwendung (AR) vor Beginn des Tests der zu testenden Anwendung (AT) zur Bereitstellung von Daten an die Sandbox (S1) konfiguriert (200, 204) wird. Verfahren nach einem der vorstehenden Ansprüche, wobei bei Auftreten eines Fehlers in der zu testenden Anwendung (AT) die Sandbox (S1) deaktiviert wird und die reguläre Anwendung (AR) weiterbetrieben wird. Verfahren nach einem der vorstehenden Ansprüche, wobei die erste Partition (112) mit einer höheren Sicherheitsstufe bereitgestellt wird als die zweite Partition (114). Fahrzeugsteuergerät (110), das dazu eingerichtet ist, alle Verfahrensschritte eines Verfahrens nach einem der vorstehenden Ansprüche durchzuführen. Computerprogramm, das ein Fahrzeugsteuergerät (100) dazu veranlasst, alle Verfahrensschritte eines Verfahrens nach einem der Ansprüche 1 bis 10 durchzuführen, wenn es auf dem Fahrzeugsteuergerät (100) ausgeführt wird.
13. Maschinenlesbares Speichermedium mit einem darauf gespeicherten Computerprogramm nach Anspruch 12.
PCT/EP2022/072127 2021-08-26 2022-08-05 Verfahren zum betreiben eines fahrzeugsteuergeräts WO2023025572A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021209362.0 2021-08-26
DE102021209362.0A DE102021209362A1 (de) 2021-08-26 2021-08-26 Verfahren zum Betreiben eines Fahrzeugsteuergeräts

Publications (1)

Publication Number Publication Date
WO2023025572A1 true WO2023025572A1 (de) 2023-03-02

Family

ID=83151519

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/072127 WO2023025572A1 (de) 2021-08-26 2022-08-05 Verfahren zum betreiben eines fahrzeugsteuergeräts

Country Status (2)

Country Link
DE (1) DE102021209362A1 (de)
WO (1) WO2023025572A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021209175A1 (de) * 2020-04-15 2021-10-21 Audi Ag Steuergerät für ein fahrzeug und verfahren zum testen eines programmelements einer fahrzeugfunktion sowie kraftfahrzeug mit einem steuergerät

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021209175A1 (de) * 2020-04-15 2021-10-21 Audi Ag Steuergerät für ein fahrzeug und verfahren zum testen eines programmelements einer fahrzeugfunktion sowie kraftfahrzeug mit einem steuergerät

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
GOH OKEHEE ET AL: "Schedulable Online Testing Framework for Real-Time Embedded Applications in VM", 17 December 2007, SAT 2015 18TH INTERNATIONAL CONFERENCE, AUSTIN, TX, USA, SEPTEMBER 24-27, 2015; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER, BERLIN, HEIDELBERG, PAGE(S) 730 - 741, ISBN: 978-3-540-74549-5, XP047307051 *

Also Published As

Publication number Publication date
DE102021209362A1 (de) 2023-03-02

Similar Documents

Publication Publication Date Title
DE102020110271B3 (de) Steuergerät für ein Fahrzeug und Verfahren zum Testen eines Programmelements einer Fahrzeugfunktion sowie Kraftfahrzeug mit einem Steuergerät
DE102019124018A1 (de) Verfahren zum Optimieren von Tests von Regelsystemen für automatisierte Fahrdynamiksysteme
WO2021058223A1 (de) Verfahren zur effizienten, simulativen applikation automatisierter fahrfunktionen
DE19927657A1 (de) Partitionierung und Überwachung von softwaregesteuerten Systemen
DE102005025520A1 (de) Verfahren zur modellbasierten Diagnose eines mechatronischen Systems
EP1924916A2 (de) Speicheranordnung und betriebsverfahren dafür
DE102018209108A1 (de) Schnelle Fehleranalyse für technische Vorrichtungen mit maschinellem Lernen
WO2008095518A1 (de) Anwendung einer verteilten diagnosearchitektur in autosar
EP1860565B1 (de) Verfahren zur Funktionsprüfung eines Steuergeräts für ein Kraftfahrzeug
WO2021209192A1 (de) Verfahren und vorrichtung zum prüfen der kompatibilität zwischen einer anwendungssoftware und einer mobilen arbeitsmaschine
WO2023025572A1 (de) Verfahren zum betreiben eines fahrzeugsteuergeräts
EP3991037B1 (de) Steuergerät für ein fahrzeug, system, verfahren und kraftfahrzeug mit einem solchen steuergerät
EP4096198A1 (de) Verfahren zur diagnose eines bordnetzes eines fahrzeugs
DE102020209228A1 (de) Verfahren zum Überwachen wenigstens einer Recheneinheit
DE102016203283A1 (de) Verfahren zum Betreiben eines Mikroprozessors
DE102015209033A1 (de) Verfahren und Vorrichtung zum Liefern einer Prüfantwort
DE112019007286T5 (de) Fahrzeuginterne steuerungsvorrichtung und fahrzeuginternes steuerungssystem
DE102021111724B4 (de) Verfahren und Computerprogramm zum Evaluieren eines Softwarestands eines Fahrerassistenzsystems
DE102022201895A1 (de) Mitigation einer manipulation von software eines fahrzeugs
DE102021207473A1 (de) Mitigation einer manipulation von software eines fahrzeugs
DE102022201898A1 (de) Mitigation einer manipulation von software eines fahrzeugs
WO2023165887A1 (de) Verfahren zum bereitstellen von daten in einem fahrzeug
DE102022105132A1 (de) Verfahren zum Simulieren von einem Steuergeräte-Antwortverhalten in einer Produktionslinie zum Fertigen eines Kraftfahrzeugs
DE202021004237U1 (de) Computerlesbares Speichermedium und Rechenvorrichtung zum Evaluieren eines Softwarestands eines Fahrerassistenzsystems
DE19748181B4 (de) Verfahren zum Prüfen einer Funktion oder Einrichtung eines Fahrzeugs

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: 22762025

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE