Softwarearchitektur (Architektur:!"#$ = Anfang, Ursprung + tectum = Haus, Dach)

Größe: px
Ab Seite anzeigen:

Download "Softwarearchitektur (Architektur:!"#$ = Anfang, Ursprung + tectum = Haus, Dach)"

Transkript

1 Softwarearchitektur (Architektur:!"#$ = Anfang, Ursprung + tectum = Haus, Dach) 12. Fallstudien eingebettete Systeme Vorlesung Wintersemester 2010 / 11 Technische Universität München Institut für Informatik Lehrstuhl von Prof. Dr. Manfred Broy Dr. Klaus Bergner, Prof. Dr. Manfred Broy, Dr. Marc Sihling

2 Inhalt! Rekapitulation! Architekturen für geschlossene lokale Systeme! Architekturkonzepte und Entwurfstechniken! Beispiel: Underground Tank Monitoring System! Architekturen für geschlossene verteilte Systeme! Architekturkonzepte und Entwurfstechniken! Beispiel: SMT Assembly Equipment! Abstecher und Ausblicke! Asynchronous Transactional Messaging! Offene verteilte Systeme! Zusammenfassung Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

3 Inhalt! Rekapitulation! Architekturen für geschlossene lokale Systeme! Architekturkonzepte und Entwurfstechniken! Beispiel: Underground Tank Monitoring System! Architekturen für geschlossene verteilte Systeme! Architekturkonzepte und Entwurfstechniken! Beispiel: SMT Assembly Equipment! Abstecher und Ausblicke! Asynchronous Transactional Messaging! Offene verteilte Systeme! Zusammenfassung Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

4 Zusammenfassung der letzten Vorlesung! Im Bereich der eingebetteten Systeme gibt es eine Fülle von Modellierungs- und Realisierungstechniken sowie technischen Infrastrukturen und Basiskomponenten.! Die Standardisierung ist allerdings nicht so fortgeschritten wie bei betrieblichen Informationssystemen.! Höherer Kostendruck - höhere Optimierung! In der Praxis gibt es meist einen Methodenbruch zwischen fachlicher Architektur und technischer Architektur (oder schlimmer: eine fachliche Architektur wird überhaupt nicht erstellt).! Um ein System realisieren zu können, muss der Entwickler heutzutage in fast allen Fällen über ein umfassendes und detailliertes Verständnis der technischen Infrastruktur (inklusive Hardware) verfügen.! Neue Ansätze basierend auf Generierung aus Modellen und Container-Architekturen sind größtenteils erst noch in der Forschung. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

5 Fachliche und Technische Architektur! Fachliche Architektur! Die Modellierung basiert auf verteilten Objekten/Komponenten, die sich gegenseitig Nachrichten schicken. Zur Spezifikation werden hauptsächlich verwendet: - Instanzendiagramme für die Systemkonfigurationen - Zustandsdiagramme für die einzelnen Komponenten - Sequenzdiagramme für die Interaktion zwischen Komponenten! Bei geschlossenen Systemen ist die Systemkonfiguration zur Laufzeit in aller Regel statisch.! Technische Architektur! Hauptkonzepte und Hauptmechanismen sind - Parallel oder quasiparallel ausgeführte Tasks (Prozesse, Threads) - Kommunikationsmechanismen zwischen Tasks (Semaphore, Signale, Queues, Mailboxes, Shared Memory, RPCs, Feldbusse) - Basiskomponenten wie RT-Betriebssysteme und RT-ORBs und Bus-Systeme Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

6 Entwicklungsschritte bei der Festlegung der Fachlichkeit! Business Requirements! meist vorgegeben durch Firmenstrategie und Marketing! Auswahl der Basisfunktionalität! Auswahl Funktionen, die durch das System erbracht werden! Festlegung der nichtfunktionalen Anforderungen! Qualitätsanforderungen - Architektur Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

7 Entwurfsschritte bei der Abbildung der Fachlichkeit! Auswahl der Hardware! meist vorgegeben oder stark eingeschränkt durch Kosten, Größe, Stromverbrauch, Performance! Auswahl der Basissoftware! Auswahl von Basiskomponenten, insbesondere eines RT-OS (falls überhaupt geeignete Komponenten existieren)! Entwurf der Tasks (Threads, Runnables)! Identifikation der Tasks! Zuordnung von Tasks zu Prozessoren (damit implizit auch Zuordnung von Kommunikationsverbindungen zu Kommunikationsmedien)! Zuordnung von Objekten zu Tasks! Entwurf der Interaktion und Kommunikation! Auswahl und Entwurf der Synchronisations- und Kommunikationsmechanismen! Zuordnung von Prioritäten zu Tasks Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

8 Erinnerung: Tasks und Multi-tasking! Ein Task (englisch für Aufgabe) ist ein Prozess, der auf der Systemebene (Kernel) läuft.! Task wird somit mit Prozess gleichgesetzt.! Oft wird ein Task auch als Subprozess angesehen, stellt also einen Thread dar.! Durch die weiteren Begriffe Multitasking und Taskwechsel, welche sich sowohl auf Prozesse als auch auf Threads beziehen können, sollte Task also eher als Oberbegriff für Prozess und Thread gesehen werden.! Multitasking nennt man allgemein die Technik, mehrere Prozesse (oder Threads) gleichzeitig oder quasi-gleichzeitig (d.h. in Form eines sehr eng verzahnten Hin- und Herschaltens) laufen zu lassen.! Es werden zwei Arten von Multitasking unterschieden: 1. Kooperatives Multitasking 2. Präemptives Multitasking Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

9 Inhalt! Rekapitulation! Architekturen für geschlossene lokale Systeme! Architekturkonzepte und Entwurfstechniken! Beispiel: Underground Tank Monitoring System! Architekturen für geschlossene verteilte Systeme! Architekturkonzepte und Entwurfstechniken! Beispiel: SMT Assembly Equipment! Abstecher und Ausblicke! Asynchronous Transactional Messaging! Offene verteilte Systeme! Zusammenfassung Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

10 Basisarchitekturen! Es gibt einige grundlegende Architekturen für geschlossene lokale Echtzeit-Systeme, die sich in ihrer Komplexität und in den erzielbaren Reaktionszeiten unterscheiden.! Einfache Systeme, die auf wenige Ereignisse reagieren müssen und/ oder geringe Anforderungen an die Reaktionszeiten und die Behandlung von Prioritäten haben, kommen mit einer einfachen Architektur und elementaren Betriebssystemkonzepten aus.! Die vier im Folgenden vorgestellten Basisarchitekturen sind (nach zunehmender Komplexität angeordnet):! Round-Robin-Architektur! Round-Robin-Architektur mit Interrupts! Task-Queue Scheduling-Architektur! RTOS-Architektur Klassifikation und Beispiele nach [Si99] Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

11 Round-Robin-Architektur Grundprinzip! Ein einziger Task fragt in einer Hauptschleife synchron der Reihe nach alle Ereignisquellen ab und ruft jeweils die entsprechenden Operationen für die Behandlung der Ereignisse auf.! Operationen können auch unbedingt (ohne zu Grunde liegendes externes Ereignis) aufgerufen werden.! Die maximale Reaktionszeit für die Ausführung einer Operation ist jeweils durch die maximale Ausführungszeit der Hauptschleife vorgegeben. Beispielcode void main(void) { while (true) { if ( <EreignisA> ) { // behandle EreignisA } if ( <EreignisB> ) { // behandle EreignisB } } }... if ( <EreignisZ> ) { // behandle EreignisZ } Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

12 Beispiel für möglichen Einsatz Digitales Multimeter In jedem Durchlauf:! Aktualisierung der Anzeige! Auslesen der Ereignisquellen! Drehschalterposition! Messergebnis Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

13 Vor- und Nachteile der Round-Robin-Architektur! Vorteile! Sehr einfach zu implementieren! Benötigt keine Basis-Software! Geeignet für ressourcenbeschränkte (Single-Prozessor-)Geräte! Nachteile! Wenn einzelne Ereignisbehandlungen zu lange brauchen, kann die Architektur unpraktikabel oder untauglich sein.! Wenn die geforderten Reaktionszeiten auf Ereignisse kürzer als die Zeit für die Ausführung der Hauptschleife sind, gehen Ereignisse verloren oder werden zu spät behandelt.! Die Architektur ist nur bis zu einem bestimmten Punkt erweiterbar: Wenn neue Ereignisquellen und Ereignisbehandlungsoperationen hinzukommen, kann die Architektur versagen. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

14 Round-Robin-Architektur mit Interrupts! Im Vergleich zu Round-Robin gibt es zusätzlich Interrupt-Handler. Sie werden hardwareunterstützt asynchron aufgerufen, wenn der Prozessor bestimmte Ereignisse feststellt.! In den Interrupt-Handlern läuft nur der Code, der für die schnelle Reaktion auf Ereignisse erforderlich ist. Interrupts (und damit die Interrupt-Handler) können unterschiedliche Prioritäten haben.! Wenn kein Interrupt-Handler aktiv ist, ruft der Hauptschleifen-Task Task-Operationen für die weitere Verarbeitung auf.! Die Task-Operationen basieren auf den Datenobjekten, die von den Interrupt-Handlern abgelegt worden sind.! Damit ergibt sich das Problem, dass sowohl Interrupt-Handler als auch Task-Operationen koordiniert auf die gleichen Datenobjekte zugreifen müssen. Dies kann durch kurzzeitiges Ausschalten der Interrupts in der Hauptschleife oder durch reentrante Datenstrukturen gelöst werden.! In der Task-Hauptschleife können auch länger dauernde Operationen ausgeführt werden, ohne die Reaktionszeit zu beeinträchtigen. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

15 Code bei Round-Robin-Architektur mit Interrupts Interrupt-Handler boolean E1 = false; boolean E2 = false;... void interrupt handlee1() { // behandle E1 E1 = true; } void interrupt handlee2() { // behandle E2 E2 = true; }... Task-Hauptschleife void main(void) { while (true) { if (E1) { E1 = false; // behandle E1 } if (E2) { E2 = false; // behandle E2 }... }} Welcher Code in den Interrupt-Handlern bzw. in den Task-Operationen der Task-Hauptschleife liegt, ist eine Entwurfsentscheidung. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

16 Beispiel für möglichen Einsatz Encryption Bridge Port a Port b (verschlüsselt)! Eingabezeichen an den Ports müssen innerhalb einer definierten Reaktionszeit gelesen und in die intern verwalteten Queues geschrieben werden (bevor das nächste Eingabezeichen ankommt). Dies geschieht innerhalb von Interrupt-Handlern.! Die Operationen zum Anfügen und Auslesen von Zeichen an die / aus den Queues sind reentrant, damit sie sowohl von den Interrupt- Handlern als auch von der Hauptschleife gerufen werden können.! Die Ver- und Entschlüsselungsroutinen arbeiten in der Hauptschleife zeitlich entkoppelt von den Interrupt-Handlern. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

17 Vor- und Nachteile von Round-Robin mit Interrupts! Vorteile! Relativ einfach zu implementieren! Benötigt keine Basis-Software! Geeignet für ressourcenbeschränkte (Single-Prozessor-)Geräte! Gut erweiterbar mit zusätzlichen Interrupt-Handlern.! Interrupt-Handler können unterschiedliche Prioritäten besitzen! Nachteile! Zugriff auf gemeinsam genutzte Daten von Interrupt-Handlern und Hauptschleife muss von Hand koordiniert werden! Es gibt keine Prioritäten für den Task-Code in der Hauptschleife. Die maximale Reaktionszeit für eine Task-Operation ist gleich der Summe der Ausführungszeiten aller Task-Operationen in der Hauptschleife (plus zusätzlich auftretende Zeit für Interrupts). Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

18 Task-Queue Scheduling Architecture! Diese Architektur ist eine Erweiterung der Round-Robin-Architektur mit Interrupts.! Anstatt den Task-Code in einer Hauptschleife immer in der gleichen Reihenfolge auszuführen, stellen die Interrupt-Handler Bearbeitungsanforderungen für Task-Operationen in eine Task- Queue ein.! Die Bearbeitungsanforderungen werden gesteuert von einem Scheduler abgearbeitet. Dies geschieht nicht notwendigerweise in der Reihenfolge, in der sie in die Task-Queue eingestellt wurden.! Die Vor- und Nachteile entsprechen im Wesentlichen denen der Round-Robin-Architektur mit Interrupts, mit folgenden Änderungen:! Zusätzliche Komplexität durch nötige Realisierung des Schedulers.! Senkung der maximalen Reaktionszeit für Task-Operationen in der Hauptschleife (Ausführungszeit der längsten Task-Operation, plus zusätzlich auftretende Zeit für Interrupts). Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

19 RTOS (real-time operating system) Betriebssystem! Ein Echtzeitbetriebssystem oder auch RTOS (real-time operating system) ist ein Betriebssystem mit! zusätzlichen Echtzeit-Funktionen für die Einhaltung von Zeitbedingungen (vorhersagbares Zeitverhalten - dies betrifft vor allem die Bereiche Scheduling und Speicherverwaltung) und die Vorhersagbarkeit des Prozessverhaltens.! Echtzeitbetriebssysteme müssen zusätzliche Fehlererkennungsmechanismen unterstützen.! Gängige Architekturen! Micro-Kernel: Diese Architektur basiert darauf, dass der eigentliche Betriebssystemkern als Task mit niedrigster Priorität realisiert ist und der Echtzeit-Kernel das Scheduling übernimmt. Dabei besitzen die Echtzeit-Prozesse die höchste Priorität. Das bringt minimale Latenzzeiten mit sich.! Nano-Kernel: Ähnlich dem Micro-Kernel-Ansatz, jedoch besteht hier die Möglichkeit, neben dem eigentlichen Echtzeit-Kernel eine beliebige Anzahl anderer Betriebssystem-Kernel laufen zu lassen. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

20 RTOS-Architektur! Die RTOS-Architektur basiert auf einem Echtzeit-Betriebssystem (Real-Time Operating System).! Wie in den beiden vorigen Architekturen wird zwischen Code in Interrupt-Handlern und Code in Tasks unterschieden.! Die Kommunikation zwischen Interrupt-Handlern und Task-Code erfolgt über die Mechanismen des Betriebssystems (explizit über Signale, Queues, Mailboxes etc. oder implizit über Shared Memory).! Anstatt alle Task-Operationen in einer Hauptschleife eines Tasks zu realisieren, werden sie nun in eigenständige Tasks verlagert.! Das Betriebssystem kann einen Task während seiner Laufzeit unterbrechen, um zu einem anderen, höher priorisierten zu wechseln.! Damit lässt sich die Reaktionszeit für Task-Operationen auf die Zeit senken, die das RTOS für den Wechsel zu dem betreffenden Task benötigt. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

21 Code bei RTOS-Architektur Interrupt-Handler void interrupt handlee1() { // behandle E1 setsignal(e1); } void interrupt handlee2() { // behandle E2 setsignal(e2); }... Tasks void task1(void) { while (true) { waitforsignal(e1); // behandle E1 }} void task2(void) { while (true) { waitforsignal(e2); // behandle E2 }} Anstelle einfacher Signale können auch andere Mechanismen (etwa Nachrichtenversand über eine Queue) Task-Operationen auslösen. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

22 Aufbau eines Tasks bei der RTOS-Architektur Verteilte Objekte aus der fachlichen Architektur deren Verhalten durch einen Zustandsautomat beschrieben wird, lassen sich schematisch in Tasks umsetzen. i1:in1 a:a i2:in2 o1:out1 void taska(void) { // Deklaration privater Daten }}} // Initialisierung, falls // erforderlich while (true) { // auf Ereignis warten: // Signal, Message,... switch (<Ereignis>) { case <i1> :... send(<o1>)... case <i2> :... Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

23 Entwurf der Tasks bei der RTOS-Architektur! So viele Tasks wie möglich, um! eine direkte Abbildung der fachlichen Architektur zu ermöglichen (ein Task pro verteiltem Objekt der fachlichen Architektur),! die Modularität und Flexibilität der Architektur zu erhöhen,! Datenobjekte in Tasks kapseln zu können,! den Zugriff auf Hardware-Geräte kapseln zu können,! differenziertere Prioritäten zu ermöglichen,! die geforderten Reaktionszeiten einhalten zu können.! So wenige Tasks wie möglich, um! die Kosten für die Kommunikation zwischen Tasks bzw. den Zugriff auf gemeinsame Datenobjekte zu minimieren,! den Verwaltungsaufwand für den Task-Wechsel zu minimieren,! Speicherplatz für Stacks zu sparen,! Test und Debugging zu vereinfachen. In der Praxis: So wenige Tasks wie möglich, so viele wie nötig. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

24 Vor- und Nachteile der RTOS-Architektur! Vorteile! Einfache und klare Implementierung! Senkung der Reaktionszeiten für Task-Operationen im Vergleich zu den drei anderen Architekturen durch erhöhte Asynchronität! Erweiterbarkeit durch modulares Hinzufügen zusätzlicher Tasks und Interrupt-Handler (mit relativ stabilen Reaktionszeiten)! Möglichkeit der Kommunikation zwischen Tasks (und Interrupt- Handlern) über Nachrichten statt über Zugriff auf gemeinsame Daten! Code unverändert sowohl auf Single-Prozessor-Rechnern als auch auf Multi-Prozessor-Rechnern ausführbar! Nachteile! Benötigt Echtzeitbetriebssystem - Erhöhter Speicherbedarf - Erhöhte Softwarekosten bzw. Aufwand für Eigenentwicklung - Aufwand für Task-Wechsel und RTOS-Aufgaben führt insgesamt zu niedrigerem Durchsatz (bzw. erfordert schnelleren Prozessor) Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

25 Vergleich der Basisarchitekturen Prioritäten schlechteste Reaktionszeit für Task-Operationen Stabilität der Reaktionszeiten bei Änderungen des Codes Einfachheit Round-Robin keine Ausführungszeit sämtlichen Codes schlecht sehr einfach Round-Robin mit Interrupts Prioritäten für Interrupt-Handler, danach alle Task- Operationen gleich Ausführungszeit aller Task-Operationen (plus Interrupt-Handler) gut für Interrupt- Handler, schlecht für Task- Operationen einfach, aber koordinierter Zugriff auf gemeinsame Datenobjekte Task-Queue Scheduling Prioritäten für Interrupt-Handler und danach für Task- Operationen Ausführungszeit der längsten Task- Operation (plus Interrupt-Handler) relativ gut einfach, aber Scheduler und koordinierter Zugriff auf gemeinsame Datenobjekte RTOS Prioritäten für Interrupt-Handler und danach für Task- Operationen keine (plus Interrupt- Handler) sehr gut komplex (allerdings versteckt im RTOS) Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

26 Inhalt! Rekapitulation! Architekturen für geschlossene lokale Systeme! Architekturkonzepte und Entwurfstechniken! Beispiel: Underground Tank Monitoring System! Architekturen für geschlossene verteilte Systeme! Architekturkonzepte und Entwurfstechniken! Beispiel: SMT Assembly Equipment! Abstecher und Ausblicke! Asynchronous Transactional Messaging! Offene verteilte Systeme! Zusammenfassung Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

27 Underground Tank Monitoring System Anzeige OK Alarm Tastenfeld Drucker Schwimmer (Messgerät) Thermometer (Messgerät) Beispiel nach [Si99] Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

28 Anforderungen: Überwachung von bis zu acht Tanks! Berechnung des Tankinhalts auf Basis von Füllstand und Temperatur! Kommandogesteuertes Messen des Füllstands für einen Tank! Auslesen der Temperaturdaten zu einem Tank! Kontinuierliche Überwachung der Tankstände! Erkennung von Lecks (wenn Inhalt über Stunden hinweg langsam sinkt)! Überlaufgefahr, wenn Füllstand rapide steigt! Ein- und Ausgabe über Tastenfeld und Anzeige! Eingabe von Befehlssequenzen aus mehreren Tastendrücken! einfache Menüsteuerung sowie Ausgabe von Alarm-Meldungen! Druck-Ausgabe! zum Ausdrucken von Füllstandshistorien etc.! Alarmglocke! Auslösung bei Erkennung eines Lecks oder bei Überlaufgefahr! eigene Taste auf dem Tastenfeld zum Abschalten des letzten Alarms Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

29 Fachliche Architektur - Instanzensicht display keyboard off alarm message key alarm printer report data request ui control data request tank monitor request data alarm overflow/leakage detector timer 0,1s level temperature measure cmd schwimmer1 schwimmer1 schwimmer1 measure cmd schwimmer1 schwimmer1 thermo1 Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

30 Sonstige Anforderungen! Hardware-Aufbau! Relativ langsamer 8-bit-Mikrocontroller! Interrupts treffen ein - von den Schwimmern nach Senden eines Mess-Kommandos, wenn der Füllstand ausgelesen werden kann (Float Interrupt), - vom Drucker nach Druck einer empfangenen Druckzeile (Printer Interrupt), - vom Tastenfeld nach Betätigen einer Taste (Button Interrupt), - von der internen Uhr je nach Einstellung (Timer Interrupt).! Ein- und Ausschalten der Alarmglocke erfolgt über Setzen eines Bits.! Echtzeitanforderungen! Zur Überlauferkennung muss das Auslesen des Füllstands einige Male pro Sekunde erfolgen.! Der Drucker druckt ca. zwei bis drei Zeilen pro Sekunde.! Das Auslesen der Füllstände der Tanks kann nur sequenziell erfolgen.! Der Mikroprozessor benötigt für die Berechnung des Tankinhalts auf Basis von Füllstand und Temperatur etwa 5 Sekunden! Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

31 Grundlegende Entwurfsentscheidungen! Erkennung von Lecks und Überläufen! Für die langfristige Erkennung von Lecks wird die Historie der berechneten Tankinhalte verwendet.! Die kurzfristige Erkennung von Überläufen erfolgt auf Basis der aktuellen Füllstände mehrmals pro Sekunde.! Verwendung eines Echtzeitbetriebssystems! Wenn kein RTOS verwendet wird, müssten sämtliche Operationen mit einer Reaktionszeit unter 5 Sekunden in Interrupts aufgerufen werden (z.b. Update des Displays, Formatierung und Druck von Reports).! Verwendung eines RTOS führt zu einem wesentlich klareren Entwurf: - Kurze Interrupt-Handler garantieren kurze Reaktionszeiten. - Anschlussaktivitäten werden prioritätsgesteuert in Tasks ausgeführt.! Erhältlichkeit eines geeigneten RTOS für den 8-bit-Prozessor muss gegeben sein. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

32 Entwurf der Tasks I! Level Calculation Task zur Berechnung des Tankinhalts! Separater Hintergrund-Task für die langwierige Berechnung des Tankinhalts (Hauptgrund für Auswahl der RTOS-Architektur).! Ein Task für sämtliche Messgeräte, da das Auslesen der Füllstände über die Schwimmer-Hardware nur sequenziell möglich ist und keine besonderen Anforderungen an die Reaktionszeit bestehen.! Overflow Detection Task zur Erkennung von Überläufen! Interrupt-gesteuerter Aufruf hoher Priorität jede 1/10 Sekunde.! Benötigt wie Level Calculation Task Zugriff auf die Mess-Hardware. Zugriff kann über Semaphor synchronisiert werden.! Button Handling Task zur Behandlung der Tastatur! Entgegennahme von Tastendrücken im Interrupt-Handler.! Komplexe Berechnung des Dialogzustands für Menüsteuerung in hochpriorisiertem Task statt im Interrupt-Handler. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

33 Entwurf der Tasks II! Display Task zur Verwaltung der Anzeige! Koordiniert den Zugriff auf die Anzeige-Hardware und verwaltet den Dialogzustand.! Printer Task zur Formatierung von Reports! Interrupt-Handler für Erkennung der Zeilenfortschaltung! Formatierung der Reports in Task mittlerer Priorität! Verwendung von RTOS-Queues als Drucker-Warteschlange! Kein eigener Task zur Verwaltung der Alarmglocke.! Alarmglocke hat außer Ein/Aus keinerlei Zwischen-Zustände, für deren Verwaltung ein eigener Task sinnvoll wäre.! Ein- und Ausschalten kann deshalb jeweils von jedem Task aus erfolgen, der Zugriff auf die Alarmglocke braucht.! Kein eigener Task zur Verwaltung der errechneten Tankinhalt-Daten.! Schneller und unkomplizierter Datenzugriff von Level Calculation Task, Display Task und Printer Task über Shared Memory.! Synchronisation über Semaphor führt nicht zu langen Wartezeiten. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

34 Resultierende Task-Architektur Timer Interrupt request Overflow Detection level Float Interrupt Float Reading Module level & temp Level Calculation Display request Button Interrupt Printer Interrupt Button Handling Printer Task Shared Content Data Nachrichtenversand über RTOS-Queues Aufruf oder Datenzugriff Interrupt-Handler Task Shared Data Module Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

35 Inhalt! Rekapitulation! Architekturen für geschlossene lokale Systeme! Architekturkonzepte und Entwurfstechniken! Beispiel: Underground Tank Monitoring System! Architekturen für geschlossene verteilte Systeme! Architekturkonzepte und Entwurfstechniken! Beispiel: SMT Assembly Equipment! Abstecher und Ausblicke! Asynchronous Transactional Messaging! Offene verteilte Systeme! Zusammenfassung Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

36 Unterschiede zu geschlossenen lokalen Systemen Die meisten Architekturprinzipien und Konzepte aus der geschlossenen lokalen Welt sind übertragbar. Zusätzlich sind zu berücksichtigen:! Höhere Latenz und beschränkte Bandbreite bei der Kommunikation! Zu den Reaktionszeiten müssen jeweils die erforderlichen Übertragungszeiten hinzugerechnet werden.! Die Bandbreite der Verbindung kann Anzahl und Umfang der gesendeten Nachrichten einer bestimmten Priorität beschränken.! Hieraus können zusätzliche Einschränkungen für den Entwurf der Task- Architektur ergeben: Falls eine schnelle Reaktion erforderlich ist, müssen Tasks gegebenenfalls auf einem Mikrocontroller vor Ort ausgeführt werden.! Ausfall von Komponenten oder Kommunikationsverbindungen! Ausfälle müssen erkannt und behandelt werden (vgl. die Patterns aus der vorigen Vorlesung).! Das System muss auch bei Ausfällen von Teilen sicher bleiben und sollte noch möglichst viel Funktionalität anbieten (graceful degradation). Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

37 Formen den Kommunikation! Synchrone Kommunikation: Unter synchroner Kommunikation versteht man einen Modus der Kommunikation, bei dem die Kommunikationspartner (Prozesse) beim Senden oder beim Empfangen von Daten immer synchronisieren, also warten (blockiert), bis die Kommunikation abgeschlossen ist.! Wird sowohl beim Senden als auch beim Empfangen gewartet (der Sender stellt also eine Anfrage und wartet auf Antwort), so entspricht das einem Rendezvous der beiden beteiligten Prozesse.! Das Blockieren des Prozesses wird intern durch geeignete Mechanismen zur Prozesssynchronisation erreicht.! Asynchrone Kommunikation: Modus der Kommunikation, bei dem das Senden und Empfangen von Daten zeitlich versetzt und ohne Blockieren des Prozesses durch bspw. Warten auf die Antwort des Empfängers - dies erfordert explizit oder implizit Warteschlangen. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

38 Verteilte synchrone Kommunikation! Die verteilte synchrone Kommunikation hat gewisse Ähnlichkeiten mit der ebenfalls synchronen Round-Robin-Architektur und teilt einige ihrer Vor- und Nachteile:! einfach zu realisieren und zu verstehen! lange Gesamt-Reaktionszeit (keine Parallelverarbeitung)! eine hängende Komponente bringt das gesamte System zum Stehen client server1 server2 server3 request1 reply1 request2 reply2 request3 reply3 Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

39 Verteilte asynchrone Kommunikation! Sowohl die erhöhte Latenz als auch der Ausfall von Komponenten lassen sich durch verteilte asynchrone Kommunikation teilweise in den Griff bekommen:! Asynchrone Kommunikation erlaubt es dem Versender, weiter zu arbeiten, während eine Nachricht verschickt wurde. Damit lassen sich Wartezeiten und zusätzliche Taskwechsel vermeiden.! Bei einem temporären Ausfall einer Empfänger-Komponente kann weitergearbeitet werden. Bei Zwischenspeicherung der Nachrichten in Queues kann er sogar transparent überbrückt werden.! Grundsätzlich lassen sich zwei Kommunikationsarten unterscheiden:! Der Sender kennt den Empfänger und kann direkt mit ihm kommunizieren (Beispiel: CORBA Messaging).! Die Kommunikation erfolgt indirekt über zwischengeschaltete Nachrichtenkanäle, bei denen sich die Partner als Sender oder Empfänger registrieren (Beispiele: CORBA Event Service, CORBA Notification Service, Java Messaging Service). Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

40 CORBA Messaging: One-Ways! Wird standardmäßig von CORBA durch das Schlüsselwort oneway unterstützt, allerdings ohne jede Auslieferungsgarantie: best try.! Asynchronous Messaging unterstützt über Policies feinere Abstufungen und macht damit das oneway-schlüsselwort obsolet:! SYNC_NONE: kein Blockieren, keine Auslieferungsgarantie (wie oneway)! SYNC_WITH_TRANSPORT: Blockieren, bis an Transportschicht übergeben! SYNC_WITH_SERVER: Blockieren, bis an Server-ORB übergeben! SYNC_WITH_TARGET: Blockieren, bis vollständig ausgeführt (normaler Aufruf) Bild aus [SV03] Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

41 CORBA Messaging: Asynchronous Method Invocation! Neben dem Versenden von One-Way-Nachrichten gibt es auch die Möglichkeit, Methodenaufrufe mit Rückgabewerten asynchron aufzurufen (AMI).! CORBA Messaging bietet hier zwei Möglichkeiten:! Rückgabewert ist ein lokales Poller-Objekt, das dann vom Client aktiv abgefragt werden kann, bis die Antwort angekommen ist. Der Client kann auch entscheiden, am Poller zu blockieren.! Der Client übergibt eine Callback-Methode, die vom ORB aufgerufen, wenn die Antwort angekommen ist. Dazu muss der Client die Kontrolle an den ORB abgeben.! Durch die Nutzung dieser Möglichkeiten kann der Entwickler des Clients die Parallelität erhöhen. Dazu muss er seine Anwendung nicht in unterschiedliche Threads aufteilen, nur um jeweils auf die Rückkehr der blockierenden synchronen Aufrufe zu warten. Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

42 Beispiel für Nutzung von AMI mit Polling client server1 server2 request1 poller1 request1 request2 poller2 poll nope poll reply1 poll reply2 reply1 request2 reply2 Softwarearchitektur verteilter Systeme eingebettete Systeme Teil II - M. Broy WS 10/

Softwarearchitektur verteilter Systeme

Softwarearchitektur verteilter Systeme Softwarearchitektur verteilter Systeme 13. Fallstudie eingebettete Systeme Vorlesung Wintersemester 2005 / 06 Technische Universität München Institut für Informatik Lehrstuhl von Prof. Dr. Manfred Broy

Mehr

Softwarearchitektur (Architektur: αρχή = Anfang, Ursprung + tectum = Haus, Dach)

Softwarearchitektur (Architektur: αρχή = Anfang, Ursprung + tectum = Haus, Dach) Softwarearchitektur (Architektur: αρχή = Anfang, Ursprung + tectum = Haus, Dach) 12. Fallstudien eingebettete Systeme Vorlesung Wintersemester 2008 / 09 Technische Universität München Institut für Informatik

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Sowohl RTX64 als auch RTX bieten harten Echtzeitdeterminismus und symmetrische Multiprocessing- Fähigkeiten (SMP).

Sowohl RTX64 als auch RTX bieten harten Echtzeitdeterminismus und symmetrische Multiprocessing- Fähigkeiten (SMP). Produktbeschreibung Februar 2014 RTX RTOS-Plattform Mit der RTX-Echtzeitsoftware von IntervalZero wird aus Microsoft Windows ein Echtzeitbetriebssystem (RTOS). RTX64 von IntervalZero unterstützt 64-Bit-Betriebssysteme

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

RTEMS- Echtzeitbetriebssystem

RTEMS- Echtzeitbetriebssystem RTEMS- Echtzeitbetriebssystem Name: Hussein Hammoud Matrikel- Nr.: 230768 Studiengang: Technische Informatik Fach: Projekt Eingebettete Kommunikation Technische Universität Berlin Sommersemester 2006 RTEMS-

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Frank Kargl Torsten Illmann Michael Weber Verteilte Systeme Universität Ulm {frank.kargl torsten.illmann weber} @informatik.uni-ulm.de

Mehr

Military Air Systems

Military Air Systems Trennung von Applikationen unterschiedlicher Kritikalität in der Luftfahrt durch Software en am Beispiel des Real-time Operating Systems PikeOS Dr. Bert Feldmann DGLR Workshop Garching, 09.10.2007 Seite

Mehr

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg COMMON OBJECT REQUEST BROKER ARCHITECTURE Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg Gliederung Motivation Was ist CORBA? Object Management Architecture (OMA ) Interface Definition Language

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

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003 Task! evt. parallel zu bearbeitende Ausführungseinheit! Beispiel: Task A Zündung Task B Einspritzung Task C Erfassung Pedalwert Zeit t J. Schäuffele, Th. Zurawka:, Vieweg, 2003 Echtzeitbetriebssysteme

Mehr

CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik)

CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik) Prof. Dr. Th. Letschert CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik) Vorlesung 7 Th Letschert FH Gießen-Friedberg Ressourcen Verwaltung passive Ressourcen aktive Ressourcen

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

Betriebssystembau (BSB)

Betriebssystembau (BSB) Betriebssystembau (BSB) 6. Übung http://ess.cs.tu-.de/de/teaching/ws2013/bsb/ Olaf Spinczyk olaf.spinczyk@tu-.de http://ess.cs.tu-.de/~os AG Eingebettete System Informatik 12, TU Dortmund Agenda Vorstellung

Mehr

3 Programmiermodelle für parallele und verteilte Systeme

3 Programmiermodelle für parallele und verteilte Systeme 3 Programmiermodelle für parallele und verteilte Systeme Das vorherrschende Programmiermodell für parallele und verteilte Systeme ist das Client Server Modell. Das Client Server Modell ist unabhängig von

Mehr

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis...

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis... 1 Einführung................................................ 1 1.1 Was ist ein Betriebssystem?............................... 1 1.1.1 Betriebssystemkern................................ 2 1.1.2 Systemmodule....................................

Mehr

Technische Informatik II

Technische Informatik II Institut für Technische Informatik und Kommunikationsnetze Technische Informatik II Übung 1: Prozesse und Threads Aufgabe 1: Prozesse und Threads a) Wie verhält sich eine Applikation die aus mehreren Prozessen

Mehr

Musterlösung Klausur SS 2004

Musterlösung Klausur SS 2004 Musterlösung Klausur SS 2004 Fachrichtung: Informatik Lehrveranstaltung: Verteilte Systeme Dozent: Prof. G. Bengel Tag: 15.6.04 Bearbeitungszeit: 90 Minuten Name:... Matr.Nr.:... Punkte:... Note:... Hilfsmittel:

Mehr

Java 2, Enterprise Edition Einführung und Überblick

Java 2, Enterprise Edition Einführung und Überblick Universität aiserslautern AG Datenbanken und Informationssysteme Seminar Datenbank-Aspekte des E-Commerce Java 2, Enterprise Edition Einführung und Überblick m_husema@informatik.uni-kl.de Vortragsinhalte

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

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

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen Albrecht Achilles 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Betriebssysteme Eine kompakte Einführung mit Linux

Mehr

Datentechnik. => Das Rechenergebnis ist nur dann sinnvoll, wenn es rechtzeitig vorliegt. Die Zeit muß daher beim Programmdesign berücksichtigt werden.

Datentechnik. => Das Rechenergebnis ist nur dann sinnvoll, wenn es rechtzeitig vorliegt. Die Zeit muß daher beim Programmdesign berücksichtigt werden. 5. Steuerung technischer Prozesse 5.1 Echtzeit (real time) Im Gegensatz zu Aufgabenstellungen aus der Büroumgebung, wo der Anwender mehr oder weniger geduldig wartet, bis der Computer ein Ergebnis liefert

Mehr

Domänenmodell: Fadenkommunikation und -synchronisation

Domänenmodell: Fadenkommunikation und -synchronisation Domänenmodell: Fadenkommunikation und -synchronisation Alexander Humphreys, Reinhard Rösch, Fabian Scheler 15. Mai 2003 Inhaltsverzeichnis 1 Domänendefinition 1 2 Domänenlexikon 1 3 Konzeptmodelle 4 4

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

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

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

OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme

OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme Wilhelm Haas Wilhelm.Haas@informatik.stud.uni-erlangen.de Friedrich-Alexander-Universität Erlangen-Nürnberg Institut für Informatik Lehrstuhl 4

Mehr

Einführung in die Echtzeitbetriebssysteme

Einführung in die Echtzeitbetriebssysteme Einführung in die Echtzeitbetriebssysteme Hauptseminararbeit in dem Studiengang B.Sc. Informatik von Maximilian von Piechowski Technische Hochschule Mittelhessen Inhaltsverzeichnis 1 Was versteht man unter

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

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Autorisierung Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Dokumentation zum Referat von Matthias Warnicke und Joachim Schröder Modul: Komponenten basierte Softwareentwickelung

Mehr

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013. WebSphere MQ Teil 3

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013. WebSphere MQ Teil 3 UNIVERSITÄT LEIPZIG Enterprise Computing Einführung in das Betriebssystem z/os Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013 WebSphere MQ Teil 3 Trigger el0100 Copyright W. G. Spruth,

Mehr

Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung

Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung Wintersemester 2009/10 Prof. Dr. Dr. h.c. Manfred Broy Unter Mitarbeit von Dr. K. Spies, Dr. M. Spichkova, L. Heinemann, P.

Mehr

Aufbau eines Echtzeit-Betriebssystems für Embedded Systems

Aufbau eines Echtzeit-Betriebssystems für Embedded Systems Aufbau eines Echtzeit-Betriebssystems für Embedded Systems I. Begriffsdefinition II. Anforderungen III. Struktur und Komponenten Dr.-Ing. Ludwig Eckert, Seite 1 I. Begriffsdefinition: Embedded System Bsp.:

Mehr

Seminar: Mobile Geräte QNX Einführung

Seminar: Mobile Geräte QNX Einführung Seminar: Mobile Geräte QNX Einführung Vortragender: Alex Maurer 2010/2011 Philipps Universität Marburg Echtzeitbetriebssystem QNX QNX ist ein RTOS (Real Time OS) vorhersagbares Zeitverhalten niedrige Latenz

Mehr

Software-basierter Speicherschutz durch spezialisierte Java-VMs auf Mikrocontrollersystemen

Software-basierter Speicherschutz durch spezialisierte Java-VMs auf Mikrocontrollersystemen Software-basierter Speicherschutz durch spezialisierte Java-VMs auf Mikrocontrollersystemen Christian Wawersich Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme Universität Erlangen-Nürnberg

Mehr

Verteilte Systeme CS5001

Verteilte Systeme CS5001 Verteilte Systeme CS5001 Th. Letschert TH Mittelhessen Gießen University of Applied Sciences Client-Server-Anwendungen: Vom passiven (shared state) Monitor zum aktiven Monitor Monitor (Hoare, Brinch-Hansen,

Mehr

Übungen zu Softwaretechnik

Übungen zu Softwaretechnik Prof. Dr. Dr. h.c. M. Broy Lösungsblatt 11 Dr. H. Ehler, S. Wagner 23. Januar 2004 Übungen zu Softwaretechnik Aufgabe 16 Qualitätseigenschaften Broker-Pattern Beurteilen Sie das in Aufgabe 15 benutzte

Mehr

Performance Messungen von FreeRTOS und

Performance Messungen von FreeRTOS und Performance Messungen von FreeRTOS und µc/os-iii auf ARM-Architekturen Tim Wacher (wht4@bfh.ch) Master of Science in Engineering MRU Production Technology 16. August 2011/ CH-3400 Burgdorf Outline 1 Ziel

Mehr

Rapid I/O Toolkit. http://projects.spamt.net/riot. Alexander Bernauer alex@copton.net 08.12.08

Rapid I/O Toolkit. http://projects.spamt.net/riot. Alexander Bernauer alex@copton.net 08.12.08 Rapid I/O Toolkit http://projects.spamt.net/riot Alexander Bernauer alex@copton.net 08.12.08 Inhalt Motivation Architektur Beispiel I/O Features Ausblick Motivation Problemstellung Vorgaben Datenverarbeitung

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

SurefireKernel ÜBERSICHT SPEZIFIKATION. www.triadem.ch. Sicherheitskernel DATASHEET

SurefireKernel ÜBERSICHT SPEZIFIKATION. www.triadem.ch. Sicherheitskernel DATASHEET Sicherheitskernel ÜBERSICHT SurefireKernel ist ein schlanker skalierbarer nicht preemptiver Echtzeit-Kernel der für den Einsatz auf Kontrollersysteme optimiert ist. Er verfügt über eine Realtime-Überwachung

Mehr

VS3 Slide 1. Verteilte Systeme. Vorlesung 3 vom 22.04.2004 Dr. Sebastian Iwanowski FH Wedel

VS3 Slide 1. Verteilte Systeme. Vorlesung 3 vom 22.04.2004 Dr. Sebastian Iwanowski FH Wedel VS3 Slide 1 Verteilte Systeme Vorlesung 3 vom 22.04.2004 Dr. Sebastian Iwanowski FH Wedel Inhaltsverzeichnis für die Vorlesung Zur Motivation: 4 Beispiele aus der Praxis Allgemeine Anforderungen an Verteilte

Mehr

Architektur Verteilter Systeme Teil 2: Prozesse und Threads

Architektur Verteilter Systeme Teil 2: Prozesse und Threads Architektur Verteilter Systeme Teil 2: Prozesse und Threads 21.10.15 1 Übersicht Prozess Thread Scheduler Time Sharing 2 Begriff Prozess und Thread I Prozess = Sequentiell ablaufendes Programm Thread =

Mehr

2. Hintergrundverarbeitung in Android: Services und Notifications

2. Hintergrundverarbeitung in Android: Services und Notifications 2. Hintergrundverarbeitung in Android: Services und Notifications Übersicht 2. Hintergrundverarbeitung in Android: Services und Notifications Übersicht: In Mobis 1: Threads; hier genauerer Blick auf Services

Mehr

SMTP-Verfahren POP-Verfahren IMAP-Verfahren

SMTP-Verfahren POP-Verfahren IMAP-Verfahren IT Zertifikat Mailserver 01 Server Mailserver Protokolle Teil des Client-Server-Modells bietet Dienste für lokale Programme/ Computer (Clients) an -> Back-End-Computer Ausbau zu Gruppe von Servern/ Diensten

Mehr

Zur Erinnerung: Threads. Threadverwaltung. Threads: Prioritäten. Beispiel Flugbuchungsprogramm. Nichtdeterminismus

Zur Erinnerung: Threads. Threadverwaltung. Threads: Prioritäten. Beispiel Flugbuchungsprogramm. Nichtdeterminismus Zur Erinnerung: Threads Programmierung (fortgeschrittene Konzepte) Threads, Monitore, Semaphore und speisende en Wolf-Ulrich Raffel (uli@wuraffel.de) Möglichkeiten, Threads zu definieren Bildung einer

Mehr

Klausurvorbereitung VS1 (Prof. Brecht) (B0rg Edition)

Klausurvorbereitung VS1 (Prof. Brecht) (B0rg Edition) Ein Prozess kann unmittelbar vom Zustand 1. Running in den Zustand Ready 2. Running in den Zustand Blocked 3. Ready in den Zustand Running Klausurvorbereitung VS1 (Prof. Brecht) (B0rg Edition) Der Adressraum

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 21.11.2012 1 Begrüßung Heute ist Tag der offenen Tür Willkommen allen Schülerinnen und Schülern! 2 Testat nach Weihnachten Mittwoch

Mehr

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

Vorbereitung zur Prüfung Echtzeitbetriebssysteme

Vorbereitung zur Prüfung Echtzeitbetriebssysteme Vorbereitung zur Prüfung Echtzeitbetriebssysteme Zugelassene Hilfsmittel: Taschenrechner Bitte verwenden Sie keinen roten Farbstift! 1. Echtzeitbetriebssysteme - Allgemein (15 Punkte) 1.1. Warum setzen

Mehr

Motivation. Motivation

Motivation. Motivation Vorlesung Modellierung nebenläufiger Systeme Sommersemester 2012 Universität Duisburg-Essen Was sind nebenläufige Systeme? Ganz allgemein: Systeme, bei denen mehrere Komponenten/Prozesse nebenläufig arbeiten

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1 Grid-Systeme Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit 07.06.2002 Grid Systeme 1 Gliederung Vorstellung verschiedener Plattformen Globus

Mehr

Funktionskapselung in Steuergeräten

Funktionskapselung in Steuergeräten Funktionskapselung in Steuergeräten Mobilität und Echtzeit Boppard am Rhein, 07.12.2007 Stand: 07.12.2007 1 Funktionskapselung in Steuergeräten Inhalt Ausgangssituation und Motivation Begriff "Kapselung"

Mehr

SWT II Projekt. Chat - Anwendung. Pflichtenheft 2000 SWT

SWT II Projekt. Chat - Anwendung. Pflichtenheft 2000 SWT SWT II Projekt Chat - Anwendung Pflichtenheft 2000 SWT i Versionen Datum Version Beschreibung Autor 3.11.2000 1.0 erste Version Dietmar Matthes ii Inhaltsverzeichnis 1. ZWECK... 1 1.1. RAHMEN... 1 1.2.

Mehr

OMEGA Architektur. Verlässlichkeit komponentenbasierter Systeme. Hauptseminar Softwaretechnik Falk Reimann EGS Softwaretechnik

OMEGA Architektur. Verlässlichkeit komponentenbasierter Systeme. Hauptseminar Softwaretechnik Falk Reimann EGS Softwaretechnik Verlässlichkeit komponentenbasierter Systeme Hauptseminar Softwaretechnik EGS Softwaretechnik s7286510@inf.tu-dresden.de Betreuer: Steffen Zschaler Überblick Motivation QoS Broker QoS Protokoll Dienste

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS geschrieben von Oliver Botschkowski 1 Offene Systeme und deren Schnittstelle für die Elektronik im Kraftfahrzeug 1 Oliver Botschkowski - OSEK-OS

Mehr

Ethernet als Bus für Echtzeitanwendungen im Automobil:

Ethernet als Bus für Echtzeitanwendungen im Automobil: Ethernet als Bus für Echtzeitanwendungen im Automobil: Konzepte aus der Automatisierungsbranche Hochschule für Angewandte Wissenschaften Hamburg Anwendungen 1 WS 08/09 16. Dezember 2008 Wie alles began

Mehr

HighQSoft GmbH www.highqsoft.de 21.05.2015. AVALON Distributor. Skalierbarkeit und Ausfallsicherheit. Dieter Müller

HighQSoft GmbH www.highqsoft.de 21.05.2015. AVALON Distributor. Skalierbarkeit und Ausfallsicherheit. Dieter Müller Distributor Skalierbarkeit und Ausfallsicherheit Dieter Müller 1 Übersicht 1) Motivation zur Erstelllung des Distributors 2) Anforderungen für die Implementierung 3) Systemarchitektur Distributor 4) Konfiguration

Mehr

Der Einsatz von CORBA in verteilten EDA-Tools

Der Einsatz von CORBA in verteilten EDA-Tools Der Einsatz von CORBA in verteilten EDA-Tools Frank Grützmacher Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Fachgebiet Mikroelektronische Schaltungen und Systeme

Mehr

Multiuser Client/Server Systeme

Multiuser Client/Server Systeme Multiuser /Server Systeme Christoph Nießner Seminar: 3D im Web Universität Paderborn Wintersemester 02/03 Übersicht Was sind /Server Systeme Wie sehen Architekturen aus Verteilung der Anwendung Protokolle

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

Untersuchungen zur Zulassung von Software unterschiedlicher Sicherheitsklassen auf einem Prozessormodule unter dem neuartigen Betriebssystem PikeOS

Untersuchungen zur Zulassung von Software unterschiedlicher Sicherheitsklassen auf einem Prozessormodule unter dem neuartigen Betriebssystem PikeOS Untersuchungen zur Zulassung von Software unterschiedlicher Sicherheitsklassen auf einem Prozessormodule unter dem neuartigen Betriebssystem PikeOS Automotive Safety & Security 2008 Stuttgart, 19. 20.11.2008

Mehr

AN025. Application Note 025 zu MODULAR-4 (ML3 und ML5) Messen der CPU-Auslastung im Echtzeitbetrieb

AN025. Application Note 025 zu MODULAR-4 (ML3 und ML5) Messen der CPU-Auslastung im Echtzeitbetrieb AN025 Application Note 025 zu MODULAR-4 (ML3 und ML5) Messen der Autor: HB AN025.DOC (6 Seiten) 1. Definition Im folgenden wie auch in allen anderen Sorcus Schriften werden folgende Kurzbezeichnungen verwendet:

Mehr

2 Echtzeitbetriebssysteme

2 Echtzeitbetriebssysteme 35 2 Echtzeitbetriebssysteme In den letzten Jahren hat sich die Automobilindustrie zu einem der wesentlichen Anwender von Echtzeitbetriebssystemen für eingebettete Systeme entwickelt. Relativ zeitig erkannten

Mehr

Java RMI Remote Method Invocation

Java RMI Remote Method Invocation Java RMI Remote Method Invocation Ziel: Aufruf von Instanzmethoden entfernter Objekte basierend auf Java. Paket: java.rmi und Unterpakete Topologie: RMI Registry RMI Server RMI Client Der Server registriert

Mehr

Kap. 6 Message-Oriented Middleware (MOM)

Kap. 6 Message-Oriented Middleware (MOM) Kap. 6 Message-Oriented Middleware (MOM) G 6.1Asynchrone Prozedur- bzw. Methodenaufrufe Lose Kopplung von Komponenten G 6.2Queued Transactions Entkopplung von Client/Server-Transaktionen G 6.3Publish/Subscribe-Techniken

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

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

Call Button / HTTP - Systembeschreibung

Call Button / HTTP - Systembeschreibung Call Button / HTTP - Systembeschreibung Detlef Reil, 14.03.2004, zu Call Button, Version 040127, V1.50 Beta! Software System Für die Kommunikation zwischen den Call Buttons und der Applikation war bisher

Mehr

Client/Server-Systeme

Client/Server-Systeme Frühjahrsemester 2011 CS104 Programmieren II / CS108 Programmier-Projekt Java-Projekt Kapitel 3: /Server-Architekturen H. Schuldt /Server-Systeme Ein zweischichtiges /Server-System ist die einfachste Variante

Mehr

Service Virtualisierung

Service Virtualisierung Service Virtualisierung So bekommen Sie Ihre Testumgebung in den Griff! Thomas Bucsics ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 8 10. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Embedded OS für ARM Cortex Microcontroller

Embedded OS für ARM Cortex Microcontroller Embedded OS für ARM Cortex Microcontroller RTOS Design, Timinganalyse und Test mit Core Simulation und Hardware Debugger Entscheidende Fragen für oder gegen RTOS Lohnt sich der Einsatz eines RTOS auch

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

Collaborative Virtual Environments

Collaborative Virtual Environments Collaborative Virtual Environments Stefan Lücking Projektgruppe Kreativität und Technik AG Domik WS 02/03 09.01.2003 1/35 Was sind CVE? Versuch einer Definition : Ein CVE ist ein Programm, das eine virtuelle

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Kap. 6 Message-Oriented Middleware (MOM)

Kap. 6 Message-Oriented Middleware (MOM) Kap. 6 Message-Oriented Middleware (MOM) 6.1Asynchrone Prozedur- bzw. Methodenaufrufe Lose Kopplung von Komponenten 6.2Queued Transactions Entkopplung von Client/Server-Transaktionen 6.3Publish/Subscribe-Techniken

Mehr

Business Process Execution Language for Web Services (BPEL4WS)

Business Process Execution Language for Web Services (BPEL4WS) Hauptseminar und Vorlesung Web Services WS 2003/04 Business Process Execution Language for Web Services (BPEL4WS) Patrick Sauter 2/17 Vortrag - Überblick Definition, Zielsetzung und Allgemeines einfacher

Mehr

EasyLab: Modell-basierte Software-Entwicklung für mechatronische Systeme

EasyLab: Modell-basierte Software-Entwicklung für mechatronische Systeme EasyLab: Modell-basierte Software-Entwicklung für mechatronische Systeme Prof. Dr.-Ing. habil. Alois Knoll (k@tum.de) Lehrstuhl für Echtzeitsysteme und Robotik Institut für Informatik Technische Universität

Mehr

Informatik. Studiengang Chemische Technologie. Michael Roth WS 2012/2013. michael.roth@h-da.de. Hochschule Darmstadt -Fachbereich Informatik-

Informatik. Studiengang Chemische Technologie. Michael Roth WS 2012/2013. michael.roth@h-da.de. Hochschule Darmstadt -Fachbereich Informatik- Informatik Studiengang Chemische Technologie Michael Roth michael.roth@h-da.de Hochschule Darmstadt -Fachbereich Informatik- WS 2012/2013 Inhalt Teil VII Einstieg in Java I Michael Roth (h_da) Informatik

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

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

Überblick. Netzprogrammierung 2. Remote Procedure Calls. Remote Procedure Call RPC

Überblick. Netzprogrammierung 2. Remote Procedure Calls. Remote Procedure Call RPC Überblick 1. Remote rocedure Call 2. Komponenten beim RC 3. Fehler programmierung 2. Remote rocedure Calls rof. Dr.-Ing. Robert Tolksdorf Freie Universität Berlin Institut für Informatik basierte Informationssysteme

Mehr

Java und XML 2. Java und XML

Java und XML 2. Java und XML Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003

Mehr

Codesigned Virtual Machines

Codesigned Virtual Machines Codesigned Virtual Machines Seminar Virtualisierung Philipp Kirchhofer philipp.kirchhofer@student.kit.edu Institut für Technische Informatik Lehrstuhl für Rechnerarchitektur Universität Karlsruhe (TH)

Mehr

Existierende Systeme I Bibliotheken & Frameworks

Existierende Systeme I Bibliotheken & Frameworks Projektgruppe: Generierung von Webanwendungen aus visuellen Spezifikationen Existierende Systeme I Bibliotheken & Frameworks Von Christian Schneider Paderborn, den 18.06.2004 Übersicht Motivation Dynamische

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

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Nebenläufige und verteilte Programme CS2301

Nebenläufige und verteilte Programme CS2301 Nebenläufige und verteilte Programme CS2301 Th. Letschert TH Mittelhessen Gießen University of Applied Sciences Netze mit aktiven und reaktiven Knoten Produzent Konsument: aktiv / passiv / reaktiv

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

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

OSEK/VDX NM (Network Management)

OSEK/VDX NM (Network Management) OSEK/VDX NM (Network Management) Alexander Berger alexander.berger@uni-dortmund.de PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Motivation Aufgaben des NM Architektur Konzept und Verhalten Indirektes

Mehr

3.2 Der CORBA-Standard Common Object Request Broker Architecture

3.2 Der CORBA-Standard Common Object Request Broker Architecture 3.2 Der CORBA-Standard Common Object Request Broker Architecture (Bildquelle: OMG) Kapitel 3.2: Vorlesung CORBA 1 CORBA Middleware im Ueberblick G CORBA = Common Object Request Broker Architecture. Standard

Mehr

Der Scheduler von Windows Konzepte und Strategien

Der Scheduler von Windows Konzepte und Strategien Gliederung Der Scheduler von Windows Konzepte und Strategien Daniel Lohmann 1 Grundbegriffe 2 Eigenschaften des Schedulers Grundlegende Eigenschaften Prioritätenmodell Dynamische Prioritätenanpassungen

Mehr