Embed Size (px)
Citation preview
Software ubiquitärer Systeme (SuS)
Middleware
https://ess.cs.tu-dortmund.de/DE/Teaching/SS2016/SuS/
Horst Schirmeier, Olaf Spinczyk
[email protected]://ess.cs.tu-dortmund.de/~hsc
AG Eingebettete SystemsoftwareInformatik 12, TU Dortmund
07.06.2016 SuS: 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
HardwareHardware
BetriebssystemBetriebssystem
MiddlewareMiddleware
DatenhaltungDatenhaltung
Anwendung/ProgrammierungAnwendung/Programmierung
07.06.2016 SuS: 04.2 Middleware 3
Inhalt● Middleware
– Ziele und Eigenschaften– Beispiel CORBA
● Middleware für ubiquitäre Systeme– Unterschiede zu „klassischer“ Middleware
● „Einfache Middleware“– OSEK/COM– OSEK/NM
● Zusammenfassung
07.06.2016 SuS: 04.2 Middleware 4
Middleware: Rolle im HW/SW-Stapel● Vermittler zwischen verteilten Anwendungskomponenten
Netz
Station
lokalesBS
Station
lokalesBS
Middleware-Komponente
Middleware-KomponenteMiddleware
Client-Komponente
Server-KomponenteAnwendung
TCP/IP …
TCP/IP…
NetzfähigeStationen,Netz-BS
Que
lle: H
eiko
Kru
mm
, VL
RvS
, TU
Dor
tmun
d
07.06.2016 SuS: 04.2 Middleware 5
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 Softwarekomponenten.
● Dienste bereitstellen– Zur Vereinfachung der Anwendungsentwicklung und
Verbesserung der Interoperabilität.
07.06.2016 SuS: 04.2 Middleware 6
Middleware: Klassen● Procedure-Oriented Middleware
– Unterstützt entfernte Prozeduraufrufe, z.B. ONC/RPC● Object-Oriented Middleware
– Erlaubt entfernte Objektkommunikation, z.B. Java RMI, CORBA● Message-Oriented Middleware
– Kommunikation über puffernde Nachrichtenkanäle (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
07.06.2016 SuS: 04.2 Middleware 7
Beispiel CORBA● Common Object Request Broker Architecture
– OMG-Standard, V1 1991, ..., V3.3 2012 (www.omg.org)– Objektorientierte Middleware
● Logische Struktur von CORBA-Systemen:
Object Request Broker (ORB)
CORBAservices
Naming
Trader
Life Cycle Transaction
Concurrency
Licensing
ApplicationObjects
CORBAfacilitiesTelecom. User Interface
07.06.2016 SuS: 04.2 Middleware 8
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();};
};
07.06.2016 SuS: 04.2 Middleware 9
Beispiel CORBA: IDL (2)● Die Datentypen sehen nur aus wie die von C++/Java!
– Die Abbildung findet sich in der CORBA-Spezifikation
07.06.2016 SuS: 04.2 Middleware 10
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
ClientIDL
Stub
ORBInterface
StaticSkeletons
DynamicSkeletonInterface
ObjectAdapter
InterfaceRepository
ImplementationRepository
Client ObjectImplementation
Object Request Broker (ORB) Core
07.06.2016 SuS: 04.2 Middleware 11
Inhalt● Middleware
– Ziele und Eigenschaften– Beispiel CORBA
● Middleware für ubiquitäre Systeme– Unterschiede zu „klassischer“ Middleware
● „Einfache Middleware“– OSEK/COM– OSEK/NM
● Zusammenfassung
07.06.2016 SuS: 04.2 Middleware 12
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
07.06.2016 SuS: 04.2 Middleware 13
Verteilte Systeme: Varianten [1]
Verteiltes System
Art derGeräte
Art der Netzwerk-verbindungen
Art desKontexts
stationär mobil permanent lückenhaft statisch dynamischv
07.06.2016 SuS: 04.2 Middleware 14
„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
07.06.2016 SuS: 04.2 Middleware 15
Mobile ubiquitäre Systeme● Mobile Geräte
– Wenig Rechenleistung und 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
07.06.2016 SuS: 04.2 Middleware 16
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.
07.06.2016 SuS: 04.2 Middleware 17
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.
07.06.2016 SuS: 04.2 Middleware 18
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.
07.06.2016 SuS: 04.2 Middleware 19
Inhalt● Middleware
– Ziele und Eigenschaften– Beispiel CORBA
● Middleware für ubiquitäre Systeme– Unterschiede zu „klassischer“ Middleware
● „Einfache Middleware“– OSEK/COM– OSEK/NM
● Zusammenfassung
07.06.2016 SuS: 04.2 Middleware 20
„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“
07.06.2016 SuS: 04.2 Middleware 21
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
07.06.2016 SuS: 04.2 Middleware 22
Interaction Layer: Überblick
07.06.2016 SuS: 04.2 Middleware 23
EmpfangsschnittstelleFür jeden Empfänger legtOSEK/COM intern einMessage Object an.– Es gibt 2 Arten …
● Queued Message Object– FIFO-Warteschlange– Neue Pakete werden verworfen,
wenn die Warteschlange 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
07.06.2016 SuS: 04.2 Middleware 24
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 entscheidet, ob
nur die periodisch verschickte I-PDU aktualisiert wird, oderzusätzlich sofort übertragen werden soll.
07.06.2016 SuS: 04.2 Middleware 25
Weitere Fähigkeiten von OSEK/COM
07.06.2016 SuS: 04.2 Middleware 26
Notification-Mechanismus● Erlaubt die Synchronisation der Anwendung mit dem
Kommunikationssystem.● 4 Arten von Ereignissen
– Erfolgreiches/fehlgeschlagenes Empfangen/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
07.06.2016 SuS: 04.2 Middleware 27
Filtermechanismus● Flexible Inhaltsfilter pro Message Object– new_value
● akt. Wert– old_value
● vorherigerWert
– mask, x,min, max,period,offset
● Konstanten– occurrence
● Häufigkeitdes Vor-kommenseinerNachricht
07.06.2016 SuS: 04.2 Middleware 28
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
07.06.2016 SuS: 04.2 Middleware 29
(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
07.06.2016 SuS: 04.2 Middleware 30
OSEK/NM: Motivation● Problem:
– Vernetzung von ECUs verschiedenster Zulieferer– Verhalten eines Knotens beeinflusst das Verhalten des gesamten Systems
(und umgekehrt)– Fehlfunktionen durch Beeinflussungen müssen 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
07.06.2016 SuS: 04.2 Middleware 31
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
07.06.2016 SuS: 04.2 Middleware 32
OSEK/NM: Konzept und Verhalten● NM basiert auf dem Überwachen von Knoten.● 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
07.06.2016 SuS: 04.2 Middleware 33
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!
07.06.2016 SuS: 04.2 Middleware 34
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
07.06.2016 SuS: 04.2 Middleware 35
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
07.06.2016 SuS: 04.2 Middleware 36
OSEK/NM: Direkte Überwachung (3)● Erkennung neuer Knoten
36
07.06.2016 SuS: 04.2 Middleware 37
OSEK/NM: Direkte Überwachung (4)● Ausfall eines Knotens
37
07.06.2016 SuS: 04.2 Middleware 38
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
38
07.06.2016 SuS: 04.2 Middleware 39
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
07.06.2016 SuS: 04.2 Middleware 40
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
07.06.2016 SuS: 04.2 Middleware 41
Inhalt● Middleware
– Ziele und Eigenschaften– Beispiel CORBA
● Middleware für ubiquitäre Systeme– Unterschiede zu „klassischer“ Middleware
● „Einfache Middleware“– OSEK/COM– OSEK/NM
● Zusammenfassung
07.06.2016 SuS: 04.2 Middleware 42
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.
07.06.2016 SuS: 04.2 Middleware 43
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
