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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Architektur Verteilter Systeme Teil 6: Interprozess-Kommunikation

Architektur Verteilter Systeme Teil 6: Interprozess-Kommunikation Architektur Verteilter Systeme Teil 6: Interprozess-Kommunikation 09.05.15 1 Literatur [6-1] http://php.net/manual/de/book.sockets.php [6-2] http://de.wikipedia.org/wiki/socket_(software) [6-3] http://php.net/manual/de/book.network.php

Mehr

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Block Verteilte Systeme und Middleware 1. Beschreiben Sie die Entwicklung verteilter Systeme von einer Zentralisierung bis zu Peer-to-Peer. Nicht

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

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz Systeme I: Betriebssysteme Kapitel 7 Scheduling Maren Bennewitz Version 23.01.2013 1 Inhalt Vorlesung Aufbau einfacher Rechner Überblick: Aufgabe, Historische Entwicklung, unterschiedliche Arten von Betriebssystemen

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

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

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

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

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem 1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem Management, Access Management a. Event Management b. Service Desk c. Facilities Management d. Change Management e. Request Fulfilment

Mehr

Loadbalancing und Clustering mit Tomcat 6

Loadbalancing und Clustering mit Tomcat 6 Loadbalancing und Clustering mit Tomcat 6 Java Forum Stuttgart 3. Juli 2008 Michael Heß ORDIX AG, Paderborn mhe@ordix.de www.ordix.de Agenda Zielsetzung des Vortrags Webserver Integration Loadbalancing

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

Inhaltsverzeichnis. 2.4 Thread-Systeme. 2.1 Was ist ein Prozess? 2.2 Scheduling. 2.3 Interprozesskommunikation

Inhaltsverzeichnis. 2.4 Thread-Systeme. 2.1 Was ist ein Prozess? 2.2 Scheduling. 2.3 Interprozesskommunikation Inhaltsverzeichnis Systemprogrammierung - Kapitel 2 Prozessverwaltung 1/21 2.1 Was ist ein Prozess? Definition Prozesszustände Prozesskontrollblöcke 2.4 Thread-Systeme Sinn und Zweck Thread-Arten Thread-Management

Mehr

Projektaufgabe Peer-To-Peer Chat Programm

Projektaufgabe Peer-To-Peer Chat Programm Projektaufgabe Peer-To-Peer Chat Programm Betreuer: Dipl. Ing. Thomas Kehrt kehrt@cs.tu-dortmund.de September 10, 2014 1 Einführung Im Rahmen des Vorkurses wird für fortgeschrittene Studenten eine Projektarbeit

Mehr

Lightweight Java in der Automatisierungstechnik

Lightweight Java in der Automatisierungstechnik Lightweight Java in der Automatisierungstechnik Erfahrungen aus dem Anlagenbau Dr. Markus Eiglsperger eig@zuehlke.com Business Driver im Anlagenbau Kosten Modularisierung Vernetzung Agilität Paradigmenwechsel

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

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

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

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

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

Reflex The Real-Time Event Flow EXecutive

Reflex The Real-Time Event Flow EXecutive Einführung The Real-Time Event Flow EXecutive Karsten Walther, und Jörg Nolte Brandenburgische Technische Universität Cottbus 1. Statusseminar des InnoProfile Projekt TANDEM 2007 Gliederung Einführung

Mehr

Reaktive Systeme und synchrones Paradigma

Reaktive Systeme und synchrones Paradigma Sascha Kretzschmann Freie Universität Berlin Reaktive Systeme und synchrones Paradigma Einführung in das Seminar über synchrone Programmiersprachen Worum geht es? INHALT 2 Inhalt 1. Einleitung - Wo befinden

Mehr

Prof. Dr.-Ing. Dagmar Meyer Architekturen verteilter SW-Systeme 5 SYNCHRONISATION

Prof. Dr.-Ing. Dagmar Meyer Architekturen verteilter SW-Systeme 5 SYNCHRONISATION Prof. Dr.-Ing. Dagmar Meyer 5 SYNCHRONISATION Warum braucht man Synchronisation? Ausgangssituation Prozesse müssen sich koordinieren / synchronisieren, z. B. beim Zugriff auf gemeinsame Ressourcen. Alle

Mehr

20 Eingebettete Software

20 Eingebettete Software 20 Eingebettete Software 20.0 Einführung Lernziele Echtzeitsysteme Eingebettete Systeme 20.1 Entwurf eingebetteter Systeme Modellierung von Echtzeitsystemen Programmierung von Echtzeitsystemen 20.2 Architekturmuster

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

DBUS Interprozess-Kommunikation für Embedded-Plattformen

DBUS Interprozess-Kommunikation für Embedded-Plattformen DBUS Interprozess-Kommunikation für Embedded-Plattformen Andreas Schwarz Neratec Solutions AG Firmenprofil Neratec Solutions AG Produkt-Entwicklungen für kundenspezifische elektronische Produkte Produkte

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

Kap. 7 IS-Infrastruktur: Zusammenfassung

Kap. 7 IS-Infrastruktur: Zusammenfassung Kapitel 7: Zusammenfassung Teil I. 1 Kap. 7 IS-Infrastruktur: Zusammenfassung In Teil I haben wir verschiedene Middleware-Lösungen zur Entwicklung (komplexer), verteilter Informationssysteme kennengelernt

Mehr

5. Threads, Serverprozesse und Benachrichtigungen

5. Threads, Serverprozesse und Benachrichtigungen 5. Threads, Serverprozesse und Benachrichtigungen Threads allgemein Threads in Android: Handler und Messages Services: Local, Remote, Binding Benachrichtigungen Entwicklung mobiler Anwendungen Europäische

Mehr

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Mehr

Real Time Operating Systems (RTOS) = Echtzeit-Betriebssysteme. Eine Einführung. Klaus Kusche, Okt. 2011

Real Time Operating Systems (RTOS) = Echtzeit-Betriebssysteme. Eine Einführung. Klaus Kusche, Okt. 2011 Real Time Operating Systems (RTOS) = Echtzeit-Betriebssysteme Eine Einführung Klaus Kusche, Okt. 2011 Ziele des Vortrags Überblick über das Thema Praktisches Verständnis von Anforderungen Problembereichen

Mehr

Echtzeitanforderung und Linux

Echtzeitanforderung und Linux Echtzeitanforderung und Linux Slide 1 - http://www.pengutronix.de - 21.01.2007 Definition Harte Echtzeit I Was zeichnet ein Echtzeitsystem aus? Zeitverhalten ist Teil der System-Spezifikation! Bei Embedded-Systemen

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

Zeit- und ereignisgesteuerte Echtzeitsysteme

Zeit- und ereignisgesteuerte Echtzeitsysteme Zeit- und ereignisgesteuerte Echtzeitsysteme Stephan Braun Stephan.Braun.Hagen@t-online.de PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Echtzeitsystemmodell Einführung Ereignis- und zeitgesteuerte

Mehr

Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching. Rainer Müller

Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching. Rainer Müller Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching Rainer Müller 21. November 2013 Spezialisierung von Betriebssystemen Vielzweckbetriebssysteme (General Purpose OS,

Mehr

Persönlichkeiten bei bluehands

Persönlichkeiten bei bluehands Persönlichkeiten bei Technologien bei Skalierbare Anwendungen mit Windows Azure GmbH & co.mmunication KG am@.de; posts..de/am 1 2 3 4 5 6 7 8 9 Immer mehr Mehr Performance Mehr Menge Mehr Verfügbarkeit

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

Automotive Software Engineering

Automotive Software Engineering Jorg Schauffele Thomas Zurawka Automotive Software Engineering Grundlagen, Prozesse, Methoden und Werkzeuge Mit 278 Abbildungen ATZ-MTZ-Fachbuch vieweg Inhaltsverzeichnis 1 Einfiihrung und Uberblick 1

Mehr

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum Analyse der Android Plattform Andre Rein, Johannes Florian Tietje FH-Gieÿen-Friedberg Android Praktikum 28. Oktober 2010 Topics 1 Übersicht Android Plattform Application Framework Activities und Services

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

POSIX Echtzeit: Kernel 2.6 und Preempt-RT

POSIX Echtzeit: Kernel 2.6 und Preempt-RT POSIX Echtzeit: Kernel 2.6 und Preempt-RT Slide 1 - http://www.pengutronix.de - 21.01.2007 Echtzeit-Systemplanung Wenn das zeitliche Verhalten spezifiziert ist, kann auch spezifiziert werden, welche Applikationsteile

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

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

Android Processes & Services

Android Processes & Services Android Processes & Services Jürg Luthiger University of Applied Sciences Northwestern Switzerland Institute for Mobile and Distributed Systems Ziele heute Arbeitsblatt 4 besprechen (inkl. Repetition)

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

^ Springer Vi eweg. Grundkurs Betriebssysteme. Synchronisation, Prozesskommunikation, Virtualisierung. Architekturen, Betriebsmittelverwaltung,

^ Springer Vi eweg. Grundkurs Betriebssysteme. Synchronisation, Prozesskommunikation, Virtualisierung. Architekturen, Betriebsmittelverwaltung, Peter Mandl Grundkurs Betriebssysteme Architekturen, Betriebsmittelverwaltung, Synchronisation, Prozesskommunikation, Virtualisierung 4. Auflage ^ Springer Vi eweg 1 Einführung 1 1.1 Computersysteme 1

Mehr

OSEK / COM. Inhaltsverzeichnis. Abbildungsverzeichnis. Florian Hohnsbehn. PG AutoLab Seminarwochenende 21.-23. Oktober 2007

OSEK / COM. Inhaltsverzeichnis. Abbildungsverzeichnis. Florian Hohnsbehn. PG AutoLab Seminarwochenende 21.-23. Oktober 2007 OSEK / COM Florian Hohnsbehn PG AutoLab Seminarwochenende 21.-23. Oktober 2007 Inhaltsverzeichnis Abbildungsverzeichnis 1 1 Einführung 1.1 Was ist OSEK COM? OSEK COM ist eine vom OSEK-VDX-Konsortium entwickelte

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

Echtzeitbetriebssysteme (am Beispiel QNX) Dr. Stefan Enderle HS Esslingen

Echtzeitbetriebssysteme (am Beispiel QNX) Dr. Stefan Enderle HS Esslingen Echtzeitbetriebssysteme (am Beispiel QNX) Dr. Stefan Enderle HS Esslingen 1. Einführung 1.1 Embedded Systeme Embedded Systeme besitzen / benutzen einen Mikrocontroller Embedded Systeme erfüllen meist eine

Mehr

Browserbasiertes, kollaboratives Whiteboard

Browserbasiertes, kollaboratives Whiteboard WS 2011/12 Bachelorarbeit Browserbasiertes, kollaboratives Whiteboard Sebastian Dorn 1 von 21 Inhalt 1. Motivation 2. Analyse 3. Design 4. Evaluation 5. Fazit Inhalt 2 von 21 Motivation Zusammenarbeit

Mehr

Studienprojekt HP-MOM

Studienprojekt HP-MOM Institute of Parallel and Distributed Systems () Universitätsstraße 38 D-70569 Stuttgart Studienprojekt HP-MOM High Performance Message Oriented Middleware 23. Januar 2013 Kurt Rothermel, Frank Dürr, Patrick

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

SaaS-Referenzarchitektur. iico-2013-berlin

SaaS-Referenzarchitektur. iico-2013-berlin SaaS-Referenzarchitektur iico-2013-berlin Referent Ertan Özdil Founder / CEO / Shareholder weclapp die Anforderungen 1.000.000 registrierte User 3.000 gleichzeitig aktive user Höchste Performance Hohe

Mehr

Adeos & Xenomai. Echtzeitbetriebssysteme / SS09. Alexander Behringer. Georg-Simon-Ohm-Hochschule Nürnberg. 24. Juni 2009

Adeos & Xenomai. Echtzeitbetriebssysteme / SS09. Alexander Behringer. Georg-Simon-Ohm-Hochschule Nürnberg. 24. Juni 2009 Adeos & Xenomai Echtzeitbetriebssysteme / SS09 Alexander Behringer Georg-Simon-Ohm-Hochschule Nürnberg 24. Juni 2009 Alexander Behringer (GSO Nbg) Adeos & Xenomai 24. Juni 2009 1 / 39 Übersicht Einführung

Mehr

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH Java Einleitung - Handout Kurzbeschreibung: Eine kleine Einführung in die Programmierung mit Java. Dokument: Autor: Michael Spahn Version 1.0 Status: Final Datum: 23.10.2012 Vertraulichkeit: öffentlich

Mehr

Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance

Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance 5. November 2013 Prof. Dr. Christian Tschudin Departement Mathematik und Informatik, Universität Basel Repetition

Mehr

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten Prof. Dr. P. Tran-Gia Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten 4. Würzburger Workshop IP Netzmanagement, IP Netzplanung und Optimierung Robert Henjes, Dr. Kurt Tutschku

Mehr

Inhaltsverzeichnis XII

Inhaltsverzeichnis XII 1 Einführung... 1 1.1 Computersysteme... 1 1.1.1 Einführung... 2 1.1.2 Aufgabe von Betriebssystemen... 3 1.1.3 Grundlegende Hardwaremodelle... 3 1.1.4 CPU-Registersatz... 7 1.1.5 Multicore-Prozessoren

Mehr

Untersuchung zur hardwareunterstützten Entwurfsverifikation von Stream-basierten Kommunikations- und Verarbeitungsalgorithmen

Untersuchung zur hardwareunterstützten Entwurfsverifikation von Stream-basierten Kommunikations- und Verarbeitungsalgorithmen Fakultät Informatik Institut für Technische Informatik, Professur für VLSI-Entwurfssysteme, Diagnostik und Architektur Untersuchung zur hardwareunterstützten Entwurfsverifikation von Stream-basierten Kommunikations-

Mehr

bintec elmeg Filialisten Lösungen mit WLAN Controllern IP Access WLAN ITK VoIP / VoVPN IT Security UC Unified Teldat Group Company

bintec elmeg Filialisten Lösungen mit WLAN Controllern IP Access WLAN ITK VoIP / VoVPN IT Security UC Unified Teldat Group Company Filialisten Lösungen mit WLAN Controllern Autor: Hans-Dieter Wahl, Produktmanager bei Teldat GmbH IP Access WLAN ITK VoIP / Vo IT Security UC Unified Communications WLAN Netzwerke findet man inzwischen

Mehr

Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten

Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten Martin Däumler Matthias Werner Lehrstuhl Betriebssysteme Fakultät für Informatik

Mehr

Grundkurs Betriebssysteme

Grundkurs Betriebssysteme Grundkurs Betriebssysteme Architekturen, Betriebsmittelverwaltung, Synchronisation, Prozesskommunikation von Peter Mandl 3., akt. und erw. Aufl. 2013 Springer Vieweg Wiesbaden 2012 Verlag C.H. Beck im

Mehr

Institut für Informatik

Institut für Informatik Technische Universität München Institut für Informatik Lehrstuhl für Computer Graphik & Visualisierung WS 2010 Praktikum: Grundlagen der Programmierung Lösungsblatt 7 Prof. R. Westermann, A. Lehmann, R.

Mehr

Implementierung Echtzeitbetriebssysteme Architektur eines RTOS am Beispiel Windows CE 23.03.2010 Autor: Rudi Swiontek und Ralf Ebert*

Implementierung Echtzeitbetriebssysteme Architektur eines RTOS am Beispiel Windows CE 23.03.2010 Autor: Rudi Swiontek und Ralf Ebert* Implementierung Echtzeitbetriebssysteme Architektur eines RTOS am Beispiel Windows CE 23.03.2010 Autor: Rudi Swiontek und Ralf Ebert* Echtzeitbetriebssysteme, kurz RTOS, besitzen neben harter Echtzeitfähigkeit

Mehr

Klausur zur Vorlesung Verteilte Systeme im SS 2007 Prof. Dr. Odej Kao 24. Juli 2007

Klausur zur Vorlesung Verteilte Systeme im SS 2007 Prof. Dr. Odej Kao 24. Juli 2007 Klausur zur Vorlesung Verteilte Systeme im SS 2007 Prof. Dr. Odej Kao 24. Juli 2007 Name: Vorname: Matrikelnummer: Studiengang: E-Mail: Schreiben Sie zunächst sofort Ihren Namen und Matrikelnummer auf

Mehr

Hello World from CORBA

Hello World from CORBA Hello World from CORBA ein erster Überblick Aufruf einer Objekt-Methode Client gettemperature() Thermometer Objekt- Implementation Thermometer th = new Thermometer(); double t = th.gettemperature(); th

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

Aspektorientierte Modellierung

Aspektorientierte Modellierung Aspektorientierte Modellierung Softwaretechnik-Seminar 2002 Thema: Evolutionäre Software Referent: Alexander Winter Gliederung Einführung und Motivation Was ist Aspektorientierte Modellierung? Vorstellung

Mehr

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa Dr. Stefan Pietschmann, PF Service-Oriented Enterprise Applications, T-Systems MMS Dresden, 22.10.2013 About US PF42 Service-oriented enterprise

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

1. Wie können Forms und SOA integriert werden?

1. Wie können Forms und SOA integriert werden? Forms goes SOA Jüssen, Stefan Senior Consultant 03.02.2011 Jede Änderung im Geschäftsprozess muss umgehend in der unterstützenden Software abgebildet werden können. Professionelle Systementwicklung basiert

Mehr

Zusicherung von Qualitätskriterien bei WebServices. Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07.

Zusicherung von Qualitätskriterien bei WebServices. Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07. Zusicherung von Qualitätskriterien bei WebServices Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07.2003 Agenda Verteilte Systeme am am Beispiel Beispiel Aspekte von Verteilung

Mehr