Achtung : Skript gibt den mündlichen Vortrag nur teilweise wieder !!!
                        

1. Warum Realzeit?

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.

2. Prozessrechner, eingebettete Systeme, hochverfügbare Systeme, Kontrolltheorie, Regelungstechnik

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]).

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.

Wie 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. M.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.

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.

3. Systemtheorie

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.

4. Anforderung an das Softwareengineering

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.

Während sich das Softwareengineering von Nichtrealzeit-Systemen meistens auf die konzeptuelle Modellierung von Software konzentrieren kann, ist im Falle von Realzeitsystemen die Einbeziehung der Hardware und ihrer Eigenschaften fast unausweichlich; nur wenn die benutzte Hardware nachweislich bestimmte Anforderungen erfüllt, kann auch die Software bestimmte Anforderungen erfüllen. Deswegen bedeutet das Engineering von Realzeitsystemen in der Regel nicht nur das Engineering von Software (also Software-Engineering (SWE)), sondern meist auch zugleich das Engineering der Harware. Man sollte daher vielleicht direkt von Real Time Engineering (RTE) sprechen.

Das Ziel des Designs ist es im allgemeinen, das zuvor modellierte Problem in ein konkretes System zu überführen, das sämtliche Anforderungen aus der Problemstellung löst. Dieses Überführung in ein konkretes System muss dabei in unterschiedlichem Umfang konkreten Umständen Rechnung tragen, die sich aus notwendigen Realisierungsbedinungen (wie z.B. Hardware, vorhandene Software, Umgebungseigenschaften) ergeben. Dazu gehören u.a. auch verabschiedete Standards, die bestimmte Aspekte eines Einsatzes des Systems regulieren.

Die beiden nachfolgenden Schaubilder zeigen drüberhinaus auch noch weitere Besonderheiten:

1. Während das SWE heute meist objektorientiert (OO) ist und als zentrale Konzepte Klassen mit Attributen und Methoden identifiziert, die miteinadner vernetzt werden, betrachtet das RTE primär Systeme, deren Ressourcen von Tasks beansprucht werden, die bestimmte Zeitintervalle bedienen müssen.




2. Da die im OO-SWE heute meist benutzen UML-Diagramme zur Repräsentierung von Klassen und deren Interaktionen nicht ausreichen, um die wichtigen Eigenschaften von Realzeitsystemen zu modellieren, findet man im Rahmen des RTE ganz andere konzeptuelle Mittel (Technische Tabellen, Taskgraphen, usw.), mit denen man die Modellierung vornimmt.




3. Selbst bei dem Einsatz von sogeannten Case-Tools im Rahmen des OO-SWE bleibt eine nicht geringe Menge an 'Wissen' ausserhalb der Modellierung, da die Modellierung nur die Repräsentation von allgemeinen Strukturen erlaubt. Dies hat zur Folge, dass bei der automatischen Generierung des Kodes die Rümpfe der beteiligten Methoden --sofern es sich nicht um von einem Hersteller 'vorfabrizierte Methoden handelt-- 'leer' sind; d.h. es bedarf abschliessend noch der 'Füllung' all dieser 'Modellierungslöcher'.




4. Im Falle des RTE ist dies in keiner Weise akzeptabel, d.h. die Modellierung muss vollständig sein, andernfalls können die notwendigen Garantien für das angeforderte RT-System nicht abgegeben werden.




5. Im Falle des RTE muss von den benutzten Architekturen auf jeden Fall gefordert werden, dass sie safety critical sind und dass dieser Tatbestand zertifiziert ist.

Diese spezifischen Anforderungen an ein RTE sollen im folgenen kurz weiter erläutert werden. Anschliessend wird ein Beispiel repräsentiert.

5. Anforderungen an die Betriebssysteme

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.

Dieser Letzte Tatbestand, dass RT-Systeme zertifizierbar sein müssen, hat weitreichende Konsequenzen (siehe dazu die interessanten Überlegungen in einem Whitepaper der Firma Lynuxworks vom September 2003) Meistens entsteht die Forderung einer Zertifizierung bei staatlichen Projekten, aber auch z.B. in der privaten Luftfahrt. Diese soll sowohl die Zuverlässigkeit wie auch die Sicherheit nach bestimmten Kriterien sicher stellen

Wie Untersuchungen der amerikanischen Regierung aufzeigten, scheiterten alle Projekte, die nicht in der Lage waren, die Aufgabenstellung sehr weitgehend auf kleine Module herunterzubrechen; ein 'zu grosser' Betriebssysmkern ist nicht zertifizierbar. Erst solche Systeme, die einen separierten kleinen Kern haben, dem man nach Bedarf beliebig Module zuschalten kann, lassen sich zertifizieren.

Diese Idee eines kleinen, sicheren Kernels gehen zurück auf Arbeiten von John RUSHBY, der 1989 in einem Artikel "Kernels for Safety?" schreibt: Work on "secure" systems has evolved an approach to systems design based on the idea of a "security kernel": a small component of the total system whose correctness is sufficient to ensure the security of the system as a whole. The attraction is that the expensive and difficult techniques needed to guarantee correct behavior need only be applied to the relatively small security kernel--yet the benefit will apply to the complete system. It is interesting and potentially rewarding, therefore, to enquire whether the security kernel approach can be extended to apply to properties other than security.

Die beiden zentralen Aufgaben, die solch ein Kern leisten muss, sind die Ermöglichung des Informationsflusses und die Datenseparation. Alles andere, kann auf andere Module ausgelagert werden. Man spricht hier auch vom Kernelspace und dem Userspace; im Kernelspace sind nur die zentralen Aufgaben lokalisiert, alles andere befindet sich im Userspace.

Diese Architektur erlaubt es, die Sicherheits-Regeln auf höchster Ebene --spricht: im Kenel-- so zu etablieren, dass sämtliche Module, die auf den Kern zugreifen, diese Sicherheits-Regeln beachten müssen. Man spricht hier von einer Mehr-Ebenen-Sicherheit ('Multi Level Security (MLS)').
START

6. Anforderungen an die Programmiersprachen

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]).

Eine mögliche Antwort bieten die gemeinsamen Kriterien/ Common Criteria (CC), zu denen das BSI - Bundesamt für Sicherheit und Informationstechnik schreibt: "Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik/ Common Criteria for Information Technology Security Evaluation (CC), Version 2.0" sind Ende im Mai 1998 unter Beteiligung Deutschlands, Frankreichs, Großbritanniens, Kanadas, der Niederlande und der USA abschließend fertiggestellt worden. Sie sind für die Bewertung der Sicherheitseigenschaften praktisch aller informationstechnischen Produkte und Systeme geeignet. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat dabei die Rolle des deutschen Partners übernommen und bei der Erarbeitung der Kriterien aktiv mitgewirkt. Die CC 2.1 sind durch die Internationale Standardisierungsorganisation (ISO) unter der Nummer 15408 ein internationaler Standard geworden. Die wenigen nichttechnischen Änderungen, die durch den Standardisierungsprozess der ISO notwendig geworden sind, wurden in der CC Version 2.1 durchgeführt. Die Version 2.1 wurde wie die Version 2.0 der Common Criteria gemäß BSI-Zertifizierungsverordnung im Bundesanzeiger offiziell bekannt gemacht. Erste Entwürfe einer gemeinsamen Evaluationsmethodologie (Common Methodology for Information Security Evaluation CEM), die der Entwicklung eines gemeinsamen Konzepts und einer abgestimmten Methodik für die Evaluierung auf Grundlage der CC dienen, sind entwickelt und veröffentlicht worden. (Siehe auch NIST: Common Criteria)

In den USA spielt daneben der Standard DO-178B der Federal Aviation Administration (FAA) zur Zertifizierung von Flugsystemen eine grosse Rolle. Für die Beziehung zwischen den Common Criteria (CC) und DO-178B gilt allgemein: "Common Criteria defines seven different levels called Evaluated Assurance Level (EAL). These levels are numbered from 1 to 7 with one being the lowest level and 7 being the highest. For the reader familiar with the DoD Orange Book (TCSEC 5200.28), EAL 7 is equivalent to an A system, 6 is B3, etc. (While Common Criteria does not require the use of EALs, they are generally accepted as the best means for defining the security level of target of evaluation (TOE). A TOE can be an OS, a firewall device, etc.)"

Dabei ist zu bachten, dass die FAA normalerweise keine einzelnen Komponenten zertifiziert, sondern nur komplette Systeme. Allerdings gibt es die Möglichkeit, Software als Removable Software Component [RSC] innerhalb eines zertifizioerten Systems zu behandeln und zu zertifizieren.

In einer Untersuchung von J. Alves-Foss, B. Rinker and C. Taylor (2002) findet sich zusätzliche charakterisierung des Verhältnisses von CC und DO-178B: "... software developed to DO-178B Level A standards will map closely to either an EAL 4 or 5 with some additional work. The additional work is to satisfy objectives generally not covered by DO-178B but they may be covered via good engineering practices. Examples include delivery mechanisms and vulnerability assessments. A DO-178B kernel's space partitioning generally will solve most of the problems related to information flow since there is no sharing of memory between partitions. This is generally done to protect partitions from one another. In addition, the time partitioning used in DO-178B kernels will prevent system resources from being monopolized by a single partition, often a concern for secure systems. These two features provide most of what will be needed in a secure kernel.

Es ist allgemeine Überzeugung, dass zur Erreichung eines EAL 7 Rating --vorausgesetzt der Kernel ist sehr klein und umfasst nur die minimalen Funktionalitäten für Informationsfluss und Datentrennung-- formale Spezifikationsmethoden notwendig sind.

Ein Beispiel für ein RT-System, das von der FAA für den DO-178B Level A standard zertifiziert ist LynxOS-178 von LynuxWorks.

Neben den Standards CC und DO-178B sei hier noch erwähnt POSIX und ISO9001

START

Die Strategie des kleinen Betriebssystem-Kerns löst zwar das Problem für den Kern selbst, lässt aber dann zunächst offen, wie man diesen kleinen Kern mit den übrigen Modulen verbindet. Ein naheliegender Ansatz besteht hier darin, die Zugriffe auf den Kern soweit wie möglich zu standardisieren. Dieser Anspruch wird z.B. von POSIX eingelöst. POSIX ist ein Acronym für Portable Operating System Interface und ist eng mit der Geschichte von UNIX verbunden ( bis hin zum heutigen Linux). Die aktuelle Version des POSIX-Standards findet man unter 2003 Edition of IEEE Std 1003.1 (known as "POSIX.1".

POSIX wurde zusammen entwickelt von IEEE und The Open Group. Es ist zugleich ein IEEE Standard und ein ISO/IEC Standard sowie ein Open Group Technical Standard.

Die Open Group schreibt dazu: "Conceptually, this standard describes a set of fundamental services needed for the efficient construction of application programs. Access to these services has been provided by defining an interface, using the C programming language, a command interpreter, and common utility programs that establish standard semantics and syntax. Since this interface enables application writers to write portable applications-it was developed with that goal in mind-it has been designated POSIX,1 an acronym for Portable Operating System Interface."

"Although originated to refer to the original IEEE Std 1003.1-1988, the name POSIX more correctly refers to a family of related standards: IEEE Std 1003.n and the parts of ISO/IEC 9945. In earlier editions of the IEEE standard, the term POSIX was used as a synonym for IEEE Std 1003.1-1988. A preferred term, POSIX.1, emerged. This maintained the advantages of readability of the symbol ``POSIX'' without being ambiguous with the POSIX family of standards."

"Several principles guided the development of this standard:

• Application-Oriented

  The basic goal was to promote portability of application programs across UNIX system environments by developing a clear, consistent, and unambiguous standard for the interface specification of a portable operating system based on the UNIX system documentation. This standard codifies the common, existing definition of the UNIX system.

• Interface, Not Implementation

  This standard defines an interface, not an implementation. No distinction is made between library functions and system calls; both are referred to as functions. No details of the implementation of any function are given (although historical practice is sometimes indicated in the RATIONALE section). Symbolic names are given for constants (such as signals and error numbers) rather than numbers.
  

• Source, Not Object, Portability

  This standard has been written so that a program written and translated for execution on one conforming implementation may also be translated for execution on another conforming implementation. This standard does not guarantee that executable (object or binary) code will execute under a different conforming implementation than that for which it was translated, even if the underlying hardware is identical.

• The C Language

  The system interfaces and header definitions are written in terms of the standard C language as specified in the ISO C standard.

• No Superuser, No System Administration

  There was no intention to specify all aspects of an operating system. System administration facilities and functions are excluded from this standard, and functions usable only by the superuser have not been included. Still, an implementation of the standard interface may also implement features not in this standard. This standard is also not concerned with hardware constraints or system maintenance.

• Minimal Interface, Minimally Defined

  In keeping with the historical design principles of the UNIX system, the mandatory core facilities of this standard have been kept as minimal as possible. Additional capabilities have been added as optional extensions.

• Broadly Implementable

The developers of this standard endeavored to make all specified functions implementable across a wide range of existing and potential systems, including:

1. All of the current major systems that are ultimately derived from the original UNIX system code (Version 7 or later)

2. Compatible systems that are not derived from the original UNIX system code

3. Emulations hosted on entirely different operating systems

4. Networked systems

5. Distributed systems

6. Systems running on a broad range of hardware

No direct references to this goal appear in this standard, but some results of it are mentioned in the Rationale volume."

Hier ein grober Überblick über die Struktur des POSIX-Standards. Für Details siehe die das Dokument selbst:

1. POSIX.1: POSIX core services (the feature set usually found in UNIX® operating systems)

2. POSIX.1b: real-time extensions

3. POSIX.1c: thread extensions

POSIX.1 Core Services (incorporates Standard ANSI C)

• Process Creation and Control

• Signals

• Floating Point Exceptions

• Segmentation Violations

• Illegal Instructions

• Bus Errors

• Timers

• File and Directory Operations

• Pipes

• C Library (Standard C)

• I/O Port Interface and Control

POSIX.1b Real-time extensions

• Priority Scheduling

• Real-Time Signals

• Clocks and Timers

• Semaphores

• Message Passing

• Shared Memory

• Asynch and Synch I/O

• Memory Locking

POSIX.1c Threads extensions

• Thread Creation, Control, and Cleanup

• Thread Scheduling

• Thread Synchronization

• Signal Handling

Wichtige Begrife zur Identifizierung einer vorhandenen POSIX-Konformität sind hier conformance und compliance. POSIX conformance bedeutet, dass der POSIX.1 Standard vollständig implementiert ist. Das Vorliegen einer conformance mus von einer akkreditierten, unabhängingen Zertifizierungs-Autorität zertifiziert worden sein. POSIX compliance bedeutet, dass eine Dokumentation verfügbar ist, aus der hervorgeht, welche Eigenschaften von POSIX unterstützt werden und welche nicht.

Als wesentliche Eigenschaften für POSIX-konforme Systeme gilt:

1. Eigener Namensbereich mit separater Symboltabelle

2. Unterstützung für den fork() call

3. Unterscheidung zwischen threads und Prozessen

4. Die Verfügbarkeit von Signalen

Ein konkretes Beispiel für ein POSIX1.b+c zertifiziertes System ist LynxOS von LynuxWorks.

START

Wind River, gegründet in 1981, bekanntgeworden mit dem RT-System VxWorks; heute grosses Spektrum, z.B. Tornado@II, Platform NE

LynuxWorks, gegründet ca. 1988, RT-System LynxOS (RT-OS), BlueCat® (embedded)

FSMLabs, Entwicklung 1995-97 von RTLinux

RTAI, eigentlich keine Firma, sondern ein Fachbereich der Universität von Mailand; erste Ideen vor 1998, ernsthafte Arbeit dann aber erst ab 1998 als der Linux Kernel 2.1.x.x. gestalt annahm.

SYSGO AG, gegründet 1991; kein eigenes Betriebssystem, aber Serviceanbieter auf hohem Niveau mit Entwicklungsumgebung ELinOS, Vertrieb von LynxOS in Deutschland

START

10. Testfragen und Übungen

Übungsaufgaben werden in der Übung bekannt gegeben werden.

1. Warum sind Realzeitsysteme wichtig?




2. Was unterscheidet einen Prozessrechner von einem 'normalen' Rechner?




3. Wie würden Sie einem/r KollegenIn beschreiben, was ein Prozess ist? Welche Rolle kann ein Prozessrechner im Kontext von Prozessen spielen?




4. Warum benötigt man formale Modelle zur Beschreibung von Realzeitsystemen?




5. Beschreiben sie den Zusammenhang zwischen Kontrolltheorie, Regelungstheorie und Systemtheorie?




6. Welcher Zusammenhang besteht zwischen Realzeitsystemen, eingebetteten Systemen und hochverfügbaren Systemen?




7. Was leistet die Systemtheorie im Kontext von realzeitsystemen?




8. Worin liegt der spezifische Beitrag des Softwareengineerings? Welche rolle spielt hier UML?




9. Welche speziellen Anforderungen ergeben sich durch Realzeitsysteme für Betriebssysteme?




10. Welche Anforderungen durch Realzeitsysteme sind für Programmiersprachen besonders wichtig? Welche Mechanismen in bekannten Programmiersprachen stehen einem Einsatz in Realzeitsystemen entgegen?