Problematische Rechenwege und Systemdefinitionen der EN 13849-1

1. Fall: Stichwort: Der geforderte Performance-Level wird nicht erreicht:

Ein großes Problem bei der Anwendung der Norm EN-13849-1 entsteht, wenn das vorgesehene Elektronische Sicherheitssystem trotz einer sinnhaft gewählten Sicherheitsstruktur nicht die erforderliche Sicherheitskennzahl (Perfomance-Level) erreicht.

Dann wird meistens der Schluß gezogen, daß keine vernünftige Lösung möglich ist. Dies bedeutet juristisch, daß Ihr Produkt nicht die vorgeschriebene Norm erfüllt und eigentlich nicht vertrieben werden darf.

Das aber ist für uns keine "Endstation".

Die Lösung liegt dann in einer ingenieurmäßigen Um-Interpretation der Norm.

Diese zunächst "abenteuerlich" anmutende Formulierung hat einen tieferen Sinn. Die "Väter" dieser Norm haben die Berechnung der Sicherheitskennzahlen in ein graphisches Schema gezwungen, welches nur eine Überschlagsrechnung darstellt. Diese einfache Überschlagsrechnung enthält - wie jede überschlägige Rechnung im Sicherheitsbereich - hohe Sicherheitsreserven, die das von Ihren Entwicklern beklagte schlechte Ergebnis der Sicherheitskennzahlen (Performance-Level) zur Folge haben.

Die oben erwähnte Um-Interpretation der Norm ist nun eine erneute ingenieurmäßige Betrachtung "mit Augenmaß" und erneute Berechnung des entworfenen Sicherheitssystems, wobei eine "richtige" ingenieurmäßige Berechnung der Sicherheitskennzahlen durchgeführt wird. Dazu benötigt man natürlich die mathematischen Zusammenhänge, die die Ausfallwahrscheinlichkeiten von verschalteten elektronischen Strukturen (Funktionsstrukturen im Zusammenwirken mit den Sicherheitsstrukturen) darstellen.

Dieser Weg ist grundsätzlich erlaubt, es gilt in jeder Norm, daß eine Abschätzung durch eine exakte Berechnung ersetzt werden darf (steht sogar explizit in der EN-13849-1).

Vergleichende Berechnungen haben uns gezeigt, daß dabei - je nach vorhandener Struktur - sehr große Unterschiede entstehen, die Zehnerpotenzen in der Sicherheit freisetzen.

-------------------------------------------------------------------------

 2. Fall: extreme, zeitaufwendige Software-Prüfungen

Im günstigsten Fall erreichen Sie bei dem Entwurf Ihrer Sicherheitsstruktur gerade noch die erforderliche Performance.

Wenn man nun denkt, damit sind alle Sichheitspflichten erfüllt, dann erschreckt man beim Lesen der Auflagen zur Sicherstellung der Softwarefunktionen.

Zu dieser Sicherstellung sind in der Regel derart umfangreiche Tests erforderlich, so dass (salopp gesagt) die Freigabe oder der Serienanlauf so spät erfolgen können, dass entweder das Produkt am Markt zu spät platziert wird oder bereits die ersten Fehler bei Serienanlauf eine Überarbeitung der Software erfordern und damit das aufwändige Testen der neuen Software von vorne beginnt.

In vielen Fällen wird so die Software niemals fertig und niemals ein Produkt auslieferbar.

Um diesem Zustand abzuhelfen, gibt es eine systematische Vorgehensweise, die Hardware- und Softwarestruktur so gestaltet, dass Prüfungen der Software binnen Wochen (statt Jahren) erledigt werden können. Die Begründung dafür ist, eine Struktur zu implementieren, die sozusagen während des Betriebs auch gleich die Software mit testet: On-Board-Software-Test.

Damit sind Sie mit Ihrem Produkt zeitnah am Markt !

Dieses Vorgehen beherrschen wir und bieten ein unverbindliches Gespräch für die Lösung Ihres Problems an (siehe unter „unsere Leistungen“).

-----------------------------------------------------------------------

3. Fall: Stichwort : "zu viele Tote"

Die hier behandelte Norm beschränkt sich auf Risikobetrachtungen mit dem Maximalrisiko von 1 Toten bei Betätigung einer zu betrachtenden Risiko-Funktion. 

Sie möchten möglicherweise eine Maschine auf den Markt bringen, die im Fehlerfall mehr als einen Toten verursacht (Umfallen eines Kranes, Explosion, Hineinfahren in eine Menschenansammlung....). 

Hier kann die Möglichkeit der paragraphengemäßen Auslegung der Norm enden. Dann aber ist „guter Rat teuer“. Wie sichern Sie sich nun trotzdem normenkonform ab?

Wir kennen die „ingenieurmäßig saubere“ Erweiterung der Norm und die Konsequenzen für die Hardware-Softwarestrukturen und helfen Ihnen über diese Hürde.