IEC 61508, ISO26262, DO 178C, ISO 25119: Sind Ihnen diese Kürzel schon mal in Ihrem beruflichen Alltag begegnet? Falls ja, dann ist die Wahrscheinlichkeit hoch, dass Sie Funktionale Sicherheitsprojekte bereits in Ihrem Unternehmen durchführen oder dass Sie in näherer Zukunft in diesen Markt einsteigen werden.
Vielleicht haben Sie auch schon selbst die Erfahrung gemacht, bzw. zumindest davon gehört, dass insbesondere Software Projekte im Umfeld der Funktionalen Sicherheit nur mit sehr hohem Dokumentations- / Testaufwand durchführbar sind. Noch dazu sind solche Projekte sehr starr, ineffizient und unflexibel.
Kommt Ihnen eine solche Argumentation oder Erfahrung bekannt vor?
Insbesondere für Sie, aber auch für alle Anderen, möchte ich in diesem Blog aufzeigen das dies nicht so sein muss. Im Gegenteil, ich möchte Sie ermuntern dass Sie sinnlose Dinge aus Ihrem Entwicklungsprozess streichen und dafür eine für in sich schlüssige, auf Ingenieursprinzipien beruhende Vorgehensweise wählen.

Typische Ausgangssituation:

Es gibt zwei Projektsituationen die ich immer wieder antreffe. In der ersten, arbeitet eine Firma schon länger in Projekten der Funktionalen Sicherheit. Insbesondere der Software Entwicklungsprozess wird aber als sehr ineffizient und überladen angesehen. Fast keine Mitarbeiter haben Interesse in einem neuen Safety Projekt zu arbeiten. Wenn überhaupt dann will ein Entwickler „nur“ den Code erstellen, um den ganze Rest soll sich der Safety Manager kümmern. Die Safety Entwicklung strahlt innerhalb der Firma überhaupt keinen Reiz aus.

Die zweite Situation ist die, dass eine Firma neu einsteigt in das Thema Funktionale Sicherheit und einen Software Prozess definiert, der die relevante Norm (je nach Branche IEC 61508, ISO26262 etc.) erfüllt. Typischerweise, werden alle „Requirements“ der Norm oft in Excel-Tabellen kopiert und dann wird versucht diese Excel Tabelle vollständig zu erfüllen. Dazu werden dann Pläne und Vorgaben ausgearbeitet. Als Ergebnis entsteht ein komplexer Software Entwicklungsprozess der in der Praxis nicht umsetzbar ist.
Beide Szenarien haben gemeinsam, dass kaum jemand Lust hat Safety Projekte durchzuführen.

Lösungsansätze:

Der Kern der Lösung ist für mich das KISS Prinzip: Keep it simple and stupid! Dieses Prinzip hilft sehr bei der Definition eines schlanken, effizienten und trotzdem alle Forderungen der Norm erfüllenden Software Entwicklungsprozesses. Hier einige Beispiele an welchen Stellen sich das wunderbar anwenden lässt:

1. Requirements: Beschreiben Sie in Datenbanken nur technische, bzw. funktionale Requirements. Strategische, politische, und terminliche Anforderungen gehören in Strategiepapiere und Planungsdokumente.
2. Architektur und Design: Erstellen Sie eine Softwarearchitektur oder das Softwaremodell in grafischer Form in einem passenden Tool. Beschreiben Sie die Architektur nicht in epischen Texten in Requirementsdatenbanken.
3. Codierrichtlinien: Überlegen Sie sich wie Ihre Entwicklungsstrategie für den Code lautet und legen sie danach die einzuhaltenden Codierrichtlinien fest. In der Regel macht es keinen Sinn zu versuchen den vollständigen MISRA Standard einzuhalten.
4. Test: Erstellen Sie keine isolierten Unittests, deren ausschließliches Ziel die Erreichung der strukturellen Source Code Coverage. Viel besser ist eine über alle Ebenen hinweg integrierte Teststrategie. In vielen Fällen wird eine GAP-Testing Strategie das Mittel der Wahl sein

Wenn Sie diese Beispiele umsetzen, wird die Motivation Ihrer Mitarbeiter deutlich ansteigen, Safety Projekte durchzuführen. Gleichzeitig werden Sie die Audits zur Funktionalen Sicherheit bestehen.

Ihre individuellen Fragen zur Funktionalen Sicherheit beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).