Selbstdiagnose

Neben den eigentlichen Safety-Prozessoren, die in der Regel über in Hard- oder Software implementierte Selbstdiagnosefunktionalität verfügen, werden auch für eine wachsende Zahl von Standardprozessoren Selbsttestbibliotheken angeboten. In beiden Fällen bedeutet dies zunächst eine erhebliche Einsparung an Entwicklungsaufwand. Wie bei den Sicherheitsarchitekturen sind aber auch hier vorab einige Fragen zu klären:

• • Welche Komponenten des Prozessors sind durch die Diagnosen abgedeckt?,
• • Entspricht der zugesicherte Diagnosedeckungsgrad meinen normativen Anforderungen? (Dies ist wiederum insbesondere für die Kategorien 3 und 4 nach ISO 13849 zu prüfen, falls gefordert.),
• • Ist die Wirksamkeit und Vollständigkeit der Diagnosen durch eine Prüfstelle gemäß der von der Applikation zu erfüllenden Normen bestätigt?,
• • Falls es sich um eine Softwarebibliothek handelt: ist die Software gemäß den Anforderungen der IEC 61508 an sichere Software entwickelt worden?

Der letzte Punkt ist auch zu betrachten und ggf. frühzeitig abzuklären, wenn der Prozessorhersteller prozessorspezifische Bibliotheken zur von ihm bereitgestellten Entwicklungsumgebung anbietet.

Zusammenfassung

• • Eine generelle Verpflichtung, Safety-Prozessoren in Sicherheitsanwendungen einzusetzen, besteht von Seiten der Prüfstellen in absehbarer Zukunft nicht.
• • Safety-Prozessoren mit interner (dual-core) Sicherheitsarchitektur bieten insbesondere bei reinen Softwareapplikation (SPS ohne Ein-/Ausgänge) eine erhebliche Reduktion des Entwicklungsaufwands.
• • Der erhöhte Entwicklungsaufwand und Performanceverluste bei gleichzeitiger Ausführung von sicherer und nicht-sicherer Software auf einem Prozessor werden durch einen Safety-Prozessor nicht zwangsläufig reduziert.
• • Sofern die I/O-Pins eines Safety-Prozessors nicht ausdrücklich rückwirkungsfrei realisiert sind, ist für zweikanalige einfehlersichere Ein-/Ausgänge ein zweiter Prozessor erforderlich.
• • In Hard- oder Software implementierte Selbsttestfunktion kann ebenfalls den Entwicklungsaufwand reduzieren.
• • In jedem Fall aber ist sorgfältig zu prüfen und mit der jeweiligen Prüfstelle abzustimmen, ob die vom Hersteller zugesagte Sicherheitsfunktionalität auch den für die Applikation geforderten Normen und Sicherheitsleveln entspricht.
• • Schließlich ist zu bedenken, dass Safety-Prozessoren i.d.R. äußerst komplexe Systeme darstellen und der eingesparte Entwicklungsaufwand zumindest teilweise durch die Einarbeitung in ein viele hundert Seiten umfassendes Anwenderhandbuch wieder aufgebraucht werden kann.