• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • UNTERNEHMEN
  • PRODUKTE
  • HEICON BLOG
  • Deutsch
    • Deutsch
    • English
  • Menü Menü
Du bist hier: Startseite1 / FuSi_Allgemein2 / Guter Safety Software Entwicklungsprozess – Was ist das?

Guter Safety Software Entwicklungsprozess – Was ist das?

FuSi_Allgemein

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).

27. April 2017/0 Kommentare/von HEICON Global Engineering GmbH
Schlagworte: CENELEC, en 50657, EN50128, Entwicklungsprozesse, Funktionale Sicherheit, FuSI, IEC61508, ISO26262, Requirements, RTCA DO178, Software Engineering, Test, Verifikation
Eintrag teilen
  • Teilen auf Facebook
  • Teilen auf Twitter
  • Teilen auf WhatsApp
  • Teilen auf LinkedIn
https://heicon-ulm.de/wp-content/uploads/2015/01/DI1A6023_klein_Funktionale-Sicherheit.jpg 433 547 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2017-04-27 22:26:242021-06-06 20:57:42Guter Safety Software Entwicklungsprozess – Was ist das?
Das könnte Dich auch interessieren
ISO26262ISO 26262 ASIL Dekomposition – Chancen und Risiken!
Requirement EngineeringRequirement/Code Review – Das bessere TDD?
Funktionale SicherheitFunktionale Sicherheit und agile Entwicklungsmethoden – Ein unüberbrückbarer Gegensatz (Teil 2)?
IndustrieFunktionale Sicherheitsgrundnorm IEC 61508
BahnEN 50128 Funktionale Sicherheit in der Bahnindustrie
Funktionale SicherheitRückwirkungsfreiheit – Die gelebte Praxis!
0 Kommentare

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlasse uns deinen Kommentar!

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kategorien

  • A_Requirement Engineering
  • B_Validation und Verifikation
  • C_Konfig-/ Änderungsmanagement
  • D_Security
  • FuSi_Allgemein
  • FuSi_Automotive
  • FuSi_Bahn
  • FuSi_Industrie
  • FuSi_Landwirtschaft
  • FuSi_Luftfahrt

Kontakt

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Tel.: +49 7353 – 98 17 81
Mobil: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRESSUM  |  DATENSCHUTZ

Implizites Testen – Eine gute Idee (Teil 2)?Validation und VerifikationFunktionale SicherheitStrukturelle Source Code Überdeckung auf dem Target!
Nach oben scrollen