WO2023156060A1

WO2023156060A1 - Verfahren zur automatisierten verifizierung von anforderungsspezifikationen eines technischen prozesses

Info

Publication number: WO2023156060A1
Application number: PCT/EP2023/000015
Authority: WO
Inventors: Gerhard Schilling
Original assignee: Gs Licence Pool Ug
Priority date: 2022-02-15
Filing date: 2023-02-15
Publication date: 2023-08-24

Abstract

Ein Verfahren dient zur automatisierten Verifizierung von Anforderungsspezifikationen eines technischen Prozesses. Dieser weist mindestens eine State Machine auf, welche verschiedene States einnehmen kann. In jeder State Machine ist jeweils genau einer der States aktiv, und zwischen verschiedenen Modi werden States in Abhängigkeit von Eingangsparametern umgeschaltet. Der technische Prozess soll in unterschiedlichen Modi und States unterschiedlich ablaufen. Es wird automatisch geprüft, ob für mindestens einen der States mindestens ein Verhalten des Prozesses und/oder eine erwartete Lösung an den Prozess und/oder die Funktions-Entity von welcher jeweils eine Lösung erwartet wird und/oder die Abhängigkeit von den Eingangsparametern definiert ist.

Description

Verfahren zur automatisierten Verifizierung von Anforderungsspezifikationen eines technischen Prozesses

Es ist bekannt , zur Realisierung technischer Prozesse State Machines einzusetzen, die in Abhängigkeit von ihren Eingangsparametern verschiedene Zustände annehmen können. Damit diese State Machine den technischen Prozess exakt und wie beabsichtigt realisiert , müssen ihre Eigenschaften im Rahmen einer Anforderungsspezifikation festgelegt werden . Fehler in einer derartigen Anforderungsspezifikation führen zu Undefinierten Zuständen oder Undefinierten Zustandsveränderungen, was im einfachsten Fall zu einer Abweichung des Verhaltens des technischen Prozesses vom Sollverhalten, im schlimmsten Fall j edoch zum vollständigen Absturz des Systems führt .

Der Erfindung liegt die Aufgabe zugrunde , ein Verfahren zur automatisierten Verifizierung von Anforderungsspezifikationen eines technischen Prozesses zu realisieren, um auf diese Weise die Zuverlässigkeit des technischen Prozesses zu verbessern .

BESTÄTIGUNGSKOPIE Diese Aufgabe wird mit den folgenden Merkmalen gelöst .

Der technische Prozess setzt eine State Machine ein . Der Begriff „State" beschreibt grundsätzlich den Status einer State Machine , die verschiedene States auf eist , zwischen denen sie in Abhängigkeit von Eingangsparametern wechseln kann . Der State ist j edoch nicht auf Interna einer State Machine beschränkt und kann auch System übergreifend genutzt werden . In diesem Sinn wird oftmals die Bezeichnung Mode oder Modus genutzt , im Rahmen dieser Erfindung werden j edoch auch derartige Modi als State angesehen . Bezüglich des technischen Prozesses sind grundsätzlich Hardwareanwendungen zu verstehen, der Erf indungsgegenstand ist j edoch nicht hierauf beschränkt . Die State Machine kann in unterschiedlichen Modi arbeiten, wobei in j edem dieser Modi unterschiedliche Verhalten definiert werden können . So kann beispielsweise auf bestimmte Aktivitäten verzichtet werden, wenn nur noch wenig Energie zur Verfügung steht , was bei batteriebetriebenen technischen Prozessen von erheblicher Bedeutung sein kann . Sowohl der Modus als auch der j eweilige Status definieren den aktuellen Zustand der State Machine und insbesondere , welche Eingangsparameter Modus- bzw . Statuswechsel sowie welche konkreten Ausgangsparameter erzeugt werden sollen. Um die Zuverlässigkeit des Gesamtsystems zu verbessern, wird automatisch geprüft , ob für mindestens einen der States mindestens ein Verhalten des Prozesses bzw . eine erwartete Lösung an den Prozess bzw . die Funkt ions -Entity eine Abhängigkeit von Eingangsparametern definiert ist . Eine fehlende Definition an dieser Stelle kann zu erheblichen Problemen im technischen Prozess führen, wobei j e nach Anwendung auch erhebliche Schäden möglich sind . Es passiert relativ häufig, dass bei der Entwicklung des technischen Prozesses bestimmte Abhängigkeiten von den Eingangsparametern Undefiniert gelassen werden, weil sie für den Entwickler selbstverständlich sind . Im Laufe der Entwicklung kann j edoch diese Selbstverständlichkeit vergessen werden oder aber ein anderes Mitglied des Entwicklungsteams hat eine andere Auffassung von Selbstverständlichkeit , so dass dann der gesamte technische Prozess nicht mehr wie erwartet funktioniert . Wichtig ist in diesem Zusammenhang lediglich die Prüfung, ob eine entsprechende Definition vorliegt . Eine Prüfung dahingehend, ob diese Definition auch zweckmäßig oder sinnvoll sein könnte , kann in der Regel nicht automatisiert stattfinden, da hierzu detailliertes Wissen zum konkreten technischen Prozess erforderlich ist . Erfahrungsgemäß ist es j edoch selten, dass ein Entwickler eine Definition der Anforderungsspezifikationen falsch setzt , da er sich beim Erstellen der Anforderungsspezifikation entsprechende Gedanken zu dem j eweiligen Problem macht . Der häufigste Fehler, der dann auch lange Zeit unbemerkt bleiben kann, ist das einfache Vergessen einer ausreichend eindeutigen Definition . Dies wird durch die automatisierte Überprüfung auf gedeckt , so dass dem Entwickler eine Warnung oder ein Fehler angezeigt wird . Auf diese Weise wird er darauf aufmerksam gemacht , seine State Machine in allen Punkten exakt zu definieren . Dies beugt den oben beschriebenen Problemen vor . Besonders fehlerträchtig sind Schnittstellen zwischen State Machines , welche parallel und damit gleichzeitig oder quasi gleichzeitig ablaufen können . In diesem Fall ist der exakte zeitliche Ablauf zwischen den State Machines unvorhersehbar, was zu erheblichen Problemen führen kann . Insbesondere ist es auf diese Weise durchaus möglich, dass verschiedene State Machines gleichzeitig oder quasi gleichzeitig widersprüchliche Prozessverhalten bewirken . Derartige Widersprüche sind nicht vorhersehbar und auch sehr schwer testbar . Aus diesem Grund ist es wichtig, dass der Entwickler in der Anforderungsspezifikation ein dominantes Prozessverhalten definiert . Dieses gibt lediglich an, welche State Machine im Falle von widersprüchlichem Verhalten Vorrang genießen soll . Da es sich hierbei um ein Ausnahmeverhalten handelt , wird dieses oftmals vergessen . Die Überprüfung des Vorhandenseins einer Definition für das dominante Verhalten verhindert ein Vergessen dieses Spezifikationsschritts , was wiederum die Zuverlässigkeit des technischen Prozesses verbessert .

Insbesondere bei mehr als zwei State Machines ist es erforderlich, Prioritätsketten zu definieren, da j a von vornherein nicht klar ist , welche State Machines ein widersprüchliches Verhalten erzeugen . Es nützt nun nichts , wenn man beispielsweise vorgibt , dass die State Machine A stets dominant sein soll , der Widerspruch aber zwischen den State Machines B und C entsteht . Daher ist es wichtig, dass die Verhaltensanforderungen in allen möglichen Fällen ein eindeutiges dominantes Prozessverhalten definieren . Zur Vermeidung weiterer Fehler ist es vorteilhaft , wenn geprüft wird, ob für mindestens eine Funktion für die zugeordneten Prozesslösungen die Auswirkungen auf eine Ausgangssignalevaluierung bzw . eine Subprozessaktivierung beschrieben sind . Fehler hierbei führen dazu, dass entweder Ausgangssignale Undefiniert bleiben oder nicht klar ist , ob ein Subprozess , der seine eigene State Machine bereitstellt , gestartet werden soll oder nicht . In beiden Fällen ergibt sich eine Undefinierte Reaktion des technischen Prozesses , was unerwünscht ist .

Insbesondere bei mehreren State Machines ist es wichtig zu definieren, ob Verhaltensanforderungen nur vom dominanten Prozess oder auch von nicht dominanten Prozessen benötigt werden . Besteht beispielsweise die Möglichkeit , dass sich ein Widerspruch zwischen verschiedenen Prozessen auf löst , wäre es bedenklich, wenn der nicht dominante Prozess kein definiertes Verhalten hätte , dessen Verhalten aber an anderer Stelle trotzdem relevant wäre . Zur Vermeidung dieser Probleme wird daher geprüft , welches der oben genannten Verhalten gefordert ist .

Zur weiteren Verbesserung des Verhaltens des technischen Prozesses ist es günstig, wenn automatisch geprüft wird, ob bei der Ausgangssignalevaluierung alle Schnittstellen 10s verwendet bzw . alle Konditionen eindeutig beschrieben bzw. alle States erreichbar sind . Anderenfalls läge der Fall vor, dass bestimmte Schnittstellen- 10s , bestimmte Konditionen oder bestimmte States zwar definiert und angelegt , nicht j edoch genutzt werden . Dies ist eine Inkonsistenz , welche aufgelöst werden sollte . In der Regel stellen derartige vagabundierende Schnittstellen- 10s usw . Definitionsfehler dar, die später nur schwer zu entdecken sind .

Zur vereinfachten Verarbeitung der Daten auf einer Datenverarbeitungsanlage ist es günstig, wenn mindestens eine der Verhaltensanforderungen textbasiert ist .

Textuelle Verhaltensanforderungen können im einfachsten Fall automatisch aus einem Text erzeugt werden, der auch editierbar ist . Da derartige Textquellen beliebig formuliert sein können, ist es in diesem Fall zweckmäßig, wenn Regelkonformität überprüft wird .

Zum Vermeiden von Lücken in der Definition der Anforderungsspezifikation ist es vorteilhaft , wenn geprüft wird, ob alle States einer State Machine als Eingangsparameter für andere State Machines verwendet werden und eine separate Betrachtung dieser State Machine dann für die IO-Kombinationen überflüssig wird . Wird ein State einer State Machine nicht als Eingabeparameter genutzt , so ist er eigentlich überflüssig . Damit könnte er weggelassen werden . In der Regel wurde j edoch die Nutzung dieses States als Eingabeparameter vergessen, was auf diese Weise mit einer entsprechenden Warnung oder einem Fehler quittiert wird .

Da Dominanz rege In sehr komplex werden können, ist es zweckmäßig, diese an zentraler Stelle zu definieren und dann an verschiedene State Machines weiterzugeben . Am einfachsten geschieht dies auf dem Wege der Vererbung in einem obj ektorientierten Modell . Auf diese Weise erhält man auf einfachstem Wege und ohne viel Aufwand in sich konsistente Dominanz rege In .

Zur Vereinfachung der Entwicklung der Anforderungsspezif ikation ist es günstig, wenn eine Verknüpfung aus einer Zuordnung von Anforderungen von einem Spezifikationsartefakt erstellt wird . Dieser Spezifikationsartefakt beschreibt dabei eine strukturelle Funkt ions ebene , die auf einem anderen Spezifikationsartefakt beruht , welcher auch eine andere Entity beschreibt . Auf diese Weise können Spezifikationsartefakte , also elementare Komponenten einer Spezifikation genutzt werden, wenn die darin enthaltenen Definitionen auch für die vorliegende Anforderungsspezifikation kompatibel sind . Dies reduziert den Spezif ikations- und Prüfaufwand, weil in der Regel die andere Entity bereits intensiv überprüft wurde .

Der Nachteil der oben beschriebenen Übernahme von Spezifikationsartefakten anderer Entities besteht darin, dass durch diese Übernahme Inkonsistenzen entstehen können . Deshalb ist es zweckmäßig, die übertragene Lösungsanforderung des zweiten Artefakts dahingehend zu überprüfen, ob dieses eindeutig zugeordnet ist bzw . durch konkrete Lösungen umgesetzt oder in Detail - Lösungsanforderungen unterteilt ist . Anderenfalls könnten Widersprüche in der Anforderungsspezifikation entstehen .

Claims

Ansprüche

1 . Verfahren zur automatisierten Verif izierung von Anforderungsspezifikationen eines technischen Prozesses , der mindestens eine State Machine aufweist , welche verschiedene States einnehmen kann, wobei in j eder State Machine j eweils genau einer der States aktiv ist , und zwischen verschiedenen Modi States in Abhängigkeit von Eingangsparametern umgeschaltet werden und der technische Prozess in unterschiedlichen Modi und States unterschiedlich ablaufen soll , dadurch gekennzeichnet, dass automatisch geprüft wird, ob für mindestens einen der States mindestens ein Verhalten des Prozesses und/oder eine erwartete Lösung an den Prozess und/oder die Funkt ions -Entity von welcher j eweils eine Lösung erwartet wird und/oder die Abhängigkeit von den Eingangsparametern definiert ist .

2 . Verfahren nach Anspruch 1 , wobei mehrere State Machines parallel und damit gleichzeitig oder quasi gleichzeitig ablaufen, dadurch gekennzeichnet, dass automatisch geprüft wird, ob in mindestens einer der möglichen Kombinationen des Prozess -Verhaltens der State Machines ein dominantes Prozess-Verhalten definiert ist .

3 . Verfahren nach Anspruch 2 , dadurch gekennzeichnet, dass automatisch geprüft wird, ob für alle Kombinationsmöglichkeiten der parallelen Verhaltensanforderungen j eweils ein eindeutiges dominantes Prozess-Verhalten definiert ist .

4 . Verfahren nach mindestens einem der Ansprüche 1 bis 3 , dadurch gekennzeichnet, dass geprüft wird, ob für mindestens eine Funktion für mindestens eine zugeordnete Prozess -Lösung deren Auswirkungen auf eine Ausgangssignal -Evaluierung und/oder auf eine Subprozess - Aktivierung beschrieben ist .

5 . Verfahren nach mindestens einem der Ansprüche 1 bis 4 , dadurch gekennzeichnet, dass automatisch geprüft wird, ob nur von dominanten Prozess -Verhaltensanforderungen eine Lösung in den Funktionen erwartet wird .

6 . Verfahren nach mindestens einem der Ansprüche 4 oder 5 , dadurch gekennzeichnet, dass automatisch geprüft wird, ob bei einer Ausgangssignal -Evaluierung alle Schnittstellen 10s verwendet und/oder ob alle Konditionen eindeutig beschrieben und/oder ob alle States erreichbar sind .

7 . Verfahren nach mindestens einem der Ansprüche 1 bis 6 , dadurch gekennzeichnet, dass mindestens eine der Verhaltensanforderungen textbasiert ist .

8 . Verfahren nach mindestens einem der Ansprüche 1 bis 7 , dadurch gekennzeichnet, dass die textuellen Verhaltensanforderungen aus einem Text automatisch erzeugt werden und/oder der editierbare Text überprüft wird, ob er regelkonform ist .

9 . Verfahren nach mindestens einem der Ansprüche 1 bis 8 , dadurch gekennzeichnet, dass geprüft wird ob alle States einer State -Machine als Eingangsparameter für andere State-Machines verwendet werden und eine separate Betrachtung dieser State-Machine dann für die 10 Kombinationen überf lüssig wird .

10 . Verfahren nach mindestens einem der Ansprüche 1 bis

9 , dadurch gekennzeichnet, dass Dominanz -Rege In mit obj ekt-orientierten Methoden verwaltet werden und somit eine Vererbung von Dominanz -Regeln ermöglicht wird .

11 . Verfahren nach mindestens einem der Ansprüche 1 bis

10 , dadurch gekennzeichnet, dass eine Verknüpfung aus einer Zuordnung von Anforderungen von einem Spezifikationsartefakt , welcher eine strukturelle Funktionsebene oder Systemeinheit beschreibt auf einem anderen Spezifikationsartefakt beruht , welcher eine andere Entity beschreibt .

12 . Verfahren nach Anspruch 11 , dadurch gekennzeichnet, dass die Prüfung darin besteht , ob die übertragene Lösungsanforderung eines zweiten Artefakts eindeutig zugeordnet ist und/oder im zweiten Artefakt entweder durch konkrete Lösungen umgesetzt oder Lösungsanforderung in weitere Detail -Lösungsanforderungen unterteilt und weiteren Entities zur Lösung zugeordnet sind .