WO2013164224A2 - Verfahren und vorrichtung zur überwachung von funktionen eines rechnersystems, vorzugsweise eines motorsteuersystems eines kraftfahrzeuges - Google Patents
Verfahren und vorrichtung zur überwachung von funktionen eines rechnersystems, vorzugsweise eines motorsteuersystems eines kraftfahrzeuges Download PDFInfo
- Publication number
- WO2013164224A2 WO2013164224A2 PCT/EP2013/058382 EP2013058382W WO2013164224A2 WO 2013164224 A2 WO2013164224 A2 WO 2013164224A2 EP 2013058382 W EP2013058382 W EP 2013058382W WO 2013164224 A2 WO2013164224 A2 WO 2013164224A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- monitoring
- level
- safe mode
- program
- operated
- Prior art date
Links
Classifications
-
- 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/16—Error detection or correction of the data by redundancy in hardware
- G06F11/1629—Error detection by comparing the output of redundant processing systems
- G06F11/1641—Error detection by comparing the output of redundant processing systems where the comparison is not performed by the redundant processing components
-
- 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
- G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
- G06F11/076—Error or fault detection not based on redundancy by exceeding limits by exceeding a count or rate limit, e.g. word- or bit count limit
-
- 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/0793—Remedial or corrective actions
-
- 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/0796—Safety measures, i.e. ensuring safe condition in the event of error, e.g. for controlling element
Definitions
- Method and device for monitoring functions of a computer system preferably an engine control system of a motor vehicle
- the invention relates to a method for monitoring functions of a computer system, preferably an engine control system of a motor vehicle, which has at least two arithmetic units, wherein at least one first arithmetic unit is operated in a safe mode.
- monitoring functions In safety-related applications, in particular in motor vehicles, it is customary to monitor functions of the computer program with safety-relevant properties. For this purpose, specially provided monitoring functions are used. These monitoring functions either validate the results of the functions to be monitored or check critical resources. The monitoring function itself is often classified as particularly important and worthy of protection. Therefore, the monitoring functions are self-monitored, such as in a three-level concept used in engine control in automobiles.
- a method for monitoring functions of a computer system having at least two execution units wherein at least two operating modes of the execution units are switched and a first operating mode corresponds to a comparison mode, in which the two execution units have identical or similar instructions, Execute program segments or programs and output signals of the two execution units are compared with each other and a second operating mode, which corresponds to a performance mode in which the Execution units execute different commands, program segments or programs in parallel, and a first function is monitored by a second monitoring function.
- the monitoring function is executed in comparison mode on at least two execution units. This further safeguards the monitoring.
- this method is not feasible on all computer architectures, since it requires a switch between the operating modes.
- the invention is therefore based on the object of specifying a method for monitoring functions of a computer system in which the independence between monitored function and monitoring is given and which is executable on general computer architectures.
- the object is achieved by operating a monitoring level of a computer program executed on the computer system, which monitors an application level of the computer program, on the first computer operated in the safe mode.
- This has the advantage that the monitoring level is processed on a different arithmetic unit than the function to be monitored in the form of the application level.
- this method has a multi-core capability, and it ensures an optimal handling of the selected computer architectures, the method is not limited to selected computer architectures.
- the secured mode is realized by a lockstep operation or a fault-redundant operation.
- this method can be executed on a general type of computer architecture, since the monitoring level is always processed on a secure computing unit and there is at least one further arithmetic unit that does not necessarily have to be protected on which, for example, the functions of the application level are processed. By securing the monitoring level, it can be considered more trustworthy than other parts of the computer program.
- the computer program is divided into, belonging to the monitoring level computing program parts and in the monitoring level not belonging computing program parts, in particular the belonging to the monitoring level computational program parts are checked for affiliation to the monitoring level and after confirming affiliation to the monitoring level these computational program parts of the processing on the be assigned in the safe mode operated computing unit.
- further computation program parts belonging to the application level and / or to a security level monitoring the monitoring level are processed by the computing unit operated in the safe mode.
- This is particularly advantageous whenever the processing unit operated in the safe mode is not fully utilized by the functions of the monitoring level.
- safety-relevant computational program parts of the application level and the security level, which monitors the monitoring level also on the first Arithmetic unit to be processed.
- the computation program parts which do not belong to the monitoring level are subdivided into whether or not they are monitored by the monitoring level, the computation program parts, which are not monitored by the monitoring level, being supplied to the second arithmetic unit, which does not have a safe mode, for processing.
- This allows a good separation of monitored and unmonitored functions, as they are processed on different arithmetic units. Spatial independence is achieved by the distribution to different arithmetic units since the monitoring is performed by a different hardware element than the execution of the monitored functions.
- the computation program parts belonging to the monitoring level or the computational program parts which belong to the application level and / or the security level and which are relevant for safety become at least one security object, preferably one
- Runtime object summarized, which is managed by an operating system. This summary allows the security objects to be run via the operating system that runs the first secure unit operating in safe mode.
- a suitable strategy of the operating system for example by a time-controlled strategy, a temporal independence between monitoring and monitored object can be represented very well.
- the at least one security object accesses a defined memory area, provided exclusively for the security object, of the first computing unit operated in the safe mode.
- the security objects have their own memory area, on which only these can access. Such a memory limit further increases the independence between monitoring and monitored object.
- the memory area provided for the security object is protected by a memory protection unit, wherein it is preferably ensured that no computer program that is being processed on the second arithmetic unit accesses the memory area.
- At least one element of a monitoring periphery of the computer system directly accesses only the first computing unit operated in the safe mode.
- the influence of the second arithmetic unit on the first arithmetic unit or the elements of the monitoring periphery controlled by it is further suppressed, in particular whenever they are connected to the first arithmetic unit in such a way that they are connected to the first arithmetic unit be configured and read out or controlled.
- a development of the invention relates to a device for monitoring functions of a computer system, preferably an engine control system of a motor vehicle, which has at least two arithmetic units, wherein at least one first arithmetic unit is operated in a safe mode.
- a device in which the independence and the proof of independence of monitored function and monitoring is given means are provided which operate on the operated in the safe mode first computing unit a monitoring level of processed on the computer system computer program which an application level of the computer program supervised.
- This has the advantage that the monitoring level is processed on a different arithmetic unit than the function to be monitored in the form of the application level, whereby the independence between monitored function and monitoring function is given. This separation is independent of the computer architecture used.
- the first arithmetic unit in the safe mode forms a lockstep pair with a third arithmetic unit, the first and the third arithmetic unit processing the same program sequences whose output signals are evaluated for error monitoring in a comparator.
- This embodiment allows a structurally simple monitoring of the surveillance level.
- the invention allows numerous embodiments. One of them will be explained in more detail with reference to the figures shown in the drawing. It shows:
- Figure 1 an embodiment of the device according to the invention
- Figure 2 a safety concept for an engine control system of a motor vehicle
- FIG. 3 shows a flow chart for the method according to the invention
- Figure 1 shows a computer architecture, as used in an engine control unit of a motor vehicle.
- the computer architecture is designed as a microprocessor 1 and contains three computing units 2, 3, 4 designated as computer core.
- the arithmetic unit 2 is connected directly to a system bus 5, while the arithmetic units 3 and 4 are connected to the system bus 5 via a comparator 6. In this case, the arithmetic unit 3 is monitored by the arithmetic unit 4.
- the arithmetic units 3 and 4 form a so-called lockstep
- the three-level concept which is shown in FIG. 2, has all the application functionalities of the engine control in a first application level 11.
- the three-level concept which is shown in FIG. 2, has all the application functionalities of the engine control in a first application level 11.
- Monitoring level 12 the application functionalities of the application monitored on-line 1 1 by monitoring functions, while the security level 13 in turn monitors the functions of the monitoring level 12.
- the Application Level 1 which includes the application functionalities, the calculation of the torque to be set by the engine takes place as a particularly safety-relevant part. This moment affects the acceleration of the vehicle. In the simplest security case, only too high a torque is to be classified as critical and this can be detected by the second monitoring level 12 by means of the monitoring functions. In somewhat more complex cases, for example, too small a moment can already be classified as safety-relevant and must then also be determined by the monitoring level 12.
- monitoring level 12 the monitoring of this moment expires. This can be carried out, for example, by the monitoring level 12 likewise calculating a moment or an upper and / or lower limit for the moment and then checking whether the torque calculated by the application level 1 1 coincides with the torque calculated in the monitoring level 12 or within tolerated barriers. Another possibility is that the torque calculated by the application plane 11 may be compared with other sensor signals, e.g. the driver request recording, plausibility. It can also be used a determined from a map barrier. If the monitoring functions of the monitoring level 12 determine that the torque calculated by the application level 11 is wrong in a safety-relevant manner, then it can initiate suitable countermeasures for establishing a safe state. Such countermeasures include, for example, the shutdown, the triggering of a reset or the limitation of the moment.
- the security level 13 is intended to monitor the functionality and the actual functioning of the monitoring level 12. Only if it is ensured that the monitoring level 12 actually works, can it be assumed that the monitoring implemented by the monitoring level 12 actually prevents a safety-critical state. The correct and error-free functioning of the monitoring level 12 is therefore of great importance for such a security concept. For this reason, the monitoring functions of the monitoring level 12 on the lockstep pair, consisting of the arithmetic units 3, 4, processed. The software sees the two arithmetic units 3, 4, which work in a safe mode, thereby only as a computer core.
- the assignment of the software stored as a computer program for running on the arithmetic units 2, 3, 4 can then be made according to the following flow chart.
- the computer program running on the microprocessor 1 is divided into the various known three levels 1 1, 12, 13.
- a predetermined computer program part is checked whether it belongs to monitoring level 12 of the safety concept of the motor vehicle. If this is the case, then in block 9 this computer program part is assigned to the lockstep pair 3, 4 for processing. If the examined computer program part does not belong to the monitoring level 12, then there is no fixed assignment of the computer program parts to be processed to a computer unit 2 or 3 (block 10).
- Strategy for example, a timed strategy, can thus also very well presented and argued a temporal independence between monitoring and monitored object.
- the individual functions regardless of their affiliation to the levels 1 1, 12, 13 divided into intervals of 5 ms, 10ms, etc. This is particularly advantageous when functional interrupts are not executed on the monitored arithmetic unit 3.
- This also allows a division of the functions into the computer program-technical functions, which not only run along temporal differences but also along the safety-related relevance.
- a particular advantage is given if in block 7 the computation program is decomposed not only into functions of the monitoring level 12 or functions not belonging to the monitoring level 12, but if there is a further decomposition in the case of the computation program parts not belonging to the monitoring level 12 whether or not a given computational program part is being monitored by the monitoring plane 12. If independence, for example in the form of a "freedom from interference" argument as required by the ISO 26262 standard, is to be demonstrated between the surveillance and the monitored functions, then it is advantageous to have the monitored functions, in this case the Functions, which do not belong to the computer program part of the monitoring level 12, to run on the independent second arithmetic unit 2. This spatial independence over the distribution to several arithmetic units 2, 3 is an additional argument, since the monitoring is performed by a different hardware element is considered the processing of the monitored functions.
- a further possibility for expansion of the considered method consists in the targeted additional use of a memory protection unit in the form of an MPU (Memory Protection Unit).
- MPU Memory Protection Unit
- a two-stage MPU which can be realized via an additional safety MPU on the system bus 5 or on a slave side of the microprocessor 1, is used. If the security objects have their own memory area (for example in a flash, RAM, ROM), which only these security objects are allowed to access, then this memory limit can be forced by programming the security protection unit in the microprocessor 1. This can be improved even further by realizing this via the second layer of the MPU or the Safety MPU.
- the independence between monitoring and monitored function can also be further improved if a monitoring periphery, for example in the form of special sensors, is connected directly to the arithmetic unit 3, so that these sensors are configured and read or controlled by the arithmetic unit 3 without the arithmetic unit 2 has an influence on it.
- a monitoring periphery for example in the form of special sensors
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Combined Controls Of Internal Combustion Engines (AREA)
Abstract
Die Erfindung betrifft ein Verfahren zur Überwachung von Funktionen eines Rechnersystems, vorzugsweiseeines Motorsteuersystems eines Kraftfahrzeuges, welches mindestens zwei Recheneinheiten (2, 3) aufweist, wobei wenigstens eine erste Recheneinheit (3) in einem abgesicherten Modus betrieben wird. Bei einem Verfahren, bei welchem die Unabhängigkeit zwischen überwachter Funktion und Überwachung gegeben ist, wird auf der in dem abgesicherten Modus betriebenen ersten Recheneinheit (3) eine Überwachungsebene (12) eines auf dem Rechnersystem (1) abgearbeiteten Rechenprogramms betrieben wird, welche eine Applikationsebene (11) des Rechenprogramms überwacht.
Description
Verfahren und Vorrichtung zur Überwachung von Funktionen eines Rechnersvs- tems, vorzugsweise eines Motorsteuersvstems eines Kraftfahrzeuges
Stand der Technik
Die Erfindung betrifft ein Verfahren zur Überwachung von Funktionen eines Rechnersystems, vorzugsweise eines Motorsteuersystems eines Kraftfahrzeuges, welches mindestens zwei Recheneinheiten aufweist, wobei wenigstens eine erste Recheneinheit in einem abgesicherten Modus betrieben wird.
In sicherheitstechnischen Anwendungen, insbesondere in Kraftfahrzeugen, ist es üblich, Funktionen des Rechenprogramms mit sicherheitsrelevanten Eigenschaften zu überwachen. Dazu werden speziell dafür vorgesehene Überwachungsfunktionen verwendet. Diese Überwachungsfunktionen plausibilisieren entweder die Ergebnisse der zu überwachenden Funktionen oder sie überprüfen kritische Ressourcen. Die Überwachungsfunktion selbst wird häufig als besonders wichtig und schützenswert eingestuft. Deshalb werden die Überwachungsfunktionen, wie beispielsweise in einem Dreiebenenkonzept, das bei der Motorsteuerung in Kraftfahrzeugen zur Anwendung kommt, selbst überwacht.
Gemäß der DE 10 2005 037 230 A1 ist ein Verfahren zur Überwachung von Funktionen eines Rechnersystems mit wenigstens zwei Ausführungseinheiten bekannt, wobei zwischen wenigstens zwei Betriebsmodi der Ausführungseinheiten umgeschaltet wird und ein erster Betriebsmodus einem Vergleichsmodus entspricht, bei dem die beiden Ausführungseinheiten gleiche oder gleichartige Befehle, Programmsegmente oder Programme abarbeiten und Ausgangssignale der beiden Ausführungseinheiten miteinander verglichen werden und einem zweiten Betriebsmodus, der einen Performance-Modus entspricht, bei dem die
Ausführungseinheiten unterschiedliche Befehle, Programmsegmente oder Programme parallel ausführen, und eine erste Funktion von einer zweiten Überwachungsfunktion überwacht wird. Die Überwachungsfunktion wird dabei im Vergleichsmodus auf mindestens zwei Ausführungseinheiten abgearbeitet. Dadurch wird die Überwachung weiter abgesichert. Allerdings ist dieses Verfahren nicht auf allen Rechnerarchitekturen durchführbar, da es eine Umschaltung zwischen den Betriebsmodi erfordert.
Zukünftig sind insbesondere aufgrund der Gültigkeit der ISO 26262 verstärkte Sicherheitsanforderungen zu erfüllen. Diese Sicherheitsanforderungen beziehen sich auf die Unabhängigkeit und den Nachweis der Unabhängigkeit von überwachter Funktion und Überwachung.
Offenbarung der Erfindung
Der Erfindung liegt somit die Aufgabe zugrunde, ein Verfahren zur Überwachung von Funktionen eines Rechnersystems anzugeben, bei welchem die Unabhängigkeit zwischen überwachter Funktion und Überwachung gegeben ist und welches auf allgemeinen Rechnerarchitekturen ausführbar ist.
Erfindungsgemäß wird die Aufgabe dadurch gelöst, dass auf der in dem abgesicherten Modus betriebenen ersten Recheneinheit eine Überwachungsebene eines auf dem Rechnersystem abgearbeiteten Rechenprogramms betrieben wird, welche eine Applikationsebene des Rechenprogramms überwacht. Dies hat den Vorteil, dass die Überwachungsebene auf einer anderen Recheneinheit abgearbeitet wird als die zu überwachenden Funktion in Form der Applikationsebene. Dadurch, dass die Überwachungsebene auf einer Recheneinheit abgearbeitet wird, welche in einem abgesicherten Modus betrieben wird, was bedeutet, dass die Funktionsweise der Recheneinheit auf ihre Betriebssicherheit überprüft wird, wird sichergestellt, dass die Überwachungsebene immer zuverlässig arbeitet.
Gleichzeitig kann ein Nachweis der Unabhängigkeit von überwachter Funktion und Überwachung geführt werden. Darüber hinaus weist dieses Verfahren eine Multicore-Tauglichkeit auf, und es ist ein optimaler Umgang mit den gewählten Rechnerarchitekturen sichergestellt, wobei das Verfahren nicht auf ausgesuchte Rechnerarchitekturen beschränkt ist.
Vorteilhafterweise wird der abgesicherte Modus durch einen Lockstep-Betrieb oder einen fault-redundant-Betrieb realisiert. Dadurch kann dieses Verfahren auf einer allgemeinen Art von Rechnerarchitektur ausgeführt werden, da die Überwachungsebene immer auf einer abgesicherten Recheneinheit abgearbeitet wird und mindestens eine weitere Recheneinheit vorhanden ist, die nicht zwingend abgesichert werden muss, auf welcher beispielsweise die Funktionen der Applikationsebene bearbeitet werden. Durch die Absicherung der Überwachungsebene kann diese im erhöhten Maße als andere Teile des Rechenprogramms als vertrauenswürdig eingestuft werden.
In einer Ausgestaltung wird das Rechenprogramm in, der Überwachungsebene angehörende Rechenprogrammteile und in, der Überwachungsebene nicht angehörende Rechenprogrammteile zerlegt, wobei insbesondere die zur Überwachungsebene gehörenden Rechenprogrammteile auf ihre Zugehörigkeit zur Überwachungsebene überprüft werden und nach der Bestätigung der Zugehörigkeit zur Überwachungsebene diese Rechenprogrammteile der Bearbeitung auf der in dem abgesicherten Modus betriebenen Recheneinheit zugewiesen werden. Durch diese Maßnahmen wird die Zuverlässigkeit der durch die Überwachungsebene ausgeführten Funktionen weiter erhöht und gewährleistet, dass diese Funktionen auf der ersten, in dem abgesicherten Modus betriebenen Recheneinheit bearbeitet werden.
In einer Variante werden weitere sicherheitstechnisch relevante, zur Applikationsebene und/oder zu einer, die Überwachungsebene überwachenden Sicher- heitsebene gehörende Rechenprogrammteile von der in dem abgesicherten Modus betriebenen Recheneinheit bearbeitet. Dies ist insbesondere immer dann von Vorteil, wenn die in dem abgesicherten Modus betriebene Recheneinheit durch die Funktionen der Überwachungsebene nicht voll ausgelastet ist. Um eine annähernd gleichmäßige Auslastung der ersten, in dem abgesicherten Modus betriebenen Recheneinheit und der zweiten Recheneinheit, die nicht abgesichert ist, zu erreichen, ist es vorteilhaft, wenn sicherheitstechnisch relevante Rechenprogrammteile der Applikationsebene und der Sicherheitsebene, welche die Überwachungsebene überwacht, ebenfalls auf der ersten Recheneinheit bearbeitet werden.
In einer Weiterbildung werden die nicht zur Überwachungsebene gehörenden Rechenprogrammteile dahingehend unterteilt, ob diese von der Überwachungsebene überwacht werden oder nicht, wobei die nicht von der Überwachungsebene überwachten Rechenprogrammteile der zweiten Recheneinheit, welche kei- nen abgesicherten Modus aufweist, zur Bearbeitung zugeführt werden. Dadurch wird eine gute Trennung von überwachten und nicht überwachten Funktionen ermöglicht, da diese auf unterschiedlichen Recheneinheiten verarbeitet werden. Durch die Verteilung auf verschiedene Recheneinheiten wird eine räumliche Unabhängigkeit erzielt, da die Überwachung durch ein anderes Hardwareelement vorgenommen wird, als die Abarbeitung der überwachten Funktionen.
In einer weiteren Ausführungsform werden die zur Überwachungsebene gehörenden Rechenprogrammteile oder die sicherheitstechnisch relevanten, zu der Applikationsebene und/oder der Sicherheitsebene gehörenden Rechenpro- grammteile zu jeweils mindestens einem Sicherheitsobjekt, vorzugsweise einem
Laufzeitobjekt, zusammengefasst, welches von einem Betriebssystem verwaltet wird. Durch diese Zusammenfassung können die Sicherheitsobjekte über das Betriebssystem, welches die erste, im abgesicherten Modus arbeitende Recheneinheit betreibt, zum Ablauf gebracht werden. Durch eine geeignete Strategie des Betriebssystems, beispielsweise durch eine zeitgesteuerte Strategie, kann damit auch eine zeitliche Unabhängigkeit zwischen Überwachung und überwachtem Objekt sehr gut dargestellt werden.
Vorteilhafterweise greift das mindestens eine Sicherheitsobjekt auf einen defi- nierten, ausschließlich für das Sicherheitsobjekt vorgesehenen Speicherbereich der ersten, in dem abgesicherten Modus betriebenen Recheneinheit zu. Somit haben die Sicherheitsobjekte einen eigenen Speicherbereich, auf dem nur diese zugreifen können. Durch eine solche Speichergrenze wird die Unabhängigkeit zwischen Überwachung und überwachtem Objekt weiter erhöht.
In einer Ausgestaltung wird der für das Sicherheitsobjekt vorgesehene Speicherbereich durch eine Speicherschutzeinheit abgesichert, wobei vorzugsweise sichergestellt wird, dass kein Rechenprogramm, was auf der zweiten Recheneinheit bearbeitet wird, auf den Speicherbereich zugreift. Durch die Sicherstellung, dass kein Rechenprogramm, was auf einer anderen Recheneinheit läuft, auf die
Speicherbereiche der ersten Recheneinheit zugreifen kann, wird selbst in Anwe-
senheit von Fehlern auf der zweiten Recheneinheit garantiert, dass die Sicherheitsobjekte jederzeit ohne Beeinflussung bleiben. Dadurch werden eine außerordentlich große Verlässlichkeit und die Einflussfreiheit der zweiten Recheneinheit auf die in dem abgesicherten Modus arbeitende erste Recheneinheit darge- stellt.
In einer weiteren Ausgestaltung greift auf mindestens ein Element einer Überwachungsperipherie des Rechnersystems direkt nur die erste, in dem abgesicherten Modus betriebene Recheneinheit zu. Infolge dieser speziellen Anbindung der Pe- ripherie wird der Einfluss der zweiten Recheneinheit auf die erste Recheneinheit bzw. die von dieser kontrollierten Elemente der Überwachungsperipherie weiter unterbunden, insbesondere immer dann, wenn diese in der Art an die erste Recheneinheit angebunden sind, dass sie von dieser konfiguriert und ausgelesen bzw. angesteuert werden.
Eine Weiterbildung der Erfindung betrifft eine Vorrichtung zur Überwachung von Funktionen eines Rechnersystems, vorzugsweise eines Motorsteuersystems eines Kraftfahrzeuges, welches mindestens zwei Recheneinheiten aufweist, wobei wenigstens eine erste Recheneinheit in einem abgesicherten Modus betrieben wird. Bei einer Vorrichtung, bei welcher die Unabhängigkeit und der Nachweis der Unabhängigkeit von überwachter Funktion und Überwachung gegeben ist, sind Mittel vorhanden, welche auf der in dem abgesicherten Modus betriebenen ersten Recheneinheit eine Überwachungsebene eines auf dem Rechnersystem abgearbeiteten Rechenprogramms betreiben, welche eine Applikationsebene des Rechenprogramms überwacht. Dies hat den Vorteil, dass die Überwachungsebene auf einer anderen Recheneinheit bearbeitet wird als die zu überwachende Funktion in Form der Applikationsebene, wodurch die Unabhängigkeit zwischen überwachter Funktion und Überwachungsfunktion gegeben ist. Diese Trennung ist unabhängig von der verwendeten Rechnerarchitektur.
Vorteilhafterweise bildet die erste Recheneinheit in dem abgesicherten Modus mit einer dritten Recheneinheit ein Lockstep-Paar, wobei die erste und die dritte Recheneinheit die gleichen Programmabläufe verarbeiten, deren Ausgangssignale zur Fehlerüberwachung in einem Vergleicher ausgewertet werden. Diese Ausgestaltung ermöglicht eine konstruktiv einfache Überwachung der Überwachungsebene.
Die Erfindung lässt zahlreiche Ausführungsformen zu. Eine davon soll anhand der in der Zeichnung dargestellten Figuren näher erläutert werden. Es zeigt:
Figur 1 : ein Ausführungsbeispiel der erfindungsgemäßen Vorrichtung
Figur 2: ein Sicherheitskonzept für ein Motorsteuerungssystem eines Kraftfahr- zeuges
Figur 3: ein Ablaufdiagramm für das erfindungsgemäße Verfahren
Figur 1 zeigt eine Rechnerarchitektur, wie sie in einem Motorsteuergerät eines Kraftfahrzeuges eingesetzt wird. Die Rechnerarchitektur ist als Mikroprozessor 1 ausgebildet und enthält drei als Rechnerkern bezeichneten Recheneinheiten 2, 3, 4. Die Recheneinheit 2 ist dabei direkt mit einem Systembus 5 verbunden, während die Recheneinheiten 3 und 4 über einen Vergleicher 6 an den Systembus 5 angebunden sind. Dabei wird die Recheneinheit 3 von der Recheneinheit 4 überwacht. Die Recheneinheiten 3 und 4 bilden dabei ein sogenanntes Lockstep-
Paar innerhalb des Mikroprozessors 1. Die Verwendung eines solchen Lockstep- Paares schützt die auf diesem Lockstep-Paar ablaufende Software gegen Fehler in der Hardware eines Rechnerkerns. Dabei werden auf den Recheneinheiten 3 und 4 dieselben Programmschritte und Daten parallel zueinander abgearbeitet. Die Signale der beiden Recheneinheiten 3, 4 werden dann im Vergleicher 6 verglichen. Sobald einer der beiden beteiligten Recheneinheiten 3, 4 ein anderes Ergebnis als die Partnerrecheneinheit 3, 4 an den Vergleicher 6 liefert, wird dieses durch den Vergleicher 6 detektiert und ein entsprechendes Fehlersignal ausgelöst. Dieses Fehlersignal wird wiederum dazu verwendet, den sicheren Zu- stand des Mikroprozessors 1 herzustellen.
Mittels des in Figur 1 gezeigten Mikroprozessors 1 werden Motorsteuerungssysteme überwacht, welche ein Dreiebenenkonzept aufweisen. Das
Dreiebenenkonzept, welches in Figur 2 dargestellt ist, weist in einer ersten Appli- kationsebene 1 1 alle Applikationsfunktionalitäten der Motorsteuerung auf. In der
Überwachungsebene 12 werden die Applikationsfunktionalitäten der Applikati-
onsebene 1 1 durch Uberwachungsfunktionen überwacht, während die Sicherheitsebene 13 wiederum die Funktionen der Überwachungsebene 12 überwacht.
In der, die Applikationsfunktionalitäten umfassenden Applikationsebene 1 1 läuft als besonders sicherheitstechnisch interessanter Teil die Berechnung des vom Motor zu stellenden Momentes ab. Dieses Moment beeinflusst die Beschleunigung des Fahrzeuges. Im sicherheitstechnisch einfachsten Fall ist nur ein zu hohes Moment als kritisch einzustufen und dieses ist von der zweiten Überwachungsebene 12 mittels der Überwachungsfunktionen zu detektieren. In etwas komplexeren Fällen ist beispielsweise auch ein zu kleines Moment schon als sicherheitsrelevant einzustufen und muss dann ebenfalls von der Überwachungsebene 12 festgestellt werden.
In der Überwachungsebene 12 läuft die Überwachung dieses Momentes ab. Dies kann beispielsweise dadurch durchgeführt werden, dass die Überwachungsebene 12 ebenfalls ein Moment oder eine obere und/oder untere Schranke für das Moment berechnet und dann überprüft, ob das von der Applikationsebene 1 1 berechnete Moment mit dem in der Überwachungsebene 12 berechneten Moment übereinstimmt oder innerhalb tolerierter Schranken liegt. Eine andere Möglichkeit besteht darin, dass das von der Applikationsebene 1 1 berechnete Moment mit anderen Sensorsignalen, z.B. der Fahrerwunscherfassung, plausibilisiert wird. Es kann auch eine aus einem Kennfeld ermittelte Schranke verwendet werden. Falls die Überwachungsfunktionen der Überwachungsebene 12 feststellen, dass das von der Applikationsebene 1 1 berechnete Moment in sicherheitsrelevanter Weise falsch ist, dann kann sie geeignete Gegenmaßnahmen zur Herstellung eines sicheren Zustandes einleiten. Solche Gegenmaßnahmen bestehen beispielsweise in der Abschaltung, dem Auslösen eines Resets oder in der Limitierung des Momentes.
Die Sicherheitsebene 13 soll dabei die Funktionsfähigkeit und das tatsächliche Funktionieren der Überwachungsebene 12 überwachen. Nur wenn sichergestellt ist, dass die Überwachungsebene 12 tatsächlich auch funktioniert, kann man davon ausgehen, dass die durch die Überwachungsebene 12 implementierte Überwachung auch tatsächlich einen sicherheitskritischen Zustand verhindert. Das korrekte und fehlerfreie Funktionieren der Überwachungsebene 12 ist also für ein solches Sicherheitskonzept von großer Bedeutung.
Aus diesem Grund werden die Überwachungsfunktionen der Überwachungsebene 12 auf dem Lockstep-Paar, bestehend aus den Recheneinheiten 3, 4, abgearbeitet. Die Software sieht die beiden Recheneinheiten 3, 4, welche in einem abgesicherten Modus arbeiten, dabei nur als einen Rechnerkern. Neben der Bildung eines Lockstep-Paares sind weitere Absicherungsmethoden der Recheneinheiten 3, 4 bekannt, wie beispielsweise eine fault-redundant-CPU oder gar eine TMR-Struktur (Triple Modular Redundancy). Wenn die aus der Überwachungsebene 12 ablaufenden Überwachungsfunktionen auf diesem abgesicherten Lockstep-Paar 3, 4 abgearbeitet werden, dann ist diese Software der Überwachungsebene 12 in besonderem Maße geschützt. Ihr korrektes Funktionieren, selbst in Anwesenheit von Fehlern der zweiten Recheneinheit 2, kann vorausgesetzt werden. Insbesondere können sogar andere Absi- cherungsmaßnahmen, die beispielsweise in der Sicherheitsebene 13 vorhanden sind, und Fehler der Recheneinheiten 2, 3 entdecken sollen, reduziert, effizienter implementiert oder gar weggelassen werden.
Die Zuordnung der als Rechenprogramm hinterlegten Software zum Ablauf auf den Recheneinheiten 2, 3, 4 kann dann entsprechend dem folgenden Ablaufdiagramm vorgenommen werden. Im Block 7 wird das auf dem Mikroprozessor 1 laufende Rechenprogramm in die verschiedenen bekannten drei Ebenen 1 1 , 12, 13 zerlegt. Im Block 8 wird ein vorgegebener Rechenprogrammteil überprüft, ob dieser zur Überwachungsebene 12 des Sicherheitskonzeptes des Kraftfahrzeu- ges gehört. Ist dies der Fall, dann wird im Block 9 dieser Rechenprogrammteil dem Lockstep-Paar 3, 4 zur Bearbeitung zugewiesen. Gehört der untersuchte Rechenprogrammteil nicht zur Überwachungsebene 12, dann findet keine feste Zuordnung der abzuarbeitenden Rechenprogrammteile zu einer Recheneinheit 2 oder 3 statt (Block 10).
Darüber hinaus können außer der Überwachungsebene 12 weitere als sicherheitsrelevant oder sicherheitstechnisch besonders interessant eingestufte Rechenprogrammteile ebenfalls bewusst auf dem, in dem abgesicherten Modus arbeitenden Lockstep-Paar (Recheneinheit 3, 4) zum Ablauf gebracht werden. Zu diesen Rechenprogrammteilen können Rechenprogrammteile der Sicherheits-
ebene 13 aber auch ausgewählte Rechenprogrammteile der Applikationsebene 1 1 , wie beispielsweise Diagnosen, gehören.
Um auch aus Entwicklungssicht eine Vereinfachung zu erreichen, ist eine Zu- sammenfassung der im Block 7 der Figur 3 abgespaltenen Rechenprogrammteile zu einem oder mehreren Sicherheitsobjekten möglich. Solche Sicherheitsobjekte können dann von einem einzigen Betriebssystem, welches die Recheneinheiten 3 und 4 betreibt, betrieben werden. Eine solche Bündelung aus Betriebssystemsicht ermöglicht eine Kombination des erfindungsgemäßen Verfahrens mit ande- ren Schutz- oder Kapselungsmechanismen. Durch eine geeignete Scheduling-
Strategie, beispielsweise eine zeitgesteuerte Strategie, kann damit auch eine zeitliche Unabhängigkeit zwischen Überwachung und überwachtem Objekt sehr gut dargestellt und argumentiert werden. In diesem Fall werden die einzelnen Funktionen unabhängig von ihrer Zugehörigkeit zu den Ebenen 1 1 , 12, 13 in Tak- te von 5 ms, 10ms usw. aufgeteilt. Dies ist besonders dann vorteilhaft, wenn funktionale Interrupts nicht auf der überwachten Recheneinheit 3 ausgeführt werden. Dies ermöglicht auch eine Aufteilung der Funktionen in die rechenpro- grammtechnischen Funktionen, die nicht nur entlang zeitlicher Unterschiede sondern auch entlang der sicherheitstechnischen Relevanz verlaufen.
Ein besonderer Vorteil ist dann gegeben, wenn im Block 7 das Rechenprogramm nicht nur in Funktionen der Überwachungsebene 12 oder Funktionen, die nicht zur Überwachungsebene 12 gehörend, zerlegt wird, sondern wenn bei den nicht zur Überwachungsebene 12 gehörenden Rechenprogrammteilen noch eine wei- tere Zerlegung dahingehend stattfindet, ob ein gegebener Rechenprogrammteil durch die Überwachungsebene 12 überwacht wird oder nicht. Wenn eine Unabhängigkeit, beispielsweise in Form eines„Freedom from Interference"- Arguments, wie es in der Norm ISO 26262 gefordert ist, zwischen der Überwachung und dem überwachten Funktionen nachgewiesen werden soll, dann ist es vorteilhaft, die überwachten Funktionen, in diesem Fall die Funktionen, die nicht zum Rechenprogrammteil der Überwachungsebene 12 gehören, auf der unabhängigen zweiten Recheneinheit 2 ablaufen zu lassen. Diese räumliche Unabhängigkeit über die Verteilung auf mehrere Recheneinheiten 2, 3 stellt dabei ein zusätzliches Argument dar, da die Überwachung durch ein anderes Hardware- element vorgenommen wird als die Abarbeitung der überwachten Funktionen.
Dies ist insbesondere dann der Fall, wenn auf dem Lockstep-Paar (Rechenein-
heit 3, 4) nur die Überwachung selbst und/ oder die Überwachung der sicherheitsrelevanten Rechenprogrammteile der Ebene 13 abläuft. Damit ist sichergestellt, dass die applikationsnahen Funktionen der Applikationsebene 1 1 auf der Recheneinheit 2 durchgeführt werden.
Eine weitere Erweiterungsmöglichkeit des betrachteten Verfahrens besteht in der gezielten zusätzlichen Verwendung einer Speicherschutzeinheit in Form einer MPU (Memory Protection Unit). Dabei wird insbesondere eine zweistufige MPU, welche über eine zusätzliche Safety-MPU am Systembus 5 oder auf einer Slave- Seite des Mikroprozessors 1 realisiert werden kann, genutzt. Wenn die Sicherheitsobjekte einen eigenen Speicherbereich (beispielsweise in einem Flash, RAM, ROM) aufweisen, auf den nur diese Sicherheitsobjekte zugreifen dürfen, dann kann man diese Speichergrenze durch Programmierung der Sicherheitsschutzeinheit im Mikroprozessor 1 forcieren. Dies kann noch weiter verbessert werden, wenn man dies über die zweite Schicht der MPU oder der Safety-MPU realisiert. Dadurch kann garantiert werden, dass auf diesen speziell zu schützenden Speicherbereich keine Rechenprogramme, die auf der Recheneinheit 2 laufen, überhaupt zugreifen können, selbst in Anwesenheit von Rechenprogrammfehlern auf der Recheneinheit 2 oder weitgehend beliebigen Hardwarefehlern. Es kann dadurch in einer außerordentlich großen Verlässlichkeit die Einflussfreiheit der Recheneinheit 2 auf die abgesicherte Recheneinheit 3 dargestellt werden.
Die Unabhängigkeit zwischen Überwachung und überwachter Funktion kann darüber hinaus noch weiter verbessert werden, wenn eine Überwachungsperipherie, beispielsweise in Form spezieller Sensoren, direkt an die Recheneinheit 3 angebunden wird, so dass diese Sensoren von der Recheneinheit 3 konfiguriert und ausgelesen oder angesteuert werden, ohne dass die Recheneinheit 2 einen Einfluss darauf hat. Dies stellt ein weiteres Argument für die Unabhängigkeit zwischen Überwachung und zu überwachendem Objekt dar. Dies gilt insbesondere auch für eine Ansteuerung des Abschaltpfades. Dieser kann dann gegebenenfalls sehr gut als redundant ansteuerbar dargestellt werden.
Mittels des vorgeschlagenen Verfahrens werden die Unabhängigkeit und der Nachweis der Unabhängigkeit von überwachter Funktion und Überwachungsfunktion zuverlässig gewährleistet. Darüber hinaus ist dieses Verfahren
Iticoretauglich, wobei es für sehr allgemeine Rechnerarchitekturen einsetzbar
Claims
1 . Verfahren zur Überwachung von Funktionen eines Rechnersystems, vorzugsweise eines Motorsteuersystems eines Kraftfahrzeuges, welches mindestens zwei Recheneinheiten (2, 3) aufweist, wobei wenigstens eine erste Recheneinheit (3) in einem abgesicherten Modus betrieben wird, dadurch gekennzeichnet, dass auf der in dem abgesicherten Modus betriebenen ersten Recheneinheit (3) eine Überwachungsebene (12) eines auf dem Rechnersystem (1 ) abgearbeiteten Rechenprogramms betrieben wird, welche eine Applikationsebene (1 1 ) des Rechenprogramms überwacht.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass der abgesicherte Modus durch einen Lockstep-Betrieb oder einen fault-redundant- Betrieb realisiert wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das
Rechenprogramm in, der Überwachungsebene (12) angehörende Rechenprogrammteile und in, der Überwachungsebene (12) nicht angehörende Rechenprogrammteile zerlegt wird, wobei insbesondere die zur Überwachungsebene (12) gehörenden Rechenprogrammteile auf ihre Zugehörigkeit zur Überwachungsebene (12) überprüft werden und nach der Bestätigung der Zugehörigkeit zur Überwachungsebene (12) diese Rechenprogrammteile zur Bearbeitung der, in dem abgesicherten Modus betriebenen Recheneinheit (3) zugewiesen werden.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass weitere
sicherheitstechnisch relevante zur Applikationsebene (1 1 ) und/oder einer, die Überwachungsebene (12) überwachende Sicherheitsebene (13) gehörende Rechenprogrammteile von der in dem abgesicherten Modus betriebenen Recheneinheit (3) bearbeitet werden.
Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass die nicht zur Überwachungsebene (12) gehörenden Rechenprogrammteile dahingehend unterteilt werden, ob diese von der Überwachungsebene (12) überwacht werden oder nicht, wobei die nicht von der Uberwachungsebene (12) überwachten Rechenprogrammteile einer zweiten Recheneinheit (2), welche keinen abgesicherten Modus aufweist, zur Bearbeitung zugeführt werden.
Verfahren nach mindestens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die zur Überwachungsebene (12) gehörenden Rechenprogrammteile oder die sicherheitstechnisch relevanten der Applikationsebene (1 1 ) und/oder der Sicherheitsebene (13) angehörenden Rechenprogrammteile zu jeweils mindestens einem Sicherheitsobjekt, vorzugsweise einem Laufzeitobjekt, zusammengefasst werden, welches von einem Betriebssystem verwaltet wird.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass das mindestens eine Sicherheitsobjekt auf einen definierten, ausschließlich für das Sicherheitsobjekt vorgesehenen Speicherbereich der ersten, in dem abgesicherten Modus betriebenen Recheneinheit (3) zugreift.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass der für das mindestens eine Sicherheitsobjekt vorgesehene Speicherbereich durch eine Sicherheitsschutzeinheit abgesichert wird, wobei vorzugsweise sichergestellt wird, dass kein Rechenprogramm, was auf der zweiten Recheneinheit (2) bearbeitet wird, auf den Speicherbereich zugreift.
Verfahren nach mindestens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass auf mindestens ein Element einer Überwachungsperipherie des Rechnersystems (1 ) direkt nur die erste, in dem abgesicherten Modus arbeitende Recheneinheit (3) zugreift. 10. Vorrichtung zur Überwachung von Funktionen eines Rechnersystems, vorzugsweise eines Motorsteuersystems eines Kraftfahrzeuges, welches mindestens zwei Recheneinheiten (2, 3) aufweist, wobei wenigstens eine erste Recheneinheit (3) in einem abgesicherten Modus betrieben wird, dadurch gekennzeichnet, dass Mittel (1 ) vorhanden sind, welche auf der in dem ab- gesicherten Modus betriebenen ersten Recheneinheit (3) eine Überwachungsebene (12) eines auf dem Rechnersystem abgearbeiteten Rechen- Programms betreiben, welche eine Applikationsebene (1 1 ) des Rechenprogramms überwacht.
Vorrichtung nach Anspruch 10, dadurch gekennzeichnet, dass die erste Recheneinheit (3) in dem abgesicherten Modus mit einer dritten Recheneinheit (4) ein Lockstep-Paar bildet, wobei die erste und die dritte Recheneinheit (3, 4), die gleichen Programmabläufe verarbeiten, deren Ausgangssignale zur Fehlerüberwachung in einem Vergleicher (6) ausgewertet werden.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE201210207215 DE102012207215A1 (de) | 2012-04-30 | 2012-04-30 | Verfahren und Vorrichtung zur Überwachung von Funktionen eines Rechnersystems, vorzugsweise eines Motorsteuersystems eines Kraftfahrzeuges |
DE102012207215.2 | 2012-04-30 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2013164224A2 true WO2013164224A2 (de) | 2013-11-07 |
WO2013164224A3 WO2013164224A3 (de) | 2013-12-27 |
Family
ID=48190954
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2013/058382 WO2013164224A2 (de) | 2012-04-30 | 2013-04-23 | Verfahren und vorrichtung zur überwachung von funktionen eines rechnersystems, vorzugsweise eines motorsteuersystems eines kraftfahrzeuges |
Country Status (2)
Country | Link |
---|---|
DE (1) | DE102012207215A1 (de) |
WO (1) | WO2013164224A2 (de) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105765541A (zh) * | 2013-12-03 | 2016-07-13 | 罗伯特·博世有限公司 | 用于机动车的控制器 |
FR3129005A1 (fr) | 2021-11-10 | 2023-05-12 | Vitesco Technologies | Procédé et dispositif de contrôle et commande d’un moteur de véhicule |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5644981B1 (ja) | 2013-06-26 | 2014-12-24 | 三菱電機株式会社 | リモートユニットおよびリモートユニットの異常判定方法 |
DE102014004004A1 (de) | 2014-03-20 | 2015-09-24 | Audi Ag | Steuergerät in einem Kraftfahrzeug, Kraftfahrzeug und Verfahren zum Betrieb eines Steuergeräts |
DE102016214243A1 (de) | 2016-08-02 | 2018-02-08 | Zf Friedrichshafen Ag | Überwachung einer feldorientierten Regelung einer Asynchronmaschine |
DE102016217762A1 (de) * | 2016-09-16 | 2018-04-12 | Continental Automotive Gmbh | Überwachung von sicherheitsrelevanten Funktionen durch eine nicht sichere Recheneinheit |
DE102016223879A1 (de) | 2016-12-01 | 2018-06-07 | Zf Friedrichshafen Ag | Überwachung einer feldorientierten Regelung einer Asynchronmaschine |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102005037230A1 (de) | 2005-08-08 | 2007-02-15 | Robert Bosch Gmbh | Verfahren und Vorrichtung zur Überwachung von Funktionen eines Rechnersystems |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102006048169A1 (de) * | 2006-10-10 | 2008-04-17 | Robert Bosch Gmbh | Verfahren zur Überwachung einer Funktionsfähigkeit einer Steuerung |
US20090183035A1 (en) * | 2008-01-10 | 2009-07-16 | Butler Michael G | Processor including hybrid redundancy for logic error protection |
DE102010042574B4 (de) * | 2010-10-18 | 2017-11-16 | Continental Automotive Gmbh | Verfahren zum Betreiben eines Mikrocontrollers für ein Automobil und Mikrocontroller |
-
2012
- 2012-04-30 DE DE201210207215 patent/DE102012207215A1/de not_active Withdrawn
-
2013
- 2013-04-23 WO PCT/EP2013/058382 patent/WO2013164224A2/de active Application Filing
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102005037230A1 (de) | 2005-08-08 | 2007-02-15 | Robert Bosch Gmbh | Verfahren und Vorrichtung zur Überwachung von Funktionen eines Rechnersystems |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105765541A (zh) * | 2013-12-03 | 2016-07-13 | 罗伯特·博世有限公司 | 用于机动车的控制器 |
CN105765541B (zh) * | 2013-12-03 | 2018-12-14 | 罗伯特·博世有限公司 | 用于机动车的控制器 |
TWI651652B (zh) * | 2013-12-03 | 2019-02-21 | 羅伯特博斯奇股份有限公司 | 汽車用的控制裝置 |
FR3129005A1 (fr) | 2021-11-10 | 2023-05-12 | Vitesco Technologies | Procédé et dispositif de contrôle et commande d’un moteur de véhicule |
WO2023083703A1 (fr) | 2021-11-10 | 2023-05-19 | Vitesco Technologies GmbH | Procédé et dispositif de contrôle et commande d'un moteur de véhicule |
Also Published As
Publication number | Publication date |
---|---|
DE102012207215A1 (de) | 2013-10-31 |
WO2013164224A3 (de) | 2013-12-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2013164224A2 (de) | Verfahren und vorrichtung zur überwachung von funktionen eines rechnersystems, vorzugsweise eines motorsteuersystems eines kraftfahrzeuges | |
EP2823430B1 (de) | Elektronisches regelungssystem | |
EP2641176B1 (de) | Mikroprozessorsystem mit fehlertoleranter architektur | |
DE10223880B4 (de) | Verfahren zur gegenseitigen Überwachung von Komponenten eines dezentral verteilten Rechnersystems | |
DE102007045398A1 (de) | Integriertes Mikroprozessorsystem für sicherheitskritische Regelungen | |
EP2099667B1 (de) | Verfahren zum sicherstellen oder aufrechterhalten der funktion eines komplexen sicherheitskritischen gesamtsystems | |
WO2002074596A1 (de) | Verfahren zur ansteuerung einer komponente eines verteilten sicherheitsrelevanten systems | |
DE102018212879A1 (de) | Steuervorrichtung und Steuerverfahren | |
WO2014056794A1 (de) | Verfahren zur steuerung eines getrennten ablaufs von verknüpften programmblöcken und steuergerät | |
EP3291094A1 (de) | Prozessorsystem und verfahren zur überwachung von prozessoren | |
DE102013214398A1 (de) | Überwachung von redundanten Komponenten | |
DE102015202326A1 (de) | Verfahren zum Betreiben einer Datenverarbeitungseinheit eines Fahrerassistenzsystems und Datenverarbeitungseinheit | |
DE102013221098B4 (de) | Fahrzeugsteuereinheit | |
EP3341843B1 (de) | Verfahren und vorrichtung zum überwachen eines zustandes einer elektronischen schaltungseinheit eines fahrzeugs | |
DE102013021231A1 (de) | Verfahren zum Betrieb eines Assistenzsystems eines Fahrzeugs und Fahrzeugsteuergerät | |
DE102021208459B4 (de) | Verfahren zur authentischen Datenübertragung zwischen Steuergeräten eines Fahrzeugs, Anordnung mit Steuergeräten, Computerprogramm und Fahrzeug | |
DE102008004206A1 (de) | Anordnung und Verfahren zur Fehlererkennung und -behandlung in einem Steuergerät in einem Kraftfahrzeug | |
DE102013202961A1 (de) | Verfahren zum Überwachen eines Stackspeichers in einem Betriebssystem eines Steuergeräts eines Kraftfahrzeuges | |
DE102017219195B4 (de) | Verfahren zum gewährleisten eines betriebs eines rechners | |
DE102006020793A1 (de) | Schaltungsanordnung und Verfahren zum Betrieb einer Schaltungsanordnung | |
DE112018002612T5 (de) | Fahrzeugsteuervorrichtung | |
DE102013213402A1 (de) | Mikrocontroller mit mindestens zwei Kernen | |
DE102016217762A1 (de) | Überwachung von sicherheitsrelevanten Funktionen durch eine nicht sichere Recheneinheit | |
EP2225640A1 (de) | Verfahren zum identifizieren gegenseitiger beeinflussung von softwarekomponenten | |
DE10233879B4 (de) | Verfahren zum Steuern und Überwachen einer sicherheitskritischen Anlage, insbesondere Verkehrs-Signalanlage sowie Vorrichtung zur Durchführung des Verfahrens |
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: 13719078 Country of ref document: EP Kind code of ref document: A2 |
|
122 | Ep: pct app. not ent. europ. phase |
Ref document number: 13719078 Country of ref document: EP Kind code of ref document: A2 |