Alles über CAN, LIN, FlexRay und MOST

S e r i e l l e B u s s y s te m e

i m Au to m o b i l

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite a

>> InhaltSerielle Bussysteme im Automobil – Architektur, Aufgaben und Vorteile 1 – 4

Sicherer Datenaustausch mit CAN 5 – 8

Einfacher und kostengünstiger Datenaustausch mit LIN 9–12

FlexRay für den Datenaustausch in sicherheitskritischen Anwendungen 13–16

MOST für die Übertragung von Multimediadaten 17–20

Sehr geehrter Leser,

das waren noch Zeiten, als es im Auto noch keine Elektronik gab und die Autofahrer bei derFührung ihrer Fahrzeuge komplett auf sich allein gestellt waren. Heute regelt beispielsweisedas Motormanagement abhängig vom Betriebspunkt des Motors den für Kraftstoffverbrauchund Abgasverhalten des Motors optimalen Zündwinkel. Zudem sorgen eine Vielzahl von elektro-nischen Systemen für ein Mehr an Komfort und Sicherheit beim Autofahren.

Das wohl bekannteste aktive Sicherheitssystem im Kfz ist das elektronische Stabilitätspro-gramm ESP, welches mittels einer Vielzahl von Sensoren bis zu 150 mal pro Sekunde Informatio-nen über die Rotationsgeschwindigkeit der Räder, Quer- und Längsbeschleunigung und dieBewegungen des Lenkrads erhält. Sobald das Auto unter- oder übersteuert, leitet das ESP Kor-rekturen ein, wozu es gezielt Räder abbremst und blitzschnell über den Datenbus die Motorleis-tung drosselt.

Das ESP ist nur ein Beispiel für die zunehmende informationelle Kopplung von elektronischenSystemen im Kfz. Aufgrund der steigenden Zahl von steuergeräteübergreifenden Funktionenund der damit einhergehenden immer intensiveren Datenkommunikation ergeben sich für dieFahrzeughersteller und -zulieferer neue Herausforderungen. Schon heute, und in Zukunft nochviel mehr, stellt die Beherrschung der wachsenden Systemkomplexität einen wesentlichenwettbewerbsentscheidenden Faktor dar.

Von Anfang an unterstützt Vector Hersteller und Zulieferer der Automobilindustrie bei der Ent-wicklung von elektronischen Steuergeräten und der Vernetzung dieser Steuergeräte mit CAN,LIN, FlexRay und MOST durch Werkzeuge für Entwurf, Simulation, Analyse, Test, Kalibrierungund Diagnose sowie durch Softwarekomponenten, Entwicklungsdienstleistungen und Schulun-gen. Die Zusammenarbeit von Vector mit Ausbildungsstätten und Hochschulen gibt Schülern,Auszubildenden und Studenten die Gelegenheit, am Know-how von Vector zu partizipieren.

An diese Tradition möchte Vector mit dieser Sonderausgabe zum Thema „Serielle Bussysteme imAutomobil“ anknüpfen. Sie setzt sich aus fünf ausgewählten Beiträgen zusammen und richtetsich an alle, die sich mit der Entwicklung von elektronischen Steuergeräten und der Vernetzungelektronischer Systeme im Kfz beschäftigen. Nach einer Einführung in die serielle Datenkom-munikation lernen Sie die im Moment gängigen seriellen Bussysteme im Kfz kennen, also CAN,LIN, FlexRay und MOST.

Ich hoffe, Sie können mit dieser Sonderausgabe aufschlussreiche Erkenntnisse gewinnen undfreue mich schon jetzt auf Ihr Feedback.

Ihr

Eberhard HindererGeschäftsführer Vector Informatik GmbH

PressReport_PTR 28.04.2008 10:17 Uhr Seite b

1

Die jüngere Geschichte des Au-tomobils ist durch eine inten-sive Elektronifizierung ge-

kennzeichnet. Die treibende Kraftdafür geht in der Hauptsache von denimmer anspruchsvolleren Wünschender Kunden an ein modernes Automo-bil aus. Des Weiteren werden vom Ge-setzgeber immer strengere Vorgabenzur Abgasemission gemacht. Aberauch die Globalisierung sorgt durchgestiegenen Wettbewerbs- und Kos-tendruck für stetigen Innovations-druck. Mit der Elektronik haben dieKfz-Hersteller einen Weg gefunden,dieser multiplen Herausforderung zubegegnen. Dies spiegelt sich vor allemin der Ende der 1970er Jahre begin-nenden Migration elektronischer Steu-ergeräte in das Automobil wider.

Die ersten eingebetteten elektroni-schen Systeme verrichteten damals ih-re Aufgaben noch völlig autonom.Schon sehr früh erkannte man, dassdurch die Koordination von Anwen-dungen, die auf unterschiedlichen elek-tronischen Steuergeräten unterge-bracht waren, die Fahrzeugfunktiona-lität immens erhöht werden konnte.

Dies war der Auslöser für die Integra-tion von Kommunikationssystemen indas Automobil.

Allen voran beherrschte damals dieelektronische Fahrdynamikregelung dieVorentwicklung. Der intensive Verka-belungsaufwand ließ jedoch nur eineneingeschränkten Datenaustausch aufBasis von Einzelleitungen zu. Als Aus-weg aus diesem Dilemma kam der bit-serielle Austausch von Daten über ei-nen einzigen Kommunikationskanal inFrage. Dieser integriert alle individuel-

len Kommunikationskanäle und wirdals Bus bezeichnet. Mittels diesesBusses und entsprechender seriellerSchnittstellen können alle elektroni-schen Steuergeräte zu einem System-verbund, dem seriellen Bussystem, zu-sammengeschlossen werden (Bild 1).Elektronische Steuergeräte werden indiesem Kontext als Busknoten (Nodes)bezeichnet.

Seit dem Einsatz serieller Bussys-teme gehören die komplexen und oftunterschiedlich gearteten Kabelbäume

Serielle Bussystemeim AutomobilTeil 1: Architektur, Aufgaben

und Vorteile

Viele Funktionen

im Automobil wären

ohne Datenaustausch

zwischen elektronischen

Komponenten gar nicht realisierbar.

Bevor in den nächsten Folgen dieser Artikelreihe auf die speziellen

Charakteristika der einzelnen Bussysteme eingegangen wird, erklärt

dieser Beitrag die technischen Grundlagen der seriellen Bussysteme in

modernen Kraftfahrzeugen und vergleicht die verschiedenen Konzepte,

die dabei Anwendung finden.

Von Eugen Mayer

Sonderdruck

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 1

Bussysteme IIII Basiswissen

2

im Automobil der Vergangenheit an.Die Bussysteme vereinfachen nichtnur die Projektierung und Installation,sondern senken auch das Gewicht undden Platzbedarf für die Verkabelung.Darüber hinaus reduziert die geringereZahl an Steckverbindungen die Störan-fälligkeit deutlich. Die vielen Vorteileerkauft man jedoch durch zahlreicheKommunikationsaufgaben, die das se-rielle Bussystem bewältigen muss. ImFolgenden werden die wichtigstenKommunikationsaufgaben erläutert.

� Kommunikationsaufgaben

Voraussetzung für einen reibungslosenseriellen Datenaustausch ist die eindeu-tige Zuordnung der zu versendendenDaten zu den Busknoten. Grundsätzlichunterscheidet man zwischen senderse-lektiver und empfängerselektiver Zu-ordnung (Adressierung). Bei der sen-derselektiven Adressierung bestimmtder Sender den gewünschten Empfän-ger über eine eindeutige Busknoten-adresse. Im Gegensatz dazu werden beider empfängerselektiven Adressierungnicht die Busknoten, sondern die zuversenden Daten adressiert. Dadurchstehen alle Daten prinzipiell jedem Bus-knoten zum Empfang zur Verfügung(Broadcast). Sämtliche Busknoten ha-ben daher die Aufgabe, die für sie rele-vanten Daten herauszufiltern. Dies ge-schieht mit Hilfe der Adresse, die manhier als Identifier bezeichnet.

Damit der Empfänger die Datenund die Adresse als Einheit auffasst,packt der Sender beides zu einemFrame zusammen. Ein typischer Frameumrahmt die Adresse und die Datenmit einer Anfangs- und Endkennung,die vor allem zur Herstellung der Syn-chronität zwischen Sender und Emp-fänger dienen. Statt „Frame“ spricht

man auch von „Rah-men“, „Nachricht“oder „Botschaft“.

Zu den vordring-lichsten Aufgabeneines seriellen Bus-systems gehören dieechtzeitfähige Da-tenübertragung unddie Datensicherung.Ein verteiltes Sys-tem wird nur dannseiner Bestimmung

gerecht, wenn sämtliche Daten recht-zeitig und fehlerfrei die jeweilige An-wendung auf den Zielknoten errei-chen. Die Leistungsfähigkeit und dasEinsatzgebiet eines seriellen Bussys-tems im Automobil hängen entschei-dend davon ab, in welchem Ausmaßes Störungen vermeidet, abwehrt, er-kennt und korrigiert sowie die recht-zeitige Datenübertragung garantierenkann.

� Datensicherheit durch Fehler-erkennung und -korrektur

Quantitativ lässt sich die Datensicher-heit durch die Restfehlerwahrschein-lichkeit beschreiben. Diese ist ein sta-tistisches Maß für die Verletzung der

Datensicherheit. Unter Restfehler-wahrscheinlichkeit versteht man dasProdukt aus der Wahrscheinlichkeit A,mit der die zu übertragenden Datenverfälscht sind, und aus der Wahr-scheinlichkeit B, mit der verfälschteDaten unerkannt bleiben. Die Daten-sicherheit eines seriellen Bussystemshängt also einerseits davon ab, wieweitreichend es Datenverfälschungen

vermeidet, und andererseits, in wel-chem Ausmaß es verfälschte Daten de-tektiert.

Als Ursachen für Datenverfälschun-gen kommen im Automobil die ver-schiedensten Wechselwirkungen durchgalvanische, kapazitive oder induktiveKopplungen bzw. elektromagnetischeFelder in Frage. Verantwortlich sinddafür im Einzelnen z.B. Verstell- undLüftermotoren, hochfrequente Signaledurch den Kommutierungsprozess inGleichstrommotoren und durch schnel-le Datenübertragungen oder Reflexio-nen an den Bus-Enden. Je besser es ge-lingt, diese Ursachen zu eliminieren,desto störfester und sicherer ist dieDatenübertragung.

Um die Störfestigkeit eines seriel-len Bussystems zu erhöhen, sind eini-ge wichtige Maßnahmen notwendig.Neben der Abschirmung des Übertra-gungsmediums sowie sämtlicher elek-trischer und elektronischer Kompo-nenten ist für einen ausreichend großenAbstand zwischen Daten- und Ener-gieübertragungsleitungen sowie zwi-schen elektrischen und elektronischenKomponenten zu sorgen. Weiterhingilt es, die Datenübertragungsfrequenzsowie die Anzahl und die Steilheit derDatensignalflanken zu begrenzen, das

Prinzip der Differenzsignalübertra-gung zu nutzen und schließlich diebeiden Bus-Enden mit dem Wellen-widerstand des Übertragungsmediumszu terminieren.

Selbst bei optimaler physikalischerSystemauslegung lassen sich Über-tragungsfehler nicht vollständig aus-schließen. Deshalb sind Fehlererken-nungsmechanismen unerlässlich. Zu

I Bild 2. Je nach Anwendungsbereich wird auf einen zufälligen oder kontrollierten Buszugriffgesetzt.

ZufälligerBuszugriff

Nichtkollisionsfrei Kollisionsfrei

- Carrier SenseMultipleAccess(CSMA)

- CSMA withCollisionAvoidance(CSMA/CA)

"Vor demBuszugriffist Buszugriffsrechtnicht vergeben"

KontrollierterBuszugriff

Zentral Dezentral

- Polling- Delegated-Token

- Token-Passing- Time DivisionMultiple Access(TDMA)

"Vor demBuszugriffist Buszugriffs-recht vergeben"

I Bild 1. Alle elektronischen Steuergeräte (Busknoten oder „Nodes“)werden mittels eines Busses und entsprechender serieller Schnitt-stellen zu einem Systemverbund, dem seriellen Bussystem, zu-sammengeschlossen.

Node NodeNodeNodeNode

Node NodeNodeSerielle

SchnittstelleBus

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 2

Basiswissen IIII Bussysteme

3

den am häufigsten eingesetzten Me-thoden zählt das Prüfsummenverfah-ren. Dabei berechnet der Sender übereinen definierten Algorithmus aus demzu versendenden Datenblock eine Prüf-summe, die er im Anschluss an denDatenblock überträgt. Mit Hilfe dieserPrüfsumme ist der Empfänger in derLage, den empfangenen Datenblock zuverifizieren.

Je ausgeklügelter der Algorithmus,je kürzer der zu sichernde Datenblockund je länger die Prüfsumme, destobesser die Fehlererkennungsfähigkeit.Allerdings ist wegen der beschränktenBandbreite und der zeitlichen Anfor-derungen ein Kompromiss zwischender Fehlererkennungsfähigkeit unddem Verhältnis zwischen Datenblockund Prüfsumme (Übertragungseffizi-enz) zu schließen. Zudem muss berück-sichtigt werden, dass auch eine Prüf-summe während der Übertragung nichtimmun gegen Störungen ist.

Wann immer das System einenÜbertragungsfehler detektiert, ist eineFehlerkorrektur notwendig, beispiels-weise mit einer fehlerkorrigierendenPrüfsumme. Dies erfordert allerdingsgegenüber der bloßen Fehlererken-nung eine deutlich längere Prüfsum-me. Aus Effizienzgründen setzt manim Automobil keine fehlerkorrigieren-den Prüfsummen ein. Die Fehlerkor-rektur erfolgt vielmehr durch die Bot-schaftswiederholung: entweder her-vorgerufen durch eine vom fehlerer-kennenden Busknoten übertrageneFehlersignalisierung oder automatischim Falle einer zyklischen Botschafts-übertragung.

� Echtzeit-Fähigkeitfür sicherheitskritischeAnwendungen

Ein echtzeitfähiges System mussdie Übertragung sämtlicher auszutau-schenden Daten zwischen den ver-schiedenen Busknoten innerhalb einesdefinierten Zeitfensters garantierenkönnen. Die wesentlichen Einflussfak-toren sind Anzahl und Größe der Bot-schaften, die zur Verfügung stehendeBandbreite und insbesondere die Artdes Buszugriffs. Bei Letzterem unter-scheidet man grundsätzlich zwischeneinem kontrollierten und einem zufäl-ligen Buszugriff (Bild 2).

Bei seriellen Bussystemen mit kon-trolliertem Buszugriff ist das Buszu-griffsrecht bereits vor dem Buszugriffeindeutig festgelegt. Solche Systemebieten deterministischen Botschafts-verkehr als wichtige Voraussetzungfür die Verwirklichung echtzeitfähigerserieller Bussysteme. Da der gesamteKommunikationsablauf planmäßig ab-läuft und nicht beeinflussbar ist, zeich-nen sich serielle Bussysteme mit kon-trolliertem Buszugriff allerdings durchein schlechtes dynamisches Verhaltenaus.

Diesen Nachteil kennen serielleBussysteme mit unkontrolliertem Bus-zugriff nicht. Jeder Busknoten hat zu

jeder Zeit das Recht, den Bus zu bele-gen, z.B. aufgrund eines aktuellen Er-eignisses. Daraus resultiert einerseitsein sehr schneller Buszugriff; an-dererseits birgt dies aber in Abhängig-keit von der Ereignisdichte, den Bot-schaftsgrößen und der zur Verfügungstehenden Datenrate eine mehr oderweniger akute Kollisionsgefahr, waskeine guten Voraussetzungen füreine echtzeitfähige Datenübertragungdarstellt.

Die Überwachung des Bussesdurch sendewillige Busknoten redu-ziert die Kollisionsgefahr erheblich.Ganz verhindert werden kann siedurch das zusätzliche Einführen vonBotschaftsprioritäten. Allerdings kön-nen auch diese auf Bus-Monitoringund Botschaftsprioritäten basierendenzufälligen Buszugriffsverfahren keineRechtzeitigkeit garantieren. Denndurch die Priorisierung besteht dieGefahr, dass niederpriore Botschaftenunverhältnismäßig lange verzögertwerden.

� Architektur seriellerBussysteme

In Anlehnung an das von der ISO(International Standardization Orga-nization) spezifizierte Referenzmodellder Datenkommunikation wird die se-rielle Schnittstelle eines Busknotensim Automobil typischerweise in zwei(Kommunikations-)Schichten unter-teilt: untere Schicht (Physical Layer)und darüber liegende Schicht (DataLink Layer).

Der Data Link Layer übernimmtdie Aufgaben von Adressierung, Fra-ming, Buszugriff, Synchronisation so-wie Fehlererkennung und -korrektur.

Definiert werden diese Aufgaben durchein Kommunikationsprotokoll. DiePhysical-Layer-Spezifikation umfasstdagegen alle Aspekte des PhysicalLayers, angefangen von der physika-lischen Busankopplung bis hin zurphysikalischen Signalübertragung mit-tels Bus.

In der Regel realisiert man die phy-sikalische Busankopplung mit Hilfeeines Transceivers und die Ankopp-lung des Data Link Layer über einenKommunikationscontroller. Wenn sichalle Busknoten innerhalb des Systemsan dasselbe Kommunikationsprotokollund dieselbe Physical-Layer-Spezifi-kation halten, sind die grundlegendenVoraussetzungen für einen reibungslo-sen Datenaustausch zwischen den Bus-knoten gegeben.

Bei der seriellen Kommunikationübergibt die Applikation des Sendersdem Kommunikationscontroller denzu versendenden Datenblock. Dieserergänzt den Datenblock um die Adres-se und um Prüf- und Synchronisa-

I Bild 3. Vereinfachte Architektur serieller Bussysteme.

CommunicationController

Transceiver

Busknoten

Applikation

Kommunikationsprotokoll

Physical Layer Definition

KommunikationCommunicationController

Transceiver

Busknoten

Applikation

Kommunikation

Bus

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 3

Bussysteme IIII Basiswissen

4

tionsinformationen, so dass ein Frameentsteht. Der Transceiver überträgtnun den Frame über den Bus. Als phy-sikalische Verbindungsstruktur kommtim Automobil hauptsächlich die we-gen der passiven Busankopplung sehreinfach handhabbare Linientopologiezum Einsatz. Auf der Empfängersei-te nimmt wieder der Transceiver denFrame entgegen und übergibt ihn dem

Kommunikationscontroller, welcherdie an ihn übertragenen Informationenauswertet und im Falle des korrektenDatenempfangs den Datenblock an dieApplikation weitergibt.

Das Ergebnis ist ein hierarchischerund somit transparenter Kommuni-kationsfluss. Dieser wird durch das Er-ledigen der den Schichten zugeordne-ten Kommunikationsaufgaben sowiedurch das Kommunikationsprotokollund die Definition des Physical Layersgarantiert (Bild 3).

Für manche Aufgaben, wie bei-spielsweise das Busmanagement (u.a.Sleep- und Wake-Up-Funktion) oderdie Diagnose und Konfiguration vonBusknoten reicht die vom Data LinkLayer zur Verfügung gestellte Kom-munikationsfunktionalität nicht aus.Durch die Definition höherer Schich-ten bzw. höherer Kommunikationspro-tokolle kann die Kommunikations-funktionalität erweitert werden.

� Transparenz durchherstellerübergreifendeBustechnologien

Der verschärfte Wettbewerb sorgt fürimmer mehr Sicherheits- und Kom-

fortfunktionen im Automobil. Die Fol-ge ist nicht nur ein permanenter An-stieg der Anzahl an elektronischenKomponenten in den Fahrzeugen, son-dern auch ein deutlich höherer Vernet-zungsgrad mit rasant steigendem Da-tenaufkommen, da die meisten neuenAutomobil-Funktionen ohne Daten-austausch nicht mehr auskommen. Da-mit für die Kfz-Hersteller die zuneh-

mende Komplexität der Fahrzeugelek-tronik beherrschbar bleibt, schaffen sieauf den System-, Funktions- und Kom-munikationsebenen verschiedene Stan-dards. Auf der System- bzw. Funktions-ebene soll in Zukunft „AUTOSAR“(AUTomotive Open System ARchitec-ture) für die nötige Transparenz sor-gen. Herstellerübergreifende Kommu-nikationsstandards wie die seriellenBussysteme CAN [1], LIN [2], MOST[3] und FlexRay [4] sorgen für mehrTransparenz auf der Kommunikations-ebene.

CAN (Controller Area Network)wird hauptsächlich in den BereichenAntrieb, Fahrwerk und Komfort einge-setzt. LIN (Local Interconnect Net-work) dient zur einfachen und kosten-günstigen Datenübertragung im Sen-sor/Aktor-Bereich. MOST (Media Ori-ented System Transport) setzt man imInfotainment zur Übertragung vonVideo- und Audiosignalen ein. UndFlexRay ermöglicht schließlich an-spruchsvollste Kommunikation in si-cherheitskritischen verteilten Anwen-dungen. Bild 4 zeigt ein Beispiel zurVernetzung von elektronischen Steuer-geräten mit seriellen Bussystemen immodernen Automobil. Im Gegensatz

zu CAN, LIN und MOST muss sichFlexRay im Automobil aber erst nochetablieren. Im Herbst dieses Jahresgeht die erste FlexRay-Serienanwen-dung auf die Straße. Der MünchnerAutobauer BMW wird im neuen X5erstmals das innovative Bussystem ineiner aktiven Dämpferkontrolle ein-setzen.

CAN wurde Anfang der 1980erJahre von der Robert Bosch GmbHentwickelt und 1994 internationalstandardisiert (ISO 11898). DreiGeschäftsführer der Vector Infomatikwaren an der Entwicklung maßgeblichbeteiligt. LIN, MOST und FlexRaygingen aus den herstellerübergreifen-den Organisationen LIN-Konsortium,MOST-Kooperation und FlexRay-Group hervor. Sie sind zwar nicht of-fiziell standardisiert, können aber alsDe-facto-Standards aufgefasst werden.

Vector Informatik [5] unterstütztFahrzeughersteller und -zulieferer beider CAN-, LIN-, FlexRay- und MOST-Vernetzung mit einer durchgängigenWerkzeugkette aus Design- und Ent-wicklungstools sowie mit Software-komponenten und Basissoftware fürAUTOSAR-Steuergeräte. Beratung,Consulting Services und Werkzeugefür das Prozessmanagement ergänzendie Anwendungsgebiete. Abgerundetwerden die Leistungen durch ein um-fangreiches Schulungsangebot, wiebeispielsweise das eintägige Seminar„Serielle Bussysteme im Automobil“oder Grundlagenseminare zu CAN,LIN, FlexRay und MOST. Ergänzendeund vertiefende Informationen zu seri-ellen Bussystemen bietet das Unter-nehmen in Form von elektronischenInformationen im Bereich „Training“an. sj

Links

[1] www.can.bosch.com[2] www.lin-subbus.com[3] www.mostcooperation.com[4] www.flexray.com[5] www.vector-informatik.de

I Bild 4. Beispiel zur Vernetzung von elektronischen Steuergeräten mit seriellen Bussystemen imAutomobil.

ABS GetriebeBk 2Bk 1

TelefonCD-Player

NaviTV-Tuner

Motor

KlimaSitzTùr

Antrieb/FahrwerkCAN High-Speed

Kombi

Dach Computer

Gateway

Sensor AktorSensor

Komfort

Sensor/AktorLIN

FlexRaySicherheitskritische Anwendungen

Multi-mediaMOSTCAN Low-Speed

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 4

Basiswissen IIII Bussysteme

Die von Bosch [1] entwickelteCAN-Technik ist seit 1993 ge-normt und liegt, gegliedert in

mehrere Teile, als ISO-Norm 11898vor (Bild 1). Der erste Teil umfasstdas CAN-Protokoll und deckt voll-ständig den Data Link Layer (Framing,Adressierung, Buszugriff, Datensiche-rung) und teilweise den Physical Lay-er (Physical Signaling) des standardi-sierten Referenzmodells der Daten-kommunikation (ISO 7498) ab. DasCAN-Protokoll wird in Hardware im-plementiert, wofür mittlerweile eineVielzahl von kostengünstigen CAN-Controllern zur Verfügung steht.

Der zweite Teil beschreibt denCAN-High-Speed-Physical-Layer, derdritte Teil den CAN-Low-Speed-Phy-sical-Layer. Beide decken den PhysicalLayer der ISO 7498 ab (unter ande-rem die physikalische Busankopplung,Datenraten und die Spannungspegel).Der CAN-High-Speed-Physical-Layerkommt vor allem in Antriebs- und Fahr-werksapplikationen zum Einsatz. Manrealisiert ihn im Wesentlichen durchden CAN-High-Speed-Transceiver, dereine maximale Datenrate von 1 Mbit/sunterstützt. Für den hauptsächlich imKomfortbereich eingesetzten CAN-Low-Speed-Physical-Layer nutzt manin der Regel den CAN-Low-Speed-Transceiver mit einer maximalen Da-tenrate von 125 kbit/s.

Die CAN-Schnittstelle (Bild 2) be-steht demnach aus einem CAN-Con-troller und einem CAN-Transceiver.Während der CAN-Controller dasCAN-Protokoll abwickelt, übernimmtder CAN-Transceiver die Aufgabe,den CAN-Controller physikalisch anden im Differenzsignalmodus betrie-

benen CAN-Bus zu koppeln. Die Dif-ferenzsignalübertragung verbessert dieStörempfindlichkeit und erfordert zweiKommunikationsleitungen (CAN-High- und CAN-Low-Leitung), die zurVermeidung von Reflexionen an denEnden mit dem Wellenwiderstand ab-geschlossen werden.

� Zuordnung von Knoten undNachrichten über Nachrichten-adressen und -filter

Die Nachrichtenadressen, üblicher-weise als Identifier (ID) bezeichnet,bestimmen nicht die CAN-Zielkno-ten, sondern die Identität der Nach-richten selbst. Prinzipiell stehen so al-le CAN-Nachrichten allen CAN-Kno-ten zum Empfang zur Verfügung(Nachrichtenverteilung). Über einenFilter selektiert jeder CAN-Knotendie für ihn relevanten CAN-Nach-richten aus dem Nachrichtenstrom(empfängerselektives System). Auf-

grund des 11-bit-breiten Identifierslassen sich in einem CAN-Netzwerkbis zu 2048 CAN-Nachrichten spezi-fizieren.

Diese Form der Nachrichtenvertei-lung bietet folgende Vorteile:� Kosteneinsparung durch Mehrfach-

ausnutzung von Sensoren.

5

I Bild 1. Die CAN-Technik ist seit 1993 genormt und liegt als ISO-Norm 11898 vor, die den DataLink Layer und teilweise den Physical Layer des standardisierten Referenzmodells der Daten-kommunikation (ISO 7498) abdeckt.

ISO 7498

LLCMACPLSPMAMDI

Logical Link ControlMedium Access ControlPhysical SignallingPhysical Medium AttachementMedium Dependant Interface

ISO 11898-1ISO 11898-2

ISO 11898-3

CAN-ProtokollCAN-High-Speed-Physical-LayerCAN-Low-Speed-Physical-Layer

LLC

MAC

PLS

PMA

MDI

2Data LinkLayer

1PhysicalLayer

CAN

CAN-Protokoll

CAN-Physical Layer

CAN-Standard

ISO 11898-1

ISO 11898-2ISO 11898-3

Implementierung

CAN-Controller

CAN-Transceiver

Serielle Bussystemeim Automobil

Teil 2: Sicherer Datenaustausch mit CAN

Die immer komplexer werdenden elektronischen Systeme

Autofahren. Durch seine spezifischen Merkmale – so wird

etwa der sichere Datenaustausch auch unter widrigen Um-

gebungsbedingungen sichergestellt – leistet dabei das seriel-

le Bussystem CAN (Controller Area Network) einen entschei-

denden Beitrag.

Von Eugen Mayer

sorgen für ein höheres Maß an Sicherheit und Komfort beim

PressReport_PTR 28.04.2008 10:17 Uhr Seite 5

Bussysteme IIII Basiswissen

� Einfache Realisierung und Synchro-nisation von verteilten Prozessen.

� Hohe Flexibilität hinsichtlich derKonfiguration.

Der Verzicht auf Knotenadressenerlaubt die Integration von weiterenBusknoten, ohne dass die Hard- oderSoftware vorhandener Busknoten mo-difiziert werden muss. Dies gilt aller-dings nur, wenn es sich beim hinzu-kommenden Busknoten ausschließlichum einen Empfänger handelt.

� Datenübertragungerfolgt ereignisgesteuert

Die übertragenen Nachrichten und de-ren Reihenfolge sind in einem CAN-Netzwerk nicht vom Fortschreiten derZeit abhängig, sondern vom Auftretenspezieller Ereignisse. Jeder CAN-Kno-ten ist prinzipiell berechtigt, sofortnach Auftreten eines Ereignisses aufden CAN-Bus zuzugreifen. In Verbin-dung mit der vergleichsweise kurzenNachrichtenlänge von maximal 130 bitim Standard-Format und der hohen Da-tenübertragungsrate bis zu 1 Mbit/s er-möglicht das Verfahren schnelle Reak-tionen auf asynchrone Vorgänge. Diesist eine wichtige Voraussetzung für ei-ne echtzeitfähige Datenübertragung imMillisekundenbereich (1 bis 10 ms),die vor allem die Applikationen desAntriebs und des Fahrwerks verlangen.

Da der CAN-Kommunikation keinZeitplan zugrunde liegt, ergibt sich derNachrichtenverkehr stets erst zur Lauf-zeit und birgt deshalb implizit dieGefahr von Kollisionen. Diese steigtmit zunehmender Buslast und stelltdie Echtzeit-Fähigkeit in Frage. Umtrotz zufälligen Buszugriffs Echt-zeit-Datenübertragung zu gewährleis-ten, kommt im CAN-Netzwerk dasCSMA/CA-Buszugriffsverfahren (Car-rier Sense Multiple Access/CollisionAvoidance) zum Einsatz.

� CSMA/CA-Zugriffsverfahrensorgt für zerstörungsfreien,prioritätsgesteuertenBuszugriff

Der Buszugriff beginnt damit, dass einsendewilliger CAN-Knoten zunächstden CAN-Bus abhört (Carrier Sense).Ist der CAN-Bus frei, darf der CAN-

Knoten sofort mit der Nachrichtenü-bertragung beginnen. Stellt er hinge-gen Busaktivitäten fest, muss er seinenSendewunsch so lange zurückstellen,bis der CAN-Bus frei und die geradelaufende Nachrichtenübertragung ab-geschlossen ist. Zudem hat er eine Pau-se von drei Bitzeiten (ITM – Intermis-sion) abzuwarten. Eine laufende Nach-richtenübertragung wird nicht unter-brochen, der Buszugriff ist damit zer-störungsfrei. Im Falle mehrerersendewilliger CAN-Knoten verhindertdie bitweise Arbitrierung (Bild 3) trotzsimultanen Buszugriffs (Multiple Ac-cess – MA) das Auftreten von Kolli-sionen. Im Rahmen der bitweisen Ar-

bitrierung legen alle sendewilligenCAN-Knoten den ID der zu über-tragenden CAN-Nachrichten bitweisevom höchst- zum niederwertigsten Bitan. Die dem CAN-Netzwerk zugrun-de liegende Wired-AND-Buslogik(0 = dominant) sorgt dafür, dass sichimmer ein eindeutiger Buspegel ein-stellt. Nach dem Aufschalten einesID-Bits vergleicht jeder CAN-Knotenden Buspegel mit dem aufgeschaltetenPegel. Die Arbitrierungslogik ent-scheidet, ob ein CAN-Knoten weitersenden darf oder das Senden einstellenmuss.

Am Ende der Arbitrierungsphasebekommt jener CAN-Knoten die Sen-deberechtigung, der die CAN-Nach-richt mit dem niederwertigsten Identi-fier überträgt. Unterlegene CAN-Kno-ten wechseln zunächst in den Emp-fangszustand und greifen für einenerneuten Sendeversuch auf den CAN-Bus zu, sobald dieser wieder frei ist.So verhindert die Bus- und Arbitrie-

rungslogik nicht nur Kollisionen (Col-lision Avoidance), sondern sorgt auchfür einen prioritätengesteuerten Bus-zugriff: Je niederwertiger ein Identi-fier ist, desto höher ist die Priorität derCAN-Nachricht und damit ein schnel-lerer Buszugriff möglich. Die CAN-Nachricht mit dem kleinsten Identifier(ID = 0) wird deshalb ohne Verzöge-rung übertragen.

Ist die Buslast nicht zu hoch, sorgtdiese Art des zufälligen, zerstörungs-freien und prioritätengesteuerten Bus-zugriffs für einen gerechten und sehrschnellen Buszugriff. Allerdings musseinerseits berücksichtigt werden, dassmit zunehmender Buslast die Verzö-

gerungen vor allemvon niederpriorenCAN-Nachrichten an-wachsen. Das kann soweit führen, dassCAN-Nachrichten imschlimmsten Fall zuspät bei Empfängernankommen oder völligunterdrückt werden.Andererseits verur-sacht das CSMA/ CA-Buszugriffsverfahreneinen reziproken Zu-sammenhang zwischenNetzwerkausdehnungund maximaler Daten-

rate. Während der bitweisen Arbitrie-rung muss ein rezessiv sendenderCAN-Knoten einen dominanten Pegelsicher erkennen. Die Größe des Bit-Zeitintervalls ist deswegen so zuwählen, dass die Signallaufzeiten aufdem CAN-Bus vollständig kompen-siert werden. Steigende Netzausdeh-nung bedingt somit ein verlängertesBit-Zeitintervall, woraus schließlicheine maximal nutzbare Datenrate re-sultiert.

� Datenübertragungerfolgt mittels Data-Frames

Neben den für die Datenübertragunghauptsächlich eingesetzten Data-Frames (Bild 4) gibt es auch Remote-Frames zur Anforderung von Daten.Sie kommen aber kaum zur Anwen-dung, da die Datenübertragung im Au-tomobil nicht auf Nachfrage, sondernim Wesentlichen auf Informationser-zeugerinitiative basiert. Beide Frame-

6

I Bild 2. Die CAN-Schnittstelle besteht aus dem eigentlichen Con-troller zur Abwicklung des CAN-Protokolls und dem Transceiverzur physikalischen Ankopplung an das differenzielle CAN-Netz-werk.

CAN-Knoten

CAN-Knoten

CAN-Knoten

CAN-Knoten

CAN-Schnittstelle

CAN-Controller

CAN-Transceiver

CAN-Bus

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 6

Basiswissen IIII Bussysteme

Typen sind identisch aufgebaut. Aller-dings entfällt beim Remote-Frame dasData-Field.

Grundvoraussetzung für die Über-tragung von Data- und Remote-Framesist ein Gleichlauf zwischen Sender undEmpfänger. Da aus Kosten- und Auf-wandsgründen auf eine Taktleitung

verzichtet wird, realisiert man denGleichlauf mittels Signalflanken undeinem definierten Re-Synchronisa-tionsmechnismus. Jede Nachrichten-übertragung beginnt mit dem Übertra-gen des dominanten Synchronisations-bits (SOF, Start of Frame) und erzeugtso die erste Signalflanke (Bus-Idle ent-spricht einem rezessiven Buspegel).Der Empfänger stellt während der ge-samten Übertragung durch Auswer-tung jeder ankommenden Signalflankedie Synchronisation sicher und passtnotfalls sein eigenes Bit-Timing ent-sprechend an. Das Bit-Stuffing-Ver-fahren sorgt dafür, dass spätestens nachfünf homogenen Bits ein komple-mentäres Bit und somit eine Signal-flanke erscheint.

Im Anschluss an das SOF folgt derID, der entweder 11 bit (Standard-ID)oder 29 bit (Extended-ID) lang seinkann. Im Automobil dominiert dasStandardformat. Das Extended-Formatspielt typischerweise im Zusammen-hang mit höheren Protokollen wie SAEJ1939 eine Rolle. Mittels IDE-Bit(Identifier Extension) wird das ID-Format angezeigt. Ein anderer Bit-schalter (RTR-Bit, Remote Transmis-

sion Request) zeigt an, ob es sich umein Data- oder ein Remote-Frame han-delt.

Zur Übertragung von Nutzinfor-mationen steht das 64 bit breite Data-Field zur Verfügung, bei dem die ge-naue Anzahl der Nutzbytes mittelsDLC (Data Length Code) angegeben

wird. Dem Data-Field folgt dieCRC-Sequence (Cyclic RedundancyCheck). Anhand aller zu übertragen-den Bits, eines Generatorpolynomsund eines definierten Algorithmus ge-neriert der Sender die CRC-Sequen-

ce. Unabhängig von der Nachrichten-filterung geschieht dasselbe empfän-gerseitig mit den ankommenden Bits.Es folgen der Vergleich der beidenSequenzen und die Quittierung nachdem rezessiven CRC-Delimiter imAcknowledge-Slot (ACK-Slot). AmEnde eines Data-Fames steht nachdem rezessiven ACK-Delimiter das7 bit lange und rezessive EOF (End ofFrame).

� Fehlererkennungs-mechanismen sorgen fürhohe Datensicherheit

Die Wahrscheinlichkeit, dass ver-fälschte CAN-Nachrichten unerkanntbleiben, ist außerordentlich gering. Sieliegt bei 4,7 × 10–11 [2]. Dafür verant-wortlich sind die im CAN-Protokolldefinierten Fehlererkennungsmecha-nismen. Dazu gehören auf der Emp-fängerseite neben dem von der Nach-richtenfilterung unabhängigen CRC,mit dem sich bis zu fünf Fehler inner-halb einer CAN-Nachricht detektierenlassen, die Überprüfung des Formats(Form Check) und die Bit-Stuffing-Regel (Stuff Check). Der Sender führtein Bit-Monitoring durch und wertetden ACK-Slot aus.

Legt man einem CAN-Netzwerk ei-ne Fehlerrate von 10–3 zugrunde, danntreten bei einer jährlichen Betriebs-dauer von 1000 Stunden, einer Daten-rate von 500 kbit/s, einer mittlerenBuslast von 25 % und einer mittlerenNachrichtenlänge von 80 bit statistischknapp alle 4000 Jahre vom CAN-Pro-tokoll unerkannte verfälschte CAN-Nachrichten auf. Unter der Fehlerrateversteht man das Verhältnis gestörterCAN-Nachrichten zur Anzahl allerübertragenen CAN-Nachrichten.

Sobald ein Fehlererkennungsme-chanismus einen Übertragungsfehler

signalisiert, bricht der CAN-Knoten,der den Fehler erkannt hat, die Nach-richtenübertragung ab, indem er einError-Flag (sechs dominante Bits) aufden CAN-Bus auflegt. Das Error-Flagverletzt bewusst die Bit-Stuffing-Re-gel, so dass netzwerkweit jeder CAN-Knoten den bis dahin lokalen Fehlerwahrnimmt und infolgedessen dieNachrichtenübertragung mit dem Auf-schalten eines Error-Flags abbricht.

7

I Bild 3. Die Wired-AND-Buslogik sorgt, hier am Beispiel von zwei CAN-Knoten, für einen eindeu-tigen Buspegel. Die Arbitrierungslogik entscheidet, ob Busteilnehmer senden dürfen.

Sender A

Wired-AND-Buslogik: 0 = dominant

0

0

1

1

0

1

0

1

0

0

0

1

Sender B Buspegel

Arbitrierungslogik

Sender

0

0

1

1

0

1

0

1

Weiter

Fehler

Stopp

Weiter

Bus Deutung

Sender A

Sender C

CAN-Bus

1ID 10

1ID 9

0ID 8

0ID 7

ID 10 ID 9 ID 8 ID 7

CAN-Knoten C verliert Arbitrierung Einstellungdes Sendens und Übergang in Empfangszustand

1ID 6

0ID 5

0ID 4

1ID 3

1ID 2

0ID 1

0ID 0

1 1 0 0 1 0 0 1 1 0 0

1 1 0 1

I Bild 4. Frames enthalten einen 11-bit- (Standard) oder 29-bit-Identifier (Extended). BeiRemote-Frames ist, im Gegensatz zu Data-Frames, die Länge des Data-Field gleich Null.

SOF

1 1 111 Bits 4 Bits 7 Bits0-8 Byte

RTR

IDE

DEL

ACK

DEL

1

rIdentifier DLC Data Field

Arbitration-Field

Control-Field

15 Bits

Checksum EOF

1 1 1

Data-Field

ACK-Field

Check-Field

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 7

Bussysteme IIII Basiswissen

Diese Methode stellt die für die Da-tenintegrität verteilter Anwendungenso wichtige netzweite Datenkonsistenzsicher.

Die Fehlerkorrektur besteht darin,die abgebrochene CAN-Nachrichtdurch denselben Sender zu wiederho-len, sobald der CAN-Bus wieder freiist (nach dem Error-Delimiter undITM). Bei der Auslegung des Systemsmuss man berücksichtigen, dass esaufgrund des CSMA/CA-Buszugriff-verfahrens keine Garantie fürdas sofortige Wiederholengibt. Die Fehlererholzeit hängtvon der Nachrichtenprioritätund der Buslast ab.

Die Fehlersignalisierungvia Error-Flag versetzt jedenCAN-Knoten in die Lage, lau-fende Nachrichtenübertragun-gen abzubrechen. Da dies auchfür defekte CAN-Knoten gilt,sind solche in der Lage, diegesamte CAN-Kommunika-tion zum Erliegen zu bringen.Um dies zu verhindern, ver-fügt jeder CAN-Knoten übereine Netzknotenüberwachung(Bild 5), die mittels Fehler-zähler und Regeln zur Steuerung derFehlerzähler den defekten Knoten ab-schalten kann (Bus Off).

� Quittierung empfangenerCAN-Nachrichten

In einem CAN-Netzwerk wird unab-hängig von der Nachrichtenfilterungjede Nachrichtenübertragung von allenEmpfängern gleichzeitig im ACK-Slotquittiert (In-Frame-Acknowledge-ment). Ein dominanter Pegel entsprichteiner positiven, ein rezessiver Pegel ei-ner negativen Quittierung. Da der Sen-der den ACK-Slot rezessiv belegt,reicht eine positive Quittierung aus, umdie Korrektheit der Nachrichten-übertragung zu bestätigen. Aufgrunddieses knotenneutralen positiven Ack-nowledgement werden negativ quittie-rende CAN-Knoten überschrieben undbleiben ungehört. Deshalb senden die-se nach dem ACK-Delimiter ein Error-Flag.

Liegt keine einzige positive Quit-tierung vor, wird also der ACK-Slotvon keinem Empfänger überschrieben,detektiert der Sender einen ACK-Feh-

ler und bricht die laufende Nachrich-tenübertragung mit dem Aufschalteneines Error-Flags ab.

� Forderung nach Echtzeit-Fähigkeit und hoherDatenübertragungsrateüberlastet CAN

Noch bis vor einigen Jahren war CANdie am meisten gefragte Bustechnik imAutomobil. Mit voranschreitender

Elektronifizierung stößt CAN zuneh-mend an seine Grenzen. Speziell beiechtzeit-kritischen und höchst sicher-heits-kritischen Kfz-Anwendungen,die zudem eine hohe Datenübertra-gungsrate erfordern wie beispielswei-se das Fahrerassistenzsystem „LaneKeeping Assistance“, kommen zuneh-mend neue Techniken zum Einsatz,aber auch in kostensensitiven Kom-fortanwendungen stellen die Fahrzeug-entwickler den CAN-Bus in Frage.

Deswegen haben sich im Laufe derZeit neben CAN zwei andere Bussefür den Einsatz im Automobil etabliertoder sind auf dem besten Wege dort-hin: LIN und FlexRay. LIN (Local In-terconnected Network) wird bereitszur kostengünstigen Vernetzung vonSensoren und Aktoren im Komfortbe-reich eingesetzt. FlexRay ist aufgrundder zeitgesteuerten Kommunikations-methode, einer Datenrate von bis zu20 Mbit/s und der Möglichkeit, aufzwei Kommunikationskanälen zu sen-den, auf dem Vormarsch. Zum welt-weit ersten Serieneinsatz kommtFlexRay im neuen BMW X5 in einemaktiven Dämpferkontrollsystem.

� ZuverlässigeSteuergerätevernetzung

Die Spezialisten der Vector Informatik[3] unterstützen Fahrzeugherstellerund -zulieferer nicht nur bei der CAN-Vernetzung, sondern auch bei den Bus-systemen LIN, FlexRay und MOST.Für Kundenprojekte sind durchgängi-ge Werkzeugketten aus Design- undEntwicklungstools wahlweise mit Soft-warekomponenten und Basissoftware

für AUTOSAR-Steuergeräteverfügbar. Für den Einstieg indie Steuergerätevernetzungbzw. den Datenaustausch imAutomobil bietet das Stuttgar-ter Unternehmen das eintägigeSeminar „Serielle Bussystemeim Automobil“ an. Grundla-genseminare zu CAN, LIN,FlexRay und MOST vermit-teln das notwendige Basiswis-sen, um sich schnell mit denvielfältigen Entwicklungs-tätigkeiten rund um die Auto-mobilelektronik vertraut zumachen [4].

Der erste Teil dieser Bei-tragsreihe [5] befasste sich

allgemein mit seriellen Bussystemenim Automobil. In den Folgen drei bisfünf werden die seriellen BussystemeLIN, FlexRay und MOST behandelt.Der interessierte Leser findet zu denbereits veröffentlichten Themen aufder Internetseite der VectorAcademy[4] ergänzende und vertiefende Infor-mationen. sj

Literatur und Links

[1] www.can.bosch.com

[2] Unruh, J.; Mathony, H. J.; Kaiser, K.H:

Error Detection Analysis of Automotive

Communication Protocols. SAE Interna-

tional Congress 1990.

[3] www.vector-informatik.de

[4] www.vector-academy.de

[5] Mayer, E. Datenkommunikation im Auto-

mobil. Teil 1: Architektur, Aufgaben und

Vorteile serieller Bussysteme. Elektronik

Automotive 2006, H. 7, S. 70 bis 73.

8

I Bild 5. Jeder CAN-Knoten verfügt über eine Netzknotenüber-wachung, die mittels Fehlerzähler defekte Knoten erkennen undabschalten kann.

Error ActiveError-Flag Error-

Delimiter

Error Passive

Reset

REC > 127oder TEC > 127

REC < 128und TEC < 128

TEC > 255 Software-Reset nach128 x 11 rezessiven BitsBus Off

Error-Flag

Error-Delimiter

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 8

Basiswissen IIII Bussysteme

9

Serielle Bussystemeim Automobil

Teil 3: Einfacher und kostengünstigerDatenaustausch mit LIN

Die LIN-Bustechnik hat sich in kürzester Zeit für den ein-

fachen und kostengünstigen Datenaustausch im Automobil

etabliert. Viele Kfz-Hersteller setzen heute zur Übertragung

von unkritischen Signalen im Komfortbereich auf LIN. Der fol-

gende Beitrag zeigt die Gründe für den Siegeszug von LIN

(Local Interconnect Network) im Automobil auf und erläutert

die dahinter stehende Technik.

Von Eugen Mayer

Die steigenden Ansprüche derAutofahrer an den Fahrkom-fort führten zu einer breiten

Elektronifizierung in diesem Bereichder Fahrzeugtechnik. Dies spiegelt sichin der Migration vieler elektronischerKomponenten in den Komfortbereichwider. Lange Zeit war es üblich, dieimmer größere Zahl von Sensoren, Ak-toren und Motoren direkt mit einemzentralen Steuergerät zu verbinden.

Diese Entwicklung stieß allmählichan ihre Grenzen: Hatte sie doch einenrasanten Anstieg des Verkabelungs-aufwands zur Folge, begleitet vongrößerem Platzbedarf, zunehmendemGewicht und einer deutlich höherenStöranfälligkeit. Zudem erforderte diezunehmende Individualisierung vieleunterschiedliche Kabelbaum- undSteckervarianten, was wiederum dieProduktion, Installation und Wartungerhebl ich erschwerte.

Die Entwickler erkannten schnell,dass auch in dieser Kfz-Applikations-domäne eine Vernetzung der Kompo-nenten über ein Bussystem die idealeLösung darstellen würde. Da jedochder CAN-Bus für den kostensensiblenSensor-/Aktor-Bereich nicht in Fragekam, begannen bereits Mitte der1990er Jahre viele Kfz-Hersteller und-zulieferer mit der Entwicklung eige-ner Sensor-/Aktor-Bussysteme.

Nach und nach entstanden zahlrei-che kostengünstige und einfache, aberproprietäre Sensor-/Aktor-Busse. ImJahr 2000 kam mit LIN ein weiteresserielles Bussystem für den Sensor-/Aktor-Bereich auf den „Vernetzungs-markt“. Diese Technologie setzte sichauf breiter Front durch, so dass manLIN inzwischen in fast jedem Fahr-zeug findet, typischerweise in denKomfort-Anwendungen wie Klima-,Sitz-, Tür- und Spiegelsteuerung.

� Konsortium verhilftLIN zum Durchbruch

Ein wesentlicher Grund für die schnel-le Etablierung von LIN war die Grün-dung des LIN-Konsortiums [1], in Rah-men dessen sich namhafte Kfz-Her-steller und -Zulieferer sowie Halblei-ter- und Tool-Hersteller zusammen-geschlossen hatten, um einen her-stellerübergreifenden Kommunika-tionsstandard für den Sensor-/ Aktor-Bereich zu schaffen. Mit der Definiti-on eines einfachen und kostengünsti-gen Physical Layer, der sich am ISO-Standard 9141 orientiert, sowie eineseinfachen und schlanken Kommunika-tionsprotokolls legte das LIN-Konsor-tium das Fundament für den Erfolg.Denn dadurch wurden die Vorausset-zungen für die Realisierung einfacher

und kostengünstiger Busknoten ge-schaffen.

Da sich das LIN-Konsortium nichtnur auf die eigentliche LIN-Kommuni-kation fokussierte, sondern auch eineEntwicklungsmethodik (LIN WorkFlow) verfügbar machte, konnte es dieAkzeptanz des Bussystems erheblicherhöhen. Mit Hilfe des LIN Work Flowlässt sich die Entwicklung eines LIN-Netzwerks (LIN-Cluster) automatisie-ren – somit lassen sich Zeit und Kos-ten sparen. Im Mittelpunkt der Ent-wicklungsmethodik stehen zwei Da-tenaustauschformate, mit deren Hilfeder gesamte LIN-Cluster sowie dieeinzelnen LIN-Knoten einheitlich be-schrieben werden (Bild 1).

Zur Beschreibung eines gesamtenLIN-Clusters dienen die einheitlicheSyntax (LIN Configuration Language)und das standardisierte LIN Descrip-tion File (LDF). Im LDF sind die kom-pletten Eigenschaften eines LIN-Clus-ters definiert, insbesondere die Kom-munikationsbeziehungen. Mit Hilfe des

I Bild 1. LIN Work Flow: der standardisierte und schnelle Weg zumLIN-Cluster. (Quelle: alle Bilder Vector Informatik)

NCF NCF

LIN-ClusterGenerator

LIN-ClusterDesign-Tool

BusanalyzerEmulator

LIN-Cluster LIN-Bus

LDF

LIN-Node-Capability-Language-

Specification

LIN-Configuration-Language-

Specification

LIN-Slave

LIN-Slave

LIN-Master

LIN-Slave

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 9

Bussysteme IIII Basiswissen

LDF können die Generierungswerkzeu-ge die Software-Komponenten für dieLIN-Kommunikation erzeugen. Zusätz-lich versorgt das LDF die Analyse-,Mess- und Testwerkzeuge oder Rest-bus-Emulatoren mit den nötigen Infor-mationen. Analog dazu gestaltet sichdie Beschreibung der einzelnen LIN-Knoten (LIN-Slaves) über die einheit-liche Syntax der Node Capability Lan-guage und die standardisierten NodeCapability Files (NCF). Das NCF be-schreibt die Leistungsmerkmale einesLIN-Slaves, etwa die Frame- und Sig-naldefinitionen, Bitraten oder Diagno-sefunktionen und stellt im Rahmen desSystemdesigns die Grundlage zur auto-matisierten Erstellung des LDF dar.

Mit Hilfe der beiden Datenaus-tauschformate und dem in der LIN-Spezifikation definierten Konfigura-tionsprozess ist es möglich, einen LIN-Slave-Typ (z.B. Schrittmotor) mehr-mals in einem LIN-Cluster einzuset-zen beziehungsweise einen LIN-Slavein verschiedenen LIN-Clustern einzu-setzen, was die Wiederverwendbarkeitvon LIN-Slaves erhöht.

Einen ebensowichtigen Beitragzum Erfolg von LINleistet die detaillierteDokumentation derSpezifikation. Die seitNovember 2006 vor-liegende LIN-Spezifi-kation 2.1 [2] definiertden Physical Layer,das Kommunikations-

protokoll, den LIN Work Flow, dieLIN API sowie die Diagnose und Kon-figuration der LIN-Knoten.

� LIN erlaubt Eindraht-Kommu-nikation mit bis zu 20 Kbit/s

Das Ziel, ein kostengünstiges Kommu-nikationsprotokoll für den seriellenDatenaustausch im sicherheitsunkriti-schen Sensor-/Aktor-Bereich zu schaf-fen, wirkte sich vor allem auf das De-sign des Physical Layer aus. So nutztman für die physikalische Signalüber-tragung in einem LIN-Cluster nicht dievon CAN bekannte Differenzsignal-übertragung, sondern verwendet einegewöhnliche Eindrahtleitung (SingleWire). Um trotzdem eine ausreichendeStörfestigkeit zu gewährleisten, ver-wendet man als Bezugspotential fürdie Buspegel die Versorgungsspan-nung der Steuergeräte-Elektronik unddie Fahrzeug-Masse. Ein LIN-Trans-ceiver sorgt für die physikalische Bus-ankopplung. Ein Pegel unterhalb 40 %der Versorgungsspannung wird vomEmpfänger als eine logische Null in-

terpretiert. Als logische Eins interpre-tieren Empfänger Pegel oberhalb von60 % der Versorgungsspannung.

Die maximale Datenrate ist auf20 Kbit/s begrenzt, damit sich die Ab-strahlungen in Grenzen halten. BeiLeitungslängen bis 40 Meter ergibtsich unter Berücksichtigung der Kno-ten- und Leitungskapazitäten sowieder maximal zulässigen Zeitkonstanteeines LIN-Clusters, welche die LIN-Spezifikation vorgibt, eine maximalempfohlene Knotenanzahl von 16.

Schaltungstechnisch entspricht einLIN-Cluster einer Open-Collector-Schaltung. Ein Pull-up-Widerstandsorgt dafür, dass der Buspegel nahezuder Versorgungsspannung (High-Pe-gel) entspricht, wenn die Sendetransis-toren aller LIN-Knoten sperren. DerBuspegel wird auf nahezu Masse (Low-Pegel) gezogen, sobald ein Sendetran-sistor öffnet. Entsprechend werden derLow-Zustand als dominanter Pegel undder High-Zustand als rezessiver Pegelbezeichnet.

� LIN arbeitet mitMaster-Slave-Kommunikation

Der Kommunikation in einem LIN-Cluster liegt eine Master-Slave-Archi-tektur zugrunde. Ein Cluster bestehtaus einem Master-Knoten (LIN-Mas-ter) und mindestens einem oder meh-reren Slave-Knoten (LIN-Slaves). Manverzichtet aus Kostengründen auf ex-plizite Kommunikationscontroller undrealisiert statt dessen die LIN-Kom-munikation über Software-Tasks, dieso genannten Slave-Tasks, in jedemKnoten. Der LIN-Master besitzt zu-sätzlich eine Master-Task, mit derenHilfe er die Cluster-Kommunikationkoordiniert (Bild 2).

Die Koordination erfolgt mittelsder zyklischen Abarbeitung der inFrame Slots organisierten LIN-Sche-dule (Bild 3). Jeweils zu Beginn einesFrame Slots überträgt die Master-Taskeinen Frame-Header mit einer Frame-Kennung (Identifier, ID), die alle LIN-Slaves über ihre Slave-Task auswer-ten. Ein LIN-Slave überträgt im An-schluss an den Frame-Header die mitder ID assoziierte Frame Response.Der LIN-Frame, gebildet aus Frame-Header und Frame-Response, steht we-gen der Nachrichtenadressierung mit-

10

I Bild 3. Zentrales Nachrichtenverteilsystem: Der LIN-Master steuert mittels Master-Task und LIN-Schedule das Sen-den und Empfangen aller LIN-Frames. Ein Frame Slot muss so lang sein, dass der entsprechende LIN-Frame über-tragen werden kann. Die Länge des IFS hängt u.a. vom Abarbeitungstakt (Time Base) der Master-Task ab.

FrameSlot 1

Header 1

FrameHeader

FrameResponse

ReceiveResponse

SendResponse

LIN-Schedule

LIN-Master

LIN-Slave 1

LIN-Slave 2

LIN-Slave 3

LIN-Bus

t0

t0

t1

t1

t2

t2

FrameSlot 2

FrameSlot 3

Frame Slot 1

IFS

IFS

IFS(InterFrameSpace)

LIN-Frame 1

Header 2

FrameHeader

FrameResponse

ReceiveResponse

SendResponse

Frame Slot 2

LIN-Frame 2Kommunikationszyklus

Header 3

FrameHeader

FrameResponse

ReceiveResponse

ReceiveResponse

SendResponse

Frame Slot 3

LIN-Frame 3

I Bild 2. Master-Slave-Kommunikationsarchitektur: alle LIN-Kno-ten besitzen eine Slave-Task zur Teilnahme an der Kommunika-tion in einem LIN-Cluster. Ein LIN-Knoten besitzt zusätzlich eineMaster-Task zur Steuerung der LIN-Kommunikation.

Slave-Task

Master-Task

LIN-Master

LIN-Bus

Slave-Task

LIN-Slave 1

Slave-Task

LIN-Slave 2

Slave-Task

LIN-Slave 3

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 10

Basiswissen IIII Bussysteme

tels ID jedem LIN-Knoten zum Emp-fang zur Verfügung (Broadcast).

� Datenübertragungmittels LIN-Frames

Die serielle Datenübertragung in einemLIN-Cluster wird wegen des fehlendenKommunikationscontrollers über dieserielle Schnittstelle (Serial Communi-cation Interface, SCI) des Mikrocon-trollers abgewickelt und erfolgt byte-orientiert. Jedes Byte wird vom SCImit dem LSB (Least Significant Bit)zuerst übertragen und von einem Start-und einem Stopp-Bit eingerahmt (SCIFrame). Ein LIN-Frame setzt sich folg-lich aus einer Anzahl von SCI Frameszusammen, aufgeteilt auf Frame-Hea-der und Frame-Response (Bild 4).

Mit der Übertragung des Frame-Headers erledigt der LIN-Master zweizentrale Kommunikationsaufgaben: Ersynchronisiert die LIN-Slaves und de-legiert die Kommunikation, indem ereinen Sender beziehungsweise einenoder mehrere Empfänger für dieFrame-Response bestimmt. Die LIN-Slaves dürfen aufgrund der Kosten-sensibilität On-Chip-Resonatoren miteiner Frequenz-Toleranz von bis zu14 % benutzen. Deshalb überträgt derLIN-Master zunächst einen Sync-Break, um alle LIN-Slaves davon inKenntnis zu setzen, dass die Übertra-gung eines LIN-Frames beginnt. DerSync-Break setzt sich aus mindestens13 dominanten Bits zusammen undruft bei allen LIN-Slaves einen SCI-Fehler hervor. Er wird vom Sync-Break-Delimiter terminiert (mindes-tens ein rezessives Bit). Mit dem fol-genden Sync-Byte (SCI Frame mit demWert 0x55) überträgt der LIN-Masterden Kommunikationstakt.

Zur Delegierung der Kommunika-tion dient ein sechs Bit langer ID, derdurch zwei Paritätsbits mit Even Pari-ty und Odd Parity gesichert ist. Der IDund die beiden Paritätsbits werden zu-sammen als PID (Protected Identifier)bezeichnet. Die ersten 60 IDs stehenfür die Nutzdatenkommunikation zurVerfügung. Die letzten vier Identifier,ID 60 bis ID 63, sind reserviert, ID 60und ID 61 davon für Diagnosezwecke.

Die Frame-Response setzt sich ausbis zu acht Datenbytes und einerChecksumme für die Fehlererkennung

zusammen. Man unterscheidet dieklassische von der erweiterten Check-summe. Die klassische Checksummeentspricht der invertierten Modulo-256-Summe aller Datenbytes. EinÜbertragungsfehler liegt vor, wennsich die Modulo-256-Summe mit denankommenden Datenbytes nicht zu0xFF addiert. Die erweiterte Check-summe berücksichtigt zusätzlich denPID bei der Bildung der invertiertenModulo-256-Summe.

Weil die LIN-Slaves meistens mitsehr einfachen und kostengünstigenMikrocontrollern ausgestattet sind, ist

ihnen nicht nur erlaubt, die Übertra-gung der Frame-Response ein wenigzu verzögern (Response Space), son-dern auch Sendepausen zwischen derÜbertragung der SCI Frames (Inter-byte Spaces) einzulegen. Insgesamtdarf sich die Frame-Response so um40 % verlängern. Dasselbe gilt für denFrame-Header, vor allem, weil es un-terschiedliche Methoden gibt, denSync-Break zu erzeugen. Die Zeit-reserve von 40 % muss man beimDesign der LIN-Schedule unbedingtberücksichtigen.

� Sporadic, Event Triggeredund Diagnostic Frames

Die LIN-Spezifikation ermöglicht es,den durch die LIN-Schedule vorgege-benen starren Kommunikationszykluszu flexibilisieren beziehungsweise zuvereinfachen. Dazu stehen die beidenFrame-Typen „Sporadic Frame“ und„Event Triggered Frame“ zur Verfü-gung. Im Zuge der Einführung der zu-

sätzlichen Frame-Typen bezeichnetman den herkömmlichen LIN-Framefortan als „Unconditional Frame“.

Unter einem Sporadic Frame ver-steht man einen Unconditional Frame,der sich mit anderen UnconditionalFrames denselben Frame Slot teilt. Spo-radic Frames werden vom LIN-Masterbedarfsabhängig komplett übertragen,so dass Kollisionen ausgeschlossensind. Wenn kein Bedarf seitens desLIN-Masters vorliegt, bleibt der ent-sprechende Frame Slot einfach leer.

Der Event Triggered Frame wurdeeingeführt, um sporadische Verände-

rungen oder Ereignisse auf Seiten derLIN-Slaves zu kommunizieren. Er ent-spricht prinzipiell einem UnconditionalFrame, nur mit dem Unterschied, dassdem Frame-Header mehrere Frame-Responses von unterschiedlichen LIN-Slaves zugeordnet sind. Mit welcherFrame-Response der Event TriggeredFrame Header komplettiert wird, hängtvom Bedarf der entsprechendenLIN-Slaves ab. Ein Bedarf liegt dannvor, wenn neue Daten zu übertragensind. Die Frame-Response des EventTriggered Frame wird im ersten Bytedurch den PID des assoziierten Uncon-ditional Frame identifiziert.

Im Gegensatz zum Sporadic Framelassen sich beim Event TriggeredFrame jedoch Kollisionen nicht aus-schließen. Im Fall einer Kollision istder LIN-Master für die Übertragungaller dem Event Triggered Frame zu-geordneten Unconditional Frames ver-antwortlich. Dies erreicht er durch dieAktivierung und Abarbeitung einerCollision Resolving Schedule.

11

I Bild 4. Jeder LIN-Frame setzt sich aus einem Frame-Header und einer Frame-Response zusammen. Der Frame-Header wird immer vom LIN-Master übertragen. Die Frame-Response kann von einem LIN-Slave oder vom LIN-Master übertragen werden.

Frame-ResponseLIN-Frame

Frame-Header

Sync-Break

Sync-Breakmind.13 bit

Sync-BreakDelimiter(mind. 1 bit)

InterbyteSpace

(optional)

InterbyteSpace

(optional)Start-Bit

Stopp-BitLSB

Nutz-BitsSCI-Frame

MSB

ResponseSpace

(optional)

mind.14 bit 10 bit

Sync-Byte PID Data 1 . . .

. . .

10 bit 10 bit

Data 7

10 bit

Data 8

10 bit

Check

10 bit

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 11

Bussysteme IIII Basiswissen

Zur Diagnose von LIN-Slaves eig-nen sich sowohl gewöhnliche Uncon-ditional Frames als auch spezielle Dia-gnostic Frames. Unconditional Frameswerden für die einfache signalbasierteDiagnose eingesetzt, während man Dia-gnostic Frames entweder zur benutzer-definierten Diagnose oder zur Diagno-se auf Basis eines standardisiertenTransportprotokolls [3] und einheit-licher Diagnosedienste einsetzt [4, 5].

Die LIN-Spezifikation definiertzwei Diagnostic Frames: Master Re-quest Frame und Slave ResponseFrame. Der Master Request Frame (ID= 0x60) entspricht dem Diagnose-Re-quest. In diesem Fall überträgt derLIN-Master sowohl den Frame-Hea-der als auch den Frame-Response. EinMaster Request Frame wird beispiels-weise dann übertragen, wenn ein Dia-gnose-Request über CAN anliegt. DerSlave Response Frame (ID = 0x61)entspricht der Diagnose-Response. Indiesem Fall überträgt der LIN-Masterden Header, der entsprechende LIN-Slave die Response.

� LIN legt Status- undNetzwerkmanagement fest

Die LIN-Spezifikation definiert einStatusmanagement und ein Netzwerk-management. Das Statusmanagementschreibt den LIN-Slaves vor, dass siedem LIN-Master erkannte Übertra-gungsfehler wie Paritäts- oder Check-summenfehler anzuzeigen haben. Da-zu dient ein Response Error Signal ineinem Unconditional Frame (StatusFrame), das allerdings keine weiterenInformationen über die Art des Fehlersenthält. Die LIN-Spezifikation enthältkeine Definitionen zur Fehlerbehand-

lung, sondern überlässt diese Aufgabedem Anwender.

Das LIN-Netzwerkmanagement re-gelt in erster Linie den Übergang allerSlaves eines LIN-Clusters vom norma-len Kommunikationszustand (Opera-tional) in den Sleep-Zustand und um-gekehrt (Bild 5). Erkennen die LIN-Slaves für vier Sekunden keine Busak-tivität, wechseln sie vom Operational-Zustand in den Sleep-Zustand. Das-selbe bewirkt ein Sleep-Kommandovom LIN-Master, bei dem es sichum einen speziellen Master RequestFrame handelt.

Umgekehrt wechselt ein LIN-Slavevom Sleep- über den Initialisierungs-in den Operational-Zustand, wenn erein Wake-up-Signal, gefolgt von ei-nem gültigen Header erkennt. DasWake-up-Signal besteht aus einem do-minanten Puls von mindestens 250 Mi-krosekunden und höchstens 5 Millise-kunden Dauer und kann von jedemLIN-Knoten gesendet werden. DieLIN-Spezifikation schreibt eine maxi-male Initialisierungsphase von 100Millisekunden vor, das heißt, der LIN-Master muss spätestens nach dieserZeitspanne mit der Abarbeitung derLIN-Schedule beginnen. Bleibt er pas-siv, sendet der entsprechende LIN-Slave ein weiteres Wake-up-Signal.Die Anzahl von und der zeitliche Ab-stand zwischen den Wiederholungensowie Time Outs sind in der Spezifi-kation festgelegt.

� Bei Vernetzungsfragenauf externes Know-howzurückgreifen

Bei der Vernetzung mit LIN, CAN,FlexRay und MOST unterstützt VectorInformatik [6] Fahrzeughersteller und-zulieferer mit einer durchgängigenWerkzeugkette, Embedded-Software-Komponenten, Basis-Software fürAUTOSAR-Steuergeräte und Hard-ware-Schnittstellen. Die Anwender desWerkzeugs CANoe.LIN profitierenbeispielsweise während des gesamtenEntwicklungsprozesses von praxisge-rechten Funktionen für Modellerstel-lung, Simulation, Funktionstest, Kon-formitätstest, Diagnose und Analyse.Den busübergreifenden Entwurf unddie Pflege der Kommunikationsdateneines vernetzten Systems unterstützen

beispielsweise die DaVinci NetworkDesigner für LIN, CAN und FlexRay.Werkzeuge für die Entwicklung, Kali-brierung und Diagnose von Fahrzeug-steuergeräten ergänzen das umfangrei-che Vector-Angebot. Für den Entwick-lungsprozess von elektronischen Sys-temen bietet das Stuttgarter Unter-nehmen neben Beratung auch eineWerkzeugumgebung. Abgerundet wer-den die Leistungen durch ein umfang-reiches Schulungsangebot zu den Vec-tor-Tools, Software-Komponenten undseriellen Bussystemen.

Für den Einstieg in den seriellenDatenaustausch im Automobil bietetdie Vector Academy [7] die eintägigeSchulung „Serielle Bussysteme im Au-tomobil“ an. Grundlagenschulungenzu CAN, LIN, FlexRay und MOSTvermitteln das notwendige Basiswis-sen, um sich schnell mit den vielfälti-gen Entwicklungstätigkeiten rund umdie Automobilelektronik vertraut zumachen.

Die ersten beiden Teile dieser Bei-tragsreihe befassten sich mit dem seri-ellen Datenaustausch im Automobil[8] und mit CAN [9]. In zwei folgen-den Beiträgen werden die seriellenBussysteme FlexRay und MOST be-handelt. Der interessierte Leser findetzu den bereits veröffentlichten The-men auf der Internetseite der VectorAcademy [7] ergänzende und vertie-fende Informationen in Form vonE-Books. sj

Literatur und Links

[1] www.lin-subbus.org[2] LIN Specification Package Revision 2.1[3] Road vehicles – Diagnostics on Control-

ler Area Network (CAN) – Part 2: Net-work layer services. International Stan-dard ISO 15765-2.4, Issue 4, 2002-06-21.

[4] Road vehicles – Diagnostics on control-ler area network (CAN) – Part 3: Imple-mentation of diagnostic services. Inter-national Standard ISO 15765-3.5, Issue5, 2002-12-12.

[5] Road vehicles – Diagnostic systems –Part 1: Diagnostic services. Internatio-nal Standard ISO 14229-1.6, Issue 6,2001-02-22.

[6] www.vector-informatik.de[7] www.vector-academy.de[8] Mayer, E.: Serielle Bussysteme im Auto-

mobil – Teil 1: Architektur, Aufgabenund Vorteile. Electronic automotive2006, H. 7, S. 70 bis 73.

[9] Mayer, E.: Datenkommunikation im Au-tomobil – Teil 2: Sicherer Datenaus-tausch mit CAN. Electronic automotive2006, H. 8, S. 34 bis 37.

12

I Bild 5. Kommunikationszustandsmodell eines LIN-Slaves.

Power On

Nachspätestens100 ms

Initialization

Empfang des Wake-up-Signalsoder interner Grund fürdas Aufwecken des

LIN-Clusters

Empfangdes Sleep-Befehlsoder tBus_Idle > 4 s

OperationalSleep

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 12

Basiswissen IIII Bussysteme

13

Laut Statistischem Bundesamt[1] war das Fahren auf Deutsch-lands Straßen noch nie so si-

cher wie im Jahr 2005. Bei beträcht-lichem Zuwachs des Kraftfahrzeugbe-standes ereigneten sich im Vergleichzum Vorjahr fast ein Prozent weni-ger Unfälle mit Personenschäden(336 619). Stark zurückgegangen istdabei die Zahl der im StraßenverkehrGetöteten (5361, –8,2 %), Schwerver-letzten (76 952, –4,6 %) und Leicht-verletzten (356 491, –1 %). 2006 setz-te sich dieser Trend fort: ZwischenJanuar und August wurden 3260 Ver-kehrsteilnehmer getötet, was einemRückgang um 7,8 % im Vergleich zumVorjahreszeitraum entspricht. Die Zahlder Verletzten sank im gleichen Zeit-raum um 5,8 %.

Entscheidend zur Reduzierung derUnfälle und Minderung der Unfallfol-gen tragen aktive Sicherheitssystemebeziehungsweise Assistenzsystemebei, die den Fahrer beim Führen seinesFahrzeugs unterstützen. Eine Studienamhafter Fahrzeughersteller zeigtzum Beispiel, dass ESP die Anzahl derSchleuderunfälle um bis zu 80 % ver-ringert [2]. Einen ebenso wichtigen

Beitrag zur Minderung der Unfallfol-gen leisten die immer sichereren Fahr-gastzellen und optimierten Rückhalte-systeme.

Mit dem Ziel, bis 2010 die Zahl derVerkehrstoten zu halbieren, forciertdie Kfz-Branche vor allem die Weiter-und Neuentwicklung von innovativenaktiven Sicherheits- und Fahreras-sistenzsystemen. Da es in diesem Zu-sammenhang nicht nur um das Infor-mieren und Anweisen geht, sondernvielmehr um korrigierendes Eingreifenund Übernehmen von Fahraufga-ben, kommt man ohne elektronischeSchnittstellen zum Fahrwerk und zumAntrieb nicht mehr aus. Großes Poten-tial wird der Kombination aus Brake-by-Wire- und Steer-by-Wire-Syste-men zugeschrieben.

� Erhöhte Anforderungendurch steigende Vernetzung

Die Realisierung von immer an-spruchsvolleren Sicherheits- und Fah-rerassistenzfunktionen geht einhermit einer immer intensiveren Kopp-lung der elektronischen Steuergeräteund erfordert deshalb sehr hohe Da-

Serielle Bussystemeim Automobil

Teil 4: FlexRay für den Datenaustausch insicherheitskritischen Anwendungen

FlexRay geht zum ersten Mal mit dem BMW X5 in Serie.

Er wurde im August 2006 auf dem Pariser Autosalon der

Öffentlichkeit vorgestellt und ist ab März dieses Jahres in

Deutschland erhältlich. FlexRay sorgt dabei innerhalb des

aktiven Fahrwerksystems für die sichere und zuverlässige

Datenübertragung zwischen dem zentralen Steuergerät und

den vier jeweils einem Stoßdämpfer zugeordneten Satelliten-

steuergeräte. Der Beitrag zeichnet den Weg von FlexRay ins

Automobil nach und erläutert die wichtigsten Prinzipien des

FlexRay-Bussystems.

Von Eugen Mayer

tenraten zur Übertragung der zuneh-menden Anzahl von Steuer- und Sta-tussignalen. Es handelt sich dabei inerster Linie um Signale, die aufgrundsehr zeitkritischer Regelungen nichtnur äußerst schnell, sondern auch ab-solut deterministisch zu übertragensind. Folglich wächst die Bedeutungvon Kommunikationssystemen imAutomobil, die schnelle und determi-nistische Datenübertragung garantie-ren. Wegen des potentiellen Einsatzesvon By-Wire-Systemen sind sie zu-dem mit fehlertoleranten Strukturenund Mechanismen auszulegen. Dennso vielfältig das Potential und die Vor-teile von By-Wire-Systemen durchneue konstruktive Freiheiten, verein-fachte Montage oder einer Persona-lisierung des Fahrzeugs auch sein mö-gen, sie erhöhen die Anforderungenan die Datenübertragung in erheb-lichem Maße, weil sie zur Klasse derFail-Operational-Systeme gehören.Diese müssen auch im Falle eines auf-tretenden Fehlers noch einwandfreifunktionieren.

Diesen Anforderungen wird CANmit seinem ereignis- und prioritätenge-steuerten Buszugriff der durch physi-kalische Randbedingungen im Auto-mobil hervorgerufenen beschränktenÜbertragungsrate von 500 Kbit/s so-wie dem Mangel an fehlertolerantenStrukturen und Mechanismen nicht ge-recht [3].

� FlexRay beantwortet dieFrage nach Determinismusund Fehlertoleranz

Die Gewissheit, dass CAN den wach-senden Anforderungen an die Daten-

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 13

Bussysteme IIII Basiswissen

übertragung im Automobil mittelfris-tig kaum mehr gerecht werden kann,führte zur Entwicklung mehrerer de-terministischer und fehlertoleranter se-rieller Bussysteme mit höheren Daten-raten. Dazu gehören zum Beispiel TTP(Time Triggered Protocol) [4], Byte-flight [5] oder auch TTCAN (TimeTriggered CAN) [6].

Ein wesentlicher Grund für den Er-folg von FlexRay war die Gründungdes FlexRay-Konsortiums [8], in des-sen Rahmen sich im Jahre 2000 diebeiden Kfz-Hersteller DaimlerChrys-ler und BMW sowie die beiden Chi-phersteller Motorola und Philips zu-sammenschlossen. Basierend auf demursprünglich von BMW entwickel-ten Byteflight-Bussystem schuf dasFlexRay-Konsortium den hersteller-übergreifenden, deterministischen undfehlertoleranten Kommunikationsstan-dard FlexRay mit einer Datenrate von10 Mbit/s für äußerst sicherheits- undzeitkritische Anwendungen im Auto-mobil.

Heute setzt sich das FlexRay-Kon-sortium aus sieben Core-Partnern zu-sammen: BMW, Bosch, Daimler-Chrysler, Freescale, General Motors,Philips und Volkswagen. Nach undnach schloss sich dem FlexRay-Kon-sortium eine Reihe von Premium As-sociate Members an, wie beispielswei-se Vector Informatik [7] und Associ-ate Members.

Einen wichtigen Beitrag zum Er-folg von FlexRay leistet die detaillier-te Dokumentation der FlexRay-Spezi-fikation. Die beiden wichtigsten Spe-zifikationen, das Kommunikationspro-tokoll und der Physical Layer, liegen

im Moment in der Version 2.1 vor.Diese und weitere Spezifikationen derFlexRay-Bustechnologie stehen aufder Homepage des FlexRay-Konsor-tiums zum Abruf bereit [8].

� Definierter Kommunikations-zyklus verbietetunkontrollierten Buszugriff

Ebenso wie bei der Datenkommunika-tion in einem CAN-Cluster liegt auchder Datenkommunikation in einem

Flex-Ray-Cluster eine Multi-Master-Kommunikationsstruktur zugrunde.Allerdings dürfen die FlexRay-Knotennicht wie bei CAN im Zuge von an-wendungsbezogenen Ereignissen un-kontrolliert auf den Bus zugreifen. Siemüssen sich vielmehr an einen exaktdefinierten Kommunikationszyklushalten, der jeder FlexRay-Botschaftein bestimmter Zeitschlitz zuordnet(Time Division Multiple Access, TD-

MA) und dadurch die Sendezeitpunktesämtlicher FlexRay-Botschaften vor-gibt (Bild 1).

Die zeitgesteuerte Kommunikationsorgt nicht nur für deterministischeDatenkommunikation, sondern auchdafür, dass alle Knoten eines FlexRay-Clusters unabhängig voneinander ent-wickelt und getestet werden können.Zudem wirkt sich das Entfernen oderdie Integration von FlexRay-Knoten inein bestehendes Cluster nicht auf denKommunikationsablauf aus, was der inder Automobilentwicklung häufig pro-pagierten Wiederverwendung entge-genkommt.

Dem Paradigma zeitgesteuerterKommunikationsarchitekturen fol-gend, besteht die grundlegende Logikder FlexRay-Kommunikation in derAuslösung aller Systemaktivitätendurch das Erreichen bestimmter Punk-te im Zeitablauf. Den dazu erforder-lichen netzwerkweiten Gleichlauf derFlexRay-Knoten wird mittels verteil-tem, fehlertoleranten Uhrensynchro-nisationsmechanismus sichergestellt:Alle FlexRay-Knoten korrigieren mit-tels regelmäßig übertragener Synchro-nisationsbotschaften nicht nur laufend

den Beginn (Offset-korrektur), sondernauch die Dauer (Stei-gungskorrektur) derKommunikationszy-klen (Bild 2). Da-durch erhöht sich so-wohl die Bandbreiten-effizienz als auch dieRobustheit der Syn-chronisation.

Der FlexRay-Kommunikation kannentweder ein elektri-scher oder ein opti-scher Physical Layerzugrunde gelegt wer-den. Für die elektri-

sche Signalübertragung spricht dieEinfachheit, woraus sich Kostenvor-teile ergeben. Die vergleichsweise kos-tenintensive optische Signalübertra-gung zeichnet sich durch eine im Ver-gleich zur elektrischen Signalübertra-gung deutlich bessere elektromag-netische Verträglichkeit (EMV) aus.

Die FlexRay-Kommunikation istnicht an eine bestimmte Topologie ge-bunden. Eine einfache passive Bus-

14

I Bild 2. Die FlexRay-Knoten führen während des Kommunika-tionszyklus eine Steigungskorrektur durch, eine Offsetkorrekturerfolgt bei Bedarf am Ende der „Network Idle Time“.

LokaleUhren

GlobaleUhren

Zyklusstart

Zyklusdauer

FlexRay-Knoten

Offset- und Steigungskorrektur

FlexRay-Knoten

FlexRay-Knoten

FlexRay-Knoten

FlexRay-Knoten

I Bild 1. Die Übertragung von Nachrichten kann bei FlexRay im statischen oder dynamischen Segment erfolgen.Während des „Symbol Window“ wird die Funktion des Buswächters überprüft; die „Network Idle Time“ (NIT) wirdzur Uhrensynchronisation genutzt. (Quelle aller Bilder: Vector Informatik)

StatischesSegment

DynamischesSegment

SymbolWindow NIT Statisches

SegmentDynamischesSegment

StatischesSegment

SymbolWindow NIT

FlexRay-Zyklus 3

. . . . . .FlexRay-Zyklus 4

FlexRay-Zyklus 5

FlexRay-Zyklus 6

FlexRay-Zyklus 7

FlexRay-Zyklus 8

FlexRay-Zyklus 9

. . .staticslot 1

staticslot 2

staticslot 3

staticslot n

frame 1 frame 2 frame 3 frame n

Statische FlexRay-Botschaften werdenin jedem Zyklus übertragen

Minislots

Dynamische FlexRay-Botschaften werden nurbei Bedarf ùbertragen

frame 4frame 3frame 2frame 1

1 2 3 4 n

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 14

Basiswissen IIII Bussysteme

struktur ist genauso möglich wie ei-ne aktive Sterntopologie oder eineKombination aus beidem (Bild 3). DieVorteile der aktiven Sterntopologiebestehen primär in der Möglichkeitzum Abschalten von fehlerhaftenKommunikationszweigen beziehungs-weise von FlexRay-Knoten sowie imAufbau größerer Cluster mit idealenBusabschlüssen, wenn die physikali-sche Signalübertragung elektrisch er-folgt.

Zur Minimierung des Ausfallrisi-kos sieht FlexRay die redundante Aus-legung des Kommunikationskanals vor(Bild 4). Dieser redundante Kommuni-kationskanal kann allerdings auch zurErhöhung der Datenrate auf bis zu20 Mbit/s herangezogen werden. DieWahl zwischen Fehlertoleranz und er-höhter Übertragungsrate lässt sich fürjede einzelne FlexRay-Botschaft tref-fen.

Schließlich sorgt ein unabhängigerKontrollmechanismus (Buswächter –Bus Guardian) dafür, dass ein FlexRay-Knoten nur dann Zugang zum Bus er-hält, wenn er laut Kommunikationszy-klus an der Reihe ist. Dadurch wird dieBusmonopolisierung durch einen de-fekten FlexRay-Knoten (BabblingIdiot) verhindert.

� Statisches Segment überträgtechtzeit-relevante Daten

Jeder Kommunikationszyklus istgleich lang und prinzipiell gegliedertin ein statisches und ein dynamischesZeitsegment (Bild 1). Von zentralerBedeutung ist das statische Segment,mit dem jeder Kommunikationszyklusbeginnt. Es ist in eine frei definierbareAnzahl von maximal 1023 gleich lan-gen statischen Zeitschlitzen (staticslots) unterteilt.

Jedem statischenZeitschlitz ist eineFlexRay-Botschaftzugeordnet, die voneinem FlexRay-Kno-ten übertragen wird.Die Zuordnung vonstatischem Zeit-schlitz, FlexRay-Bot-schaft und FlexRay-Knoten erfolgt mittelsSlotnummer, Bot-schaftskennung (Iden-

tifier, ID) und dem Wert des auf jedemFlexRay-Knoten implementierten Slot-Counters. Damit pro Zyklus alleFlexRay-Botschaften in der richtigenReihenfolge zeitlich korrekt übertra-gen werden, werden die Slot-Counterzu Beginn eines jeden statischen Zeit-schlitzes auf allenFlexRay-Knoten syn-chron inkrementiert.Wegen der garantier-ten äquidistanten undsomit deterministi-schen Datenübertra-gung ist das statischeSegment prädestiniertfür die Übertragung von echtzeitrele-vanten Botschaften.

Im Anschluss an das statische Seg-ment folgt optional das je Kommuni-kationszyklus gleich lange dynami-sche Segment. Auch dieses Segmentist in Zeitschlitze gegliedert, aber nichtin statische Zeitschlitze, sondern inMinislots (Bild 1). Die Kommunika-tion im dynamischen Segment (Mini-slotting) basiert ebenfalls auf Zuord-nungen und dem synchronen Inkre-mentieren der Slot-Counter.

Allerdings werden die den Mini-slots zugewiesenen FlexRay-Botschaf-ten nicht zwangsläufig in jedem Kom-

munikationszyklus übertragen, son-dern lediglich bei Bedarf. Wenn keinBedarf vorliegt, werden die Slot-Coun-ter nach der definierten Zeit eines Mi-nislots inkrementiert. Bei der Übertra-gung einer dynamischen FlexRay-Bot-schaft verzögert sich die Inkrementie-rung der Slot-Counter um die Zeit derBotschaftsübertragung (Bild 5).

Die Zuordnung einer dynamischenFlexRay-Botschaft zu einem Minislotlegt implizit die Priorität der FlexRay-Botschaft fest: Je niedriger die Num-mer des Minislots, desto höher ist diePriorität der dynamischen FlexRay-Botschaft, dementsprechend früher er-folgt die Übertragung und folglich istvor dem Hintergrund eines begrenztendynamischen Zeitsegments auch dieÜbertragungswahrscheinlichkeit hö-her. Diejenige dynamische FlexRay-

Botschaft, die dem ersten Minislot zu-geordnet ist, wird bei Bedarf auf jedenFall übertragen, wenn man von einemausreichend langen dynamischen Zeit-segment ausgeht.

Beim Kommunikationsdesign mussman sicherstellen, dass auch die dyna-mische FlexRay-Botschaft mit derniedrigsten Priorität übertragen wer-den kann – zumindest, wenn sonst keinanderer Bedarf mit höherer Prioritätvorliegt. Der Designer eines FlexRay-Clusters hat auch darauf zu achten,dass die Übertragung der längsten dy-namischen FlexRay-Botschaft mög-lich ist.

15

I Bild 3. FlexRay erlaubt Bus- und Sternstruk-turen, oder wie in diesem Beispiel eine kom-binierte Topologie aus passivem Bus undaktivem Stern.

FlexRay-Knoten

FlexRay-Knoten

FlexRay-Knoten

FlexRay-Knoten

Bus

FlexRay-Knoten

FlexRay-Knoten

Stern

I Bild 4. Um das Ausfallrisiko zu minimieren, arbeitet FlexRaywahlweise mit zwei getrennten Kommunikationskanälen.

FlexRay-Knoten

FlexRay-Knoten

FlexRay-Knoten

Kanal A

FlexRay-Knoten

FlexRay-Knoten

Kanal B

I Bild 5. Im dynamischen Segment arbeitet FlexRay mit Minislots. Dabei ist jedem Minislot genau eine Botschaftzugewiesen, die jedoch nicht zwangsläufig in jedem Kommunikationszyklus übertragen werden muss.

Frame ID m

Frame ID m + 3 Frame ID m + 7

Frame ID m + 3 Frame ID m + 5

slot counter Kanal A

slot counter Kanal B dynamic slot mit Übertragung dynamic slot ohne Übertragung

minislot

Dynamisches Segment

Kanal B

Kanal Am

m m + 1

m + 1

m + 2

m + 2

m + 3

m + 3

m + 4

m + 4

m + 5

m + 5

m + 6 m + 7 m + 8

t

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 15

Bussysteme IIII Basiswissen

Der Kommunikationszyklus wirddurch zwei weitere Zeitsegmente kom-plettiert (Bild 1). Das Segment „Sym-bol Window“ dient zur Überprüfungder Funktion des Buswächters und dasZeitsegment „Network Idle Time“(NIT) schließt den Kommunikations-zyklus ab. Während der NIT berech-nen die FlexRay-Knoten die zur Syn-chronisation der lokalen Uhren erfor-derlichen Korrekturfaktoren. Am Ende

der NIT wird im Bedarfsfall die Off-setkorrektur durchgeführt (die Stei-gungskorrektur findet stets über denganzen Kommunikationszyklus ver-teilt statt). Eine Datenübertragung fin-det während der NIT nicht statt.

� Sichere Datenübertragungdurch CRC

Die Übertragung von Signalen ineinem FlexRay-Cluster erfolgt mittelsder exakt definierten FlexRay-Bot-schaft, wobei es zwischen der imstatischen Segment und der im dy-namischen Segment übertragenenFlexRay-Botschaft im Aufbau prin-zipiell keinen Unterschied gibt. Siesetzt sich stets aus einem Header, derPayload und dem Trailer zusammen(Bild 6).

Der Header umfasst das 5 bit breiteStatusfeld, die ID, die Payload Lengthund den Cycle Counter. Die Header-CRC (11 bit) sichert Teile des Status-feldes, die ID und die Payload Lengthmit einer Hamming-Distanz von sechs.Die ID kennzeichnet die FlexRay-Bot-schaft und korrespondiert mit einemZeitschlitz im statischen oder dynami-schen Segment. Im dynamischen Seg-ment entspricht die ID der Priorität derFlexRay-Botschaft. Die einzelnen Bitsdes Statusfeldes spezifizieren die

FlexRay-Botschaft genauer. Beispiels-weise zeigt das „Sync Frame IndicatorBit“ an, ob die FlexRay-Botschaft zurUhrensynchronisation verwendet wer-den darf.

Im Anschluss an den Header folgtdie Payload. Insgesamt lassen sichmit einer FlexRay-Botschaft bis zu254 byte an Nutzdaten transportie-ren. Der Trailer umfasst die denHeader und die Payload sichernde

CRC (24 bit). Bei einer Payload biszu 248 byte garantiert die CRC eineHamming-Distanz von sechs, für einegrößere Payload liegt die Hamming-Distanz bei vier [8].

� Durchgängige Lösungfür Entwicklung, Simulationund Verifikation

Bereits im Jahr 2001 bot die Vector In-formatik die erste Lösung für die Ent-wicklung von FlexRay-Systemen an.In der Zwischenzeit erhält der Ent-wickler ein umfassendes Portfolio [9].Dazu gehören Werkzeuge für Design,Entwicklung, Simulation, Analyse,Test und Kalibrierung von Steuergerä-ten und verteilten Netzwerken. Mitdem DaVinci Network DesignerFlexRay existiert eine Umgebung zumeffizienten Design der Vernetzungsar-chitektur und der Kommunikationsbe-ziehungen. Simulation, Analyse undTest von FlexRay-Systemen erfolgenmit CANoe.FlexRay, dessen Multi-bus-Konzept den gleichzeitigen Be-trieb der Bussysteme FlexRay, CAN,LIN und MOST ermöglicht. Um dasSystemverhalten des FlexRay-Netz-werkes bei Fehlern und Störungen ge-nau zu untersuchen, generiert FRstressdiese auf einem Kanal im FlexRay-Cluster.

Für den direkten Zugriff auf Steuer-geräte-interne Größen benötigt der Ent-wickler ein spezielles Mess- und Ver-stellprotokoll: XCP on FlexRay. ImRahmen der Entwicklung des aktivenFahrwerksystems des neuen BMW X5setzten die BMW-Ingenieure dasMess-, Kalibrier- und Diagnose-ToolCANape ein. Als XCP on FlexRayMaster misst und verstellt CANapeeinzelne Steuergeräteparameter direkt

über FlexRay. Neben Soft-ware entwickelt Vector In-formatik auch Stacks fürSteuergeräte. Mit den Flex-Ray-Softwarekomponentenlassen sich Applikationen un-kompliziert an verschiedeneBus- oder Betriebssystemeanbinden. Für den hardware-seitigen Zugang zu FlexRay-Bussen sorgen passende Bus-interfaces für die USB-, PCI-und PCMCIA-Schnittstelleeines PC oder Notebooks.

Das notwendige Basiswissen, umsich mit den vielfältigen Entwick-lungstätigkeiten rund um die Steuer-gerätekommunikation im Automobilvertraut zu machen, werden von derVector Academy [10] im Rahmen vonSeminaren zu CAN, LIN, FlexRay undMOST vermittelt.

Die bisher erschienenen drei Teiledieser Beitragsreihe befassten sich all-gemein mit dem seriellen Datenaus-tausch im Automobil, mit CAN undLIN. Im letzten Beitrag wird auf dieÜbertragung von Multimediadaten mitMOST eingegangen. Der interessierteLeser findet zu den bereits veröffent-lichten Themen auf der Internetseiteder Vector Academy ergänzende undvertiefende Informationen, unter ande-rem in Form von E-Books. sj

Literatur und Links

[1] www.destatis.de[2] www.bosch.de[3] Mayer, E.: Datenkommunikation im

Automobil. Teil 2: Sicherer Datenaus-tausch mit CAN. Elektronik automotive2006, H. 8, S. 34ff.

[4] www.tttech.com[5] www.byteflight.com[6] www.can-cia.org/can/ttcan[7] www.vector-informatik.de[8] www.flexray.com[9] www.flexray-solutions.de

[10] www.vector-academy.de

16

I Bild 6. Eine FlexRay-Botschaft besteht aus Header, Payload und Trailer. Pro Nachricht können bis zu254 Bytes an Nutzdaten übertragen werden.

ID DLC CRC CRC CRC CRCcyclecount

5 bit 11 bit 7 bit 11 bit 6 bit 0 - 127 Worte [0 - 2032 bit] 24 bit

Data 0 Data 1 Data 2 ... Data n

FlexRay-Botschaft

Header Payload Trailer

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 16

Basiswissen IIII Bussysteme

17

War früher das Autoradio ein-ziges Infotainment-Gerät,kamen im Laufe der Zeit

CD- und MP3-Player, Navigations-geräte und schließlich auch Bildschir-me für die Wiedergabe von Video-und DVD-Filmen hinzu. Darüber hi-naus lassen Bluetooth-Freisprechein-richtungen mit integriertem Mikrofonund iPod-Steuerung das Cockpit all-mählich zum Multimedia-Center wer-den, über das sich alle Playlisten undVerzeichnisse eines digitalen MP3-Players direkt auf dem Fahrzeugdis-play anzeigen und auch starten lassen.

Der ohnehin bereits umfangreicheVerkabelungsaufwand nimmt durchdie weiter ansteigende Vernetzungder immer leistungsfähigeren Info-tainmentgeräte kaum mehr handhab-bare Ausmaße an. Glücklicherweiseerkannten einige Kfz-Hersteller schonfrüh, welche Vorteile die Busvernet-zung auch für diesen Bereich zu bie-ten hat. Mitte der 1990er Jahre be-gannen BMW und Daimler auf derBasis des von Matsushita und Philipsentwickelten D2B-Bus (Digital DataBus) eine einheitliche Kommunika-

tionstechnologie zur seriellen Über-tragung von Audio- und Videosigna-len im Fahrzeug zu entwickeln.

� Die MOST Cooperation

1998 gründeten BMW, Daimler, Har-man/Becker und SMSC (vormalsOASIS Silicon Systems) die MOSTCooperation [1]. Inzwischen hat sichMOST als De-facto-Standard für die

Übertragungvon Multimediadaten im Fahrzeug eta-bliert; die MOST Cooperation umfasst15 internationale Fahrzeug- und mehrals 70 Gerätehersteller. Die MOST-Spezifikation liegt seit Oktober 2006in der Version 2.5 vor. Sie gliedertsich in die Bereiche Application, Net-work und Hardware.

Der Bereich Application beschreibtein logisches Gerätemodell zur trans-parenten Modellierung und Steuerungvon verteilten Infotainment-Systemenund basiert in erster Linie auf Metho-den der Objektorientierung. Weiter-hin definiert er ein hierarchischesKommunikationsmodell sowie Diens-te zur Verwaltung eines Infotainment-Systems.

Die Network Section beschreibt den„MOST Network Interface Controller“und seine Dienste, das Netzwerkma-nagement sowie die Handhabung desDatentransports in einem MOST-Sys-tem. Die Hardware Section setzt sichmit der Hardware-Struktur einesMOST-Gerätes auseinander.

Ein Auto der Premiumklasse ähnelt zunehmend einem

mobilen Büro. Auf Wunsch des Kunden drängen immer mehr

moderne Unterhaltungs- und Informationsmedien in das

Kraftfahrzeug. Zu den wichtigsten Herausforderungen gehört

dabei, den Verkabelungsaufwand gering zu halten und

gleichzeitig den gestiegenen Anforderungen an den Funk-

tionsumfang eines Infotainmentsystems im Fahrzeug gerecht

zu werden. In circa 50 Modellreihen kommt daher bereits

das Bussystem MOST (Media Oriented System Transport) zur

Übertragung von Audio- und Videosignalen zum Einsatz.

Von Eugen Mayer

Serielle Bussystemeim Automobil

Teil 5: MOST für die Übertragung vonMultimediadaten

I Bild 1. Struktur eines MOST-Gerätes, das unter anderem den Function Block „Audio Disk Player“beherbergt. Zur Systemverwaltung sind für jedes MOST-Gerät der Net Block, für jeden FunctionBlock Systemfunktionen obligatorisch.

FktIDsFktID = 0x000

NotificationFktID = 0x001

Systemfunktionen

Deck-StatusFktID = 0x200

Track-PositionFktID = 0x202

FBlockIDsFktID = 0x000

Geräte-InfoFktID = 0x001

GerätefunktionenAudio Disk Player FBlockID = 0x31 Function Block

Function

Function

Function

Function

Function

Net Block

MOST Network Interface

MOST-Gerät

...

... ......

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 17

Bussysteme IIII Basiswissen

� Modellierungvon Funktionen

Ein MOST-Gerät gliedert sich in eineFunktions- und in eine Netzwerkebene(MOST Network Interface). Auf derFunktionsebene sind die Infotain-ment-Funktionen als Funktionsblöcke(Function Blocks) untergebracht. JederFunktionsblock wie etwa der „AudioDisk Player“ stellt dem MOST-Netz-werk einen dedizierten Satz von Funk-tionen (z.B. Track Position) zur Ver-fügung, auf die mittels OperationTypes (z.B. Set zum Setzen einesTracks, oder SetGet zum Setzen undLesen eines Tracks) zugegriffen wer-den können (Bild 1).

Sowohl den Funktionsblöcken alsauch den von einem Funktionsblockbereitgestellten Funktionen sindAdressen (FBlockID, FktID) zugeord-net. Man kann sie, ebenso wie die Ken-nungen der Operation Types, dem Func-tion Catalog entnehmen. So hat derFBlock „Audio Disk Player“ denFBlockID=0x31 – die Funktion „TrackPosition“ den FktID=0x202.

Durch die Trennung von Funktionund Netzwerk und mit Hilfe der Funk-tionsmodellierung lässt sich ein Kom-munikationsmodell realisieren, wel-ches völlig unabhängig von physi-kalischen MOST-Geräten ist. Folglichspielt es keine Rolle, auf welchenMOST-Geräten man einen Funktions-block unterbringt.

� HierarchischesKommunikationsmodell

MOST-Systemen liegt eine dreistu-fige, hierarchische Steuerungsphilo-sophie nach dem Master-Slave-Prinzipzugrunde (Bild 2). Auf der oberstenHierarchieebene ist die HMI (HumanMachine Interface) angesiedelt, einexponierter Controller, der dem An-wender den gesamten Funktionsum-fang zur Verfügung stellt. Auf der mitt-leren Hierarchieebene befinden sichdie üblichen Controller. Sie decken ei-nen Teil der Systemfunktionen ab undstellen ihr partielles Systemwissen derHMI als System-Master zur Verfü-gung.

Die unterste Hierarchieebene bil-den die System-Slaves, deren Funktio-nen jeweils von einem oder mehrerenControllern nutzbar sind. Sie sind mitkeinerlei Systemwissen ausgestattet,was die Flexibilität hinsichtlich derKonfiguration wesentlich erhöht. Sys-tem-Slaves lassen sich einem MOST-System einfach hinzufügen oder ent-fernen. Zur Steuerkommunikation die-nen MOST-Kommandos. Sie umfas-sen im Kern den FBlockID, den FktID,den Operation Type und bis zu 65 535Nutzbyte.

� Systemverwaltung

Die Application Section definiert auchübergeordnete Funktionsblöcke undFunktionen zur Systemverwaltung. Zuden Systemfunktionen zählt unter an-derem die Funktion FktIDs (FktID=0x000), mit der man die von einemFunktionsblock unterstützten Funktio-nen abfragt. Die Systemfunktion Noti-fication (FktID=0x001) erlaubt dasErstellen der Notification-Matrix füreinen Funktionsblock. Aus der Notifi-cation-Matrix geht hervor, welchesMOST-Gerät zu benachrichtigen ist,wenn sich eine bestimmte Eigenschaft

eines Funktionsblocks verändert hat.Dieser Mechanismus verhindert einunnötiges Ansteigen der Buslast imMOST-System.

Zur Abfrage seiner Funktionsblöckeund Adressen hat jedes MOST-Gerätden (System-)Funktionsblock NetBlock mit der FBlockID=0x01. Mit-tels der Funktion FBlockIDs (FktID=0x000) können die auf einem MOST-Gerät implementierten Funktions-blöcke in Erfahrung gebracht werden.Über die FktIDs 0x002, 0x003 und0x004 lassen sich die physikalischeund die logische Adresse sowie dieGruppenadresse eines MOST-Gerätesermitteln.

Eine wichtige Aufgabe bei der Ver-waltung eines MOST-Systems hat derNetwork Master. Er ist für den Sys-temstart und die Verwaltung der Cen-tral Registry verantwortlich. Diese um-fasst die logischen Adressen der in ei-nem MOST-System implementiertenMOST-Geräte und die Adressen derdarauf untergebrachten Funktions-blöcke.

� „MOST Network Interface“

Das „MOST Network Interface“(Bild 3) sorgt dafür, dass die auf un-terschiedlichen MOST-Geräten unter-gebrachten Funktionsblöcke in der La-ge sind, miteinander zu kommunizie-ren. Dabei erbringen die „MOST Sys-tem Services“ („Low Level System“und „MOST Network Services“) dieKommunikationsfunktionen, die fürden Transport aller multimediarele-vanten Daten (zeitkontinuierliche Bit-ströme, Paketdaten und Steuerdaten)notwendig sind. Die „Low Level Sys-tem Services“ (Schicht-2-Dienste) sindin Hardware (Network Interface Con-troller; NIC) implementiert und setzenauf dem Physical Layer auf.

Die „MOST Network Services“, dieden Transport Layer in Form von „Ba-sic Layer System Services“ und dashöhere Management in Form eines Ap-plication Sockets umfassen, sind aufeinem externen Host Controller (EHC)untergebracht und steuern den NIC.Dabei muss sichergestellt sein, dassder EHC auch die zeitkritischsten Tei-le des Network Interface bedienenkann. Durch die Weiterentwicklungen,von MOST25 über MOST50 zu MOST-

18

I Bild 3. Unterschied zwischen der NIC- und der INIC-Architektureines MOST-Gerätes.

Application Socket

EHC

Physical Interface

Low Level System Services

NIC

Basic Layer System Services

NIC-ArchitekturApplication Socket

Physical Interface

Low Level System Services

NIC

EHC

Basic Layer System Services

INIC-Architektur

INIC

I Bild 2. Hierarchie eines MOST-Systems.

System-Slaves

System-Controller

HMI

MOST-Kommandos

MOST-Kommandos

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 18

Basiswissen IIII Bussysteme

150, stößt diese Architektur inzwi-schen an ihre Grenzen.

In Neuentwicklungen löst der INIC(Intelligent Network Interface Control-ler) den NIC ab. Während der INIC dieAbwicklung der zeitkritischen Teiledes Netzwerktreibers vom EHC über-nimmt, läuft auf dem EHC nur noch einrelativ kleiner Teil des Netzwerktrei-bers, der im Wesentlichen einen Sockelfür die Applikation darstellt. Die INIC-Architektur entlastet somit den EHC.Zur Steuerung stellt der INIC dem EHCbzw. der MOST API („MOST NetworkServices“) mit der INIC API eineSchnittstelle zur Verfügung. Die Funk-tionen des INIC sind durch einen Funk-tionsblock (FBlock INIC) gekapselt.

� MOST Networking

MOST ermöglicht die Übertragungvon kontinuierlichen Bitströmen (Bit-streaming) ohne Pufferung und unnö-tigen Overhead. Dazu speist ein ausge-wiesenes MOST-Gerät (Timing Mas-ter) den MOST-Frame (Bild 4) miteiner festen Frequenz (44,1 kHz oder48 kHz) in das üblicherweise optischeÜbertragungsmedium ein.

In einem MOST25-System stelltder MOST Frame 60 Streaming Chan-nels zu je 8 bit (bzw. 15 Quadlets zu je4 byte) zur Übertragung von kontinu-ierlichen Bitströmen zur Verfügung(Source Data Area). Die Übertra-gungsrate eines Streaming Channelsergibt sich entweder zu 352,8 kbit/s(44,1 kHz) oder zu 384 kbit/s (48 kHz).

Da die MOST-Geräte physikalischzu einem Ring zusammengeschlossensind, muss jeder MOST-Frame jedesMOST-Gerät mit der vom Timing Mas-ter vorgegeben Frequenz passieren.Sobald sich die entsprechenden Kom-munikationspartner (Datenquelle und-senke) mit denselben Streaming Chan-nels verbunden haben, beginnt das Bit-streaming (Bild 5).

Auf- und Abbau der Verbindunggeschieht üblicherweise auf Anfragedurch den Funktionsblock ConnectionMaster (CM; FblockID=0x03). Zu die-sem Zweck stellt der CM die beidenFunktionen BuildSyncConnection undRemoveSyncConnection bereit.

Im Rahmen des Verbindungsauf-baus fordert der CM die entsprechendeDatenquelle auf, zum Beispiel den TV-

Tuner, sich die entsprechende AnzahlStreaming Channels beim Timing Mas-ter allokieren zu lassen. Denn derTiming Master ist für die Verwaltungder „Channel Resource Allocation Ta-ble“ zuständig. Die Adressen der allo-kierten Streaming Channels gibt derCM der Datensenke, zum Beispiel Dis-play, weiter, damit sich diese mit denStreaming Channels verbinden kann.Zum Abschluss aktualisiert der CMdie „Sync Connection Table“, über dieer sämtliche synchronen Verbindungenverwaltet. Der Abbau funktioniert nachdem gleichen Schema.

Um auch Datenpakete übertragen zukönnen, hat der Anwender die Mög-lichkeit, die Anzahl der StreamingChannels mittels Boundary Descriptorbis auf 24 (sechs Quadlets) zu verrin-gern. Denn alle Streaming Channels,die nicht für das Bitstreaming reserviertsind, werden zum Packet Channel zu-sammengefasst. Während bei 44,1 kHzeine maximale Übertragungsrate vonbis zu 12,7 Mbit/s möglich ist, erreichtman bei 48 kHz eine maximale Über-tragungsrate von bis zu 13,8 Mbit/s.Verwaltet wird der Boundary De-scriptor vom Funktionsblock NetworkMaster (FBlockID= 0x02). Über dieFunktion Boundary (FktId=0xA03)lässt sich dieser setzen.

Zur Übertragung von Datenpaketenkommt ein Schicht-2-Protokoll zumEinsatz. Der Frame setzt sich aus demArbitrierungsfeld, der Quell- und Ziel-adresse, dem Data Length Code, demDatenfeld (48 oder 1014 byte) und der

Datensicherung zusammen. Ein imRing zirkulierender Token regelt denBuszugriff. Jenes MOST-Gerät, wel-ches den Token vom Ring nimmt, darfauf den Packet Channel zugreifen.

Schließlich muss das MOST-Systemdie zur Verwaltung und Steuerung not-wendigen MOST-Kommandos übertra-gen. Dazu kommen Control Messages(Bild 6) zum Einsatz, die im ControlChannel übertragen werden. Zur Über-tragung einer Control Message sind16 MOST-Frames (MOST-Block) er-forderlich. Die Übertragungsrate be-trägt bei 44,1 kHz 705,6 kbit/s und bei48 kHz 768 kbit/s. Auch der Übertra-gung der Control Messages liegt einSchicht-2-Protokoll zugrunde. Der Bus-zugriff erfolgt mittels CSMA-Verfah-ren (Carrier Sense Multiple Access).

� Physical Layer

Zur Übertragung der Audio- und Vi-deosignale im MOST-System sind

19

I Bild 4. Aufbau des MOST-Frames: Im Administrations-Byte 0werden Synchronisationsinformationen und der BoundaryDescriptor, im Administrations-Byte 63 werden Status-Bits undein Paritäts-Bit zur Sicherung des MOST-Frames übertragen.

m

Stream-Data-Channels

0 1 2 3 4 5 6 7 n

Administration

Administration

. . . 60 61 62 6358 59. . .

SynchronousData Transfer

PacketChannels

AsynchronousData Transfer

Boundary Descriptor

Source Data Area (60 byte)

MOST Frame (64 byte)Control Data Channel (2 byte)

I Bild 5. Prinzip des Bitstreamings: Der Timing Master überträgt mit der Frequenz von 48 kHzMOST-Frames. Es stehen 40 Streaming Channels (10 Quadlets) mit je 384 kbit/s zur Allokierungbereit (Boundary Descriptor = 0xA). Der Packet Channel (20 byte) stellt für die Übertragung vonDatenpaketen eine Bandbreite von 7,68 Mbit/s zur Verfügung.

MOST-Frame (t = 1/f)

1 2 3 4140 42 43

40 StreamData Channels

à 8 bit

40 StreamData Channels

à 8 bit

. . . 6160 62 21 3 6160 62

PacketChannelà 20 byte

. . . 4140 42 43. . .

PacketChannelà 20 byte

. . . . . .

MOST-Frame (t = 1/f)

Stream DataChannel 1 - 40 384 kbit/s1 byte1 byte 1 byte

Packet Channel 7,68 Mbit/s20 byte20 byte 20 byte

Control Channel 768 kbit/s2 byte2 byte 2 byte1/f 1/f1/f . . .

TimingSlave

TimingSlave

TimingSlave

TimingMaster

f = 48 kHz

MOST-Ring

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 19

Bussysteme IIII Basiswissen

heute Lichtwellenleiter aus Polymer-fasern (POF; polymeroptische Faser)Stand der Technik (Kasten). In derSumme sind die technischen Eigen-schaften der Polymerfasern denenelektrischer Übertragungsmedien weitüberlegen. Zu erwähnen ist vor allemdie hervorragende elektromagnetischeStörfestigkeit und die vergleichswei-se hohe Signalübertragungsgeschwin-digkeit von bis zu 500 Mbit/s. Außer-dem stellt die Kombination aus POF,roter Leuchtdiode als Lichtquelle undeiner Silizium-PIN-Fotodiode als

Empfänger eine sehr günstige undvergleichsweise einfach handhabbareForm der optischen Signalübertra-gung dar.

Mit MOST150 geht nach MOST50aktuell ein MOST-System an denStart, dem diese Sender- und Empfän-ger-Technik zugrunde liegt und demAnwender eine Übertragungsge-schwindigkeit von 150 Mbit/s zurVerfügung stellt. Die im Auto ver-gleichsweise kurzen Strecken von biszu 20 m sind damit problemlos zu be-wältigen.

� Entwicklung, Test undAnalyse von MOST-Systemen

Die Vector Informatik GmbH ist seit1999 assoziiertes Mitglied der MOSTCooperation und bietet Unterstützungbei Entwicklung und Analyse von Info-tainment-Lösungen im Automobil. FürAnwendungen wie High-End-Audio-systeme, Multimedia-Streaming, Tele-fonie und Navigation gibt es eine um-fassende Palette an Analyse-, Entwick-lungs- und Test-Werkzeugen, Hard-ware-Schnittstellen, Datenlogger sowieSchulungen und Dienstleistungen [2].Das notwendige Basiswissen rund umdie Steuergerätekommunikation imAutomobil vermittelt die Vector Aca-demy [3] im Rahmen von Seminaren zuCAN, LIN, FlexRay und MOST. sj

Literatur

[1] www.mostcooperation.com[2] www.vector-group.net/most/de[3] www.vector-academy.de[4] Mayer, E.: Serielle Bussysteme im Auto-

mobil. Teil 1: Archtiektur, Aufgabenund Vorteile. Elektronik automotive2007, H. 7, S. 70 – 73.

[5] Mayer, E.: Datenkommunikation imAutomobil. Teil 2: Sicherer Datenaus-tausch mit CAN. Elektronik automotive2007, H. 8, S. 34 – 37.

[6] Mayer, E.: Serielle Bussysteme im Auto-mobil. Teil 3: Einfacher und kostengüns-tiger Datenaustausch mit LIN. Elektro-nik automotive 2008, H. 1, S. 40 – 43.

[7] Mayer, E.: Serielle Bussysteme im Auto-mobil. Teil 4: FlexRay für den Datenaus-tausch in sicherheitskritischen Anwen-dungen. Elektronik automotive 2008,H. 2, S. 42 – 45.

20

Dipl.-Ing., Dipl.-Techpaed. Eugen Mayer

hat an der FH Ravensburg/Weingarten Elek-

tronik und an der Universität Stuttgart Elek-

trotechnik und Berufspädagogik studiert. Er

arbeitet seit 1999 bei der Vector Informatik

und ist dort als Senior Trainer tätig.

eugen.mayer@vector-informatik.de

Signalübertragung mittels POF

Tritt ein Lichtstrahl von einem transparentenMedium in ein anderes über, so wird er ge-brochen. Die Brechung ist um so stärker, jegrößer der Einfallswinkel ist. Das Medium, indem der Lichtstrahl mit dem Lot den kleine-ren Winkel bildet, ist das optisch dichtereMedium. Beim Übergang vom optisch dich-teren zum optisch dünneren Medium wirdder Strahl vom Lot weg gebrochen. DerBrechungswinkel α kann berechnet werden,wenn die so genannten Brechzahlen n derbeiden Medien bekannt sind (Snellius-Ge-setz). Überschreitet der Lichtstrahl beimÜbergang vom optisch dichteren zum op-tisch dünneren Medium den Einfallswinkelα0, so tritt Totalreflexion ein.Aufgrund dieser Eigenschaft kann man Lichtin einem optischen Leiter transportieren. ImMOST-System setzt man üblicherweise Poly-merfasern zur optischen Signalübertragungein, deren Kern aus PMMA (Polymethylmetha-crylat) von einem dünnen Mantel aus fluorier-tem Acrylat umgeben ist. PMMA hat einegrößere Brechzahl als fluoriertes Polymer.

Wenn der eingehende Lichtstrahl über demGrenzwinkel liegt, wird aufgrund der Totalre-flexion das Licht im Kern geführt.Die kleinsten Dämpfungen für das Übertragenvon Licht in einer Step-Index-PMMA-Fasern er-hält man bei 520 nm (grün), 560 nm (gelb)und 650 nm (rot). In erster Linie werden roteLEDs verwendet (Dämpfung: 0,14 dB/m), dasie sehr kostengünstig sind

0,2

0,1

0,4dB/m

0,3

500450 600550 650 nm

Dämpfung

Wellenlänge

Dämpfungsfenster

I Bild 6. Zur Übertragung einer Control Message ist ein MOST-Block erforderlich. Die ControlMessage setzt sich zusammen aus: Arbitrierung (a), Zieladresse (b), Quelladresse (c), MessageTyp (d), Datenfeld (e), Datensicherung (f), Bestätigung (g) und Reservierung (h).

a

2byte

2byte

2byte

2byte

2byte

2byte

2byte

2byte

2byte

2byte

2byte

2byte

2byte

2byte

2byte

2byte

b c d f g he

MOSTFrame

MOST-Block (16 MOST Frames)

Control Message (32 byte)

. . .

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite 20

Es ist keine Kunst,

Automobil-Vernetzung zu entwickeln, wenn man es einmal gelernt hat.

Egal, ob Sie in das Thema Automobil-Elektronik neu ein-

steigen oder ob Sie schon ein versierter Profi sind: in der

VectorAcademy finden Sie mit Sicherheit den richtigen Work-

shop für Ihren Wissens-Level. Ihr Vorteil: Sie buchen nur die

Module, die Sie wirklich brauchen.

CAN, LIN, AUTOSAR, FlexRay, MOST, offene Protokolle... statt Antworten in Büchern zu suchen, löchern Sie doch unse-

re Trainer! Effektiver können Sie sich Wissen und Fähigkeiten

nicht aneignen: wir vermitteln Ihnen strukturiert die Theorie,

leiten Sie bei praxisorientierten Übungen an. Und Sie tau-

schen Erfahrungen mit Kollegen aus Ihrer Branche aus.

Mit weniger sollten Sie sich nicht zufrieden geben. Dafür

kostet es weniger als Sie vielleicht denken. Den schnellen

Überblick verschaffen Sie sich am besten auf unseren Web-

Seiten. Falls Antworten offen bleiben, unsere Schulungsbera-

ter freuen sich auf Ihren Anruf:

Tel (07 11) 8 06 70-5 70 und -5 76

www.vector-academy.de

VectorAcademy. Mehr Praxis.

Vector Informatik GmbH

Ingersheimer Str. 24

70499 Stuttgart

Tel (07 11) 8 06 70-0 Fax (07 11) 8 06 70-1 11

info@vector-informatik.com

www.vector-informatik.com

PTR_Ad_2007_A4_V1.0.indd 1 15.04.2008 09:07:25

V 1

.0 2

00

8-0

4©

200

8 Ve

ctor

Info

rmat

ik G

mbH

Ihre Ansprechpartner

Deutschland und alle Länder,

soweit nicht unten genannt

Vector Informatik GmbHIngersheimer Str. 24 70499 StuttgartGERMANYTel.: +49 711 80670 0Fax: +49 711 80670 111

Frankreich, Belgien, Luxemburg

Vector France SAS168, Boulevard Camélinat92240 MalakoffFRANCETel.: +33 1 4231 4000Fax: +33 1 4231 4009

Schweden, Dänemark, Norwegen,

Finnland, Island

VecScan ABLindholmspiren 541756 GöteborgSWEDENTel.: +46 31 764 76 00 Fax: +46 31 764 76 19

USA, Kanada, Mexiko

Vector CANtech, Inc.Suite 55039500 Orchard Hill Place Novi, Mi 48375USATel.: +1 248 449 9290Fax: +1 248 449 9704

Japan

Vector Japan Co., Ltd.Seafort Square Center Bld. 18F2-3-12 Higashi-shinagawa,Shinagawa-kuTokyo 140-0002 JAPANTel.: +81 3 5769 6970Fax: +81 3 5769 6975

Korea

Vector Korea IT Inc.Daerung Post Tower III, 508Guro-gu, Guro-dong 182-4Seoul 152-790 REPUBLIC OF KOREATel.: +82 2 2028 0600Fax: +82 2 2028 0604

www.vector-worldwide.com

PressReportAHR_PTR 24.04.2008 10:30 Uhr Seite d