WO2012066108A1 - Mikroprozessorsystem mit fehlertoleranter architektur - Google Patents

Mikroprozessorsystem mit fehlertoleranter architektur Download PDF

Info

Publication number
WO2012066108A1
WO2012066108A1 PCT/EP2011/070414 EP2011070414W WO2012066108A1 WO 2012066108 A1 WO2012066108 A1 WO 2012066108A1 EP 2011070414 W EP2011070414 W EP 2011070414W WO 2012066108 A1 WO2012066108 A1 WO 2012066108A1
Authority
WO
WIPO (PCT)
Prior art keywords
microprocessor
software
modules
module
hwsai
Prior art date
Application number
PCT/EP2011/070414
Other languages
English (en)
French (fr)
Inventor
Kai Schade
Peter Zimmerschitt-Halbig
Andreas Heise
Original Assignee
Continental Teves Ag & Co. Ohg
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 Continental Teves Ag & Co. Ohg filed Critical Continental Teves Ag & Co. Ohg
Priority to EP11785406.7A priority Critical patent/EP2641176B1/de
Priority to US13/988,176 priority patent/US20130268798A1/en
Priority to CN201180055658.7A priority patent/CN103262045B/zh
Priority to KR1020137015830A priority patent/KR20130119452A/ko
Publication of WO2012066108A1 publication Critical patent/WO2012066108A1/de

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1479Generic software techniques for error detection or fault masking
    • G06F11/1487Generic software techniques for error detection or fault masking using N-version programming
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/004Error avoidance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/1629Error detection by comparing the output of redundant processing systems
    • G06F11/1641Error detection by comparing the output of redundant processing systems where the comparison is not performed by the redundant processing components
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B9/00Safety arrangements
    • G05B9/02Safety arrangements electric
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/1675Temporal synchronisation or re-synchronisation of redundant processing components
    • G06F11/1687Temporal synchronisation or re-synchronisation of redundant processing components at event level, e.g. by interrupt or result of polling

Definitions

  • the invention relates to a microprocessor system for Ausu ⁇ tion of at least partially safety-critical software modules in the context of the control and / or regulation of the software modules associated functions or tasks according to the preamble of the claim.
  • intrinsic safety incidence is the fault-silent property a component of a system which communicates with other components in communica tion ⁇ and upon detection of a fault within the component, no additional information or sends no further actions even more performs.
  • Known intrinsically safe microcontrollers include, for example, two microprocessor cores, which the same program taktsyn ⁇ chron parallel execute (lockstep mode LSM) and on ⁇ occur off of an error.
  • Other known Mikrocon ⁇ troller comprise three or more cores and a majority unit that decides if an error occurs, which of the processors has calculated correctly and then the right computing processor to be carried out task transfers (fault-tolerant principle), ie it is the property of or ability of a system to perform its specified function even with a limited number of faulty subsystems or components.
  • microcontrollers are already known, which are composed of two fault-silent systems with two cores each to a fault-tolerant (fault-tolerant) system.
  • microcontroller units are spatially closely adjacent, so that they can exchange data MITEI ⁇ Nander quickly.
  • Defects in hardware components are detected by special protection, such as by a checksum calculation before bus transfer or by checksum memory for flash memories.
  • special protection such as by a checksum calculation before bus transfer or by checksum memory for flash memories.
  • redundant components such as memory modules (e.g., RAM, ROM, cache), CPUs, monitoring modules, or bus comparators or memory protection units.
  • n-th software components require a nearly n-time runtime for calculation in a single runtime environment on a single intrinsically safe microprocessor module
  • ASIL nen for software and hardware components of automotive systems, defines the standard ISO 26262 so-called Secure ⁇ transconductance stages, abbreviated (Automotive Safety Level).
  • the respective security level is a measure of the functiona ⁇ le security of the system, depending on the risk and danger to persons that may arise from the system function. Functions or processes with a lower risk are principally built by a safety circuit with a lower safety integrity level than processes with a higher risk.
  • Software failure due to conceptual errors corresponds to the ASIL-D security level.
  • the invention has for its object to provide an initially ge ⁇ -called microprocessor system which ensures intrinsic safety ASIL-D classification on hardware and software level, and in addition, is flexible in handling and maintenance of the software components, and has a multi-relapse level concept.
  • Such a microprocessor system for executing at least partially safety-critical software modules in the context of the control and / or regulation of the software modules associated functions or tasks which includes at least one intrinsically safe microprocessor module with searchess ⁇ least two microprocessor cores, according to the invention characterized by that at least one further intrinsically safe microprocessor module having at least two microprocessor cores is provided, wherein the at least two microprocessor modules are connected via a bus system,
  • At least two software modules are provided which perform at least partially overlapping functions
  • the aforementioned software module may already be running in a kind of standby mode, but still require the release to pass through, for example, the eventual control of an actuator or communication on a bus medium before it effectively gains control or release to perform active actions.
  • This release can for example be done as follows, namely explicitly by an arbitrator in the form of a monitoring software module, or explicitly by self-display of the primary software module with notification that it was switched off due to Fever ⁇ ler or off, or implicitly by the absence of alive signals of Microprocessor module on which the primary software module is executed. Due to the at least partially redundant software modules, in the event of an error, one of these software modules can be executed with the related function, which is allocated to the same or another microprocessor module.
  • a hardware / software architecture can be created that allows a distribution of software components, such as ABS or ESP functions or program modules or tasks on various intrinsically safe microprocessor modules, for example, two monitoring ESP -Software modules (which do not necessarily have to be programmed identically to fulfill predefined ASIL safety levels, or which, in terms of the original functional specification, satisfy the fundamentally identical development specifications but which should or must be implemented differently) if necessary on an intrinsically safe microprocessor -Module can run in parallel.
  • software components such as ABS or ESP functions or program modules or tasks on various intrinsically safe microprocessor modules
  • two monitoring ESP -Software modules which do not necessarily have to be programmed identically to fulfill predefined ASIL safety levels, or which, in terms of the original functional specification, satisfy the fundamentally identical development specifications but which should or must be implemented differently
  • a faulty software module when a faulty software module is detected, it has its function for troubleshooting executed by a further software module which has this function as an overlapping function or at least as a faulty software module is identical with regard to the functions or tasks to be performed, ie serves the same purpose.
  • the increased availability is reflected in the error ⁇ tolerance of the microprocessor system invention over the failure of a software module that an identical or partially identical software module for error ⁇ treatment is executable.
  • the functional safety of the Mikroprozes ⁇ sorsystem is increased when provided according to an embodiment of the invention for performing a safety-related function multiple on one or more microprocessor modules distributed software modules with diversified redundant software.
  • a hedge at the hardware level by the intrinsic safety of the microprocessor modules and a hedge on the software level by the redundancy these software modules with the diversely re ⁇ dundanten software is ensured.
  • each microprocessor module for carrying out basic functions has basic software modules, Preferably, communication software modules, input validation software modules, and task specific software modules, each located once on the microprocessor module.
  • ESP / ESC non-safety-critical software
  • non-safety-critical software such as Soft ⁇ ware for navigation systems or can not on the inventive microprocessor system with multiple microprocessor modules in addition to safety-critical software, such as brake control software (ABS / ASR / EBV) or vehicle dynamics control software highly safe ⁇ uniform critical systems such as adaptive cruise control systems (ACC) or other software for non-safety critical remplias ⁇ assistance systems or enhanced functions are executed in parallel for safety-critical software.
  • ABS / ASR / EBV brake control software
  • ACC adaptive cruise control systems
  • the micropro cessor ⁇ modules are constructed with an intrinsically safe multiprocessor structure, this may be the robustness and possible ge ⁇ rings interactions due to environments in various Laufzeitumge- (RTEs, run-time environments) can be realized.
  • the microprocessor modules can be as ASIC rea ⁇ lmitter, is so as to ensure that the ver ⁇ various microprocessor modules of your IC package are connected spatially short not only with respect to what suitable as before for insertion in printed circuit boards or harnesses bus is required, which are fast but not the fastest, but also at the level of DIE or Si ⁇ silicon common structures or buses for the best possible data transmission speed available, so that short distances provide for fast data transfer, fast bus systems are provided can and only slight latencies occur.
  • Another advantage is that software modules (.
  • a Pope a relation to a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly a formerly ⁇ -relevant function by leading redundant and / or
  • At least one microprocessor module as a multiprocessor platform with respect to its microprocessor cores operates in a lockstep mode (LSM), whereby a Absi ⁇ assurance is largely achieved due to spatial redundancy, so duplicated structures.
  • LSM lockstep mode
  • Such a micro ⁇ processor module operates basically in this LSM mode, but can also be after switching on the supply voltage following an initialization routine or after a ex ⁇ tern reset signal or at runtime as a single operation in this LSM mode, in which this micropro ⁇ zessor module also remains.
  • At least one micro ⁇ processor module as a multiprocessor platform with respect to its microprocessor cores in a decoupled parallel mode (DPM) work, namely achieved its functional security objectives on the architectural measure of asymmetric Redun ⁇ dance.
  • DPM decoupled parallel mode
  • the microprocessor system can have, in addition to several microprocessor modules as multi-core processor platforms, at least one microprocessor module with a single microprocessor core (single core processor).
  • these microprocessor modules are connected to at least one bus system with an input / output interface to allow ex ⁇ tern expandability.
  • microprocessor system of the invention can be formed according to an embodiment of the invention with microprocessor modules, each having similar Radiosys ⁇ systems.
  • microprocessor modules each having similar Radiosys ⁇ systems.
  • a part of the microprocessor modules are each equipped with a time-disk-based operating system, which are synchronized.
  • the microprocessor modules are phase- locked miteinan ⁇ coupled. This can he ⁇ be sufficient for example. Equidistant time intervals by a sending time stamps by a transmitter via external or on-chip bus systems in conjunction with an advantageous ⁇ exemplary adjustment of the time slice at the receiver.
  • micropro ⁇ zessor modules at least partially ASIC with a ge ⁇ common housing.
  • the microprocessor system according to the invention is in vorteilhaf ⁇ ter way for use in an electronic vehicle control unit, which is preferably provided for the Bremsensteue ⁇ tion and control, suitable, the properties of but typically also predestined to accommodate software modules that the coordinate vehicle dynamics behavior, or a selected group of chassis ECUs.
  • the coordination can in this case interventions in the sense of system-wide
  • Figure 1 is a schematic block diagram of a micropro ⁇ zessorsystems with intrinsically safe microprocessor modules as basic elements according to the invention
  • Figure 2 is a schematic block diagram of a eigensi ⁇ Cheren microprocessor module of the Mikroreasys ⁇ tems of Figure 1;
  • Figure 3 is a schematic block diagram of a further intrinsically safe microprocessor module of the micropro ⁇ zessorsystems of Figure 1, and
  • FIG. 4 shows a schematic representation of a division of different software modules into two microprocessor modules of a microprocessor system according to FIG . 1.
  • the intrinsically safe microprocessor module HWSAi as a dual-core microprocessor according to Figure 2 operates in the so-called
  • LSM lockstep
  • those microprocessors perform redundant and isochronous (hence lockstep mode)
  • the sliding ⁇ che program segment from the results of the two micropro ⁇ zessorkerne CPUi and CPU 2 are compared and an error is then in the comparison for a match recognized.
  • Each microprocessor core CPUi and CPU 2 of the microprocessor module HWSAi according to FIG. 2 has its own bus system Bi or B 2 , which are connected via an interface IF.
  • Bi or B 2 which are connected via an interface IF.
  • Ki and K 2 which monitor for the detection of single errors of hardware defects all inputs and outputs of the redundant basic elements of this microprocessor module HWSAi, as well as the example shown in Figure 2 two microprocessor cores CPUi and CPU 2 in the event of an error, so in a discrepancy between the two microprocessor cores CPUi and CPU 2 causes a shutdown of this microprocessor module HWSAi or its degradation.
  • this microprocessor module HWSAi includes more Components such as random access memory (RAM), program memory (Flash or ROM), comparators and security modules, modules for external buses (CAN, LIN, Flexray, MOST, ISOK, Ethernet), where such components can also be redundant for security reasons.
  • RAM random access memory
  • Flash or ROM program memory
  • comparators and security modules modules for external buses (CAN, LIN, Flexray, MOST, ISOK, Ethernet)
  • modules for external buses CAN, LIN, Flexray, MOST, ISOK, Ethernet
  • a flash or ROM memory can be expanded by additional memory capacities which serve the purpose of accomodating checksums.
  • additional elements in the sense of memory bits for non-functional, but safety-oriented purposes is forma comparable to a partially redundant embodiment, which can operate according to their incompleteness not according to the principle of spatial redundancy, the aforementioned Lockstep mode LSM, but according to the principles asymmetric secured structures, in terms of time, must work.
  • the intrinsically safe microprocessor module HWSA j as a dual-core microprocessor with two microprocessor cores CPU 3 and CPU 4 according to Figure 3 operates in the so-called DPM (Decoupled Paral ⁇ lel) mode, ie they can independently process different program sequences.
  • Each microprocessor core CPU 3 and CPU 4 has its own bus B 3 and B 4 , which are connected via an interface IF.
  • other components such as random access memory (RAM), program memory (Flash or ROM) comparators and security modules, modules for external buses (CAN, LIN, Flexray, MOST, ISOK, Ethernet) are available.
  • RAM random access memory
  • Flash or ROM program memory
  • Security modules modules for external buses (CAN, LIN, Flexray, MOST, ISOK, Ethernet) are available.
  • a Hedging is achieved by time-integral balancing and can be based on symmetrical as well as asymmetric spatial redundancy of the components.
  • This microprocessor system MCUSA of Figure 1 is not only a hardware system architecture is what ensures intrinsic safety according to the ASL-D classification, but also ensures on the software level, a Eigensi ⁇ reliability of this safety level ASIL-D, as in Fol ⁇ constricting should be explained.
  • Figure 4 shows an example of the static allocation or distribution of various software modules to two intrinsically safe microprocessor modules HWSAi and HWSA 2 of a Mik ⁇ roreaorsystem MCUSA, such as, according to FIG 1.
  • these two microprocessor modules HWSAi and HWSA can 2 ent ⁇ speaking Figure 2 or Figure 3 be constructed.
  • the recorded ⁇ led software modules in each microprocessor module HWSAi and HWSA 2 are corresponding t the time axis or time base H wsAi and t H WSA2 an example.
  • HWSAi and HWSA 2 distinguishes between so-called basic software modules that are provided on each of the two microprocessor modules HWSAi and HWSA 2 and are executed only once and on the other ⁇ side Software modules that are multiple redundantly static on a microprocessor module, so for example. HWSAi or HWSA 2 or more microprocessor modules, so for example. HWSAi and HWSA 2 allocated and executed. Some of the software modules can also have overlapping tasks.
  • These basic software modules are communication software modules, input plausibility software modules, and task-specific software modules.
  • HWSA communication allows data to be exchanged, either unidirectionally or bidirectionally, via a bus system or a network B of the microprocessor system MCUSA (see Figure 1) .
  • the input plausibility software modules "HWSAl-Input-Plausibilization” and “HWSA2-Input-Plausibilization” are used for the communication via software, ie via the software. plausibility of the input variables received in order to be passed on to the control functions as qualified values, since only results of control functions that can be based on qualified input variables can reasonably be compared after completion of the calculation.
  • E2E end-to-end protection
  • This validation checksum is taken from the control functions which receive the date or all the data which receive the date on the basis of a known calculation key, the E2E checksum for checking the correct transmission of the date, and thus even provides means, which is a result of a conceptual error in the starting point.
  • Plausibility software module on the side of the transmitter as well as in the input plausibility software module on the side of the receiver erken ⁇ erken ⁇ NEN and react accordingly.
  • the task-specific (dedicated task) software Grundmo ⁇ modules of the microprocessor module HWSAi or microprocessor module HWSA 2 are shown in Figure 4 as "HWSAl Dedicated Task 1", “HWSAl Dedicated Task 2" and “HWSAl-Dedicated Task 3 "or” HWSA2 Dedicated Task Y ",” HWSA2 Dedicated Task Z “and” HWSA2 Dedicated Task W ".
  • These basic software modules are also easily executed, without any further Requirements for diversity and increased robustness or to have to satisfy redundancy.
  • These task-specific basic software modules essentially exist only once and are executed on the microprocessor module HWSAi or HWSA 2 "de- dicated”.
  • HWSAI output plausibilization or “HWSA2 output plausibilization”
  • HWSA2 output plausibilization serve to check the plausibility of the output values or manipulated variables previously determined by the totality of all control functions. It is between the functionally necessary
  • FIG. 4 shows an allocated on the microprocessor module HWSAi, software module "HWSA task B i2" which is programmed by a programmer A and this alloktechnischates on the Mik ⁇ roreaor module HWSA 2 diversely redundant software module "HWSA task B 22 ", which is programmed by another programmer B.
  • microprocessor Module HWSAi a diverse redundant ⁇ tes software module "HWSA task C i3 ", which is programmed by another programmer B.
  • Such software modules va ⁇ riieren structurally very strong.
  • HWSAl-Output-Plausibilization or “HWSA2-Output-Plausibilization” compares the results of the redundant respectively quasiredundant and, depending on the static allocation, software modules distributed to different HWSAi microprocessor modules or evaluates.
  • microprocessor system MCUSA according to FIG. 1 is designed for dynamic processing with regard to the software modules.
  • this software module "HWSAl-Dedicated-Task 3" fails and a partial function or subtask is therefore not feasible and this subtask or partial function as a program segment also on the software module "HWSA2 dedicated task Z" of the microprocessor module HWSA 2 is present, this software module "HWSA2 dedicated task Z" is activated in role as a backup software modules and ⁇ ne backup routines performed.
  • Dynamic processing means that state-dependent gig, ie regarding hardware or software or operating modes of the microprocessor system certain microprocessor modules HWSAi or certain software modules, so demand-driven ⁇ are performed.
  • the prerequisite for this is, of course, the static allocation corresponding software module, as described in connection with Figure 4.
  • the amount of the distributed or diversified software modules includes two main types: which serve increased functional Si ⁇ safety, that is, in the microprocessor modules HWSAi a permanent result of comparison is performed a) Such software modules, and b) such software modules which are increased availability and which can be ideally carried out alternatively or dyna ⁇ mixing started in order to save resources and running time in the normal operation mode, where this is advantageous.
  • This particular operating situation may be a detected error in a microprocessor module HWSAi, even this can be a special Eigenkalibrier- or diagnostic procedure that limits or the functioning temporarily ⁇ be a constantly present undervoltage event. It is not necessary to have the full functionality covered by backup software modules.
  • the backup software modules can be slimmer, smaller in code size and runtime consumption.
  • the HWSAi microprocessor module which dynamically executes the backup software modules, can dynamically shut down a large number of its local, nonessential software modules to ensure processing of the backup software modules.
  • the Mikropro ⁇ zessorsystem MCUSA invention is characterized by the following advantages:
  • microprocessor module fails, other microprocessor modules remain active; Software modules are partially or completely executed. Further backup routines in another software module will be Kirt ⁇ ⁇ on ei nem another microprocessor module with the control,
  • Microprocessor module HWSAi or a software module is present is unambiguously possible, since intrinsically safe Mikro ⁇ roreaor modules HWSAi are used with corresponding intrinsically safe running infrastructure modules (RAM, FLASH, buses, etc.), so that in the case of a Negati ⁇ ven result comparison, ie that results redundant I ⁇ ter software modules have contradicted themselves, the software modules can be classified as non-functional at the same time ensuring the functioning of the microprocessor modules HWSAi.
  • Optio ⁇ nal a two- or Mehrfachredundanz the software modules are used to identify by Ma orticiansbil ⁇ tion the problematic software module unambiguously and still maintain the safe function execution.
  • the microprocessor system MCUSA can be built as an ASIC in a single housing. Of course it is also possible the microprocessor system MCUSA on two or more ASIC to implement it and then combine them in a single IC package or pa each ASIC in a separate IC package ⁇ CKEN.
  • Mik ⁇ roreaor module HWSAi may be the same or different, and that a single operating system can be used, which distributes the computational load static, some effort or fully effort at the various microprocessor modules HWSAi.
  • those operating on a time slice basis operating systems of the microprocessor modules HWSAi synchronous to each other can be formed, i. occupy a defined phase-locked state to each other, which is e.g. can be reached by the time-equidistant transmission of timestamps by a transmitter via external or on-chip bus systems in conjunction with an advantageous adjustment of the time slice (loop) on the receiver side.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)

Abstract

Die Erfindung betrifft einen Mikroprozessorsystem (MCUSA) zur Ausführung von zumindest teilweise sicherheitskritischen Software-Modulen im Rahmen der Steuerung und/oder Regelung von den Software-Modulen zugeordneten Funktionen oder Aufgaben, welches wenigstens ein eigensicheres Mikroprozessor-Modul (HWSAi) mit wenigstens zwei Mikroprozessorkernen (CPUi) umfasst; erfindungsgemäss ist vorgesehen, dass wenigstens ein weiteres eigensicheres Mikroprozessor-Modul (HWSAi i=1,... n) mit wenigstens zwei Mikroprozessorkernen (CPU1, CPU2; CPU3, CPU4) vorgesehen ist, wobei die wenigstens beiden Mikroprozessor-Module (HWSA1, HWSA2) über ein Bus-System (B) verbunden sind, wenigstens zwei Software-Module vorgesehen sind, welche wenigstens teilweise überlappende Funktionen ausführen, diese Software-Module mit wenigstens teilweise überlappenden Funktionen auf einem Mikroprozessor-Modul (HWSA1, HWSA2) oder auf wenigstens zwei Mikroprozessor-Modulen (HWSA1, HWSA2) verteilt sind, und Zur Erkennung von Software- und/oder Hardware-Fehlern Mittel zum Vergleichen und/oder Arbitrieren der mit den Software-Modulen für die identischen Funktionen erzeugten Ergebnisse vorgesehen sind.

Description

Mikroprozessorsystem mit ehlertoleranter Architektur
Die Erfindung betrifft ein Mikroprozessorsystem zur Ausfüh¬ rung von zumindest teilweise sicherheitskritischen Software- Modulen im Rahmen der Steuerung und/oder Regelung von den Software-Modulen zugeordneten Funktionen oder Aufgaben gemäß Oberbegriff des Patentanspruchs.
Im Stand der Technik sind eigensichere Mikrocontroller und Mikroprozessorsysteme für sicherheitsrelevante Kraftfahr¬ zeugsteuergeräte bekannt.
Dabei wird der Begriff „eigensicher" als die Fähigkeit eines elektronischen Systems betrachtet, welches beim Auftreten bestimmter Fehler im sicheren Zustand bleibt oder unmittelbar in einen anderen sicheren Zustand übergeht oder bei Vorliegen eines Fehlers abzuschalten. Ein Unterfall der Eigensicherheit ist die Fault-Silent-Eigenschaft einer Komponente eines Systems, welches mit anderen Komponenten in Kommunika¬ tion steht und beim Erkennen eines Fehlers innerhalb der Komponente keine weiteren Informationen aussendet bzw. keine weiteren Aktionen selbst mehr ausführt.
Bekannte eigensichere Mikrocontroller umfassen zum Beispiel zwei Mikroprozessorkerne, die das gleiche Programm taktsyn¬ chron parallel abarbeiten (Lockstep-Modus, LSM) und bei Auf¬ treten eines Fehlers abschalten. Andere bekannte Mikrocon¬ troller umfassen drei oder mehrere Kerne und eine Majoritätseinheit, die bei einem Fehler entscheidet, welche der Prozessoren richtig gerechnet hat und die dann dem richtig rechnenden Prozessor die vorzunehmende Aufgabe überträgt ( fault-tolerant-Prinzip) , d. h. es ist die Eigenschaft bzw. Fähigkeit eines Systems auch mit einer begrenzten Zahl fehlerhafter Subsysteme oder Komponenten seine spezifizierte Funktion bzw. Aufgabe zu erfüllen. Ferner sind auch bereits Mikrocontroller bekannt, die aus zwei Fault-Silent-Systemen mit jeweils zwei Kernen zu einem fehlertoleranten ( fault-tolerant ) -System zusammengesetzt sind .
Weiterhin sind Hardware-Strukturen bekannt, bei denen zwei getrennte Mikrocontrollereinheiten (MCUs) räumlich eng benachbart angeordnet sind, so dass diese schnell Daten mitei¬ nander austauschen können.
Heutige sicherheitsrelevante Systeme eines Kraftfahrzeugs, wie z.B. ein ESP-Regelsystem, in denen Fehlfunktionen der Elektronik sicher detektiert werden müssen, verwenden bei den entsprechenden Steuergeräten solcher Systeme üblicherweise Redundanzen zur Fehlererkennung, also bspw. eigensichere Mikroprozessor-Module bzw. Mikroprozessorplattformen mit zwei Mikroprozessorkernen (Dual-Core-Architektur ) , die im Lockstep-Modus verriegelt sind. Mit solchen Mikroprozes¬ sor-Modulen können ESP-Funktionen redundant berechnet und auf Übereinstimmung geprüft werden. Tritt eine Diskrepanz der Ergebnisse auf, so wird das ESP-System abgeschaltet.
Defekte in Hardware-Komponenten werden durch spezielle Absicherung erkannt, wie bspw. durch eine Checksummenberechnung vor Bustransfer oder mittels Checksummenspeicher bei Flash- Speichern. Zudem ist es auch bekannt, auf der Basis von redundanten Komponenten, wie Speichermodule (z.B. RAM, ROM, Cache), CPU's, Überwachungsmodule bzw. Buskomparatoren oder Memoryprotection-Units Eigensicherheit zu erreichen.
Mit solchen Architekturen können jedoch „Defekte" oder „konzeptionelle Fehler" einer Software nicht erkannt werden. Solche Defekte können z. Bsp. im Rahmen eines Freigabepro¬ zesses der Software nicht erkannte Übersetzungsfehler von Compiler oder Assembler sein, welche nur unter speziellen Rahmenbedingungen eintreten und offensichtlich werden.
Bekannte Lösungen zur Absicherung von Softwarekomponenten hinsichtlich solcher Defekte bestehen darin, einen anderen Assembler/Compiler bzw. eine geänderte Assembler-/Compiler- Vorgabe zu treffen, so z. Bsp. Speed-optimiert statt Memory optimiert oder verschiedene Optimier-Level .
Konzeptionelle Fehler einer Software beruhen bspw. auf „Denkfehler" der Entwickler und führen beim Ablauf der Soft wäre unter speziellen Umständen zu unspezifiziertem Verhalten bzw. in einen falschen Betriebs-Modus des Systems, d. h es liegt eine ungenügende Abbildung der zu erwartenden äuße ren Umstände bzw. Betriebssituationen auf die Struktur der Software bzw. Betriebsmodi vor.
Zur Absicherung von Softwarekomponenten gegenüber solchen konzeptionellen Fehlern ist es bekannt, die Funktion von ei ner zweiten, dritten, ... n-ten Softwarekomponente ausführen zu lassen und jeweils die Ergebnisse mit den (n-1) anderen Softwarekomponenten zu vergleichen und zu bewerten.
Dieser bekannte Fehlererkennungsansatz zur Erkennung von konzeptionellen Fehlern weist folgende Nachteile auf:
- Die n-ten Softwarekomponenten bedingen eine nahezu n-fach Laufzeit zur Berechnung in einer einzigen Laufzeitumgebung auf einem einzigen eigensicheren Mikroprozessor-Modul,
- Bei einem Versagen der zugrundeliegenden einfach redundan ten Hardware wird die gesamte Software abgeschaltet; dies führt hinsichtlich Robustheit und Verfügbarkeit des gesamten eingebetteten Systems zu einem schlechten Resultat,
- Über Sicherheitsstufe ASIL-D hinausgehend werden Hardware- Zweifachfehler von den auf die Erkennung von Einfachfehlern getrimmten Hardware-Überwachungsmodulen nicht garantiert erkannt und können zu unklaren Sachverhalten führen, die es programmiertechnisch nicht gestatten, konzeptionelle Fehler der Softwarekomponenten von Hardwaredefekten eineindeutig zu unterscheiden. So werden z.B. Zweifachfehler in Flash-oder RAM-Speichern sowie in Mikroprozessoren auf der Hardwareebene nicht erkannt, führen zu einer Verfälschung eines Inputs, eines Algorithmus oder eines Outputs einer oder mehrerer Softwarekomponenten mit der Folge einer Abschaltung der be- einflussten Softwarekomponenten, ohne dass die genaue Ursache gedeutet werden könnte. Eine nachgelagerte Offline- Analyse würde sich schwierig, langwierig und kostspielig ge¬ stalten,
- Eine sequentielle Ausführung der n-fachen Softwarekompo¬ nenten ( Serialisierung) führt erfahrungsgemäß mittelfristig zu Softwarestrukturen, die prinzipbedingt nicht mehr trennbar sind. Wenige monolithische Blöcke entstehen, die in ei¬ nem abgegrenzten Kontext betrachtet, entwickelt und gepflegt werden. Die FSM-technische Betrachtung eines solchen Gesamt¬ systems gestaltet sich fortwährend schwieriger und die Ein¬ führung eines mehrstufigen Rückfallebenenkonzeptes ist, auf¬ grund der nicht mehr klar gegebenen Grenzen der Softwarekomponenten, sehr aufwändig,
- Schließlich geht die Handhabbarkeit, Pflege und Wartung der Softwarekomponenten selbst aufgrund der monolithischen Struktur verloren.
Zur Beurteilung der Zuverlässigkeit von Sicherheitsfunktio- nen für Software- und Hardwarekomponenten von Automotive- Systemen definiert die Norm ISO 26262 so genannte Sicher¬ heitsstufen, abgekürzt ASIL (Automotive Safety Level) . Die jeweilige Sicherheitsstufe stellt ein Maß für die funktiona¬ le Sicherheit des Systems in Abhängigkeit von dem Risiko und der Gefährdung von Personen dar, die von der Systemfunktion ausgehen können. Funktionen oder Prozesse mit einer geringeren Gefährdung werden prinzipiell durch einen Sicherheitskreis mit einem geringeren Sicherheitsintegritätslevel auf¬ gebaut als Prozesse mit höherer Gefährdung. Gemäß dieser Norm gibt es vier Sicherheitsstufen ASIL-A bis ASIL-D, wobei ASIL-D die höchste Sicherheitsanforderung darstellt. Ein Softwareversagens aufgrund von konzeptionellen Fehlern entspricht dabei der ASIL-D Sicherheitsstufe.
Der Erfindung liegt die Aufgabe zugrunde, ein eingangs ge¬ nanntes Mikroprozessorsystem anzugeben, welches eine Eigensicherheit nach ASIL-D Klassifizierung auf Hardware- und Software-Ebene gewährleistet und zusätzlich flexibel in Handhabung und Wartung der Softwarekomponenten ist sowie über ein mehrstufiges Rückfallebenenkonzept verfügt.
Diese Aufgabe wird gelöst mit den Merkmalen des Patenan¬ spruch 1.
Ein solches Mikroprozessorsystem zur Ausführung von zumindest teilweise sicherheitskritischen Software-Modulen im Rahmen der Steuerung und/oder Regelung von den Software- Modulen zugeordneten Funktionen oder Aufgaben, welches wenigstens ein eigensicheres Mikroprozessor-Modul mit wenigs¬ tens zwei Mikroprozessorkernen umfasst, zeichnet sich erfindungsgemäß dadurch aus, dass - wenigstens ein weiteres eigensicheres Mikroprozessor-Modul mit wenigstens zwei Mikroprozessorkernen vorgesehen ist, wobei die wenigstens beiden Mikroprozessor-Module über ein Bus-System verbunden sind,
- wenigstens zwei Software-Module vorgesehen sind, welche wenigstens teilweise überlappende Funktionen ausführen,
- diese Software-Module mit wenigstens teilweise über¬ lappenden Funktionen auf einem Mikroprozessor-Modul oder auf wenigstens zwei Mikroprozessor-Modulen verteilt sind, und
- Zur Erkennung von Software- und/oder Hardware-Fehlern Mittel zum Vergleichen und/oder Arbitrieren der mit den Software-Modulen für die identischen Funktionen erzeugten Ergebnisse vorgesehen sind.
Mit einem solchen erfindungsgemäßen Mikroprozessorsystem lassen sich eigensichere Mikroprozessor-Module in der Art integrieren, dass im Fehlerfall die entsprechende Hardware- Komponente oder die Software-Komponente eineindeutig identi¬ fiziert und fallabhängig abgeschaltet werden kann.
Dies wird durch die Eigenschaft der Eigensicherheit der Mik¬ roprozessor-Module gesichert, so dass bei einem Hardware- Fehler ein anderes Mikroprozessor-Modul aktiviert wird oder weiterlaufen gelassen wird und dort ein die gleiche oder identische oder ähnliche oder gleichartig aber weniger um¬ fassende Funktion ausführendes Software-Modul gestartet wird. Auch kann vorgenanntes Software-Modul schon in einer Art Standby Betrieb laufend sein, jedoch noch die Freigabe zum Durchgriff auf z.B. die letztendliche Steuerung eines Aktuators oder der Kommunikation auf einem Busmedium noch bedürfen bevor es effektiv die Kontrolle oder die Freigabe zur Ausführung aktiver Handlungen bekommt. Diese Freigabe kann beispielsweise wie folgt geschehen, nämlich explizit durch einen Arbitrierer in Form eines überwachenden Software-Moduls, oder explizit durch Selbstanzeige des primär zuständige Softwaremoduls mit Meldung, dass es aufgrund Feh¬ ler abschaltet oder abgeschaltet wurde, oder implizit durch Ausbleiben von Alive-Signalen des Mikroprozessor-Moduls auf welcher das primär zuständige Softwaremodul ausgeführt wird. Durch die wenigstens teilweise redundanten Software-Module kann im Fehlerfall eines dieser Software-Modul dasjenige mit der verwandten Funktion ausgeführt werden, welches auf dem gleichen oder einem anderen Mikroprozessor-Modul allokiert ist .
Insbesondere kann erkannt werden, ob ein Versagen eines ei¬ gensicheren Mikroprozessor-Moduls oder eines Software-Moduls vorliegt, wobei auch dann ein Software-Modul als fehlerhaft erkannt werden kann, wenn gleichzeitig die Funktionstüchtig¬ keit desjenigen Mikroprozessor-Modul, auf welchem dieses Software-Modul lokalisiert ist, sichergestellt ist.
Schließlich kann mit dem erfindungsgemäßen Mikroprozessorsystem eine Hardware/Software-Architektur geschaffen werden, die eine Verteilung von Softwarekomponenten, wie bspw. ABS- oder ESP-Funktionen oder Programmmodule oder Tasks auf verschiedenen eigensicheren Mikroprozessor-Modulen erlaubt, wobei zum Beispiel auch zwei sich überwachende ESP-Software- module (die zur Erfüllung von vorgegebenen ASIL-Sicherheits- stufen nicht notwendigerweise identisch programmiert sein müssen, bzw. gemessen an der ursprünglichen funktionalen Spezifikation den grundlegend gleichen Entwicklungsvorgaben genügen aber andersartig umgesetzt sein sollen bzw. gar müssen) notfalls auf einem eigensicheren Mikroprozessor-Modul parallel laufen können.
In einer vorteilhaften Ausgestaltung der Erfindung, ist es vorgesehen, bei Erkennung eines Fehler behafteten Software- Moduls dessen Funktion zur Fehlerbehebung von einem weiteren Software-Modul ausführen zu lassen, welches diese Funktion wenigstens als mit dem Fehler behafteten Software-Modul überlappende Funktion aufweist oder welches hinsichtlich der auszuführenden Funktionen oder Aufgaben identisch ist, also dem gleichen Zweck dient.
Damit wird durch ein solches Mikroprozessorsystem eine
Sicherheitsarchitektur mit erhöhter Robustheit zur Verfügung gestellt, da bei Versagen eines Software-Moduls andere Soft¬ ware-Module aktiv bleiben. Insbesondere können Teilfunktio¬ nen oder Teilaufgaben des versagenden Software-Moduls als Backup-Routinen oder Programmsegmente auf einem anderen Software-Modul auf demselben oder einem anderen Mikroprozes¬ sor-Modul gestartet werden, die nicht mit dem versagenden Software-Modul identisch sind, jedoch auch diese Teilfunkti¬ on oder Teilaufgabe durchführen können.
Ferner ist es besonders vorteilhaft, wenn gemäß einer Wei¬ terbildung der Erfindung bei Erkennung eines Fehler behafteten Mikroprozessor-Moduls zur Fehlerbehebung ein weiteres Mikroprozessor-Modul die Durchführung der Funktion des Fehler behafteten Mikroprozessor-Moduls übernimmt, auf welchem das zur Durchführung dieser Funktion erforderliche Software- Modul lokalisiert ist. Damit wird eine Sicherheitsarchitek¬ tur mit weiter erhöhter Robustheit geschaffen, da bei einem Versagen eines Mikroprozessor-Moduls andere Mikroprozessor- Module aktiv bleiben, Software-Module im Fehlerfall teilwei- se oder vollständig weiter ausgeführt werden sowie auch hier Teilfunktionen oder Teilaufgaben als Backup-Routinen oder Programmsegmente in einem anderen Software-Modul auf einem anderen Mikroprozessor-Modul mit der Kontrolle beauftragt werden können.
Dabei ist es weiterbildungsgemäß besonders vorteilhaft, dass zur Ausführung einer sicherheitsrelevanten Funktion mehrfach auf einem oder mehreren Mikroprozessor-Modulen verteilte Software-Module mit im Wesentlichen redundanter Software vorgesehen sind.
Die dadurch erhöhte Verfügbarkeit äußert sich in der Fehler¬ toleranz des erfindungsgemäßen Mikroprozessorsystems gegenüber dem Versagen eines Software-Moduls darin, dass ein identisches oder teilidentisches Software-Modul zur Fehler¬ behandlung ausführbar ist.
Weiterhin wird die funktionale Sicherheit des Mikroprozes¬ sorsystem erhöht, wenn gemäß einer Weiterbildung der Erfindung zur Ausführung einer sicherheitsrelevanten Funktion mehrfach auf einem oder mehreren Mikroprozessor-Modulen verteilte Software-Module mit diversitär redundanter Software vorgesehen sind. Damit wird sowohl eine Absicherung auf Hardware-Ebene durch die Eigensicherheit der Mikroprozessor- Module als auch eine Absicherung auf Software-Ebene durch die Redundanz diese Software-Module mit der diversitär re¬ dundanten Software gewährleistet.
Des Weiteren ist es besonders vorteilhaft, wenn nach einer Ausgestaltung der Erfindung jedes Mikroprozessor-Modul zur Durchführung von Grundfunktionen Software-Grundmodule, vor- zugsweise Kommunikation-Software-Module, Eingangsplausibili- sierungs-Software-Module und aufgabenspezifische Software- Module, welche jeweils einmal auf dem Mikroprozessor-Modul lokalisiert sind, aufweist.
Damit können auf dem erfindungsgemäßen Mikroprozessorsystem mit mehreren Mikroprozessor-Modulen neben sicherheitskritischer Software, wie zum Beispiel Bremsenregelungssoftware (ABS/ASR/EBV) oder Fahrdynamikregelungssoftware (ESP/ESC) auch nicht sicherheitskritische Software, zum Beispiel Soft¬ ware für Navigationssysteme oder nicht hochgradig sicher¬ heitskritische Systeme wie Abstandsregelsysteme (ACC) oder sonstige Software für nicht sicherheitskritische Fahreras¬ sistenzsysteme oder Komfortfunktionen parallel zur sicherheitskritischen Software ausgeführt werden. Da die Mikropro¬ zessor-Module mit einer eigensicheren Multiprozessorstruktur aufgebaut sind, kann dies der Robustheit und möglichst ge¬ ringen Wechselwirkungen wegen in verschiedenen Laufzeitumge- bungen (RTEs, Run-Time Environments) realisiert werden.
Vorzugsweise können die Mikroprozessor-Module als ASIC rea¬ lisiert werden, so dass gewährleistet ist, dass die ver¬ schiedenen Mikroprozessormodule nicht nur bezüglich Ihrer IC-Gehäuse räumlich kurz angebunden sind, was nach wie vor für die Einbringung in Leiterplatten bzw. Kabelbäume taugliche Bussysteme erforderlich ist, welche schnell aber nicht schnellst sind, sondern auch auf Ebene des DIE bzw. dem Si¬ lizium gemeinsame Strukturen oder Busse für eine möglichst optimale Datenübertragungsgeschwindigkeit nutzbar werden, so dass kurze Entfernungen für eine schnelle Datenübertragung sorgen, schnelle Bus-Systeme vorgesehen werden können und nur geringe Latenzen auftreten. Ein weiterer Vorteil besteht darin, dass Software-Module un¬ terschiedlicher Herkunft (bspw. OEM-spezifische Anwendungen und Eigenentwicklungen) auf dem Mikroprozessorsystem entkop¬ pelt werden können, da sowohl das eine Software-Modul auf einem eigensicheren Mikroprozessor-Modul und das andere Software-Modul auf einem anderen eigensicheren Mikroprozes¬ sor-Modul lokalisiert werden können. Insbesondere kann damit auch sicherheitsrelevante von nicht sicherheitsrelevanter Software entkoppelt werden.
Vorzugsweise ist als Software-Grundmodul weiterbildungsgemäß ein Ausgangsarbitrierungs-Software-Modul vorgesehen, welches eine Arbitrierung und vorteilhafterweise auch eine Plausibi- lisierungsprüfung der Ergebnisse der eine sicherheitsrele¬ vante Funktion durchführenden redundanten und/oder
diversitär redundanten Software-Module durchführt. Dies er¬ möglicht eine eineindeutige Fehlerzuordnung, ob also ein Versagen eines Mikroprozessor-Moduls oder ein Versagen eines Software-Moduls vorliegt. Denn in Verbindung mit den eigen¬ sicheren Mikroprozessor-Modulen können im Falle eines negativen Vergleichs der Ergebnisse redundanter Software-Module bei gleichzeitiger Sicherstellung der Funktionstüchtigkeit der Mikroprozessor-Module die Software-Module als fehlerhaft erkannt werden. Der Vorteil besteht also darin, dass nicht nur Hardware-Fehler entdeckt werden können, sondern durch die parallele Abarbeitung von Software auch konzeptionelle Software-Fehler entdeckt werden können.
Besonders vorteilhaft ist es gemäß einer Weiterbildung der Erfindung, wenn wenigstens ein Mikroprozessor-Modul als Mul- tiprozessorplattform hinsichtlich seiner Mikroprozessorkerne in einem Lockstep-Modus (LSM) arbeitet, wodurch eine Absi¬ cherung weitestgehend aufgrund von räumlicher Redundanz, also duplizierten Strukturen erreicht wird. Ein solches Mikro¬ prozessor-Modul arbeitet grundsätzlich in diesem LSM-Modus, kann aber auch nach dem Einschalten der Versorgungspannung auf eine Initialisierungsroutine folgend oder nach einem ex¬ ternen Reset-Signal oder zur Laufzeit als einmaligen Vorgang in diesen LSM-Modus versetzt werden, in dem dieses Mikropro¬ zessor-Modul auch verbleibt.
Desweiteren kann weiterbildungsgemäß wenigstens ein Mikro¬ prozessor-Modul als Multiprozessorplattform hinsichtlich seiner Mikroprozessorkerne in einem Decoupled-Parallel-Modus (DPM) arbeiten, nämlich seine funktionalen Sicherheitsziele über die architektonische Maßnahme der asymmetrischen Redun¬ danz erreicht. Dadurch wird die Absicherung durch einen zeitlich integralen Abgleich erreicht, die auf asymmetrisch ausgeführter räumlicher Redundanz der Komponenten basiert.
Das erfindungsgemäße Mikroprozessorsystem kann nach einer Ausgestaltung der Erfindung neben mehreren Mikroprozessor- Modulen als Multikernprozessorplattformen wenigstens ein Mikroprozessor-Modul mit einem einzigen Mikroprozessorkern (Single Core Prozessor) aufweisen. Vorzugsweise sind dabei diese Mikroprozessor-Module mit wenigstens einem Bus-System mit einer Input/Output-Schnittstelle verbunden, um eine ex¬ terne Erweiterbarkeit zu ermöglichen.
Ferner kann das erfindungsgemäße Mikroprozessorsystem gemäß einer Weiterbildung der Erfindung mit Mikroprozessor-Modulen ausgebildet werden, welche jeweils gleichartige Betriebssys¬ teme aufweisen. Damit ist es vorzugsweise möglich, hierfür ein Betriebssystem zu verwenden, welches die Rechenlast sta¬ tisch, teildynamisch oder volldynamisch auf die verschiedenen Mikroprozessor-Module verteilt.
In einer Ausgestaltung der Erfindung sind ein Teil der Mikroprozessor-Module jeweils mit einem zeitscheibenbasierten Betriebssystem ausgerüstet, welche synchronisiert werden. Dadurch sind die Mikroprozessor-Module phasenstarr miteinan¬ der gekoppelt. Dies kann bspw. durch eine zeitäquidistante Versendung von Zeitmarken durch einen Sender über externe oder Onchip-Bus-Systeme im Zusammenwirken mit einer vorteil¬ haften Justage der Zeitscheibe auf Seiten des Empfängers er¬ reicht werden.
Schließlich ist es erfindungsgemäß vorgesehen, die Mikropro¬ zessor-Module wenigstens teilweise als ASIC mit einem ge¬ meinsamen Gehäuse auszubilden.
Das erfindungsgemäße Mikroprozessorsystem ist in vorteilhaf¬ ter Weise für die Anwendung in einem elektronischen Fahrzeugsteuergerät, welches vorzugsweise für die Bremsensteue¬ rung und -regelung vorgesehen ist, geeignet, wobei der Eigenschaften nach typischerweise jedoch auch prädestiniert, um Software-Module zu beherbergen, welche das fahrdynamische Verhalten der, oder einer ausgewählten Gruppe von Chassis- Steuergeräten koordinieren. Die Koordination kann in diesem Fall Eingriffe im Sinne von systemweiten
Betriebsmodusumschaltungen der Arbeitspunkte der Steuergeräte der Chassisdomäne oder aber auch einstufigen oder mehrstufigen oder kaskadierten oder eingebetteten Regelschleifen umfassen . Die Erfindung wird nachfolgend anhand von Ausführungsbei¬ spielen unter Bezugnahme auf die beigefügten Figuren ausführlich beschrieben. Es zeigen:
Figur 1 ein schematisches Blockschaltbild eines Mikropro¬ zessorsystems mit eigensicheren Mikroprozessor- Modulen als Grundelemente gemäß der Erfindung,
Figur 2 ein schematisches Blockschaltbild eines eigensi¬ cheren Mikroprozessor-Moduls des Mikroprozessorsys¬ tems nach Figur 1,
Figur 3 ein schematisches Blockschaltbild eines weiteren eigensicheren Mikroprozessor-Moduls des Mikropro¬ zessorsystems nach Figur 1, und
Figur 4 eine schematische Darstellung einer Aufteilung von verschiedenen Software-Modulen auf zwei Mikroprozessor-Module eines Mikroprozessorsystems gemäß Fi¬ gur 1.
Ein Mikroprozessorsystem MCUSA gemäß Figur 1 besteht aus mehreren duplizierten Grundelementen, die als eigensichere Mikroprozessor-Module HWSAi (i=l, ... i=n) , auch CPU-Module ge¬ nannt, wenigstens zwei Mikroprozessorkerne CPUi und CPU2 bzw. CPU3 und CPU4 aufweisen, wie aus den Figuren 2 und 3 ersicht¬ lich ist. Ferner kann dieses Mikroprozessorsystem MCUSA wenigstens einen Mikroprozessor CPU umfassen, der als Standard-Mikroprozessor (also nicht eigensicher ist) nur einen Kern (Single Core Prozessor) aufweist. Jedes dieser Mikro¬ prozessor-Module HWSAi (i=l, ... i=n) als auch der Standard- Mikroprozessor CPU sind über eine Schnittstelle IF mit einem zentralen Bus-System oder Netzwerk B verbunden, wobei über eine Schnittstelle IFext eine Erweiterung durch Anschluss weiterer Komponenten, bspw. Hardware-Module möglich ist. Es ist auch möglich die Mikroprozessor-Module HWSAi (i=l, ... i=n) und ggf. auch den Standard-Mikroprozessor CPU vollständig oder teilweise miteinander über mehrere, ggf. autarke Bus¬ systeme zu vernetzten.
Das eigensichere Mikroprozessor-Modul HWSAi als Dual-Core- Mikroprozessor gemäß Figur 2 arbeitet im sogenannten
LSM (Lockstep) -Modus, d. h. solche Mikroprozessoren führen redundant und taktsynchron (daher Lockstep-Modus) das glei¬ che Programmsegment aus, die Ergebnisse der beiden Mikropro¬ zessorkerne CPUi und CPU2 werden verglichen und ein Fehler wird dann bei dem Vergleich auf Übereinstimmung erkannt.
Jeder Mikroprozessorkern CPUi und CPU2 des Mikroprozessor- Moduls HWSAi gemäß Figur 2 weist ein eigenes Bus-System Bi bzw. B2 auf, die über eine Schnittstelle IF verbunden sind. Zur Durchführung des Vergleichs der Ergebnisse sind, vor¬ teilhafterweise redundante Komparatoren Ki und K2 vorgesehen, welche zur Erkennung von Einfachfehlern von Hardwaredefekten alle Ein- und Ausgänge der redundanten Grundelemente dieses Mikroprozessor-Moduls HWSAi überwachen, sowie die in Figur 2 beispielhaft dargestellten beiden Mikroprozessorkerne CPUi und CPU2 im Fehlerfall, also bei einer Diskrepanz zwischen den beiden Mikroprozessorkerne CPUi und CPU2 ein Abschalten dieses Mikroprozessor-Moduls HWSAi oder dessen Degradierung bewirkt. Die Absicherung wird durch eine weitgehende symmet¬ rische räumliche Redundanz erreicht, d. h. Strukturen werden dupliziert. Neben den dargestellten Mikroprozessorkernen CPUi und CPU2 umfasst dieses Mikroprozessor-Modul HWSAi weitere Komponenten, wie Arbeitsspeicher (RAM) , Programmspeicher (Flash oder ROM) Vergleicher und Sicherheitsmodule, Module für externe Busse (CAN, LIN, Flexray, MOST, ISOK, Ethernet) wobei solche Komponenten aus Sicherheitsgründen auch redundant ausgeführt sein können. Auch können solche Komponenten neben der räumlichen Redundanz im Sinne einer wesentlichen Duplizierung der Strukturen sowie neben dem Fall der einfachen Ausführung ganz ohne vollständige Duplizierung auch über eine asymmetrische Redundanz verfügen. Beispielsweise sei genannt, dass ein Flash bzw. ROM Speicher durch zusätzliche Speicherkapazitäten erweitert sein kann, welche dem Zwecke der Beherbergung von Checksummen dienen. Diese zusätzlichen Elemente im Sinne von Speicherbits für nicht¬ funktionale, sondern sicherheitsgerichtete Zwecke ist forma vergleichbar mit einer teilweise redundanten Ausführungsform, welche ob ihrer Unvollständigkeit nach nicht nach dem Prinzip der räumlichen Redundanz, dem vorgenannten Lockstep Modus LSM arbeiten kann, sondern nach den Prinzipien asymmetrisch abgesicherter Strukturen, zeitlich integral, arbei ten muss.
Das eigensichere Mikroprozessor-Modul HWSAj als Dual-Core- Mikroprozessor mit zwei Mikroprozessorkernen CPU3 und CPU4 gemäß Figur 3 arbeitet im sogenannten DPM (Decoupled Paral¬ lel) -Modus, d. h. sie können unabhängig voneinander verschieden Programmsequenzen abarbeiten. Jeder Mikroprozessor kern CPU3 und CPU4 weist einen eigenen Bus B3 bzw. B4 auf, di über eine Schnittstelle IF verbunden sind. Neben diesen bei den Kernen CPU3 und CPU4 sind auch weitere Komponenten, wie Arbeitsspeicher (RAM), Programmspeicher (Flash oder ROM) Vergleicher und Sicherheitsmodule, Module für externe Busse (CAN, LIN, Flexray, MOST, ISOK, Ethernet) vorhanden. Eine Absicherung wird durch einen zeitlich integralen Abgleich erreicht und sowohl auf symmetrisch wie auch asymmetrisch ausgeführter räumlicher Redundanz der Komponenten basieren kann .
Das Mikroprozessorsystem MCUSA gemäß Figur 1 besteht damit aus einer Parallelstruktur von mehreren eigensicheren Grundelementen, nämlich den Mikroprozessor-Modulen HWSAi (i=l, ... i=n) und stellt eine Mikroprozessor-Sicherheits-Architektur dar, wobei diese Struktur als ASIC oder zumindest mit weni¬ gen ASIC^s in einem einzigen Gehäuse hergestellt werden kann .
Dieses Mikroprozessorsystem MCUSA gemäß Figur 1 stellt nicht nur eine Hardware-Systemarchitektur dar, welche eine Eigensicherheit gemäß der ASL-D Klassifizierung sicherstellt, sondern sichert auch auf der Software-Ebene eine Eigensi¬ cherheit gemäß dieser Sicherheitsstufe ASIL-D, wie im Fol¬ genden erläutert werden soll.
Hierzu zeigt Figur 4 beispielhaft die statische Allokierung bzw. Verteilung verschiedener Software-Module auf zwei eigensicheren Mikroprozessor-Module HWSAi und HWSA2 eines Mik¬ roprozessorsystem MCUSA, wie bspw. gemäß Figur 1. Dabei können diese beiden Mikroprozessor-Module HWSAi und HWSA2 ent¬ sprechend Figur 2 oder Figur 3 aufgebaut sein. Die aufge¬ führten Software-Module in dem jeweiligen Mikroprozessor- Modul HWSAi und HWSA2 werden entsprechend den Zeitachsen bzw. Zeitbasen tHwsAi und tHwsA2 einer bspw. zugehörigen Laufzeitum¬ gebung sequentiell abgearbeitet, beginnend und endend je¬ weils mit einem Software-Grundmodul „HWSA-Communication" . Dabei sind diejenigen Software-Module mit (D) gekennzeich- net, die der Sicherheitsstufe ASIL-D entsprechen, also Soft¬ ware mit einem hohen Sicherheitslevel zum Beispiel für sicherheitskritische Anwendungen, wie ABS- oder ESP- Funktionen, wie sie in speziellen Aus führungs formen vorkommen .
Hinsichtlich der Software-Module auf den beiden Mikroprozes¬ sor-Modulen HWSAi und HWSA2 wird einerseits unterschieden zwischen sogenannten Software-Grundmodulen, die auf jedem der beiden Mikroprozessor-Module HWSAi und HWSA2 vorgesehen sind und jeweils nur einmal ausgeführt werden und anderer¬ seits Software-Modulen, die mehrfach redundant statisch auf einem Mikroprozessor-Modul, also bspw. HWSAi oder HWSA2 oder mehreren Mikroprozessor-Modulen, also bspw. HWSAi und HWSA2 allokiert und ausgeführt werden. Dabei können auch einige der Software-Module überlappende Aufgaben haben.
Bei diesen Software-Grundmodulen handelt es sich um Kommunikation-Software-Module, Eingangsplausibilisierungs-Software- Module und aufgabenspezifische Software-Module.
Das bereits erwähnte Software-Grundmodul „HWSA-Communicati- on" erlaubt einen Austausch von Daten, entweder uni- oder bidirektional über ein Bussystem oder ein Netzwerk B des Mikroprozessorsystem MCUSA (vgl. Figur 1) . Dies soll Eingangsgrößen für die Regelfunktionen, laufzeitrelevante Daten (Zähler, Statusinformationen, Systemzeiten, etc.) und Ausgangsgrößen/Ergebnisse der Regelfunktionen umfassen.
Das Eingangsplausibilisierungs-Software-Module „HWSAl-Input- Plausibilization" bzw. „HWSA2-Input-Plausibilization" dienen dazu, die zuvor per Kommunikation, also mittels der Soft- ware-Grundmodule „HWSA-Communication" erhaltenen Eingangsgrößen zu plausibilisieren, um als qualifizierte Werte an die Regelfunktionen weitergegeben werden zu können, da nur Ergebnisse von Regelfunktionen, die auf qualifizierten Eingangsgrößen beruhen können, nach Fertigstellung der Berechnung auch sinnvoll vergleichbar sind.
Zusätzlich zur in den Eingangsplausibilisierungs-Software- Modulen ausgeführten Prüfung der Kommunikationsdaten kann eine sogenannte End-To-End Absicherung, auch E2E genannt, angewandt werden, welche dem Funktionsprinzip nach bereits in der das Kommunikationsdatum erzeugenden Regelfunktion ei ne eineindeutige Absicherungs-Prüfsumme dem Datum hinzufügt sowie diese mit dem Datum als atomische Einheit gleichzeiti und gemeinsam versendet. Diese Absicherungs-Prüfsumme wird von der das Datum empfangenden bzw. allen das Datum empfangenden Regelfunktionen aufgrund bekanntem Berechnungsschlüs sei der E2E Prüfsumme zur Gegenprüfung auf korrekte Übertra gung des Datums herangezogen und damit sogar Mittel zur Ver fügung stellt, eine aufgrund eines konzeptionellen Fehlers im Ausgangs-Plausibilisierungs-Software-Modul auf Seite des Senders als auch im Eingangs-Plausibilisierungs-Software- Modul auf Seite des Empfängers erfolgte Verfälschung erken¬ nen und hierauf entsprechend reagieren zu können.
Die aufgabenspezifischen (dedicated task) Software-Grundmo¬ dule des Mikroprozessor-Moduls HWSAi bzw. Mikroprozessor- Moduls HWSA2 werden gemäß Figur 4 als „HWSAl-Dedicated-Task 1", „HWSAl-Dedicated-Task 2" und „HWSAl-Dedicated-Task 3" bzw. „HWSA2-Dedicated-Task Y", „HWSA2-Dedicated-Task Z" und „HWSA2-Dedicated-Task W" bezeichnet. Auch diese Software- Grundmodule werden einfach ausgeführt, ohne weiterführende Anforderungen an Diversität und erhöhter Robustheit oder ohne Redundanz genügen zu müssen. Diese aufgabenspezifischen Software-Grundmodule existieren im Wesentlichen nur ein Mal und werden auf dem Mikroprozessor-Modul HWSAi bzw. HWSA2 „de- diziert" ausgeführt.
Ferner sind als Software-Module auch Ausgangsarbitrierungs- Software-Module vorgesehen, bezeichnet als „HWSAl-Output- Plausibilization" bzw. „HWSA2-Output-Plausibilization" , die zur Plausibilisierung der zuvor von der Gesamtheit aller Regelfunktionen bestimmten Ausgangswerte bzw. Stellgrößen dienen. Dabei wird zwischen der funktional notwendigen
Plausibilisierung und der aus funktionaler Sicherheit notwendigen Plausibilisierung unterschieden. Diese unterschiedlichen Plausibilisierungen werden weiter unten beschrieben.
Weiterhin gibt es Software-Module, die auf einem Mikropro¬ zessor-Modul mehrfach und/oder auf mehreren Mikroprozessor- Modulen verteilt lokalisiert sind und gemäß Figur 4 mit „HWSA-Task A±j", „HWSA-Task B±j", „HWSA-Task C±j" und „HWSA- Task X±j" bezeichnet. Diese redundanten Software-Module sind mit der gleichen Aufgabe betraut, d.h. dienen weitestgehend dem gleichen Zweck.
Für das Mikroprozessorsystem MCUSA ergibt sich damit insgesamt eine erhöhte Verfügbarkeit sowie eine erhöhten Sicher¬ heit.
Wenn solche Software-Module auf mehreren Mikroprozessor- Modulen HWSAi verteilt sind, werden höhere Robustheitsforde¬ rung und höhere Verfügbarkeit gegenüber Hardware-Ausfällen erfüllt . Bei einer statischen Allokation solcher Software-Module sowohl mehrfach innerhalb eines Mikroprozessor-Modules HWSAi oder HWSA2 als auch auf mehreren Mikroprozessor-Modulen HWSAi und HWSA2, werden erhöhte Sicherheitsanforderungen gegenüber „Defekten" oder auch „konzeptionellen Fehlern" erfüllt.
So sind die beiden auf dem Mikroprozessor-Modul HWSA2 allo- kierten Software-Module „HWSA2-Task X13" und „HWSA2-Task X23" redundant mit im Wesentlichem gleichem Algorithmus ausge¬ führt, wobei beide Software-Module vom gleichen Programmie¬ rer A programmiert sind, jedoch das Software-Modul „HWSA2- Task X23" anders als das Software-Modul „HWSA-Task Xi3" kompiliert bzw. assembliert ist, wodurch sich auf der Programmcode-Ebene im Wesentlichen eine Identität ergibt, jedoch durch die unterschiedliche Übersetzung systematische Fehler ausgeschlossen werden können.
Desweiteren sind die beiden redundanten Software-Module „HWSA-Task C33" und „HWSA-Task C23" auf die beiden Mikropro¬ zessor-Module HWSAi und HWSA2 verteilt, wobei beide Software- Module ebenso vom gleichen Programmierer A programmiert wurden, jedoch das Software-Modul „HWSA-Task C23" anders als das Software-Modul „HWSA-Task C33" kompiliert bzw. assembliert ist, wodurch sich auf der Programmcode-Ebene im Wesentlichen eine Identität ergibt, jedoch durch die unterschiedliche Übersetzung systematische Fehler ausgeschlossen werden können .
Diese redundanten Software-Module „HWSA-Task Xi3" und „HWSA- Task X23" bzw. „HWSA-Task C33" und „HWSA-Task C23" verfügen also einen identischen oder nur marginal abgewandelten Algo- rithmus .
Schließlich sind diversitär redundante Software-Module vor¬ gesehen, die auf dem gleichen Mikroprozessor-Modul HWSAi oder HWSA2 verteilt sind.
Gemäß Figur 4 sind dies die beiden auf dem Mikroprozessor- Modul HWSAi allokierten Software-Module „HWSA-Task Ai2" und „HWSA-Task A22", die von zwei verschiedenen Programmierern A und B programmiert sind. Auch zu den beiden redundanten Software-Modulen „HWSA2-Task X13" und „HWSA2-Task X23" auf dem Mikroprozessor-Modul HWSA2 existiert auf demselben Mikropro¬ zessor-Modul HWSA2 ein diversitär redundantes Software-Modul „HWSA-Task X33" . Solche Software-Module variieren strukturell sehr stark.
Solche diversitär redundanten Software-Module können auch auf verschiedene Mikroprozessor-Module verteilt werden. So zeigt Figur 4 ein auf dem Mikroprozessor-Modul HWSAi allo- kiertes Software-Modul „HWSA-Task Bi2", welches von einem Programmierer A programmiert ist und ein hierzu auf dem Mik¬ roprozessor-Modul HWSA2 allokiertes diversitär redundantes Software-Modul „HWSA-Task B22", welches von einem anderen Programmierer B programmiert ist. Auch zu den beiden auf beide Mikroprozessor-Module HWSAi und HWSA2 verteilten redun¬ danten Software-Modulen „HWSA-Task C23" und „HWSA-Task C33", welche von einem Programmierer A programmiert sind, exis¬ tiert auf Mikroprozessor-Modul HWSAi ein diversitär redundan¬ tes Software-Modul „HWSA-Task Ci3", welches von einem anderen Programmierer B programmiert ist. Solche Software-Module va¬ riieren strukturell sehr stark. Die Anzahl m der diversitär redundanten Software-Module kann größer als die Anzahl n (n<m) der Mikroprozessor-Module HWSAi (i=l, ... n) sein. In einem solchen Fall kann eine
Serialisierung von n Software-Modulen auf einem einzigen Mikroprozessor-Modul HWSAi durchgeführt werden. Selbstver¬ ständlich kann in diesem Fall, eine genügende Rechenleistung des zugrundeliegenden Mikroprozessor-Moduls vorausgesetzt, eine erhöhte Sicherheit durch die sequentiell gerechneten und schlussendlich hinsichtlich ihrer Ausgangssignale plau- sibilisierten Software-Module erreicht werden. Jedoch wird in diesem Fall der Einbringung sämtlicher Software-Module die Verfügbarkeit gegenüber Versagen des zugrundeliegenden Mikroprozessor-Moduls nicht gesteigert, wobei es unerheblich ist ob diese Software-Module redundant programmiert oder an¬ ders übersetzt sind. Die Verfügbarkeit wird bei diversitär ausgeführter Einlagerung der redundanten Software-Module auf verschiedene Mikroprozessor-Module gesteigert.
Solche diversitär redundanten, dem gleichen Zweck dienenden, Software-Module „HWSA-Task A±j", „HWSA-Task B±j", „HWSA-Task C±j" und „HWSA2-Task X±j", die über einen nach Intention gänzlich anderen Algorithmus verfügen, liefern die Grundlage für eine konzeptionell redundante Berechnung von Ausgangsgrößen bzw. Ergebnissen von Regelfunktionen, was die Absicherung gegenüber konzeptionellen Fehlern gewährleistet.
Die höhere Verfügbarkeit äußert sich in einer Toleranz des Mikroprozessorsystems MCUSA gegenüber dem Versagen eines Mikroprozessor-Moduls HWSAi, da in einem solchen Fall eines detektierten Fehlers oder Ausfalls eines Mikroprozessor- Moduls HWSAi ein anderes Mikroprozessor-Modul HWSAj (iDj) ein entsprechendes Software-Modul ausführen kann. Eine erhöhte funktionale Sicherheit wird durch die diversitär redundanten Software-Module, welche auf verschie¬ denen Mikroprozessor-Modulen HWSAi ausgeführt werden, erreicht, wodurch sowohl eine Absicherung auf Hardware-Ebene durch die Eigensicherheit der Mikroprozessor-Module HWSAi als auch eine Absicherung auf Software-Ebene durch die
diversitäre Redundanz der Software-Module, also durch deren nicht gleichen Algorithmus gewährleistet wird.
Zurück zu den Software-Modulen „HWSAl-Output-Plausibiliza¬ tion" bzw. „HWSA2-Output-Plausibilization" auf dem Mikroprozessor-Modul HWSAi bzw. HWSA2 nach Figur 4.
Bei der funktional notwendigen Plausibilisierung mittels der Software-Module „HWSAl-Output-Plausibilization" bzw. „HWSA2- Output-Plausibilization" werden spezielle, Regelfunktionen ausführende Software-Module priorisiert und andere zurückge¬ stellt. So ist bspw. im Zusammenhang einer ESP-Regelfunktion und einer ABS-Regelfunktion die Regelfunktion einer ESP- Intervention der einer ABS-Intervention überlegen und wird daher priorisiert und zuerst ausgeführt. Eine solche funkti¬ onale Plausibilisierung wird zugunsten des Handlings des Fahrzeugs ausgeführt.
Bei der aus funktionaler Sicherheit notwendigen
Plausibilisierung mittels den Software-Modulen „HWSAl- Output-Plausibilization" bzw. „HWSA2-Output- Plausibilization" werden die Ergebnisse der redundant bzw. quasiredundant ausgeführten und, abhängig der statischen Allokierung, auf verschiedene Mikroprozessor-Modulen HWSAi verteilten Software-Module miteinander verglichen bzw. be- wertet. So wären die Ergebnisse zweier unabhängiger ESP- Regelfunktionen (also demselben Zweck dienend, nämlich dem Fahrzeug eine „ESP" Funktion zu verleihen) miteinander verglichen. Im Beispiel nach Figur 4 ist etwa das Software- Modul „HWSA-Task Bij " zwei Mal implementiert, nämlich als „HWSA-Task B12 auf dem Mikroprozessor-Modul HWSAi und als „HWSA-Task B22" auf dem Mikroprozessor-Modul HWSA2. Dass die relevanten Eingangsdaten für dieses Software-Modul stimmig sind, ist durch das zuvor ausgeführte Software-Modul „HWSA- Communication" zum Zeitpunkt (vgl. Figur 4) gewährleistet. Dass die errechneten Ausgangsdaten für einen Vergleich oder eine Gewichtung auf beiden Seiten vorliegen wird durch das Software-Modul „HWSA-Communication" zum Zeitpunkt ß gewährleistet. Dass die erreichten Vergleichsergebnisse bzw. Ge¬ wichtungsergebnisse auf beiden Mikroprozessor-Modulen HWSAi und HWSA2 vorliegen wird durch das Software-Modul „HWSA- Communication" zum Zeitpunkt γ gewährleistet.
Desweiteren ist das Mikroprozessorsystem MCUSA gemäß Figur 1 für eine dynamischen Prozessierung hinsichtlich der Software-Module ausgebildet.
Wenn bspw. das Software-Modul „HWSAl-Dedicated-Task 3" ausfällt und eine Teilfunktion oder Teilaufgabe deshalb nicht durchführbar ist und diese Teilaufgabe oder Teilfunktion als Programmsegment auch auf dem Software-Modul „HWSA2- Dedicated-Task Z" der Mikroprozessor-Moduls HWSA2 vorhanden ist, wird dieses Software-Modul „HWSA2-Dedicated-Task Z" der Rolle nach als Backup-Software-Module aktiviert und sei¬ ne Backup-Routinen durchgeführt.
Eine dynamische Prozessierung bedeutet, dass zustandsabhän- gig, also bzgl. Hardware oder Software oder Betriebsmodi des Mikroprozessorsystems bestimmte Mikroprozessor-Module HWSAi bzw. bestimmte Software-Module, also bedarfsabhängig durch¬ geführt werden. Voraussetzung hierfür ist natürlich die statische Allokierung entsprechender Software-Modul, wie dies im Zusammenhang mit Figur 4 beschrieben wurde.
Die Menge der verteilten bzw. diversifizierten Software- Module beinhaltet im Wesentlichen zwei Arten: a) Solche Software-Module, welche erhöhter funktionaler Si¬ cherheit dienen, also in den Mikroprozessor-Modulen HWSAi ein dauerhafter Ergebnisvergleich durchgeführt wird, und b) solche Software-Module, welche erhöhter Verfügbarkeit dienen und die idealerweise alternativ ausgeführt bzw. dyna¬ misch gestartet werden können, um im Normalbetriebsmodus Ressourcen und Laufzeit zu sparen, sofern dies vorteilhaft ist .
Zugunsten einer Absicherung der Software bzw. der Algorithmen gegenüber „konzeptionellen Fehlern" werden, wie oben beschrieben, diversitär redundante Software-Module einge¬ bracht .
Diese diversitär redundanten Software-Module brauchen nicht zwangsläufig auf verschiedenen Mikroprozessor-Modulen HWSAi beherbergt werden. Diese Software-Module fallen unter die oben genannte Kategorie a. Auch werden diese diversitär re¬ dundanten Software-Module aus einer alternativen Betrachtungsweise heraus redundant entwickelt, von einem anderen Team konzeptioniert und von einem anderen Programmierer rea- lisiert. Die Wahrscheinlichkeit der Wiederholung eines spe¬ ziellen „Konzeptionellen Fehlers" wird dadurch verringert.
Konzeptionelle Fehler können beispielsweise durch die Ausge¬ staltung enthaltener Zustandsmaschinen, Zustandstransitionen beim Wechsel von einem Betriebsmodus in den anderen, Fehlerreaktionsverfahren oder ähnliches entstehen. Insbesondere innerhalb von Programmsegmenten, in welchen der oder die Programmierer abbilden wie voneinander abhängige verschiedener momentaner Mess- oder Regelgrößen oder Istzustände sowie Stell- oder Regelwerte oder Sollzustände, also hinsichtlich Kombinatorik oder in einer gewissen Abfolge, also hinsichtlich Sequenz, auf einen Algorithmus abbilden und wie dieser arbeiten, alternative Gleichungen ausführen oder zum Beispiel verschiedene Sicherheitslevel anspringen soll, ergibt sich ein immens komplexer und komplizierter Baum von Permutationen aus der Überlegung einer durchzuführenden mehrstufigen Sequenz über mehrkanaliger Kombinatorik. Diese Umstände begünstigen das Einschleichen von konzeptionellen Fehlern an vermeintlich kleinen, isolierten aber ggf. bei Eintreten fatalen Programmabschnitten, welche aufgrund ihrer wenig ausgedehnten Natur schwerlich vollständig durch Entwicklungstests und/oder Dauerläufe vorab zu identifizieren sind.
Zugunsten der Robustheit des Mikroprozessorsystems MCUSA ge¬ genüber Hardwareausfällen können Software-Module, wie oben beschrieben, auf verschiedene Mikroprozessor-Module HWSAi verteilt bzw. diversifiziert werden. Diese Software-Module fallen unter die oben genannte Kategorie b) . Aus Sicher¬ heitsgründen ist daher eine permanente und konkurrente Aus¬ führung inklusive beiderseitigem Vergleich der Ergebnisse dieser Software-Module nicht erforderlich. Auch würde die Robustheit dadurch nicht steigen. Eine bedarfsgerechte Aus¬ führung der diversifizierten Software-Module hingegen würde eine effizientere Nutzung der Laufzeitreserven der Mikroprozessor-Module HWSAi bedeuten. Der Bedarfsfall kann über den Eintritt in eine spezielle Betriebssituation eintreten. Diese besondere Betriebssituation kann ein detektierter Fehler in einem Mikroprozessor-Modul HWSAi sein, auch kann dies ein besonderer Eigenkalibrier- oder Diagnose-Vorgang sein, der die Funktionstüchtigkeit temporär einschränkt oder ein fort¬ während vorliegender Unterspannungsfall sein. Es nicht not¬ wendig durch Backup-Software-Module die volle Funktionalität abdecken zu lassen. Die Backup-Software-Module können schlanker ausfallen, kleiner von Code-Größe und Laufzeitkonsum sein. Aus Effizienzgründen kann das, die Backup- Software-Module dynamisch ausführende Mikroprozessor-Modul HWSAi eine Menge ihrer lokalen, nicht essentiellen Software- Module dynamisch abschalten, um die Prozessierung der Backup-Software-Module gewährleisten zu können.
Weiterhin ist mit dem Mikroprozessorsystem MCUSA gemäß Figur 1 eine zeitkontinuierliche Plausibilisierung, also ein stän¬ diger Vergleich der Ergebnisse der verteilten Software- Module vorgesehen.
Zur Beurteilung der für die funktionalen Sicherheit erforderlichen relevanten Eingangsdaten, Ergebnisse und Teilergebnisse sowie Ausgangsdaten der auf dem jeweiligen Mikroprozessor-Modul HWSAi vorliegenden und verteilt gerechneten Software- Modulen werden diese in geeigneter Weise zu verschiedenen Zeitpunkten ( , ß und γ gemäß Figur 4) innerhalb des Mikroprozessorsystems MCUSA kommuniziert, wie dies zu den oben erläuterten Zeitpunkten , ß und γ i. Z. mit Figur 4 erläutert wurde. Somit wird ein Mittel zu Verfügung ge¬ stellt, welches es gestattet zur Laufzeit sowohl die Funkti¬ onstüchtigkeit der verteilten redundanten Mikroprozessor- Module HWSAi innerhalb des Mikroprozessorsystems MCUSA zu kommunizieren als auch die Funktionstüchtigkeit der verteil¬ ten Software-Module hinsichtlich des Ausschlusses von durch konzeptionelle Fehler im Algorithmus aufgetretenen Programmschwächen zu belegen.
Zusammenfassend zeichnet sich das erfindungsgemäße Mikropro¬ zessorsystem MCUSA durch folgende Vorteile aus:
- Es zeigt eine erhöhte Robustheit des eingebetteten Gesamt¬ systems sowohl hinsichtlich Hardware als auch Software:
- Bei Versagen eines Mikroprozessor-Moduls bleiben andere Mikroprozessor-Module aktiv; Software-Module werden teilweise oder ganz weiter ausgeführt. Ferner werden Backup Routinen in einem anderen Software-Modul auf ei¬ nem anderen Mikroprozessor-Modul mit der Kontrolle be¬ auftragt,
- Bei Versagen eines Software-Moduls bleiben andere Soft¬ ware-Module aktiv. Es kann dasselbe Software-Modul auf¬ grund der Redundanz durchgestartet bzw. neu initiali¬ siert werden. Ferner können Backup Routinen in einem anderen Software-Modul auf demselben oder einem anderen Mikroprozessor-Modul HWSAi gestartet werden.
- Möglichkeit der eineindeutigen Fehlerzuordnung im Fehlerfall zu Hardware oder Software:
- Bei Versagen eines Mikroprozessor-Moduls HWSAi wird dies eineindeutig angezeigt, bspw. durch ein Register, ein Interrupt, ein Exception oder automatisch ein Signal bzw. Pin setzende Überwachungshardware;
- Bei Versagen eines Software-Moduls wird dies eineindeu¬ tig durch Vergleich bzw. Bewertung gegenüber den Ergebnissen eines anderen Software-Moduls festgestellt; und
- Die Ursachenerkennung bei Deutung ob Versagen eines
Mikroprozessor-Moduls HWSAi oder eines Software-Moduls vorliegt ist eineindeutig möglich, da eigensichere Mik¬ roprozessor-Module HWSAi mit entsprechend eigensicher ausgeführten Infrastrukturmodulen (RAM, FLASH, Busse, etc.) verwendet werden, so dass im Falle eines negati¬ ven Ergebnisvergleichs, d. h. dass Ergebnisse redundan¬ ter Software-Module sich widersprochen haben, bei gleichzeitiger Sicherstellung der Funktionstüchtigkeit der Mikroprozessor-Module HWSAi die Software-Module als nicht funktionstüchtig eingestuft werden können. Optio¬ nal kann eine Zwei- oder Mehrfachredundanz der Software-Module angewendet werden, um durch Ma oritätsbil¬ dung das problembehaftete Software-Modul eineindeutig zu identifizieren und die sichere Funktionsausführung dennoch aufrechtzuerhalten. ynamische Rechenkapazitätsallokierung :
- Bei Versagen eines Mikroprozessor-Moduls HWSAi werden Backup Routinen in einem anderen Software-Modul auf ei¬ nem anderen Mikroprozessor-Modul HWSAj mit der Kontrolle beauftragt; und
- Bei Versagen eines Software-Moduls werden Backup Routi¬ nen in einem anderen Software-Modul auf demselben oder einem anderen Mikroprozessor-Modul HWSAi gestartet; - Flexibles Design des eingebetteten Gesamtsystems aus Mik¬ roprozessor-Modul HWSAi und Software-Modulen:
- Strukturiertheit und einfache Portierbarkeit der Soft¬ ware-Module über die Mikroprozessor-Module HWSAi hinweg können implizit „by design" erreicht werden.
Das Mikroprozessorsystem MCUSA kann als ASIC in einem einzigen Gehäuse aufgebaut werden. Natürlich ist es auch möglich das Mikroprozessorsystem MCUSA auf zwei oder mehreren ASIC's zu realisieren und dann in einem einzigen IC-Gehäuse zusammenzufassen oder jedes ASIC in ein eigenes IC-Gehäuse zu pa¬ cken .
Weiterhin ist es möglich, dass die Betriebssysteme der Mik¬ roprozessor-Modul HWSAi gleich oder verschiedenartig sein können, auch dass ein einziges Betriebssystem zum Einsatz kommen kann, welches die Rechenlast statisch, teildynamisch oder volldynamisch auf die diversen Mikroprozessor-Module HWSAi verteilt.
Schließlich können diejenigen auf einer Zeitscheibenbasis arbeitenden Betriebssysteme der Mikroprozessor-Module HWSAi synchronisierbar zueinander ausgebildet werden, d.h. einen definierten phasenstarren Zustand zueinander einnehmen, was z.B. durch die zeitäquidistante Versendung von Zeitmarken durch einen Sender via externer oder Onchip-Bussystemen im Zusammenwirken mit einer vorteilhaften Justage der Zeitscheibe (Loop) auf Seiten des Empfängers erreichbar ist.

Claims

Patentansprüche
1. Mikroprozessorsystem (MCUSA) zur Ausführung von zumindest teilweise sicherheitskritischen Software-Modulen im Rahmen der Steuerung und/oder Regelung von den Software- Modulen zugeordneten Funktionen oder Aufgaben, welches wenigstens ein eigensicheres Mikroprozessor-Modul (HWSAi) mit wenigstens zwei Mikroprozessorkernen (CPU±) umfasst, dadurch gekennzeichnet, dass
- wenigstens ein weiteres eigensicheres Mikroprozessor- Modul (HWSAi i=l, ... n) mit wenigstens zwei Mikroprozes¬ sorkernen (CPUi, CPU2; CPU3, CPU4) vorgesehen ist, wobei die wenigstens beiden Mikroprozessor-Module (HWSAi,
HWSA2) über ein Bus-System (B) verbunden sind,
- wenigstens zwei Software-Module vorgesehen sind, wel¬ che wenigstens teilweise überlappende Funktionen ausfüh¬ ren,
- diese Software-Module mit wenigstens teilweise über¬ lappenden Funktionen auf einem Mikroprozessor-Modul (HWSAi, HWSA2) oder auf wenigstens zwei Mikroprozessor- Modulen (HWSAi, HWSA2) verteilt sind, und
- Zur Erkennung von Software- und/oder Hardware-Fehlern Mittel zum Vergleichen und/oder Arbitrieren der mit den Software-Modulen für die identischen Funktionen erzeugten Ergebnisse vorgesehen sind.
2. Mikroprozessorsystem (MCUSA) nach Anspruch 1, dadurch gekennzeichnet, dass bei Erkennung eines Fehler behafte¬ ten Software-Moduls dessen Funktion zur Fehlerbehebung von einem weiteren Software-Modul ausgeführt wird, wel¬ ches diese Funktion wenigstens als mit dem Fehler behaf¬ teten Software-Modul überlappende Funktion aufweist.
3. Mikroprozessorsystem (MCUSA) nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass bei Erkennung eines Fehler behafteten Mikroprozessor-Moduls (HWSAi, HWSA2) zur Feh¬ lerbehebung ein weiteres Mikroprozessor-Modul (HWSAi, HWSA2) die Durchführung der Funktion des Fehler behafte¬ ten Mikroprozessor-Moduls (HWSAi, HWSA2) übernimmt, auf welchem das zur Durchführung dieser Funktion erforderliche Software-Modul lokalisiert ist.
4. Mikroprozessorsystem (MCUSA) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zur Ausfüh¬ rung einer sicherheitsrelevanten Funktion mehrfach auf einem oder mehreren Mikroprozessor-Modulen (HWSAi, HWSA2) verteilte Software-Module mit im Wesentlichen redundan¬ ter Software vorgesehen sind.
5. Mikroprozessorsystem (MCUSA) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zur Ausfüh¬ rung einer sicherheitsrelevanten Funktion mehrfach auf einem oder mehreren Mikroprozessor-Modulen (HWSAi, HWSA2) verteilte Software-Module mit diversitär redundanter Software vorgesehen sind.
6. Mikroprozessorsystem (MCUSA) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass jedes Mikro¬ prozessor-Modul (HWSAi, HWSA2) zur Durchführung von
Grundfunktionen Software-Grundmodule, vorzugsweise Kom¬ munikation-Software-Module, Eingangsplausibilisierungs- Software-Module und aufgabenspezifische Software-Module, welche jeweils einmal auf dem Mikroprozessor-Modul loka¬ lisiert sind, aufweist.
7. Mikroprozessorsystem (MCUSA) nach Anspruch 6, dadurch gekennzeichnet, dass als Software-Grundmodul ein
Ausgangsarbitrierungs-Software-Modul vorgesehen ist, welches eine Arbitrierung und vorzugsweise auch eine Plausibilisierungsprüfung der Ergebnisse der eine sicherheitsrelevante Funktion durchführenden redundanten und/oder diversitär redundanten Software-Module durchführt .
8. Mikroprozessorsystem (MCUSA) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass wenigstens ein Mikroprozessor-Modul (HWSAi) hinsichtlich seiner Mik¬ roprozessorkerne (CPUi, CPU2) in einem Lock-Stepped-Modus (LSM) arbeitet.
9. Mikroprozessorsystem (MCUSA) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass wenigstens ein Mikroprozessor-Modul (HWSA2) hinsichtlich seiner Mik¬ roprozessorkerne (CPU3, CPU3) in einem Decoupled-Parallel- Modus (DPM) arbeitet.
10. Mikroprozessorsystem (MCUSA) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass im Mikropro¬ zessorsystem (MCUSA) wenigstens ein Mikroprozessor (CPU) mit einem Mikroprozessorkern (Single Core Prozessor) vorgesehen ist.
11. Mikroprozessorsystem (MCUSA) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Mikro¬ prozessor-Module (HWSAi, i=l, ... n) wenigstens ein Bus- System mit einer Input/Output-Schnittstelle zur externen Erweiterbarkeit aufweisen.
12. Mikroprozessorsystem (MCUSA) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Mikro¬ prozessor-Module (HWSAi, i=l, ... n) identische Betriebs¬ systeme aufweisen.
13. Mikroprozessorsystem (MCUSA) nach Anspruch 12, dadurch gekennzeichnet, dass das Betriebssystem ausgebildet ist, die Rechenlast zur Ausführung einer Funktion auf mehrere Mikroprozessor-Module (HWSAi, i=l, ... n) verteilen zu kön¬ nen .
14. Mikroprozessorsystem (MCUSA) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein Teil der Mikroprozessor-Module (HWSAi, i=l, ... n) mit zeitscheiben- basierten Betriebssystemen ausgerüstet sind, welche synchronisiert werden.
15. Mikroprozessorsystem (MCUSA) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Mikro¬ prozessor-Module (HWSAi, i=l, ... n) wenigstens teilweise als ASIC mit einem gemeinsamen Gehäuse ausgebildet sind.
16. Verwendung des Mikroprozessorsystems (MCUSA) nach einem der vorhergehenden Ansprüche in einem elektronischen Fahrzeugsteuergerät, welches vorzugsweise für die Brem¬ sensteuerung und -regelung vorgesehen ist.
PCT/EP2011/070414 2010-11-19 2011-11-18 Mikroprozessorsystem mit fehlertoleranter architektur WO2012066108A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP11785406.7A EP2641176B1 (de) 2010-11-19 2011-11-18 Mikroprozessorsystem mit fehlertoleranter architektur
US13/988,176 US20130268798A1 (en) 2010-11-19 2011-11-18 Microprocessor System Having Fault-Tolerant Architecture
CN201180055658.7A CN103262045B (zh) 2010-11-19 2011-11-18 具有容错架构的微处理器系统
KR1020137015830A KR20130119452A (ko) 2010-11-19 2011-11-18 오류 허용 아키텍쳐를 갖는 마이크로프로세서 시스템

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE102010044191.0 2010-11-19
DE102010044191 2010-11-19
DE102011086530.6 2011-11-17
DE102011086530A DE102011086530A1 (de) 2010-11-19 2011-11-17 Mikroprozessorsystem mit fehlertoleranter Architektur

Publications (1)

Publication Number Publication Date
WO2012066108A1 true WO2012066108A1 (de) 2012-05-24

Family

ID=46021502

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/070414 WO2012066108A1 (de) 2010-11-19 2011-11-18 Mikroprozessorsystem mit fehlertoleranter architektur

Country Status (6)

Country Link
US (1) US20130268798A1 (de)
EP (1) EP2641176B1 (de)
KR (1) KR20130119452A (de)
CN (1) CN103262045B (de)
DE (1) DE102011086530A1 (de)
WO (1) WO2012066108A1 (de)

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011084534A1 (de) * 2010-10-18 2012-04-19 Continental Teves Ag & Co. Ohg Fehlersichere Parkbremse für Kraftfahrzeuge
DE102012218363A1 (de) * 2012-10-09 2014-04-10 Continental Automotive Gmbh Verfahren zur Steuerung eines getrennten Ablaufs von verknüpften Programmblöcken und Steuergerät
EP2813949B1 (de) * 2013-06-11 2019-08-07 ABB Schweiz AG Mehrkernprozessorfehlererkennung für sicherheitskritische softwareanwendungen
DE102013218814A1 (de) * 2013-09-19 2015-03-19 Siemens Aktiengesellschaft Verfahren zum Betreiben eines sicherheitskritischen Systems
DE102014201682A1 (de) * 2014-01-30 2015-07-30 Robert Bosch Gmbh Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem
DE102014004110A1 (de) 2014-03-21 2015-09-24 Wabco Gmbh Verfahren zum Betrieb eines autonom arbeitenden Fahrsicherheits- oder Fahrerassistenzsystems eines Kraftfahrzeugs
US9410554B2 (en) * 2014-04-04 2016-08-09 Solar Turbines Incorporated Controlling a gas compressor having multiple magnetic bearings
DE102014212384A1 (de) * 2014-06-27 2015-12-31 Robert Bosch Gmbh Vorrichtung und Verfahren zum Betreiben eines Fahrzeugs
US9956973B2 (en) * 2014-07-07 2018-05-01 Westinghouse Air Brake Technologies Corporation System, method, and apparatus for generating vital messages on an on-board system of a vehicle
US10063370B2 (en) 2014-09-11 2018-08-28 Infineon Technologies Ag Method and device for checking an identifier
US9699184B2 (en) * 2014-09-11 2017-07-04 Infineon Technologies Ag Method and device for processing data
DE102014219286A1 (de) 2014-09-24 2016-03-24 Continental Automotive Gmbh Steuergerät und Verfahren zur Absicherung von Daten
US9582376B2 (en) 2014-11-14 2017-02-28 Invensys Systems, Inc. Unified communications module (UCM)
DE102015204337A1 (de) 2015-03-11 2016-09-15 Siemens Aktiengesellschaft Sicherheitsrelevantes Computersystem
US9694765B2 (en) * 2015-04-20 2017-07-04 Hitachi, Ltd. Control system for an automotive vehicle
DE102015216086A1 (de) * 2015-08-24 2017-03-02 Robert Bosch Gmbh Verfahren und Vorrichtung zum Überwachen eines Zustandes einer elektronischen Schaltungseinheit eines Fahrzeugs
US9672095B2 (en) 2015-09-21 2017-06-06 Nxp Usa, Inc. Safety level specific error response scheme for mixed criticality systems
DE102015218898A1 (de) * 2015-09-30 2017-03-30 Robert Bosch Gmbh Verfahren zur redundanten Verarbeitung von Daten
DE112015007095B4 (de) * 2015-12-03 2018-11-22 Mitsubishi Electric Corporation Multiplexsystem
GB2545897B (en) * 2015-12-21 2018-02-07 Advanced Risc Mach Ltd Asymmetric coherency protocol
US10037016B2 (en) * 2016-03-23 2018-07-31 GM Global Technology Operations LLC Hybrid dual-duplex fail-operational pattern and generalization to arbitrary number of failures
US9996431B2 (en) * 2016-03-23 2018-06-12 GM Global Technology Operations LLC Architecture and apparatus for advanced arbitration in embedded controls
US10042693B2 (en) * 2016-07-12 2018-08-07 Infineon Technologies Ag Diverse integrated processing using processors and diverse firmware
EP3279830B1 (de) * 2016-08-02 2020-10-28 Veoneer Sweden AB Sichtsystem und -verfahren für ein kraftfahrzeug
US10102085B2 (en) * 2016-08-25 2018-10-16 GM Global Technology Operations LLC Coordinated multi-mode allocation and runtime switching for systems with dynamic fault-tolerance requirements
WO2018128204A1 (ko) * 2017-01-06 2018-07-12 주식회사 알티스트 파티셔닝 기술을 이용하여 lsm 및 dpm을 동시에 사용할 수 있는 멀티코어 시스템
DE102017201032A1 (de) 2017-01-23 2018-05-03 Zf Friedrichshafen Ag Redundante Prozessorarchitektur
CN110799404A (zh) * 2017-04-17 2020-02-14 移动眼视力科技有限公司 包括驾驶相关系统的安全系统
US11214273B2 (en) * 2017-06-23 2022-01-04 Nvidia Corporation Method of using a single controller (ECU) for a fault-tolerant/fail-operational self-driving system
US10496398B2 (en) * 2017-07-25 2019-12-03 Aurora Labs Ltd. Hot updates to ECU software using tool chain
US10800264B2 (en) 2017-09-15 2020-10-13 Nio Usa, Inc. System and method for providing ASIL D fail operational power systems in automated vehicle applications
US10857889B2 (en) * 2017-10-04 2020-12-08 Nio Usa, Inc. Highly-integrated fail operational e-powertrain for autonomous driving application
DE102017218643A1 (de) 2017-10-19 2019-04-25 Volkswagen Aktiengesellschaft Funktionsmodul, Steuereinheit für ein Betriebsassistenzsystem und Arbeitsvorrichtung
KR102482143B1 (ko) * 2018-01-30 2022-12-29 에이치엘만도 주식회사 Ecu 및 ecu 동작 방법
CN108920409B (zh) * 2018-06-22 2022-09-02 阜阳师范学院 一种实现容错功能的异构多核处理器组织结构
US10853180B2 (en) * 2018-10-09 2020-12-01 EMC IP Holding Company LLC Automatically setting a dynamic restore policy in a native cloud environment
US10936444B2 (en) 2018-10-26 2021-03-02 EMC IP Holding Company LLC Smart dynamic restore for Kubernetes based applications
US11176395B2 (en) 2018-11-30 2021-11-16 Electronics And Telecommunications Research Institute Image recognition processor including functional safety processor core and operation method thereof
US10831628B2 (en) 2018-12-12 2020-11-10 Intel Corporation Hardware lockstep checking within a fault detection interval in a system on chip
FR3096326B1 (fr) * 2019-05-23 2022-10-28 Safran Landing Systems Système de freinage d’aéronef avec dispositifs de commande dissimilaires et module logiciel utilisé en cas de défaillance
IT201900018362A1 (it) * 2019-10-10 2021-04-10 Texa Spa Metodo e sistema di controllo di almeno due motori elettrici di trazione di un veicolo
DE102019218718B4 (de) * 2019-12-02 2023-11-16 Volkswagen Aktiengesellschaft Steuerungssystem zur Steuerung eines Betriebs eines selbstfahrenden Fahrzeugs sowie Kraftfahrzeug
CA3157095A1 (en) 2019-12-09 2021-06-17 Alon Green Method and system for high integrity can bus traffic supervision in safety critical application
DE102020200144A1 (de) * 2020-01-08 2021-07-08 Zf Friedrichshafen Ag Emuliertes redundantes Regelsystem
DE102020200141A1 (de) * 2020-01-08 2021-07-08 Zf Friedrichshafen Ag Fehlertolerantes Regelsystem
CN112180712A (zh) * 2020-09-27 2021-01-05 四川九洲空管科技有限责任公司 一种综合监视系统
CN117891515A (zh) * 2022-10-08 2024-04-16 深圳市中兴微电子技术有限公司 智能座舱的实现方法、智能座舱、计算机可读介质
CN117573609B (zh) * 2024-01-16 2024-05-03 宁波中控微电子有限公司 一种具有冗余功能的片上系统及其控制方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5551047A (en) * 1993-01-28 1996-08-27 The Regents Of The Univeristy Of California Method for distributed redundant execution of program modules
US6615366B1 (en) * 1999-12-21 2003-09-02 Intel Corporation Microprocessor with dual execution core operable in high reliability mode
WO2008146091A1 (en) * 2007-05-25 2008-12-04 Freescale Semiconductor, Inc. Data processing system, data processing method, and apparatus
US20100262971A1 (en) * 2008-07-22 2010-10-14 Toyota Jidosha Kabushiki Kaisha Multi core system, vehicular electronic control unit, and task switching method

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4341082A1 (de) * 1993-12-02 1995-06-08 Teves Gmbh Alfred Schaltungsanordnung für sicherheitskritische Regelungssysteme
US7085959B2 (en) * 2002-07-03 2006-08-01 Hewlett-Packard Development Company, L.P. Method and apparatus for recovery from loss of lock step
US7328371B1 (en) * 2004-10-15 2008-02-05 Advanced Micro Devices, Inc. Core redundancy in a chip multiprocessor for highly reliable systems
US7366948B2 (en) * 2004-10-25 2008-04-29 Hewlett-Packard Development Company, L.P. System and method for maintaining in a multi-processor system a spare processor that is in lockstep for use in recovering from loss of lockstep for another processor
US7502958B2 (en) * 2004-10-25 2009-03-10 Hewlett-Packard Development Company, L.P. System and method for providing firmware recoverable lockstep protection
KR20070083760A (ko) * 2004-10-25 2007-08-24 로베르트 보쉬 게엠베하 적어도 2개의 실행 유닛을 구비한 컴퓨터 시스템에서전환을 위한 방법 및 장치
DE102005037230A1 (de) * 2005-08-08 2007-02-15 Robert Bosch Gmbh Verfahren und Vorrichtung zur Überwachung von Funktionen eines Rechnersystems
CN101243402B (zh) * 2005-08-11 2011-08-31 大陆-特韦斯贸易合伙股份公司及两合公司 用于控制或调节至少部分安全关键处理的微处理器系统
US8935569B2 (en) * 2010-03-23 2015-01-13 Continental Teves Ag & Co. Ohg Control computer system, method for controlling a control computer system, and use of a control computer system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5551047A (en) * 1993-01-28 1996-08-27 The Regents Of The Univeristy Of California Method for distributed redundant execution of program modules
US6615366B1 (en) * 1999-12-21 2003-09-02 Intel Corporation Microprocessor with dual execution core operable in high reliability mode
WO2008146091A1 (en) * 2007-05-25 2008-12-04 Freescale Semiconductor, Inc. Data processing system, data processing method, and apparatus
US20100262971A1 (en) * 2008-07-22 2010-10-14 Toyota Jidosha Kabushiki Kaisha Multi core system, vehicular electronic control unit, and task switching method

Also Published As

Publication number Publication date
DE102011086530A1 (de) 2012-05-24
EP2641176B1 (de) 2015-01-07
KR20130119452A (ko) 2013-10-31
CN103262045B (zh) 2015-06-17
EP2641176A1 (de) 2013-09-25
CN103262045A (zh) 2013-08-21
US20130268798A1 (en) 2013-10-10

Similar Documents

Publication Publication Date Title
EP2641176B1 (de) Mikroprozessorsystem mit fehlertoleranter architektur
EP2550599B1 (de) Kontrollrechnersystem, verfahren zur steuerung eines kontrollrechnersystems, sowie verwendung eines kontrollrechnersystems
DE60019038T2 (de) Intelligente Fehlerverwaltung
EP1917592B1 (de) Rechnersystems mit wenigstens zwei ausführungseinheiten und einer vergleichseinheit sowie verfahren zu dessen steuerung
DE102017106087A1 (de) Fehlertoleranz-muster und schaltprotokoll für mehrere hot- und cold-standby-redundanzen
EP2513796B1 (de) Verfahren zum betreiben einer recheneinheit
DE112016004678T5 (de) Verfahren zum Ausführen von Programmen in einem elektronischen System für Anwendungen mit funktionaler Sicherheit umfassend mehrere Prozessoren, entsprechendes System und Computerprogrammprodukt
DE102017106086A1 (de) Hybrid-dual-duplex fail-betriebsmuster und verallgemeinerung einer beliebigen anzahl an ausfällen
DE102008004205A1 (de) Schaltungsanordnung und Verfahren zur Fehlerbehandlung in Echtzeitsystemen
EP3841438B1 (de) Automatisierungssystem zur überwachung eines sicherheitskritischen prozesses
DE102015202326A1 (de) Verfahren zum Betreiben einer Datenverarbeitungseinheit eines Fahrerassistenzsystems und Datenverarbeitungseinheit
DE102011007467A1 (de) Mehrkernige integrierte Mikroprozessorschaltung mit Prüfeinrichtung, Prüfverfahren und Verwendung
DE102008004206A1 (de) Anordnung und Verfahren zur Fehlererkennung und -behandlung in einem Steuergerät in einem Kraftfahrzeug
EP2494488A1 (de) Verfahren zum ausführen von sicherheits-relevanten und nicht-sicherheits-relevanten softwarekomponenten auf einer hardwareplattform
DE102021202935A1 (de) Verfahren und Vorrichtung zum Steuern einer Fahrfunktion
DE69911255T2 (de) Mikroprozessormodul mit abstimmungseinrichtung zur rückstellung und verfahren dazu
DE102004051991A1 (de) Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms
DE102017219195B4 (de) Verfahren zum gewährleisten eines betriebs eines rechners
WO2008128710A1 (de) Steuervorrichtung für fahrzeuge
WO2007017372A1 (de) Verfahren und vorrichtung zur steuerung eines rechnersystems mit wenigstens zwei ausführungseinheiten
WO2023242154A1 (de) Verfahren zum überprüfen eines mehrere einzelkomponenten aufweisenden systems zum gemeinsamen durchführen einer funktion durch die mehreren einzelkomponenten
DE102016217762A1 (de) Überwachung von sicherheitsrelevanten Funktionen durch eine nicht sichere Recheneinheit
DE102018120344A1 (de) Automatisierungssystem zur Überwachung eines sicherheitskritischen Prozesses
EP2662773B1 (de) Redundantes Mehrprozessorsystem und zugehöriges Verfahren
WO2022268270A1 (de) Steuereinrichtung sowie assistenzsystem für ein fahrzeug

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011785406

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20137015830

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 13988176

Country of ref document: US