EP4655669A1 - Kontrollsystem und verfahren zum kontrollieren von funktionsaufrufen in einem fahrzeug, computerprogrammprodukt und speichermedium - Google Patents

Kontrollsystem und verfahren zum kontrollieren von funktionsaufrufen in einem fahrzeug, computerprogrammprodukt und speichermedium

Info

Publication number
EP4655669A1
EP4655669A1 EP24701680.1A EP24701680A EP4655669A1 EP 4655669 A1 EP4655669 A1 EP 4655669A1 EP 24701680 A EP24701680 A EP 24701680A EP 4655669 A1 EP4655669 A1 EP 4655669A1
Authority
EP
European Patent Office
Prior art keywords
function call
call data
vehicle
layer
programming interface
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24701680.1A
Other languages
English (en)
French (fr)
Inventor
Roland Wagner
Dirk Sikora
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Volkswagen AG
Original Assignee
Volkswagen AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Volkswagen AG filed Critical Volkswagen AG
Publication of EP4655669A1 publication Critical patent/EP4655669A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4494—Execution paradigms, e.g. implementations of programming paradigms data driven
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space

Definitions

  • the present invention relates to a control system and a method for controlling function calls in a vehicle by means of a programming interface.
  • the invention further relates to a computer program product for carrying out the method and to a storage medium on which such a computer program product is stored.
  • Modern vehicles have a complex structure with a large number of sensors, actuators and system functions, for example in an infotainment system. Since such vehicle components are generally not used in isolation but exchange data with each other, communication protocols and networks have been created that serve to network the various, partially computer-implemented vehicle components. For example, in many vehicles the vehicle components are connected to each other via a star-shaped network architecture in which a central transit point, a so-called gateway, is used to provide communication between different components. For modern vehicles, work is being done on programming interfaces that are intended to improve communication between an internal vehicle operating system and third-party programs. Systems and methods of this type are described, for example, in US 11 132 650 B2, in which it is proposed to encode and decode data that is exchanged between a third-party program and the vehicle system via a programming interface at various points in the programming interface.
  • the object of the present invention is to improve existing systems and methods for the interaction between third-party programs and vehicle systems.
  • the above object is solved by the patent claims.
  • the above object is solved by the control system according to claim 1, the vehicle according to claim 9, the method according to claim 10, the computer program product according to claim 12 and the storage medium according to claim 13. Further advantages of the invention emerge from the subclaims, the description and the figures.
  • Features that are described in connection with the control system apply, of course also in connection with the vehicle according to the invention, the method according to the invention, the computer program product according to the invention, the storage medium according to the invention and vice versa, so that with regard to the disclosure of the individual aspects of the invention, reference is and/or can always be made to each other.
  • a control system for controlling function calls in a vehicle comprises a programming interface for connecting a third-party program to a computer-implemented operating system of the vehicle for sending function call data from the third-party program to the operating system for executing function calls and corresponding functions in the vehicle that are perceptible to the driver of the vehicle.
  • the programming interface comprises a connection layer for sending the function call data from the third-party program to the programming interface and a communication layer for sending the function call data from the programming interface to the operating system.
  • the programming interface further comprises a security layer provided between the connection layer and the communication layer, which is configured to perform a check of the function call data sent from the connection layer to the security layer with respect to a system stability of the operating system to be ensured and to enable or prevent a sending of the function call data from the security layer towards the communication layer based on the check performed.
  • a security layer provided between the connection layer and the communication layer, which is configured to perform a check of the function call data sent from the connection layer to the security layer with respect to a system stability of the operating system to be ensured and to enable or prevent a sending of the function call data from the security layer towards the communication layer based on the check performed.
  • the third-party program can be understood as programs from third-party providers that are not part of the core system of the vehicle, which is developed during the manufacture of the vehicle and installed in the vehicle.
  • the third-party program can therefore be understood as an application for the operating system, for example in the form of an application (app) that can be installed in the vehicle, which is provided by a third-party provider.
  • a programming interface can be understood as a so-called API (Application Programming Interface), in particular an API or on-board API that can be implemented in the vehicle.
  • the programming interface can serve as a gateway for various vehicle functions.
  • the computer-implemented operating system can be understood as an in-vehicle system that is or can be executed by means of a computer or a corresponding computing unit.
  • the operating system can have a compilation of computer programs that manage system resources of a computer or computer system provided in the vehicle.
  • the system resources can include a main memory, hard disks, input and output devices, a communication bus system (CAN, Ethernet, LIN, etc.) and processors, which can also be understood as part of the operating system.
  • the operating system according to the invention is therefore not to be considered limited to a conventional, purely software-based operating system.
  • the programming interface according to the invention has the security layer, which is configured and designed to check the function call data with direct reference to the system stability of the operating system that is to be ensured.
  • Checking with reference to the system stability that is to be ensured is to be understood here as meaning that all function call data sent and passing through the security layer are checked to see whether forwarding the data could possibly lead to problems with the desired execution of the operating system, for example in the communication bus system.
  • Checking with reference to the system stability that is to be ensured can therefore be understood as checking based on predefined stability parameters for influencing system stability.
  • the check must be distinguished, for example, from a check with reference to a possibly required coding of the data, which is carried out at least in the programming interface without reference to the desired system stability.
  • Function call data that has the required coding and enters the operating system can still lead to system instability if the operating system is overloaded, for example by a third-party program with particularly high performance requirements.
  • the function call data refers in particular to data and/or signals that initiate or are intended to initiate a function call by means of the operating system, i.e. the execution of a desired function by means of the operating system.
  • a function call can include many different calls, for example a call to activate seat heating, to open a sliding door, to set a turn signal, to influence the vehicle speed and/or direction, to set a navigation route and to change a radio station. It is always important here that the desired calls do not lead to a predefined system stability.
  • the security layer can be configured to carry out the check without data exchange between the operating system and the third-party program.
  • the check can be carried out using a set of rules, i.e. based on a predefined set of rules and/or conditions.
  • the check is preferably carried out for all data of the third-party program, regardless of, for example, whether a secure data connection has already been established between the third-party program and the operating system.
  • Enabling or preventing the sending of function call data can be understood to mean that the function call data provided and checked by the third-party program is accepted or rejected depending on the check and is then forwarded out of the security layer or not.
  • the security layer can be configured to perform the check by means of suitable comparisons between determined data and/or parameters and reference data and/or reference parameters.
  • the programming interface according to the invention can have several layers, whereby the layers can be understood not only as layers, but also as different modules, which do not necessarily have to be arranged or designed in layers. In the present application, the term layer is nevertheless used to ensure the most uniform possible notation.
  • the programming interface can also have a protocol layer, which can be provided between the security layer and the communication layer or for processing data that is sent between the security layer and the communication layer.
  • the respective layers or modules can be understood as so-called middleware functions.
  • the Kontra II system can have a diagnostic module, via which the middleware functions or the corresponding layers can be configured via diagnostics in order to be able to adapt threshold values and/or rules, for example.
  • the protocol layer is configured in particular for logging function call data from the security module and feedback data from the operating system.
  • function call data from the security layer and data and/or signals from the operating system can be written to a data memory, which can be part of the Kontra II system, but is preferably not part of the programming interface.
  • the data written to the data memory can be stored from a volatile buffer into a non-volatile memory.
  • the communication adapter can be configured to be adaptable for different vehicle platforms in order to take into account changes in the vehicle platform and/or in the third-party programs.
  • the security layer can be configured to perform the check in two stages, with the check being carried out in a first check stage with respect to the system stability of the operating system and a check being carried out in a second check stage, at least partially simultaneously or subsequently, with respect to vehicle and/or vehicle occupant safety.
  • the security layer can be embedded in the communication flow between the connection layer and the communication layer and/or in the communication flow between the third-party program and the operating system. At this point, the security layer does not change the function call data, for example, it does not redesign it for any encoding or decoding.
  • Corresponding rejection information can then be sent to the sender, i.e. to the third-party program or to the third-party program via the connection layer.
  • the rejection information may include data on the reason for the rejection.
  • the verification in the second verification stage with regard to vehicle and/or vehicle occupant safety can be understood to mean that the function call Data are checked to determine whether forwarding the function call data to the operating system and resulting function calls could endanger vehicle and/or vehicle occupant safety or not.
  • Vehicle safety is to be understood here in particular as mechanical and/or electromechanical vehicle safety, i.e. not data security, for example.
  • a check with regard to vehicle safety can be understood to mean that the check is carried out to prevent mechanical and/or electronic damage to the vehicle.
  • the check of the function call data with regard to the vehicle and/or vehicle occupant safety to be guaranteed can again be carried out using a predefined set of rules, i.e.
  • a simple example of a check with regard to vehicle and vehicle occupant safety is a set of rules according to which no acoustic output and/or no opening of a door may be possible at a vehicle speed greater than zero. If a function call is detected in the function call data which would result in this rule being violated, the function call data is held back in the security layer or is not forwarded to the operating system and/or not forwarded to the communication layer.
  • Controlling function calls can be understood as controlling and/or regulating function calls.
  • controlling function calls can be understood as enabling and preventing function calls or corresponding function call data that are requested or sent by the third-party program.
  • the security layer can be designed to be configurable.
  • the security layer or part of the security layer can be designed to be switchable off.
  • the control system can have a suitable switch-off module that can preferably be operated by a vehicle occupant.
  • the programming interface can be viewed as part of the operating system or as an independent part independent of the operating system.
  • the check can be carried out using an artificial intelligence of the control system. This means that the artificial intelligence can be configured to carry out the check.
  • the security layer is configured to determine a number of function calls in the function call data and to perform the check based on the determined number of function calls to be carried out.
  • the function call data can be forwarded or not.
  • system stability can be ensured by, for example, preventing a number of function calls that cannot be reliably processed from being sent to the operating system, thereby overloading the operating system.
  • it can be prevented, for example, from overloading a communication bus system, which in turn could cause system instability.
  • function calls can be added up to carry out the check and as soon as a predefined number of function calls is exceeded or as soon as a predefined threshold is reached or exceeded, the forwarding or sending of the function call data can be prevented or prohibited.
  • the threshold can be predefined based on system parameters of the vehicle and/or determined dynamically during data transmission and set accordingly.
  • a time factor can be taken into account. Over time and by processing the function calls, the accumulation described above can be reset.
  • the security layer can be configured accordingly to carry out these steps.
  • the invention further relates to a control system in which the security layer is configured to determine the type of at least one function call in the function call data and to carry out the check based on the determined type of the at least one function call.
  • the function call data can be forwarded or not.
  • the type of function call can be understood to mean a predefined and/or predefinable type of function call.
  • Function calls can differ in their type, for example, in that function calls of one type relate to the setting of lighting devices in the exterior of the vehicle and another type relate to the setting of lighting devices in the interior of the vehicle. Other types of function calls can, for example, relate to setting the engine, setting the air conditioning and/or setting the infotainment system.
  • the detected type can be compared with predefined types, and if the detected type matches one of the predefined types, or if the detected type does not match a predefined type, the function call data can be forwarded or not. This is another simple and reliable way to prevent unwanted function calls.
  • the security layer in a control system it is possible for the security layer in a control system to be configured to determine the amount of payload of the function call data and to carry out the check based on the amount of payload determined.
  • the function call data can be forwarded or not.
  • the check based on the amount of payload determined can be carried out by means of a comparison between the amount of payload determined and a predefined or predefinable reference amount of payload.
  • the reference amount of user data can be predefined based on a maximum permissible bus load of the respective vehicle, which, if exceeded, would result in an overload of the communication bus system.
  • the check based on the determined amount of user data can also be understood to mean that the amount of user data is assessed and/or checked to see whether the data in the amount of user data is in the correct or in a predefined and/or desired range. This can also prevent problems in components, as it can prevent, for example, the components from being inaccessible and/or being outside an operating range.
  • the security layer can be configured to detect an anomaly in the function call data and to carry out the check based on the detected anomaly.
  • the function call data can be forwarded or not.
  • Anomalies can be detected in particular when the function call data contains several function calls or when several function calls are detected based on the function call data.
  • An anomaly can be detected when a function call or function calls are detected that would never occur under predefined conditions. Under an An anomaly can also be understood as an unexpected change or an unexpected deviation from an expected pattern in a data set.
  • the anomaly can be detected using artificial intelligence.
  • the security layer can have a detection unit, for example with artificial intelligence, to detect an anomaly accordingly.
  • the security layer can be configured to assess the plausibility for at least one function call in the function call data and to carry out the check based on the assessed plausibility.
  • the function call data can be forwarded or not.
  • the plausibility of the system call data or the corresponding system calls can be assessed or checked, for example, with reference to a time stamp. This means that if the time stamp does not match a current system time of the vehicle, the function call data can be assessed as implausible and forwarding of the function call data can be prohibited.
  • the plausibility can be assessed using artificial intelligence. Accordingly, the security layer can have an investigation unit, for example with artificial intelligence, for assessing the plausibility accordingly.
  • the security layer in a control system can be configured to determine the operating state of the vehicle and to carry out the check based on the determined operating state of the vehicle.
  • the function call data can be forwarded or not depending on the determined operating state of the vehicle.
  • the set of rules described above can be provided as part of the security layer and configured to configure itself automatically based on an operating state of the vehicle. Based on the operating state, it can be determined, for example, whether the vehicle is currently stationary or moving and at what speed and/or direction the vehicle is moving.
  • the operating state of the vehicle can be influenced by parameters for the engine and/or a possible drive battery.
  • the security layer is configured to determine the functional state of functional modules for executing the operating system and to carry out the check based on the determined functional state of the functional modules or at least one functional module.
  • the functional modules can be understood in particular as functional modules such as a main memory, a processor, a communication bus system and/or a data storage device, each of which can be understood as part of the operating system. If it is recognized that the functional modules are already at full capacity, at least certain functional orders from the third-party program could lead to an overload of the operating system. This can be reliably prevented in the manner proposed.
  • a further aspect of the invention relates to a vehicle with a Kontra II system as described above.
  • the vehicle according to the invention thus brings with it the same advantages as have been described in detail with reference to the control system according to the invention.
  • the vehicle is to be understood in particular as a road vehicle, for example in the form of a car or a truck.
  • the vehicle can also be understood as a rail vehicle, a watercraft, an aircraft or a robot.
  • a further aspect of the invention relates to a method for controlling function calls in a vehicle as described above, comprising the steps:
  • the method according to the invention therefore also brings with it the advantages described above.
  • the method can be configured to operate the control system described above. The following steps can be carried out as part of the method: Determining a number of function calls in the function call data and performing the check based on the determined number of function calls, Determining a type of at least one function call in the function call data and performing the check based on the determined type of the at least one function call,
  • a further aspect of the invention relates to a computer program product comprising instructions which cause the control system described above to carry out or be able to carry out the method steps described.
  • the invention further relates to a computer-readable, in particular non-volatile, storage medium on which such a computer program product is stored.
  • the computer program product according to the invention and the storage medium according to the invention therefore also bring with them the advantages described above.
  • the computer program product can be implemented as computer-readable instruction code in any suitable programming language and/or machine language such as JAVA, C++, C# and/or Python.
  • the computer program product can be stored on a computer-readable storage medium such as a data disk, a removable drive, a volatile or non-volatile memory, or a built-in memory/processor.
  • the instruction code can program a computer or other programmable devices such as a control device, which can be part of the control system, in such a way that the desired functions are carried out.
  • the computer program product can be and/or be provided in a network such as the Internet, from which it can be downloaded by a user if required.
  • the computer program product can be implemented both by means of software and by means of one or more several special electronic circuits, i.e. in hardware or in any hybrid form, i.e. by means of software components and hardware components.
  • Figure 1 is a block diagram for explaining a control system according to the invention and a method for controlling function calls in a vehicle
  • Figure 2 shows a storage medium with a computer program product stored thereon according to an embodiment of the invention
  • Figure 3 shows a vehicle with a control system according to an embodiment of the invention.
  • Fig. 1 shows a control system 10 for controlling function calls and associated functions in a vehicle 11, which is shown in Fig. 3.
  • the control system 10 has a programming interface 12 for connecting a third-party program 13 to a computer-implemented operating system 14 of the vehicle 11. If the third-party program 13 is connected to the programming interface 12, the third-party program 13 can send function call data via the programming interface 12 to the operating system 14 so that the function calls contained in the function call data or at least one contained function call can be executed in the vehicle 11.
  • the programming interface 12 has a connection layer 15 for sending the function call data from the third-party program 13 to the programming interface 12 and a communication layer 18 for sending the function call data from the programming interface 12 to the operating system 14.
  • the programming interface 12 shown has a security layer 16 provided between the connection layer 15 and the communication layer 18 as well as a Protocol layer 17 provided by security layer 16 and communication layer 18.
  • the security layer 16 is configured to perform a check of the function call data sent from the connection layer 15 to the security layer 16 with respect to ensuring system stability of the operating system 14.
  • the security layer 16 is also configured to enable or prevent the function call data from being sent from the security layer 16 to the communication layer 18 based on the check performed or, in the present case, to forward it to the protocol layer 17 or not depending on the check.
  • the security layer 16 shown in Fig. 1 is configured to carry out the check in two stages, with the check being carried out in a first check stage with respect to the system stability of the operating system 14 and a check being carried out in a second check stage with respect to vehicle and/or vehicle occupant safety.
  • the security layer 16 is embedded in the communication flow between the connection layer 15 and the communication layer 18 and accordingly in the communication flow between the third-party program 13 and the operating system 14.
  • the security layer 16 is configured to determine a number of function calls in the function call data, to determine the type of at least one function call in the function call data and to determine the amount of payload data of the function call data, to determine the functional state of function modules for executing the operating system 14 and/or to carry out the check based on the determined number of function calls, based on the determined type of at least one function call, based on the determined functional state of the function modules and/or based on the determined amount of payload data.
  • the security layer 16 is configured to determine an anomaly in the function call data, to assess the plausibility for at least one function call in the function call data and/or to determine the operating state of the vehicle and to carry out the check based on the determined anomaly, based on the assessed plausibility and/or based on the determined operating state of the vehicle 11.
  • the function call data is sent according to the procedure shown in Fig. 1 shown arrow in the direction of the communication layer 18. However, if the check determines that the function call data must not be forwarded or that sending the function call data is to be prevented, the function call data is not forwarded in the direction of the operating system. Instead, as shown by the dashed arrow in Fig. 1, a corresponding error message is sent to the third-party program 13.
  • function call data is first sent from the third-party program 13 to the connection layer 15.
  • Function call data is then sent from the connection layer 15 to the security layer 16.
  • the function call data is then checked by the security layer 16, as described in detail above. Depending on the check, forwarding of the function call data from the security layer 16 towards the communication layer 18 is enabled or not.
  • Fig. 2 shows a computer-readable and non-volatile storage medium 20 in the form of a memory stick or a flash drive.
  • Computer program product 19 is stored on the storage medium 20, which includes instructions that cause the control system 10 shown and described to carry out the method steps described above.
  • Fig. 3 shows a vehicle 11 in the form of an autonomously drivable electric vehicle in which the control system 10 shown in Fig. 1 is installed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Small-Scale Networks (AREA)

Abstract

Die vorliegende Erfindung betrifft ein Kontrollsystem (10) zum Kontrollieren von Funktionsaufrufen in einem Fahrzeug (11), aufweisend eine Programmierschnittstelle (12) mit einem zwischen einem Anbindungs-Layer (15) der Programmierschnittstelle (12) und einem Kommunikations-Layer (18) Programmierschnittstelle (12) bereitgestellten Sicherheits-Layer (16), der konfiguriert ist eine Überprüfung von Funktionsaufruf-Daten, die vom Anbindungs-Layer (15) an den Sicherheits-Layer (16) gesendet werden, mit Bezug auf eine zu gewährleistende Systemstabilität eines Betriebssystems (14) des Fahrzeugs (11) durchzuführen und ein Senden der Funktionsaufruf-Daten vom Sicherheits-Layer (16) in Richtung des Kommunikations-Layers (18) basierend auf der durchgeführten Überprüfung zu ermöglichen oder zu verhindern. Die Erfindung betrifft ferner ein Verfahren sowie ein Computerprogrammprodukt (19) zum Betreiben eines solchen Kontrollsystems (10) sowie ein computerlesbares Speichermedium (20), auf welchem ein solches Computerprogrammprodukt (19) gespeichert ist.

Description

Beschreibung
Kontra 11 system und Verfahren zum Kontrollieren von Funktionsaufrufen in einem Fahrzeug, Computerprogrammprodukt und Speichermedium
Die vorliegende Erfindung betrifft ein Kontrollsystem und ein Verfahren zum Kontrollieren von Funktionsaufrufen in einem Fahrzeug mittels Programmierschnittstelle. Die Erfindung betrifft ferner ein Computerprogrammprodukt zum Ausführen des Verfahrens sowie ein Speichermedium, auf dem ein solches Computerprogrammprodukt gespeichert ist.
Moderne Fahrzeuge weisen eine komplexe Struktur mit einer Vielzahl an Sensoren, Aktoren und Systemfunktionen, beispielsweise in einem Infotainment-System, auf. Da solche Fahrzeugkomponenten in der Regel nicht isoliert genutzt werden, sondern Daten untereinander austauschen, sind Kommunikationsprotokolle und Netzwerke geschaffen worden, die dazu dienen, die verschiedenen, teilweise computerimplementierten Fahrzeugkomponenten zu vernetzen. Beispielsweise werden in vielen Fahrzeugen die Fahrzeugkomponenten über eine sternförmige Netzwerkarchitektur miteinander verbunden, in der eine zentrale Durchgangsstelle, ein sogenanntes Gateway, genutzt wird, um die Kommunikation zwischen verschiedenen Komponenten bereitzustellen. Für moderne Fahrzeuge wird hierzu an Programmierschnittstellen gearbeitet, welche eine Kommunikation zwischen einem fahrzeuginternen Betriebssystem und Drittprogrammen verbessern sollen. Gattungsgemäße Systeme und Verfahren werden beispielsweise in der US 11 132 650 B2 beschrieben, in welcher vorgeschlagen wird, Daten, die zwischen einem Drittprogramm und dem Fahrzeugsystem über eine Programmierschnittstelle ausgetauscht werden, an verschiedenen Stellen in der Programmierschnittstelle zu kodieren und zu dekodieren.
Aufgabe der vorliegenden Erfindung ist es, bestehende Systeme und Verfahren für die Interaktion zwischen Drittprogrammen und Fahrzeugsystemen zu verbessern. Die voranstehende Aufgabe wird durch die Patentansprüche gelöst. Insbesondere wird die voranstehende Aufgabe durch das Kontrollsystem gemäß Anspruch 1 , das Fahrzeug gemäß Anspruch 9, das Verfahren gemäß Anspruch 10, das Computerprogrammprodukt gemäß Anspruch 12 sowie das Speichermedium gemäß Anspruch 13 gelöst. Weitere Vorteile der Erfindung ergeben sich aus den Unteransprüchen, der Beschreibung und den Figuren. Dabei gelten Merkmale, die im Zusammenhang mit dem Kontrollsystem beschrieben sind, selbstverständlich auch im Zusammenhang mit dem erfindungsgemäßen Fahrzeug, dem erfindungsgemäßen Verfahren, dem erfindungsgemäßen Computerprogrammprodukt, dem erfindungsgemäßen Speichermedium und jeweils umgekehrt, sodass bezüglich der Offenbarung zu den einzelnen Erfindungsaspekten stets wechselseitig Bezug genommen wird und/oder werden kann.
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Kontrollsystem zum Kontrollieren von Funktionsaufrufen in einem Fahrzeug vorgeschlagen. Das Kontrollsystem umfasst eine Programmierschnittstelle für das Anbinden eines Drittprogramms an ein computerimplementiertes Betriebssystem des Fahrzeugs zum Senden von Funktionsaufruf- Daten von dem Drittprogramm an das Betriebssystem zum Ausführen von Funktionsausrufen und entsprechenden, für den Fahrer des Fahrzeugs wahrnehmbaren, Funktionen im Fahrzeug. Die Programmierschnittstelle umfasst einen Anbindungs-Layer zum Senden der Funktionsaufruf-Daten von dem Drittprogramm an die Programmierschnittstelle und einen Kommunikations-Layer zum Senden der Funktionsaufruf-Daten von der Programmierschnittstelle an das Betriebssystem. Die Programmierschnittstelle weist ferner einen zwischen dem Anbindungs-Layer und dem Kommunikations-Layer bereitgestellten Sicherheits-Layer auf, der konfiguriert ist, eine Überprüfung der Funktionsaufruf-Daten, die vom Anbindungs-Layer an den Sicherheits-Layer gesendet werden, mit Bezug auf eine zu gewährleistende Systemstabilität des Betriebssystems durchzuführen und ein Senden der Funktionsaufruf- Daten vom Sicherheits-Layer in Richtung des Kommunikations-Layers basierend auf der durchgeführten Überprüfung zu ermöglichen oder zu verhindern.
Mit dem erfindungsgemäßen Kontra II system können Interaktionen zwischen Drittprogrammen und dem Betriebssystem des Fahrzeugs auf einfache und zuverlässige Weise dahingehend verbessert werden, dass stets die Systemstabilität des Betriebssystems gewährleistet wird, während es nicht nötig ist, einem Drittprogramm sensible Daten des Betriebssystems und/oder des Fahrzeugs preiszugeben. Auf diese Weise können die Fahrzeugplattform und die zugehörigen Fahrzeugfunktionen auf entsprechend einfache und zuverlässige Weise vor unerwünschten Eingriffen geschützt werden.
Unter dem Drittprogramm können Programme von Drittanbietern verstanden werden, die nicht zum Kernsystem des Fahrzeugs, das bei der Fertigung des Fahrzeugs entwickelt und im Fahrzeug installiert wird, gehören. Unter dem Drittprogramm kann folglich eine Anwendung für das Betriebssystem, beispielsweise in Form einer im Fahrzeug installierbaren Applikation (App), das von einem Drittanbieter bereitgestellt wird, verstanden werden. Unter der Programmierschnittstelle kann eine sogenannte API (Application Programming Interface), insbesondere eine in das Fahrzeug implementierbare API bzw. On-Board-API verstanden werden. Die Programmierschnittstelle kann als Gateway für verschiedene Fahrzeugfunktionen dienen.
Unter dem computerimplementierten Betriebssystem kann ein fahrzeuginternes System verstanden werden, das mittels Computer bzw. mittels einer entsprechenden Recheneinheit ausgeführt wird oder werden kann. Das Betriebssystem kann eine Zusammenstellung von Computerprogrammen aufweisen, die Systemressourcen eines im Fahrzeug bereitgestellten Computers oder Computersystems verwaltet. Die System ressourcen können einen Arbeitsspeicher, Festplatten, Ein- und Ausgabegeräte, ein Kommunikations-Bussystem (CAN, Ethernet, LIN, etc.) und Prozessoren umfassen, die ebenfalls als Bestandteil des Betriebssystems verstanden werden können. Das erfindungsgemäße Betriebssystem ist demnach nicht auf ein konventionelles, rein software-basiertes Betriebssystem beschränkt zu betrachten.
Im Gegensatz zu bekannten Programmierschnittstellen für Fahrzeuge weist die erfindungsgemäße Programmierschnittstelle den Sicherheits-Layer auf, der zum Überprüfen der Funktionsaufruf- Daten mit direktem Bezug auf die zu gewährleistende Systemstabilität des Betriebssystems konfiguriert und ausgestaltet ist. Unter dem Überprüfen mit Bezug auf die zu gewährleistende Systemstabilität ist vorliegend zu verstehen, dass sämtliche gesendeten und den Sicherheits-Layer passierenden Funktionsaufruf-Daten dahingehend geprüft werden, ob ein Weiterleiten der Daten möglicherweise zu Problemen bei der gewünschten Ausführung des Betriebssystems, beispielsweise im Kommunikations-Bussystem, führen könnte. Unter dem Überprüfen mit Bezug auf die zu gewährleistende Systemstabilität kann demnach ein Überprüfen basierend auf vordefinierten Stabilitätsparametern zum Beeinflussen der Systemstabilität verstanden werden. Zu unterscheiden ist die Überprüfung beispielsweise von einer Überprüfung mit Bezug auf eine möglicherweise geforderte Kodierung der Daten, die zumindest in der Programmierschnittstelle ohne Bezug auf die gewünschte Systemstabilität durchgeführt wird. Funktionsaufruf-Daten, die die geforderte Kodierung aufweisen und in das Betriebssystem gelangen, können trotzdem zu einer Systeminstabilität führen, indem das Betriebssystem beispielsweise durch ein Drittprogramm mit besonders hoher Leistungsanforderung überlastet wird. Unter den Funktionsaufruf-Daten sind vorliegend insbesondere Daten und/oder Signale zu verstehen, die einen Funktionsaufruf mittels des Betriebssystems, also das Ausführen einer gewünschten Funktion mittels des Betriebssystems, veranlassen oder veranlassen sollen. Unter einem Funktionsaufruf können viele unterschiedliche Aufrufe, beispielsweise ein Aufruf zum Aktivieren einer Sitzheizung, zum Öffnen einer Schiebetüre, zum Setzen eines Blinkers, zum Beeinflussen der Fahrzeuggeschwindigkeit und/oder -richtung, zum Einstellen einer Navigationsroute und zum Wechseln eines Radiosenders, verstanden werden. Wichtig ist hierbei stets, dass die gewünschten Aufrufe nicht zu einer vordefinierten Systemstabilität führen. Mittels des erfindungsgemäßen Kontrollsystems und insbesondere mittels des Sicherheits- Layers kann dies gewährleistet werden, insbesondere ohne, dass dem Drittprogramm Informationen vom Fahrzeug und/oder vom Betriebssystem des Fahrzeugs bekannt sein müssen. Das heißt, der Sicherheits-Layer kann konfiguriert sein, die Überprüfung ohne Datenaustausch zwischen dem Betriebssystem und dem Drittprogramm durchzuführen. Die Überprüfung kann mittels Regelwerk, das heißt, basierend auf einem vordefinierten Satz von Regeln und/oder Bedingungen, durchgeführt werden. Die Überprüfung wird vorzugsweise für sämtliche Daten des Drittprogramms durchgeführt, unabhängig beispielsweise davon, ob bereits eine gesicherte Datenverbindung zwischen dem Drittprogramm und dem Betriebssystem hergestellt wurde. Unter dem Ermöglichen oder Verhindern des Sendens der Funktionsaufruf-Daten kann verstanden werden, dass die vom Drittprogramm bereitgestellten und geprüften Funktionsaufruf-Daten abhängig von der Überprüfung akzeptiert oder abgelehnt werden und anschließend aus dem Sicherheits-Layer weitergeleitet werden, oder nicht. Der Sicherheits- Layer kann zum Durchführen der Überprüfung mittels geeigneter Vergleiche zwischen ermittelten Daten und/oder Parametern und Referenz-Daten und/oder Referenz-Parametern konfiguriert sein.
Die erfindungsgemäße Programmierschnittstelle kann mehrere Layer aufweisen, wobei unter den Layern nicht nur Schichten, sondern auch verschiedene Module, die nicht zwangsläufig schichtartig angeordnet oder ausgestaltet sein müssen, verstanden werden können. In der vorliegenden Anmeldung wird für eine möglichst einheitliche Schreibweise trotzdem der Begriff Layer verwendet. Die Programmierschnittstelle kann neben dem Anbindungs-Layer, dem Sicherheits-Layer und dem Kommunikations-Layer noch einen Protokoll-Layer aufweisen, der zwischen dem Sicherheits-Layer und dem Kommunikations-Layer bzw. zum Verarbeiten von Daten, die zwischen dem Sicherheits-Layer und dem Kommunikations-Layer gesendet werden, bereitgestellt sein kann. Unter den jeweiligen Layern bzw. Modulen können sogenannte Middleware-Funktionen verstanden werden. Das Kontra II system kann ein Diagnosemodul aufweisen, über welches die Middleware-Funktionen bzw. die entsprechenden Layer über Diagnose konfigurierbar sind, um beispielsweise Schwellwerte und/oder Regeln anpassen zu können. Der Protokoll-Layer ist insbesondere zum Protokollieren bzw. Logging von Funktionsaufruf- Daten vom Sicherheits-Modul sowie von Rückmeldungsdaten vom Betriebssystem konfiguriert. Im Protokoll-Layer können Funktionsaufruf-Daten vom Sicherheits-Layer sowie Daten und/oder Signale vom Betriebssystem in einen Datenspeicher geschrieben werden, der Bestandteil des Kontra II systems sein kann, jedoch vorzugsweise nicht Bestandteil der Programmierschnittstelle ist. Im Falle eines vordefinierten oder vordefinierbaren Schlüsselereignisses und/oder Triggersignals können die in den Datenspeicher geschrieben Daten aus einem flüchtigen Zwischenspeicher in einen nichtflüchtigen Speicher abgelegt werden.
Konnten die Funktionsaufruf-Daten den Sicherheits-Layer und den Protokoll-Layer erfolgreich passiert, können sie über den Kommunikations-Layer zu den gewünschten und/oder vordefinierten Ziel-Funktionen im Betriebssystem weitergeleitet werden. Der Kommunikationsadapter kann für verschiedene Fahrzeugplattformen anpassbar konfiguriert sein, um Änderungen in der Fahrzeugplattform und/oder an den Drittprogrammen Rechnung tragen zu können.
Der Sicherheits-Layer kann konfiguriert sein, die Überprüfung zweistufig durchzuführen, wobei in einer ersten Überprüfungsstufe die Überprüfung mit Bezug auf die Systemstabilität des Betriebssystems durchgeführt wird und in einer zweiten Überprüfungsstufe, zumindest teilweise gleichzeitig oder anschließend, eine Überprüfung mit Bezug auf eine Fahrzeug- und/oder Fahrzeuginsassensicherheit durchgeführt wird oder werden kann. Der Sicherheits-Layer kann hierzu in den Kommunikationsfluss zwischen dem Anbindungs-Layer und dem Kommunikations-Layer und/oder in den Kommunikationsfluss zwischen dem Drittprogramm und dem Betriebssystem eingebettet sein. An dieser Position ändert der Sicherheits-Layer die Funktionsaufruf-Daten nicht, nimmt beispielsweise keine Umgestaltung für eine etwaige Kodierung oder Dekodierung vor. Nur falls während der Überprüfung der Funktionsaufruf-Daten festgestellt wird, dass die Funktionsaufruf-Daten bzw. wenigstens ein in den Funktionsaufruf- Daten enthaltener Funktionsaufruf im Betriebssystem zu einer Systeminstabilität des Betriebssystems führen könnte, wird die Kommunikation zwischen den jeweiligen Modulen unterbrochen. Anschließend kann an den Sender, also an das Drittprogramm bzw. an das Drittprogramm über den Anbindungs-Layer, eine entsprechende Ablehnungsinformation gesendet werden. Die Ablehnungsinformation kann Daten zum Grund der Ablehnung umfassen.
Die Überprüfung in der zweiten Überprüfungsstufe mit Bezug auf eine Fahrzeug- und/oder Fahrzeuginsassensicherheit kann dahingehend verstanden werden, dass die Funktionsaufruf- Daten dahingehend überprüft werden, ob ein Weiterleiten der Funktionsaufruf-Daten zum Betriebssystem und daraus resultierende Funktionsaufrufe die Fahrzeug- und/oder Fahrzeuginsassensicherheit gefährden könnten oder nicht. Unter der Fahrzeugsicherheit ist hierbei insbesondere eine mechanische und/oder elektromechanische Fahrzeugsicherheit, also beispielsweise keine Datensicherheit, zu verstehen. Mit anderen Worten, eine Überprüfung mit Bezug auf die Fahrzeugsicherheit kann dahingehend verstanden werden, dass die Überprüfung durchgeführt wird, um mechanische und/oder elektronische Schäden am Fahrzeug zu verhindern. Entsprechendes gilt auf analoge Weise hinsichtlich der Fahrzeuginsassensicherheit. Die Überprüfung der Funktionsaufruf-Daten mit Bezug auf die zu gewährleistende Fahrzeug- und/oder Fahrzeuginsassensicherheit kann erneut mittels eines vordefinierten Regelwerks, also basierend auf einem vordefinierten Satz von Regeln und/oder Bedingungen, durchgeführt werden. Als einfaches Beispiel für eine Überprüfung mit Bezug auf die Fahrzeug- und Fahrzeuginsassensicherheit sei ein Regelwerk genannt, gemäß welchem bei einer Fahrzeuggeschwindigkeit größer Null keine Akustikausgabe und/oder kein Öffnen einer Türe möglich sein darf. Wird in den Funktionsaufruf-Daten nun ein Funktionsaufruf erkannt, welcher zur Folge hätte, dass gegen dieses Regelwerk verstoßen werden müsste, werden die Funktionsaufruf- Daten im Sicherheits-Layer zurückgehalten bzw. nicht an das Betriebssystem und/oder nicht in Richtung des Kommunikations-Layers weitergeleitet.
Unter dem Kontrollieren der Funktionsaufrufe kann ein Steuern und/oder Regeln der Funktionsaufrufe verstanden werden. Insbesondere kann unter dem Kontrollieren der Funktionsaufrufe ein Ermöglichen und Verhindern angefragter bzw. vom Drittprogramm gesendeter Funktionsaufrufe bzw. entsprechender Funktionsaufruf-Daten verstanden werden.
Der Sicherheits-Layer kann konfigurierbar ausgestaltet sein. Insbesondere kann der Sicherheits-Layer oder ein Teil des Sicherheits-Layers abschaltbar ausgestaltet sein. Hierzu kann das Kontrollsystem ein geeignetes, vorzugsweise von einem Fahrzeuginsassen betätigbares Abschaltmodul aufweisen. Die Programmierschnittstelle kann als Teil des Betriebssystems oder als eigenständiger Teil unabhängig vom Betriebssystem betrachtet werden. Das Überprüfen kann mittels einer künstlichen Intelligenz des Kontrollsystems durchgeführt werden. Das heißt, die künstliche Intelligenz kann zum Durchführen der Überprüfung konfiguriert sein.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung ist es möglich, dass in einem Kontrollsystem der Sicherheits-Layer konfiguriert ist, eine Anzahl an Funktionsaufrufen in den Funktionsaufruf-Daten zu ermitteln und die Überprüfung basierend auf der ermittelten Anzahl an Funktionsaufrufen durchzuführen. Mit anderen Worten, abhängig von der ermittelten Anzahl an Funktionsaufrufen können die Funktionsaufruf-Daten weitergeleitet werden oder nicht. Auf diese Weise kann die Systemstabilität dahingehend gewährleistet werden, dass beispielsweise verhindert wird, dass eine nicht zuverlässig verarbeitbare Anzahl an Funktionsaufrufen an das Betriebssystem geschickt wird und das Betriebssystem auf diese Weise überlastet. Insbesondere kann verhindert werden, dass beispielsweise ein Kommunikations-Bussystem überlastet wird, wodurch wiederum eine Systeminstabilität verursacht werden könnte. Zusätzlich oder alternativ zur Ermittlung der Anzahl an Funktionsaufrufen können, zum Durchführen der Überprüfung, Funktionsaufrufe aufsummiert werden und sobald eine vordefinierte Anzahl an Funktionsaufrufen überschritten ist bzw. sobald ein vordefinierter Schwellwert erreicht oder übertroffen wurde, kann das Weiterleiten bzw. Senden der Funktionsaufruf-Daten verhindert bzw. verboten werden. Der Schwellwert kann basierend auf System Parametern des Fahrzeugs vordefiniert und/oder während einer Datenübertragung dynamisch ermittelt und entsprechend eingestellt werden oder sein. Neben der Anzahl der Funktionsaufrufe kann ein Zeitfaktor berücksichtigt werden. Über die Zeit und eine Abarbeitung der Funktionsaufrufe kann die vorstehend beschriebene Aufsummierung zurückgesetzt werden. Der Sicherheits-Layer kann entsprechend konfiguriert sein, um diese Schritte durchzuführen.
Die Erfindung betrifft ferner ein Kontrollsystem, bei welchem der Sicherheits-Layer konfiguriert ist, die Art wenigstens eines Funktionsaufrufs in den Funktionsaufruf-Daten zu ermitteln und die Überprüfung basierend auf der ermittelten Art des wenigstens eines Funktionsaufrufs durchzuführen. Mit anderen Worten, abhängig von der ermittelten Art des wenigstens einen Funktionsaufrufs können die Funktionsaufruf-Daten weitergeleitet werden oder nicht. Unter der Art des Funktionsaufrufs kann eine vordefinierte und/oder vordefinierbare Art eines Funktionsaufrufs verstanden werden. Funktionsaufrufe können sich in ihrer Art beispielsweise dahingehend unterscheiden, dass Funktionsaufrufe einer Art das Einstellen von Leuchtmitteln im Außenbereich des Fahrzeugs betreffen und einer anderen Art das Einstellen von Leuchtmitteln im Interieurbereich des Fahrzeugs betreffen. Andere Arten von Funktionsaufrufen können beispielsweise das Einstellen des Motors, das Einstellen der Klimaanlage und/oder das Einstellen des Infotainment-Systems betreffen. Viele weitere, allgemeinere oder detailliertere Arten von Funktionsaufrufen sind denkbar. Beim Durchführen der Überprüfung basierend auf der ermittelten Art kann die ermittelte Art mit vordefinierten Arten verglichen werden, und wenn die ermittelte Art einer der vordefinierten Art entspricht, oder wenn die ermittelte Art gerade nicht einer vordefinierten Art entspricht, können die Funktionsaufruf-Daten weitergeleitet werden, oder eben nicht. Auch auf diese Weise können unerwünschte Funktionsaufrufe auf einfache und zuverlässige Art verhindert werden.
Gemäß einer weiteren Ausgestaltungsvariante der vorliegenden Erfindung ist es möglich, dass bei einem Kontrollsystem der Sicherheits-Layer konfiguriert ist, die Nutzdatenmenge der Funktionsaufruf-Daten zu ermitteln und die Überprüfung basierend auf der ermittelten Nutzdatenmenge durchzuführen. Mit anderen Worten, abhängig von der ermittelten Nutzdatenmenge können die Funktionsaufruf-Daten weitergeleitet werden oder nicht. Indem alle Funktionsaufrufe Richtung Fahrzeug auf die enthaltene Nutzdatenmenge bzw. den entsprechenden Payload geprüft werden, kann beispielsweise verhindert werden, dass eine zu hohe Nutzdatenmenge das Betriebssystem und insbesondere das zugehörige Kommunikations- Bussystem überlastet und folglich zu einer Systeminstabilität führt. Das Überprüfen basierend auf der ermittelten Nutzdatenmenge kann mittels eines Vergleichs zwischen der ermittelten Nutzdatenmenge und einer vordefinierten oder vordefinierbaren Referenz- Nutzdatenmenge durchgeführt werden. Wird die vordefinierte Referenz-Nutzdatenmenge erreicht oder überschritten, wird das Weiterleiten der Funktionsaufruf- Daten verhindert. Die Referenz- Nutzdatenmenge kann anhand einer maximal zulässigen Buslast des jeweiligen Fahrzeugs, bei einem Überschreiten von welcher ein Überlasten des Kommunikations-Bussystems die Folge wäre, vordefiniert werden bzw. sein. Die Überprüfung basierend auf der ermittelten Nutzdatenmenge kann ferner dahingehend verstanden werden, dass die Nutzdatenmenge dahingehend begutachtet und/oder überprüft wird, dass bzw. ob die Daten der Nutzdatenmenge im richtigen bzw. in einem vordefinierten und/oder entsprechend gewünschten Bereich liegen. Auch auf diese Weise können Probleme in Bauteilen verhindert werden, da beispielsweise verhindert werden kann, dass die Bauteile nicht erreichbar sind und/oder außerhalb eines Betriebsbereichs liegen.
Darüber hinaus ist es bei einem erfindungsgemäßen Kontrollsystem möglich, dass der Sicherheits-Layer konfiguriert ist, eine Anomalie in den Funktionsaufruf- Daten zu ermitteln und die Überprüfung basierend auf der ermittelten Anomalie durchzuführen. Mit anderen Worten, abhängig von einer ermittelten Anomalie können die Funktionsaufruf-Daten weitergeleitet werden oder nicht. Auch auf diese Weise kann die Systemstabilität des Betriebssystems einfach und zuverlässig gewährleistet werden. Anomalien können insbesondere dann erkannt werden, wenn in den Funktionsaufruf-Daten mehrere Funktionsaufrufe enthalten sind bzw. wenn basierend auf den Funktionsaufruf-Daten mehrere Funktionsaufrufe ermittelt werden. Eine Anomalie kann dann ermittelt werden, wenn ein Funktionsaufruf oder Funktionsaufrufe ermittelt werden, die unter vordefinierten Bedingungen niemals vorkommen würden. Unter einer Anomalie kann ferner eine unerwartete Änderung oder ein unerwartetes Abweichen von einem erwarteten Muster in einem Datensatz verstanden werden. Die Anomalie kann mittels künstlicher Intelligenz ermittelt werden. Demnach kann der Sicherheits-Layer eine Ermittlungseinheit, beispielsweise mit einer künstlichen Intelligenz, zum entsprechenden Ermitteln einer Anomalie aufweisen.
Darüber hinaus ist es bei einem Kontrollsystem gemäß der vorliegenden Erfindung möglich, dass der Sicherheits-Layer konfiguriert ist, die Plausibilität für wenigstens einen Funktionsaufruf in den Funktionsaufruf-Daten zu beurteilen und die Überprüfung basierend auf der beurteilten Plausibilität durchzuführen. Mit anderen Worten, abhängig von einer beurteilten Plausibilität können die Funktionsaufruf-Daten weitergeleitet werden oder nicht. Auch auf diese Weise kann die Systemstabilität des Betriebssystems einfach und zuverlässig gewährleistet werden. Die Plausibilität der Systemaufruf-Daten bzw. der entsprechenden Systemaufrufe kann beispielsweise mit Bezug auf einen Zeitstempel beurteilt bzw. überprüft werden. Das heißt, passt der Zeitstempel nicht zu einer aktuellen Systemzeit des Fahrzeugs, können die Funktionsaufruf- Daten als unplausibel beurteilt werden und ein Weiterleiten der Funktionsaufruf- Daten kann verboten werden. Die Plausibilität kann mittels künstlicher Intelligenz beurteilt werden. Demnach kann der Sicherheits-Layer eine Ermittlungseinheit, beispielsweise mit einer künstlichen Intelligenz, zum entsprechenden Beurteilen der Plausibilität aufweisen.
Gemäß einer weiteren Ausführungsvariante der vorliegenden Erfindung ist es möglich, dass bei einem Kontrollsystem der Sicherheits-Layer konfiguriert ist, den Betriebszustand des Fahrzeugs zu ermitteln und die Überprüfung basierend auf dem ermittelten Betriebszustand des Fahrzeugs durchzuführen. Mit anderen Worten, die Funktionsaufruf-Daten können abhängig vom ermittelten Betriebszustand des Fahrzeugs weitergeleitet werden oder nicht. Auch dies kann auf relativ einfache Weise zur gewünschten Systemstabilität beitragen. Das vorstehend beschriebene Regelwerk kann als Teil des Sicherheits-Layers bereitgestellt und konfiguriert sein, sich automatisch über einen Betriebszustand des Fahrzeugs zu konfigurieren. Anhand des Betriebszustands kann beispielsweise ermittelt werden, ob das Fahrzeug gerade steht oder sich bewegt und mit welcher Geschwindigkeit und/oder Richtung sich das Fahrzeug bewegt. Der Betriebszustand des Fahrzeugs kann durch Parameter zum Motor und/oder zu einer möglichen Antriebsbatterie beeinflusst werden. Abhängig vom ermittelten Betriebszustand des Fahrzeugs können im Betriebssystem beispielsweise verschiedene Funktionen verboten werden. Abhängig von den definierten erlaubten und verbotenen Funktionen können nun bestimmte Funktionsaufruf- Daten bzw. entsprechende Funktionsaufrufe weitergeleitet werden oder nicht. Befindet sich das Fahrzeug beispielsweise in einem autonomen Betriebszustand, beispielsweise in einer Gefahrensituation, in welchem ein manuelles Eingreifen des Fahrers in den Fährbetrieb nicht zulässig ist, werden Funktionsaufrufe zum Verändern des Fahrverhaltens durch Drittprogramme nicht zum Betriebssystem geleitet bzw. im Sicherheits-Layer entsprechend gesperrt. Entsprechend ist es möglich, dass bei einem erfindungsgemäßen Kontra II system der Sicherheits-Layer konfiguriert ist, den Funktionszustand von Funktionsmodulen zum Ausführen des Betriebssystems zu ermitteln und die Überprüfung basierend auf dem ermittelten Funktionszustand der Funktionsmodule oder wenigstens eines Funktionsmoduls durchzuführen. Unter den Funktionsmodulen können insbesondere Funktionsmodule wie ein Arbeitsspeicher, ein Prozessor, ein Kommunikations-Bussystem und/oder ein Datenspeicher verstanden werden, die jeweils als Teil des Betriebssystems verstanden werden können. Wird erkannt, dass die Funktionsmodule bereits ausgelastet sind, könnten zumindest bestimmte Funktionsaufträge vom Drittprogramm zu einer Überlastung des Betriebssystems führen. Dies kann auf die vorgeschlagene Weise zuverlässig verhindert werden.
Ein weiterer Aspekt der Erfindung betrifft ein Fahrzeug mit einem wie vorstehend beschriebenen Kontra II system. Damit bringt das erfindungsgemäße Fahrzeug die gleichen Vorteile mit sich, wie sie ausführlich mit Bezug auf das erfindungsgemäße Kontrollsystem beschrieben worden sind. Unter dem Fahrzeug ist insbesondere ein Straßenfahrzeug, beispielsweise in Form eines PKW oder eines LKW, zu verstehen. Unter dem Fahrzeug kann jedoch auch ein Schienenfahrzeug, ein Wasserfahrzeug, ein Luftfahrzeug oder ein Roboter verstanden werden.
Ein weiterer Aspekt der Erfindung betrifft ein Verfahren zum Kontrollieren von Funktionsaufrufen in einem wie vorstehend beschriebenen Fahrzeug, aufweisend die Schritte:
Senden von Funktionsaufruf-Daten von einem Drittprogramm an den Anbindungs-Layer der Programmierschnittstelle,
Senden der Funktionsaufruf-Daten vom Anbindungs-Layer an den Sicherheits-Layer, Überprüfung der Funktionsaufruf-Daten durch den Sicherheits-Layer, und
Ermöglichen oder Verhindern eines Sendens der Funktionsaufruf-Daten vom Sicherheits- Layer in Richtung des Kommunikations-Layers anhand der durchgeführten Überprüfung.
Damit bringt das erfindungsgemäße Verfahren ebenfalls die vorstehend beschriebenen Vorteile mit sich. Das Verfahren kann zum Betreiben des vorstehend beschriebenen Kontrollsystems konfiguriert sein. So können im Rahmen des Verfahrens folgende Schritte durchgeführt werden: Ermitteln einer Anzahl an Funktionsaufrufen in den Funktionsaufruf-Daten und Durchführen der Überprüfung basierend auf der ermittelten Anzahl an Funktionsaufrufen, Ermitteln einer Art wenigstens eines Funktionsaufrufs in den Funktionsaufruf- Daten und Durchführen der Überprüfung basierend auf der ermittelten Art des wenigstens eines Funktionsaufrufs,
Ermitteln einer Nutzdatenmenge der Funktionsaufruf-Daten und Durchführen der Überprüfung basierend auf der ermittelten Nutzdatenmenge,
Ermitteln einer Anomalie in den Funktionsaufruf-Daten und Durchführen der Überprüfung basierend auf der ermittelten Anomalie,
Beurteilen einer Plausibilität für wenigstens einen Funktionsaufruf in den Funktionsaufruf- Daten und Durchführen der Überprüfung basierend auf der beurteilten Plausibilität, Ermitteln eines Betriebszustandes des Fahrzeugs und Durchführen der Überprüfung basierend auf dem ermittelten Betriebszustand des Fahrzeugs, und/oder
Ermitteln eines Funktionszustandes von Funktionsmodulen zum Ausführen des Betriebssystems und Durchführen der Überprüfung basierend auf dem ermittelten Funktionszustand des Betriebssystems.
Ein weiterer Aspekt der Erfindung betrifft ein Computerprogrammprodukt, das Befehle umfassend, die bewirken, dass das vorstehend beschriebene Kontrollsystem die beschriebenen Verfahrensschritte ausführt oder ausführen kann. Ferner betrifft die Erfindung ein computerlesbares, insbesondere nichtflüchtige Speichermedium, auf welchem ein solches Computerprogrammprodukt gespeichert ist. Damit bringt das erfindungsgemäße Computerprogrammprodukt und das erfindungsgemäße Speichermedium ebenfalls die vorstehend beschriebenen Vorteile mit sich.
Das Computerprogrammprodukt kann als computerlesbarer Anweisungscode in jeder geeigneten Programmiersprache und/oder Maschinensprache wie beispielsweise in JAVA, C++, C# und/oder Python implementiert sein. Das Computerprogrammprodukt kann auf einem computerlesbaren Speichermedium wie einer Datendisk, einem Wechsellaufwerk, einem flüchtigen oder nichtflüchtigen Speicher, oder einem eingebauten Speicher/Prozessor abgespeichert sein. Der Anweisungscode kann einen Computer oder andere programmierbare Geräte wie ein Steuergerät, das Bestandteil des Kontrollsystems sein kann, derart programmieren, dass die gewünschten Funktionen ausgeführt werden. Ferner kann das Computerprogrammprodukt in einem Netzwerk wie beispielsweise dem Internet bereitgestellt werden und/oder sein, von dem es bei Bedarf von einem Nutzer heruntergeladen werden kann. Das Computerprogrammprodukt kann sowohl mittels einer Software, als auch mittels einer oder mehrerer spezieller elektronischer Schaltungen, das heißt in Hardware oder in beliebig hybrider Form, das heißt mittels Software-Komponenten und Hardware-Komponenten, realisiert werden und/oder sein.
Weitere, die Erfindung verbessernde Maßnahmen ergeben sich aus der nachfolgenden Beschreibung zu verschiedenen Ausführungsbeispielen der Erfindung, welche in den Figuren schematisch dargestellt sind. Sämtliche aus den Ansprüchen, der Beschreibung oder den Figuren hervorgehende Merkmale und/oder Vorteile, einschließlich konstruktiver Einzelheiten und räumlicher Anordnungen können sowohl für sich als auch in den verschiedenen Kombinationen erfindungswesentlich sein.
Es zeigen jeweils schematisch:
Figur 1 ein Blockschaltbild zum Erläutern eines erfindungsgemäßen Kontrollsystems sowie Verfahrens zum Kontrollieren von Funktionsaufrufen in einem Fahrzeug,
Figur 2 ein Speichermedium mit einem darauf gespeicherten Computerprogrammprodukt gemäß einer Ausführungsform der Erfindung, und
Figur 3 ein Fahrzeug mit einem Kontrollsystem gemäß einer Ausführungsform der Erfindung.
Fig. 1 zeigt ein Kontrollsystem 10 zum Kontrollieren von Funktionsaufrufen und zugehörigen Funktionen in einem Fahrzeug 11, das in Fig. 3 dargestellt ist. Das Kontrollsystem 10 weist eine Programmierschnittstelle 12 für das Anbinden eines Drittprogramms 13 an ein computerimplementiertes Betriebssystem 14 des Fahrzeugs 11 auf. Ist das Drittprogramm 13 an die Programmierschnittstelle 12 angebunden, kann das Drittprogramm 13 Funktionsaufruf- Daten über die Programmierschnittstelle 12 an das Betriebssystem 14 Senden, sodass die in den Funktionsaufruf-Daten enthaltenen Funktionsausrufe bzw. wenigstens ein enthaltener Funktionsaufruf im Fahrzeug 11 ausgeführt werden kann. Hierzu weist die Programmierschnittstelle 12 einen Anbindungs-Layer 15 zum Senden der Funktionsaufruf- Daten von dem Drittprogramm 13 an die Programmierschnittstelle 12 und einen Kommunikations-Layer 18 zum Senden der Funktionsaufruf-Daten von der Programmierschnittstelle 12 an das Betriebssystem 14 auf. Ferner weist die dargestellte Programmierschnittstelle 12 einen zwischen dem Anbindungs-Layer 15 und dem Kommunikations-Layer 18 bereitgestellten Sicherheits-Layer 16 sowie einen zwischen dem Sicherheits-Layer 16 und dem Kommunikations-Layer 18 bereitgestellten Protokoll-Layer 17 auf.
Der Sicherheits-Layer 16 ist konfiguriert, eine Überprüfung der Funktionsaufruf-Daten, die vom Anbindungs-Layer 15 an den Sicherheits-Layer 16 gesendet werden, mit Bezug auf eine zu gewährleistende Systemstabilität des Betriebssystems 14 durchzuführen. Ferner ist der Sicherheits-Layer 16 konfiguriert, ein Senden der Funktionsaufruf-Daten vom Sicherheits-Layer 16 in Richtung des Kommunikations-Layers 18 basierend auf der durchgeführten Überprüfung zu ermöglichen oder zu verhindern bzw. in vorliegendem Fall abhängig von der Überprüfung an den Protokoll-Layer 17 weiterzuleiten oder nicht.
Der in Fig. 1 gezeigte Sicherheits-Layer 16 ist konfiguriert, die Überprüfung zweistufig durchzuführen, wobei in einer ersten Überprüfungsstufe die Überprüfung mit Bezug auf die Systemstabilität des Betriebssystems 14 durchgeführt wird und in einer zweiten Überprüfungsstufe eine Überprüfung mit Bezug auf eine Fahrzeug- und/oder Fahrzeuginsassensicherheit durchgeführt wird. Der Sicherheits-Layer 16 ist hierzu in den Kommunikationsfluss zwischen dem Anbindungs-Layer 15 und dem Kommunikations-Layer 18 und entsprechend in den Kommunikationsfluss zwischen dem Drittprogramm 13 und dem Betriebssystem 14 eingebettet. Zum Durchführen der ersten Überprüfungsstufe ist der Sicherheits-Layer 16 konfiguriert, eine Anzahl an Funktionsaufrufen in den Funktionsaufruf- Daten zu ermitteln, die Art wenigstens eines Funktionsaufrufs in den Funktionsaufruf- Daten zu ermitteln und die Nutzdatenmenge der Funktionsaufruf-Daten zu ermitteln, den Funktionszustand von Funktionsmodulen zum Ausführen des Betriebssystems 14 zu ermitteln und/oder die Überprüfung basierend auf der ermittelten Anzahl an Funktionsaufrufen, basierend auf der ermittelten Art des wenigstens eines Funktionsaufrufs, basierend auf dem ermittelten Funktionszustand der Funktionsmodule und/oder basierend auf der ermittelten Nutzdatenmenge durchzuführen. Zum Durchführen der zweiten Überprüfungsstufe ist der Sicherheits-Layer 16 konfiguriert, eine Anomalie in den Funktionsaufruf-Daten zu ermitteln, die Plausibilität für wenigstens einen Funktionsaufruf in den Funktionsaufruf-Daten zu beurteilen und/oder den Betriebszustand des Fahrzeugs zu ermitteln und die Überprüfung basierend auf der ermittelten Anomalie, basierend auf der beurteilten Plausibilität und/oder basierend auf dem ermittelten Betriebszustand des Fahrzeugs 11 durchzuführen.
Wurde die Überprüfung erfolgreich durchgeführt und wird im Sicherheits-Layer 16 entschieden, dass die Funktionsaufruf-Daten weitergeleitet werden dürfen bzw. dass ein Senden der Funktionsaufruf-Daten ermöglich wird, werden die Funktionsaufruf-Daten gemäß dem in Fig. 1 gezeigten Pfeil weiter in Richtung des Kommunikations-Layers 18 gesendet. Wird im Rahmen der Überprüfung hingegen festgestellt, dass die Funktionsaufruf-Daten nicht weitergeleitet werden dürfen bzw. dass ein Senden der Funktionsaufruf-Daten zu verhindern ist, werden die Funktionsaufruf- Daten nicht in Richtung des Betriebssystems weitergeleitet. Stattdessen wird, wie durch den gestrichelten Pfeil in Fig. 1 gezeigt, eine entsprechende Fehlernachricht an das Drittprogramm 13 gesendet.
Mit Bezug auf Fig. 1 kann ferner ein Verfahren zum Kontrollieren von Funktionsaufrufen in einem Fahrzeug 11 beschrieben werden. Zum Ausführen des Verfahrens werden zunächst Funktionsaufruf-Daten vom Drittprogramm 13 an den Anbindungs-Layer 15 gesendet. Anschließend werden Funktionsaufruf-Daten vom Anbindungs-Layer 15 an den Sicherheits- Layer 16 gesendet. Daraufhin werden die Funktionsaufruf-Daten durch den Sicherheits-Layer 16, wie vorstehend im Detail beschrieben, überprüft. Abhängig von der Überprüfung wird ein Weiterleiten der Funktionsaufruf-Daten vom Sicherheits-Layer 16 in Richtung des Kommunikations-Layers 18 ermöglicht oder nicht.
In Fig. 2 ist ein computerlesbares und nichtflüchtiges Speichermedium 20 in Form eines Memory-Sticks bzw. eines Flash-Drives dargestellt. Auf dem Speichermedium 20 Computerprogrammprodukt 19 gespeichert, das Befehle umfasst, die bewirken, dass das gezeigte und beschriebene Kontrollsystem 10 die vorstehend beschriebenen Verfahrensschritte ausführt.
In Fig. 3 ist ein Fahrzeug 11 in Form eines autonom fahrbaren Elektrofahrzeugs dargestellt, in welchem das in Fig. 1 gezeigte Kontrollsystem 10 installiert ist.
Die Erfindung lässt neben den dargestellten Ausführungsformen weitere Gestaltungsgrundsätze zu. Das heißt, die Erfindung soll nicht auf die mit Bezug auf die Figuren erläuterten Ausführungsbeispiele beschränkt betrachtet werden. Bezugszeichenliste
Kontrol I system Fahrzeug Programmierschnittstelle Drittprogramm Betriebssystem Anbindungs- Layer Sicherheits- Layer Protokoll-Layer
Kommunikations- Layer Computerprogrammprodukt Speichermedium

Claims

Patentansprüche
1. Kontra 11 system (10) zum Kontrollieren von Funktionsaufrufen in einem Fahrzeug (11), aufweisend eine Programmierschnittstelle (12) für das Anbinden eines Drittprogramms
(13) an ein computerimplementiertes Betriebssystem (14) des Fahrzeugs (11) zum Senden von Funktionsaufruf-Daten von dem Drittprogramm (13) an das Betriebssystem
(14) zum Ausführen von Funktionsausrufen im Fahrzeug (11), wobei die Programmierschnittstelle (12) einen Anbindungs-Layer (15) zum Senden der Funktionsaufruf-Daten von dem Drittprogramm (13) an die Programmierschnittstelle (12) und einen Kommunikations-Layer (18) zum Senden der Funktionsaufruf-Daten von der Programmierschnittstelle (12) an das Betriebssystem (14) aufweist, dadurch gekennzeichnet, dass die Programmierschnittstelle (12) ferner einen zwischen dem Anbindungs-Layer
(15) und dem Kommunikations-Layer (18) bereitgestellten Sicherheits-Layer (16) aufweist, der konfiguriert ist eine Überprüfung der Funktionsaufruf-Daten, die vom Anbindungs-Layer (15) an den Sicherheits-Layer (16) gesendet werden, mit Bezug auf eine zu gewährleistende Systemstabilität des Betriebssystems (14) durchzuführen und ein Senden der Funktionsaufruf-Daten vom Sicherheits-Layer (16) in Richtung des Kommunikations-Layers (18) basierend auf der durchgeführten Überprüfung zu ermöglichen oder zu verhindern.
2. Kontra II system (10) nach Anspruch 1 , dadurch gekennzeichnet, dass der Sicherheits-Layer (16) konfiguriert ist, eine Anzahl an Funktionsaufrufen in den Funktionsaufruf-Daten zu ermitteln und die Überprüfung basierend auf der ermittelten Anzahl an Funktionsaufrufen durchzuführen.
3. Kontra II system (10) nach einem der voranstehenden Ansprüche, dadurch gekennzeichnet, dass der Sicherheits-Layer (16) konfiguriert ist, die Art wenigstens eines Funktionsaufrufs in den Funktionsaufruf-Daten zu ermitteln und die Überprüfung basierend auf der ermittelten Art des wenigstens eines Funktionsaufrufs durchzuführen.
4. Kontra II system (10) nach einem der voranstehenden Ansprüche, dadurch gekennzeichnet, dass der Sicherheits-Layer (16) konfiguriert ist, die Nutzdatenmenge der Funktionsaufruf-Daten zu ermitteln und die Überprüfung basierend auf der ermittelten Nutzdatenmenge durchzuführen.
5. Kontra II system (10) nach einem der voranstehenden Ansprüche, dadurch gekennzeichnet, dass der Sicherheits-Layer (16) konfiguriert ist, eine Anomalie in den Funktionsaufruf- Daten zu ermitteln und die Überprüfung basierend auf der ermittelten Anomalie durchzuführen.
6. Kontra II system (10) nach einem der voranstehenden Ansprüche, dadurch gekennzeichnet, dass der Sicherheits-Layer (16) konfiguriert ist, die Plausibilität für wenigstens einen Funktionsaufruf in den Funktionsaufruf- Daten zu beurteilen und die Überprüfung basierend auf der beurteilten Plausibilität durchzuführen.
7. Kontra II system (10) nach einem der voranstehenden Ansprüche, dadurch gekennzeichnet, dass der Sicherheits-Layer (16) konfiguriert ist, den Betriebszustand des Fahrzeugs (11) zu ermitteln und die Überprüfung basierend auf dem ermittelten Betriebszustand des Fahrzeugs (11) durchzuführen.
8. Kontra II system (10) nach einem der voranstehenden Ansprüche, dadurch gekennzeichnet, dass der Sicherheits-Layer (16) konfiguriert ist, den Funktionszustand von Funktionsmodulen zum Ausführen des Betriebssystems (14) zu ermitteln und die Überprüfung basierend auf dem ermittelten Funktionszustand der Funktionsmodule durchzuführen.
9. Fahrzeug (11) mit einem Kontroll system (10) nach einem der voranstehenden Ansprüche.
10. Verfahren (10) zum Kontrollieren von Funktionsaufrufen in einem Fahrzeug (11) nach Anspruch 9, aufweisend: Senden von Funktionsaufruf-Daten von einem Drittprogramm (13) an den Anbindungs-Layer (15) der Programmierschnittstelle (12),
Senden der Funktionsaufruf-Daten vom Anbindungs-Layer (15) an den Sicherheits- Layer (16),
Überprüfung der Funktionsaufruf-Daten durch den Sicherheits-Layer (16), und Ermöglichen oder Verhindern eines Sendens der Funktionsaufruf-Daten vom Sicherheits-Layer (16) in Richtung des Kommunikations-Layers (18) anhand der durchgeführten Überprüfung.
11. Verfahren (10) nach Anspruch 10 zum Betreiben des Kontrollsystems (10) nach einem der Ansprüche 1 bis 8.
12. Computerprogrammprodukt (19) umfassend Befehle, die bewirken, dass das Kontra II system (10) nach einem der Ansprüche 1 bis 8 die Verfahrensschritte nach einem der Ansprüche 10 bis 11 ausführt.
13. Computerlesbares Speichermedium (20) mit einem darauf gespeicherten Computerprogrammprodukt (19) nach Anspruch 12.
EP24701680.1A 2023-01-26 2024-01-23 Kontrollsystem und verfahren zum kontrollieren von funktionsaufrufen in einem fahrzeug, computerprogrammprodukt und speichermedium Pending EP4655669A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102023200652.9A DE102023200652A1 (de) 2023-01-26 2023-01-26 Kontrollsystem und Verfahren zum Kontrollieren von Funktionsaufrufen in einem Fahrzeug, Computerprogrammprodukt und Speichermedium
PCT/EP2024/051518 WO2024156695A1 (de) 2023-01-26 2024-01-23 Kontrollsystem und verfahren zum kontrollieren von funktionsaufrufen in einem fahrzeug, computerprogrammprodukt und speichermedium

Publications (1)

Publication Number Publication Date
EP4655669A1 true EP4655669A1 (de) 2025-12-03

Family

ID=89707800

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24701680.1A Pending EP4655669A1 (de) 2023-01-26 2024-01-23 Kontrollsystem und verfahren zum kontrollieren von funktionsaufrufen in einem fahrzeug, computerprogrammprodukt und speichermedium

Country Status (3)

Country Link
EP (1) EP4655669A1 (de)
DE (1) DE102023200652A1 (de)
WO (1) WO2024156695A1 (de)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11132650B2 (en) 2011-04-22 2021-09-28 Emerging Automotive, Llc Communication APIs for remote monitoring and control of vehicle systems
DE102016202527A1 (de) * 2016-02-18 2017-08-24 Robert Bosch Gmbh Recheneinheit für ein Kraftfahrzeug
CN113196266A (zh) * 2018-10-02 2021-07-30 大众汽车股份公司 使用车辆的车辆计算单元执行一个或多个车辆应用的方法、车辆计算单元、用于提供用于车辆应用的许可信息清单的方法、用于车辆应用的许可信息清单和计算机程序
US20210012021A1 (en) * 2019-07-12 2021-01-14 Jeff Pickhardt Interposed secure function calls
DE102021106282A1 (de) * 2021-03-15 2022-09-15 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zur Überwachung der Interaktion zwischen einer SW-Anwendung und einer Fahrzeug-Komponente

Also Published As

Publication number Publication date
WO2024156695A1 (de) 2024-08-02
DE102023200652A1 (de) 2024-08-01

Similar Documents

Publication Publication Date Title
EP3584140B1 (de) Verfahren und vorrichtung für die steuerung eines sicherheitsrelevanten vorganges, sowie fahrzeug
EP2705430B1 (de) System zur diagnose einer komponente in einem fahrzeug
EP3698273B1 (de) Verfahren und system zum betreiben eines fahrzeugs
DE102017100380A1 (de) Diagnostiktest-durchführungssteuersystem und verfahren
DE102018220605B4 (de) Kraftfahrzeugnetzwerk und Verfahren zum Betreiben eines Kraftfahrzeugnetzwerks
DE102020121540A1 (de) Bestimmungseinrichtung, Bestimmungssystem, Speichermedium, das ein Programm speichert, und Bestimmungsverfahren
DE102017218643A1 (de) Funktionsmodul, Steuereinheit für ein Betriebsassistenzsystem und Arbeitsvorrichtung
DE112019007286T5 (de) Fahrzeuginterne steuerungsvorrichtung und fahrzeuginternes steuerungssystem
DE102023110645A1 (de) Sicherheitsverfahren und Sicherheitsvorrichtung
DE102019202527A1 (de) Sicherheitssystem und Verfahren zum Betreiben eines Sicherheitssystems
DE102023200871A1 (de) Verfahren zur Bereitstellung einer Rückfallfunktion für eine sicherheitsrelevante Fahrfunktion
DE102022201898A1 (de) Mitigation einer manipulation von software eines fahrzeugs
DE102021213666A1 (de) Verfahren und Computerprogramm zum Erkennen einer Manipulation eines Steuergeräts eines Kraftfahrzeugs, Steuergerät-System und computerlesbares Medium
DE102011087063A1 (de) Kontrollrechnersystem und Verfahren zur beschleunigten Initialisierung einzelner Module
DE102022201895A1 (de) Mitigation einer manipulation von software eines fahrzeugs
EP4655669A1 (de) Kontrollsystem und verfahren zum kontrollieren von funktionsaufrufen in einem fahrzeug, computerprogrammprodukt und speichermedium
DE102021207870A1 (de) Verfahren und Recheneinheit zum Verwalten von Diagnoseanfragen in einem Netzwerk
DE102016105876A1 (de) Elektronisches Steuergerät für ein Fahrzeug mit separater Datenverbindung, Assistenzsystem, Fahrzeug sowie Verfahren
DE102022208003A1 (de) Verfahren für eine Kontrolle eines Zugriffs verschiedener Applikationen bei einem Fahrzeug
DE102019004612A1 (de) Verfahren zum Betreiben eines Fahrzeugs mit einem Steuergerät
DE102019111244A1 (de) Verfahren, Server und Diagnosesystem zum Durchführen einer servergestützten Diagnose für ein Fortbewegungsmittel
DE102022208004A1 (de) Verfahren für eine Kontrolle eines Zugriffs verschiedener Applikationen bei einem Fahrzeug
EP4437414A1 (de) Partizipatives sicherheitsprotokoll für datenwolken-basierte funktionen
DE102018200429A1 (de) Störungsbehandlung in einem System
DE102023207033A1 (de) Verfahren sowie Vorrichtung zur Mitigation einer Auswirkung eines fehlerhaften Sensors eines Fahrzeugs

Legal Events

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

Free format text: STATUS: UNKNOWN

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

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

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250826

AK Designated contracting states

Kind code of ref document: A1

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)