Hinzufügen vorhandener Daten in Arbeitsblätter

Die Nutzerunterstützung beim Einfügen vorhandener Daten wurde erweitert. Beim Suchen vorhandener Daten werden diese nun auch hierarchisch dargestellt. Zudem gibt es Freitextsuche. Damit können Daten nun besser überblickt und schneller gefunden werden (Abb.1).

Suche im Baum

Es ist nun möglich Modellelemente zu suchen (und zu finden) auch wenn diese in der Baumdarstellung ausgeblendet sind. Mit der v10 kann der gesamte Pfad eines Elements im Baum über die Datenliste eingeblendet werden. Das ermöglicht eine schnellere Suche, gerade in großen Projekten. (Abb.2)

Auch diese Neuerung geht auf den Input unserer Kunden aus dem DACH-Raum zurück, die wir strukturiert an unsere japanischen Kollegen weiterleiten. Wir arbeiten sehr eng mit den Kollegen dort zusammen und tauschen uns regelmäßig aus – zuletzt hat unser IT-Experte Georg ein paar Tage in Japan in der Zentrale von DENTSU SOKEN verbracht.

Erweiterung der Historiensuche auf sämtliche Speicherstände

Neben der Historienliste, die es schon länger in iQUAVIS gibt, gibt es jetzt die „Gesamte Verlaufssuche“ (Abb. 3). Das bedeutet:

• Jeder einzelne Speicherstand ist hier aufgeführt, unabhängig davon, ob ein Historienstand erzeugt wurde oder nicht.
• Die Speicherstände lassen sich wie Historienstände öffnen und durchsuchen.

Weitere Änderungen

Im Rahmen des v10 Updates kommen noch weitere, kleinere Updates:

• Die Update Buttons für Architektur und Projektplan sind nun zu einem Button verschmolzen.
• Strg+K funktioniert innerhalb von Tabellen auch auf für Attribute (passende Spalte wird ausgewählt)

• „Verantwortlicher“ ist im Tooltip anzeigbar
• Ablaufplan:
  • Veränderte Tasks hervorheben
  • Untergeordnete Tasks einklappen

Wann kommt die v10?

Unsere Kunden bekommen die v10 im Laufe der Monats Mai automatisch eingespielt. Haben Sie Interesse an iQUAVIS, nehmen Sie gern Kontakt auf.

iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über 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/

Wie Produktlinien systematisch entstehen

Product Line Engineering (PLE) verspricht, aus einer gemeinsamen Basis effizient viele individuelle Produkte zu entwickeln. In der Regel wird dabei zwischen Domänen-Engineering und Anwendungs-Entwicklung unterschieden. Doch was passiert eigentlich in diesen beiden Phasen und wie unterstützt iQUAVIS bei der Umsetzung dieses Ansatzes? 

Zwei mal zwei Perspektiven 

Im Schaubild Abb. 1 unten ordnen wir die wesentlichen Fähigkeiten von iQUAVIS ein. Das Bild ist horizontal in zwei Bereiche unterteilt: Links: Domänen-Entwicklung, die sozusagen die wiederverwendbaren Kernartefakte in den Blick nimmt. Rechts: die Anwendungs-Entwicklung, die auf ein konkretes Produkt fokussiert.

Vertikal werden zwei Ebenen unterschieden: Oben, die Marktperspektive, die Feature und Konfigurationen für die Kunden beschreibt, sowie unten die Architekturperspektive, in der es um die technische Basis geht, um ebendiese Feature realisieren zu können.

Domänen-Entwicklung: Die gemeinsame Basis schaffen 

Den methodischen Einstieg in die Domänen-Entwicklung bildet das Feature-Modell. Es repräsentiert die Marktsicht einer Produktlinie. Dabei ist ein Feature ein vom Kunden bestellbares Merkmal. Ein Feature fasst inhaltlich funktionale und nicht-funktionale Anforderungen zusammen.

Folgende Fragestellungen stehen hinter der Feature-Modellierung: 

• Welche Feature werden oder sollen zukünftig am Markt angeboten werden? 
• Wo gibt es Variabilität? 
• Welche Feature bedingen sich oder schließen sich aus? 
• Welche Features sind optional oder verpflichtend? 

Das Feature-Modell beschreibt also nicht ein einzelnes Produkt, sondern die gesamte Lösungsdomäne. Es ist das zentrale Kommunikationsmittel zwischen Vertrieb, Produktmanagement und Technik. 

Die Lösungsbausteine zu dem beschriebenen Feature-Modell finden wir in der Architekturperspektive in Form von Modulen bzw. architektonischen Bausteinen. Bei der Entwicklung dieser Bausteine zielt man auf: 

• Wiederverwendbare Komponenten 
• Architekturelle Muster 
• Schnittstellen 
• technische Variationspunkte 

Jeder Baustein ist so entworfen, dass er für viele Produkte wieder verwendbar ist. Variabilität wird bewusst eingeplant – nicht als Sonderfall, sondern als Kernprinzip. Das Ergebnis der Domänen-Entwicklung ist damit: 

• ein Feature-Model für die Markt‑ und Produktsicht 
• eine Referenzarchitektur aus Modulen/Bausteinen für die technische Umsetzung 

Anwendungs-Entwicklung: Konkrete Produkte bauen 

Während die Domänen-Entwicklung sozusagen die Bühne aufbaut, beginnt in der Anwendungs-Entwicklung die konkrete Ausprägung . 

Im oberen rechten Bereich des Schaubildes sieht man die Konfigurationen. Hier wird das Feature-Modell verwendet, um konkrete Produkte zu definieren: 

• Auswahl der Feature, aus denen ein konkrete Produkt besteht
• Berücksichtigung der Einschränkungen des Feature-Modells (Varianten, Optionen etc.)

Eine Konfiguration ist damit eine gültige Auswahl aus dem Feature-Model – sie beschreibt genau ein Produkt.

Aus der Konfiguration wird auf der Architekturebene im unteren rechten Bereich die Produktarchitektur abgeleitet. Das Schaubild zeigt: 

• Die Produktarchitektur entsteht nicht neu, sie wird aus den Bausteinen oder Modulen zusammengesetzt 
• Die Konfiguration steuert, welche Bausteine wie kombiniert werden 
• Aufgabe der Produktarchitektur ist die technische Plausibilisierung, also ob die Module über ihre Schnittstellen so zusammenpassen, wie es die Konfiguration definiert

So entsteht eine konkrete, lauffähige Architektur, die genau die zuvor gewählten Features unterstützt. 

Die Domänenentwicklung liefert also die Bausteine – die Anwendungsentwicklung setzt sie zusammen. 

Die Verbindung zwischen beiden Welten 

Ein zentrales Element des Bildes sind die Verbindungen: 

• Das Feature-Modell verweise auf die architektonischen Bausteine 
• Die Bausteine werden in konkreten Produktarchitekuren verwendet
• Eine Konfiguration verweist auf eine (plausible) Kombination von Featuren und die daraus abgeleiteten Lösungselemente

Genau diese Durchgängigkeit unterscheidet Product Line Engineering von klassischer Wiederverwendung oder Copy‑&‑Paste‑Entwicklung. Die Verknüpfung von Marktanforderungen bis zur technischen Umsetzung erfolgt modellbasiert und ist die Grundlage für Kommunikation und Kooperation Produktmanagent und Technik. Entscheidend ist, dass das aufgebaute Beziehungswissen nun in den unterschiedlichen Phasen der Produktentstehung genutzt wird:

• Für die Produktroadmap werden Feature zeitlich aufgeplant
• Die Architektur berücksichtigt die bestehenden Feature und die kommenden Feature (Big Picture) und wird entsprechend ausgelegt
• Technische Entscheidungen finden nicht isoliert, sondern vor dem Hintergrund ebendieser Planung statt
• Auch technische Risiken für bestimmte Feature oder Opportunitäten, die sich aus einer neuartigen Kombination von Lösungselementen ergeben könnten, werden auf dieser Basis erarbeitet
• Qualitäts- oder Risikomethoden berücksichtigen, in welchen Konfigurationen sich eine bestimmte Funktion oder Lösung befindet kann
• Bereits abgesicherte Module können wiederverwendet werden

Diese Liste an Nutzungsmöglichkeiten ließe sich noch weiter fortführen.

Wie unterstützt iQUAVIS bei diesem Ansatz? 

iQUAVIS bietet die notwendigen Toolfunktionalitäten, um den beschriebenen Ansatz umzusetzen. Es beinhaltet die Möglichkeit, Feature-Modelle zu definieren und entsprechende Abhängigkeiten zu modellieren. Die Feature können Lösungselementen zugeordnet werden. Bedingungen wie Exclude oder Mandatory können in verschiedenen Sichten angezeigt und bearbeitet werden (vgl. Abb. 2-4).

Der VariantenManager in iQUAVIS bietet darauf aufbauend die Möglichkeit, Varianten konkret auszuprägen – natürlich unter Berücksichtigung der Bedingungen des Featurebaums.

iQUAVIS bietet auch die Möglichkeit, wiederverwendbare Architekturbausteine anzulegen. Es stellt alle gängigen Modellierungsmethoden des MBSE zur Verfügung, um die Architekturbausteine in konkreten Systemmodellen zu nutzen.

Webinaraufzeichnung: Variantenmanagement für das Product Line Engineering

In diesem Webinar über Variantenmanagement mit iQUAVIS für das Product Line Engineering erhalten Sie einen praktischen Einblick. Beachten Sie zum Thema Varianten auch diesen Beitrag über Varianz im Systemmodell.

• 
  Produktmanagement mit iQUAVIS – Aufzeichnung
  von Sonja Feierabend
  26. Mai 2026
  Wenn Sie unser Live-Webinar über Produktmanagement mit iQUAVIS verpasst haben, erhalten Sie nun eine Chance, sich die Aufzeichnung anzusehen. Produktmanagement mit iQUAVIS Wie lassen sich strategisches Produktmanagement und modellbasierte Systementwicklung (MBSE) effektiv miteinander verbinden? Und wie kann ein Tool diese Zusammenarbeit konkret unterstützen?  In diesem Webinar zeigen wir, dass modernes Produktmanagement und MBSE nicht nebeneinander, sondern
• 
  iQUAVIS v10 – Update 2026
  von Christian Dr. Bremer
  19. Mai 2026
  Aus Japan hat uns die iQUAVIS v10 erreicht, an der wir noch einige Anpassungen für den europäischen Markt vorgenommen haben, damit iQUAVIS bei all unseren Kunden reibungslos läuft. Die wichtigsten Neuerungen der v10, die demnächst ausgerollt wird, stellen wir in diesem Blogartikel einmal vor. Hinzufügen vorhandener Daten in Arbeitsblätter Die Nutzerunterstützung beim Einfügen vorhandener Daten
• 
  Product Line Engineering mit iQUAVIS
  von Christian Dr. Bremer
  5. Mai 2026
  Im Product Line Engineering (PLE) entstehen Produktlinien systematisch aus einer gemeinsamen Basis. Dahinter steckt ein hochkomplexes Engineering, das wir in diesem Beitrag in der Theorie erläutern. In einem weiteren Beitrag werden wir die praktische Umsetzung aufzeigen. Wie Produktlinien systematisch entstehen Product Line Engineering (PLE) verspricht, aus einer gemeinsamen Basis effizient viele individuelle Produkte zu entwickeln. In der

iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über 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/

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/

Mehr zum methodischen Hintergrund der Methode CONSENS finden Sie in unserem separaten Beitrag zu CONSENS.

Übersicht zur CONSENS Methode

Die CONSENS Methode ist gegliedert in zwei Phasen: Die Analyse- und die Synthese-Phase. In der ersten Phase arbeitet der Anwender mit Anwendungsszenarien, Umfeldelemente und Anforderungen. In der zweiten Phase sind es hauptsächlich Funktionen, Lösungselement und ggf. Verhalten. In iQUAVIS bieten sich Baumansichten an, um die Übersicht über die Phasen und die Traceability zwischen den Modellelemente zu überblicken.

Neben den reinen Daten gibt CONSENS auch Bearbeitungsschritte vor, nämlich die schrittweise Erarbeitung der einzelnen Partialmodelle. iQUAVIS ermöglicht die Umsetzung solcher Vorgaben in der Prozesstabelle. Hier werden Aufgaben (standardisiert) definiert. Zu jeder Aufgabe gehören Sichten, in die der Nutzer direkt springen kann um so die Inhalte zu erarbeiten. Diese Sicht richtet sich daher an alle Nutzer und wird als Absprungebene in die einzelnen Aktivitäten genutzt.

Umsetzung der Partialmodelle

Die Partialmodelle von CONSENS werden in verschiedene Sichten in iQUAVIS umgesetzt. Für die Darstellung von Wirkstruktur und Umfeldmodell werden die Entity-Block-Diagramme verwenden. Für die Funktionshierarchie wird mit einer Baumansicht gearbeitet. Wie in CONSENS beabsichtigt, arbeitet iQUAVIS dabei auch mit starken optischen Unterscheidungselementen: So sind bspw. alle lösungsbehafteten Elemente (in iQUAVIS „Entity“) mit rechtwinkligen Ecken versehen. Lösungsneutrale Modellelemente wie bspw. Funktionen haben abgerundete Ecken. Auch mit Farben für Elemente oder Beziehungen kann gearbeitet werden.

Die Verhaltensmodellierung wird ebenfalls mit den entsprechende Diagrammtypen ermöglicht. In den Bildern zu sehen sind die Sequenz-, Aktivitäts- und Zustandsdiagramme.

Traceability und Nutzung der Methode CONSENS in iQUAVIS

Die in CONSENS angefertigten Partialmodelle stehen nicht für sich alleine, sondern ergeben ein konsistentes Ganzes. Dazu werden die Modellelemente zueinander verknüpft. Beispielsweise ergeben sich Anwendungsszenarien oder Use Cases aus Umfeldelementen; Funktionen werden durch Systemelemente realisiert; Anforderungen werden mit Testfällen abgesichert.

In der unten stehenden Grafik haben wir versucht, das so entstehende Systemmodell zu veranschaulichen. Insbesondere die Querbeziehungen bilden später die Grundlage für aussagekräftige Auswertungen:

• Ein Systemelement ändert sich – welche Funktionen und Anforderungen müssen nun neu geprüft werden?
• Wir können eine Anforderung nicht erfüllen, woher kam die eigentlich und gibt es andere Wege, den Kundenwunsch umzusetzen?
• Wer entwickelt eigentlich welches Systemelement und wann werden z.B. Informationen von anderen Kollegen dafür benötigt

Wir haben dem Aufbau des Systemmodells einen eigenen Beitrag gewidmet: Das Systemmodell mit iQUAVIS

Anpassung des CONSENS Profils

Die CONSENS Methode ist gut geeignet um einen Einstieg in das Thema MBSE zu ermöglichen. Sobald man jedoch als Nutzer die ersten Projekterfahrungen gesammelt hat und Schritt für Schritt tiefer in das Thema einsteigt, stellt man in der Regel fest, dass es weitergehende Anforderungen an die Methode gibt. Beispielsweise werden weitere Anforderungsklassen notwendig, oder neue Sichten werden benötigt für bestimmte (bereits etablierte) Methoden. Diese Situation ist unser Erfahrung nach die Regel, denn letztlich gibt es immer unternehmensspezifische Aspekte, die der Branche, der Art der Projekte oder den Unternehmensstruktur geschuldet sind. Hier bietet iQUAVIS intuitiv zu bedienende Tools für die Erweiterung an. Neue Modellelement-Klassen oder neue Attribute können direkt im Tool erzeugt werden.

iQUAVIS bietet dazu ein separates Administrationstool, mit dem Vorlagen und Profile zentral editiert und an alle Nutzer ausgerollt werden können. So kann auch dauerhaft sichergestellt werden, dass alle Nutzer mit den selben Modellelementen arbeiten und die Modelle so vergleichbar und standardisiert weiterverwendbar werden.

Ihre Fragen?

Haben Sie noch Fragen zur Methode CONSENS und wie iQUAVIS sie umsetzt? Fragen Sie uns gern über die Kommentarfunktion oder melden Sie sich für eine kostenlose Live Demo am Beispiel Ihres Use Cases an! Wir freuen uns auf Ihre Anfrage! Mehr über iQUAVIS erfahren Sie außerdem auf dieser Seite.

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/

Die ISO 26262 

Die ISO 26262 definiert ein Vorgehensmodell zusammen mit geforderten Aktivitäten und Arbeitsprodukten („work products“) sowie anzuwendenden Methoden in Entwicklung und Produktion. Dabei deckt sie unter anderem auch die Konzeptphase oder Produktentwicklung auf Systemlevel ab. 

Damit betrifft die Norm auch Aktivitäten, die in iQUAVIS durchgeführt werden. iQUAVIS ist mit den bekannten Sichten und Modellierungsmöglichkeiten bestens geeignet, die geforderten Methoden umzusetzen – das hat nun auch der TÜV Rheinland bestätigt. Mit der Zertifizierung erhalten Nutzer die Sicherheit, dass iQUAVIS die Methoden verlässlich umsetzt und iQUAVIS somit auch für sicherheitsrelevante Risikoanalysen wie der HARA geeignet ist.  

iQUAVIS: Die Zertifizierung 

Die iQUAVIS Version 9, wurde durch den TÜV Rheinland für ISO 26262 für die Kapitel 3 -6, 8, 11 und 12 zertifiziert. Für die Umsetzung stellen wir in iQUAVIS geeignete Vorlagen zur Verfügung – sprechen Sie uns gern darauf an! 

Den Wortlaut des Zertifikats haben wir hier übersetzt: 

iQUAVIS ist ein Softwaretool, das die Anforderungen des Tool Confidence Level (TCL) 1 für ASIL D gemäß ISO 26262-8 erfüllt. iQUAVIS unterstützt während des gesamten Entwicklungsprozesses eine Vielzahl von Aufgaben, darunter Systemdesign, Projektmanagement, Risikomanagement und Änderungsmanagement. Dazu gehören Aktivitäten wie Konzeptdesign, Systemdesign, Hardwareentwicklung und Softwareentwicklung für Automobilprodukte und -komponenten. iQUAVIS erleichtert die Erstellung der in ISO 26262 Teile 3 – 6, 8, 11 und 12 geforderten Arbeitsprodukte. 

Das Zertifikat mit dem Originaltext auf Englisch steht hier zur Einsicht bereit.

Arbeiten mit iQUAVIS und der ISO 26262 

Wir wollen Ihnen die Arbeit möglichst erleichtern und stellen für Ihren Prüfprozess geeignete Vorlagen zur Verfügung.  

iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über 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/

Über iQUAVIS

iQUAVIS wurde vom japanischen Unternehmen DENTSU SOKEN Inc. gemeinsam mit produzierenden Unternehmen wie Toyota entwickelt. In Zusammenarbeit mit dem Fraunhofer IEM und Two Pillars wurde es zu einem SysML-freien Modellierer weiterentwickelt, der sich perfekt an jede MBSE-Methode, z. B. die CONSENS-Methode, anpasst. iQUAVIS steht für „Quality Visualisation“ und verdeutlicht den Ursprung: Quality Engineering.

Wie funktioniert Produktentwicklung mit iQUAVIS? 

Mit dem Systemmodell in iQUAVIS decken wir drei Hauptaspekte eines Systems ab: die Struktur, das Verhalten und die Anforderungen. 

Die strukturelle Betrachtung beginnt typischerweise mit einer Umgebungsbetrachtung. Das zu entwickelnde Produkt ist eine Blackbox, und die Elemente der Umgebung, bzw. des Kontexts, werden identifiziert. Die Beziehungen zwischen dem System und seiner Umgebung werden durch Funktionslinien und entsprechende Ports dargestellt. Bei der Betrachtung des Produkts transformieren wir die Blackbox in eine Whitebox und betrachten die inneren Bestandteile, bzw. Module des Systems.  

Die Wirkstruktur beschreibt, wie die verschiedenen Systemteile zusammenarbeiten und wie die zuvor identifizierten Schnittstellen bzw. Ports genutzt werden. Solche Blockdiagramme decken Aspekte aller Disziplinen ab und bilden so die Grundlage für ein einheitliches Systemverständnis aller Beteiligten. Systemelemente können übrigens auch klassifiziert werden, um bspw. Sensoren von Aktoren zu unterscheiden. 

Mit der Verhaltensansicht betrachten wir die Funktionalität des Systems. Der Einstieg in das Verhalten wird häufig über Use-Cases gemacht, die das Systemverhalten auf übergeordneter Ebene beschreiben. Das Systemverhalten kann dann weiter detailliert werden. Mit dem Zustandsdiagramm beschreiben wir die Betriebszustände des Systems, z.B.: Ein Ereignis löst den Übergang von einem Zustand in einen anderen aus. Ein Zustand kann sich dann auf ein funktionales Verhalten beziehen, das in diesem Zustand ausgeführt wird. Dieses Verhalten lässt sich im Funktionsblockdiagramm nach den Regeln eines Aktivitätsdiagramms beschreiben. Dabei werden Funktionen ein einen Ablauf gebracht. Es gibt auch die Möglichkeit, technische Abhängigkeiten zwischen Funktionen zu beschreiben. Noch detaillierter wird es dann mit dem Sequenzdiagramm, mit dem konkrete Kommunikation zwischen Systemelementen beschrieben werden kann. 

Anforderungen und Anforderungsmanagement

Anforderungen können aus etablierten Anforderungsmanagement-Tools synchronisiert, aber auch basierend auf der zuvor beschriebenen Analyse abgeleitet oder verfeinert werden. 

iQUAVIS bietet beispielsweise Baumansichten zur Übersicht über die Anforderungen. Darüber hinaus ermöglicht eine solche Ansicht die Verknüpfung der Anforderungen mit den zuvor genannten Funktionen und Lösungselementen. Das Ergebnis ist ein Traceability-Baum, der die Anforderungen, die funktionale und die logische Ansicht abdeckt. 

Projektmanagement

Das Projektmanagement in iQUAVIS bietet verschiedene Möglichkeiten zur Steuerung des Entwicklungsprojekts. Aufgaben werden in einem Zeitplandiagramm organisiert, wie unten dargestellt. Darüber hinaus ermöglicht iQUAVIS beispielsweise die Verwaltung von Ressourcen und kann mehrere Projekte in einem Plan abwickeln. 

Kurz gesagt: iQUAVIS bietet Ihnen … 

• Ein gemeinsames Verständnis Ihrer Projekte 

• Einen einfachen und nachhaltigen Einstieg in MBSE ohne SysML und komplizierte Anwendungen 

• Eine durchgängige Traceability von Anforderungen, Funktionen, Systemelementen und Testfällen (RFLP) 

• Eine frühzeitige Erkennung potenzieller Risiken 

• Eine Parallelisierung der Entwicklungsaktivitäten 

• Projektstruktur und Projektplanung, inkl. einfacher Anpassung

Kontakt und weitere Informationen

Für Fragen stehen wir Ihnen gern zur Verfügung. Schauen Sie sich auch gern unsere Webinare und Tutorials auf YouTube an, stöbern Sie hier auf unserer Seite oder richten Sie Ihre Mitteilung direkt an uns. Wir sind übrigens nicht nur Tool-Vendoren, sondern beraten auch zum Thema Systems Engineering und MBSE.

Mehr über iQUAVIS

Lernen Sie iQUAVIS kennen:

• 
  iQUAVIS v10 – Update 2026
  von Christian Dr. Bremer
  Aus Japan hat uns die iQUAVIS v10 erreicht, an der wir noch einige Anpassungen für den europäischen Markt vorgenommen haben, damit iQUAVIS bei all unseren Kunden reibungslos läuft. Die wichtigsten Neuerungen der v10, die demnächst
• 
  Product Line Engineering mit iQUAVIS
  von Christian Dr. Bremer
  Im Product Line Engineering (PLE) entstehen Produktlinien systematisch aus einer gemeinsamen Basis. Dahinter steckt ein hochkomplexes Engineering, das wir in diesem Beitrag in der Theorie erläutern. In einem weiteren Beitrag werden wir die praktische Umsetzung
• 
  Die Methode CONSENS in iQUAVIS
  von Christian Dr. Bremer
  In diesem Beitrag stellen wir die Umsetzung der Methode CONSENS in iQUAVIS vor. iQUAVIS lässt sich für die Umsetzung der CONSENS Methode speziell vorbereiten. Wir liefern das entsprechende Profil standardmäßig an unsere Kunden aus, die

iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über 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/

Unsere Kunden arbeiten mit unterschiedlichen Requirements-Management-Tools, an die iQUAVIS dann von uns angeschlossen wird. Wir wollen im Folgenden einen Blick auf diese Schnittstellen zu Requirements-Management-Software werfen.

Requirements-Management-Tools: Datenaustausch mit ReqIF

Prinzipiell ist ein Datenaustausch mit RM-Tools nichts Neues. Alt bewährt ist der Datenaustausch über ReqIF. iQUAVIS ermöglicht den Im- und Export von ReqIF Dateien und ist dabei auch roundtripfähig. Das bedeutet, dass die IDs von Anforderungen bei Änderungen beibehalten werden, sodass Änderungen an Anforderungen nachgezogen werden können.

Das ReqIF-Format ist etabliert, aber es gibt Nachteile: Der dateibasierte Ansatz birgt die Gefahr, dass man mit veralteten Daten arbeitet und auf diese Weise viel Zeit und Nerven investieren muss, um auf einem aktuellen Stand zu bleiben.

Mit ReqIF werden einzelne Dateien ausgetauscht, die womöglich schon kurz nach dem Export nicht mehr aktuell sind. Das wird besonders bei großen Projekten mit vielen Projektteilnehmern zum Killer und führt zu Ärger, Überstunden und Verzögerungen.

Datenbankbasierter Austausch auf Basis von Web-Schnittstellen

Aufgrund der genannten Erfahrungen und weil uns das Streben nach Optimierung in der DNA liegt, bieten wir unseren Kunden für iQUAVIS schon seit langem webbasierte Schnittstellen an – zugeschnitten auf die kundenspezifischen Bedürfnisse.

Was wir immer wieder zu Ohren bekommen, ist die Annahme, mit dem Einstieg ins Systems Engineering und in iQUAVIS müsse man das gesamte Unternehmen umkrempeln und die Organisation auf den Kopf stellen. Das stimmt so nicht (ganz): Wir passen iQUAVIS an Kundenbedürfnisse an.

Das begann ursprünglich als individuelle Lösung. Inzwischen sind daraus eigene Schnittstellen entstanden, die wir als zusätzliche Feature anbieten. Wir werden diese Plugins demnächst hier auf dem Blog einzeln vorstellen.

Über Webschnittstellen wie bspw. die REST API realisieren wir einen datenbankbasierten Austausch, der das Arbeiten mit stets aktuellen Daten ermöglicht – auch bei großen Projekten und auch bei großen Teams.

Wir bieten mittlerweile Schnittstellen zu verschiedenen Tools an, etwa zu Jira oder zu Codebeamer an. Mit den Schnittstellen verknüpfen Sie die entsprechenden Umgebungen kinderleicht: Sie werden per URL angesteuert. In der Schnittstellenkonfiguration erfolgt dann das Mapping zwischen Anforderungsklasse und iQUAVIS-Klasse. Die Datenintegration läuft dann auf Knopfdruck.

Dieser datenbankbasiere Ansatz bietet nicht nur den Vorteil, dass Daten schnell aktuell gehalten werden können, es werden auch Konzepte für Rechte/Rollen leicht durchsetzbar, da wir mit den bestehenden Berechtigungen auf dem Requirements-Tool arbeiten.

Immer ein offenes Ohr für unsere Kunden

Durch die enge Zusammenarbeit mit den Kunden sind wir von Two Pillars sehr nah an der Praxis: Wir verkaufen Ihnen nicht einfach die Software und wünschen viel Spaß beim Ausprobieren, sondern wir begleiten unsere Kunden in ihrem Prozess zum Model-Based Systems Engineering und passen iQUAVIS immer detaillierter an Ihre Anforderungen an.

Uns macht es jedes Mal Spaß, die Fortschritte zu sehen und auch selbst dazuzulernen. Nicht umsonst bieten wir regelmäßig Key User Meetings an, bei denen wir Neues vorstellen und den Anwendern auch untereinander die Möglichkeit geben, sich auszutauschen. Denn auch wenn die Branchen und Produkte verschieden sind – die Fragen und Probleme sind oft ähnlich.

Haben Sie Fragen zu unseren Schnittstellen? Schreiben Sie gern einen Kommentar oder wenden Sie sich per Kontaktformular an uns. Weitere Informationen zu unseren Schnittstellen finden Sie hier.

iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über 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/

Browserunterstützung für das Projektmanagement

iQUAVIS ist dient als Tool in erster Linie einem umfassenden Projektmanagement und verbindet unterschiedliche Disziplinen in der Produktentwicklung. Dieser ganzheitliche Ansatz des Systems Engineering ist die große Stärke der Software. In der Version 7.0 haben wir an der Verbesserung des Projektmanagements gearbeitet: Projektpläne und Aufgaben sind nun auch über den Browser verfügbar. Die Voraussetzung dafür ist die Web-API im Lizenzpaket.

Mit der Browserunterstützung kann der User über einen Browser iQUAVIS bedienen, ohne dass die Software auf dem jeweiligen Gerät installiert sein muss! Das erleichtert nicht nur die interdisziplinäre Zusammenarbeit, sondern auch die Installation der Software selbst.

Diese Vorbereitungen für eine Browser-Readiness beschränkt sich zunächst auf das Projektmanagement, bildet aber gleichzeitig die Grundlage, um in Zukunft auch MBSE-Modelle im Browser verfügbar zu machen – weitere Updates zu diesem Thema werden demnächst folgen. Neuigkeiten geben wir über den Newsletter, hier auf dem Blog und über unsere LinkedIn-Seite bekannt.

Arbeitsblätter

Die Browserunterstützung ist die größte Neuerung beim Update auf iQUAVIS 7.0, aber nicht die einzige: Wir haben noch an weiteren kleinen, nützlichen Details gefeilt, die das Arbeiten mit iQUAVIS leichter machen: Innerhalb der Arbeitsblätter ist nun das Editieren innerhalb einer Zeile möglich. Außerdem haben wir die Filter-Funktion in orthogonalen Tabellen verbessert.

Baumdiagramme mit zusätzlichen Bedingungen

Bei den Baumdiagrammen ist nun eine erweiterte Vorwärts- und Rückwärtsexpansion mit zusätzlichen Bedingungen möglich. Die Funktion „Baum-Erweiterung“ wurde um die Möglichkeit ergänzt, mit ausgewählten Bedingungen zu erweitern.

Web-API

Die Web-API wurde in ihrem Funktionsumfang deutlich erweitert. Die Erweiterung dient bereits der Vorbereitung für das browsergestützte Arbeiten, auf dem künftig ein Schwerpunkt liegen wird.

Performanceverbesserung

Beim Laden und Anlegen neuer Projekte ist eine deutliche Performanceverbesserung spürbar: iQUAVIS läuft schneller und effizienter!

iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über 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/

Inhalt

Action Priority Tables

Jetzt auch Action Priority Tables mit iQUAVIS anwenden für Ihre FMEA konform mit VDA/AIAG Standard.

Zur Priorisierung von Risiken wird in der FMEA die Schwere (Severity), Auftretenswahrscheinlichkeit (Occurance) und Entdeckungswahrscheinlichkeit (Detectability) bewertet. Das Produkt dieser drei Werte ergibt in der klassischen Form der FMEA die sogenannte Risikoprioritätszahl. Je höher diese Zahl, desto höher auch die Priorität, die diesem Risiko beigemessen wird. Dieses Vorgehen hat jedoch die Schwachstelle, das z.B. schwerwiegende Risiken eventuell zu gering bewertet werden, sofern die anderen beiden Werte niedrig sind. Dabei wäre bereits das einmalige Auftreten katastrophal.

Im neuen Standard der VDA/AIAG werden anstatt der Risikoprioritätszahl Action Priority Tables genutzt. Hierbei wird mit Wertebereichen für die drei beschriebenen Einflussfaktoren gearbeitet. Auf diese Weise können Risiken realitätsnäher bewertet werden. Die Einordnung des jeweiligen Risikos erfolgt dann in eine der drei Kategorien – gering, mittel oder hoch.

iQUAVIS unterstützt beide Varianten der FMEA,

1. mittels RPZ (Risikoprioritätszahl – englisch: RPN) und
2. mit Action Priority Tables.

Im folgenden Bild ist dargestellt, wie zusätzlich zur herkömmlichen Methode nun auch die Dimension der Action Priority betrachtet und mit in die Bewertung einbezogen wird.

Individualisierte Aufwandsplanung

Aufgabendauer präziser planen!

Ein und dieselbe Aufgabe kann je nach Erfahrung des zugewiesenen Mitarbeiters schneller oder langsamer bearbeitet werden. Wenn man diesen Faktor in der Aufgabenplanung nicht berücksichtigt, führt das zu Fehlplanungen. Mit Hilfe von Faktoren, die den Erfahrungsgrad der Mitarbeiter widerspiegeln, ermöglicht iQUAVIS eine realistische Planung der Aufgaben auch bei Wechsel der Zuständigkeit. Nehmen Sie als Beispiel eine Aufgabe, für die im Schnitt 6 Personentage benötigt werden. Teilt man nun diese Aufgabe gleichmäßig auf drei verschiedene Ressourcen auf, ergibt sich als Basis zur Berechnung der Gesamtdauer dieser Aufgabe folgendes Bild:

Eine Ingenieurin erledigt ihren Teil der Aufgaben in zwei Tagen (Faktor 1) und ein Senior Engineer erledigt seinen Teil der Aufgaben in 1,4 Arbeitstagen (Faktor 0,7). Ein Junior Engineer benötigt dagegen 3 Arbeitstage für seinen Teil (Faktor 1,5).  Insgesamt wird die Aufgabe bei gleichmäßiger Verteilung in 6.5 Tagen erledigt sein. iQUAVIS nutzt diese Faktoren bei der Zuweisung von Aufgaben und ermöglicht so eine deutlich realitätsnähere Planung. Die Faktoren dienen dabei rein der Einstufung des Erfahrungsgrads und nicht als Einzelbewertung der individuellen Mitarbeiter. Mit diesem Feature erweitern sich für den Projektplaner die Möglichkeiten der Aufgabenplanung. Außerdem sind die Erwartungen an die Mitarbeiter transparent und nachvollziehbar.

Automatisiertes Einfärben von Elementen: Neue Möglichkeiten der Visualisierung

Wir arbeiten in iQUAVIS bewusst mit Farben, um Unterschiede zwischen Klassen, Datensätzen u.a. zu visualisieren. Es ist jetzt möglich Modellelemente per Knopfdruck einzufärben. Diese Einfärbung kann auf Basis von Klassen, Datensätzen oder benutzerdefiniert erfolgen. So kann schnell überblickt werden, welche unterschiedliche Klassen oder Datensätze in einem Modell vorhanden sind. In Diagrammen und Bäumen ist es jetzt möglich, zwischen verschiedenen farblichen Darstellungen zu wechseln. Die folgenden Bilder zeigen die Möglichkeit, in Diagrammen zwischen Farben

• der Klassen (links, gelb)
• der Datensätze (mittig, grün)
• im Rahmen einer benutzerdefinierten Visualisierung (rechts, orange) zu wechseln.

Bäume ermöglichen den Wechsel zwischen Klassen- und Datensatz-Darstellung. Aus der Kombination aus Klassen und Datensätzen ergeben sich interessante neue Möglichkeiten zur Darstellung Ihrer Modelle.

Microsoft Outlook und iQUAVIS synchronisiert

Sparen Sie Arbeitsschritte  =  Sparen Sie Zeit!

Aufgaben werden in iQUAVIS bisher im Home-Screen oder im Projekt übersichtlich dargestellt. Mit der neuen iQUAVIS Version können Mitarbeiter bei neuen Aufgaben direkt per E-Mail informiert werden. Der Mitarbeiter kann mit dieser Mail direkt in das iQUAVIS Projekt navigieren oder sogar die Aufgaben unmittelbar in der Mail quittieren. Die Aktualisierung der Aufgaben wird direkt mit dem iQUAVIS Projekt synchronisiert.

Die Notwendigkeit, iQUAVIS zu öffnen und manuell die Information hinzuzufügen, d.h. den Aufgabenstatus auf „erledigt“ zu setzten, entfällt. Dadurch wird die Aufgabenbearbeitung in iQUAVIS noch effektiver in den Arbeitsalltag integriert.

Mit diesem Feature machen Sie einen großen Schritt in Richtung verbesserte Workflows und nahtlose digitale Prozesssteuerung! Insbesondere auch die Kombination mit dem Microsoft Teams-Connector „2Psync“ bietet dann eine ganzheitliche Kommunikationslösung zwischen Technik und Projekt.

Single Sign-on (SSO) mit Microsoft Azure

Machen Sie sich das Arbeitsleben einfacher, indem Sie die Single Sign-on (SSO) Methode mit Microsoft Azure nutzen.

Ohne SSO müssen Sie sich bei jedem Start von iQUAVIS mit Ihrem Benutzernamen und einem (hoffentlich anspruchsvollem) Kennwort einloggen.
Mit SSO, können Sie sich diesen Schritt in Zukunft sparen: Nachdem Sie sich wie gewohnt beim Start Ihres Computers in ihr Windows-Konto eingeloggt haben, brauchen Sie iQUAVIS nur noch zu starten und können direkt loslegen, ohne zusätzliche Passworteingabe. Die Authentifizierung wird im Hintergrund über Microsoft Azure abgewickelt. Das ist nicht nur bequemer sondern auch sicherer. Denn so entfällt das „Passwort-Wirrwarr“ und Logins können zentral verwaltet werden.

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/

Datenaustauschformate

Mit der Version 4.0 wurden die Möglichkeiten zur Werkzeugkopplung gestärkt. Das geht nun sowohl über unsere REST API als auch über das Konzept der OSLC (Open Services for Lifecycle Collaboration).

OSLC (Open Services for Lifecycle Collaboration)

Es erfordert großen Aufwand, Daten, die redundant in mehren Dateien projektübergreifend verwendet werden, durch Kopieren und Einfügen zu synchronisieren. Ein solcher manueller Schritt kann leicht Fehler zur Folge haben und Daten verfälschen. Aus diesen Grund hat sich das modellbasierte Systems Engineering entwickelt, kurz MBSE. iQUAVIS hat auf Basis des OSLC Konzeptes nun die Möglichkeiten geschaffen, sich mit anderen Werkzeugen automatisch zu verbinden.

REST API

Die REST API wurde gestärkt. Neben generellen Verbesserungen ist auch die Anbindung von Werkzeugen des Requirement Managements im Fokus gewesen, s.d. nun beispielsweise die Round Trip-Fähigkeit über ReqIF Datenaustausch stark profitiert: Der Anwender kann vorhandene Daten aktualisieren oder löschen, wenn er Daten zwischen DOORS und iQUAVIS importiert oder exportiert. Bei diesem Vorgang können Benutzer wahlweise den Befehl „gekennzeichnete DOORS Daten löschen“ ausführen oder weglassen.

Transparenz bei der Zusammenarbeit

Wenn Sie im Team an einem gemeinsamen Datensatz arbeiten, ist es wichtig zu erfahren, was in Ihrer Abwesenheit passiert ist. Veränderte Daten können von iQUAVIS im Worksheet nun automatisch farblich hervorgehoben und mit Zeitstempel gekennzeichnet werden. So ersparen Sie sich zeitaufwändige Kontrollen. Außerdem besteht die Möglichkeit, alle Änderungen ab einem beliebigen Datum anzeigen zu lassen. Dazu müssen keine zusätzlichen Verlaufsdaten gespeichert werden.

Neue Abhängigkeitstypen und Visualisierung

Ein neuer Abhängigkeitstyp „Abhängigkeit (Beziehung)“ ergänzt die bestehende „Abhängigkeit (Hierarchie)“. Durch zwei unterschiedliche Arten von Abhängigkeiten erweitern sich Ihre Möglichkeiten zur Modellierung und Analyse von Modellen (z. B. Kostenanalyse, Marktauswirkungen, etc.). Die Abhängigkeitstypen können als Bedingungen zum Extrahieren von Informationen genutzt werden, z. B. in Filtern und Arbeitsblättern. Die Funktion „Baum erweitern“ ermöglicht das Verfolgen der „Abhängigkeit (Beziehung)“. Funktionslinien aus den Blockdefinitionsdiagrammen können nun zusätzlich auch im Baum angezeigt werden. Die Darstellung der Abhängigkeitsbeziehungen kann im Menü aktiviert werden.

Veränderte Daten im Arbeitsblatt markieren

In diesem kurzen Video geben wir einen Einblick in iQUAVIS und wie Sie veränderte Daten im Arbeitsblatt markieren können:

Mehr über unser Systems-Engineering-Tool iQUAVIS erfahren Sie hier.

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/