Dann würde ich sagen, nachdem ich meinen Rechner endlich angeschlossen gekriegt habe, können wir auch anfangen.

Dann willkommen zur zweiten Ausgabe von den Echtzeitsystemen. Wir sind ja letztes Mal nicht ganz durchgekommen.

Das heißt, ich muss heute noch mal ein bisschen Gas geben, dass wir die beiden Kapitel 3.1 von letzter Woche und 3.2 für diese Woche dann auch tatsächlich noch schaffen.

Was haben wir uns letzte Woche angeguckt? Wir waren stehen geblieben bei der Erkenntnis, dass die physikalischen Parameter eine entscheidende Rolle darauf haben, wie wir unser Echtzeitsystem auslegen müssen.

Also da noch mal die Erinnerung an das Beispiel mit dem Quattrocopter. Woher wissen wir, wie oft wir oder mit welchen zeitlichen Konstanten wir da rechnen dürfen?

Das waren dann solche Sachen wie Massenträgheit oder die Kraft, die die Motoren aufbringen können.

Also letztendlich die Frage, wie viel Zeit braucht es, bis das System wieder in einem stabilen Zustand ist.

Da kann man sich im Prinzip auch ganz einfach merken, ein träges System werde ich natürlich nicht so oft oder nicht mit so engen zeitlichen Schranken steuern müssen als ein System, was halt sehr, sehr dynamisch ist.

Da sinken natürlich die Zeitkonstanten entsprechend ab.

Was wir noch nicht geschafft haben, war die Frage zu klären, was ist eigentlich der Einfluss des Rechensystems.

Das ist für mich immer so ein bisschen die Horrorvorstellung, aber im Prinzip mal so der Teil, der Ihnen ein Gefühl geben soll, was wir bisher nicht beaktet haben.

Also am ersten Moment klingt das ja relativ einfach. Wir haben ein Echtzeitsystem, wir müssen uns angucken, wie sieht die Physik aus, was ist das zu kontrollierende Objekt, welche Eigenschaften hat das, welche Zeitkonstanten können wir daraus ableiten.

Dann haben wir es geschafft. Das Problem ist natürlich, es ist weit gefehlt. Wir haben bisher das Echtzeitrechensystem noch gar nicht betrachtet und das wollen wir uns heute mal anschauen.

Das ist wieder so ein Ausflug, der so näher ein bisschen, ich will jetzt nicht sagen in die Untiefen der Informatik geht, aber das ist ein Ausflug, der uns tatsächlich in den Bereich der Betriebssysteme bringt, also das, wo ich ja ursprünglich herkomme.

Da auch nochmal der Hinweis darauf, also für all diejenigen, die es noch näher interessiert, schaut euch die Vorlesung Betriebssysteme an, da ist auch ein Pointer in den Folien drin.

Da ist das alles nochmal im Detail beschrieben, bzw. für die einzelnen Begriffe dann auch gerne auf Worshclosar, auch da gibt es dann die einzelnen Begriffe nochmal erklärt.

Was ich auch noch sagen muss, habe ich ganz vergessen, meine Stimme ist heute nicht die beste, also ich hoffe, dass wir durchkommen. Vergeben wir bitte, wenn das mal ein bisschen leiser wird.

Okay, also fangen wir an, anschalten sollte man es auch noch. Gut, also die Frage ist jetzt bei dem zeitlichen Verhalten von so einem Echtzeitsystem, worauf müssen wir eigentlich achten, also was sind denn die Elemente, die wir tatsächlich betrachten müssen, welche Ebenen müssen wir uns eigentlich anschauen.

Und das ist das, wo ich heute so ein bisschen den Fokus drauf lenken will, nämlich darauf, dass es eben nicht egal ist, das Rechensystem zu ignorieren und vielleicht auch die Eigenschaften, die die Hardware hat, zu ignorieren.

Das ist nämlich durchaus relevant. Und das bringt uns heute auf den Begriff der Verwaltungsgemeinkosten oder im englischen Overhead.

Also im Prinzip die Kosten, die entstehen dadurch, dass wir einfach eine Ausführungsplattform haben, das ist so ein generelles Problem, so ein gedankliches Problem, das man vielleicht häufig hat.

Im Unterschied zu alten Disziplinen wie vielleicht das Maschinenbau oder klassische Elektrotechnik haben wir nämlich das riesengroße Problem, wir schreiben Software und Software für sich hat aber erstmal keine Eigenschaften, sondern die Eigenschaften entstehen erst dadurch, dass wir sie auf einer Plattform zur Ausführung bringen.

Also wir haben noch eine Maschine, die unterhalb der Software liegt, nämlich die Hardware, der Prozessor, der das, was wir eigentlich entwickelt haben, erstmal zur Ausführung bringt.

Dummerweise hat der seine eigenen Eigenschaften und diese Eigenschaften können wir halt leider nicht ignorieren.

Das ist übrigens auch der Grund, warum viele Probleme, die, wo man jetzt sagt, in der Konstruktion, in der Mechanik hat man diese Probleme längst gelöst, also Modularisierung, komponentenbasierte Techniken oder komponierbare Systeme.

Das funktioniert in der Informatik alles nicht. Also dieses Märchen von wir haben standardisierte Software, Bausteine mit definierten Eigenschaften, den wir in allen Szenarien wieder verwenden können,

den gibt es bis heute nicht, im Gegensatz zu einer Schraube, wo ich genau spezifizieren kann, das ist die Schraube mit vollen Eigenschaften, funktioniert deshalb nicht, weil wir einen Rechner unten drunter haben.

Die Hardware verändert uns die Eigenschaften und deshalb kann man eben Wiederverwendbarkeit hier gar nicht so einfach erreichen.

Und aus Sicht der Echtzeitsysteme gibt es eben dieses Problem der Kosten, die wir berücksichtigen müssen.

Gut, es gibt eine ganze Reihe von Kosten, die da in so einem System entstehen können. Ich will es jetzt heute mal nur an einem Beispiel klar machen, wovon ich da rede, das sind nämlich die Programmunterbrechungen.

Das ist im Wesentlichen auch das, was ihr in den Übungen begegnet und mit dem ihr rumhantieren müsst und wo es vielleicht ganz gut ist, wenn man mal verstanden hat, was das eigentlich bedeutet.

Okay, grundsätzlich, was sind Programmunterbrechungen? Na ja, wie es der Name schon sagt, alles, was meinen aktuellen Programmfluss unterbricht, ist eine Programmunterbrechung,

unterscheidet da zwei Arten, Synchrone und Asynchron, bzw. im Englischen den Trap und den Interrupt. Das ist eine sehr wichtige Unterscheidung. Warum?

Weil das uns spezifiziert, woher das eigentlich kommt, also was ist die Ursache für diese Programmunterbrechung und sie unterscheiden sich auch massiv dahingehend, dass man die Aussagekraft, die man damit verknüpfen kann.

Also um es kurz zu machen, mit einem Trap komme ich in einem Echtzeitsystem wesentlich besser klar als mit einem Interrupt. Warum, werden wir jetzt gleich sehen.

Beiden gemein ist, dass sie behandelt werden müssen. Also sowohl ein Trap als auch ein Interrupt könnt ihr in den Übungen sehen.

Also wenn ihr loslegt, die Übungsaufgaben macht, dann werdet ihr mit beidem in Kontakt kommen und ja, manchmal ist es nicht so ganz offensichtlich, was man da tun soll.

Grundsätzlich muss man was tun, also das ist sozusagen die Botschaft, wenn euer Programm abstürzt, zum Beispiel wegen dem Trap, dann müsst ihr halt was an eurem Code ändern, weil ansonsten wird das wieder passieren.

Und bei einem Interrupt ist es auch so, wenn ihr eine Taste drückt, wollt ihr, dass die bearbeitet wird. Das Problem an der Sache ist, es ist grundsätzlich gerätespezifisch, also wie da genau vorzugehen ist, hängt halt von, ja von eurem Prozessor ab, den ihr da unten drin habt.

Die sind alle relativ ähnlich, aber in Detail ist halt unterschiedlich, das heißt, damit muss man sich so ein bisschen beschäftigen.

Wie gesagt, hier der Pointer, wenn ihr da mehr Interesse dran habt, wenn ihr wissen wollt, wie genau sich das mit diesen Unterbrechungen verhält, mit diesen Programmunterbrechungen, dann sei hier auf die Vorlesung Betriebssysteme verwiesen, da steht das nochmal im Detail drin.

Gut, fangen wir heute mit dem Trap an. Synchron, was heißt eigentlich Synchron, was meinen wir damit? Naja, letztendlich ist es die Ursache und Synchron, Ursachen für eine synchrone Unterbrechung sind letztendlich Fehler in eurem Programm.

Also immer dann, wenn das Programm in eine Situation reinläuft, wo ein Fehler entsteht, wird ein Trap ausgelöst, das bedeutet, dass im Prinzip, wenn ihr das Programm mit denselben Eingaben, mit demselben Zustand, in derselben Umgebung nochmal startet, wird ein und derselbe Fehler wieder auftreten.

Der Klassiker wäre eine Division durch Null. Wenn ihr eine Division durch Null ausführt, das sollte jedem klar sein, dass es nicht definiert, was da rauskommt, das ist ungültig, das heißt, das wird passieren, der Prozessor wird einen Trap auslösen, wird sagen, hey, lieber Programmierer, hier haben wir eine Division durch Null, damit kann ich nichts anfangen.

Und das ist ein Trap, es gibt viele Ursachen dafür, kann sein eine Division durch Null, kann sein ein Systemaufruf, kann eine Adressraumverletzung sein, also ihr wollt auf Speicher zugreifen, auf den ihr nicht zugreifen dürft, ihr wollt vielleicht Speicher anfordern und es gibt keinen Speicher mehr, also all das sind Möglichkeiten, wo es zu so einem Trap kommen kann.

Das Schöne daran ist, sie sind insofern definiert, dass sie eben nur von dem Arbeitszustand von eurem Programm abhängen, sprich, wenn ihr das Programm in gleicher Form wieder ausführt, dann wird derselbe Fehler wieder passieren und zwar exakt an derselben Stelle, nämlich zum Beispiel genau dort, wo diese Division ausgeführt wird.

Das wird immer genau da passieren, wo die Division ausgeführt wird und nirgendwo anders, deshalb sagt man, diese Unterbrechung ist synchron oder der englische Begriff ist Trap dafür. Das Schöne ist, es ist deterministisch, von letzter Woche wissen wir noch, deterministisches Verhalten ist super aus Echtzeit-Sicht, das heißt, wir können an der Stelle damit planen, wir könnten jetzt die Zeit, die es kostet, mit diesem Trap umzugehen, die könnten wir berücksichtigen und dann sind wir eigentlich schon wieder fein raus, also das ist eigentlich sozusagen die einfachere Klasse von Programmunterbrechung.

Schwieriger wird es bei Asynchronen Programmunterbrechung oder Interrupt im Englischen, das ist die berühmt berüchtigte Taste, also wenn ich an den Rechner eine Taste drücke, ist nicht definiert, wann und wo das passiert, das heißt, an welcher Stelle in meinem Programmablauf dieser Interrupt zuschlägt, ist nicht vorhersagbar und dementsprechend habe ich halt ein Problem damit, also Interrupt, Asynchron, alles was irgendwo mit zum Beispiel RRO zu tun hat, mit externen Geräten oder ähnlichem.

Ja, also das ist eine gute Frage, wir werden uns bei einem anderen Punkt, da können wir uns noch wesentlich intensiver darüber streiten, nämlich bei sowas wie einem Zeitgeber, da kann man sich so richtig darüber streiten, ob das ein Trap oder ein Interrupt ist.

Grundsätzlich technisch gesehen, ja, es wird sicherlich eine Art von Signalisierung stattfinden, da werden irgendwelche Pegel hochgezogen, irgendwas in der Hardware passiert.