Wie können wir wissen, dass formale Methoden funktionieren?

Ein wichtiges Ziel formaler Methoden ist es, die Korrektheit von Systemen entweder automatisiert oder durch den Menschen zu beweisen. Es scheint jedoch, dass Sie möglicherweise NICHT garantieren können, dass das System nicht ausfällt, auch wenn Sie einen Korrektheitsnachweis erbringen können. Beispielsweise:

• Die Spezifikation modelliert das System möglicherweise nicht richtig, oder das Modell eines Produktionssystems ist möglicherweise zu kompliziert, oder das System weist aufgrund widersprüchlicher Anforderungen von Natur aus Fehler auf. Welche Techniken sind bekannt, um zu testen, ob eine Spezifikation überhaupt Sinn macht?
• Der Proofprozess kann auch fehlerhaft sein! Wer weiß, dass diese Inferenzregeln korrekt und legitim sind? Außerdem können Beweise sehr umfangreich sein, und woher wissen wir, dass sie keine Fehler enthalten? Dies ist das Herzstück der Kritik in de Millo, Lipton und Perlis '"Sozialen Prozessen und Beweisen von Theoremen und Programmen". Wie reagieren moderne formale Methodenforscher auf diese Kritik?
• Zur Laufzeit gibt es viele nicht deterministische Ereignisse und Faktoren, die das System ernsthaft beeinflussen können. Kosmische Strahlung kann beispielsweise den Arbeitsspeicher auf unvorhersehbare Weise verändern, und wir können im Allgemeinen nicht garantieren, dass die Hardware keine byzantinischen Fehler aufweist, gegen die Lamport nachweislich nur sehr schwer robust ist. Die Korrektheit des statischen Systems garantiert also nicht, dass das System nicht ausfällt! Gibt es Techniken, die dafür verantwortlich sind, dass echte Hardware nicht funktioniert?
• Derzeit ist das Testen das wichtigste Werkzeug, um sicherzustellen, dass die Software funktioniert. Es scheint, als sollte es ein komplementäres Instrument mit formalen Methoden sein. Ich sehe jedoch hauptsächlich Forschung, die sich entweder auf formale Methoden oder auf das Testen konzentriert. Was ist über die Kombination der beiden bekannt?

Zu 4: Es gibt viel zu tun, um formale Methoden und Tests zu kombinieren. Das googeln von "formalen Methodentests" bringt einen ziemlichen Arbeitsaufwand mit sich. Obwohl es viele verschiedene Ziele dieser Arbeit gibt, besteht eines der Hauptziele darin, effektivere Testsuiten zu generieren. Dieser Vortrag gibt eine nette Einführung, basierend auf der Modellprüfung.

Auch in Bezug auf das Thema Softwaresicherheit , das außer Frage gestellt wurde: Formale Methoden müssen härter arbeiten, um in diesem Bereich erfolgreich zu sein. In der Regel schreibt man eine Spezifikation für eine Software und überprüft, ob die Spezifikation erfüllt ist, dh ob die Ausgabe die Nachbedingung erfüllt, wenn die Eingabe die Vorbedingung erfüllt. Um eine sichere Software zu gewährleisten, muss auch überprüft werden, ob sich die Software bei Eingaben, die die Voraussetzung nicht erfüllen, vernünftig verhält. (Dies ist natürlich gleichbedeutend damit, die Vorbedingung für alle Eingaben auf "wahr" zu setzen.) Der Platz aller Eingaben ist in der Regel viel größer als nur eine wohlgeformte Eingabe. In der Regel ist dies jedoch eine Stelle, an der selbst funktionell korrekte Software verletzt werden kann Verletzung seiner Annahmen.

Zu Punkt 3: Es wurden einige Arbeiten durchgeführt, um Systeme in Einstellungen zu überprüfen, in denen Fehler explizit modelliert werden, einschließlich Fehlerlogik: Begründen fehlertoleranter Programme. Matthew Meola und David Walker. Europäisches Symposium für Programmierung, 2010. Die Arbeiten zur probabilistischen Modellprüfung und zur probabilistischen Verifizierung befassen sich mit dem Problem der Fehler in gewissem Maße.

Ihre Punkte in der Reihenfolge:

• Die Richtigkeit aller Angaben ist letztendlich subjektiv: Sie werden wahrgenommen, um ein Problem nach Ansicht ihrer Benutzer richtig zu lösen, oder sie tun es nicht. Es gibt kein Entrinnen von Software-Entwicklung, und keine Methode hat die Silberkugel für diese.
• Es wird viel Arbeit investiert, um zu beweisen, dass der Prozess in Bezug auf seine Annahmen korrekt ist. Normalerweise stehen Experten Informationen zur Verfügung, um diese Regeln zu validieren. Jede menschliche Aktivität ist fehleranfällig, aber sehr formalisierte Systeme, die gut untersuchte Ansätze verwenden, sind wesentlich weniger fehleranfällig als fast alle anderen menschlichen Prozesse.
• Irgendwann weist jedes System einen Fehlermodus auf, der außerhalb des Bereichs dieses Systems liegt. Sie sind immer noch besser dran, alle vorhersehbaren Fehlerquellen zu beseitigen , selbst wenn Sie einige unvorhersehbare Fehlerquellen unberücksichtigt lassen.
• Testen und beweisen kann leicht koexistieren. Testen ist ein weniger spezifischer, mehr Ad-hoc- Prozess, sodass Sie möglicherweise weniger formelle Arbeit daran finden. Möglicherweise interessieren Sie sich jedoch für ein Tool wie QuickCheck , das die vom Haskell-Typensystem angebotenen Beweise durch Tests ergänzt.

Es wurde bereits gezeigt, dass formale Methoden sehr gut funktionieren. Ohne sie hätten wir die Komplexität des Entwurfs moderner digitaler Systeme (Mikroprozessoren) nicht bewältigen können.

Keine Mikroschiffe, deren Logik keiner Überprüfung der funktionalen Äquivalenz unterliegt; ohne dass die FPU der FV unterlag; ohne dass die Cache-Kohärenz-Protokolle FV unterlagen (dies ist seit 1995 der Fall).

Abgesehen von offensichtlichen Unterschieden zwischen Software und technischen physischen Systemen (z. B. Brücken, bei denen Sicherheitsfaktoren hinzugefügt werden können), spielen sie in CS die Rolle der technischen Mathematik. Die Verwendung von FM hängt jedoch immer vom Nutzen / Kosten ab. Fuzz-Tests zahlen sich bei Unternehmen wie Microsoft aus (Google SAGE auf einer Folie).

Sogar innerhalb eines Mikros gibt es Subsysteme (z. B. Mikroprozessor-Pipelines), in denen FV nicht die gleichen Auswirkungen hatte wie anderswo (z. B. FPU). In vielen Fällen wurden konventionelle Tests überhaupt nicht durchgeführt, als die formale Bewertung der symbolischen Flugbahn das Fehlen von Fehlern bewies : Kaivola et al., CAV'09).

Formale Methoden werden auch bei der Synthese von Artefakten verwendet (Code, hochwertige Tests, Zeitpläne für die optimale Entleerung von Batteriebänken, ...). Natürlich sind alle in der Frage aufgeworfenen Fragen zutreffend, und wie bei jedem anderen Einsatz von Technologie müssen falsche Anzeigen erkannt und vermieden werden.

Zu 2: Wenn das System in einem Proof-Assistenten (z. B. Twelf oder Agda oder Coq) formalisiert ist und die Eigenschaften von Solidität und Vollständigkeit überprüft werden und die Proofs in dieser Codierung erstellt werden, ist dies kein Problem. Möglicherweise haben Sie ein System formalisiert, das nicht das beschreibt, was Sie beabsichtigt haben, aber Sie haben zumindest keine falschen Beweise oder ein kaputtes System, in dem Sie argumentieren.

Es scheint jedoch, dass Sie möglicherweise NICHT garantieren können, dass das System nicht ausfällt, auch wenn Sie einen Korrektheitsnachweis erbringen können.

Ja, vielleicht gibt es keine Garantien . Formale Methoden sollen Fehler finden, beseitigen und Menschen überzeugen.

Welche Techniken sind bekannt, um zu testen, ob eine Spezifikation überhaupt Sinn macht?

Möglicherweise interessieren Sie sich für Tools zur Modellprüfung für Spezifikationen formaler Systeme .

Der Proofprozess kann auch fehlerhaft sein! Wer weiß, dass diese Inferenzregeln korrekt und legitim sind?

Ich denke (aufgrund von Goedels Unvollständigkeitssatz), dass das Zeigen eines Systems von Inferenzregeln konsistent ist, appelliert notwendigerweise an einen noch mächtigeren Satz von Inferenzregeln.

Außerdem können Beweise sehr umfangreich sein, und woher wissen wir, dass sie keine Fehler enthalten?

Hoffentlich werden große Beweise von einem kleinen Proof-Checker geprüft, der von Menschen in angemessener Zeit gelesen und verstanden werden kann. Dies wird manchmal als "de Bruijn-Kriterium" bezeichnet. Wenn Sie der Meinung sind, dass der Proof Checker keinen falschen Proof zertifiziert, müssen Sie nur den Checker überprüfen.

Gibt es Techniken, die dafür verantwortlich sind, dass echte Hardware nicht funktioniert?

Wie wäre es mit fehlertoleranter typisierter Assemblersprache ?

Ich sehe jedoch hauptsächlich Forschung, die sich entweder auf formale Methoden oder auf das Testen konzentriert. Was ist über die Kombination der beiden bekannt?

"Die TAP-Konferenz widmet sich der Konvergenz von Beweisen und Tests" .

Nur für "Beweise und Tests" googeln hat mehrere gute Treffer über der Falte.

Welche Techniken sind bekannt, um zu testen, ob eine Spezifikation überhaupt Sinn macht?

Es ist definitiv ein Urteilsspruch. In der Softwareentwicklung wurde eine sehr strenge Methodik entwickelt, um die Spezifikationen zu finden, zu schreiben und zu bestätigen. Dies geschieht durch echte Menschen und unter Verwendung eines nicht-formalen (im Sinne eines nicht-mathematischen) Prozesses, so dass es immer noch Inkonsistenzen unterliegt, aber am Ende des Tages entspricht es dem, was die Menschen überprüfen möchten, nicht mehr und nicht weniger.

Gibt es Techniken, die dafür verantwortlich sind, dass echte Hardware nicht funktioniert?

Sicher, es gibt ein Feld der Überprüfung, das als Laufzeitüberprüfung bezeichnet wird. Sie können auch die ausführungsbasierte Modellüberprüfung auf dem realen System verwenden, das in einer vollständig virtuellen Umgebung ausgeführt wird, die einem bestimmten Szenario unterliegt (dazu habe ich mich mit V-DS + APMC selbst beigetragen ). Dies ist jedoch eindeutig ein Hauptproblem, um die Interaktion zwischen dem System und der Umgebung in den Verifizierungsprozess einzubeziehen.

Ich sehe jedoch hauptsächlich Forschung, die sich entweder auf formale Methoden oder auf das Testen konzentriert. Was ist über die Kombination der beiden bekannt?

Wow, heute werde ich total schamlos sein und mich wieder zitieren. Mit den Autoren, die an der Kombination von Modellprüfung und - prüfung arbeiten, können Sie in der Publikationsliste eines ehemaligen Doktoranden unserer Gruppe nachsehen oder in einer guten Suchmaschine nach "Näherungsprüfung des probabilistischen Modells" oder "Überprüfung des statistischen Modells" suchen (Aufgabe von Younes et al., Sen et al. Oder ich et al. Und viele andere).

Vielleicht interessieren Sie sich sehr für die Arbeiten von John Rushby , einem der Designer des PVS-Theorembeweisers, der generell an genau den Punkten interessiert ist, die Sie erwähnen. Lesen Sie diesen klassischen Bericht an die FAA über die Verwendung formaler Methoden und die Zertifizierung kritischer Systeme (1993) und seine neueren Schriften über die Zusammenstellung eines probabilistischen formalen Sicherheitsnachweises aus verschiedenen Beweismitteln (Tests, Nachweise, Analysen usw.).