DE112016004678T5

DE112016004678T5 - Verfahren zum Ausführen von Programmen in einem elektronischen System für Anwendungen mit funktionaler Sicherheit umfassend mehrere Prozessoren, entsprechendes System und Computerprogrammprodukt

Info

Publication number: DE112016004678T5
Application number: DE112016004678.2T
Authority: DE
Inventors: Riccardo Mariani
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2015-10-13
Filing date: 2016-10-12
Publication date: 2018-09-13
Also published as: US10761916B2; ITUB20154590A1; WO2017064623A1; US20180349259A1

Abstract

Verfahren zum Ausführen von Programmen (P) in einem elektronischen System für Anwendungen mit funktionaler Sicherheit, das ein Einzelprozessor- oder Multiprozessorverarbeitungssystem (10) und ein weiteres eigenständiges Steuermodul (15) umfasst, das Folgendes umfasst: Durchführen einer Zerlegung eines Programms (P), das eine Sicherheitsfunktion (SF) beinhaltet, die auf dem System (10) auszuführen ist, in mehrere parallele Unterprogramme (P1, ..., Pn); Zuweisen einer Ausführung jedes parallelen Unterprogramms (P1, ..., Pn) zu einem jeweiligen Verarbeitungsmodul (11) des Systems, insbesondere einem Prozessor (C1, ..., Cm) der Multiprozessorarchitektur (10) oder einer virtuellen Maschine (V1, ..., Vn), die einem der Prozessoren (C1, ..., Cm) zugeordnet ist; periodisches Ausführen in dem System (10) gemäß einer Zyklusfrequenz (f_cyc) des Programms (P) während Normalbetriebs des Systems (10), in Zusammenhang mit der Sicherheitsfunktion (SF), von Selbsttestvorgängen (A_stl, A_sys, A_chk), die jedem der Unterprogramme (P1, ..., Pn) und den entsprechenden Verarbeitungsmodulen (11), auf denen sie ausgeführt werden, zugeordnet sind, wobei die Selbsttestvorgänge (A_stl, A_sys, A_chk) Folgendes beinhalten: Diagnoseselbsttestvorgänge (A_stl), die Diagnoseselbsttests durchführen; Vorgänge (A_sys) eines Selbsttests von auf der Architektur (10) gemessenen Systemwerten; anwendungsbezogene Selbsttestvorgänge (A_chk), die Vorgänge eines Prüfens einer Ausführung von Anwendungsbedingungen (A_cou) und/oder einer Ausführung von LBISTs (Logic Built-in Self-Tests - Logischen integrierten Selbsttests) (A_bst), und umfassend: Erzeugen jeweiliger Selbsttestdaten (D_stl, D_sys, D_chk) entsprechend den Selbsttestvorgängen (A_stl, A_sys, A_chk) und Durchführen von Prüfvorgängen (51, 61) an den Selbsttestdaten (D_stl, D_sys, D_chk); kontinuierliches Austauschen der Selbsttestdaten (D_stl, D_sys, D_chk) über ein Protokoll (PL) von Nachrichten (MC) mit dem weiteren eigenständigen Steuermodul (15); Durchführen mindestens eines Teils der Prüfvorgänge (51, 61) in dem weiteren Steuermodul (15); und Ausführen des Vorgangs der Zerlegung des Programms (P) in mehrere parallele Unterprogramme (P1, ..., Pn) zum Erreichen eines Deckungsgradziels (A_stl, A_sys, A_chk) für jeden der Selbsttestvorgänge (A_stl, A_sys, A_chk), das einem jeweiligen Unterprogramm (P1,..., Pn) oder Verarbeitungsmodul (11) derart zugeordnet ist, dass ein gegebenes Ausfallwahrscheinlichkeitsziel (g12) eingehalten wird.

Description

Technisches Gebiet
Die vorliegende Beschreibung betrifft Techniken zum Ausführen von Programmen in Zusammenhang mit elektronischen Systemen für Anwendungen, in denen funktionale Sicherheit erforderlich ist. Das beschriebene elektronische System basiert auf einer Architektur umfassend einen einzelnen Prozessor (CPU) oder mehrere Prozessoren. Die beschriebenen Techniken stellen Folgendes bereit:

Ausführen einer Zerlegung des auszuführenden Programms über die Architektur in mehrere parallele Unterprogramme;
Zuweisen einer Ausführung jedes parallelen Unterprogramms zu einem jeweiligen Verarbeitungsmodul des Systems, insbesondere einem physischen Prozessor oder einer virtuellen Maschine, die einem der Prozessoren zugeordnet ist; und
periodisches Ausführen gemäß einer Zyklusfrequenz des Programms während Normalbetriebs der Architektur von Selbsttestvorgängen, die dazu ausgelegt sind, funktionale Sicherheitsziele zu erfüllen.
Verschiedene Ausführungsformen können für funktionale Sicherheit angewendet werden. Insbesondere finden verschiedene Ausführungsformen in elektronischen Systemen im Gebiet der Industrierobotik und Industriesteuerung sowie in dem technischen Gebiet von elektronischen Systemen für automobile Anwendungen zur Fahrerassistenz und zum teilweisen oder vollständig autonomen Fahren Anwendung.

Technologischer Hintergrund
Standards zu funktionaler Sicherheit wie z. B. IEC 61508, ISO 13849 und ISO 26262 beinhalten Anforderungen für die Erkennung potentiell gefährlicher Ausfälle bei integrierten elektronischen Systemen. Beispielsweise ist im Standard ISO 26262 eine der Anforderungen als „Probabilistic Metric for HW Random Failures (PMHF)“ (Probabilistische Metrik für zufällige Ausfälle der Hardware) definiert, welche für eine erste Annäherung für ein gegebenes Ausfallmodell F als das Produkt der Basisausfallwahrscheinlichkeit (λ), der Verteilung dieser Wahrscheinlichkeit im Ausfallmodell (AF), des Einerkomplements des Anteils der sicheren Ausfälle (Safe-Failure Fraction) (1-s) und des Einerkomplements des Diagnosedeckungsgrads nicht sicherer Ausfälle (1-k) definiert ist.
Mit „sicheren Ausfällen“ sind Ausfälle gemeint, die derart gestaltet sind, dass der Einsatzzweck des durch die elektronische Vorrichtung ausgeführten Programms nicht beeinflusst oder aber auf sichere Weise beeinflusst ist; d. h. der Einsatz endet mit einem bekannten Zustand, dem sogenannten „sicheren Zustand“, in dem die funktionale Sicherheit nicht gefährdet ist.
Prozessoren eines Einzelprozessor- oder Multiprozessorverarbeitungssystems gehören zu den kritischsten Elementen eines derartigen integrierten elektronischen Systems, und ihre Komplexität steigt mit den Fortschritten auf diesem Gebiet.
Im Hinblick auf die Prozessoren schlagen die zuvor erwähnten Standards (beispielsweise ISO 26262-5, Anhang D, Tabelle D.4) verschiedene mögliche Techniken zum Erhalten von Diagnosewerten eines Deckungsgrads von nicht sicheren Ausfällen vor, gekennzeichnet durch k, die so hoch wie möglich sind.
Die oben genannten Techniken finden verschiedene Implementierungen im Stand der Technik.
Architekturen, wie die in dem Patent Nr. US 6 233 702 oder in dem Patent Nr. US 7 472 051 beschriebenen, erfordern zwingend eine Modifikation der Hardware des Prozessors, um funktionale Sicherheit sicherzustellen, wie ein Implementieren einer vollständigen oder reduzierten Form von Redundanz des Prozessors.
Architekturen, wie die in dem Patent Nr. US 5 513 319 beschriebenen, sehen vor, dass ein eigenständiges Element (Watchdog) periodisch durch den Prozessor in voreingestellten Zeitintervallen abgefragt wird. Jedoch ist die funktionale Sicherheit, die dies sicherstellen kann, insoweit begrenzt, als dass nur ein kleiner Prozentsatz der Ausfälle des Prozessors mit einem derartigen Verfahren erkannt werden kann - im Wesentlichen diejenigen, die einen deutlichen Unterschied im Programmablauf verursachen.
Gegenstand und Kurzdarstellung
Die hierin beschriebenen Ausführungsformen dienen dem Zweck, die Möglichkeiten der zuvor diskutierten Verfahren nach dem Stand der Technik zu verbessern, insbesondere zu ermöglichen, einen hohen Diagnosedeckungsgrad bei komplexen Architekturen, wie denen von modernen Multiprozessoren, zu erreichen, und somit das Deckungsgradziel für den einzelnen Prozessor zu begrenzen und den Bedarf an Modifikationen der Hardware zu begrenzen oder zu eliminieren.
Verschiedene Ausführungsformen erreichen den oben genannten Zweck dank eines Verfahrens mit den in den nachfolgenden Ansprüchen genannten Merkmalen. Verschiedene Ausführungsformen können auch eine Architektur betreffen, da sie gleichermaßen ein Computerprogrammprodukt betreffen können, das in den Speicher mindestens eines Computers (z. B. eines Endgeräts in einem Netzwerk) geladen werden kann und Teile von Softwarecode umfasst, der zum Implementieren der Schritte des Verfahrens ausgelegt ist, wenn das Programm auf mindestens einem Computer ausgeführt wird. Wie hierin verwendet, ist das oben genannte Computerprogrammprodukt als äquivalent zu einem computerlesbaren Mittel mit Anweisungen zum Steuern des Computersystems, um die Ausführung des erfindungsgemäßen Verfahrens zu koordinieren, zu verstehen. Ein Verweis auf „mindestens einen Computer“ ist als Hervorheben der Möglichkeit eines Implementierens der vorliegenden Erfindung in einer modularen und/oder verteilten Form zu verstehen. Die Ansprüche bilden einen festen Bestandteil der hierin bereitgestellten technischen Lehren in Bezug auf die Erfindung.
Verschiedene Ausführungsformen können vorsehen, dass das Verfahren Selbsttestvorgänge beinhaltet, die Folgendes umfassen:

Diagnoseselbsttestvorgänge, d. h. Vorgänge, die Tests auf dem Prozessor ausführen und das Ergebnis mit in der Entwicklungsphase vorausberechneten Werten vergleichen;
Vorgänge zum Selbsttest von Systemwerten, die auf der Architektur gemessen werden, (rein beispielhaft die Spannung und Temperatur) und Vergleich des Ergebnisses mit erwarteten Referenzbereichen;
anwendungsbezogene Selbsttestvorgänge, die Selbsttestvorgänge umfassen, die eine periodische Ausführung in den mehreren parallelen Programmen von sogenannten „Anwendungsbedingungen“ (d. h. dedizierte Vorgänge beispielsweise zur Ablaufsteuerung und/oder zum Kapseln von Daten mit Schutzcodes und/oder zur Wiederholung spezieller Teile von Unterprogrammen) und/oder eine periodische Ausführung von LBIST-Schaltungen (Logic Built-in Self-Test - Logischer integrierter Selbsttest) beinhalten,
und die Folgendes umfassen:
- Erzeugen jeweiliger Selbsttestdaten entsprechend den Selbsttestvorgängen und Ausführen von Prüfvorgängen an den Selbsttestdaten;
- kontinuierliches Austauschen der Selbsttestdaten über ein Protokoll von Nachrichten mit einem weiteren eigenständigen Steuermodul;
- Durchführen zumindest eines Teils der Prüfvorgänge in dem weiteren eigenständigen Steuermodul; und
- Ausführen des Vorgangs der Zerlegung des Programms in mehrere parallele Unterprogramme zum Einhalten eines Ausfallwahrscheinlichkeitsziels, das eine Funktion eines Deckungsgradwerts, der durch die Diagnoseselbsttestvorgänge bestimmt ist, eines Deckungsgradwerts, der durch die Vorgänge des Selbsttests von auf der Architektur gemessenen Systemwerten bestimmt ist, und eines Deckungsgradwerts, der durch die anwendungsbezogenen Selbsttestvorgänge bestimmt ist, ist.

Die beschriebene Methode zur Zerlegung des Programms und die Aufteilung der Selbsttestvorgänge in die zuvor erwähnten drei separaten Vorgänge (Diagnoseselbsttestvorgänge, Selbsttest durch Überwachen der Systemwerte und anwendungsbezogener Selbsttest) ermöglicht eine Verbesserung gegenüber dem Stand der Technik; nämlich:

- eine Dreiteilung ermöglicht eine optimierte Verteilung der Ziele, d. h. durch Heruntersetzen des Ziels für die Vorgänge, die - für den bestimmten Systemtyp, für den das beschriebene Verfahren angewendet wird - zu ihrer Erreichung einen großen Entwicklungsaufwand oder Modifikationen der Hardware erfordern würden, und anstatt dessen ein Heraufsetzen des Ziels für die Vorgänge, die sich in diesem Rahmen als einfacher herausstellen;
- die Möglichkeit einer Durchführung eines Selbsttests der Programme in der Zielzeit unter Ausführung der Anwendungsbedingungen und/oder von LBISTs ermöglicht bei Systemen, in denen die Rechenressourcen bereits weitgehend ausgenutzt werden, ein Erreichen desselben Deckungsgradergebnisses, ohne die Rechenleistung des Systems weiter zu senken.

Figurenliste
Nachfolgend werden verschiedene Ausführungsformen rein beispielhaft unter Bezug auf die beigefügten Zeichnungen beschrieben, in denen:

- 1 ein Blockdiagramm einer Ausführungsform einer Multiprozessorarchitektur eines elektronischen Systems ist, das zum Implementieren des hierin beschriebenen Verfahrens ausgelegt ist;
- 2 ein Diagramm zeigt, das eine Sicherheitsfunktion darstellt, die durch das hierin beschriebene Verfahren verwendet wird;
- 3 ein Diagramm mit Softwareebenen der Multiprozessorarchitektur zeigt, die zum Implementieren des hierin beschriebenen Verfahrens ausgelegt ist;
- 4 und 5 Diagramme zeigen, die Pakete darstellen, die durch ein Kommunikationsprotokoll verwendet werden, das durch die Multiprozessorarchitektur implementiert wird;
- 6 ein Blockdiagramm eines Steuermoduls zeigt, das mit der Multiprozessorarchitektur zum Implementieren des hierin beschriebenen Verfahrens zusammenwirkt;
- 7 eine schematische Darstellung eines Testprogramms ist, das durch die hierin beschriebene Multiprozessorarchitektur ausgeführt wird;
- 8 ein Logikdiagramm zeigt, das ein Beispiel einer Logikimplementierung eines Zerlegungsvorgangs des hierin beschriebenen Verfahrens darstellt;
- 9 ein Prinzipdiagramm einer Implementierung des Systems auf einem SoC (System-on-Chip) mit einem symmetrischen Dual-Kern-Multiprozessor zeigt;
- 10 ein Prinzipdiagramm einer Implementierung des Systems auf zwei Komponenten, einem SoC und einem externen Gerät, zeigt;
- 11 ein schematisches Diagramm zeigt, das veranschaulicht, wie Selbsttestvorgänge gemäß dem hierin beschriebenen Verfahren funktionieren;
- 12 ein Logikdiagramm von Kombinationsmöglichkeiten der Selbsttestvorgänge zeigt;
- 13 ein Logikdiagramm der Verwendung von Selbsttestvorgängen in verschiedenen Anwendungskonfigurationen zeigt;
- 14 eine abweichende Ausführungsform des Schemas von Softwareebenen der Multiprozessorarchitektur zeigt, die zum Implementieren des hierin beschriebenen Verfahrens ausgelegt ist; und
- 15 eine weitere abweichende Ausführungsform des Schemas von Softwareebenen der Multiprozessorarchitektur zeigt, die zum Implementieren des hier beschriebenen Verfahrens ausgelegt ist.

Ausführliche Beschreibung
In der folgenden Beschreibung werden zahlreiche spezifische Details bereitgestellt, um ein bestmögliches Verständnis der Ausführungsformen zu ermöglichen, die beispielhaft bereitgestellt sind. Die Ausführungsformen können mit oder ohne spezifische Details oder auch mit anderen Verfahren, Komponenten, Materialien usw. implementiert sein. In anderen Fällen werden gut bekannte Strukturen, Materialien oder Vorgänge nicht im Detail dargestellt oder beschrieben, damit verschiedene Aspekte der Ausführungsformen nicht schwerer verständlich werden. Verweise in der vorliegenden Beschreibung auf „eine Ausführungsform“ bzw. „einer Ausführungsform“ bedeuten, dass eine bestimmte Struktur, eine bestimmte Eigenheit oder eine bestimmte Eigenschaft, die in Verbindung mit ihrer Implementierung beschrieben ist, in mindestens einer Ausführungsform enthalten ist. Daher beziehen sich Ausdrücke wie „in einer Ausführungsform“, die an verschiedenen Stellen der vorliegenden Beschreibung vorkommen können, nicht notwendigerweise auf die gleiche Ausführungsform. Weiterhin können die bestimmten Strukturen, Eigenheiten oder Eigenschaften in jeder geeigneten Weise in einer oder mehreren Ausführungsformen kombiniert werden.
Die verschiedenen Verweise sind hierin lediglich zur besseren Lesbarkeit bereitgestellt und bestimmen in keiner Weise den Schutzumfang oder die Bedeutung der Ausführungsformen.
1 zeigt eine Verarbeitungsarchitektur, die mit funktionaler Sicherheit eines integrierten elektronischen Systems für Anwendungen funktionaler Sicherheit bereitgestellt ist. Wie bereits erwähnt, kann das elektronische System beispielsweise ein elektronisches System für automobile Anwendungen zur Fahrerassistenz und zum teilweisen oder vollständig autonomen Fahren sein, das eine Verarbeitungsarchitektur umfasst, die in funktionaler Sicherheit betrieben wird.
Die oben genannte Architektur umfasst ein Multiprozessorverarbeitungssystem; insbesondere ist auf dem Multiprozessorverarbeitungssystem, das als Ganzes mit dem Bezugszeichen 10 bezeichnet ist, ein funktionales Sicherheitssystem implementiert, das auf der Bereitstellung einer Anzahl von Verarbeitungs- und Steuerkanälen basiert. Mit „Kanal“ ist im Zusammenhang mit Sicherheit und insbesondere mit IEC 61508 ein Element oder ein Satz von Elementen gemeint, das/der eigenständig eine sogenannte „Sicherheitsfunktion SF“ implementiert (siehe IEC 61508-4, 3.3.6). Dies kann beispielsweise ein Mikroprozessor, eine virtuelle Maschine oder aber ein beliebiges anderes Element sein.
Das Multiprozessorverarbeitungssystem 10 umfasst mehrere Prozessormodule 11. Die oben genannten Prozessormodule 11 umfassen hauptsächlich eigenständige CPUs (Central Processing Units), d. h. so genannte „Kerne“. Wie im Folgenden im Einzelnen beschrieben, kann sich in der vorliegenden Beschreibung ein Prozessormodul in einem Multikernsystem (oder auch in einem Einzelkernsystem) auch auf eine virtuelle Maschine beziehen, die von Virtualisierungssoftware auf einem der oben genannten Kerne erzeugt wird. Unter Bezugnahme auf die 1 und 3 ist somit hierin mit „Prozessormodul“ 11 einer von mehreren Kernen C1, ..., Cm des Multiprozessors 10 oder auch eine von mehreren virtuellen Maschinen V1, ..., Vn bezeichnet, die auf einem oder mehreren der oben genannten Kerne C1, ..., Cm implementiert ist.
Der Multiprozessor 10 kann architektonisch auf unterschiedliche Weise aufgebaut sein, einschließlich sowohl homogene Architekturen (d. h. solche, in denen die verschiedenen Verarbeitungskerne 11 gleich sind) als auch heterogene Architekturen (d. h. solche, in denen die Verarbeitungskerne 11 unterschiedlich sind) sowie Architekturen mit gemeinsamem Speicher oder Architekturen mit verteiltem Speicher, die durch Nachrichtenaustausch kommunizieren. Vom Standpunkt der physischen Implementierung aus sind mehrere Lösungen möglich, die von einem höheren Integrationsgrad, bei dem die Kerne 11 in ein und derselben integrierten Schaltung vorgesehen sind, bis hin zu einem niedrigeren Integrationsgrad reichen, bei dem die Kerne 11 des Multiprozessors 10 auf verschiedenen integrierten Schaltungen oder auf verschiedenen und separaten Modulen bereitgestellt sind.
In diesem Zusammenhang ist in dem Beispiel der 1 eine Architektur dargestellt, die nur einen der oben genannten Multiprozessoren 10 umfasst, der wiederum die mehreren Prozessormodule 11 umfasst. Auf dem oben genannten Multiprozessor 10 werden die Anwendungsfunktionen, d. h. die Programme P, beispielsweise zur Steuerung oder Assistenz beim Fahren eines Kraftfahrzeugs, und die Sicherheitsfunktionen SF ausgeführt, die auf einen Selbsttest der Integrität des Systems und auf die Erkennung möglicher Ausfälle oder Fehlfunktionen ausgerichtet sind, die in der Logik und in den Festkörperspeichern der Multiprozessoren 10 selbst oder in Unterabschnitten davon auftreten können.
Zusätzlich zu dem Multiprozessor 10 stellt die in 1 dargestellte, mit funktionaler Sicherheit bereitgestellte Architektur eine eigenständige Verarbeitungseinheit bereit, dargestellt durch das Steuermodul 15, das zum Analysieren, Verarbeiten und Vergleichen des Inhalts von Flüssen von Überwachungs- und Steuernachrichten MC ausgelegt ist, die von den in dem Multiprozessor 10 betriebenen verschiedenen Programmen stammen, die die oben erwähnten Selbsttestvorgänge implementieren, die durch die Prozessoren 11 des Multiprozessors 10 ausgeführt werden, um die Überwachung ihrer funktionalen Sicherheit und die Erkennung von möglichen Fehlfunktionen zu ermöglichen, die in der Logik auftreten können, aus der sie zusammengesetzt sind, oder auch allgemeiner durch den Ablauf der Ausführung von Unterprogrammen P1, ..., Pn, in die das Programm P zerlegt ist, damit es auf den jeweiligen Prozessormodulen 11 ausgeführt werden kann.
Der Multiprozessor 10 und das Steuermodul 15 kommunizieren über Kommunikationsmittel 12, die es den verschiedenen Prozessormodulen 11 des Multiprozessors 10 ermöglichen, die oben genannten Überwachungs- und Steuernachrichten MC zu der Verarbeitungs- und Vergleichseinheit zu senden und von dieser zu empfangen, d. h. das Steuermodul 15, das wiederum Nachrichten, beispielsweise Alarme, von dem Multiprozessor 10 empfangen bzw. zu diesem senden kann.
Wie bereits erwähnt, ist zur Vereinfachung in 1 nur ein Multiprozessor 10 dargestellt, tatsächlich können in der Architektur jedoch mehrere Prozessoren oder Multiprozessoren bereitgestellt sein, die die Überwachungs- und Steuernachrichten mit dem Steuermodul 15 über jeweilige Kommunikationsmittel 12 austauschen.
Das hierin beschriebene Verfahren gilt für alle diese möglichen Auslegungen eines Multiprozessors 10, auf dem eine durch SF in 2 bezeichnete Sicherheitsfunktion implementiert ist. Mit „Sicherheitsfunktion“ ist eine Funktion gemeint, die im Rahmen eines Systems betrieben wird, das ein Einhalten der Anforderungen der funktionalen Sicherheit, auf die in den oben erwähnten Standards Bezug genommen wird, erfordert. 2 stellt tatsächlich eine Sicherheitsfunktion SF dar, die in einen Softwareprozess implementiert ist, nämlich einem Programm P, das von dem Multiprozessor 10 auszuführen ist. In 2 ist das Programm P, das ein zyklisch ausgeführter Prozess ist, als Ganzes durch einen Kreisring dargestellt, der eine zyklische Ausführung in einer Zeit t mit einer Zykluszeit T_cyc darstellt. Die Sicherheitsfunktion SF belegt ein zeitliches Segment des oben erwähnten Programms P, d. h. einen Sektor des Kreisrings, wobei die Sicherheitsfunktion SF im Allgemeinen ein Teil des Programms P ist und somit in einer sicheren Ausführungszeit T_s ausgeführt wird, die kürzer als die Zykluszeit T_cyc ist. In 2 ist auch angezeigt, wie während der Ausführung der Sicherheitsfunktion SF, d. h. während der sicheren Ausführungszeit T_s, Überwachungs- und Steuernachrichten MC ausgetauscht werden, insbesondere mit einem eigenständigen Steuermodul 15.
Wie in 1 gezeigt, stellt das hierin beschriebene Verfahren ein Zerlegen des Programms P in parallele Unterprogramme P1, ..., Pn bereit, die in der Architektur von 1 jeweils auf einem Kern 11 implementiert sind. Zwar ist in 1 ein Multiprozessor dargestellt, jedoch können die Unterprogramme P1, ..., Pn auch in dem Fall zerlegt werden, wenn in dem Verarbeitungssystem nur ein Prozessor vorgesehen ist, beispielsweise über Virtualisierungstechniken. Eine technische Lösung, die auf dem Gebiet der Betriebssysteme für Multiprozessoren zur Verfügung steht, ist die Virtualisierungstechnologie, die genau eine Virtualisierung der Hardware ermöglicht, auf der Anwendungsprogramme auf einem einzelnen Kern oder, wie im Folgenden dargestellt, auch auf den Kernen 11 des Multiprozessors 10 ausgeführt werden (beispielsweise wird auf die sogenannten „Hypervisoren“ bzw. „Virtual-Machine-Monitors“ verwiesen). Gemäß dem Anwendungsparadigma für Virtualisierungstechnologien wird das Programm P in mehrere parallele Prozesse P1, ..., Pn zerlegt, die jeweils auf einer virtuellen Maschine V1, ..., Vn ausgeführt werden können, um eine parallele Ausführung zu erhalten, die funktional dem Ausgangsprogramm P entspricht, das die Sicherheitsfunktion SF umfasst.
Die Zerlegung in Unterprogramme P1, ..., Pn, die den verschiedenen virtuellen Maschinen oder Kernen zuzuordnen sind, orientiert sich bei bekannten Systemen an Überlegungen funktionaler Art in Bezug auf die Funktionen des spezifischen Programms P. Wie im Folgenden ausführlicher beschrieben, stellt das hierin beschriebene Verfahren stattdessen ein Durchführen des oben erwähnten Zerlegungsvorgangs in Teilprozesse P1, ..., Pn auf Grundlage der Einhaltung von gegebenen Einschränkungen des Deckungsgrads in Bezug auf das Vorhandensein von Ausfällen zufälliger Art bereit, die die in industriellen und automobilen Anwendungen vorgesehenen funktionalen Sicherheitsstandards fordern. Diese Einschränkungen werden daher im Allgemeinen als Funktionen f(k) eines durch den Standard geforderten Deckungsgrads k bezeichnet.
Die funktionale Sicherheitsarchitektur der 1 ist darüber hinaus dazu ausgelegt, im Rahmen der Sicherheitsfunktion SF Selbsttestvorgänge durchzuführen, die unter Bezugnahme auf 3 ausführlicher beschrieben sind, die im Allgemeinen Folgendes umfassen:

Diagnoseselbsttestvorgänge A_stl, die Diagnosetests durch Ausführung von den Prozessoren 11 zugeordneten STLs (Self-Test Libraries-Selbsttestbibliotheken) 50 durchführen, wie in 3 angezeigt;
Vorgänge A_sys zum Selbsttest von auf der Architektur gemessenen Systemwerten, die ebenfalls vorzugsweise durch Ausführung der STLs 50 durchgeführt werden;
anwendungsbezogene Selbsttestvorgänge A_chk, die Vorgänge eines Vergleichens zwischen Unterprogrammen P1, ..., Pn durch Anwendungsvergleichssoftwaremodule 60 sein können, die unter Bezugnahme auf 3 im Folgenden der vorliegenden Beschreibung beschrieben sind; wie jedoch unter Bezugnahme insbesondere auf die 11 und 14 beschrieben, ist in dem erfindungsgemäßen Verfahren vorgesehen, den anwendungsbezogenen Selbsttest für Prüfungsvorgänge durch periodische Ausführung von Anwendungsbedingungen (CoU, Conditions Of Use) (A_cou) und/oder periodische Ausführung von LBISTs (Logic Built-in Self-Tests-Logischen integrierten Selbsttests) durchzuführen.

In diesem Zusammenhang sind in 2 die STLs 50 und die Anwendungsvergleichssoftwaremodule 60 angezeigt, die jedem der Kerne 11 zugeordnet sind und jeweils die drei Selbsttestvorgangsarten A_stl, A_chk, A_sys implementieren. Wie bereits erwähnt, umfassen die STLs 50 vorzugsweise Software zum Durchführen sowohl der Diagnoseselbsttestvorgänge A_stl als auch der Vorgänge A_sys zum Selbsttest von auf der Architektur gemessenen Systemwerten, jedoch können in abweichenden Ausführungsformen die Vorgänge A_sys zum Selbsttest von Systemwerten über ein separates und dediziertes Softwaremodul durchgeführt werden.
Die oben genannten drei Selbsttestvorgangsarten A_stl, A_sys, A_chk umfassen ein Erzeugen von Selbsttestdaten auf dem Multiprozessor 10, d. h. Diagnoseselbsttestdaten D_stl, Systemdaten D_sys bzw. Anwendungsselbsttestdaten D_chk. Wie in 3 ausführlicher erwähnt und dargestellt, ist es außerdem vorgesehen, die oben genannten Selbsttestdaten D_stl, D_sys, D_chk in Softwaremodulen zu erzeugen, die durch die Diagnoseselbsttestbibliotheken 50 und durch die Anwendungsvergleichssoftwaremodule 60 dargestellt sind, und sie in den Überwachungs- und Steuernachrichten MC zu senden, so dass Prüfvorgänge an den Selbsttestdaten D_stl, D_sys, D_chk über Module durchgeführt werden, die in 2 als Logikmodule 51, 61 dargestellt sind, die in dem Steuermodul 15 beinhaltet sind.
In 1 sind wiederum die Kommunikationssysteme 12 dargestellt, die zum Austausch der Überwachungs- und Steuernachrichten MC zwischen den Prozessormodulen verwendet werden, die den Multiprozessor 10 und das Steuermodul 15 bilden. Die oben erwähnten Kommunikationskanäle können aus Segmenten eines Punkt-zu-Punkt-Typs bestehen oder aber in einer hierarchischen Weise und ggf. mit einem Mehrfachzugriff auf ein gemeinsames physisches Medium erzeugt werden, wie z. B. in dem dargestellten Beispiel einen Kommunikationsbus. Eine Bestimmung des Inhaltes der auszutauschenden Überwachungs- und Steuernachrichten MC wird durch Ausführen der Selbsttestvorgänge A_stl, A_sys, A_chk sowie weiterer im Folgenden ausführlicher beschriebener Vorgänge erhalten, und ein Senden der Überwachungs- und Steuernachrichten MC selbst wird in regelmäßigen Zeitintervallen erreicht, in denen die den Multiprozessor 10 bildenden Prozessormodule 11 von der Ausführung der jeweiligen Anwendungsprogramme P1, ..., Pn, die aus der Zerlegung des Programms P erhalten wurden, für das sie normalerweise hauptsächlich dediziert sind, umgelenkt und der Ausführung eines speziellen Codes, d. h. dem Code der Programme der Selbsttestbibliotheken 50, zugewiesen werden. Insbesondere werden die Überwachungs- und. Steuernachrichten MC auf unterschiedlichen hierarchischen Ebenen oder Organisationsebenen der Software erzeugt, die in dem Multiprozessor 10 wie im Folgenden ausführlicher beschrieben ausgeführt wird. Der Austausch von Überwachungs- und Steuernachrichten MC zwischen dem System-Multiprozessor 10 und dem Steuermodul 15 wird gemäß einem Kommunikationsprotokoll PL erhalten, das ebenfalls im Folgenden näher beschrieben wird.
Gemäß einem Hauptaspekt des hierin beschriebenen Verfahrens ist es vorgesehen, den Zerlegungsvorgang des Programms P in mehrere parallele Unterprogramme P1, ..., Pn derart durchzuführen, dass ein Ausfallwahrscheinlichkeitsziel eingehalten wird, das im allgemeinen Fall mit g und in dem nachfolgend dargestellten Beispiel mit zwei Prozessoren mit g12 bezeichnet ist, das eine Funktion für jedes Unterprogramm P1, ..., Pn eines jeweiligen Deckungsgradwerts k_stl ist, der durch die oben genannten Diagnoseselbsttestvorgänge A_stl bestimmt wird, eines jeweiligen Deckungsgradwerts k_sys, der durch die Vorgänge A_sys eines Selbsttests von auf der Multiprozessorarchitektur 10 gemessenen Werten bestimmt wird, und eines Deckungsgradwerts k_chk, der durch die anwendungsbezogenen Selbsttestvorgänge A_chk bestimmt wird, ist.
Der Deckungsgrad in Bezug auf DC (Diagnostic Coverage - Diagnosedeckungsgrad) oder SFF (Safe-Failure Fraction - Anteil der sicheren Ausfälle; in diesem Zusammenhang wird auf den Sicherheitsstandard IEC 61508 verwiesen) für jede Komponente der Sicherheitsarchitektur in 1, insbesondere für den Teil des Softwareprogramms der Diagnoseselbsttestvorgänge A_stl (STLs 50), wird auf Grundlage der folgenden Merkmale des Systems bestimmt:

- SIL (Safety Integrity Level - Sicherheits-Integritätslevel), das für das System, insbesondere ein Zweikanalsystem, zu erreichen ist; dies führt zu einer Anforderung eines Deckungsgrads k, der von dem System eingehalten werden muss;
- Basiszyklusfrequenz f_cyc der Vorgänge und DTI (Diagnostic-Test Interval-Diagnosetestintervall); in dieser Hinsicht wird, wie in 2 dargestellt, das Programm P als Ganzes zyklisch mit einer Zykluszeit T_cyc und somit einer Basiszyklusfrequenz f_cyc ausgeführt; die Sicherheitsfunktion SF belegt ein zeitliches Segment des Programms P für eine sichere Ausführungszeit T_s, die kürzer als die Zykluszeit T_cyc ist;
- Anzahl und Art der Prüfungen, insbesondere in der betrachteten Architektur, die durch das Steuermodul 15 an den Ergebnissen der Diagnoseselbsttestvorgänge A_stl pro Zeiteinheit durchgeführt werden; die sichere Ausführungszeit T_s ist eine Funktion f(k) der Einschränkung des vom Sicherheitsstandard geforderten Deckungsgrads k.

Ferner wird, wie im Folgenden ebenfalls ausführlich beschrieben ist, der Vorgang des Datenaustauschs mit einer Nachrichtensequenz ausgeführt, wobei eine Menge von Daten q und eine Frequenz f gemäß einer weiteren Funktion des oben genannten einzuhaltenden Ausfallwahrscheinlichkeitsziels g gewählt werden.
Als zusätzlicher Schritt kann eine Prüfung vorgesehen sein zum Verifizieren, ob die Zielwerte des Deckungsgrads k, die als eine Funktion des oben genannten Ausfallwahrscheinlichkeitsziels g bestimmt wurden, effektiv durch Fehlerinjektion in einem Simulationsschritt erreicht wurden, beispielsweise gemäß dem in dem Patent Nr. EP 1 980 964 A1 Beschriebenen, das im Namen des Anmelders der vorliegenden Erfindung eingereicht wurde.
Es folgt nun eine detaillierte Beschreibung des Vorgangs der Zerlegung des Programms P in mehrere parallele Unterprogramme P1, ..., Pn gemäß einer Funktion eines einzuhaltenden Ausfallwahrscheinlichkeitsziels g.
Um die geringste Ausfallwahrscheinlichkeit g ohne Hardwaremodifikationen und mit geringstmöglicher Auswirkung auf das Programm P, in Bezug auf die Größe des Programmspeichers und auf die Ausführungszeit, zu erhalten, stellt das beschriebene Verfahren tatsächlich eine Zerlegung des Programms P in zwei oder mehr eigenständige Programme P1, P2, ..., Pn bereit.
Die beschriebene funktionale Sicherheitsarchitektur wird als eine Funktion eines Ausfallwahrscheinlichkeitsziels g und somit als eine Funktion von zu erreichenden Werten eines Deckungsgrads k festgelegt. Spezifische Beispiele beziehen sich im Folgenden im Wesentlichen auf ein Zweikanalsystem, d. h. ein System, in dem das Programm P in zwei Prozesse P1 und P2 zerlegt wird, die auf zwei Kernen C1...C2 oder zwei virtuellen Maschinen VI...V2 betrieben werden, die zwei Ergebniskanäle liefern.
Somit kann im beispielhaften Fall eines Zerlegungsvorgangs in zwei Programme P1, P2 und bei einer Annahme der Einfachheit halber, dass die beiden eigenständigen Programme P1, P2 auf zwei identischen Prozessormodulen 11 mit der gleichen Basisausfallwahrscheinlichkeit λ gleich 1 und mit der gleichen Verteilung der Ausfallmodelle Λ gleich 1 ausgeführt werden, die Ausfallwahrscheinlichkeit des aus den Prozessoren 1 und 2 gebildeten Multiprozessorsystems beschrieben werden als: $g12 \leq {(1 - β)}^{2} \cdot (1 - s1) (1 - k1) \cdot (1 - s2) \cdot (1 - k2) \cdot texp +β \cdot (1 - s12) \cdot (1 - k12)$
wobei: k1 und k2 die Ausfalldeckungsgrade für die zwei Prozessoren, zum Beispiel C1 bzw. C2, sind, die die zwei Programme P1 und P2 ausführen; s1 und s2 die Anteile der sicheren Ausfälle der zwei Prozessoren C1 bzw. C2 sind, die die zwei Programme P1 bzw. P2 ausführen; β der Anteil der Ausfälle ist, der einen gemeinsam verursachten Ausfall (GVA bzw. engl. CCF, Common Cause Failure) zwischen den zwei Prozessoren C1 und C2 verursachen kann; k12 der Ausfalldeckungsgrad ist, der einen GVA zwischen den zwei Prozessoren C1 und C2 verursachen kann; s12 der Anteil der sicheren Ausfälle ist, der für die zwei Prozessoren C1 und C2 gemeinsam ist; und texp die Expositionszeit des ersten Ausfalls ist. Die Zeit texp ist durch die Art der Verwendung des Systems und durch die Art des Ausfallmodells definiert und kann im Grenzwert der Lebensdauer des Systems entsprechen. Unter der Annahme, dass ein gegebenes Unterprogramm Pi eine Basisausfallwahrscheinlichkeit λ gleich 1 und eine Verteilung der Ausfallmodelle Λ gleich 1 aufweist, identifiziert das Wertepaar si, ki, die der Anteil der sicheren Ausfälle des entsprechenden Prozessors bzw. der Ausfalldeckungsgrad sind, im Wesentlichen die Ausfallwahrscheinlichkeit desselben.
Gleichung (1), die oben für das Ausfallwahrscheinlichkeitsziel g12 der zwei eigenständigen Unterprogramme P1 und P2 definiert ist, wird über die Arithmetik der Fehlerbaumanalyse (FTA, Fault-Tree-Analysis) (siehe beispielsweise ISO 26262-10, Anhang B) bestimmt; d. h. sie entspricht (siehe 8) einem Bestimmen der Ausfallwahrscheinlichkeit der zwei Unterprogramme P1 und P2, die durch eine Logikfunktion eines UND-Typs verbunden sind und bei denen die jeweilige Hardware, auf der jedes Programm ausgeführt wird, mit einer sehr geringen Ausfallwahrscheinlichkeit verknüpft ist. Somit drückt Gleichung (1) die resultierende mittlere Ausfallwahrscheinlichkeit, d. h. das Ausfallwahrscheinlichkeitsziel, annähernd als ein Produkt der jeweiligen Wahrscheinlichkeiten und der Expositionszeit t aus.
Es ist daher möglich, Gleichung (1) einfach für eine beliebige Anzahl von eigenständigen Programmen zu erweitern: Zum Beispiel kann im Fall von drei Programmen das UND-Gatter mit drei Eingängen in zwei UND-Gatter mit zwei Eingängen zerlegt werden, und dann kann die resultierende Formel unter Verwendung von Gleichung (1), die oben für zwei Programme P1 und P2 dargestellt ist, konstruiert werden.
Mit anderen Worten wird der Wert der Ausfallwahrscheinlichkeit der Unterprogramme P1, ..., Pn in Bezug auf ein einzuhaltendes Ausfallwahrscheinlichkeitsziel g berechnet, indem die Unterprogramme P1, ..., Pn als Eingänge eines UND-Gatters betrachtet werden, das so viele Eingänge aufweist wie Unterprogramme vorhanden sind, das oben genannte UND-Gatter in UND-Gatter mit zwei Eingängen zerlegt wird und das Wahrscheinlichkeitsziel als eine Funktion des Produkts der Ausfallwahrscheinlichkeiten am Ausgang jedes UND-Gatters mit zwei Eingängen und die Ausführungszeit berechnet werden.
Wiederum unter Anwendung der FTA-Arithmetik wird die Ausfallwahrscheinlichkeit g12 durch Addieren (nämlich durch Anwenden einer logischen Funktion eines ODER-Typs) eines GVA-Ausdrucks β·(1-s12)·(1-k12) abgeschlossen, der die GVAs berücksichtigt.
Somit umfasst die Berechnung des oben genannten Ausfallwahrscheinlichkeitsziels g: Betrachten der Unterprogramme P1, ..., Pn als Eingänge einer UND-Logikfunktion AG mit so vielen Eingängen wie Unterprogramme P1, ..., Pn vorhanden sind; Zerlegen der UND-Logikfunktion AG in UND-Logikfunktionen mit zwei Eingängen, die als Eingänge die Paare der oben genannten Unterprogramme P1, ..., Pn, die gebildet werden können, aufweisen, und Berechnen des Produkts der Ausfallwahrscheinlichkeiten am Ausgang von jedem UND-Gatter mit zwei Eingängen, multipliziert mit dem Komplement des Anteils der gemeinsam verursachten Ausfälle β, und der Expositionszeit texp, Berechnen des oben genannten Wahrscheinlichkeitsziels g als eine Funktion des Ergebnisses des vorhergehenden Vorgangs addiert mit einem Wert, der durch Anwenden von ODER-Funktionen auf gemeinsam verursachte Ausfälle erhalten wird, d. h. die Paare ki, si für alle Paare ij der Unterprogramme P1, ..., Pn, und durch Multiplizieren des Ergebnisses, das durch den Anteil der gemeinsam verursachten Ausfälle β erhalten wird.
8 veranschaulicht über eine Logikschaltung den Berechnungsvorgang des Wahrscheinlichkeitsziels g durch Implementieren der Logikfunktionen gemäß dem, was gerade erörtert wurde. Mit AG ist das UND-Gatter mit n Eingängen bezeichnet, das gemäß dem oben Beschriebenen in Gatter mit zwei Eingängen zerlegt werden kann und das als Eingang für jedes Unterprogramm Pi den Deckungsgrad ki und den Anteil der sicheren Ausfälle si empfängt (im Beispiel von Gleichung (1) k1, s1 und k2, s2). Die Ausgabe wird mit 1-β multipliziert, was das Einerkomplement des Anteils der Ausfälle ist, die einen gemeinsam verursachten Ausfall verursachen können. Das UND-Gatter (wie in der FTA-Arithmetik vorgesehen) berechnet die Multiplikation mit der Expositionszeit. Mit OG sind ODER-Gatter mit mehreren Eingängen bezeichnet, die für zwei Unterprogramme Pi und Pj als Eingang den GVA-Deckungsgrad kij und den Anteil an gemeinsam verursachten sicheren Ausfällen sij empfangen (in dem Beispiel k12, s12). Die Ausgabe wird mit β multipliziert, was ein Anteil der Ausfälle ist, der einen gemeinsam verursachten Ausfall verursachen kann. Ein Gatter OGT berechnet dann die Summe der Ausgänge der Gatter AG und OG, um die allgemeine Form g des Ausfallziels g12 von Gleichung (1) zu liefern.
Eines der Merkmale, die das Verfahren auszeichnen, besteht darin, dass die Ausfalldeckungsgrade k1, k2 und k12 als die Kombination von drei Beiträgen definiert sind:

k_stl, d. h. der Deckungsgradanteil, der durch Ausführen der Diagnoseselbsttestvorgänge A_stl sichergestellt ist (ausgeführt über die STL 50, insbesondere unter Zusammenwirken mit dem auf dem Modul 15 vorhandenen Modul 51);
k_chk, d. h. der Deckungsgradanteil, der durch die anwendungsbezogene Prüfung der Ausführung der Programme P1 und P2 in einer Zielzeit T sichergestellt ist - in der Regel als der PST (Process Safety Time - Prozesssicherheitszeit) oder dem FTTI (Fault Tolerant Time Interval - Fehlertoleranzzeitintervall) entsprechend berechnet, d. h. durch den Selbsttestvorgang A_chk (ausgeführt in der Vergleichskomponente 60, insbesondere unter Zusammenwirken mit dem auf dem Steuermodul 15 vorhandenen Modul 61);
k_sys, d. h. der Deckungsgradanteil, der durch den Vergleich der Systemselbsttestdaten D_sys, die durch den Vorgang A_sys eines Selbsttests (vorzugsweise noch einmal unter Zusammenwirken der Module des Multiprozessors 10 und des Moduls 15 durchgeführt) von auf der Multiprozessorarchitektur 10 gemessenen Systemparametern erhalten werden, wie z. B. die Temperatur und die Spannung der Prozessoren C1, C2, auf denen die Programme P1 und P2 ausgeführt werden, mit Referenzwerten oder Grenzwerten, d. h. Bereichen R_att, sichergestellt ist.

Insbesondere gilt für die Deckungsgrade k1, k2 der Programme P1 und P2 und für den GVA-Deckungsgrad k12: $\begin{array}{l} k1 = k_{stl1} \cup k_{chk} \cup k_{sys} \\ k2 = k_{stl2} \cup k_{chk} \cup k_{sys} \\ k12 = k_{stl12} \cup k_{chk} \cup k_{sys} \end{array}$
Der Vereinigungsoperator U zeigt an, dass die beiden Deckungsgrade gemäß den Regeln der Mengenlehre als eine Funktion ihres einzelnen Ausgalldeckungsgrads kombiniert werden.
Das Deckungsgradziel der STLs, nämlich k_stl1, das der Bibliothek 50 zugeordnet ist, die in dem Programm enthalten ist, das von dem Prozessor C1 ausgeführt wird, k_stl2, das der Bibliothek 50 zugeordnet ist, die in dem Programm enthalten ist, das von dem Prozessor C2 ausgeführt wird, und k_stl12, das der Bibliothek 50 zugeordnet ist, die in dem Programm enthalten ist, das von dem Prozessor C1 und/oder dem Prozessor C2 ausgeführt wird, zum Abdecken der gemeinsam verursachten Ausfälle - und somit der Struktur und der Programmierung der Bibliotheken - wird mit dem Ziel bestimmt, das Ausfallwahrscheinlichkeitsziel g12 als eine Funktion der Parameter β, t und s1, s2 und s12 zu erreichen.
Somit umfasst das Verfahren in der Praxis ein Bereitstellen von drei verschiedenen Arten von Selbsttestvorgängen A_stl, A_chk, A_sys in der Sicherheitsarchitektur, denen die Deckungsgrade k_stl, k_chk, k_sys zugeordnet sind, und, unter Annahme einer Anzahl von Unterprogrammen P1, ..., Pn, in die das funktionale Sicherheitsprogramm P zerlegt wurde, für jede Art von Selbsttestvorgang A_stl, A_chk, A_sys Zuordnen des oben genannten Selbsttestvorgangs A_stl oder A_chk oder A_sys zu jedem Unterprogramm P1, ..., Pn und/oder Prozessor 11, Definieren der Parameter des Selbsttestvorgangs A_stl oder A_chk oder A_sys derart, dass die resultierenden Werte eines Deckungsgrads k_stl oder k_chk oder k_sys, zusammen mit denjenigen, die von den anderen zwei Arten von Selbsttestvorgängen gemäß dem Ausdruck der Gleichung (1) abgeleitet sind, das für das System definierte Ausfallwahrscheinlichkeitsziel g einhalten.
Gemäß einem weiteren Aspekt des hierin beschriebenen Verfahrens wird der oben genannte:

Vorgang A_stl des Diagnoseselbsttests auf Grundlage der Selbsttestbibliotheken 50, die mit jeweiligen Selbsttestdeckungsgraden k_stl1, k_stl2 und k_stl12 für die zwei Prozessoren C1 und C2 definiert sind,
Vorgang A_chk der anwendungsbezogenen Prüfung der Programme P1 und P2 mit Anwendungsdeckungsgrad k_chk, und
Vorgang des Vergleichs A_sys von Systemselbsttestdaten D_sys der Prozessoren C1, C2, auf denen die Programme P1 und P2 mit erwarteten Bereichen R_att ausgeführt werden, wodurch der Systemdeckungsgrad k_sys identifiziert wird,
nicht vollständig durch den Multiprozessor 10 ausgeführt, sondern werden sequentiell über ein weiteres Element abgeschlossen, das unabhängig von dem Multiprozessor 10 ist, nämlich das Steuermodul 15. Dies wird über einen Datenaustausch (die Nachrichten MC) zwischen dem Multiprozessor 10 und dem Steuermodul 15 erreicht.

Die Entsprechung der Deckungsgrade k_stl1, k_stl2, k_stl12, k_chk und k_sys in Bezug auf die wie oben beschrieben bestimmten Zielwerte wird über Ausfallinjektionen während einer Simulation getestet.
Somit stellt das hierin beschriebene Verfahren ein Betreiben in einem Zusammenhang mit elektronischen Systemen mit funktionaler Sicherheit, die ein gegebenes Programm P ausführen, wobei der Vorgang der Zerlegung des Programms P in Unterprogramme und der Aufteilung der Selbsttestvorgänge in drei separate Vorgänge, nämlich Selbsttest A_stl durch Diagnosetests, Selbsttest A_sys durch Überwachen der Systemwerte und Selbsttest A_chk durch anwendungsbezogene Prüfung, gemäß einer Beziehung, Gleichung (1), die das Ausfallziel mit den Deckungsgraden der Unterprogramme verknüpft, die wiederum als eine Funktion der Deckungsgrade k_stl, k_chk, k_sys der drei Selbsttestvorgänge A_stl, A_chk, A_sys definiert sind, eine präzise Identifikation der Deckungsgradziele ermöglicht, die jedem der drei Selbsttestvorgänge zuzuweisen sind, wodurch eine optimierte Verteilung der Ziele ermöglicht wird.
Die unter Bezugnahme auf 1 beschriebene Architektur stellt darüber hinaus ein Durchführen der oben genannten Selbsttestvorgänge unter Zusammenwirken mit einem externen Modul, dem Steuermodul 15, über ein Kommunikationsprotokoll PL zum Austausch von Überwachungs- und Steuernachrichten MC bereit. „Externes Modul“ bezeichnet hierin ein Modul außerhalb der Prozessoren 11, wobei dieses Modul auch in der integrierten Schaltung enthalten sein kann, in der die Prozessoren bereitgestellt sind. Das beschriebene Verfahren stellt somit Selbsttestvorgänge bereit, die im Gegensatz zu den in bekannten Systemen ausgeführten Selbsttestvorgängen, die die Selbsttestdaten in ein und demselben Einprozessor- oder Multiprozessorverarbeitungssystem erzeugen und prüfen, ein Erzeugen der Selbsttestdaten in dem Einprozessor- oder Multiprozessorverarbeitungssystem bereitstellen, wobei der Selbsttestvorgang jedoch durch Durchführen der Prüfung über ein separates eigenständiges Element, das Steuermodul 15, abgeschlossen wird.
Um die oben genannten und andere Aspekte ausführlicher zu beschreiben, zeigt 3 schematisch ein abstraktes Modell einer Ausführungsform der beschriebenen Lösung durch eine Hierarchie von physischen und Software-Ebenen eines ISO-/OSI-Typs, wobei auch das Kommunikationsprotokoll PL darstellt ist.
Das oben genannte Kommunikationsprotokoll PL ist auf hierarchischen Ebenen implementiert, wobei die Nachrichten auf der Anwendungsebene (L4 in 3) in dem durch das Programm P implementierten Protokoll PL gekapselt sind und auf einer niedrigeren Ebene (Ebene L2 in 3) die den STLs 50 entsprechenden Nachrichten hinzugefügt werden. Wie in 3 dargestellt, implementiert das Steuermodul 15 das Kommunikationsprotokoll PL in Bezug auf die oben genannten hierarchischen Ebenen in gespiegelter Weise. Das oben genannte Protokoll PL ordnet die Überwachungs- und Steuernachrichten MC in einem hierarchischen Rahmen an, der eine Kapselung von verschiedenen Pakten für unterschiedliche Kennungen ID von verschiedenen Prozessormodulen 11 und deren Weiterleitung in dem Steuermodul 15 zu den für ihre Analyse und ihren Vergleich zuständigen Verarbeitungseinheiten ermöglicht, wie unter Bezug auf 6 ausführlicher dargestellt ist. Im Folgenden sind mit VC die eine spezifische Systemebene adressierenden logischen Kanäle, mit ID die Kennungen, die die physischen Kanäle hinsichtlich eines Verarbeitungselements adressieren, mit C1, ..., Cm physische Kerne und mit V1, ..., Vm virtuelle Maschinen bezeichnet. Insbesondere umfasst in dem Protokoll PL eine Nachricht MC eines Pakettyps folgende Felder für numerische Werte:

Felder, die für die Hierarchisierung der Nachrichten MC als Funktion der logischen Kanäle VC, zu denen sie gehören, dediziert sind;
Felder für die kardinale und zeitliche Sequenz der Pakete der Nachrichten MC;
Befehlsfelder für das Steuermodul 15; und
ein Nutzdatenfeld, das das Datum enthält, in Bezug auf welches das Steuermodul 15 den Selbsttestvorgang abschließen muss.

Das Steuermodul 15 ist darüber hinaus dazu ausgelegt, mittels eines Algorithmus, der eine Fehlererkennung und/oder -korrektur ermöglicht, eine Integritätsprüfung des Inhalts der Nachricht MC durchzuführen. Vorzugsweise wird der Algorithmus CRC32 als Fehlererkennungsalgorithmus verwendet (in 7 ist er in dem Modul 112a implementiert).
In der detaillierteren Darstellung der hierarchischen physischen und Software-Ebenen in 3 ist mit L1 eine physische Hardwareausführungsschicht bezeichnet, die dem Multiprozessor 10 entspricht, der eine Vielzahl von Kernen C1, ..., Cm und ein Eingabe-/Ausgabemodul 10 umfasst. Dies wird in der Regel durch eine oder mehrere integrierte Schaltungen implementiert.
Mit L2 ist eine Supervisorebene L2 bezeichnet, die durch ein Virtuelle-Maschinen-Verwaltungsmodul 17 dargestellt ist, eine Softwarekomponente, die üblicherweise als „Hypervisor“ bezeichnet wird, deren Funktion der Virtualisierung der vorhandenen Hardware der physischen Ebene L1 ist, so dass auf einer Virtualisierungsebene L3 eine Anzahl n von virtuellen Maschinen V1, ..., Vn mit entsprechendem Betriebssystem derart zur Verfügung stehen, dass sie als eigenständige Einheiten verwendet werden können, sogenannte „virtuelle Gastmaschinen“. Das Virtuelle-Maschinen-Verwaltungsmodul 17 stellt sicher, dass die verschiedenen virtuellen Maschinen V1, ..., Vn und die entsprechenden Unterprogramme P1, ..., Pn, in die das Programm P beispielsweise manuell zu zerlegen ist, über bestimmte Merkmale verfügt, die für das Programm P erforderlich sind. Der Zerlegungsvorgang kann alternativ überhaupt nicht geschützt oder durch Modifikationen der Anwendung selbst bzw. des zugehörigen Betriebssystems geschützt sein. Auf dem Gebiet der Anwendung von funktionaler Sicherheit umfassen die oben genannten Merkmale in der Regel ein Sicherstellen einer Ausführung in Echtzeit und ein Verhindern einer Interferenz bei Ausführung verschiedener Prozesse. Wie bereits erwähnt, sieht das hierin beschriebene Verfahren stattdessen vor, dass die oben genannten Merkmale nur oder auch ein Ausfallwahrscheinlichkeitsziel g berücksichtigen. Im Allgemeinen ist eine Anzahl n an virtuellen Maschinen bereitgestellt, die einer Anzahl an Unterprozessen P1, ..., Pn entspricht, in die das Programm P zerlegt wird, wobei in dem bevorzugten Beispiel n = 2 gilt. Da eine Anzahl an virtuellen Maschinen auf ein und demselben Kern bereitgestellt sein kann, ist die Anzahl m der Kerne vorzugsweise kleiner oder gleich n.
Das hierin beschriebene Virtuelle-Maschinen-Verwaltungsmodul 17 umfasst eine Softwarekomponente, die den STLs 50 entspricht, die, wie bereits erwähnt, einen Test der funktionalen Integrität von jedem Kern C1, ..., Cm einführen, sowie Peripheriegeräte, die die zugrundliegende Hardware, d. h. die physische Ebene L1, bilden, um sicherzustellen, dass mögliche Ausfälle eines zufälligen Typs, die in der oben genannten zugrundliegenden Hardware auftreten können, mit einem vordefinierten Prozentsatz eines Deckungsgrads k erkannt werden. Bei einem homogenen Multiprozessor kann nur eine Bibliothek 50 vorhanden sein. Die Modalitäten, mit denen eine Softwarekomponente, hier die Komponente der STL 50 (oder die Komponenten der STL 50 bei einem nicht-homogenen Multiprozessor), in das Virtuelle-Maschinen-Verwaltungsmodul 17 integriert wird, sind Fachleuten auf diesem Gebiet an sich bekannt. Die Komponente der STL 50 kann insofern leicht in das Virtuelle-Maschinen-Verwaltungsmodul 17 integriert werden, als die Module eines solchen Typs, beispielsweise die Hypervisoren, die mit den bekannten Virtualisierungssystemen bereitgestellt sind, in der Regel dem Benutzer Schnittstellen zur Verfügung stellen, die eine Integration zusätzlicher Komponenten ermöglichen. Folglich ist es möglich, die Komponente der STL 50 als zusätzliche Komponente zu integrieren, wie in 3 dargestellt.
Eine Anwendungsebene L4 entspricht der Ebene der Unterprogramme P1, ..., Pn, in die das Programm P zerlegt wird und die auf den virtuellen Maschinen V1, ..., Vn implementiert sind. Der Anwendungsschicht L4 ist ein Anwendungsvergleichssoftwaremodul oder eine Komponente 60 zugeordnet, insbesondere eine(s) für jeden Prozess P1, ..., Pn, speziell als „Anwendungssicherheitsebene“ (ASL, Application Safety Layer) bezeichnet, das bzw. die im Allgemeinen den Selbsttestvorgang durchführt, der die Anwendungsselbsttestdaten D_chk erzeugt, beispielsweise durch einen Vergleich der Zwischenergebnissen der Kanäle oder durch Prüfung einer Ausführung von Anwendungsbedingungen oder einer Ausführung von LBISTs. Genauer gesagt erhält, wie bereits erwähnt, in dem hierin beschriebenen Verfahren das Anwendungsvergleichssoftwaremodul oder die Komponente 60, insbesondere eine(s) für jeden Prozess P1, ..., Pn, die Anwendungsselbsttestdaten D_chk, die dann in dem Steuermodul 15 geprüft und verglichen werden.
In 3 ist das Steuermodul 15 als eine Hardwarekomponente dargestellt, die in 6 im Detail gezeigt ist. Es kann jedoch auch in äquivalenter Weise als Software implementiert sein, mit Unterschieden beim Kosten-/Leistungsverhältnis der resultierenden Komponente. Rein beispielhaft kann das Steuermodul 15 als ein von einem weiteren Prozessor ausgeführtes Programm implementiert sein.
Die Überwachungs- und Steuernachrichten MC, die mit dem Steuermodul 15 ausgetauscht werden, um die Selbsttestvorgänge A_stl, A_sys, A_chk abzuschließen, sind in zwei verschiedene Arten unterteilt:
Nachrichten, die Daten enthalten, die unabhängig von den Merkmalen des Programms P sind, das von dem Mikroprozessor 10 ausgeführt wird; dies sind beispielsweise die Systemselbsttestdaten D_sys, die durch die Vorgänge A_sys eines Selbsttests der auf der Architektur gemessenen Systemwerte erzeugt werden, welche Messungen von Spannung und/oder Temperatur der Kerne C1, ..., Cm des Multiprozessors 10 umfassen, sowie Diagnoseselbsttestdaten D_stl im Hinblick auf Zwischenergebnisse von Berechnungen, die gemäß einer der spezifischen Diagnoseselbsttestmethoden der Selbsttestbibliotheken 50 durchgeführt werden; und
Nachrichten, die Daten bezüglich anwendungsbezogener Tests enthalten und daher von dem Programm P oder der Anwendung selbst abhängen oder Daten bezüglich einer Prüfung einer Ausführung von Anwendungsbedingungen oder einer Ausführung von LBISTs enthalten; dies sind die Anwendungsselbsttestdaten D_chk, die durch Vorgänge A_chk eines Vergleichs zwischen den Unterprogrammen P1, ..., Pn über Anwendungsvergleichssoftwaremodule 60 erzeugt werden.
Das Steuermodul 15 schließt die Selbsttestvorgänge A_stl, A_sys, A_chk, die im Multiprozessor 10 gestartet wurden, unter Zusammenwirken und über einen Austausch der Nachrichten MC, die die entsprechenden Selbsttestdaten D_stl und D_chk enthalten, mit den entsprechenden Selbsttestlogikkomponenten 51 und Anwendungsvergleichslogikkomponenten 61 ab, die in dem Steuermodul 15 beinhaltet sind. Wie in 6 dargestellt, ist diese Trennung eines logischen Typs; jedoch können die Komponenten 51 und 61 über ein und denselben Satz von Hardwaremodulen implementiert werden. Dies wird beispielsweise wie folgt erreicht:

- das Steuermodul 15 schließt die Diagnoseselbsttestvorgänge A_stl ab, indem es im Logikmodul 51 den Vergleich der Diagnoseselbsttestdaten D_stl im Hinblick auf Zwischenergebnisse von Berechnungen, die auf den Kernen C1, ..., Cm des Multiprozessors 10 gemäß einer der spezifischen Diagnoseselbsttestmethoden der Selbsttestbibliotheken 50 mit einem Satz vorberechneter und erwarteter Werte D_stla, die in dem oben genannten Steuermodul 15 gespeichert sind, durchgeführt wurden, und erkennt mögliche gemeinsam verursachte Ausfälle (GVAs); mögliche Unterschiede zwischen den oben genannten Diagnoseselbsttestdaten _Dstl und dem Satz von vorberechneten und erwarteten Werten D_stla zeigen die Auswirkung eines Ausfalls (ob permanent oder vorübergehend) in der Logik oder in dem Status der Kerne C1, ..., Cm des Mikroprozessors 10 an;
- parallel dazu führt das Steuermodul 15 tatsächlich eine Funktion von Gegenprüfungen zwischen den beiden entsprechenden Sicherheitskanälen durch, indem es einen kontinuierlichen Vergleich in dem Logikmodul 61 von Anwendungsselbsttestdaten D_chk, die unabhängig voneinander durch ein Paar von Prozessormodulen 11, ob virtuelle Maschinen oder Kerne, erzeugt werden, durchführt;
- das Steuermodul 15 schließt auch den Vorgang A_sys des Selbsttests von auf der Architektur gemessenen Systemwerten mit einer Prüfung ab, indem es prüft, ob die Systemselbsttestdaten D_sys in die erwarteten Bereiche R_att fallen, die ebenfalls im Steuermodul 15 gespeichert sind.

Das Steuermodul 15 führt die oben genannten Prüfungen der Überwachungs- und Steuernachrichten MC beispielsweise gemäß den folgenden Kriterien für den Vergleich durch:

es berücksichtigt nur die Reihenfolge des Eingangs der Nachrichten MC und ob sie zu dem im Vergleich berücksichtigten Zyklus gehören; daher wird vorzugsweise die absolute Eingangszeit der einzelnen Nachrichten MC nicht berücksichtigt, obwohl sie in alternativen Ausführungsformen berücksichtigt werden kann;
das Steuermodul 15 ist dazu ausgelegt, das Einfügen von Nachrichten MC aus verschiedenen Quellen zu ermöglichen, d. h. von verschiedenen Prozessorelementen 11, in diesem Fall zwei, unter Einhaltung der Reihenfolge in den Sequenzen für jedes der zwei Prozessormodule 11, wie bereits erwähnt; und
das Steuermodul 15 wendet eigene Prüfungen auf zyklischer Basis an, wobei die Prüfungen für jeden der durch die Zykluszeit T_cyc definierten Zyklen abgeschlossen werden.

Es folgt nun eine ausführlichere Beschreibung der STLs 50 und der komplementären Logikmodule 51.
Die STLs 50 haben folgende Doppelfunktion:
Implementieren des Selbsttestvorgangs, der durch den Vorgang A_stl eines Diagnoseselbsttests des Multiprozessorverarbeitungssystems 10 dargestellt ist; der Diagnoseselbsttestvorgang A_stl wird in der Regel durch ein Vergleichen der Berechnungsergebnisse, der Diagnoseselbsttestdaten D_stl, die zum Zeitpunkt des Tests selbst durch den Multiprozessor 10 verarbeitet werden, mit vorberechneten und gespeicherten korrekten Ergebnissen, den erwarteten Ergebnissen D_stla erreicht, um zu prüfen, ob der Multiprozessor 10 die ihm zugewiesenen Programmsequenzen korrekt berechnet und ausführt; die Berechnungsergebnisse D_stl werden in der Regel aus der Sequenz von Vorgängen eines Arithmetik-, Logik- und Adressierungstyps erhalten, um die verschiedenen Schaltungsteile des Mikroprozessors 11 so vollständig, umfassend und erschöpfend wie möglich einzubeziehen; wie bereits erwähnt, werden in dem hierin beschriebenen Verfahren und der hierin beschriebenen Architektur die Vorgänge des Vergleichs mit den erwarteten Werten D_stla unter Zusammenwirken mit einem externen Verarbeitungsmodul, dem Steuermodul 15, (d. h. unter Zusammenwirken der Module 50 und 51 in der hierarchischen Darstellung von 3) implementiert; und
Messen von Systemselbsttestdaten D_sys, d. h. Messen von globalen Parametern, im Hinblick auf den Betrieb und/oder die Betriebsbedingungen jedes Mikroprozessors; vorzugsweise werden Größen wie die Betriebsspannung des Mikroprozessors und die Temperatur des Systems oder auch die Temperatur innerhalb des Mikroprozessors gemessen; diese Funktion ist besonders wichtig beim Identifizieren von Situationen eines möglichen Ausfalls der Mikroprozessoren und insbesondere von Situationen, die gemeinsam verursachte Ausfälle bei den Mikroprozessoren bestimmen können; die oben genannten Systemselbsttestdaten D_sys werden, wie bereits erwähnt, vorzugsweise auch über entsprechende Programme erhalten, die in den Bibliotheken 50 beinhaltet sind, wobei sie auch in separaten Bibliotheken bereitgestellt sein können, und werden anhand der erwarteten Bereiche R_att in den Logikmodulen 51 geprüft.
Insbesondere und in Bezug auf die Diagnoseselbsttestvorgänge A_stl, die die Diagnoseselbsttestdaten D_stl liefern, besteht der Selbsttestcode in der Regel aus einem Satz von Testsegmenten, die mit 202 bezeichnet und unter Bezug auf 7 ausführlicher beschrieben sind.
Die oben genannten Testsegmente sind vorzugsweise auf das Testen einer oder mehrerer Funktionseinheiten des Mikroprozessors, in diesem Fall des Multiprozessorverarbeitungssystems 10, gemäß den Zielen einer Analyse eines FMEDA-Typs (Failure Modes Effects and Diagnostic Analysis - Ausfallmöglichkeits-, Einfluss- und Diagnoseabdeckungsanalyse) ausgelegt, die auf Ebene der integrierten Schaltung und insbesondere auf den einzelnen Kernen C1, ..., Cm oder einzelnen Prozessoren durchgeführt wird. Die oben genannte FMEDA kann beispielsweise gemäß der in der Patentanmeldung Nr. EP 1 980 964 A1 beschriebenen Methode durchgeführt werden, die im Namen des Anmelders der vorliegenden Erfindung eingereicht wurde. Das Gesamtziel der Testsegmente, die die STL 50 von jedem der Kerne C1, ..., Cm bilden, besteht darin, einen Deckungsgrad, insbesondere einen Selbsttestdeckungsgrad k_stl oder Systemdeckungsgrad k_sys, zu erreichen, der die auf der gesamten Logik, die den Kern C1, ..., Cm bildet, voreingestellte Deckungsgradeinschränkung f(k) erfüllt. Dies ist bei Mikroprozessoren mit einer fortschrittlichen Architektur (mit tiefer Pipeline, vom superskalaren Typ mit mehreren Ausgaben) normalerweise ein extrem schwieriges Problem, und die Schwierigkeit nimmt merklich zu, wenn die Komplexität des Mikroprozessors, der einer Selbstdiagnose unterzogen wird, steigt. Der für den Anwendungssektor relevante funktionale Sicherheitsstandard definiert die Mindestanforderungen an die Integrität des Systems und die verschiedenen Komponenten des Systems.
Somit müssen die verschiedenen Segmente, die die Bibliothek 50 bilden, so ausgelegt sein, dass insgesamt auf dem gesamten Mikroprozessor oder Kern ein Zielwert eines Deckungsgrads k_stl erreicht wird, so dass - über eine Berechnungsmethode wie die nachstehend beschriebene durch Anwenden von Gleichung (1) - ein Integritätslevel erreicht werden kann, das größer oder gleich dem ist, was der relevante Sicherheitsstandard vorsieht.
Die Programme der Diagnoseselbsttestbibliothek 50 sind in der Regel aus Gründen der Erweiterbarkeit in Bezug auf die verschiedenen Funktionseinheiten des zu testenden Mikroprozessors und der Spezialisierung von einfacheren Einheiten, der Testsegmente 202, auf jeder der Funktionseinheiten des Mikroprozessors in modularer Form organisiert.
7 stellt in diesem Zusammenhang schematisch ein Selbstdiagnoseprogramm der Selbsttestbibliothek 50 dar, das mit 200 bezeichnet ist. Die in dem Programm 200 beinhalteten Testsegmente 202 werden aufgerufen, indem die Kennungs-ID# eines auszuführenden Testsegments durch eine als „Testschnittstelle 201“ bezeichnete Softwareebene angezeigt wird, die die Schnittstelle zu der Software bereitstellt, die das Selbstdiagnoseprogramm der Bibliothek 50 zyklisch und regelmäßig aufruft. Das Testsegment 202 antwortet durch Senden einer Gut-/Schlecht-Signatur.
Die Struktur eines Testsegments 202 ist wiederum von einem modularem Typ, der durch aufeinanderfolgende Stufen organisiert ist, und umfasst eine Präambel 203 und eine Postambel 204, die in der Regel in einer Hochsprache (ANSI-C) geschrieben, d. h. unabhängig von der Architektur des Mikroprozessors, der einem Selbsttest unterzogen wird, sind. Die Präambel 202 und die Postambel 204 sind für die Funktionen einer Schnittstelle zu der höheren Schicht, eine Verwaltung der globalen Variablen und die Ergebnisse des Tests dediziert, die mit Techniken zu verwalten sind, die eine Erkennung jedes Fehlers ermöglichen, der das Ergebnis des Tests beeinträchtigen könnte, wenn dies von den Softwaremodulen verarbeitet wird.
Das Kernstück des Testsegments 202 ist durch eine Reihe von Modulen 206 dargestellt, die in niederem Code, üblicherweise einem Assemblierer (Assembler), spezifisch für die Architektur des Mikroprozessors geschrieben sind, der in der Figur als „ASM-Kerncode“ bezeichnet ist. Die Module 206 sind die Teile, die den Selbsttest insoweit tatsächlich durchführen, als sie die verschiedenen logischen und arithmetischen und sequentiellen Einheiten des Mikroprozessors derart gezielt stimulieren, dass ein möglicher Ausfall des Mikroprozessors selbst aktiviert und beobachtbar gemacht wird. Die verschiedenen Module 206 in niederem Code können durch in Hochsprache geschriebene Routinen 205 verwaltet werden. Das Testsegment 202 umfasst einen Signaturrechner 207 zum Erzeugen der Gut-/Schlecht-Signaturen am Ende der Prüfungen über die Module 205 und 206. Die Testsegmente 202 umfassen mehrere Module 206 in niederem Code zum Erhalten eines Deckungsgradziels für die Ausfälle unter Berücksichtigung eines gegebenen Satzes von durch die Sicherheitsanalyse definierten Ausfallmöglichkeiten.
Es folgt nun eine Beschreibung der Verteilung der Selbsttestvorgänge, insbesondere der Diagnoseselbsttestvorgänge A_stl, zwischen den STLs 50 auf den Prozessoren 11 und den Logikkomponenten 51 auf dem Steuermodul 15.
Der Betrieb der STLs 50 basiert auf der Fähigkeit eines Mikroprozessors, sich selbst zu testen durch Ausführen von Codesequenzen derart, dass die verschiedenen Logiken, aus denen er gebildet ist, bestmöglich einbezogen werden, und Erzeugen von Zwischenergebnissen, die, auf geeignete Weise derart akkumuliert, dass mögliche Fehler in den Zwischenergebnissen nicht aufgehoben werden können, dann Signaturen erzeugen können, die, wenn sie mit den gleichen Werten verglichen werden, die unter Annahme der Abwesenheit von Fehlern zuvor berechnet wurden, die höchste Zuverlässigkeit einer Erkennung eines möglichen Ausfalls liefern, der die zu testende Logik beeinträchtigt haben könnte. Die Fähigkeit, den Ausfall zu aktivieren und zu erkennen, hängt sowohl von der Fähigkeit des Tests der STL 50 zum Aktivieren des Ausfalls als auch von dem numerischen Verfahren ab, das zum Akkumulieren der Zwischenergebnisse derart verwendet wird, dass ein möglicher Unterschied in den Zwischenergebnissen während des Akkumulationsprozesses nicht aufgehoben werden kann. Aus Gründen der Klarheit: Es kann verschiedene Arten von Ergebnissen geben, die von den STLs 50 im Mikroprozessor erzeugt werden, nämlich Zwischenergebnisse, Akkumulationen und Signaturen, wobei die letzteren zwei gemäß den Ausführungsformen häufig auf dasselbe hinauslaufen. Akkumulation ist in der Regel notwendig, um die Anzahl von Zwischenergebnissen zu reduzieren, die andernfalls nicht handhabbar wären. Im Folgenden wird der Einfachheit halber auf die Zwischenergebnisse Bezug genommen, wobei in dieser Definition alle drei oben genannten Ergebnisarten eingeschlossen sind.
Die Erkennung einer Aktivierung des Ausfalls in dem einzelnen Mikroprozessor kann durch zwei verschiedenartige Mechanismen erfolgen:

a) Erkennung durch die Selbsttestsoftware selbst, die durch Erkennen eines Unterschieds beim Vergleich der Diagnoseselbsttestdaten D_stl mit den vorberechneten Daten, d. h. den erwarteten Ergebnissen D_stla, den Fehler bestimmt und programmatisch Gegenmaßnahmen ergreift, wobei der erkannte Fehler angezeigt wird; dies ist der Regelfall, wenn ein Ausfall nicht die für eine Steuerung des Programmablaufs verantwortliche Logik beeinträchtigt, sondern nur den Teil einer arithmetischen/logischen Berechnung der Daten;
b) Stimulation, die durch Ausführung der Tests der STLs 50 bestimmt wird, zusammen mit Auftreten eines Ausfalls, wodurch ein Fehler in der Ausführungssequenz des Programms P bestimmt wird, so dass beispielsweise Steuergrenzen für die Ausführungszeit t verletzt werden, die von einem externen Watchdog kontrolliert werden, der den Fehler meldet; dies ist der Regelfall, wenn ein Ausfall die Logik beeinträchtigt, die für die Steuerung des Programmausführungsablaufs verantwortlich ist; es ist anzumerken, dass der Watchdog eine dedizierte Komponente des Systems sein kann, oder aber ein weiterer Kern, der durch Durchführen einer Gegenprüfung ein fehlerhaftes funktionales oder zeitliches Verhalten einer Ausführung des Tests der STLs 50 auf dem betreffenden Mikroprozessor erkennen kann.

In dem obigen Zusammenhang erzeugen die in 3 angezeigten STLs 50 Diagnoseselbsttestdaten D_stl, die Daten bezüglich des Selbsttestprozesses oder aber Zwischenergebnisse (oder Teilergebnisse, Akkumulationen von Zwischenergebnissen oder aber Ergebnisse des Vergleichs von Zwischenergebnissen mit erwarteten Werten) umfassen, die an ein externes Modul, das Steuermodul 15, gesendet werden, das einen Quervergleich der Diagnoseselbsttestdaten D_stl (Mechanismus a) mit einer Steuerung des Ausführungsablaufs durchführt (wobei auf diese Weise die Funktionen des externen Watchdogs im Zusammenhang mit dem Mechanismus b der Stimulation der STL-Tests wie oben beschrieben durchgeführt werden).
Die STLs 50 erzeugen darüber hinaus die gemessenen Werte, einschließlich Systemkonfigurationen, d. h. die Systemselbsttestdaten D_sys.
Die STLs 50 erzeugen entsprechende Nachrichten MC, die die oben genannten Diagnoseselbsttestdaten D_stl und Systemselbsttestdaten D_sys enthalten, an das Steuermodul 15, das über die Logikkomponenten 51 die oben genannten Nachrichten verarbeitet, die von den auf den physischen Kernen C1, ..., Cm des Multiprozessors 10 ausgeführten STLs 50 erzeugt werden.
Eine solche Verarbeitung, die in den Logikkomponenten 51 durchgeführt wird, ist zum Ausführen der folgenden Vorgänge ausgelegt:
Durchführen einer Gegenprüfung an den Diagnoseselbsttestdaten D_stl
durch Implementieren einer (kanalinternen) Ausführungsablaufprüfung der Ergebnisse des Vergleichs, der von den Mikroprozessoren C1, ..., Cm durchgeführt wurde
und durch Vornehmen einer (kanalübergreifenden) Gegenprüfung des aus dem Verarbeiten der Tests der Bibliotheken 50 auf jedem der Mikroprozessoren C1, ..., Cm erhaltenen Teilergebnisses.
Durchführen einer Prüfung der richtigen zeitlichen Ausführung durch Prüfen, ob die Ergebnisse des Vergleichs, d. h. die Teilergebnisse, in vorbestimmten Zeitfenstern (gekennzeichnet durch eine maximale und minimale Latenz) und gemäß einer voreingestellten Reihenfolge gesendet und empfangen werden; dies ermöglicht die Erkennung möglicher Fehler bei der Ausführung des Ablaufs, wie bereits erwähnt, als Mechanismen der Erkennung der Fehler im Ablauf einer Ausführung der Tests der STLs 50, die die Unterstützung einer externen Komponente erfordert; und
Durchführen einer Prüfung, ob die gemessenen Werte D_sys tatsächlich vordefinierten Variabilitätsbereichen für die zu messenden Größen (in der Regel Betriebsspannung und Temperatur) angehören; zusätzlich können Prüfungen einer Konsistenz der Systemkonfigurationen durchgeführt werden, die von den STLs 50 erhalten werden und die den Status des Systems während der Ausführung darstellen.
Die Verletzung einer der soeben beschriebenen Prüfungen zieht eine Erzeugung eines Alarms AL durch das Steuermodul 15, wie in 6 gezeigt, und die Implementierung der Gegenmaßnahmen, die für die Sicherheitsanwendung erforderlich sind, nach sich. Die oben genannten Alarmerzeugungsfunktionen senden Alarme an ein Modul 16, das ein Modul ist, das Systemressourcen in dem System 10 steuert und beispielsweise ein Rücksetzen oder ein Trennen der Versorgungsspannung implementieren bzw. in jedem Fall das Erreichen eines sicheren Status des Systems erzwingen kann.
Ein Beispiel für einen Ablauf von Vorgängen, die der Selbsttestbibliothek 50 zugeordnet sind, ist Folgendes:
Wie auch aus 6 in Bezug auf das Modul 116 hervorgeht, führt das Steuermodul 15 mehrere Prüfungen von Wert, Reihenfolge, Zeit (Latenz, Versatz und absolute Eingangszeit unter Verwendung von Zeitstempeln) und Bereichen (in dem Modul 114 mit Vergleichseinrichtung) aus. Insbesondere werden die folgenden Prüfungen an den Selbsttestdaten D_stl, D_chk, D_sys durchgeführt:

• die Prüfung der Werte verifiziert, dass die Zwischenergebnisse gleich sind oder dass die Ausführung der Anwendungsbedingungen oder der LBISTs eingehalten wird;
• die Prüfung der Reihenfolge verifiziert, dass die Reihenfolge der Nachrichten gemäß Zählern in der Nachricht korrekt ist;
• bei der Prüfung der Eingangszeiten wird die Zeit des Eingangs der Nachricht mit einer erwarteten Minimal- und Maximalzeit in dem aktuellen Ausführungszyklus und/oder mit der entsprechenden Nachricht von einem anderen Kern verglichen; und
• die Prüfung der Bereiche verifiziert, dass der gemessene Wert dem vordefinierten Bereich R_att angehört.

Jede Verletzung der Prüfungen wird durch das Steuermodul 15 verwaltet, das einen Fehler meldet und dann Alarme an das Modul 16 sendet.
Nun folgt eine ausführlichere Beschreibung der Anwendungsvergleichssoftwarekomponenten 60 und der komplementären Logikmodule 61, die in dem Steuermodul 15 vorhanden sind.
Somit sind, wie in 3 angezeigt, in den auf den virtuellen Maschinen V1, ..., Vn ausgeführten Unterprogrammen P1, ..., Pn Anwendungsvergleichssoftwarekomponenten 60 vorhanden, die die ASL (Application Safety Layer - Anwendungssicherheitsebene) implementieren, d. h. Methoden einer Erkennung von Teilergebnissen der Verarbeitung der Unterprogramme P1, ..., Pn oder aber einer Ausführung von Anwendungsbedingungen oder von LBISTs. Die Anwendungsvergleichssoftwarekomponenten 60 führen auch eine Akkumulation der oben genannten Teilergebnisse durch und erfassen Unterschiede der akkumulierten Ergebnisse (zum Beispiel die Akkumulation einer zyklischen Redundanzprüfung (CRC, Cyclic Redundant Check)) durch das Programm mit der Sicherheitsfunktion SF. Die Anwendungsvergleichssoftwarekomponenten 60 organisieren auch die Daten der akkumulierten Ergebnisse und der Unterschiede oder der Anwendungsbedingungen oder der LBISTs im Rahmen von Anwendungsdaten D_chk gemäß dem Protokoll PL, das ebenfalls Gegenstand des hierin beschriebenen Verfahrens ist.
Wie bereits erwähnt, weisen auch die Anwendungsvergleichssoftwarekomponenten 60 entsprechende Anwendungsvergleichslogikkomponenten 61 in dem Steuermodul 15 auf. Das Steuermodul 15 führt Quervergleiche der Anwendungsselbsttestdaten D_chk durch, insbesondere durch Prüfen der Konsistenz der Informationen auf Grundlage der Werte der Anwendungsselbsttestdaten D_chk, ihrer Reihenfolge und der Uhrzeit, die in den Paketen von Anwendungsselbsttestdaten D_chk angezeigt werden, die durch die Anwendungsvergleichssoftwarekomponenten 60 erzeugt werden.
Nunmehr wird der Kommunikationsprotokoll PL ausführlicher beschrieben. Die Organisation der Selbsttestvorgänge A_stl, A_sys, A_chk sieht die Definition verschiedener Typen von Nachrichtensätzen in dem Protokoll PL gemäß den Softwareebenen L2, ..., L4, die die Nachricht erzeugt haben, und dem Zweck der Nachricht selbst vor.
Die folgenden logischen Kanäle oder virtuellen Kanäle (VC, Virtual Channels) sind definiert. Jeder der logischen Kanäle VC trägt Nachrichten, die von höchstens zwei verschiedenen physischen Kanälen stammen, die durch ID0 und ID1 bezeichnet sind:

VC0: Sicherheits-VC - logischer Sicherheitskanal mit Ursprung auf der Anwendungsebene L4 durch das Programm mit der Sicherheitsfunktion SF (physische Kanäle mit den Kennungen ID0 und ID1);
VC1: Supervisor-VC - logischer Kanal mit Ursprung auf der Supervisor-Ebene L2 oder auf der Anwendungsebene L4, je nach Implementierung (physische Kanäle mit der Kennung ID0); und
VC2: Q&D - logischer Qualitäts- und Dienstkanal mit Ursprung auf der Supervisor-Ebene L2 oder auf der Virtuelle-Maschinen- und Betriebssystem-Ebene L3, je nach Implementierung, der Wartungsvorgänge auf dem System durchführt (physische Kanäle mit den Kennungen ID0 und ID1).

In der bevorzugten Ausführungsform mit zwei physischen Kanälen gilt:

die logischen Kanäle VC0 und VC2 unterstützen zwei physische Kanäle ID0 und ID1, die somit Sicherheitskanäle sind; und
der logische Kanal VC1 unterstützt nur einen physischen Kanal, ID0.

Die obige Definition der logischen Kanäle VC spiegelt sich in einem bestimmten Merkmal des Steuermoduls 15 wider, so dass es möglich ist, programmierbare Prüfungen und Alarme für jede der Kategorien der Sätze von Nachrichten zu konfigurieren.
In einer bevorzugten Ausführungsform des Steuermoduls 15 ist die Reihenfolge der Übertragung der verschiedenen logischen Kanäle VC, beispielsweise VC0, VC1 und VC2, vorbestimmt und festgelegt. 4 zeigt ein Beispiel einer möglichen Ausführungsform des Kommunikationsprotokolls PL, die durch die Vergleichslogik des Steuermoduls 15 widergespiegelt wird. Dargestellt ist insbesondere der Kommunikationskanal, in dem in einem Diagnosetestintervall DTI die logischen Kanäle VC0, VC1, VC2 gemäß dem Kommunikationsprotokoll PL gesendet werden:

logischer Kanal VC0, für die physischen Kanäle ID0, ID1 - dieser trägt die Daten der Sicherheitsfunktion SF, d. h. die Anwendungsselbsttestdaten D_chk, deren Konsistenz mit den Komponenten 61 des Steuermoduls 15 getestet wird: homologe Nachrichten, die zu den Kanälen ID0 und ID1 gehören, werden miteinander verglichen, und der Vergleich muss das korrekte Ergebnis liefern, d. h. Daten, die zum Beispiel bis auf Unterschiede, wie zum Beispiel Codierungsunterschiede, gleich sind; die Daten könnten tatsächlich auf unterschiedliche Art codiert sein (zum Beispiel um einen Kanal ergänzt), um die Wahrscheinlichkeit gemeinsam verursachter Fehler zu reduzieren;
logischer Kanal VC1 für den physikalischen Kanal ID0 - dieser trägt die Diagnoseselbsttestdaten D_stl der Diagnoseselbsttestbibliothek 50, die von der Supervisor-Ebene L2 stammen; und
logischer Kanal VC2 für die physikalischen Kanäle ID0, ID1 - dieser trägt die gemessenen Werte, d. h. die Systemselbsttestdaten D_sys, wie z. B. einen Wert der Temperatur, Spannung usw.

Wiederum Bezug nehmend auf 4 ist anzumerken, dass die Gesamtzeit der Übertragung auf dem Nachrichtenkommunikationskanal MC das Diagnosetestintervall DTI des Systems insofern nicht überschreiten darf, als ungünstigenfalls die Übertragung kontinuierlich und mit der gleichen Zykluszeit T_cyc wie der des Programms P stattfinden muss.
Die von dem Steuermodul 15 durchgeführten Prüfungen der Sequenzen Sq von Nachrichten sind in dem Diagramm von 5 beschrieben. In der ersten Zeile ist die hierarchische Ebene, L, und das betreffende Element, ob Prozessormodul C1 oder C2 oder aber Supervisormodul 17, angegeben. Die Nachrichten MC, die mit den Kennungen ID0 und ID1 markiert sind, sind in verschiedenen Nachrichtensätzen Sq (Sq1 und Sq2) gekapselt und in den verschiedenen logischen Kanälen VC beinhaltet. Sie werden von dem Steuermodul 15 zwei Arten von Prüfungen unterzogen:

kanalinternen Prüfungen ITC (InTra-Channel) (in 5 nicht dargestellt), die auf Nachrichten angewendet werden, die zu ein und demselben logischen Kanal VC und zu ein und derselben Kennungs-ID gehören; und
kanalübergreifenden Prüfungen INTC (INTer-Channel), die auf Nachrichten MC angewendet werden, die zu verschiedenen logischen Kanälen VC gehören (zum Beispiel erste Nachricht Sq1 0,0 von ID0 verglichen mit erster Nachricht Sq1 0,1 von ID1, zweite Nachricht Sql 2,0 von ID0 verglichen mit zweiter Nachricht Sql 2,1 von ID1 usw.); diese kanalübergreifenden Prüfungen INTC werden zusätzlich zu und auf einer höheren Ebene als die kanalinternen Prüfungen ITC durchgeführt, die darauf abzielen, die Konsistenz der von den einzelnen Kanälen stammenden Nachrichten zu verifizieren.

Es ist zu betonen, dass 5 die Nachrichten nach ihrem Ursprung und nicht nach der zeitlichen Sequenz, mit der sie übertragen werden, darstellt.
Die Struktur des beschriebenen Kommunikationsprotokolls PL und der Prüfungen, die an den Sätzen der Nachrichten durchgeführt werden, findet eine direkte Entsprechung in der funktionalen Architektur des Steuermoduls 15 bis hin zu seiner implementierungsbezogenen Mikroarchitektur, wie nachfolgend unter Bezug auf 6 beschrieben ist.
Wie bereits erwähnt, sind Implementierungen des Steuermoduls 15 sowohl eines Softwaretyps als auch eines Hardwaretyps mit dedizierter Logik möglich, beispielsweise in einer FPGA-Vorrichtung oder aber in einer ASIC.
6 zeigt die Hauptfunktionen, die in das Steuermodul 15 integriert sind.
Das Schema von 6 stellt dedizierte Hardwareeinheiten dar, kann jedoch gleichermaßen funktionale Einheiten darstellen, die zum Beispiel zum Bereitstellen einer Implementierung als eingebettete Software in einem Prozessormodul, das getrennt von dem Multiprozessor 10 ist, oder aber als dedizierte Hardware in einer FPGA-Vorrichtung oder aber in einer ASIC verwendet werden. Rein beispielhaft zeigt 9 eine mögliche Implementierung der vorgeschlagenen Architektur auf einem System-on-Chip (SoC) 1000, insbesondere mit einem symmetrischen Zweikernprozessor, bei dem zwei Prozessoren 11 in einem „Hardmakro“ 1010 enthalten sind, wobei das Steuermodul 15 ein Softwaremodul ist, das auf einem redundanten Prozessor ausgeführt wird, der in einem programmierbaren Teil 1020 (FPGA) des SoC 1000 implementiert ist.
Um zu 6 zurückzukehren, ist mit 112 eine Busschnittstelle zu dem Kommunikationsbus 12 bezeichnet, die ein Konfigurations- und Statusschnittstellenmodul 112c und Puffer 112b für die Nachrichten der verschiedenen Kanäle ID0 und ID1 umfasst. Sie umfasst ferner ein Modul 112a für eine CRC-Prüfung der eingehenden Pakete.
Mit 113 ist ein Zeitgebermodul zum Prüfen der zeitlichen Steuerung bezeichnet, insbesondere zum Prüfen, ob die Ausführungszeit innerhalb der für die Prüfung festgelegten Grenzen bleibt.
Mit 114 ist ein Modul für die kanalübergreifenden Prüfungen (Vorgänge INTC) bezeichnet, das eine Vergleichseinrichtung 114a für einen kanalübergreifenden Vergleich der Daten der Kanäle und einen Hardware-Fehlerinjektor 114b umfasst.
Mit 116 ist ein Modul für die kanalinternen Prüfungen (Vorgänge ITC) bezeichnet, das die Module 116a, 116b, 116c zum Prüfen der Eingangszeit, der Reihenfolge und des Wertes der eingehenden Daten umfasst.
Die Daten werden den oben genannten Modulen 114 und 116 durch ein Ereignisschleifenmodul 115 zugeführt, das vorzugsweise ein Speicherdirektzugriffsmodul (DMA, Direct Memory Access) 116a und ein Nachrichtensteuermodul 116b umfasst.
Mit 111 ist eine Fehlersteuerung bezeichnet, die über einen programmierbaren Ereignis-Router Alarme an das Modul 16 sendet. Die Informationen und die Signale bezüglich der Daten und Alarme, die sich von anomalen Bedingungen ableiten, die durch die Vergleiche zwischen den physikalischen Kanälen ID0 und ID1 oder mit den erwarteten Wertebereichen oder vorberechneten Ergebnissen in den Modulen 114 und 116 erkannt werden, werden getrennt gehalten (aus logischer, elektrischer und physikalischer Sicht), wie von den Referenzsicherheitsstandards gefordert (siehe z. B. IEC 61508 mit Empfehlungen zur Entwicklung von Sicherheitssystemen). Wiederum mit Bezug auf 6 werden die Alarme durch eine gestrichelte Linie angezeigt. Die angezeigten Alarmquellen erkennen Anomalien durch folgende Vergleiche:

kanalübergreifende Prüfungen INTC (Modul 114) - diese Art von Vergleich beinhaltet Vergleiche von Werten, zum Beispiel Werten, von denen erwartet wird, dass sie gleich sind, die von verschiedenen Kernen des Multiprozessors berechnet werden, und Vergleiche mit vorberechneten Erwartungswerten; sie erzeugen einen kanalübergreifenden Alarm Alintc;
kanalinterne Prüfungen ITC (Modul 116) - diese Art von Vergleich beinhaltet Vergleiche mit vorberechneten Erwartungswerten oder auch ein Prüfen anhand eines vordefinierten Referenzbereichs (z. B. von Betriebstemperatur oder Spannung); sie erzeugen einen kanalinternen Alarm Alitc;
Prüfungen der Zeitabläufe (Modul 113), zum Beispiel, ob die Ausführungszeit innerhalb der für die Prüfung eingestellten Extremwerte bleibt; sie erzeugen einen Zeitalarm Alt; und
Anomalien bei der Struktur und Zusammensetzung der Nachricht vom formalen Standpunkt; in dem betrachteten Beispiel das Fehlschlagen einer Prüfung eines CRC-Typs, die durch das CRC-Modul 112a an dem Text einer Nachricht am Eingang zu der Schnittstelle 112 durchgeführt wird, wobei diese Prüfung einen Alarm ALc erzeugt.
Schließlich umfasst das Steuermodul 15 ein Fehlerinjektionsmodul 117.

Wie aus der Beschreibung der 6 zu ersehen, sind die Logikmodule 51 und 61 nicht separat implementiert, aber die für jedes der Logikmodule erforderlichen Funktionen werden im Wesentlichen von den Modulen 114, 116 und 113 ausgeführt.
Wiederum rein beispielhaft zeigt 10 eine mögliche Implementierung der vorgeschlagenen Architektur auf einer Kombination aus zwei separaten Komponenten, einem SoC (System-on-Chip) 1030 insbesondere mit einem symmetrischen Multiprozessor mit vier Prozessormodulen 11, wobei das Steuermodul 15 ein Softwaremodul ist, das auf einem redundanten Prozessor 1050 ausgeführt wird, der in einer ASIC oder einem FPGA 1040 implementiert ist, der über PCI 1060 mit dem SoC 1030 verbunden ist.
Bei der Berechnung des von den Selbsttestvorgängen A_chk abgeleiteten Deckungsgradziels wird das Anwendungsdeckungsgradziel k_chk im Fall eines Vergleichs von Zwischenergebnissen beispielsweise als eine Funktion der Datenmenge q, die bei jedem Vergleich in Bezug auf die Gesamtmenge ausgetauscht wird, und als Datenaustauschperiode t (deren Umkehrung die Datenaustauschfrequenz f ist) in Bezug auf eine Zielzeit T bestimmt - in der Regel entsprechend der PST (Prozesssicherheitszeit) oder dem FTTI (Fehlertoleranzzeitintervall) berechnet, wie durch die oben genannten Standards für funktionale Sicherheit definiert: $k_{chk} = min (1, q \cdot T/t)$
Die Datenaustauschperiode t entspricht der sicheren Ausführungszeit Ts.
Aus den Gleichungen (1) und (2) geht hervor, dass die Deckungsgrade k1, k2, k12 von dem Wert des Vergleichsdeckungsgrads k_chk abhängen und dass das Ausfallwahrscheinlichkeitsziel eine Funktion von k1, k2, k12 ist. Folglich gilt auch, dass bei einem gegebenen Ausfallwahrscheinlichkeitsziel g die Werte der Menge der ausgetauschten Daten q und der Frequenz f des Austausches der Daten so bemessen sind, dass der Vergleichsdeckungsgrad k_chk einen Wert annimmt, durch den, wenn er in die Gleichungen (1) und (2) eingefügt wird, das Ausfallwahrscheinlichkeitsziel g eingehalten wird.
Das hierin beschriebene Verfahren zielt jedoch auf Anwendungen ab, bei denen es erforderlich sein kann, die gesamte Rechenleistung der verfügbaren Prozessoren auszunutzen. Folglich sieht das erfindungsgemäße Verfahren ein Ausführen der Diagnoseselbsttestvorgänge A_stl, die Diagnoseselbsttests durchführen, und der Vorgänge A_sys eines Selbsttests von gemessenen Systemwerten gemäß dem bisher Beschriebenen vor. Die oben genannten Diagnoseselbsttestvorgänge A_stl und Vorgänge A_sys eines Selbsttests von gemessenen Systemwerten identifizieren jeweilige Deckungsgradziele k_stl und k_sys, die, wenn sie beispielsweise in Gleichungen wie Gleichung (2) eingefügt werden, den Deckungsgrad der Programme P1, ..., Pn bestimmen. Angesichts der Beiträge der Deckungsgradziele k_stl und k_sys wird der verbleibende Beitrag k_chk, d. h. das Deckungsgradziel, das durch die anwendungsbezogenen Selbsttests sichergestellt wird, um das Ausfallwahrscheinlichkeitsziel g einzuhalten, unter Verwendung von anwendungsbezogenen Selbsttestvorgängen A_chk erhalten, die weniger Rechenleistung beanspruchen.
Gemäß einer ersten Ausführungsform umfassen die oben genannten anwendungsbezogenen Selbsttestvorgänge A_chk, die weniger Rechenleistung beanspruchen, Vorgänge A_cou eines Prüfens einer periodischen Ausführung der Anwendungsbedingungen. Der Vorteil eines Vorgangs mit den Anwendungsbedingungen statt mit den Zwischenprogrammen besteht darin, dass in der Regel (wie in 11A dargestellt) die anwendungsbezogenen Selbsttestvorgänge A_chk über einen Vergleich von Zwischenprogrammen einen anwendungsbezogenen Deckungsgrad k_chk liefern, der sich mit k_stl deutlich überschneidet und somit eine „Verschwendung“ von Rechenressourcen mit sich bringt. Stattdessen wird der Deckungsgrad durch die Vorgänge A_cou eines Prüfens einer periodischen Ausführung der Anwendungsbedingungen bestimmt, um die oben genannte Überlappung zu begrenzen (siehe beispielsweise 11B) und somit die Verschwendung von Rechenressourcen zu begrenzen.
Somit umfassen die anwendungsbezogenen Selbsttestvorgänge A_chk Selbsttestvorgänge A_cou eines Prüfens einer periodischen Ausführung von Anwendungsbedingungen, unter Berücksichtigung der Tatsache, dass die Programme P1, P2, ..., Pn (oder eine Teilmenge davon) erforderlich sind, um gegebene CoUs (Conditions of Use - Anwendungsbedingungen) derart einzuhalten, dass, sofern sie mindestens einmal in der PST oder dem FTTI gemäß den oben genannten Standards für funktionale Sicherheit eingehalten werden, ein entsprechendes Deckungsgradziel k_cou sichergestellt ist, das die folgende Bedingung erfüllt: $k_{stl} \cup k_{cou} = k_{chk} \cup k_{stl}$
d. h. die Bedingung, dass die Vereinigung des Diagnoseselbsttestdeckungsgrads k_stl und der Deckungsgrad für die Anwendungsbedingen k_cou gleich der Vereinigung der Deckungsgrade k_chk und k_stl ist, die durch den anwendungsbezogenen Selbsttestvorgang bzw. durch den Diagnoseselbsttestvorgang gegeben sind.
Die oben genannten CoUs können beispielsweise in zwei Klassen eingeteilt werden:

„Klasse 1“ - Anwendungsbedingung, bei der die Programme eine Prüfung des Programmablaufs beinhalten, wobei dies eine im Stand der Technik bekannte Technik ist;
„Klasse 2“ - Anwendungsbedingung, bei der die Programme eine oder mehrere der folgenden bekannten Techniken beinhalten:
- Prüfung einer Konsistenz der Daten, zum Beispiel durch Vergleichen von Daten, die von verschiedenen Eingängen des Prozessors stammen;
- Kapselung der Daten mit einem Code, beispielsweise eines CRC-Typs;
- periodische Ausführung eines Tests unter Verwendung fester Datenmuster; und
- periodische Wiederholung von Teilen der Unterprogramme.

Rein beispielhaft und zur weiteren Verdeutlichung der Bedeutung des Begriffs „Anwendungsbedingungen“ folgt nun eine ausführliche Beschreibung einer CoU der Klasse 2 (in Bezug auf die Kapselung der Daten mit einem Code):
„Während jedes FTTI muss das Programm zwischen dem Prozessor und dem Speicher mindestens ein Datenpaket übertragen, das mindestens vier 64-Bit-Daten enthält, das an mindestens vier aufeinanderfolgenden Speicheradressen zu speichern ist. Die Quelladresse, die Adresse des Adressaten und die Gesamtanzahl der übertragenen Bytes müssen Vielfache von 64 Bytes sein. Das Datum muss mit einem Code (z. B. eines CRC-Typs) gekapselt sein. Der Code ist im Datum enthalten. Wenn das Paket gelesen wird, muss das Programm den CRC neu erzeugt und mit dem im gelesenen Wort enthaltenen vergleichen.“
Es ist anzumerken, dass die Begriffe „mindestens“ und „muss“ in der Beschreibung „Bedingungen“ darstellen, die der Programmierer einhalten muss. Es ist auch anzumerken, dass der Ausdruck „während jedes FTTI“ in der Beschreibung die Periodizität anzeigt.
Folglich werden aus der obigen ausführlichen Beschreibung einer CoU der Klasse 2 beispielsweise unter anderem die Bedingungen CN1, CN2, CN3 extrahiert:

CN1 = „Übertragung zwischen dem Prozessor und dem Speicher mindestens eines Datenpakets, das mindestens vier 64-Bit-Daten enthält“
CN2 = „Paket [...], das an mindestens vier aufeinanderfolgenden Speicheradressen zu speichern ist“
CN3 = „die Quelladresse, die Adresse des Adressaten und die Gesamtanzahl der übertragenen Bytes müssen Vielfache von 64 Bytes sein“,
wobei jede dieser Bedingungen einer Bedingung von Periodizität zugeordnet ist, d. h. einer Ausführung während jedes FTTI.

Im Hinblick auf die Selbsttestvorgänge eines Prüfens einer Ausführung von Anwendungsbedingungen A_cou stellt die hierin beschriebene Lösung auch eine Technik bereit, die ein Prüfen, ob diese Anwendungsbedingungen in den Programmen P1, P2, ..., Pn tatsächlich enthalten sind, ermöglicht.
Unter Bezugnahme auf 7 basiert diese Technik auf der Tatsache, dass:

• jedes Programm P1, P2, ..., Pn, sobald es eine CoU ausführt, dies der Testschnittstelle 201 (über eine speziell bereitgestellte Variable) berichtet;
• die Testschnittstelle 201 bei der Programmierung so konfiguriert wird, dass bekannt ist, wie viele Anwendungsbedingungen mindestens einmal in der PST oder dem FTTI gemäß den oben genannten Standards für funktionale Sicherheit eingehalten werden müssen;
• die Testschnittstelle 201 auf Grundlage der oben genannten Informationen berichtet, ob die Anzahl der Anwendungsbedingungen, die mindestens einmal in der PST oder dem FTTI eingehalten werden, gleich der programmierten Anzahl ist, wobei diese Informationen als Selbsttestdatum D_chk mit einem Selbsttestdatum für die Anwendungsbedingungen D_cou geliefert werden.

14 veranschaulicht in diesem Zusammenhang eine mögliche vereinfachte Variante der funktionalen Sicherheitsarchitektur von 3, in der jedes Unterprogramm P1, P2, ..., Pn, sobald es eine CoU ausführt, dies über die Anwendungsvergleichssoftwaremodule 60 an die Diagnoseselbsttestbibliotheken 50 berichtet, die die Testschnittstelle 201 umfassen. Die Testschnittstelle 201 sendet dann das entsprechende Selbsttestdatum für die Anwendungsbedingungen D_cou in den Überwachungs- und Steuernachrichten MC an die Verarbeitungs- und Vergleichseinheit, d. h. das Steuermodul 15. In der Ausführungsform der 4 ist der Einfachheit halber vorgesehen, nur die Selbsttest-Logikkomponenten 51 zum Prüfen auch der Selbsttestdaten für die Anwendungsbedingungen D_cou zu verwenden. Die Selbsttestvorgänge A_cou können in jedem Fall auch über die komplette Architektur von 3 implementiert werden.
Gemäß einer weiteren Ausführungsform umfassen die oben genannten anwendungsbezogenen Selbsttestvorgänge A_chk, die weniger Rechenleistung beanspruchen, Vorgänge eines Prüfens einer periodischen Ausführung von LBISTs (Logic Built-in Self-Tests - Logischen integrierten Selbsttests) A_bst.
Auch hier verhindert der Deckungsgrad für die Vorgänge eines LBIST-Typs A_bst ein Überlappen aufgrund des Vergleichs von Zwischenprogrammen, wie unter Bezugnahme auf 11B beschrieben, und begrenzt somit die Verschwendung von Rechenressourcen.
Somit umfassen die anwendungsbezogenen Selbsttestvorgänge A_chk Vorgänge A_bst eines Prüfen einer Ausführung von LBISTs, unter Berücksichtigung der Tatsache, dass die Hardware des Prozessors periodisch sogenannte LBIST-Schaltungen, die Fachleuten auf dem Gebiet an sich bekannt sind, derart einschalten muss, dass, wenn sie mindestens einmal in der PST oder dem FTTI gemäß den oben genannten Standards für funktionale Sicherheit betrieben werden, ein LBIST-Deckungsgrad k_bst derart sichergestellt ist, dass gilt: $k_{stl} \cup k_{bst} = k_{chk} \cup k_{stl}$
d. h. eine Bedingung, bei der die Vereinigung des Diagnoseselbsttestdeckungsgrads k_stl und des LBIST-Deckungsgrads k_bst gleich der Vereinigung der Deckungsgrade k_chk und k_stl ist, die durch den Selbsttestvorgang A_chk bzw. durch den Diagnoseselbsttestvorgang A_stl gegeben sind.
Betreffend die LBIST-Selbsttestvorgänge A_bst, die entsprechende von dem Modul 15 zu prüfende Selbsttestdaten D_bst erzeugen, sieht die hierin beschriebene Lösung Folgendes vor:

jedes Programm P1, P2, ..., Pn, benachrichtigt, sobald es entscheidet, dass ein geeigneter Zeitpunkt für eine Unterbrechung gegeben ist (zum Beispiel weil die Funktion, die es ausführt, zu diesem bestimmten Zeitpunkt von der Anwendung nicht verwendet wird) die entsprechende physische Ebene L1, dass der LBIST-Vorgang gestartet werden kann;
an diesem Punkt wird die entsprechende Hardwareschaltung, die den LBIST-Test ausführt, beispielsweise die in 15 dargestellte und im Folgenden beschriebene Schaltung 41 (in der Regel eine Maschine eines LFSR- oder MISR-Typs, die Fachleuten auf dem Gebiet an sich bekannt ist), aktiviert und erzeugt - nach einer gewissen Zeit - das Ergebnis des LBIST-Tests D_bst für den betreffenden Kern;
dieses Ergebnis wird (z. B. in Form einer „Go-/No-Go“-Warnung) an die Testschnittstelle 201 weitergegeben;
auf Grundlage der oben genannten Informationen berichtet die Testschnittstelle 201, ob alle LBIST-Selbsttestvorgänge A_bst ausgeführt wurden und mit welchem Ergebnis, wobei diese Informationen als Selbsttestdatum D_chk in der Nachricht MC mit ggf. einem Selbsttestdatum für die Anwendungsbedingungen D_cou geliefert werden.

15 zeigt in diesem Zusammenhang eine mögliche vereinfachte Variante der funktionalen Sicherheitsarchitektur von 3, in der jedes Programm P1, P2, ..., Pn, sobald es annimmt, dass es einen LBIST-Vorgang ausführen kann, dies über die Anwendungsvergleichssoftwaremodule 60 auf der Ebene L4 an die entsprechende Ebene L1 berichtet, in der eine LBIST-Schaltung 41 vorhanden ist. Sobald die LBIST-Schaltung 41 den Vorgang abgeschlossen hat, berichtet sie dies an die Diagnoseselbsttestbibliotheken 50, die die Testschnittstelle 201 umfassen. Die Testschnittstelle 201 sendet dann das entsprechende Selbsttestdatum D_bst in den Überwachungs- und Steuernachrichten MC an die Verarbeitungs- und Vergleichseinheit, d. h. das Steuermodul 15. Hierin ist in der Ausführungsform von 15 der Einfachheit halber vorgesehen, nur die Selbsttest-Logikkomponenten 51 zum Prüfen auch der Selbsttestdaten für die Anwendungsbedingungen D_bst zu verwenden. Die LBIST-Selbsttestvorgänge A_bst können in jedem Fall auch über die komplette Architektur von 3 implementiert werden.
Es ist darüber hinaus zu betonen, dass es zum Erzielen einer größeren Flexibilität in abweichenden Ausführungsformen auch möglich ist, Vergleichsselbsttestvorgänge A_cou und A_bst so zu kombinieren, dass folgende Gleichung sichergestellt ist: $k_{stl} \cup k_{bst} \cup k_{cou} = k_{chk} \cup k_{stl}$
Gleichung (6) kann auf zwei Arten erfüllt werden, wie in 12 dargestellt: bei verschiedenen Ausfallmöglichkeiten (Failure Modes) FM1, FM2, ..., FMn durch Kombinieren der drei entsprechenden Vorgänge A_stl, A_cou und A_bst in einer „verbundenen“ Weise (12A); d. h. jede Ausfallmöglichkeit FM1, FM2, ..., FMn wird durch alle drei durch jeden Vorgang sichergestellten Deckungsgrade abgedeckt;
durch Kombinieren der drei Vorgänge A_stl, A_cou und A_bst in einer „nicht verbundenen“ Weise (12B); d. h. jede Ausfallmöglichkeit FM1, FM2, ..., FMn ist durch einen (oder höchstens zwei) der drei durch jeden Vorgang sichergestellten Deckungsgrade abgedeckt, beispielsweise durch k_stl + k_bst und nicht verbunden durch k_cou oder aber durch k_stl + k_bst und nicht verbunden durch k_cou.
Der Vorteil der nicht verbundenen Möglichkeit liegt darin, dass beispielsweise die LBIST-Selbsttestvorgänge A^bst stärker invasiv sind (sie erfordern eine Vergrößerung der Siliziumfläche der Vorrichtung und/oder eine lange Ausführungszeit gemäß der Anzahl der durchzuführenden Tests) und es daher zweckmäßig sein kann, diese Vorgänge auf nur einige Ausfallmöglichkeiten zu begrenzen und die Diagnoseselbsttestvorgänge A_stl und die Vorgänge eines Prüfens der Anwendungsbedingungen A_cou auf andere Ausfallmöglichkeiten einzugrenzen. Auf diese Weise wird die Belastung verringert (die Anzahl der Tests, die die LBIST-Schaltungen durchführen müssen, ist niedriger) und somit werden die Kosten für die Verwendung der LBIST-Selbsttestvorgänge A^bst reduziert.
Da auch die Selbsttestvorgänge A_cou eines Prüfens von Anwendungsbedingungen in Bezug auf die Programme invasiv sein können (sie erfordern die Einhaltung einiger Anwendungsbedingungen, deren Erfüllung bzw. Verifizierung bei einigen Programmen rechenintensiv ist), kann es zweckmäßig sein, diese Vorgänge auf nur einige Ausfallmöglichkeiten zu begrenzen und die Diagnoseselbsttestvorgänge A_stl und die LBIST-Selbsttestvorgänge A_bst auf andere Ausfallmöglichkeiten einzugrenzen. Auf diese Weise wird die Belastung verringert und somit werden die Kosten für die Verwendung der Selbsttestvorgänge von Anwendungsbedingungen A_cou reduziert.
Es ist anzumerken, dass die Einführung der Selbsttestvorgänge von Anwendungsbedingungen A_cou und LBISTs A_bst auch die Implementierung von Multiprozessorlösungen mit gemischten Integritätsleveln ermöglicht, d. h. Lösungen, bei denen die Deckungsgradanforderung für jeden Prozessor in Bezug auf das auszuführende Programm unterschiedlich sind.
Als Beispiel für dieses Merkmal der beschriebenen Lösung wird, wie in 13 dargestellt, ein Multiprozessorsystem wie das von 10 betrachtet, das aus vier Kernen 11 besteht, von denen zwei, diejenigen, die die Unterprogramme P1 und P2 ausführen, ein und dieselbe Anforderung an das Integritätslevel LS1, zum Beispiel SIL2 oder ASILB gemäß den oben genannten funktionalen Sicherheitsstandards aufweisen, während der Kern 11, der das Programm P3 ausführt, ein niedrigeres gemischtes Integritätslevel LS2 aufweist, beispielsweise SIL1 bzw. ASILA, während der Kern 11, der das Unterprogramm P4 ausführt, nicht auf sicherheitskritische Programme ausgerichtet ist und somit keine Integritätslevelanforderung aufweist, was in den Figuren mit NLS bezeichnet ist. In diesem Szenario ermöglicht die beschriebene Lösung Folgendes auf sehr flexible Weise:

• Verwendung einer Kombination von Diagnoseselbsttestvorgängen A_stl, von Selbsttestvorgängen A_chk eines Prüfens von Zwischenergebnissen, von Messwert-Selbsttestvorgängen A_sys oder aber einer Kombination von Diagnoseselbsttestvorgängen A_stl, Messwert-Selbsttestvorgängen A_sys, Selbsttestvorgängen einer Ausführung von Anwendungsbedingungen A_cou oder LBISTs A_bst für die Prozessoren 11, die die Unterprogramme P1 und P2 ausführen, die einem höheren Deckungsgradwert k zugeordnet sind, der von dem SIL- oder ASIL-Wert LS1 abgeleitet ist;
• Verwenden einer Kombination von Diagnoseselbsttestvorgängen A_stl, A_cou und A_sys oder A_stl, A_bst und A_sys für den Prozessor 11, der das Unterprogramm P3 bei einem niedrigeren Deckungsgradwert k ausführt, der von dem SIL- oder ASIL-Wert LS2 abgeleitet ist;
• Verwenden der Diagnoseselbsttestvorgänge A_stl für den Prozessor 11, der das Unterprogramm P4 ausführt, nur für die Interferenzprüfung (d. h. nicht angeforderter Zugriff des Unterprogramms P4 auf die Ressourcen der Unterprogramme P1, P2 und P3).

Daher ist im Allgemeinen vorgesehen, dass bei einer Mehrzahl von Verarbeitungsmodulen 11, denen eine Ausführung jeweiliger paralleler Unterprogramme P1, ..., Pn zugeordnet ist, wenn eine Teilmenge der Unterprogramme, in diesem Fall P3, ein Integritätslevel (LS2) aufweist, das niedriger ist als das Integritätslevel (LS1) einer anderen Teilmenge der Unterprogramme, eine Kombination der Selbsttestvorgänge verwendet wird, die die Diagnoseselbsttestvorgänge A_stl, die Diagnoseselbsttestvorgänge durchführen, Vorgänge A_sys eines Selbsttests von gemessenen Systemwerten, anwendungsbezogene Selbsttestvorgänge A_chk, die ein Prüfen einer Ausführung von Anwendungsbedingungen A_cou oder einer Ausführung von LBISTs A_bst für die Teilmenge von Programmen, d. h. P3, mit dem niedrigeren Integritätslevel LS2 beinhalten, umfassen.
Somit sind aus der obigen Beschreibung die Vorteile der Erfindung deutlich erkennbar.
Das beschriebene Verfahren und die beschriebene Architektur ermöglichen es in vorteilhafter Weise, gegebene Anforderungen von funktionaler Sicherheit für ein Multikanal- oder Einkanalsystem zu erfüllen, auch wenn dieses in einen Multiprozessor auf einer einzigen integrierten Schaltung hochintegriert ist.
Die oben beschriebene Methode zur Zerlegung des Programms und Aufteilung der Selbsttestvorgänge in drei separate Vorgänge, nämlich Selbsttest durch Diagnosetests, Selbsttest durch Überwachen der Systemwerte und anwendungsbezogener Selbsttest durch Kombination einer Prüfung einer Ausführung von Anwendungsbedingungen und/oder LBISTs und die entsprechende Gleichung (1), ermöglicht eine genaue Identifizierung der Deckungsgradziele, die jedem der drei Selbsttestvorgänge zuzuweisen sind, wodurch eine optimierte Verteilung der Ziele ermöglicht wird, d. h. eine Verringerung der Ziele für die Vorgänge, die - für die jeweilige Art von System, auf das das beschriebene Verfahren angewendet wird - einen großen Konstruktionsaufwand erfordern würden, und stattdessen Anheben der Ziele für die Vorgänge, die in einem solchen Kontext einfacher durchzuführen sind.
Die beschriebene Lösung ermöglicht darüber hinaus die Eingrenzung des Problems der gemeinsam verursachten Ausfälle (GVAs bzw. engl. CCFs, Common Cause Failures) durch Einführung eines Elements, das im Wesentlichen durch ein Steuermodul repräsentiert wird, d. h. einem eigenständigen Elektronik-Zeitgeber-Modul, das vom Prozessor periodisch in vorgegebenen Zeitintervallen zum Ausführen der drei verschiedenen beschriebenen Selbsttestvorgänge mit einer gegebenen Periodizität oder Frequenz abgefragt wird.
Insbesondere wird das oben Genannte durch Ausführung der Selbsttestvorgänge erreicht:

- eine Prüffunktion sowohl eines zeitlichen Typs als auch eines Werte- und eines Sequenztyps durch: Erzwingen von Prüfungen zum Auftreten von vordefinierten Ereignissen innerhalb vordefinierter Zeitfenster und die Einhaltung vordefinierter Sequenzen; und Prüfen numerischer Werte, die von den Prozessoren bestimmt oder in jedem Fall berechnet werden, die den oben genannten Diagnoseselbsttestvorgängen entsprechen;
- Erkennung des Auftretens von GVAs in den Prozessoren durch Vergleich von Werten, die von den Prozessoren berechnet oder aber über Sensoren gemessen werden, die in den Prozessoren oder allgemein in dem Multiprozessor verfügbar sind, mit vorberechneten korrekten Werten entsprechend den oben genannten Vorgängen eines Selbsttests der Systemwerte; und
- Implementierung von Protokollen zum Bestimmen der Integrität der Prozessoren auf Grundlage von Gegenprüfungen, die den oben genannten Vorgängen eines Selbsttests der Zwischenergebnisse der Programme entsprechen.

In diesem Zusammenhang ist zu betonen, dass hochintegrierte und homogene Schaltungsimplementierungen der Multiprozessoren zwar die höchste Leistung und die niedrigsten Systemkosten sicherstellen, aber gleichzeitig dem Problemen der GVAs ausgesetzt sind, die umso wichtiger und schwieriger zu verhindern und/oder zu erkennen sind, je homogener und hochintegrierter die Architekturen sind. Das Vorhandensein von GVAs ist der Hauptgrund dafür, dass Lösungen mit diese Art von Architektur und Aufbau in der Welt der Anwendungen, die den Sicherheitsstandards im Automobil- und Industriebereich unterliegen, nicht weit verbreitet sind, wodurch der wirtschaftliche Vorteil, der dadurch erzielt werden könnte, verloren geht.
Die beschriebene Lösung ermöglicht darüber hinaus eine Kombination der Steuerungssoftware virtueller Maschinen (z. B. Hypervisoren) mit dedizierten Softwareprogrammen, die die oben genannten Selbsttestvorgänge implementieren, und die gemeinsame Verwendung ermöglicht, dass die Anforderungen zum Erreichen des in industriellen und automobilen Anwendungen geforderten funktionalen Sicherheits-Integritätslevels erfüllt werden.
Die beschriebene Lösung ermöglicht darüber hinaus (wie unter Bezugnahme auf die Gleichungen 5 und 6 dargestellt) ein Dosieren der verschiedenen Selbsttestvorgänge, um eine maximale funktionale Sicherheit bei minimalen Kosten hinsichtlich der Leistung oder der Komplexität der Hardware zu erreichen.
Das beschriebene Verfahren und die beschriebene Architektur ermöglichen darüber hinaus ein optimiertes logisches und zeitliches Überwachen, insbesondere für Multikernsysteme mit Unterstützung für Gegenprüfungen zwischen Kernen;
Implementierung von Diagnosen sowohl für Architekturen mit 1oo1-Voting als auch für Architekturen mit 1oo2-Voting;
Überwachen von Informationen in Bezug auf die Hardware des Multikerns (Status, Temperatur, Versorgungszustand usw.);
Selbstüberwachungssystem gemäß der Spezifikation IEC 61508 2. Ed., das in SIL2- und SIL3-Systeme integriert werden kann;
Standardschnittstelle zur Verwendung mit der Software;
konfigurierbare Reaktion; und
Möglichkeit der Optimierung für die gewählte Implementierungstechnologie (FPGA oder ASIC).
Selbstverständlich können die Einzelheiten und die Ausführungsformen, unbeschadet des Prinzips der Erfindung, im Hinblick auf das, was hierin rein beispielhaft beschrieben ist, sogar beträchtlich, variieren, ohne dadurch vom Schutzumfang abzuweichen, wobei der Schutzumfang durch die beigefügten Ansprüche definiert ist.
In der beispielhaft betrachteten Sicherheitsarchitektur kann das Steuermodul 15 einem Votermodul zugeordnet sein, das üblicherweise in Multikanalarchitekturen zum kontinuierlichen Vergleichen der Ausgänge der Kanäle verwendet wird, bevor diese von dem Programm oder von den Aktuatoren verwendet werden, das gemäß den Votingtechniken den an das Programm zu liefernden sicheren Ausgang bewerten. Ein ODER-Gatter kann den Ausgang des Steuermoduls 15 und den Ausgang der Votervorrichtung empfangen und mögliche Unterschiede zwischen den Ausgängen erkennen. Die Erkennung eines Unterschieds bestimmt eine Bedingung einer Fehlererkennung, die das System zwingt, einen sicheren Zustand zu erreichen oder aufrechtzuerhalten, der für das gerade ausgeführte Programm definiert ist.
Der Begriff „Bibliothek“ wird in der vorliegenden Beschreibung zum Definieren der Softwaremodule von Diagnoseselbsttestprogrammen verwendet, kann jedoch auch auf die Module zum Selbsttest der Systemdaten (die, wie bereits erwähnt, in der Diagnoseselbsttestbibliothek enthalten sein können) und auf die Selbsttestmodule zum Vergleich von Zwischenergebnissen der Unterprogramme angewendet werden.
Die oben genannten Bibliotheken oder Softwaremodule, die die Selbsttestprogramme umfassen, können beispielsweise in einem Flash-Speicher gespeichert sein, der auf der Karte oder der integrierten Schaltung verfügbar ist, die das Verarbeitungssystem umfasst, und dann in einen RAM der Verarbeitungsmodule geladen werden.
Zwar bezieht sich das hierin beschriebene Verfahren auf ein Verarbeitungssystem, insbesondere ein Multiprozessorsystem, und ein Steuermodul, die Vorgänge der Zerlegung in Unterprogramme selbst gelten jedoch auch nur für das Verarbeitungssystem ohne ein eigenständiges Steuermodul. Mit anderen Worten ist Gegenstand der vorliegenden Offenbarung auch ein Verfahren zum Ausführen von Programmen in einem elektronischen System für Anwendungen mit funktionaler Sicherheit einschließlich eines Verarbeitungssystems des Einzelprozessor- oder Multiprozessortyps, wobei das Verfahren umfasst: Durchführen eines Zerlegungsvorgangs eines Programms, das eine Sicherheitsfunktion beinhaltet und über das System auszuführen ist, in mehrere parallele Unterprogramme; Zuweisen einer Ausführung jedes parallelen Unterprogramms zu einem jeweiligen Verarbeitungsmodul des Systems, insbesondere einem Prozessor der Multiprozessorarchitektur oder einer virtuellen Maschine, die einem der Prozessoren zugeordnet ist; Ausführen in dem System, periodisch gemäß einer Programmzyklusfrequenz, während Normalbetriebs des Systems im Rahmen der Sicherheitsfunktion, von Selbsttestvorgängen, die jedem der Unterprogramme und den entsprechenden Verarbeitungsmodulen, auf denen sie ausgeführt werden, zugeordnet sind, wobei die oben genannten Selbsttestvorgänge Diagnoseselbsttestvorgänge, die Diagnoseselbsttests durchführen, Vorgänge eines Selbsttests von gemessenen Systemwerten, Selbsttestvorgänge eines Vergleichs durch eine geeignete Kombination eines Prüfens einer Ausführung von Anwendungsbedingungen und/oder von LBISTs umfassen, und wobei die Selbsttestvorgänge umfassen: ein Erzeugen von jeweiligen Selbsttestdaten entsprechend den Selbsttestvorgängen und ein Durchführen von Prüfungsvorgängen an den Selbsttestdaten, Ausführung des Vorgangs der Zerlegung des Programms in mehrere parallele Unterprogramme, so dass ein Deckungsgradziel für jeden der Selbsttestvorgänge, der einem jeweiligen Unterprogramm oder Verarbeitungsmodul zugeordnet ist, derart erhalten wird, dass ein gegebenes Ausfallwahrscheinlichkeitsziel eingehalten wird.
Es ist anzumerken, dass der Begriff „Anwendungsbedingung“ die Tatsache anzeigt, dass die sogenannten dedizierten Vorgänge durch den Programmierer in Mengen und mit Merkmalen in das Hauptprogramm geschrieben sein müssen, die ausreichen, um die Deckungsgradziele zu erreichen (wie im Folgenden ersichtlich). Die oben genannten Vorgänge stellen somit für den Programmierer eine erforderliche „Bedingung“ für die Anwendung des elektronischen Systems im Rahmen der funktionalen Sicherheit dar.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 6233702 [0007]
US 7472051 [0007]
US 5513319 [0008]
EP 1980964 A1 [0034, 0069]

Zitierte Nicht-Patentliteratur

ISO 13849 [0002]
ISO 26262 [0002]

Claims

Verfahren zum Ausführen von Programmen (P) in einem elektronischen System für Anwendungen mit funktionaler Sicherheit, das ein Einzelprozessor- oder Multiprozessorverarbeitungssystem (10) und ein weiteres eigenständiges Steuermodul (15) umfasst, das Folgendes umfasst: Durchführen einer Zerlegung eines Programms (P), das eine Sicherheitsfunktion (SF) beinhaltet, die über das System (10) auszuführen ist, in mehrere parallele Unterprogramme (P1, ..., Pn); Zuweisen einer Ausführung jedes parallelen Unterprogramms (P1, ..., Pn) zu einem jeweiligen Verarbeitungsmodul (11) des Systems, insbesondere einem Prozessor (C1, ..., Cm) der Multiprozessorarchitektur (10) oder einer virtuellen Maschine (V1, ..., Vn), die einem der Prozessoren (C1, ..., Cm) zugeordnet ist; periodisches Ausführen in dem System (10) gemäß einer Zyklusfrequenz (f_cyc) des Programms (P) während Normalbetriebs des Systems (10), in Zusammenhang mit der Sicherheitsfunktion (SF), von Selbsttestvorgängen (A_stl, A_sys, A_chk), die jedem der Unterprogramme (P1, ..., Pn) und den entsprechenden Verarbeitungsmodulen (11), auf denen sie ausgeführt werden, zugeordnet sind, wobei das Verfahren dadurch gekennzeichnet ist, dass die Selbsttestvorgänge (A_stl, A_sys, A_chk) Folgendes beinhalten: Diagnoseselbsttestvorgänge (A_stl), die Diagnoseselbsttests durchführen; Vorgänge (A_sys) eines Selbsttests von gemessenen Systemwerten; anwendungsbezogene Selbsttestvorgänge (A_chk), die Vorgänge eines Prüfens einer Ausführung von Anwendungsbedingungen (A_cou) und/oder einer Ausführung von LBISTs (Logic Built-in Self-Tests - Logischen integrierten Selbsttests) (A_bst) beinhalten, und wobei die Selbsttestvorgänge (A_stl, A_sys, A_chk) Folgendes umfassen: Erzeugen jeweiliger Selbsttestdaten (D_stl, D_sys, D_chk) entsprechend den Selbsttestvorgängen (A_stl, A_sys, A_chk) und Durchführen von Prüfvorgängen (51, 61) an den Selbsttestdaten (D_stl, D_sys, D_chk); kontinuierliches Austauschen der Selbsttestdaten (D_stl, D_sys, D_chk) über ein Protokoll (PL) von Nachrichten (MC) mit dem weiteren eigenständigen Steuermodul (15); Durchführen mindestens eines Teils der Prüfvorgänge (51, 61) in dem weiteren Steuermodul (15); und Ausführen des Vorgangs der Zerlegung des Programms (P) in mehrere parallele Unterprogramme (P1, ..., Pn) zum Erreichen eines Deckungsgradziels (k_stl, k_sys, k_chk) für jeden der Selbsttestvorgänge (A_stl, A_sys, A_chk), das einem jeweiligen Unterprogramm (P1,..., Pn) oder Verarbeitungsmodul (11) derart zugeordnet ist, dass ein gegebenes Ausfallwahrscheinlichkeitsziel (g12; g) eingehalten wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das gegebene Ausfallwahrscheinlichkeitsziel (g12; g) eine Funktion eines Deckungsgrads (k_stl), der durch die Diagnoseselbsttestvorgänge (A_stl) bestimmt ist, eines Deckungsgrads (k_sys), der durch die Vorgänge (A_sys) eines Selbsttests von auf dem Verarbeitungssystem (10) gemessenen Systemwerten bestimmt ist, eines Deckungsgrads (k_chk), der durch die anwendungsbezogenen Selbsttestvorgänge (A_chk) bestimmt ist, die Vorgänge eines Prüfens einer Ausführung von Anwendungsbedingungen (A_cou) und/oder einer Ausführung von LBISTs (A_bst) beinhalten, ist.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass eine Berechnung des Ausfallwahrscheinlichkeitsziels (g12; g) Folgendes beinhaltet: Betrachten der Unterprogramme (P1, ..., Pn) als Eingänge einer UND-Logikfunktion (AG) mit so vielen Eingängen wie Unterprogramme (P1, ..., Pn) vorhanden sind; Zerlegen der UND-Logikfunktion (AG) in UND-Logikfunktionen mit zwei Eingängen, die als Eingänge die Paare der Unterprogramme (P1, ..., Pn), die gebildet werden können, aufweisen, und Berechnen des Produkts der Ausfallwahrscheinlichkeiten am Ausgang von jedem UND-Gatter mit zwei Eingängen, multipliziert mit dem Komplement des Anteils der gemeinsam verursachten Ausfälle (β), und der Expositionszeit (texp); und Berechnen des Wahrscheinlichkeitsziels (g) als eine Funktion des Ergebnisses des vorhergehenden Vorgangs addiert mit einem Wert, der durch Anwenden von ODER-Funktionen auf gemeinsam verursachte Ausfälle zwischen den Paaren von Unterprogrammen (P1, ..., Pn) erhalten wird, was mit dem Anteil der gemeinsam verursachten Ausfälle (β) multipliziert wird.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Ausfallwahrscheinlichkeiten der Unterprogramme (P1, ..., Pn) als eine Funktion der Vereinigung zwischen dem Deckungsgradwert (k_stl), der durch die Diagnoseselbsttestvorgänge (A_stl) für jedes Unterprogramm (P1, ..., Pn) bestimmt ist, dem Deckungsgrad (k_sys), der durch die Vorgänge (A_sys) eines Selbsttests von auf der Architektur (10) gemessenen Systemwerten bestimmt ist, und dem Deckungsgrad (k_chk), der durch die anwendungsbezogenen Selbsttestvorgänge (A_chk) bestimmt ist, die Vorgänge eines Prüfens einer Ausführung von Anwendungsbedingungen (A_cou) und/oder einer Ausführung von LBISTs (A_bst) beinhalten, bewertet werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das System (10) ein Virtuelle-Maschinen-Verwaltungsmodul (17) implementiert, das virtuelle Maschinen (V1, ..., Vn) erzeugt, auf denen die Unterprogramme (P1, ..., Pn) ausgeführt werden können.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Vorgang eines Durchführens mindestens eines Teils der Prüfvorgänge (51, 61) in dem weiteren Steuermodul (15) Folgendes beinhaltet: Durchführen des Vergleichs von Diagnoseselbsttestdaten (D_stl) entsprechend den Zwischenergebnissen von Berechnungen, die auf den Prozessoren (C1, ..., Cm) des Einzelprozessor- oder Multiprozessorverarbeitungssystems (10) gemäß den Diagnoseselbsttestvorgängen (D_stl) durchgeführt werden, mit einem Satz gespeicherter vorberechneter und erwarteter Werte (D_stla); Durchführen des Vergleichs von Anwendungsselbsttestdaten (D_chk), die durch anwendungsbezogene Selbsttestvorgänge (A_chk) erzeugt werden, die Vorgänge eines Prüfens einer Ausführung von Anwendungsbedingungen (A_cou) und/oder einer Ausführung von LBISTs (A_bst) beinhalten; und Vergleichen von Systemselbsttestdaten (D_sys) mit gespeicherten erwarteten Bereichen (R_att).
Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass das weitere Steuermodul (15) dazu ausgelegt ist, an den Selbsttestdaten (D_stl, D_chk, D_sys) Folgendes durchzuführen: eine Prüfung der Werte zum Verifizieren, dass die Anwendungsselbsttestdaten (D_chk) und/oder die Diagnoseselbsttestdaten (D_stl) gleich oder korrekt sind; eine Prüfung der Wertebereiche zum Verifizieren, dass der Wert eines Systemselbsttestdatums (D_sys) einem vordefinierten Wertebereich (R_att) angehört; eine Prüfung der Reihenfolge zum Verifizieren, dass die Reihenfolge der Nachrichten korrekt ist; und eine Prüfung der Eingangszeiten der Nachrichten.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Vorgang des kontinuierlichen Austauschens der Selbsttestdaten (D_stl, D_sys, D_chk) über ein Protokoll (PL) von Nachrichten (MC) mit dem weiteren eigenständigen Steuermodul (15) ein Organisieren der Nachrichten (MC) in logischen Kanälen (VC) gemäß einer hierarchischen Ebene (L) entsprechend den Nachrichten (MC) und gemäß einem physischen Kanal (ID0, ID1) entsprechend den Nachrichten (MC) beinhaltet.
Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass der Vorgang eines Durchführens mindestens eines Teils der Prüfvorgänge (51, 61) in dem weiteren Steuermodul (15) eine Ausführung folgender Vorgänge beinhaltet: kanalinterner Prüfungen (ITC), die auf Nachrichten angewendet werden, die zu ein und demselben logischen Kanal (VC) und zu ein und demselben physischen Kanal (ID) gehören; und kanalübergreifender Prüfungen (INTC), die auf Nachrichten (MC) angewendet werden, die zu verschiedenen logischen Kanälen (VC) gehören.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei mehreren Verarbeitungsmodulen (11), denen jeweilige parallele Unterprogramme (P1, ..., Pn) zur Ausführung zugeordnet sind, eine Teilmenge der Unterprogramme (P3) ein Integritätslevel (LS2) aufweist, das niedriger ist als das Integritätslevel (LS1) einer anderen Teilmenge der Programme: Verwenden einer Kombination der Selbsttestvorgänge (A_stl, A_sys, A_chk), die die Diagnoseselbsttestvorgänge (A_stl), die Diagnoseselbsttests durchführen, die Vorgänge (A_sys) eines Selbsttests von gemessenen Systemwerten und die anwendungsbezogenen Selbsttestvorgänge (A_chk), die Vorgänge eines Prüfens einer Ausführung von Anwendungsbedingungen (A_cou) und/oder einer Ausführung von LBISTs (A_bst) beinhalten, beinhalten, für die Teilmenge der Unterprogramme (P3) mit einem niedrigeren Integritätslevel (LS2).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Verfahren bei verschiedenen Ausfallmöglichkeiten (FM1, FM2, ..., FMn) Folgendes beinhaltet: Verwenden für jede Ausfallmöglichkeit einer Kombination umfassend Vorgänge, die zu den Diagnoseselbsttestvorgängen (A_stl) gehören, die Diagnoseselbsttests durchführen, und Vorgänge, die zu den anwendungsbezogenen Selbsttestvorgängen (A_chk) gehören, die Vorgänge eines Prüfens einer Ausführung von Anwendungsbedingungen (A_cou) und/oder einer Ausführung von LBISTs (A_bst) beinhalten; oder Verwenden für jede Ausfallmöglichkeit (FM1, FM2, ..., FMn) einer Kombination, bei der mindestens einer der folgenden Sätze von Vorgängen fehlt: Vorgänge, die zu den Diagnoseselbsttestvorgängen (A_stl) gehören, die Diagnoseselbsttests durchführen; und Vorgänge, die zu den anwendungsbezogenen Selbsttestvorgängen (A_chk) gehören, die Vorgänge eines Prüfens einer Ausführung von Anwendungsbedingungen (A_cou) und/oder einer Ausführung von LBISTs (A_bst) beinhalten.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die anwendungsbezogenen Selbsttestvorgänge (A_chk) Vorgänge eines Prüfens einer Ausführung von Anwendungsbedingungen (A_cou) sind.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die anwendungsbezogenen Selbsttestvorgänge (A_chk) Vorgänge eines Prüfens einer Ausführung von LBISTs (A_bst) sind.
Verfahren zum Ausführen von Programmen (P) in einem elektronischen System für Anwendungen mit funktionaler Sicherheit, das ein Einzelprozessor- oder Multiprozessorverarbeitungssystem (10) umfasst, das Folgendes umfasst: Durchführen einer Zerlegung eines Programms (P), das eine Sicherheitsfunktion (SF) beinhaltet, die über das System (10) auszuführen ist, in mehrere parallele Unterprogramme (P1, ..., Pn); Zuweisen einer Ausführung jedes parallelen Unterprogramms (P1, ..., Pn) zu einem jeweiligen Verarbeitungsmodul (11) des Systems, insbesondere einem Prozessor (C1, ..., Cm) der Multiprozessorarchitektur (10) oder einer virtuellen Maschine (V1, ..., Vn), die einem der Prozessoren (C1, ..., Cm) zugeordnet ist; periodisches Durchführen in dem System (10) gemäß einer Zyklusfrequenz (f_cyc) des Programms (P) während Normalbetriebs des Systems (10), in Zusammenhang mit der Sicherheitsfunktion (SF), von Selbsttestvorgängen (A_stl, A_sys, A_chk), die jedem der Unterprogramme (P1, ..., Pn) und den entsprechenden Verarbeitungsmodulen (11), auf denen sie ausgeführt werden, zugeordnet sind, wobei das Verfahren dadurch gekennzeichnet ist, dass die Selbsttestvorgänge (A_stl, A_sys, A_chk) Folgendes beinhalten: Diagnoseselbsttestvorgänge (A_stl), die Diagnoseselbsttests durchführen; Vorgänge (A_sys) eines Selbsttests von gemessenen Systemwerten; und anwendungsbezogene Selbsttestvorgänge (A_chk), die Vorgänge eines Prüfens einer Ausführung von Anwendungsbedingungen (A_cou) und/oder einer Ausführung von LBISTs (Logic Built-in Self-Tests - Logischen integrierten Selbsttests) (A_bst) beinhalten, und wobei die Selbsttestvorgänge (A_stl, A_sys, A_chk) Folgendes umfassen: Erzeugen jeweiliger Selbsttestdaten (D_stl, D_sys, D_chk) entsprechend den Selbsttestvorgängen (A_stl, A_sys, A_chk) und Durchführen von Prüfvorgängen (51, 61) an den Selbsttestdaten (D_stl, D_sys, D_chk); Ausführen des Vorgangs der Zerlegung des Programms (P) in mehrere parallele Unterprogramme (P1, ..., Pn) zum Erreichen eines Deckungsgradziels (A_stl, A_sys, A_chk) für jeden der Selbsttestvorgänge (A_stl, A_sys, A_chk), das einem jeweiligen Unterprogramm (P1,..., Pn) oder Verarbeitungsmodul (11) derart zugeordnet ist, dass ein gegebenes Ausfallwahrscheinlichkeitsziel (g12; g) eingehalten wird.
Elektronisches System mit funktionaler Sicherheit, umfassend ein Einzelprozessor- oder Multiprozessorverarbeitungssystem (10) und ein weiteres eigenständiges Steuermodul (15), das dazu ausgelegt ist, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 13 auszuführen.
Computerprogrammprodukt, das in den Speicher mindestens eines Computers geladen werden kann, wobei das Computerprogrammprodukt Teile von Softwarecode umfasst, der zum Implementieren der Schritte des Verfahrens nach einem der Ansprüche 1 bis 14 ausgelegt ist, wenn das Programm auf mindestens einem Computer ausgeführt wird.