Diskussion:Funktionale Sicherheit

Definition

Die FS eines Systems umfasst mehr als das, was in der 61508 drin steht. Dort werden nur elektrisch oder elektronische oder elektronische programmierbare Systeme abgehandelt. Pneumatische, mechanische (...) FS wird dort zwar erwähnt, aber nicht beschrieben. -- ~ğħŵ ₫ 13:22, 23. Mär. 2007 (CET)

Ja, das ist vollkommen richtig. Programmierbare Systeme stehen wegen ihrer Komplexität und ihrer leichten Modifizierbarkeit allerdings im Vordergund, aber im Prinzip gibt es ähnliche Probleme mit systematischen Fehlern auch bei anderen Systemen. --RAMSS 21:10, 23. Mär. 2007 (CET)

sicherheitsbezogen - sicherheitsrelevant - sicherheitskritisch

In diesem Artikel (wie auch in der Praxis) grassieren die Begriffe "sicherheitsbezogen", "sicherheitsrelevant" und "sicherheitskritisch".

Die Begriffe "sicherheitsbezogenes System (safety-related system)" und "sicherheitsbezogene Software (safety-related software)" sind in DIN EN 61508-4 definiert.

"sicherheitsrelevant" und "sicherheitskritisch" sind, soweit ich weiß, nirgends definiert. Jeder schmeißt damit um sich wie er will, und jeder versteht etwas anderes darunter. Kann da jemand weiter helfen? --85.93.75.6 16:07, 20. Jan. 2009 (CET)

"Sicherheitsrelevant" heißt im Artikel das gleiche wie "sicherheitsbezogen". "Sicherheitskritisch" taucht im Artikel nicht auf. Ich würde es in der Praxis erstmal genauso deuten wie "sicherheitsbezogen". Bei Systemen, wo EUC und sicherheitsrelevantes System getrennt sind (Trennung von EUC-Funktion und Sicherheitsfunktion auf unterschiedliche Hardware-Komponenten -- trifft nicht auf alle Systeme zu), könnte damit aber je nach Kontext auch das EUC gemeint sein. --Matthäus Wander 22:36, 9. Apr. 2009 (CEST)

Klassifizierung von Bedienungsfehlern

Gehören Bedienungsfehler (im Betrieb oder während Wartungsarbeiten) als menschliche Fehler zu den systematischen Fehlern oder, weil vorhersehbar und beherrschbar, zu den Störungen? Gruß – Rainald62 13:48, 7. Sep. 2009 (CEST)

Bedienungsfehler sind Ausfälle/Störungen, da der Mensch von einer eigentlich korrekt vorgegebenen Spezifikation (Benutzerhandbuch) abweicht und somit einen Fehler im System verursacht (ähnlich wie wenn ein Hardware-Bauteil ausfällt und von seiner Spezifikation abweicht).

• Beispiel: Der Operator hat Anweisung zu prüfen, ob sich Menschen im Gefahrenbereich aufhalten und, sofern der Gefahrenbereich frei ist, einen Freigabeknopf zu drücken. Der Operator übersieht jemanden und drückt den Knopf.

Zu den systematischen Fehler gehören eher solche Fehler, die ein Systementwickler in das System einbaut und die dem System innewohnen -- das System gilt dann als systematisch fehlerhaft, unabhängig davon ob der Operator einen Fehler macht oder nicht.

• Beispiel 1: Der Hardware-Designer hat die Schaltung fehlerhaft entworfen. Der Freigabeknopf ist permanent eingeschaltet.
• Beispiel 2: Im Benutzerhandbuch wurde die Anweisung vergessen, dass der Operator den Gefahrenbereich prüfen muss. Das Handbuch ist fehlerhaft. --Matthäus Wander 17:06, 11. Sep. 2009 (CEST)

Für die Praxis der Eisenbahnsignaltechnik mußte nach Richtlinie des Eisenbahnbundesamtes eine „Sicherheit gegen vorhersehbare Bedienungsfehler“ nachgewisen werden. Wie verträgt sich das mit dem Begriff Funktionale Sicherheit? --SonniWP✍ 11:47, 30. Dez. 2012 (CET)

Externe Einrichtung?

Was ist in der Definition im Artikel damit gemeint? In der Norm-Definition heisst es "Teil der Gesamtsicherheit, bezogen auf die EUC und das EUC-Leit- oder Steuerungssystem, der von der korrekten Funktion des E/E/PE-sicherheitsbezogenen Systems und anderer risikomindernder Maßnahmen abhängt". Wie soll das Sicherheitssystem die Sicherheit für externe Einrichtungen garantieren? Und welche? EUC oder Euc-Leif- und Steuerungssystem sollten doch zum betrachteten System gehören, in der Norm wird noch von Risikoreduktion durch externe Systeme gesprochen, aber das wäre ein Widerspruch, das kann das Sicherheitssystem nicht leisten... Ich würde vorschlagen stattdessen die Definition aus der Norm zu nehmen und durch ein Beispiel zu erläutern.--Duerer38 (Diskussion) 20:07, 17. Mai 2015 (CEST)

Einordnung der 26262

Kann mir jemand mal erklären, was der Satz "Bedienungsfehler werden von den Normen jedoch nicht erfasst, da das System dann eine Bewertung des manuellen Eingriffs ("vom Bediener gewollter Missbrauch zur Vermeidung eines noch größeren Schadens" oder "Fehler des Bedieners") treffen müsste." als Einleitungssatz zur 26262 bedeuten soll? Natürlich muss jede Norm zur funktionalen Sicherheit auch Bedienerfehler bis hin zum vorhersehbaren Missbrauch abdecken, so steht das jedenfalls im entsprechenden ISO/IEC Guide 51. Vorschlag: Richtigstellen oder Streichen?

Auch die Feststellung "Diese ist im November 2011 erschienen und seither gesetzlich festgeschrieben. " ist nach meiner Meinung falsch. Die Anwendung von Konsensnormen ist in der Regel immer freiwillig. Vorschlag: Belegen oder streichen.--Duerer38 (Diskussion) 22:30, 21. Mai 2015 (CEST)

Funktionale Sicherheit wird leider von Laien gerne falsch verstanden. Grundsätzlich geht es darum, die Funktionen einen Systems (funktionale Systembeschreibung) mit nicht-funktionalen Anforderungen zur Absicherung gegen Fehlfunktion zu ergänzen. Fehlfunktion wird hierbei klassischerweise in 2 Fälle eingeordnet: "(Teilweise) Ausführung, obwohl nicht getriggert", oder "Keine (vollständige) Ausführung, obwohl getriggert". Ob die Funktion dabei auf der abstrakt-funktionalen Ebene Verletzungssicherheit einhält, ist bei den meisten Definitionen von "reiner FuSi" gar nicht im Scope. Dieser Scope wird meistens nämlich als Gebrauchssicherheit bzw. "Safety in Use" beschrieben. Wenn man also zum Beispiel feststellt, dass man sich bei der Benutzung eines Systems irgendwo die Hand einklemmen kann, ist das kein FuSi Scope. Wenn man allerdings einen Sensor hinzufügt (bemerkt durch Analyse im Scope der Gebrauchssicherheit), der diese Verletzung absichert, indem er z.B. einen Systemstop auslöst, kann dieser Sensor, bzw. das zugehörige H/W-S/W-System nach FuSi Richtlinien abgesichert werden. Hier würde man im Beispiel aber nicht nur feingranulare Anforderungen ableiten (zB Kodierrichtlinien für involvierte Software), sondern zB auch durchaus abstraktere System-Architekturanforderungen stellen, z.B. "low-active" / invertierte Signalverarbeitung für den Sicherheitssensor (-> wenn dieser einmal kaputt geht, würde er sofort auslösen und das System stoppen, der Ausfall wird nicht erst durch nicht erbrachte Sicherheitsabschaltung bemerkt - dieses Systemdesign wiederum ist natürlich nur möglich für Systeme, deren Sicherheitsabschaltung jederzeit für den Benutzer ungefährlich ist). Sprich, die zuverlässige Funktion dieses Sicherheitssystems wird insgesamt sichergestellt. Das heißt, bei FuSi geht es primär nur darum, ein (meist E/E) System gegen gefährliche Fehlfunktionen abzusichern, während das funktionale Systemdesign selbst im Prinzip gar nicht hinterfragt wird in den Aspekten der Korrektheit und des Umfangs ausreichender Gebrauchssicherheit (ein guter FuSi-Ingenieur tut dies natürlich trotzdem und teilt das Ergebnis der entsprechenden Stelle mit). Warum diese Abgrenzung, wird man sich fragen? Nun, weil man nicht alles in einen Topf werfen soll. Gemäß divide-and-conquer Ansatz muss ein komplexes Thema wie Sicherheit in Domänen zerlegt werden und jeder Sicherheitsingenieur sollte das verstehen. Zwar sollte jeder aus seiner Domäne heraus die Gesamtsicherheit im Auge haben, sich aber primär um seinen Scope kümmern. Wenn man also in einem Vortrag sitzt, wo jemand behauptet: FuSi, das ist das, wo man gegen Verletzungsgefahr absichert! -> Nein, diese Formulierung ist viel zu unpräzise. Zumindest für den Anspruch eines sehr guten Sicherheitsingenieurs. Damit ist letztlich auch klar, warum man "bewussten Systemmissbrauch" bei FuSi meist ausklammert: Weil diese Sichtweise weit vom eigentlichen Kern von FuSi entfernt ist, und wiederrum unter der Gebrauchssicherheit betrachtet werden sollte. Quelle für diese Ausführungen: Direkt nachlesbar in IEC 61508, ISO 26262, etc. Grüße aus Ingolstadt. --91.42.206.32 11:01, 14. Nov. 2015 (CET)