"Es funktioniert" reicht nicht: Risiken müssen bewusst gesteuert werden
Batteriesysteme speichern hohe Energie. Das ist kein kleines technisches Detail, sondern eine technische Realität, die unmittelbar mit der Gesundheit und dem Leben von Menschen zusammenhängt.
Dennoch wird funktionale Sicherheit in Batteriesystemen bei vielen kleinen und mittleren Unternehmen noch immer als Nebenthema behandelt. Statt ein selbstverständlicher Bestandteil der Produktentwicklung zu sein, wird sie oft aufgeschoben, bleibt unklar oder wird von der Organisation nie wirklich verantwortet.
Das eigentliche Problem ist nicht technisch, sondern eine Frage der Denkweise
Ein häufig beobachteter Ansatz sieht so aus:
- Das Produkt funktioniert, also nicht anfassen.
- Die Vorschriften verlangen es nicht ausdrücklich.
- Eine Zertifizierung wird nicht gefordert.
Auf den ersten Blick wirkt das pragmatisch, aber die entscheidende Wahrheit ist einfach:
Dass ein System funktioniert, heißt nicht, dass seine Risiken beherrscht sind.
Diese Denkweise löst oft das Problem von heute, und mit etwas Glück trägt sie eine Weile. Ein bewusster, vertretbarer technischer Ansatz ist sie jedoch nicht.
Besonders kritisch wird das bei Systemen mit folgenden Merkmalen:
- BMS und Batteriesysteme
- hohe Energiedichte
- komplexes Zusammenspiel von Hardware und Software
- mehrere mögliche Fehlerszenarien
Ohne klares Verständnis, wo, wann und wie Risiken entstehen, bleibt die Produktentwicklung fragil.
Was funktionale Sicherheit ist und was nicht
Funktionale Sicherheit ist nicht:
- ein Zertifizierungsziel
- für jedes Produkt eine verpflichtende vollständige Konformität
- reine Dokumentation
Funktionale Sicherheit bedeutet:
- Risiken sichtbar zu machen
- zu beantworten, wo, wann und wie ein System gefährlich wird
- Entscheidungen auf technische Argumente statt auf Intuition zu stützen
- technisches Wissen in der Organisation zu verankern, nicht bei einzelnen Personen
Kurz gesagt: Funktionale Sicherheit ist eine Ingenieurkultur.
Eine nüchterne Tatsache: ISO 26262 ist nicht einfach
Die durchgängige Umsetzung von ISO 26262:
- kostet Zeit
- erfordert umfangreiche Dokumentation
- verlangt diszipliniertes technisches Arbeiten
- wird mit steigenden ASIL-Stufen zunehmend teurer
Deshalb bleiben viele Teams zwischen zwei Extremen stecken: "Fangen wir gar nicht erst an" oder "Vollständige Konformität ist zu komplex und zu teuer." Die Realität beschränkt sich jedoch nicht auf diese beiden Optionen.
Warum eMOBINO das Starterpaket für funktionale Sicherheit entwickelt hat
Die häufigste Lücke, die wir sehen, ist eindeutig: Viele Teams wissen nicht, wo sie anfangen sollen. Funktionale Sicherheit wird entweder auf unbestimmte Zeit verschoben oder nur bruchstückhaft und unkontrolliert angegangen.
Gebraucht wird stattdessen ein Ausgangspunkt, der:
- handhabbar ist
- auf die Organisation zugeschnitten ist
- langfristig Wert schafft
- unabhängig von einzelnen Personen funktioniert
Genau dafür wurde das Starterpaket für funktionale Sicherheit entwickelt.
Was diese Arbeit ist und was nicht
Dieses Paket ist weder Software noch Hardware. Es ist eine auf Produkt und Organisation zugeschnittene Methodik, ein langfristiger Leitfaden für die Entwicklung und eine wiederverwendbare technische Referenz innerhalb des Unternehmens.
Das Ziel ist nicht, funktionale Sicherheit auf ein einzelnes Projekt zu beschränken, sondern sie in der technischen Denkweise des Unternehmens zu verankern.
Umfang: ein Starterset als ISO-26262-Referenz
Diese Arbeit deckt die Abschnitte 3.5, 3.6, 3.7, 4.5 und 4.6 der ISO 26262 ab, darunter:
- Definition der Systemarchitektur
- Definition der BMS-Architektur
- Architekturprüfung
- Item-Definition
- Funktionsbaum und Fehlerbaum
- Gefährdungsanalyse und Risikobewertung (HARA)
- Definition der Sicherheitsziele, einschließlich ASIL-Stufen
- technische Sicherheitsarchitektur des BMS
- System-FMEA des BMS
- Überprüfung des Konzepts zur funktionalen Sicherheit
- funktionale Sicherheitsanforderungen an das BMS-System
- Überprüfung der funktionalen Sicherheitsanforderungen an das BMS
Das Ziel
Das Ziel ist nicht, gleich am ersten Tag eine ASIL-D-Zertifizierung zu erreichen. Es geht darum, die technische Reife in Batteriesystemen zu erhöhen und einen Entwicklungsansatz aufzubauen, bei dem Risiken gründlich durchdacht und auf künftige Projekte übertragbar sind.
Steht diese Grundlage, können Teams Schritt für Schritt zu einer vollständigen, durchgängigen funktionalen Sicherheit weitergehen, wenn und sobald sie diese brauchen.
mustafa.simsek@emobino.com
www.emobino.com
