Software ubiquitärer Systeme Middleware Olaf Spinczyk Arbeitsgruppe Eingebettete Systemsoftware Lehrstuhl für Informatik 12 TU Dortmund Olaf.Spinczyk@tu-dortmund.de http://ess.cs.uni-dortmund.de/~os/ http://ess.cs.tu-dortmund.de/de/teaching/ss2013/sus/ 1
Inhalt Middleware Ziele und Eigenschaften Beispiel CORBA Middleware für ubiquitäre Systeme Unterschiede zu klassischer Middleware Einfache Middleware Anwendung/Programmierung OSEK/COM OSEK/NM Zusammenfassung Datenhaltung Middleware Betriebssystem Hardware 04.2 Middleware 2
Inhalt Middleware Ziele und Eigenschaften Beispiel CORBA Middleware für ubiquitäre Systeme Unterschiede zu klassischer Middleware Einfache Middleware OSEK/COM OSEK/NM Zusammenfassung 04.2 Middleware 3
Middleware: Rolle im HW/SW-Stapel Vermittler zwischen verteilten Anwendungskomponenten Station Station Client Komponente Middleware Komponente lokales BS TCP IP... Anwendung Server Komponente Middleware Middleware Komponente Netzfähige Stationen, Netz-BS lokales BS Quelle: Heiko Krumm, VL RVS, TU Dortmund TCP IP... Netz 04.2 Middleware 4
Middleware: Aufgaben Verbergen der Verteilung Den Entwickler sollten technische Details der Kommunikation und die Platzierung der Softwarekomponenten auf verschiedene Rechner nicht berühren. Verbergen von Heterogenität Die Unterschiede von Hardware, Betriebssystem und Kommunikationsprotokollen sollen den Programmierer nicht belasten. Standard-Schnittstellen für Entwickler und Integratoren Dient der einfachen Portierbarkeit, Komposition und Interoperabilität von SW-Komponenten. Dienste bereitstellen Zur Vereinfachung der Anwendungsentwicklung und Verbesserung der Interoperabilität. 04.2 Middleware 5
Middleware: Klassen Procedure-Oriented Middleware Unterstützt entfernte Prozeduraufrufe, z.b. ONC/RPC Object-Oriented Middleware Erlaubt entfernte Objektkommunikation, z.b. JavaRMI, CORBA Message-Oriented Middleware Kommunikation über puffernde Nachrichtenkanäle, also entkoppelt, z.b. IBM Websphere MQ Database-Oriented Middleware Zugriff mehrerer Klienten auf eine zentrale Datenbank, z.b. alle Implementierungen von ODBC Transaction-Oriented Middleware Unterstützung für sichere verteilte Transaktionen, z.b. Oracle Tuxedo 04.2 Middleware 6
Beispiel CORBA Common Objekte Request Broker Architecture OMG Standard, V1 1991, V2 1994, V3 1998 (www.omg.org) Objektorientierte Middleware Logische Struktur von CORBA-Systemen Application Objects CORBAfacilities Telecom. User Interface Object Request Broker (ORB) Naming Trader Life Cycle Transaction Licensing Concurrency CORBAservices 04.2 Middleware 7
Beispiel CORBA: IDL (1) Interface Definition Language Die Schnittstelle von CORBA-Objekten wird sprachunabhängig in CORBA IDL definiert. module Bank { // Deklaration einer eigenen Exception exception BankFehler { string info; }; interface IKonto { readonly attribute long nummer; double einzahlen(in double betrag) raises (BankFehler); }; // IGiroKonto erbt von IKonto interface IGiroKonto : IKonto { double lesekreditlimit(); }; interface ISparKonto : IKonto { double lesezinssatz(); }; }; 04.2 Middleware 8
Beispiel CORBA: IDL (2) Die Datentypen sehen nur aus wie die von C++/Java! Die Abbildung findet sich in der CORBA-Spezifikation 04.2 Middleware 9
Beispiel CORBA: Laufzeitsystem Der Client Stub und die Static Skeletons werden sprachabhängig aus der IDL-Beschreibung generiert Fernaufrufe sehen dadurch aus wie normale Funktionsaufrufe Standard-Semantik: Synchroner Aufruf, Request/Reply-Protokoll Objektreferenzen sind rechnerübergreifend gültig Client Object Implementation Interface Repository Dynamic Invocation Client IDL Stub ORB Interface Static Skeletons Dynamic Skeleton Interface Object Request Broker (ORB) Core Object Adapter Implementation Repository 04.2 Middleware 10
Inhalt Middleware Ziele und Eigenschaften Beispiel CORBA Middleware für ubiquitäre Systeme Unterschiede zu klassischer Middleware Einfache Middleware OSEK/COM OSEK/NM Zusammenfassung 04.2 Middleware 11
Verteilte Systeme logische Verbindungen Anwendung Middleware Betriebss. Hardware Anwendung Middleware Betriebss. Hardware Gerät 1 Gerät N Kontext 1 Anwendung Middleware Betriebss. Hardware Netz Netz Netzwerkverbindungen Kontext N Anwendung Middleware Betriebss. Hardware Gerät 2 Gerät 3 Kontext2 Kontext 3 04.2 Middleware 12
Verteilte Systeme: Varianten [1] Verteiltes System Art der Geräte Art der Netzwerkverbindungen Art des Kontexts v stationär mobil permanent lückenhaft statisch dynamisch 04.2 Middleware 13
Klassische Verteilte Systeme Stationäre Geräte Permanente Netzwerkverbindung Hohe Rechenleistung, viel Speicher Kaum Ausfälle, hohe Bandbreite Statischer Kontext Immer dieselben Nutzer(rollen), unveränderter Ort 04.2 Middleware 14
Mobile ubiquitäre Systeme Mobile Geräte Wenig Rechenleistung u. Speicher Mangel an Energie Lückenhafte Netzwerkverbindung Abgeschaltete Geräte normal (Kosten), unzuverlässige Netze, evtl. variable Bandbreite Dynamischer Kontext Ort, umgebende Netzwerkstruktur usw. ändern sich 04.2 Middleware 15
Klassische vs. mobile Middleware (1) Gewicht (=Ressourcenverbrauch) Klassisch: schwer - Stationäre Geräte - Um viele Fähigkeiten wie Fehlertoleranz oder Security zu integrieren, muss man entsprechend viele Ressourcen spendieren. Mobil: - Mobile Geräte leicht - Ein großes Middleware-System wäre auf kleinen ubiquitären Rechnern nicht einsetzbar. Viele Fähigkeiten klassischer Middleware sind zum Glück bei Spezialzwecksystemen auch verzichtbar. 04.2 Middleware 16
Klassische vs. mobile Middleware (2) Typisches Kommunikationsparadigma Klassisch: synchron - Permanente Netzwerkverbindung - Client und Server sind gleichzeitig online. Ersterer erwartet die Antwort des Servers. Das entspricht dem Programmiermodell von Funktionsaufrufen. Mobil: asynchron - Lückenhafte Netzwerkverbindung - Client und Server sind nicht notwendigerweise gleichzeitig online. 04.2 Middleware 17
Klassische vs. mobile Middleware (3) Repräsentation von Kontext Klassisch: transparent - Statischer Kontext - Die Middleware kann den Kontext einmalig (oder zumindest selten) ermitteln. Sie ist ohne Anwendungshilfe in der Lage effizient in jedem denkbaren Kontext zu arbeiten und verbirgt diesen daher vor der Anwendung und dem Benutzer. Mobil: gewahr - Dynamischer Kontext - Die Anwendung bzw. der Benutzer interessieren sich ausdrücklich für den Kontext, z.b. Welches Netz ist hier verfügbar? (Preis!), Welche Dienste kann man hier nutzen? - Eine wichtige Forschungsfrage ist daher, wie man Kontext repräsentiert und auf Kontextänderungen reagiert. 04.2 Middleware 18
Inhalt Middleware Ziele und Eigenschaften Beispiel CORBA Middleware für ubiquitäre Systeme Unterschiede zu klassischer Middleware Einfache Middleware OSEK/COM OSEK/NM Zusammenfassung 04.2 Middleware 19
Einfache Middleware Kein feststehender Begriff! Meint: Middleware für kleine Microcontroller-basierte verteilte eingebettete Systeme. Schönstes Beispiel: Das Auto OSEK/COM [2] - Einheitliche Kommunikationsinfrastruktur für KFZ-Steuergeräte - Protokollunabhängige Schnittstellen OSEK/NM [3] - Ergänzt OSEK/COM um Netzwerkmanagement 04.2 Middleware 20
Aufgaben der Schichten (bottom up) Data Link Layer unbestätigter Versand einzelner Pakete Network Layer Segmentierung und Zusammensetzung Flusskontrolle Empfangsbestätigtes Senden Hier definiert COM lediglich Anforderungen Interaction Layer API zum lokalen und rechnerübergreifenden Nachrichtenaustausch zwischen OSEK-Tasks und Unterbrechungsbehandlungsroutinen m:n Kommunikation unbeschränkte Nachrichtengröße Nachrichtenfilterung Pufferung Hier steckt die eigentliche Funktionalität 04.2 Middleware 21
Interaction Layer: Überblick 04.2 Middleware 22
Empfangsschnittstelle Für jeden Empfänger legt OSEK/COM intern ein Message Object an. Es gibt 2 Arten Queued Message Object FIFO-Warteschlage Neue Pakete werden verworfen, wenn die Warteschlage voll ist. Unqueued Message Object Neue Nachrichten überschreiben jeweils die vorherige Nachricht Anwendungen können diese Nachricht beliebig oft (atomar) lesen Sender und Empfänger können komplett asynchron arbeiten 04.2 Middleware 23
Sendeschnittstelle Es gibt drei Übertragungsmodi Direct Transmission Mode Die Nachricht wird direkt übertragen Periodic Transmission Mode Es wird eine I-PDU erstellt und in regelmäßigen Abständen verschickt Die SendMessage-Operation aktualisiert lediglich die I-PDU Sender und Empfänger werden komplett entkoppelt Mixed Transmission Mode Kombination aus Direct und Periodic Die Transfer Property der Nachricht entscheiden, ob nur die periodisch verschickte I-PDU aktualisiert wird oder ob zusätzlich sofort übertragen werden soll. 04.2 Middleware 24
Weitere Fähigkeiten von OSEK/COM 04.2 Middleware 25
Notification-Mechanismus Erlaubt die Synchronisation der Anwendung mit dem Kommunikationssystem. 4 Arten von Ereignissen Erfolgreiches/fehlgeschlagenes Empfangen Erfolgreiches/fehlgeschlagenes Senden 4 Möglichkeiten Ereignisse anzuzeigen Aufruf einer Callback-Funktion Setzen eines Flags Setzen eines OSEK-Events Aktivieren eines Tasks Nur der Notification-Mechanismus kann Kontextwechsel auslösen Dies sollte nicht zu häufig stattfinden Daher die Filterfähigkeit 04.2 Middleware 26
Filtermechanismus Flexible Inhaltsfilter pro Message Object new_value - akt. Wert old_value - vorheriger Wert mask, x, min, max, period, offset - Konstanten occurrence - Häufigkeit des Vorkommens einer Nachricht 04.2 Middleware 27
Deadline Monitoring Empfangen Schlägt Alarm, wenn z.b. eine periodische Nachricht nicht rechtzeitig eintrifft Sonderbehandlung für die erste Nachricht Senden Überprüft ob eine Nachricht schnell genug vom Network/Data Link Layer verschickt wurden. Kopplung an OSEK/NM möglich 04.2 Middleware 28
(Wieder) Conformance Classes CCCA Minimale Funktionalität, nur interne Kommunikation Nur Unqueued Messages CCCB Nur interne Kommunikation Queued Messages Statusinformationen von Nachrichten CCC0 Minimale Funktionalität für interne und externe Kommunikation CCC1 Unterstützt alle Features von OSEK COM 04.2 Middleware 29
OSEK/NM: Motivation Problem Vernetzung von ECUs verschiedenster Zulieferer Verhalten eines Knotens beeinflusst das Verhalten des gesamten Systems (und umgekehrt) Fehlfunktionen durch Beeinflussungen muss vermieden werden Lösung Auslagerung dieser Aufgaben in eine dedizierte Netzwerk-Management-Komponente - Status des Netzwerks wird kontinuierlich kontrolliert Standardisierte Schnittstellen und Protokolle sollen Funktionsfähigkeit zusichern - Knoten müssen Verhandlungen führen, z.b. vor Eintritt in Schlafmodus Ergebnis Zuverlässigere Systeme Ersparnis von Kosten und Entwicklungszeit 04.2 Middleware 30
OSEK/NM: Architektur NM hat Schnittstellen zur: Anwendung API bietet Zugang zu NM-Funktionen Interaktionsschicht wird zur Überwachung der Nachrichten der Anwendung benutzt Datensicherungsschicht bietet Zugang zur Kommunikationshardware 04.2 Middleware 31
OSEK/NM: Konzept und Verhalten NM basiert auf dem Überwachen von Knoten. Es gibt dazu zwei Methoden: Indirekte Knotenüberwachung Direkte Knotenüberwachung Konfigurationsmanagement nutzt Knotenüberwachung zur Ermittlung/Steuerung der aktuellen Konfiguration Ausgefallene Knoten Übergänge zwischen - Betriebsmodus - Schlafmodus - limp-home Modus 04.2 Middleware 32
OSEK/NM: Indirekte Überwachung Idee Anwendungen tauschen i.d.r. periodisch Nachrichten aus indirektes NM überwacht diesen normalen Nachrichtenaustausch Empfang und Senden von Nachrichten wird als Lebenszeichen interpretiert Wird über einen bestimmten Zeitraum keine Nachricht empfangen Fehlfunktion des Knotens Vorteil Ideal bei sehr einfachen oder zeitkritischen Anwendungen, da keine zusätzliche Netzlast erzeugt wird. Nachteil Passiv Nicht alle Aufgaben sind erfüllbar! 04.2 Middleware 33
OSEK/NM: Direkte Überwachung (1) Idee Knoten überwachen sich gegenseitig Knoten senden und empfangen spezielle NM-Nachrichten Jeder Knoten sendet ein Ich lebe - ( I am alive -) Signal und empfängt die Lebenssignale aller anderen Knoten. Die Lebenssignale werden aufsummiert gegenwärtige Konfiguration Vorteil Knoten können zusätzlich über die Ringnachrichten kommunizieren und z.b. netzwerkweite Moduswechsel auslösen. Nachteil Kontinuierliche erhöhte Buslast. 04.2 Middleware 34
OSEK/NM: Direkte Überwachung (2) Logischer Ring Jeder Knoten hat eine eindeutige Nummer, die auch die Reihenfolge im Ring repräsentiert. Es gibt zwei Aktivitäten: Integration von Knoten in den logischen Ring Bestimmen von fehlerhaften Knoten und Neukonfigurierung des logischen Rings 04.2 Middleware 35
OSEK/NM: Direkte Überwachung (3) Erkennung neuer Knoten 04.2 Middleware 36
OSEK/NM: Direkte Überwachung (4) Ausfall eines Knotens 04.2 Middleware 37
OSEK/NM: Direkte Überwachung (5) NM unterstützt die Interoperabilität von Knoten verschiedener Zulieferer Repräsentation von NM-Daten hat ein festgelegtes Format NM-PDU 04.2 Middleware 38
OSEK/NM: Schlafmodus Mit Hilfe der NM-PDUs kann zum Beispiel ein netzwerkweiter Wechsel in den Schlafmodus erfolgen. Jeder Knoten kann globalen Ruhezustand anstoßen Sende Ringnachricht mit Bussleep.ind = 1 Andere Knoten im Netz: reichen Bussleep.ind unverändert weiter oder setzen Bussleep.ind zurück kommt Bussleep.ind beim Initiator unverändert (= 1) an sende Ringnachricht mit Bussleep.ack = 1 alle Knoten empfangen diese Nachricht wechseln (nach einer Wartezeit) in Ruhezustand 04.2 Middleware 39
OSEK/NM: Konfigurierbarkeit Spezifikation wurde in Kern-Dienste und optionale Dienste unterteilt Resultat modulares NM, anpassbar an Speicherausstattung und Rechenleistung eines Knotens Beispiele: Renault setzt indirektes NM ein - 1 2 KB ROM, inklusive Fehlerspeicher - 0% Buslast (keine NM-spezifischen Nachrichten) Mercedes-Benz setzt direktes NM ein - 1,5 1,7 KB ROM - 4 8 KB RAM - 1% Buslast 04.2 Middleware 40
Inhalt Middleware Ziele und Eigenschaften Beispiel CORBA Middleware für ubiquitäre Systeme Unterschiede zu klassischer Middleware Einfache Middleware OSEK/COM OSEK/NM Zusammenfassung 04.2 Middleware 41
Zusammenfassung OSEK/COM und OSEK/NM können zusammen als typisches Beispiel für eine Middleware für ubiquitäre Systeme angesehen werden. Gewicht (=Ressourcenverbrauch): leicht Beide Komponenten sind statisch konfigurierbar Einfache Abstraktionen und Protokolle erfordern wenig Aufwand Kommunikationsparadigma: asynchron Mittels Unqueued Message Objects und Periodic Transmission können Sender und Empfänger komplett entkoppelt werden. Ausfälle von Knoten oder Nachrichten können toleriert werden. Kontext: gewahr OSEK/NM beobachtet das Netz und stellt den Anwendungen die entsprechenden Informationen zur Verfügung. Sie können damit kontextgewahr realisiert werden. 04.2 Middleware 42
Literatur [1] L. Capra, W. Emmerich, and C. Mascolo, Middleware for Mobile Computing: Awareness vs. Transparency. In Proceedings of the Eighth Workshop on Hot Topics in Operating Systems (May 20-22, 2001). HOTOS. IEEE Computer Society, Washington, DC, p. 164, 2001. [2] OSEK/VDX Communication Specification 3.0.3, Juli 2004, www.osek-vdx.org [3] OSEK/VDX Network Management: Concept and Application Programming Interface, Version 2.5.3, Juli 2004, www.osek-vdx.org 04.2 Middleware 43