Software ubiquitärer Systeme - ess.cs.tu-dortmund.de · Die Datentypen sehen nur aus wie die von...

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/

mailto:[email protected]

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




● Beispiel CORBA



● OSEK/NM

● Zusammenfassung


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


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.


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


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

http://www.omg.org/


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();};

};


Beispiel CORBA: IDL (2)● Die Datentypen sehen nur aus wie die von C++/Java!

● Die Abbildung findet sich in der CORBA-Spezifikation


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




● Beispiel CORBA



● OSEK/NM

● Zusammenfassung


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


Verteilte Systeme: Varianten [1]

Verteiltes System

Art derGeräte

Art der Netzwerk-verbindungen

Art desKontexts

stationär mobil permanent lückenhaft statisch dynamisch

v


„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


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


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.


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.


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.




● Beispiel CORBA



● OSEK/NM

● Zusammenfassung


„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“


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


Interaction Layer: Überblick


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


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.


Weitere Fähigkeiten von OSEK/COM


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


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


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


(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


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


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


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


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!


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.


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


OSEK/NM: Direkte Überwachung (3)● Erkennung neuer Knoten


OSEK/NM: Direkte Überwachung (4)● Ausfall eines Knotens


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


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


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




● Beispiel CORBA



● OSEK/NM

● Zusammenfassung


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.


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

http://www.osek-vdx.org/

http://www.osek-vdx.org/

Software ubiquitärer Systeme - ess.cs.tu-dortmund.de · Die Datentypen sehen nur aus wie die von...

Documents

Transcript of Software ubiquitärer Systeme - ess.cs.tu-dortmund.de · Die Datentypen sehen nur aus wie die von...