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:

• Variante: eine Entweder-Oder-Beziehung (XOR) zwischen verschiedenen Funktionen oder Systemelementen
• Option: eine Oder-Beziehung (OR) – eine Funktion oder ein Element ist nicht zwingend erforderlich, sondern kann in einer Konfiguration verwendet werden
• Default: Eine Funktion oder ein Element muss zwingend vorkommen

Darüber hinaus kann die Varianz in einem Modell durch Bedingungen eingeschränkt werden. Solche Bedingungen sind:

• Mandatory (oder requires): Eine Funktion oder ein Systemelement benötigt ein anderes zwingend
• Exclude: Wenn eine bestimmte Funktion oder Systemelement gewählt ist, kann ein bestimmtes anderes Element nichtmehr genutzt werden
• Wenn-Dann: Für komplexere Bedingungen können Wenn-Dann-Regeln definiert werden, die nach bspw. mehrere bedingende Funktionen oder Systemelemente beinhalten.

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.

• Varianz kann bewusst geplant werden, insb. in Abstimmung zwischen Produktmanagement und Entwicklung, die auf Basis einen Modells ihr gemeinsames Verständnis sicherstellen
• Auf Basis der modellierten Varianz können konkrete Konfigurationen definiert werden, sei es, um in der Entwicklung bestimmte Konfigurationen fokussiert zu analysieren, Kundenkonfigurationen zu dokumentieren oder alle denkbaren Konfigurationen auszuleiten
• Die Integration von Varianz in das Systemmodell sichert die Traceability von Anforderungen über Funktionen bis zur Lösung. So kann insb. im Fall von Änderungen der Impact festgestellt 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. Bremer

Dr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS.

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/