-
Die Erfindung betrifft ein Verfahren zur Computer gestützten Prüfung einer Anforderungsspezifikation eines technischen Prozesses.
-
Aus der
DE 10 2017 004 348 A1 ist ein gattungsgemäßes Verfahren bekannt, welches Klassen nutzt, um mittels Vererbung und anschließender Instanziierung Spezifikationsartefakte abzuleiten. Dieses Verfahren hat sich bewährt und bildet den Ausgangspunkt der vorliegenden Erfindung.
-
Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren der eingangs genannten Art zu schaffen, welches flexibler zu handhaben ist, ohne dass hierdurch Fehler, insbesondere widersprüchliche bzw. fehlende Spezifikationen der Anforderungsspezifikationen entstehen.
-
Diese Aufgabe wird erfindungsgemäß mit den folgenden Merkmalen gelöst.
-
Ein Verfahren zur Computer gestützten Prüfung einer Anforderungsspezifikation eines technischen Prozesses nutzt objektorientierte erste Klassen, die nach Vererbungsregeln in zweite Klassen vererbt werden. Auf diese Weise können vorhandene erste Klassen erweitert, eingeschränkt und/oder spezifiziert werden. Die Klassen definieren dabei jeweils einen bestimmten Aspekt der Anforderungsspezifikation, wobei es wichtig ist, dass diese zueinander widerspruchsfrei und vollständig definiert sind. Anderenfalls bestünde die Gefahr, dass der technische Prozess nicht wie beabsichtigt abläuft und in der Folge auch nicht die gewünschte technische Wirkung aufweist. Dabei werden die für die Anforderungsspezifikation wichtigen Spezifikationsartefakte aus den ersten und zweiten Klassen abgeleitet. Dies kann entweder durch weitere Vererbung oder aber durch Instanziierung der ersten und zweiten Klassen geschehen. Diese Spezifikationsartefakte enthalten Teilaspekte der Anforderungsspezifikation, die aber - je nach Komplexität des technischen Prozesses - in vielfältiger Weise miteinander in Wechselwirkung stehen können. Es hat sich nun herausgestellt, dass ein durchgängiger, objektorientierter Ansatz eine hohe Zuverlässigkeit der gesamten Anforderungsspezifikation in Bezug auf Eindeutigkeit und Vollständigkeit ermöglicht, dies wird jedoch durch eine erhebliche Unflexibilität erkauft. Insbesondere ist es bei einem durchgängig objektorientierten Ansatz nicht einfach möglich, innerhalb der Klassenhierarchie Änderungen vorzunehmen, um eine bereits vorhandene Anforderungsspezifikation für ein neues Projekt oder für die Änderung eines bereits bestehenden Projekts anzupassen. Dies steht insbesondere einer guten Wiederverwertbarkeit bereits erstellter Anwendungsspezifikationen, sowie daraus erstellter Klassen im Rahmen neuer Projekte entgegen. Zur Lösung dieses Problems sind Spezifikationsartefakte, die einen Teilaspekt der Anforderungsspezifikation beschreiben editierbar und in dritte Klassen umwandelbar. Damit kann parallel zum durchgängig objektorientierten Ansatz ein bereits vorhandenes Spezifikationsartefakt genutzt werden, wobei durch die Editierbarkeit auch sichergestellt ist, dass es den Anforderungen des neuen Projekts auch entsprechend anpassbar ist. Damit ist jedoch die Möglichkeit geschaffen, dass diese neue dritte Klasse nicht mit den objektorientierten Regeln der ersten und zweiten Klasse vereinbar ist. Zur Behebung dieses Problems wird geprüft, ob die dritten Klassen diesen Regeln der ersten und zweiten Klassen genügen, wobei sie nur in diesem Fall objektorientiert in gleicher Weise wie die ersten und zweiten Klassen nutzbar sind. Damit erweitern diese dritten Klassen die ersten und zweiten Klassen und können in gleicher Weise wie die ersten und zweiten Klassen genutzt werden. Auf diese Weise ergibt sich ein iterativer Prüfungsprozess, der eine flexible Einbindung von bereits fertig gestellten Spezifikationsartefakten, welche nicht notwendigerweise objektorientiert erstellt sind, in eine objektorientierte Anforderungsspezifikation. Auf diese Weise ist es möglich, einerseits aus den Klassen Spezifikationsartefakte und andererseits in umgekehrter Richtung aus den Spezifikationsartefakten neue Klassen zu bilden. Dies schafft eine erhebliche Flexibilität und eine hohe Wiederverwertbarkeit von bereits erstellten Anforderungsspezifikationen.
-
Die Spezifikationsartefakte werden vorzugsweise mittels Klasseninstanziierung abgeleitet, da auf diese Weise sehr einfach Eigenschaften der Spezifikationsartefakte vor einer Veränderung geschützt werden können.
-
Als Quelle zur Erstellung der Anforderungsspezifikation können Textquellen bzw. modellbasiertes Systems Engineering genutzt werden. Auf diese Weise sind beispielsweise Zustandsdiagramme und Flussdiagramme zur Spezifikation funktioneller Eigenschaften realisierbar.
-
Bei der Überprüfung wird bevorzugt auch geprüft, ob alle Anforderungen exakt einmal definiert sind. Auf diese Weise werden Widersprüche zwischen den Spezifikationen vermieden. Derartige Widersprüche können dazu führen, dass der technische Prozess wegen Unauflösbarkeit des Widerspruchs nicht realisiert werden kann oder aber falsch spezifiziert ist.
-
Da Schnittstellenanforderungen stets von verschiedenen Klassen genutzt werden müssen, ist es vorteilhaft, wenn diese objektorientiert erstellt sind. Auf diese Weise werden Mehrfachdefinitionen und Widersprüche innerhalb der Schnittstellenanforderungen vermieden.
-
Auch funktionelle Anforderungen werden bevorzugt objektorientiert erstellt. Diese funktionellen Anforderungen definieren Struktur und Verhalten des technischen Prozesses. Hierzu zählen beispielsweise die Reaktion auf Ereignisse oder der zeitliche Ablauf des technischen Prozesses.
-
Es hat sich herausgestellt, dass insbesondere die dritten Klassen, welche mit dem erfindungsgemäßen Verfahren aus den Spezifikationsartefakten erstellt sind, aufgrund der Editierbarkeit fehleranfällig sind. Da in diesem Fall eine Editierbarkeit dieser Spezifikationsartefakte zwangsweise erforderlich ist, kommt ein Requirement Engineer oftmals auf die Idee, diese Editierfunktion zu späteren Zeitpunkten wiederholt auszunutzen. Dies ist aber vor allem deshalb gefährlich, weil andere Klassen erstellt sein können, die diese dritte Klasse bereits nutzen, beispielsweise mittels Vererbung. Auf diese Weise entstehen durch die erneute Editierung Widersprüche. Zur Vermeidung dieser Probleme, ist es zweckmäßig, wenn die dritten Klassen teilweise oder vollständig mit Schreib- bzw. Löschschutz ausgerüstet sind. Auf diese Weise werden derartige Probleme unterbunden und Regelverletzungen vermieden.
-
Zusätzlich zu den Regeln der ersten und zweiten Klassen ist es zweckmäßig, die dritten Klassen auch auf Vollständigkeit zu prüfen. Hier wird insbesondere geprüft, ob die Eigenschaften der dritten Klassen eindeutig definiert sind bzw. eindeutig anderen Klassen bzw. Klassengruppen zugeordnet sind. Dies ist wichtig, um eine widerspruchsfreie und vollständige Definition der Eigenschaften der dritten Klassen zu gewährleisten.
-
Insbesondere, wenn klassenübergreifende Systemmodi angesetzt werden, kommt es immer wieder vor, dass das Verhalten des technischen Prozesses in bestimmten Systemmodi oder Kombinationen von Systemmodi nicht definiert ist. Dies ist insbesondere bei den dritten Klassen relevant, da diese aus einem anderen Projekt entnehmbar sind und folglich möglicherweise bestimmte Systemmodi gar nicht berücksichtigen. Zu diesem Zweck werden die dritten Klassen dahingehend überprüft, ob die funktionellen Anforderungen für verschiedene Kombinationen von Systemmodi definiert sind. Auf diese Weise werden derartige Fehler zuverlässig verhindert.
-
Insbesondere, wenn Anforderungen aus verschiedenen Dateiquellen genutzt werden, kommt es immer wieder vor, dass bestimmte Verhaltensanforderungen mehrfach definiert sind. Dies führt zu widersprüchlichem Verhalten des technischen Prozesses und damit zu Problemen im Prozessablauf. In diesen Fällen ist es daher günstig, wenn überprüft wird, dass Verhaltensanforderungen unabhängig von mindestens einem der Eingangsparameter ein einziges definiertes Verhalten bewirken. Auf diese Weise werden Fehler durch mehrfach definierte Verhaltensanforderungen vermieden.
-
Der Erfindungsgegenstand wird beispielhaft anhand der Zeichnung erläutert, ohne den Schutzumfang zu beschränken.
-
Es zeigt:
- 1 ein Beispiel für eine Systemfunktion
- 2 eine Modus-/Zustandstabelle
- 3 eine Kombinationstabelle
- 4 eine ergänzte Zustands-/Modustabelle,
- 5 eine Klasse,
- 6 eine Evaluierungstabelle,
- 7 eine Service Function,
- 8 eine Verhaltensdefinition,
- 9 eine Funktionalmatrix,
- 10 eine Beispielanforderung,
- Figur .11 eine Klasseninstanz und
- 13 eine Datenbanktabelle.
-
Jede einzelne Funktion einer Anforderungsspezifikation für einen technischen Prozess muss das Verhalten in jeder Situation (Umgebungssituation, Fehler, Konfiguration, Speicher über frühere Zustände oder Fehler, States, Modes,....) definieren, welche alle parallel und d.h. auch gleichzeitig auftreten können.
-
Beispielsweise soll eine System Funktion (SF) gemäß 1 verschiedene Zustände (switch_status) an einem Schalter erfassen und das evaluierte Signal (switch_signal) an einen Empfänger weitergeben.
-
Es existieren in diesem System (ECU) dazu mehrere, parallele Situationen (Modes), die in 2 dargestellt sind. Damit ergeben sich viele möglichen Kombinationen aus State und Mode, wobei man für jede einzelne mögliche Kombination den evaluierten Ausgangswert definieren muss, da diese in der Praxis auch auftreten können. Diese Kombinationen sind in 3 dargestellt.
-
Damit ergeben sich - je nach Komplexität des technischen Prozesses - theoretisch mehrere Millionen Kombinationen, welche für jede einzelne Funktion separat definiert werden müssen und vereinfacht in 4 dargestellt sind. Dort sind alle dominanten und nicht-dominanten Verhaltenslösungen aller Modes und States der ECU mittels einer Methode zusammengefasst dargestellt. Diese Funktionen sind in Klassen definiert, von denen eine lediglich beispielhaft in 5 dargestellt ist.
-
Die vorliegende Erfindung liefert Methoden, Automatismen und automatisierte Überprüfungen, mit denen dieser sehr komplexe Vorgang effizient und vollständig gestaltet wird. Zudem ist es oftmals erforderlich, dass aus dieser Tabelle testbare textuelle Anforderungen erstellt werden, d.h. für jede Zeile eine einzelne textuelle Anforderung erstellt werden muss, (z.B. zur Verlinkung zu Testspezifikationen), welche beispielsweise für die erste Zeile lautet:
- Req1: If the measured switch status is SWITCH_OPEN and the Car_Operation_Phase is PARKING and the Battery_State is LOW_VOLTAGE and the ECU_Operation_Mode is Start_up_Mode and the ECU_Life_Cycle_Phase is ECU_Production_Phase, then the switch_signal shall be set to SWITCH_INVALID
-
Beispielsweise im Start_up_Mode:STATE wird eine Verhaltensanforderung SF shall be deactivated gemäß 5 als dominant definiert.
-
Eine weitere Methode prüft dabei automatisch, ob nur ein dominantes Verhalten (hier SF deactivated) definiert ist. Grundsätzlich ist es auch möglich, mehrere Verhaltensgruppen (beispielsweise könnte man zwischen SF und Diagnose-Verhalten unterscheiden) zu bilden, wobei für jede Verhaltensgruppe wieder jeweils nur ein dominantes Verhalten existieren darf.
-
Das mittels einer Methode automatisch definierte Verhalten einer Funktion - bezogen auf den jeweiligen dominanten Eingangsparameter - wird in der folgenden Tabelle rot dargestellt. Alle kursiven Elemente müssen dabei manuell ergänzt werden (x = don't care)
-
Prinzipiell ist diese Methode nicht nur auf Tabellen gemäß 6, sondern auch auf andere MBSE Diagramme zur Erstellung von Verhaltenslösungen (beispielsweise State Machine Diagram, Activity Diagrams..) anwendbar.
-
Für jede Service Function SF gemäß 7 ist es erforderlich, jedes kombinierte (zumindest für jedes nicht dominante) State Verhalten manuell daraufhin zu überprüfen, ob dieses für die SF relevant ist. Dies kann beispielsweise dadurch unterstützt werden, indem eine Methode eine Tabelle erstellt, in welcher alle kombinierten State-Verhalten gelistet sind und dazu eindeutig manuell definiert werden kann, ob diese für die jeweilige SF relevant sind. Eine weitere Methode überprüft beispielsweise dabei, ob die Spalte für die relevanten Funktions-Verhalten vollständig ausgefüllt ist.
-
Für eine vollständige Beschreibung der Evaluierung jedes Ausgangssignals einer SF ist es erforderlich, dass alle Eingangssignale-Zustände in Kombination mit allen relevanten SF Verhalten definiert werden. Dies kann vorteilhafterweise gemäß 8 dadurch geschehen, indem mittels Automatismen (Methoden) folgende Tabellen erzeugt werden, welche dann manuell befüllt werden und somit alle potenziellen Kombinationen einen definierten Ausgangszustand aufweisen.
-
Eine Methode könnte beispielsweise zunächst die dominanten Requirements in folgender Textform erzeugen, welche sich für automatisierte SW-Code Generierung eignen, da logisch eindeutig:
- Req 5: If (Car_Operation_Phases is PARKING) or (ECU_Operation_Modes is Start_up_Mode) or (ECU_Life_Cycle_Phases is ECU_Production_Phase) , then Measure_Switch_Status shall be deactivated and measured_switch_status shall be set to SWITCH_INVALID
-
Da in dieser Form jedoch ODER-Verknüpfungen in den Eingangsparametern existieren, bedeutet dies, dass mehrere Situationen in einer Anforderung zusammengefasst sind und es sich somit um keine testbaren Anforderungen handelt. Eine andere Methode könnte dabei folgende testbaren Anforderungen in Textform erzeugen, welche jeweils nur eine Situation beschreiben und welche sich daher für eine automatisierte Testfall Generierung eignen:
- Req 6: If (Car_Operation_Phases is PARKING), then Measure_Switch_Status shall be deactivated and measured_switch_status shall be set to SWITCH_INVALID
- Req 7: If (ECU_Operation_Modes is Start_up_Mode) then Measure_Switch_Status shall be deactivated and measured_switch_status shall be set to SWITCH_INVALID
- Req 8: If (ECU_Life_Cycle_Phases is ECU_Production_Phase) then Measure_Switch_Status shall be deactivated and measured_switch_status shall be set to SWITCH_INVALID
-
Insbesondere wird zunächst automatisiert eine logische Subdominant Requirement Matrix erzeugt, in welcher die relevanten SF Verhalten (Zwischenwerte) durch die ursprünglichen States-Situationen ohne dominanten Eingangs-Zustände ersetzt sind.
-
Aus der 9 können folgende funktionalen subdominante Anforderungen erzeugt werden, welche mehrere Situationen zusammengefasst definieren:
- Req10: If (Battery_States is NORMAL_VOLTAGE or HIGH_VOLTAGE) and (ECU_Operation_Modes is Operation_Mode) and (switch_signal is SWITCH_OPEN) , then measured_switch_status shall be set to SWITCH_OPEN
- Req 11: If (Battery_States is NORMAL_VOLTAGE or HIGH_VOLTAGE) and (ECU_Operation_Modes is Operation_Mode) and (switch_signal is SWITCH_CLOSED, then measured_switch_status shall be set to SWITCH_CLOSED
- Req 12: If (Battery_States is NORMAL_VOLTAGE or HIGH_VOLTAGE) and (ECU_Operation_Modes is Operation_Mode) and (switch_signal is SWITCH_ERROR), then measured switchstatus shall be set to SWITCH_INVALID
- Req 13: If (ECU_Operation_Modes is Error_Mode), then measured_switch_status shall be set to SWITCH_OPEN
- Req 14: If (Battery_States is LOW_VOLTAGE) and (ECU_Operation_Modes is Operation_Mode), then measured_switch_status shall be set to the previous measured_switch_status.
-
Auch aus dieser 9 lassen sich testbare Anforderungen erzeugen, welche jeweils nur eine Situation beschreiben. Es ist oftmals erforderlich, Verhaltensanforderungen zu vererben (an beispielsweise abgeleitete oder ähnliche Funktionen, an Subfunktionen, an Testspezifikationen,..). Dabei ist ein entscheidender Vorteil, wenn jede einzelne atomare Komponente der Verhaltensanforderung mittels Klassen beschrieben wird, wie im folgenden Beispiel gemäß 10 dargestellt:
-
Für die Subdominanten Verhaltensanforderungen wird eine eigne Database vom Typ Behavior_Requirements angelegt, die alle relevanten SF Verhalten vom Typ BEHAVIOR beinhaltet. Die Klasse BEHAVIOR beinhaltet alle (nummerierten) OUT-Signal Kombinationen vom Typ AND_Conditions, welche alle Eingangs-Konditionen und das zugehörige Resultat beinhaltet.
-
Das vererbte Verhalten und dessen Teil-Konditionen werden dann für jede Funktion gemäß 11 als Instanz der Klasse Behavior-Requirements mittels einer Methode in einer Tabelle dargestellt: Diese Tabelle wird dann nach der Eingabe der Eingangszustände und deren Kombinationen durch eine weitere Methode automatisiert ergänzt. Das Ergebnis ist in der 12 dargestellt.
-
Dabei wird automatisiert überprüft, ob danach das geforderte Verhalten SF activated und die Teilbedingung (ECU_Operation_Modes == Operation_Mode) immer noch enthalten sind.
-
Die Tabelle gemäß 13 ist dabei eine View der Model-Datenbank Measure_Switch_Status:Behavior_Requirements, welche sowohl die vererbten (schwarz) als auch in der Tabelle ergänzte Instanzen und Inhalte aufweist.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- DE 102017004348 A1 [0002]
