Category

After all those years, it’s almost disconcerting to see that – at least in the embedded software development domain – there is software written without unit tests. This technical depth needs to be refurbished in the aftermath with a much higher price. I don’t have to fool myself, I did it myself. But why don’t we see the benefits of a little bit of more effort in the beginning, which could save us hours of debugging in the future? I think it’s in the mind of everyone to make results as soon as possible.

With this blog post I would like to point out the major problems and give some inputs on how to make unit testing part of our daily business as software developers. READ MORE

Wie man ein Safety-Konzept erstellt und pflegt habe ich in verschiedenen Projekten bei unterschiedlichen Kunden erfahren dürfen. Dabei gab es in jedem Projekt Momente, wo uns die Komplexität drohte zu entgleisen: Die Traceability wurde unübersichtlich, eine FMEA ist ausgeufert oder enthielt plötzlich Doppelspurigkeit, oder eine Impact-Analyse wurde wegen fehlender Dokumentation der Abhängigkeiten schier unmöglich. Dies wieder in den Griff zu bekommen hat uns viel Mühe und Aufwand gekostet.

Da war mir natürlich ein Tool wie Ansys medini analyze herzlich willkommen. Es verspricht, all meine bekannten Probleme zu lösen, indem es die gängigen Methodiken und Werkzeuge für das Safety-Konzept in einem modellbasierten Tool vereinigt. Es schlägt somit Brücken wo ich vorher mühsam mit händischer Arbeit welche finden musste.

Auch innerhalb Noser Engineering war Ansys medini analyze noch nicht bekannt. Es musste also dringend eine eigene Erfahrung her, um die Versprechungen auf die Probe zu stellen. In Zusammenarbeit mit CADFEM habe ich während 1 Woche ein kleines Beispielprojekt erstellen dürfen.

Das Beispielprojekt

Als Beispiel habe ich einen “Industrial Lasercutter and plotter” gewählt, welcher den Anforderungen der Norm IEC 61508 entsprechen muss. Die funktionalen Anforderungen waren schnell formuliert und für das Beispiel absichtlich einfach gehalten:

• High performance Laser Cutter and Laser Plotter in a single robust housing.
• Cutting and plotting of different materials and patterns with high throughput for industrial purposes.
• Ethernet connection to an order and design system for full control.
• Simple operating elements on housing for easy and safe handling.

Ein abstraktes Systemskizze gab zudem erste Einblicke in die bevorstehenden Gefahren für Mensch und Maschine.

Mit dem Beispiel habe ich mich dem gängigen Vorgehen zum Erstellen eines Safety-Konzepts durchgearbeitet.

1. Erstellen eines Systemmodells
2. Erste Hazard-Analyze für die Ermittlung der Safety-Requirements
3. Aufstellung der Safety-Requirements
4. Safety-Architektur
5. System-FMEA

Ansys medini analyze hat mir dabei die ersten Schritte danke Templates stark vereinfacht und mich mit anderen Beispielen aus dem Automotive Bereich inspiriert.

Einblick in Ansys medini analyze

Systemmodell

Als erstes habe ich ein vereinfachtes Systemmodell erstellt. Dabei sind die wichtigsten Komponenten und Funktionalitäten bereits aufgelistet. Zudem hat Ansys medini analyze es ermöglicht, zu jeder Funktionalität oder Komponente bereits die ersten Fehlerfälle sauber zu notieren.

Prelimenary Hazard-Analysis

Dank den Fehlerfällen in dem Systemmodell liess sich die “Prelimenary Hazard-Analysis” schnell und einfach erstellen. Die ermittelten Hazards konnten notiert und mit den Fehlerfällen verlinkt werden. Zudem liess sich für jede Hazard auch eine Safety Measure beschreiben.

Safety-Requirements

Die Safety Measures aus der Hazard-Analyze habe ich in Safety-Requirements sauber ausformuliert und mit der Anforderungsansicht von Ansys medini analyze einfach dargestellt.

Safety-Architektur

Danach ging es an die Safety-Architektur. In dieser habe ich das System mit den zusätzlichen Safety-Komponenten ergänzt und alle für mein Beispiel relevanten Fehlerfälle ergänzt. Wichtig war dabei auch die Verlinkung zu Safety-Requirements.

FMEA

Aus der Safety-Architektur ist es mit Ansys medini analyze nur ein Klick bis zur FMEA. Das Tool erstellt das Gerüst mit allen bekannten Fehlerfällen automatisch und bietet auch vordefinierte Risikowerte und -kategorien. Die FMEA sauber zu Füllen war dann aber doch wie gewohnt eine händische Arbeit wo viel Detailwissen über die Fehlerfälle gefragt war.

Cause/Effect-Net

Kaum war die FMEA gemacht, hatte ich dank den Cause/Effect-Nets von Ansys medini analyze die Möglichkeit zu verfolgen, welcher Fehler zu welchem Hazard führt. Dabei werden die Cause/Effect-Nets automatisch durch das Tool erstellt. Es ist sogar möglich, im Cause/Effect-Net zu arbeiten und weiter Abhängigkeiten hinzuzufügen – wobei dann die FMEA automatisch ergänzt wird!

Weitere nette Features

Bei meiner Arbeit habe ich noch folgende Features gestreift, welche ich unbedingt bei meinem nächsten Projekt einsetzen möchte:

• Task-Listen (inkl. Verantwortlichkeiten, Termine, Links)
• Sauberer Diff-Viewer (auch für Templates nutzbar)
• Sauberer und umfangreicher Reportgenerierung

Fazit

Ja, Ansys medini analyze kann seine Versprechen halten.

Das Erstellen und Pflegen eines Safety-Konzepts wird einfacher und übersichtlicher. Verlinkungen können schnell und einfach erstellt werden, der modellbasierte Ansatz garantiert dabei eine saubere Nachverfolgbarkeit.

Die aktuellen Templates sind zwar für Automotive und Aerospace ausgelegt und für Medical und Railway wären einige Vorarbeiten nötig. Aber bereits bei einem Folge-Projekt kann dank den Templates sehr schnell profitiert werden.

Ansys medini analyze ist jedoch nicht als Stand-alone Tool ausgelegt. Es ist zwar viele innerhalb des Tools möglich, z.B. mit Task-Listen oder Verlinkungen von externen Dokumenten. Trotzdem ist der Haupt-Use-Case von Ansys medini analyze die Verwendung innerhalb der Ansys Tool-Landschaft oder unterstützend zu anderen grossen Requirement- und Modellierungs-Tools.

So oder so ist klar, Noser Engineering ist bereit für das nächste safety-relevante Projekt – aber am liebsten unterstützt durch Ansys medini analyze.