Sie sind auf Seite 1von 3

ETHERNET

Im Bezug auf Kontrollkommunikation hat die Nutzung von Ethernet zwei wichtige
Herausforderungen: Erstens sollen sehr viele unterschiedliche Anwendungsflle
untersttzt werden und zweitens ist Ethernet im Gegensatz zu vielen verbreiteten
Kommunikationslsungen im Fahrzeug kein Bus und somit auch kein klassisches
Broadcast-Medium. Dieser Beitrag gibt
einen berblick ber SOME/IP einer
Middleware fr automobile Kontrollkommunikation, die fr diese Herausforderungen entwickelt wurde.

Alle Bilder: BMW

thernet im Fahrzeug soll eine Vielzahl von Anwendungsfllen untersttzen, welche unter anderen im Bereich Infotainment und Fahrerassistenz angesiedelt sind. Dies
fhrt zu einer sehr groen und heterogenen Menge von Anforderungen an die Kontrollkommunikation und somit auch an
die eingesetzte Middleware-Lsung.
Zudem ist es fr ein effizientes Ethernet-Netz wesentlich,
Unicast-Kommunikation einzusetzen. Sie wird nur auf Ethernet-Links bertragen, die zum Erreichen des Empfngers
notwendig sind. Im Gegensatz zu einem Ethernet-Netz mit
ausschlielicher Broadcast-Nutzung sinkt also die Link-Auslastung und es knnen mehr Kommunikationsumfnge im
Gesamtnetz bertragen werden. Da diese und andere Anforderungen durch bestehende Middleware-Lsungen nicht adquat abgedeckt werden, hat sich die BMW Group 2011 entschlossen, die Middleware-Lsung Scalable Service-Oriented Middleware over IP, kurz SOME/IP, zu spezifizieren.
SOME/IP setzt auf Ethernet und auf die TCP/IP-Protokollfamilie auf. Bild 1 zeigt die Einordnung von SOME/IP in Relation
zu Ethernet und Anwendungen. Wesentlich hierbei ist, dass
SOME/IP eine definierte Anwendungsschnittstelle automatisch auf Pakete abbildet. SOME/IP hebt sich von anderen
Middleware-Lsungen wie folgt ab:

www.hanser-automotive.de

Bild 1: Einordnung Middleware-Lsung SOME/IP.

WW SOME/IP kann in AUTOSAR umgesetzt werden.


WW SOME/IP ist ebenso wie MOST dienstorientiert.
WW SOME/IP erlaubt einen sehr schnellen Aufstart des Gesamtsystems.
WW SOME/IP untersttzt kleinste Steuergerte durch einfache Serialisierung.

SOME/IP Serialisierung und Messaging

Carl Hanser Verlag GmbH & Co.KG, Mnchen, www.hanser-automotive.de; Nicht zur Verfgung in Intranet- u.Internet-Angeboten oder elektron. Verteilern

SOME/IP Die Middleware fr Ethernetbasierte Kommunikation

Die primren Aufgaben einer Middleware sind einerseits die


Serialisierung und Deserialisierung, also die Umsetzung zwischen Steuergerte-interner und -externer Netzwerkreprsentation und andererseits das Messaging, also das Senden
und Empfangen von Nachrichten.
SOME/IP verfolgt bei der Serialisierung eine mglichst
einfache Lsung, die Datentypen ohne komplexe Umrechnungen serialisiert. Zu den untersttzten Datentypen in
SOME/IP gehren uint8/16/32/64, sint8/16/32/64, float32/64,
HANSER automotive networks / Special 2013

17

ETHERNET

teile: Methoden,
Events und Fields.

enumeration, boolean, bitfield, struct, union, static array und


dynamic array. Die Arrays selbst knnen in einer oder mehreren Dimensionen vorliegen.
Hierbei sehen die einfachen untersttzten Datentypen,
z.B. ein uint8, in der Netzwerkreprsentation und der internen
Reprsentation gleich aus. Dies steht im Gegensatz zu Lsungen wie Google Protocol Buffers, die auf Basis der bertragenen Werte eine variable, komprimierte Darstellung erlauben,
und im Gegensatz zu CAN, fr den uerst komplexe Umrechnungsvorschriften eingesetzt werden, um die sehr stark
begrenzte Datengre in CAN-Frames von 8 Bytes sowie die
stark begrenzte Bandbreite zu kompensieren.
SOME/IP kann im Gegensatz hierzu sehr groe Pakete
transportieren und auf Ethernet systembedingt auf wesentlich grere Bandbreiten zurckgreifen. Analog zu CAN knnen neben einzelnen Dateneinheiten auch grere Datenmengen mittels Transportprotokoll (hier TCP) bertragen
werden. Die Serialisierung von SOME/IP wurde daher auf Serialisierungsgeschwindigkeit optimiert.
Die Dienstorientierung von SOME/IP wird beim SOME/IP
Messaging sichtbar: Jede SOME/IP-Kommunikation wird
zwischen dem Dienstanbieter (Server) und Dienstnehmer
(Client) gefhrt und betrachtet dabei den Dienst (Service). Ein
Service kann aus folgenden Anteilen bestehen (Bild 2):
WW Methode mit Rckantwort (Request/Response Method)
Eine Anfrage vom Client an Server, welche mit einer
Antwort oder einer Fehlerantwort beantwortet wird.
WW Methode ohne Rckantwort (Fire&Forget Method) Eine
Anfrage vom Client zum Server, welche nicht beantwortet wird.
WW Event Eine Nachricht vom Server zu registrierten Clients (siehe folgenden Abschnitt), welche u. a. bei nderung geschickt wird.
WW Field Eine logische Reprsentation einer Eigenschaft
beim Server fr die eine Abfragemethode (Getter), eine
nderungsmethode (Setter) und ein Event (Notification)
existieren kann.
WW Eventgroup eine logische Gruppierung von Events und
Fields.
Der Service selbst kann mehr als einmal im Fahrzeug instanziiert werden, man spricht hierbei von Service Instances.
SOME/IP Messaging bildet fr alle Anteile eines Services
entsprechende Informationen auf SOME/IP-Nachrichten ab,
um diese ber UDP oder TCP zu bertragen. Die SOME/IPNachrichten bestehen aus einem Header und einer Payload.

18

HANSER automotive networks / Special 2013

Carl Hanser Verlag GmbH & Co.KG, Mnchen, www.hanser-automotive.de; Nicht zur Verfgung in Intranet- u.Internet-Angeboten oder elektron. Verteilern

Bild 2: Service-An-

Bild 3 zeigt das SOME/IP-Header-Format, welches folgende


Header-Felder enthlt:
WW Message ID [32bit] besteht aus Service ID [16bit] und
Method ID [16bit], welche den Service und die Methode
bzw. Event eindeutig identifizieren.
WW Length [32bit] beschreibt die Lnge der SOME/IPNachricht ohne Message ID und Length
WW Request ID [32bit] besteht aus Client ID [16bit] und
Session ID [16bit], welche den anfragenden Client und
die Anfrage identifizieren und hiermit erlauben, eine Response einem Request eindeutig zuzuordnen.
WW Protocol Version [8 bit] die Version des SOME/IP-Protokolls (derzeit 1).
WW Interface Version [8 bit] die Version des Services.
WW Message Type [8 bit] beschreibt den Typ der SOME/
IP-Nachricht (Request, Response, Event, ).
WW Return Code [8 bit] transportiert den Rckgabewert
eines Requests.
WW Payload [0 bit oder lnger] transportiert serialisierte
Methoden- oder Event-Parameter.

Service Discovery und


Publish/Subscribe

Ethernet untersttzt effiziente Unicast-Kommunikation.


Durch die Adressierung des Empfngers belegt die Kommunikation nur die notwendige Bandbreite auf den EthernetLinks. Dies erhht die Gesamtsumme mglicher Kommunikation im Gesamtsystem und reduziert die ungewollte Kommunikation, die ein Steuergert filtern msste.
Fr Unicast-Kommunikation muss jedoch der Sender einer Nachricht sicher sein, dass der Empfnger diese auch
empfangen kann. Sollte der Empfnger zum Sendezeitpunkt
den Switches nicht bekannt sein, fluten diese Nachrichten,

Bild 3: SOME/IP Header-Format.

welche damit wie bei einem Bus auf jedem Link transportiert
werden. Der Unicast-Vorteil wre dann verloren.
Aus diesem Grund wurde 2012 SOME/IP um eine Service Discovery (kurz SOME/IP-SD) ergnzt, welche in AUTOSAR 4.1 als SWS Service Discovery standardisiert wurde.
SOME/IP-SD hat hierbei zwei Aufgaben:
WW Service Discovery Bekanntmachung der Verfgbarkeit
und Lokalitt (d. h. IP-Adresse und Portnummer) von
Service-Instanzen.
WW Publish/Subscribe Registrierungsmechanismus fr
Eventgroups.
Carl Hanser Verlag, Mnchen

ETHERNET

Carl Hanser Verlag GmbH & Co.KG, Mnchen, www.hanser-automotive.de; Nicht zur Verfgung in Intranet- u.Internet-Angeboten oder elektron. Verteilern

In Bild 4 wird ein exemplarischer Ablauf von SOME/IP-SD gezeigt, bei dem zu erkennen ist, wie SOME/IP-SD die IP-Adresse und Portnummer des Services signalisiert und diese
dann von SOME/IP fr Events und Methoden verwendet
werden. SOME/IP-SD ermglicht so eine effiziente UnicastKommunikation auf Ethernet und kann gleichzeitig die Menge
an zyklischen Nachrichten stark minimieren, da die Kommunikationspartner explizit ber die Verfgbarkeit von Services informiert werden.

Ausblick und Untersttzung


Bild 4: Beispielablauf SOME/IP-SD.

Um diese Aufgaben umzusetzen, kommunizieren SOME/IPSD-Instanzen regelmig und bertragen hierbei unterschiedliche SOME/IP-SD-Eintrge (Entries), die in Nachrichten gebndelt werden:
WW Find Service sucht eine Service Instance.
WW Offer Service publiziert eine Service Instance.
WW Stop Offer Service stoppt die Verfgbarkeit einer Service Instance.
WW Subscribe Eventgroup abonniert die Events und Fields
einer Eventgroup.
WW Stop Subscribe Eventgroup stoppt ein Subscribe Eventgroup Entry.
WW Subscribe Eventgroup Ack besttigt ein Subscribe
Eventgroup Entry.
WW Subscribe Eventgroup Nack lehnt ein Subscribe Eventgroup Entry ab.

Die Middleware SOME/IP wurde fr den Fahrzeugeinsatz


entwickelt und umfasst Serialisierung, Messaging, Service
Discovery und Publish/Subscribe. SOME/IP ist skalierbar und
kann auf Kleinststeuergerten (wie Kameras nach dem kommenden ISO17215-Standard), AUTOSAR-Steuergerten (seit
AUTOSAR 4.1) und Infotainment-Steuergerten genutzt werden. SOME/IP wird bereits von einer Vielzahl von AUTOSARImplementierungen sowie Werkzeuge fhrender Anbieter
untersttzt. W (oe)

Dr. Lars Vlker hat langjhrige Erfahrung in der Bewertung


und Konstruktion von Kommunikationsprotokollen sowie auf
dem Gebiet der Netzsicherheit. Er ist seit 2010 bei der BMW
Group in Mnchen und befasst sich dort mit dem Ethernet
MAC-Layer und Kommunikationsprotokollen fr Fahrzeuge.
Eine wesentliche Verantwortung hierbei ist die Entwicklung
und Standardisierung der Middleware-Lsung SOME/IP.

Konformittstest fr BroadRReach PHY

IP/Ethernet-Schnittstelle fr
FlexCard

Die neue BRR-Option fr Tektronix-Oszilloskope automatisiert


alle fr eine Konformittsprfung von BroadR-Reach erforderlichen Tests. Die BRR-Option ermglicht die Durchfhrung aller
geforderten Tests mit nur einem einzelnen Tektronix Oszilloskop, einschlielich der
Messung der spektralen
Leistungsdichte (PSD) und
der Rckflussdmpfung.
Bislang wurden fr diese
Tests ein Spektrumanalysator und ein Netzwerkanalysator bentigt. Die BRR- Neue BRR-Option fr TektroOption
enthlt
einen nix-Oszilloskope untersttzt
Testadapter mit einem Me- die Messung der spektralen
chanismus, der ein Strsig- Leistungsdichte.
nal hinzufgt, um die Verzerrungsmessungen auszufhren. Diese gehren zu den von
der Spezifikation empfohlenen wichtigsten Messungen.

Seit Juni verfgt die FlexCard PMC II von Ebers


pcher Electronics auch ber eine IP/EthernetSchnittstelle. Fr alle Bus-Interfaces der Karte (CAN,
FlexRay, Ethernet) wird mit einer Auflsung von einer
Mikrosekunde ein hochgenauer synchroner Zeitstempel generiert, mit dem es z. B. mglich ist, so erzeugte
Logdateien von verschiedenen Bussystemen zeitsynchron abzuspielen. Ein weiterer Vorteil ist, dass die
Karte automatisch als Standard-Ethernet-Interface
von Windows erkannt wird. Die Installation auf einem
PC wird dadurch sprbar vereinfacht und die Karte
lsst sich mit bestehender Ethernet-Software einsetzen.
ber eine spezielle WinPcap-Version, welche fr dieFlexCard PMC II entwickelt wurde, kann der hardwaregenerierte Zeitstempel ausgelesen und ausgewertet werden. Die FlexCard API der Schnittstellenkarte ermglicht es, wie bisher, parallel mit CAN- und FlexRayFrames zu arbeiten.

www.tektronix.com

www.eberspaecher-electronics.com

www.hanser-automotive.de

HANSER automotive networks / Special 2013

19