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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ü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

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

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

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

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

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

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

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

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

Systeme I: Betriebssysteme Kapitel 4 Prozesse. Maren Bennewitz

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

Mehr

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

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

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

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

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

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

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

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

Ü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

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

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

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

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

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

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

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

Was machen wir heute? Betriebssysteme Tutorium 12. Organisatorisches. Frage 12.1.a. Programmieraufgaben Vorstellung. Antwort

Was machen wir heute? Betriebssysteme Tutorium 12. Organisatorisches. Frage 12.1.a. Programmieraufgaben Vorstellung. Antwort Was machen wir heute? Betriebssysteme Tutorium 12 1 Organisatorisches Philipp Kirchhofer philipp.kirchhofer@student.kit.edu http://www.stud.uni-karlsruhe.de/~uxbtt/ Lehrstuhl Systemarchitektur Universität

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

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

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

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

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

Verteilte Systeme. Einführung. Prof. Dr. Oliver Haase

Verteilte Systeme. Einführung. Prof. Dr. Oliver Haase Verteilte Systeme Einführung Prof. Dr. Oliver Haase 1 Definition A distributed system is a collection of independent computers that appears to its users as a single coherent system. - Andrew Tanenbaum

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

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

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

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

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

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

Kommunikation und Kooperative Systeme

Kommunikation und Kooperative Systeme Kommunikation und Kooperative Systeme Teil II Verteilte Dienste und Anwendungen Nik Klever FB Informatik - FH klever@fh-augsburg.de Einführung Begriffsbestimmung Kommunikation: Austausch, Übermittlung

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

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule

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

Zusammenfassung Modul 223

Zusammenfassung Modul 223 Zusammenfassung Modul 223 von Christian Roth Powered by Schuschu Bison Schweiz AG, Surentalstrasse 10, CH-6210 Sursee, www.bison-group.com Inhaltsverzeichnis 1 Entwurfmuster... 3 1.1 Singleton... 3 1.1.1

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

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

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

ARM Cortex-M Prozessoren. Referat von Peter Voser Embedded Development GmbH

ARM Cortex-M Prozessoren. Referat von Peter Voser Embedded Development GmbH ARM Cortex-M Prozessoren Referat von Peter Voser Embedded Development GmbH SoC (System-on-Chip) www.embedded-development.ch 2 Instruction Sets ARM, Thumb, Thumb-2 32-bit ARM - verbesserte Rechenleistung

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

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

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

Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank

Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank Message Broker (MB) Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank Programmierung verteilter Systeme Lab Institut für Informatik Universität Augsburg Universitätsstraße

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

Ü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

OSEK / OSEKtime - ein Vergleich

OSEK / OSEKtime - ein Vergleich OSEK / OSEKtime - ein Vergleich Hauptseminar WS 07/08 André Puschmann andre.puschmann@stud.tu-ilmenau.de Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Fachgebiet Rechnerarchitektur

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

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

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

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

Lösung Verteilte Systeme WS 2011/12 Teil 1

Lösung Verteilte Systeme WS 2011/12 Teil 1 Seite 1 von 5 Lösung Verteilte Systeme WS 2011/12 Teil 1 2.02.2012 1. Aufgabe (5) Sie fahren in Ihrem Privatfahrzeug auf einer Autobahn und hinter Ihnen fährt ein Polizeifahrzeug. 1.1 Nennen Sie ein Szenario,

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

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

FAQ. VisBee - IDE FAQ 2011-11-21. Änderungsindex: 1.0. Änderungsdatum: 2011-11-21. Christ Elektronik GmbH. Alpenstraße 34 DE-87700 Memmingen

FAQ. VisBee - IDE FAQ 2011-11-21. Änderungsindex: 1.0. Änderungsdatum: 2011-11-21. Christ Elektronik GmbH. Alpenstraße 34 DE-87700 Memmingen Änderungsindex: 1.0 Änderungsdatum: DE- Copyright 2011 Weitergabe sowie Vervielfältigung dieser Unterlage, Verwertung und Mitteilung ihres Inhalts nicht gestattet, soweit nicht ausdrücklich zugestanden.

Mehr

Low-Level Client-Server Architektur

Low-Level Client-Server Architektur Softwareentwicklung in verteilten Umgebungen Einführung Übung 1 Low-Level Client-Server Architektur Alexander Lex 1 KEINE PLAGIATE! Einzel-Übungen! Eigenständige Arbeit jedes Teilnehmers Weitergabe von

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

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

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

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