Zuverlässige Echtzeitsysteme Sebastian Witte

Größe: px
Ab Seite anzeigen:

Download "Zuverlässige Echtzeitsysteme Sebastian Witte"

Transkript

1 Seminar Softwarebasierte Fehlertoleranz Zuverlässige Echtzeitsysteme Sebastian Witte Matrikelnummer:

2 2 Zuverlässige Echtzeitsysteme 1 Einleitung In dieser Arbeit werden Methoden vorgestellt, die für das Entwickeln zuverlässiger Echtzeitsysteme verwendet werden können. Echtzeitsysteme sind beliebige Computersysteme, die gewisse Anforderungen erfüllen müssen. Grundsätzlich heißt dies, dass das System Aufgaben in einer festgesetzten Frist erledigen muss. Hierbei gibt es jedoch zwei unterscheidbare Fälle: Zum einen gibt es Echtzeitanwendungen, bei denen die entsprechenden Aufgaben vollständig und innerhalb der geforderten Frist erfüllt werden müssen. Diese Anforderungen nennt man harte Echtzeitanforderungen. Wie dieser Ausdruck vermuten lässt, gibt es auch weiche Echtzeitanforderungen. Dies sind dann Aufgaben, bei denen es auch vorkommen darf, dass die Aufgabe verspätet oder gar nicht erledigt wird. Hierbei kann das verspätete Resultat der Aufgabe zwar immer noch nützlich sein, aber es kann je nach Anwendungszweck auch einfach verworfen werden. Für die Realisierung von Systemen mit harten Echtzeitanforderungen ist das Ermitteln der Worst Case Execution Time (WCET) erforderlich, damit garantiert werden kann, dass die Anforderungen eingehalten werden können. Dies bedeutet, dass bei maximal möglicher Systemlast die Ausführung der geforderten Aufgabe, für die auch der am längsten dauernde Kontrollfluss angenommen wird, korrekt und fristgerecht erledigt wird. Dies bedeutet auch, dass man, sofern es notwendig ist, Fehlerkorrekturverfahren für Bitfehler (z.b. durch äußere Einflüsse) mit in die WCET einbeziehen muss. Da die Einhaltung der (harten) Echtzeitanforderungen mit steigender Systemkomplexität nicht mehr so genau garantiert werden kann, bestehen typische Echtzeitsysteme aus robuster, ausgiebig getesteter Hardware und erfüllen nur einzelne oder sehr wenige Aufgaben. Da hierfür auch die WCET eingeplant wird, sind diese Systeme unter Umständen nur zu einem Bruchteil ihrer möglichen Kapazitäten ausgelastet. Wie man aber an den heutzutage erhältlichen Smartphones erkennen kann, sind auch recht kleine Systeme mit relativ hoher Rechenleistung ausgestattet. Neuere Geräte besitzen sogar schon vier Prozessorkerne und einen Gigabyte Arbeitsspeicher. Bezogen auf die Rechenleistung, wären Smartphones also in der Lage mehrere Echtzeitanwendungen auszuführen. Würde man dies auch tatsächlich durchführen, wäre ein solches System ein Beispiel für ein gemischtkritisches System. Heraus ergibt sich ein weiteres Problem. Denn typischerweise werden kleine Programme diverser Anbieter installiert, die keine nennenswerten Qualitätsansprüche haben und dennoch das System zum Absturz bringen können. Deshalb müssen solche Geräte eine weitere Anforderung erfüllen: Zuverlässigkeit. Dies beinhaltet Aspekte wie Vertraulichkeit, Robustheit, Intaktheit der Daten, Vertraulichkeit und Verfügbarkeit. Dementsprechend müssen Anwendungen isoliert und unabhängig voneinander agieren können und fehlerhafte Programme dürfen die Integrität des Systems nicht beeinflussen. Diese Aspekte müssen für die Verwendung gemischtkritischer Systeme erfüllt werden. Im folgenden Kapitel wird zunächst die Mikrokernarchitektur vorgestellt, da sie in beiden Referenzbeispielen verwendet wird.

3 Zuverlässige Echtzeitsysteme 3 2 Mikrokernarchitektur Ein Mikrokernel eignet sich konzeptionell sehr gut, um ein gemischtkritisches Echtzeitsystem realisieren zu können. Eine andere Möglichkeit bestünde darin, ein bestehendes monolithisches Desktopbetriebssystem so zu modifizieren, so dass es diese Anforderungen erfüllen kann. Ein Beispiel dafür wäre die aus RTLinux[15] entstandene Erweiterung des Linux-Kernels[3]. Doch wie sieht es bei einem solchen System mit der Zuverlässigkeit aus? Der Linux-Kernel besteht aus Millionen Zeilen Quelltext 1 und es ist praktisch unmöglich bei einem derart komplexen System Vorhersagen über Fehler oder Laufzeiten machen zu können. Da man aber Aussagen über Fehlerfreiheit und längstmögliche Programmflüsse benötigt, ist ein weniger komplexer Betriebssystemkern wünschenswert. Härtig und Roitsch[9], sowie Petters, Elphinstone und Heiser[13], verwenden für ihre Projekte jeweils einen Mikrokernel der L4-Familie. Ein Mikrokernel stellt die minimal benötigten Schnittstellen zur Verfügung, um ein Betriebssystem zu realisieren. Dabei wird versucht die Anzahl der Anwendungen, die auf Kernelebene ausgeführt werden, möglichst klein zu halten. Die wichtigsten Bausteine auf Kernelebene sind Interprozesskommunikation (IPC), sowie die Verwaltung von Adressräumen und Prozessfäden. Sofern es möglich ist, sollten alle anderen Dienste und Anwendungen, auf Benutzerebene laufen. So wird dann eine Isolation der einzelnen Anwendungen realisiert. Dabei ist zu beachten, dass das gewünschte System über Speicherschutzmechanismen wie Memory Management Units (MMUs) verfügen muss. Bei Geräten, die direkten Speicherzugriff (DMA) ermöglichen, muss zusätzlich eine Input/Ouput Memory Management Unit"(IOMMU) vorhanden sein. Ein weiteres Kriterium für den Systementwurf ist die Unterstützung mehrerer Privilegierungsebenen. Auf Kernelebene sind prinzipiell beliebige Hardwarezugriffe möglich, die nur durch in Hardware realisierte Maßnahmen eingeschränkt werden können. Eine Anwendung auf Benutzerebene kann nur durch Berechtigungen vom Betriebsystem Hardwareresourcen verwenden. Diese Berechtigungen erhält die Anwendung in letzter Instanz durch Systemcalls, die dann zum Beispiel in letzter Instanz von den Gerätetreibern ausgeführt werden. Im Gegensatz zu üblichen Desktopbetriebssystemen wie Windows oder Linux, laufen bei typischen Einzwecksystemen alle Anwendungen auf Kernelebene, wie es in Abbildung 1 zu sehen ist. Die L4-Familie von Mikrokerneln begründet sich auf den Versuch von Jochen Liedtke 2, einen sehr leistungsfähigen Mikrokernel zu bauen. Der resultierende Kernel war vollständig in x86-assembler programmiert worden und hatte dieses Ziel erreicht. Seitdem wurden einige Erweiterungen entwickelt, von denen die sel4-erweiterung[8] im 3. und Fiasco 3 im 4. Abschnitt genauer betrachtet werden. 1 html?page=

4 4 Zuverlässige Echtzeitsysteme typisches Echtzeitsystem monolitschisches Betriebssystem Anwendung Anwendung Anwendung Anwendung Dienst Dienst Dienst Dienst Dienst Dienst Hardware Hardware mikrokernbasiertes Betriebssystem Anwendung Anwendung Dienst Dienst Dienst Mikrokernel Hardware Kernelebene Abbildung 1. Kernelebenenvergleich verschiedener Architekturen[13, Abb. 1.1] 3 Zuverlässigkeit am Beispiel des sel4-mikrokernels Am NICTA 4, einem australischen Forschungsinstitut, entstand der secure embedded L4-Microkernel [10] (sel4), der unter recht besonderen Methoden entstanden ist. Dabei wurde ein formal verifizierbarer und zuverlässiger L4-artiger Kernel entwickelt, der auch praktisch nutzbar ist und sich für Echtzeitsysteme eignet. Da besonders die Teile des Systems, die direkt mit der Hardware agieren können, einen besonders starken Einfluss auf die Stabilität des Systems haben, wurde hier der Weg über die Etablierung einer Trusted Computing Base (TCB) gewählt. 3.1 Trusted Computing Base Die Trusted Computing Base [14] ist das Fundament eines Systems. Für Software ist dies in erster Linie das Betriebssystem, welches die Schnittstelle zwischen Hardware und den Anwendungen darstellt. Da formale Methoden zur Systemverifizierung sehr aufwändig und bei hoher Komplexität eines Systems nicht anwendbar sind, wurde ein mikrokernelbasiertes System als Ausgangsbasis gewählt. Der Quelltext eines solchen Mikrokernels umfasst in der Regel nicht mehr als Zeilen und lässt sich mit Hilfe maschinengestützter Beweisverfahren 4

5 Zuverlässige Echtzeitsysteme 5 verifizieren. Jedoch zeigt die Praxis, dass Systeme, die von Theoretikern entworfen wurden, zwar meistens korrekt, aber in der Regel nicht sehr leistungsfähig sind und bei praktischer Anwendung nicht die benötigten Schnittstellen bieten. Während Systeme, die von erfahrenen Kernelprogrammierern entworfen wurden, zwar zumeist sehr leistungsfähig sind, es sich aber immer wieder kleinere Fehler in den Quelltexten finden lassen, die bei unvorhergesehenen Kontrollflüssen zu Programm- oder Systemabstürzen führen. Deshalb wollte man am NICTA die besten Eigenschaften der beiden Methoden vereinen und ein leistungsfähiges und formal verifizierbares Betriebssystem erzeugen. Dafür wurde ein Team zusammengestellt, das aus erfahrenen Kernelprogrammierern, sowie Theoretikern besteht, die sich auch mit dem Thema der jeweils anderen Gruppe auseinandersetzten. Durch die enge Kooperation sollten die Bedürfnisse der beiden Gruppen abgedeckt werden und ein System mit den gewünschten Eigenschaften entstehen. 3.2 Formale Verifizierung Die Erzeugung von leistungsfähigem Code auf Betriebssystemebene kann nur mit Programmiersprachen wie C, C++ oder Assembler realisiert werden, da diese vollständig kontrollierbare Speicherkontrolle ermöglichen. Diese sind jedoch dafür bekannt, dass sie relativ viel Code für kleinere Aufgaben benötigen, was dann dafür sorgt, dass die formale Verifizierung des so erzeugten Codes sehr aufwändig sein kann. Zudem sind Änderungen an den Schnittstellen oft sehr aufwändig, da an diversen Stellen die Aufrufe der geänderten Funktion modifiziert werden müssen. Da diese Änderungen bei der Erzeugung eines Prototyps häufiger vorkommen, ist der Arbeitsaufwand in der Entwurfsphase sehr hoch. Um dies zu umgehen, wurde die Funktionsweise des Betriebssystems zunächst durch ein in Haskell geschriebenes, lauffähiges Modell ersetzt und erst dann der entsprechende C-Code geschrieben, der (wünschenswerterweise) im endgültigen Kernel auftauchen soll. Haskell[5] bietet sich hier als Programmiersprache an, da die starke Typisierung der Verwendung von maschinengestützten Beweisern entgegen kommt. Der Kern von Haskell basiert, wie der vom NICTA verwendete Theorembeweiser Isabelle/HOL[12], auf dem Lambdakalkül und deshalb bildet dieser Theorembeweiser die Grundlage für die Verifizierung des sel4-mikrokernels. Auch ist die Änderung von Schnittstellen zum simulierten Betriebssystem vergleichsweise arbeitssparend und der Quelltext kann so organisiert und dokumentiert werden, dass es sich fast wie eine englische Beschreibungssprache liest. Dabei hat der Quelltext wegen der starken Typisierung keine Mehrdeutigkeiten. Diese Änderungen werden nicht nur ausschließlich wegen der Funktionalität gemacht, sondern auch um die formale Richtigkeit einer Funktion leichter beweisen zu können. Dies geschieht in einem sich ständig wiederholenden Prozess, der dem in Abbildung 2 entspricht. Das Sicherheitstheorem beschreibt die Eigenschaften an das formale Modell, die erfüllt werden müssen. Darin werden unter anderem Vorbedingungen, Invarianten, gewünschte Garantien etc. beschrieben und mittels Proof-Carrying-Code [11] automatisch verifiziert. Dies bewirkt zudem, dass gewisse Überprüfungen zur Laufzeit überflüssig werden.

6 6 Zuverlässige Echtzeitsysteme Entwurf & Spezifikation interaktiver Entwurfszyklus Haskellprototyp formales Modell leistungsfähige C-Implementierung Sicherheitstheorem Abbildung 2. Systementwurf des sel4-mikrokernels[13, Abb. 1.4] Die Übersetzung des Haskellprototyps in effizienten C-Code kann, wie auch der Entwurf und das formale Modell, Einfluss auf den Haskellprototyp haben, da Schnittstellen in der Praxis eventuell noch zusätzliche Argumente oder Ähnliches benötigen. Deshalb stehen die beiden Implementierungen in einer Wechselwirkung zueinander, wobei augenscheinlich die Menge an Implementierungsänderungen, die durch die C-Implementierung entstanden sind, noch überschaubar gewesen sein müssen, da sich die Arbeit aus dem Artikel [13] zu einem Produktionsfähigen System entwickelt hat[8]. 3.3 Sicherheit Als Sicherheit versteht man in der Informationstechnologie in der Regel die Sicherstellung von Vertraulichkeit, Integrität und Verfügbarkeit. Ein oft benutzter Ansatz zur Realisierung dieser Eigenschaften ist die räumliche und zeitliche Isolation der verschiedenen Komponenten. Da beim sel4-mikrokernel die meisten Anwendungen auf Benutzerebene laufen ist die räumliche Isolation gegeben. Dennoch können Probleme durch dynamische Speicherallokation entstehen. Wenn ein Prozess immer mehr Speicher zur Verfügung gestellt bekommt, kann er dafür sorgen, dass andere Anwendungen nicht mehr genügend Speicher zur Verfügung haben, um ihre harten Fristen einhalten zu können oder sie funktionieren gar nicht mehr. Um dieses Problem zu umgehen, wurde ein auf Capabilities [7, S. 145] basierender Ansatz verwendet. Dies sind begrenzt große und typisierte Speicherblöcke, die beim Systemstart den einzelnen Anwendungen zugewiesen werden. Diese statisch zugeteilten Speicherblöcke sind typisiert und je nach Typ werden der Anwendung, die diesen Speicherblock erhalten hat, bestimmte Berechtigungen zugesprochen. Der

7 Zuverlässige Echtzeitsysteme 7 initiale Typ des Speicherblocks heißt untyped Memory [13, S. 9] und schränkt den Speicher nur auf seinen Adressraum und dem zugehörigen Prozess ein. Er garantiert also die räumliche Isolation und kann ansonsten vom dazugehörigen Prozess fast beliebig verwendet werden. Wenn der Prozess einen Teil des ihm zugeteilten untyped Memory einem Zweck zuführen möchte, dann geschieht dies durch einen retype-aufruf an das Betriebssystem und der gewünschte Speicherbereich wird gemäß des gewünschten Typs reserviert und geschützt. Dies bedeutet, dass wenn der Speicherbereich als gemeinsam genutzter Speicher verwendet werden soll, dass das Betriebssystem sicherstellt, dass auch nur diese Funktion ausgeführt wird und der Speicher zum Beispiel nicht als Stapelspeicher zur Verfügung gestellt wird. Die Anwendung, die der Speicherbereich zugeteilt wurde, hat weiterhin volle Berechtigungen diesen Speicher wieder einem anderen Zweck zuzuführen. Sie kann aber auch vorhandene Rechte an eine andere Anwendung für diesen Speicher übertragen. Im Falle eines gemeinsam genutzten Speichers wären das zum Beispiel Lese- oder Schreibrechte. Zeitliche Isolation wird in der Industrie meistens entweder durch fest zugeteilte Zeitscheiben oder durch festgesetzte Prioritäten realisiert. Es gibt jedoch Probleme bei der Verwendung eines Schedulers mit fixen Prioritäten. Prinzipiell sind dort nämlich keine Prozessorzeitgarantien für beliebige Echtzeitanwendungen treffbar, da höherpriore Anwendungen theoretisch den Prozessor zu 100% auslasten können. Zudem kann, abhängig vom derzeitigen Zustand des Systems, eine Anwendung, die eine geringere Priorität zugeteilt bekommen hat, in diesem Zustand eine deutlich höhere Priorität haben, das durch ein fixes Prioritätensystem nicht dargestellt werden kann. Zeitscheibenbasierte Scheduler haben aufgrund ihres Designs recht hohe Latenzen. Dennoch sind real eingesetzte Systeme, die mit Hilfe dieser Methoden konzipiert wurden, für ihren Anwendungszweck ausreichend. Wenn man nun Anwendungen unbekannter Herkunft in ein ansonsten vertrauenswürdiges System integrieren möchte, erschwert dies eine fundierte Aussage über das zeitliche Verhalten. Ein Fehler in diesen Anwendungen sollte für die Stabilität des Systems keine Auswirkungen haben und nur die von dieser Anwendung abhängigen Anwendungen betreffen. Typischerweise hat ein System aber nicht nur Echtzeitanwendungen, sondern auch Anwendungen, für die eine fairnessbasierte Zuteilung von Prozessorzeit angebracht ist. Dementsprechend hat man verschiedene Schedulinganforderungen auf einem gemischtkritischen System. Beim sel4 versucht man diesen Anforderung gerecht zu werden, indem ein auf Constant Bandwidth Servers [6] basierender Ansatz verwendet wird. Dabei werden den Anwendungen keine Prioritäten oder Zeitscheiben zugeteilt, sondern sie erhalten Ausführungszeitguthaben, welches periodisch aufgefrischt wird. Wenn Anwendungen ihr Guthaben nicht verbrauchen, steht es noch offen, wie mit diesen verbleibenden Guthaben umgegangen wird und dafür kann ein weiteres Schedulingverfahren angewendet werden. Die Guthaben entsprechen bei harten Echtzeitanwendungen der WCET und bei weichen Echtzeitanwendungen liegt das Guthaben Zwischen der durchschnittlichen Ausführungszeit und der WCET. Zudem kann ein Ansatz von Slack Management verwendet werden.

8 8 Zuverlässige Echtzeitsysteme Dabei kann ungenutztes Guthaben anderen Anwendungen zugeteilt werden und somit die Beendigung einer Anwendung ermöglichen, obwohl sie kein eigenes Guthaben mehr hat. Das überzählige Guthaben ist aber nur solange gültig, wie es vor der eigentlichen Frist der dazugehörigen Anwendungen angewandt wird. Ungenutztes Guthaben kann auch genutzt werden, um die Prozessoren herunter zu takten und so Strom zu sparen, was für batteriebetriebene (eingebettete) Systeme wichtig sein kann. Das so entworfene System entspricht der Abbildung 3, in der eine klare Trennung der vertrauenswürdigen und den potentiell nicht vertrauenswürdigen Bestandteilen, die von einem virtualisierten Linuxserver verwaltet werden, zu erkennen ist. Der Linuxserver läuft vollständig auf Benutzerebene und etwaige Systemaufrufe werden in die entsprechenden IPC-Nachrichten für den Mikrokernel übersetzt, so dass die nicht unbedingt vertrauenswürdigen Anwendungen keine Anpassungen benötigen, um auf dem System zu laufen. alte Anwendungen sensible Anwendungen Linux Server vertrauenswürdige Dienste Gerätetreiber vertrauenswürdige Gerätetreiber Sicherheitsrichtlinien sel4 Mikrokernel Hardware Abbildung 3. sel4-architektur [13, Abb. 1.6] 3.4 WCET-Analyse Die Ermittlung der WCET ist einer der wichtigsten Bestandteile, um zuverlässige Echtzeitsysteme zu erstellen. Denn diese wird zumindest für harte Echtzeitanfoderungen benötigt, um diese fristgerecht ausführen zu können. Bei der Bestimmung der WCET muss jeder Bestandteil des Gesamtsystems betrachtet

9 Zuverlässige Echtzeitsysteme 9 werden, der bei für die Ausführung der Anwendung benötigt wird. In Abbildung 4 werden die wesentlichen Schritte schematisch in ihrem Zusammenhang gezeigt. Dabei wird in der Strukturanalyse zunächst bestimmt, welche Kontrollflussstruktur dieser hat und welche Operationen ausgeführt werden. Dies wird in einem Kontrollflussgraphen gespeichert. Im nächsten Schritt wird der Kontrollfluss genauer analysiert. Aufgrund gewisser Datenabhängigkeiten können dann zum Beispiel die maximal möglichen Schleifeniterationen bestimmt werden statt der theoretisch möglichen. Auch die Vermeidung anderer Kontrollflüsse, die durch Datenabhängigkeit eigentlich gar nicht erreicht werden können, werden hier entdeckt und aus dem Graphen entfernt. Danach wird die Ausführungszeit der einzelnen Knoten bestimmt und man kann dann durch Auffinden des Pfades mit größtmöglicher Ausführungszeit im Graphen die WCET bestimmen. Diese statische Analyse funktioniert noch für 8- oder 16-Bitsysteme, scheitert jedoch an komplexeren Systemen. Grundlage für die statische Bestimmung der WCET sind unter anderem detaillierte Hardwaremodelle, um die Dauer der einzelnen Schritte überhaupt zuverlässig bestimmen zu können. Diese sind für komplexere Architekturen nicht vorhanden. Erschwert werden Analysen auch durch mehrere Cacheebenen, Kontrollzweigvorhersagen und andere Zusätze, die von modernen Prozessoren verwendet werden, um im Durchschnittsfall langsamere Speicherzugriffe zu sparen. Dies führt dazu, dass man sehr pessmistische Annahmen über die Speicherzugriffe etc. macht und die WCET dann um mehrere Größenordnungen überschätzt wird. Um eine genauere Aussage über die WCET machen zu könzu prüfender Code Strukturanalyse Low-Level Analyse Kontrollflussanalyse Berechnung WCET Abbildung 4. Schritte bei der WCET-Analyse [13, Abb. 1.8] nen, werden bei modernen Prozessoren Debuggingwerkzeuge verwendet, damit Laufzeitanalysen über verzweigungsfreie Basisblöcke von Ausführungen zuverlässig durchgeführt werden können. Es wird angenommen, dass der Großteil der Ausführungszeit auf der Vielfalt von Verzweigungen beruht und dafür eignet sich wieder die statische Analyse. Zudem muss eine Cacheanalyse durchgeführt werden, um die Messungen auf Basisblockebene verbessern zu können. Die Analyse der WCET ist für einen Kernel kaum automatisierbar, da er zum Teil aus hoch optimierten Assemblercode besteht und durch Interrupts beliebige Kontrollflüsse auftreten können. Ein Werkzeug, das dies bewerkstelligen könnte sei wohl so komplex, dass es praktisch nicht realisiert werden kann und in seiner Komplexität die bisher verwendete Methodik weit übersteigt. Für den sel4-mikrokernel

10 10 Zuverlässige Echtzeitsysteme wurde auf Programmiererannotationen gesetzt, die Laufzeit von Funktionen oder Codeblöcken qualitativ beschreiben. Da dies aber nur schlecht skaliert, ist dies nur bei einem Kernel mit kleiner Codebasis, also einem Mikrokernel, durchführbar. Da Teile des Betriebssystems formal verifiziert werden, entsteht der Aufwand der WCET-Analyse für die entsprechenden Codeabschnitte im Kernel nur einmal und kann in folgenden Analysen weiterverwendet werden. 4 Gemischtkritische Systemsicherheit am Beispiel des Dresden Real-time Operating System (DROpS) Beim Dresden Real-time Operating System war die Motivation für die Realisierung echtzeitfähiger Prozesse zwar eine andere, dennoch gibt es Ähnlichkeiten zur Realisierung von gemischtkritischen Systemen zu sel4. Die Motivation für DROpS war die Erkenntnis, dass auf heutiger Desktophardware Anwendungen mit Echtzeitanforderungen laufen und diese Echtzeitanforderungen nicht berücksichtigt werden. Ein Beispiel für Anwendungen mit Echtzeitanforderungen sind diverse Multimediaanwendungen. Beim Abspielen von Filmen sollten die Bilder in einer bestimmten Frist dargestellt werden und der Ton sollte zu den Bildern synchron sein. Die Architektur der Desktopcomputer hat sich in den letzten Jahrzehnten nicht geändert und da die verwendeten Betriebssysteme keine Methoden zur Realisierung von Echtzeitanforderungen enthalten, wurde das gewünschte Echtzeitverhalten durch Anpassungen von Middleware oder durch übermäßige Reservierung von Systemresourcen realisiert. Solche Lösungsansätze genügen einem anspruchsvollen Forscher natürlich nicht und deshalb haben Härtig und Roitzsch in [9] ein System entworfen, das Echtzeitanforderugen garantiert einhalten kann und als Desktopbetriebssystem einsetzbar ist. Ein wichtiger Fokus der beiden Forscher war auch, dass das System praktisch verwendbar sein sollte. Auch Härtig und Roitzsch waren der Meinung, dass übliche monolithische Desktopbetriebssysteme nicht vernünftig um Echtzeitfähigkeit erweitert werden können, da die Echtzeitanwendungen in der Regel auf Kernelebene laufen (vgl. RTLinux[15]). Es kann auch nicht sichergestellt werden, dass diese Anwendungen zuverlässig operieren und womöglich sogar das System zum Absturz bringen. Diese potentiellen Missstände waren für Härtig und Roitzsch nicht akzeptabel. Deshalb entschlossen sie sich zwei Kernel auf einem System laufen zu lassen. Dabei wird, wie in Abbildung 5 dargestellt, ein echtzeitfähiger L4-Mikrokernel (hier: Fiasco[2]) zur Kontrolle der Hardware verwendet und ein normaler Linuxkernel läuft virtuell und bedient die Softwareanwendungen, die keine Echtzeitanforderungen haben. Dort ist auch zu sehen, dass verschiedene Datentransportsysteme besonderen Fokus bezüglich ihrer Echtzeitanforderungen haben. Hierauf wird in Abschnitt 4.1 aber noch genauer eingegangen. Den Echtzeitanwendungen werden mittels festgesetzter Prioritäten die benötigten Resourcen zugeteilt während der Linuxkernel und die damit eingehenden Standardanwendungen eine bestmögliche Resourcenzuteilung erhalten. Zusätzlich werden die verschiedenen Hardwareresourcen, wie beispielsweise Prozessorzeit, Speicher und Netzwerkbandbreite,

11 Zuverlässige Echtzeitsysteme 11 von dedizierten Verwaltungselementen zugeteilt, so dass Echtzeitanwendungen ihre Fristen einhalten können und andere Anwendungen ihre Aufgaben erfüllen können. Dieses Prinzip ist zunächst einmal sehr ähnlich zu dem von sel4, wo die Echtzeitanwendungen auch durch ein Schedulingverfahren organisiert werden, das die entsprechenden Anforderungen erfüllen kann und den verbleibenden Prozessen bestmöglich die verbleibenden Resourcen zugeteilt werden können. Durch die verschiedenen Resourcenverwalter wird auch eine zeitliche und räumliche Trennung der Echtzeitanwenungen (und des Linuxkernels) vorgenommen, so dass auch hier Zuverlässigkeit durch Isolation realisiert wird. Anwendungen ohne Echtzeitanforderungen Echtzeitanwendungen Linux Echtzeitethernet Echtzeitdateisystem Echtzeit- SCSI Echtzeittransport CPU / Hauptspeicher L4-Mikrokernel Abbildung 5. DROpS-Architektur[9, Abb. 13.1] 4.1 Scheduling anhand eines probabilistischen Modells Heutige Hardware ist darauf spezialisiert durchschnittliche Programmabläufe zu optimieren. Das bekannteste Beispiel hierfür sind CPU-Caches, die die Speicherlokalität der Anwendungen ausnutzen, um so in vielen Fällen Zugriffe auf den langsameren Hauptspeicher, oder einen langsameren Cache dazwischen, einzusparen und so die Programmausführung zu beschleunigen. Aufgrund dieser Verfahren ist die Lücke zwischen der durchschnittlichen Ausführungszeit und der WCET oft sehr groß. Da aber vor allem bei Multimediaanwendungen die Berechnung eines Bildes keine festgesetzte Rechenzeit hat und je nach Komplexität des Bildes die Rechenzeit relativ stark schwanken kann, würde durch eine WCET-Annahme oft sehr viel Rechenzeit nicht genutzt werden. Jedoch sind Multimediaanwendungen eine Klasse von Anwendungen, die nicht eingehaltene Fristen auch mal verkraften können und sich dadurch nur die Qualität verringert, die Dienstleistung an sich aber gleich bleibt. Aufgrund dieser Annahmen

12 12 Zuverlässige Echtzeitsysteme wurde festgestellt, dass das Verfehlen dieser Fristen für einen geringen Prozentsatz schon enorme Resourceneinsparungen mit sich bringen kann, was man an der Messung der Bandbreitenverteilung nach Qualitätsbeschränkungen recht gut erkennen kann. Deshalb werden die verschiedenen Echtzeitanwendungen noch in zwei Klassen von Echtzeitanwendungen eingeteilt. Diese Zuteilung entspricht in etwa der Klassifizierung von weichen und harten Anforderungen, jedoch ist dies hier nicht ganz äquivalent. Es gibt verbindliche (mandatory) und optionale Anwendungen. Dabei sind die verbindlichen Anwendungen die harten Echtzeitanwendungen, für die die Fristen unbedingt eingehalten werden müssen und die optionalen Anwendungen erhalten eine Qualität, die eingehalten werden muss (z.b. 95% aller Fristen sollen eingehalten werden). Das Problem bei diesen Qualitätsaussagen ist jedoch, dass ein Wahrscheinlichkeitsmodell bekannt sein muss, damit die Resourcenverwalter ihre Resourcen ausreichend an die entsprechenden Anwendungen freigeben können. Es konnte jedoch beobachtet werden, dass selbst Qualitäten geringfügig unter 100% zu signifikant besserer Resourcenauslastung führen können, wie man in Abbildung 6 erkennen kann. Der Ansatz, der die- Abbildung 6. Bandbreite die einem optionalen Datenstrom zugesprochen werden kann [9, Abb. 13.3] se Qualitäten sicherstellen kann, heißt Quality-Rate-Monotonic Scheduling [9, S. 262] (QRMS). Hierbei werden den optionalen Anwendungen konstante Reservierungszeiten der Resourcen zugeteilt. Dies entspricht dem Guthaben beim Scheduling des sel4. QRMS ignoriert dabei sogar, wenn Anwendungen ihre Reservierungszeit nicht vollständig nutzen. Diese Vereinfachung ermöglicht eine bessere Annäherung an die geforderten Qualitäten und bei Überschreitung der Reservierungszeit werden die Anwendungen darüber benachrichtigt, dass sie ihre Qualität drosseln müssen[9, S. 263].

13 Zuverlässige Echtzeitsysteme 13 Eine weitere Besonderheit von DROpS ist, dass auch ein spezieller Fenstermanager[4] names DOpE[9, S. 266]erstellt wurde, der Echtzeitanwendungen mit grafischer Ausgabe berücksichtigt. Zum Zeitpunkt als DROpS entwickelt wurde, waren hardwaregestützte Virtualisierungen noch sehr unüblich. Trotzdem wurde bei dieser Art der Virtualisierung, der sogenannten Paravirtualisierung, nur eine Verlangsamung der Reaktionszeit von 2 bis 10% gemessen[9, S. 269]. Dementsprechend ist auf heutigen Systemen mit hardwaregestützter Virtualisierung die Verlangsamung noch kleiner, jedoch wurden hierfür keine vergleichbaren Prozentangaben gemessen, sondern nur eine absolute Verzögerungszeit von maximal 5,73µs[9, S. 270]. Für Anforderungen im Millisekundenbereich ist diese Verzögerung kaum relevant. In einem direkten Vergleich mit RTLinux hatte DROpS nur eine zusätzliche Verzögerung von 9µs und insgesamt 33µs[9, S. 270]. Dies ist vernachlässigbar, wenn die geforderteten Fristen im Millisekundenbereich liegen. 5 Fazit Obwohl die Zielgruppe von Härtig und Roitzsch eine andere war als für Petters, Elphinstone und Heiser, war das entworfene System doch sehr ähnlich. Beide verwendeten einen L4-Mikrokernel für die Echtzeitanwendungen und ein virtualisiertes Linux für Anwendungen ohne Echtzeitanforderungen. In [13] wurde auch ein größerer Fokus auf die Zuverlässigkeit und Sicherheit des Systems gelegt, während in [9] dieses durch Isolation gelöst wurde und danach nicht weiter erwähnt wurde. Auch der Ansatz, die Resourcenreservierung der weichen Echtzeitanwendungen eher an ihrer durchschnittlichen Ausführungszeit fest zu machen, war bei beiden Artikeln ähnlich. Jedoch sind Härtig und Roitzsch so weit gegangen, dass sie ihnen auch noch gewisse Qualitäten zusichern konnten. Meiner Meinung nach ist die Methodik in [13] sehr interessant und vielversprechend, um zuverlässige Echtzeitsysteme realisieren zu können, die auch anderen Anwendungen Resourcen bieten, um ihre Aufgabe zu erfüllen. Vor allem da auch die Miteinbeziehung von Energie(-kosten) in der Informatik immer wichtiger wird. Dazu durfte ich einen Vortrag von Clifford Stein[1] an der technischen Universität Dortmund am 31. Januar 2013 hören. Der Versuch die gesamte Trusted Computing Base einer formalen Verifzierung zu unterziehen, und trotzdem ein praktisch einsetzbares System präsentieren zu können, ist beeindruckend und sicherlich eine der besten Methoden, um ein zuverlässiges System zu konzipieren. Im Gegensatz dazu stehen die Aussagen von Härtig und Roitzsch, ihr System usable on a daily basis [9, S. 258, Abschnitt ] machen zu wollen. Immerhin schafften sie es akzeptable Verzögerungen durch die Verwendung eines Mikrokernels und eines virtualiserten Linuxkernels zu schaffen. Dennoch halte ich die Bindung an die Fensterverwaltung, sowie das Fehlen von vernünftigen Gerätetreibern für ein schwer überwindbares Defizit, um auch bei normalen Endbenutzern erfolgreich eingesetzt werden zu können. Zudem scheint RTLinux ein erfolgsversprechender Kompromiss zu sein, um Echtzeitanforderungen für

14 14 Zuverlässige Echtzeitsysteme bestimmte Anwendungen realisieren zu können, da dies als Kernelkonfigurationsmöglichkeit in den offiziellen Linuxkernel Einzug genommen hat. Literatur 1. Clifford Stein s personal homepage at Columbia University, edu/~cs2035/ 2. The Fiasco Microkernel, 3. Real-time linux wiki, 4. Window Manager Wikipedia, 5. Haskell 2010 language report (2010), haskell2010/ 6. Abeni, L., Buttazzo, G.: Integrating Multimedia Applications in Hard Real-Time Systems. In: Proceedings of the 19th IEEE Real-Time Systems Symposium, pp IEEE Computer Science Press, Madrid, Spain (1998) 7. Dennis, J.B., Van Horn, E.: Programming semantics for multiprogrammed computations. In: Communications of the ACM 9, pp Massachusetts Institute of Technology, Cambridge, Massachusetts (1966) 8. ERTOS: Secure embedded l4, 9. Härtig, H., Roitsch, M.: As time goes by: Research on l4-based real-time systems. In: Chakraborty, S., Eberspächer, J. (eds.) Advances in Real-Time Systems, pp Springer-Verlag Berlin Heidelberg (2012) 10. Klein, G., Elphinstone, K., Heiser, G., Andronick, J., Cock, D., Derrin, P., Elkaduwe, D., Engelhardt, K., Kolanski, R., Norrish, M., Sewell, T., Tuch, H., Winwood, S.: sel4: Formal verification of an os kernel. In: Communications of the ACM. pp No. 53, NICTA, University of New South Wales, Open Kernel Labs (June 2010) 11. Necula, G.C., Lee, P.: In: Proceedings of the USENIX 2nd Symposium on Operating Systems Design and Implementation. Seattle, Washington (October 1996) 12. Nipkow, T., Paulson, L.C., Wenzel, M.: Isabelle/HOL A Proof Assistant for Higher-Order Logic, LNCS, vol Springer (2002) 13. Petters, S.M., Elphinstone, K., Heiser, G.: Trustworthy real-time systems. In: Chakraborty, S., Eberspächer, J. (eds.) Advances in Real-Time Systems, pp Springer-Verlag Berlin Heidelberg (2012) 14. Rushby, J.: Design and Verification of Secure Systems. In: 8th ACM Symposium on Operating System Principles. vol. 15, pp Pacfic Grove, California (December 1981) 15. Yodaiken, V., Barabanov, M.: A Real-Time Linux. New Mexico Institute of Technology (2000), 290S/rtlinux.pdf

Sebastian Witte 06.03.2013

Sebastian Witte 06.03.2013 06.03.2013 Inhalt kleine, leistungsfähige Systeme verfügbar (Smartphones) Resourcenverschwendung übermäßige Resourcenreservierung kleinste Systeme noch zu schnell zu restriktives Scheduling Vermischung

Mehr

J. Reinier van Kampenhout Robert Hilbrich Hans-Joachim Goltz. Workshop Echtzeit Fraunhofer FIRST

J. Reinier van Kampenhout Robert Hilbrich Hans-Joachim Goltz. Workshop Echtzeit Fraunhofer FIRST Modellbasierte Generierung von statischen Schedules für sicherheitskritische, eingebettete Systeme mit Multicore Prozessoren und harten Echtzeitanforderungen J. Reinier van Kampenhout Robert Hilbrich Hans-Joachim

Mehr

VIRTUALISIERUNG IN MIKROKERN BASIERTEN SYSTEMEN

VIRTUALISIERUNG IN MIKROKERN BASIERTEN SYSTEMEN Fakultät Informatik Institut für Systemarchitektur, Professur Betriebssysteme VIRTUALISIERUNG IN MIKROKERN BASIERTEN SYSTEMEN Henning Schild Dresden, 5.2.2009 Definition Einführung von Abstraktionsschichten

Mehr

Operating System Kernels

Operating System Kernels Operating System Kernels von Patrick Bitterling 1 Themenübersicht -Eine Einleitung über Kernel -Begriffserklärung, Architekturen -Kernel Subsysteme -Prozess-Scheduling, Speichermanagement,... -Der Networking

Mehr

Grundlagen Rechnerarchitektur und Betriebssysteme

Grundlagen Rechnerarchitektur und Betriebssysteme Grundlagen Rechnerarchitektur und Betriebssysteme Johannes Formann Definition Computer: Eine Funktionseinheit zur Verarbeitung von Daten, wobei als Verarbeitung die Durchführung mathematischer, umformender,

Mehr

Echtzeitprogrammierung und Echtzeitverhalten von Keil RTX. Frank Erdrich Semester AI 7

Echtzeitprogrammierung und Echtzeitverhalten von Keil RTX. Frank Erdrich Semester AI 7 Echtzeitprogrammierung und Echtzeitverhalten von Frank Erdrich Semester AI 7 Inhalt Einleitung Echtzeit und Echtzeitsysteme Echtzeitprogrammierung Real-Time Operating System Keil RTOS RTX Zusammenfassung

Mehr

Konzepte und Methoden der Systemsoftware. Aufgabe 1: Multi-Feedback-Scheduling. SoSe bis P

Konzepte und Methoden der Systemsoftware. Aufgabe 1: Multi-Feedback-Scheduling. SoSe bis P SoSe 2013 Konzepte und Methoden der Systemsoftware Universität Paderborn Fachgebiet Rechnernetze Präsenzübung 4 13.05.2013 bis 17.05.2013 Aufgabe 1: Multi-Feedback-Scheduling 0 P 1. Beschreiben Sie kurz

Mehr

Was machen wir heute? Betriebssysteme Tutorium 2. Organisatorisches. Frage 2.1.a. Theorieblätter Abgabe. Antwort. Probleme mit OS/161?

Was machen wir heute? Betriebssysteme Tutorium 2. Organisatorisches. Frage 2.1.a. Theorieblätter Abgabe. Antwort. Probleme mit OS/161? Was machen wir heute? Betriebssysteme Tutorium 2 Philipp Kirchhofer philipp.kirchhofer@student.kit.edu http://www.stud.uni-karlsruhe.de/~uxbtt/ Lehrstuhl Systemarchitektur Universität Karlsruhe (TH) 1

Mehr

7.2 Conjoining Specifications

7.2 Conjoining Specifications Seminar: Spezifikation und Verifikation verteilter Systeme 7.2 Conjoining Specifications Teil 2: Das Kompositions-Theorem Dirk Fahland 1 TLA & Komposition in TLA Jede TLA-Formel Mi lässt sich in eine äquivalente

Mehr

Die Sicht eines Sysadmins auf DB systeme

Die Sicht eines Sysadmins auf DB systeme Die Sicht eines Sysadmins auf DB systeme Robert Meyer 21. Oktober 2016 Robert Meyer Die Sicht eines Sysadmins auf DB systeme 21. Oktober 2016 1 / 20 Inhaltsverzeichnis 1 Einleitung 2 IO unter Linux typische

Mehr

Projekt für Systemprogrammierung WS 06/07

Projekt für Systemprogrammierung WS 06/07 Dienstag 30.01.2007 Projekt für Systemprogrammierung WS 06/07 Von: Hassan Bellamin E-Mail: h_bellamin@web.de Gliederung: 1. Geschichte und Definition 2. Was ist Virtualisierung? 3. Welche Virtualisierungssoftware

Mehr

Klausur. Betriebssysteme SS 2007

Klausur. Betriebssysteme SS 2007 Matrikelnummer: 9999999 Klausur FB Informatik und Mathematik Prof. R. Brause Betriebssysteme SS 2007 Vorname: Nachname: Matrikelnummer: Geburtsdatum: Studiengang: Bitte tragen Sie auf jeder Seite Ihre

Mehr

HW/SW CODESIGN. Echtzeitverhalten. Mehmet Ozgan 0526530. 17. November 2015

HW/SW CODESIGN. Echtzeitverhalten. Mehmet Ozgan 0526530. 17. November 2015 HW/SW CODESIGN Echtzeitverhalten 17. November 2015 Mehmet Ozgan 0526530 ÜBERBLICK 1. Echtzeitsysteme 2. Hardware im Zeitbereich 3. Software im Zeitbereich 2 ECHTZEITSYSTEME REAL-TIME SYSTEM Ein Echtzeitsystem

Mehr

Die L4-Mikrokern. Mikrokern-Familie. Hauptseminar Ansätze für Betriebssysteme der Zukunft. Michael Steil. Michael Steil 18.04.2002

Die L4-Mikrokern. Mikrokern-Familie. Hauptseminar Ansätze für Betriebssysteme der Zukunft. Michael Steil. Michael Steil 18.04.2002 Die L4-Mikrokern Mikrokern-Familie Hauptseminar Ansätze für Betriebssysteme der Zukunft 18.04.2002 Folie 1 Aufbau des Vortrags 1. Mikrokerne: Idee und Geschichte 2. L4: ein schneller Mikrokern 3. L4Linux:

Mehr

Verteilte Systeme. Verteilte Systeme. 5 Prozeß-Management SS 2016

Verteilte Systeme. Verteilte Systeme. 5 Prozeß-Management SS 2016 Verteilte Systeme SS 2016 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 31. Mai 2016 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/14) i

Mehr

Vorlesung Rechnerarchitektur. Einführung

Vorlesung Rechnerarchitektur. Einführung Vorlesung Rechnerarchitektur Einführung Themen der Vorlesung Die Vorlesung entwickelt an Hand von zwei Beispielen wichtige Prinzipien der Prozessorarchitektur und der Speicherarchitektur: MU0 Arm Speicher

Mehr

Echtzeit-Multitasking

Echtzeit-Multitasking Technische Informatik Klaus-Dieter Thies Echtzeit-Multitasking Memory Management und System Design im Protected Mode der x86/pentium-architektur. Shaker Verlag Aachen 2002 Die Deutsche Bibliothek - CIP-Einheitsaufnahme

Mehr

Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK) nick.merriam@rapitasystems.

Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK) nick.merriam@rapitasystems. Das zeitliche Verhalten von Echtzeitsoftware zu analysieren und sicher zu stellen, dass die Anforderungen an das Echtzeitverhalten erfüllt werden kann sehr aufwendig und teuer sein. In diesem Artikel sollen

Mehr

RealTime Linux. Paul Seidel Seminar Prozessteuerung und Robotik WS 08/09 Lehrstuhl BS und Middleware Prof. Polze Hasso-Plattner-Institut Potsdam

RealTime Linux. Paul Seidel Seminar Prozessteuerung und Robotik WS 08/09 Lehrstuhl BS und Middleware Prof. Polze Hasso-Plattner-Institut Potsdam RealTime Linux Paul Seidel Seminar Prozessteuerung und Robotik WS 08/09 Lehrstuhl BS und Middleware Prof. Polze Hasso-Plattner-Institut Potsdam Übersicht 2 Standard-Kernel Dual-Kernel RTAI/LXRT In-Kernel

Mehr

WCET-Analyseverfahren in der automobilen Softwareentwicklung

WCET-Analyseverfahren in der automobilen Softwareentwicklung WCET-Analyseverfahren in der automobilen Softwareentwicklung Martin Däumler 1 Robert Baumgartl 2 Matthias Werner 1 1 Technische Universität Chemnitz 2 HTW Dresden 28. November 2008 M. Däumler et al (TUC,

Mehr

Verteilte Echtzeit-Systeme

Verteilte Echtzeit-Systeme - Verteilte Echtzeit-Systeme Hans-Albrecht Schindler Wintersemester 2015/16 Teil B: Echtzeit-Betriebssysteme Abschnitt 13: Echtzeit-Primärspeicherverwaltung CSI Technische Universität Ilmenau www.tu-ilmenau.de

Mehr

Wie groß ist die Page Table?

Wie groß ist die Page Table? Wie groß ist die Page Table? Im vorigen (typischen) Beispiel verwenden wir 20 Bits zum indizieren der Page Table. Typischerweise spendiert man 32 Bits pro Tabellen Zeile (im Vorigen Beispiel brauchten

Mehr

Echtzeitscheduling (1)

Echtzeitscheduling (1) Echtzeitscheduling (1) Scheduling in Betriebssystemen Ressourcenausteilung (CPU, Speicher, Kommunikation) Faire Ressourcenvergabe, insbesondere CPU Hohe Interaktivität / kurze Reaktionszeit für interaktive

Mehr

Hardware Virtualisierungs Support für PikeOS

Hardware Virtualisierungs Support für PikeOS Virtualisierungs Support für PikeOS Design eines Virtual Machine Monitors auf Basis eines Mikrokernels Tobias Stumpf SYSGO AG, Am Pfaenstein 14, 55270 Klein-Winternheim HS Furtwangen, Fakultät Computer

Mehr

Bibliotheks-basierte Virtualisierung

Bibliotheks-basierte Virtualisierung Dr.-Ing. Volkmar Sieh Department Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2015/2016 V. Sieh Bibliotheks-basierte Virtualisierung (WS15/16)

Mehr

Proseminar Technische Informatik A survey of virtualization technologies

Proseminar Technische Informatik A survey of virtualization technologies Proseminar Technische Informatik A survey of virtualization technologies Referent: Martin Weigelt Proseminar Technische Informatik - A survey of virtualization technologies 1 Übersicht 1. Definition 2.

Mehr

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Friedrich-Alexander-Universität Erlangen-Nürnberg Ausgewählte Kapitel eingebetteter Systeme Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Sven Kerschbaum 1. Einführung Bei einem eingebetteten

Mehr

Virtualisierter Terminalserver

Virtualisierter Terminalserver Virtualisierter Terminalserver 1. Virtualisierung Virtualisierung bezeichnet in der Informatik laut Wikipedia die Nachbildung eines Hard- oder Software- Objekts durch ein ähnliches Objekt vom selben Typ

Mehr

(a) Wie unterscheiden sich synchrone und asynchrone Unterbrechungen? (b) In welchen drei Schritten wird auf Unterbrechungen reagiert?

(a) Wie unterscheiden sich synchrone und asynchrone Unterbrechungen? (b) In welchen drei Schritten wird auf Unterbrechungen reagiert? SoSe 2014 Konzepte und Methoden der Systemsoftware Universität Paderborn Fachgebiet Rechnernetze Präsenzübung 2 2014-04-28 bis 2014-05-02 Aufgabe 1: Unterbrechungen (a) Wie unterscheiden sich synchrone

Mehr

Übung I Echtzeitbetriebssysteme

Übung I Echtzeitbetriebssysteme Übung I Echtzeitbetriebssysteme a) Von welchen drei Faktoren hängt bei der Echtzeitverarbeitung das korrekte Ergebnis ab? b) Wann ist ein System echtzeitfähig? c) Was versteht man unter Harter und Weicher

Mehr

A U S A R B E I T U N G

A U S A R B E I T U N G Echtzeitsysteme Zuordnung von Echtzeitsystemen nach den Zeitschranken A U S A R B E I T U N G Studiengang Informationstechnik an der Dualen Hochschule Baden-Württemberg Karlsruhe von Ruwen Möhrle März

Mehr

Zwischenbericht Diplomarbeit Entwicklung einer Laufzeitumgebung für Komponenten mit Ressourcenanforderungen

Zwischenbericht Diplomarbeit Entwicklung einer Laufzeitumgebung für Komponenten mit Ressourcenanforderungen Zwischenbericht Diplomarbeit Entwicklung einer Laufzeitumgebung für Komponenten mit Ressourcenanforderungen Brit Engel Überblick Beschreibung Aufgabenstellung Entwurf der Komponenten Verwaltung Funktionsbereiche

Mehr

Docker. Eine Einführung

Docker. Eine Einführung Docker Eine Einführung Inhalt Motivation Virtualisierung Docker Anwendung Fazit & Ausblick 2 von 21 Motivation Motivation Ziel: Sicherheit im Bereich der Webentwicklung Idee: Mehr Praxis Perspektivenwechsel

Mehr

Rechnernutzung in der Physik. Betriebssysteme

Rechnernutzung in der Physik. Betriebssysteme Rechnernutzung in der Physik Betriebssysteme 1 Betriebssysteme Anwendungsprogramme Betriebssystem Treiber BIOS Direkter Zugriff von Anwenderprogrammen auf Hardware nur in Ausnahmefällen sinnvoll / möglich:

Mehr

Protected User-Level DMA in SCI Shared Memory Umgebungen

Protected User-Level DMA in SCI Shared Memory Umgebungen Protected User-Level DMA in SCI Shared Memory Umgebungen Mario Trams University of Technology Chemnitz, Chair of Computer Architecture 6. Halle Chemnitz Seminar zu Parallelverarbeitung und Programmiersprachen

Mehr

Innovative Architekturansätze

Innovative Architekturansätze Innovative Architekturansätze Peter Sturm AG Systemsoftware Betriebssysteme im Umbruch Allgemeine Probleme Steigende Komplexität Mangelnde Zuverlässigkeit Neue Herausforderungen ManyCore- Architekturen

Mehr

Real-Time Operating Systems Ein Überblick

Real-Time Operating Systems Ein Überblick Real-Time Operating Systems Ein Überblick Stefan Tittel Universität Dortmund Proseminar: Werkzeuge und Techniken zur Spezifikation, Simulation und Implementierung von eingebetteten Systemen, 2004 1 Einführung

Mehr

Rechnergestützter VLSI-Entwurf

Rechnergestützter VLSI-Entwurf Schaltungssynthese Dipl.-Ing. e-mail: rgerndt@iam.de Seite SYN/1 Motivation Vereinfachung des Systementwurfes Weniger Fehler durch abstrakte Beschreibung Portierbarkeit der Schaltung (PLD, CPLD, FPGA,

Mehr

kernkonzept L4Re ISOLATION UND SCHUTZ IN MIKROKERNBASIERTEN SYSTEMEN kernkonzept 1

kernkonzept L4Re ISOLATION UND SCHUTZ IN MIKROKERNBASIERTEN SYSTEMEN kernkonzept 1 kernkonzept L4Re ISOLATION UND SCHUTZ IN MIKROKERNBASIERTEN SYSTEMEN kernkonzept 1 kernkonzept Systeme mit höchsten Sicherheitsanforderungen trotzdem flexibel und nutzerfreundlich dank Mikrokernen der

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Systeme I: Betriebssysteme Kapitel 4 Prozesse. Maren Bennewitz

Systeme I: Betriebssysteme Kapitel 4 Prozesse. Maren Bennewitz Systeme I: Betriebssysteme Kapitel 4 Prozesse Maren Bennewitz Version 20.11.2013 1 Begrüßung Heute ist Tag der offenen Tür Willkommen allen Schülerinnen und Schülern! 2 Wdhlg.: Attributinformationen in

Mehr

Sequentielle Programm- / Funktionsausführung innerhalb eines Prozesses ( thread = Ausführungsfaden )

Sequentielle Programm- / Funktionsausführung innerhalb eines Prozesses ( thread = Ausführungsfaden ) Threads Sequentielle Programm- / Funktionsausführung innerhalb eines Prozesses ( thread = Ausführungsfaden ) Ein thread bearbeitet eine sequentielle Teilaufgabe innerhalb eines Prozesses Mehrere nebenläufige

Mehr

Scheduling in Echtzeitbetriebssystemen. Prof. Dr. Margarita Esponda Freie Universität Berlin

Scheduling in Echtzeitbetriebssystemen. Prof. Dr. Margarita Esponda Freie Universität Berlin Scheduling in Echtzeitbetriebssystemen Prof. Dr. Margarita Esponda Freie Universität Berlin Echtzeitsysteme Korrekte Ergebnisse zum richtigen Zeitpunkt Hart Echtzeitsysteme Eine verspätete Antwort ist

Mehr

Test (Lösungen) Betriebssysteme, Rechnernetze und verteilte Systeme

Test (Lösungen) Betriebssysteme, Rechnernetze und verteilte Systeme Seite 1 Test (Lösungen) Betriebssysteme, Rechnernetze und verteilte Systeme 1 11.07.2007 Hinweise: Bevor Sie mit der Bearbeitung der Aufgaben beginnen, müssen Sie auf allen Blättern Ihren Namen und Ihre

Mehr

Tutorium Rechnerorganisation

Tutorium Rechnerorganisation Woche 11 Tutorien 3 und 4 zur Vorlesung Rechnerorganisation 1 Christian A. Mandery: KIT Universität des Landes Baden-Württemberg und nationales Grossforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Virtualisierung im Echtzeitbereich. Andreas Hollmann FH Landshut EADS Military Air Systems

Virtualisierung im Echtzeitbereich. Andreas Hollmann FH Landshut EADS Military Air Systems Virtualisierung im Echtzeitbereich Andreas Hollmann FH Landshut EADS Military Air Systems 2 Überblick Hintergrund und Motivation Vorstellung von Lösungsansätzen Auswahl und Evaluierung Einschränkungen

Mehr

Systemsoftware (SYS) Fakultät für Informatik WS 2008/2009 Christian Baun. Übungsklausur

Systemsoftware (SYS) Fakultät für Informatik WS 2008/2009 Christian Baun. Übungsklausur Hochschule Mannheim Systemsoftware (SYS) Fakultät für Informatik WS 2008/2009 Christian Baun Übungsklausur Aufgabe 1: Definieren Sie den Begriff der Systemsoftware. Nennen Sie die Aufgaben und Komponenten

Mehr

Linux gefahrlos testen

Linux gefahrlos testen Seite 1 von Cage Linux gefahrlos testen In diesem Artikel wird beschrieben, wie man Linux in einer virtuellen Maschine unter Windows installiert. 1 Grundlegende Informationen Um diesen Artikel zu verstehen,

Mehr

Dipl.-Inf. J. Richling Wintersemester 2003/2004. Weiche Echtzeit

Dipl.-Inf. J. Richling Wintersemester 2003/2004. Weiche Echtzeit Dipl.-Inf. J. Richling Wintersemester 2003/2004 Weiche Echtzeit Wiederholung - Resultat/Wert-Funktion "harte" Echtzeit Wert Zeit Wert Zeit Wert Deadline Zeit "weiche" Echtzeit Wert Deadline Zeit Deadline

Mehr

Nichtdeterministische Platzklassen

Nichtdeterministische Platzklassen Sommerakademie 2010 Rot an der Rot AG 1: Wieviel Platz brauchen Algorithmen wirklich? Nichtdeterministische Platzklassen Ulf Kulau August 23, 2010 1 Contents 1 Einführung 3 2 Nichtdeterminismus allgemein

Mehr

Entwurfsmuster und Softwarearchitekturen für sicherheitskritische Systeme

Entwurfsmuster und Softwarearchitekturen für sicherheitskritische Systeme 1 Entwurfsmuster und Softwarearchitekturen für sicherheitskritische Systeme Für das Seminar Analyse, Entwurf und Implementierung zuverlässiger Software Von: Andreas Seibel Betreut durch: Dr. Holger Giese

Mehr

Foliensatz. Theorie und Einsatz von Verbindungseinrichtungen in parallelen Rechnersystemen

Foliensatz. Theorie und Einsatz von Verbindungseinrichtungen in parallelen Rechnersystemen Foliensatz Center for Information Services and High Performance Computing (ZIH) Theorie und Einsatz von Verbindungseinrichtungen in parallelen Rechnersystemen Hochgeschwindigkeitskommunikationen 13. Juli

Mehr

CyPhyControl. Virtualisierte Ausführungsplattform für die zuverlässige Steuerung cyber-physikalischer Systeme

CyPhyControl. Virtualisierte Ausführungsplattform für die zuverlässige Steuerung cyber-physikalischer Systeme CyPhyControl Virtualisierte Ausführungsplattform für die zuverlässige Steuerung cyber-physikalischer Systeme Olaf Spinczyk Markus Buschhoff Boguslaw Jablkowski AG Eingebettete Systemsoftware Informatik

Mehr

User Level Device Driver am Beispiel von TCP

User Level Device Driver am Beispiel von TCP September 17, 2004 Einleitung Motivation für Userlevel Device Driver Probleme von Userlevel Device Driver Motivation für Userlevel Device Driver Modularität, leichterer Austausch/Erneuerung von Komponenten.

Mehr

Dynamisches Huffman-Verfahren

Dynamisches Huffman-Verfahren Dynamisches Huffman-Verfahren - Adaptive Huffman Coding - von Michael Brückner 1. Einleitung 2. Der Huffman-Algorithmus 3. Übergang zu einem dynamischen Verfahren 4. Der FGK-Algorithmus 5. Überblick über

Mehr

Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen?

Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen? Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen? Umgebung Getestet wurde auf einem Linux-System mit voller invis-server Installation, auf dem eine virtuelle Maschine

Mehr

Technische Informatik 1

Technische Informatik 1 Technische Informatik 1 7 Prozesse und Threads Lothar Thiele Computer Engineering and Networks Laboratory Betriebssystem 7 2 7 3 Betriebssystem Anwendung Anwendung Anwendung Systemaufruf (syscall) Betriebssystem

Mehr

1. Motivation / Grundlagen 2. Sortierverfahren 3. Elementare Datenstrukturen / Anwendungen 4. Bäume / Graphen 5. Hashing 6. Algorithmische Geometrie

1. Motivation / Grundlagen 2. Sortierverfahren 3. Elementare Datenstrukturen / Anwendungen 4. Bäume / Graphen 5. Hashing 6. Algorithmische Geometrie Gliederung 1. Motivation / Grundlagen 2. Sortierverfahren 3. Elementare Datenstrukturen / Anwendungen 4. Bäume / Graphen 5. Hashing 6. Algorithmische Geometrie 4/2, Folie 1 2014 Prof. Steffen Lange - HDa/FbI

Mehr

BSD Alternativen zu Linux

BSD Alternativen zu Linux BSD Alternativen zu Linux Woher kommt BSD? Was ist BSD? Was ist sind die Unterschiede zwischen FreeBSD, NetBSD und OpenBSD? Warum soll ich *BSD statt Linux einsetzen?. p.1/21 BSD Alternativen zu Linux

Mehr

Which Thin Client fits. Michael Hoting

Which Thin Client fits. Michael Hoting Which Thin Client fits Michael Hoting Introducing Name: Michael Hoting (44) System Engineer / Consultant Started in 1989 as trainee developer for fabric applications. Focus since 2004 on thin client and

Mehr

Linux-Treiber entwickeln

Linux-Treiber entwickeln Linux-Treiber entwickeln Eine systematische Einführung in Gerätetreiber für den Kernel 2.6 von Jürgen Quade, Eva K Kunst überarbeitet Linux-Treiber entwickeln Quade / Kunst schnell und portofrei erhältlich

Mehr

Systemvoraussetzungen für ConSol*CM Version 6.10.2 Architektur Überblick

Systemvoraussetzungen für ConSol*CM Version 6.10.2 Architektur Überblick Systemvoraussetzungen für ConSol*CM Version 6.10.2 Architektur Überblick ConSol*CM basiert auf einer Java EE Web-Architektur, bestehend aus den folgenden Kern-Komponenten: JEE Application Server für die

Mehr

Ein Scheduler für alle Fälle Robert Kaiser, SYSGO AG

Ein Scheduler für alle Fälle Robert Kaiser, SYSGO AG Ein Scheduler für alle Fälle Robert Kaiser, SYSGO AG Am Pfaffenstein 14 D-55270 Klein-Winternheim Tel. +49 (0) 6136 9948-0 Fax. +49 (0) 6136 9948-10 PikeOS: multiple VM Umgebung VM #0 VM #1 VM #2... PikeOS

Mehr

Quantifying Application Performance for Adaptive Power Management

Quantifying Application Performance for Adaptive Power Management Quantifying Application Performance for Adaptive Power Management Andreas Weißel Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich-Alexander Universität Erlangen-Nürnberg weissel@cs.fau.de

Mehr

Lizenzierung von System Center 2016

Lizenzierung von System Center 2016 Lizenzierung von System Center 2016 Herzlich Willkommen zu unserem Webcast Lizenzierung von System Center 2016. Mai 2016 Seite 2 von 10 Mit den Microsoft System Center-Produkten lassen sich Endgeräte wie

Mehr

OSEK-OS. Oliver Botschkowski. oliver.botschkowski@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab

OSEK-OS. Oliver Botschkowski. oliver.botschkowski@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab OSEK-OS Oliver Botschkowski oliver.botschkowski@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einleitung Motivation Ziele Vorteile Einführung in OSEK-OS Architektur Task Management Interrupt

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Lastenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006)

Lastenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006) Lastenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006) Alles, was in dieser Schriftart gesetzt ist, dient nur zur Erläuterung und sollte im fertigen Lastenheft nicht mehr auftauchen! Der Umfang

Mehr

Verteilte Echtzeit-Systeme

Verteilte Echtzeit-Systeme - Verteilte Echtzeit-Systeme Hans-Albrecht Schindler Wintersemester 2015/16 Teil B: Echtzeit-Betriebssysteme Abschnitt 9: Scheduling gemischter Prozessmengen CSI Technische Universität Ilmenau www.tu-ilmenau.de

Mehr

Advanced Operating Systems

Advanced Operating Systems - Advanced Operating Systems Hans-Albrecht Schindler Wintersemester 2015/16 Teil A: Betriebssystem-Architekturkonzepte Abschnitt 4: Exokernel basierte Architekturen CSI Technische Universität Ilmenau www.tu-ilmenau.de

Mehr

<Insert Picture Here> RAC Architektur und Installation

<Insert Picture Here> RAC Architektur und Installation RAC Architektur und Installation Elmar Ströhmer Michael Künzner Oracle Server Technologies Competence Center Agenda Überblick und Architekturen von HA-Systemen Hardware Die Basis

Mehr

Early first draft Höllische Programmiersprachen Seminar im WS 2014/15 Speichermanagement

Early first draft Höllische Programmiersprachen Seminar im WS 2014/15 Speichermanagement Early first draft Höllische Programmiersprachen Seminar im WS 2014/15 Speichermanagement Max Haslbeck Technische Universität München 20.01.2015 Zusammenfassung 1 Einleitung 2 Begriffsklärung Heutzutage

Mehr

Virtueller Speicher. SS 2012 Grundlagen der Rechnerarchitektur Speicher 44

Virtueller Speicher. SS 2012 Grundlagen der Rechnerarchitektur Speicher 44 Virtueller Speicher SS 2012 Grundlagen der Rechnerarchitektur Speicher 44 Die Idee Virtuelle Adressen Prozess 1 Speicherblock 0 Speicherblock 1 Speicherblock 2 Speicherblock 3 Speicherblock 4 Speicherblock

Mehr

Embedded Linux. Arthur Baran

Embedded Linux. Arthur Baran Arthur Baran Inhalt Embedded System Aufbau von Embedded Linux Systemen Echtzeit Einige Beispiele Arthur Baran 2 Was ist Embedded System? klein verborgen im Gerät soll eine bestimmte Aufgabe erledigen Arthur

Mehr

Systemprogramme bezeichnen alle Programme, die bestimmte Aufgaben unterstützen, die unabhängig von einer konkreten Anwendung sind

Systemprogramme bezeichnen alle Programme, die bestimmte Aufgaben unterstützen, die unabhängig von einer konkreten Anwendung sind Betriebssysteme Systemprogramme bezeichnen alle Programme, die bestimmte Aufgaben unterstützen, die unabhängig von einer konkreten Anwendung sind Umfaßt z.b. auch Compiler, Interpreter und Dienstprogramme

Mehr

Python ist leicht zu erlernen, unterstützt mehrere Programmierparadigmen und ist klar strukturiert.

Python ist leicht zu erlernen, unterstützt mehrere Programmierparadigmen und ist klar strukturiert. 1 Einführung In diesem Kapitel wird die moderne Programmiersprache Python vorgestellt. Nach einigen Bemerkungen zur Installation dieser Sprache wird gezeigt, wie Python interaktiv ausgeführt werden kann.

Mehr

Coma I. Einleitung. Computer und Algorithmen. Programmiersprachen. Algorithmen versus Programmiersprachen. Literaturhinweise

Coma I. Einleitung. Computer und Algorithmen. Programmiersprachen. Algorithmen versus Programmiersprachen. Literaturhinweise Coma I Einleitung 1 Computer und Algorithmen Programmiersprachen Algorithmen versus Programmiersprachen Literaturhinweise 2 Computer und Algorithmen Programmiersprachen Algorithmen versus Programmiersprachen

Mehr

MARKERLESS AUGMENTED REALITY. Henrik Brauer

MARKERLESS AUGMENTED REALITY. Henrik Brauer MARKERLESS AUGMENTED REALITY Henrik Brauer Inhalt Was ist Augmented Reality Meine Motivation Grundlagen Positionsbestimmung mit Marker Positionsbestimmung ohne Marker Idee Risiken INHALT Augmented Reality

Mehr

LINUX Schulung. FrauenComputerZentrum Berlin. Jutta Horstmann, Mai 2006

LINUX Schulung. FrauenComputerZentrum Berlin. Jutta Horstmann, Mai 2006 LINUX Schulung FrauenComputerZentrum Berlin Jutta Horstmann, Mai 2006 Agenda Was ist Linux Was ist Open Source Warum Open Source Software Wie sieht Open Source Software aus Was kann man damit machen Ausprobieren!!

Mehr

Die Integration zukünftiger In-Car Multimedia Systeme unter Verwendung von Virtualisierung und Multi-Core Plattformen

Die Integration zukünftiger In-Car Multimedia Systeme unter Verwendung von Virtualisierung und Multi-Core Plattformen Die Integration zukünftiger In-Car Multimedia Systeme unter Verwendung von Virtualisierung und Multi-Core Plattformen 0. November 0 Sergio Vergata, Andreas Knirsch, Joachim Wietzke Echtzeit 0 Agenda Motivation

Mehr

Constraint-basierte Planung und Optimierung von Prüfungsterminen mithilfe einer graphischen Benutzeroberfläche

Constraint-basierte Planung und Optimierung von Prüfungsterminen mithilfe einer graphischen Benutzeroberfläche Douglas Cunningham,Petra Hofstedt, Klaus Meer, IngoSchmitt (Hrsg.): INFORMATIK 2015 LectureNotes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2015 Constraint-basierte Planung und Optimierung

Mehr

L4Android !!!!! Ein guter Lösungsansatz? Cassian Spägele FH Kaiserslautern Fach: Studienarbeit Prof. A.Müller 14.01.2014

L4Android !!!!! Ein guter Lösungsansatz? Cassian Spägele FH Kaiserslautern Fach: Studienarbeit Prof. A.Müller 14.01.2014 L4Android Ein guter Lösungsansatz? Cassian Spägele FH Kaiserslautern Fach: Studienarbeit Prof. A.Müller 14.01.2014 "1 Inhalte des Vortrages Vorstellung L4Android Motivation der L4Android-Hersteller Sicherheitsszenario

Mehr

Beim Programmieren mit MMIX habt ihr vielleicht schon öfter eine der folgenden Fehlermeldungen von MMIXAL bekommen:

Beim Programmieren mit MMIX habt ihr vielleicht schon öfter eine der folgenden Fehlermeldungen von MMIXAL bekommen: 1 ADRESSIERUNG IN MMIX Beim Programmieren mit MMIX habt ihr vielleicht schon öfter eine der folgenden Fehlermeldungen von MMIXAL bekommen: no base address is close enough to the address A! relative address

Mehr

Round-Robin Scheduling (RR)

Round-Robin Scheduling (RR) RR - Scheduling Reigen-Modell: einfachster, ältester, fairster, am weitesten verbreiteter Algorithmus Entworfen für interaktive Systeme (preemptives Scheduling) Idee: Den Prozessen in der Bereitschaftsschlange

Mehr

IRS in virtualisierten Umgebungen

IRS in virtualisierten Umgebungen Lehrstuhl Netzarchitekturen und Netzdienste Institut für Informatik Technische Universität München IRS in virtualisierten Umgebungen Seminar: Future Internet Christian Lübben Betreuer: Nadine Herold, Stefan

Mehr

Systeme 1. Kapitel 6. Nebenläufigkeit und wechselseitiger Ausschluss

Systeme 1. Kapitel 6. Nebenläufigkeit und wechselseitiger Ausschluss Systeme 1 Kapitel 6 Nebenläufigkeit und wechselseitiger Ausschluss Threads Die Adressräume verschiedener Prozesse sind getrennt und geschützt gegen den Zugriff anderer Prozesse. Threads sind leichtgewichtige

Mehr

Hochverfügbarkeit und virtualisierte Umgebungen

Hochverfügbarkeit und virtualisierte Umgebungen Hochverfügbarkeit und virtualisierte Umgebungen Hartmut Streppel Oracle Deutschland B.V. & Co. KG München Schlüsselworte Virtualisierung, Hochverfügbarkeit, Solaris Container, Solaris Zonen, Logical Domains,

Mehr

Linker: Adreßräume verknüpfen. Informationen über einen Prozeß. Prozeß-Erzeugung: Verwandtschaft

Linker: Adreßräume verknüpfen. Informationen über einen Prozeß. Prozeß-Erzeugung: Verwandtschaft Prozeß: drei häufigste Zustände Prozeß: anatomische Betrachtung jeder Prozeß verfügt über seinen eigenen Adreßraum Sourcecode enthält Anweisungen und Variablen Compiler überträgt in Assembler bzw. Binärcode

Mehr

secunet Security Networks AG A priori Policies zum Schutz von Fahrzeug Bordnetzen

secunet Security Networks AG A priori Policies zum Schutz von Fahrzeug Bordnetzen secunet Security Networks AG A priori Policies zum Schutz von Fahrzeug Bordnetzen 12. Deutscher IT-Sicherheitskongress Bonn, 10. Mai 2011 Dr. Marc Lindlbauer, Bereichsleiter Online Security Agenda 1 Online-Dienste

Mehr

Design and Implementation of a Soft-error Resilient OSEK Real-time Operating System

Design and Implementation of a Soft-error Resilient OSEK Real-time Operating System Design and Implementation of a Soft-error Resilient OSEK Real-time Operating System Florian Lukas Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich Alexander Universität Erlangen

Mehr

Embedded Linux. Embedded Linux. Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de. Seminar "Eingebettete drahtlose Systeme"

Embedded Linux. Embedded Linux. Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de. Seminar Eingebettete drahtlose Systeme Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de Embedded Linux 30.01.2009 Daniel Buchheim Inhalt: Was ist Embedded Linux? Hardwareunterstützung in Eingebetteten Systemen Open Source Aspekte Aufbau

Mehr

CUDA. Jürgen Pröll. Multi-Core Architectures and Programming. Friedrich-Alexander-Universität Erlangen-Nürnberg Jürgen Pröll 1

CUDA. Jürgen Pröll. Multi-Core Architectures and Programming. Friedrich-Alexander-Universität Erlangen-Nürnberg Jürgen Pröll 1 CUDA Jürgen Pröll Multi-Core Architectures and Programming Jürgen Pröll 1 Image-Resize: sequentiell resize() mit bilinearer Interpolation leicht zu parallelisieren, da einzelne Punkte voneinander unabhängig

Mehr

RTOS Einführung. Version: Datum: Autor: Werner Dichler

RTOS Einführung. Version: Datum: Autor: Werner Dichler RTOS Einführung Version: 0.0.1 Datum: 20.07.2013 Autor: Werner Dichler Inhalt Inhalt... 2 RTOS... 3 Definition... 3 Anforderungen... 3 Aufgaben... 3 Eigenschaften... 4 Einteilung der Betriebssysteme...

Mehr

Der Rechner. Grundbegriffe. Aufbau. Funktionsweise. Betriebssystem. Kategorisierung. PC-Komponenten. Prof. Dr. Aris Christidis

Der Rechner. Grundbegriffe. Aufbau. Funktionsweise. Betriebssystem. Kategorisierung. PC-Komponenten. Prof. Dr. Aris Christidis Der Rechner Grundbegriffe Aufbau Funktionsweise Betriebssystem Kategorisierung PC-Komponenten Auf der Grundlage eines Programms kann ein Computer Daten mit seiner Umgebung austauschen, mathematische und

Mehr

1 Grundprinzipien statistischer Schlußweisen

1 Grundprinzipien statistischer Schlußweisen Grundprinzipien statistischer Schlußweisen - - Grundprinzipien statistischer Schlußweisen Für die Analyse zufallsbehafteter Eingabegrößen und Leistungsparameter in diskreten Systemen durch Computersimulation

Mehr

1 Windows 2000/XP (3.1, NT, 95, 98)

1 Windows 2000/XP (3.1, NT, 95, 98) 1 Windows 2000/XP (3.1, NT, 95, 98) 2 Der Anfang: MS-DOS Zielsetzung: Ein leichtes Betriebssystem für IBM-PCs mit lediglich einem Benutzer Abwärtskompatibel zu CP/M-80 von Digital Research Einführung 1981

Mehr

Betriebssysteme Übung 2. Tutorium System Calls & Multiprogramming

Betriebssysteme Übung 2. Tutorium System Calls & Multiprogramming Betriebssysteme Übung 2. Tutorium System Calls & Multiprogramming Task Wiederholung 1 System SysCalls (1) Wozu? Sicherheit Stabilität Erfordert verschiedene modes of execution: user mode privileged mode

Mehr

Scheduling- Algorithmen. Handbuch für Endnutzer

Scheduling- Algorithmen. Handbuch für Endnutzer Scheduling- Algorithmen Handbuch für Endnutzer Stand 15.03.2005 1. Vorwort... 1 2. Systemvoraussetzungen... 2 3. Programmarten... 2 4. Sicherheit der Endnutzer... 2 5. Handhabung... 3 5.1. Prozesseingabe...

Mehr

Mikrokernbasierte Betriebssysteme in industriellen Anwendungen

Mikrokernbasierte Betriebssysteme in industriellen Anwendungen Mikrokernbasierte Betriebssysteme in industriellen Anwendungen Diplomverteidigung André Puschmann 1. Dezember 2009 Überblick 1 Einführung 2 Echtzeit- und Verlässlichkeitsanalyse 3 Entwurf/Implementierung

Mehr