Anforderungen simulieren - warum und wie?

Veröffentlicht 29.03.2022

Fehler, die sich aus den Anforderungen ergeben, ziehen sich durch den gesamten Lebenszyklus von Produkten. Die Kosten für die Korrektur von Fehlern, die durch fehlerhafte Anforderungen verursacht werden, steigen exponentiell mit dem Fortgang der Entwicklung an. Lesen Sie, warum es wichtig ist, vor jeder Umsetzung sicherzustellen, dass die Anforderungen korrekt und kohärent sind und erfahren Sie, wie sie es ermöglichen.

Redaktionsleitung

Dipl.-Ing. Nicole Meyer

Senior Consulting 3DS-PLM | Redakteurin 3DS-PLM Technisches Magazin

REQUIREMENT-IN-THE-LOOP-ANSATZ

Die Software STIMULUS ermöglicht es, funktionale Anforderungen zu simulieren und unterstützt den Anwender dabei, die Anforderungen auf ihre Inkonsistenz zu überprüfen. Auf diese Weise können fehlerhafte Anforderungen durch einen "Requirement-in-the-Loop"-Ansatz frühzeitig erkannt werden, was Zeit, Aufwand und Kosten für die Korrektur von Fehlern in späteren Phasen des Produktlebenszyklus spart.

ABSCHIED VON DER REINEN MECHANIK – HIN ZUR MECHATRONIK

Die Beherrschung der ständig zunehmenden Produktkomplexität ist heutzutage ein sehr aktuelles Thema. Selbst Produkte, die früher rein mechanisch waren, sind heute Teil eines cyber-physischen Ökosystems geworden. Produkte müssen heute zumindest ein gewisses Maß an Intelligenz aufweisen, damit sie wettbewerbsfähig sind. Intelligente Produkte, die zum cyber-physischen Ökosystem gehören, stützen sich in hohem Maße auf die Mechatronik, in der mechanische, elektrische/elektronische und Software-Systeme integriert sind.

Damit Unternehmen auf dem heutigen innovationsgetriebenen Markt erfolgreich bestehen können, ist es sinnvoll, Model-Based Systems Engineering einzusetzen, um die Zusammenarbeit in einem multidisziplinären Entwicklungsumfeld zu erleichtern.

Abbildung 1: Das V-Modell als modernes Konzept, ermöglicht eine itterative feingranulierte Analyse der System-Beziehungen

ALLES BEGINNT MIT DEN ANFORDERUNGEN

Die Produktentwicklung beginnt mit der Festlegung der Anforderungen an das Produkt, die sich aus den Bedürfnissen der Interessengruppen, auch Stakeholder genannt, ergeben. Mit zunehmender Produktkomplexität steigt auch die Anzahl der Interessengruppen, die von dem Produkt betroffen sind, sowie die Gesamtzahl der Anforderungen und Vorschriften, die das Produkt erfüllen muss.

ANFORDERUNGEN ENTSCHEIDEN ÜBER DEN ERFOLG ODER MISSERFOLG EINES PRODUKTES

Anforderungsspezifikationen enthalten Hunderte oder sogar Tausende von Anforderungen, die Produktkomponenten in unterschiedlichen Detaillierungsgraden beschreiben. Auf der Grundlage der Anforderungen wird die Produktarchitektur gestaltet, die die Grundlage für Designentscheidungen bildet. Auch Testfälle werden aus Anforderungen abgeleitet, so dass die Anforderungen auch in den späteren Phasen des Produktlebenszyklus, nämlich bei der Systemintegration, Verifizierung und Validierung wichtig werden. Wie man sieht, spielen die Anforderungen in allen Phasen des Lebenszyklus eine wichtige Rolle und entscheiden somit über den Erfolg des Endprodukts. Daher ist es von großer Bedeutung, dass die Anforderungen von Beginn an konsistent und vollständig sind.

DIE KOSTEN FÜR KORREKTUREN FEHLERHAFTER ANFORDERUNGEN STEIGEN MIT FORTSCHREITENDER ENTWICKLUNG EXPONENTIELL AN

Während der Produktentwicklung sind Änderungen unvermeidlich. Änderungen auf technischer Ebene, z. B. an Software, Zeichnungen, Design, die bereits freigegeben wurden, sind kostspielig und führen zu Verzögerungen bei nachfolgenden Entwicklungsaktivitäten [1].

Eine der häufigsten Ursachen für späte Änderungen sind mehrdeutig und unklar formulierte Anforderungen [1]. Fehler, die durch unvollständige, falsche oder inkonsistente Anforderungen verursacht werden, ziehen sich durch den gesamten Produktlebenszyklus, da Anforderungen sämtliche Lebenszyklusphasen direkt oder indirekt beeinflussen.

Abbildung 2: Korrektur-Kosten in Abhängigkeit des Stadiums, wann ein Systemfehler identifiziert wird

FUNKTIONALE ANFORDERUNGEN UND DIE SYSTEMARCHITEKTUR

Funktionale Anforderungen sind konkretisierte Anforderungen, die beschreiben, was das Produkt tun soll. Sie beschreiben, wie das System auf bestimmte Zustände und Eingaben reagieren soll und bilden die Grundlage für die Systemarchitektur.

Die Systemarchitektur enthält unter anderem die Systemkomponenten und deren Schnittstellen untereinander. Jeder Austausch von Daten/Energie/Informationen zwischen Systemkomponenten wird in Schnittstellen beschrieben. Diese Informationen werden aus den Anforderungen abgeleitet, wenn keine separate Schnittstellenspezifikation vorhanden ist [2].

ASPICE & ANFORDERUNGEN

Die Konformität mit Normen und Vorschriften dient dem Nachweis der Produktqualität. In der Automobilindustrie zum Beispiel ist die ASPICE-Konformität ein wichtiges Thema für Zulieferer, die Produkte an OEMs liefern. Die Erhebung von Anforderungen, die Erarbeitung der Spezifikationen sowie die Rückverfolgbarkeit zwischen Produktarchitektur und Systemanforderungen sind wichtig, um die ASPICE-Konformität nachweisen zu können. Die Sicherstellung der Konsistenz zwischen den Anforderungen und der Systemarchitektur ist als Ergebnis des Prozesses "SYS.3 System Architectural Design" aufgeführt:

“SYS.3.BP7: ENSURE CONSISTENCY. ENSURE CONSISTENCY BETWEEN SYSTEM REQUIREMENTS AND THE SYSTEM ARCHITECTURAL DESIGN.”

WIE STELLT MAN NUN DIE KONSISTENZ DER VORLIEGENDEN ANFORDERUNGEN SICHER?

In den meisten Fällen werden Anforderungen textbasiert in natürlicher Sprache verfasst. Die Überprüfung von textbasierten Anforderungen auf Kohärenz, Korrektheit und Widerspruchsfreiheit ist für Menschen eine nahezu unlösbare Aufgabe. Vor allem bei sicherheitskritischen Systemen ist eine hohe Qualität der Spezifikationen ein Muss.

Funktionale Anforderungen können dank STIMULUS, das zum Portfolio von Dassault Systèmes gehört, nun simuliert werden, um ihre Kohärenz und Konsistenz zu gewährleisten. STIMULUS verwendet dafür einen "Requirements-in-the-Loop"-Ansatz.

Nehmen wir einen Fall, der auf den ersten Blick "einfach" erscheint: Wir haben Anforderungen, die das automatische Ein- und Ausschalten der Scheinwerfer beschreiben. Die Scheinwerfer sollen sich automatisch eingeschalten, wenn die Umgebungslichtintensität weniger als 60 % beträgt. Wenn das Umgebungslicht mehr als 70 % beträgt, sollen sich die Scheinwerfer ausschalten. Außerdem soll der Schaltvorgang des Scheinwerfers etwas verzögert erfolgen, um häufiges Ein- und Ausschalten zu vermeiden.

Um die Anforderungen simulieren zu können, müssen wir sie vom Computer ausführbar machen. STIMULUS bietet vordefinierte Templates für maschineninterpretierbare Ausdrücke, die der natürlichen Sprache sehr nahe kommen:

Abbildung 3: STIMULUS Templates sind maschineninterpretierbar

Um zu beobachten, wie sich die Anforderungen bei verschiedenen Umgebungslichtintensitäten verhalten, erstellen wir eine Testumgebung, die den Schalter und die Scheinwerfersteuerungskomponenten enthält. Außerdem definieren wir ein Profil für die zeitliche Veränderung der Lichtintensität (linearer Anstieg und Rückgang im Laufe der Zeit). STIMULUS erzeugt das Lichtintensitätsprofil entsprechend den vom Benutzer definierten Bedingungen.

Abbildung 4: Arbeiten in der Test-Umgebung

Abbildung 5: Analyseergebnisse in der Test-Umgebung

Wenn wir eine Simulation durchführen, stellen wir fest, dass die Anforderungen nicht ausreichen, um das Verhalten zu jedem Zeitpunkt eindeutig zu beschreiben. Wenn sich der Schaltzustand des Scheinwerfers ändert, wird Instabilität beobachtet, weil der Zustand während der ersten 2 bzw. 3 Sekunden der Schaltverzögerung durch die Anforderungen nicht eindeutig definiert ist:

STIMULUS informiert den Modellierer auch über den Grund für diese Instabilität. Die Teile der Anforderungen, die in der instabilen Phase nicht zur Anwendung kommen, sind grau hinterlegt:

Abbildung 6: Ausgeschlossene Anforderungen identifizieren

Daher müssen wir das Verhalten des Scheinwerfers im Übergangsbereich der Lichtintensitäten genauer beschreiben. Dafür führen wir zwei zusätzliche Anforderungen ein, die den jeweiligen Ausgangszustand der Scheinwerfer während dieser Übergangsphase berücksichtigen:

Abbildung 7: Ergänzen von ausgeschlossenen Anforderungen

STIMULUS kann verschiedene Testfälle mit unterschiedlichen Lichtintensitätsprofilen erstellen. Unten sehen wir zwei Testläufe, Lauf [0] und Lauf [1], überlagert dargestellt und können das Verhalten des Systems untersuchen. Nun führen unsere Anforderungen jederzeit zu stabilen Schaltvorgängen.

Der in diesem Artikel vorgestellte Fall ist ein kleines Beispiel dafür, wie selbst einfache Anforderungen widersprüchlich formuliert sein können. Mit STIMULUS konnten gleich mehrere Probleme identifiziert werden.

Abbildung 7: Stabile Analyseergebnisse der Test-Umgebung

[1] Langer, S., Wilberg, J., Maier, A., & Lindemann, U. (2012). Änderungsmanagement-Report 2012:
Studienergebnisse zu Ursachen und Auswirkungen, aktuellen Praktiken, Herausforderungen und Strategien in Deutschland. Technische Universität München.

[2] ITK Engineering GmbH. (2021). Requirements in the Loop - Frontloading your verification efforts. [Whitepaper].