RFLP

Varianz im Systemmodell ist neben der Interdisziplinarität einer der wesentlichen Komplexitätstreiber bei der Entwicklung moderner mechatronischer Produkte und daher auch einer der Hauptgründe zur Nutzung von Model-Based Systems Engineering. Dabei taucht Varianz an unterschiedlichen Stellen auf, sei es im Systementwurf, in der Stückliste oder der Fertigung. Im diesem Beitrag analysieren wir, wie die Varianz auf Systemebene berücksichtigt werden kann. Einordnung in den RFLP Ansatz Wir fokussieren uns in unserem Beitrag auf Varianz, die auf Systemebene entsteht. Betrachten wir ein Systemmodell nach dem RFLP-Ansatz, tritt Varianz typischerweise auf funktions-, logischer- und physischer Ebene auf.  Auf Funktionsebene geht es typischerweise um mögliche alternative Funktionsumfänge, die das Produkt aufweisen kann. In diesem Zusammenhang wird an Stelle einer Funktion häufig auch der Begriff „Feature“ verwendet. Beschrieben wird, welche Funktionen oder Feature, ein Kunde wählen kann oder am Markt angeboten werden sollen. Auf logischer Ebene wird dann zugeordnet, wie eine Funktion umgesetzt wird. Dabei findet man jedoch nicht unbedingt immer eine 1:1 Zuordnung, es wird vielmehr in Betracht gezogen, ob ein Systemelement bspw. mehrere Funktionen umsetzen kann oder ob eine Überspezifikation zugunsten einer Teileersparnis Sinn macht. Darüber hinaus kann es auch gut sein, dass Funktionen, die ähnlich klingen und vermeintlich nur geringfügige Unterschiede aufweisen, mit anderen Technologien oder unterschiedlichen Produktfamilien umgesetzt werden. Dementsprechend ergibt sich der Variantenbaum aus genannten Überlegungen und ist daher in der Regel kein einfaches Spiegelbild des Funktionsbaums. Auf physischer Ebene wird die konkrete Umsetzung mit einem Bauteil definiert. Auf dieser Ebene spiegelt sich Varianz bspw. in Bauteilen wider, die von unterschiedlichen Zulieferern kommen, aber die gleich Spezifikation aufweisen oder an unterschiedlichen Standorten verbaut werden. Berücksichtigung von Varianz im Systemmodell Wie im Diagramm angedeutet, verstehen wir Varianz als Teil der Beziehungen zwischen den Modellelementen. Dabei kann diese Beziehung drei Ausprägungen annehmen: Darüber hinaus kann die Varianz in einem Modell durch Bedingungen eingeschränkt werden. Solche Bedingungen sind: In iQUAVIS setzen wir Varianten-Beziehung als Teil der Hierarchiebeziehung um. Im Bild zu sehen ist das Beispiel einer Wetterstation, die bspw. über zwei verschiedene Bildschirmgrößen verfügen könnte. Mögliche Bedingungen werden mittels Abhängigkeitsbeziehung modelliert, im Beispiel zwischen der kleineren Bildschirmgröße und dem Feature, auch Wind messen zu können. Im rechten Teil des Bilds wird der Feature Baum im „Varianten Filter“ noch einmal visualisiert. Hier gibt es die Möglichkeit, mittels Checkboxen, eine bestimmte Variante oder Option auswählen und somit die Varianz des Systemmodells auszuprägen. Damit kann zum einen das Verhalten des Modells geprüft sowie zum anderen konkrete Konfigurationen erzeugt werden. Nutzung des Systemmodells Ein MBSE Modell, das Varianz beinhaltet, kann als Grundlage zur Kommunikation und Kooperation mit anderen Projektbeteiligten genutzt werden. Die Informationen zur Varianz im Systemmodell bilden die Basis für verschiedene aufbauende Aktivitäten. Eine Plausibilitätsprüfung kann sicherstellen, dass die modellierte Variantenlogik frei von Widersprüchen ist. Das Product Line Engineering benötigt die Möglichkeit, Varianz auf Systemebene darzustellen, die sie sowohl für die Beschreibung der Produktlinie als auch der Produktfamilie relevant ist. In iQUAVIS setzt das Thema Varianz mit dem VariantenManager um. Mehr dazu erfahren Sie auf der Seite zum Variantenmanagement mit iQUAVIS. Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT, Administration und Personalwesen. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/