|
|
I-RT REALZEITSYSTEME WS0304
|
Warum eine Vorlesung zum Thema 'Realzeitsysteme'?
Wir sindes mittlerweile gewohnt, nahezu immer und überall von technischen Systemen umgeben zu sein, die für uns unterschiedlichste Dienstleistungen erbringen. Diese Dienstleistungen sind mehr oder weniger nützlich.
In einer Reihe von Situationen ist es für uns wichtig, dass diese Dienstleistungen innerhalb eines gewissen Zeitrahmens erfolgen, da sie sonst ihre Nützlichkeit einbüssen(Bearbeitung von Anfragen, Bearbeitung von Aufträgen, Auswertung von Messwerten, Reaktion auf bestimmte Ereignisse...) oder gar gefährlich werden, lebensgefährlich (Beschleunigung und Bremsen von Fahrzeugen, Kollisionsentdeckung bei Flugzeugen, Überwachung von Patienten in der Intensivstattion, Abschalten von (Kern-)Kraftwerken usw.)
Es sind diese zeitkritischen Prozesse, die eine Beschäftigung mit Realzeit nahelegen bzw. erzwingen. Wie sich im Verlaufe der Vorlesung zeigen wird, kann die Anforderung der Realzeit die Architektur und die Programmierung von Systemen erheblich verändern; vieles, was bei nicht-zeitkritischen Prozessen ('weiche Realzeit', 'soft realtime') in der Regel 'geht', ist bei zeitkritischen Prozessen ('harte Realzeit', 'hard realtime') von vornherein ausgeschlossen. Dieser Unterschied ist so fundamental, das es in der Regel nicht möglich ist, aus 'weichen' Realzeitsystemen im Nachheinein 'harte' Realzeitsysteme zu machen. Ein Umstand, der bei vielen Softwareentwicklungsprozessen heute noch immer unterschätzt wird (selbst bei Forschungsprogrammen von so renommierten Institutionen wie der DFG (:= Deutsche Forschungsgemeinschaft).
Das immer weitere Vordringen von mikroprozessorgesteuerter Technologie in nahezu alle Lebensbereiche, speziell auch solche, die für Menschen 'kritisch' sind, intensiviert die Bedeutung von 'harten Realzeitsystemen'. Möglicherweise ist es nicht zu hoch gegriffen, wenn man sagt, dass 'harte Realzeitsysteme' die Basis für die gesamte zukünftige mikroprozessorbasierte Technologie darstellen werden. Hierin klingt eine enorme gesellschaftliche Bedeutung dieser Technologie an, der entsprechende umfangreiche Anstrengungen im Ausbildungsbereich korrespondieren müssen, will die Ausbildung den gesellschaftlichen Anforderungen gerecht werden.
Im Kontext des Begriffs 'Realzeitsysteme' hört man immer wieder auch Begriffe wie 'Prozessrechner', 'eingebettete Systeme', 'Hochverfügbarkeit' sowie 'Kontrolltheorie' bzw. 'Regelungstechnik'.
Die Zusammenhänge sind fliessend.
Kollege Eric JACOBSON [JACOBSON 1996:1ff] verweist bei der Einführung des Themas Prozessrechner auf den Kontext der Automatisierung. Überall dort, wo versucht wird, konkrete Prozesse mit Hilfe maschineller Systeme zu steuern oder gar zu regeln, müssen Daten von Prozessen verarbeitet werden. Zu diesem Zweck benötigt man technische Vorrichtungen, die zu solch einer Prozessdatenverarbeitung geeignet sind, eben Prozessrechner.
Vom Grundansatz her sind solche Prozessrechner nichts anderes als Computer. Was Prozessrechner von 'normalen' Rechnern unterscheidet, das ist normalerweise eine spezifische Aufgabenstellung, die sie unabhängig von einem Menschen --nicht aber notwendigerweise ohne Interaktion mit einem Menschen-- erfüllen sollen. Vorausgesetzt es gibt einen einigermassen definierten Prozess mit spezifischen Kennwerten und Parametern werden Prozessrechner in der Regel dafür gebaut, einen solchen Prozess innerhalb eines klar vereinbarten Rahmens zu regeln. Typischerweise sind dies Regelungsaufgaben, die für einen Menschen entweder zu monoton sind (einfache Arbeiten mit vielen Wiederholungen) oder die die Grenzen der menschlichen Fähigkeiten übersteigen.
Typische Anforderungen, die gewöhnlich an Prozessrechner gestellt werden:
Möglichst flexible Kopplung an bestehende Systeme
Einhaltung von zeitlichen Vorgaben, Zuverlässig (Realzeit)
Korrekte Erfüllung aller Anforderungen
Robust gegen Umwelteinflüsse
Leicht zu warten
Kostengünstig (Anschaffung, Betrieb)
Möglichst kleine Abmessungen
Umweltverträglich
Es wurde eben schon gesagt, dass der Einsatz eines Prozessrechners einen definierten Prozess voraussetzt. Eine erste informelle Beschreibung von Prozessen ist die folgende (vgl. auch JACOBSON[JACOBSON 1996:6ff]).
Prozessrechner mit Prozess
Ein Prozess ist in diesem Bild eine Zustandsmenge, die durch folgende Eigenschaften ausgezeichnet sein kann:
Aufgrund der Struktur des Prozesses gibt es bestimmte Kennwerte, die festliegen und sich normalerweise nicht ändern.
Demgegenüber gibt es Parameter, die sich ändern können.
Einem Prozess kann einen Zufluss besitzen, der sich mittels messbaren Grössen beschreiben lässt.
Ebenfalls kann ein Prozess einen Abfluss besitzen, der sein Verarbeitungsgut darstellt.
Der Abfluss eines Prozesses stellt zugleich auch eine Rückwirkung auf den Prozesszustand dar.
Zusätzlich zum definierten Zufluss kann ein Prozess auch noch anderen Zufluss besitzen, der gegenüberdem vereinbarten Zufluss als Störgrösse auftritt.
En Prozessrechner kann einmal dadurch an einen Prozess gekoppelt sein, dass er gewisse Messgrössen vom Prozesszustand bekommt, die dem Prozessrechner dann als Eingangsdaten vorliegen.
Neben den 'normalen' Messgrössen kann es spezielle Messgrössen für ausgezeichnete ('kritische') Wertegeben, die als Alarmgrössen gelten und die als spezielle Eingangsgrössen ('Ereignisse') erfasst werden.
Umgekehrt kann ein Prozessrechner auch über Ausgabedaten an einen Prozess gekoppelt sein. In diesem Fallwirken die Ausgabedaten des Prozessrechners als Stellgrössen für den Prozess.
Dies ist wie gesagt nur eine mögliche Beschreibung für einen Prozess. Weitere werden wir noch kennen lernen.
Prozess - Prozessrechner - Steuerungsrechner (Bsp. von der Firma Sysgo AG)
Was man aus diesen Überlegungen ersieht, kann man einen Prozess nur in dem Masse steuern kann, wie man ihn angemessen beschreiben kann. Nur dann, wenn es auf der Basis einer klaren Beschreibung eines Prozesses gelingt, ein entsprechendes Modell im Prozessrechner zu implemenieren, kann der Prozessrechner die Messgrössen und Alarme in der richtigen Weise 'interpretieren' und in die entsprechendenStellgrössen umsetzen. N.a.W. die Qualität eines Prozessrechners hängt nicht nur von der Qualität seiner technischen Realisierung ab, sondern vor allem und in erster Linie von der Qualität des Modells, das seiner Konstruktion und Programmierung zugrunde liegt.
Konstruktion eines Systems mittels eines Modells
Die Unterscheidung zwischen 'Modell' und 'System' im Schaubild ist nicht absolut zu nehmen. Die Terminologie geht in der Literatur unterschiedliche Wege. Man muss im Einzelfall den Sprachgebrauch der verwendetenDisziplinen überprüfen, wie der Begriff des Modells verwendet wird.
Im allgemeinen wird es ausreichen zwischen den Daten und dem Modell zu unterscheiden, das diese Daten interpretiert.
Vor dem Hintergrund dieser Beschreibung eines Prozessrechners wird deutlich, dass die Abgrenzung zu Realzeitsytemen kaum möglich ist; Prozessrechner sind per se Realzeitsysteme.
Berücksichtigt man ferner, dass der Konstruktion von Prozessrechnern --bzw. Realzeitsystemen-- in den meisten Fällen formale, mathematische Modelle zugrunde liegen müssen, da sich ansonsten das Leistungsverhalten der Rechner kaum angemessen beschreiben lässt, ist die Brücke zur sogenannten Kontrolltheorie und Regelungstechnik schnell geschlagen.
Üblicherweise versteht man unter Kontrolltheorie jene Disziplin, die mathematische Modelle für beliebige zeitvariierende Inputs von Systemen erstellt (siehe z.B.: Fritz COLONIUS/ Wolfgang KLIEMANN [2000]). Dies ist weitgehend deckungsgleich mit den Inhalten der der Regelungstechnik (siehe z.B.: G.SCHULZ [2002]).
Wie sich in den weiteren Vorlesungen zeigen wird, kann man diese unterschiedlichen formalen Ansätze einheitlich unter dem Konzept der allgemeinen Systemtheorie subsumieren und dort behandeln (siehe weiter unten und z.B.: George J.KLIR [1991]).
Der Zusammenhang mit eingebetteten Systemen ('embedded systems') besteht darin, dass ein Grossteil der heutigen Prozessrechner und Realzeitsysteme in andere technische Systeme 'eingebettet' werden (z.B.: innerhalb von Fertigungs-Maschinen zur Steuerung, innerhalb von Autos, von Flugzeugen, von Küchenmaschinen, von mobilen Telefonen, usw.).
Ferner besteht vielfach ein natürlicher Zusammenhang zwischen zeitkritischen Systemen ('harten Realzeitsystemen') und hochverfügbaren ('safety critical') Systemen, da hochverfügbare Systeme sich dadurch auszeichnen, dass ein bestimmtes Verhalten innerhalb klar vorgegebener Randbedingungen garantiert werden muss; der häuffigste und wichtigste Parameter ist dabei die Zeit. Da eine 'Garantie' voraussetzt, dass man beweisen kann, dass die Leistung bei Vorliegen bestimmter Randbedingungen auf jeden Fall verfügbar ist, ergibt sich von hier der natürliche Anknüpfungspunkt, warum harte Realzeitsysteme mit hoher Verfügbarkeit fast ausschlieslich auf der Basis expliziter fomaler (mathematischer) Modelle konstruiert werden. Ohne solche expliziten formalen Modelle sind Beweisführungen kaum möglich.
Wie eben schon deutlich wurde, verlangen Realzeit und Verfügbarkeit ein Ausmass an Transparenz und Zuverlässigkeit bei der Beschreibung von technischen Systemen und den durch sie kontrollierten Prozessen, dass es ohne eine leistungsfähige Formalisierung in diesen Bereich nicht geht. Wie die einschlägige Literatur zeigt, kann diese Formalisierung beliebig komplex werden. Auf dieser Herausforderung können wir in dieser Vorlesung nur ansatzweise reagieren. Das Hauptaugenmerkt wird darauf liegen, einen formalen Ansatz einzuführen, der allgemein genug ist, um alle denkbaren Formalisierungsaufgaben lösen zu können, und doch auch zugleich einfach genug, um einen Einstieg zu erlauben. Für diese Zwecke ist die allgemeine Systemtheorie ideal geeignet (siehe etwa [PICHLER 1975] und [KLIR 1991]).
Die Grundidee der allgemeinen Systemtheorie besteht darin, die technischen Systeme auch mathematisch als Systeme zu betrachten, die beliebige Inputmengen in beliebige Outputmengen abbilden können.
[KLIR 1991:9] beschreibt ein System S als ein geordnetes Paar S = (O,R). 'O' ist dabei eine Menge irgendwelcher --beliebig komplexer-- Objekte und 'R' ist eine Relation über dieser Menge O. In vielen Fällen ist die Relation R eine Funktion, so dass gilt:
R : O ---> O
Diese Definition ist so allgemein, dass darunter nahezu jedes konkrete System fallen kann. Auch könnte man die gesamte Kontrolltheorie von hier aus entwickeln. In diesem Sinne ist die allgemeine Systemtheorie eine Obermenge zur Kontrolltheorie.
Interessant für die Konstruktion eines Systems ist noch die grundsätzliche Aussage von KLIR,
"Every system is a construction based upon some world of experiences, and these, in turn, are expressed in terms of purposeful distinctions made either in the real world or in the world of ideas." [KLIR 1991:13].
Basierend auf der mathematischen Strukturtheorie [BOURBAKI 1970] wurden die Fragen der Systemidentifizierung, des Messens, der Modellbildung und der formalen Eigenschaften von Modellen als Theorien auch in der modernen Wissenschaftstheorie untersucht (vgl. etwa [BALZER 1982], [W.BALZER/ C.U.MOULINES/ J.D.SNEE 1987], [LUDWIG1978, 1978b]). Hier allerdings in noch grösserer Allgemeinheit als in der Systemtheorie; man kann sagen die allgemeine Systemtheorie ist ein Spezielfall einer allgemeinen Strukturtheorie. In der allgemeinen Strukturtheorie untersucht man nicht einfach nur Systeme, sondern ganze Theorien.
T(x) gdw x =< <M, ... >, <R, ... >, A>
Eine Theorie T besteht dann aus einer ganzen Folge von Mengen, entsprechend einer ganze Folge von Relationen bzw. Funktionen, die über diesen Mengen typisiert sind. Ferner werden auch die Axiome A in die Untersuchung mit einbezogen. Während dies den Strukturkern schildert, gibt es unterschiedliche Ansätze, wie man die Koppelung eines solchen Stukturkerns 'an die empirische Wirklichkeit' beschreibt und realisiert. Letztlich ist solch eine abstrakte Struktur zur Beschreibung von realen Prozessen ja nur dann brauchbar, wenn geklärt ist, wie sie in Beziehung gesetzt werden kann zu Messdaten.
Bevor wir näher auf Beispiele systemtheoretischer Analysen eingehen, sei aber auch noch der Zusammenhang mit dem Softwareengineering hingewiesen.
Die soeben herausgearbeitete Notwendigkeit, den zu steuernden Prozess sowie das dazu notwendige steuernde System formal zu modellieren entspricht natürlich strukturell auch dem Paradigma des Softwareengineerings (siehe z.B. [ELLIS1994]).
Wie das nachfolgende Schaubild verdeutlicht, ist es ein wesentlicher Bestandteil des Softwareengineering-Prozesses, nach einer Erfassung der spezifischen Problemanforderungen, diese in ein formales Modell zu überführen.
Während im Rahmen der der Systemtheorie der Schwerpunkt auf der Erstellung formaler --meistens mathematischer-- Modelle liegt, mit dem Zwecke, bestimmte Eigenschaften beweisen zu können, ist das Softwareengineerung normalerweise eher an solchen Modellbildungen interessiert, die eine möglichst zuverlässige Implementierung der formalen Modelle auf konkreten Systemen ermöglicht. Die Entsprechung zu den eingangs formulierten Anforderungen ('requirements') muss nachweisbar sein, die Software sollte korrekt und vollständig sein, zugleich sollte sie wartbar sein und --wünschenswerterweise-- skalierbar.
Als Quasi-Standard im Bereich des Softwareengineerings hat sich für die Modellierung UML durchgesetzt. Obwohl dies für viele Aspekte der Modellierung sehr hilfreich ist, zeigt sich gerade im Kontext von Realzeitsystemen, dass diese Art der Modellierung erhebliche Schwächen gegenüber einem systemtheoretischen Ansatz aufweist. Zwar lassen sich die UML-Konstrukte prinzipiell alle in systemtheoretische Konstrukte übersetzen, nicht aber umgekehrt.
Das strukturelle Problem in der Beziehung zwischen Systemtheorie und UML, das sich hier andeutet, kann in dieser Vorlesung nicht gelöst werden. Es soll versucht werden, beide Verfahren bei der Modellierung zu benutzen und es soll exemplarisch eine erste 'Sensibilisierung' für das hier herrschende und bislang noch ungelöste Problem geschaffen werden. Oberstes Ziel bei der Modellierung von Realzeitsystemen muss sein, alle entscheidenden Faktoren für die Erfüllung einer zeitkrritischen Aufgabe so zu modellieren, dass das Zusammenspeil hinreichend transparent ist, um die Verfügbarkeit beweisbar zu machen.
Da die formalisierten Modelle letztendlich auf konkreter Hardware ablaufen müssen, ist die Frage der Implementierung keinesfalls sekundär, sondern nahezu gleichberechtigt zur Frage der Modellierung. Ein explizites formales Modell nützt nur etwas, wenn es zugleich eine entsprechend transparente und zuverlässige Hardware gibt. Im Falle von Mikroprozessoren ist die Hardware selbst von einer gewissen Komplexität und umschliesst von vornherein einen nicht unbeträchtlichen Anteil an Software, die den Mikroprozessor in Form von Microcode in seinem grundsätzlichen Verhalten steuert. Da heute in der Regel die jeweilige Anwendungssoftware nicht direkt auf den Mikroprozessor zugreift, sondern vermittelt durch ein Betriebssystem, ist das Betriebssystem bei der Implementierung mit zu berücksichtigen.
Das Betriebssystem stellt in diesem Zusammenhang die Kommunikationsschnittstelle zwischen Anwendungssoftware und Mikroprozessor dar und verwaltet darüberhinaus die verfügbaren Ressourcen; letzteres bedeutet, dass im Falle von mehreren Prozessen innerhalb definierter --und garantierter!-- Zeitscheiben eine Ressourcenzuteilung zu diesen verschiedenen Prozessen vorgenommen werden muss, die konfliktfrei und zuverlässig sein muss.
Die Erfahrung zeigt, dass eine Garantie für die Einhaltung dieser Eigenschaften in Form einer Zertifizierung in der Regel nur leistbar ist, wenn das Betriebsystem möglichst einfach und transparent ist. Dies ist mit den heutigen verfügbaren Methoden letztlich nur mit Mikrokernen oder Exokernen möglich.
In der Vorlesung werden wir uns ansatzweise mit einer einfachen Form eines Mikrokerns beschäftigen.
Das formale Modell eines Systems wird in der Regel in ein Anwendungsprogramm überführt, das mittels einer Programmiersprache P realisiert wird. Heute stehen eine Vielzahl von Programmiersprachen zur Verfügung, die sich durch unterschiedliche Spezialisierungen auszeichnen. Für die Anforderungen der harten Realzeit und der hohen Verfügbarkeit ist im Prinzip gleichgültig, welche Programmiersprache benutzt wird, solange garantiert werden kann, dass die spezifischen Anforderungen eingehalten werden können.
Es ist genau diese Garantieforderung, durch die eine Vielzahl von Sprachen als mögliche Kandidaten für ein Realzeitprojekt ausscheiden. Alle Sprachen, die z.B. ein automatisches Speichermanagement beeinhalten (wie z.B. C++ oder Java) stellen ein unkalkulierbares Risiko dar und kommen für harte Realzeit und hohe Verfügbarkeit nicht in Frage. Das gleiche gilt für solche Mechanismen im Kontext von objektorientierten Paradigmen, in denen diverse Konstruktoren in einer Weise aktiviert werden können, die nicht eindeutig voraussagbar sind.
In der Praxis spielt heute --de facto-- im Bereich von Realzeit und Verfügbarkeit nur eine einzige Sprache eine unumschränkte Rolle, und das ist die Sprache C, in vielfachen Kontexten zusätzlich begleitet von direktem Assemblerkode. Selbst die sprache ADA, die im Zeitraum 1979-1995 im Auftrag des amerikanischen Verteidigungsministeriums speziell für harte Realzeitanwendungen entwickelt worden ist, konnte sich nicht wirklich durchsetzen. Das neueste Kampffliegerprojekt Amerikas wird ofiziell in C abgewickelt und grosse internationale Luftfahrt-Konzerne benutzen wieder (!) C statt Ada (siehe z.B.: Michael JUNGMANN [2003], dazu auch Jörg MATTHES et al [2003]).
Übungsaufgaben werden in der Übung bekannt gegeben werden.
Warum sind Realzeitsysteme wichtig?
Was unterscheidet einen Prozessrechner von einem 'normalen' Rechner?
Wie würden Sie einem/r KollegenIn beschreiben, was ein Prozess ist? Welche Rolle kann ein Prozessrechner im Kontext von Prozessen spielen?
Warum benötigt man formale Modelle zur Beschreibung von Realzeitsystemen?
Beschreiben sie den Zusammenhang zwischen Kontrolltheorie, Regelungstheorie und Systemtheorie?
Welcher Zusammenhang besteht zwischen Realzeitsystemen, eingebetteten Systemen und hochverfügbaren Systemen?
Was leistet die Systemtheorie im Kontext von realzeitsystemen?
Worin liegt der spezifische Beitrag des Softwareengineerings? Welche rolle spielt hier UML?
Welche speziellen Anforderungen ergeben sich durch Realzeitsysteme für Betriebssysteme?
Welche Anforderungen durch Realzeitsysteme sind für Programmiersprachen besonders wichtig? Welche Mechanismen in bekannten Programmiersprachen stehen einem Einsatz in Realzeitsystemen entgegen?