WO2023138894A1 - Verfahren zur computer gestützten prüfung einer anforderungsspezifikation eines technischen prozesses - Google Patents

Verfahren zur computer gestützten prüfung einer anforderungsspezifikation eines technischen prozesses Download PDF

Info

Publication number
WO2023138894A1
WO2023138894A1 PCT/EP2023/000004 EP2023000004W WO2023138894A1 WO 2023138894 A1 WO2023138894 A1 WO 2023138894A1 EP 2023000004 W EP2023000004 W EP 2023000004W WO 2023138894 A1 WO2023138894 A1 WO 2023138894A1
Authority
WO
WIPO (PCT)
Prior art keywords
classes
requirements
behavior
rules
checked
Prior art date
Application number
PCT/EP2023/000004
Other languages
English (en)
French (fr)
Inventor
Gerhard Schilling
Original Assignee
Gs Licence Pool Ug
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gs Licence Pool Ug filed Critical Gs Licence Pool Ug
Publication of WO2023138894A1 publication Critical patent/WO2023138894A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/10—Requirements analysis; Specification techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/31—Programming languages or programming paradigms
    • G06F8/315—Object-oriented languages

Definitions

  • the invention relates to a method for computer-assisted testing of a requirement specification for a technical process.
  • the object of the invention is to create a method of the type mentioned at the outset, which can be handled more flexibly without errors, in particular contradictory or missing specifications of the requirement specifications arise.
  • a method for computer-assisted testing of a requirement specification of a technical process uses object-oriented first classes, which are inherited in second classes according to inheritance rules. In this way, existing first classes can be extended, restricted and/or specified.
  • the classes each define a certain aspect of the requirements specification, whereby it is important that these are completely and completely defined without contradictions. Otherwise there is a risk that the technical process will not run as intended and consequently will not have the desired technical effect.
  • the specification artifacts that are important for the requirements specification are derived from the first and second classes. This can be done either through further inheritance or through instantiation of the first and second classes. These specification artifacts contain partial aspects of the requirements specification, which - depending on the complexity of the technical process - can interact with one another in a variety of ways.
  • the specification artifacts are preferably derived by means of class instantiation, since in this way properties of the specification artifacts can be protected from being changed in a very simple manner.
  • Text sources or model-based systems engineering can be used. In this way, for example, state diagrams and flow charts for the specification of functional properties can be implemented.
  • interface requirements must always be used by different classes, it is advantageous if these are created in an object-oriented manner. In this way, multiple definitions and contradictions within the interface requirements are avoided.
  • Functional requirements are also preferably created in an object-oriented manner. These functional requirements define the structure and behavior of the technical process. This includes, for example, the reaction to events or the timing of the technical process.
  • the third classes in particular which are created from the specification artifacts using the method according to the invention, are error-prone due to their editability. Since in this case it is absolutely necessary for these specification artifacts to be editable, a requirements engineer often comes up with the idea of using this editing function repeatedly at a later point in time. However, this is particularly dangerous because other classes can be created that already use this third class, for example by means of inheritance. In this way, contradictions arise as a result of renewed editing. To avoid these problems, it is useful if the third classes are partially or fully equipped with write or delete protection. In this way, such problems are prevented and rule violations avoided.
  • Lib_Req2 If it is the "laboratory power supply” type, then it should contain an adjustable current limitation.
  • Lib_Req3 If it is the “medical power supply” type, then an isolating transformer should be implemented
  • SYS_PROP type [laboratory power supply ,
  • a toroidal transformer is to be installed in the power supply unit.
  • An isolating transformer is to be implemented in the power supply unit.
  • FIG. 1 shows an example of a system function
  • Figure 2 is a mode/state table
  • Figure 3 is a combination table
  • FIG. 4 is an expanded status/mode table
  • figure 5 a class
  • Figure 11 a class instance
  • FIG. 13 a database table.
  • a system function (SF) should detect different states (switch_status) on a switch and forward the evaluated signal (switch_signal) to a receiver.
  • the present invention provides methods, automatisms and automated checks with which this very complex process is designed efficiently and completely.
  • SF deactivated SF deactivated
  • Another method automatically checks whether only one dominant behavior (here SF deactivated) is defined.
  • SF deactivated SF deactivated
  • this method can be used not only on tables according to FIG. 6, but also on other MBSE diagrams for creating behavioral solutions (for example state machine diagrams, activity diagrams . . . ).
  • each service function SF it is necessary to manually check each combined (at least for each non-dominant) state behavior to determine whether this is relevant for the SF.
  • This can be supported, for example, by a method creating a table in which all combined state behaviors are listed and it can be clearly manually defined whether these are relevant for the respective SF. Another method checks, for example, whether the column for the relevant function behavior is completely filled out.
  • automatisms methods to generate the following tables, which are then filled in manually and thus all potential combinations have a defined initial state.
  • a method could, for example, first generate the dominant requirements in the following text form, which are suitable for automated SW code generation because they are logically clear:
  • Measure_Switch_Status shall be deactivated and measured_switch_status shall be set to SWITCH_INVALID
  • a logical subdominant requirement matrix is first automatically generated, in which the relevant SF behavior (intermediate values) are replaced by the original states situations without dominant input states.
  • measured_switch_status shall be set to SWITCH_OPEN Req 11 : If (Battery_States is NORMAL_VOLTAGE or
  • measured_switch_status shall be set to the previous measured_switch_status .
  • Testable requirements can also be generated from this FIG. 9, each of which only describes one situation. It is often necessary to inherit behavioral requirements (to, for example, derived or similar functions, to subfunctions, to test specifications, . . ). There is a decisive advantage here if each individual atomic component of the behavioral requirement is described using classes, as shown in the following example according to FIG. 10:
  • a separate database of the Behavior_Requirements type is created for the subdominant behavioral requirements, which contains all relevant SF behaviors of the BEHAVIOR type.
  • the class BEHAVIOR contains all (numbered) OUT signal combinations of the type AND_Conditions, which contains all input conditions and the associated result.
  • the inherited behavior and its partial conditions are then represented for each function according to FIG. 11 as an instance of the Behavior Requirements class by means of a method in a table: This table is then the entry of the input states and their combinations are automatically supplemented by another method. The result is shown in FIG.
  • the table according to FIG. 13 is a view of the model database Measure_Switch_Status: Behavior_Requirements, which has both the inherited (black) and the instances and contents added to the table.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Stored Programmes (AREA)

Abstract

Ein Verfahren zur Computer gestützten Prüfung einer Anforderungsspezifikation eines technischen Prozesses erfolgt objektorientiert. Dabei werden aus ersten Klassen nach Vererbungsregeln zweite Klassen erstellt. Die ersten und zweiten Klassen enthalten Regeln und aus diesen werden Spezifikationsartefakte abgeleitet. Diese beschreiben jeweils Teilaspekte der Anforderungsspezifikation. Die Spezifikationsartefakte mindestens einer der Klassen sind editierbar und in dritte Klassen umwandelbar. Die zweiten und/oder dritten Klassen werden dahingehend überprüft, ob sie den Regeln der ersten und zweiten Klassen genügen. Anschließend sind die dritten Klassen wie die ersten und zweiten Klassen nutzbar, so dass das Verfahren zur Prüfung iterativ auf Grundlage der dritten Klassen ablaufen kann.

Description

Verfahren zur Computer gestützten Prüfung einer Anforderungsspezifikation eines technischen Prozesses
Die Erfindung betrifft ein Verfahren zur Computer gestützten Prüfung einer Anforderungsspezifikation eines technischen Prozesses .
Aus der DE 10 2017 004 348 Al 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 f lexibler zu handhaben ist , ohne dass hierdurch Fehler, insbesondere widersprüchliche bzw . fehlende Spezifikationen der Anforderungsspezif ikationen entstehen .
BESTÄTIGUNGSKOPIE Diese Aufgabe wird erfindungsgemäß mit den folgenden Merkmalen gelöst .
Ein Verfahren zur Computer gestützten Prüfung einer Anforderungsspezifikation eines technischen Prozesses nutzt obj ektorientierte 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 j eweils 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 - j e 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, obj ektorientierter Ansatz eine hohe Zuverlässigkeit der gesamten Anforderungsspezifikation in Bezug auf Eindeutigkeit und Vollständigkeit ermöglicht , dies wird j edoch durch eine erhebliche Unflexibilität erkauft . Insbesondere ist es bei einem durchgängig obj ektorientierten Ansatz nicht einfach möglich, innerhalb der Klassenhierarchie Änderungen vorzunehmen, um eine bereits vorhandene Anforderungsspezifikation für ein neues Proj ekt oder für die Änderung eines bereits bestehenden Proj ekts anzupassen . Dies steht insbesondere einer guten Wiederverwertbarkeit bereits erstellter Anwendungsspezifikationen, sowie daraus erstellter Klassen im Rahmen neuer Proj ekte 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 obj ektorientierten Ansatz ein bereits vorhandenes Spezifikationsartefakt genutzt werden, wobei durch die Editierbarkeit auch sichergestellt ist , dass es den Anforderungen des neuen Proj ekts auch entsprechend anpassbar ist . Damit ist j edoch die Möglichkeit geschaffen, dass diese neue dritte Klasse nicht mit den obj ektorientierten 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 obj ektorientiert 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 obj ektorientiert erstellt sind, in eine obj ektorientierte 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 obj ektorientiert erstellt sind . Auf diese Weise werden Mehrfachdefinitionen und Widersprüche innerhalb der Schnittstellenanforderungen vermieden . Auch funktionelle Anforderungen werden bevorzugt obj ektorientiert 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 Proj ekt 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 def iniertes Verhalten bewirken. Auf diese Weise werden Fehler durch mehrfach definierte Verhaltensanforderungen vermieden .
Zur weiteren Verbesserung der Konsistenz der Anforderungen ist es vorteilhaft , wenn geprüft wird, ob an eine Instanz lediglich diej enigen Systemeigenschafts- abhängigen Anforderungen vererbt werden, welche in den Anforderungen für das System definiert sind . Beispielsweise sind in einer Anforderungs- Library für Netzteile folgende systemeigenschaftsabhängige
Anforderungen hinterlegt : Lib_Reql : Wenn im Applikations-Gehäuse „Raumnot" herrscht , dann soll ein Ringkern- Transformator verbaut werden .
Lib_Req2 : Wenn es sich um die Bauart „Labor-Net zgerät" handelt , dann soll es eine einstellbare Strombegrenzung beinhalten . Lib_Req3 : Wenn es sich um die Bauart „Medizinisches - Netzgerät" handelt , dann soll ein Trenntransformator realisiert werden
Diese Anforderungen können in einer generischen Library- Klasse für Netzteile standardisiert beschrieben werden:
Klasse Netzteil [
SYS_PROP Platzangebot =
[Raumnot , keine Raumnot]
FUNC REQ IF Platzangebot == Raumnot , THEN „Im Netzgerät soll ein Ringkern-Transformator verbaut werden . "
SYS_PROP Bauart = [Labor-Netzgerät ,
Medizinisches -Netzgerät] FUNC REQ IF Bauart == Labor-Netzgerät , THEN „Das Netzgerät soll eine einstellbare Strombegrenzung beinhalten . "
FUNC REQ IF Bauart == Medizinisches-Netzgerät , THEN „Im Netzgerät soll ein Trenntransformator realisiert werden . "
In der textuellen Spezifikation kann dann eine Instanz dieser Klasse (bspw. für ein Krankenhaus) verwendet werden, in welcher zunächst automatisch die erforderlichen System- Entscheidungen vererbt werden :
Netzteilanforderungen : = Krankenhaus : Netzteil
Platzangebot = [Raumnot , keine Raumnot]
Bauart = [Labor-Netzgerät , Medizinisches-Netzgerät]
Werden dann die System-Entscheidungen getroffen, da werden automatisch die entsprechenden systemeigenschaf ts- abhängige Anforderungen vererbt :
Netzteilanforderungen : = Krankenhaus : Netzteil
Platzangebot = Raumnot ->
Im Netzgerät soll ein Ringkern-Transformator verbaut werden .
Bauart = Medizinisches-Netzgerät ->
Im Netzgerät soll ein Trenntransformator realisiert werden .
Der Erfindungsgegenstand wird beispielhaft anhand der Zeichnung erläutert , ohne den Schutzumfang zu beschränken .
Es zeigt :
Figur 1 ein Beispiel für eine Systemfunktion
Figur 2 eine Modus - /Zustandstabei le Figur 3 eine Kombinationstabelle
Figur 4 eine ergänzte Zustands- /Modus tabel le ,
Figur 5 eine Klasse ,
Figur 6 eine Evaluierungstabelle ,
Figur 7 eine Service Function,
Figur 8 eine Verhaltensdefinition,
Figur 9 eine Funktionalmatrix,
Figur 10 eine Beispielanforderung,
Figur 11 eine Klasseninstanz und
Figur 13 eine Datenbanktabelle .
Jede einzelne Funktion einer Anforderungsspezifikation für einen technischen Prozess muss das Verhalten in j eder Situation (Umgebungssituation, Fehler, Konfiguration, Speicher über frühere Zustände oder Fehler, States , Modes , .... ) definieren, welche alle parallel und d . h. auch gleichzeitig auf treten können .
Beispielsweise soll eine System Funktion (SF) gemäß Figur 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 Figur 2 dargestellt sind . Damit ergeben sich viele möglichen Kombinationen aus State und Mode , wobei man für j ede einzelne mögliche Kombination den evaluierten Ausgangswert definieren muss , da diese in der Praxis auch auf treten können . Diese Kombinationen sind in Figur 3 dargestellt . Damit ergeben sich - j e nach Komplexität des technischen Prozesses - theoretisch mehrere Millionen Kombinationen, welche für j ede einzelne Funktion separat definiert werden müssen und vereinfacht in Figur 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 def iniert , von denen eine lediglich beispielhaft in Figur 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 j ede Zeile eine einzelne textuelle Anforderung erstellt werden muss , ( z . B . zur Verlinkung zu Testspezifikationen) , welche beispielsweise für die erste Zeile lautet :
Reql : 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_ Lif e_ 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äß Figur
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 j ede Verhaltensgruppe wieder j eweils nur ein dominantes Verhalten existieren darf .
Das mittels einer Methode automatisch definierte Verhalten einer Funktion - bezogen auf den j eweiligen 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äß Figur 6 , sondern auch auf andere MBSE Diagramme zur Erstellung von Verhaltenslösungen (beispielsweise State Machine Diagram, Activity Diagrams . . ) anwendbar .
Für j ede Service Function SF gemäß Figur 7 ist es erforderlich, j edes kombinierte ( zumindest für j edes 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 j eweilige 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 j edes Ausgangssignals einer SF ist es erforderlich, dass alle Eingangssignale-Zustände in Kombination mit allen relevanten SF Verhalten definiert werden . Dies kann vorteilhafterweise gemäß Figur 8 dadurch geschehen, indem mittels Automatismen (Methoden) folgende Tabellen erzeugt werden, welche dann manuell befüllt werden und somit alle potenziellen Kombinationen einen definierten Ausgangs zustand auf weisen.
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_Lif e_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 j edoch 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 j eweils 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 Figur 9 können folgende funktionalen subdominante Anforderungen erzeugt werden, welche mehrere Situationen zusammengefasst definieren :
ReqlO : 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_switch_status 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 Figur 9 lassen sich testbare Anforderungen erzeugen, welche j eweils nur eine Situation beschreiben . Es ist oftmals erforderlich, Verhaltensanforderungen zu vererben (an beispielsweise abgeleitete oder ähnliche Funktionen, an Subfunktionen, an Testspezif ikationen, . . ) . Dabei ist ein entscheidender Vorteil , wenn j ede einzelne atomare Komponente der Verhaltensanf or derung mittels Klassen beschrieben wird, wie im folgenden Beispiel gemäß Figur 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 j ede Funktion gemäß Figur 11 als Instanz der Klasse Behavior-Requirements mittels einer Methode in einer Tabelle dargestellt : Diese Tabelle wird dann nach der Eingabe der Eingangs zustände und deren Kombinationen durch eine weitere Methode automatisiert ergänzt . Das Ergebnis ist in der Figur 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äß Figur 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 .

Claims

Ansprüche Verfahren zur Computer gestützten Prüfung einer
Anforderungsspezifikation eines technischen Prozesses , wobei die Anforderungsspezif ikation obj ektorientiert aus ersten Klassen und nach Vererbungsregeln vererbten zweiten Klassen erstellt wird, wobei die ersten und zweiten Klassen Regeln enthalten und aus diesen ersten und zweiten Klassen Spezifikationsartefakte abgeleitet werden, welche j eweils Teilaspekte der Anforderungsspezifikation beschreiben, dadurch gekennzeichnet , dass die Spezifikationsartefakte mindestens einer der Klassen editierbar sind und in dritte Klassen umgewandelt werden, wobei die zweiten und/oder dritten Klassen dahingehend überprüft werden, ob sie den Regeln der ersten und zweiten Klassen genügen, um anschließend wie die ersten und zweiten Klassen nutzbar zu sein, so dass das Verfahren zur Prüfung iterativ auf Grundlage der dritten Klassen ablaufen kann . Verfahren nach Anspruch 1 , dadurch gekennzeichnet , dass die Spezif ikationsartefakte mittels Klasseninstanziierung abgeleitet werden . Verfahren nach Anspruch 1 oder 2 , dadurch gekennzeichnet , dass die Anforderungsspezifikation die Klassen, Textquellen und/oder Modell basiertes Systems Engineering nutzt . Verfahren nach mindestens einem der Ansprüche 1 bis
3 , dadurch gekennzeichnet , dass die Anforderungsspezifikation dahingehend überprüft wird, dass alle Anforderungen exakt einmal definiert sind und/oder dass keine Vererbungsregel verletzt wird . Verfahren nach mindestens einem der Ansprüche 1 bis
4 , dadurch gekennzeichnet , dass alle Schnittstellenanforderungen obj ektorientiert erstellt werden . Verfahren nach mindestens einem der Ansprüche 1 bis
5 , dadurch gekennzeichnet , dass alle funktionellen Anforderungen, welche die Struktur und das Verhalten des technischen Prozesses beschreiben, obj ektorientiert erstellt werden . Verfahren nach mindestens einem der Ansprüche 1 bis
6 , dadurch gekennzeichnet , dass die Klassen teilweise oder vollständig mit Schreib- bzw. Löschschutz ausrüstet sind, um eine versehentliche Änderung der dritten Klassen, welche zu einer Verletzung der Vererbungsregeln führen kann, zu verhindern . Verfahren nach mindestens einem der Ansprüche 1 bis
7 , dadurch gekennzeichnet , dass die dritten Klassen auf Vollständigkeit geprüft werden um sicherzustellen, dass alle Eigenschaften der dritten Klassen eindeutig definiert und/oder eindeutig anderen Klassen oder Klassengruppen zugeordnet sind . Verfahren nach mindestens einem der Ansprüche 1 bis
8 , dadurch gekennzeichnet , dass die dritten Klassen mit klassenübergreifenden Systemmodi wechselwirken und überprüft wird, ob die dritten Klassen funktionelle Anforderungen für Kombinationen von Systemmodi definieren . Verfahren nach mindestens einem der Ansprüche 1 bis
9 , dadurch gekennzeichnet , dass mindestens eine der Klassen mindestens eine Verhaltensanforderung aufweist , welche überprüft wird, ob unabhängig vom Zustand mindestens eines Eingangsparameters ein einziges , definiertes Verhalten bewirkt wird . Verfahren nach mindestens einem der Ansprüche 1 bis
10 , dadurch gekennzeichnet, dass geprüft wird, ob an eine Instanz lediglich diej enigen systemeigenschaf ts- abhängigen Anforderungen vererbt werden, welche in den Anforderungen für das System definiert sind .
PCT/EP2023/000004 2022-01-20 2023-01-20 Verfahren zur computer gestützten prüfung einer anforderungsspezifikation eines technischen prozesses WO2023138894A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022000208.6 2022-01-20
DE102022000208.6A DE102022000208A1 (de) 2022-01-20 2022-01-20 Verfahren zur Computer gestützten Prüfung einer Anforderungsspezifikation eines technischen Prozesses

Publications (1)

Publication Number Publication Date
WO2023138894A1 true WO2023138894A1 (de) 2023-07-27

Family

ID=85199586

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/000004 WO2023138894A1 (de) 2022-01-20 2023-01-20 Verfahren zur computer gestützten prüfung einer anforderungsspezifikation eines technischen prozesses

Country Status (2)

Country Link
DE (1) DE102022000208A1 (de)
WO (1) WO2023138894A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006050112A1 (de) * 2006-10-25 2008-04-30 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren zur Erstellung einer Anforderungsbeschreibung für ein eingebettetes System
US20130080140A1 (en) * 2011-09-23 2013-03-28 The Mathworks, Inc. Using a requirements framework
DE102017004348A1 (de) 2017-05-08 2018-11-08 Gerhard Schilling Verfahren zur Computer gestützten, automatisierten Überprüfung von Software-Anforderungen

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006050112A1 (de) * 2006-10-25 2008-04-30 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren zur Erstellung einer Anforderungsbeschreibung für ein eingebettetes System
US20130080140A1 (en) * 2011-09-23 2013-03-28 The Mathworks, Inc. Using a requirements framework
DE102017004348A1 (de) 2017-05-08 2018-11-08 Gerhard Schilling Verfahren zur Computer gestützten, automatisierten Überprüfung von Software-Anforderungen

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANA M D MOREIRA ET AL: "Rigorous object-oriented analysis", 21 September 1994, OBJECT-ORIENTED METHODOLOGIES AND SYSTEMS, SPRINGER BERLIN HEIDELBERG, BERLIN, HEIDELBERG, PAGE(S) 65 - 78, ISBN: 978-3-540-58451-3, XP019191449 *
MUELLER-GLASER K D ET AL: "AN APPROACH TO COMPUTER0AIDED SPECIFICATION", IEEE JOURNAL OF SOLID-STATE CIRCUITS, IEEE, USA, vol. 25, no. 2, 1 April 1990 (1990-04-01), pages 335 - 345, XP000116671, ISSN: 0018-9200, DOI: 10.1109/4.52154 *

Also Published As

Publication number Publication date
DE102022000208A1 (de) 2023-07-20

Similar Documents

Publication Publication Date Title
EP0852759B1 (de) Entwurfsverfahren für die anlagentechnik und rechnergestütztes projektierungssystem zur verwendung bei diesem verfahren
EP0685086B1 (de) Einrichtung zur automatischen erzeugung einer wissensbasis für ein diagnose-expertensystem
WO1998040796A1 (de) Verfahren zur rechnergestützten fehleranalyse von sensoren und/oder aktoren in einem technischen system
DE10026478A1 (de) Verfahren zur Generierung anwendungsspezifischer Eingabedateien
WO2007057270A1 (de) Programmgesteuerte einheit und verfahren zum betreiben derselbigen
DE10133375A1 (de) Verfahren und Vorrichtung zum automatischen Erstellen eines Bayes-Netzwerks
DE19854754A1 (de) Verfahren, Editor, Rechner, Steuermodul und Speichermittel zum Editieren von Konfigurationsdaten für Telekommunikationssysteme
WO2023138894A1 (de) Verfahren zur computer gestützten prüfung einer anforderungsspezifikation eines technischen prozesses
WO2018206146A2 (de) Verfahren zur computer gestützten, automatisierten überprüfung von anforderungen
DE19721366A1 (de) Elektrische Schaltungsanordnung
EP1950635B1 (de) Verfahren zum Betrieb eines Automatisierungssystems
EP1202166A1 (de) System zur Verifikation von Software-Anwendungsmodellen in Ketten von Software-Entwurfswerkzeugen
DE10209640A1 (de) Verfahren zur Generierung eines Automatisierungsprogramms
EP3933593A1 (de) Verfahren und computerprogramm zum testen eines technischen systems
EP1766787A2 (de) Verfahren und anordnung zur erkennung unidirektionaler fehler mit systematischen ungeordneten codes
EP1958101B1 (de) System und verfahren zur automatischen prüfung von planungsergebnissen
EP1960854A1 (de) Diagnoseverfahren und diagnosevorrichtung zur funktionsorientierten diagnose eines systems mit vernetzten komponenten
EP1997007A2 (de) Verfahren und managementsystem zum konfigurieren eines informationssystems
EP1379953A1 (de) Programmgesteuerte einheit
WO1990002994A1 (de) Schaltungsanordnung zur addition oder subtraktion von im bcd-code oder dual-code codierten operanden
WO2023156060A1 (de) Verfahren zur automatisierten verifizierung von anforderungsspezifikationen eines technischen prozesses
EP0708941A1 (de) Verfahren zum test eines objektorientierten programms
EP1795999A1 (de) Verfahren und System zur Transformation von Elementen eines in einer Kontaktplandarstellung vorliegenden Steuerungsprogramms in eine Funktionsplandarstellung
EP1590751A2 (de) Eigenschaftsnachweis (formale verifikation) für ein mischsystem mit analogen und digitalen teilsystemen
DE10131438B4 (de) Verfahren zur Entwicklung einer technischen Komponente

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23703696

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE