11
Software ubiquitärer SystemeMiddleware
Olaf SpinczykArbeitsgruppe Eingebettete Systemsoftware
Lehrstuhl für Informatik 12TU Dortmund [email protected]://ess.cs.uni-dortmund.de/~os/
http://ess.cs.tu-dortmund.de/DE/Teaching/SS2012/SuS/
04.2 – Middleware 22
Inhalt● Middleware
● Ziele und Eigenschaften
● Beispiel CORBA
● Middleware für ubiquitäre Systeme● Unterschiede zu „klassischer Middleware“
● Einfache „Middleware“● OSEK/COM
● OSEK/NM
● Zusammenfassung
HardwareHardware
BetriebssystemBetriebssystem
MiddlewareMiddleware
DatenhaltungDatenhaltung
Anwendung/ProgrammierungAnwendung/Programmierung
04.2 – Middleware 33
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 44
Middleware: Rolle im HW/SW-Stapel● Vermittler zwischen verteilten Anwendungskomponenten
Netz
Station
lokalesBS
Station
lokalesBS
MiddlewareKomponente
MiddlewareKomponenteMiddleware
ClientKomponente
ServerKomponenteAnwendung
TCPIP ...
TCPIP ...
NetzfähigeStationen,Netz-BS
Qu
elle
: H
eik
o K
rum
m, V
L R
VS
, T
U D
ort
mu
nd
04.2 – Middleware 55
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 66
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 77
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
Object Request Broker (ORB)
CORBAservices
Naming
Trader
Life Cycle Transaction
Concurrency
Licensing
ApplicationObjects
CORBAfacilities
Telecom. User Interface
04.2 – Middleware 88
Beispiel CORBA: IDL (1)● Interface Definition Language
● Die Schnittstelle von CORBA-Objekten wird sprachunabhängig in CORBA IDL definiert.
module Bank {// Deklaration einer eigenen Exceptionexception BankFehler { string info; };interface IKonto {
readonly attribute long nummer; double einzahlen(in double betrag) raises (BankFehler);
};// IGiroKonto erbt von IKontointerface IGiroKonto : IKonto {
double leseKreditLimit();};interface ISparKonto : IKonto {
double leseZinssatz();};
};
04.2 – Middleware 99
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 1010
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
DynamicInvocation
ClientIDLStub
ORBInterface
StaticSkeletons
DynamicSkeletonInterface
ObjectAdapter
InterfaceRepository
ImplementationRepository
ClientObject
Implementation
Object Request Broker (ORB) Core
04.2 – Middleware 1111
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 1212
Verteilte Systeme
NetzNetz
GerätGerät 1HardwareBetriebss.
MiddlewareAnwendung
Gerät 2HardwareBetriebss.
MiddlewareAnwendung
Gerät 3HardwareBetriebss.
MiddlewareAnwendung
Gerät NHardwareBetriebss.
MiddlewareAnwendung
Netzwerk-Netzwerk-verbindungenverbindungen
KontextKontext 1
Kontext2 Kontext 3
Kontext N
logischeVerbindungen
04.2 – Middleware 1313
Verteilte Systeme: Varianten [1]
Verteiltes System
Art derGeräte
Art der Netzwerk-verbindungen
Art desKontexts
stationär mobil permanent lückenhaft statisch dynamisch
v
04.2 – Middleware 1414
„Klassische“ Verteilte Systeme● Stationäre Geräte
● Hohe Rechenleistung, viel Speicher
● Permanente Netzwerkverbindung
● Kaum Ausfälle, hohe Bandbreite
● Statischer Kontext
● Immer dieselben Nutzer(rollen),unveränderter Ort
04.2 – Middleware 1515
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. variableBandbreite
● Dynamischer Kontext
● Ort, umgebende Netzwerkstruktur usw. ändern sich
04.2 – Middleware 1616
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: leicht
- Mobile Geräte
- 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 1717
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 1818
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 1919
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 2020
„Einfache Middleware“● Kein feststehender Begriff!
● Meint: Middleware für kleine Microcontroller-basierte verteilte eingebettete Systeme.
● Schönstes Beispiel: Das Auto● OSEK/COM [2]
- Einheitliche Kommunikations-infrastruktur für KFZ-Steuergeräte
- Protokollunabhängige Schnittstellen
● OSEK/NM [3]
- Ergänzt OSEK/COM um„Netzwerkmanagement“
04.2 – Middleware 2121
Aufgaben der Schichten (bottom up)● Data Link Layer
● unbestätigter Versand einzelner Pakete
● Network Layer● Segmentierung und Zusammensetzung● Flusskontrolle● Empfangsbestätigtes Senden
● Interaction Layer● API zum lokalen und rechnerübergreifenden
Nachrichtenaustausch zwischen OSEK-Tasksund Unterbrechungsbehandlungsroutinen
● m:n Kommunikation● unbeschränkte Nachrichtengröße● Nachrichtenfilterung● Pufferung
Hier definiertCOM lediglichAnforderungen
Hier definiertCOM lediglichAnforderungen
Hier stecktdie eigentlicheFunktionalität
Hier stecktdie eigentlicheFunktionalität
04.2 – Middleware 2222
Interaction Layer: Überblick
04.2 – Middleware 2323
EmpfangsschnittstelleFür jeden Empfänger legtOSEK/COM intern einMessage 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 überschreibt jeweils die letzte vorherige Nachricht
● Anwendungen können diese Nachricht beliebig oft (atomar) lesen
● Sender und Empfänger können komplett asynchron arbeiten
04.2 – Middleware 2424
SendeschnittstelleEs 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, obnur die periodisch verschickte I-PDU aktualisiert wird oder obzusätzlich sofort übertragen werden soll.
04.2 – Middleware 2525
Weitere Fähigkeiten von OSEK/COM
04.2 – Middleware 2626
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 2727
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 Vor-kommenseinerNachricht
04.2 – Middleware 2828
Deadline Monitoring● Empfangen
● Schlägt Alarm, wenn z.B. eine periodische Nachrichtnicht 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 2929
(Wieder) Conformance Classes● CCCA
● Minimale Funktionalität, nur interneKommunikation
● 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 3030
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 3131
OSEK/NM: ArchitekturNM hat Schnittstellen zur:
● Anwendung● API bietet Zugang zu
NM-Funktionen
● Interaktionsschicht● wird zur Überwachung der
Nachrichten der Anwendungbenutzt
● Datensicherungsschicht● bietet Zugang zur
Kommunikationshardware
04.2 – Middleware 3232
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 3333
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 3434
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 3535
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 3636
OSEK/NM: Direkte Überwachung (3)● Erkennung neuer Knoten
04.2 – Middleware 3737
OSEK/NM: Direkte Überwachung (4)● Ausfall eines Knotens
04.2 – Middleware 3838
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 3939
OSEK/NM: SchlafmodusMit 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 4040
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 4141
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 4242
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 4343
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