DE102004028796B3 - Kontrollerbaustein - Google Patents

Kontrollerbaustein Download PDF

Info

Publication number
DE102004028796B3
DE102004028796B3 DE200410028796 DE102004028796A DE102004028796B3 DE 102004028796 B3 DE102004028796 B3 DE 102004028796B3 DE 200410028796 DE200410028796 DE 200410028796 DE 102004028796 A DE102004028796 A DE 102004028796A DE 102004028796 B3 DE102004028796 B3 DE 102004028796B3
Authority
DE
Germany
Prior art keywords
cpu
control module
module according
administrative unit
interrupt
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE200410028796
Other languages
English (en)
Inventor
Antonio Romero-Lobato
Stefan Selmikeit
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Continental Automotive GmbH
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE200410028796 priority Critical patent/DE102004028796B3/de
Application granted granted Critical
Publication of DE102004028796B3 publication Critical patent/DE102004028796B3/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

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/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy
    • 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/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0715Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
    • 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/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865Monitoring of software
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/88Monitoring involving counting

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Die Erfindung betrifft einen auf einem monolithischen Siliziumplättchen integrierten Kontrollerbaustein, mit einer CPU, einem Programmspeicher, einem Arbeitsspeicher, der dazugehörigen Kontrollerperipherie, wobei der Kontrollerbaustein von einem Betriebssystem oder einem anderen Programmabschnitt mit Systemverwaltungsaufgaben verwaltet wird und ein Anwendungsprogramm verarbeitet und wobei das System aus Kontrollerbaustein und Programmen als besonders stabil arbeitendes System ausgebildet ist. Um einen Kontrollerbaustein anzugeben, der eine schnelle und sichere Analyse, Verwaltung und Beobachtung von Tasks und Interrupts ermöglicht, ohne die Rechenleistung der CPU durch diese Aufgaben zu reduzieren, ist auf dem Kontrollerbaustein eine skalierbare Verwaltungseinheit integriert, welche zur selbständigen Verwaltung einer Vielzahl in sich geschlossener Programmabschnitte als beobachtendes Element ausgebildet ist, wobei die verwalteten und beobachteten Programmabschnitte unverändert erhalten bleiben.

Description

  • Die Erfindung bezieht sich auf einen Kontrollerbaustein zur Steuerung sicherheitsrelevanter Systeme, insbesondere in einem Kraftfahrzeug, mit einer CPU, einem Programmspeicher und einem Arbeitsspeicher, wobei die CPU Programmabschnitte von Anwendungsprogrammen aufruft und wobei analysiert wird, ob die Programmabschnitte Fehler verursachen.
  • Derartige Kontrollerbausteine sind bekannt und werden in vielen technischen Bereichen eingesetzt. So offenbart die DE 41 11 072 C3 ein Verfahren zum Feststellen einer Störung in einem Mikrocomputersystem während einer Multitasking-Verarbeitung, wobei jede Task, bezeichnet als Aufgaben-Programm, selbst entscheidet, ob sie normal durchgeführt worden ist oder nicht. In Abhängigkeit von dieser Entscheidung wird ein Zähler inkrementiert und der erreichte Zählerstand wird mit einem erwarteten Zählerstand verglichen, wobei der erwartete Zählerstand auf den vorab bekannten Zeitaktivierungsintervallen basiert.
  • Die US 2003/0115506 A1 beschreibt einen Mikrocomputer, der einen Prozessor und einen Debug-Schaltkreis sowie einen Systembus zwischen Prozessor und Debug-Schaltkreis enthält. Weiterhin ist eine Kommunikationsverbindung zwischen Prozessor und Debug-Schaltkreis vorhanden und der Prozessor ist so konfiguriert, dass er den Zählerstand eines Programmzählers über diese Kommunikationsverbindung zum Debug-Schaltkreis überträgt. Auf diese Weise kann ein auf dem Prozessor ablaufendes Programm gedebuggt werden, ohne dass in die Speicherzugriffe oder die Abarbeitungs-Pipeline des Prozessors störend eingegriffen werden muss.
  • Auch in modernen Kraftfahrzeugen findet sich eine Vielzahl von Steuergeräten, die jeweils mindestens einen Kontrollerbaustein aufweisen. Diese Steuergeräte sind in der Regel an verschiedenen Stellen im Fahrzeug verteilt. Steuergeräte zur Kontrolle der Klimaanlage, des Kombiinstrumentes oder des Schließsystems finden sich zum Beispiel in der Instrumententafel, während zum Beispiel das Motorsteuergerät in Motorraum platziert ist. Komplexe Steuergeräte benötigen ein Betriebssystem und ein Anwendungsprogramm, um ihre Funktion erfüllen zu können. Leider sind diese Programme, und das gilt sowohl für das Betriebssystem als auch für die Anwendungsprogramme, in der Regel nicht vollkommen frei von Fehlern. Ein optimaler Fehlererkennungs- und Beseitigungsprozess ist sehr wichtig, um einen im Steuergerät zuverlässig arbeitenden Kontrollerbaustein zu erhalten. Von der CPU (Central Prozess Unit), die ein wesentlicher Bestandteil des Kontrollerbausteins ist, oft aufgerufene Programmabschnitte werden im Folgenden als Tasks bezeichnet. Die Tasks sollten möglichst effizient und ihre Code möglichst kein sein, damit die Rechenzeit der CPU nicht unnötig belegt wird. Neben den Tasks gibt es so genannte Interrupt Requests (ISR), kurz Interrupts, die die CPU in ihrer Arbeit unterbrechen, um wichtige Aufgaben mit einer höheren Priorität zu bearbeiten. Auch die Interrupts müssen verwaltet und beobachtet werden, um sicherzustellen, dass die Systemstabilität auch bei hoher Interruptbelastung erhalten bleibt.
  • Die Analyse der Tasks und Interrupts wird nach dem Stand der Technik mit einem an das Betriebssystem angehängten Verwal tungsprogramm bewältigt. Das Aufrufen dieses Verwaltungsprogramms und das Laden in die CPU benötigt jedoch auch eine nicht zu vernachlässigende CPU-Zeit und CPU-Leistung (teilweise 5-15%). Sehr kleine Tasks (Tasklänge von etwa 10 μsec) können auf diese Art kaum sinnvoll analysiert und verwaltet werden. Darüber hinaus belegt das an das Betriebssystem angehängte Verwaltungsprogramm wertvollen ROM- oder FLASH- Speicher auf dem Kontrollerbaustein. Bei der Verwendung der Methoden nach dem Stand der Technik, ergeben sich auch für die Analyse und Verwaltung der Interrupts die oben genannten Probleme.
  • Aufgabe der Erfindung ist es daher, eine schnelle und sichere Analyse, Verwaltung und Beobachtung von Tasks und Interrupts zu ermöglichen, ohne die Rechenleistung der CPU durch diese Aufgaben zu reduzieren.
  • Die Aufgabe wird gemäß Patentanspruch 1 gelöst.
  • Dies hat den Vorteil, dass zur Verwaltung der Tasks und Interrupts kein zusätzlicher Programmabschnitt in die CPU geladen werden muss und die Verwaltung der Tasks und Interrupts allein von der als Hardware-Makro auf dem Kontrollerbaustein angelegten Verwaltungseinheit ausgeführt wird. Das Betriebssystem ist damit frei von einem Verwaltungsprogramm für die Task- und Interruptanalyse. Wertvolle Teile des Programmspeichers (ROM-/FLASH-Speicher) können durch andere Teile des Betriebssystems genutzt oder ganz eingespart werden. Die Tasks und Interrupts können sehr schnell analysiert und verwaltet werden, was einen so genannten real time Einsatz des Kontrollerbausteins ermöglicht, der zum Beispiel beim Einsatz des Kontrollerbausteins im Kraftfahrzeug benötigt wird. Durch die Analyse und Verwaltung der Tasks und Interrupts mit der Verwaltungseinheit, wird die stabile Funktion des Steuergerätes sichergestellt. Fehler verursachende Tasks werden schnell erkannt und eine Fehlerbehandlung kann durch das Betriebssystem eingeleitet werden.
  • Gemäß der Erfindung wird die zeitliche Verweildauer einzelner Programmabschnitte in der CPU mit einer bis zu einer bestimmten Grenze frei konfigurierbaren Genauigkeit von der Verwaltungseinheit erfasst. Durch die zeitliche Vermessung der Programmabschnitte (Tasks und/oder Interrupts) ist leicht festzustellen, ob ein Programmabschnitt die CPU ungewöhnlich lange beansprucht. Die Bearbeitung derartiger Programmabschnitte kann dann beendet werden, um die CPU für andere Tasks freizuhalten. Hierdurch wird das System aus CPU und Programm nicht instabil, wenn ein fehlerhafter Programmabschnitt bearbeitet wurde.
  • Bei einer Weiterbildung wird die Anzahl der Aufrufe der einzelnen Programmabschnitte durch die CPU von der Verwaltungs einheit genau erfasst. Dies hat den Vorteil, dass Programmabschnitte, die ungewöhnlich häufig aufgerufen werden und dadurch die CPU übermäßig auslasten, erkannt und gegebenenfalls vom Betriebssystem beendet werden können.
  • Bei einer Weiterbildung kann das Betriebssystem immer auf die Verwaltungseinheit zugreifen. Dies hat den Vorteil, dass das Betriebssystem die Kontrolle und die Verwaltung der Tasks und Interrupts übernehmen kann, ohne einen an das Betriebssystem angehängten Programmabschnitt in die CPU laden zu müsse.
  • Gemäß der Erfindung ist für jeden Taskkanal die zeitliche Auflösung frei konfigurierbar. Damit kann die zeitliche Auflösung der Verwaltungseinheit der Tasklänge angepasst werden. Bei sehr langen Tasks kann mit einer geringeren zeitlichen Auflösung gemessen werden, ohne das Ergebnis unakzeptabel zu verfälschen. Bei einer sehr kurzen Task hingegen kann eine hohe zeitliche Auflösung gewählt werden, womit auch diese Task noch genau beobachtet werden kann. Auch dies dient der optimalen Nutzung der Verwaltungseinheit. Aus denselben Gründen ist es vorteilhaft, wenn für jeden Interruptkanal die zeitliche Auflösung frei konfigurierbar ist.
  • Die Erfindung lässt zahlreiche Ausführungsformen zu. Eine davon soll anhand der in den Zeichnungen dargestellten Figuren erläutert werden. Diese zeigen in:
  • 1: ein elektronisches Bauelement,
  • 2: einen Ausschnitt des Kontrollerbausteins,
  • 3: den Aufbau der skalierbaren Verwaltungseinheit,
  • 4: den Bereich zur Task-Analyse,
  • 5: den Bereich zur Interruptanalyse,
  • 6: ein typisches Zeitdiagramm.
  • 1 zeigt ein elektronisches Bauelement 1 mit einem Leistungshalbleiter 2, der in erster Linie zur elektrischen Versorgung des Kontrollerbausteins 5 bestimmt ist und die vom Kontrollerbaustein 5 erzeugten logischen Signale verstärkt und über eine Pin 4 an andere elektronische Bauelemente weitergibt. Hierzu ist der Leistungshalbleiter 2 über Verbindungsdrähte 3 mit dem Kontrollerbaustein 5 elektrisch verbunden. Auch die elektrische Anbindung des Leistungshalbleiters 2 an die Pins 4 erfolgt mit Verbindungsdrähten 3.
  • Der Kontrollerbaustein 5 umfasst eine Central Process Unit (CPU) 6, einen Programmspeicher 7, der zum Beispiel als Read Only Memory (ROM) oder Flash-Speicher ausgebildet sein kann, ein Random Access Memory (RAM) 8 und eine Kontroller Periphery 9. In der Kontroller Periphery 9 befinden sich beispielsweise der Interruptkontroller, ein Clock-System, eine Resetlogik und ein Watchdog. Darüber hinaus ist auf dem Kontrollerbaustein 5 eine skalierbare Verwaltungseinheit 10 angeordnet, die in den nachfolgenden Figuren ausführlich beschrieben wird.
  • 2 zeigt einen Ausschnitt des Kontrollerbausteins 5, auf dem die skalierbare Verwaltungseinheit 10, eine dazugehörige Interfacelogik 11 und die notwendige Supplylogik 12 angeordnet sind. Die Supplylogik 12 versorgt die skalierbare Verwaltungseinheit 10 und die Interfacelogik 11 mit elektrischer Energie. Dazu wird die Supplylogik 12 mit der Versorgungsspannung VCC und dem Ground GND verbunden. Darüber hinaus wird der Supplylogik 12 ein Enable-Signal zugeführt, das die Supplylogik 12 entweder einschaltet und damit die skalierbare Verwaltungseinheit 10 und die Interfacelogik 11 in Betrieb setzt beziehungsweise die Supplylogik 12 ausschaltet, womit auch die Interfacelogik 11 und die skalierbare Verwaltungseinheit 10 ausgeschaltet sind. Der Interfacelogik 11 werden die Signale Chipselect CS, Read/Write RD-WR und Bite high enable BHE zugeführt. Diese drei Signale werden über den Systemkontroll-Bus an die Interfacelogik 11 geliefert. Das Signal Chipselect CS spricht die Interfacelogik 11 an und wählt diesen Baustein aus. Wenn die Interfacelogik 11 mit elektrischer Spannung versorgt wird, wobei die Supplylogik 12 mit dem Enable-Signal eingeschaltet sein muss, können Daten in die Interfacelogik 11 eingeschrieben beziehungsweise aus dieser herausgelesen werden. Ob Daten eingeschrieben oder he rausgelesen werden, wird durch das Signal Read/Write RD-WR bestimmt, welches entweder das Schreiben oder das Lesen zulässt. Über den Adress-Bus ADD wird die Interfacelogik 11 adressiert, und über den Daten-Bus DATA können 8 Bit beziehungsweise 16 Bit breite Signale in die Interfacelogik 11 eingeschrieben oder aus dieser ausgelesen werden. Die vorgenannten Signale werden durch das Signal Clock CLK synchronisiert, das der Interfacelogik 11 zugeführt wird. Erzeugen kann die Interfacelogik 11 ein Interruptsignal INT und mit einem Reset-Signal können sämtliche Daten in der Interfacelogik 11 zurückgesetzt werden.
  • Die Interfacelogik 11 kommuniziert mit der skalierbaren Verwaltungseinheit 10, die durch die Supplylogik 12 ihrerseits mit elektrischer Leistung versorgt wird. In der skalierbaren Verwaltungseinheit 10 werden die Programmabschnitte (Tasks oder Interrupts) vermessen, überprüft und verwaltet. Hierzu ist die skalierbare Verwaltungseinheit 10 in zwei Bereiche unterteilt, was in 3 näher dargestellt wird.
  • 3 zeigt den Aufbau der skalierbaren Verwaltungseinheit 10 mit einem Clock-Divider 13, der beispielsweise vier Basisfrequenzen von 8 MHz 20, 4 MHz 21, 2 MHz 22 und 1 MHz 23 zur Verfügung stellt und einem Bereich 14 zur Task-Analyse, sowie einem Bereich 15 zur Interrupt-Analyse. Mit der skalierbaren Verwaltungseinheit 10 können in den jeweiligen Bereichen 14, 15 sowohl Tasks als auch Interrupts zeitlich exakt vermessen und die Häufigkeit ihres Auftretens festgehalten werden. Die Tasks und Interrupts können vom Betriebssystem zeitlich begrenzt werden, oder bei zu häufigem Aufruf vom System abgeschlossen werden. Jede der zur Verfügung gestellten Frequenzen von 8, 4, 2 oder 1 MHz kann ausgewählt werden zur Analyse von Tasks oder Interrupts.
  • Ein Prozess ist ein abgeschlossenes System aus einer Vielzahl von Tasks, zugeteiltem Speicherplatz und Schnittstellen zu anderen Prozessen. Die Anzahl der unterstützten Tasks innerhalb eines Prozesses hängt von der speziellen Anwendung ab. Die Analyse der Tasks erfolgt im Bereich 14 zur Task-Analyse, der in 4 genauer dargestellt ist.
  • Der in 4 dargestellte Bereich zur Task-Analyse 14 dient sowohl zur Fehlerbeseitigung im Entwicklungsprozess zur Erstellung einer Anwendungssoftware als auch zur Erkennung von Fehlfunktionen im System während des Betriebes. Hierzu umfasst der Bereich zur Task-Analyse 14 einen Clock-Divider 13, der an seinem Ausgang die Frequenzen 8 MHz 20, 4 MHz 21, 2 MHz 22 und 1 MHz 23 zur Verfügung stellt. Die erforderliche Frequenz wird von einem Multiplexer MUX ausgewählt und an das Controlregister 1 CTRL1 weitergegeben. Die ausgewählte Frequenz bestimmt das zeitliche Auflösungsvermögen der skalierbaren Verwaltungseinheit 10. Mit einer hohen Frequenz können auch Taks mit einer kurzen Laufzeit gut aufgelöst werden. Bei Tasks mit einer langen Laufzeit genügt die Auswahl einer niedrigen Frequenz.
  • Eine Interrupterkennung 16 gibt ihrerseits beim Auftreten eines Interruptsignals ein Signal an das Kontrollregister 1 CTRL1 weiter. Die Taskerkennung 17 lädt die anliegenden Tasks in die entsprechenden Zeitzähler 18 der Taskstatustafel 24. Über das erste Kontrollregister CTRL1 wird mit Hilfe des Zeitzählers 18 die Zeit vermessen, die die aktuelle Task in der CPU 6 benötigt, um bearbeitet zu werden. Der Zeitzähler 18 ist als 8, 16 oder 32 Bit-Zähler ausgebildet, mit dem eine zeitliche Auflösung von 125 nsec bis zu 1 μsec erreichbar ist. Die zeitliche Auflösung ist über den Multiplexer MUX einstellbar und damit als Registeroption angelegt.
  • Neben dem Zeitzähler 18 ist im Bereich zur Task-Analyse 14 der Ereigniszähler 19 ausgebildet. Während die in der Task-Statustafel 24 abgelegten Tasks zeitlich vom Zeitzähler 18 vermessen werden, wird im Ereigniszähler 19 die Häufigkeit der Aufrufe einer einzelnen Task registriert. Hierzu steht die Task-Statustafel 24 über das dritte Kontrollregister 3 CTRL3 mit dem Ereigniszähler 19 in Verbindung. Über die Kontrollregister CTRL 2 und CTRL4 können die Daten der in der Task-Statustafel 24 abgelegten Tasks gesichert werden und in die Backup-Taskregister 0 bis N eingeschrieben werden. Dies ermöglicht eine beliebige Erfassung der Taskaufrufe.
  • Die Taskstatustafel 24 enthält alle Informationen über die beobachtete Tasks, und wenn im angehängten Zeitzähler 18 oder im entsprechenden Ergebniszähler 19 ein bestimmter oberer Wert für die Länge oder die Häufigkeit der aufgerufenen Tasks überschritten wird, kann sowohl vom Zeitzähler 18 als auch vom Ereigniszähler 19 ein Interruptsignal an die CPU 6 gesendet werden, wodurch die zulange währende oder zu häufig aufgerufene Task von der Bearbeitung in der CPU 6 ausgeschlossen werden kann. Die Ausschlussentscheidung trifft das Betriebssystem. Durch die permanente Zeitanalyse und Häufigkeitsanalyse der aufgerufenen Tasks ist eine sehr effiziente Überwachung der Applikationssoftware möglich, und die CPU 6 kann in keine Instabilität laufen, da zulange währende oder zu häufig aufgerufene Tasks von der Bearbeitung in der CPU 6 ausgeschlossen werden.
  • In 5 ist der Bereich zur Interruptanalyse 15 dargestellt. Auch hier findet sich der Clock-Divider 13, der die Frequenzen 8 MHz 20, 4 MHz 21, 2 MHz 22 und 1 MHz 23 zur Verfügung stellt. Eine dieser vier Frequenzen wird vom Multiplexer MUX ausgewählt und an das erste Kontrollregister CTRL 1 weitergeleitet. Auch die Interrupterkennung 16 leitet ihr Signal an das erste Kontrollregister CTRL 1 weiter. Darüber hinaus ist ein Bereich zur Interrupterkennung 17 angelegt, der die Interrupts in die Interrupt-Statustafel 25 lädt.
  • Auch im Bereich zur Interruptanalyse 15 findet sich ein Zeitzähler 18 und ein Ereigniszähler 19. Der Zeitzähler 18 ist auch als 8, 16 oder 32 Bit-Zähler ausgelegt, und er kann mit einer Auflösung von 125 nsec bis zu 1 μsec die Bearbeitungszeit des Interrupts in der CPU 6 vermessen. Die Häufigkeit, mit der ein Interrupt aufgerufen wird, wird im Ereigniszähler 19 auf dem Bereich zur Interruptanalyse 15 festgestellt. Über die beiden Kontrollregister CTRL 2 und CTRL 4 kann die Datensicherung der Interrupts in den Backup-Registern BACKUP-ISR0 bis BACKUP-ISRN vorgenommen werden.
  • Wird über den Zeitzähler 18 ein Interrupt festgestellt, der die CPU 6 zulange belegt, so kann ein weiteres Interruptsignal INT1 generiert werden, welches die CPU 6 veranlasst, das anliegende Interruptsignal ISRX abzuschließen und nicht weiter zu bearbeiten. Auch wenn ein Interrupt ISRX zu häufig aufgerufen wird, kann über den Ereigniszähler 19 ein weiteres Interruptsignal INT2 generiert werden. Durch diese Interruptanalyse im Bereich 15 zur Interruptanalyse wird die CPU 6 vor zulange währenden oder zu häufig aufgerufenen Interruptrequest ISRX geschützt, und eine Instabilität des Datenverarbeitungssystems wird wirkungsvoll verhindert.
  • In 6 ist ein typisches Zeitdiagramm dargestellt, in dem die zeitliche Belegung der CPU 6 beschrieben wird. Auf der Zeitachse t ist die CPU-Zeit angegeben, die mit verschiedenen Tasks T1 bis T3 und Abläufen aus dem Betriebssystem OS belegt ist. Zunächst belegt das Betriebssystem OS die Zeit von t0 bis t1, wonach die Task T1 von t1 bis t2 abgearbeitet wird. Nun greift das Betriebssystem OS erneut ein und belegt die CPU 6 von t2 bis t3. Eine zweite Task T2 belegt so dann die CPU 6 von t3 bis t4, woraufhin wieder das Betriebssystem OS die CPU 6 belegt. Innerhalb dieser CPU-Belegungszeit durch das Betriebssystem OS wird ein Interrupt ISR1 generiert, der zum Zeitpunkt tISR1 = t5 das Betriebssystem OS unterbricht und von t5 bis t6 die CPU 6 belegt, woraufhin nach Beendigung des Interrupts ISR1 die CPU 6 erneut vom Betriebssystem OS in der Zeit von t6 bis t7 belegt wird. Zum Zeitpunkt t7 arbeitet die CPU wieder für die Task T1, woraufhin zwischen t8 und t9 das Betriebssystem OS die CPU 6 belegt und von t9 bis t10 wieder die Task T1 bearbeitet wird.
  • Die CPU 6 hat in diesem Beispiel von der Zeit t0 bis t10 gearbeitet, wobei die Task T1 dreimal aufgerufen wurde und die CPU-Zeit t(T1) = (t2 – t1) + (t8 – t7) + (t10 – t9) belegt hat. Sowohl die Häufigkeit der Aufrufe der Task T1 als auch die von ihr benötigte CPU-Zeit T(t1) wird vom Bereich zur Taskanalyse 14 registriert. Sollten diese Werte eine bestimmte vorgegebene Grenze überschreiten, wird die Task T1 von der weiteren Bearbeitung in der CPU 6 ausgeschlossen.
  • Gerade fehlerhafte Tasks benötigen übergebührlich viel CPU-Zeit und können sehr oft aufgerufen werden. Durch die Taskanalyse im Bereich zur Taskanalyse 14 ist es möglich, diese fehlerhaften Tasks zu erkennen und zu eliminieren. Alle anderen fehlerfrei arbeitenden Tasks können dann die CPU 6 weiterhin belegen, ohne dass das Gesamtsystem instabil wird. Eine derartige Systemanalyse ist besonders bei signalverarbeitenden Systemen von Vorteil, die sicherheitsrelevante Prozesse bearbeiten. In Kraftfahrzeugen zum Beispiel ist es wichtig, dass sicherheitsrelevante Systeme wie zum Beispiel die Airbagsteuerung oder die ABS-Steuerung fehlerfrei und sicher arbeiten. Werden diese Systeme gleichzeitig von einer CPU gesteuert, die zum Beispiel auch die Klimaanlage des Fahrzeuges steuert, so muss gewährleistet sein, dass beim Ausfall von Prozessen innerhalb der Klimaanlagensteuerung ein fehlerfreies Funktionieren der Airbagsteuerung oder ABS-Steuerung gewährleistet ist. Dies wird durch den Einsatz der skalierbaren Verwaltungseinheit 10 auf dem Kontrollerbaustein 5 realisiert. Die CPU 6 wird durch die skalierbare Verwaltungseinheit 10 effektiv vor Systeminstabilität geschützt. Auch beim Versagen einer Softwareanwendung in der CPU 6 bleiben alle anderen Systeme voll funktionsfähig.

Claims (11)

  1. Kontrollerbaustein (5) zur Steuerung sicherheitsrelevanter Systeme, insbesondere in einem Kraftfahrzeug, mit einer CPU (6), einem Programmspeicher (7) und einem Arbeitsspeicher (8), wobei die CPU (6) Programmabschnitte (TASK0 bis TASKn) von Anwendungsprogrammen aufruft und wobei analysiert wird, ob die Programmabschnitte (TASK0 bis TASKn) Fehler verursachen, dadurch gekennzeichnet, dass auf dem Kontrollerbaustein (5) eine Verwaltungseinheit (10) integriert ist, welche die Analyse der Programmabschnitte (TASK0 bis TASKn) durchführt, indem sie die zeitliche Verweildauer der Programmabschnitte (TASK0 bis TASKn) in der CPU (6) mit einer bis zu einer bestimmten Grenze frei konfigurierbaren Genauigkeit erfasst.
  2. Kontrollerbaustein nach Anspruch 1, dadurch gekennzeichnet, dass das zeitliche Auflösungsvermögen der Verwaltungseinheit (10) von einer aus mehreren Frequenzen (20, 21, 22, 23) über einen Multiplexer (MUX) ausgewählten Frequenz bestimmt ist.
  3. Kontrollerbaustein nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass die Verwaltungseinheit (10) die Anzahl der Aufrufe der einzelnen Programmabschnitte (TASK0 bis TASKn) durch die CPU (6) erfasst.
  4. Kontrollerbaustein nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Verwaltungseinheit (10) beim Überschreiten eines oberen Wertes für die zeitliche Länge oder die Häufig keit der aufgerufenen Programmabschnitte (TASK0 bis TASKn) ein Interruptsignal (INT1, INT2) an die CPU (6) sendet.
  5. Kontrollerbaustein nach Anspruch 4, dadurch gekennzeichnet, dass ein auf dem Kontrollerbaustein (5) laufendes Betriebssystem entscheidet, ob ein zu lange währender oder zu häufig aufgerufener Programmabschnitt (TASK0 bis TASKn) von der Bearbeitung in der CPU (6) ausgeschlossen wird.
  6. Kontrollerbaustein nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die CPU (6) durch Interrupts (ISR0 bis ISRn) in ihrer Arbeit unterbrochen wird, um Aufgaben mit einer höheren Priorität zu bearbeiten, und dass die Verwaltungseinheit (10) eine Analyse der Interrupts (ISR0 bis ISRn) durchführt, indem sie die Bearbeitungszeit (6) der Interrupts (ISR0 bis ISRn) in der CPU (6) misst.
  7. Kontrollerbaustein nach Anspruch 6, dadurch gekennzeichnet, dass die Verwaltungseinheit (10) die Häufigkeit, mit der ein Interrupt (ISR0 bis ISRn) aufgerufen wird, feststellt.
  8. Kontrollerbaustein nach einem der vorhergehenden Ansprüche 6 oder 7, dadurch gekennzeichnet, dass die Verwaltungseinheit (10) bei der Feststellung, dass ein Interrupt (ISR0 bis ISRn) die CPU (6) zu lange belegt oder zu häufig aufgerufen wird, ein Interruptsignal (INT1, INT2) an die CPU (6) sendet.
  9. Kontrollerbaustein nach Anspruch 8, dadurch gekennzeichnet, dass die CPU (6) durch das Interruptsignal (INT1, INT2) veranlasst wird, den anliegenden Interrupt (ISR0 bis ISRn) nicht weiter zu bearbeiten.
  10. Kontrollerbaustein nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass auf dem Kontrollerbaustein (5) eine Interfacelogik (11) ausgebildet ist, die mit einem Systemkontroll-Bus, einem Adress-Bus (ADD) und einem Daten-Bus (DATA) des Kontrollerbausteins (5) verbunden ist, ein Interruptsignal (INT) erzeugen kann und mit der Verwaltungseinheit (10) kommuniziert.
  11. Kontrollerbaustein nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Betriebssystem immer auf die Verwaltungseinheit (10) zugreifen kann.
DE200410028796 2004-06-15 2004-06-15 Kontrollerbaustein Expired - Fee Related DE102004028796B3 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE200410028796 DE102004028796B3 (de) 2004-06-15 2004-06-15 Kontrollerbaustein

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE200410028796 DE102004028796B3 (de) 2004-06-15 2004-06-15 Kontrollerbaustein

Publications (1)

Publication Number Publication Date
DE102004028796B3 true DE102004028796B3 (de) 2006-01-19

Family

ID=35508226

Family Applications (1)

Application Number Title Priority Date Filing Date
DE200410028796 Expired - Fee Related DE102004028796B3 (de) 2004-06-15 2004-06-15 Kontrollerbaustein

Country Status (1)

Country Link
DE (1) DE102004028796B3 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4111072C3 (de) * 1990-04-05 1996-09-26 Zexel Corp Verfahren zum Feststellen einer Störung in einem Mikrocomputersystem
US20030115506A1 (en) * 1999-10-01 2003-06-19 Edwards David Alan Apparatus and method for shadowing processor information

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4111072C3 (de) * 1990-04-05 1996-09-26 Zexel Corp Verfahren zum Feststellen einer Störung in einem Mikrocomputersystem
US20030115506A1 (en) * 1999-10-01 2003-06-19 Edwards David Alan Apparatus and method for shadowing processor information

Similar Documents

Publication Publication Date Title
EP1027707B1 (de) Verfahren zur prüfung der busanschlüsse von beschreib- und lesbaren integrierten, elektronischen schaltkreisen, insbesondere von speicherbausteinen
EP0198935A1 (de) Elektrisch umprogrammierbarer Halbleiterspeicher mit Redundanz
EP1915631A1 (de) Verfahren und vorrichtung zur überprüfung eines ersten spannungswertes
EP0104635A2 (de) Verfahren und Anordnung zum Prüfen eines digitalen Rechners
EP0766092B1 (de) Testbare Schaltungsanordnung mit mehreren identischen Schaltungsblöcken
DE69030755T2 (de) Verfahren und Gerät zur Prüfung von Leiterplatten mit gesteuerter Rückspeisungsbelastung
DE102014208611A1 (de) Verfahren zur Diagnose eines Zustands in einem Fahrzeug und Diagnose-Testgerät
DE3702408A1 (de) Verfahren und pruefvorrichtung zum pruefen einer integrierten schaltungsanordnung
DE102012206870A1 (de) Verfahren und Vorrichtung zum Erkennen einer Manipulation an einer elektrischen Leitung
EP0843317A2 (de) Verfahren zum Testen eines in Zellenfelder unterteilten Speicherchips im laufenden Betrieb eines Rechners unter Einhaltung von Echtzeitbedingungen
DE102006007439B4 (de) Halbleitereinzelchip, System und Verfahren zum Testen von Halbleitern unter Verwendung von Einzelchips mit integrierten Schaltungen
DE69731053T2 (de) Prüfung von Schaltungen mit Schmitt-Eingängen
DE102004028796B3 (de) Kontrollerbaustein
DE60309157T2 (de) Speichersystem mit Fehlererkennungsvorrichtung
DE4321014B4 (de) Verfahren und Schaltungen zum Schutz von Eingängen von als integrierte Schaltungen vorliegenden Analogmultiplexern
DE102004043063B4 (de) Verfahren zum Betreiben eines Halbleiter-Bauelements mit einem Test-Modul
DE10303654A1 (de) Integrierte Halbleiterschaltung mit eingebauter Selbsttestfunktion und zugehöriges System
WO2020148324A1 (de) Vorrichtung und verfahren zur funktionsprüfung eines antennensystems zur fremdmetallerkennung
EP1224547B1 (de) Integrierter elektronischer baustein mit duplizierter kernlogik und hardware-fehlereinspeisung für prüfzwecke
DE102007026934A1 (de) System und Verfahren zur Ausfalldetektion eines Winkelsensors einer aktiven Frontlenkung
DE102019129305A1 (de) Schaltvorrichtung für ein Bremssystem für ein Fahrzeug, Bremssystem mit einer Schaltvorrichtung und Verfahren zum Betreiben einer Schaltvorrichtung
DE10335132B3 (de) Speicheranordnung eines Computersystems
EP3701276A1 (de) Integrierte schaltung und asic
EP1019824B1 (de) Verfahren zum erzeugen eines fehlerkennzeichnungssignals im datenbestand eines speichers und hierzu geeignete einrichtung
DE10112560A1 (de) Verfahren und Vorrichtung zum Prüfen von Schaltungsmodulen

Legal Events

Date Code Title Description
8100 Publication of the examined application without publication of unexamined application
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: CONTINENTAL AUTOMOTIVE GMBH, 30165 HANNOVER, DE

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20140101