Moderne Entwicklung nach dem Design-Centered-Approach
In der Entwicklung von mechatronischen Systemen wird seit Längerem versucht die Entwicklungsprozesse der Mechanik und des Systems denen der Hard- und Software-Entwicklung anzugleichen. Die Entwicklungsprozesse der Mechanik und des Systems werden bis heute stark von den Normen ISO9001 und TS16949 bestimmt, die von der Software durch ISO 15504 (SPICE).
Moderne Entwicklungsmethoden, wie die Modellbasierte-Entwicklung, werden eingesetzt, um einen hohen Innovationsgrad zu gewährleisten. Dafür ist es von essentieller Bedeutung, dass die Systementwicklung zu einem frühen Zeitpunkt zu bewertbaren Design-Entscheidung gelangt. Design-Entscheidungen können durch die FMEA Methodik bewertet werden, indem eine Risikobewertung der auszuführenden Funktionen erfolgt. Für das Software-Design wäre die Einführung von bewerteten Design-Entscheidungen von großem Nutzen. Die Norm zur Funktionalen Sicherheit ISO 26262 zielt ebenfalls in diese Richtung, indem sie die Bereiche System-, Hardware- und Software-Entwicklung jeweils durch ein V-Modell abbildet und Funktionen bezüglich ihres Risikos bewertet.
Es gibt aktuell keine Firma im automotive Bereich, die nicht große Anstrengungen unternimmt, Brücken zwischen den Methoden zu bauen. Dafür müssen insbesondere Software-Schnittstellen zwischen ALM Tools und PLM Tools programmiert werden. Auch Tools, die Daten aus Modellen z.B. aus Matlab in ALM Tools integrieren können, sind sehr gefragt. Obwohl es Tools gibt, die die Bearbeitung von FMEA in ALM Tools anbieten, wird die FMEA und das Anforderungsmanagement noch komplett parallel bearbeitet, weil ein integrativer Ansatz fehlt. Die daraus resultierende Doppelarbeit demotiviert die Entwickler, worunter das Projektergebnis leidet, was wiederum das Budget belastet (Abb. 1).
Abbildung 1
SIBAC Int. zeigt eine Lösung auf, wie die Prozesse und Methoden für ein System bestehend aus Mechanik, Hardware und Software, das modellbasiert entwickelt wird, sinnvoll durch den Ansatz des Design-Centered-Approach (DCA) integriert werden können. Der dafür nötige Paradigmenwechsel besteht in der Anzahl der zu betrachtenden Ebenen im Anforderugnsmanagement und der FMEA (Abb. 2).
Abbildung 2
Der DCA beschreibt die Herangehenweise an die Systementwicklung in unterschiedlichen Abstraktionsebenen. Jede Abstraktionsebene besteht aus einer Funktionsspezifikation und einer nachvollziehbar abgeleiteten Designentscheidung, dem Architekturdesign. Das Architekturdesign ermittelt sinnvolle Funktionsblöcke aus der Funktionsspezifkation und stellt die Funktionsblöcke in Beziehung (vgl. Funktionsblöcke in Matlab-Simulink siehe Abb. 1). Die Beziehungen der Funktionsblöcke sind die Schnittstellen des Systems. Die daraus ableitbaren Schnittstellentests sind die aus dem V-Modell bekannten Integrationstests. Die Folgeebene detailliert nachvollziehbar die ermittelten Funktionsblöcke.
Das hat in der Praxis den Vorteil, dass jede funktionale Beschreibung eines Funktionsblockes als Spezifikation bzw. Lastenheft in sich schlüssig ist und wahlweise intern bearbeitet oder nach extern vergeben werden kann (siehe Abb. 2). Die daraus ableitbaren Tests sind die bekannten System- bzw. in Abhängigkeit von der Ebene Subsystem-Tests.
Das mögliche Fehlverhalten des Systems leitet sich aus der Erweiterung der Funktionsspezifikation durch Fehlfunktionen ab. Dadurch kann analog zur FMEA Methodik das Ursachenelement für den Fehler auf jeder Ebene identifiziert und in der Auftretungs- und Entdeckungswahrscheinlichkeit bewertet werden. Damit liegt der Risikowert einer Designentscheidung dem Entwickler vor und liefert dem Projektteam klare Entscheidungensgrundlagen. Doppelarbeiten entfallen, der Entwicklungsstand ist jederzeit nachvollziehbar und das Team motiviert (siehe Abb. 3).
Durch den DCA wird die FMEA nahtlos in den Prozess für komplexe Produktentwicklungen integriert. Die vom VDA Band 4 empfohlenen 5 Ebenen haben in der Beschreibung von komplexen Systemen zu Zielkonflikten geführt, da die Systemkomplexität nicht ohne Kompromisse abgebildet werden kann. Der gewählte Ansatz löst diesen Zielkonflikt auf, indem das Archtikturdesign als zentraler Ausgangspunkt verwendet wird, und erfüllt so die erwähnten Normen umfassend.
In Abbildung 3 wird gezeigt, wie die Bewertung auf System-Ebene erfolgen kann. Das Design wird in mehreren Schleifen den System-Anforderungen angepasst. Eine A-Bewertung analog zur FMEA ist auf der Fahrzeug-Ebene noch nicht möglich. Zieht man aber die Systemtests wie sie aus dem Anforderungsmanagement bekannt sind hinzu, wird eine B*E Bewertung des Systemdesigns möglich. Sind die Funktionen auf der folgenden System-Ebene beschrieben, kann auch die A-Bewertung und damit die Berechnung der aus der FMEA bekannten RPZ erfolgen. Ebenso werden die ASIL Bewertungen in der Spezifikation direkt mit den Designbewertungen verknüpft.
Es entfällt die umständliche und zeitraubende Arbeit, Daten von einem in das andere Bewertungs- und Dokumentationssystem zu übertragen. Die Klarheit der Beschreibung der Spezifikation sowie die Übersichtlichkeit bei der Ableitung von Funktions- und Integrationstests nimmt deutlich zu.
Abbildung 3