Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR THE COMPUTER-AIDED, AUTOMATED VERIFICATION OF REQUIREMENTS
Document Type and Number:
WIPO Patent Application WO/2018/206146
Kind Code:
A2
Abstract:
In a method for the computer-aided, automated verification of requirements, the requirements are stored in a database, and at least one interface description and at least one functional description are filed, the requirement having at least one subcomponent. The verification includes the computer-aided verification of the completeness and/or consistency of the interface description and/or the functional description. The verification is done also in relation to subcomponents.

Inventors:
SCHILLING GERHARD (DE)
Application Number:
PCT/EP2018/000246
Publication Date:
November 15, 2018
Filing Date:
May 08, 2018
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SCHILLING GERHARD (DE)
International Classes:
G06F11/36
Foreign References:
Other References:
None
Attorney, Agent or Firm:
WITZANY, Manfred (DE)
Download PDF:
Claims:
Ansprüche

Verfahren zum Computer gestützten, automatisierten Überprüfen von mindestens einer Anforderung, welche mindestens eine weitere Anforderung als Subkomponente aufweist, wobei die Anforderungen in mindestens einer Datenbank gespeichert sind und zumindest eine Schnittstellenbeschreibung für mindestens ein Eingangs- und/oder Ausgangssignal und mindestens eine funktionelle Beschreibung in formalisierter Form aufweisen, dadurch gekennzeichnet, dass die Überprüfung das Computer gestützte Prüfen der Vollständigkeit und/oder Konsistenz der

SchnittStellenbeschreibung und/oder der funktionellen Beschreibung einschließt, und sich die genannte Überprüfung auch auf mindestens eine der weiteren Anforderungen erstreckt .

Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Prüfung umfasst, ob eine in der Schnittstellenbeschreibung genannte Schnittstelle zu initialisieren und/oder das Signal zu filtern und/oder zu prüfen ist .

Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Prüfung umfasst, wie eine in der SchnittStellenbeschreibung genannte Schnittstelle zu initialisieren und/oder das Signal zu filtern und/oder zu prüfen ist.

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

3, dadurch gekennzeichnet, dass die Prüfung umfasst, ob ein Gültigkeitsbereich eines in der Schnittstellenbeschreibung genannten Signals definiert ist.

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

4, dadurch gekennzeichnet, dass die Prüfung umfasst, ob eine Datenbreite und/oder ein Vorzeichen zwischen der in der Schnittstellenbeschreibung genannten Schnittstelle und einer der Schnittstelle zugeordneten Variablen kompatibel sind.

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

5, dadurch gekennzeichnet, dass die Prüfung umfasst, ob jeder Zustand der funktionellen Beschreibung aufgrund von definierten Zustandswechselbedingungen erreichbar ist.

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

6, dadurch gekennzeichnet, dass die Prüfung umfasst, ob von jedem Zustand der funktionellen Beschreibung ein Folgezustand erreichbar ist.

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

7, dadurch gekennzeichnet, dass die Prüfung umfasst, ob jede Zustandsänderungsbedingung der funktionellen Beschreibung. einen eindeutigen Folgezustand auswählt .

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

8, dadurch gekennzeichnet, dass die Prüfung umfasst, ob jedes Signal der Schnittstellenbeschreibung in der funktionellen Beschreibung verwendet wird.

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

9, dadurch gekennzeichnet, dass die Prüfung umfasst, ob jedes in der Schnittstellenbeschreibung definierte Ausgangssignal oder Ausgangssignaländerung eindeutig von in der funktionellen Beschreibung definierten Zuständen definiert ist.

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

10, dadurch gekennzeichnet, dass die Prüfung umfasst, ob die funktionelle Beschreibung mindestens eine Abhängigkeit einer Zustandsänderungsbedingung von einem Signal definiert, welches in derselben funktionellen Beschreibung erzeugt werden soll.

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

11, dadurch gekennzeichnet, dass die Prüfung umfasst, ob die funktionelle Beschreibung mindestens eine Zustandswechselbedingungen definiert, welche mindestens einen Wert nutzt, der nicht in der zugeordneten Schnittstellenbeschreibung definiert ist .

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

12, dadurch gekennzeichnet, dass die Prüfung umfasst, ob in der Schnittstellenbeschreibung definierte Werte in der funktionellen Beschreibung verwendet werden.

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

13, dadurch gekennzeichnet, dass die Prüfung umfasst, ob ein berechneter Wert genutzt wird, bevor er überschrieben wird.

15. Verfahren nach mindestens einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass die funktionelle Beschreibung verschiedene Modi definiert und die Prüfung umfasst, ob für jeden Modus eindeutig festgelegt ist, ob mindestens eine der funktionellen Beschreibungen auszuführen ist .

16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass die Prüfung umfasst, ob von jedem Modus jeder andere Modus erreichbar oder dessen Erreichbarkeit ausdrücklich verneint ist.

17. Verfahren zum Computer gestützten, automatischen Erzeugen von Testdaten für ein Zielsystem, die eine Anforderung erfüllen soll, welche in einer Datenbank gespeichert ist und zumindest SchnittStellenbeschreibungen und mindestens eine funktionelle Beschreibung in formalisierter Form aufweisen, dadurch gekennzeichnet, dass die Schnittstellenbeschreibungen aller Eingangssignale analysiert werden, wobei alle in der SchnittStellenbeschreibung eingetragenen Werte jedes Eingangssignals sortiert werden, um Testwerte zu erzeugen, die zwischen diesen eingetragenen Werten liegen und unterschiedliche Permutationen dieser Testwerte als Testdaten ausgegeben werden.

18. Verfahren nach mindestens einem der Ansprüche 1 bis 17, dadurch gekennzeichnet, dass die Anforderung eine Software betrifft, welche zur Steuerung und/oder Regelung mindestens eines technischen Prozesses vorgesehen ist .

19. Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass die Software auf mindestens einem Controller läuft .

Description:
Verfahren zur Computer gestützten, automatisierten Überprüfung von Anforderungen

Die Erfindung betrifft ein Verfahren zum Computer gestützten, automatisierten Überprüfen von mindestens einer Anforderung und zur Erzeugung von Testdaten. Unter einer „Anforderung" ist hier und im Folgenden eine Beschreibung eines grundsätzlich beliebigen, technischen Prozesses zu verstehen. Es kann sich dabei um eine elektrische oder elektronische Schaltung, um eine hydraulische oder pneumatische Vorrichtung, um ein mechanisches Gerät, um einen Produktionsprozess, um einen chemischen Prozess oder eine Computersoftware handeln. Diese Aufzählung ist lediglich beispielhaft und nicht abschließend zu verstehen. Insbesondere können die o. g. Beispiele auch in beliebiger Weise vermischt bzw. kombiniert auftreten. Die Anforderung soll dabei den konkreten technischen Ablauf eines Zielsystems beschreiben. Auf diese Weise wird das Zielsystem in seiner gesamten Funktionalität spezifiziert. Diese Anforderung weist mindestens eine weitere Anforderung als

BESTÄTIGUNGSKOPIE Subkomponente auf, wobei jede der Anforderungen in mindestens einer Datenbank gespeichert ist und zumindest eine Schnittstellenbeschreibung und eine funktionelle Beschreibung aufweist .

Aus der Praxis sind verschiedene Computerprogramme bekannt, die Anforderungen in Textform erfassen und in einer Datenbank ablegen. Diese Datenbank ist dabei verlinkt, um Textpassagen, die sich bereits in der Datenbank befinden, an anderer Stelle zu verwenden. So kann beispielsweise eine SchnittStellenbeschreibung im Rahmen einer Komponente zur Signalaufbereitung beschrieben werden. Wenn die dieser Schnittstelle zugeordneten Signale dann an anderer Stelle benötigt werden, kann die entsprechende Schnittstellenbeschreibung hierzu verlinkt werden. Dies hat den Vorteil, dass eine Änderung der Schnittstellenbeschreibung sich auch auf die anderen, verlinkten Komponenten auswirkt. Nachteilig ist jedoch, dass es dem Entwickler überlassen bleibt, ob er diese Verlinkungstechnik auch nutzt und wie er mit einer sich nachträglich ändernden Beschreibung umgeht. Damit kann der Entwickler, der in der Regel von einem mehrköpfigen Team gebildet wird, unvollständige bzw. inkonsistente Anforderungen erstellen. Computerprogramme, welche mit derartigen, mangelhaften Anforderungen erstellt sind, neigen zu großer Fehleranfälligkeit, wodurch sich der Entwicklungsprozess zeitlich sehr in die Länge streckt. In Ermangelung besserer Systeme sind jedoch Entwickler gezwungen, sich dieser bekannten Komponenten zu bedienen. Diese bilden daher den nächstliegenden Stand der Technik zum

Erfindungsgegenstand .

Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren der eingangs genannten Art zu schaffen, welches qualitativ höherwertige Anforderungen erzeugt und Unvollständigkeiten bzw. Inkonsistenzen möglichst frühzeitig erkennt .

Diese Aufgabe wird erfindungsgemäß mit den folgenden Merkmalen gelöst .

Bei dem erfindungsgemäßen Verfahren wird mindestens eine Anforderung in einer Datenbank gespeichert . Als Datenbank ist eine Ansammlung von Datenblöcken zu verstehen, die in einer oder mehreren Dateien gespeichert sind und für die eine wahlfreie Zugriffsmöglichkeit eingerichtet ist. Diese Anforderung weist mindestens eine weitere Anforderung als Subkomponente auf, wobei diese Subkomponente grundsätzlich in gleicher Weise wie die Hauptkomponente zu behandeln ist. Es ist jedoch nicht zwingend erforderlich, sämtliche spezifizierten

Subkomponenten in diese Prüfung einzubeziehen. Es ist durchaus vorstellbar, einzelne Subkomponenten von der Prüfung gezielt ausschließen zu können. Auf diese Weise kann dem Umstand Rechnung getragen werden, dass zu einem bestimmten Entwicklungszeitpunkt verschiedene

Subkomponenten noch gar nicht entwickelt sind oder andere Entwickler für die entsprechende Subkomponente zuständig sind. Bezöge man zwangsweise alle Subkomponenten in die Prüfung ein, so ergäbe sich in diesen genannten Fällen zwangsläufig eine Vielzahl von Fehlermeldungen, die den Entwicklungsablauf erheblich stören. Jede Anforderung weist zumindest eine Schnittstellenbeschreibung für mindestens ein Eingangs- und/oder Ausgangssignal und mindestens eine funktionelle Beschreibung in formalisierter Form auf. Die Schnittstellenbeschreibung umfasst sämtliche Details, die die jeweilige Schnittstelle und das Signal betreffen, welches über diese Schnittstelle empfangen und/oder gesendet wird. Dies können beispielsweise sein: Datenbreite, Wertebereich, Protokoll, zugeordneter physikalischer Wert, Abtastfrequenz, PortZuordnung,

Initialisierungserfordernis und -verfahren,

Filtererfordernis und -verfahren, Mittelungserfordernis und -verfahren und Zuverlässigkeitsindikatoren. Diese Aufzählung ist jedoch nur beispielhaft und nicht abschließend zu verstehen. Die funktionelle Beschreibung erfolgt in formalisierter Form, beispielsweise als Flussdiagramm, Zustandsautomat oder Pseudocode. Auch diese Aufzählung ist nur beispielhaft und nicht abschließend zu verstehen. Um Lücken bzw. Fehler in der Anforderung möglichst frühzeitig zu erkennen, erfolgt eine Computer gestützte Prüfung auf Vollständigkeit bzw. Konsistenz . Diese Prüfung umfasst die

Schnittstellenbeschreibung und/oder die funktionelle Beschreibung. Bei der Vollständigkeitsprüfung der Schnittstellenbeschreibung kann insbesondere geprüft werden, ob alle erforderlichen Angaben in der Schnittstellenbeschreibung enthalten sind. Diese hängen grundsätzlich von der spezifizierten Art des Signals ab. So werden an rein binäre Signale wesentlich geringere Definitionsanforderungen gestellt als an seriell bzw. parallel übermittelte Daten. Werden Informationen beispielsweise seriell übertragen, so ist die Anwendung des jeweiligen Protokolls von entscheidender Bedeutung. Bei reinen Zustandsinformationen spiegelt das Signal unmittelbar einen äußeren Systemzustand wieder, so dass hier keinerlei ProtokollInformationen benötigt werden. Bei der Konsistenzprüfung der Schnittstellenbeschreibung werden gegenseitige Abhängigkeiten berücksichtigt. Wird beispielsweise in der Schnittstellenbeschreibung ein Signal als serieller Datenstrom gekennzeichnet, ohne ein entsprechendes Protokoll zu spezifizieren, kann diese Inkonsistenz erkannt und als Warnung bzw. Fehler ausgegeben werden. Bezüglich Echtzeitanforderungen kommen Informationen wie Samplingrate, Latenzzeit und die geforderte Reaktionszeit auf ein bestimmtes Trigger- Ereignis in Betracht . Es ist auch daran gedacht zu prüfen, ob die angegebenen Echtzeitanforderungen konsistent zueinander sind. Eine Inkonsistenz ergibt sich beispielsweise daraus, dass die Reaktionszeit einer Schnittstellenbeschreibung eines Ausgangssignals kürzer ist als die Summe der damit verbundenen Sampling- und Bearbeitungszeiten. Ebenso könnte eine Inkonsistenz durch Verletzung des Abtasttheorems aufgefunden werden. Dies betrifft sowohl Eingangs- als auch Ausgangssignale. Wenn die Abtast- bzw. Update-Rate kleiner als die halbe Signalperiode ist, ist eine ordnungsgemäße

Signalverarbeitung ausgeschlossen. In diesem Fall wird ein entsprechender Fehler bzw. eine Warnung ausgegeben. Bei der Schnittstellenbeschreibung spielt es keine Rolle, ob die Schnittstelle eine externe oder interne Hardware- Schnittstelle oder eine Software-Schnittstelle betrifft. Software-Schnittstellen sind in der Regel Daten, welche in einem entsprechenden Speicher abgelegt sind. Diese können in gleicher Weise wie Hardware-Schnittstellen beschrieben und geprüft werden. Die funktionelle Beschreibung beschreibt den konkreten Programmablauf und lässt sich folglich nicht mit der gleichen Gründlichkeit wie die Schnittstellenbeschreibung prüfen. In eingeschränktem Maß sind jedoch auch hier Prüfungen auf Vollständigkeit und Konsistenz möglich. Da alle genannten Prüfungen Computer gestützt stattfinden, können Dokumentationsfehler in der Anforderung erkannt werden, bevor die erste Komponente des Zielsystems gezeichnet oder die erste Programmzeile der Software geschrieben ist. Insbesondere ist daran gedacht, der Schnittstellenbeschreibung eine erhöhte Bedeutung zukommen zu lassen. Dies geschieht insbesondere dadurch, dass sämtliche Signal bezogenen Informationen ausschließlich in den Schnittstellenbeschreibungen abgelegt werden. Auf diese Weise wird vermieden, dass sich Signal bezogene Informationen der Vollständigkeitsbzw. Konsistenzprüfung entziehen können. Damit ergibt sich eine zwangsweise Verlinkung der

Schnittstellenbeschreibungen. Wenn an irgendeiner Stelle in der Anforderung Informationen zu einem Signal benötigt werden, können diese ausschließlich aus der zugeordneten Schnittstellenbeschreibung kommen. Da diese

Schnittstellenbeschreibung aber auf Vollständigkeit und Konsistenz mit hoher Güte geprüft ist, werden Definitionsfehler und -lücken auf diese Weise mit hoher Wahrscheinlichkeit ausgeschlossen. Grundsätzlich zwingt dieses Verfahren den Entwickler dazu, sich frühzeitig zu allen möglichen Details Gedanken zu machen, bevor Inkonsistenzen entstehen können. Auf diese Weise entsteht ein Zielsystem mit hoher Qualität und sehr kurzem Entwicklungszyklus, was die Produktivität der Entwicklung insgesamt erheblich verbessert.

Vorzugsweise umfasst die Prüfung der

Schnittstellenbeschreibung das Überprüfen, ob bestimmte Informationen hinterlegt sind, beispielsweise ob die Schnittstelle zu initialisieren, zu filtern bzw. zu prüfen ist. Oftmals ist eine komplexe Signalaufbereitung erforderlich, was durch spezialisierte Bausteine wie beispielsweise Analog-Digital-Umsetzer, Frequenzzähler oder andere Komponenten erledigt wird. Diese Komponenten benötigen manchmal eine Initialisierung, bevor der erste Wert für das Signal ermittelt werden kann. Für andere Schnittstellen, beispielsweise reine

Digitalschnittstellen ist dagegen eine Initialisierung oftmals nicht erforderlich. Je nach Signalqualität kann es auch erforderlich sein, das der Schnittstelle zugeordnete Signal zu filtern, um Störimpulse zu eliminieren oder die Signalgenauigkeit zu erhöhen. Es ist zweckmäßig zu prüfen, ob diesbezüglich entsprechende Angaben in der SchnittStellenbeschreibung enthalten sind, so dass beim Fehlen dieser Angaben eine entsprechende Warnung ausgegeben wird. Außerdem kann es erforderlich sein, ein der Schnittstelle zugeordnetes Signal zu prüfen, um beispielsweise dessen Konsistenz oder Qualität zu bestimmen. Auch das Vorhandensein dieser Information wird zweckmäßigerweise geprüft, um zu verhindern, dass Signale mit schlechter Qualität oder sogar irreguläre Signale der weiteren Prozessverarbeitung zugeführt werden .

Für den Fall, dass in der Schnittstellenbeschreibung die Initialisierung, das Filtern oder Prüfen gefordert wird, ist es zweckmäßig, auch das hierfür erforderliche Verfahren in der SchnittStellenbeschreibung zu hinterlegen. Dies erfolgt am zweckmäßigsten durch eine entsprechende funktionelle Beschreibung in formalisierter Form. Das erfindungsgemäße Verfahren prüft in diesem Fall, ob ein entsprechendes Verfahren hinterlegt ist oder entsprechende Parameter, beispielsweise die Zahl der erforderlichen Mittelungen, zur Filterung des Messwertes hinterlegt sind.

Oftmals haben Signale nur einen beschränkten Gültigkeitsbereich, wobei bei Über- bzw. Unterschreiten dieses Gültigkeitsbereichs Sonderbehandlungen auszuführen sind. Um diese Sonderbehandlungen konsistent über die gesamte Anforderung zu erstellen, ist es zweckmäßig, den Gültigkeitsbereich des Signals in der

Schnittstellenbeschreibung zu hinterlegen. Das erfindungsgemäße Verfahren prüft daher, ob ein entsprechender Gültigkeitsbereich definiert ist. Grundsätzlich ist daran gedacht, neben dem Gültigkeitsbereich auch Zwischenwerte, insbesondere Grenzwerte des Signals in der Schnittstellenbeschreibung zu hinterlegen. Diese Grenzwerte können dann beispielsweise in der funktionellen Beschreibung zum Vergleich mit dem Signal herangezogen werden. Es ist jedoch nicht zweckmäßig, diese Grenzwerte auf Vollständigkeit der Schnittstellenbeschreibung zu prüfen, da eine Prüfung anhand objektiver Kriterien fehlschlagen wird. Für derartige Anwendungsfälle ist es zweckmäßiger, die funktionelle Beschreibung dahingehend zu überprüfen, dass als Vergleichsparameter ausschließlich Parameter aus Schnittstellenbeschreibungen genutzt werden. Auf diese Weise ergibt sich eine konsistente Benutzung der Grenzwerte .

In der Regel müssen die Signale, die von Schnittstellen bezogen werden, in entsprechenden Variablen gespeichert werden. Auf diese Variablen kann dann die funktionelle Beschreibung Bezug nehmen, sofern sichergestellt ist, dass durch das Speichern der Signale in der Variablen kein Informationsverlust entsteht. Aus diesem Grund umfasst die Prüfung einen Vergleich der Datenbreite bzw. des Vorzeichens der Schnittstellenbeschreibung mit der zugeordneten Variablen. Kommt dieser Vergleich zu dem Ergebnis, dass beim Speichern des Signals in der Variablen Information verloren geht, weil beispielsweise die Datenbreite zu gering ist oder ein mögliches negatives Vorzeichen verloren ginge, so wird eine entsprechende Warnung erzeugt .

Naturgemäß ist die funktionelle Beschreibung wesentlich schwieriger zu prüfen als die Schnittstellenbeschreibung, da die funktionelle Beschreibung den eingesetzten Algorithmus wiedergeben muss. Es ist schwierig, einen Fehler in einem Algorithmus computergestützt aufzufinden. Trotzdem sind gewisse Prüfungen der funktionellen Beschreibung machbar. Beispielsweise kann geprüft werden, ob jeder Zustand der funktionellen Beschreibung aufgrund von definierten Zustandswechselbedingungen erreichbar ist. Ist ein Zustand nicht erreichbar, so liegt offensichtlich ein algorithmischer Fehler vor, der eine entsprechende Warnung zur Folge hat . Dabei kann es durchaus sein, dass ein Zustand nur dann erreichbar ist, wenn ein Signal seinen Gültigkeitsbereich verlässt, um in diesem Zustand dann eine Sonderbehandlungsroutine abzuarbeiten. Ist aber ein Zustand nur aufgrund von einander widersprechenden Signalbedingungen und/oder physikalisch nicht realisierbaren Signalen erreichbar, so liegt offensichtlich ein algorithmischer Fehler in der funktionellen Beschreibung vor, der beim Prüfen durch das erfindungsgemäße Verfahren zu einer entsprechenden Warnung führt .

Außerdem ist es vorteilhaft zur prüfen, ob von jedem Zustand der funktionellen Beschreibung ein Folgezustand erreichbar ist. Wenn kein Folgezustand mehr erreichbar wäre, müsste das System für immer in diesem Zustand verbleiben, so dass das Zielsystem als „abgestürzt" zu bezeichnen wäre. Damit liegt für den Fall, dass kein Folgezustand erreichbar ist, ein algorithmischer Fehler in der funktionellen Beschreibung vor, der durch das erfindungsgemäße Verfahren zu einer entsprechenden Warnung führt .

Außerdem ist es zweckmäßig, die funktionelle Beschreibung dahingehend zu prüfen, ob jedes definierte Signal der Schnittstellenbeschreibung in der funktionellen Beschreibung verwendet wird. Im gegenteiligen Fall erzeugt das erfindungsgemäße Verfahren eine entsprechende Warnung. Diese Warnung zeigt dem Entwickler an, dass er entweder ein Signal in der funktionellen Beschreibung vergessen hat oder dieses Signal aus der Schnittstellenbeschreibung löschen oder als „reserviert" markieren sollte. Diese Maßnahme verhindert insbesondere, dass der Entwickler aus Bequemlichkeitsgründen in der Schnittstellenbeschreibung seiner Anforderung einfach grundsätzlich alle möglichen Schnittstellen in der Schnittstellenbeschreibung anführt, die er vielleicht irgendwo benötigen könnte. Damit umgeht der Entwickler aber das Gebot, sich über die erforderlichen Signale zuerst Gedanken zu machen, bevor er die funktionelle Beschreibung erstellt. Das erfindungsgemäße Verfahren quittiert diese Vorgangsweise dann mit einer entsprechenden Anzahl von Warnungen, so dass der Entwickler zwangsweise einen sauberen

Schnittstellenansatz definieren muss.

Insbesondere bei komplexen Anforderungen kommt es immer wieder vor, dass Ausgangssignale inkonsistent sind, da verschiedene Komponenten der Anforderung unterschiedliche Werte für das Ausgangssignal fordern. Wenn beispielsweise eine Komponente ein bestimmtes Ausgangssignal auf Eins setzt, wenn ein Eingangssignal A aktiv ist und eine weitere Komponente dasselbe Ausgangssignal auf Null setzt, wenn ein Eingangssignal B inaktiv ist, so kann es durchaus vorkommen, dass widersprüchliche Bedingungen für das Ausgangssignal vorliegen, insbesondere wenn das Eingangssignal A aktiv und das Eingangssignal B inaktiv ist. Derartige Fehler sind im der fertigen Zielsystem nur sehr schwer zu finden und verursachen daher eine beträchtliche Verlängerung der Entwicklungszeit. Es ist daher zweckmäßig, die Eindeutigkeit der Ausgangssignale bzw. Ausgangssignaländerungen bereits in der funktionellen Beschreibung zu prüfen und Fälle wie den oben genannten mit einer entsprechenden Warnung zu quittieren.

In der Informatik sind rekursive Algorithmen bekannt, die einen einfachen, programmtechnischen Ansatz zur Lösung eines komplexen mathematischen Problems bieten. Derartige rekursive Ansätze sind jedoch in der Signalverarbeitung höchst gefährlich, da sie davon ausgehen, dass die entsprechenden Eingangswerte konstant bleiben. Dies ist bei der Signalverarbeitung aber gerade nicht der Fall. Aus diesem Grund ist es zweckmäßig zu prüfen, ob die funktionelle Beschreibung rekursive Signalabfragen enthält . Dies kann man am einfachsten dadurch feststellen, dass geprüft wird, ob eine

Zustandsänderungsbedingung in der funktionellen Beschreibung in Abhängigkeit von einem Signal steht, welches von derselben funktionellen Beschreibung erzeugt werden soll. Damit werden rekursive Signalabfragen mit entsprechenden Warnungen durch das erfindungsgemäße Verfahren quittiert. Ein rekursiver Algorithmus ohne Einflussnahme auf Zustände, wie beispielsweise die schnelle Analog-Digital-Wandlung ist davon jedoch nicht betroffen. Um zu verhindern, dass wichtige Werte, wie beispielsweise Vergleichswerte in Zustandsänderungsbedingungen an beliebiger Stelle hinterlegt werden und damit einer Vollständigkeitsprüfung entzogen werden, ist es vorteilhaft, wenn das erfindungsgemäße Verfahren ZustandsWechselbedingungen dahingehend überprüft, ob darin Werte genutzt werden, die nicht in der Schnittstellenbeschreibung hinterlegt sind. Damit ist der Entwickler gezwungen, sämtliche Vergleichswerte, die er für seine funktionelle Beschreibung benötigt, in der Schnittstellenbeschreibung zu hinterlegen, wo sie dann in der gesamten Anforderung auf Konsistenz überprüfbar ist .

Um auf der anderen Seite zu verhindern, dass der Entwickler prophylaktisch einfach alle möglichen Werte in der Schnittstellenbeschreibung definiert, die er möglicherweise einmal benötigen könnte, ist es zweckmäßig zu prüfen, ob die in der Schnittstellenbeschreibung definierten Werte in der funktionellen Beschreibung verwendet werden. Überflüssige Werte der

Schnittstellenbeschreibung erzeugen dann eine entsprechende Warnung. Es kann beispielsweise vorkommen, dass neben einem komplett aufbereiteten Signal zusätzlich eine Signalrohform, beispielsweise das ungefilterte Signal, gespeichert werden soll. Kommt es zu einem unerwarteten Störfall, so kann aus diesem Speicher der zeitliche Verlauf des Rohsignals ausgelesen werden, um Anhaltspunkte für eine Früherkennung des Störfalls zu finden. Diese Information ist für die Weiterentwicklung des Zielsystems von erheblicher Bedeutung, insbesondere bei sicherheitsrelevanten Komponenten wie Flugzeug- oder Kraftwerkskomponenten. Um das Rohsignal einem Datenlogger zuführen zu können, muss dieses aber für die Datenlogger- Komponente verfügbar sein. Dies kann am einfachsten dadurch geschehen, dass es in der

Schnittstellenbeschreibung aufgeführt wird. Damit wird aber auch klar dokumentiert, dass unterschiedliche Komponenten unterschiedliche Verarbeitungsstadien des Signals erhalten, wodurch Verwechslungen ausgeschlossen werden. Durch das Überprüfen der Verwendung des Rohsignals in der funktionellen Beschreibung ist außerdem sichergestellt, dass der Entwickler nicht grundsätzlich alle möglichen Verarbeitungsstufen in der

Schnittstellenbeschreibung öffentlich macht, weil er auf diese Weise mit einer Vielzahl von Warnungen überschüttet würde .

Außerdem ist es zweckmäßig, die funktionelle Beschreibung dahingehend zu prüfen, ob ein berechneter Wert genutzt wird, bevor er überschrieben wird. In der Regel ist das Überschreiben eines Wertes vor dessen Auslesen ein algorithmischer Fehler, so dass hier eine entsprechende Warnung erstellt wird.

Oftmals ist es erforderlich, in einer Anforderung verschiedene Modi zu definieren, in denen das zu erstellende Zielsystem jeweils unterschiedlich arbeiten soll. Diese Modi können beispielsweise sein: Normaler Betriebsmodus, Unterspannungsmodus, defekter Sensormodus, defekter Aktormodus, ungenügender Speicherplatzmodus usw. Alternativ oder zusätzlich können auch Modi für verschiedene Ausführungsformen der Anforderung, beispielsweise für unterschiedliche Applikationsmodelle definiert werden. So kann eine bestimmte Komponente für ein Kraftfahrzeug unterschiedliche Modi für verschiedene Kraftfahrzeugmodelle aufweisen, so dass die Adaption auf ein bestimmtes Kraftfahrzeugmodell durch einfache Wahl des Modus erfolgen kann. Die unterschiedlichen Modi sind dabei auch kombiniert einsetzbar. So können beispielsweise zwei Modi für die Betriebsspannung, zwei Modi für den Zustand der Sensoren, zwei Modi für den Zustand der Aktoren und vier Modi für die Modelle eingesetzt werden. Dies ergibt dann 32 verschiedene Modi. In Realität können die Modi noch wesentlich komplexer werden, was deren akkumulierte Zahl noch wesentlich in die Höhe treibt . Bei derartigen Anforderungen ist es relativ schwierig, eindeutig festzulegen, ob eine bestimmte funktionelle Beschreibung auch tatsächlich eindeutig den verschiedenen Modi zugeordnet ist. Diese eindeutige Zuordnung ist jedoch unabdingbare Voraussetzung für ein korrekt laufendes Zielsystem. Aus diesem Grund ist es zweckmäßig zu prüfen, ob für jeden definierten Modus eindeutig festgelegt ist, ob mindestens eine der funktionellen Beschreibungen auszuführen ist. Beim Auftreten von Definitionslücken bezüglich der Moduswahl wird dann eine entsprechende Warnung erzeugt .

Bei der Definition von Modi kommt es relativ häufig vor, dass mögliche Moduswechsel übersehen werden. Es kann zwar durchaus vorkommen, dass bestimmte Moduswechsel ausgeschlossen werden können. In der Regel ist jedoch ein nicht definierter Moduswechsel ein Indiz für eine unvollständige Anforderung. Aus diesem Grund ist es zweckmäßig zu prüfen, ob von jedem Modus jeder andere Modus erreichbar ist, oder dessen Erreichbarkeit ausdrücklich verneint ist. Die letztgenannte Möglichkeit erlaubt, eine entsprechende Warnung zu unterdrücken, wenn ein bestimmter Modusübergang nicht vorgesehen ist. In diesem Fall ist jedoch eine ausdrückliche Verneinung erforderlich, so dass der Entwickler sich über den nicht definierten Moduswechsel Gedanken gemacht haben muss. Ein versehentliches Weglassen eines bestimmten Moduswechsels ist hierdurch jedoch ausgeschlossen.

Die Erfindung betrifft außerdem ein Verfahren zum Computer gestützten, automatischen Erzeugen von Testdaten für ein Zielsystem, die eine Anforderung erfüllen soll. Im Stand der Technik wird hierzu eine Vielzahl von Testdaten zwischen den definierten Grenzen des Gültigkeitsbereichs der einzelnen Signale erzeugt, um das erzeugte Zielsystem zu testen. Bei Anforderungen, die nach dem erfindungsgemäßen Verfahren geprüft sind, ist jedoch gewährleistet, dass - die Beachtung von Warnungen vorausgesetzt - sämtliche Schwellwerte zum Vergleich mit Signalen in den Schnittstellenbeschreibungen hinterlegt sind. Damit sind alle Grenzwerte, bei denen sich das Verhalten des Zielsystems in irgendeiner Weise ändert, durch Werte eindeutig festgelegt, die in den Schnittstellenbeschreibungen festgelegt sind. Dies wird beim erfindungsgemäßen Verfahren zum automatischen Erzeugen von Testdaten dahingehend ausgenutzt, dass die SchnittStellenbeschreibungen aller Eingangssignale analysiert werden, wobei alle in der

Schnittstellenbeschreibung eingetragenen Werte jedes Eingangssignals sortiert werden. Zwischen jeweils benachbarten Werten dieser sortierten Wertereihe ändert sich das grundsätzliche Verhalten des Zielsystems nicht. Darum reicht es aus, jeweils einen Testwert zwischen diesen eingetragenen Werten zu erzeugen und diese Werte in unterschiedlichen Permutationen als Testdaten auszugeben. Damit werden wesentlich weniger Testdaten erzeugt, wobei sichergestellt ist, dass jede Abfragebedingung der Signale in den Testdaten realisiert wird. Der Test des Zielsystems wird auf diese Weise nicht nur schneller, sondern auch sicherer.

Das erfindungsgemäße Verfahren wird vorzugsweise für Anforderungen eingesetzt, welche zur Steuerung und/oder Regelung mindestens eines technischen Prozesses dienen. Dort sind relativ hohe Anforderungen an die Sicherheit des Zielsystems zu stellen, so sich das erfindungsgemäße Verfahren. in diesem Bereich besonders vorteilhaft auswirkt .

Vorzugsweise ist das Zielsystem Software realisiert, welche auf mindestens einem Controller läuft, der neben der zentralen Recheneinheit auch Speicher und Schnittstellen aufweist. In diesem Bereich, der auch als „embeded System" bezeichnet wird, gelten besonders hohe Anforderungen an die Softwaresicherheit, da ein Eingriff in die Software von außen in der Regel nicht möglich ist.

Das erfindungsgemäße Verfahren wird beispielhaft und auszugsweise ohne Anspruch auf Vollständigkeit anhand der folgenden Ausführungsbeispiele unter Bezugnahme auf die Zeichnung näher erläutert. Diese Ausführungen dienen lediglich dazu, das erfindungsgemäße Verfahren zu erläutern und nicht, um den Schutzbereich festzulegen, der durch die Ansprüche definiert ist.

Es zeigt:

Figur 1 ein Verfahren zum Prüfen der

Schnittstellenbeschreibung auf Vollständigkeit,

Figur 2 ein Verfahren zum Prüfen der funktionellen

Beschreibung auf Erreichbarkeit aller Zustände,

Figur 3 ein Verfahren zur Realisierung einer state- Funktion,

Figur 4 eine formalisierte Anforderung eines

Radiogeräts als funktionale Blackbox- Architektur und

Figur 5 die Anforderung gemäß Figur 4 mit

Subkomponenten .

Die Figur 1 zeigt einen Algorithmus zur Überprüfung der Schnittstellenbeschreibung auf Vollständigkeit. Dabei wird vorausgesetzt, dass dem Entwickler ein Template zur Anlage einer Schnittstellenbeschreibung in einer Datenbank zur Verfügung gestellt wurde, in dem entsprechende Felder zum Ausfüllen enthalten sind. Der Algorithmus gemäß Figur 1 prüft die in der Datenbank abgelegten Schnittstellenbeschreibungen in folgender Weise :

In Schritt 1 wird eine Zählvariable n auf den Wert 0 initialisiert. Diese Zählvariable n dient zur Referenzierung der SchnittStellenbeschreibungen. Dies bedeutet, dass die erste Schnittstellenbeschreibung mit n = 0, die zweite Schnittstellenbeschreibung mit n = 1 usw. referenziert werden kann. In Schritt 2 wird eine weitere Zählvariable m auf den Wert 0 initialisiert. Diese Zählvariable m dient zur Referenzierung der einzelnen Datenfelder innerhalb der Schnittstellenbeschreibung, wobei das erste Datenfeld mit dem Index m = 0 referenziert wird.

In Schritt 3 wird abgefragt, ob in der Datenbank zur Schnittstellenbeschreibung n im Feld m ein Wert eingetragen ist. Außerdem wird in Schritt 3 abgefragt, ob der eingetragene Wert in der Datenbank auch konsistent zu den übrigen Werten der Schnittstellenbeschreibung n ist. Falls mindestens einer der genannten Tests fehlschlägt, verzweigt die Abfrage gemäß Schritt 3 zum Zweig 3F. In diesem Fall wird in Schritt 4 eine entsprechende Warnung erzeugt und ausgegeben. Falls die Tests gemäß Schritt 3 keine Beanstandungen finden, wird der Zweig 3T genutzt, wodurch die Ausgabe der Warnung in Schritt 4 unterdrückt wird.

In Schritt 5 wird die Zählvariable m inkrementiert , um auf diese Weise das nächste Feld innerhalb der Schnittstellenbeschreibung n zu adressieren. Im folgenden Schritt 6 wird abgefragt, ob die Zählvariable m noch innerhalb zulässiger und vordefinierter Grenzwerte liegt. Falls dies der Fall ist, wird zum Zweig 6T verzweigt, so dass der Programmfluss mit Schritt 3 fortgesetzt wird. Liegt die Zählvariable m aber innerhalb des zulässigen Bereichs, so wird zum Zweig 6F verzweigt und der folgende Schritt 7 ausgeführt.

In Schritt 7 wird die Zählvariable n inkrementiert , um auf diese Weise die nächste SchnittStellenbeschreibung zu adressieren.

Im folgenden Schritt 8 wird abgefragt, ob die Zählvariable n noch innerhalb zulässiger und vordefinierter Grenzwerte liegt. Falls dies der Fall ist, wird zum Zweig 8T verzweigt, so dass der Programmfluss mit dem Schritt 2 fortgesetzt wird. Liegt die Zählvariable m aber innerhalb des zulässigen Bereichs, so wird zum Zweig 8F verzweigt und der folgende Schritt ausgeführt .

Nach Durchlaufen dieses Algorithmus sind sämtliche Schnittstellenbeschreibungen auf Vollständigkeit und Konsistenz geprüft. Wie man sieht, ist die Prüfung der Schnittstellenbeschreibung programmtechnisch relativ einfach, wobei trotzdem eine sehr hohe Prüfungsgüte erzielt werden kann. Diese Vereinfachung ist eine Folge der Trennung der gesamten Anforderung in eine funktionelle Beschreibung und eine

Schnittstellenbeschreibung . Figur 2 zeigt einen Algorithmus zur Überprüfung der funktionellen Beschreibung. Dabei wird vorausgesetzt, dass die funktionelle Beschreibung in Form eines Zustandsautomaten in der oben genannten Datenbank gespeichert ist.

In Schritt 10 wird die Funktion State (init) aufgerufen. Diese Funktion versetzt einen virtuellen

Zustandsautomaten in jenen Zustand, in den der Zustandsautomat beispielsweise unmittelbar nach einem reset kommt . Dies ist also der Ausgangszustand des Zustandsautomaten. Außerdem werden von dieser Funktion verschiedene Prüfungen durchgeführt, die weiter unten erläutert sind.

In Schritt 11 wird eine Zählvariable n auf 0 initialisiert. Dabei wird vorausgesetzt, dass die einzelnen Zustände des Zustandsautomaten in der Datenbank über die Zählvariable n initiiert abgerufen werden können .

In Schritt 12 wird geprüft, ob beim Zustand n das checked-flag gesetzt ist. Falls dies nicht der Fall ist, verzweigt die Abfrage gemäß Schritt 12 in den Zweig 12F und erzeugt in Schritt 13 eine entsprechende Warnung, welche ausgegeben wird. Falls das checked-flag jedoch gesetzt war, verzweigt die Abfrage gemäß Schritt 12 in den Zweig 12T und unterdrückt die Ausgabe der Warnung durch Umgehung des Schritts 13. In Schritt 14 wird die Zählvariable n inkrementiert , um auf diese Weise den nächsten, folgenden Zustand aufzurufen.

In der Abfrage gemäß Schritt 15 wird nun geprüft, ob die Zählvariable n innerhalb zulässiger Grenzen ist oder ob n einen Zustand referenziert , der nicht mehr existiert. Falls die Zählvariable n zulässig ist, verzweigt die Abfrage gemäß Schritt 15 zum Zweig 15T, so dass der Programmfluss zum Schritt 12 verzweigt. Falls jedoch die Zählvariable n ungültig ist, ist die Prüfung abgeschlossen .

In Figur 3 ist der Algorithmus für die State-Funktion gemäß Schritt 12 dargestellt. Es versteht sich von selbst, dass der Schritt 10 in gleicher Weise auszubilden ist .

In einem Schritt 20 wird eine Zählvariable m auf den Wert 0 initialisiert. Diese Zählvariable m referenziert für den jeweiligen, ausgewählten Zustand eine entsprechende Zustandswech.selbedingung, einschließlich einer Referenz auf den jeweiligen Folgezustand. In einem Schritt 21 wird abgefragt, ob ein checked-flag des ausgewählten Zustandes gesetzt ist. In diesem Fall wird der Programmfluss im Zweig 21T fortgesetzt. Falls das checked-flag jedoch nicht gesetzt ist, wird mit dem Zweig 21F fortgesetzt. Dabei ist zu berücksichtigen, dass das checked-flag jedes Zustandes zu Beginn des beschriebenen Algorithmus zurückgesetzt ist. Durch Setzen dieses checked-flags wird angezeigt, dass dieser Zustand bereits geprüft wurde und daher eine weitere Prüfung unterlassen werden kann. Auf diese Weise werden Endlosschleifen vermieden. Außerdem wird auf diese Weise die Effizienz des Algorithmus erheblich gesteigert, da doppelte und mehrfache Prüfungen desselben Zustandes zuverlässig ausgeschlossen werden.

Vom Zweig 21F wird der Schritt 22 ausgeführt, in dem das checked-flag gesetzt wird. Damit wird angezeigt, dass der aktuelle Zustand nunmehr der Prüfung unterworfen wurde und eine erneute Prüfung auszuschließen ist.

Im folgenden Schritt 23 erfolgen eine oder mehrere Abfragen zum Zustand, die insbesondere die Vollständigkeit und Konsistenz betreffen. Im Falle von Inkonsistenzen oder Unvollstandigkeiten wird in den Zweig 28F verzweigt und in Schritt 24 eine entsprechende Warnung ausgegeben. Anderenfalls wird Schritt 24 durch Auswahl des Zweiges 24T unterdrückt.

Im folgenden Schritt 25 wird ein Zeiger der Übergangsbedingung mit dem Index m ausgelesen und in Schritt 26 die Funktion State mit dem auf diese Weise ermittelten Zeiger als Parameter aufgerufen. Damit ergibt sich ein rekursiver Aufruf der Funktion State, durch den sichergestellt ist, dass alle möglichen Zustände und Zustandsübergänge berücksichtigt werden.

In Schritt 27 wird die Zählvariable m inkrementiert , um die nächste Übergangsbedingung zu prüfen. In Schritt 28 wird abgefragt, ob die Zählvariable m noch innerhalb erlaubter Grenzen liegt. Falls dies der Fall ist, wird in den Zweig 28T verzweigt, so dass dann wieder der Schritt 21 ausgeführt wird. Referenziert die Zählvariable m jedoch einen ungültigen Zustand, so wird in den Zweig 28F verzweigt und die Abfrage gemäß Schritt 29 ausgeführt. In dieser Abfrage gemäß Schritt 29 wird geprüft, ob die Zählvariable m einen Wert > 1 erreicht hat. Falls dies der Fall ist, wird die state-Funktion durch Wahl des Zweiges 29T beendet. Anderenfalls wird der Zweig 29F angewählt und in Schritt 30 die Warnung erzeugt, dass kein Folgezustand erreichbar ist.

Der Ablauf dieses Algorithmus ist durch den rekursiven Aufruf der Funktion State relativ komplex, aber anders nur sehr schwer realisierbar. Die Funktion State beginnt dabei mit dem Ausgangszustand gemäß Schritt 10 und prüft diesen nach den vorgegebenen Kriterien. Für den Fall, dass der Zustand bereits geprüft wurde, werden sämtliche Prüfungen, einschließlich der Aufrufe von Folgezuständen unterdrückt . Der rekursive Algorithmus geht zunächst die Zustände in der Reihenfolge der ersten in jedem Zustand genannten Übergangsbedingung durch, bis entweder kein Folgezustand mehr gefunden werden kann oder ein Zustand aufgerufen wird, der bereits geprüft wurde. Anschließend wird die zuletzt gewählte Übergangsbedingung des Zustandsautomaten auf die in der Datenbank nächste angegebene Übergangsbedingung verändert und der Algorithmus in gleicher Weise ausgeführt. Demnach werden die einzelnen Übergangsbedingungen des Initialisierungszustandes in der Regel zuletzt bearbeitet .

Die Figur 4 zeigt eine Anforderung für ein Radiogerät in der Blackbox-Darstellung. Dabei werden die einzelnen Schnittstellen, die die Verbindung des Geräts nach außen sicherstellen, spezifiziert, der interne Ablauf bleibt jedoch weitgehend unspezifiziert .

Die Anforderung 100 weist eine Blackbox 101, Eingabeschnittstellen 102, Ausgabeschnittstellen 103 sowie Störeinwirkungen 104 auf. Die Verarbeitung der von den Eingabeschnittstellen 102 eingehenden Signale, um die Signale der Ausgabeschnittstellen 103 zu erzeugen, sind der nicht näher spezifizierten Blackbox 101 vorbehalten.

Die Eingabeschnittstellen 102 weisen eine

Spannungsversorgung 110, einen Ein/Aus-Schalter 111, einen Frequenzbandschalter 112, einen Frequenzwähler 113 und einen Lautstärkenwähler 114 auf. Außerdem umfasst die Eingabeschnittstelle 102 einen Antennenanschluss 115, über den elektromagnetische Wellen empfangen werden können .

Die Ausgabeschnittstelle 103 umfasst einen Lautsprecher 120 sowie Leuchtdioden 121 zur Funktionskontrolle. An potentiellen Störungen 104 sind

Versorgungsspannungsschwankungen, elektromagnetische Fremdstrahlungen sowie Temperatureinflüsse zu berücksichtigen . Auf dieser Blackbox-Ebene ist der funktionelle Zusammenhang zwischen den einzelnen Signalen nicht spezifiziert. Die Vollständigkeitsprüfung dieser Anforderung beschränkt sich auf dieser Ebene daher in der Regel auf eine Vollständigkeitsprüfung der Schnittstellenbeschreibungen. Dies bedeutet, dass für sämtliche Eingangsschnittstellen 102 und

Ausgangsschnittstellen 103 die jeweiligen Signale vollständig beschrieben werden müssen, um eine erfindungsgemäße Vollständigkeitsprüfung zu bestehen. Bei Schaltfunktionen reichen dabei in der Regel Spannungspegeldefinitionen sowie eine maximale

Strombelastbarkeit aus. Beim Antenneneingang 115 müssen dagegen zusätzlich Übertragungsprotokolle und

Modulationsweisen spezifiziert werden, um das Zielsystem funktionssicher zu gestalten.

Wird bei diesem gezeigten Entwicklungsstand des Zielsystems eine Schnittstelle nicht vollständig definiert, können sich hierdurch im Zuge der Entwicklung sowie späteren Weiterentwicklung Widersprüche ergeben, welche der ordnungsgemäßen Funktion des Zielsystems entgegenstehen. Diese Widersprüche können grundsätzlich dazu führen, dass ein Entwickler einer Subkomponente bei dem Eingangssignal von bestimmten Voraussetzungen ausgeht, die nicht zutreffend sind. Es wird insbesondere im Bereich der Digitalelektronik oftmals angenommen, dass sämtliche Eingangssignale die Pegeldefinition der TTL- Logik befolgen, wenn nichts anderes spezifiziert ist. Bei analogen Geräten werden solche Annahmen in der Regel eher nicht gemacht. Wenn nun der Frequenzbandwähler 112 beispielsweise zwischen 0 Volt und 12 Volt schaltet, die Subkomponente, die dieses Signal auswerten soll, aber von TTL-Pegeln ausgeht, so kann dies zur Zerstörung der elektronischen Komponenten führen. Aufgrund derartiger Erwägungen ist es wichtig, alle

Schnittstellenbeschreibungen vollständig darzulegen. Um die Funktionalität des Zielsystems zu sichern, ist es daher zweckmäßig, diese Schnittstellenbeschreibungen mit dem erfindungsgemäßen Verfahren zu prüfen, so dass bei Spezifikationslücken entsprechende Warnungen oder Fehlermeldungen generiert werden. Diese zeigen dem Entwickler an, dass er eine lückenhafte

Schnittstellenbeschreibung erstellt hat, die entsprechend nachzubessern ist .

Die Figur 5 zeigt die Anforderung gemäß Figur 4 mit den darin enthaltenen Subkomponenten. Dabei wird zusätzlich zur bereits beschriebenen Schnittstellenbeschreibung eine funktionelle Beschreibung der Blackbox 101 gemäß Figur 4 eingefügt. Diese funktionelle Beschreibung umfasst verschiedene Subkomponenten 130, die wiederum Signale austauschen. Demnach benötigen die einzelnen Subkomponenten 130 wieder Schnittstellenbeschreibungen. Verschiedene Subkomponenten 130 nutzen dabei externe Schnittstellen der Anforderung 100. Da diese bereits vollständig definiert sind, entfällt hierbei jeder weitere Definitionszwang.

Allerdings tauschen die Subkomponenten 130 auch untereinander Signale aus. Zu diesem Zweck weisen die Subkomponenten 130 interne Schnittstellen 131 auf, die wiederum entsprechend spezifiziert werden müssen. Dabei werden die Schnittstellenbeschreibungen der

Subkomponenten 130 wiederum in gleicher Weise auf Vollständigkeit geprüft. Es ist allerdings möglich, einzelne Subkomponenten 130 von dieser

Vollständigkeitsprüfung auszunehmen, wenn diese Subkomponenten 130 zu einem bestimmten

Entwicklungsstadium noch nicht entwickelt sind oder die Entwicklung dieser Subkomponenten in den

Zuständigkeitsbereich anderer Entwickler fällt. Auf diese Weise kann die aufgrund der nicht vollständigen Schnittstellenbeschreibung zu erwartende Fehler- und Warnungsflut eingedämmt werden. Es versteht sich aber von selbst, dass zu einem entsprechend fortgeschrittenen Entwicklungszeitpunkt die Vollständigkeitsprüfung auch auf diese ursprünglich ausgenommenen Subkomponenten 130 erstreckt werden sollte.

Die Anforderung 100 gemäß Figur 5 enthält in der funktionellen Beschreibung einen Tuner 140, einen Verstärker 141, einen Lautsprecher 142, eine LED- Ansteuerung 143 und ein Netzteil 144.

Der Tuner 140 ist mit dem Antennenanschluss 115 und dem Frequenzbandwähler 112 verbunden. Zusätzlich ist damit zu rechnen, dass eine Störeinspeisung 104 in Form elektromagnetischer Wellen auftritt. Diese

Störeinstrahlung muss vom Tuner 140 entsprechend unterdrückt werden. Der Tuner 140 erzeugt dabei ein Niederfrequenzsignal 150, zu dem eine entsprechende Schnittstellenbeschreibung auf Subkomponentenebene zu erstellen ist. Der Verstärker 141 nimmt dieses Niederfrequenzsignal 150 entgegen, so dass für den Verstärker 141 diesbezüglich keine eigene

Schnittstellenbeschreibung erforderlich ist. Vielmehr wird auf die Schnittstellenbeschreibung des Tuners 140 Bezug genommen. Durch die Vollständigkeitsprüfung der SchnittStellenbeschreibungen wird erreicht, dass die SchnittStellenbeschreibungen der Subkomponenten in sich konsistent sind und nicht versehentlich für ein und dasselbe Signal unterschiedliche

Schnittstellenbeschreibungen hinterlegt sind. Damit ist eindeutig festgelegt, welches Niederfrequenzsignal der Tuner 140 liefern muss und was der Verstärker 141 erhält.

Der Verstärker 141 ist mit dem Lautsprecher 142 verbunden. Zu diesem Zweck erzeugt der Verstärker 141 ein verstärktes Signal 151, welches zur

Lautsprecheransteuerung geeignet ist. Auch hierfür muss eine entsprechende Schnittstellenbeschreibung hinterlegt sein, um die Vollständigkeitsprüfung zu bestehen. Die LED-Ansteuerung 143 steht mit dem Tuner 140, dem Verstärker 141 und dem Netzteil 144 in Verbindung. Auch diesbezüglich sind entsprechende

Schnittstellenbeschreibungen zu erstellen, die die ordnungsgemäße Signalverarbeitung durch die LED- Ansteuerung 143 ermöglichen. Das Netzteil 144 versorgt alle anderen Subkomponenten 130 mit den erforderlichen Spannungen. Auch hierfür müssen entsprechende Schnittstellenbeschreibungen hinterlegt sein, die sich aber auf Spannungswerte, Toleranzen und

Strombelastbarkeiten beschränken können. Durch die erfindungsgemäße Vollständigkeitsprüfung wird erreicht, dass potentielle Fehlerquellen bei der Entwicklung des entsprechenden Zielsystems frühzeitig erkannt werden und das Zielsystem insgesamt in sich konsistent definiert ist. Dadurch werden Fehler im Zielsystem reduziert, so dass dessen technische Funktionalität zuverlässiger wird.

Das gleiche Ziel könnte man grundsätzlich zwar auch erreichen, indem man Überwachungs- und

Redundanzkomponenten einbaut. Diese verlagern jedoch nur das Problem um eine weitere Ebene, zumal auch diese Komponenten fehlerfrei funktionieren müssen. Insbesondere bei einem Missverständnis in der Schnittstellendefinition würden auch Überwachungskomponenten in der Regel fehlschlagen. Damit löst der vorgeschlagene Ansatz der Prüfung der entsprechenden Anforderungen die gestellte Aufgabe wesentlich effizienter und zuverlässiger und sorgt für ein gut funktionierendes Zielsystem.