Erarbeitung der 2. Ausgabe der Normen der Reihe IEC in IEC SC 65A MT Stand Ende 2011

Transkript

1 Erarbeitung der 2. Ausgabe der Normen der Reihe IEC in IEC SC 65A MT Stand Ende 2011 Eine Information des GK 914 Funktionale Sicherheit elektrischer, elektronischer und programmierbarer elektronischer Systeme (E, E, PES) zum Schutz von Personen und Umwelt 1

2 Überarbeitung von Begriffen (1) Einige Ausfallbegriffe werden vollständig überarbeitet Ausfälle infolge gemeinsamer Ursache (common cause cailures) Definition geändert und neue Anmerkungen Gleichzeitige Ausfälle von verschiedenen Geräten, die auf ein Ereignis zurückgehen und nicht einer die Folge eines anderen ist. Ausfälle infolge gemeinsamer Ausfallart (common code cailures) Definitionen geändert und neue Anmerkungen Gleichzeitige Ausfälle von verschiedenen Geräten, die durch die gleiche Ausfallart gekennzeichnet sind. 2

3 Überarbeitung von Begriffen (2) Einige Ausfallbegriffe werden vollständig überarbeitet Gefahrbringender Ausfall (dangerous failure) Geänderte Definition und neue Anmerkungen Ausfall mit der Tendenz, eine bestimmte Sicherheitsmaßnahme zu behindern. ANMERKUNG 1 ANMERKUNG 2 ANMERKUNG 3 ANMERKUNG 4 Ein Ausfall ist nur im Hinblick auf eine gegebene Sicherheitsfunktion gefahrbringend. Ein gefahrbringender Ausfall erhöht grundsätzlich die Wahrscheinlichkeit eines Ausfalls der betreffenden Sicherheitsfunktion Wenn Fehlertoleranz vorhanden ist, kann ein gefahrbringender Ausfall entweder zu einem eingeschränkten sicherheitstechnischen System führen, in dem die Sicherheitstätigkeit zwar verfügbar ist, jedoch in einer Anforderungsbetriebsart mit einer höheren Wahrscheinlichkeit des Ausfalls bei Anforderung oder in der Betriebsart mit kontinuierlicher Anforderung mit einer höheren Wahrscheinlichkeit der Herbeiführung eines gefährlichen Ereignisses, oder zu einem nicht einsatzfähigen sicherheitstechnischen System, in dem in einer Anforderungsbetriebsart die Sicherheitsmaßnahme vollständig fehlt oder in der Betriebsart mit kontinuierlicher Anforderung das gefahrbringende Ereignis herbeigeführt worden ist. Ist keine Fehlertoleranz vorhanden, so setzen alle gefahrbringenden Ausfälle das sicherheitstechnische System außer Funktion. 3

4 Überarbeitung von Begriffen (3) Einige Ausfallbegriffe werden vollständig überarbeitet ungefährlicher Ausfall Geänderte Definition und neue Anmerkungen Ausfall mit der Tendenz, eine gegebene Sicherheitsmaßnahme zu begünstigen. ANMERKUNG 1 ANMERKUNG 2 ANMERKUNG 3 ANMERKUNG 4 ANMERKUNG 5 Ein Ausfall ist nur im Hinblick auf eine gegebene Sicherheitsfunktion ungefährlich. Ein ungefährlicher Ausfall erhöht grundsätzlich die Wahrscheinlichkeit eines Erfolges der betreffenden Sicherheitsfunktion. Wenn Fehlertoleranz eingebaut worden ist, kann ein ungefährlicher Ausfall entweder: in der Anforderungsbetriebsart zu einer verminderten Ausführung führen, in der die Sicherheitstätigkeit zwar verfügbar ist, aber mit einer geringeren Wahrscheinlichkeit eines Ausfalles bei Anforderung oder in der kontinuierlichen Betriebsart zu einer geringeren Wahrscheinlichkeit, das gefahrbringende Ereignis zu bewirken, oder zu einer Fehlauslösung mit Herbeiführung der Sicherheitstätigkeit. wenn keine Fehlertoleranz vorhanden ist, führen alle ungefährlichen Ausfälle zu einer Fehlauslösung. Eine Fehlauslösung kann im Hinblick auf eine gegebene Sicherheitsfunktion ungefährlich sein oder gefahrbringend in Hinblick auf eine andere. Aus diesem Grunde sollte die Rate sicherer Ausfälle so gering wie möglich sein. 4

5 Überarbeitung von Begriffen (4) Einige Ausfallbegriffe werden vollständig überarbeitet Erkannter, offenkundiger Ausfall Geänderte Definition und neue Anmerkungen Ausfälle oder Fehler, mit Bezug auf Hard- und Software, die nicht versteckt sind, weil sie sich selbst melden oder im Normalbetrieb entdeckt werden oder mit Hilfe spezieller Detektionsmechanismen (z. B. Diagnosetest, Wiederholungsprüfungen, Bedienereingriff wie Sichtprüfung oder händische Prüfung) entdeckt werden ANMERKUNG 1 ANMERKUNG 2 ANMERKUNG 3 ANMERKUNG 4 In der IEC bezieht sich der Begriff Gefahrbringender, erkannter Ausfall/Fehler auf gefahrbringende Ausfälle, die durch Diagnosetests erkannt worden sind, außer wenn aus dem Zusammenhang eine andere Bedeutung hervorgeht. Diese Begriffe werden unterschiedlich verwendet: Offenkundig wird hauptsächlich verwendet für Ausfälle oder Fehler, die sich bei ihrem Auftreten selbst zeigen (z. B. durch eine Zustandsänderung). Die Behebung solcher Ausfälle kann beginnen, sobald sie aufgetreten sind. Erkannt wird hauptsächlich verwendet für Ausfälle oder Fehler, die sich bei ihrem Auftreten nicht selbst zeigen und versteckt bleiben, bis sie erkannt werden. Die Behebung solcher Ausfälle kann erst beginnen, wenn sie erkannt worden sind. Verläuft die Erkennung sehr schnell (z. B. durch Diagnosetests), können die erkannten Fehler oder Ausfälle als offenkundig aufgefasst werden. Wenn die Erkennung nicht sehr schnell verläuft (z. B. bei Wiederholungsprüfungen), kann der erkannte Ausfall oder Fehler nicht als offenkundig aufgefasst werden. Ein offenkundiger Ausfall kann nur dann als ungefährlich betrachtet werden, wenn wirksame Maßnahmen automatischer oder händischer Art getroffen werden. 5

6 Überarbeitung von Begriffen (5) Einige Ausfallbegriffe werden vollständig überarbeitet Zufälliger Hardwareausfall (random hardware failure) Ausfall, der zufällig auftritt und aus verschiedenen Mechanismen der Verschlechterung der Eigenschaften der Hardware (Degradationsmechanismen) hervorgeht. ANMERKUNG 1 Neue Anmerkung Es gibt verschiedene solcher Mechanismen, die mit unterschiedlichen Raten in verschiedenen Bauteilen auftreten. Da Fertigungstoleranzen diese Bauteile aufgrund dieser Mechanismen nach verschiedenen Betriebszeiten ausfallen lassen, ereignen sich Ausfälle von aus vielen Bauteilen bestehenden Betriebsmittel mit vorhersagbaren Raten, jedoch zu nicht vorhersagbaren Zeitpunkten. ANMERKUNG 2 Zwei wichtige Unterschiede bestehen zwischen zufälligen Hardwareausfällen und systematischen Ausfällen: Ein zufälliger Hardwareausfall ist nur mit dem System selbst verknüpft, ein systematischer Ausfall dagegen sowohl mit dem System als auch mit einer Zufallsbedingung. Ferner wird ein zufälliger Hardwareausfall durch einen einzigen Zuverlässigkeitsparameter (z. B. die Ausfallrate) beschrieben, ein systematischer Ausfall dagegen durch zwei (z. B. die Wahrscheinlichkeit eines bereits vorhandenen Fehlers und die Häufigkeit der Gefährdung durch eine bestimmte Bedingung). Ein systematischer Ausfall kann nach seiner Entdeckung beseitigt werden, während dieses bei einem zufälligen Hardwareausfall nicht möglich ist. Dieses bedeutet, dass die Zuverlässigkeitsparameter von Hardwareausfällen durch Rückmeldungen aus dem Feld geschätzt werden können, während dies bei systematischen Ausfällen sehr schwierig ist. Die IEC betrachtet dieses als unrealistisch und bevorzugt bei systematischen Ausfällen einen qualitativen Ansatz. 6

7 Überarbeitung von Begriffen (6) Einige Ausfallbegriffe werden vollständig überarbeitet Systematischer Ausfall Geänderte Definition und neue Anmerkungen Ausfall, der auf einen bereits vorhandenen Fehler zurückgeführt werden kann, unter bestimmten Bedingungen regelmäßig auftritt und nur durch Entfernen des Fehlers mit Hilfe einer Änderung des Entwurfs, des Fertigungsverfahrens, der betrieblichen Vorgehensweisen, der Dokumentation oder anderer relevanter Faktoren behoben werden kann. ANMERKUNG 1 ANMERKUNG 2 ANMERKUNG 3 ANMERKUNG 4 ANMERKUNG 5 Die bereits existierenden Fehler, die systematische Ausfälle der Software verursachen, können auch bugs (Wanzen) genannt werden. Instandsetzung ohne Änderung wird gewöhnlich nicht die Ursache des unter bestimmten Bedingungen auftretenden Ausfalls beheben. Ein systematischer Ausfall kann durch Simulation der betreffenden Bedingung reproduziert werden. Beispiele für Fehler, die zu systematischen Ausfällen führen, sind auch menschliche Irrtümer, die sich ereignen bei: der Spezifikation der Sicherheitsanforderung. der Konstruktion, Herstellung, Installation, dem Betrieb oder der Instandhaltung der Hardware. dem Entwurf und/oder der Implementierung der Software und der Änderungen des Anwendungsprogramms. Ähnliche Funktionseinheiten, die gleichartig konstruiert sind, installiert sind, betrieben werden, implementiert sind oder instand gehalten werden, enthalten wahrscheinliche die gleichen Fehler. Daher werden sie auch von Ausfällen gemeinsamer Ursache betroffen, wenn die betreffenden Bedingungen auftreten. 7

8 Überarbeitung von Begriffen (7) Drei verschiedene Betriebsarten eingeführt Betriebsart (mode of operation) Art, in der eine sicherheitstechnische Funktion betrieben wird. Betriebsarten können sein: Erweiterte Definition Betriebsart mit niedriger Anforderungsrate: wobei die Sicherheitsfunktion nur auf Anforderung ausgeführt wird, um einem sicheren Zustand des Prozesses zu erreichen oder aufrecht zu erhalten und die Häufigkeit von Anforderungen nicht mehr als einmal pro Jahr beträgt; oder Betriebsart mit hoher Anforderungsrate: wobei die Sicherheitsfunktion nur auf Anforderung ausgeführt wird, um einem sicheren Zustand des Prozesses zu erreichen oder aufrecht zu erhalten und die Häufigkeit von Anforderungen mehr als einmal pro Jahr beträgt, oder Betriebsart mit kontinuierlicher Anforderung: wobei die Sicherheitsfunktion als Teil des normalen Betriebes einen sicheren Zustand des Prozesses aufrecht erhält. 8

9 Überarbeitung von Begriffen (8) Sichtweise des Endanwenders betont betriebsbewährt (proven-in-use). Dieser Begriff stammt aus der DIN EN (VDE 0803) und betrifft den Hersteller. Er wird künftig in den Normen der Reihe IEC nicht mehr verwendet werden. Frühere Nutzung (prior use), dieser Begriff betrifft den Endanwender und wird künftig in den Normen der Reihe IEC verwendet werden. Er wird überarbeitet Dokumentierte Beurteilung, beruhend auf Betriebserfahrungen in einer ähnlichen Umgebung, dass ein Gerät für die Verwendung in einem sicherheitstechnischen System geeignet ist und die Anforderungen hinsichtlich der Funktionen und der Sicherheitsintegrität erfüllen kann. ANMERKUNG Um ein Gerät für ein sicherheitstechnisches System auf der Grundlage früherer Nutzung zu qualifizieren, sollte der Anwender dokumentieren, dass das Gerät eine befriedigende Leistung in einer ähnlichen Betriebsumgebung erreicht hat. Das Verständnis dafür, wie sich das Betriebsmittel in einer bestimmten Betriebsumgebung verhält, ist erforderlich, damit man mit hoher Gewissheit annehmen kann, dass der beabsichtigte Entwurf, die beabsichtigte Sichtprüfung, Prüfung, Instandhaltung und die beabsichtigten betrieblichen Praktiken angemessen sind. 9

10 Änderung von Begriffen (9) Sicherheitshandbuch für neue und bereits früher genutzte Geräte Sicherheitshandbuch Geänderte Definition und neue Anmerkungen Handbuch, das die sichere Anwendung eines Gerätes, Teilsystems oder Systems beschreibt. ANMERKUNG 1 ANMERKUNG 2 Neu Feldgerät Dieses kann ein (allgemeines) einzelnes Schriftstück sein oder eine Sammlung von Schriftstücken. Das Sicherheitshandbuch kann das Sicherheitshandbuch des Herstellers für IEC konforme Objekte oder das Sicherheitshandbuch für betriebsbewährte Objekte enthalten. Gerät der PLT Betriebs- und Überwachungseinrichtung oder des sicherheitstechnischen Systems, das direkt an den Prozess angeschlossen ist oder sich in unmittelbarer Nähe zu diesem befindet. ANMERKUNG Das sind z. B. Sensoren, Stellgeräte oder handbetätigte Schalter. 10

11 Geänderte Definitionen (10) Typ A- und Typ B-Geräte eingeführt Neu Typ A-Gerät Gerät. dessen für eine festgelegte Funktion erforderliche Bauteile alle folgende Anforderungen erfüllen: a) das Ausfallverhalten aller eingesetzten Bauteile ist eindeutig definiert, und b) das Verhalten des Gerätes kann unter Fehlerbedingung vollständig bestimmt werden, und c) ausreichend verlässliche Ausfalldaten liegen vor, um zu zeigen, dass die angenommenen Ausfallraten für erkannte und unerkannte gefahrbringende Ausfälle erreicht werden. ANMERKUNG 1 Von einem Gerät, das keine Software oder Firmware benötigt, um eine festgelegte Funktion auszuführen, kann angenommen werden, dass es die oben stehenden Punkte a) und b) erfüllt. ANMERKUNG 2 ANMERKUNG 3 Von einem Gerät, das Software oder Firmware zur Ausführung einer festgelegten Funktion benötigt, ausgenommen programmierbare Logiksysteme (SPS), kann nur angenommen werden, dass es die oben stehende Punkte a) und b) erfüllt, wenn das folgende zutrifft: die Hardware des Gerätes wurde aufgrund früherer Nutzung ausgewählt (d.h. sie ist betriebsbewährt); das Gerät erlaubt nur die Einstellung prozessbezogener Parameter wie z. B. Messbereich und Signal-Ausfallrichtung im Fehlerfall (zum Messbereichsanfang oder ende); die Einstellung der prozessbezogenen Parameter im Gerät ist geschützt z. B. durch Brücken (jumper), Passwort; keine der sicherheitstechnischen Funktionen, die dieses Gerät verwenden, hat eine höhere Anforderung an die Sicherheitsintegrität als SIL 3. Feldsensoren, Stellgeräte und Verknüpfungssteuerungen, die nicht programmierbar sind, werden gewöhnlich dem Typ A zugeordnet. Neu Typ B-Gerät Gerät, für das eines oder mehrere der Bauteile, die benötigt werden, um eine festgelegt Funktion zu erfüllen, nicht vom Typ A ist (programmierbare Steuerungen (SPS) werden gewöhnlich dem Typ B zugeordnet). 11

12 Änderungen von Begriffen (11) Systematische Eignung eingeführt Systematische Eignung Maß des Vertrauens (ausgedrückt auf einer Skala von SC 1 bis SC 4), dass die systematische Sicherheitsintegrität eines Gerätes den Anforderungen des festgelegten SILs hinsichtlich der festgelegten Sicherheitsfunktionen entspricht, wenn das Gerät in Übereinstimmung mit den im Sicherheitshandbuch für IEC konforme Objekte für das Gerät festgelegten Anweisungen betrieben wird. ANMERKUNG 1 Die systematische Eignung wird mit Bezug auf die Anforderungen zur Vermeidung und Beherrschung von systematischen Fehlern bestimmt (siehe IEC und IEC ). ANMERKUNG 2 ANMERKUNG 3 Der systematische Ausfallmechanismus hängt von der Art des Gerätes ab. Für ein Gerät, das nur Hardware enthält, brauchen z. B. nur Mechanismen zum Hardwareversagen betrachtet werden. Für ein Gerät, das Hard- und Software enthält, wird es notwendig sein, sowohl Mechanismen zum systematischen Hardwareausfall als auch zum Softwareversagen zu betrachten. Eine hinsichtlich der festgelegten Sicherheitsfunktionen systematische Eignung SC N eines Gerätes bedeutet, dass die systematische Sicherheitsintegrität für SIL N erreicht ist, wenn das Element in Übereinstimmung mit den im Sicherheitshandbuch für IEC konforme Objekte für das Geräte festgelegten Anweisungen betrieben wird. 12

13 Neue Anforderungen zur Prüfung und deren Planung Prüfverfahren Zusammenführung des Anwendungsprogramms, der Hardware und der Feldgeräte sowie von Teilsystemen, die anderen Normen unterliegen ( wie z. B. Maschinen und Feuerungsanlagen) Arten der durchzuführenden Prüfungen und Prüfumfang Prüffälle (test cases) und Prüfdaten Prüfumgebung einschließlich Werkzeugen, Unterstützung durch Dienstprogramme, eingebetteter Software und der benötigten Konfiguration Prüfkriterien (z. B. gut/schlecht Kriterien) Anweisungen für Abhilfemaßnahmen, wenn während der Prüfung ein Ausfall auftritt Ortsinformationen (z. B.Anlage oder Standort) Abhängigkeiten von Funktionalitäten außerhalb geeignetes Personal Nicht-Sicherheitsfunktionen und Prozess- und Kommunikationsschnittstellen, die in sicherheitsbezogene Signale und Funktionen eingebunden sind, müssen daraufhin überprüft werden, dass sie das sicherheitstechnische System im Normalbetrieb und bei einer Störung nicht beeinflussen. 13

14 Neue Anforderungen für eine Beurteilung des Risikos aus der IT-Sicherheit Für das sicherheitstechnische System und die zugehörigen Geräte muss eine Risikobeurteilung hinsichtlich der IT-Sicherheit durchgeführt werden. Diese muss ergeben: eine Beschreibung der Geräte, die durch diese Risikobeurteilung abgedeckt werden (z. B. sicherheitstechnisches System, Betriebs- und Überwachungseinrichtungen oder jedes andere Geräte, das mit dem sicherheitstechnischen System verbunden ist); eine Beschreibung aller festgestellten Bedrohungen, die möglicherweise Schwachstellen ausnutzen und zu IT-Sicherheits-Vorfällen führen können (einschließlich absichtlicher Angriffe auf die Hardware und zugehöriger Software sowie unbeabsichtigte irrtümliche Angriffe); eine Beschreibung der möglichen Auswirkungen eines IT-Sicherheitsereignisses und die Wahrscheinlichkeit dessen Auftretens; Berücksichtigung verschiedener Phasen wie Entwurf, Betrieb und Instandhaltung; die Feststellung von Anforderungen zur weiteren Verminderung des Risikos; eine Beschreibung der zur Beseitigung oder Verminderung der Bedrohung getroffenen Maßnahmen oder eine Verweisung auf Informationen hierüber. Eine Anleitung zur IT-Sicherheit des sicherheitstechnischen Systems wird in der 2. Ausgabe der IEC im Abschnitt 20 IT-Sicherheit des sicherheitstechnische Systems enthalten sein. 14

15 IT-Sicherheit und Sicherheit Sicherheit Klares Ziel aufgrund gut verstandener Bedrohungen. IT-Sicherheit Bewegtes Ziel, da sich neue, bösartige Bedrohungen nicht in Anleitungen wiederfinden. Dennoch sollten Anwendungsingenieure verbesserte Handlungsanleitungen nachfragen. 15

16 Der Inhalt der Spezifikation der Anforderungen an die Sicherheit wurde verbessert und ausgeweitet Anforderungen an Anwendungsprogramme verbessert, z. B. Kapazität und Antwortzeiten Watchdogs im Anwendungsprogramm Validierung der Datenbereiche Überwachung der Feldgeräte im sicherheitstechnischen System Kommunikationsschnittstellen Anforderungen an die Vorgehensweise zur Wiederholungsprüfung eingeführt z. B. Prüfdauer Offline/Online Prüfungen Zustand des Prozesses während der Prüfung Feststellung von Ausfällen infolge gemeinsamer Ursache 16

17 Erkennung eines Fehlers Alarme und Bedienertätigkeiten Eine Tätigkeit, die dazu dient, einen sicheren Zustand des Prozesses nach dem Auftreten eines Fehlers zu erreichen oder aufrecht zu erhalten, sollte in der Spezifikation der Sicherheitsanforderungen festgelegt werden. Wenn die Tätigkeit von einem Bedieneingriff als Antwort auf einen Alarms abhängt (z. B. Öffnen oder Schließen eines Ventils), muss der Alarm als Teil des sicherheitstechnischen Systems betrachtet werden (d. h. unabhängig von den Betriebs- und Überwachungseinrichtungen). Wenn die Tätigkeit von einer Reparaturanforderung des Bedieners an die Instandhaltung abhängt, darf der Alarm Teil der Betriebs- und Überwachungseinrichtung sein, aber er muss angemessenen Wiederholungsprüfungen und einem Änderungsmanagement unterworfen werden, und der Diagnose-Deckungsgrad, der für diesen Diagnosealarm angenommen wird, muss auf 90 % begrenzt werden. Wenn die Reparatur des fehlerhaften Teils nicht vollständig innerhalb der bei der Berechnung der Wahrscheinlichkeit von zufälligen Hardwareausfällen angenommenen mittleren Dauer bis zu Wiederherstellung (MTTR) durchgeführt werden kann, muss eine dafür vorgesehene Tätigkeit ausgeführt werden, um einen sicheren Zustand zu erreichen oder aufrecht zu erhalten. 17

18 Anforderungen hinsichtlich früherer Nutzung klarer formuliert Die Nachweise dafür, dass ein Gerät zum Zweck passt (Information zur früheren Nutzung) müssen auf jeden Fall dokumentiert werden. Auf früherer Nutzung beruhende Bewertung beinhaltet das Zusammenstellen dokumentierter Informationen über die Leistungsfähigkeit des Gerätes in einer ähnlichen Betriebsumgebung. Die frühere Nutzung zeigt die Funktionalität und Integrität des eingebauten Gerätes einschließlich der Prozessberührung, der Grenzen des gesamten Gerätes, der Kommunikation und Hilfsmittel. Das Hauptergebnis der Bewertung der früheren Nutzung ist der Nachweis, dass das Gerät frei von gefahrbringenden systematischen Fehlern ist. Auf Grundlage von ausreichenden Betriebsstunden können die Hardwareausfallraten festgestellt und für die Berechnung der mittleren Wahrscheinlichkeit eines gefahrbringenden Ausfalls bei Anforderung der Sicherheitsfunktionen (PFD avg ) verwendet werden. Eine installierte Basis von zusammen mindestens Betriebsstunden in verschiedenen Einbauorten wird empfohlen und sorgt für ausreichend Zeit für Frühausfälle, die z. B. aus der Spezifikation der Handhabung, des Einbaus und der Inbetriebnahme herrühren. 18

19 Frühere Nutzung Sicherheitshandbuch und Management der Änderungsanforderungen Ein Sicherheitshandbuch, das die Randbedingungen für den Betrieb, die Instandhaltung und die Fehleraufdeckung enthält, muss verfügbar sein und die typischen Konfigurationen der Komponenten und Teilsysteme und die beabsichtigten Betriebsprofile umfassen. Geräte, die auf Grund früherer Nutzung ausgewählt worden sind, müssen durch eine festgelegte Revisionsnummer gekennzeichnet sein und einem Änderungsmanagement unterliegen. Falls Änderungen an dem Gerät durchgeführt werden, muss begründet werden, weshalb die auf früherer Verwendung beruhenden Nachweise weiterhin gültig sind, indem die Bedeutung der durchgeführten Änderungen bewertet wird. 19

20 Anforderungen zur Hardwarefehlertoleranz (HFT) vereinfacht und gestrafft (1/2) Die Hardwarefehlertoleranz des sicherheitstechnischen Systems oder Teilssystems muss mit bis oder den Anforderungen nach IEC :2010, übereinstimmen (Route 1H). der Anteil sicherer Ausfälle (SFF) wird in der 2. Ausgabe nicht mehr enthalten sein. Wenn das sicherheitstechnische System in unabhängige Teilsysteme (z. B. Sensoren, Logiksteuerung und Stellgeräte) aufgeteilt werden kann, darf die Hardwarefehlertoleranz des sicherheitstechnischen Systems den Teilsystemen zugeordnet werden. Bei der Bestimmung der erreichten Hardwarefehlertoleranz dürfen bestimmte Fehler ausgeschlossen werden, vorausgesetzt, dass die Wahrscheinlichkeit ihres Auftretens im Verhältnis zu den Anforderungen an die Sicherheitsintegrität sehr gering ist. Jeder derartige Fehlerausschluss muss begründet und dokumentiert werden. 20

21 Anforderungen zur Hardwarefehlertoleranz (HFT) vereinfacht und gestrafft (2/2) SIL 1 2 (niedrige Anforderungsrate) 2 (hohe Anforderungsrate) 3 4 Mindestens geforderte Fehlertoleranz X X X X X Wenn bei Geräten des Typs A die mindestens geforderte Hardwarefehlertoleranz zu einer verringerten Gesamtsicherheit führen würde, darf die Hardwarefehlertoleranz verringert werden. Dieses muss begründet und dokumentiert werden. Die Begründung muss zum Nachweis führen, dass die vorgesehene Architektur dem Verwendungszweck angemessen ist und die Anforderungen an die Sicherheitsintegrität erfüllt. Falls sich durch die Anwendung des obigen Punktes eine Hardwarefehlertoleranz von 0 ergibt, muss eine Begründung den Nachweis liefern, dass die betreffenden gefährlichen Ausfallarten ausgeschlossen werden können, einschließlich einer Abwägung der Möglichkeit von systematischen Ausfällen. 21

22 Verbesserte Anforderungen für Ausfalldaten Ausfalldaten müssen glaubwürdig, nachvollziehbar, dokumentiert und begründet sein. Die Ausfalldaten sollten auf Felddaten für ähnliche Geräte in einer ähnlichen Betriebsbedingung beruhen. Dieses beinhaltet vom Anwender gesammelte Daten, Daten, die der Hersteller oder Lieferant aus gesammelten Gerätedaten hergeleitet hat und Daten von allgemeinen Ausfalldatenbanken. In einigen Fällen kann ingenieursmäßiger Sachverstand verwendet werden, um Abschätzungen für fehlende Daten vorzunehmen oder den Einfluss einer unterschiedlichen Betriebsumgebung auf die Daten zu bewerten. Endanwender sollten entsprechende Datensammlungen durchführen, um die Anwendung der IEC zu verbessern. Bestimmte Normen beschreiben, wie Felddaten erfasst werden können (IEC oder ISO 14224). Bei der Berechnung der Ausfallkennzahlen müssen die Unsicherheiten der Ausfalldaten beurteilt und in Betracht gezogen werden. Verwendung der oberen Grenze des Vertrauensintervalls (z. B. 70 %) für jeden Zuverlässigkeitsparameter, der in die Rechnung eingeht, anstelle seines Mittelwertes, so dass man konservative Schätzungen der Ausfallkennzahlen erreicht. Die Testabdeckung (proof test coverage, PTC) jeder Wiederholungsprüfung, deren Durchführung und die Zuverlässigkeit der hierzu verwendeten Einrichtungen muss für die Nachprüfung des Hardware-SILs (PFD avg ) in Betracht gezogen werden. 22

23 Neuer Anwendungsbereich der Anwendungsprogrammentwicklung Spezifikationen der Anforderungen an die Sicherheit des SIS Anwendungsprogrammierer Sicherheitsvalidierung des SIS validiertes SIS Endanwender Spezifikationen der Anforderungen an die Sicherheit des Anwendungsprogramms Testen der Integration des Anwendungsprogramms Architektur des Teilssystems Entwurf der Architektur des Anwendungsprogramms Entwicklung des Anwendungsprogramms testen des Anwendungsprogramms Output Verification Entwicklung des Anwendungsmoduls testen des Anwendungsmoduls entwickeln und testen des Codes nur bei Programmiersprachen mit nicht eingeschränktem Sprachumfang Siehe IEC , Lieferant des PES 23

24 Überarbeitung des Abschnittes über die Anwendungsprogrammentwicklung (1/2) Wesentlich mehr Praxisorientierung. Softwareengineering-Methoden werden berücksichtigt: Die Techniken zum Schreiben des Anwendungsprogramms werden für alle SILs die gleichen sein. Softwarearchitektur und Verifikationstiefe werden SIL-abhängig werden. Konfigurationsmanagment, Versionsverfolgung Der entsprechende Abschnitt wird feste Programmiersprachen und Sprachen mit eingeschränktem Sprachumfang, aber keine Programmiersprachen mit nicht eingeschränktem Sprachumfang unterstützen und keine Anwendungsprogrammierung für SIL 4 behandeln. Genaue Anforderungen für eine Entwurfsspezifikation des Anwendungsprogramms Entwicklung und Implementierung des Anwendungsprogramms müssen mit den durch den Hersteller des speicherprogrammierbaren Logiksystems angegebenen Entwicklungswerkzeugen und Randbedingungen übereinstimmen. Nachverfolgbarkeit ist sicher zu stellen (traceability). 24

25 Überarbeitung des Abschnittes über die Anwendungsprogrammentwicklung (2/2) Anforderungen für die Verifikationen des Anwendungsprograms (überprüfen und testen) Verweisung auf Abschnitt 7 Das Anwendungsprogramm einschließlich seiner Dokumentation muss durch eine fachkundige Person, die nicht an der Entwicklung beteiligt war, überprüft werden. Überprüfungen und Tests müssen entsprechend niedergeschriebener Vorgehensweisen und Checklisten durchgeführt werden. Anforderungen an den Inhalt der Testdokumentation (Abschnitt 7) Anforderungen an Methoden und Werkzeuge zur Anwendungsprogrammierung Die Entwicklung des Anwendungsprogramms muss mit den Randbedingungen des Sicherheitshandbuches der programmierbaren elektronischen Steuerung übereinstimmen. 25

26 Erweiterte Anforderungen für Betrieb und Instandhaltung Berücksichtigung des Lebenszyklus des sicherheitstechnischen Systems Es muss ein Instandhaltungsplan für das sicherheitstechnische System zur Verfügung gestellt werden. Verwaltung des Bestandes an Ersatzteilen Instandhaltungsanalyse notwendig (z. B. Zeit zwischen Ausfällen der Betriebsmittel, Zeit für deren Instandsetzung) Planung der Wiederholungsprüfung Planung von Updates, Modernisierung und Ersatz der Hardware Planung von Updates, Backups und Wiederherstellung der Software. Verfahrensweisen für den Betrieb und die Instandhaltung müssen zur Verfügung gestellt werden, zum Beispiel um Qualität und Einheitlichkeit der Wiederholungsprüfungen sicherzustellen sowie angemessene Nachprüfungen nach dem Ersatz eines Gerätes. um Verzögerungen zu überprüfen und um deutliche Verspätungen der Wiederholungsprüfungen zu vermeiden. um Methoden und Prozeduren, die zum Test der Diagnoseeinrichtung verwendet werden, zu beschreiben. zur Datensammlung. 26

27 Neue Anforderungen für die Überbrückung des sicherheitstechnischen Systems Ein fortgesetzter Betrieb mit einem überbrückten Gerät oder Teilsystem des sicherheitstechnischen Systems darf nur erlaubt werden, wenn eine Gefährdungsanalyse festgestellt hat, dass die ergriffenen Ersatzmaßnahmen das Risiko angemessen vermindern. Ausgleichsmaßnahmen, die einen fortgesetzten sicheren Betrieb gewährleisten, während das sicherheitstechnische System durch eine Überbrückung außer Funktion ist oder vermindert arbeitet (Reparatur oder Prüfung), müssen innerhalb der zugehörigen betrieblichen Grenzen (Dauer, Prozessparameter) angewandt werden. Betriebliche Vorgehensweisen müssen entwickelt werden, um die zur Sicherstellung der funktionalen Sicherheit notwendigen Ersatzmaßnahmen festzulegen. Der Zustand der Überbrückung des sicherheitstechnische Systems und ihre Dauer muss über die Benutzerschnittstelle angezeigt und/oder in einem Überbrückungsbuch aufgezeichnet werden. Der Bediener muss über die vor und während einer Überbrückung anzuwendenden Vorgehensweisen in Kenntnis gesetzt werden und ebenso darüber, was vor dem Entfernen einer Überbrückung getan werden sollte und wie lange diese höchstens bestehen bleiben darf. Diese Information muss regelmäßig revidiert werden. 27