In einem Verfeinerungsschritt werden Komponenten
aus der nächsthöheren Schicht in kleinere Komponenten aufgespalten.
Dies richtet sich nach den vorgebenden Funktionalitäten der angenommenen
Steuergeräte.
Nachzuweisen ist in diesem Fall, daß es sich um eine
gültige Verfeinerung handelt (Thema des Arbeitspakets 5),
sprich daß die nachgewiesenen Eigenschaften der oberen Modelle erhalten
bleiben. Dabei kommen hybride (zeitabhängige) Automaten, sowie VSE
als interaktives Beweissystem zum Einsatz (Arbeitspaket 4).
Mehrere derartige Verfeinerungsschritte sind hier
vorstellbar, gar wahrscheinlich. Beispielsweise wird ein zu realisierendes
Steuerungssystem ständig in einer implementationsnäheren Weise
spezifiziert — sei es durch eine Datentypverfeinerung oder
durch Konkretisierungen abstrakter Schritte innerhalb des Modells —
ohne allerdings die Hardwareunabhängigkeit zu verlieren (Arbeitspakete
4 und 5).
Desweiteren spielt — beispielsweise bei der
Codegenerierung — die modellbasierte Beschreibung von
Ressourcenanforderungen in diesen Schichten eine wichtige Rolle.
In diesem Zusammenhang sind die von ScopeSET
entwickelten Methoden und Werkzeuge, die in
Arbeitspaket 2 eine wesentliche Rolle spielen,
zur Definition entsprechender UML-Profile interessant.
Von besonderem Interesse ist dabei ein Transformator,
wie er in Ameos mit ACD
als templategesteuerte Transformation bereitsteht. Dieser könnte
einerseits alle Ressourcen aufsammeln und darstellen, sodaß ein
Benutzer diese überprüfen kann. Andererseits könnte er Transformationen
so formulieren, daß sie nach bestimmten Ressourcenanforderungen
optimieren (ebenfalls Arbeitspaket 2). Dazu
werden Transformationen von UML-Elementen bezüglich ihrer Ressourcen
als Modell beschrieben, wobei je nach Ressourcentyp unterschiedliche
Transformationen zum Einsatz kommen können (Arbeitspakete
2, 4 und 5).
Unterstützend kann eine Giotto-artige Beschreibung
(Arbeitspaket 4) des Steuerungssystems (harte)
Realzeiteinschränkungen annehmen bzw. verlangen, deren Erfüllung nur
durch die Annahme spezieller Zielprozessoren zu garantieren ist.
Ebenso wie in den oberen Schichten ist auch hier ein
Verfeinerungsnachweis zu erbringen (Arbeitspaket 5)
und zu zeigen, daß auch auf dieser Stufe die globalen Eigenschaften
erhalten bleiben.
In den einzelnen Zwischenschichten werden ausgehend
von einem Systemmodell in verschiedenen Sprachen/Formalismen Anforderungen
an das Systemmodell in einer Anforderungsspezifikation formuliert.
Ausgangspunkt ist hier die Vorstellung, daß die Sprachmittel, die
für die Anforderungspezifikation bzw. die Systemspezifikation zur
Verfügung stehen, im allgemeinen nicht identisch sind. Dies hat
pragmatische Gründe, aber auch die Adäquatheit der Beschreibungssprache
zur Ursache.
Das Problem des Nachweises, daß die Systemspezifikation
die an sie gestellten Anforderungen erfüllt, ist in diesem Kontext durch
die Verschiedenheit der Sprachen zusätzlich erschwert. Desweiteren sind
die Sprachmittel zur Beschreibung der Anforderungen oftmals bereits
mächtig genug, um in ihnen Eigenschaftsnachweise zu führen bzw. aus
ihnen Folgerungen zu schließen, die später ebenfalls für das zu
entwickelnde System gelten sollten. Hier stellt sich die Aufgabe,
die Brücke, die die Systemspezifikation und die Anforderungspezifikation
verbindet, in der Art zu bauen, daß diese Eigenschaften aufgrund der
verwendeten Technik möglichst ohne zusätzlichen Beweisaufwand gelten sollten.
Der im SuReal-Projekt verfolgte Lösungsansatz der
Beobachter-Modelle ordnet sich durch eine horizontale Strukturierung
in das Gesamtszenario ein. Man geht von verschiedenen Sprachmitteln aus,
mit denen unterschiedliche Realzeitanforderungen auf den verschiedenen
Schichten formuliert werden. Mithilfe der Beobachter-Modelle wird eine
einheitliche konsistente Sicht auf die spezifizierten Anforderungen ermöglicht.
In den niederen Schichten spielen die Auswirkungen
auf das Zeitverhalten als Folge der Systemintegration auf vernetzten
Mehrprozessor-Architekturen eine große Rolle. Dies wird in
Arbeitspaket 6 speziell behandelt.
Durch den Einsatz von Betriebsystemen und arbitrierenden
Busprotokollen entsteht eine Vielfalt neuer Abhängigkeiten: Unterbrechungen,
Blockierungen, Warten auf externe Ereignisse usw. Als Beispiel zeigt das
folgende Bild die Worst-Case-Antwortzeit eines Software-Tasks unter
Berücksichtigung aller möglichen Unterbrechungen und der
betriebssystembedingten Verzögerungen.
Diese Abhängigkeiten beeinflussen das Zeitverhalten
einzelner Abläufe auf schwer vorhersagbare Weise. Eine solche
Unvorhersagbarkeit ist ein großes Risiko für die Zuverlässigkeit des
fertigen Systems. Deshalb sind die folgenden Anforderungen zu berücksichtigen:
- Eine frühzeitige Vorhersage des Zeitverhaltens, welches sich als
Folge der Systemintegration ergeben wird.
- Die Bestimmung der Robustheit (Sensitivität) des Zeitverhaltens
des Gesamtsystems gegenüber lokalen Änderungen.
- Eine systematische Optimierung der Elektronik-Architektur, z.B.
hinsichtlich Kosten und Erweiterbarkeit.
Es zeigt sich, daß in all diesen Zwischenschichten
die Beschreibungstechniken aus Arbeitspaket 4
und die Verfeinerungsbeweise aus Arbeitspaket 5
durchgehend (vertikal) zur Durchsetzung der Sicherheitsziele
benötigt werden.
· Prozessorschicht
|