· Startseite

Geplante Arbeiten: Zwischenschichten

 

· Konsortium
· Ausgangspunkt
· Arbeitsplan
  · Arbeiten
    · Schicht 1
    · Schicht 2
    · Schicht 3
· Presse
· Impressum
· Intern
·

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.

Beispiel: Worst-Case-Antwortzeit eines Tasks
Beispiel: Worst-Case-Antwortzeit eines Tasks

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:

  1. Eine frühzeitige Vorhersage des Zeitverhaltens, welches sich als Folge der Systemintegration ergeben wird.
  2. Die Bestimmung der Robustheit (Sensitivität) des Zeitverhaltens des Gesamtsystems gegenüber lokalen Änderungen.
  3. 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

AbsInt
Angewandte Informatik GmbHDeutsches Forschungszentrum
für Künstliche Intelligenz GmbHTechnische Universität DresdenInstitut für Datentechnik
und Kommunikationsnetze
an der TU BraunschweigScopeSet Technology Deutschland GmbHaicas GmbHTechnische Universität MünchenSymtavision Stand: 08/2006
Siegel des Bundesministeriums
für Bildung und Forschung