DE102021207872A1

DE102021207872A1 - Kompositionelle verifikation von eingebetteten softwaresystemen

Info

Publication number: DE102021207872A1
Application number: DE102021207872.9A
Authority: DE
Inventors: Andrea Flexeder; Bernard Schmidt; Maximilian Schlund; Jochen Quante
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2021-07-22
Filing date: 2021-07-22
Publication date: 2023-01-26
Also published as: CN115687071A; US11977478B2; US20230023480A1

Abstract

Ein Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zur statischen Prüfung eines Softwaresystems, das in eine Vielzahl von Softwareeinheiten zerlegt ist, wobei zwischen den Softwareeinheiten eine oder mehrere Schnittstellen vorhanden sind, wobei eine jede Schnittstelle eine jeweilige erste und eine jeweilige zweite Softwareeinheit der Vielzahl der Softwareeinheiten zumindest insofern verbindet, als die jeweilige erste Softwareeinheit mindestens eine Ausgangsvariable aufweist, die für die jeweilige zweite Softwareeinheit als mindestens eine Eingangsvariable fungiert; das Verfahren umfassend Empfangen einer Kontextinformation für mindestens eine Schnittstelle, wobei die Kontextinformation jeweils mindestens eine Nachbedingung für die mindestens eine Ausgangsvariable der jeweiligen ersten Softwareeinheit und/oder mindestens eine Vorbedingung für die mindestens eine Eingangsvariable der jeweiligen zweiten Softwareeinheit umfasst; Empfangen einer Auswahl einer dritten Softwareeinheit aus der Vielzahl der Softwareeinheiten derart, dass eine dazugehörige Ersatzzerlegung des Softwaresystems in die dritte Softwareeinheit und einem Komplement der dritten Softwareeinheit erzeugt wird, wobei die dritte Softwareeinheit und das Komplement das Softwaresystem bilden und zumindest insofern über eine Ersatzschnittstelle verbunden sind, als das Komplement mindestens eine Ausgangsvariable aufweist, die für die dritte Softwareeinheit als Eingangsvariable fungiert; Auswählen, zumindest auf Basis der für die mindestens eine Schnittstelle empfangenen Kontextinformation, mindestens einer Nachbedingung je Ausgangsvariable des Komplements, die als Eingangsvariable der dritten Softwareeinheit fungiert; und Prüfen, ob die eine oder die mehreren ausgewählten Nachbedingungen hinsichtlich einer formalen Verifikation durch die dritte Softwareeinheit vorwärts propagiert werden können.

Description

Stand der Technik
Software kann - insbesondere ab einer gewissen Komplexität - Fehler aufweisen. Eine Klasse von Fehlern wird z.B. durch Laufzeitfehler gebildet, die während der Laufzeit der Software auftreten. Laufzeitfehler können zum Absturz der Software oder zu falschem Verhalten der Software führen. Das falsche Verhalten der Software kann während der Entwicklung und/oder einem Test mitunter unentdeckt bleiben und später im Einsatz zu einem Absturz der Software führen.
In Software, insbesondere in sicherheitsrelevanter Software, sollten keine Laufzeitfehler auftreten. Tritt dennoch ein Laufzeitfehler bei der Ausführung der Software auf, kann es vorkommen, dass die Ausführung der Software zwangsläufig unterbrochen wird. Eine durch die Ausführung der Software bewirkte Funktionalität der Software kann dann nicht mehr bereitgestellt werden (z.B. wenn eine Fehlerfolge nicht von einer Redundanz in der Sicherheitsarchitektur abgefangen wird). Im Falle, dass ein Laufzeitfehler falsches Verhalten der Software hervorruft, kann die Funktionalität der Software ebenfalls gestört oder ausgehebelt werden. Laufzeitfehler können zum Beispiel dadurch entstehen, dass implizite Annahmen der Programmiersprache, in der die Software programmiert wurde, nicht eingehalten werden. Beispielsweise darf bei einer Division der Divisor nicht Null sein, oder es darf nicht auf Array-Elemente außerhalb der definierten Array-Größe zugegriffen werden. Wird dies trotzdem gemacht, so führt dies in der Regel zu undefiniertem Verhalten, zu falschen Ergebnissen und/oder zum Absturz der Software.
Software kann dafür ausgelegt sein, ein technisches System, insbesondere z.B. ein Fahrsystem, zu überwachen, zu steuern und/oder zu regeln. Die Auswirkung (z.B. die Fehlerfolge) eines Laufzeitfehlers bei der Ausführung der Software kann im Allgemeinen von vielen Faktoren abhängen (System, Umgebung, Anwendungsfälle, offener Kontext, ...). In schlimmen Fällen kann die Auswirkung (z.B. die Fehlerfolge) Unfälle, Schäden, Versehrtheit und/oder Todesfolge einschließen. Beispielsweise kann ein Laufzeitfehler mit Division durch Null zum Abbruch der Ausführung der Software führen, die dann ihre eigentliche Aufgabe (z.B. die Ansteuerung der Bremsen oder die Auslösung des Airbags) nicht mehr erfüllen kann. Ein anderes Beispiel ist das Überschreiben eines Speicherbereichs mit falschen Daten, z.B. wenn über Arraygrenzen hinaus geschrieben und damit andere Variablen, die zufällig dort liegen, unbeabsichtigt verändert werden, was zu falschem Verhalten oder gar Absturz führen kann. Technische Systeme können für den Benutzer und/oder die Umgebung des technischen Systems sicherheitskritisch sein. Die in einem solchen technischen System eingesetzte Software kann ebenfalls sicherheitskritisch sein. Software kann allerdings auch unabhängig von einem technischen System sicherheitskritisch sein.
Es sind daher - insbesondere bei sicherheitskritischer Software - Maßnahmen erforderlich, die die Abwesenheit von Fehlern in der Software sicherstellen können/sollen. Häufig werden dazu umfangreiche Tests der Software durchgeführt. Tests können jedoch nur die Anwesenheit von Fehlern aufzeigen und nicht deren Abwesenheit nachweisen, da sie immer nur bestimmte Einzelkonfigurationen bzw. -szenarien („Stichproben“) prüfen können, nicht aber das korrekte Verhalten der Software in allen Konfigurationen/Szenarien.
Es existieren Ansätze zur formalen Verifikation von Software, die die Fehlerfreiheit der Software formal nachweisen können. Häufig benötigen diese eine formale Spezifikation, die in der Regel nicht vorliegt und deren Erstellung aufwendig sein kann. Für die Klasse der Laufzeitfehler ist die formale Spezifikation allerdings generisch verfügbar. Die Ansätze zur formalen Verifikation umfassen die abstrakte Interpretation und das Model Checking. Bei der abstrakten Interpretation werden die Anweisungen des Programms auf einer abstrakten Domäne ausgeführt. Bei geeigneter Wahl der abstrakten Domäne kann damit eine gute Überapproximation des Programmverhaltens ermittelt werden. Das Model Checking prüft dagegen ein Modell des Programms gegen eine formale Spezifikation, z.B. in temporaler Logik. Bounded Model Checking (BMC) ist eine spezielle Variante des Model Checking, die nur bis zur einer gegebenen Grenze (Bound) eine gültige Aussage macht. BMC kann im Vergleich zu vielen Model Checking Ansätzen besser automatisiert einsetzbar sein.
Es existieren mehrere kommerzielle Werkzeuge (englisch: tools), die Software mit diesen Methoden auf Laufzeitfehler prüfen können (z.B. Astree von Abslnt und Polyspace CodeProver von MathWorks), sowie einige Werkzeuge aus dem universitären Bereich (z.B. CBMC der Universität Oxford). Allerdings leiden all diese Werkzeuge unter dem Problem, dass sie entweder nicht auf große Softwaresysteme skalieren oder viele falsch-positive Ergebnisse liefern. Letzteres ergibt sich häufig dadurch, dass diese Werkzeuge konservativ ausgelegt sind, um keinen Fehler zu übersehen („Soundness“), was für sicherheitsrelevante Systeme prinzipiell sinnvoll sein kann. Je komplexer jedoch das zu analysierende System ist, desto unpräziser wird die Analyse und desto mehr falsch-positive Fehlermeldungen können angezeigt werden. Falsch-positive Fehlermeldungen können z.B. Meldungen von Fehlern sein, die in Wirklichkeit niemals auftreten können. Dies liegt vor allem daran, dass bei zunehmender Komplexität des Systems nicht alle Informationen exakt vorgehalten werden können (d.h. sie müssen zusammengefasst bzw. abstrahiert werden), da anderenfalls Speicherverbrauch und Laufzeit exponentiell anstiegen und die Fehleranalyse dann nicht mehr durchgeführt werden könnte.
Werden dagegen Teile des Systems einzeln analysiert, so fehlen Informationen über deren Kontext, was ebenfalls zu vielen falsch-positiven Meldungen führt. Bei vielen falsch-positiven Meldungen, insbesondere wenn sie manuell begutachtet werden müssen, entsteht hier ein gewaltiger und häufig nicht zu bewältigender Aufwand, was den Einsatz dieser Werkzeuge im industriellen Umfeld praktisch unmöglich macht.
Häufig ist die Software ein Softwaresystem, das mehrere Softwareeinheiten umfasst, die über Schnittstellen miteinander wechselwirken können. Die Schnittstelle einer Softwareeinheit kann neben dem Funktionsaufruf und den zugehörigen Parametern auch aus dem Rückgabewert und eventuell gemeinsam genutztem Speicher bestehen. Beispielsweise kann das Softwaresystem eine Softwareeinheit A und eine Softwareeinheit B umfassen, die über eine Schnittstelle verbunden sind. Weiterhin kann zum Beispiel das Softwaresystem Softwareeinheiten C und D umfassen, die jeweils über eine Schnittstelle mit der Softwareeinheit A verbunden sind. Die Prüfung der Softwareeinheit A kann nun zum Beispiel traditionell entweder isoliert erfolgen oder ihm Kontext des gesamten Softwaresystems:

Im ersten Fall sind die Schnittstellen zu allen Seiten (z.B. zu Softwareeinheiten B, C und D) offen und es ist nichts weiter über den Kontext bekannt. Hier muss nur auf Basis der Syntax der Schnittstellen auf mögliche Verwendungsformen geschlossen werden, was allerdings viele Verwendungsmöglichkeiten einschließen kann, die niemals auftreten werden. Das wiederum hat üblicherweise viele falsch-positive (Fehler)meldungen zur Folge.

Im zweiten Fall wird das gesamte Softwaresystem zusammen geprüft. Damit ist die vollständige Kontextinformation vorhanden. Allerdings wird das Softwaresystem für reale Fälle schnell so groß, dass die Prüfung nur noch sehr oberflächlich geschehen kann, wodurch die Präzision der Analyse eingeschränkt wird. Beispielsweise können Schleifen nicht genauer analysiert werden und müssen überapproximiert werden. Dies führt üblicherweise ebenfalls zu vielen falsch-positiven (Fehler)meldungen.
Kontrakte (erstmals beschrieben 1986 von Bertrand Meyer für Eiffel, englisch: contracts; für die vertragsbasierte Programmierung), die die Schnittstelle einer Funktion oder eines Moduls genauer definieren, sind bekannt. Kontrakte umfassen spezifische Vorbedingungen, die erfüllt sein müssen, damit eine Funktion/Modul korrekt funktioniert, sowie Nachbedingungen, die die Funktion/das Modul dann zusichert. In Forschungsarbeiten wurde versucht, Kontrakte in Programmiersprachen einzubauen und statisch zu prüfen (z.B. Spec# für C# oder JML für Java, Kontrakt-Attribute in C++2x), allerdings nicht unter dem Aspekt der kompositionellen Verifikation eingebetteter Softwaresysteme. In der Praxis werden Kontrakte bis heute nur zur Laufzeit (Zusicherungen) und nicht statisch geprüft.
Der Entwickler kann Kontrakte zum Beispiel von Hand schreiben. Diese können unter anderem aus Vorbedingungen (englisch: preconditions) und Nachbedingungen (englisch: postconditions) bestehen. Vorbedingungen beschreiben dabei zusätzliche Einschränkungen auf den Eingangsvariablen bzw. dem Zustand der Software(komponente) (z.B. Funktion, Modul, Klasse, Subsystem), die erfüllt sein müssen, damit die Software(komponente) korrekt arbeitet. Nachbedingungen beschreiben entsprechend den Zustand des Systems nach Ausführung einer Komponente (z.B. Zustand der Komponente oder mögliche Rückgabewerte einer Funktion). Robuste Software sollte idealerweise keine Vorbedingungen brauchen. Allerdings kommt es häufig vor, dass Software aus Gründen der Performance, der algorithmischen Kompatibilität und der Abhängigkeiten zu anderen Komponenten nicht vollständig robust ausgelegt werden kann. Um diese Komponenten abzusichern und somit das korrekte Gesamtverhalten zu garantieren, können Kontrakte verwendet werden.
Für den industriellen Alltag hat sich das manuelle Aufschreiben von formalen Kontrakten, d.h. für jede einzelne Software-Komponente die korrekten Vorbedingungen und Nachbedingungen zu erstellen, nur für wenige kleine, extrem sicherheitskritische Systeme etabliert. Der Aufwand ist in der Regel für einen breiten Einsatz zu hoch. Hinzu kommt, dass Software meist auf einem hohen Anteil an sogenanntem „Legacy Code“ (deutsch, etwa: bereits vorhandener (d.h. alter) Programmiercode z.B. aus einem Vorgängerprojekt) basiert, der nicht regelmäßig von den Entwicklern wieder angefasst und/oder weiterentwickelt wird. Für diese Komponenten nachträglich händisch Vorbedingungen einzufügen ist in der Praxis schwierig und/oder zeitaufwendig, und somit häufig nicht realisierbar, insbesondere wenn Softwareentwickler in der Zwischenzeit z.B. die Stelle gewechselt haben und/oder das zusätzliche implizite Wissen der Softwareentwickler für den „Legacy Code“ nicht mehr zur Verfügung steht. Daher ist es vorteilhaft, automatisch Kontrakte (Vorbedingungen und/oder Nachbedingungen) aus dem Programmiercode herleiten zu können.
Offenbarung der Erfindung
Ein erster allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zur statischen Prüfung eines Softwaresystems, das in eine Vielzahl von Softwareeinheiten zerlegt ist. Zwischen den Softwareeinheiten sind eine oder mehrere Schnittstellen vorhanden, wobei eine jede Schnittstelle eine jeweilige erste und eine jeweilige zweite Softwareeinheit der Vielzahl der Softwareeinheiten zumindest insofern verbindet, als die jeweilige erste Softwareeinheit mindestens eine Ausgangsvariable aufweist, die für die jeweilige zweite Softwareeinheit als mindestens eine Eingangsvariable fungiert. Das Verfahren umfasst Empfangen einer Kontextinformation für mindestens eine Schnittstelle, wobei die Kontextinformation jeweils mindestens eine Nachbedingung für die mindestens eine Ausgangsvariable der jeweiligen ersten Softwareeinheit und/oder mindestens eine Vorbedingung für die mindestens eine Eingangsvariable der jeweiligen zweiten Softwareeinheit umfasst; Empfangen einer Auswahl einer dritten Softwareeinheit aus der Vielzahl der Softwareeinheiten derart, dass eine dazugehörige Ersatzzerlegung des Softwaresystems in die dritte Softwareeinheit und einem Komplement der dritten Softwareeinheit erzeugt wird, wobei die dritte Softwareeinheit und das Komplement das Softwaresystem bilden und zumindest insofern über eine Ersatzschnittstelle verbunden sind, als das Komplement mindestens eine Ausgangsvariable aufweist, die für die dritte Softwareeinheit als Eingangsvariable fungiert Auswählen, zumindest auf Basis der für die mindestens eine Schnittstelle empfangenen Kontextinformation, mindestens einer Nachbedingung je Ausgangsvariable des Komplements, die als Eingangsvariable der dritten Softwareeinheit fungiert; und Prüfen, ob die eine oder die mehreren ausgewählten Nachbedingungen hinsichtlich einer formalen Verifikation durch die dritte Softwareeinheit vorwärts propagiert werden können. Ein zweiter allgemeiner Aspekt der vorliegenden Offenbarung betrifft eine Softwareeinheit, die als dritte Softwareeinheit nach dem computer-implementierten Verfahren zur statischen Prüfung des Softwaresystems nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) geprüft und/oder freigegeben wurde.
Ein dritter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Softwaresystem, in dem jede Softwareeinheit der Vielzahl der Softwareeinheiten als jeweilige dritte Softwareeinheit nach dem computer-implementierten Verfahren zur statischen Prüfung des Softwaresystems nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) geprüft und/oder freigegeben wurde.
Ein vierter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Verfahren, das Bereitstellen des Softwaresystems nach dem dritten allgemeinen Aspekt (oder einer Ausführungsform davon) und, optional, Verwenden des Softwaresystems umfasst.
Das in dieser Offenbarung vorgeschlagene Verfahren nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) ermöglicht eine statische Prüfung von Softwareeinheiten des Softwaresystems und somit des gesamten Softwaresystems auf Laufzeitfehler. Zum Beispiel kann dadurch ein eingebettetes System („embedded software“) zur Überwachung, Steuerung und/oder Regelung eines technischen Systems (z.B. eines Fahrzeugs) bezüglich Laufzeitfehler verifiziert werden. Die statische Prüfung kann neben lokalen Fehlern auch Integrationsfehler finden, wobei Integrationsfehler nicht innerhalb von Softwareeinheiten, sondern an den Schnittstellen zwischen Softwareeinheiten auftreten können. Insbesondere bei Softwaresystemen einer gewissen Komplexität, wie sie zum Beispiel als eingebettetes System zur Steuerung eines technischen Systems (z.B. eines Fahrzeugs) auftreten, erweist sich üblicherweise eine frühe Prüfbarkeit schon während der Entwicklung - und nicht erst nach der Integration - als vorteilhaft, weil dann früh und insbesondere rechtzeitig Fehler korrigiert und die Funktionalität verbessert werden kann. Zum Beispiel werden Softwareeinheiten eines Softwaresystems ab einer gewissen Komplexität häufig in einem Produktentwicklungsprozess von unterschiedlichen Entwicklern mehr oder weniger zeitgleich entwickelt (und verantwortet). Ein vollständiger Test einer Version einer einzelnen Softwareeinheit im Zusammenspiel mit aktuellen Versionen aller anderer Softwareeinheiten des Softwaresystems kann aufwändig und aus logistischen Gründen sogar unmöglich sein. Über das zum Beispiel im Vorfeld vereinbarte Verhalten (z.B. Kontrakte mit Vorbedingungen für Eingangsvariablen und/oder Nachbedingungen für Ausgangsvariablen von Schnittstellen) zwischen den Softwareeinheiten des Softwaresystems kann im Verfahren nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) für eine einzelne Softwareeinheit (d.h. für die dritte Softwareeinheit) ein gewünschtes oder geplantes Verhalten aller weiteren Softwareeinheiten abstrahiert werden. Dadurch kann die einzelne Softwareeinheit unabhängig vom Entwicklungsstand der weiteren Softwareeinheiten geprüft werden. Dieses Vorgehen kann für die einzelne Softwareeinheit (d.h. für die dritte Softwareeinheit) zu verschiedenen Zeitpunkten des Entwicklungsprozesses wiederholt werden. Das Verfahren kann somit inkrementell angewendet werden. Weiterhin kann das Vorgehen auch für jede weitere Softwareeinheit des Softwaresystems wiederholt werden. Dadurch kann das gesamte Softwaresystem verifiziert werden.
Weitere Vorteile des in dieser Offenbarung vorgeschlagenen Verfahrens nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) können darin gesehen werden, dass möglichst wenige falsch-positive Fehlermeldungen erzeugt werden und das Verfahren auch auf große Software-Systemen skalieren kann. Das kann dadurch erreicht werden, dass die zu prüfende Softwareeinheit (d.h. die dritte Softwareeinheit) von den weiteren Softwareeinheiten (d.h. vom Komplement) insofern nicht gänzlich isoliert wird, als Vorbedingungen und/oder Nachbedingungen an den Schnittstellen (d.h. an der Ersatzschnittstelle) zu den weiteren Softwareeinheiten beibehalten und berücksichtigt werden. Weiterhin können auch Softwaresysteme analysiert werden, die aus heterogenen Komponenten bestehen. Eine solche Heterogenität kann z.B. aus verschiedenen Programmiersprachen, zugelieferten Black-Box-Komponenten, Künstliche-Intelligenz-Komponenten, etc. resultieren. Somit ist das Verfahren nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) prädestiniert für komplexe und/oder sicherheitsrelevante Softwaresysteme wie zum Beispiel eingebettete Systeme zur Überwachung, Steuerung und/oder Regelung eines technischen Systems (z.B. eines Fahrzeugs).
Einzelne Softwareeinheiten können unter Berücksichtigung ihres geplanten Verwendungskontextes isoliert geprüft werden, z.B. schon während ihrer Entwicklung, und insbesondere - in dem in der Praxis häufig anzutreffenden Fall - wenn noch nicht alle Softwareeinheiten des Softwaresystems verfügbar sind. Bisher kann eine Prüfung im Verwendungskontext z.B. erst ganz am Ende der Entwicklung - nach der Integration aller Einheiten - durchgeführt werden. Das ist insofern nachteilhaft, als die Behebung eines Fehlers umso teurer ist, je später er entdeckt wird. Zudem muss nach einer Änderung (z.B. nach einer Korrektur) nur die betroffene Komponente erneut geprüft werden und nicht nochmals das gesamte Softwaresystem. Das ist insbesondere bei für die Softwareeinheiten unterschiedlichen Verantwortlichkeiten und/oder Freigabemodalitäten vorteilhaft. Durch das Verfahren nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) können Zeiten zwischen Entdecken und Beheben von Fehlern sowie ggf. erneutem Freitesten verkürzt werden und somit die Qualität des Softwaresystems verbessert werden.
Die Ergebnisse der isolierten Prüfung von Softwareeinheiten können dazu verwendet werden, um eine spätere Integrationsanalyse zu vereinfachen und/oder komplett zu ersetzen und so Integrationsfehler auch schon entwicklungsbegleitend und insbesondere in früheren Stadien der Entwicklung zu erkennen. Die Integrationsanalyse kann z.B. nur noch aus der Prüfung der Kompatibilität aller Kontrakte miteinander bestehen und ist somit wesentlich schneller als bisher. Bei aktuellen Werkzeugen kann sich diese Prüfung durchaus über mehrere Tage erstrecken.
Da jeweils nur einzelne Softwareeinheiten geprüft werden, ist das Verfahren nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) in der Lage, die Überprüfung in kurzer Zeit durchzuführen, ohne in ein Skalierungsproblem zu laufen.
Für die Prüfung einer einzelnen Einheit kann die Analyse sehr präzise erfolgen, da kein Skalierungsproblem auftritt. Dadurch kann die Anzahl der falsch-positiven Fehlermeldungen minimiert und der manuelle Prüfungsaufwand für diese Meldungen reduziert werden.
Durch die Abstraktion von Komponenten durch deren Kontrakte wird auch eine Analyse über die Grenzen von Programmiersprachen hinweg ermöglicht. Darüber hinaus können auch Komponenten einbezogen werden, deren Inhalt nicht als Quellcode verfügbar ist (z.B. zugelieferte Software).
Figurenliste

1 illustriert schematisch ein computer-implementiertes Verfahren zur statischen Prüfung eines Softwaresystems.
2a illustriert schematisch ein beispielhaftes Softwaresystem mit mindestens zwei Softwareeinheiten, die über eine Schnittstelle miteinander verbunden sind.
2b illustriert schematisch ein beispielhaftes Softwaresystem mit sechs Softwareeinheiten, von denen manche über Schnittstellen miteinander verbunden sind.
2c illustriert schematisch eine Ersatzzerlegung mit einer dritten Softwareeinheit und ihrem Komplement, die über eine Schnittstelle miteinander verbunden sind.
3 zeigt eine beispielhafte Ausführungsform des computer-implementierten Verfahrens zur statischen Prüfung eines Softwaresystems.
4 illustriert schematisch ein (alternatives) weiteres computer-implementiertes Verfahren zur statischen Prüfung eines Softwaresystems.

Beschreibung
Das computer-implementierte Verfahren 100, das schematisch in 1 illustriert ist, zielt auf die statische Prüfung von Softwareeinheiten eines Softwaresystems und/oder auf die statische Prüfung des Softwaresystems ab. Das Softwaresystem 10 kann zum Beispiel ein eingebettetes System (englisch: embedded system) sein und/oder dafür ausgelegt sein, in einem eingebetteten System (hier im Sinne eines Computer-Systems) implementiert zu werden. Das Softwaresystem 10 kann dafür ausgelegt sein, ein technisches System, insbesondere ein Fahrsystem, zu überwachen, zu steuern und/oder zu regeln.
Das Fahrsystem kann zum Beispiel eine Steuergerätsoftware z.B. für die Motorsteuerung sein. Das technische System, insbesondere das Fahrsystem, kann sicherheitskritisch sein. Ein eingebettetes System kann ein Computer-System - z.B. umfassend einen Prozessor, einen Speicher und Eingabe- bzw. Ausgabegeräte - sein, das in einen technischen Kontext eingebunden ist. Zum Beispiel kann das Computer-System eine dedizierte Funktionalität innerhalb eines größeren technischen Systems, insbesondere eines größeren mechatronischen Systems, haben.
Offenbart wird zunächst ein computer-implementiertes Verfahren 100 zur statischen Prüfung eines Softwaresystems 10, das in eine Vielzahl von Softwareeinheiten 20, 21, 22, 23, 24, 25 zerlegt ist. Solche Zerlegungen sind beispielhaft in 2a-b gezeigt. Die Vielzahl der Softwareeinheiten kann zum Beispiel ≥2, ≥3, ≥4, ≥5, ≥10, ≥50, ≥100, ≥1e3, ≥1e4 Softwareeinheiten umfassen. Die statische Prüfung ist im Gegensatz zu einer dynamischen Prüfung nicht darauf angewiesen, dass die Softwareeinheiten mit konkreten Werten ausgeführt werden. Das kann insofern ein Vorteil sein, als die konkrete Ausführung konkreten Input erfordert, der in der Regel allenfalls Stichprobentests abdecken kann. Zwischen den Softwareeinheiten 20-25 sind eine oder mehrere Schnittstellen vorhanden. Das bedeutet nicht, dass jede Softwareeinheit mit jeder anderen Softwareeinheit über eine Schnittstelle verbunden ist. Der eher triviale Fall, dass eine Softwareeinheit über keine Schnittstelle mit einer der weiteren Softwareeinheiten verbunden ist, ist zwar nicht ausgeschlossen aber mangels Interaktion mit den weiteren Softwareeinheiten nicht von besonderem Interesse. Dasselbe gilt für eine Gruppe von Softwareeinheiten, von denen keine über eine Schnittstelle mit einer restlichen Gruppe von Softwareeinheiten verbunden ist. In 2b ist zum Beispiel die Softwareeinheit 24 nicht über eine Schnittstelle, wohl aber über mehrere Schnittstellen und Softwareeinheiten 20, 21, 22, 23 mit der Softwareeinheit 25 verbunden. In der Zerlegung des Softwaresystems 10 kann mindestens eine Schnittstelle existieren. Eine jede Schnittstelle verbindet eine jeweilige erste und eine jeweilige zweite Softwareeinheit der Vielzahl der Softwareeinheiten 20-25 zumindest insofern, als die jeweilige erste Softwareeinheit 20, 21, 22, 23, 24 mindestens eine Ausgangsvariable 40 aufweist, die für die jeweilige zweite Softwareeinheit 20, 21, 22, 23, 25 als mindestens eine Eingangsvariable 50 fungiert. Die Begriffe erste/zweite jeweilige Softwareeinheit beziehen sich auf eine (konkrete) Schnittstelle. Zum Beispiel ist die Softwareeinheit 21 in 2b eine erste Softwareeinheit für die Schnittstelle zwischen der Softwareeinheit 21 und der Softwareeinheit 20. Für diese Schnittstelle ist die Softwareeinheit 20 eine zweite Softwareeinheit. Andererseits ist die Softwareeinheit 21 in 2b auch eine erste Softwareeinheit für die Schnittstelle zwischen der Softwareeinheit 20 und der Softwareeinheit 23, etc. Eine jeweilige zweite Softwareeinheit kann (siehe „Schnittstelle verbindet ... zumindest insofern, ...“) weiterhin mindestens eine Ausgangsvariable aufweisen, die für die jeweilige erste Softwareeinheit als mindestens eine Eingangsvariable fungiert. Eine solche Schnittstelle ist zum Beispiel in 2b zwischen den Softwareeinheiten 23 und 25 dargestellt. Zirkuläre Ringschlüsse können insofern konsistent sein, als eine oder mehrere Ausgangsvariablen von einer oder mehreren Eingangsvariablen zu einem vorherigen Rechenschritt (z.B. Interrupt) abhängt. Weiterhin kann eine Schnittstelle mehrere Eingangsvariablen und/oder Ausgangsvariablen umfassen, siehe zum Beispiel Softwareeinheiten 20, 21, 22 in 2b. Weiterhin kann jede Softwareeinheit eine oder mehrere globale Eingangsvariablen und/oder eine oder mehrere globale Ausgangsvariablen aufweisen. Solche globalen Eingangs- bzw. Ausgangsvariablen sind in 2a-c durch gestrichelte Pfeile dargestellt. Sie sind somit zugleich Eingangs- und/oder Ausgangsvariablen des Softwaresystems.
Das Verfahren 100 umfasst Empfangen 120 einer Kontextinformation für mindestens eine Schnittstelle, wobei die Kontextinformation jeweils mindestens eine Nachbedingung für die mindestens eine Ausgangsvariable 40 der jeweiligen ersten Softwareeinheit und/oder mindestens eine Vorbedingung für die mindestens eine Eingangsvariable 50 der jeweiligen zweiten Softwareeinheit umfasst. Die Kontextinformation kann zum Beispiel aus Kontrakten je Schnittstelle abgeleitet werden. Weiterhin kann das Verfahren 100 Empfangen von mindestens einer (globalen) Nachbedingung für mindestens eine globale Eingangsvariable umfassen. Eine solche (globale) Nachbedingung kann z.B. aus einer Spezifikation, insbesondere einer Sensorspezifikation, oder als eine Nachbedingung für ein noch größeres Softwaresystem, das Softwaresystem 10 umfassend, bereitgestellt werden. Weiterhin kann das Verfahren 100 Empfangen von mindestens einer Vorbedingung für mindestens eine globale Ausgangsvariable umfassen. Eine solche (globale) Vorbedingung kann wiederum z.B. aus einer Spezifikation, insbesondere einer Treiberspezifikation, oder als eine Vorbedingung für ein noch größeres Softwaresystem, das Softwaresystem umfassend, bereitgestellt werden.
Das Verfahren 100 umfasst weiterhin Empfangen 130 einer Auswahl einer dritten Softwareeinheit 20 aus der Vielzahl der Softwareeinheiten 20-25 derart, dass eine dazugehörige (d.h. zur dritten Softwareeinheit 20) Ersatzzerlegung des Softwaresystems 10 in die dritte Softwareeinheit 20 und einem (mathematisch: dem) Komplement 30 der dritten Softwareeinheit 20 erzeugt 131 wird, wobei die dritte Softwareeinheit 20 und das Komplement 30 das Softwaresystem 10 bilden und zumindest insofern über eine Ersatzschnittstelle verbunden sind, als das Komplement 30 mindestens eine Ausgangsvariable 40 aufweist, die für die dritte Softwareeinheit 20 als Eingangsvariable 50 fungiert. In anderen Worten, in der Ersatzzerlegung existiert eine Ersatzschnittstelle. Die dritte Softwareeinheit 20 ist die Softwareeinheit, die geprüft werden soll. In 2b-c wird zum Beispiel die Softwareeinheit 20 empfangen/ausgewählt 130 und die dazugehörige Ersatzzerlegung des Softwaresystems 10 gebildet, indem die Softwareeinheiten 21, 22, 23, 24, 25 ein Komplement 30 bilden, das mit der Softwareeinheit 20 über die Ersatzschnittstelle verbunden ist. Wie oben bereits dargelegt, ist der Fall, in dem die dritte Softwareeinheit nicht über eine Ersatzschnittstelle mit dem Komplement 30 verbunden ist, für die statische Prüfung nicht von Interesse. Die Existenz einer Ersatzschnittstelle impliziert die Existenz mindestens einer Schnittstelle. Umgekehrt gilt, dass die Existenz mindestens einer Schnittstelle in der Zerlegung des Softwaresystems 10 mindestens eine Ersatzzerlegung und insbesondere das Empfangen/Auswählen 130 mindestens einer dritten Softwareeinheit 20 zulässt. Eine zu einer dritten Softwareeinheit dazugehörige Ersatzzerlegung kann fiktiv sein, d.h. es ist nicht notwendigerweise erforderlich die weiteren Softwareeinheiten physikalisch (z.B. in einem Modul etc.) zu einem Komplement zu vereinigen. Stattdessen kann es (siehe nächster Schritt 140) ausreichend sein, das Komplement über seine (relevanten) Kontextinformationen zu abstrahieren. Dieser Vorgang kann auch als Herausschneiden der dritten Softwareeinheit bezeichnet werden. Die Bezeichnung „dritte Softwareeinheit“ impliziert nicht, dass es mindestens drei Softwareeinheiten geben muss. In der Tat kann zum Beispiel auch in 2a die Softwareeinheit 20 als dritte Softwareeinheit empfangen/ausgewählt 130 werden und die dazugehörige Ersatzzerlegung mit einem Komplement 30 bestehend aus der Softwareeinheit 24 erzeugt 131 werden. Das Empfangen 130 kann zum Beispiel Auswählen über eine Benutzerschnittstelle einer Programmier- und/oder Integrationsumgebung umfassen und somit von einer Eingabe eines Nutzers (z.B. eines Programmierers) abhängig gemacht werden. Alternativ kann das Empfangen 130 ein automatisiertes Auswählen sein. Zum Beispiel kann das automatisierte Auswählen ein Unterschritt in einer Schleife über mehrere (z.B. nur die im eigenen Verantwortungsbereich) und/oder alle (dritten) Softwareeinheiten der Zerlegung des Softwaresystems 10 sein. In einer solchen Auswahl kann implizit eine Prüfung enthalten sein, ob eine Ersatzzerlegung mit Ersatzschnittstelle möglich ist. In einer solchen Schleife kann somit jede Softwareeinheit des Softwaresystems 10 und somit das gesamte Softwaresystem 10 statisch geprüft werden.
Das Verfahren 100 umfasst weiterhin Auswählen 140, zumindest auf Basis der für die mindestens eine Schnittstelle empfangenen 120 Kontextinformation, mindestens einer Nachbedingung je Ausgangsvariable 40 des Komplements 30, die als Eingangsvariable 50 der dritten Softwareeinheit 20 fungiert. Weiterhin kann das Verfahren 100 Auswählen mindestens einer (globalen) Nachbedingung für mindestens eine globale Eingangsvariable umfassen. Das Verfahren 100 kann Auswählen je mindestens einer Nachbedingung (global oder lokal) für jede Eingangsvariable (global oder lokal) der dritten Softwareeinheit 20 umfassen. Eine nicht globale Nachbedingung - d.h. eine Nachbedingung, die nicht einer globalen Eingangsvariablen zugeordnet ist, sondern einer Ausgangsvariable einer Softwareeinheit des Softwaresystems - kann als lokale Nachbedingung bezeichnet werden. Eine nicht globale Vorbedingung - d.h. eine Vorbedingung, die nicht einer globalen Ausgangsvariablen zugeordnet ist, sondern einer Eingangsvariable einer Softwareeinheit des Softwaresystems - kann als lokale Eingangsbedingung bezeichnet werden. Das Auswählen (z.B. 140) kann sich unmittelbar aus der Topologie der Zerlegung des Softwaresystems in Softwareeinheiten und Schnittstellen bzw. aus der Topologie der Ersatzzerlegung des Softwaresystems in die dritte Softwareeinheit und dessen Komplement ergeben.
Das Verfahren 100 umfasst weiterhin Prüfen 150, ob die eine oder die mehreren ausgewählten 140 Nachbedingungen (und/oder die eine oder die mehreren ausgewählten globalen Nachbedingungen) hinsichtlich einer formalen Verifikation (z.B. fehlerlos) durch die dritte Softwareeinheit 20 vorwärts propagiert 151 werden können. Die formale Verifikation kann zum Beispiel darin bestehen, dass keine Laufzeitfehler auftreten dürfen. Das Prüfen 150 kann dann ein Prüfen sein, ob die ausgewählten Nachbedingungen (global und/oder lokal) von den Eingangsvariablen der dritten Softwareeinheit 20 bis zu mindestens einem Ende der dritten Softwareeinheit 20 vorwärts propagiert werden können, ohne dass ein Laufzeitfehler auftreten kann. Könnte ein Laufzeitfehler auftreten, fällt das Prüfen 150 negativ aus. Anderenfalls fällt das Prüfen 150 positiv (d.h. erfolgreich) aus. In anderen Worten das Vorwärtspropagieren 151 wird gestartet und läuft im positiven Fall bis zu dem mindestens einen Ende der dritten Softwareeinheit 20 durch. Im negativen Fall dagegen wird das Vorwärtspropagieren 151 abgebrochen und das mindestens eine Ende der dritten Softwareeinheit 20 kann nicht erreicht werden. Entgegen der Darstellung in 1 kann ein negatives Ergebnis (ebenso wie ein positives) zum Beispiel über eine Benutzerschnittstelle dem Nutzer zurückgespielt werden. Alternativ oder zusätzlich kann zum Beispiel das Prüfen 150 ein Prüfen umfassen, ob alle Zusicherungen in der dritten Softwareeinheit 20 beim Vorwärtspropagieren von den Eingangsvariablen der dritten Softwareeinheit 20 bis zu mindestens einem Ende der dritten Softwareeinheit 20 eingehalten werden können. Andere Kriterien für die formale Verifikation sind möglich. Die Reihenfolge der Schritte in 1 ist exemplarisch. Zum Beispiel kann Schritt 120 auch nach Schritt 130 erfolgen und weiterhin mit dem Schritt 140 zusammenfallen. Die dargestellte Abfolge kann vorteilhaft sein, wenn eine Schleife über mehrere dritte Softwareeinheiten erfolgen soll. Dann nämlich muss Schritt 120 nur einmal erfolgen und nicht wiederholt werden.
Die dritte Softwareeinheit 20 und das Komplement 30 können, beispielhaft in 2c dargestellt, zumindest auch insofern verbunden sein, als die dritte Softwareeinheit 20 mindestens eine Ausgangsvariable 41 aufweist, die für das Komplement 30 als Eingangsvariable 51 fungiert (z.B. für den nächsten Berechnungsschritt). Das Verfahren 100 kann weiterhin Auswählen 141, zumindest auf Basis mindestens einer Kontextinformation (d.h. einer Kontextinformation einer weiteren Schnittstelle), mindestens einer Vorbedingung je Eingangsvariable 51 des Komplements 30, die durch eine Ausgangsvariable 41 der dritten Softwareeinheit 20 bedatet wird, umfassen. Weiterhin kann das Verfahren 100 Auswählen mindestens einer (globalen) Vorbedingung für mindestens eine globale Ausgangsvariable umfassen. Das Verfahren 100 kann Auswählen je mindestens einer Vorbedingung (global oder lokal) für jede Ausgangsvariable (global oder lokal) der dritten Softwareeinheit 20 umfassen. Das Auswählen (z.B. 141) kann sich unmittelbar aus der Topologie der Zerlegung des Softwaresystems in Softwareeinheiten und Schnittstellen bzw. aus der Topologie der Ersatzzerlegung des Softwaresystems in die dritte Softwareeinheit und dessen Komplement ergeben.
Das Verfahren 100 kann weiterhin Prüfen 152, ob die eine oder die mehreren ausgewählten 140 und hinsichtlich der formalen Verifikation durch die Softwareeinheit vorwärts propagierten 151 Nachbedingungen die eine oder mehreren ausgewählten 141 Vorbedingungen je Eingangsvariable 51 des Komplements 30 erfüllen, umfassen. Alternativ oder zusätzlich kann das Verfahren 100 Prüfen, ob die ausgewählten (z.B. 140) und hinsichtlich der formalen Verifikation durch die Softwareeinheit vorwärts propagierten (z.B. 151) globalen und/oder lokalen Nachbedingungen die eine oder mehreren ausgewählten 141 Vorbedingungen je Eingangsvariable 51 des Komplements und/oder die eine oder mehreren ausgewählten globalen Vorbedingungen erfüllen, umfassen. Das Prüfen 152 kann negativ oder positiv (d.h. erfolgreich) ausfallen. Entgegen der Darstellung in 1 kann ein negatives Ergebnis (ebenso wie ein positives) zum Beispiel über eine Benutzerschnittstelle dem Nutzer zurückgespielt werden.
Das Verfahren 100 kann dafür ausgelegt sein, Laufzeitfehler in Softwareeinheiten 20-25 und/oder im Softwaresystem 10 zu erkennen. In der Tat können negative Prüfergebnisse dem Benutzer zum Beispiel über eine Benutzerschnittstelle einer Programmier- und/oder Integrationsumgebung zurückgespielt werden. Dadurch kann der Benutzer zum Beispiel Maßnahmen einleiten, die Abhilfe schaffen und bei erneuter Prüfung 150, 152 ein positives Prüfergebnis bewirken. Letzteres kann für eine Freigabe der dritten Softwareeinheit 20 und/oder des gesamten Softwaresystems 10 erforderlich sein. Abhilfe kann zum Beispiel dadurch geschaffen werden, dass ein Programmiercode der dritten Softwareeinheit geändert und/oder korrigiert wird, und zum Beispiel dadurch ein gefundener Laufzeitfehler vermieden wird.
Das Vorwärtspropagieren 151 der einen oder mehreren erzeugten 140 Nachbedingungen und/oder die eine oder die mehreren ausgewählten globalen Nachbedingungen durch die dritte Softwareeinheit 20 kann auf abstrakter Berechnung basieren. Die abstrakte Berechnung kann ganz oder teilweise analytisch (d.h. nicht-konkret) sein. Die abstrakte Berechnung muss somit nicht von konkretem Input abhängen. Im Gegensatz zu konkretem Input, der zum Beispiel nur Stichprobentests abdecken würde, weil nicht alle konkreten Inputkonfigurationen (in einer vorgegebenen Zeit) realisiert werden können, kann eine analytische Berechnung auch Wertebereiche (auch: Domänen) von Input erfassen und bewerten. Durch die abstrakte Berechnung kann die Rechenzeit reduziert werden. Zum Beispiel kann bei einer Division im Programmiercode (in bestimmten Fällen) analytisch berechnet werden, wann der Divisor null ist. Daraus kann dann eine oder mehrere Bedingungen an den Input ermittelt werden, die verhindern, dass es zu einer Division durch Null kommen kann. Alternativ oder zusätzlich kann das Vorwärtspropagieren 151 auf einer konkreten Berechnung basieren. Zum Beispiel kann das Vorwärtspropagieren 151 mitunter auf probabilistischem Input (z.B. für eine oder mehrere globale Ausgangsvariablen) ä la Monte Carlo basieren. Dadurch können zum Beispiel externe Einflüsse, insbesondere Sensoreinflüsse, zumindest probabilistisch mitberücksichtigt werden.
Das Verfahren 100 kann weiterhin umfassen: Freigeben 160 der dritten Softwareeinheit 20, wenn das Prüfen 150, ob die eine oder die mehreren ausgewählten 140 Nachbedingungen hinsichtlich der formalen Verifikation durch die dritte Softwareeinheit vorwärts propagiert 151 werden können, positiv ausfällt. Das Verfahren 100 kann weiterhin umfassen: Freigeben 161 der dritten Softwareeinheit 20, wenn das Prüfen 152, ob die eine oder die mehreren ausgewählten 140 und hinsichtlich der formalen Verifikation durch die Softwareeinheit vorwärts propagierten 151 Nachbedingungen die eine oder mehreren ausgewählten 141 Vorbedingungen je Eingangsvariable 51 des Komplements 30 der dritten Softwareeinheit 20 erfüllen, positiv ausfällt. Eine solche Freigabe 160, 161 kann zum Beispiel als Nachweis in Fällen der Produkthaftung verwendet werden.
Weiterhin kann mindestens eine weitere dritte Softwareeinheit 21 der Vielzahl der Softwareeinheiten 20-25 ausgewählt und analog zur dritten Softwareeinheit 20 geprüft 150, 152 und/oder freigegeben 160, 161 werden. Dadurch kann eine Schleife über mehrere und/oder alle zu prüfenden Softwareeinheiten realisiert werden. Somit kann ein Teil und/oder das gesamte Softwaresystem 10 geprüft und schlussendlich freigegeben werden. Eine solche optionale Schleife ist in 1 schematisch durch den gestrichelten Pfeil von Schritt 160/161 zu Schritt 130/131 dargestellt.
Das Verfahren 100 kann Zerlegen 110 des Softwaresystems 10 in die Vielzahl der Softwareeinheiten 20-25 umfassen. Das Zerlegen 110 kann zum Beispiel automatisiert z.B. nach der Struktur der Speicherung, der Dateien, der Funktionen, der Module, der Klassen, und/oder der Subsysteme erfolgen. Alternativ oder zusätzlich können größere Teile zum Beispiel durch code clustering in kleinere Softwareeinheiten zerlegt werden. Alternativ oder zusätzlich kann das Zerlegen 110 des Softwaresystems 10 in die Vielzahl der Softwareeinheiten 20-25 auf mindestens einer Eingabe eines Benutzers (z.B. eines Programmierers und/oder eines Verantwortlichen für die Validierung/Verifikation) via eine Benutzerschnittstelle einer Programmier- und/oder Integrationsumgebung basieren. Wie in 1 schematisch illustriert, kann das Zerlegen dem Schritt 120 und/oder einer möglichen Schleife über mehrere dritte Softwareeinheiten vorgeschaltet sein.
Das Empfangen 120 einer Kontextinformation für eine Schnittstelle zwischen einer ersten und einer zweiten Softwareeinheit kann Auslesen 121a mindestens einer Nachbedingung für die mindestens eine Ausgangsvariable 40 der ersten Softwareeinheit und/oder Auslesen 121b mindestens einer Vorbedingung für die mindestens eine Eingangsvariable 50 der zweiten Softwareeinheit aus einer Annotation, insbesondere aus einer Spezifikation, umfassen. Das kann zum Beispiel der Fall sein, wenn die Zerlegung des Softwaresystems 10 bereits existiert bzw. festgelegt ist.
Alternativ oder zusätzlich kann das Empfangen 120 einer Kontextinformation für eine Schnittstelle zwischen einer ersten und einer zweiten Softwareeinheit Erzeugen 122a mindestens einer Nachbedingung für die mindestens eine Ausgangsvariable 40 der ersten Softwareeinheit und/oder Erzeugen 122b mindestens einer Vorbedingung (z.B. durch Rückwärtspropagation und abstrakte Berechnung) für die mindestens eine Eingangsvariable 50 der zweiten Softwareeinheit umfassen. Das Erzeugen 122a der mindestens einen Nachbedingung für die mindestens eine Ausgangsvariable 40 der ersten Softwareeinheit kann auf mindestens einer weiteren Vorbedingung für mindestens eine weitere Eingangsvariable der ersten Softwareeinheit basieren. Das Erzeugen 122b der mindestens einen Vorbedingung für die mindestens eine Eingangsvariable 50 der zweiten Softwareeinheit kann auf mindestens einer weiteren Nachbedingung für mindestens eine weitere Ausgangsvariable basieren.
Unter „formaler Verifikation“ kann der formale Nachweis der Korrektheit bzw. Fehlerhaftigkeit einer Softwareeinheit bzw. eines Softwaresystems bezüglich einer formalen Spezifikation, mittels automatischer Beweisverfahren wie zum Beispiel Abstrakter Interpretation oder Bounded Model Checking verstanden werden.
Nach den in dieser Offenbarung vorgeschlagenen Verfahren 100, 200 können formale Verifikationsmethoden auf große Softwaresysteme anwendbar gemacht werden, indem das Softwaresystem in kleine Softwareeinheiten (z.B. Subsysteme, Komponenten, Module, Funktionen) zerlegt/zerschnitten wird und die entstehenden (offenen) Schnittstellen zu abhängigen Softwareeinheiten durch Kontextinformation - aus sogenannten Kontrakten - angereichert werden. Diese Kontextinformation kann aus mindestens einer Vorbedingung, die für die Softwareeinheit gelten muss, damit sie fehlerfrei ausgeführt werden kann, sowie mindestens einer Nachbedingung, die die Softwareeinheit nach Ausführung zusichert, wenn ihre eine oder mehreren Vorbedingungen erfüllt waren. Diese Informationen können schon während der Entwicklung manuell annotiert worden sein oder auch automatisch durch Codeanalyse aus dem Code gewonnen werden. Die Kontextinformation einer zu analysierenden Softwareeinheit sowie die entsprechende Information der abhängigen Softwareeinheiten kann dann genutzt werden, um diese Softwareeinheit zu analysieren. Durch die kleineren Softwareeinheiten und/oder das zusätzliche Kontextwissen an den Schnittstellen kann die Präzision der Analyse erhöht und somit falsch-positive Fehlermeldungen reduziert werden. Für die eigentliche Prüfung der kleineren Softwareeinheiten können bereits existierende Werkzeuge zur formalen Verifikation (beispielsweise die oben genannten) verwendet werden, wenn der zu prüfende Programmiercode vorher geeignet aufbereitet wird.
3 zeigt eine beispielhafte Ausführungsform des computer-implementierten Verfahrens zur statischen Prüfung eines Softwaresystems.
Im ersten Schritt kann hier das Softwaresystem in kleinere Softwareeinheiten (in 3 abgekürzt: Einheiten) zerlegt werden. Dann kann jede dieser Softwareeinheiten separat durch Kontraktinformationen der abhängigen Softwareeinheiten ergänzt und anschließend formal verifiziert werden. Wenn alle Softwareeinheiten erfolgreich verifiziert wurden, ist damit auch das (gesamte) Softwaresystem 10 verifiziert.
Die Zerteilung des Softwaresystems in kleinere Softwareeinheiten kann anhand natürlich vorhandener Strukturen, wie Funktionen, Module, Klassen, Subsysteme erfolgen. Alternativ kann sie auch durch Bildung anderer Strukturen erfolgen, die z.B. bezüglich Breite der Schnittstellen optimiert sind (Clustering).
Aus dem Softwaresystem kann jeweils eine zu prüfende Softwareeinheit herausgeschnitten werden. Ihre abhängigen Softwareeinheiten (z.B. aufgerufene Funktionen, globale Variablen, etc.) können durch deren Kontrakte (siehe 2c) ersetzt werden. Dadurch kann das Verhalten der abhängigen Softwareeinheiten in abstrahierter Form berücksichtigt werden, was dazu führt, dass die Analyse des Verhaltens der zu prüfenden Softwareeinheit (z.B. die dritte Softwareeinheit 20) präziser durchgeführt und damit die Anzahl der falsch-positiven (Fehler)meldungen reduziert werden kann.
Beispielsweise könnte eine verwendete Softwareeinheit 24, 30 einen Wert liefern, der in der zu prüfenden Softwareeinheit 20 als Divisor verwendet wird. Wenn der Kontrakt für die Softwareeinheit 24, 30 zusichert, dass sie immer Werte ungleich Null liefert, kann eine Division durch Null an der entsprechenden Stelle in der Softwareeinheit 20 ausgeschlossen werden. Fehlt dieses Wissen, dann würde die Analyse einen falsch-positiven Fehler melden, der dann nur mit manueller Inspektion ausgeschlossen werden kann.
Weiterhin kann eine Integrationsprüfung (wie auch z.B. in den Verfahren 200) durchgeführt werden:

Die Einhaltung der Vorbedingungen (des Kontrakts) der verwendeten Softwareeinheiten kann direkt im Rahmen der Prüfung der Softwareeinheit erfolgen. Dazu können an der Schnittstelle der verwendeten Softwareeinheiten die übergebenen Daten auf Einhaltung ihres Kontrakts geprüft werden.
Alternativ kann die Integrationsprüfung auch nachgelagert erfolgen. Dazu müssen die an den jeweiligen Schnittstellen vorliegenden Daten gesammelt, aggregiert und dann gegen die Kontrakte der jeweiligen Zielsoftwareeinheiten (z.B. die mit den Eingangsvariablen) geprüft werden. Wenn eine Softwareeinheit oder ein Kontrakt geändert wird, so sind nur die entsprechende Softwareeinheit sowie deren Nachbarn erneut zu prüfen. Der Rest des Systems bleibt davon unberührt.
Eine mögliche Umsetzung verwendet existierende Prüfwerkzeuge zur Prüfung der Softwareeinheiten. Die Kontrakte werden dann mit den unterstützten Sprachmitteln dieser Werkzeuge umgesetzt. Dazu kommen die jeweiligen Direktiven zum Setzen von Wertebereichen oder sonstigem Wissen über Variablen sowie die Direktiven zur Prüfung von Bedingungen (z.B. assert()) zum Einsatz. Damit kann für jede von der zu prüfenden Softwareeinheit verwendete Softwareeinheit bei ihrem Aufruf die Gültigkeit ihrer Vorbedingungen geprüft (z.B. assert precondition) sowie die Gültigkeit ihrer Nachbedingungen sichergestellt werden (z.B. durch entsprechendes Setzen der Rückgabewerte). Die Analyse des eigentlichen Inhalts der verwendeten Softwareeinheit ist dazu dann nicht mehr nötig - sie wird durch den Kontrakt abstrahiert.
Eine andere mögliche Umsetzung implementiert die formale Verifikation so, dass sie sowohl den Programmiercode des Softwaresystems wie auch Kontraktinformationen direkt verarbeiten und bei der Analyse berücksichtigen kann.

Offenbart wird mindestens ein Computer-Programm, das dafür ausgelegt ist, das computer-implementierte Verfahren 100 zur statischen Prüfung eines Softwaresystems auszuführen. Das Computer-Programm kann z.B. in interpretierbarer oder in kompilierter Form vorliegen. Es kann (auch in Teilen) zur Ausführung z.B. als Bit- oder Byte-Folge in den RAM eines Steuergeräts oder Computer geladen werden, wobei ein Computer auch als Server fungieren kann. Offenbart wird weiterhin ein computer-lesbares Medium oder Signal, das das mindestens eine Computer-Programm speichert und/oder enthält. Das Medium kann z.B. eines von RAM, ROM, EPROM,... umfassen, in dem das Signal gespeichert wird.
Offenbart wird weiterhin ein Computersystem, das dafür ausgelegt ist, das Computer-Programm auszuführen. Das Computersystem kann insbesondere mindestens einen Prozessor und mindestens einen Arbeitsspeicher umfassen. Weiterhin kann das Computersystem einen Speicher umfassen. Das Computersystem kann sich über ein System einschließlich des Servers erstrecken.
Offenbart wird weiterhin eine Softwareeinheit, die als dritte Softwareeinheit 20 nach dem computer-implementierten Verfahren 100 zur statischen Prüfung des Softwaresystems 10 geprüft 150, 152 und/oder freigegeben 160, 161 wurde. Offenbart wird weiterhin ein Softwaresystem 10, in dem jede Softwareeinheit der Vielzahl der Softwareeinheiten 20-25 als jeweilige dritte Softwareeinheit 20, 21 nach dem computer-implementierten Verfahren 100 zur statischen Prüfung des Softwaresystems 10 geprüft 150, 152 und/oder freigegeben 160, 161 wurde. Offenbart wird weiterhin ein Verfahren 300, das Bereitstellen 310 des Softwaresystems 10, in dem jede Softwareeinheit der Vielzahl der Softwareeinheiten 20-25 als jeweilige dritte Softwareeinheit 20, 21 nach dem computer-implementierten Verfahren 100 zur statischen Prüfung des Softwaresystems 10 geprüft 150, 152 und/oder freigegeben 160, 161 wurde, umfasst. Das Verfahren 300 kann Verwenden 320 des Softwaresystems 10 umfassen. Das Verfahren 300 kann zum Beispiel im Betrieb und zur Steuerung eines Fahrsystems verwendet 320 werden.
Offenbart wird weiterhin ein weiteres computer-implementiertes Verfahren 200 zur statischen Prüfung eines Softwaresystems 10, das in eine Vielzahl von Softwareeinheiten 20-25 zerlegt ist,
wobei zwischen den Softwareeinheiten 20-25 eine oder mehrere Schnittstellen vorhanden sind, wobei eine jede Schnittstelle eine jeweilige erste und eine jeweilige zweite Softwareeinheit der Vielzahl der Softwareeinheiten 20-25 zumindest insofern verbindet, als die jeweilige erste Softwareeinheit mindestens eine Ausgangsvariable 40 aufweist, die für die jeweilige zweite Softwareeinheit als mindestens eine Eingangsvariable fungiert.
Das Verfahren 200 kann umfassen: je Schnittstelle zwischen einer jeweiligen ersten und einer jeweiligen zweiten Softwareeinheit, Empfangen 220 eines Schnittstellenkriteriums für die Schnittstelle, wobei das Schnittstellenkriterium jeweils mindestens eine Nachbedingung für die mindestens eine Ausgangsvariable 40 der jeweiligen ersten Softwareeinheit und mindestens eine Vorbedingung für die mindestens eine Eingangsvariable 50 der jeweiligen zweiten Softwareeinheit umfasst und dann erfüllt ist, wenn alle Vorbedingungen durch die dazugehörigen Nachbedingungen erfüllt werden.
Das Verfahren 200 kann weiterhin umfassen: je Schnittstelle zwischen einer jeweiligen ersten und einer jeweiligen zweiten Softwareeinheit, Prüfen 230, ob das jeweilige Schnittstellenkriterium für die Schnittstelle erfüllt ist.
Offenbart wird weiterhin ein alternatives weiteres computer-implementiertes Verfahren 200 zur statischen Prüfung eines Softwaresystems 10, das in eine Vielzahl von Softwareeinheiten 20-25 zerlegt ist,
wobei zwischen den Softwareeinheiten 20-25 eine oder mehrere Schnittstellen vorhanden sind, wobei eine jede Schnittstelle eine jeweilige erste und eine jeweilige zweite Softwareeinheit der Vielzahl der Softwareeinheiten 20-25 zumindest insofern verbindet, als die jeweilige erste Softwareeinheit mindestens eine Ausgangsvariable 40 aufweist, die für die jeweilige zweite Softwareeinheit als mindestens eine Eingangsvariable fungiert.
Das Verfahren 200 kann umfassen: Empfangen 220 mindestens eines Schnittstellenkriteriums für eine Schnittstelle zwischen einer jeweiligen ersten und einer jeweiligen zweiten Softwareeinheit, wobei das Schnittstellenkriterium mindestens eine Nachbedingung für die mindestens eine Ausgangsvariable 40 der ersten Softwareeinheit und mindestens eine Vorbedingung für die mindestens eine Eingangsvariable 50 der zweiten Softwareeinheit umfasst und dann erfüllt ist, wenn alle Vorbedingungen durch die dazugehörigen Nachbedingungen erfüllt werden.
Das Verfahren 200 kann weiterhin Prüfen 230, ob das Schnittstellenkriterium für die Schnittstelle erfüllt ist, umfassen.
Generell und in den Verfahren 200, muss eine Nachbedingung einer Ausgangsvariable nicht über den Variablentyp der Ausgangsvariable hinaus einschränkend sein. In anderen Worten die Berechnungsvorschrift der Ausgangsvariable auf dem Wertebereich des Variablentyps kann surjektiv sein. Die Nachbedingung entspricht dann unmittelbar der Forderung, dass die Ausgangsvariable im Wertebereich des Variablentyps der Ausgangsvariable liegt. Ebenso muss eine Vorbedingung einer Eingangsvariable nicht über den Variablentyp der Eingangsvariable einschränkend sein. In anderen Worten, eine Vorbedingung wäre dann zwar nicht notwendig, kann aber dennoch unmittelbar der Forderung entsprechen, dass die Eingangsvariable im Wertebereich des Variablentyps der Eingangsvariable liegt. In dem Sinne können die Verfahren 200 auch auf Schnittstellen angewandt werden, die keine Vorbedingung und/oder keine Nachbedingung erfordern.
Die Verfahren 200 können erweitert werden, um Nachbedingungen globaler Eingangsvariablen und/oder Eingangsvariablen globaler Ausgangsvariablen zu berücksichtigten, wobei je globaler Eingangsvariable bzw. globaler Ausgangsvariable eine globale Schnittstelle entsteht, die in den Verfahren 200 wie eine (reguläre) Schnittstelle betrachtet werden kann.
Das weitere computer-implementierte Verfahren 200 und/oder das alternative weitere computer-implementierte Verfahren 200 können dafür ausgelegt sein, Integrationsfehler in einer Integration von Softwareeinheiten 20-25 des Softwaresystems 10 zu erkennen und/oder zu vermeiden.
Die Verfahren 200 können (wie im Verfahren 100) Zerlegen 210 des Softwaresystems 10 in die Vielzahl der Softwareeinheiten 20-25 umfassen.
Das weitere computer-implementierte Verfahren 200 und/oder das alternative weitere computer-implementierte Verfahren 200 sind schematisch in 4 illustriert.

Claims

Computer-implementiertes Verfahren (100) zur statischen Prüfung eines Softwaresystems (10), das in eine Vielzahl von Softwareeinheiten (20, 21, 22, 23, 24, 25) zerlegt ist, wobei zwischen den Softwareeinheiten (20-25) eine oder mehrere Schnittstellen vorhanden sind, wobei eine jede Schnittstelle eine jeweilige erste und eine jeweilige zweite Softwareeinheit der Vielzahl der Softwareeinheiten (20-25) zumindest insofern verbindet, als die jeweilige erste Softwareeinheit (20, 21, 22, 23, 24) mindestens eine Ausgangsvariable (40) aufweist, die für die jeweilige zweite Softwareeinheit (20, 21, 22, 23, 25) als mindestens eine Eingangsvariable (50) fungiert; das Verfahren (100) umfassend: - Empfangen (120) einer Kontextinformation für mindestens eine Schnittstelle, wobei die Kontextinformation jeweils mindestens eine Nachbedingung für die mindestens eine Ausgangsvariable (40) der jeweiligen ersten Softwareeinheit und/oder mindestens eine Vorbedingung für die mindestens eine Eingangsvariable (50) der jeweiligen zweiten Softwareeinheit umfasst; - Empfangen (130) einer Auswahl einer dritten Softwareeinheit (20) aus der Vielzahl der Softwareeinheiten (20-25) derart, dass eine dazugehörige Ersatzzerlegung des Softwaresystems (10) in die dritte Softwareeinheit (20) und einem Komplement (30) der dritten Softwareeinheit (20) erzeugt (131) wird, wobei die dritte Softwareeinheit (20) und das Komplement (30) das Softwaresystem (10) bilden und zumindest insofern über eine Ersatzschnittstelle verbunden sind, als das Komplement (30) mindestens eine Ausgangsvariable (40) aufweist, die für die dritte Softwareeinheit (20) als Eingangsvariable (50) fungiert; - Auswählen (140), zumindest auf Basis der für die mindestens eine Schnittstelle empfangenen (120) Kontextinformation, mindestens einer Nachbedingung je Ausgangsvariable (40) des Komplements (30), die als Eingangsvariable (50) der dritten Softwareeinheit (20) fungiert; - Prüfen (150), ob die eine oder die mehreren ausgewählten (140) Nachbedingungen hinsichtlich einer formalen Verifikation durch die dritte Softwareeinheit (20) vorwärts propagiert (151) werden können.
Verfahren (100) nach Anspruch 1, wobei die dritte Softwareeinheit (20) und das Komplement (30) zumindest auch insofern verbunden sind, als die dritte Softwareeinheit (20) mindestens eine Ausgangsvariable (41) aufweist, die für das Komplement (30) als Eingangsvariable (51) fungiert; das Verfahren (100) umfassend: - Auswählen (141), zumindest auf Basis mindestens einer Kontextinformation, mindestens einer Vorbedingung je Eingangsvariable (51) des Komplements (30), die durch eine Ausgangsvariable (41) der dritten Softwareeinheit (20) bedatet wird; - Prüfen (152), ob die eine oder die mehreren ausgewählten (140) und hinsichtlich der formalen Verifikation durch die Softwareeinheit vorwärts propagierten (151) Nachbedingungen die eine oder mehreren ausgewählten (141) Vorbedingungen je Eingangsvariable (51) des Komplements (30) erfüllen.
Verfahren (100) nach einem der vorhergehenden Ansprüche, dafür ausgelegt, Laufzeitfehler in Softwareeinheiten (20-25) und/oder im Softwaresystem (10) zu erkennen.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei das Vorwärtspropagieren (151) der einen oder mehreren erzeugten (140) Nachbedingungen durch die dritte Softwareeinheit (20) auf abstrakter Berechnung basiert.
Verfahren (100) nach einem der vorhergehenden Ansprüche, umfassend: - Freigeben (160) der dritten Softwareeinheit (20), wenn das Prüfen (150), ob die eine oder die mehreren ausgewählten (140) Nachbedingungen hinsichtlich der formalen Verifikation durch die dritte Softwareeinheit vorwärts propagiert (151) werden können, positiv ausfällt.
Verfahren (100) nach einem der vorhergehenden Ansprüche, umfassend: - Freigeben (161) der dritten Softwareeinheit (20), wenn das Prüfen (152), ob die eine oder die mehreren ausgewählten (140) und hinsichtlich der formalen Verifikation durch die Softwareeinheit vorwärts propagierten (151) Nachbedingungen die eine oder mehreren ausgewählten (141) Vorbedingungen je Eingangsvariable (51) des Komplements (30) der dritten Softwareeinheit (20) erfüllen, positiv ausfällt.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei mindestens eine weitere dritte Softwareeinheit (21) der Vielzahl der Softwareeinheiten (20-25) ausgewählt und analog zur dritten Softwareeinheit (20) geprüft (150, 152) und/oder freigegeben (160, 161) wird.
Verfahren (100) nach einem der vorhergehenden Ansprüche, umfassend: - Zerlegen (110) des Softwaresystems (10) in die Vielzahl der Softwareeinheiten (20-25).
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei das Empfangen (120) einer Kontextinformation für eine Schnittstelle zwischen einer ersten und einer zweiten Softwareeinheit - Auslesen (121a) mindestens einer Nachbedingung für die mindestens eine Ausgangsvariable (40) der ersten Softwareeinheit und/oder - Auslesen (121b) mindestens einer Vorbedingung für die mindestens eine Eingangsvariable (50) der zweiten Softwareeinheit aus einer Annotation, insbesondere aus einer Spezifikation, umfasst.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei das Empfangen (120) einer Kontextinformation für eine Schnittstelle zwischen einer ersten und einer zweiten Softwareeinheit - Erzeugen (122a) mindestens einer Nachbedingung für die mindestens eine Ausgangsvariable (40) der ersten Softwareeinheit und/oder - Erzeugen (122b) mindestens einer Vorbedingung für die mindestens eine Eingangsvariable (50) der zweiten Softwareeinheit umfasst.
Verfahren (100) nach Anspruch 10, wobei: - das Erzeugen (122a) der mindestens einen Nachbedingung für die mindestens eine Ausgangsvariable (40) der ersten Softwareeinheit auf mindestens einer weiteren Vorbedingung für mindestens eine weitere Eingangsvariable der ersten Softwareeinheit basiert und/oder - das Erzeugen (122b) der mindestens einen Vorbedingung für die mindestens eine Eingangsvariable (50) der zweiten Softwareeinheit auf mindestens einer weiteren Nachbedingung für mindestens eine weitere Ausgangsvariable basiert.
Softwareeinheit, die als dritte Softwareeinheit (20) nach dem computer-implementierten Verfahren (100) zur statischen Prüfung des Softwaresystems (10) nach einem der vorhergehenden Ansprüche geprüft (150, 152) und/oder freigegeben (160, 161) wurde.
Softwaresystem (10), in dem jede Softwareeinheit der Vielzahl der Softwareeinheiten (20-25) als jeweilige dritte Softwareeinheit (20, 21) nach dem computer-implementierten Verfahren (100) zur statischen Prüfung des Softwaresystems (10) nach einem der Ansprüche 1-11 geprüft (150, 152) und/oder freigegeben (160, 161) wurde.
Verfahren (300), umfassend: - Bereitstellen (310) des Softwaresystems (10) nach Anspruch 13; - optional, Verwenden (320) des Softwaresystems (10).