Cyber-Physical Systems WS09/10 - FAU

Cyber-Physical Systems WS16/17

Cyber-Physical Systems

6. Vernetzung und Kommunikation

Dr.-Ing. Torsten Klie

Lehrstuhl für Hardware-Software-Co-Design

DRAHTLOSE

KOMMUNIKATION

Für „kleine“ und „große“ CPS

Cyber-Physical Systems WS16/17 23

Bluetooth Low Energy / Smart

• 2.4-GHz-Standard für Kurzstreckennetze (<10m) bei

Datenrate von 1 Mbps

• Geringerer Stromverbrauch als

„klassisches“ Bluetooth

(10 mW vs. 1000 mW)

– Schnellerer Verbindungsaufbau

– Kurze Bursts auf der Funkstrecke

• IPv6 integriert

• Als „Funktechnologie für das Internet der Dinge“ vermarktet

• Eingeschränkte Kompatibilität zum klassischem Bluetooth

– Oft separate ICs

– Parallelbetrieb klassische / smart möglich


LoRa / LoRaWAN

• Long Range Wide Area Network

• Basiert auf offenem Industrie-Standard „LoRa“

• Entwickelt für das Internet der Dinge

• Bidirektional

• Frequenzbereiche: 868 Mhz (EU) / 915 (USA)

• Reichweite: 2 – 40 km

• Datenraten: 0,3 – 50 kbps

• Verschlüsselung mit AES (128 Bit)

• Geringer Energieverbrauch:

– vor allem durch Frequenzspreizung

– Batterielebensdauer bis 15 Jahre


Integration verschiedener Standards

• Haupt-Anforderung: Mobilität

• Beispiel: Anbindung von Laptops

– Arbeitsplatz: Docking-Station, Ethernet, Kabelgebunden

– Hörsaal: WLAN der Uni

– Zuhause: Privates (W)LAN

– Unterwegs: UMTS, EDGE, WLAN, ggf. Bluettooth

• Unterschiedliche Geräte: Nicht nur an Laptops denken!

– Smartphones

– Sensoren

– Fahrzeuge

• Auch: Anbindung von „Lagacy-Systemen“ und Exoten (z.B.

spezielle Busse)


Möglichkeiten der Integration

• Clean-Slate

(„reinen Tisch machen“, also kompletter Neuentwurf)

– Vorteil: direkte Umsetzung der Anforderungen

– Nachteil: hohe Investition

• Ausstattung der Geräte mit mehreren verschiedenen

Empfangseinrichtungen

– Vorteil: Flexibilität

– Nachteil: Kosten, Energieaufwand

• Gateways

– Vorteil: Können dort eingesetzt werden, wo sie gebraucht werden

– Nachteil: hohe Investition, ggf. Verzögerungen in der

Kommunikation


SERVICE ORIENTED

ARCHITECTURE

Vernetzung von Diensten und Informationen in „großen CPS“


Grundlagen von SOA


Quelle: IBM

29

Web Services


Web-Service: Definition

• Kommunikationsmethode zwischen zwei elektronischen

Geräten über das Internet/WWW

• Verfügbarmachen von benutzerorientierter

Anwendungsfunktionalität für Maschinen

• „Große Web-Services“

– Klassische Services, die dem SOAP-Standard folgen

• Web API:

– Populär im Rahmen von Web 2.0

– Vermeiden von SOAP

– Verwenden von Representational State Transfer (REST)

– Kombinieren mehrere Web-Services in einer Anwendung (Mashup)


SOAP Envelope (Beispiel)

<?xml version=”1.0” encoding=”UTF−8”?>

<S:Envelope

xmlns:S=”http://schemas.xmlsoap.org/soap/envelope/”>

<S:Header/>

<S:Body>

<ns2:command xmlns:ns2=”http://pengine.fau.de/”>

<parameter>Reload Policies</parameter>

</ns2:command>

</S:Body>

</S:Envelope>


Web Services Description Language (WSDL) 1/2

<wsdl:definitions[ . . . ]>

<wsdl:types><xsd:schema> [...] </xsd:schema></wsdl:types>

<wsdl:message name=”performEvent”>

<wsdl:part name=”parameters ” element=” tns:performEvent”/>

</wsdl:message>

<wsdl:message name=”performEventResponse”>

<wsdl:part name=”parameters” element=”tns:performEventResponse”/>

</wsdl:message>

<wsdl:portType name=”PolicyEngineWSI”>

<wsdl:operation name=”performEvent”>

<wsdl:input message=”tns:performEvent”/>

<wsdl:output message=”tns:performEventResponse”/>

</wsdl:operation>

</wsdl:portType>


Web Services Description Language (WSDL) 2/2

<wsdl:binding name=”PolicyEngineWSIPortBinding” type=” tns:PolicyEngineWSI”>

<soap:binding transport=”http://schemas.xmlsoap.org/soap/http” style=”document”/>

<wsdl:operation name=”performEvent”><soap:operationsoapAction=””/>

<wsdl:input><soap:body use=”literal”/></wsdl:input>

<wsdl:output><soap:body use=”literal”/></wsdl:output>

</wsdl:operation>

</wsdl :binding>

<wsdl:service name=”PolicyEngineWSIService”>

<wsdl:port name=”PolicyEngineWSIPort” binding=” tns:PolicyEngineWSIPortBinding”><soap:addresslocation=”http://policy2:8081/PolicyEngine/PolicyEngineWSIService”/>

</wsdl:port>

</wsdl:service>

</wsdl:definitions>


Web Service Registry

• White Pages: Information über Organisationen

• Yellow Pages: Liste von WS-Beschreibungen

• Green Pages: Technische Information über Dienste

– Uniform Resource Identifier (URI)

– Semantik des Dienstes in textueller Beschreibung.


publish

use

search

35

Semantische Web-Services: Motivaton

• Beschreibung in UDDI Registry nur textuell

• Rechner „verstehen“ die Beschreibungen nicht

• Beispiel (Pseude-Code):

// ermittelt Ortsname aus PLZ

service_1( int ) String

// ermittelt Bezeichnung aus Artikelnummer

service_2( int ) String


Ontologien

• Traditionelle Philiosophie:

– Grundstrukturen der Realität

– Entitäten, die sind

• Informatik:

– „Explizite formale Spezifikation einer Konzeptualisierung“ (nach

Gruber)

– Versuch eines umfassenden und rigerosen konzeptionellen

Schemas über eine Domäne (Groh und Toni)

• Hauptbestandteile:

– Konzepte („Klassen“) (z.B. „Kraftstoff“)

– Beziehungen (z.B. Unterklassen: Diesel)

– Eigenschaften (z.B. Auto verbraucht Kraftstoff)

– Beschränkungen des Wertebereichs, logische Beziehungen,

Disjunktheit


Verwendung von Ontologien


Quelle: G. Groh und K. Toni, Foundations of the Semantic Web, 2005

38

W3C Semantic Web Initiative

• Computer können die Bedeutung

von Inhalten nicht verstehen

• Semantic Web (Tim Berners-

Lee): Erweiterung des

bestehenden Webs durch

annotieren von Informationen mit

ihrer Bedeutung

• Ontologien: Gemeinsames

Vokabular– Hierarchien

– Eigenschaften


Quelle: W3C

39

• W3C Standard

– Bevorzugte Ontologie-Sprache des W3C

– Erlaubt Abfragen in Prädikatenlogik erster Ordnung (First-

Order Logic)

Web Ontology Language (OWL)

berechenbar


Resource Description Framework (RDF)

• W3C Standard

– URI: Identifikation, XML: Serialisation, XML Schema:

Datentypen)

• Einfaches Datenmodel für binäre Predikate

– Aussagen (statements): <subject> <predicate>

<object>

• Beispiel: “Volkswagen baut den Golf“

– Graphical notation:

http://www.volkswagen.de http://www.vw.de/~golf

– XML-Notation:<rdf:Description rdf:about=„http://www.volkswagen.de“><sampleOntology:builds>Golf</sampleOntology>

</rdf:Description>

• Mehrere RDF-Dokumente bilden ein semantisches Netz

http://ontology.org/#builds


RDF Schema (RDF-S) 1/2

• W3C Standard– Definiert Vokabular für RDF-

Statements

• RDF-S Konzepte– Klassen

• Class

• Resource

• Property

• Literal

– Eigenschafen (properties)• subClassOf

• subPropertyOf

• Domain

• range

Car

Compact

Sports CarMPV

SUV

Economy model Eco-Car

Energy Source

Diesel

Gasoline

Fuel cell

powerdBy

rdfs:range

rdfs:domain


RDF Schema (RDF-S) 2/2

• Beispiel (gekürzt)

<rdf:RDF

<rdfs:Class rdf:ID=„car“/>

<rdfs:Class rdf:ID=„compact“>

<rdfs:subClassOf rdf:resource=„#car“/>

</rdfs:Class>

<rdfs:Class rdf:ID=„energySource“/>

<rdf:Property rdf:ID=„poweredBy“>

<rdfs:domain rdf:resource=„#car“/>

<rdfs:range rdf:resource=„#energySource“/>

</rdf:Property>

</rdf:RDF>


Web Ontology Language (OWL) 1/2

• W3C Standard

– Bevorzugte Ontologie-Sprache des W3C

– Erlaubt Abfragen in First-Order-Logik

• Versionen

– OWL Lite

• Classifikationshierarchien und einfache Bedingungen

– OWL DL

• Unterstützt Description-Logik

• Alle OWL-Konstrukte, abermit z.T. eingeschränkter Verwendung

• Berechenbar

– OWL Full

• Uneingeschränkt ausdrucksstark (first-order logic support)

• Keine Garantien in Bezug auf die Berechenbarkeit


Web Ontology Language (OWL) 2/2

<rdf:RDF><owl:Ontology rdf:about=„cars“>

<owl:class rdf:ID=„Car“/>

<owl:FunctionalProperty rdf:ID="salesPrice"><rdf:type rdf:resource=„&owl;#DatatypeProperty"/><rdfs:domain rdf:resource="#Car"/><rdfs:range rdf:resource=„&xsd;positveInteger"/></owl:FunctionalProperty>

<owl:class rdf:ID=„EnergySource“/>

<owl:Class rdf:ID="HybridCar"><rdfs:subClassOf>

<owl:Restriction><owl:minCardinality rdf:datatype=„&xsd;int">2</owl:minCardinality><owl:onProperty><owl:ObjectProperty rdf:ID="poweredBy"/>

</owl:onProperty></owl:Restriction>

</rdfs:subClassOf><rdfs:subClassOf><owl:Class rdf:ressource=„#Car"/>

</rdfs:subClassOf>

</owl:Class></owl:Ontology>

</rdf:RDF>


Semantische Web-Services: OWL-S


Quelle: W3C

46

CAR-2-X-KOMMUNIKATION

Nach: F. Dressler, Vehicular Networking, 2014


Car-to-X (C2X) communication patterns

• Vehicle-to-X

(V2X)

• Inter-Vehicle

Communica-

tion (IVC)

• Vehicular

ad-hoc net-

work (VANET)

• …


… to infrastructure

… to car

… to home

Quelle: F. Dressler: Vehicular Networking. 2014

Use Cases


Quelle: CVIS

Taxonomy of Use Cases


Vehicle-to-X

Non-Safety

Comfort

Contextual Information

Entertainment

Traffic Information

Systems

Optimal Speed

Advisory

Congestion, Accident

Information

Safety

Situation Awareness

Adaptive Cruise Control

Blind Spot Warning

Warning Messages

Traffic Light Violation

Electronic Brake Light

Taxonomy of Use Cases - Requirements


Vehicle-to-X

Non-Safety

Viele Nachrichten

Hohe Datenrate

Geringe Latenzanforderung

Geringe Zuverlässligkeit gefordert

Safety

Wenige Nachrichten

Kleine Paketgröße

Hohe Latenzanforderung

Hohe Zuverlässigkeit gefordert

Diversität der Anforderungen


Application Latency Reliability # Vehicles Area Persistence

Information

Query★ ★ ★★★ ★★★

Hazard Warning ★★★ ★★ ★★ ★★★

ACC,

el. Brake Light★★★ ★★ ★ ★

Cooperative

Awareness★★ ★★★ ★ ★ ★

Intersection

Assistance★★ ★★★ ★★ ★★ ★

Platooning ★★★ ★★★ ★★ ★ ★

Quelle: Willke, P. Tientrakool, and N. F. Maxemchuk, A Survey of Inter-Vehicle

Communication Protocols and Their Applications. 2009

Motivation

• Klassisches Netz

– Verbindung: kabelgebunden

– Knoten: statisch

– Konfiguration: statisch

• Mobile Ad Hoc Network (MANET)

– Verbindung: drahtlos

– Knoten: mobil

– Konfiguration: dynamisch

– (Infrastruktur: optional)

• Vehicular Ad Hoc Network (VANET)

– Nicht: “MANET auf Rädern”

– Verschiedene Topologien, Kommunikations-

muster, Infrastrukturen, ...


Quelle: M.S. Corson and J.

Macker: Mobile Ad hoc

Networking (MANET):

Routing Protocol Performance

Issues and Evaluation

Considerations. 1999

Autobahn vs. Stadt

• 1D-Mobilität

• Bimodale Konnektivität– Stabile Verbindung

(Fahrzeuge auf der selben Fahrbahn)

– UND

– instabile Verbindung(Fahrzeuge auf der Gegenfahrbahn)

• HoheGeschwindigkeiten

• …

• 2D-Mobilität

• Bipolare Konnektivität

– Vielen Nachbarn

(beim Stehen)

– ODER

– Wenige Nachbarn (beim

Fahren)

• Hindernisse

• …


Ebenen der Infrastruktur-Unterstützung

• Reine Ad-hoc-Kommunikation

• Stationary Support Units (SSU)

– Autonomer Rechner mit Funk

– Unbegrenzter Speicher und Energie

– Bekannte Position, hohe Zuverlässigkeit

• Roadside Units (RSU)

– SSU plus…

– Ethernet NIC, UMTS radio, ...

– Verbunden mit anderen RSUs

• Traffic Information Center (TIC)

– Zentraler Server mit RSUs verbunden


Infrastruktur oder keine Infrastruktur

• Zentrale Koordination

– Ressourcen-

Management

– Security

• Hohe Latenz

• Hohe Netzwerklast

• …

• Selbstorganisiertes

System

– Kanalzugang

– Authentifizierzung

• Geringe Latenz

• Geringe Datenrate

• …


Herausforderungen der C2X-Kommunikation


• Highly varying channel conditions

• High congestion, contention, interference

• Tightly limited channel capacityCommunication

• Unidirectional Links

• Multi-Radio / Multi-Network

• Heterogeneous equipmentNetworking

• Highly dynamic topology

• But: predictable mobility

• Heterogeneous environmentMobility

• No (or no reliable) uplink to central infrastructure

• Ensuring privacy

• Heterogeneous user baseSecurity

Quelle: F. Dressler: Vehicular Networking. 2014

Technologie

• Rundfunk (Broadcast Media)

– Traffic Message Channel (TMC)

• Zentrales Management von Verkehrsinformation

• Datenquellen variieren (Bund-/Land-/Stadtpolizei, Straßenmeisterei,

Radio, …)

• Übertragung im RDS-Kanal von UKW

– Transport Protocol Experts Group (TPEG)

• Geplanter Nachfolger von RDS-TMC/Alert-C für DAB

• Veröffentlicht April 2000

• Prinzipien: Erweiterbarkeit & Medienunabhängigkeit

• Informationstypen von “TPEG Applications” definiert

• Modulares Konzept


Technologie

• Zelluläre Netze

– Kann UMTS für Car-to-X communication genutzt werden?

• Beispiel: UTRA FDD Release 99 (W-CDMA)

• Geschwindigkeit der Fahrzeuge kein limitierender Faktor

– Feldtest bei 290 km/h zeigen Signalverlust nur bei plötzlichem Bremsen(⇨handover prediction failures)

• Offene Fragen: Delay & Kapazität

– Kanäle in UMTS

• Shared channels: E.g. Random Access Channel (RACH), uplink

and Forward Access Channel (FACH), downlink

• Dedicated channels: E.g. Dedicated Transport Channel (DCH), up-

/downlink


Technology

• Zelluläre Netze

– FACH

• Time slots von Basis-Station verwaltet

• Verzögerung in der Größenordung von 10 ms pro 40 Byte und UE

• Kapazität stark eingeschränkt (in Netzen ohne Multicast)

• Aktuelle Zelle des UE muss bekannt sein

– RACH

• Slotted ALOHA – random access durch UEs: Power ramping with

Acquisition Indication

• Verzögerung ca. 50 ms pro 60 Byte und UE

• Massive Interferenzen mit anderen UEs

– DCH

• Verzögerung ca. 250 ms / 2 s / 10 s für channel establishment

• Obere Schranke von ca. 100 UEs


Technologie

• Fazit: Kann UMTS für Car-to-X-Kommunikation genutzt

werden?

– Bei geringer Marktdurchdringung: ja

– Letzendlich:

• Investitionen in viel kleinere Zellen (z.B. an Autobahnen)

• Umsetzen von Multicast (MBMS)

– Hauptanwendungsgebiet für UMTS: Zentrale Dienste

• Beispiel: Google Maps Traffic

– Sammelt Informationen von UMTS-Geräten

– Speicherung der Daten auf zentralem Server

– Verteilung via Internet (⇨ ideal für zelluläre Netze)


Technologie

• Wireless LAN IEEE 802.11{a,b,g,n} für Car-to-X-

Kommunikation?

– Kann nicht gleichzeitig im Modus “Infrastruktur” und

“ad hoc” sein

– Wechsel zeitaufwändig

– Verbindung zeitaufwändig

– Keine integrale Sicherheit im Netz

– (Massiv) geteiltes Frequenzband (⇨ ISM)

– Keine eingebautes QoS

– Mehrwege-Ausbreitung reduzieren Reichweite und Geschwindigkeit


UMTS/LTE vs. 802.11p

• Vorteile von UMTS/LTE

+ Einfaches Anbieten zentraler Dienste

+ Schnelle Informationsverteilung im gesamten Netz

+ Bereits vorhandene Infrastruktur

+ Einfache Migration zu (und Integration in) Smartphones

• Nachteile von UMTS/LTE

- Hohe Latenz im Nahbereich (evtl. Zu hoch für Safety)

- Netz muss erweitert warden (kleinere Zellen, Multicast)

- Starke Abhängigkeit vom Netzbetreiber

- Hohe Last im Kern-Netz, auch für lokale Kommunikation


UMTS/LTE vs. 802.11p

• Vorteile von 802.11p/Ad hoc

+ Kleinstmögliche Latenz

+ Ohne Netzbetreiber funktionsfähig

+ Netzlast stark ortsbezogen

+ Besserer Datenschutz

• Nachteile von 802.11p/Ad hoc

- Braucht Gateway für zentrale Dienste (z.B. RSU)

- Keine Hardware vorhanden; Hardware ist noch teuer

• Die Lösung?

– Hybride Systeme:

• Beide Technologien auf die Straße und in die Autos bringen

• Entscheidung je nach Anwendung und Infrastruktur-Verfügbarkeit


Higher Layer Standards: CALM

• Mixed-media communication

– „Communications access for land mobiles“

– ISO TC204 Working Group 16

– Initiative um transparent das bestmögliche Medium zu nutzen

– Integriert sind:

• GPRS, UMTS, WiMAX

• Infrarot, Millimeter Wave

• Wi-Fi, WAVE

• Unidirektionale Datenquellen (DAB, GPS, ...)

• WPANs (BlueT, W-USB, ...)

• Bus-Systeme im Auto (CAN, Ethernet, ...)


Wie geht es weiter?


1. Was sind “Cyber-physical Systems”?

• Definitionen und Abgrenzung zu eingebetteten Systemen, Ubiquitous

Computing, etc.

2. Anwendungen für Cyber-physical Systems

• Beispiele im Bereich Verkehr, Infrastruktur u.a.

3. Kontrolltheoretische Grundlagen

4. Echtzeitanforderungen

5. Control-Scheduling-Co-Design

6. Vernetzung und Kommunikation

7. Selbstorganisationsprinzipien

• „Self-X“, Autonomie, Verhandlungen

• Autonomic Computing und Policy-based Management

8. Entwurfsmethoden für Cyber-physical Systems

• Modellierung

• Programmierung

66

Ausblick auf Kapitel 7

• Selbstorganisationsprinzipien

– Definitionen von Selbstorganisation

– „Self-X“

• Selbstheilung

• Selbstkonfiguration

• Selbstschutz

• …

– Autonomie

• Grade von Autonomie (Autonomous / Autonomic)

• Steuerung von (Teil-)Autonomen Systemen

– Verhandlungen in Agentensystemen


Cyber-Physical Systems WS09/10 - FAU

Documents

Transcript of Cyber-Physical Systems WS09/10 - FAU