DE102010047954A1 - Formelle offline-Verifikation ausführbarer Modelle - Google Patents

Formelle offline-Verifikation ausführbarer Modelle Download PDF

Info

Publication number
DE102010047954A1
DE102010047954A1 DE102010047954A DE102010047954A DE102010047954A1 DE 102010047954 A1 DE102010047954 A1 DE 102010047954A1 DE 102010047954 A DE102010047954 A DE 102010047954A DE 102010047954 A DE102010047954 A DE 102010047954A DE 102010047954 A1 DE102010047954 A1 DE 102010047954A1
Authority
DE
Germany
Prior art keywords
statement
track
symbols
propositional
proposition
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
DE102010047954A
Other languages
English (en)
Inventor
Swarup K. Karnataka Mohalik
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GM Global Technology Operations LLC
Original Assignee
GM Global Technology Operations LLC
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 GM Global Technology Operations LLC filed Critical GM Global Technology Operations LLC
Publication of DE102010047954A1 publication Critical patent/DE102010047954A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3604Software analysis for verifying properties of programs

Abstract

Ein System und ein Verfahren für eine automatische formelle Verifikation eines ausführbaren Systems umfassen einen Aussagemonitor, der ausgestaltet ist, um ein System hinsichtlich einer Aussage in der Spezifikation zu verifizieren. Der Aussagemonitor umfasst einen Parser, der ausgestaltet ist, um eine Propositionsformel, die eine Aussage in der Spezifikation darstellt, unter Verwendung Boolscher Propositionen zu erzeugen, ein Filter, das ausgestaltet ist, um eine Spur von Wahrheitszuordnungen für die Propositionssymbole zu erzeugen, und einen Spurverifizierer, der ausgestaltet ist, um die Aussage unter Verwendung der Spur von Wahrheitszuordnungen für die Propositionssymbole und die Propositionsformel zu verifizieren.

Description

  • HINTERGRUND
  • Im Allgemeinen umfasst ein Systementwicklungsprozess eine Anforderungsentwicklungsstufe, eine Entwurfs- und Entwicklungsstufe und eine Verifikationsstufe. Eine Anforderung kann sich durch eine dokumentierte Notwendigkeit, wie ein bestimmtes Produkt oder ein bestimmter Dienst arbeiten sollte, auszeichnen. Genauer gesagt kann eine Anforderung als Statement bezeichnet werden, das die notwendigen Funktionalitäten, Attribute, Fähigkeiten, Eigenschaften oder Qualitäten eines Systems identifiziert. Anforderungen in Form einer Anforderungsspezifikation werden als Eingänge in die Entwurfsstufen eines Systementwicklungsprozesses verwendet, um zu entwerfen, welche Elemente und Funktionen für ein bestimmtes System notwendig sind.
  • Anforderungsspezifikationen können unter Verwendung einer Vielzahl von Sprachen ausgedrückt werden. Diese Sprachen können grafischer Natur sein oder in Textform vorliegen und können ohne Einschränkung Übergangssysteme (z. B. Zustandsmaschinen), Ereignissequenzabläufe (z. B. Szenario- oder Sequenzdiagramme) und eine strukturierte englische Sprache umfassen. Das System wird unter Verwendung von Software oder Hardware oder beidem realisiert, wobei oftmals Schnittstellen verwendet werden, die unter Verwendung von Sensoren zum Erfassen der Eingänge der Umgebung (einschließlich des Benutzers) und Aktoren zum Steuern der Hardware realisiert sind. Bei komplexen Systemen, insbesondere bei jenen, bei denen Sicherheit ein primäres Anliegen ist, sind ein umfassendes Testen und eine umfassende Verifikation des Systems erforderlich, um sicherzustellen, dass das Verhalten des Systems den Anforderungsspezifikation des Systems genügt.
  • Ein allgemeiner Ansatz zum Testen und Verifizieren eines Systems ist eine formelle Verifikation. Eine formelle Verifikation ist allgemein der Prozess des Beweisens oder Widerlegens der Korrektheit vorgesehener Algorithmen, die einem System unterliegen, in Bezug auf eine formelle Spezifikation (auch als Eigenschaft bezeichnet), wobei eine Klasse von Zustandsraumuntersuchungsverfahren verwendet wird. Ein Ansatz einer formellen Verifikation ist eine Modellüberprüfung, was eine automatische, systematische, umfassende Untersuchung der Verhalten des Modells ist. Für gewöhnlich umfasst dies das Untersuchen aller Zustände und Übergänge in dem Modell durch Verwenden von intelligenten und bereichsspezifischen Abstraktionstechniken, um ganze Gruppen von Zuständen in einer einzelnen Operation zu betrachten und die Rechenzeit zu reduzieren. Realisierungstechniken umfassen eine Zustandsraumaufzählung, eine symbolische Zustandsraumaufzählung, eine abstrakte Interpretation, eine symbolische Simulation und eine Abstraktionsverfeinerung. Die zu verifizierenden Eigenschaften werden oftmals in einer temporären Logik beschrieben, wie beispielsweise einer linearen temporären Logik (LTL von linear temporal logic) oder einer Rechenbaumlogik (CTL von computational tree logic).
  • Bekannte Verfahren einer formellen Verifikation sind normalerweise nur auf die Modelle des Systems in der Entwurfsstufe oder auf den Softwareabschnitt der Systeme anwendbar. Obwohl es theoretisch möglich ist, kann es unmöglich sein, Modelle für gesamte Systeme zu realisieren, oder können sie bestenfalls extrem groß sein, so dass existierende Techniken formeller Verfahren den resultierenden großen Zustandsraum nicht bewältigen können. Daher ist ein Testen unter Verwendung einer Simulation des Systems der einzige Weg zum Verifizieren des Systems hinsichtlich seiner Anforderungsspezifikation. Da die Testfälle (Testeingänge in das System und die gewünschten Ausgänge) jedoch durch Tester geschrieben werden, testen sie für gewöhnlich lediglich einfache Spezifikationen. Der Grund hierfür ist, dass das Schreiben von Testfällen für komplexe temporäre Spezifikationen fehleranfällig ist. Ferner ist das Überprüfen der Simulationsläufe hinsichtlich der erwünschten Ausgänge gemäß komplexen temporären Spezifikationen auch zeitaufwendig und fehleranfällig. Somit ist es notwendig, ein System und ein Verfahren für eine automatische formelle Verifikation eines ausführbaren Systems bereitzustellen, die für Systeme jeder Größe skalierbar sind.
  • ZUSAMMENFASSUNG
  • Ein System und ein Verfahren für eine automatische formelle Verifikation eines ausführbaren Systems umfassen einen Parser, der ausgestaltet ist, um eine Propositionsformel, die eine Aussage in der Spezifikation darstellt, unter Verwendung von Boolschen Propositionen zu erzeugen, ein Filter, das ausgestaltet ist, um eine Spur von Wahrheitszuordnungen für die Propositionssymbole zu erzeugen, und einen Spurverifizierer, der ausgestaltet ist, um die Aussage unter Verwendung der Spur von Wahrheitszuordnungen für die Propositionssymbole und die Propositionsformel zu verifizieren.
  • Das Verfahren zum Verifizieren eines Systems hinsichtlich einer Aussage in einer Spezifikation umfasst das Erzeugen einer Propositionsformel, die eine Aussage in der Spezifikation darstellt, unter Verwendung von Boolschen Propositionen, wobei jede Boolsche Proposition mit einer atomaren Aussage in der Aussage in Verbindung steht, und das Erzeugen einer Spur, die eine Sequenz von Konfigurationen des Systems in Bezug auf die Aussage darstellt, wobei die Spur Spurkonfigurationsdaten umfasst, die eine Konfiguration des Systems in Ansprechen auf eine bestimmte Spur darstellen. Das Verfahren umfasst ferner das Umwandeln der Spurkonfigurationsdaten in Wahrheitszuordnungen für einen Satz von Propositionssymbolen, das Erzeugen einer Spur des Systems unter Verwendung der Wahrheitszuordnungen für die Propositionssymbole und das Verifizieren der Aussage unter Verwendung der Spur von Wahrheitszuordnungen für die Propositionssymbole und die Propositionsformel.
  • Weitere Merkmale werden aus der folgenden Beschreibung und den beigefügten Ansprüchen in Verbindung mit den begleitenden Zeichnungen ersichtlich.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 zeigt ein beispielhaftes System für eine formelle Online-Verifikation eines ausführbaren Systems gemäß einer Ausführungsform;
  • 2 zeigt einen beispielhaften aussagebasierten Verifikationsalgorithmus, der das System verwendet, um die Testfallaussagen zu verifizieren, gemäß der in 1 gezeigten Ausführungsform;
  • 3 zeigt einen beispielhaften Algorithmus zum Realisieren eines Aussagemonitors gemäß 2;
  • 4 zeigt einen beispielhaften Algorithmus zum Auswerten einer Aussage gemäß 3;
  • 5 zeigt ein beispielhaftes System einer formellen Offline-Verifikation gemäß einer Ausführungsform;
  • 6 zeigt einen beispielhaften aussagebasierten Verifikationsalgorithmus, der einen Satz von Spuren verwendet, um Aussagen in der Spezifikation zu verifizieren, gemäß dem in 5 gezeigten System;
  • 7 zeigt einen beispielhaften Algorithmus zum Realisieren eines Aussagemonitors gemäß 6; und
  • 8 zeigt einen beispielhaften Algorithmus zum Auswerten einer Aussage gemäß 7.
  • DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
  • Die hierin beschriebenen Ausführungsformen beziehen sich allgemein auf ein System und ein Verfahren für eine formelle Verifikation ausführbarer Systeme und insbesondere auf ein System und ein Verfahren für eine automatische formelle Verifikation eines ausführbaren Systems hinsichtlich bestimmter Abschnitte einer Spezifikation. Das System und das Verfahren setzen einen aussagebasierten Verifikationsprozess ein, der für ein System jeder Größe skalierbar ist und ausgestaltet ist, um mit oder ohne direkte Zugreifbarkeit auf das System (d. h. online bzw. offline) zu arbeiten.
  • Unter Verwendung eines Online-Ansatzes auf das System einer formellen Verifikation wird eine Sammlung (Suite) von Testfällen zum Verifizieren einer bestimmten Aussage von der Spezifikation entwickelt. Im Allgemeinen ist eine Aussage ein Wahr-Falsch-Statement, das verwendet wird, um bestimmte Eigenschaften von Variablen zu verifizieren, die in der Spezifikation enthalten sind. Die Testfälle werden durch das System simuliert, und die Ergebnisse werden zur Auswertung und Verifikation der Aussage an einen Aussagemonitor gesendet.
  • Unter Verwendung eines Offline-Ansatzes auf das System einer formellen Verifikation wird ein Satz von Spuren, die eine Sequenz von Konfigurationen des Systems darstellen, erzeugt und in das System eingegeben. Die Konfiguration für jede Spur wird für eine Auswertung und Verifikation der darin enthaltenen Aussagen an den Aussagemonitor gesendet.
  • Online-Verifikationssystem
  • 1 zeigt ein beispielhaftes System 10 einer formellen Online-Verifikation mit einer Testsammlung 12 in Kommunikation mit einem Aussagemonitor 14 und einem ausführbaren System 16. Das System 10 kann an einer oder mehreren geeigneten Recheneinrichtungen realisiert sein, die allgemein Anwendungen umfassen, die Softwareanwendungen sein können, die konkret als Satz von von einem Computer ausführbaren Anweisungen an einem von einem Computer lesbaren Medium in der Recheneinrichtung umfasst sind. Die Recheneinrichtung kann eine beliebige einer Anzahl von Recheneinrichtungen sein, wie beispielsweise ein Personal Computer, ein Prozessor, eine tragbare Recheneinrichtung etc.
  • Recheneinrichtungen umfassen im Allgemeinen jeweils Anweisungen, die durch eine oder mehrere Einrichtungen wie jene, die oben aufgelistet sind, ausgeführt werden können. Die von einem Computer ausführbaren Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung einer Vielzahl von Programmierserachen und/oder Technologien erzeugt werden, die ohne Einschränkung und entweder allein oder in Kombination JavaTM, C, C++, Visual Basic, Java Script, Perl, etc. umfassen. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem von einem Computer lesbaren Medium, etc., und führt er diese Anweisungen aus, wodurch ein oder mehrere Prozesse durchgeführt werden, die einen oder mehrere der hierin beschriebenen Prozesse umfassen. Solche Anweisungen und andere Daten können unter Verwendung einer Vielzahl von bekannten von einem Computer lesbaren Medien gespeichert und gesendet werden.
  • Ein von einem Computer lesbares Medium umfasst jedes Medium, das an einem Bereitstellen von Daten (z. B. Anweisungen), die durch eine Recheneinrichtung, wie beispielsweise einen Computer, gelesen werden können, beteiligt ist. Solch ein Medium kann viele Formen annehmen, die ohne Einschränkung nichtflüchtige Medien, flüchtige Medien und Übertragungsmedien umfassen. Nichtflüchtige Medien umfassen beispielsweise optische oder magnetische Platten und andere dauerhafte Speicher. Flüchtige Medien umfassen einen dynamischen Direktzugriffsspeicher (DRAM von dynamic random access memory), der typischerweise einen Hauptspeicher bildet. Allgemeine Formen von von einem Computer lesbarem Medium umfassen jedes Medium, von dem ein Computer lesen kann.
  • Auf 1 Bezug nehmend ist die Testsammlung 12 eine Ansammlung von Testfällen, die entworfen wurden, um das Verhalten des Systems für verschiedene Aussagen, die in der Spezifikation ausgeführt sind, zu bewerten. Im Allgemeinen ist ein Testfall eine Sequenz von Eingängen und eine Sequenz von erwarteten Ausgängen, er kann jedoch auch eine Testfall-ID, eine Testbeschreibung, in Beziehung stehende oder Voraussetzungsanforderungen, eine Testkategorie, Bemerkungen etc. umfassen. Die Testsammlung 12 kann unter Verwendung jedes zugänglichen Mediums gespeichert sein, das ohne Einschränkung eine Datei, wie beispielsweise ein Textverarbeitungsprogrammdokument, eine Tabellenkalkulation, eine Tabelle oder eine Datenbank umfasst.
  • Der Aussagemonitor 14 umfasst wie nachstehend ausführlicher erläutert einen Parser 14a, ein Filter 14b, eine Speichereinrichtung 14c und einen Spurverifizierer 14d. Der Parser 14a ist eine Software, die eine Aussage in der Spezifikation, die in einer Logiksprache, wie beispielsweise LTL, geschrieben ist, aufspaltet und einen Satz von atomaren Aussagen ausgibt (Aussagen, die nicht weiter aufgespaltet werden können). Die Speichereinrichtung 14c speichert eine Verbindungsliste, die jede durch den Parser 14a erzeugte atomare Aussage mit einem eindeutigen Propositionssymbol in Verbindung bringt.
  • Das Filter 14b ist eine Software, die als Eingang eine Konfiguration des Systems hernimmt, wobei den in den Aussagen genannten Variablen Werte zugeordnet werden, und die den Propositionssymbolen Wahrheitswerte (Wahr oder Falsch) zuordnet, indem die entsprechenden atomaren Aussagen unter Verwendung der Werte der Variablen in der Konfiguration ausgewertet werden. Der Spurverifizierer 14d weist die Propositionsformel F auf, die die Aussage ist, bei der alle atomaren Aussagen durch die entsprechenden Propositionssymbole ersetzt wurden. Der Spurverifizierer 14d wertet F unter Verwendung des Wahrheitswerts der Propositionen für jede der Konfigurationen in der Sequenz von Konfigurationen aus, die von der Spur des Systems entsprechend einem Testfall erhalten werden.
  • Wie es nachstehend ausführlicher beschrieben ist wird jeder Testfall in der Testsammlung durch das ausführbare System simuliert, das in einer Modellerstellungssprache, wie beispielsweise, jedoch ohne Einschränkung, C, C++, Unified Modeling Language (UML) und Simulink/Stateflow, geschrieben ist. Die Simulationsergebnisse werden für eine Auswertung und Verifikation der Testfallaussage an den Aussagemonitor 14 gesendet.
  • 2 zeigt einen beispielhaften aussagebasierten Verifikationsalgorithmus 20, der das ausführbare System 16 verwendet, um die Testfallaussagen gemäß dem in 1 gezeigten System zu verifizieren. Der Algorithmus 20 beginnt bei Schritt 22 durch Initialisieren des ausführbaren Systems 16 und der Testsammlung 12. In Schritt 24 ermittelt der Algorithmus 20, ob alle Testfälle in der initialisierten Testsammlung ausgeführt wurden. Wenn dies der Fall ist, wird in Schritt 26 ein Ausgang ”Testsammlung beendet” erzeugt. Wenn die Testsammlung 12 weiterhin nicht ausgeführte Testfälle enthält, wird in Schritt 28 der nächste Testfall in der Sammlung 12 ausgewählt. In Schritt 30 ermittelt der Algorithmus 20, ob alle Eingänge von dem ausgewählten Testfall abgearbeitet wurden. Wenn dies der Fall ist, wird in Schritt 32 ein Ausgang ”Testfall beendet” erzeugt. Wenn weiterhin Eingänge auszuführen sind, wird in Schritt 34 der nächste Testeingang von dem ausgewählten Testfall für eine Simulation an das System 16 gesendet. Die Testfallsimulationsdaten, die die Konfiguration eines Systems (z. B. Modell) darstellen, hierin nachfolgend als ”Konfiguration e” bezeichnet, werden in Schritt 36 von dem System 16 erfasst. Bei diesem Beispiel umfasst Konfiguration e den Testfalleingang, die Zustandsvariablen mit aktuellen Werten und die Ausgangsvariablen mit aktuellen Werten. Die Sequenz von Konfigurationen des Systems, die einem Testfall entspricht, kann auch als Lauf des Systems bezeichnet werden. In Schritt 38 wird eine Kopie von Konfiguration e zur Auswertung und Verifikation der Aussage an den Aussagemonitor 14 gesendet. Bei einem nicht einschränkenden Ansatz werden die mit Konfiguration e in Verbindung stehenden Daten in einer Datei oder Datenbank gespeichert oder auf andere Weise für andere Systemkomponenten und/oder Prozesse zugänglich gemacht, wie es nachstehend in Bezug auf andere Merkmale des Systems ausführlich beschrieben ist.
  • 3 zeigt einen beispielhaften Algorithmus 40 zum Realisieren des Aussagemonitors 14. Der Algorithmus wird bei Schritt 42 initialisiert, indem die Ergebnisvariable auf ”NA” gesetzt wird, was bedeutet, dass ein wahres oder falsches Ergebnis auf der Grundlage der aktuellen Information nicht angegeben werden kann (not applicable), oder ”NA” kann in einigen Fällen einen initialisierten Platzhalter für den Wert des Ergebnisses darstellen, wenn der Prozess beginnt oder endet. In Schritt 44 ermittelt der Algorithmus 40, ob der aktuelle Test beendet ist. Wenn dies der Fall ist, gibt das System in Schritt 46 ”NA” aus. Wenn der ausgewählte Testfall nicht beendet ist, wird in Schritt 48 Konfiguration e erfasst und wird in Schritt 50 die aktuelle Aussage ausgewertet.
  • 4 zeigt einen Algorithmus 100 zum Auswerten der aktuellen Aussage gemäß Schritt 50 von 3. Unter Verwendung dieses Algorithmus wird der ausgewählte Testfall, der zum Verifizieren einer bestimmten Aussage entworfen wurde, hinsichtlich der Spezifikationsanforderungen für diese Aussage ausgewertet. Mit anderen Worten werden Ergebnisse von der Testfallsimulation des Systems (d. h. Konfiguration e) hinsichtlich der entsprechenden Aussage von der Spezifikation ausgewertet, um zu ermitteln, ob die durch das System ausgedrückte Aussage den Anforderungen der Spezifikation genügt.
  • Der Algorithmus 100 beginnt in Schritt 102 durch Extrahieren der gegebenen Aussage von der Spezifikation, die allgemein in einer formellen Sprache geschrieben wird, die die Zeit als Sequenz von Zuständen sieht, wie beispielsweise eine lineare temporäre Logik (LTL). Bei einer temporären Logik kann ein Statement zeitlich konstant sein, wobei sich jedoch sein Wahrheitswert zeitlich ändern kann. Beispielsweise kann das Statement zu einer gegebenen Zeit wahr sein, wobei das Statement jedoch zu einer anderen Zeit falsch sein kann. Es kann jedoch kein Statement in dem gleichen Zustand (z. B. ein Moment, ein Zeitpunkt oder ein Augenblick) gleichzeitig wahr oder falsch sein. Ein Schreiben der Spezifikation in formeller Sprache erlaubt dem System eine automatische Simulation und Verifikation des Systems 16 hinsichtlich der Spezifikation.
  • Unter Verwendung eines Ansatzes wird die Spezifikation in ActionLTL geschrieben, was in der Hinsicht eine Variante der linearen temporären Logik (LTL) ist, dass es die Spezifikation komplexer temporärer Anforderungen, wie beispielsweise Auftreten eines Ereignisses, arithmetische Ausdrücke und parametrische Funktionen, ermöglicht. Die ActionLTL-Aussage wird dann in Schritt 104 unter Verwendung des Parsers 14a in Boolsche Propositionen umgewandelt. Mit anderen Worten werden die komplexen Ausdrücke in der Aussage in elementare atomare Ausdrücke aufgespaltet, die in diesem Fall Boolsche Ausdrücke in ihrer einfachsten Form sind. In Schritt 106 wird jedem atomaren Ausdruck ein Propositionssymbol zugeordnet und werden die kollektiven Zuordnungen an eine Verbindungsliste ausgegeben, die die Verbindung zwischen den Ausdrücken von Variablen in Boolscher Form und den zugeordneten Propositionssymbolen speichert. Bei diesem Beispiel wird die Verbindungsliste in der Speichereinrichtung 14c gespeichert, wobei jedoch, wie es ein Fachmann verstehen wird, jedes Mittel verwendet werden kann, das geeignet ist, um die Verbindungsliste zu speichern, auf diese zuzugreifen und diese abzurufen. In Schritt 108 erzeugt der Algorithmus 100 eine Propositionsformel durch Ersetzen jedes atomaren Ausdrucks durch das entsprechende Propositionssymbol. Wie es nachstehend ausführlicher erklärt ist, wird die Propositionsformel in den Spurverifizierer 14d (1) eingegeben und in Verbindung mit anderen Systemmerkmalen verwendet, um die gegebene Aussage auszuwerten und zu verifizieren.
  • In Schritt 110 ruft das Filter 14b die Daten von Konfiguration e ab, die Zustandsvariablen und -werte umfassen. In Schritt 112 ordnet ein mit dem Filter 14b in Verbindung stehendes Filterprogramm jedem Propositionssymbol entsprechend den atomaren Aussagen unter Verwendung der Werte der Variablen in jeder Konfiguration Wahrheitswerte zu (Wahr oder Falsch). Genauer gesagt betrachtet das Filter 14b die Verbindungsliste, um zu ermitteln, welcher atomare Ausdruck welchem Propositionssymbol zugeordnet ist. Die Beziehung zwischen den atomaren Ausdrücken und den Propositionssymbolen wird durch das Filter 14b in Schritt 114 verwendet, um die Testfallsimulation des Systems 16 (d. h. Lauf des Systems) in eine Sequenz von Wahrheitswertzuordnungen zu den Propositionssymbolen umzuwandeln. Somit erzeugt das Filter 14b anstatt eines simulierten Testfalls, der an Variablen ausgeführt wird, die in einer formellen Sprache ausgedrückt werden, eine Sequenz von Zuordnungen zu den Propositionssymbolen.
  • In Schritt 116 werden die Propositionsformel von Schritt 108 und die Sequenz von Zuordnungen zu den Propositionssymbolen von Schritt 114 in einen Spurverifizierer 14d eingegeben, um formell zu verifizieren, dass die in dem System 16 dargestellte Aussage der in der Spezifikation ausgeführten Aussage genügt. In Schritt 118 gibt der Spurverifizierer das Ergebnis der Spur aus.
  • Wieder auf 3 Bezug nehmend ermittelt der Algorithmus 40 in Schritt 120, ob das Ergebnis der Spur von Schritt 118 ”wahr” ist, was bedeutet, dass der Spurverifizierer 14d das System 16 hinsichtlich der Spezifikation für die gegebene Aussage verifizieren konnte. Wenn dies der Fall ist, das Ergebnis ”wahr” ist, gibt das System in Schritt 122 ein ”Wahr”-Statement aus. Wenn das Ergebnis nicht ”wahr” ist, ermittelt der Algorithmus 40 in Schritt 124, ob das Ergebnis ”Falsch” ist. Wenn ein falsches Ergebnis ermittelt wird, gibt das System in Schritt 126 ein ”Falsch”-Statement aus. Wenn das Ergebnis nicht falsch ist, wird die aktuelle Aussage in Schritt 128 aktualisiert, indem eine Information bezüglich der Auswertung aufgezeichnet wird. Wenn ein Ergebnis weder wahr noch falsch ist, ist dies ein Hinweis für das System, dass eine weitere Verarbeitung und Auswertung der Zustände abgeschlossen werden muss.
  • Offline-Verifikationssystem
  • 5 zeigt ein beispielhaftes System 200 einer formellen Offline-Verifikation. Wie das Online-System von 1 ist das Offline-Verifikationssystem 200 ausgestaltet, um Aussagen von der Spezifikation in Bezug auf ein bestimmtes System zu verifizieren, jedoch ohne dass während des Testens auf das tatsächliche System zugegriffen werden muss. Das Verifikationssystem 200 umfasst eine Spursammlung 202 in Kommunikation mit einem Aussagemonitor 204. Der Aussagemonitor 204 des Offline-Systems 200 ist in der Hinsicht im Wesentlichen der gleiche wie der Online-Aussagemonitor 14, dass der Aussagemonitor 204 einen Parser 204a, ein Filter 204b, eine Speichereinrichtung 204c und einen Spurverifizierer 204d umfasst. Die Spursammlung 202 verwendet jedoch, im Gegensatz zu der Testsammlung 12 von 1, die an dem System simulierte Testfälle verwendet, einen Satz von Spuren zum Bestätigen der Aussagen von der Spezifikation. Bei einem Beispiel stellen die Spuren eine Sequenz von Konfigurationen des Systems dar, die für eine Verifikation in den Aussagemonitor 204 eingegeben werden. Die Spuren können aus jeder geeigneten Testerzeugungssoftware erzeugt werden, wie beispielsweise, jedoch ohne Einschränkung, Reactis®. Aus einer Perspektive sind die Spuren in der Hinsicht ähnlich zu den Läufen des Systems unter Verwendung des oben beschriebenen Online-Ansatzes, dass die Spuren eine Sequenz von Eingängen, Zustandsvariablen und Ausgangsvariablen umfassen. Mit anderen Worten stellen die Spurkonfigurationen gewählte Zustands- und Ausgangsvariablen des Systems in Ansprechen auf eine spezifische Eingangssequenz dar.
  • 6 zeigt einen beispielhaften aussagebasierten Verifikationsalgorithmus 220, der einen Satz von Spuren verwendet, um Aussagen in der Spezifikation gemäß dem in 5 gezeigten System zu verifizieren. Der Algorithmus 220 beginnt bei Schritt 222 durch Laden des Satzes von Spuren in das System 200. In Schritt 224 ermittelt der Algorithmus 220, ob alle Spuren in der geladenen Testsammlung 202 ausgeführt wurden. Wenn dies der Fall ist, wird in Schritt 226 ein Ausgang ”Spursammlung beendet” erzeugt. Wenn die Spursammlung 202 weiterhin nicht ausgeführte Spuren enthält, wird in Schritt 228 die nächste Spur in der Sammlung 202 ausgewählt. In Schritt 230 ermittelt der Algorithmus 200, ob alle Konfigurationen (d. h. Läufe) der ausgewählten Spur abgearbeitet wurden. Wenn dies der Fall ist, wird in Schritt 232 ein Ausgang ”Spur beendet” erzeugt. Wenn weiterhin Konfigurationen auszuführen sind, werden Spurkonfigurationsdaten, die die Konfiguration eines Systems gemäß einer gegebenen Spur darstellen, hierin nachfolgend als ”Konfiguration e” bezeichnet, in Schritt 234 erfasst. Bei diesem Beispiel umfasst Konfiguration e die Spureingangssequenz, die Zustandsvariablen mit aktuellen Werten und die Ausgangsvariablen mit aktuellen Werten. In Schritt 236 wird eine Kopie von Konfiguration e zur Auswertung und Verifikation der Aussage an den Aussagemonitor 204 gesendet. Bei einem nicht einschränkenden Ansatz werden die mit Konfiguration e in Verbindung stehenden Daten in einer Datei oder Datenbank gespeichert oder auf andere Weise für andere Systemkomponenten und/oder Prozesse zugänglich gemacht, wie es nachstehend in Bezug auf andere Merkmale des Systems ausführlich beschrieben ist.
  • 7 zeigt einen beispielhaften Algorithmus 300 zum Realisieren des Aussagemonitors 204. Der Algorithmus 300 wird bei Schritt 302 initialisiert, indem die Ergebnisvariable auf ”NA” gesetzt wird, was bedeutet, dass ein wahres oder falsches Ergebnis auf der Grundlage der aktuellen Information nicht angegeben werden kann, oder ”NA” kann in einigen Fällen einen initialisierten Platzhalter für den Wert des Ergebnisses darstellen, wenn der Prozess beginnt oder endet. In Schritt 304 ermittelt der Algorithmus 300, ob die aktuelle Spur beendet ist. Wenn dies der Fall ist, gibt das System in Schritt 306 ”NA” aus. Wenn die ausgewählte Spur nicht beendet ist, wird in Schritt 308 Konfiguration e erfasst und wird in Schritt 310 die aktuelle Aussage ausgewertet.
  • 8 zeigt einen Algorithmus 400 zum Auswerten der aktuellen Aussage gemäß Schritt 310 von 7. Unter Verwendung dieses Algorithmus wird die ausgewählte Spur, die zum Verifizieren einer bestimmten Aussage entworfen wurde, hinsichtlich der Spezifikationsanforderungen für diese Aussage ausgewertet. Mit anderen Worten werden Ergebnisse von der Spur des Systems (d. h. Konfiguration e) hinsichtlich der entsprechenden Aussage von der Spezifikation ausgewertet, um zu ermitteln, ob die durch das System ausgedrückte Aussage den Anforderungen der Spezifikation genügt.
  • Der Algorithmus 400 beginnt bei Schritt 402 durch Extrahieren der gegebenen Aussage von der Spezifikation, die allgemein in einer formellen Sprache geschrieben ist, wie beispielsweise lineare temporäre Logik (LTL) oder ActionLTL, die in der Hinsicht eine Variante der linearen temporären Logik (LTL) ist, dass sie die Spezifikation komplexer temporärer Anforderungen, wie beispielsweise Auftreten eines Ereignisses, arithmetische Ausdrücke und parametrische Funktionen, ermöglicht. Die ActionLTL-Aussage wird dann in Schritt 404 unter Verwendung des Parsers 204a geparst, um Boolsche Propositionen zu identifizieren. Mit anderen Worten werden die komplexen Ausdrücke in der Aussage in elementare atomare Ausdrücke aufgespaltet, die in diesem Fall Boolsche Ausdrücke in ihrer einfachsten Form sind. In Schritt 406 wird jedem atomaren Ausdruck ein Propositionssymbol zugeordnet und werden die kollektiven Zuordnungen an eine Verbindungsliste ausgegeben, die die Verbindung zwischen den Ausdrücken von Variablen in Boolscher Form und den zugeordneten Propositionssymbolen speichert. Bei diesem Beispiel wird die Verbindungsliste in der Speichereinrichtung 204c gespeichert, wobei jedoch, wie es ein Fachmann verstehen wird, jedes Mittel verwendet werden kann, das geeignet ist, um die Verbindungsliste zu speichern, auf diese zuzugreifen und diese abzurufen. In Schritt 408 erzeugt der Algorithmus 400 eine Propositionsformel durch Ersetzen jedes atomaren Ausdrucks durch das entsprechende Propositionssymbol. Wie es nachstehend ausführlicher erklärt ist, wird die Propositionsformel in den Spurverifizierer 204d (5) eingegeben und in Verbindung mit anderen Systemmerkmalen verwendet, um die gegebene Aussage auszuwerten und zu verifizieren.
  • In Schritt 410 ruft das Filter 14b die Daten von Konfiguration e von der ausgewählten Spur mit Zustandsvariablen und -werten ab. In Schritt 412 ordnet ein mit dem Filter 204b in Verbindung stehendes Filterprogramm jedem Propositionssymbol entsprechend den atomaren Aussagen unter Verwendung der Werte der Variablen in jeder Konfiguration Wahrheitswerte zu (Wahr oder Falsch). Genauer gesagt betrachtet das Filter 204b die Verbindungsliste, um zu ermitteln, welcher atomare Ausdruck welchem Propositionssymbol zugeordnet ist. Die Beziehung zwischen den atomaren Ausdrücken und den Propositionssymbolen wird durch das Filter 204b in Schritt 414 verwendet, um die Spur des Systems (d. h. Lauf des Systems) in eine Sequenz von Wahrheitswertzuordnungen zu den Propositionssymbolen umzuwandeln. Somit erzeugt das Filter 204b anstatt einer Spur, die an Variablen ausgeführt wird, die in einer formellen Sprache ausgedrückt werden, eine Sequenz von Zuordnungen zu den Propositionssymbolen.
  • In Schritt 416 werden die Propositionsformel von Schritt 408 und die Spur an Wahrheitszuordnungen zu den Propositionssymbolen von Schritt 414 in einen Spurverifizierer 204d eingegeben, um formell zu verifizieren, dass die Spur der in der Spezifikation ausgeführten Aussage genügt. In Schritt 418 gibt der Spurverifizierer das Ergebnis der Spur aus.
  • Wieder auf 7 Bezug nehmend ermittelt der Algorithmus 300 in Schritt 420, ob das Ergebnis des Aussagemonitors von Schritt 418 ”wahr” ist, was bedeutet, dass der Spurverifizierer 204d die Spur hinsichtlich der Spezifikation für die gegebene Aussage verifizieren konnte. Wenn dies der Fall ist, das Ergebnis ”wahr” ist, gibt das System in Schritt 422 ein ”Wahr”-Statement aus. Wenn das Ergebnis nicht ”wahr” ist, ermittelt der Algorithmus 300 in Schritt 424, ob das Ergebnis ”Falsch” ist. Wenn ein falsches Ergebnis ermittelt wird, gibt das System in Schritt 426 ein ”Falsch”-Statement aus. Wenn das Ergebnis nicht falsch ist, wird die aktuelle Aussage in Schritt 428 aktualisiert, indem eine Information bezüglich der Auswertung aufgezeichnet wird. Wenn ein Ergebnis weder wahr noch falsch ist, ist dies ein Hinweis für das System, dass eine weitere Verarbeitung und Auswertung der Zustände abgeschlossen werden muss.
  • Es ist zu verstehen, dass die obige Beschreibung darstellend und nicht einschränkend sein soll. Für Fachleute würden beim Lesen der obigen Beschreibung viele andere alternative Ansätze oder Anwendungen als die bereitgestellten Beispiele ersichtlich werden. Der Schutzumfang der Erfindung sollte nicht in Bezug auf die obige Beschreibung festgelegt werden, sondern sollte stattdessen in Bezug auf die beigefügten Ansprüche zusammen mit dem vollen Umfang an Äquivalenten, die diese Ansprüche einschließen, festgelegt werden. Es wird erwartet und es ist vorgesehen, dass weitere Entwicklungen in der hierin erläuterten Technik auftreten und dass die offenbarten Systeme und Verfahren in solche weiteren Beispiele einbezogen werden. Zusammengefasst ist zu verstehen, dass die Erfindung abgewandelt und verändert werden kann und lediglich durch die folgenden Ansprüche eingeschränkt ist.
  • Die vorliegenden Ausführungsformen wurden speziell gezeigt und beschrieben, welche lediglich die geeignetsten Ausführungsformen darstellen. Fachleute werden erkennen, dass verschiedene Alternativen der hierin beschriebenen Ausführungsformen beim Ausführen der Ansprüche eingesetzt werden können, ohne von dem Gedanken und Schutzumfang der Erfindung abzuweichen, und dass das Verfahren und das System in dem Schutzumfang dieser Ansprüche und ihre Äquivalente dadurch abgedeckt sind. Diese Beschreibung sollte als alle neuen und nicht offensichtlichen Kombinationen von hierin beschriebenen Elementen umfassend betrachtet werden, und es können in dieser oder einer späteren Anmeldung Ansprüche bezüglich jeder neuen und nicht offensichtlichen Kombination dieser Elemente dargestellt werden. Ferner sind die vorstehenden Ausführungsformen erläuternd, und kein einzelnes Merkmal oder Element ist für alle möglichen Kombinationen wesentlich, die in dieser oder einer späteren Anmeldung beansprucht sein können.
  • Alle in den Ansprüchen verwendeten Begriffe sollen als ihren breitesten vernünftigen Aufbau und ihre übliche Bedeutung wie durch Fachleute verstanden umfassend betrachtet werden, wenn nicht hierin ein ausdrücklicher Hinweis auf das Gegenteil gegeben wird. Insbesondere sollte die Verwendung der Singularartikel, wie beispielsweise ”ein/eine”, ”der/die/das” etc. als eines oder mehrere der angegebenen Elemente bezeichnend gelesen werden, wenn nicht ein Anspruch eine explizite Einschränkung auf das Gegenteil bezeichnet.

Claims (10)

  1. Verfahren zum Verifizieren eines ausführbaren Systems hinsichtlich einer Aussage in einer Spezifikation, wobei das Verfahren die Schritte umfasst, dass: eine Propositionsformel, die eine Aussage in der Spezifikation darstellt, unter Verwendung Boolscher Propositionen erzeugt wird, wobei jede Boolsche Proposition mit einer atomaren Aussage in der Aussage in Verbindung gebracht wird; eine Spur erzeugt wird, die eine Sequenz von Konfigurationen des Systems in Bezug auf die Aussage darstellt, wobei die Spur Spurkonfigurationsdaten umfasst, die eine Konfiguration des Systems in Ansprechen auf eine bestimmte Spur darstellen; die Spurkonfigurationsdaten in Wahrheitszuordnungen für einen Satz von Propositionssymbolen umgewandelt werden; eine Spur des Systems unter Verwendung der Wahrheitszuordnungen für die Propositionssymbole erzeugt wird; und die Aussage unter Verwendung der Spur von Wahrheitszuordnungen für die Propositionssymbole und die Propositionsformel verifiziert wird.
  2. Verfahren nach Anspruch 1, wobei die Spurkonfigurationsdaten eine Sequenz von Eingängen, Zustandsvariablen, einer Zustandsinformation und Ausgangsvariablen umfassen.
  3. Verfahren nach Anspruch 1, wobei die Aussage in der Spezifikation in einer formellen Sprache geschrieben wird.
  4. Verfahren nach Anspruch 1, ferner umfassend, dass eine Verbindungsliste erzeugt wird, die die Beziehung zwischen den atomaren Aussagen und den Propositionssymbolen identifiziert.
  5. Verfahren nach Anspruch 4, wobei das Umwandeln der Spurkonfigurationsdaten in Propositionssymbole umfasst, dass die Spurkonfigurationsdaten unter Verwendung der Verbindungsliste in Boolsche Symbole umgewandelt werden.
  6. Verfahren nach Anspruch 1, wobei die Spur eine Testsammlung mit mehreren Spuren ist.
  7. Von einem Computer lesbares Medium, das konkret von einem Computer ausführbare Anweisungen umfasst zum: Erzeugen einer Propositionsformel, die eine Aussage in der Spezifikation darstellt, unter Verwendung Boolscher Propositionen, wobei jede Boolsche Proposition mit einer atomaren Aussage in der Aussage in Verbindung gebracht wird; Erzeugen einer Spur, die eine Sequenz von Konfigurationen des Systems in Bezug auf die Aussage darstellt, wobei die Spur Spurkonfigurationsdaten umfasst, die eine Konfiguration des Systems in Ansprechen auf eine bestimmte Spur darstellen; Umwandeln der Spurkonfigurationsdaten in Wahrheitszuordnungen für einen Satz von Propositionssymbolen; Erzeugen einer Spur des Systems unter Verwendung der Wahrheitszuordnungen für die Propositionssymbole; und Verifizieren der Aussage unter Verwendung der Spur von Wahrheitszuordnungen für die Propositionssymbole und die Propositionsformel.
  8. Von einem Computer lesbares Medium nach Anspruch 7, wobei die Spurkonfigurationsdaten eine Sequenz von Eingängen, Zuständen, Zustandsvariablen und Ausgangsvariablen umfassen.
  9. Von einem Computer lesbares Medium nach Anspruch 7, ferner umfassend, dass eine Verbindungsliste erzeugt wird, die die Beziehung zwischen den atomaren Aussagen und den Propositionssymbolen identifiziert.
  10. Von einem Computer lesbares Medium nach Anspruch 9, wobei das Umwandeln der Spurkonfigurationsdaten in Wahrheitszuordnungen für einen Satz von Propositionssymbolen umfasst, dass die Spurkonfigurationsdaten unter Verwendung der Verbindungsliste in Wahrheitszuordnungen für Boolsche Symbole umgewandelt werden.
DE102010047954A 2009-10-14 2010-10-08 Formelle offline-Verifikation ausführbarer Modelle Withdrawn DE102010047954A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/579,141 US8412668B2 (en) 2009-10-14 2009-10-14 Offline formal verification of executable models
US12/579,141 2009-10-14

Publications (1)

Publication Number Publication Date
DE102010047954A1 true DE102010047954A1 (de) 2011-06-22

Family

ID=43855833

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102010047954A Withdrawn DE102010047954A1 (de) 2009-10-14 2010-10-08 Formelle offline-Verifikation ausführbarer Modelle

Country Status (3)

Country Link
US (1) US8412668B2 (de)
CN (1) CN102298549B (de)
DE (1) DE102010047954A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8453119B2 (en) * 2009-10-14 2013-05-28 GM Global Technology Operations LLC Online formal verification of executable models
CN111767739B (zh) * 2020-05-26 2024-01-23 西安电子科技大学 一种基于pptl3的微信群在线监控方法及系统
US11231498B1 (en) 2020-07-21 2022-01-25 International Business Machines Corporation Concealed object detection

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6247146B1 (en) * 1998-08-17 2001-06-12 Advanced Micro Devices, Inc. Method for verifying branch trace history buffer information
US6738955B2 (en) * 2000-11-30 2004-05-18 International Business Machines Corporation Method and system for formal characterization of average performance
US7584079B2 (en) * 2000-12-08 2009-09-01 Configit Software A/S Method of configuring a product
EP1410228B1 (de) * 2001-06-22 2016-03-23 Wonderware Corporation Fernüberwachung bzw. diagnose verteilter komponenten einer überwachungsprozesssteuer- und herstellungsinformationsanwendung von einem zentralen ort aus
US7519953B2 (en) * 2003-09-30 2009-04-14 Microsoft Corporation Method and system for automatically testing a software build
US7487076B2 (en) * 2003-10-31 2009-02-03 The Mathworks, Inc. Simplified data signal support for diagramming environment languages
GB0407657D0 (en) * 2004-04-03 2004-05-05 Ibm Symbolic model checking of software
US7260501B2 (en) * 2004-04-21 2007-08-21 University Of Connecticut Intelligent model-based diagnostics for system monitoring, diagnosis and maintenance
WO2006007621A2 (de) * 2004-07-22 2006-01-26 Avl List Gmbh Verfahren zur untersuchung des verhaltens von komplexen systemen, insbesondere von brennkraftmaschinen
US7725874B2 (en) * 2004-08-13 2010-05-25 National Instruments Corporation Combination structure nodes for a graphical program
JPWO2006038394A1 (ja) * 2004-10-04 2008-05-15 松下電器産業株式会社 ソースコード検査器、方法、プログラム及び記憶媒体
US20070260438A1 (en) * 2006-05-08 2007-11-08 Langer William J Vehicle testing and simulation using integrated simulation model and physical parts
US20070266349A1 (en) * 2006-05-09 2007-11-15 Craig Jesse E Directed random verification
US8024691B2 (en) * 2006-09-28 2011-09-20 Mcgill University Automata unit, a tool for designing checker circuitry and a method of manufacturing hardware circuitry incorporating checker circuitry
US8005661B2 (en) * 2007-05-07 2011-08-23 Nec Laboratories America, Inc. Modeling and verification of concurrent systems using SMT-based BMC
US8453119B2 (en) * 2009-10-14 2013-05-28 GM Global Technology Operations LLC Online formal verification of executable models
US20110208501A1 (en) * 2010-02-25 2011-08-25 Gm Global Technology Operations, Inc. Functional test generation through model inversion
US8589898B2 (en) * 2010-03-29 2013-11-19 GM Global Technology Operations LLC Method and apparatus for analyzing software including a calibrated value
US8584108B2 (en) * 2010-03-29 2013-11-12 GM Global Technology Operations LLC Method and apparatus for analyzing software

Also Published As

Publication number Publication date
CN102298549B (zh) 2014-08-27
US20110088017A1 (en) 2011-04-14
CN102298549A (zh) 2011-12-28
US8412668B2 (en) 2013-04-02

Similar Documents

Publication Publication Date Title
DE60017457T2 (de) Verfahren zur isolierung eines fehlers in fehlernachrichten
DE102018003142A1 (de) Automatische Einstellung von Multitasking-Konfigurationen für ein Codeprüfsystem
DE102006050112A1 (de) Verfahren zur Erstellung einer Anforderungsbeschreibung für ein eingebettetes System
DE102014008551A1 (de) Softwareevaluierungsvorrichtung und -Verfahren
AT521713B1 (de) Verfahren zur Detektion sicherheitsrelevanter Datenflüsse
EP3451202B1 (de) Verfahren zum erzeugen eines auf einem testgerät ausführbaren modells eines technischen systems und testgerät
DE102011011951A1 (de) Anforderungsgetriebener Merkmalsentwicklungsprozess
DE102018116911A1 (de) Verfahren zur Erzeugung von Quellcode
EP3047341B1 (de) System zum rechnergestützten erstellen von regeln zur überwachung und/oder diagnose einer technischen anlage
DE102010033861A1 (de) Auf einer formellen Analyse basierte Entwicklung von Anforderungsspezifikationen
DE102011012068A1 (de) Begriffsverwaltungssystem (tms)
DE10038499A1 (de) Verfahren und System für die verbesserte Entwicklungsprüfung mittels angepasster Ablaufverfolgung
DE102010047954A1 (de) Formelle offline-Verifikation ausführbarer Modelle
DE102021116315A1 (de) Verfahren zum Zusammenführen von Architekturinformationen
DE102011011490A1 (de) Funktionstestgenerierung mittels Modellinversion
DE202016008006U1 (de) Generierung von Integrationstests im Kleinen
EP3232327A1 (de) Verfahren zum testen eines steuerprogramms eines steuergeräts in einer simulationsumgebung auf einem rechner
DE102019008598A1 (de) Identifikation und Visualisierung von Assoziationen zwischen Code, der von einem Modell generiert ist, und Quellen, welche die Codegeneration beeinflussen
US9152385B2 (en) Systems and methods for generating high-quality formal executable software feature requirements
DE102010047957A1 (de) Formelle online-Verifikation ausführbarer Modelle
DE102011012071A1 (de) Anforderungseinbringungs-/-auslesewerkzeug, genannt r2db
DE102021207872A1 (de) Kompositionelle verifikation von eingebetteten softwaresystemen
DE102020213809A1 (de) Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts und Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts
DE102020206327A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
EP3933593A1 (de) Verfahren und computerprogramm zum testen eines technischen systems

Legal Events

Date Code Title Description
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20130501