Lesezeit 2 min
In UL 1998 geht es um Software für programmierbare Bauteile, die sicherheitsrelevante Funktionen ausführen, deren Ausfall zu Brand, elektrischem Schlag oder Personenverletzungen führen kann. Der Anwendungsbereich ist nahe bei Annex H von UL/EN 60730-1 (Functional Safety of Electronic Controls, Section H.11.12 Software).
Gewisse Produktsicherheitsnormen, wie z. B. UL/EN 62109-1 (Safety of Power Converters for Use in Photovoltaic Power Systems) fordern die Einhaltung eines Sicherheitslevels (SIL: Safety and Integrity Level), überlassen es aber dem Anwender, diesen nach UL 1998 oder nach Annex H von UL/EN 60730-1 nachzuweisen. Bei Produkten für den US-Markt steht man damit vor der Qual der Wahl zwischen diesen zwei Normen.
UL/EN 60730-1 hat den Vorteil der Homologisierung zwischen dem EU- und dem US-Markt, ist aber recht schwer zu lesen, wirkt sperrig und verzettelt. UL 1998 kommt dagegen schlank daher (rund 20 Seiten ohne Anhang) und wirkt aufgeräumt. Auf den ersten Blick scheint es einfacher zu sein, diese Norm zu erfüllen. Doch hält dieser Eindruck einer genaueren Prüfung stand?
Wer die beiden Normen im Detail vergleicht, stellt fest, dass weitgehende Parallelität in den Anforderungen besteht. Am auffälligsten ist es bei den Tabellen UL 1998 Table A2.1 und UL/EN 60730-1 Table H.1 (H.11.12.7), wo es um die Abdeckung von Hardware-Fehlern mit Hilfe von Software geht. Die Tabellen sind weitgehend identisch, SW class B (C) von UL/EN 60730-1 entspricht SW class 1 (2) von UL 1998.
Weniger auffällig ist es bei der geforderten Dokumentation und bei der Verfolgbarkeit von Anforderungen. UL/EN 60730-1 (Figure H.1) fordert hier ein gegenüber IEC 61508-3 leicht modifiziertes V-Modell, ein Begriff, den man in UL 1998 vergeblich sucht. Mit Sätzen wie z. B. in Abschnitt 4.7 ("safety-related requirements... shall be traceable throughout the SW process activities and documented evidence supporting compliance with this standard") wird aber faktisch ebenfalls ein V-Modell errichtet und die System- und SW-Architektur muss beschrieben und mit den Anforderungen verknüpft werden.
Es läuft darauf hinaus, dass bei beiden Normen, das gleiche getan werden muss: V-Modell, Massnahmen gegen zufällige Hardware-Fehler und gegen systematische Fehler, SW Partitionierung, statische Code Analyse, Unit Tests, usw.
Ernüchtert? Wer die Normen der funktionalen Sicherheit und ihre Abstammung von IEC 61508 kennt, ist nicht überrascht, im Gegenteil. Es ist gut zu wissen, dass es keine Abkürzungen gibt. Ingenieure haben über Jahrzehnte Techniken entwickelt, die sich als wirksam erwiesen haben, um die Sicherheit von Geräten zu garantieren. Um diese kommt man (zum Glück) nicht herum, sie werden nur in andere Worte gekleidet, je nach Norm.
Gerne unterstützen wir Sie mit unserem Normenwissen in der Zertifizierungsplanung!
Samuel Leemann
Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!
ist MSc EE ETHZ und Hardware-, System- und Safety-Spezialist sowie Mitbesitzer an Solcept. Seine früheren beruflichen Tätigkeiten waren im kaufmännischen Bereich und in der Entwicklung von Medizin- und Kommunikationstechnik. Prinzipien, die ihn bei Entwicklungsarbeiten leiten sind Einfachheit und Sicherheit. Samuel ist Alltagsvelofahrer, wandert gerne und hält sich mit Yoga fit.
Projekte? Ideen? Fragen? Machen wir einen kostenlosen Erst-Workshop!
Keine Kommentare