Echtzeit-Betriebssysteme und -Bussysteme

Transkript

1 Echtzeit-Betriebssysteme und -Bussysteme Seminar im Wintersemester 2006/07 Steffen H. Prochnow Reinhard von Hanxleden Echtzeitsysteme und Eingebettete Systeme Institut für Informatik und Praktische Mathematik Christian-Albrechts-Universität zu Kiel Kiel, 1. Februar 2007

2

3 Vorwort Eingebettete Systeme bestehen in der Regel aus speziell an den jeweiligen Anwendungsbereich angepasster Hardware, auf der ein geringer Anteil von Software ausgeführt wird. Vorteil des hohen Spezialisierungsgrades der Hardware ist eine hohe Leistungsfähigkeit, die allerdings mit einer aufwändigen Entwicklung und geringen Flexibilität derartiger Systeme einhergeht. Diese Nachteile, zusammen mit der stetig steigenden Komplexität eingebetteter Systeme, haben zu Entwurfskonzepten geführt, welche die Integration standardisierter Komponenten wie etwa CPUs, DSPs und Bussystemen vorsehen und den Einsatz von spezieller Hardware minimieren; der Softwareanteil in diesen Systemen überwiegt dabei. Zur Verbesserung der Flexibilität und Portabilität der Software werden in solchen Systemen vorwiegend Echtzeit-Betriebssysteme eingesetzt; Echtzeit-Bussysteme übernehmen in dieser Umgebung die Kopplung kommunizierender Echtzeit-Knoten. Aus der Beschäftigung mit am Markt verfügbaren Echtzeit-Betriebs- und -Bussystemen ergeben sich eine Reihe interessanter Problemstellungen, denen sich im Wintersemester 2006/07 die Seminarveranstaltung des Lehrstuhls Echtzeitsysteme und Eingebettete Systeme widmete. Ziel für die studentischen Seminarteilnehmer war, sich binnen eines Semesters in ein vorgegebenes Themengebiet einzuarbeiten und dieses im Überblick darzustellen. Dazu gehörte das Verfassen einer schriftlichen Ausarbeitung (max. 10 Seiten, Stil entsprechend ACM SIG Proceedings) und sowie ein Vortrag (max. 45 min). Die Ausarbeitungen sind im Folgenden zusammengestellt. Im Anhang finden sich die annotierten Präsentationsfolien der Vorträge, die am 1. Februar 2007 im Rahmen eines Workshops gehalten wurden. Für das Zustandekommen und das Gelingen des Seminars möchte ich mich herzlich bei den Autoren und den Zuhörern bedanken. Steffen Prochnow iii

4 iv

5 Zeitplan 9:00 Uhr: Christoffer Menk, Einführung in Echtzeitbetriebssysteme 9:45 Uhr: Dominik Meyer, VxWorks Aufbau und Programmierung 10:30 Uhr Kaffeepause 10:45 Uhr: Lars Wienbrandt, Echtzeitbussysteme im Überblick 11:30 Uhr: Henrik Rathje, Das FlexRay Protokoll im Vergleich mit TTP/C 12:15 Uhr: Christian Motika, Real-Time Ethernet und Ethernet Powerlink 13:00 Uhr: Gemeinsames Mittagessen (Oblomow) v

6 vi

7 Inhaltsverzeichnis I. Echtzeit-Betriebssysteme 1 1. Einführung in Echtzeitbetriebssysteme 3 Christoffer Menk 2. VxWorks Aufbau und Programmierung 13 Dominik Meyer II. Echtzeit-Bussysteme Echtzeitbussysteme im Überblick 25 Lars Wienbrandt 4. Das FlexRay Protokoll im Vergleich mit TTP/C 39 Henrik Rathje 5. Real-Time Ethernet und Ethernet Powerlink 47 Christian Motika vii

8 Inhaltsverzeichnis III. Anhang: Vorträge 57 Einführung in Echtzeitbetriebssysteme 59 Christoffer Menk VxWorks Aufbau und Programmierung 69 Dominik Meyer Echtzeitbussysteme im Überblick 75 Lars Wienbrandt Das FlexRay Protokoll im Vergleich mit TTP/C 89 Henrik Rathje Real-Time Ethernet und Ethernet Powerlink 97 Christian Motika viii

9 Teil I. Echtzeit-Betriebssysteme

10

11 Einführung in Echtzeitbetriebssysteme Einführung in Echtzeitbetriebssysteme Christoffer Menk Christian-Albrechts-Universität zu Kiel Arbeitsgruppe für Echtzeitsysteme und Eingebettete Systeme Kiel, Germany Zusammenfassung In der heutigen Zeit gibt es viele Echtzeitbetriebssysteme, die für eine Vielzahl von Echtzeitsystemen eingesetzt werden. Diese Echtzeitsysteme müssen spezielle Anforderungen erfüllen, die vom Betriebssystem berücksichtigt werden müssen. Für diese Echtzeitbetriebssysteme müssen daher andere Mechanismen als für herkömmliche Betriebssysteme benutzt werden. Ziel dieser Arbeit ist es deshalb einen Überblick über Echtzeitbetriebssysteme zu geben und wesentliche Merkmale und Unterschiede zu herkömmlichen Betriebssystemen aufzuzeigen. Weiterhin wird eine Auswahl von bekannten Echtzeitbetriebssystemen, die es auf dem Markt gibt, vorgestellt und Kriterien zur Auswahl eines Echtzeitbetriebssystems gegeben. 1. EINFÜHRUNG Echtzeitsysteme und Eingebettete Echtzeitsysteme befinden sich überall in unserer Umgebung, ob in einem Handy, Flugzeug oder Auto. Es wurde festgestellt, dass 98% der weltweit hergestellten Mikroprozessoren in Eingebetteten Systemen verwendet werden [3]. Diese vom Mikroprozessor gesteuerten Systeme sind meistens auch Echtzeitsysteme. Im Gegensatz zu herkömmlichen Computern arbeiten diese Systeme oft in einer Umgebung, in der Speicher und Rechenleistung begrenzt sind. Weiterhin müssen sie ihre Aufgaben für ihren Benutzer oder ihre Umgebung in einer bestimmten Zeit erledigt haben. Für solche Systeme wurden daher spezielle Echtzeitbetriebssysteme entwickelt, die die Eigenschaften und Einschränkungen in Zeit, Speicher und Rechenleistung erfüllen und berücksichtigen. Ein Echtzeitbetriebssystem stellt hierfür aber nur die nötigen Mittel zur Verfügung. Die Applikation, die dann auf diesem Echtzeitbetriebssystem läuft, muss garantieren, dass das System auch wirklich in Echtzeit arbeitet. Ein herkömmliches Betriebssystem ist für solche Aufgaben hingegen nicht geeignet, weil es insbesondere nicht den zeitlichen Determinismus für seine Anwendungen garantiert. Deswegen werden in Abschnitt 2 allgemeine Unterschiede von Echtzeitbetriebssystemen zu herkömmlichen Betriebssystemen aufgezeigt. Danach werden in Abschnitt 3 und 4 der grundlegende Aufbau eines Echtzeitbetriebssystems erläutert und die wichtigsten Elemente des Kernels genauer beschrieben. In Abschnitt 5 wird der Markt der Echtzeitbetriebssysteme genauer betrachtet und es werden Kriterien für die Auswahl eines Echtzeitbetriebssystems gegeben. Abschließend werden in Abschnitt 6 einige Schlussfolgerungen aus den vorherigen Abschnitten gezogen. 2. UNTERSCHIEDE ZU HERKÖMMLICH- EN BETRIEBSSYSTEMEN Laut DIN versteht man unter einem Betriebssystem die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften der Rechenanlage die Grundlage der möglichen Betriebsarten des digitalen Rechnersystems bilden und insbesondere die Abwicklung von Programmen steuern und überwachen [7]. Die Größe eines Betriebssystems kann von einigen Kilobytes bei Mikrorechnern bis zu mehreren Megabytes bei Großrechnern reichen. Ein Echtzeitbetriebssystem betreibt, wie der Name schon sagt, den Rechner und die Anwendungsprogramme in Echtzeit, d.h. das Ergebnis muss bis zu einem bestimmten Zeitpunkt feststehen, welcher als deadline bezeichnet wird. Hierbei wird zwischen harten und weichen Echtzeitsystemen unterschieden. Bei harten Echtzeitsystemen muss das Echtzeitbetriebssystem sicherstellen, dass die fest vorgegeben deadlines eingehalten werden, weil es sonst zu schwerwiegenden Systemausfällen kommen kann. Bei weichen Echtzeitsystemen sollen die zeitlichen Schranken zwar auch eingehalten werden, aber wenn eine deadline verpasst wird, funktioniert das System trotzdem noch korrekt. Ein Beispiel für ein hartes Echtzeitsystem ist die Steuerung eines Flugzeugs, die bei nicht rechtzeitiger Funktionsweise, sogar Menschenleben kosten kann. Ein Bankautomat wäre ein Beispiel für ein weiches Echtzeitsystem, weil gelegentliche Verzögerungen für den Benutzer tolerierbar sind. Der Hauptunterschied zu herkömmlichen Betriebssystemen ist, dass Echtzeitbetriebssysteme zeitlich determiniert arbeiten müssen. Dieses ist der Fall, wenn zu jeder Kombination von Eingangsgrößen die Reaktionszeit des Echtzeitsystems in festen zeitlichen Grenzen vorhersagbar ist [21]. Insbesondere darf es keine zeitlichen zufälligen Komponenten geben. Durch solche Komponenten könnte es zu zufälligen Verzögerungen kommen, wodurch deadlines verpasst werden würden. Herkömmliche Betriebssysteme sind im Gegensatz dazu im Allgemeinen nicht deterministisch, weil die Antwortzeiten von Applikationen nicht vorgeschrieben sind. Daher kann es hier durchaus zu unerwartet langsameren Antwortzeiten kommen. Dieses begründet sich in der Tatsache, dass zeitliche Determiniertheit einfach kein Ziel bei der Entwicklung von Betriebssystemen ist. In bekannten Betriebssystemen wird für die Prozessverwaltung ein Time- Sharing-Scheduler eingesetzt, der so konzipiert ist, dass er 3

12 Christoffer Menk Benutzern gute Antwortzeiten bietet und dabei sicherstellt, dass Hintergrundaufträge mit geringerer Priorität nicht verhungern [17]. Dieses Konzept ist für Echtzeitbetriebssystem nicht geeignet und daher gibt es andere Algorithmen für die Prozessverwaltung, wovon einige in Abschnitt 4 vorgestellt werden. Ein weiterer Unterschied zwischen Echtzeitbetriebssystemen und herkömmlichen Betriebssystemen sind die Zeiten, wann ein Prozesswechsel stattfinden kann. In herkömmlichen Betriebssystemen gibt es einen Ticker, der z. B. alle 10ms überprüft, ob es einen Prozess mit höherer Priorität gibt, der dann den Prozessor benutzen darf. Wenn jetzt also ein Prozess mit höherer Priorität, als der aktuelle Prozess, den Prozessor benutzen will, kann es vorkommen, dass er bis zu 10ms warten muss. Die wichtigste Eigenschaft eines Echtzeitbetriebssystems ist aber die zeitliche Determiniertheit, deswegen sollte ein Prozess zu jeder Zeit unterbrochen werden können. Weiterhin muss der Scheduler in herkömmlichen Betriebssystem oft ein Array von Prozessen durchsuchen, um herauszufinden, welcher Prozess als nächstes den Prozessor benutzen darf. Dieses ist aber nicht deterministisch, weil diese Suche länger dauert, je mehr Prozesse im Array vorhanden sind. Ein Echtzeitbetriebssystem benutzt daher eine Tabelle, die ständig aktuell gehalten wird, so dass der Prozess mit höchster Priorität in konstanter Zeit gefunden werden kann. Dieses kann in Abbildung 1 betrachtet werden. Es ist zwar zu erkennen, dass für wenige Prozesse die Zei- Determinismus ist auch ein wichtiger Faktor bei der dynamischen Belegung von Speicher. Viele herkömmliche Betriebssysteme benutzen für die Speicherverwaltung einen Heap. Die aus C bekannten Befehle malloc und free arbeiten auf einem Heap. Näheres kann dazu in Kernighan und Ritchie [10] nachgelesen werden. Wenn mehrere Prozesse diese Befehle benutzen kann es dazu kommen, dass der Speicher mit der Zeit in viele kleine Fragmente zerlegt wird, die nicht mehr von größeren Prozessen benutzt werden können, weil sie mehr Speicher benötigen. Dieses Phänomen wird External Memory Fragmentation genannt und kann durch einen Garbage Collector behoben werden. Jedoch sind die Algorithmen für Garbage Collectoren im Allgemeinen nicht deterministisch, wodurch sie für ein Echtzeitbetriebssystem nicht in Frage kommen. Der Determinismus geht bei nicht echtzeitfähigen Garbage Collectoren dadurch verloren, dass nicht bekannt ist, wie viel Speicher aufbereitet werden muss, welche Zeit benötigt wird, um die nicht deterministische Datenstruktur zu verwalten. Für Echtzeitbetriebssysteme gibt es deswegen andere Mechanismen für die Speicherverwaltung, die in Abschnitt 4 erläutert werden. Weitere Unterschiede gibt es bei der Wartbarkeit und der Reaktion auf fehlerhafte Zustände. Ein Echtzeitbetriebssystem sollte stets eine definierte Reaktion auf einen Fehlerzustand haben, weil das System sonst nicht mehr vorhersagbar wäre. Weiterhin sollten Echtzeitbetriebssysteme auch eine gute Wartbarkeit bieten, weil Fehler oft schnell beseitigt werden müssen, wenn es sich z. B. um sicherheitskritische Systeme handelt. Aus den vorher genannten Gründen sollte ein Echtzeitbetriebssystem nach Witzak [21] folgende Anforderung erfüllen: Garantie der geforderten Rechtzeitigkeit und Gleichzeitigkeit I/O-Management und Hardwaresteuerung Sicherstellung der Unterbrechungsfähigkeit Sichere Verwaltung der Rechenprozesse und des Systemspeichers Definierte Reaktion auf Fehlerzustände Bereitstellung der Ressourcen zur Prozesskommunikation und Synchronisation Abbildung 1: Vergleich der Zeit für einen Prozesswechsel (Quelle: Kalinksy [9]) ten zum Prozesswechsel bei einem herkömmlichen Betriebssystem geringer sind, aber bei Echtzeit geht es nicht um Schnelligkeit, sondern um Vorhersagbarkeit, welche durch die konstante Zeit zum Prozesswechsel gewährleistet wird. Weiterhin ist zu erkennen, dass der Wert für einen Prozesswechsel bei einem herkömmlichen Betriebssystem über einen größeren Bereich eingezeichnet ist. Dieses liegt daran, dass herkömmliche Betriebssysteme nicht deterministische Scheduler benutzen, die nicht vorhersagbar sind und von Betriebssystem zu Betriebssystem verschieden sind. Es gibt noch weitere Unterschiede zwischen einem Echtzeitbetriebssystem und einem herkömmlichen Betriebssystem. Dieses resultiert daraus, dass für herkömmliche Betriebssysteme viele nicht deterministische Lösungen verwendet werden. Im nächsten Abschnitt wird nun der allgemeine Aufbau eines Echtzeitbetriebssystem besprochen. 3. AUFBAU EINES ECHTZEITBETRIEBS- SYSTEMS Die grundlegenden Funktionen, die ein Echtzeitbetriebssystem liefern sollte, sind Prozess-Scheduling, Interruptverwaltung und Prozesskommunikation. Ein Kernel ist der kleinste Bestandteil eines Betriebssystems, der diese Funktionen zur Verfügung stellt. Bei eingebetteten Systemen kann dieses schon das komplette Echtzeitbetriebssystem repräsentieren, während hingegen bei einem kommerziellen Echtzeitbetriebssystem dieses nur ein kleiner Bestandteil ist. Oft reicht für kleinere Echtzeitsysteme ein einfaches Polled Loop- System aus, welches in einer Schleife immer wieder überprüft, ob ein Ereignis eingetreten ist. Dieses System arbei- 4

13 Einführung in Echtzeitbetriebssysteme tet gut auf einem einzelnen Prozessor, der nur einzelne I/O- Operationen für ein Gerät verarbeiten muss und das Überlappen von Ereignissen im System nicht vorkommt. Eine andere Möglichkeit ist ein Round-Robin-System, welches jedem Prozess eine feste Zeit zuordnet. In diesen System werden Prozesse so lange ausgeführt, bis ein Interrupt kommt oder sie fertig sind. Diese Arten von Kernels haben für kleinere Echtzeitsysteme den Vorteil, dass sie einfach zu implementieren sind und kommerzielle Echtzeitbetriebssysteme für diese Einsätze zu komplex wären. Eine genauere Übersicht über die Strategien für die Entwicklung eines Kernels kann in Laplante [13] nachgelesen werden. Funktionen er im Mikro-Kernel haben möchte und welche nicht. Die Abbildung 3 zeigt die grundlegenden Funktionen, die die meisten Kernel zur Verfügung stellen. Die wichtigste Kategorie ist hierbei die Prozessverwaltung, weil diese den Scheduler enthält. Mit Hilfe des Schedulers kann entschieden werden, welcher Prozess den Prozessor benutzen darf und welche Priorität dieser haben soll. Eine Übersicht über Algorithmen, die für den Echtzeitbetrieb geeignet sind, werden im nächsten Abschnitt beschrieben. Eine weitere Kate- Bei heutigen kommerziellen Echtzeitbetriebssystemen wird sehr häufig eine Mikro-Kernel Architektur verwendet, weil diese aufgrund ihrer Eigenschaften besonders für Echtzeitbetriebssysteme geeignet ist. Ein Mikro-Kernel enthält, im Gegensatz zum etwas schnelleren monolithischen Kernel, nur die wichtigsten Funktionen. Bei einem Entwurf eines Mikro- Kernels werden nur die wichtigsten Funktionen im Kernel- Modus laufen gelassen und alles andere im User-Modus betrieben. Der Mikro-Kernel erlaubt den anderen Komponenten des Betriebssystems also keinen direkten Zugriff, sondern kommuniziert mit diesen über Nachrichten. Die Architektur kann beispielhaft in Abbildung 2 betrachtet werden. Durch diese Architektur wird ein hohes Maß an Sicherheit Abbildung 3: Basis-Funktionen eines Kernels nach Kalinsky [9] (a) Mikro-Kernel (b) Monolithischer- Kernel Abbildung 2: Vergleich der Architekturen zweier Kernels und Stabilität gewährleistet. Die Stabilität resultiert daher, dass viel weniger Code im Kernel-Modus läuft. Der Mikro- Kernel kann insbesondere Fehlfunktionen in Komponenten, die im User-Modus laufen, erkennen, abfangen und die betroffene Komponente neu starten. Ein Fehler in einem Treiber hat somit also nicht mehr zwangsläufig einen Neustart des gesamten Systems zur Folge. Ein weiterer Vorteil ist die leichte Portierbarkeit auf andere Plattformen, weil der Mikro-Kernel relativ klein gehalten ist. Ein monolithischer Kernel wird hingegen in vielen herkömmlichen Betriebssystemen verwendet und erlaubt allen Betriebssystemkomponenten mit gleicher Berechtigung zu arbeiten. Hieraus resultiert auch ein Nachteil vom Mikro-Kernel, weil viel mehr Wechsel vom User- in den Kernel-Modus notwendig sind, um bestimmte Operationen auszuführen. Deswegen ist der Mikro-Kernel auch etwas langsamer als ein monolithischer Kernel. Welche Funktionen von einem Mikro-Kernel unterstützt werden, hängt immer vom Anwender ab. In kommerziellen Echtzeitbetriebssystemen ist der Mikro-Kernel skalierbar und der Entwickler kann selber entscheiden, welche gorie ist die Prozesskommunikation, mit Hilfe derer Prozesse untereinander sicher kommunizieren können und außerdem fällt unter diese Kategorie auch noch die Synchronisation von Prozessen. Unter die Kategorie Timer fallen Funktionen, die Verzögerungen und time outs von Prozessen erlauben. Bei Echtzeitbetriebssystemen gibt es wesentlich mehr Funktionen, die das Arbeiten mit der Zeit ermöglichen, da diese der wichtigste Bestandteil eines Echtzeitsystems sind. Mit Hilfe der Speicherverwaltung wird der Hauptspeicher verwaltet, wenn Prozesse diesen zur Ausführung benötigen. Die letzte der fünf Kategorien ist in der Abbildung mit Interrupt bezeichnet und ermöglicht die Organisation und den Zugriff auf die Hardware. Mit Hilfe von Interrupts können in Echtzeitbetriebssystemen außerdem schnell Fehler erkannt werden und möglicherweise behoben bzw. toleriert werden. Zu diesen grundlegenden Funktionen gibt es noch weitere Services, die von manchen Echtzeitbetriebssystemen unterstützt werden, wie z. B. Dateisystemverwaltung, Netzwerkkommunikation und Datenbankverwaltung, welche aber in dieser Arbeit nicht genauer erläutert werden. Der Umfang eines Echtzeitbetriebssystem hängt immer vom Anwendungsgebiet ab. Deswegen sollte ein Echtzeitbetriebssystem auch nur die Funktionen unterstützen, die im konkreten Anwendungsfall benötigt werden. Viele Echtzeitbetriebssysteme bieten deshalb die Möglichkeit auszuwählen, welche Komponenten benötigt werden, wodurch das System klein gehalten werden kann. Wie ein passendes Echtzeitbetriebssystem ausgewählt werden kann und welche Echtzeitbetriebssysteme es auf dem Markt gibt, wird in Abschnitt 5 besprochen. Als nächstes werden nun die Elemente der Abbildung 3 näher erläutert. 5

14 Christoffer Menk 4. ELEMENTE EINES ECHTZEIT- BETRIEBSSYSTEMS In diesem Abschnitt werden nun die im vorherigen Abschnitt vorgestellten Elemente eines Echtzeitbetriebssystems, die in Abbildung 3 dargestellt sind, genauer betrachtet. Diese Elemente müssen, wie schon vorher angesprochen, nicht in jedem Echtzeitbetriebssystem enthalten sein, gehören aber zu den fundamentalen Funktionen, die die meisten Echtzeitbetriebssysteme unterstützen. 4.1 Prozessverwaltung Kategorien für Echtzeit-Scheduling Algorithmen Grundsätzlich existieren neben den Rechenprozessen der Applikation auch die Prozesse des Systems. Zum sicheren Ablauf sollten die Prozesse des Systems eine höhere Priorität besitzen. Um die Rechenzeit möglichst effizient aufzuteilen, sind bestimmte Strategien notwendig. Die Entscheidung welchem Rechenprozess zu welcher Zeit eine Ressource zugeteilt wird, nennt man Scheduling. Ein Überblick über die Kategorien von Echtzeit-Scheduling Algorithmen, die in diesem Abschnitt betrachtet werden, wird in Abbildung 4 dargestellt. sollten hier Algorithmen verwendet werden, die garantieren, dass bestimmte Prozesse ihre deadline einhalten. Das Echtzeitbetriebssystem muss also insbesondere vorausschauend planen und immer vom schlimmsten Fall ausgehen. Wie in Abbildung 4 zu sehen, gibt es für harte Echtzeitsysteme zwei Kategorien von Algorithmen. Dynamic und Static: Ein Scheduler wird als dynamisch bezeichnet, wenn er zur Laufzeit entscheidet, welcher Prozess als nächstes an der Reihe ist. Statische Scheduler hingegen treffen ihre Entscheidung schon während des Kompilierens. Sie erstellen eine sogenannte dispatching table offline, die dann zur Laufzeit vom dispatcher abgearbeitet wird. Der Vorteil von statischen Algorithmen ist, dass das Verhalten des Systems schon vor dem Start genau geplant ist. Ein Nachteil ist jedoch, dass das System nicht flexibel auf Änderungen in der Umgebung reagieren kann. Hier liegt der Vorteil von dynamischen Algorithmen, die jederzeit auf ihre Umgebung reagieren können, jedoch ist der Nachteil, dass diese wiederum nicht komplett vorhersagbar sind. Dynamische und statische Algorithmen können weiterhin noch präemptiv oder nicht präemptiv sein. Preemptive und Nonpreemptive: Bei präemptiven Algorithmen kann der ausführende Prozess zu jeder Zeit unterbrochen werden, wenn ein Prozess, der ein wichtigeres Anliegen hat, eine Ressource benutzen will. Das Gegenteil hierzu sind nicht präemptive Algorithmen. Ein Prozess wird nur beendet, wenn er mit seiner Ausführung fertig ist oder selber entscheidet, dass er die benutzten Ressourcen freigibt. Nicht präemptive Algorithmen stehen im Gegensatz zu schnellen Reaktionszeiten, die von den meisten Echtzeitsystemen gefordert wird. Daher werden sie nur für Szenarien eingesetzt, in denen viele Prozesse mit einer Ausführungszeit, die im Vergleich zur Zeit für einen Prozesswechsel klein ist, auftreten. Welcher Scheduling-Algorithmus eingesetzt wird, hängt also insbesondere immer vom Echtzeitsystem und von den Prozessen, die in diesem System vorkommen, ab. Nachfolgend werden nun einige Beispiele bekannter Algorithmen gegeben. Abbildung 4: Kategorien von Echtzeit-Scheduling Algorithmen nach Koeptz [11] Soft und Hard: Eine erste Unterteilung für die Algorithmen wird für harte und weiche Echtzeitsysteme vorgenommen. Bei weichen Echtzeitsystemen ist es tolerierbar, wenn ein Prozess seine deadline verpassen sollte, deswegen werden für diese Systeme oft Best-Effort-Algorithmen verwendet. Hierbei bekommt jeder Prozess ein bestimmtes Zeitfenster, in der er die CPU benutzen darf. Bei dieser Art von Algorithmen kann es daher passieren, dass Prozesse abgebrochen werden, wenn sie ihr Zeitfenster überschreiten und noch nicht mit ihrer Ausführung fertig sind. Der Vorteil dieser Algorithmen ist, dass im Mittel mehr Prozesse korrekt ausgeführt werden, als bei Algorithmen, die die Zeit für einen Prozess berechnen. Der Nachteil ist, dass sie nicht für harte Echtzeitsysteme geeignet sind, weil sie insbesondere nicht vorhersagbar sind und nicht garantieren, dass ein Prozess seine deadline einhält. Harte Echtzeitsysteme hingegen müssen ein vorhersagbares Verhalten haben. Deswegen Beispiele Rate Monotonic: Dieser Algorithmus ist dynamisch präemptiv und vergibt an die Prozesse feste Prioritäten. Je kürzer die Periode eines Prozesses ist, desto höher ist die Priorität. Die Prozesse müssen aber periodisch und unabhängig voneinander sein. Earliest Deadline First: Dieser Algorithmus ist dynamisch präemptiv. Den Prozessen werden dynamische Prioritäten zugeordnet, wobei der Prozess mit der am nächsten liegenden deadline die höchste Priorität bekommt. Least Laxity First: Dieses Verfahren ist ähnlich zu Earliest Deadline First, jedoch wird bei der Festlegung der Priorität nicht nur die deadline, sonder auch die Rechenzeit betrachtet. Unter Laxity kann die Zeit verstanden werden, die einem Prozess bis zur nächsten deadline übrig bleiben würde, wenn dieser ab jetzt den Prozessor komplett benutzen dürfte. Der Prozess mit der geringsten Laxity bekommt dementsprechend die höchste Priorität. 6

15 Einführung in Echtzeitbetriebssysteme Server: Mit Hilfe von Servern können sowohl periodische als auch aperiodische Prozesse verwaltet werden. Hierbei wird ein bestimmter periodischer Prozess dazu benutzt, um die aperiodischen Prozesse abzuarbeiten. Weiterhin schützt ein Server die Ressourcen, die von harten Prozessen benutzt werden, und erlaubt weichen Prozessen so schnell wie möglich zu laufen. Unter diese Kategorie fallen u. a. die Fixed Priority Server und Dynamic Priority Server. ist, weil es die gleiche Zeit für kurze oder lange Nachrichten benötigt. Deswegen versehen viele Echtzeitbetriebssysteme diese Nachrichten noch mit speziellen Informationen, die wichtig für den Empfänger sein könnten. Diese beiden Priority Ceiling Protocols: Mit Hilfe dieser Protokolle können periodische Prozesse verwaltet werden, die gemeinsam auf Ressourcen zugreifen müssen. Genauere Informationen zu diesen und anderen Algorithmen können u. a. in Kopetz [11] und Laplante [13] bekommen werden. 4.2 Prozesskommunikation Die Kommunikation zwischen Prozessen ist in Echtzeitbetriebssystemen von wichtiger Bedeutung, insbesondere wenn diese die Mikro-Kernel Architektur verwenden. Für die Kommunikation zwischen Prozessen gibt es zwei Varianten, die in Echtzeitbetriebssystemen benutzt werden, einerseits die Kommunikation über gemeinsamen Speicher (Shared Memory) und andererseits mittels Nachrichtenübertragung (Message Passing). Shared Memory: Echtzeitsysteme bieten im Allgemeinen eine sehr einfache Kommunikation über gemeinsamen benutzten Speicher, weil die Rechenprozesse und das Betriebssystem im gleichen linear adressierbaren Speicher betrieben werden. Dieses wird auch als flat memory model bezeichnet. Dieses Modell steht im Gegensatz zu herkömmlichen Betriebssystemen, weil hier lokaler Speicher für die Prozesse benutzt wird, auf den andere Prozesse nicht zugreifen können. Für ein Echtzeitbetriebssystem sind aber vor allem schnelle Kommunikation und wenig Overhead entscheidend, deswegen trifft man hier oft auf diesen Ansatz. Der Vorteil der schnellen Kommunikation geht aber zu Lasten der Sicherheit und Stabilität, denn die Applikationen müssen darauf achten, dass der gemeinsame Speicher korrekt benutzt wird. Message Passing: Die verschiedenen Möglichkeiten, die es bei der Nachrichtenübertragung gibt, können in Abbildung 5 betrachtet werden. Bei indirekter Nachrichtenübertragung werden Message Queues benutzt, um die Nachrichten zu speichern, denn die Nachrichten werden nicht direkt von Prozess zu Prozess geschickt. Diese Technik wird oft benutzt, weil sie sehr einfach für die Kommunikation zwischen zwei Prozessen benutzt werden kann, indem für je zwei Prozesse eine eigene Message Queue eingerichtet wird. Viele Echtzeitbetriebssysteme kopieren hierbei die Nachricht in eine versteckte Region des Speichers, damit die Nachrichten, während sie in der Message Queue liegen, nicht verändert oder gelesen werden können. Sie werden dann erst bei Abholung aus diesem verstecktem Speicherbereich heraus kopiert, wodurch Sicherheit und Stabilität gewährleistet werden. Bei diesem Verfahren muss aber beachtet werden, dass es sehr aufwendig ist. Eine andere Möglichkeit ist die direkte Nachrichtenübertragung. Hierbei wird die Nachricht direkt von Prozess zu Prozess gesendet. Es oft nur Pointer übergeben, wodurch diese Art der Kommunikation sehr effizient Abbildung 5: Kategorien der Nachrichtenübertragung Verfahren können jetzt asynchron oder synchron ablaufen. Bei synchroner Nachrichtenübertragung, muss der Sender so lange warten, bis der Empfänger seine Nachricht erhalten hat. Bei asynchroner Übertragung muss hingegen der Sender nicht warten, wodurch aber auch nicht kontrolliert werden kann, ob der Empfänger jemals seine Nachricht erhalten hat. Bei direkter Übertragung wird die Nachricht eigentlich direkt dem Empfänger übergeben. Wenn dieses aber nun asynchron geschieht, so wird automatisch durch das Echtzeitbetriebssystem eine Message Queue erzeugt. Diese automatische Erzeugung erfolgt aber nur bei Echtzeitbetriebssystemen die asynchrone direkte Nachrichtenübertragung nutzen. Es kann also nur bei direkter synchroner Nachrichtenübertragung wirklich auf Message Queues verzichtet werden. Mit Hilfe dieser Techniken werden in Echtzeitbetriebssystemen aber nicht nur Nachrichten übertragen, sondern auch Prozesse synchronisiert. Dieses liegt daran, dass Semaphoren für komplexere Systeme oft nicht mehr ausreichend sind, wenn sie z. B. aus mehreren Prozessoren bestehen. Weiterhin können die Mechanismen auch genutzt werden um beispielsweise einen Prozess über ein bestimmtes Ereignis zu benachrichtigen. 4.3 Speicherverwaltung Ein zentrales Element eines Echtzeitbetriebssystems ist die Speicherverwaltung. Im Abschnitt 2 wurde schon erwähnt, dass die herkömmlichen Techniken der Speicherverwaltung, wie Swapping oder Speicherverwaltung mit einem Heap für ein Echtzeitbetriebssystem weniger geeignet sind. Einerseits weil oft nur wenig Speicher zur Verfügung steht und andererseits der geforderte Determinismus z. B. durch einen herkömmlichen Garbage Collector verloren geht. Echtzeitbetriebssysteme unterstützen deswegen Techniken, die die Echtzeit-Anforderungen erfüllen, oder einen Garbage Collector benutzen, der feste Antwortzeiten hat. Es werden nun die verschiedenen Verfahren, die Echtzeitbetriebssysteme nutzen, vorgestellt und deren Vor- und Nachteile erläutert. Fixed Partitioning: Der Speicher wird vom Echtzeitbetriebssystem in feste Partitionen zerlegt. Ein Programm wird dann in eine Partition geladen, die gleich oder größer als das Programm ist. Der Vorteil ist, dass diese Methode leicht zu 7

16 Christoffer Menk implementieren ist und das Echtzeitbetriebssystem nur wenig Aufwand betreiben muss. Der Nachteil ist, dass der Speicher nicht optimal genutzt wird und die Zahl der Prozesse, die den Speicher benutzen, begrenzt ist. Diese Technik ist auch in Abbildung 6 dargestellt. (Quelle: Kalins- Abbildung 6: Fixed Partitioning ky [9]) Dynamic Partitioning: Bei dieser Technik werden die Partitionen dynamisch erzeugt, so dass jeder Prozess in eine Partition geladen wird, die die gleiche Größe, wie der Prozess selbst hat. Der Vorteil hierbei ist, dass der Speicher optimal ausgenutzt wird, jedoch muss für dieses Verfahren viel Aufwand betrieben werden, damit keine External Memory Fragmentation auftritt. Simple Paging: Der Speicher wird in gleich große Partitionen unterteilt. Weiterhin wird auch jeder Prozess so aufgeteilt, dass er diese Partitionen benutzen kann. Beim Laden eines Prozess werden dann einfach alle benötigten Elemente in den Speicher geladen, wobei diese nicht zusammenhängend gespeichert werden müssen. Der Vorteil ist, dass keine External Memory Fragmentation auftreten kann. Der Nachteil ist, dass es immer ein wenig Speicher gibt, der nicht genutzt wird, weil es Teile von Programmen gibt, die nicht der Größe der Partition entsprechen. Virtual Memory Paging: Die Technik ist ähnlich zu Simple Paging jedoch werden nur die gerade benötigten Teile eines Prozesses geladen. Bei diesem Verfahren kann keine External Memory Fragmentation auftreten und es existiert ein großer virtueller Speicherraum. Der Nachteil ist gleich zum Simple Paging und weiterhin erfordert dieses Verfahren wesentlich mehr Aufwand. Simple Segmentation: Jeder Prozess wird in Segmente aufgeteilt, die dann in dynamische Partitionen geladen werden. Der Vorteil ist, dass der Speicher optimal genutzt wird. Jedoch entsteht zusätzlicher Aufwand, weil die Größe der einzelnen Segmente überprüft werden muss. Weiterhin kann es auch wieder zu External Memory Fragmentation kommen. Virtual Memory Segmentation: Die Technik ist ähnlich zu Simple Segmentation jedoch werden nur die gerade benötigten Segmente eines Prozesses geladen. Der Nachteil ist hierbei der hohe Aufwand, den diese Verfahren benötigt, und dass es zu External Memory Fragmentation kommen kann. Der Vorteil ist, dass der Speicher optimal genutzt wird und ein großer virtueller Speicherraum existiert. Welches dieser Verfahren benutzt wird, hängt auch hier vom zu betreibenden Echtzeitsystem ab. Systeme, bei denen die Anzahl der Prozesse fest ist, werden Fixed Partitioning oder Simple Paging benutzen. Während hingegen bei größeren Systemen, bei denen die Anzahl der Prozesse nicht immer bekannt ist, genügend Speicher zur Verfügung gestellt werden muss und daher Virtual Memory Paging oder Virtual Memory Segmentation benutzt wird. 4.4 Timer In vielen Echtzeitsystemen ist ein Großteil der Prozesse zeitgesteuert. Die Prozesse werden entweder zu a priori bekannten oder dynamisch berechneten Zeiten gestartet. Weiterhin hängt bei einem Echtzeitsystem die korrekte Funktionsweise im wesentlichen von der Zeit ab. Ein Echtzeitbetriebssystem muss also flexible Sprachmittel für die Zeit bieten, die die Zeitgeber in die Anwendung einbinden oder den Ablauf zeitlich steuern. Ein wichtige Eigenschaft, die in verteilten Echtzeitsystemen oft gefordert wird, ist die Synchronisation der Uhren. Wenn dieser Service nicht vom System selber zur Verfügung gestellt wird, muss das Echtzeitbetriebssystem für die korrekte Funktionsweise sorgen. Die Präzision der Uhrensynchronisation kann nämlich durch das Betriebssystem wesentlich besser gesteuert werden, als durch Applikationen, weil das Betriebssystem direkt auf die entsprechenden Ressourcen zugreifen kann. Nach Kopetz [11] sollte ein Echtzeitbetriebssystem die folgenden Services für die Zeit bieten 1. Die statische oder dynamische Spezifikation einer unendlichen Sequenz von Events zu bestimmten Zeitpunkten, die mit einer bestimmten Periode auftreten. 2. Die Spezifikation eines Zeitpunktes in der Zukunft in einer bestimmten zeitlichen Distanz. 3. Das Versehen eines Events mit einem Zeitstempel, kurz nachdem es aufgetreten ist. 4. Die Ausgabe einer Nachricht zu einem präzise festgelegtem Zeitpunkt in der Zukunft, der relativ oder absolut angegeben werden kann. 5. Ein Funktion, die die International Atomic Time in eine Uhrzeit umwandelt und umgekehrt. Diese Services werden unter anderem benötigt, um Prozesse zu einem bestimmten Zeitpunkt zu starten oder um time outs zu definieren. Diese eben genannten Services gehören zu den grundlegenden Funktionen und werden im Allgemeinen von den Echtzeitbetriebssystemen unterstützt. 4.5 Interrupts Es kann zwischen zwei Klassen von Interrupts unterschieden werden, einerseits die asynchronen Interrupts, die durch externe Ereignisse ausgelöst werden und andererseits synchrone Interrupts, die Folge einer Befehlsausführung sind. Bei 8

17 Einführung in Echtzeitbetriebssysteme der Behandlung von Interrupts durch das Echtzeitbetriebssystem muss darauf geachtet werden, dass die Reaktionszeiten des Systems erhalten bleiben, denn Interrupts haben grundsätzlich eine höhere Priorität als andere Prozesse und laufen in einem anderen Kontext als Prozesse. Asynchrone Interrupts: Zu den asynchronen Interrupts zählen einerseits die Maschinenfehler, die durch Paritätsfehler oder einer Spannungsausfallmeldung ausgelöst werden können. Anderseits können sie auch durch I/O-Operationen ausgelöst werden, wie den Abschluss einer Lese- oder Schreiboperation, der Ankunft von Daten oder dem Ablauf eines Timers. Segmented Interrupt Architecture: Bei diesem Ansatz werden Interrupts nicht komplett ausgeschaltet, sondern es werden keine asynchronen Zugriffe auf kritische Daten von einer ISR oder einem anderen Systemaufruf erlaubt. Der Zugriff auf kritische Daten wird von einer zweiten ISR behandelt, die zusammen mit den anderen Prozesse vom Scheduler verwaltet wird. Dieser Ansatz ist in Abbildung 8 dargestellt. Bei diesem Ansatz können die Interrupts entweder sequentiell oder mit Hilfe von Prioritäten abgearbeitet werden. Synchrone Interrupts: Zu den synchronen Interrupts gehören einmal die Ausnahmen (Exceptions) und anderseits die Softwareinterrupts. Exceptions werden unter anderem durch eine Division durch 0 oder einen Arithmetiküberlauf ausgelöst. Softwareinterrupts werden z. B. durch Systemaufrufe ausgelöst. Wenn ein Interrupt ausgelöst wurde, wird dieser von einer Interrupt Service Routine (ISR) behandelt. Eine ISR muss hierbei einerseits die Hardware Konditionen berücksichtigen und außerdem dafür Sorge tragen, dass die entsprechende Daten gesendet oder empfangen werden, die zur Behandlung des Interrupts notwendig sind. Die ISR muss also insbesondere das Echtzeitbetriebssystem mit den notwendigen Informationen versorgen, damit die Applikationen korrekt ausgeführt werden können. Weil eine ISR die Ausführung eines Prozesses unterbricht, wird versucht, den Code, der in einer ISR ausgeführt wird, möglichst klein zu halten. Deswegen wird oft nur die notwendigsten Funktionen in einer ISR behandelt und weitere Arbeit auf Prozesse aufgeteilt, die dann vom Scheduler verwaltet werden. Die Zeit, die zum Bearbeiten eines Interrupts notwendig ist, wird als Interrupt-Latenzzeit bezeichnet und ist von Echtzeitbetriebssystem zu Echtzeitbetriebssystem verschieden. Ein Echtzeitbetriebssystem muss insbesondere dafür sorgen, dass mehrere ISR nicht die gleichen Daten zur selben Zeit modifizieren. Hierzu gibt es zwei Ansätze, die im folgenden einmal vorgestellt werden, die Unified Interrupt Architecture und die Segmented Interrupt Architecture. Unified Interrupt Architecture: Der Ansatz dieser Architektur kann in Abbildung 7 betrachtet werden. Bei diesem Ansatz werden alle Interrupts ausgeschaltet, während eine ISR oder das System kritische Daten innerhalb des Echtzeitbetriebssystem modifiziert. Hierdurch wird komplett verhindert, dass irgendein Prozess unkoordinierte Änderungen in einer kritischen Sektion vornimmt. Interrupts werden in diesem Ansatz rein sequentiell abgearbeitet. Abbildung 7: Unified Interrupt Architecture nach Lamie [12] Abbildung 8: Segmented Interrupt Architecture nach Lamie [12] Beide Ansätze erlauben eine deterministische Behandlung von Interrupts in einem Echtzeitbetriebssystem, jedoch gibt es Unterschiede in der Effizienz und der Einfachheit. Segmented Interrupt Architectures schalten zwar nie Interrupts ab, jedoch wird durch die Verlagerung des Codes in eine zweite ISR, die Ausführungszeit anderer Prozesse verschlechtert. Weil durch diesen Ansatz wesentlich mehr Prozesse entstehen, die durch den Scheduler verwaltet werden müssen, wird auch mehr Zeit für den Prozesswechsel verbraucht. Eine Unified Interrupt Architecture ist hingegen wesentlich einfacher zu bedienen. Ein kleiner Nachteil ist zwar, dass Interrupts für kurze Zeit ausgeschaltet werden, jedoch ist diese Zeit sehr klein und es müssen keine Prioritäten oder Zeitbedingungen für Interrupts beachtet werden. Weil die Interrupt-Latenzzeiten für viele Echtzeitsysteme aber trotzdem noch zu lang sein können, erlauben einige Echtzeitbetriebssysteme, dass die systemeigenen Interrupts ausgeschaltet werden, um diese dann direkt über die Hardware zu erledigen. 5. BEISPIELE VON BEKANNTEN ECHT- ZEITBETRIEBSSYSTEMEN 5.1 Einteilung der Echtzeitbetriebssysteme Echtzeitbetriebssysteme können in folgende drei Kategorien eingeteilt werden. Kommerzielle Echtzeitbetriebssystem(kern)e: Echtzeitbetriebssystemkerne sind von kleinem Umfang und unterstützen nur die elementaren Funktionen. Sie sind für die Minimierung von Kontextwechselzeiten und schnelle Interruptverwaltung optimiert. Kommerzielle Echtzeitbetriebssysteme bieten im Gegensatz dazu weitere Unterstützung für Dateisysteme, Netzwerke, etc. Außerdem werden noch eine Reihe von Entwicklungswerkzeugen zur Verfügung gestellt. Zu dieser Kategorie gehören unter anderem VxWorks [20] und QNX [15]. 9

18 Christoffer Menk Systeme aus der Forschung: Echtzeitbetriebssysteme in dieser Kategorie kommen, wie der Name schon sagt, aus der Forschung. Beispiele hierfür sind RTOS-UH [16] welches an der Universität Hannover entwickelt wurde. Herkömmliche Betriebssysteme mit Echtzeiterweiterungen: Zu dieser Kategorie werden alle Erweiterungen zu bekannten Betriebssystemen, wie Linux oder Windows gezählt. Die Erweiterungen ermöglichen den Betrieb von Programmen in Echtzeit. Bei diesen Systemen ist aber zu beachten, dass das vorhandene Betriebssystem, welches nicht deterministisch ist, als Grundlage verwendet wird und daher können diese Erweiterungen oft nur für weiche Echtzeitsysteme verwendet werden. Das eigentliche Betriebssystem wird hierbei oft als eigenständiger Prozess mit niedriger Priorität betrieben. Beispiele hierfür sind INTime [18] oder RT- Linux [6]. 5.2 Marktübersicht Wenn der Markt der Server und Workstations betrachtet wird, so kann gesagt werden, dass entweder Produkte aus der Windows Familie oder UNIX-Derivate benutzt werden. Der Markt bei Echtzeitbetriebssystemen hingegen ist unter vielen Herstellern aufgeteilt. Die Zeitung Real-Time Magazine [19] hat eine Umfrage durchgeführt, bei der die Leser befragt wurden, welches Echtzeitbetriebssystem sie verwenden. Das Ergebnis dieser Umfrage kann in Abbildung 9 betrachtet werden. Hierbei ist zu beachten, dass diese Umfrage zwar Abbildung 9: Marktanteil der Echtzeitbetriebssysteme (Quelle: Real-Time Magazine [19]) nicht repräsentativ ist, weil nur die Leser des Real-Time Magazines befragt wurden, jedoch zeigt sie, dass der Markt zersplittert ist. Immerhin gaben 33% der Befragten an, ein Echtzeitbetriebssystem zu nutzen, welches weniger als 1% Marktanteil hat. Außerdem benutzen 6% der Befragten Leser ein Betriebssystem, welches sie selber geschrieben haben. Welches Echtzeitbetriebssystem sich in Zukunft durchsetzen wird, dafür gab es diverse Antworten. Viele der Befragten gaben an, dass sich Windows NT in der nächsten Zukunft als Echtzeitbetriebssystem durchsetzen wird. Jedoch bietet Windows NT nur einige Echtzeit-Eigenschaften und weiterhin ist es ursprünglich nicht für Echtzeit-Anwendungen entwickelt worden. Gerade bei eingebetteten Systemen, die nur wenig Ressourcen besitzen, ist Windows NT ungeeignet. Microsoft versucht hier aber den Markt mit Windows CE zu bedienen, welches speziell für Echtzeit entwickelt wurde. Andere Firmen versuchen Windows NT so zu erweitern, dass es den Echtzeit Anforderungen genügt, ein Beispiel hierfür ist INTIME. Hierbei stellt INTIME ein eigenständiges Betriebssystem dar, welches Windows NT als Prozess mit niedriger Priorität laufen lässt. So können Programme, die keine Echtzeit Anforderungen erfüllen müssen, als Windows Programm laufen und Programme mit Echtzeit- Anforderungen, werden als eigenständiger Prozess gestartet. Ein ähnliches Konzept wird von RT-Linux verwendet, welches Linux als Prozess mit niedriger Priorität ausführt. Die Prozesse werden bei RT-Linux von einem zu Linux unabhängigen Kernel verwaltet. Mit Hilfe dieser Architektur gewinnt eine Echtzeit-Anwendung zwar volle Kontrolle über das System, jedoch kann sie auch nur beschränkt Linux Systemaufrufe ausnutzen. Andere Echtzeitbetriebssysteme wie z. B. VxWorks setzen hierbei auf die in Abschnitt 3 vorgestellte Micro-Kernel Architektur. VxWorks wird in vielen Echtzeitsystemen eingesetzt und gehört mit 14% zu dem am meisten genutzten Echtzeitbetriebssystem. Welches Echtzeitbetriebssystem sich also in Zukunft durchsetzen wird, ist fraglich. Immerhin sind die Anforderungen zwischen den Echtzeitsystemen äußerst unterschiedlich. Ein Server, der kontinuierlich einen Video-Stream liefert, muss ganz andere Bedingungen erfüllen, als ein Computer, der die Steuerung für ein Flugzeug betreibt. Welches Echtzeitbetriebssystem eingesetzt wird, hängt immer vom konkreten Anwendungsfall ab. Im nächsten Abschnitt werden einige Kriterien gegeben, die bei der Auswahl eines entsprechenden Echtzeitbetriebssystems helfen. 5.3 Kriterien zur Auswahl eines Echtzeitbetriebssystems Welches Echtzeitbetriebssystem im konkreten Anwendungsfall benutzt werden kann, hängt immer vom vorhandenen Echtzeitsystem ab. Bei kleineren Systemen reicht der Speicher für ein kommerzielles Echtzeitbetriebssystem oft nicht aus. Viele kommerzielle Echtzeitbetriebssysteme sind daher für eingebettete Systeme zu groß und haben oft zu hohe Antwortzeiten und Features. Ein kleines System lässt sich oft einfacher mit einem eigenen Kernel betreiben. Ein Nachteil bei der Entwicklung eines eigenen Kernels ist, dass sich Fehler einschleichen können, die bei kommerziellen Echtzeitbetriebssystemen nicht vorkommen würden, weil diese ausführlicher getestet wurden. Bei der Auswahl eines Herstellers sollte also auch darauf geachtet werden, wie viel Erfahrung dieser bei der Entwicklung seines Produktes hat. Bei einem Echtzeitsystem sollte das Verhalten und die Reaktionszeiten der einzelnen Anwendungen bekannt sein, beziehungsweise gegen eine obere Schranke abgeschätzt werden können. Es sollte deswegen bei bekannten Echtzeitbetriebssystemen auf die Spezifikationen, wie z. B. die Reaktionszeit, geachtet werden, ob diese auch dem Echtzeitsystem genügen. Ein wichtiger Faktor ist auch die eingesetzte Hardware, von der im Wesentlichen auch die Reaktionszeiten abhängen. Ein ausgewähltes Echtzeitbetriebssystem sollte mit der eingesetzten Hardware also möglichst schon ausgiebig getestet sein. Ein nicht unerheblicher Faktor sind die Kosten, denn oftmals kann es billiger sein, ein Echtzeitbetriebssystem selber zu entwickeln, als eines käuflich zu erwerben. Es sollte also genau überlegt werden, ob die kompletten Funktionen eines Echtzeitbetriebssystems wirklich benötigt werden, oder ob nicht ein eigenes bzw. frei erhältliches Echtzeitbetriebssystem ausreicht. Ein weiterer Faktor sind die 10

19 Einführung in Echtzeitbetriebssysteme Produkt oscan LynxOS OS/9 psos QNX VxWorks Hersteller Vector Lynx Microware ARS Integrated QNX Software WindRiver Informatik Works Inc. Systems Systems LTD Zielsystem C16x, 680x0, 680x0, 680x0, i386, 680x0, PowerPC, C16x, 80x86, 80x86, i486, 80x86, Tricore, PowerPC, PowerPC, C16x, 80286, PowerPC, ARM7, 88000, CPU32, PowerPC, Pentium CPU32, M16C, i860, CPU32, i960, M32C, MIPS, i960, MIPS, ST10 SPARC, Hitachi SH, SPARC, RS6000 MIPS AMD29k Hostsystem UNIX, UNIX, UNIX, UNIX, QNX UNIX, Windows Windows Windows Windows OS/2 Dateisystem UNIX, FAT UNIX, UNIX, UNIX, FAT, FAT, FAT, FAT NFS, NFS, ISO9660 RTFS RTFS Netzwerk TCP/IP, TCP/IP, TCP/IP, TCP/IP, TCP/IP, NFS OS/9-net, Netware, NFS, NFS, NeWLink OSI 1-7, SNMP, SNMP, SNMP Streams Streams Feldbus CAN CAN CAN LIN PROFIBUS FlexRay Interbus-S Scheduling präemptiv, präemptiv, präemptiv, präemptiv, präemptiv, präemptiv, kooperativ prioritäts- prioritäts- prioritäts- prioritäts- prioritätsgesteuert, gesteuert, gesteuert, gesteuert, gesteuert, rundenbasiert rundenbasiert rundenbasiert rundenbasiert rundenbasiert Tabelle 1: Eigenschaften kommerzieller Echtzeitbetriebssysteme (Quelle: Göhner [7]) Entwicklungswerkzeuge, die ein Echtzeitbetriebssystem zur Verfügung stellt, und ob spezielle Schulungen für die Mitarbeiter notwendig sind. Um spezielle Schulungen zu vermeiden, orientieren sich viele Echtzeitbetriebssysteme an UNIX und stellen bekannte Entwicklungswerkzeuge von UNIX zu Verfügung. Hierbei kommt es also insbesondere darauf an, wie die Mitarbeiter geschult sind und mit welches Werkzeugen sie sich auskennen. Abschließend werden nun noch einige Vor- und Nachteile genannt, die ein kommerzielles Echtzeitbetriebssystem mit sich bringt. Vorteile kommerzieller Echtzeitbetriebssysteme: Verbesserung der Portabilität Verbesserung der Wartbarkeit und Erweiterbarkeit Erhöhte Zuverlässigkeit Vereinfachte Programmierung auf komplexer Hardware Mögliche Einsparung von Kosten durch kürzere Entwicklungszeiten Nachteile kommerzieller Echtzeitbetriebssysteme: Kosten für die Lizenzierung des Echtzeitbetriebssystems Abhängigkeit vom Hersteller Unbekannter Quellcode (nicht immer einsehbar) Einarbeitungs- und Trainingsaufwand Eine Auswahl einiger kommerzieller Echtzeitbetriebssysteme kann in Tabelle 1 betrachtet werden. 6. SCHLUSSFOLGERUNGEN Heutzutage gibt es viele Arten von Echtzeitbetriebssystemen, die sich vor allem durch den zeitlichen Determinismus von herkömmlichen Betriebssystemen unterscheiden. Eine wichtige Architektur für Echtzeitbetriebssysteme ist der vorgestellte Mikro-Kernel, durch den die Größe eines Systems skaliert werden kann. Weiterhin wird durch diese Architektur die Sicherheit und Stabilität des Systems verbessert. Die einzelnen Kernels der Echtzeitbetriebssysteme unterscheiden sich vor allem im Umfang und in ihren möglichen Einsatzgebieten. Gerade kommerzielle Echtzeitbetriebssysteme bieten weiterhin noch eine Reihe an Entwicklungswerkzeugen, die die Echtzeitbetriebssystemkerne oder Systeme aus der Forschung nicht immer bieten. Der Markt der Echtzeitbetriebssysteme ist auf viele verschiedene Systeme aufgeteilt, welches daran liegt, dass es sehr viele unterschiedliche Echtzeit-Anwendungen gibt, die unterschiedliche Anforderungen haben. Echtzeitbetriebssysteme sollten nur die Funktionen enthalten, die auch im konkreten Anwendungsfall benötigt werden, damit das System übersichtlicher und damit 11

20 Christoffer Menk sicherer wird. Daher gibt es auch kein optimales Echtzeitbetriebssystem, welches für jede Art von Anwendung geeignet ist. Für kleinere Echtzeitsysteme kann es daher sinnvoller sein, ein eigenes Echtzeitbetriebssystem zu entwickeln, welches nur die speziell benötigten Funktionen enthält. Bei größeren Echtzeitsystemen liegt der Vorteil von kommerziellen Echtzeitbetriebssystemen darin, dass diese ausgiebig getestet und über Jahre hinweg entwickelt wurde. Abschließend kann daher auch keine genaue Bewertung von Echtzeitbetriebssystemen vorgenommen werden. Je nach Anwendungsfall muss untersucht werden, ob ein Echtzeitbetriebssystem die benötigten Anforderungen erfüllt und ein kommerzielles Echtzeitbetriebssystem wirklich benötigt wird. 7. LITERATURVERZEICHNIS [1] Barr, M.: Choosing an RTOS. Embedded Systems Programming, Januar [16] RTOS-UH: RTOS-UH. [17] Stalling, W.: Betriebssysteme Prinzipien und Umsetzung. Prentice Hall, [18] tenasys: INTime. [19] Timmerman, M.: RTOS Market Overview A follow up. Real-Time Magazine, [20] WindRiver: VxWorks. [21] Witzak, M. P.: Echtzeitbetriebssysteme. Francis, [2] Bovet, D. P. und M. Cesati: Understanding the Linux Kernel. O Reilly, [3] Burns, A. und A. Wellings: Real-Time Systems and Programming Languages. Pearson Education Limited, [4] Buttazzo, G. C.: Hard Real-Time Computing Systems Predictable Scheduling Algorithms and Applications. Kluwer Academic Publishers, [5] Choi, S.: Dynamic Time-Based Scheduling for Hard Real-Time Systems. Techn. Ber., UM Computer Science Department, [6] FSMLabs: RT-Linux. [7] Göhner, P.: Echtzeitbetriebssysteme, lehrmaterialien/umdruck/kapitel5.pdf. [8] Joseph, M.: Real-time Systems Specification, Verification and Analysis. Prentice Hall, [9] Kalinsky, D.: Basic Concepts of Real-Time Operating Systems, [10] Kernighan, B. W. und D. M. Ritchie: Programmieren in C. Hanser, [11] Kopetz, H.: Real-time systems: design principles for distributed embedded applications. Kluwer, [12] Lamie, W. E.: Pardon the Interruption: Two Approaches to RTOS Interrupt Architectures. I.Q. Magazine, 03(04), [13] Laplante, P. A.: Real-time systems design and analysis: an engineer s handbook. IEEE Press, [14] Liu, J. W. S.: Real-Time Systems. Prentice Hall, [15] QNX Software Systems: QNX. 12

21 VxWorks Aufbau und Programmierung VxWorks - Aufbau und Programmierung Dominik Meyer Christian-Albrechts-Universität zu Kiel Arbeitsgruppe für Echtzeitsysteme und Eingebettete Systeme Kiel, Germany dmey@informatik.uni-kiel.de Zusammenfassung Diese Ausarbeitung befasst sich mit dem Echtzeitbetriebssystem VxWorks der Firma Wind River [2]. Es werden die Basis-Funktionen des Betriebssystems erklärt, die POSIX Kompatibilität beleuchtet und die Unterschiede zwischen den POSIX Implementationen und den Standard-Funktionen dargestellt. Zusätzlich wird noch ein Überblick über die Entwicklungsumgebung Tornado gegeben. 1. EINFÜHRUNG Der Markt der Echtzeitbetriebssysteme ist zwar überschaubar groß, doch bieten die einzelnen Hersteller in Ihren Produkten unterschiedliche Konzepte. Wenn man sich das erste mal mit diesem Thema beschäftigt und für einen bestimmten Anwendungszweck ein Echtzeitbetriebssystem sucht, helfen einem die Produkt-Beschreibungen der Hersteller sehr wenig. Oft werden die Fragen, Wie funktioniert das? oder Welche Unterstützung gibt es für... nicht ausreichend beantwortet. Diese Ausarbeitung setzt sich mit dem Echtzeitbetriebssystem VxWorks auseinander. 1.1 Was ist VxWorks Im Allgemeinen wird mit VxWorks ein Echtzeitbetriebssystem der Firma Wind River [2] bezeichnet. VxWorks ist aber eigentlich ein Toolkit, aus dem sich ein Echtzeitbetriebssystem, nach den eigenen Anforderungen, zusammenstellen lässt. Das Toolkit enthält eine Entwicklungsumgebung für die Desktop-Betriebssysteme Windows, Unix und Linux, sowie einen Betriebssystem-Kern, den WIND Kernel, ein einfaches Ein- und Ausgabe-System und einen vollständigen TCP/IP-Stack. Weitere Module sind von Wind River und anderen Firmen erhältlich und erweitern VxWorks um viele Möglichkeiten. Wie alle modernen Betriebssysteme ist Vx- Works in Schichten aufgebaut (siehe Abbildung 1). Die unterste Schicht bildet dabei die Hardwarenahe- oder Treiber- Schicht. Nur in dieser Schicht interagiert das Betriebssystem direkt mir der Hardware. Diese werde in dieser Ausarbeitung nicht weiter betrachten, da sie nur für System- Programmierer aber nicht für Anwendungsentwickler interessant ist. Die Treiber-Schicht legt fest, auf welchen Prozessor Architekturen das Betriebssystem lauffähig ist. Für Vx- Works sind das ARM, MIPS, PowerPc, SuperH, Intel Pentium und Intel XScale. Über der Treiber-Schicht befindet sich der WIND Kernel, als Herz des Betriebssystems. Bei VxWorks besteht der Kern aus einem Microkernel, der den Abbildung 1: Kernel Struktur Scheduler, die System-Uhr und die Semaphoren-Verwaltung zur Verfügung stellt. Robust definierte Schnittstellen ermöglichen es den übrigen Schichten des Betriebssystems auf die Dienste des Microkernels zuzugreifen. In Abschnitt 2 dieser Ausarbeitung wird der Microkernel etwas genauer betrachtet und die für einen Programmierer wichtigen Funktionen beschrieben. Als Schale um den Microkernel sind weitere wichtige Betriebssystem-Dienste angeordnet (siehe Abbildung 1): 1. Speicher-Management 2. Timer 3. Interrupt-Verwaltung 4. Intertaskkommunikation Auf das Speicher-Management und die Intertaskkommunikation wird in den Abschnitten 3 und 4 eingegangen und ein kurzer Einblick in die Funktionsweisen dieser Dienste gegeben. 13

22 Dominik Meyer Für ein Echtzeitbetriebssystem ist die Abwicklung von Interrupts sehr wichtig, da sporadische Interrupts die Responsivität des Systems beeinträchtigen können. Deshalb wird in Abschnitt 2.4 kurz auf diese eingegangen. Weiter ist in Abbildung 1 zu erkennen, wie die Anwendungsebene von den Systemkomponenten abgekoppelt ist. Innerhalb der Systemebene gibt es zusätzlich zu den um den Kern angeordneten Betriebssystem Diensten, noch weitere, die von Dritt- Anbietern zur Verfügung gestellt werden. Diese stellen Funktionen zur Verfügung, die bei speziellen Anwendungen benötigt werden. Außerdem ist die bereits erwähnte Abkopplung der geräte- und architekturspezifischen Betriebssystem- Komponenten zu erkennen. Dies ermöglicht eine einfache Anpassung von VxWorks auf eine andere Prozessor-Architektur und andere Hardwarekomponenten. Anschnitt 7 befasst sich mit dem Software-Entwurf unter VxWorks. Dabei wird die Entwicklungsumgebung Tornado kurz vorgestellt, die beim Kauf von VxWorks mitgeliefert wird. Zusätzlich werden einige Beispiele zur Programmierung unter VxWorks gezeigt. 2. KERNEL In diesem Abschnitt geht es um den WIND Kernel. Um auf Scheduling und Semaphoren näher eingehen zu können, wird als erstes der Task, die kleinste organisatorische Einheit, von VxWorks eingeführt. 2.1 Task Definition Task: Ein Task ist eine organisatorische Einheit, die aus ausführbaren Programmcode, eigenem Speicher und Variablen besteht und ist gekennzeichnet durch eine Priorität und einen Taskzustand[11] Die Tasks bilden in VxWorks die Einheiten, die vom Scheduler mit Systemressourcen versorgt werden können. Sie sind mit den Prozessen in Desktop-Betriebssystemen zu vergleichen. Sie ähneln in ihrem Aufbau aber mehr den Threads. Ein Task-Kontext besteht aus: 1. den Programmcounter (PC) des Prozessors für diesen Task vor dem letzten Kontext-Wechsel 2. den Inhalt der CPU Register für diesen Task vor dem letzten Task-Wechsel 3. die Speicher-Adresse des Stacks 4. die Festlegung der Ein- und Ausgabegeräte für die standard Ein- und Ausgabe und für die Fehler-Ausgabe 5. einen Verzögerungstimer 6. einen Zähler für die Zeit, die in einem Time-Slice bereits verbraucht ist 7. einige Kernel-Kontrollstrukturen 8. einen Signal-Handler 9. einige Werte zum Debuggen und für Performance-Messungen VxWorks arbeitet, wie die meisten Echtzeitbetriebssysteme, mit einem flat memory model. Das bedeutet, daß alle Tasks in einem großen Speicherbereich laufen. Sie können also auf den Speicherbereich der anderen Tasks zugreifen. Auf diesen Punkt wird im Abschnitt 4 über Intertaskkommunikation noch eingegangen. Genaueres über das Speicher- Management und wie Speicherbereiche geschützt werden können wird in Abschnitt 3 erklärt. Tasks nehmen immer einen eindeutigen Zustand im System an. Dieser ist davon abhängig, ob ein Task gerade Zugriff auf die CPU erhält oder ob er auf den Zugriff auf eine System- Ressource wartet. Folgende Zustände sind in VxWorks vorgesehen: der Task wartet nur auf die CPU (ready) der Task wartet auf eine andere Ressource als die CPU (pendet) der Task schläft für einen Zeitraum (delayed) der Task steht nicht zur Ausführen bereit, dieser State dient zu Debug Zwecken (suspended) der Task wartet auf eine Ressource außer der CPU und besitzt einen Timeout für das Warten (pended+timeout) Die möglichen Taskstatewechsel sind in Abbildung 2 abgebildet. Im Zustand ready befinden sich Tasks, sobald sie er- Abbildung 2: Taskzustände in VxWorks zeugt worden sind. Der Kernel wählt nur Tasks, die sich in diesem Zustand befinden, für das Scheduling aus. Während der Laufzeit kann ein Task seinen Zustand ändern, in dem er für einen bestimmten Zeitraum schläft oder er auf das Freiwerden einer Semaphore wartet. 2.2 Scheduler Definition Scheduler: Als Scheduler wird der Teil des Betriebssystems bezeichnet, der dafür sorgt, daß die einzelnen Tasks Rechenzeit und andere Ressourcen zugewiesen bekommen. Der Scheduler sorgt auch dafür, daß kritische Echtzeiteigenschaften der Tasks eingehalten werden können. Der Scheduler von VxWorks ist Teil des Microkernels. Er unterstützt zwei Scheduling-Verfahren: Priority Preemptive Scheduling In diesem Verfahren vergibt der Benutzer, schon bei 14

23 VxWorks Aufbau und Programmierung der Entwicklung des Systems, Taskprioritäten, welche die Wichtigkeit der Aufgabe der Tasks widerspiegeln. Dem Entwickler stehen dabei Prioritäten von 1 bis 255 zur Verfügung, wobei 1 die höchste Priorität beschreibt und 255 die niedrigste. Während der Laufzeit des Systems wählt der Scheduler immer den Prozess mit der höchsten Priorität aus und gibt diesem Rechenzeit. Ein Task-Wechsel zu einem anderen Task findet nur statt, wenn der aktive Prozess auf eine Ressource oder ein Ereignis wartet. Dann wird dem Prozess, mit der nächsthöheren Priorität Rechenzeit zugewiesen. Wird ein Prozess mit einer höheren Priorität durch das Freiwerden einer Ressource aufgeweckt und hat der aktive Prozess eine niedrigere Priorität, wird ein Task- Wechsel ausgeführt und der vorher wartende Prozess bekommt Rechenzeit und Zugriff auf die freien Ressourcen. Round Robin In diesem Verfahren erhält jeder Prozess gleichmäßig viel Rechenzeit zur Verfügung gestellt. Alle Tasks besitzen die gleiche Priorität und bekommen immer eine feste Anzahl von CPU Zyklen zugewiesen. Zusätzlich zu diesen beiden Scheduling-Algorithmen lassen sich in VxWorks daraus auch Misch-Systeme bilden. Dabei werden Gruppen von Tasks gebildet. Jede dieser Gruppe bekommt nach der Wichtigkeit ihre Prioritäten zugewiesen. Da nun die Tasks einer Gruppe die selbe Priorität besitzen, werden diese Tasks Round-Robin gescheduled und die Auswahl der Gruppe geschieht über Priority-Preemptive Scheduling. Da ein Echtzeitsystem sich schnell an Veränderungen der Umwelt anpassen muss, gibt es verschiedene Möglichkeiten den Scheduler zu beeinflussen. 1. Bei Round-Robin Scheduling lässt sich die Ausführungsdauer eines Tasks verändern. Dadurch kann die Responsivität bei bestimmten Aufgaben optimiert werden oder die Geschwindigkeit bei Berechnungen verbessert werden. Die richtige Wahl ist Aufgabe des Anwendungsentwicklers. 2. Bei Priority-Preemptive Scheduling lassen sich zur Laufzeit die Prioritäten von Tasks verändern. Wenn sich in der realen Welt die Wichtigkeit einer Berechnung verändert, kann diesem auch in VxWorks Rechnung getragen werden. 3. Zusätzlich zu diesen beiden Methoden, kann ein Task den Scheduler noch abschalten. Dadurch ist dieser der einzige Task der Zugriff auf die CPU erhält. Wenn dieser Prozess durch das nicht Vorhandensein einer Ressource auf diese warten muss, wird der Task mit der höchsten Priorität ausgewählt, um Rechenzeit zu erhalten. Durch das An- und Abschalten des Scheduler lässt sich zum Beispiel Gegenseitiger-Ausschluss(mutual-exclusion) implementieren. Zu beachten ist nur, daß weiterhin Interrupts, den Task unterbrechen können. In der Literatur findet man oft Scheduling Algorithmen wie z.b. Rate Monotonic, Earliest Deadline First und Least Laxity First. Einige von diesen Scheduling Algorithmen lassen sich mit Hilfe der von VxWorks unterstützen Verfahren simulieren. Dies gilt aber nur für Algorithmen, bei denen der Entwickler vorher festlegt, welche Priorität die jeweiligen Tasks besitzen. Eine dynamische Vergabe, während der Laufzeit, wird nicht unterstützt. Der Scheduler von Vx- Works ist am besten für weiche Echtzeitsysteme geeignet. Dies liegt daran, daß VxWorks zu komplex ist. Es lassen sich nicht alle Task-Unterbrechungen voraussehen und es wird auch keine statische Festlegung der Tasklaufzeiten unterstützt. 2.3 Semaphoren Definition Semaphore: Mit Semaphoren werden Elemente des Betriebssystem- Kerns bezeichnet, die dazu eingesetzt werden, Probleme der Prozess-Synchronisation zu lösen. Semaphore sind systemweit gültig. Es gibt verschiedene Arten von Semaphoren, die sich aber alle untereinander austauschen lassen. Wie jedes andere Betriebssystem stellt VxWorks auch Semaphoren zur Task-Synchronisation zur Verfügung. Folgende Semaphoren-Typen sind implementiert: Binary Semaphore Dies sind die schnellsten Semaphoren. Sie lassen sich für die verschiedensten Dinge einsetzen. Optimiert sind sie für Gegenseitigen-Ausschluss und Synchronisation von Tasks. Diese Art von Semaphoren ist eigentlich in jedem heute eingesetztem Betriebssystem zu finden. Counting Semaphore Diese Semaphoren sind ähnlich wie die binären Semaphoren. Zusätzlich zählen sie mit, wie oft eine Semaphore genommen worden ist. Sie sind optimiert um eine Ressource zu schützen, von der es eine bestimmte Anzahl gibt. Auch diese Semaphore ist heute oft in den gängigen Betriebssystemen zu finden. Mutual-Exclusion Semaphore Im Gegensatz zu den anderen Semaphoren sind diese nicht in anderen Betriebssystemen zu finden. In Vx- Works dienen sie nur zum Implementieren von Gegenseitigem-Ausschluss. In Linux oder Windows werden meist Binäre-Semaphoren dazu verwendet. Mutual-Exclusion Semaphore besitzen folgende zusätzliche Eigenschaften gegenüber von Binären-Semaphoren: sie können nur für Gegenseitiger-Ausschluss verwendet werden eine Semaphore kann nur von dem Task, der sie genommen hat wieder zurückgegeben werden sie können nicht von einer interrupt service routine (ISR) verwendet werden das globale Freigeben aller auf diese Semaphore wartenden Tasks ist nicht möglich Bei dem Einsatz von Semaphoren ergibt sich ein Problem, wenn ein Task aus dem System entfernt werden soll, während dieser Task noch eine Semaphore hält. Dies kann zum Deadlock der anderen Tasks führen und so das gesamte System zum Stillstand bringen. Um dies zu verhindern kann in VxWorks beim Erzeugen einer Semaphore ein Flag gesetzt 15

24 Dominik Meyer werden, welches dem Betriebssystem mitteilt, daß der Task, welcher eine Semaphore hält nicht gelöscht werden darf. 2.4 Interrupt Verwaltung Definition Interrupt: Ein Interrupt ist eine Unterbrechung des normalen Programmablaufs durch den Prozessor. Diese Unterbrechung wurde in den meisten Fällen durch den Timer-Interrupt herbeigeführt, mit dessen Hilfe das System Taskwechsel durchführt. Zusätzlich lösen Hardwaregeräte einen Interrupt aus, um zu signalisieren, daß bestimmte asynchrone Arbeiten abgeschlossen sind oder neue Daten verfügbar sind, wie es beim Einsatz von Sensoren bei Echtzeitbetriebssystemen häufiger vorkommt. Interrupts müssen in Echtzeitbetriebssystemen sehr schnell abgehandelt werden, damit die Aufgaben der einzelnen Tasks schnell ausgeführt und Überprüfungen von Sensoren in nahezu Echtzeit geschehen. Dazu werden die Interrupt Handler eingesetzt. Interrupt Handler sind kleine, schnell abzuarbeitende Programmteile, die beim Starten des Betriebssystems initialisiert werden. Um ihre Aufgabe in Echtzeitbetriebssystemen erfüllen zu können müssen bestimmte Richtlinien bei der Programmierung von Interrupt-Handlern beachtet werden. In VxWorks werden diese Handler Interrupt Service Routines(ISR) genannt. Um schnelle Reaktionszeiten der ISR zu gewährleisten, laufen diese in VxWorks in einem speziellen Kontext, außerhalb aller Task-Kontexte. Deshalb ist beim Aufruf einer ISR kein Task-Wechsel nötig und dadurch Zeit eingespart. VxWorks stellt für alle gängigen Interrupts eigene ISR zur Verfügung. Bestehen aber eigene Anforderungen an einen Interrupt, so können diese in selbst geschriebenen ISR erfüllt werden. Dabei sind einige wichtige Dinge zu beachten: Alle ISR benutzen den selben Interrupt Stack. Dieser Stack wurde bereits beim Start des Betriebssystems initialisiert. Er muss groß genug sein, um den schlimmsten anzunehmenden Fall von verschachtelten ISR bedienen zu können. Außerdem sollte in den ISR s darauf geachtet werden, daß der Stack nicht unnötig belegt wird, da nur begrenzter Platz zur Verfügung steht. Da eine ISR nicht in einem normalen Task-Kontext läuft bestehen bestimmte Einschränkungen in dem zur Verfügung stehenden Funktionsumfang. Deshalb dürfen synchrone Funktionen, die auf eine Aktion oder Interrupt warten, nicht verwendet werden. Dazu zählen bestimmt I/O-Funktionen und Semaphoren. Aus diesem Grund dürfen auch die Funktionen zum Reservieren und Freigeben von Speicher nicht verwendet werden, da diese die zu den blockierenden Funktionen zählen. Eine ISR darf auch nicht direkt über die Treiber mit der Hardware kommunizieren. Auch eine Benutzung eines mathematischen Coprozessors ist unter VxWorks innerhalb einer ISR nicht möglich, da der Interrupt Treiber nicht die Register des Coprozessors sichert. Durch eine Benutzung würden dann Ergebnisse, auf die der Task, der unterbrochen wurde, wartet verfälscht. Benötigt eine ISR trotzdem Funktionen des Coprozessors, muss der Programmierer dafür sorgen, daß die Register gespeichert und nach der Benutzung wieder zurückgesetzt werden. Zur Kommunikation zwischen ISR s und normalen Tasks können die in Abschnitt 4 vorgestellten Methoden verwendet werden. 3. SPEICHERVERWALTUNG Definition Speicherverwaltung (Memory Management): Speicherverwaltung bezeichnet den Teil der Betriebssystem- Dienste, der sich mit dem verwalten des vorhandenen Speichers befasst. Da dieser immer nur in begrenztem Maße zur Verfügung steht müssen die Funktionen den Speicher effizient reservieren und wieder freigeben. Jedes Betriebssystem stellt auch Speicherverwaltungsroutinen zur Verfügung. Über die Speicherverwaltung können Tasks und Betriebssystem Speicher für Daten und Puffer anfordern. In den heutigen Desktop-Betriebssystem ist es üblich die Speicherverwaltung auf einem Virtual Memory Interface(VMI) zu implementieren. VMI bedeutet, daß der physikalische Speicher nicht direkt angesprochen wird, sondern daß es eine Abstraktionsschicht gibt, die es ermöglicht Auslagerungsdateien oder -Partitionen zu verwenden. Diese Schicht sorgt dafür, daß zur Zeit nicht benötigter Speicher aus dem physischen Speicher in die Auslagerungsdateien oder -Partitionen verschoben wird und daß der physische Speicher durch schnelleren Cache gepuffert werden kann. Viele Echtzeitbetriebssystem verwenden dieses Prinzip nicht, da es dort meist keine große Unterstützung für Festspeicher-Medien gibt, auf die Speicher ausgelagert werden könnte. Wind River hat das VMI Konzept aber aufgegriffen und in VxWorks implementiert. VxWorks stellt einmal eine Basisunterstützung von VMI zur Verfügung und zusätzlich in einem Modul eine erweiterte Unterstützung. 3.1 Basic VMI Diese Speicherverwaltungsroutinen stehen immer unter Vx- Works zur Verfügung. Sie sind direkt im Basis-Code des Betriebssystems enthalten. Die Basisunterstützung unter Vx- Works sieht so aus, daß bei der Initialisierung des Systems, beim Booten, der Kernel einen virtuellen Speicherbereich erzeugt. Dieser virtuelle Speicherbereich ist eine eins zu eins Abbildung vom physikalischem Speicher. In diesem virtuellem Speicherbereich werden alle später gestarteten Tasks ausgeführt. Die Tasks können untereinander auf den gesamten Speicherbereich dieser Virtuellen Einheit zugreifen und so auch den Programmcode von anderen Tasks verändern. Es gibt zum einen den gewollten Zugriff auf einen gemeinsamen Speicherbereich und zum anderen den ungewollten. Auf ersteren wird in Abschnitt 4 genauer eingegangen. Der ungewollte Fall kann aber mit diesen Basis-Funktionen nicht verhindert werden. In diesem Fall ist es die Aufgabe des Programmieres dafür zu sorgen, daß keine solchen Zugriffe geschehen können. Der Umfang der Basisfunktionalität hängt auch davon ab, ob die Hardware eine Memory Management Uni (MMU) zur Verfügung stellt. Mithilfe einer MMU kann das VMI Speicherbereiche, die z.b. von Geräten mit Direkt Memory Access (DMA) zugegriffen wird, automatisch vom Caching ausnehmen. Ist keine MMU vorhanden, muss der 16

25 VxWorks Aufbau und Programmierung Programmierer selbst für die Cache-Updates sorgen, oder das Caching komplett deaktivieren. Durch das Deaktivieren des Caches wird die Gesamt-Performance des Betriebssystems jedoch stark eingeschränkt. 3.2 VxVMI Modul Dieses Modul kann zusätzlich zum Betriebssystem erworben werden. Es setzt aber das Vorhandensein einer MMU voraus. Die Basis-Funktionen, wie eben beschrieben, bleiben erhalten. VxVMI benötigt eine MMU um zu verhindern, daß bestimmte Bereiche des Speichers überschrieben werden. Beim Start von VxWorks werden alle Text-Segmente, die den Programmcode des Betriebssystems enthalten, schreibgeschützt. Beim Start von weiteren Tasks werden deren Text-Segmente ebenfalls automatisch schreibgeschützt. Dadurch ist sichergestellt, daß andere Tasks nicht den Programmcode von bereits laufenden Tasks verändern können. Zusätzlich wird beim Start von VxWorks auch die sich im Speicher befindende Interrupt Vector Table (IVT), die die Sprungadressen enthält, die bei dem Auftreten von Interrupts angesprungen werden, auf nur lesend gesetzt. Durch diese Maßnahmen wird die Zuverlässigkeit bedeutend erhöht. Zusätzlich zu diesen Erweiterungen bietet VxVMI die Möglichkeit, ganze Speicherbereiche vom Caching auszunehmen oder sie ebenfalls, wie die Text-Segmente, gegen Schreibzugriffe zu schützen. Eine weitere, sehr wichtige Erweiterung ist Private Virtual Memory(PVM). PVM bietet die Möglichkeit, daß einzelne Tasks mehrere virtuelle Speicherbereiche erzeugen können, die sie nach belieben in den Auslagerungsspeicher verschieben können und wieder in den Speicher laden können. Jeder dieser virtuellen Speicherbereiche hat für die globalen Objekte des Systems, die gleichen virtuellen Speicheradressen, damit die Tasks weiterhin auf System-Objekte wie die Semaphoren zugreifen können. Mit den Basis-Funktionen ist es also möglich ganz normal zu arbeiten. Besteht aber in dem zu entwickelnden System das Bedürfnis nach mehr Zuverlässigkeit und Sicherheit, kommt man um die Nutzung des VxVMI Moduls zur Absicherung der Speicherbereiche nicht herum. 4. INTERTASKKOMMUNIKATION Definition Intertaskkommunikation: Einzelne Task müssen oft miteinander kommunizieren, um ihren Ablauf koordinieren zu können. Um dies so einfach und sicher wie möglich zu gestalten, bieten alle Betriebssysteme Intertaskkommunikation (oder ein Äquivalent für die jeweilige organisatorische Einheit) an. Wie bereits erwähnt wurde, ist VxWorks ein Multitasking- Betriebssystem. Deshalb ist es sehr wichtig, daß die parallel ausgeführten Tasks miteinander kommunizieren können, um Aktionen und Zugriffe zu Synchronisieren. Dafür stehen in VxWorks mehrere Verfahren zur Verfügung: 1. Gemeinsamer-Speicher, zum Austausch einfacher Daten 2. Message Queues, zum Austausch von Nachrichten innerhalb einer CPU 3. Pipes, zum Austausch von Nachrichten innerhalb einer CPU 4. Sockets und Remote Procedure Calls(RPC), zur Kommunikation über ein Netzwerk 5. Signale, für Fehler- und Exception-Behandlung 6. VxMessagePassing(VxMP) und VxFusion zum Austausch von Nachrichten über mehrere CPUs hinweg Im folgenden wird nur auf die Verfahren eingegangen, die mit der Basis Version von VxWorks möglich sind und innerhalb einer CPU stattfinden. Das Thema Sockets und RPC ist zu umfassend, als daß es hier behandelt werden könnte. 4.1 Shared Memory Dies ist die einfachste Art unter VxWorks Daten auszutauschen. Wie im Abschnitt 3 und 2.1 erwähnt wurde, besitzt VxWorks ein flat memory model und alle Tasks können auf den Speicherbereich der anderen Tasks zugreifen. Durch die- Abbildung 3: Shared Data Structure aus [1] se Methode können globale Variablen, lineare Puffer, Ring- Puffer und verkettete Listen und Zeiger direkt von den verschiedenen Task-Kontexten referenziert werden. Wenn man diese Methode wählt, muss aber darauf geachtet werden, daß auf den gemeinsamen Speicherbereich nicht gleichzeitig geschrieben wird oder gleichzeitig geschrieben und gelesen wird. Um dies zu gewährleisten können die Semaphoren aus Abschnitt 2.3 eingesetzt werden. In Abbildung 3 ist der typische Aufbau einer solchen Kommunikation dargestellt. Drei Tasks kommunizieren über eine gemeinsame Speicherstelle im Hauptspeicher. 4.2 Message Queues Heutige Echtzeit-Applikationen werden aus unabhängigen Tasks zusammengesetzt, die aber zum Erfüllen ihrer Aufgabe eng zusammenarbeiten. Zur Synchronisation solcher Tasks wurden bereits Semaphoren vorgestellt. Zusätzlich zur Synchronisation müssen aber oft auch kurze Nachrichten ausgetauscht werden. Dies ist zum Beispiel bei verteiltem Rechnen notwendig, um Aufgaben zu verteilen und die Ergebnisse der Berechnungen wieder zusammenzubringen. Für solche Aufgaben eignen sich Message Queues. Message Queues bilden Kanäle zwischen zwei oder auch mehreren Tasks. Unter VxWorks arbeiten diese Kanäle nach dem FIFO Prinzip. Zusätzlich dazu gibt es die Möglichkeit eine Nachricht als dringend, zu markieren. Die Nachricht wird dann nach dem LIFO Prinzip einsortiert und Zusätzlich zu den Prioritäten kann beim Versenden oder Empfangen auch ein Ti- 17

26 Dominik Meyer meout angegeben werden. Beim Versandt bedeutet der Timeout, das der Task eine zeitlang auf das Freiwerden eines Platzes in der Queue wartet. Beim Empfang bedeutet er, die Zeit, die der Task warten soll, wenn zu dem Zeitpunkt gerade keine Nachricht in der Queue war. Der Timeout kann auch so gewählt werden, daß der Task gar nicht wartet oder daß er ununterbrochen wartet. Wenn eine bidirektionale Verbin- Abbildung 4: Full Duplex Message Queue aus [1] dung zwischen Tasks gewünscht wird, wie sie in Abbildung 4 dargestellt ist, kann diese mit zwei Message Queues implementiert werden. Es können auch mehrere Tasks gleichzeitig auf die gleiche Message Queue lesend oder schreibend zugreifen. Dabei geht das Empfangen der Nachricht nach dem Prinzip wer zuerst kommt bekommt die Nachricht. Es wird also nicht automatische sichergestellt, daß alles Tasks die verschickte Nachricht bekommen. Ist so ein Verhalten gewünscht, muss die Kommunikation über eine Client/Server Struktur erfolgen. Dabei dient ein Task als Server. Dieser empfängt von allen Clients über eine Message Queue Nachrichten. Diese Nachrichten werden dann über je eine Message Queue zu jedem einzelnen Client weiter verschickt. Siehe dazu Abbildung 5. Ähnlich wie in Abbildung 5 lässt sich auch eine Client/Server Struktur mit Pipes aufbauen. 4.4 Signale Zusätzlich zu den bisher beschriebenen Methode zur Intertaskkommunikation gibt es noch den Signal-Mechanismus. Signale können von jedem Task und jeder ISR an jeden anderen Task gesendet werden. Jeder Task kann nun einen Signal-Handler initialisieren. Beim Ankommen eines Signals wird der Task suspended und der angegebene Signal-Handler wird im Kontext des Tasks ausgeführt. Dadurch hat der Signal-Handler auf den Speicher des Tasks Zugriff. Beim Programmieren von Signal-Handlern muss darauf geachtet werden, daß dieser nicht in einen blockierenden Zustand kommt. Passiert dies kommt es zum Stillstand des gesamten Task und unter Umständen zum Deadlock des gesamten Systems. Signal-Handler sollten nur wenige CPU-Zyklen laufen und so wenige Operationen wie möglich durchführen, damit der Task seine normale Funktionsweise wieder aufnehmen kann. Mit Signalen lassen sich am besten Laufzeitfehler von anderen Tasks melden oder das kurze signalisieren, daß eine bestimmte Aufgabe erfüllt wurde. Letzteres könnte z.b. das Auslesen eines Sensors sein. Sobald dieser ausgelesen wurde und das Ergebnis im Speicher steht, kann mit einem Signal ein anderer Task benachrichtigt werden, daß dieser dieses Ergebnis verwenden kann. 5. SONSTIGE FEATURES 5.1 I/O System Definition I/O System: Das I/O System eines jeden Betriebssystem stellt die Kommunikation des Betriebssystems mit der Umwelt zur Verfügung. Dies ist z.b. die Ausgabe von Text auf einem Bildschirm und die Eingabe von Zeichen über eine Tastatur. Es gehört aber auch die Kommunikation über zusätzliche Hardwarekomponenten dazu, wie z.b. Serielle Schnittstellen, Netzwerk-Karten, Aktuatoren und Sensoren. Abbildung 5: Client Server Struktur 4.3 Pipes Pipes bieten eine Alternative zu Message Queues um Nachrichten zwischen Tasks auszutauschen. Pipes werden mit Gerätenamen gekoppelt und die einzelnen Tasks können mit den standard I/O-Befehlen auf diese Pipes zugreifen. Sie sind den Message Queues sehr ähnlich. Der Unterschied besteht nur in den Zugriffs-Methoden. Bei Pipes gibt es keine Prioritäten, sie sind normale FIFO Queues. Der Schreibzugriff auf eine Pipe ist nicht-blockierend, daß heißt, der Task schreibt in die Pipe und kehrt dann in den laufenden Task zurück. Der Lesezugriff auf eine Pipe ist blockierend. Der Task wartet solange auf eine Nachricht in der Pipe bis eine ankommt. Kommt keine, so kann der Task für immer warten. Das I/O System das VxWorks bietet, ist zu dem von UNIX kompatible. Dies ermöglicht vielen Programmierern einen leichten Umstieg auf VxWorks. Die einzelnen Systemfunktionen zur Ein- und Ausgabe sind so geschrieben, daß sie schnell Ergebnisse liefern und so die Echtzeit-Anforderungen erfüllt werden können. Von VxWorks werden folgende Einund Ausgabegeräte unterstützt: Zeichenorientierte Geräte, wie z.b. Terminals oder Kommunikationsleitungen Blockorientierte Geräte, z.b. Festplatten virtuelle Geräte, dazu gehören die Pipes und Sockets Monitor- und Kontrollgeräte, z.b. digitale und analoge Ein- und Ausgabegeräte Netzwerkgeräte 18

27 VxWorks Aufbau und Programmierung 5.2 Dateisysteme Definition Dateisystem: Ein Dateisystem sorgt dafür, daß ein Programmierer sich nicht mit der direkten Speicherung von Daten auf Festspeichermedien befassen muss. Dateisysteme stellen Dateien und Verzeichnisse zur Verfügung, um Daten speichern zu können. In vielen Echtzeitbetriebssystemen ist es üblich, daß sich der Programmierer selbst um die Speicherung seiner Daten auf der Festplatte kümmern muss, oder daß es gar keine Unterstützung für Festspeichermedien gibt. Dies ist bei VxWorks nicht so. Es unterstützt eine Reihe von Dateisystemen, die der Programmierer verwenden kann um seine Daten zu speichern. Die Dateisysteme setzen in VxWorks alle auf einer standard Schnittstelle zum Gerätetreiber auf. Dadurch können mehrere Dateisysteme parallel unter VxWorks existieren, wie man es von Linux, Unix und Windows gewohnt ist. Zusätzlich lassen sich auch eigene Dateisysteme einfacher über dieses Interface programmieren. Folgende Dateisysteme unterstützt VxWorks standardmäßig: dosfs Ist zu dem DOS Dateisystem kompatibel, wurde aber für den Echtzeiteinsatz optimiert rawfs Ein Basis Dateisystem, daß die gesamte Festplatte als eine große Datei darstellt tapefs Dieses Dateisystem ist für die Benutzung auf Backupgeräten gedacht. cdromfs Ein Dateisystem, das kompatibel zum ISO9669 Standard ist und somit normale CD-Roms lesen kann TSFS (Target Server File System) Durch dieses Dateisystem kann dem Zielsystem Zugriff auf Dateien des Entwicklungssystem gegeben werden 6. POSIX Definition: POSIX POSIX ist ein Standard, der die Kompatibilität von Computerprogrammen über Betriebssystemgrenzen hinweg sicherstellen soll. Es gibt verschiedene POSIX Standards, die für bestimmte Einsätze gedacht sind. Für Echtzeitbetriebssysteme ist der wichtigste Standard b. Dieser legt bestimmte Funktionen und Elemente fest, die zur Zeitmessung, Task- Erzeugung, Semaphoren- und Speicherverwaltung benötigt werden. VxWorks ist genau zu dem Standard b kompatibel. Das bedeutet, daß VxWorks zusätzlich zu seinen normalen Betriebssystem Funktionen auch noch POSIX Funktionen optional anbietet. In diesem Kapitel werden kurz die unterstützten Funktionen beschrieben und einige wichtige mit den VxWorks Kernelfunktionen verglichen. Die VxWorks Kernelfunktionen werden dabei mit WIND Funktionen bezeichnet. 6.1 POSIX Erweiterungen POSIX Blocks und Timer VxWorks unterstützt die im Standard vorgeschriebene globale Uhr und die Funktionen um auf diese Uhr zuzugreifen. Die im Standard als optional eingestuften virtuellen Uhren werden von VxWorks nicht unterstützt. VxWorks stellt auch den vorgeschriebenen Timer zur Verfügung, der von Tasks benutzt werden kann, um sich zu einem späteren Zeitpunkt in der Ausführung selber Signale senden zu können. Dazu stellt VxWorks die geforderten POSIX Routinen zur Verfügung. POSIX Memory locking Memory locking bedeutet, daß bestimmte Speicherseiten vom Paging und Swapping des Betriebssystems ausgeschlossen werden. Sie verbleiben dann die gesamte Zeit im Hauptspeicher. Dadurch kann die Performance von bestimmten Tasks verbessert werden. In VxWorks sind diese Funktionen nur als Dummy implementiert, da durch das Memory Management von VxWorks alle Speicherseiten im Hauptspeicher liegen. POSIX Threads Um auch betriebssystemübergreifend Threads erzeugen zu können definiert der Standard b auch ein Interface um diese zu erzeugen. Threads werden in Vx- Works als Tasks mit folgenden zusätzlichen Attributen im Task-Kontext implementiert: eine zusätzliche Thread ID, die unterschiedlich von der Taskid ist eine Möglichkeit die Größe des Stacks festzulegen eine Möglichkeit die Speicheradresse festzulegen, ab welcher für den Thread Speicher alloziert wird Zusätzlichen Thread State, welcher festlegt, ob der Parent Task auf das Ende des Threads wartet oder mit seiner Arbeit weitermacht einer Möglichkeit festzulegen, ob der Thread die Scheduling Parameter von seinem Parent erbt oder diese speziell definiert werden die Möglichkeit die Scheduling Policy einzustellen. Dabei stehen FIFO und Round Robin zur Verfügung die Möglichkeit zusätzliche Scheduling Parameter anzugeben, wie z.b. eine Priorität Zusätzlich zu diesem erweiterten Task-Kontext bieten Threads einige Funktionen die Tasks nicht bieten. Ein Thread kann bestimmte Dinge im Thread-Kontext speichern, indem ein key erzeugt wird, über die dann die Daten angesprochen werden können. Zusätzlich zu diesen Daten kann auch ein Destructor angegeben werden, der für das ordnungsgemäße löschen der Daten und des key beim Beenden des Threads ausgeführt wird. Außerdem unterstützen POSIX Threads das Feature Thread Cancellation. Mit diesem Feature lässt sich ein Thread ordnungsgemäß abbrechen. Dabei wird zwischen synchronem und asynchronem Abbruch unterschieden. Beim synchronen Abbruch überprüft der Thread ob er abgebrochen wurde und springt dann zu einem Abbruchspunkt. Beim asynchronen Abbruch verhält sich der Thread ähnlich eines Signals. Wenn der Thread unterbrochen wird, wird ein Handler aufgerufen. 19

28 Dominik Meyer POSIX Scheduling Interface VxWorks implementiert auch das POSIX Scheduling Interface. Dabei unterscheiden sich das standard Vx- Works Scheduling und das POSIX Scheduling in folgenden Dingen: Das POSIX Scheduling basiert auf Prozessen und das VxWorks Scheduling auf Tasks. Deshalb werden die POSIX Routinen für das Scheduling auch unter VxWorks auf die Tasks angewandt. Im POSIX Standard wird von FIFO Scheduling geredet unter VxWorks von preemptive Priority Scheduling. Nur die Terme unterscheiden sich. Beide beschreiben prioritätsbasiertes Scheduling. POSIX legt das Scheduling auf einer Prozess zu Prozess Basis fest, VxWorks auf einer systemweiten Basis. Das bedeutet unter dem VxWorks standard Scheduling werden alle Tasks entweder mit dem round-robin- oder mit preemptive Priority Schema gescheduled. Außerdem unterscheiden sich die beiden Systeme durch die Nummerierung der Prioritäten. In PO- SIX sind die höheren Werte auch die höhere Priorität. Im VxWorks standard Scheduling ist es umgekehrt. POSIX Semaphoren VxWorks implementiert ebenfalls POSIX benannte und unbenannte Semaphoren. Dies sind Counting Semaphoren. Die VxWorks standard Semaphoren sind mit diesen in der Basis vergleichbar bieten aber einige zusätzliche Eigenschaften: Prioritätsvererbung Schutz gegen das löschen von Tasks, die eine Semaphore halten Die Möglichkeit, daß ein einzelner Task eine Semaphore mehrmals nehmen kann Besitz von Gegenseitiger-Ausschluss Semaphoren Unterstützung von Timeouts von Semaphoren die Auswahl von Queuing-Mechanismen POSIX Mutexes und Condition Variables Mutexes und Condition Variablen sind mit den Gegenseitiger-Ausschluss Semaphoren und den binären Semaphoren vergleichbar. VxWorks verwendet diese Semaphoren um die POSIX Mutexes und Codition Variablen zu implementieren. POSIX Message Queues POSIX Message Queues werden ebenfalls von VxWorks unterstützt. Diese Message Queues sind ähnlich zu den standard Message Queues von VxWorks mit den folgenden Unterschieden: Feature VxWorks POSIX Nachrichten 1 32 Prioritäts Level Blocked Task FIFO oder prioritätsbasiert prioritätsbasiert Queues Empfang mit Optional nicht unterstützt Timeout Task Benachrichtigung nicht unterstützt Optional POSIX Queued Signals Queued Signals gehören auch zum Standard b. Sie stehen unter VxWorks als alternative zu den Vx- Works Signals zur Verfügung. VxWorks bietet 7 Signale, die von den Tasks zur Kommunikation verwendet werden können. Diese Signale sind durch den PO- SIX Standard vorgeschrieben. Im Gegensatz zu den VxWorks werden die gesandten Signale aber in eine Queue gestellt, wodurch keine Signale verloren gehen und Tasks auf mehrere gleichzeig ankommenden Signale reagieren kann. 7. PROGRAMMIERUNG 7.1 Gegenseitiger-Ausschluss Da Gegenseitiger-Ausschluss ein sehr wichtiger Bereich in der Programmierung von Echtzeitsystemen ist, wird in diesem Abschnitt auf die verschiedenen Arten eingegangen, mit denen unter VxWorks Gegenseitiger-Ausschluss erreicht werden kann. Diese beziehen sich aber nur auf Systeme mit nur einem Prozessor und auch nicht auf Verteilte Systeme. Die mächtigste, aber auch die gefährlichste Möglichkeit, ist das Deaktivieren der Interrupts. Vor dem Eintritt in die kritische Sektion werden die Interrupts einfach deaktiviert. Dadurch werden keine Taskwechsel mehr ausgeführt, da der Timerinterrupt nicht mehr bearbeitet wird. Auch werden keine Hardwareinterrupts mehr bearbeitet. Der Task läuft dann alleine und Gegenseitiger-Ausschluss ist sichergestellt. In dieser Phase dürfen keine VxWorks Betriebssystembefehle ausgeführt werden, da sonst die Interrupts durch diese wieder aktiviert werden könnten. Diese Methode sollte nur angewandt werden, wenn Gegenseitiger- Ausschluss auch gegenüber Interrupts benötigt wird. Eine weitere Möglichkeit ist das Abschalten des Preemption, der Unterbrechung eines Tasks durch einen Task mit höherer Priorität. Dadurch wird der Task, der das Preemption abgeschaltet hat, nur noch von ISR s unterbrochen werden. Mit diese Methode kann aber zu nicht nachvollziehbaren Antwortzeiten auf Echtzeitereignisse kommen, da Prozesse mit höherer und damit wichtigerer Priorität erst nach Freigabe des Preemption wieder an die Reihe kommen. Die sicherste Methode in VxWorks Gegenseitiger-Ausschluss sicherzustellen ist der Einsatz der Gegenseitiger- Ausschluss-Semaphoren. Sie sind schnell, Tasks können von Tasks mit höherer Priorität unterbrochen werden, solange sie nicht auf die gleiche Ressource zugreifen. Auch Interrupts müssen nicht deaktiviert werden. Die letzte Methode ist den anderen bei der Entwicklung von Echtzeit-Applikationen vorzuziehen, da die Auswirkungen besser vorhersehbar sind. Deshalb ist in Abbildung 6 ein Beispiel dafür angegeben. Beim Abschalten der Interrupts und beim deaktivieren des Preemption müssen vom Programmierer viele Dinge beachtet werden, damit das Betriebssystem nicht in einen Deadlock gerät oder Interrupts plötzlich wieder aktiviert sind. In Zeile 14 von Abbildung 6 wird die Semaphore für ihren Einsatz initialisiert. Dazu wird der Befehl SemMCreate verwendet. Dabei steht das M für 20

29 VxWorks Aufbau und Programmierung mutual-exclusion. In Zeile 18 nimmt sich die Funktion funca mittels SemTake die Semaphore und gibt sie nach der kritischen Sektion in Zeile 23 mittels SemGive wieder zurück. Ähnlich arbeitet auch funcb. Diese Befehle sind sehr einfach und verhindern dadurch Programmierfehler. 1 / Function A r e q u i r e s a c c e s s to a r e s o u r c e which i t a c q u i r e s by t a k i n g 2 mysem ; 3 Function A may a l s o need to c a l l f u n c t i o n B, which a l s o r e q u i r e s mysem : 4 / 5 6 / i n c l u d e s / 7 #i n c l u d e " v x W o r k s. h " 8 #i n c l u d e " s e m L i b. h " 9 SEM_ ID mysem ; / Create a mutual e x c l u s i o n semaphore. / 12 init ( ) 13 { 14 mysem = s e m M C r e a t e ( S E M _ Q _ P R I O R I T Y ) ; 15 } 16 f u n c A ( ) 17 { 18 s e m T a k e ( mysem, W A I T _ F O R E V E R ) ; 19 p r i n t f ( " f u n c A : Got mutual - e x c l u s i o n s e m a p h o r e \ n " ) ; // c r i t i c a l s e c t i o n s e m G i v e ( m y S e m ) ; 24 p r i n t f ( " f u n c A : R e l e a s e d mutual - e x c l u s i o n s e m a p h o r e \ n " ) ; 25 } 26 f u n c B ( ) 27 { 28 s e m T a k e ( mysem, W A I T _ F O R E V E R ) ; 29 p r i n t f ( " f u n c B : Got mutual - e x c l u s i o n s e m a p h o r e \ n " ) ; // c r i t i c a l s e c t i o n s e m G i v e ( m y S e m ) ; 34 p r i n t f ( " f u n c B : R e l e a s e s mutual - e x c l u s i o n s e m a p h o r e \ n " ) ; 35 } Abbildung 6: Mutual-Exclusion Semaphoren im Einsatz 7.2 Tornado Entwicklungs Umgebung Beim Kauf von VxWorks liefert Wind River auch eine Entwicklungsumgebung mit. Diese Tornado genannte, Umgebung bietet alle Funktionen, die nötig sind, um Echtzeit- Applikationen zu entwickeln und sie in einem Simulator oder später auf der Ziel-Architektur zu testen und zu debuggen. In Abbildung 7 ist der Aufbau dieser Umgebung gezeigt. Mit dieser Entwicklungsumgebung ist es möglich ein komplettes Echtzeitsystem zu konfigurieren und die nötigen Applikationen in das System einzuspielen. Wie man auf der Abbildung erkennen kann, bildet der Target-Server die Verbindung zwischen den Entwicklungswerkzeugen und der Ziel-Architektur oder einem Simulator. Über den Target-Server kann auf dem Zielsystem eine Shell gestartet werden, mit der man den System überwachen und konfigurieren kann. Außerdem lassen sich über den Target-Server auch Debugdaten direkt von dem System in die Entwicklungsumgebung einspielen, so daß man Fehlermeldungen direkt mit dem geschriebenen Code vergleichen kann. Abbildung 7: Entwicklungsumgebung Tornado 8. EINSATZGEBIETE VxWorks wird hauptsächlich in Kleingeräten eingesetzt. Die typischen Anwendungsgebiete sind: 1. Luft- und Raumfahrt 2. Verteidigung 3. Maschinensteuerung 4. medizinische Geräte 5. Netzwerk Infrastruktur Das bekannteste Beispiel für den Einsatz von VxWorks sind die NASA Projekte Mars Reconnaissance Orbiter,Pathfinder sowie die Mars-Fahrzeuge Spirit und Opertunity. Bei der Pathfinder-Mission kam es zu Problemen, die auf eine fehlerhafte Programmierung der Tasks unter VxWorks zurückzuführen war [7]. 9. SCHLUSSFOLGERUNG VxWorks ist ein sehr mächtiges Echtzeitbetriebssystem. Es beinhaltet viele Features die auch in aktuellen Desktop-Betriebssystemen enthalten sind. Als Beispiele dafür sind Virtual Memory Management und Dateisysteme genannt. Das Vorhandensein dieser Dienste vereinfacht das Programmieren sehr. Trotz solcher Features bleiben unter VxWorks die Echtzeiteigenschaften erhalten. Viele der Betriebssystem - Funktionen sind sehr anwendungsnah gehalten. Dies erkennt man am besten an den Semaphoren. Für jede wichtige Art Semaphoren einzusetzen, besitzt VxWorks einen eigenen Typ Semaphoren (Binäre-, Counting- und Mutual exclusion Semaphoren). Dies hilft unnötige Programmierfehler zu vermeiden und die Software zuverlässiger zu machen. Zusätzlich 21

30 Dominik Meyer bietet die Entwicklungsumgebung Tornado sehr viele Funktionen um dem Entwickler, schon beim Entwicklungsprozess zu helfen Fehler zu finden und seine Programme, sogar auf dem Zielsystem, zu debuggen. Die Literatur zum Thema VxWorks ist aber erstaunlich eingeschränkt. Viele der Informationen sind nur in den Programmierthandbüchern von Wind River zu finden. Weitergehende Informationen, z.b. wie die Echtzeiteigenschaften von VxWorks sichergestellt werden, findet man kaum. Bücher, die weitergehende Informationen enthalten können, sind in Büchereien nicht zu finden und auch im Buchhandel nur mit einiger Lieferzeit erhältlich. Informationen von Wind River direkt erhalten nicht mal große Kunden, die VxWorks professionell in Produkten einsetzen. 10. LITERATURVERZEICHNIS [1] VxWorks Programmers Guide. Techn. Ber., Wind River. flight/sw/vxdocs/vxworks/guide/. [2] Wind River. [3] VxWorks / Tornado II FAQ, http: // [4] Bala, N.: Real-time Operating Systems (RTOS) modelling. Techn. Ber. http: //mesl.ucsd.edu/gupta/teaching/cse237a-s04/ ProjectPresentations/VxWorksReportv5.doc. [5] Collier, J.: An Overview Tutorial of the VxWorks Real-Time Operating System. Techn. Ber. php#vxworks\programming. [6] Joseph, M.: Real-time Systems Specification, Verification and Analysis. Prentice Hall, [7] Reeves, G. E.: What really happend on Mars, Pathfinder/Authoritative_Account.html. [8] Stalling, W.: Betriebssysteme Prinzipien und Umsetzung. Prentice Hall, [9] WindRiver: VxWorks. [10] WindRiver: Aerospace & Defence, aerospace-defense/mars-rover.html. [11] Witzak, M. P.: Echtzeit Betriebsysteme - Eine Einführung in Architektur und Programmierung. Franzis,

31 Teil II. Echtzeit-Bussysteme

32

33 Echtzeitbussysteme im Überblick Echtzeitbussysteme im Überblick CAN, LIN, Realtime-Ethernet, TTP, Byteflight, FlexRay, SAFEBus Lars Wienbrandt Christian-Albrechts-Universität zu Kiel Arbeitsgruppe für Echtzeitsysteme und Eingebettete Systeme Kiel, Germany Zusammenfassung Dieser Artikel gibt eine Zusammenfassung über einige ausgewählte Echtzeitbussysteme und deren Klassifizierungen. Behandelt werden verschiedene Klassifizierungen, z.b. eine von der SAE (Society of Automotive Engineering [30, 11]) eingeführte. Es werden die Spezifikationen und Anwendungsbereiche in der Industrie von CAN (mit TTCAN ), LIN, Realtime-Ethernet am Beispiel Ethernet Powerlink, TTP, byteflight, FlexRay und SAFEbus erläutert und an geeigneter Stelle Unterschiede oder Ähnlichkeiten zwischen den jeweiligen Systemen herausgestellt. Sowohl die Sicherheit und Zuverlässigkeit auf der einen Seite, als auch der Kostenpunkt und die Wirtschaftlichkeit auf der anderen Seite spielen für eine Einteilung in verschiedene Klassen eine große Rolle. 1. EINFÜHRUNG Echtzeitbussysteme werden in allen Bereichen in denen verteilte Echtzeitsysteme zum Einsatz kommen benötigt. Sie stellen ein System zur Kommunikation zwischen verschiedenen verteilten Anwendungsknoten dar. Durch den Trend in der Automobilindustrie immer mehr Mechanik durch elektronische Bauteile zu ersetzen und Zusatzfunktionalitäten einzubauen, wächst die Anzahl der verteilten Systeme im Automobil stetig an. Weiterhin werden Systeme immer komplexer und sicherheitsrelevanter. Eine Konsequenz daraus ist, dass nicht mehr eine zentrale Kontrolleinheit die Systeme steuern kann. Es entsteht die Notwendigkeit von Bussystemen. Die Einführung von Bussystemen führte ebenfalls zur Einsparung von Verkabelung, da nicht mehr jeder Knoten mit jedem anderen, mit dem eine Kommunikation erwünscht ist, direkt verbunden werden muss. Dies hat eine erhebliche Kosten und Gewichtsreduzierung zur Folge. In der Automobilindustrie sind etwa 1000 Meter Kabel pro Serienfahrzeug eine grobe Orientierung. Bereits 1998 waren in Automobilen der höheren Klasse bis zu 50 elektronische Kontrolleinheiten (ECUs) verbaut, 2005 spricht man von bis zu 70 ECUs [18, 26]. Abbildung 1 zeigt wieviel Steuergeräte im Laufe der Zeit in PKWs deutscher Hersteller vernetzt wurden [11]. Leider haben viele Hersteller zunächst Insellösungen für die Entwicklung von Bussystemen geschaffen. Der Trend geht allerdings längst zu Zusammenschlüssen von Entwicklern in Abbildung 1: Vernetzungsumfang deutscher PKWs der Industrie und zur Schaffung von offenen Standards. Hierdurch können beispielsweise Controller von verschiedenen Zulieferern produziert werden. Dies hat einen Wettbewerb auf dem Markt zur Folge, welches ein niedrigeres Preisniveau seitens der Hersteller erwarten lässt. Außerdem können Komponenten verschiedener Hersteller untereinander ausgetauscht werden und eine hohe Stückzahl und langfristige Verfügbarkeit kann gewährleistet werden [21]. Die Anforderungen an ein Bussystem sind je nach Aufgabenbereich unterschiedlich. Es gibt sicherheitsunkritische Aufgaben, wie z.b. die Ansteuerung elektrischer Fensterheber oder der Klimaanlage im Automobil, welche sicher von langsamen Bussystemen, bei denen ein auftretender Fehler nicht schwerwiegend ist, erfüllt werden können, oder Aufgaben zur Koordination der gesamten Karosserieelektronik, welche wegen des höheren Datenaufkommens von schnelleren Systemen erfüllt werden müssen [19]. Darüberhinaus müssen sicherheitsrelevante Applikationen, wie Airbag, ABS, ESP, von sehr zuverlässigen, fehlertoleranten und ausfallsicheren Bussystemen gesteuert werden, um hier die Funktion ständig zu gewährleisten [1, 2, 15]. Außerdem werden langsame und selten benötigte Bussysteme für Diagnosesysteme zur Wartung und Reparatur oder schnelle und nicht zwingend zuverlässige Bussysteme für Multimedia-Anwendungen benötigt. Abbildung 2 zeigt Anwendungsbeispiele und verschiedene Bussysteme eines Mittelklassefahrzeugs [30]. Durch sog. x-by-wire-systeme (z.b. fly- oder drive-by-wire) [22, 23, 29] entsteht ein neuer Aufgabenbereich, der höchste Zuverlässigkeit, Datenkonsistenz, Fehlertoleranz und Ausfallsicherheit erfordert. x-by-wire-systeme bezeichnen elek- 25

34 Lars Wienbrandt Abbildung 2: Bussysteme eines Mittelklassefahrzeugs tronische Systeme, die sicherheitsrelevante, vorher mechanisch oder hydraulisch gelöste Aufgaben, wie z.b. Bremsen oder Lenkung im Automobil, ersetzen sollen. In der Automobilindustrie liegt die Anwendung noch in der Zukunft, aber im Flugzeug wird fly-by-wire schon länger verwendet (s. Kapitel SAFEbus). Dieses Dokument soll einen Überblick über die Vielfalt von Bussystemen, mit besonderem Augenmerk auf Echtzeitbussysteme, geben. In Kapitel 2 werden Klassifizierungen von Bussystemen vorgestellt. Anhand der beschriebenen Kriterien werden dann eine Reihe von Bussystemen in die jeweiligen Klassen eingeteilt. In den darauffolgenden Kapiteln soll dann ein erweiterter Einblick in ausgewählte populäre Echtzeitbussysteme gegeben werden. Auf eine detaillierte Beschreibung der Protokollspezifikation und der physikalischen Ebene soll allerdings verzichtet werden. Stattdessen wird ein Überblick über das Systemverhalten und Eigenschaften des Bussystems gegeben. Außerdem wird die Verwendung der Bussysteme in der Wirtschaft beschrieben. 2. KLASSIFIZIERUNG VON ECHTZEIT- BUSSYSTEMEN Die Society of Automotive Engineering (SAE [30, 11]) hat im Jahr 2002 eine Klassifizierung von Bussystemen zur Verwendung im Automobil vorgestellt. Sie teilt die Bussysteme anhand ihrer Bandbreite und ihrem Anwendungsbereich in drei Klassen ein. Die Klassifizierung wurde inoffiziell noch durch weitere Klassen erweitert [16, 30, 11, 12]. Die Klasseneinteilung ist nicht eindeutig und die Grenzen fließend. Einige Bussysteme können also durchaus in mehreren Klassen vertreten sein. Im Folgenden sei die originale Klasseneinteilung der SAE beschrieben. Klasse A: Bussysteme, deren Bandbreite nicht größer als 10kB/s ist, werden in diese low-speed-klasse eingeteilt. Diese Bussysteme kommen hauptsächlich in der Karosserieelektronik, z.b. zur Ansteuerung der Beleuchtung oder anderer Aktuatoren, wie elektr. Fensterheber, Scheibenwischer usw., zum Einsatz. Maßgeblich für Klasse-A-Bussysteme ist die Eigenschaft nicht für sicherheitskritische und -gefährdende Aufgaben geeignet zu sein. Insbesondere sind diese Bussysteme nicht echtzeitfähig, dafür sollen sie im Niedrigpreisbereich (bis 4US-$ pro Knoten, [21]) liegen. Ein typischer Vertreter ist z.b. LIN (s. Kapitel 3.2) [19]. Klasse B: Für Klasse-B-Bussysteme wird eine Bandbreite zwischen 10kB/s und 100kB/s genannt. Deren Anwendungsbereich ist genereller Informationstransfer, wie z.b. Instrumentenanzeige, Geschwindigkeitsmessung usw. Auch diese Bussysteme sind generell nicht echtzeitfähig oder für sicherheitskritische Aufgaben geeignet, allerdings verfügen sie bereits über eine Absicherung gegen Fehler, wie Redundanz oder Abschalten fehlerhafter Knoten. Die Preise liegen mit ca. 5US-$ pro Knoten etwas höher als in der Klasse A [21]. Hier ist z.b. CAN /B (low speed CAN ) [6, 4] ein typischer Vertreter (s. Kapitel 3.1). Klasse C: Dies stellt die Klasse der echtzeitfähigen Bussysteme dar, deren Bandbreite höher als 100kB/s sein muss. Sie werden je nach Anforderungen auch in sicherheitskritischen Systemen eingesetzt. Die Aufgabenbereiche sind z.b. allg. Fahrdynamik, wie Antriebssteuerung, ABS, ESP, und die für die Zukunft relevanten x-by-wire-systeme. Dies stellt auch die höchste Preisklasse mit Kosten ab 10US-$ pro Knoten dar. Ein Vertreter ist beispielsweise CAN /C (high speed CAN ) [6, 4] (s. Kapitel 3.1). Diese Einteilung der SAE unterteilt bereits nach wichtigen Kriterien. Wie bereits erwähnt, wurde diese Einteilung, vor allem die Klasse C, noch erweitert um damit deutlichere Grenzen zu schaffen. Das Hauptkriterium bleibt weiterhin die Bandbreite. Es entstehen zwei zusätzliche Klassen (Klasse D und Multimedia). Klasse C beinhaltet daher nur noch Bussysteme bis zu einer Bandbreite von 1MB/s. Die beiden neuen Klassen seien im Folgenden beschrieben. Klasse D: Diese Klasse wird auch C+ genannt. Sie repräsentiert echtzeitfähige Bussysteme mit hohen Fehlertoleranz- und Fehlerbehandlungseigenschaften mit einer Bandbreite von 1MB/s bis 10MB/s für sicherheitskritische Aufgaben, wie z.b. x-bywire. Typische Vertreter sind hier nun FlexRay [10] 26

35 Echtzeitbussysteme im Überblick und TTP [27]. Des Weiteren werden Infotainment- Anwendungen, d.h. Anwendungen, die eine nicht so hohe Bandbreite, wie Multimedia-Anwendungen benötigen und auch nicht über Echtzeitfähigkeit verfügen müssen, im Zusammenhang mit Klasse D genannt. Multimedia: Hier werden alle Bussysteme eingeteilt, welche nicht zwangsweise über Echtzeitfähigkeit verfügen müssen. In erster Linie ist eine hohe Bandbreite von mehr als 10MB/s erforderlich. Sie werden daher hauptsächlich im Multimedia-Bereich angewendet, welcher zumeist hohe Datenraten erfordert. Typische Vertreter sind hier z.b. MOST, Ethernet, USB 2.0 oder FireWire. In Tabelle 1 sind alle Klassen in einer Übersicht aufgeführt. Außerdem werden noch weitere Bussysteme diesen Klassen zugeordnet. Abbildung 3 [11] zeigt bildlich das Verhältnis von steigenden Bandbreiten zu steigenden Kosten pro Netzwerkknoten anhand weniger Beispielbussysteme. Eine Einteilung, die hier behandelt wurde dient aber nur der groben Orientierung, da die Klassifikation zu sehr mit der Datenrate zusammenhängt. Einige Bussysteme unterstützen allerdings je nach physikalischer Ebene verschiedene Bandbreiten (wie z.b. TTP - s. Kapitel 3.4). Eine grobe Einteilung in die jeweiligen Aufgabenbereiche erscheint daher sinnvoller (s. dazu Abbildung 2). Eine allgemeingültige Klassifizierung, die wirklich alle Bussysteme exakt erfasst, scheint nicht zu existieren. Im Folgenden sollen nun einige ausgewählte Bussysteme genauer beschrieben werden. Dazu gehören LIN, CAN mit Modifikation TTCAN, Realtime-Ethernet am Beispiel Ethernet Powerlink, TTP, byteflight, FlexRay und SAFEbus. Hierbei werden an geeigneter Stelle auch Ähnlichkeiten oder Unterschiede zwischen einigen Systemen angesprochen. 3. AUSGEWÄHLTE BUSSYSTEME 3.1 Der CAN-Bus Allgemein CAN (Controller Area Network) im Allgemeinen ist klassenübergreifend. Es gibt eine low-speed-variante in Klasse B und eine high-speed-variante in Klasse C. Es wurde bereits 1983 von BOSCH zur allgemeinen Vernetzung elektrischer Systeme im Automobil entwickelt [4] stellte BOSCH den Standard CAN2.0 vor und 1992 entstand die CiA (CAN in Automation) [6], eine Gruppierung internationaler Nutzer und Hersteller, die sich zur Weiterentwicklung des CAN -Protokolls zusammengeschlossen hat. In diesem Jahr wurde CAN auch zum ersten Mal in einem Automobil eingesetzt veröffentlichte die CiA das CAN - Protokoll als ISO-Standard. Heute wird CAN auch in vielen anderen Industriezweigen für Automatisierungs- und Kontrollanwendungen verwendet und ist mittlerweile in fast jedem europäischen PKW vorhanden waren bereits über 50 Millionen CAN -Knoten installiert [20]. Aktuell wird in der Automobilindustrie noch CAN in sicherheitsunterstützenden Systemen, wie Airbag-Controller, ABS und ESP eingesetzt [11]. Aufgrund immer höherer Sicherheitsanforderungen wird es in diesen Anwendungsberei- Abbildung 4: Anwendung von CAN chen allerdings allmählich durch schnellere, sicherere und zuverlässigere Bussysteme wie FlexRay oder TTP (Kapitel 3.6 und 3.4) ersetzt [10, 26]. Auch im Komfort-Bereich (elektr. Fensterheber, Tür, Klimaanlage usw.) wird CAN langsam aufgrund der niedrigen Anforderungen durch das billigere, aber nicht so schnelle LIN (s. Kapitel 3.2) ersetzt [25]. In der Automatisierungs- und Kontrolltechnik bleibt CAN ein populäres Bussystem [20]. Durch die Einfachheit des Protokolls, der Offenlegung des Standards und die lange Präsenz auf dem Markt sind CAN -Controller von vielen verschiedenen Anbietern verfügbar und garantieren dadurch weiterhin niedrige Preise und Beständigkeit auf dem Markt. Über 40 Halbleiter-Firmen, darunter Intel und Philips, stellen CAN - Controller her. Abbildung 4 [11] zeigt die Verwendung von CAN am Beispiel eines PKW Kommunikation Für CAN gibt es verschiedene Spezifikationen. Es gibt lowspeed- und high-speed-can, jeweils in zwei verschiedenen Protokollversionen. Des Weiteren gibt es TTCAN, welches in Kapitel genauer beschrieben wird. Low-speed und high-speed Systeme unterscheiden sich durch die Art, wie der CAN -Controller den Bus ansteuert, welcher in der Regel aus zwei Leitungen (CAN low und CAN high) besteht. Man unterscheidet zwischen rezessiven und dominanten Bits. Durch die unterschiedlichen Darstellungen von rezessiven und dominanten Bits bei low- und high-speed- CAN werden beim ersten eine bessere Redundanz, allerdings auf Kosten der Geschwindigkeit, erreicht [12]. Low-speed-CAN erreicht eine Bandbreite von maximal 125kB/s, während für high-speed-can ein Maximum von 1MB/s angegeben wird. Die Bandbreiten hängen hier allerdings stark von der Buslänge ab. high-speed-can erreicht die maximale Bandbreite beispielsweise nur bei einer Buslänge von bis zu 40m. Bei ca. 500m Buslänge liegt die maximale Datenrate bei nur noch 125kB/s [20, 4]. Ein Nachrichtenfenster bei CAN enthält neben einem Identifier, der gleichzeitig die Priorität für die Busarbitrierung darstellt, diverse weitere Informationen zur enthaltenen Nachricht, u.a. Protokollversion, Menge der Daten, sowie ein 15-Bit-Fehlercode (CRC ). Die eigentlichen Daten dürfen dabei lediglich zwischen 0 und 8Byte belegen [20]. Der große Kommunikationsoverhead gegenüber der Nutzdaten reduziert die effektive Bandbreite auf fast die Hälfte der eigentlich verfügbaren. 27

36 Lars Wienbrandt Klasse (SAE) Bitrate Vertreter Anwendungen A bis 10kB/s LIN, J1850 Karosserieelektronik B 10kB/s bis 100kB/s CAN /B (low speed CAN ), ARINC-429 Instrumentierung C 100kB/s bis 1MB/s CAN /C (high speed CAN ), TTCAN, INTERBUS, echtzeitkritische Anwendungen, Bluetooth langs. Datenübertragung D 1MB/s bis 10MB/s FlexRay, TTP, byteflight, SAFEbus, PROFIBUS, echtzeitkritische Anwendungen, langs. Ethernet, USB 1.1 Infotainment, x-by-wire Multimedia ab 10MB/s MOST, FireWire, USB 2.0, D2B, Multimedia-Anwendungen, Ethernet, Realtime-Ethernet (Ethernet Powerlink) schnelle Datenübertragung Tabelle 1: Klassifizierung von Bussystemen Abbildung 3: Klassifikation nach Übertragungsrate/Kosten Da CAN ereignisgesteuert ist, besteht die Möglichkeit, dass mehrere Knoten gleichzeitig eine Nachricht senden möchten. Der Buszugriff erfolgt nach CSMA/CD-Prinzip (Carrier Sense Multiple Access with Collision Detection). Die Arbitrierung geschieht also wie folgt: Die Knoten senden gleichzeitig ihren Identifier und beobachten dabei den Buspegel. Sollte der Pegel nicht dem von einem Knoten gesendetem Bit entsprechen, so tritt dieser von seinem Sendewunsch zurück. Nach dem Senden des Identifiers steht also fest, welcher Knoten den Bus zu diesem Zeitpunkt für sich allein beanspruchen darf. Eine Kommunikation funktioniert also nach dem Broadcasting-Prinzip. Alle Knoten empfangen die gesendete Nachricht und entscheiden für sich, ob sie die Nachricht verwenden, oder nicht. Damit bei vielen gleichen Bits, die in einer Nachricht aufeinander folgen, die Synchronisation nicht verloren geht, wird ein sog. Bit-Stuffing eingeführt. Hierbei wird nach fünf gleichen aufeinanderfolgenden Bits ein weiteres komplementäres Bit eingefügt. Dies wird für die Applikation transparent vom CAN -Controller ausgeführt und beim Empfänger ebenso transparent rückgängig gemacht Fehlertoleranz und -behandlung Das CAN -Bussystem verfügt über eine eigene Fehlererkennung und -signalisierung auf Protokollebene. So vergleicht z.b. jeder Knoten die mitgesendete Prüfsumme (CRC ) einer Nachricht mit der selbst errechneten. Des Weiteren beobachtet jeder sendende Knoten den Buspegel (Monitoring) und kann daher Differenzen zwischen gesendetem und empfangenen Bit feststellen. Ein lokal am Sender oder global auftretender Bitfehler kann daher sicher erkannt werden. Mit Hilfe des Bit-Stuffings [20] können Fehler den anderen Knoten bekannt gemacht und das Senden einer Nachricht abgebrochen werden. Dazu wird ein sog. Error-Flag gesendet, welches nicht den Konventionen des Bit-Stuffings genügt, also mehr als fünf aufeinanderfolgende gleiche Bits enthält. Die Annahme der Nachricht von anderen Knoten wird dadurch verhindert und eine Datenkonsistenz auf dem Bus sichergestellt. Ein aufgetretener Fehler kann also nicht korrigiert werden. Der Sender muss also nach dem Abbruch erneut beginnen die Nachricht zu senden (Automatic Repeat Request) [20]. Leider gibt es durch die Ereignissteuerung und der Prioritätenvergabe einen entscheidenden Nachteil des CAN - Busses. Ein hochpriorer Sender kann durch schnelles Hintereinanderauftreten von Ereignissen den Bus vollständig blockieren. Dieses Fluten hat zur Folge, dass kein anderer Knoten mehr Informationen senden kann. Latenzzeiten sind demnach nicht mehr garantiert, was das Fehlen der Echtzeitfähigkeit bei CAN begründet. Um dieses Problem zu umgehen, wurde CAN zu TTCAN erweitert, welches im Folgenden beschrieben wird Modifikation des CAN-Bus: TTCAN TTCAN [13] wurde im Jahr 2000 als Erweiterung zum bestehenden CAN entwickelt und ist ebenfalls als freier Standard verfügbar. Ziel ist es, auch bei maximaler Busauslastung alle wichtigen Nachrichten mit vorhersagbarer Latenzzeit zu übertragen. Um kompatibel zu bleiben, setzt TT- CAN auf die physikalische Ebene von low-speed-can oder high-speed-can auf und erhält damit die alte Bandbreite. TTCAN ist sowohl zeit- als auch ereignisgesteuert. Für die 28

37 Echtzeitbussysteme im Überblick Zeitsteuerung sind nun sog. Basic Cycles eingeführt worden, die mit einer Referenznachricht beginnen, welche zur Synchronisation dient. Danach folgen verschiedene vom Nutzer vordefinierte Zeitfenster, die bestimmten Nachrichten von bestimmten Knoten zugeordnet sind. Im Unterschied zu CAN dürfen Knoten nun lediglich in den ihnen zugeordneten Zeitfenstern senden. Allerdings gibt es noch sog. Arbitration-Fenster, in denen ereignisgesteuerte Nachrichten nach bekanntem Prinzip gesendet werden dürfen. Auch freie Fenster können eingebaut werden, in denen der Bus zunächst ungenutzt bleibt. Sie können später, z.b. nach dem Einfügen neuer Knoten ins Netzwerk, neu definiert und damit in ein nachrichtenspezifisches oder Arbitration-Fenster umgewandelt werden. Aus mehreren verschiedenen aber gleich langen Basic-Cycles kann eine System-Matrix aufgebaut werden, welche sich im Laufe der Kommunikation ständig wiederholt. Jeder Knoten muss aus dieser System-Matrix lediglich die für ihn interessanten Stellen wissen, d.h. die Stellen, wo die für ihn eingerichteten Zeitfenster, die Arbitration-Fenster und die Zeitfenster der Nachrichten sind, die er empfangen möchte. Um das gesamte System nun zu synchronisieren wird ein Zeitmaster-Knoten benötigt. Dieser sendet zu Beginn eines jeden Basic-Cycles die Referenznachricht, welche In- formationen zur globalen Zeit enthält. Um fehlertolerant gegenüber einem Ausfall des Zeitmasters zu sein, können mehrere potentielle Zeitmaster im System eingesetzt werden. Die Zeitmaster haben allgemein die höchste Priorität im System um konform mit dem darunterliegendem CAN - Protokoll zu bleiben. Fällt ein Zeitmaster aus, beginnen die anderen, nach einem kleinen Timeout hinter dem eigentlichem Beginn der erwarteten Referenznachricht, eine erneute Referenznachricht zu senden. Hier gewinnt derjenige, der die höchste Priorität hat und ist ab diesem Zeitpunkt der neue Zeitmaster. Ein weiterer Unterschied von TTCAN zu CAN ist, dass bei fehlerhaften Nachrichten nicht sofort versucht wird, die gleiche Nachricht erneut zu senden, weder im eigenen Zeitfenster, noch im Arbitration-Fenster. Das Prinzip des Automatic Repeat Request ist hier nicht erlaubt. 3.2 Der LIN-Bus Allgemein LIN steht für Local Interconnect Network. Es ist ein typische Vertreter für Klasse-A-Bussysteme. Die Entwicklung begann 1998 unter Zusammenschluss einiger Firmen, dem LIN -Konsortium, bestehend aus den Automobilherstellern Audi, BMW, Daimler-Chrysler, Volvo und Volkswagen, dem Werkzeughersteller VCT und dem Halbleiterhersteller Motorola. Mittlerweile zählt das Konsortium neben den eben genannten noch weitere 63 assoziierte Mitglieder dazu, darunter vor allem weitere namhafte europäische Automobilhersteller [19]. Ziel war es ein Bussystem zu schaffen, welches einfach zu bedienen, ein offener Standard und billiger als z.b. CAN ist. Damit sollte erreicht werden, dass standardisierte Schnittstellen und Komponenten erhältlich sind, funktionale Erweiterungsmöglichkeiten und mehr Funktionalität bei klei- Abbildung 5: single-master/multiple-slave-konzept im LIN nerem Preis vorhanden sind. LIN soll überall dort zum Einsatz kommen, wo die Leistung, Bandbreite und Vielseitigkeit von CAN nicht benötigt wird [28, 25]. Dies betrifft z.b. die Karosserieelektronik im Automobil, wie die Lichtanlage, Scheibenwischer, elektr. Fensterheber, Sitzverstellung, Außenspiegelverstellung, Schlossverriegelung usw. LIN wird daher auch als Sub-Bus bezeichnet, da seine Daten meist mit einem darüberliegenden Bussystem, wie z.b. CAN, ausgetauscht werden [25] Kommunikation Der LIN -Bus benutzt das single-wire-prinzip, besitzt also nur eine Datenleitung. Er hat eine Bandbreite von maximal 20kB/s, welche aber i.a. nicht ausgeschöpft wird, denn die unterstützten Anwendungen benötigen weitaus weniger. LIN ist zeitgesteuert und setzt auf das single-master/multipleslave-konzept. Es gibt also nur einen Master-Knoten, der für die Synchronisation im Bus zuständig ist. Die Slave- Knoten synchronisieren sich anhand eines vom Master verschickten Synchronisationsimpulses. Bis auf einen für den Master werden also keine Quarz- oder Keramik-Resonatoren benötigt, was weitere Kosteneinsparungen zur Folge hat. Die Synchronisation funktioniert auf diese Weise allerdings nur aufgrund der niedrigen Datenrate genau genug. Des Weiteren kann auch ein Masterknoten als Slave fungieren. Abbildung 5 zeigt ein typisches single-master/multiple-slave- Konzept. In einem LIN -Bussystem werden normalerweise 2 bis 12 Knoten angeschlossen, obwohl die Anzahl nicht dadurch begrenzt ist. Maximal sind in einem System 64 Identifier möglich. Durch das zeitgesteuerte Verhalten muss also für jeden Knoten ein eigenes Zeitfenster offen stehen, damit es zu keinen Kollisionen auf dem Bus kommt. Der Master besitzt hierzu eine Scheduling-Tabelle, in der die Identifier der angeschlossenen Slave-Knoten in beliebiger Reihenfolge stehen, in der sie Nachrichten schicken dürfen. Die Kommunikation und Synchronisation auf einem LIN -Bus ist nachfolgend beschrieben. Der Master-Knoten führt einen sog. Master-Task aus. Weiterhin kann er, wie die anderen Slave-Knoten, einen Slave- Task ausführen. Der Master-Task markiert den Anfang jeder Kommunikation und hat folgenden Ablauf. Der Master schickt ein Sync Break und ein Synchronisationsbyte, welches nur der Synchronisation mit den Slave-Knoten dient und zunächst keine Daten enthält. Danach wird ein 6-Bit- Identifier geschickt, der mit zwei Paritätsbits abgesichert ist. Der Identifier bezeichnet den Knoten, der nun senden darf. 29

38 Lars Wienbrandt Als nächstes wird nun erwartet, dass der aufgerufene Slave- Knoten seine Nachricht verschickt. Dieser Vorgang ist im Slave-Task eingebunden. Jeder Knoten synchronisiert sich zunächst anhand dem vom Master verschickten Sync Break und Synchronisationsbyte. Danach wird der vom Master gesendete Identifier analysiert. Abhängig vom Identifier muss nun der aufgerufene Knoten seine Nachricht versenden. Alle anderen können diese Nachricht empfangen oder auch einfach nichts tun. Da die Länge einer Nachricht auf bis zu 8 Byte begrenzt ist, kann also eine garantierte Latenzzeit angegeben werden. Diese beträgt bei LIN maximal 100ms. Der gesamte Kommunikationsvorgang lässt sich ebenfalls aus Abbildung 5 entnehmen Fehlertoleranz und -behandlung LIN verfügt wegen seiner Einfachheit nicht über umfangreiche Fehlerbehandlungsroutinen. Lediglich das Identifier-Feld wird mit zwei Prüfbits und die eigentlichen Daten mit einer Prüfsumme versehen. Außerdem erkennt der Master, falls ein Knoten oder sogar der ganze Bus ausfällt. Was in diesem Fall getan werden soll obliegt aber der dem Master übergeordneten Anwendung. Das LIN -Protokoll stellt hierfür keine Fehlerbehandlungsroutinen zur Verfügung. 3.3 Realtime-Ethernet am Beispiel Ethernet Powerlink Allgemein Das Ethernet gehört heute zu den meist genutzten Kommunikationsmedien im LAN-Bereich. Offene und einfache Protokollstrukturen haben es dazu gebracht. Wegen der weiten Verbreitung und großer Herstellervielfalt ist entsprechende Hardware sehr kostengünstig. Für Echtzeitanwendungen ist Ethernet an sich allerdings nicht geeignet. Durch die Möglichkeit von Buskollisionen und Schlangenbildung kann schon eine maximale Latenzzeit nicht garantiert werden. Um Ethernet echtzeitfähig zu machen, gibt es viele verschiedene Ansätze. Alle Ansätze können allerdings in drei Kategorien eingeteilt werden [9]. Top of TCP/IP: Das Top of TCP/IP Konzept führt Veränderungen lediglich auf der Applikationsebene durch. Die Kommunikation erfolgt wie beim Standard-Ethernet über TCP/IP. Der Nachteil ist, dass auch hier Kollisionen und Schlangenbildung auftreten können, welche durch weitere Konzepte, wie z.b. predictable Ethernet verhindert werden müssen. Top of Ethernet: Beim Top of Ethernet Konzept wird direkt auf das Ethernet-Protokoll zugegriffen. Die Kommunikation erfolgt nicht mehr über TCP/IP sondern über einen eigenen Protokolltyp, welches in einen Ethernet-Frame eingebunden wird. Der Vorteil ist, dass keine eigene Hardware benötigt wird und auf die bereits bestehende kostengünstige Hardware zurückgegriffen werden kann. Ethernet Powerlink, welches im Folgenden genauer erläutert werden soll, setzt auf dieses Konzept auf. Abbildung 6: Ein Zyklus in Ethernet Powerlink Modified Ethernet: Dieses Konzept verändert die Ethernet-Ebene. Der Nachteil ist, dass nun nicht mehr bestehende Hardware genutzt werden kann. Es müssen eigene Hardwarelösungen entwickelt werden. Dies spiegelt sich meist in höheren Kosten wider. Wie nun eine deterministische Nachrichtenübertragung zu gegebenen Latenzzeiten erreicht wird, soll im Folgenden am Beispiel von Ethernet Powerlink kurz beschrieben werden. Ethernet Powerlink wurde im Jahr 2001 von der österreichischen Firma Bernecker + Rainer (B&R) zur Verwendung in der Antriebs- und Automatisierungstechnik entwickelt und im Jahr 2002 in Kooperation mit der Züricher Hochschule Winterthur frei verfügbar gemacht [24]. Durch Gründung der Ethernet Powerlink Standardization Group (EPSG [8]) wurde auch anderen Interessenten die offene und freie Weiterentwicklung ermöglicht. Die Forderungen an Ethernet Powerlink sind neben der Echtzeitfähigkeit kostengünstige Hardware und Wartung, sowie Kompatibilität zum Standard-Ethernet und Geschwindigkeit Kommunikation Die Kommunikation funktioniert bei Ethernet Powerlink im Zeitschlitzverfahren nach dem single master/multiple slave- Konzept, ähnlich wie bei LIN (s. Kapitel 3.2). Ein Masterknoten übernimmt das Netzwerkmanagement und steuert die anderen Teilnehmer in festen Kommunikationszyklen. Ein Zyklus hat immer die gleiche Dauer und wird in zwei Bereiche, den isochronen und den asynchronen Teil, fest eingeteilt. Die Kommunikation beginnt mit einem Aufruf des Masters an alle Knoten zur Kennzeichnung des Starts eines Zyklus. Dies geschieht über eine Broadcast-Nachricht. Die Knoten müssen sich nun zum Senden bereit halten. Der Master fordert nun im isochronen Teil die entsprechenden Knoten per Polling auf zu Senden. Der aufgeforderte Knoten darf nun seine Nachricht senden, welches ebenfalls per Broadcast passiert. Dadurch kann die Nachricht von jedem Teilnehmer, der sie benötigt, gleichzeitig empfangen werden. Ein Beispiel für einen Ethernet Powerlink-Zyklus ist in Abbildung 6 [17] dargestellt. Durch das Polling werden Kollisionen verhindert und eine Schlangenbildung vermieden, und die Nachrichten treffen bei einem voll funktionsfähigen Bus zu garantierten Latenzzeiten und kleinem Jitter ein. Nach dem isochronen Teil folgt der asynchronen Teil. Der Master informiert die anderen Knoten darüber mit Hil- 30

39 Echtzeitbussysteme im Überblick fe einer weiteren Broadcast-Nachricht. Die Kommunikation im asynchronen Teil ermöglicht die Kompatibilität zum Standard-Ethernet und die Integration von TCP, UDP Fehlertoleranz und -behandlung Ethernet Powerlink besitzt an sich über keine Fehlerbehandlungsmaßnahmen. Dies wird vollständig der darüberliegenden Applikation überlassen. Lediglich eine Fehlererkennung über einen CRC ist möglich. Ein weiteres Problem stellt die mangelnde Absicherung gegen Fehler dar. Buskollisionen oder garantierte Latenzzeiten können nur garantiert werden, wenn die Länge einer zu sendenden Nachricht dem Master bekannt ist. Ist eine Nachricht länger als erlaubt, kommt es unvermeidlich zur Kollision. Auch ein Sender, der eine Aufforderung des Masters ignoriert und zu einem beliebigen Zeitpunkt sendet, kann eine Kollision bewirken. Es sind keine Buswächter hierfür vorgesehen. Weiterhin stellt die Master/Slave-Struktur an sich eine Gefahr dar. Die korrekte Funktion des Busses ist von der korrekten Funktion des Masters abhängig. Bei Ausfall des Masters muss entweder eine redundante Einheit die Aufgaben übernehmen oder es kommt zu keiner Kommunikation mehr auf dem Bus. 3.4 Das TTP-Protokoll Allgemein Das TTP (Time Triggered Protocol) wurde an der TU Wien entwickelt. Erste Implementierungen gab es bereits Dann gründeten die Beteiligten 1998 die Firma TTTech [27], in der die Entwicklung einer TTA (Time Triggered Architecture), in welcher TTP der wesentliche Bestandteil ist, bis heute weitergeführt wird. TTP sollte den höheren Sicherheitsanforderungen im Automobil, z.b. für x-by-wire- Systeme [29] gerecht zu werden und schließlich CAN als Bussystem für sicherheitskritische und -gefährdende Systeme ablösen. Um trotzdem eine Kompatibilität zu gewährleisten, existiert die Möglichkeit CAN auf TTP zu emulieren. TTP wird derzeit beispielsweise bei Audi und Volkswagen in der Automobilindustrie verwendet, doch auch für den Einsatz im Flugzeug ist TTP interessant. Honeywell wendet es beispielsweise für Flugzeugelektronik und -kontrollsysteme an. TTP ist ein zeitgesteuertes Protokoll, welches über gute Echtzeiteigenschaften und Fehlertoleranz verfügt und damit höchste Sicherheitsanforderungen erfüllen soll. TTP gibt es in zwei Varianten, TTP/A und TTP/C [26], wobei TTP/A lediglich eine im Funktionsumfang reduzierte Variante von TTP/C ist. Die Bandbreite hängt von der verwendeten physikalischen Ebene ab, welche nicht im Protokoll definiert wird. Je nach der darüberliegenden Architektur (der TTA) gibt es derzeit Implementierungen von bis zu 25MB/s, während bereits Forschungsprojekte für Raten von über 1GB/s laufen [23]. Das Protokoll unterstützt bis zu vierfache Redundanz und kann sowohl in Bus- oder Stern-Topologie realisiert werden. Außerdem unterstützt TTP Zusammensetzbarkeit (Composability), d.h. Komponenten können unabhängig voneinander getestet und dann zusammengefügt werden [18, 22]. Allerdings ist es schwierig neue Knoten in ein bereits bestehendes System zu integrieren, da jeder Knoten neu konfiguriert werden muss, um die Informationen zu den neuen Knoten zu erhalten Kommunikation Die Kommunikation erfolgt in sog. TDMA-Runden (Time Division Multiple Access), die einen Kommunikationszyklus beschreiben. Eine TDMA-Runde ist in Zeitfenster (Instanzen) unterteilt, in der verschiedene Knoten die Möglichkeit bekommen eine Nachricht zu versenden. Allerdings gibt es analog zur System-Matrix bei TTCAN einen sog. Cluster Cycle, welcher mehrere verschiedene TDMA-Runden enthält, die nacheinander abgearbeitet werden und anschließend von vorne beginnen. Ein Zeitfenster muss der Größe des N-Frames entsprechen, der in diesem Zeitraum gesendet werden soll. Ein N-Frame enthält die zu versendende Nachricht. Eine Nachricht kann zwischen 2 und 240 Byte groß sein. Jeder TTA-Knoten verfügt über eine Message Descriptor List, kurz MEDL, in welcher alle Aktionen, die im System durchgeführt werden sollen, aufgeführt sind. Dies sind der Sendezeitpunkt (Sendeinstanz) und die Adresse im sog. Communication Network Interface (CNI ) einer zu sendenden Nachricht, außerdem die Empfangszeitpunkte und Adressen der abzulegenden Nachrichten. Das CNI (Communication Network Interface) stellt eine reine Datenschnittstelle zur Anwendung dar. Der TTA-Knoten schreibt und liest aus dieser Schnittstelle die Nachrichten entsprechend den Einträgen in der MEDL. Die Anwendung auf der anderen Seite verfährt genau anders herum. So bleibt das TTP-Protokoll für den Anwender transparent. Um auch eine ereignisgesteuerte Kommunikation zu ermöglichen, können Zeitfenster in einer TDMA-Runde für ereignisgesteuerte Nachrichten freigehalten werden. Diese können dann z.b. nach CAN -Standard übertragen werden. TTP selbst sieht keine Ereignissteuerung vor Synchronisation Bei TTP/C verfügt jeder Knoten im Netzwerk über seine eigene lokale Uhr. Vor dem Beginn einer Kommunikation müssen diese also synchronisiert werden, damit nicht zwei Knoten gleichzeitig schreibend auf den Bus zugreifen. Zur Businitialisierung wird dazu ein I-Frame von einem beliebigen Knoten gesendet. Dieser I-Frame dient ausschließlich der Initialisierung oder einer Resynchronisation. Empfängt ein Knoten einen I-Frame, so synchronisiert er sich anhand dieser Information. Danach beginnt die Kommunikation mit der ersten TDMA-Runde. Während des Betriebes synchronisieren sich die Knoten anhand der Differenz des erwarteten Zeitpunktes einer empfangenen Nachricht und dem tatsächlichen Eintreffen. Bei TTP/A verläuft die Kommunikation nach einem Master-Slave-Prinzip. Ein Master spricht über Polling die Slaves an, welche nur nach Aufforderung reagieren. 31

40 Lars Wienbrandt Fehlertoleranz und -behandlung TTP unterstützt umfangreiche Mechanismen zur Fehlerbehandlung. Zur Überwachung der Kommunikation stellt eine TTA Buswächter zur Verfügung. Je nach eingesetzter Topologie besitzt jeder Knoten seinen eigenen Buswächter (Bus-Topologie), oder ein Buswächter überwacht den gesamten Bus (Stern-Topologie). Letzteres hat den Vorteil, dass Buswächter und Knoten auch physikalisch voneinander getrennt sind. Buswächter haben die Aufgabe den Bus vor unerlaubten Kommunikationen zu schützen. Dazu haben sie ihre eigene MEDL und ihre eigene lokale Uhr. Sie öffnen für einen Knoten ein Zeitfenster also nur dann, wenn es ihm auch erlaubt ist, eine Nachricht zu senden. Hiermit wird vor allem das Problem des babbling idiot vermieden. Der babbling idiot ist ein Knoten, der aufgrund eines Fehlers ständig Nachrichten sendet, ohne sein Zeitfenster abzuwarten. Des Weiteren sind in jedem Knoten Membership-Infos über jeden anderen Knoten enthalten. Jeder Knoten sucht nach dem Senden eine Bestätigung bei den anderen Knoten. Kommt eine Nachricht nicht im richtigen Zeitfenster an, wird ein Fehler signalisiert. Außerdem findet eine CRC - Kalkulation und Überprüfung statt. Fehlerhafte Knoten werden isoliert, damit sie keine Behinderung von fehlerfreien Knoten darstellen. Dies geschieht einerseits durch die Buswächter und andererseits überprüft jeder Knoten seinen eigenen Zeit- und Wertebereich. Es besteht die Möglichkeit ein TTP-System redundant aufzubauen, d.h. ein Softwaresubsystem kann auf zwei Fail- Silent-Knoten repliziert werden. Die Entscheidung über einen Fehler geschieht dann nach TMR-Abstimmung (Triple Modular Redundancy). Eine redundante Einheit kann dann eine schadhafte Einheit übernehmen, ohne dass es auf der Funktionsebene bemerkbar ist. Dies stellt die Datenkonsistenz sicher. 3.5 Das byteflight-bussystem Allgemein 1996 beschloss BMW mit Motorola, ELMOS, Infineon und Tyco EC ein Bussystem für Automobile zu schaffen, welches eine höhere Datenrate und höhere Flexibilität als TTP (s. Kapitel 3.4) erlangt. Außerdem sollte es extrem zuverlässig, deterministisch und von geringer Störanfälligkeit sein. Ein weiterer wichtiger Punkt stellte das Ziel der einfachen Erweiterbarkeit dar. Es sollten neue Komponenten ohne große Schwierigkeiten in ein bestehendes Bussystem integriert werden können, ohne alle Knoten wie bei TTP neu konfigurieren zu müssen [3]. Auch hier ging die Motivation von den hohen Anforderungen der zukunftsorientierten x-by-wire-systeme aus, auch wenn sich herausstellen sollte, dass es aufgrund mangelnder Fehlertoleranzeigenschaften nur für passive Sicherheitssysteme geeignet ist. Aufgrund der begonnenen Weiterentwicklung von byteflight zu FlexRay [10], welche im September 2000 mit der Gründung des FlexRay-Konsortiums den entscheidenden Schritt tat, werden der Zukunft von byteflight als eigenständiges Produkt allerdings keine guten Chancen mehr ausgemalt [5]. Abbildung 7: byteflight Nachrichtenzyklen Kommunikation Die Kommunikation im byteflight-system geschieht über sog. FTDMA-Runden (Flexible Time Division Multiple Access). Sie erweitern das TDMA-Prinzip, bekannt aus TTP, um die Eigenschaft, dass nicht jedes Zeitfenster zwangsweise belegt sein muss. Außerdem stellt es ein einfache Möglichkeit ereignisgesteuerte Nachrichten zu verarbeiten zur Verfügung. Eine FTDMA-Runde läuft nun wie folgt ab. Jeder Knoten besitzt eine im System eindeutige ID im Bereich zwischen 1 und 255 und einen Zähler, den sog. Slot-Counter. Zu Anfang einer FTDMA-Runde sendet nun ein vorher als Sync- Master deklarierter Knoten einen Synchronisationsimpuls, welcher die Zähler synchronisiert. Dieser wiederholt sich bei einer Datenrate von 10MB/s alle 250µs. Die Zeit dazwischen entspricht einem Zyklus. In jedem Zyklus zählen die Slot-Counter in einer festgelegten Geschwindigkeit alle IDs durch. Erreichen die Zähler die ID eines Knotens, der eine Nachricht senden möchte, so stoppen die Zähler und die Nachricht wird gesendet. Danach zählen die Zähler weiter. Hierbei kann es natürlich sein, dass innerhalb eines Zyklus nicht alle IDs erreicht werden. Deswegen kann man die IDs mit Prioritäten vergleichen, Nachrichten mit niedrigerer ID, und damit höherer Priorität, können eher gesendet werden. Kann eine Nachricht in einem Zyklus nicht gesendet werden, so muss sie auf den nächsten Zyklus warten, der nicht so ausgelastet ist. Abbildung 7 [3] zeigt ein Beispiel verschiedener FTDMA-Runden. Die Länge einer Nachricht liegt bei maximal 12 Bytes zzgl. einiger Nachrichteninformationen sowie 2 Bytes CRC. Ein Start- und ein Stopp-Bit vor und nach jedem Byte dienen der Bitsynchronisation und garantieren dadurch einen Jitter, der kleiner als eine Bitdauer von 100ns ist. Wegen des relativ geringen Verhältnisses von maximaler Nachrichtendauer zur Zykluszeit garantiert das byteflight-protokoll also selbst bei vollausgelastetem Bus die Übermittlung der Nachrichten mit höchster Priorität mit festen Latenzzeiten. Außerdem lässt sich ein byteflight-system durch einfaches Hinzufügen neuer Knoten mit noch nicht verwendeten IDs leicht erweitern. Durch das Prinzip der FTDMA-Runden mit Prioritätenvergabe lässt sich ein byteflight-system also sehr vielseitig aufbauen. Es kann sowohl rein zeitgesteuert, rein ereignisgesteuert oder etwas von beiden sein Fehlertoleranz und -behandlung Die byteflight-spezifikation sieht, wie nur wenig andere Bussysteme und im Unterschied zu FlexRay, nur eine Vernetzung durch Glasfaserleitungen vor. Dies hat den Vorteil, dass sie elektromagnetisch vollkommen störunanfällig sind. Allerdings impliziert dies den Aufbau einer Stern-Topologie für das Bussystem. 32

41 Echtzeitbussysteme im Überblick byteflight bietet Fehlererkennungs- und -behandlungsroutinen für verschiedene Arten von Fehlern. Dazu gehören z.b. die Erkennung eines falschen Nachrichtenformates durch CRC und Überprüfung der Start- und Stopp-Bits, oder die Erkennung von Timing-Fehlern beim Synchronisationsimpuls. Nach Auftreten eines Übertragungsfehlers kann die Nachricht allerdings nicht sofort wieder gesendet werden. In diesem Fall muss der nächste Zyklus abgewartet werden. Des Weiteren sichert der Star-Coupler, die zentrale Einheit, die alle Busteilnehmer miteinander verbindet, den Bus wie ein Buswächter vor fehlerhaften Knoten, indem er sie abschaltet, falls er eine Verletzung des Nachrichtenformates oder die Belegung eines falschen Zeitfensters detektiert. Der Star-Coupler nimmt außerdem eine Überwachung der optischen Signalqualität vor. Die Installation weiterer dezentralisierter Buswächter ist möglich. Zusätzlich ist die Sicherheit des Sync-Masters von Bedeutung. Dazu kann beim Ausfall des Sync-Masters jeder andere Knoten ebenfalls als Sync-Master deklariert werden, welcher dann die Aufgabe des ersten abnimmt. Ein Sync- Master kann durch Veränderung des Synchronisationsimpulses einen fehlerhaften Buszustand anzeigen. Hiermit können z.b. bestimmte Sicherheitsfunktionen aktiviert werden. Auf den normalen Kommunikationsvorgang hat dies allerdings keinen Einfluss. Abschließend bietet byteflight zwar Mechanismen zur Erkennung von Fehlern und dem Abschalten fehlerhafter Knoten, allerdings gibt es keine Möglichkeiten Fehler zu tolerieren oder zu behandeln [21]. 3.6 Das FlexRay-Bussystem Allgemein Daimler Chrysler und BMW begannen 1999 die Weiterentwicklung byteflight und TTP zu FlexRay. Da byteflight aufgrund fehlender Fehlertoleranz- und -behandlungseigenschaften nicht für x-by-wire-systeme im Automobil geeignet scheint, soll FlexRay nun die Geschwindigkeit und Flexibilität von byteflight mit der Robustheit von TTP verbinden. Als Datenrate sind 10MB/s angestrebt, welche aber stark vom Physical Layer abhängt. Das Design des Protokolls erlaubt jedoch, dass auch höhere Datenraten erzielt werden können [10]. Das FlexRay-Konsortium, gegründet im September 2000, besteht mittlerweile aus den Kernmitgliedern BMW, Daimler Chrysler, Bosch, Freescale Semiconductor, General Motors, Philips und Volkswagen, sowie vielen weiteren assoziierten Mitgliedern. Das Konsortium hat keine direkten kommerziellen Interessen an FlexRay. Die Spezifikation soll daher frei verfügbar sein. Ein wichtiger Unterschied zu byteflight ist, dass die FlexRay- Spezifikation nicht mehr nur Glasfaser als Übertragungsmedium vorsieht. Dies ermöglicht den Aufbau verschiedener Topologien, in welcher Hinsicht FlexRay sehr flexibel gestaltet werden sollte. Eine weitere Erweiterung stellt das neu hinzugekommene Powermanagement dar. FlexRay-Knoten sollen nun verschiedene Power-Modes, wie Sleep, Standby und Normal, unterstützen. Zur Zeit werden für den Physical Abbildung 8: Zweikanal-Mischsystem bei FlexRay Layer hauptsächlich CAN -High-Speed-Transceiver benutzt [21] Kommunikation Jeder FlexRay-Knoten kann bis zu zwei Kommunikationskanäle nutzen. Diese sind einerseits zu Redundanzzwecken vorhanden, können allerdings mit bestimmten Einschränkungen auch unterschiedlich genutzt werden (z.b. zur Erhöhung der Datenrate). Um dies zu veranschaulichen, müssen zunächst die verschiedenen nach der Flex- Ray-Spezifikation möglichen Netzwerktopologien beschrieben werden. FlexRay-Knoten können fast beliebig untereinander vernetzt werden. Die Spezifikation sieht dabei vier grundlegende Arten vor:[7] passive bus: Bei einem passiven Bus sind alle Knoten über einen Bus miteinander verbunden. Diese Vernetzungsart ist die unsicherste, da ein einfacher Kurzschluss, z.b. am Verbindungsstecker, den gesamten Bus blockieren kann. active star: Ein aktiver Sternknoten bildet einen Verbindungsknoten der über einzelne Zweige die anderen Netzwerkknoten miteinander verbindet. Zweige können auch passive Busse (s.o.) sein. Ein Kurzschluss in einer Leitung blockiert damit nur ein Knoten oder Sub-Bus. cascaded stars: Es ist ebenfalls möglich mehrere aktive Sterne untereinander zu verbinden. Maximal sind dabei drei Stück möglich. dual channel: Wie schon erwähnt können FlexRay- Knoten zwei Kanäle verwenden. Jeder Kanal kann dabei separat behandelt werden, d.h. jeder Kanal kann Knoten über verschiedene Weisen untereinander verbinden. Auch der Mischbetrieb mit Ein- und Zweikanalknoten ist erlaubt. Die zwei Kanäle können redundant oder zur Vergrößerung der Übertragungsrate verwendet werden. Ein Beispiel mit einem Zweikanal- Mischsystem ist in Abbildung 8 [7] dargestellt. Das FlexRay-Protokoll sieht eine Einteilung eines Kommunikationszyklus in zwei Teile vor, einen Statischen und einen Dynamischen. Die Grenze zwischen beiden Teilen kann bei der Konfiguration beliebig gewählt werden. Es kann auch ein rein dynamisches oder rein statisches System geschaffen werden. Der statische Teil sieht eine Kommunikation auf Basis von TDMA-Runden, wie bei TTP (s. Kapitel 3.4), vor. Die Knoten bekommen also ein festes Zeitfenster (static slot), 33

42 Lars Wienbrandt in dem sie eine Nachricht senden dürfen. Der dynamische Teil funktioniert wie bei byteflight (s. Kapitel 3.5) auf Basis von FTDMA-Runden. Ein Zähler zählt verfügbare mini slots durch. Erreicht er eine ID eines Knotens, so darf dieser eine Nachricht versenden. Die IDs entsprechen also Prioritäten, denn ein Knoten mit geringerer ID darf eher senden. Im Zweikanalbetrieb können beide Kanäle auch unterschiedliche Daten übertragen. Hierbei gibt es allerdings Einschränkungen. Im statischen Teil müssen die Zeitfenster auf beiden Kanälen gleich sein. Nur im dynamischen Teil können verschiedene mini slots zur gleichen Zeit existieren. Eine Möglichkeit besteht darin, dass zwei Zähler, einer für jeden Kanal, die mini slots durchzählen. Existiert in einem Kanal ein Ein-Kanal-Knoten, der an einer Stelle sendet, so verschieben sich die Fenster auf beiden Kanälen (s. auch Abbildung 9) Synchronisation FlexRay benötigt für alle Knoten eine gemeinsame Zeitbasis. Die Synchronisation erfolgt in einem rein dynamischen System genau wie bei byteflight (s. Kapitel 3.5). In einem gemischten oder rein statischen System werden ähnlich wie bei TTP die Differenzen zwischen erwarteten und tatsächlichem Eintreffen einiger Nachrichten im statischen Teil gemessen. Bei einem Zweikanal-System werden nur Nachrichten berücksichtigt, welche in beiden Kanälen versendet werden. Danach werden die ersten k und letzten k Werte (k ist vordefiniert) gestrichen und aus den verbliebenen der Mittelwert berechnet (Fault Tolerant Midpoint) [2]. Hiermit wird in gewissem Maße eine korrekte Synchronisation selbst im Vorhandensein von fehlerhaften Knoten erreicht. Der errechnete Korrekturwert wird gleichmäßig in den nächsten Kommunikationsschritt eingebracht um die Stetigkeit der Zeitbasis zu gewährleisten. Optional ist auch eine externe Uhrensynchronisation möglich. Hierbei wird der lokale Korrekturwert durch einen globalen überlagert Fehlertoleranz und -behandlung Zur Sicherung der Kommunikation besitzt jeder Knoten einen Buswächter pro Kanal, die das Senden von Nachrichten nur in den dem Knoten zugeteilten Zeitfenstern und im dynamischen Teil ermöglichen. Außerdem überwachen sie die Uhrensynchronisation. Dazu besitzen Buswächter auch ihre eigene Zeitbasis um die Fehlerwahrscheinlichkeit bei der Synchronisation gering zu halten [7]. Im Gegensatz zu TTP besitzt FlexRay keine Membership- Informationen über die anderen Knoten um fehlerhafte Knoten auszuschließen. Außerdem bietet FlexRay auf Protokollebene keine Services über eine bestmögliche Datenübertragung hinaus, d.h. alle Mechanismen für fehlertolerante Applikationen müssen von den Applikationsprogrammen selbst bereit gestellt werden [22, 23]. Zur Fehlererkennung im Datenbereich dient ein 24-Bit-CRC. 3.7 Der SAFEbus Allgemein SAFEbus wurde von Honeywell für das Airplane Information Management System (AIMS) in der Boeing 777 entwickelt, welche erstmals 1995 zum Einsatz kommen sollte [15]. Die AIMS-Architektur besitzt zwei redundante Schaltschränke (cabinets), die sog. Line Replaceable Modules (LRMs) enthalten, welche alle wichtigen Funktionen im Flugzeug steuern, u.a. auch fly-by-wire-funktionen. Die Sensoren und Aktuatoren sind im Flugzeug verteilt und über sog. inter-unit-busse mit den cabinets verbunden. Die sicherheitskritischten Busse sind allerdings die Busse, die die LRMs innerhalb eines cabinets miteinander verbinden. Dies sind die intra-unit- oder backplane-busse. Sie müssen über höchste Datenintegrität und Fehlertoleranz verfügen. Ansonsten kann auch die Funktion der inter-unit-busse nicht gewährleistet werden. Es wird eine Wahrscheinlichkeit, dass ein Fehler unentdeckt bleibt, von 10 9 /Std. gefordert [14]. Diese Aufgabe übernimmt in der Boeing 777 der SAFEbus. Die inter-unit-busse sind hauptsächlich ARINC 429 oder ARINC 629, die allerdings im Folgenden nicht näher erläutert werden. Die Datenrate liegt in der Implementierung von 1995 bei 30MB/s. Je nach physikalischer Ebene sind aber auch derzeit schon Datenraten von bis zu 50MB/s denkbar gewesen [15]. Außerdem bietet SAFEbus selbst bei kleinen Nachrichten eine hohe Effizienz und effektive Ausnutzung der Bandbreite. Der Bus wurde 1993 als ARINC 659 standardisiert. Die Spezifikation ist allerdings nicht frei verfügbar. Von allen bisher behandelten Bussystemen stellt SAFEbus den teuersten dar. Ein Knoten wird mit mehr als 100$ angegeben [22] Kommunikation Die SAFEbus-Spezifikation sieht in jedem LRM für den Bus zwei Bus Interface Units (BIUs) vor, welche jeweils zwei verschiedene Busse, wiederum bestehend aus jeweils zwei Datenleitungen und einer Taktleitung, steuern. Da jede der vier Datenleitungspaare zur gleichen Zeit die gleichen Datensignale repräsentieren, ist der Bus also vierfach redundant und die Kommunikation erfolgt 2-Bit-parallel. Die Kommunikation bei SAFEbus funktioniert wie bei TTP rein zeitgesteuert. Jedes LRM besitzt jeweils eine Tabelle (Table Memory), in welcher Aufgaben und der Zeitpunkt zur Ausführung gespeichert sind. Diese Aufgaben können das Empfangen oder Senden einer Nachricht sein. Außerdem sind hier Speicheradressen für die Daten gespeichert. Eine Nachricht muss also weder Sender- noch Empfängerinformationen enthalten, da anhand der Tabelle jedes LRM weiß, wann es welche Daten senden muss und wann es welche Daten empfangen soll. In vielen Bussystemen werden zur Fehlererkennung zusätzliche CRC -Felder in eine Nachricht eingefügt. Dieses wird hier ebenfalls nicht benötigt (s. Kapitel 3.7.4). Eine SAFEbus- Nachricht besteht also abgesehen von einer Lücke zur Trennung zweier Nachrichten, welche der Dauer von zwei Bits entspricht, nur aus Datenbits (s. Abbildung 10)! Berücksichtigt man die minimale Nachrichtengröße von 4Byte ergibt sich eine Effizienz des Bussystems von mind. 94% und schon bei einer Nachrichtengröße von 24Byte erreicht man eine Effizienz von 99%. Die maximale Nachrichtengröße liegt bei 1kByte. Andere Bussysteme erreichen wegen des hohen Overheads bei kleinen Nachrichten um 4Byte nur eine Effizienz von etwa 10 bis 30%! 34

43 Echtzeitbussysteme im Überblick Abbildung 9: Kommunikation bei FlexRay unerlaubterweise sendet, obwohl der Bus bereits belegt ist, erzeugt nun eine Unstimmigkeit, welches sofort erkannt werden kann. Außerdem werden Kurzschlüsse oder andere Fehler, die mehrere Busleitungen gleichzeitig betreffen, durch dieses Schema schnell erkannt. Abbildung 10: Eine SAFEbus-Nachricht Synchronisation Synchronisation beschreibt hier, dass alle BIUs sich an der gleichen Position in dem Table Memory befinden sollen. Jedes BIU enthält einen eigenen Oszillator für den Takt und einen Zähler für die Position in der Tabelle. SAFEbus stellt nun drei verschiedene Synchronisationsnachrichten zur Verfügung. Eine Initial Sync Message wird für die Initialisierung beim Bus-Start benutzt, um alle Zähler an den Anfang der Tabelle zu setzen. Eine Short Resync Message dient dazu während des Betriebs auseinander driftende Oszillatoren zu korrigieren. Eine Long Resync Message dient schließlich dazu, ein verlorengegangenes BIU wieder an einen aktiven Bus zurückzuführen, indem ihm die aktuelle Position in der Tabelle mitgeteilt wird. Sofort nach Erhalt irgendeiner Synchronisationsnachricht werden die Oszillatoren und Zähler schlagartig korrigiert. Zum Senden dieser Nachrichten wird kein zusätzliches BIU benötigt. Jedes BIU besitzt die Fähigkeit eine solche zu senden. Für die Short Resync Messages bestehen Einträge in den Tabellen verschiedener BIUs, um diese zu senden Fehlertoleranz und -behandlung Wie bereits erwähnt, ist der SAFEbus vierfach redundant mit zwei BIUs pro LRM. Dieses bildet zusammen zwei Self-Checking-Busse. Jedes BIU funktioniert dabei als Buswächter für seinen Partner. Bei einem babbling idiot kann sich nun das LRM selbst entfernen. Außerdem wird der Bus von jedem Empfänger überwacht. Nur korrekt empfangene Daten werden auch in den Speicher geschrieben. Self- Checking-Busse bieten im Allgemeinen eine sicherere Fehlererkennung als mit CRC -Codes und erfordern zusätzlich keinen weiteren Nachrichtenoverhead, welches eine hohe Effizienz garantiert. Um eine Fehlererkennung noch zu verbessern, werden alle vier Busleitungen unterschiedlich kodiert, die das gleiche Datensignal repräsentieren sollen. Je zwei Leitungen sind immer negativ zueinander. Das eine Paar hat weiterhin die Eigenschaft immer dann einen Bitwechsel auszuführen, wenn das andere keinen macht, und umgekehrt. Außerdem verhält sich der Status einer Busleitung wie ein logisches ODER, falls mehrere BIUs gleichzeitig schreiben. Ein BIU das nun SAFEbus ist fail operational/fail passive, d.h. falls ein Self Checking Bus ausfällt, bleibt das System betriebsbereit. Sollte allerdings auch der zweite Self Checking Bus ausfallen, schaltet sich das ganze System ab. 4. FAZIT Bussysteme spielen eine immer größere Rolle in der Industrie und die Entwicklung schreitet dementsprechend immer weiter voran. Die eben vorgestellten Systeme spiegeln die gegenwärtige Situation auf dem Markt, vor allem in der Automobilindustrie, wieder. Es gibt verschiedene ältere aber bewährte Bussysteme, wie z.b. CAN, welche allerdings den stetig wachsenden Ansprüchen bald nicht mehr gewachsen zu sein scheinen. Neuentwicklungen, wie FlexRay sind dagegen aber meistens noch zu unerprobt. Ein Trend ist dennoch in Richtung Sicherheit und Geschwindigkeit zu verzeichnen, wobei ein Preisanstieg kaum zu vermeiden aber natürlich trotzdem unerwünscht ist. Außerdem wurde erkannt, dass es kein Allround-Bussystem gibt, dass allen Anforderungen gleichermaßen gerecht wird. Je nach Aufgabenbereich und Einsatzgebiet müssen verschiedene Anforderungen erfüllt werden, z.b. ist der SAFEbus als intra-unit- oder backplane-bus im Flugzeug sehr gut aufgehoben, aber schon zur Verwendung als inter-unit-bus aufgrund der langen Verbindungsleitungen nicht mehr geeignet. Auch die Verwendung von SAFEbus im Automobil wäre wegen der hohen Kosten nicht rentabel! Ebenfalls eine Kostenfrage ist beispielsweise die Entwicklung des LIN -Busses. Es wurde erkannt, dass CAN oder TTP für die Aufgaben eines Sub- Busses überqualifiziert und zu teuer waren. Wie zu sehen ist, schließen sich immer mehr Firmen zur Neu- oder Weiterentwicklung von Bussystemen zusammen und legen dessen Standard offen. Dieser Trend hat ebenfalls finanziellen Hintergrund. Insellösungen dienen lediglich der Vermarktung eines Produktes. Ersatzteile werden dadurch teuer und schwer beschaffbar. Die Verbreitung als offener Standard unterstützt eine weitere Verbreitung und geringere Preise aufgrund des Wettbewerbs der Herstellerfirmen. LIN, CAN, Ethernet Powerlink und FlexRay sind beispielsweise frei verfügbar. Als Übersicht über die Eigenschaften der hier behandelten Bussysteme dient abschließend Tabelle 2. Sie stellt diese nocheinmal anhand verschiedener Kriterien gegenüber. 35

44 Lars Wienbrandt Master / Slave- Konzept max. Bitrate max. Daten pro Frame CAN LIN Powerlink TTP byteflight FlexRay SAFEbus Art der Kommunikation ereignisgesteuert, Vorrang nach Priorität 1MB/s (high speed CAN ) single master / multiple slave zeitgesteuert, polling 20kB/s single master / multiple slave zeitgesteuert, polling z.b. 100MB/s bei Standard- Ethernet gleichberechtigt gleichberechtigt (TTP/C ) single master / multiple slave (TTP/A) zeitgesteuert, synchronisiert (MEDL) 25MB/s (in Studie: > 1GB/s) gleichberechtigt (aber: bel. Knoten ist Sync Master) zeitgesteuert oder ereignisgesteuert, synchronisiert (Slot- Counter) 10MB/s s. byteflight s. byteflight 10MB/s gleichberechtigt zeitgesteuert, synchronisiert (Table Memory) 30MB/s (denkbar: > 50MB/s) 8Byte 8Byte beliebig 240Byte 12Byte 12Byte 1kByte Topologie Bus Bus max. Anzahl Knoten Fehlererkennung zwei Self- Checking- Busses, zwei Sender gleichzeitig Buswächter, unterschiedl. Kodierung der Busleitungen Fehlerbehandlung Kostenrelation untereinander Anwendungsbereiche Bus, Stern (auch mehrere) je nach physikalischer Ebene beliebig bit-CRC, bit-stuffing Error-Flag zur Fehlersignalisierung, Automatic Repeat Request Prüfsumme, Identifier- Prüfbits, Erkennung von ausgefallenen Knoten bzw. Bus nicht auf Protokollebene CRC CRC, Membership- Infos, Buswächter nicht auf Protokollebene Fail-Silent- Knoten, Redundanz Stern 16-bit-CRC, Buswächter im Star Coupler, Überwachung der optischen Signalqualität Abschalten von Knoten möglich (über Applikation) Bus, Stern, kombiniert, Zweikanal m. versch. Topologien Bus: 8, Stern: 16, mehr durch Kombinationen möglich 24-bit-CRC, Buswächter bei jedem Knoten und Kanal, Überwachung der Uhrensynchronisation Applikation kann Knoten ausschließen und Fehler korrigieren, Redundanz Bus beliebig vierfache Redundanz, Selbstabschaltung, fail operational / fail passive günstig billig günstig teuer teuer teuer sehr teuer Automobil, Automatisierungsund Kontrolltechnik Sub-Bus im Automobil (Karosserieelektronik) Antriebsund Automatisierungstechnik 36 Automobil und Flugzeug (sicherheitskritische Anwendungen, x-by-wire) Automobil (sicherheitskritische Anwendungen, x-by-wire) Tabelle 2: Gegenüberstellung einiger Bussysteme Automobil (Weiterentwicklung von byteflight) Flugzeug (backplane bus - sicherheitskritische Anwendungen, x-by-wire)

45 Echtzeitbussysteme im Überblick 5. LITERATURVERZEICHNIS [1] Avidyne Corporation: Avidyne Databus Technology Selection, Lincoln, MA 01773, Nov [2] Belschner, R., J. Berwanger, C. Bracklo, C. Ebner, B. Hedenetz, W. Kuffner, P. Lohrmann, J. Minuth, M. Peller, A. Schedl und V. Seefried: Anforderungen an ein zukünftiges Bussystem für fehlertolerante Anwendungen aus Sicht KFZ-Hersteller. Techn. Ber., Daimler Chrysler AG, Stuttgart, BMW AG, Munich, Okt [3] Berwanger, J., M. Peller und R. Grießbach: byteflight - A New High Performance Data Bus System for Safety-Related Applications. Techn. Ber., BMW AG, EE-211 Development Safety Systems Electronics, Munich, Germany, [4] BOSCH CAN-Homepage: Controller Area Network (CAN). [5] Cena, G. und A. Valenzano: Performance Analysis of Byteflight Networks. Techn. Ber., IEIIT-CNR, Torino, ITALY, [6] CiA Homepage: CAN in Automation (CiA), [7] Elend, B.: FlexRay - The electrical physical layer. In: FlexRay International Workshop, Tokyo. Philips Semiconductors, Juni [8] Ethernet Powerlink Homepage: Home of the Ethernet Powerlink Standardization Group. [9] Felser, M.: Real-Time Ethernet - Industry Prospective. Proceedings of the IEEE, Vol. 93, No.6, S , Juni [10] FlexRay Homepage: FlexRay - The communication system for advanced automotive control applications. [11] Form, T.: Datenbussysteme in Straßenfahrzeugen. Techn. Ber., Technische Universität Carolo-Wilhelmina zu Braunschweig, Institut für Regelungstechnik, Okt [12] Form, T.: Elektr(on)ische Fahrzeugsysteme II. Techn. Ber., Technische Universität Carolo-Wilhelmina zu Braunschweig, Institut für Regelungstechnik, Juni [13] Führer, T., B. Müller, W. Dieterle, F. Hartwich, R. Hugel und M. Walther: Time Triggered Communication on CAN. Techn. Ber., Robert Bosch GmbH, [14] Hoyme, K. und K. Driscoll: SAFEbus. IEEE AES Systems Magazine, S , März [15] Hoyme, K., K. Driscoll, J. Herrlin und K. Radke: ARINC 629 and SAFEbus: Data Buses for Commercial Aircraft. Scientific Honeyweller, S , [16] Intel: Introduction to In-Vehicle Networking. Techn. Ber., Intel Corporation, com/design/mcs96/papers/autolxbk.htm. [17] IXXAT Automation GmbH: Einführung ETHERNET Powerlink. powerlink_technologie_de,18100,147.html. [18] Kopetz, H. und T. Thurner: TTP A New Approach to Solving the Interoperability Problem of Independently Developed ECUs. Techn. Ber., Technical Unversity of Vienna, Austria and Daimler Chrysler Research, Stuttgart, Germany, xbywire/projects/new-ecu.html. [19] LIN Consortium Homepage: LIN Local Interconnect Network. [20] ME-Meßsysteme GmbH, Hennigsdorf, Germany: Grundlagen zum CAN Bus. [21] Randt, M. (Hrsg.): Workshop Bussysteme im Automobil, Augsburg, Germany, Juni ECT [22] Rushby, J.: A Comparison of Bus Architectures for Safety-Critical Embedded Systems. Techn. Ber., Computer Science Laboratory, SRI International, Menlo Park, CA 94025, Sep http: // [23] Rushby, J.: Bus Architectures for Safety-Critical Embedded Systems. Techn. Ber., Computer Science Laboratory, SRI International, Menlo Park, CA 94025, Juli [24] Scheitlin, H.: Ethernet Powerlink - klipp und klar. SE STZ Automate Now, S , [25] Specks, J. W. und A. Rajnák: LIN - Protocol, Development Tools, and Software Interfaces for Local Interconnect Networks in Vehicles. In: 9th International Conference on Electronic Systems for Vehicles, Baden-Baden, Okt [26] TTTech: Eine Plattform für sicherheitskritische Anwendungen. Techn. Ber., TTTech Computertechnik AG, 1040 Wien, Austria, [27] TTTech Company Homepage: TTTech. [28] Wense, H.-C. von der: Introduction to LIN. Techn. Ber., Motorola, Munich, Germany, März [29] X-By-Wire Team: X-By-Wire: Safety Related Fault-tolerant Systems in Vehicles. Techn. Ber., X-By-Wire Project, ac.at/projects/xbywire/projects/new-home.html. [30] Zimmermann, W. und R. Schmidgall: Bussysteme in der Fahrzeugtechnik. Vieweg-Verlag, Apr

46 Lars Wienbrandt 38

47 Das FlexRay Protokoll im Vergleich mit TTP/C Das FlexRay Protokoll im Vergleich mit TTP/C Henrik Rathje Christian-Albrechts-Universität zu Kiel Arbeitsgruppe für Echtzeitsysteme und Eingebettete Systeme Kiel, Germany Skalierbare deterministische Datenübertragung Zusammenfassung Im Folgenden werden einige wichtige Details des FlexRay Protokolls vorgestellt und Eigenschaften von FlexRay denen von TTP/C gegenübergestellt. 1. EINFÜHRUNG Durch die Einführung verschiedener neuer Funktionen, beispielsweise zur Umgebungserkennung, sowie durch den Austausch mechanischer durch elektronische Komponenten (xby-wire) im Automobilbereich steigt die Anzahl verteilter elektronischer Systeme im Automobil. Ein Bussystem, welches die Kommunikation dieser Systeme untereinander ermöglicht, sollte verlässlich und fehlertolerant sein und sich deterministisch verhalten. FlexRay ([10] [5], [3], [4], [2]), und TTP/C ([8], [7] [9]) sind Protokolle, die für diese Anforderungen entwickelt wurden. In Kapitel 2 wird das FlexRay Protokoll detailliert vorgestellt. Hierzu wird zunächst in Abschnitt 2.1 auf die Knoten- Architektur eingegangen. In Abschnitt 2.2, in dem die Protokoll- Architektur behandelt wird, wird zuerst die physische- und dann die Sicherungsschicht erklärt. Anschließend geht es in Abschnitt 2.3 um die Mechanismen, die FlexRay zum geordneten Netzwerkstart, zur Uhrensynchronisierung, sowie zur Fehlerbehandlung einsetzt. In Kapitel 3 werden zuerst in Abschnitt 3.1 einige wichtige Details des TTP/C Protokolls genannt und anschließend in Abschnitt 3.2 erläutert, wie in TTP/C Fehler erkannt und behandelt werden. In Kapitel 4 werden die beiden Protokolle schließlich verglichen. Unter anderem wird hier die Leistungsfähigkeit beider Protokolle im Umgang mit verschiedenen Fehlerarten untersucht. Dieses Dokument endet mit Kapitel 5, dem Fazit. 2. FLEXRAY Das FlexRay-Konsortium entstand aus einer Kooperation zwischen BMW und DaimlerCrysler. Beide Firmen befanden, dass damals existierende Bussysteme ihren Ansprüchen für zukünftige Anwendungen wie beispielsweise x-by-wire nicht genügten. Das FlexRay-Konsortium wurde im Jahr 2000 von BMW, DaimlerCrysler, Philips und Motorola gegründet um ein deterministisches, fehlertolerantes Bussystem mit hoher Bandbreite zu entwickeln. Die Protokollspezifikation v2.1 wurde Ende 2005 veröffentlicht. Folgende Eigenschaften bietet das Protokoll zusätzlich zu den bereits erwähnten: Skalierbare ereignisgesteuerte Datenübertragung Fehlertolerante Uhrensynchronisation Skalierbare Fehlertoleranz durch redundante Übertragungskanäle 10Mbit/s Datenrate pro Übertragungskanal Entwicklungswerkzeuge für Design, Simulation und Tests befinden sich derzeit in der Entwicklungsphase. BMW und DaimlerChrysler beabsichtigen FlexRay innerhalb der nächsten Jahre in Serienfahrzeugen einzusetzen. 2.1 Knoten-Architektur Ein FlexRay-Cluster (siehe Abbildung 2) besteht aus mehreren FlexRay-Nodes (bzw. Knoten) und kann je nach Topologie auch aktive Star-Coupler umfassen. Abbildung 1 zeigt einen FlexRay-Node und seine einzelnen Bestandteile. Host Power Supply Communication Data Configuration Data & Status Information Control Data & Status Information Control Signals (optional) Control Signal Communication Controller Communication Data Bus Driver Abbildung 1: FlexRay Node (Quelle: [5]) Der Host konfiguriert den Communication Controller und übergibt diesem die zu übertragenen Daten. Im Communication Controller sind alle Protokoll-Aspekte des FlexRay Systems implementiert. Der Communication Controller erzeugt aus den Nutzdaten Frames und übergibt diese dem Bus Driver, der diese Daten geeignet auf dem physischen Medium überträgt. Optional kann im FlexRay-Node je ein Control Signal Communication Data 39

48 Henrik Rathje Bus Guardinan pro Kommunikationskanal eingesetzt werden. Der Bus Guardian kann bestimmte Sende-Fehler des Knotens erkennen und den Knoten gegebenenfalls abschalten oder neu starten. Der Bus Driver kann empfangene Wakeup-Symbole (Bitmuster) selbstständig erkennen und den Host über die optionale Leitung zum Netzteil einschalten. Alle übrigen Frames werden vom Bus Driver an den Communication Controller übergeben, der die dekodierten Nutzdaten dem Host übergibt. 2.2 Protokollarchitektur Physical Layer Node A Node B Star 1A Node C Star 2A Node D Statischer Teil Der sich periodisch wiederholende Kommunikationszyklus wird bei FlexRay in ein statisches- und ein dynamisches Segment, ein Symbol-Window und eine Network-Idle-Time unterteilt. Das statische Segment besteht aus einer festen Anzahl von durchnummerierten Static-Slots, in denen genau ein Frame übertragen werden kann. Die Anzahl der Static- Slots und die Länge des dynamischen Segments sind frei wählbar und werden vor Inbetriebnahme des Systems durch die System-Konfiguration festgelegt. Das Recht in einem bestimmten Static-Slot zu senden wird genau einem FlexRay- Node zugeteilt, so dass keine Kollisionen auftreten. Sendet ein fehlerhafter Knoten in einem ihm nicht zugeweisenen Static-Slot, so kann dies vom Bus Guardian erkannt werden und geeignet reagiert werden. Durch die exklusiv zugewiesenen Static-Slots steht jedem Knoten eine feste Bandbreite zur Verfügung. Die Datenübertragung erfolgt hier deterministisch. Node E Node F Node G Dynamischer Teil In Abbildung 4 wird die Datenübertragung im dynamischen Segment beispielhaft dargestellt. Abbildung 2: Netz Topologie (Quelle: [5]) FlexRay erlaubt Bus- und Stern-Topologien in ein- oder zweikanaliger (redundanter) Ausführung, sowie hybride Topologien. In Abbildung 2 sind die Nodes E, F und G durch einen passiven Bus miteinander verbunden. Dieser Bus ist an den aktiven Sternpunkt 2A angeschlossen um die Kommunikation mit den übrigen Knoten zu ermöglichen. Ein aktiver Sternpunkt arbeitet als bidirektionaler Transceiver, der angeschlossene Busse oder Knoten elektrisch entkoppelt, aber korrekt empfangene Nachrichten an alle angeschlossenen Geräte weiterverteilt. Durch die elektrische Entkoppelung kann ein fehlerhafter Knoten, der einen Kurzschluss auf einem oder beiden angeschlossenen Kanälen verursacht, nicht die gesamte Kommunikation auf diesen Kanälen blockieren Data Link Layer Media Access Control In Abbildung 3 wird das Medienzugriffsverfahren von Flex- Ray graphisch illustriert. Der Medienzugriff bei FlexRay erfolgt sowohl TDMA basiert (im statischen Segment) als auch Minislotting basiert (im dynamischem Segment). communication cycle level arbitration grid level macrotick level microtick level macrotick static segment dynamic segment static slot static slot minislot minislot microtick action point action point symbol window action point t network idle time Das dynamische Segment besteht aus einer festgelegten Anzahl von Minislots. Während dieser Minislots darf wieder genau ein Knoten Daten senden. Nachdem eine Nachricht vollständig übertragen wurde, wird in allen Knoten ein Slot- Counter inkrementiert. Um Kollisionen zu vermeiden wird zur Konfigurationszeit festgelegt, welcher Knoten bei welchem Wert des Slot-Counters senden darf. Verzichtet ein Knoten auf sein Senderecht, wird der Slot-Counter ebenfalls inkrementiert, so dass im Folgenden ein anderer Knoten die Möglichkeit hat, Daten zu übertragen. Die Bandbreite wird im dynamischen Segment bedarfsgesteuert auf die verschiedenen Knoten verteilt. Hierbei geht der zeitliche Determinismus verloren, denn ein Knoten muss unvorhersehbar lange warten, bis alle Knoten mit Berechtigung bei niedrigeren Slot-Counter-Werten zu senden das Medium frei gegeben haben. Allerdings gestattet das Minislotting-Verfahren im dynamischen Segment in manchen Fällen eine effizientere Nutzung der Bandbreite als das statische TDMA Verfahren, beispielsweise wenn jeweils nur genau ein Knoten pro Kommunikationszyklus Daten senden will. Kanalkodierung Kodierung In Abbildung 5 ist gezeigt, wie ein FlexRay-Frame zur Übertragung auf dem physischen Medium vom Comminication- Controller kodiert wird. High TxD Low High TxEN Low MAC FSP CODEC a TSS FSS BSS 1st byte sequence MSB LSB BSS BSS last byte sequence 1 * gdbit FES FSP b Abbildung 3: Media Access Control (Quelle: [5]) Abbildung 5: Frame Encoding im statischen Segment (Quelle: [5]) 40

49 Das FlexRay Protokoll im Vergleich mit TTP/C m slot counter channel A minislot 1 m+1 m+2 m+3 m+4 m+5 minislot gnumberofminislots channel A frame ID m frame ID m+3 frame ID m+5 t channel B frame ID m+3 frame ID m+7 m m+1 m+2 m+3 m+4 m+5 m+6 m+7 m+8 slot counter channel B dynamic slot without transmission dynamic slot with transmission dynamic segment containing gnumberofminislots minislots transmission may only start within the first platesttx minislots of the dynamic segment Abbildung 4: Medienzugriff im dynamischen Segment (Quelle: [5]) Vor den eigentlichen Daten des Frames (in Abbildung 5 1stbyte-sequence und last-byte-sequence) wird eine Transmission- Start-Sequence (TSS) und eine Frame-Start-Sequence (FSS) gesendet. Die TSS besteht aus einer festen Anzahl von Low Bits, die FSS besteht aus einem High-Bit. Die Leerlaufzeit während der TSS wird von aktiven Sternpunkten genutzt um Verbindungen zu initialisieren. Die FSS ist eine Trainingssequenz, um die Empfänger zu kalibrieren. Außerdem wird vor jedem Byte des Frames eine Byte-Start-Sequence (BSS) eingefügt. Diese liefert den Empfängern Timing-Informationen. Dekodierung Um Nachrichten zu empfangen, tastet der Empfänger zunächst das empfangene Signal (RxD in Abbildung 6) ab, und führt anschliessend ein Majority-Voting durch (siehe Abbildung 6). Die Channel-Sample-Clock gibt den Takt, mit dem das Signal abgetastet wird, vor. Die neuesten n Abtastwerte werden im Voting-Window gespeichert. Ist die Mehrheit der Bits im Voting-Window high-bits, so ist das dekodierte Signal zvotedval ebenfalls high und sonst low. Wie auch im Beispiel in Abbildung 6 zu erkennen ist, können so falsch übertragene Bits (glitches) korrigiert werden. Dem zu übertragenen Signal wird also Redundanz hinzugefügt indem einzelne Bits mehrfach hintereinander übertragen werden. Frame-Format In Abbildung 7 ist ein FlexRay-Frame dargestellt. der Frame-ID kann der Empfänger den Absender der Nachricht erkennen (die Frame-ID entspricht der Static-Slot-Nummer aus Abbildung 3). Der Header-CRC (Cyclic Redundancy Check Code) erlaubt dem Empänger festzustellen, ob der Header korrekt oder fehlerhaft empfangen wurde. Der CRC- Code im Trailer-Segment lässt eine Erkennung von Übertragungsfehlern im Header- und Payload-Segment zu. Wird beim Dekodieren der Frames ein fehlerhafter CRC-Code erkannt, so meldet der Comunication-Controller dem Host einen Decoding-Error Höhere Protokollschichten Am Controller-Host-Interface (CHI ) bietet FlexRay Services an, die auf den Protokoll-Services aufsetzen. Neben einem Puffer zum Versenden von Nachrichten bietet das CHI einen FIFO-Speicher für empfangene Nachrichten. Weiterhin gibt es die Möglichkeit, diese Nachrichten nach Kriterien wie Message- oder Channel-ID filtern zu lassen. Ausserdem werden vom CHI Timer-, Interrupt-, und Error-Signaling- Services angeboten. 2.3 Funktionsweise Netzwerk Start Der Start eines FlexRay-Clusters erfolgt in zwei Schritten, dem Wakeup und dem Startup. Beim Wakeup werden die Communication-Controller und Hosts der einzelnen FlexRayknoten lediglich eingeschaltet, beim Startup synchronisieren sich die Nodes und beginnen gemäß des Kommunikations- Zyklus mit der Datenübertragung. Wakeup In Abbildung 8 ist der Ablauf der Wakeup-Prozedur in einem Dual-Channel-Cluster beispielhaft dargestellt. local wakeup event wake channel A POC state leave coldstart inhibit mode Node A wakeup/coldstart node channel A, B power off/reset config ready wakeup listen wakeup send ready integration listen wake channel B coldstart listen Node B wakeup/coldstart node channel A, B power off / reset config wakeup ready wakeup ready coldstart listen listen send Abbildung 7: FlexRay-Frame (Quelle: [5]) Node C non coldstart node channel B Channel A power off / reset wakeup pattern config ready integration listen B wakeup pattern Ein Frame besteht aus einem Header-, einem Payload- und einem Trailer-Segment. Die Aufgabe der einzelnen Felder erschließt sich im wesentlichen aus ihrer Bezeichnung. Anhand Abbildung 8: Wakeup (Quelle: [5]) 41

50 Henrik Rathje cvotingdelay channel sample clock RxD glitch voting window zvotedval Abbildung 6: Sampling und Majority Voting (Quelle: [5]) Für die erfolgreiche Durchführung der Startup-Prozedur in einem Dual-Channel-Cluster sind zwei intakte Wakeup/Coldstart- Nodes (Kaltstart-Knoten) erforderlich. Um den Ausfall eines beliebigen Knotens tolerieren zu können, sollten also mindestens drei Knoten als Kaltstart-Knoten konfiguriert sein. Mindestens ein Knoten des Clusters muss externe Wakeup- Events empfangen können. Damit fehlerhafte Knoten nicht die Kommunikation auf beiden Kanälen gleichzeitig stören, soll ein FlexRay-Knoten die Wakeup-Prozedur nur auf einem Kanal zur Zeit ausführen. Die Wakeup/Coldstart Nodes in diesem Beispiel sind die Knoten A und B. Knoten A empfängt ein externes Wakeup Signal, konfiguriert den Comminication-Controller und führt anschliessend ein Wakeup auf Kanal A durch. Hierzu wird zunächst geprüft, ob schon andere Knoten Wakeup-Pattern auf Kanal A gesendet haben. Dies ist im Beispiel nicht der Fall, also sendet Knoten A im nächsten Schritt ein Wakeup- Symbol auf Kanal A. Dieses Symbol wird vom Bus-Driver von Knoten B erkannt, woraufhin Kaltstart-Knoten B mit der Wakeup Prozedur auf Kanal B beginnt. Das von Knoten B gesendete Wakeup-Pattern wird von Knoten A und C erkannt. Als Konsequenz wird Knoten C eingeschaltet. Knoten A weiss nun, das ein anderer Knoten das Wakeup auf Kanal B durchgeführt hat und kann mit dem Startup beginnen. Laut [5] toleriert die Wakeup Prozedur eine beliebige Anzahl von Knoten, die einen Kanal zur selben Zeit aufwecken wollen. Startup Der Startup-Prozess findet auf beiden Kanälen synchron statt. Der Leading-Startup-Node (führender Kaltstart-Knoten) sendet Startup-Frames über den Kommunikationskanal, die übrigen Knoten synchronisieren sich an den so vorgegebenen Kommunikations-Zyklus. Die Rolle des führenden Kaltstart- Knotens kann prinzipiell von jedem Kaltstart-Knoten übernommen werden, so dass der Startup-Prozess auch bei Ausfall eines beliebigen Knoten korrekt ablaufen kann. Node A coldstart node Node B coldstart node Node C Channel Legend POC state cycle schedule POC state POC state ready ready ready CAS coldstart listen no schedule : CAS symbol coldstart listen integration listen CAS S A A coldstart collision resolution initialize schedule initialize schedule integration coldstart check coldstart consistency check coldstart join integration consistency check normal active cycle 0 cycle 1 cycle 2 cycle 3 cycle 4 cycle 5 cycle 6 cycle 7 cycle 8 normal active S S S S S S S S S S S S S S normal active A A A A A A A A B B B B B C : startup frame of node A S B : startup frame of node B Abbildung 9: Startup (Quelle: [5]) C earliest point in time for all nodes to leave startup : frame of node C In Abbildung 9 ist der Ablauf der Startup-Prozedur skizziert. Knoten A ist der erste Knoten, der die Startup-Prozedur einleitet und prüft im ersten Schritt der Prozedur, ob Daten auf dem Kommunikationskanal übertragen werden (coldstartlisten). Knoten B leitet die Startup-Prozedur kurze Zeit später ein. Dann sendet Knoten A das Collision-Avoidance- Symbol (CAS). Dieses wird vom Knoten B empfangen. Somit ist Knoten B nun darüber informiert, dass Knoten A die Rolle des führenden Kaltstart-Knoten übernimmt, und nimmt selbst die Rolle eines Following-Coldstart-Node (folgender Kaltstart-Knoten) ein. Als führender Kaltstart-Knoten sendet Knoten A in den ersten vier Kommunikations Zyklen jeweils einen Startup Frame. Der folgende Kaltstart- Knoten B leitet seinen Schedule aus den ersten beiden empfangenen Startup Frames ab. Die darauf folgenden Startup- Frames werden für die Uhrensynchronisation genutzt. Wenn die Uhrensynchronisation erfolgreich verlaufen ist, beginnt ein folgender Kaltstart-Knoten selbst mit dem Senden von Startup-Frames. Knoten, die keine Kaltstart-Knoten sind (in diesem Beispiel Knoten A) benötigen zwei korrekt empfangene Startup-Frames von zwei verschiedenen Kaltstart- Knoten um sich zu synchronisieren. In den folgenden zwei Zyklen prüfen die Nicht-Kaltstart Knoten ob die empfangenen Startup Frames zum eigenen Schedule passen und beginnen bei positivem Ergebnis im Folgenden mit der Nutzdatenübertragung Uhrensynchronisation Der TDMA-Buszugriff von FlexRay erfordert eine zeitliche Synchronisation der Knoten auf Macrotick-Ebene (siehe Abbildung 3). In FlexRay wird ein verteilter Uhren-Synchronisations- Mechanismus eingesetzt, so dass die Uhrensynchronisation 42

51 Das FlexRay Protokoll im Vergleich mit TTP/C auch noch bei einem Ausfall eines beliebigen Knotens funktioniert. Im Rahmen der Uhrensynchronisation wird bei Flex- Ray eine Phasen- und Frequenz-Korrektur durchgeführt. default config POCOperational media access schedule (MAC) config cycle 2n cycle 2n+1 cycle 2n+2 cycle 2n+3 static dyn. sym. NIT static dyn. sym. NIT static dyn. sym. NIT static dyn. sym. NIT halt clock sync correction schedule (MTG) rate correction rate correction offset rate correction rate correction offset ready correction values clock sync calculation schedule (CSP) measurement phase measurement values rate correction value calculation wakeup startup normal active normal passive offset correction value calculation Abbildung 10: Uhrensynchronisation (Quelle: [5]) Abbildung 11: Protocol Operation Control (Quelle: [5]) Der Ablauf der Uhrensynchronisaion ist in Abbildung 10 skizziert. Im statischen Segment des Kommunikations-Zyklus werden von mehreren, entsprechend konfigurierten Knoten des Clusters Sync-Frames gesendet. Beim Empfang eines Sync-Frames misst jeder FlexRay-Knoten die Microtick-Differenz zwischen der erwarteteten und der tatsächlichen Empfangszeit eines Sync-Frames (measurement-phase). Der Wert für eine Offset Korrektur wird in jedem Komminikations Zyklus berechnet. Hierzu wird ein Fault-Tolerant-Midpoint Algorithmus verwendet, bei dem abhängig von der Anzahl der gemessenen Werte die größten und kleinsten n Werte gestrichen, und die übrigen Messwerte gemittelt werden. Liegt das Ergebnis in definierten Grenzen, so wird es als Korrekturwert verwendet, andernfalls wird ein Fehler signalisiert. Während der Network-Idle-Time der ungeraden Kommunikationszykel wird die Offset-Korrektur durchgeführt, also der Macrotick-Counter angepasst. Macroticks bestehen aus einer Anzahl von Mictoticks, die mit Hilfe eines Quarz- Oszillators erzeugt werden. Bei der Frequenz-Korrektur wird die Anzahl der Microticks, aus denen ein Macrotick besteht, angepasst. Die Daten für die Frequenz-Korrektur werden nur in den ungeraden Kommunikationszyklen berechnet Fehlererkennung und -behandlung Abbildung 11 zeigt die verschiedenen Zustände, die ein FlexRay- Knoten einnehmen kann. Zustandswechsel werden vom Host oder vom Communication Controller initiiert. Bei vom Communication Controller initiierten Zustandwechseln werden dem Host Statusinformationen zur Verfügung gestellt. Im Zustand normal active ist der Knoten betriebsbereit und kann Nachrichten verschicken. In diesem Zustand führt der Controller Fehlerprüfungen durch. Werden im Rahmen der Uhrensynchronisation Fehler festgestellt, dann wird abhängig von der Schwere des Fehlers ein Wechsel in den Zustand normal passive oder halt veranlasst. Im Zustand normal passive sendet der Knoten selbst keine Daten und versucht sich neu zu synchronisieren. Bei sehr grossen Differenzen zwischen der lokalen und der Cluster-Zeit wird nicht davon ausgegangen, dass eine Resynchronisation möglich ist und der Knoten wird ausgeschaltet (halt). 3. TTP/C Das TTP/C Protokoll (im folgenden kurz TTP) wurde an der TU Wien im Rahmen zwanzig jähriger Forschungstätigkeit auf dem Gebiet der zuverlässigen Echtzeitsysteme entwickelt. Wie FlexRay wurde TTP als Bussystem für den Automobilbereich entwickelt. TTP basiert auf dem MARS System, welches in einem europäischen Forschungsprojekt umfangreichen Fault-Injection Experimenten unterzogen wurde. In einem weiteren Forschungsprojekt und in Zusammenarbeit mit DaimlerChrysler wurden Prototypen entwickelt und evaluiert. Nach Abschluss dieser Forschungsprojekte wurde im Jahr 1998 die Firma TTTech als Spin-Off der TU Wien gegründet, um TTP weiter zu entwickeln und zu vermarkten. TTP wird bereits in industriellen Serienprodukten eingesetzt, beispielsweise in der Lockheed Martin F-16 für die Triebwerkssteuerung. 3.1 Protokolleigenschaften Ein TTP Knoten ist ähnlich wie ein FlexRay Knoten aufgebaut. Wie FlexRay unterstützt auch TTP Bus-, Sternund Hybrid-Topologien. Allerdings müssen die Kommuni- 43

52 Henrik Rathje kationskanäle redundant ausgelegt werden. Der Medienzugriff erfolgt bei TTP rein TDMA-basiert. So kann der gesamte Medienzugriff durch Buswächter geschützt werden. In einer sogenannten Message-Descriptor-List (MEDL), die jedem Knoten bekannt ist, wird unter anderem der Schedule des Medienzugriffs definiert. In der MEDL wird definiert, welcher Knoten in welchem TDMA-Slot das Senderecht erhält. Die Länge der TDMA-Slots in einem Zyklus kann bei TTP unterschiedlich sein. Jeder TTP-Frame enthält Angaben über den Controller State (C-State) des Senders. Der C-State wird definiert durch Stand des Macrotick-Counters, den Stand des Slot-Counters, und dem aktuellen Membership Vektor eines TTP-Knotens. Im Membership-Vektor ist eingetragen, welche Knoten des Clusters korrekt arbeiten und welche nicht. Zur Erkennung von Bitübertragungsfehlern werden in TTP Frames außerdem CRC-Summen versendet. Zur Uhrensynchronisation nutzt TTP eine modifizierte Version des Welch-Lynch Algorithmus. TTP bietet zusätzlich zur low-level-nachrichtenübertragung noch einen CAN-Emulations-Layer. Dieser ermöglicht die Migration existierender CAN-basierter Software auf ein TTPbasiertes System mit minimalem Aufwand. Mit TTP-Tools existiert eine Palette von Software-Tools, welche für die Entwicklung eines TTP-Clusters genutzt werden können. TTP- Matlink integriert TTP-Tools in MATLAB/Simulink. So können Entwickler mit einer Entwicklungsumgebung arbeiten, die automatische Erzeugung von verteiltem Code unterstützt. 3.2 Fehlererkennung und -behandlung Durch den Controller State, der mit jedem TTP-Frame versendet wird, erhält jeder TTP Knoten eine Rückmeldung, ob die von ihm versendete Nachricht bei den anderen Knoten korrekt angekommen ist, oder nicht. Diese Art von Rückkanal wird im Rahmen des Membership-Service von TTP für die Erkenung von Acknowledgement- und von Clique- Fehlern verwendet. Zur Diagnose von Acknowledgement-Fehlern prüft jeder Knoten ob er in den Membership-Vektoren seiner beiden Nachfolger enthalten ist. Wenn keiner der beiden Nachfolger den korrekten Empfang der Nachrichten dieses Knoten über den Membership-Vektor bestätigt, der zweite Nachfolger aber den Empfang der Nachrichten des ersten Nachfolgers bestätigt, dann wird ein Acknowledgement-Fehler diagnostiziert und der Controller angehalten. Ein Clique-Fehler wird dann von einem Knoten diagnostiziert, wenn die C-States der Mehrzahl der Knoten nicht mit dem C-State des betreffenden Knoten übereinstimmt. Jeder Knoten zählt in jeder TDMA-Runde die Anzahl der empfangenen Nachrichten deren C-State Information identisch mit der eigenen ist, und die Anzahl der empfangenen Nachrichten, die andere C-State-Informationen enthalten. Ist die Anzahl der empfangenen Nachrichten mit abweichendem C- State grösser, so wird der Communication Controller angehalten. Für TTP gibt es eine Fehler-Hypothese. In der Fehler-Hypothese werden Aussagen über Typ und Anzahl von Fehlern, die ein TTP Cluster tolerieren sollte, getroffen und die Mechanismen zum Umgang mit diesen Fehlern untersucht. Die Fehler- Hypothese von TTP besagt, das ein TTP Cluster (in redundanter Stern-Ausführung) die Fehlfunktion einer beliebigen Komponente toleriert. Des Weiteren wurde für TTP eine Never-Give-Up (NGU) Strategy formuliert, in der der Umgang mit Fehlern die nicht von der Fehler-Hypothese abgedeckt werden (Level-2-Fault, hier: Ausfall mehrerer Komponenten des Clusters) beschrieben wird. Der Membershipservice von TTP kann Level-2-Fehler erkennen. Im Rahmen der NGU-Straterie wird das System innerhalb von 10 Milisekunden neugestartet, nachdem durch den Membership- Service ein Level-2-Fehler erkannt wurde. 4. GEGENÜBERSTELLUNG Kopetz erläutert in [6] wie sich ein TTP Cluster in redundanter Sternausführung in folgenden Fehlerszenarien verhält: Outgoing Link Failure Bei dieser Fehlerart kann ein Knoten keine Nachrichten an die anderen Knoten des Clusters verschicken. In TTP erfährt ein Knoten über den Membership-Service, dass die eigenen versendeten Nachrichten von den anderen Knoten nicht empfangen werden. TTP erkennt diese Fehlerart also auf Protokollebene. Slightly-off Specification Failure Hier sendet ein Knoten Signale, die beispielsweise im Zeitbereich leicht vom spezifizierten Soll-Wert abweichen. Dies kann zu einem inkonsistenten Systemzustand führen, wenn diese fehlerbehafteten Nachrichten von manchen Knoten des Clusters korrekt empfangen werden, und von anderen nicht. In TTP werden solche inkonsistenten Zustände vom Membership-Service erkannt. Spatial Proximity Failure Ein solcher Fehler entsteht wenn Cluster-Komponenten, die zur Fehlertoleranz eingeführt wurden, in direkter Nachbarschaft verbaut wurden, so dass beispielsweise bei einem Brand beide Komponenten ausfallen. In einem TTP-Cluster in redundanter Sternausführung können alle Komponenten mit ausreichendem Abstand zueinander installiert werden. Masquerading Failure Dieser Fehlertyp tritt auf, wenn ein fehlerhaft sendender Knoten die Identität eines anderen Knotens annimmt, und der empfangene Knoten nicht feststellen kann, von welchem der beiden Knoten eine Nachricht kommt. In TTP werden fehlerhaft sendende Knoten durch den Membership Service ausgeschlossen. Dadurch können Fehler dieser Art in TTP nicht auftreten. Babbling Idiot Failure Hier missachtet ein Knoten die Regeln des Medienzugriffsprotokoll und sendet Nachrichten zu unzulässigen Zeitpunkten. In TTP erkennen die in den Sternpunkten installierten Buswächter, wenn ein Knoten Nachrichten zum falschen Zeitpunkt sendet und leiten diese Nachrichten nicht an die übrigen Knoten weiter. Ein TTP-Cluster in genannter Ausführung erkennt all diese Fehler also ohne Hilfe der Anwendungsschicht. In [1] erläutert Elend, dass die intakten Knoten eines FlexRay- Clusters gleicher Ausführung ebenfalls trotz eines Spatial Proximity Fehlers kommunizieren können. Aufgrund des fehlenden Membership-Service in FlexRay müssten die verbleibenden Knoten allerdings über die Anwendungssoftware feststellen, dass ein Knoten ausgefallen ist. Selbiges gilt auch für 44

53 Das FlexRay Protokoll im Vergleich mit TTP/C Nutzdaten pro Frame Uhrensynchronisation Fehler Hypothese / Fehler Toleranz Konsistenzprüfung Datenübertra- Ereignisgesteuerte gung Verfügbarkeit Zertifizierung Clique- Erprobung in Fehjer-Injektions Experimenten TTP/C Bis zu 240 Byte, für jeden Knoten frei wählbar Verteilte, fehlertolerante, formal verifizierte Phasenkorrektur Beliebige Fehlfunktionen einer einzelnen Hardwarekomponente werden toleriert. Zwei redundante Kommunikationskanäle. Bitübertragungsfehler, Sende- und Empfangsfehler. Empfangsbestätigung, Membership-Service, Erkennung. Auf Protokollemene erkannte Fehler Auf TDMA aufgesetzte Event- Channel (CAN-Emulation). Chips seit 1998 auf dem Markt verfügbar. Controller Firmware und Software Werkzeuge sind für Luftfahrt Anwendungen zertifiziert. + FlexRay Bis zu 254 Byte, gleiche Länge aller TDMA-Slots Verteilte, fehlertolerante Phasenund Frequenzkorrektur Einige Fehlfunktionen einer einzelnen Hardwarekomponente werden toleriert. Ein- oder zwei Kommunikationskanäle (Mischformen möglich). Bitübertragungsfehler. Medienzu- Minislotting-basierter griff Prototypen verfügbar. Tabelle 1: Tabellarischer Vergleich von TTP/C und FlexRay Babbling Idiot Failures, die ein Bus Guardian im Sternpunkt des FlexRay Clusters zumindest im statischen Segment erkennen sollte. Allerdings gilt auch hier, wie in allen Fehlerfällen, dass die intakten Knoten, wenn überhaupt, dann nur durch entsprechende Anwendungssoftware und nicht vom Controller über den Ausfall eines Knotens Kenntnis erlangen können. Auf den Internetseiten des FlexRay-Konsortiums sind keine Dokumente hinterlegt, in denen der Umgang mit diesen Fehlern diskutiert wird. In Tabelle 1 sind die wichtigsten Eigenschaften von TTP und FlexRay tabellarisch gegenübergestellt. Insbesondere in Punkto Sicherheit bietet TTP/C einige Merkmale, die bei FlexRay momentan fehlen: Membership-Service zur Konsistenzprüfung. Formale Verifikation der Kernmechanismen (Uhrensynchronisation und Membership-Service). Formulierung einer Fehler-Hypothese. Zertifizierung der Controllerfirmware und Softwarewerkzeuge für Luftfahrtanwendungen. Erprobung in Fehler-Injektions Experimenten. Kopetz attestiert TTP in [6] einen Kostenvorteil gegenüber FlexRay, jedoch gelten die dort aufgeführten Argumente nur für heute nicht mehr aktuelle Eigenschaften der FlexRay Hardware. Die Herstellungskosten für TTP-Hardware dürften den Herstellungskosten für FlexRay Hardware etwa gleichen. 5. FAZIT Die hier untersuchten Bussysteme TTP/C und FlexRay unterscheiden sich hinsichtlich des Hardware-Aufbaus, der unterstützten Netz-Topologien und der verfügbaren Bandbreite nur unwesentlich. Weiterhin nutzen beide Protokolle TDMA für den Medienzugriff und sind somit in der Lage Nachrichten deterministisch übertragen. Außerdem unterstützen beide Protokolle redundante Kommunikationskanäle, erlauben den Einsatz von Buswächtern, und aktiven Sternpunkten und setzen verteilte Uhrensynchronisation ein. Hierdurch verhalten such beide Systeme fehlertolerant; in beiden Systemen führt die Fehlfunktion eines beliebigen Knotens oder ein Kurzschluss in einem Kommunikationskanal nicht zwingend zum Totalausfall des Systems. Durch die deterministische Datenübertragung und die Fehlertoleranz erfüllen beide Protokolle wichtige Anforderungen an ein Bussystem für sicherheitskritische Anwendungen. Technisch unterscheiden sich die Protokolle hauptsächlich durch den Membership-Service, der in TTP/C eingesetzt wird. Durch den Membership-Service wird zum einen die konsistente Funktion aller aktiven System-Knoten gewährleistet was TTP/C für sicherheitskritische Anwendungen weiter qualifiziert. Zudem werden durch den Membership-Service Knotenausfälle im System bekannt gemacht, so dass die verbleibenden Knoten geeignet reagieren können. 6. LITERATURVERZEICHNIS 45

54 Henrik Rathje [1] B. Elend. Design von FlexRay-Netzwerk-Topologien fr verteilte sicherheitsrelevante Applikationen. auto & elektronik, pages 44 46, Feb [2] FlexRay Consortium. FlexRay Communications System, Electrical Physical Layer Specification, Version 2.1, Revision A, Dec [3] FlexRay Consortium. FlexRay Communications System, Preliminary Central Bus Guardian Specification, Version 2.0.9, Dec [4] FlexRay Consortium. FlexRay Communications System, Preliminary Node-Local Bus Guardian Specification, Version 2.0.9, Dec [5] FlexRay Consortium. FlexRay Communications System, Protocol Specification, Version 2.1, Revision A, Dec [6] H. Kopetz. A Comparison of TTP/C and FlexRay. Research Report 10/2001, Technische Universität Wien, Institut für Technische Informatik, Treitlstr. 1-3/182-1, 1040 Vienna, Austria, [7] TTA-Group. TTP - Frequently Asked Questions, [8] TTTech. Time-Triggered Protocol TTP/C High-Level Specification Document Protocol Version 1.1. Technical report, TTTech Computertechnik AG, 1040 Wien, Austria, [9] TTTech. A Platform for Safety-Critical Applications. Technical report, TTTech Computertechnik AG, 1040 Wien, Austria, [10] R. S. Werner Zimmermann. Bussysteme in der Fahrzeugtechnik. Viehweg,

55 Real-Time Ethernet und Ethernet Powerlink Real-Time Ethernet und Ethernet Powerlink Christian Motika Christian-Albrechts-Universität zu Kiel Institut für Informatik Arbeitsgruppe für Echtzeitsysteme und Eingebettete Systeme Kiel, Germany Zusammenfassung Neben der weiten Verbreitung des Ethernet [7] in der Unternehmenskommunikation, gibt es inzwischen mit dem Real- Time Ethernet [18] auch zahlreiche Lösungen, die einen Einsatz als Feldbus sogar in den klassischen Echtzeit-Domänen wie der Antriebs- und Automatisierungstechnik zulassen. Dieser Artikel diskutiert am Beispiel eines bereits etablierten Vertreters Ethernet Powerlink [4], welche Herausforderungen sich beim Übergang vom klassischen Ethernet zum Real- Time Ethernet ergeben und wie diese bereits heute schon erfolgreich bestritten wurden und dem Ethernet so den Weg ebnen, auch in diesem Bereich zukünftig eine wichtige Rolle zu übernehmen. 1. EINLEITUNG In der Bürokommunikation hat sich das Ethernet [7] schon seit einigen Jahren behaupten können und ist dort inzwischen nicht mehr wegzudenken [13]. Die Gründe für die Etablierung von Ethernet hier als Quasi-Standard liegen unter anderem in den offenen Protokollstrukturen und der freien Topoplogiewahl. Mit Ethernet Powerlink (EPL) [4] sollen nun die Vorteile des Ethernet ausgenutzt und mit der Möglichkeit einer Verwendung als Echtzeitbussystem verschmolzen werden. EPL ist also eine Gesamtlösung für fast alle derzeit denkbaren Echtzeitbus-Probleme, die durchaus die herkömmlichen Feldbusse in der Industrieautomation ja sogar in der Antriebstechnik zu ersetzen vermag [12]. Neben EPL gibt es noch weitere Realisierungen, die ebenfalls auf das Ethernet als technische Grundlage für ein Echtzeitbussystem setzen. Alle diese Lösungen haben das Ethernet als technische Grundlage gemeinsam, fußen jedoch auf verschiedenen Grundkonzepten zur Realisierung der Echtzeitanforderungen des Real-Time Ethernet (RTE) [18]. Zunächst sollen in diesem Artikel im Abschnitt 2 die Probleme des herkömmlichen Ethernet bei einem Einsatz als Feldbus erörtert werden. Auf dem Weg zu Techniken zur Lösung dieser Schwierigkeiten werden dann die Unterschiede zum RTE herausgearbeitet. Schließlich beleuchtet der Artikel in Abschnitt 3 die Eigenschaften und Funktionsweisen von EPL mit seinen Vor- und Nachteilen gegenüber konventionellen Feldbussen und stellt damit eine Lösung für das RTE genauer vor. 2. VOM ETHERNET ZUM REAL-TIME ETHERNET In diesem Abschnitt soll nun zunächst auf die geschichtliche Entwicklung vom Ethernet zum RTE eingegangen werden und daraufhin auf die Anforderungen und Grenzen bei der Nutzung des Ethernet als Echtzeit-Bussystem. Abschließend erfolgt dann eine Klassifizierung der verschiedenen RTE- Konzepte. 2.1 Geschichtliche Entwicklung Wie einführend bereits deutlich gemacht wurde, zählt das Ethernet heute zu einem der meist genutzten Kommunikationsmedien im LAN-Bereich. Diese Entwicklung begann bereits 1972 am Xerox Palo Alto Research Center (PARC) [20], an welchem das Ethernet in seinen Grundzügen zunächst nur als firmenspezifisches, nicht standardisiertes Medium ins Leben gerufen wurde. Erst 13 Jahre später, wurde vom Institute of Electrical and Electronics Engenieers (IEEE) [6] mit dem IEEE [7] ein erster allgemein gültiger Standard für das Ethernet festgelegt, welcher auch heute noch Bestand hat. Seit dem wurde das Ethernet hauptsächlich nur in Bezug auf die möglichen Übertragungsmedien und seine Geschwindigkeit respektive der Datenübertragungsraten weiterentwickelt. Obwohl hierfür sowohl viele Teile des alten Standards überarbeitet und erweitert wurden, als auch neue Standards für das Ethernet hinzukamen, hat sich das ursprüngliche Format der Datenpakete bis heute nahezu nicht verändert [19]. Doch die Entwicklung beim Ethernet machte bei den schnelleren Übertragungsraten des Fast Ethernet/Gigabit Ethernet/10 Gigabit Ethernet und bei den neuen Übertragungsmedien wie Fiber Optic oder drahtloses Ethernet nicht halt. Viele Hersteller von Kommunikationssystemen arbeiteten zum Jahrtausendwechsel bereits an Lösungen für das RTE. Dies führte auch in diesem neuen Bereich des Ethernets 2003 zu einer Normung bei der International Electrotechnical Commission (IEC); in der Norm IEC [9] sind heute zehn Lösungen für echtzeitfähiges Ethernet standardisiert. Ein wichtiger Vertreter von ihnen, das EPL, wurde in der Version 1 bereits im November 2001 von der österreichischen Firma Bernecker + Rainer (B&R) zunächst für den Eigenbedarf entwickelt und später, im April 2002, im Rahmen einer Kooperation mit der Züricher Hochschule Winterthur (ZHW) [21], offengelegt. Nachdem sich schnell weitere Interessenten der neuen Technik gefunden hatten, wurde mit der Gründung der Ethernet Powerlink Standardization Group (EPSG) [4] der Grundstein für eine offene und freie Wei- 47

56 Christian Motika terentwicklung des Systems gelegt, die bereits im November 2003 zur Verabschiedung der aktuellen Version 2 von EPL führte [5, 3, 19]. 2.2 Anforderungen und Grenzen Nachdem nun die geschichtliche Entwicklung kurz beleuchtet wurde, wird es nun um die Herausarbeitung von Problemen gehen, die beim Übergang vom Ethernet zum RTE aus den im folgenden betrachteten Anforderungen an ein Echtzeit-Bussystem erwachsen. Außerdem werden daraufhin Lösungsansätze vorgestellt, die diese Anforderungen teilweise erfüllen können und auf die heutigen RTE-Konzepte hinarbeiten, denen zum Schluss dieses Abschnitts ein eigener Absatz gewidmet ist Anforderungen an ein Echtzeit-Bussystem Als Anforderungen an ein echtzeitfähiges Bussystem u.a. im Feldbusbereich wären zunächst zu nennen: Zeitdeterministische Kommunikation: Diese stellt sicher, dass ein Telegramm unabhängig vom Delay und Jitter zu einer vorgegebenen Zeit ankommt. Zeitsynchronisierte Aktionen: Zeitsynchronisierte Aktionen ermöglichen es Feldteilnehmern untereinander, Aktionen zeitlich zu synchronisieren. Querkommunikation: Es ist oft gewünscht, dass diese Teilnehmer unkompliziert untereinander Daten austauschen können. Effiziente Kommunikation: Unter einer effizienten Kommunikation versteht man die Tatsache, dass beim Austausch von Daten möglichst wenig Overhead übertragen wird, der das Netz nur zusätzlich unnötig belastet. Im Folgenden werden nun die Probleme herausgearbeitet, die sich ergeben, wenn diese Anforderungen an das Standard- Ethernet mit seinen Standardprotokollen IP/TCP/UDP gestellt werden Kollisionsproblematik Ein entscheidendes Problem beim Ethernet liegt beim verwendeten CSMA/CD-Zugriffsverfahren (Carrier Sense Multiple Access with Collision Detection), der im Standard IE- EE festgesetzt ist. Es regelt den Zugriff auf das physikalische Medium, z.b. das Twisted-Pair-Kabel. Bei dem Verfahren prüft ein am Netzwerk angeschlossenes sendebereites Gerät schon vor dem Absenden, ob bereits schon ein anderes Gerät sein Datenpaket im Netzwerk platziert hat. Da dieser Vorgang nicht synchronisiert ist, könnten mehrere Geräte gleichzeitig zu der Ansicht gelangen, sie dürften nun senden. Platzieren daraufhin alle Geräte gleichzeitig Daten im Netz, so entsteht eine Kollision, welche die Datentelegramme ungültig werden lässt. Die Collision Detection in jedem Gerät erkennt diesen Zustand und bricht den Sendevorgang vorerst ab. Nach einer zufällig langen Wartezeit versuchen die beteiligten Geräte nun erneut ihre Telegramme zu verschicken. Gelingt dies erneut nicht, so wird erneut eine (nun evtl. auch längere) zufällige Zeit lang gewartet. Durch die zufällige Wartezeit wird die Wahrscheinlichkeit verringert, dass der Sendevorgang erneut wegen einer Kollision abgebrochen werden muss. Die kontinuierliche Verdoppelung des Intervalls aus dem die Wartezeit zufällig gewählt wird bei jedem aufeinander folgenden Fehlversuch soll die Auslastung des Netzwerkes streuen, falls es temporär zu einer hohen Auslastung kommt. Jedoch bringt dieses Verfahren das Problem mit sich, dass die Wahrscheinlichkeit von Kollisionen mit der Anzahl der an diesem Shared-Ethernet beteiligten Geräte rapide ansteigt. Daher gibt es auch für die Kaskadierung von Netzwerk- Hubs, eine obere Grenze, denn bei zu vielen Kollisionen pro Zeit büßt das Netzwerk zu viel an Performance ein und eine Übertragung von Daten ist kaum noch möglich. Unter dem Echtzeitaspekt führen Kollisionen und die damit verbundenen Konsequenzen einer zufälligen Verzögerung (dem sog. Jitter) zu einer Verletzung des gewünschten Determinismus, was das Verfahren somit zumindest für harte Echtzeitanwendungen unbrauchbar macht Problem der Schlangenbildung Für das Ethernet gibt es neben Hubs auch sog. Switches. Diese geben die Pakete nicht wie ein Hub an alle Endgeräte oder Subnetze weiter, sondern entscheiden paketweise anhand einer Analyse der Zieladresse, welchem Anschluss dieses Paket bereitgestellt wird. Beim Switched-Ethernet gibt es keine Kollisionen. Jedoch tritt nun ein neues Problem in den Vordergrund: Werden zwei Nachrichten gleichzeitig an den selben Empfänger geschickt, so landen beide Nachrichten beim Switch. Dieser muss jedoch mindestens eine Nachricht in einem internen Puffer zwischenspeichern. Da i.a. nicht vorhergesagt werden kann, wann eine Nachricht vor der Auslieferung zwischengespeichert werden muss, erhalten wir hier wieder eine zufällige Verzögerung. Für einen streng deterministischen Datenaustausch ist somit auch das Switched-Ethernet nicht ohne Weiteres geeignet Das predictable Ethernet als Lösung für das Kollisions- und Schlangenbildungsproblem? Eine Möglichkeit nun den obigen Problemen für Echtzeitanforderungen zu begegnen, stellt das pretictable Ethernet [15] dar. Die Idee hierbei ist, sicherzustellen, dass die Busauslastung generell auf unter 20% beschränkt wird. Dadurch erreicht man, dass sich die Kollisions-Wahrscheinlichkeit beim Shared-Ethernet bzw. die Schlangenbildungs-Wahrscheinlichkeit beim Switched-Ethernet für viele Echtzeit-Anwendungen ausreichend stark verringert. Dadurch, dass die Kollisionsfreiheit und das Ausbleiben von Schlangenbildung aber nicht garantiert werden können, ist diese Lösung auf keinen Fall für harte Echtzeitsysteme geeignet. Vorteile dieser Herangehensweise ist, dass man sich hierbei auf die Bereitstellung ausreichend leistungsfähiger Hardware beschränken kann, ohne das Ethernet in irgendeiner Weise zu modifizieren. Es ist aber offensichtlich eine schlechte Ausnutzung des Mediums und damit eine Verschwendung von Ressourcen. 48

57 Real-Time Ethernet und Ethernet Powerlink Determinismus herstellen Dennoch kann man auch beim Shared-/Switched-Ethernet und ebenso beim pretictable Ethernet Determinismus herstellen. Dazu werden i.a. Puffer von ausreichender Größe (meist in den Endgeräten) verwendet. Damit die nichtdeterministische Laufzeit der Datenpakete später wieder ausgeglichen bzw. korrigiert werden kann, muss jedes Datenpaket mit einem Zeitstempel versehen werden. Diese Art der Determinisierung des Durchschnittlaufzeitverhaltens der Datenpakete wird z.b. beim Video-Streaming oder beim VoIP (Voice over IP) verwendet. Die ankommenden Daten werden dabei zunächst in einem Puffer gesammelt und erst, wenn der Puffer zu einem bestimmten Gerade gefüllt ist, mit einer entsprechenden festen (!) Verzögerung (Delay) ausgeben. Diese Verzögerung macht dieses Verfahren i.d.r. für die harten Echtzeitanforderungen in der Automations- und Antriebstechnik unbrauchbar Weitere Probleme Bevor im nächsten Abschnitt auf komplexere Lösungen für das Determinismusproblem weiter eingegangen wird, seien zunächst noch kurz einige weitere, in Bezug auf einen Echtzeitbus, negative Eigenschaften des klassischen Ethernet und seiner Protokolle beleuchtet: Verbindungsorientiertheit: TCP/IP bietet nur Punktzu-Punkt-Verbindungen an. Es wird aber oft auch die Kommunikation der Netzteilnehmer untereinander notwendig. Sequenzorientiertheit: TCP/IP garantiert nur die zeitliche Abfolge der Telegramme. Bei vielen Echtzeitproblemen wird aber häufig nur der aktuellste Wert benötigt; dieser muss dafür möglichst schnell geliefert werden. Verkabelung: Beim Switched-Ethernet wird zwar eine Kollision ausgeschlossen jedoch müssen alle Endgeräte mit einem Switch verbunden werden. Dies führt oft zu einer aufwändigen und vorallem teuren Verdrahtung. Effizienz-Problematik: Häufig müssen sehr kleine Datenpakete verschickt werden, dafür aber sehr viele. Die Effizienz ist dann günstig, wenn der Overhead, d.h. die Differenz aus Nutzdaten- und Gesamtdatenlänge möglichst klein ist. Zum Overhead bei einem TCP/IP Datenpaket (s. Abbildung 1) gehören jedoch alle Datenbytes bis auf die Application Data, die Nutzdaten. Dies macht den Overhead bei TCP/IP für kleine Datenmengen jedoch äußerst groß. Abbildung 1: Ein typisches TPC/IP-Datenpaket (Quelle: Scheitlin [15]) Abbildung 2: Mögliche Strukturen für RTE (nach Felser [5]) 2.3 RTE-Konzepte Das Standard-Ethernet ist ohne Änderungen nicht in der Lage, die Anforderungen des Echtzeit-Ethernet zu erfüllen. Auf die Probleme wurde im vorangegangenen Abschnitt detailliert eingegangen. Hier sollen nun die drei bisherigen Grundkonzepte vorgestellt werden, auf denen alle bisherigen Lösungen für das RTE fußen. Die Kommunikations-Interfaces sind in verschiedene Schichten unterteilt. In Abbildung 2 sind diese Schichten aller vier Ethernet-Lösungen vereinfacht nebeneinander dargestellt, um die Unterschiede der Konzepte besser zu verdeutlichen. Alle Ethernet-Lösungen haben die universelle Verkabelung gemeinsam. Beim Non-Real-Time Ethernet benutzen die Nicht-Echtzeit-Programme die im ISO Standard festgelegten TCP/UDP-IP-Protokolle wie z.b. HTTP, FTP, SMTP oder DNS. Das Top-of-TCP/IP-Konzept verfolgt das zum normalen Ethernet-Standard kompatibelste Model. Hier werden die TCP/UDP-IP-Protokolle nicht verändert und die Echtzeitkommunikation auf der höheren Protokollstapel-Ebene verankert. Eine transparente Kommunikation über Netzwerkgrenzen hinweg zur Außenwelt über eine Anbindung an das Internet ist hier ohne großen Aufwand realisierbar. Verschiedene RTE-Lösungen beruhen auf diesem Konzept, unter ihnen sind beispielsweise Modbus-RTPS entwickelt von Schneider Electric oder EtherNet/IP entwickelt von Rockwell, ebenso P-NET oder auch Vnet/IP der japanischen Firma Yokogawa [5]. Der entscheidende Nachteil dieses Grundkonzeptes ist es, dass die Kommunikation über diesen Protokollstapel ausreichende Speicher- und Rechen-Ressourcen bedingt und nichtdeterministische Zeitverzögerungen der Kommunikation auftreten können. Mit dem Top-of-Ethernet-Konzept, welches als Drittes von links in Abbildung 2 dargestellt ist, möchte man genau die Schwachstellen des eben dargestellten Konzeptes ausgleichen. Hier wird an der Ethernet-Hardware, dem Zugriff darauf und der Ethernet-Schicht selbst nichts verändert. Jedoch wird neben dem aufgesetzten Standard-IP-Protokollstapel ein spezieller eigener Protokolltyp (Ethertype) im Ethernet- Frame spezifiziert. Auf diesem Konzept bauen die z.b. folgenden RTE-Lösungen auf: Ethernet Powerlink der Firma Bernecker + Rainer, TCnet von Toshiba, das chinesische EPA und Profinet CBA der Firma Siemens [5]. Das letzte hier vorgestellte Konzept für ein echtzeitfähi- 49

58 Christian Motika ges Ethernet beruht auf einer teilweisen Modifizierung des Ethernet selbst und damit auch seiner Hardware. Beim Modified-Ethernet-Konzept werden für die Geräte in der Echtzeitdomäne Änderungen an der Hardware nötig, mit dem Ziel, der Echtzeitproblematik noch gezielter und zwar direkt auf Hardwareebene und dem Zugriff darauf zu begegnen. Diese Änderungen erlaubt es i.d.r. aber immer noch dem Nicht-Echtzeit-Datenverkehr, ohne größere Schwierigkeiten verarbeitet zu werden. Jedoch werden viele Vorzüge des Top-of-Ethernet-Konzeptes, wie z.b. die kostengünstige Benutzung von Standardhardware, hier für Geräte der Echtzeit-Domäne nicht mehr möglich. Vertreter dieses Konzepts sind u.a. EtherCAT entwickelt von Beckhoff, SER- COS III (Ethernet-Erweiterung des SERCOS Standards) und Profinet IO von Siemens, eine Erweiterung von Profinet CBA [5]. 3. ETHERNET POWERLINK Nachdem im vorangegangenen Abschnitt bereits die Probleme des Ethernet herausgestellt und auch eine Klassifizierung der RTE-Lösungen vorgenommen wurden, wird nun eine Gesamtlösung des Top-of-Ethernet-Konzeptes näher beleuchtet. Hierbei wird Ethernet Powerlink vorgestellt und damit ein Weg aufgezeigt, mit den behandelten Problemen umzugehen. 3.1 Eigenschaften und Funktionsweise von EPL Weitere Anforderungen Die Anforderungen, welche an EPL gestellt werden beschränken sich nicht nur auf die im zweiten Abschnitt vorgestellten Anforderungen an einen Echtzeit-Feldbus. Weiterhin verspricht man sich durch die Ausnutzung der Vorteile des Ethernet noch etwas mehr: Kompatibilität zu Ethernet/Internet Kostengünstige Hardware Kostengünstige Wartung Hohe Geschwindigkeit Dadurch das Ethernet die technische Grundlage ist, sollte es Teilnehmern des EPL-Netzes auch unkompliziert möglich sein, mit der Außenwelt (z.b. dem Internet) zu kommunizieren. Aufgrund des Einsatzes von Standardhardware, sollte diese im Vergleich zur Spezialhardware herkömmlicher Feldbusse deutlich günstiger sein. Außerdem sollte das weit verbreitete Wissen um das Ethernet auch die Wartung des Systems deutlich günstiger machen. Schließlich muss die Ausnutzung der um Potenzen höheren Übertragungsgeschwindigkeit des Ethernet verglichen mit traditionellen Feldbussen möglich sein. Es wird sich anhand der nun folgenden Erklärungen der Funktionsweisen von EPL zeigen, wie die Echtzeitanforderungen, diese zusätzlichen Eigenschaften und das zugrunde liegende Ethernet in Einklang gebracht wurden und welche Erwartungen man an ein EPL-System stellen kann Slot Communication Network Management Die herkömmliche Kollisions-Strategie beim Ethernet führte zu einem ungewünschten Nicht-Determinismus. Um diesem nun angemessen zu begegnen, wird bei EPL dem CSMA/CD Verfahren ein Zeitschlitzverfahren, das Slot Communication Network Management (SCMN), übergeordnet. Das CS- MA/CD Verfahren bleibt dabei weiterhin unverändert auf der Ethernet-Schicht (s. Abbildung 5) implementiert, jedoch wird durch das übergeordnete Zeitschlitzverfahren eine Kollision oder Schlangenbildung auf einer höheren Schicht ausgeschlossen. Das Buszugriffsverfahren ist das sog. Polling [19], welches zeitgesteuert (time triggered) ist und für die generelle Vermeidung von Kollisionen und damit für die optimale Ausnutzung der Bandbreite und damit der enormen Geschwindigkeit, die das Ethernet bietet, sorgt. Es funktioniert innerhalb einer Echtzeit-Domäne nach einer Art Master-Slave- Beziehung, wobei der Master als Managing Node (MN) bezeichnet wird und die anderen Geräte, die Slaves, als Controlled Nodes (CN). Der MN übernimmt die Kontrolle über die Kommunikationssteuerung und die Zeitsynchronisation. Alle CNs dürfen nur Daten senden, wenn Sie vom MN dazu aufgefordert wurden. Dies stellt sicher, dass im gesamten Netzwerk(segment) nie mehrere Knoten gleichzeitig senden, da immer nur jeweils einer die Sendeberechtigung erhält. Somit ist eine Kollision und eine Schlangenbildung beim Shared-/Switched- Ethernet ausgeschlossen. Grundsätzlich werden alle Telegramme des MN per broadcast verschickt, d.h. alle am EPL- Netzwerk beteiligten Geräte der Echtzeit-Domäne erhalten diese Nachricht nahezu zeitgleich - bzw. mit einer geringen anbindungsbedingten Verzögerung, die konzeptionell möglichst klein gehalten werden muss. Die Anforderung an die Leistungsfähigkeit des MN sind relativ hoch, da er für das exakte Einhalten der Zyklenzeiten und einen möglichst minimalen Jitter verantwortlich ist. Die Kommunikation in einem EPL-Zyklus (s. Abbildung 3) läuft im Detail dann wie folgt ab: 1. Start-of-Cycle (SoC): Der MN sendet eine broadcast message an alle CNs, um allen zu signalisieren, dass nun ein neuer EPL-Zyklus beginnt. Die CNs können bzw. müssen dann auf diese Nachricht in adäquater Weise reagieren und einen abrufbereiten Status einnehmen. Auf der Basis dieses Telegramms beruht auch die zeitliche Synchronisation der Teilnehmer; daher ist es ganz wesentlich, dass dieser Start eines EPL-Zyklus möglichst Jitter-frei gehalten wird. 2. Isochronous Period: Innerhalb dieser Periode schickt der MN nacheinander Anfragen (Poll-Request) an die Teilnehmer, dies jedoch als Unicast-Telegramm, d.h. als direkt an den entsprechenden CN adressiertes Datenpaket. Die entsprechenden CNs antworten dann umgehend auf die Anfragen des MN mit den entsprechenden Daten (Poll-Response) und zwar als broadcast message. Die einzelnen CNs werden sequentiell in einer durch den MN fest vorgegebenen Reihenfolge abgearbeitet. Sie erhalten also vom MN ein Zeitfenster/Zeitschlitz fester Größe zum Antworten, daher 50

59 Real-Time Ethernet und Ethernet Powerlink Abbildung 3: Ein EPL-Zyklus (nach Scheitlin [15]) trägt das Verfahren auch den Namen Zeitschlitzverfahren. Da die Antwortdaten jeweils als broadcast message verschickt werden, stehen sie so jedem Netzteilnehmer ohne Umwege zur Verfügung - Dadurch wird eine effektive Querkommunikation ermöglicht, eine der Anforderungen an ein Feldbussystem (siehe dazu Abschnitt 2). Durch die festen Zeitfenster ist zudem die Kollisionsfreiheit gewährleistet, denn es wird immer nur ein CN zur Zeit zum Antworten aufgerufen. Im Extremfall fungiert der MN sogar nur noch als zentraler Taktgeber und verarbeitet selbst keine der vom CN bereitgestellten Informationen. 3. Asynchronous Period: Diese Phase schließt sich in jedem EPL-Zyklus an die Isochronous Period an. In der Version 1 von EPL wurde die isochrone Phase mit einem End-of-Cycle Telegramm abgeschlossen und es folgte in der asynchronen Periode zunächst eine invite unicast message an einen CN der zuvor in der isochronen Phase angemeldet hatte, asynchrone Daten versenden zu wollen. Diese beiden Telegramme wurden in Version 2 von EPL zusammengefasst zu einer Startof-Asynchronous-Nachricht (SoA) als multicast, welche nun am Anfang der asynchronen Periode versendet wird und alle CNs darüber informiert, dass die isochrone Phase beendet ist und sie evtl. darauf vorbereitet, in der jetzigen Phase ein asynchrones Telegramm zu erhalten oder zu senden. In dem asynchronen Zeitschlitz finden die azyklischen, nicht zeitkritischen und gerichteten (also Daten mit fester Zieladresse, die nicht als multicast versendet wurden) Platz; hierzu zählen z.b. UDP/IP- oder TCP/IP-Datenpakete. In dieser Phase ist es auch möglich von außen auf das EPL- Netzwerksegment zuzugreifen, um z.b. Daten auszulesen besondere Einstellungen oder Wartungsarbeiten vorzunehmen. Es können sowohl der MN als auch die CN über ihre Adresse angesprochen werden. Auch der Austausch von nicht-isochronen Daten eines CNs mit einem anderen findet in dieser Phase Platz. Pro EPL- Zyklus kann jedoch nur eine solche Nachricht im Zeitschlitz Platz finden. Bevor ein CN jedoch in der asynchronen Phase Daten senden darf, muss er dies in der isochronen Phase bereits beim MN anmelden. Dieser signalisiert ihm dann in der nächsten freien asynchronen Phase innerhalb der SoA multicast message, dass er seine Daten nun senden darf. 4. Idle Period: In dieser Phase passiert nichts mehr bis zum Anfang eines neuen EPL-Zyklus. Die Dauer der Phase ist abhängig von der Länge der asynchronen Periode und damit von der Zeit die anschließend noch bis zum Start des nächsten EPL-Zyklus verbleibt. Zusammenfassend garantiert das SCNM eine kollisionsfreie Datenkommunikation auf einem Shared-Ethernet nur über Repeater-Hubs auch ohne Switches. Natürlich garantiert es außerdem eine schlangenbildungsfreie Datenkommunikation für ein Switched-Ethernet; jedoch wird man in der Realität möglichst auf Switches verzichten, da sie langsamer sind und konfiguriert werden müssen. Für die isochronen Daten sind individuelle Zeitscheiben reserviert, dies macht den gewünschten Determinismus erst möglich. Die gemeinsam genutzten (shared) Zeitscheiben für die nichtdeterministischen asynchronen Daten ermöglichen dazu die Übertragung von z.b. TCP/UDP/IP-Datenpaketen und sind so für die gewünschte Kompatibilität verantwortlich Cyclic oder Prescaled/Multiplexed Die EPL-Zyklenzeit kann abhängig von der Implementierung eingestellt werden. Dennoch ist die Anzahl der teilnehmenden CNs in einem EPL-Segment beschränkt durch die Zeit der isochronen Periode. Da jedoch meistens längst nicht alle Teilnehmer in jedem Zyklus abgefragt werden und zeitkritische Daten senden müssen, wird daher zwischen zwei CN-Klassen unterschieden: 1. Cyclic: Die CNs dieser Klasse werden in jedem EPL- Zyklus abgefragt. 2. Prescaled/Multiplexed: Die CNs dieser Klasse müssen nur alle n Zyklen abgefragt werden. Durch die Prescaled-Klasse können nun auch langsamere Endgeräte verwendet verwendet werden und sich nur jedes n-te Mal aufrufen lassen EPL-Nachrichten Die Rahmenstruktur eines EPL-Telegramms entspricht prinzipiell immer dem gleichen Aufbau. Es besteht zunächst aus dem herkömmlichen Ethernet-Header. Er enthält standardkonform die Ursprungs- und Ziel-MAC-Adresse sowie den 51

60 Christian Motika EtherType (siehe Abschnitt 2) für EPL (0x88AB). Auf diesen folgt dann der für jeden Telegrammtyp unterschiedliche EPL-Header, welcher die Ursprungs- und Ziel-ID des EPL- Knotens enthält. Anschließend folgen dann evtl. die Daten und schließlich immer noch ein Ethernet-CRC zur Fehlererkennung. Die Rahmenstruktur ist in Abbildung 4 grafisch dargestellt. Die Adressierung der Knoten wird wie folgt gelöst: Um einen EPL-Knoten anzusprechen, wird innerhalb eines EPL-Segmentes nur die ELP-Knoten-ID des Geräts benutzt. Sie besteht bei den CNs aus einer Zahl zwischen 1 und 239. Diese ist zugleich das letzte Oktett der IPv4-Adresse des entsprechenden Knotens (z.b ELPNODEID). Der MN, von dem es pro Segment ja immer nur einen geben kann, hat stets die ELP-Knoten-ID 240. Eine broadcast message wird an die ELP-Knoten-ID 255 verschickt. Die SoC-Nachricht enthält im Daten-Teil die Netzwerkzeit des CN zur Synchronisation. In einem Poll-Request (PReq) und einem Poll-Response (PRes) werden als Daten PDO- Objekte übermittelt, auf welche später noch näher eingegangen wird. In einem PRes wird im EPL-Header zusätzlich noch der NMT-Status übermittelt, in dem z.b. Fehlerzustände gespeichert sind (siehe Abschnitt zur Fehlerbehandlung 3.1.9). Im SoA-Telegramm werden eine Request- Service-ID und ein Request-Service-Target, das ist die EPL- ID des anzusprechenden CNs, als Daten mitgesendet. In der asynchronen Antwort (ASnd) ist das Datenfeld im wesentlichen unspezifiziert und kann je nach Ziel unterschiedliche Nutzlast enthalten Eigener Protokollstapel Um die Echzeitfähigkeit sicherzustellen, wurde auf dem Ethernet aufbauend ein eigener Protokollstapel realisiert, der der Einhaltung des oben beschriebenen Verfahrens dient. Zusätzlich ist jedoch, um die Kompatibilität zum Standard-Ethernet zu wahren, ein TCP/UDP/IP Protokollstack parallel implementiert. Der prinzipielle Aufbau eines typischen EPL- Protokollstacks ist in Abbildung 5 dargestellt EPL-Referenzmodell und CANopen-Integration Etwas genauer betrachtet, basiert der eben vorgestellte Protokollstapel auf dem ISO/OSI Schichten-Modell und stellt eine Kombination aus TCP/UDP/IP und CANopen dar (vgl. dazu Abbildung 6). Die Applikationsschnittstelle von EPL in der Version 2 basiert auf den in CANopen Kommunikationsprofilen DS301 von CAN (bzw. EN ) [1] definierten Mechanismen. Diese Profile definieren einerseits die Process Data Objects (PDO) und andererseits die Service Data Objects (SDO). Die PDOs sind grundsätzlich die Daten-Objekte, welche in den Nachrichten der isochronen Phase verschickt werden Abbildung 4: Rahmenstruktur eines EPL-Pakets (nach EPSG [2]) Abbildung 5: Protokollstack eines EPL-Nodes (Quelle: EPSG [3]) (Poll-Request und Poll-Response) und enthalten z.b. Sensorwerte oder Aktuatorenanweisungen. Ein CN kann jeweils mehrere Daten-Objekte empfangen aber nur ein solches Daten-Objekt, nämlich sein eigenes, senden. Ein MN kann dagegen alle Daten-Objekte aller (in einem Powerlink-Segement bis zu 240 teilnehmenden CNs) empfangen und eben so viele Daten-Objekte senden, um mit allen teilnehmenden Knoten kommunizieren und Daten austauschen zu können. Über das Object Directory kann der Aufbau eines solchen Prozess-Daten-Objektes festgelegt und modifiziert werden. Hier werden auch alle PDO-Werte unter einem Index bzw. auch unter einen Namen abgelegt. Sie können mit den nachfolgend erwähnten SDOs auch asynchron beschrieben (Aktuatoren) bzw. asynchron ausgelesen (Sensoren) werden. Das Object Directory stellt allgemein gesprochen die Schnittstelle zwischen der eigentlichen Applikation und den darunter liegenden Kommunikationsschichten dar. Hier können von der Anwendungsseite her auch sog. call back functions mit einem Applikationsobjekt verknüpft werden, wodurch eine ereignisgesteuerte Benachrichtigung der Anwendung bei busseitig veranlasster Datenänderung implementiert werden kann. Die SDOs werden dazu verwendet das Verhalten der CNs zu veränderen. Beispiele dafür sind z.b. die Übergabe oder Änderung von Parametern oder Konfigurationsdaten eines CNs. Mit SDOs ist es auch möglich einzelne Einträge im Object Directory zu lesen oder zu beschreiben. Diese Einträge können über einen Index/Subindex oder ihren Namen angesprochen werden. SDOs können über verschiedene Wege übermittelt werden: Standardmäßig werden sie über das UDP/IP Protokoll geschickt, jedoch ist es auch möglich, dafür ein ELP-ASnd oder eine PDO-Nachricht mittels eines SDO-Containers zu verwenden. Das Network Management (NMT) enthält die grundlegenden Netzwerk-Einstellungen und Netzwerk-Stati sowie sog. Statemachines. Letztere definieren den Operations-Modus (dieser kann entweder standardmäßig der Basic Ethernet Mode sein, d.h. der Knoten verhält sich wie ein normales Ethernet-Gerät; oder er kann der EPL Mode sein, dann befindet sich das Gerät entweder als MN oder als CN einsatzbereit für das SCNM in einem EPL-Netzwerk-Segment). Die Statemachines definieren außerdem noch das Boot-Verhalten des Geräts und können ggf. auch von außen verändert wer- 52

61 Real-Time Ethernet und Ethernet Powerlink bzw. zu einer Ethernet-Domäne oder auch zu einem anderen EPL-Segment kommt hier ein spezieller EPL-Router zum Einsatz, welcher oft auch in den MN des betreffenden Segements integriert ist und auch die IP-Adressen-Übersetzung (NAT) übernimmt. Der Router kann jedoch auch in einen EPL-Switch integriert sein, wie in der Abbildung 7 zu sehen ist. Mit solchen MNs ist es auch möglich mehrere EPL- Segmente miteinander z.b. über das Ethernet zu verbinden. Hierbei findet die Uhren-Synchronisation untereinander mit Hilfe des in jedem MN implementierten IEEE 1588 Protokolls [8] statt. An dieser Stelle wird noch einmal deutlich, welche hohen Leistungsanforderungen i.a. an den MN gestellt werden. Abbildung 6: Ethernet Powerlink-Referenzmodell (Quelle: IXXAT [10]) den. Schließlich übernimmt die NMT auch die Behandlung von Fehlerfällen auf Netzwerkebene, auf die später noch eingegangen wird. Der dargestellte EPL Lower Layer ist die EPL-Schicht, die für das Zusammenspiel aller anderen Komponenten verantwortlich ist. Hier wird z.b. der im NMT festgelegte Betriebsmodus realisiert, genauso wie die lokalen Fehlerbehandlungen und das SCNM. MAC und PHY entsprechen, wie bereits an anderer Stelle erwähnt, der gleichen Netzzugangsschicht, die auch beim Standard-Ethernet verwendet wird Open- und Protected-Mode EPL unterstützt zukünftig zwei verschiedene Operationsmodi, den Open-Mode und den Protected-Mode. Je nach dem ob die Kompatibilität zu anderen Ethernet-Komponenten oder die maximale Performance beim Echtzeitverhalten im Vordergrund steht, sollte man sich konzeptionell für den einen oder den anderen Betriebsmodus entscheiden. Der Protected-Mode wurde bereits mit der Version 1 von EPL eingeführt. Hier sind die vollen Echtzeiteigenschaften von EPL und die maximale Performance, d.h. minimaler Jitter und kurze Zyklenzeiten, garantiert. Im Protected-Mode müssen Echtzeit-Domäne und Ethernet-Domäne physisch voneinander getrennt werden. Innerhalb der Echtzeit-Domäne dürfen ausschließlich EPL-Geräte Verwendung finden; Standard-Ethernet-Knoten sind hier nicht zugelassen, da sie den SCNM-Mechanismus zerstören und Kollisionen verursachen würden. Mit Hilfe des Protected-Modes sind Prozesse der IAONA 1 Echtzeitklasse 4 realisierbar. Das Zeitverhalten wird hier mit Hilfe des Zeitschlitzverfahrens gesteuert. Für eine Verbindung der Echtzeit-Domäne zur Außenwelt 1 Industrial Automation Open Network Alliance, Einteilung in vier Echtzeitklassen siehe dazu Scheitlin [16] Im Open-Mode, der erst zukünftig mit Version 3 von EPL realisiert wird, dürfen auch innerhalb eines EPL-Segementes, also der Echtzeit-Domaine, Nicht-EPL-Geräte enthalten sein. Durch diese Aufweichung ist zwar ein deterministisches Zeitverhalten immer noch garantiert, allerdings sind die Zeitbeschränkungen wie die minimale Zyklenzeit und der minimale Jitter gelockert und die Steuerung des Zeitverhaltens basiert hier auf Zeitstempeln gemäß des IEEE Innerhalb gewisser Grenzen sind im Open-Mode dann auch Kollisionen und Schlangenbildung zugelassen. Dadurch evtl. entstehende Verzögerungen werden dann durch die Zeitstempel rechnerisch wieder ausgeglichen. Wegen dieser Problematik jedoch lassen sich im Open-Mode auch nur Prozesse bis zu der IAONA Echtzeitklasse 3 realisieren. EPL wird im Open- Mode daher nicht besser als andere auf Zeitstempeln basierende Lösungen sein. Die Spezifikation sieht auch vor, dass eine Umschaltung zwischen beiden Betriebsmodi automatisch erfolgt. Dabei präferiert EPL immer den Protected-Mode und schaltet nur in den Open-Mode herunter, falls mindestens ein Nicht-EPL-Gerät im Segment angeschlossen ist Benutzung von Standardhardware EPL baut im Sinne des Top-of-Ethernet-Konzeptes auf der Ethernet-Schicht des Protokollstapels auf. Dies bedeutet, dass EPL das physikalische Medium genau nach Ethernet- Standard benutzt. Hierbei sind die verwendeten Controller wie die PHYs (Physical Interface, ein spezieller Elektronik- Chip, der den Zugriff auf das physikalische Medium inklu- Abbildung 7: EPL-Segment-Synchronisation (Quelle: EPSG [2]) 53

62 Christian Motika sive der Vorverarbeitung durchführt und kontrolliert) und die MACs (Media Access Controlled Node, ein Chip der das Ethernet-Protokoll inklusive des CSMA/CD beherrscht) in den Endgeräten für das Standard-Ethernet und für EPL- Segmente identisch. Da am CSMA/CD Verfahren konzeptionell nichts verändert wird und die übergeordnete Zugriffskontrolle auf der höheren EPL-Schicht stattfindet, können also in Powerlink-Hardware kostengünstig Standard-Ethernet-Chips verbaut werden Fehlerbehandlung Schließlich soll nun im Folgenden noch auf das Error Handling von EPL eingegangen werden, welches allerdings aktuell sehr stark weiterentwickelt wird. Zunächst kann bei einem Ausfall eines CNs das Netzwerksegment vollständig in Betrieb bleiben. Das Ersatzgerät kann jederzeit ohne Neukonfiguration des MNs oder Routers eingefügt werden, und das im laufendem System. Damit unterstützt EPL modulare Konzepte und Hot Plugging. Auf der Netzwerk-Ebene unterstützt EPL sowohl die selbstständige Erkennung von ausgefallenen, aber auch von wieder aktiven Knoten. Hierbei werden durch die NMT die Fehlermeldungen einerseits protokolliert und andererseits für die Applikationsebene bereitgestellt, um hier auch in der Anwendung adäquat reagieren zu können. Über die Poll- Response wird im EPL-Header der NMT Status auch den anderen Geräten im Segment mitgeteilt, so dass auch diese auf evtl. Fehlerzustände eines Knotens angemessen reagieren können. 3.2 Vor- und Nachteile von EPL Nachdem wir im vorangegangenen Abschnitt die Funktionsweise von EPL näher betrachtet haben, ist es nun an der Zeit, einmal sowohl die besonders positiven als auch negativen Eigenschaften von EPL vor allem in Bezug auf seinen Einsatz als Echtzeit-Feldbus herauszustellen. Zyklenzeit [ms] Max Anzahl der Geräte 0,2 8 0,5 12 1,0 30 2,0 66 3,0 102 Tabelle 1: Mögliche Zyklenzeit abhängig von der Anzahl der Geräte, hier mit 80 Byte Daten (nach Schwager [19]) Zyklenzeit: EPL gestattet auch Zyklenzeiten von äußerst kurzer Dauer (bis zu 200µs), die einen Einsatz in der Antriebstechnik ermöglichen (siehe auch Tabelle 1) [2, 19]. Jitter: Die Synchronisation eines MN über ein SoC kann aufgrund der hohen Geschwindigkeit des Ethernets mit einem Jitter (Präzision) bis auf unter 1µs garantiert werden [3]. Nach Herstellerangaben werden mit Version 2 von EPL sogar Jitterwerte unterhalb von 400ns möglich [19]. Busauslastung: Die Busauslastung kann durch Bandbreitenoptimierung (offline scheduling) gegen 100% gehen. Diese kann deswegen erreicht werden, da in jedem Zyklus Daten verschickt werden können, (cycled oder multiplexed). Die Echtzeiteigenschaften leiden nicht unter dieser Auslastung, da das Verfahren time-triggered ist und deterministisch bleibt Verbreitung: Da die Ethernettechnologie weit verbreitet ist, kann besonders bei der Verkabelung auf Standard-Twisted-Pair-Kabel zurückgegriffen werden, aber auch teilweise bei der Hardware auf Standard-Ethernet-Komponenten. Dies stellt ein enormes finanzielles Einsparpotential gegenüber der meist Spezialanfertigungen für herkömmliche Feldbusse dar. Auch gibt es für das Ethernet bereits umfangreich zur Verfügung stehende Software und Werkzeuge für die Einrichtung und Wartung, die nicht erst teuer neu entwickelt werden müssen. Felderprobt: EPL war die erste ethernetbasierte Echtzeitbus-Technologie, die nun bereits über einen langen Zeitraum im Feldbereich erprobt ist. Nach Angaben von Bernecker + Rainer waren schon im Jahr 2004 über EPL-Geräte bei mehr als 100 Kunden im Einsatz [19]. Abbildung 8: Topologien eines EPL-Netzwerksegmentes (Quelle: Pfeiffer [14]) Vorteile Datendurchsatz: Da das Ethernet die technische Grundlage bildet, sind die Geschwindigkeitsvorteile gegenüber herkömmlichen Feldbussen groß. Bereits das Fast Ethernet ist hier bis zu 100 Mal schneller; Durch die Nutzung von Gigabit- Ethernet oder dem 10-Gigabit-Ethernet werden in Zukunft selbst diese Grenzen noch einmal gesprengt. Topologie: Für EPL gibt es keine Topologiebeschränkungen. Das bedeutet, dass sowohl Stern-, Baum- als auch Linienstrukturen möglich sind [14, 17, 2]. Auch ein Einsatz von Lichtwellenleitern ist denkbar. Verschiedene Topologien können zudem durch Hubs kombiniert werden. Hierbei entfallen sogar die beim CSMA/CD Verfahren (siehe Abschnitt 2) für eine Collision Domain bestehenden Kaskadierungsbeschränkungen für die Hintereinanderschaltung von vier Hubs, da Kollisionen durch das SCNM von vornherein ausgeschlossen werden (bei einer Infrastruktur mit Hubs muss jedoch der maximale Jitter bedacht werden; bei der Verwendung von Switches sowohl der maximale Jitter als auch das maximalen Delay). Da viele EPL-Geräte bereits mit einem integrierten Repeater-Hub ausgerüstet sind, ist der Verkabelungsaufwand gerade bei der Linientopologie sehr gering (siehe Abbildung 8). Switches werden nicht benötigt! 54

63 Real-Time Ethernet und Ethernet Powerlink Komplexität: Da einerseits das Wissen über das Ethernet bereits weit verbreitet ist und andererseits keine Switches eingesetzt werden, deren Konfiguration enormes Fachwissen voraussetzen würde, hält sich die Komplexität bei der Installation, Erweiterung oder Wartung eines EPL-Netzwerks in Grenzen und reduziert auch die Kosten für Spezialschulungen oder die Netzwerkwartung. Offenheit: Seit April 2002 ist der Standard von EPL für andere Firmen offen gelegt. Durch die Gründung der EPSG im Herbst 2002, wurde eine unabhängige Expertengruppe ins Leben gerufen, mit dem Ziel, das Echtzeit-Ethernet im industriellen Umfeld zu etablieren. Dabei ist die Technologie lizenz- und patentfrei und basiert auf weltweiten Standards und frei zugänglichen Spezifikationen, um so Drittanbietern den Einstieg (auch finanziell) zu erleichtern und die Verbreitung voranzutreiben. Kosten: Neben der Verwendung von bereits für den großen Markt entwickelten Standard-Ethernet-Chips, kann für die Vernetzung von EPL-Knoten auf günstigere Hubs zurückgegriffen werden. Diese sind zudem schneller und müssen nicht erst wie die teureren Switches konfiguriert werden. Kompatibilität: Im Open-Mode ist EPL voll kompatibel auch zu Standard-Ethernet-Komponenten und deren Standard-Kommunikation. Diese Kompatibilität muss jedoch für den Protected Mode teilweise aufgegeben werden; hier wird ein Gateway nötig, um weiterhin mit der Außenwelt zu kommunizieren. Die Kommunikation findet jedoch mit konventioneller Ethernet-Hardware (alles unterhalb der Ethernetschicht im EPL-Reference-Model - siehe Abbildung 5) statt [17, 15]. Außerdem wurde durch die Integration der CANopen Kommunkationprofilen in EPL V2 einerseits die Migration von CANopen zu EPL auf Softwareebene stark erleichtert, andererseits damit auch die Weiterverwendbarkeit bereits existierender CANopen-Anwendungs- und Geräteprofile ermöglicht Nachteile Robustheit: Um Anlagen und Anlagenteile in der rauhen industriellen Umgebung ausfallsicher zu machen, wird den Geräten auch eine entsprechende Robustheit abgefordert. Der RJ45-Stecker der Twisted-Pair-Ethernet-Verbindungen hat sich bei bei Tests als erstaunlich robust gegen das Eindringen von Staub oder sogar Flüssigkeiten erwiesen [11]. Für allerhöchste Robustheitsansprüche steht darüberhinaus auch der vierpolige M12-Steckverbinder nach IEC zur Verfügung [14]. Leider ist gerade bei den off-theshelf Standard-Ethernet-Produkten, von den Kabeln/Steckern abgesehen, diese Robustheit oft nicht gegeben, was einen Einsatz von ihnen im Feld problematisch macht. Overhead: In der Automatisierung werden meistens nur geringe Datenmengen von Gerät zu Gerät verschickt, angefangen von nur wenigen Bit bis hin zu einigen Bytes. Jedoch besteht ein Ethernetpaket aus mindestens 47 Bytes [15]. Zwar kann dieser Nachteil von EPL durch seine Geschwindigkeit wieder ausgeglichen werden, dennoch stellt dieser Overhead eine Verschwendung von Ressourcen dar, die jedoch konzeptionell bedingt ist. Politik: Leider ist EPL geschäftspolitisch (immernoch) umstritten [15]. Ursprünglich von einem der größeren Marktteilnehmer dem österreichischen Steuerungsherstgeller B&R entwickelt, taten und tun sich direkte Konkurrenten bis heute schwer diese Lösung zu adaptieren und entwickelten für ihre Kundschaft lieber eigene ethernetbasierte Echtzeitlösungen, die jedoch allesamt nicht kompatibel zueinander sind (Siemens das ProfiNet, Rockwell das Ethernet/IP, Bosch das Sercos III und Beckhoff das EtherCat). Sicherheit und Redundanz: Für einige industrielle Umgebungen unverzichtbar ist die Ausfallsicherheit durch Redundanz und die Sicherheit, dass Daten korrekt ankommen. EPLSafety und EPL High Availability nehmen sich dieser Herausforderungen an. Jedoch sind diese Neuentwicklungen derzeit noch nicht ausgereift und warten noch auf ihre Markteinführung, wie der Ausblick auf die neusten Entwicklungen im nächsten Abschnitt zeigt. 3.3 Aktuelle Entwicklung Abschließend soll hier noch kurz auf die aktuellsten Entwicklungen von EPL und um EPL herum eingegangen werden Ethernet Powerlink Safety Ethernet Powerlink Safety (EPLSafety) ist ein offenes Sicherheitsprotokoll, welches einen gesicherten Austausch von Daten über das Ethernet ermöglicht. Obwohl EPLSafety auch zusammen mit anderen Übertragungslösungen wie z.b. CAN genutzt werden kann, ist es für den Einsatz zusammen mit EPL optimiert. EPLSafety benutzt dabei die unsichere Übertragungsschicht zum Austausch der gesicherten Daten innerhalb des sog. EPLSafety-Frames. Diese Frames werden von der Übertragungsschicht nicht mehr weiter interpretiert. Ein EPLSafety-Gerät erkennt zudem automatisch um was für eine Art von Telegramm (normal oder gesichert) es sich handelt. Dies macht auch einen gemischten Einsatz von EPL- und EPLSafety-Knoten in einem Segment möglich. EPLSafety erfüllt dabei Sicherheitsanforderungen bis zu SIL- 3 (Safety Integrity Level) gemäß der IEC61508 Spezifikation. Auch der deutsche TÜV Rheinland hat die Eignung des Protokolls in der Spezifikation 1.0 im November 2005 festgestellt. Um diesen hohen Sicherheitsanforderungen zu genügen, werden durch die Verwendung spezieller Nachrichtenstrukturen nahezu alle systematischen sowie stochastischen Fehler erkannt und die Restfehlerwahrscheinlichkeit so auf unter gedrückt. Beispielsweise wird der CRC- Typ dynamisch flexibel an die Nachrichtenlänge angepasst oder die Framelänge kann der benötigten Menge an Nutzdaten (1 bis 32 Byte) angepasst werden. Durch Zeitsynchronisation lassen sich Datenverluste oder Verzögerungen erkennen. Daneben werden auch Wiederholungen, Einfügung und Maskerade der Daten erkannt. EPLSafety erlaubt außerdem den Aufbau von einander getrennter Sicherheitszonen, wobei eine Störung in einer Zone dabei nach dem Error-Containment-Prinzip keine Auswirkungen auf die anderen Zonen hat. Fertige Implementierungen werden noch vor Ende des Jahres 2006 erwartet Ethernet Powerlink High Availability Eine spezielle Neuentwicklung für EPL selbst stellt das Ethernet Powerlink High Availability (EPLHA) dar. Mit EPLHA 55

64 Christian Motika soll Redundanz nahtlos in EPL integriert werden. Es werden damit sowohl redundante CNs als auch die redundante Nutzung zweier Übertragungsmedien möglich werden. Bei einem Ausfall soll die switch-over-time innerhalb eines EPL- Zyklus stattfinden und damit so gut wie keine Verzögerung mit sich bringen und eine extrem schnelle Wiederaufnahme des Normalbetriebs gewährleisten. Damit wird der Einsatz von EPL zukünftig auch in hochsicherheitskritischen Umgebungen wie dem Kraftwerksbau oder der Flugzeugtechnik ermöglicht. Die Kompatibilität zu Standard-EPL-Geräten soll mit EPLHA in vollem Umfang gewahrt bleiben. Die EPLHA-Spezifikation befindet sich kurz vor ihrer Fertigstellung und soll noch vor Ende 2006 veröffentlicht werden Gigabit Ethernet Auch beim Thema Übertragungsmedien befindet sich EPL in einer Weiterentwicklung. Zukünftig soll hier neben dem Fast Ethernet auch das Gigabit Ethernet benutzt werden. Da sich EPL vollkommen standardkonform verhält, was die untersten Schichten des Protokollstapels betrifft, wird eine schnelle und problemlose Integration von Gigabit Ethernet in den EPL-Standard möglich. Diese soll ebenfalls bald, bis Anfang 2007 erfolgen Besondere EPL-Geräte Neuartige EPL-Geräte befinden sich derzeit noch in der Entwicklung und sollen möglichst bald dem Markt zur Verfügung stehen. Dabei handelt es sich beispielsweise um eine EPL-PCI-Schnittstellenkarte für den PC. Mit einer solchen Karte soll es möglich werden, PC-basierende Steuerungsandwendungen zu implementieren oder einen PC für die Analyse zur Diagnose oder zu Testzwecken zu verwenden. Außerdem wird es damit möglich sein ein einfaches Gateway für hierarchische EPL-Systeme bereitzustellen. Eine andere Neuentwicklung ist z.b. ein EPL-CANopen-Gateway. Mit diesem können dann Prozessdaten und Servicedaten zwischen beiden Netzwerken ausgetauscht werden. Außerdem ermöglicht solch ein Gerät EPL als Backbone für bestehende CANopen- Systeme zu verwenden oder die Integration von CANopen- Subnetzen in ein übergeordnetes EPL-System. 4. FAZIT EPL wird bereits heute in zahlreichen Bereichen der Industrieautomation erfolgreich eingesetzt. Hierzu zählen z.b. Spritzgießmaschinen und Verpackungsmaschinen mit Zyklenzeiten zwischen 400µs und 800µs aber auch Großanlagen mit über 50 Knoten und immer noch Zyklenzeiten um die 2, 5ms [14]. Damit beweist EPL, dass es bereits heute möglich ist, sowohl weichen als auch harten Echtzeitanforderungen mit Hilfe des Ethernet zu begegnen. Aufgrund der weiten Verbreitung ist eine stetige Weiterentwicklung des Ethernet ohnehin zu erwarten. Auch eine Durchsetzung des Realtime-Ethernet gegen die bisher noch dominierenden konventionellen Feldbusse wäre aufgrund der aufgezeigten Vorteile durchaus denkbar. Mit dem Ethernet wird sich auch EPL weiterentwickeln. Durch die Öffnung des Protokolls und die Integration von CANopen wurden schon entscheidende Schritte gemacht, die Attraktivität von EPL weiter zu steigern. Die im letzten Abschnitt betrachteten laufenden Neuentwicklungen belegen das Engagement aller Partner der EPSG, EPL für die Zukunft zu rüsten, damit sich der Einsatzbereich von Ethernet Powerlink auch um den sicherheitskritischen Bereich erweitert und auch hier von den vielen Vorteilen der Ethernet- Technologie, die das RTE mitbringt, profitiert werden kann. 5. LITERATURVERZEICHNIS [1] CANopen: [2] EPSG: Einführung in ETHERNET Powerlink [3] EPSG: Real Time - Industrial Ethernet is Real [4] Ethernet Powerlink Standardization Group: [5] Felser, M.: Real-Time Ethernet - Industry Prospective [6] IEEE: [7] Institute of Electrical and Electronics Engenieers: IEEE CSMA/CD (ETHERNET), [8] Institute of Electrical and Electronics Engenieers: IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, [9] International Electrotechnical Commission: IEC , Digital data communications for measurement and control, [10] IXXAT: Powerlink Technologie [11] Jones, M.: Real-Time Solutions for Industrial Ethernet [12] Kopetz, H.: Real-Time Systems. Kluwer Academic Publishers, [13] Mueller, M.: Ethernet ins Feld, aber wie? [14] Pfeiffer, A.: Echt Zeit fuer Ethernet - Ethernet Powerlink verwendet Zeitscheibenverfahren [15] Scheitlin, H.: Echtzeit Ethernet: Realitaet oder Illusion? [16] Scheitlin, H.: Ethernet Powerlink - Klipp und Klar [17] Schlegel, C.: ETHERNET Powerlink Implementation Strategies [18] Schwager, J.: [19] Schwager, J.: Ethernet erreicht das Feld [20] XEROX: [21] Zuericher-Hochschule-Winterthur:

65 Teil III. Anhang: Vorträge

66

67 Einführung in Echtzeitbetriebssysteme Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Einführung in Echtzeitbetriebssysteme Vortrag zum Seminar Echtzeit-Betriebssysteme und -Bussysteme Christoffer Menk Christian-Albrechts-Universität zu Kiel Arbeitsgruppe für Echtzeitsysteme und Eingebettete Systeme Kiel, Germany Christoffer Menk Einführung in Echtzeitbetriebssysteme 1 / 30 Seminarvortrag Einführung in Echtzeitbetriebssysteme Vortrag zum Seminar Echtzeit-Betriebssysteme und -Bussysteme Christoffer Menk Christian-Albrechts-Universität zu Kiel Arbeitsgruppe für Echtzeitsysteme und Eingebettete Systeme Kiel, Germany Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Motivation Echtzeitsysteme und Eingebettete Echtzeitsysteme befinden sich überall in der Umgebung. 98% der weltweit hergestellten Mikroprozessoren in Eingebetteten Systemen In Umgebung oft Speicher und Rechenleistung begrenzt Systeme müssen Aufgaben oft in bestimmter Zeit erledigen Einsatz von verschiedenen Echtzeitbetriebssystemen Herkömmliche Betriebssysteme i.a. nicht geeignet Christoffer Menk Einführung in Echtzeitbetriebssysteme 2 / 30 Seminarvortrag Motivation Motivation Echtzeitsysteme und Eingebettete Echtzeitsysteme befinden sich überall in der Umgebung. 98% der weltweit hergestellten Mikroprozessoren in Eingebetteten Systemen In Umgebung oft Speicher und Rechenleistung begrenzt Systeme müssen Aufgaben oft in bestimmter Zeit erledigen Einsatz von verschiedenen Echtzeitbetriebssystemen Herkömmliche Betriebssysteme i.a. nicht geeignet Ein Echtzeitbetriebssystem stellt nur die nötigen Mittel für die Bearbeitung einer Aufgabe zur Verfügung. Die Applikation, die dann auf diesem Echtzeitbetriebssystem läuft, muss garantieren, dass das System auch wirklich in Echtzeit arbeitet. 59

68 Christoffer Menk Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Inhalt 1 Unterschiede zu herkömmlichen Betriebssystemen 2 Aufbau eines Echtzeitbetriebssystems 3 Elemente eines Echtzeitbetriebssystems 4 Beispiele von bekannten Echtzeitbetriebssystemen 5 Schlussfolgerungen Christoffer Menk Einführung in Echtzeitbetriebssysteme 3 / 30 Seminarvortrag Inhalt Inhalt 1 Unterschiede zu herkömmlichen Betriebssystemen 2 Aufbau eines Echtzeitbetriebssystems 3 Elemente eines Echtzeitbetriebssystems 4 Beispiele von bekannten Echtzeitbetriebssystemen 5 Schlussfolgerungen Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Prozessverwaltung, Speicherverwaltung Prozessverwaltung: Echtzeitbetriebssysteme müssen zeitlich determiniert arbeiten. Herkömmliche Betriebssysteme arbeiten i. A. nicht determiniert Beispiel: Time-Sharing-Scheduler Nicht geeignet für Echtzeitbetriebssysteme Speicherverwaltung: Herkömmliche Betriebssysteme benutzen Heap Problem: External Memory Fragmentation Kann durch einen Garbage Collector behoben werden Andere Lösungen für Echtzeitbetriebssysteme Christoffer Menk Einführung in Echtzeitbetriebssysteme 4 / 30 Seminarvortrag Unterschiede zu herkömmlichen Betriebssystemen Prozessverwaltung, Speicherverwaltung Prozessverwaltung, Speicherverwaltung Prozessverwaltung: Echtzeitbetriebssysteme müssen zeitlich determiniert arbeiten. Herkömmliche Betriebssysteme arbeiten i. A. nicht determiniert Beispiel: Time-Sharing-Scheduler Nicht geeignet für Echtzeitbetriebssysteme Speicherverwaltung: Herkömmliche Betriebssysteme benutzen Heap Problem: External Memory Fragmentation Kann durch einen Garbage Collector behoben werden Andere Lösungen für Echtzeitbetriebssysteme Es gibt inzwischen auch Real-Time Garbage Collectoren, die das Problem der External Memory Fragmentation deterministisch beheben. 60

69 Einführung in Echtzeitbetriebssysteme Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Prozesswechselzeit Kalinsky, D.: Basic Concepts of Real-Time Operating Systems, Herkömmliche Betriebssysteme durchsuchen Array von Prozessen Für Echtzeitsystem nicht geeignet Echtzeit bedeutet nicht Schnelligkeit Christoffer Menk Einführung in Echtzeitbetriebssysteme 5 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Übersicht 1 Unterschiede zu herkömmlichen Betriebssystemen 2 Aufbau eines Echtzeitbetriebssystems 3 Elemente eines Echtzeitbetriebssystems 4 Beispiele von bekannten Echtzeitbetriebssystemen 5 Schlussfolgerungen Christoffer Menk Einführung in Echtzeitbetriebssysteme 6 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Kernel eines Echtzeitbetriebssystems Grundlegende Funktionen eines Echtzeitbetriebssystems: Prozess-, Interruptverwaltung und Prozesskommunikation. Kernel ist kleinster Bestandteil oder schon komplettes Echtzeitbetriebssystem Polled-Loop-System Round-Robin-System Kommerzielle Echtzeitbetriebssysteme benutzen Mikro-Kernel Architektur Nur wichtigsten Funktionen im Kernel-Modus Christoffer Menk Einführung in Echtzeitbetriebssysteme 7 / 30 Seminarvortrag Aufbau eines Echtzeitbetriebssystems Kernel eines Echtzeitbetriebssystems Kernel eines Echtzeitbetriebssystems Grundlegende Funktionen eines Echtzeitbetriebssystems: Prozess-, Interruptverwaltung und Prozesskommunikation. Kernel ist kleinster Bestandteil oder schon komplettes Echtzeitbetriebssystem Polled-Loop-System Round-Robin-System Kommerzielle Echtzeitbetriebssysteme benutzen Mikro-Kernel Architektur Nur wichtigsten Funktionen im Kernel-Modus Polled-Loop-Systeme sind die einfachsten Echtzeit-Kernels. In diesem System gibt es einen einzelnen sich wiederholenden Test, der überprüft, ob ein Event eingetreten ist oder nicht. Für diese Systeme wird kein Scheduling oder Prozesskommunikation benötigt, weil es nur einen Prozess gibt. In einem Round-Robin-System werden mehrere Prozesse sequentiell ausgeführt, oft in Verbindung mit einer cyclic executive. Jeder Prozess hat hierbei eine bestimmte Zeit, in der er ausgeführt werden darf. Der Prozess wird so lange ausgeführt, bis er sich selber beendet, oder ein clock interrupt das Ende seiner Ausführungszeit vorgibt. 61

70 Christoffer Menk Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Mikro-Kernel: Vergleich zu monolithischem Kernel (a) Mikro-Kernel (b) Monolithischer-Kernel Christoffer Menk Einführung in Echtzeitbetriebssysteme 8 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Mikro-Kernel: Vor- und Nachteile Vorteile: Hohes Maß an Sicherheit und Stabilität Fehlfunktionen von Komponenten im User-Modus können abgefangen werden. Portierbarkeit Skalierung Nachteile: Viele Wechsel vom User- in Kernel-Modus. Etwas langsamer als monolithischer Kernel. Christoffer Menk Einführung in Echtzeitbetriebssysteme 9 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Übersicht 1 Unterschiede zu herkömmlichen Betriebssystemen 2 Aufbau eines Echtzeitbetriebssystems 3 Elemente eines Echtzeitbetriebssystems 4 Beispiele von bekannten Echtzeitbetriebssystemen 5 Schlussfolgerungen Christoffer Menk Einführung in Echtzeitbetriebssysteme 10 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Elemente eines Echtzeitbetriebssystems Christoffer Menk Einführung in Echtzeitbetriebssysteme 11 / 30 62

71 Einführung in Echtzeitbetriebssysteme Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Prozessverwaltung Kategorien von Echtzeit-Scheduling Algorithmen: Christoffer Menk Einführung in Echtzeitbetriebssysteme 12 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Prozessverwaltung Soft: Best-Effort-Algorithmen Hard: Algorithmen sollten garantieren, dass ein Prozess seine deadline einhält. Dynamic: Entscheidung zur Laufzeit nicht komplett vorhersagbar, aber flexibel Static: Entscheidungen während des Kompilierens vorhersagbar, aber nicht flexibel Christoffer Menk Einführung in Echtzeitbetriebssysteme 13 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Prozessverwaltung Preemptive: Ausführender Prozess immer unterbrechbar Nonpreemptive: Prozess wird nur beendet, wenn er dieses selber entscheidet oder mit seiner Ausführung fertig ist. Wird in kleineren Systemen eingesetzt Christoffer Menk Einführung in Echtzeitbetriebssysteme 14 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Prozesskommunikation Shared Memory: Einfache Kommunikation weil Betriebssystem und Programme oft im gleichen linear adressierbaren Speicherbereich. Schnelle Kommunikation und wenig Overhead. Weniger Sicherheit und Stabilität. Message Passing: Langsamer als Shared Memory Echtzeitbetriebssystem sorgt für korrekte Verwaltung Christoffer Menk Einführung in Echtzeitbetriebssysteme 15 / 30 63

72 Christoffer Menk Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Speicherverwaltung Folgende Verfahren zur Speicherverwaltung werden benutzt: Fixed Partitioning Dynamic Partitioning Simple Paging Virtual Memory Paging Simple Segmentation Virtual Memory Segmentation Nicht alle Verfahren beheben das Problem der External Memory Fragmentation Christoffer Menk Einführung in Echtzeitbetriebssysteme 16 / 30 Seminarvortrag Elemente eines Echtzeitbetriebssystems Speicherverwaltung Speicherverwaltung Folgende Verfahren zur Speicherverwaltung werden benutzt: Fixed Partitioning Dynamic Partitioning Simple Paging Virtual Memory Paging Simple Segmentation Virtual Memory Segmentation Nicht alle Verfahren beheben das Problem der External Memory Fragmentation Dynamic Partitioning: Partitionen werden dynamisch erzeugt, so dass sie genau der Größe des Prozesses entsprechen. Simple Paging: Der Speicher und die Prozesse werden in gleich große Partitionen unterteilt. Bei Benutzung werden dann alle Teile des Prozesses in den Speicher geladen. Simple Segmentation: Jeder Prozess wird in Segmente unterteilt, die dann dynamisch in den Speicher geladen werden. Virtual bedeutet, dass immer nur die gerade benötigten Teile eines Prozesses geladen werden. Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Speicherverwaltung: Fixed Partitioning Speicher wird in feste Partitionen zerlegt Vorteile: Leichte Implementierung wenig Aufwand Nachteile: Anzahl der Prozesse begrenzt Speicher nicht optimal genutzt Christoffer Menk Einführung in Echtzeitbetriebssysteme 17 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Timer Korrekte Funktionsweise des Echtzeitsystems abhängig von der Zeit Echtzeitbetriebssysteme bieten diverse Sprachmittel für die Zeit Zeitgeber in eine Anwendung einbinden. Ablauf zeitlich steuern. Anwendungen zu bestimmten Zeitpunkt starten Christoffer Menk Einführung in Echtzeitbetriebssysteme 18 / 30 64

73 Einführung in Echtzeitbetriebssysteme Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Interrupt Sicherstellung der Reaktionszeiten Asynchrone Interrupts Maschinenfehler I/O-Operationen Synchrone Interrupts Exceptions Softwareinterrupts Behandlung des Interrupts durch Interrupt Service Routine (ISR). Lamie, W. E.: Pardon the Interruption: Two Approaches to RTOS Interrupt Architectures. I.Q. Magazine, 03(04), Christoffer Menk Einführung in Echtzeitbetriebssysteme 19 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Interrupt: Unified Interrupt Architecture Sequentielle Abarbeitung von Interrupts Während der ISR keine weiteren Interrupts oder kritischen Systemaufrufe Vorteil: Einfache Verarbeitung Nachteil: Reaktionszeit Christoffer Menk Einführung in Echtzeitbetriebssysteme 20 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Interrupt: Segmented Interrupt Architecture Keine Zugriffe auf kritische Daten oder Systemaufrufe von ISR 1 ISR 2 wird durch Scheduler verwaltet. Vorteil: Kurze Reaktionszeiten. Nachteil: Mehr Prozesswechsel Christoffer Menk Einführung in Echtzeitbetriebssysteme 21 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Übersicht 1 Unterschiede zu herkömmlichen Betriebssystemen 2 Aufbau eines Echtzeitbetriebssystems 3 Elemente eines Echtzeitbetriebssystems 4 Beispiele von bekannten Echtzeitbetriebssystemen 5 Schlussfolgerungen Christoffer Menk Einführung in Echtzeitbetriebssysteme 22 / 30 65

74 Christoffer Menk Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Einteilung von Echtzeitbetriebssystemen Kommerzielle Echtzeitbetriebssystem(kern)e: Kerne unterstützen elementare Funktionen Kerne optimiert für schnelle Interruptverwaltung und Prozesswechsel Echtzeitbetriebssysteme weitere Funktionen Beispiele: VxWorks, QNX Systeme aus der Forschung: Beispiel: RTOS-UH von der Universität Hannover Herkömmliche Betriebssysteme mit Echtzeiterweiterung: Herkömmliches Betriebssystem als Grundlage Eigentliches Betriebssystem als Prozess mit niedriger Priorität Beispiele: INTime, RT-Linux Christoffer Menk Einführung in Echtzeitbetriebssysteme 23 / 30 Seminarvortrag Beispiele von bekannten Echtzeitbetriebssystemen Einteilung von Echtzeitbetriebssystemen Einteilung von Echtzeitbetriebssystemen Kommerzielle Echtzeitbetriebssystem(kern)e: Kerne unterstützen elementare Funktionen Kerne optimiert für schnelle Interruptverwaltung und Prozesswechsel Echtzeitbetriebssysteme weitere Funktionen Beispiele: VxWorks, QNX Systeme aus der Forschung: Beispiel: RTOS-UH von der Universität Hannover Herkömmliche Betriebssysteme mit Echtzeiterweiterung: Herkömmliches Betriebssystem als Grundlage Eigentliches Betriebssystem als Prozess mit niedriger Priorität Beispiele: INTime, RT-Linux Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Marktübersicht Timmerman, M.: RTOS Market Overview A follow up. Real-Time Magazine, Christoffer Menk Einführung in Echtzeitbetriebssysteme 24 / 30 Seminarvortrag Beispiele von bekannten Echtzeitbetriebssystemen Marktübersicht Marktübersicht Timmerman, M.: RTOS Market Overview A follow up. Real-Time Magazine, Die Marktübersicht wurde vom Real-Time Magazine bei einer Leser-Umfrage erstellt. Daher ist diese nicht zwangsweise repräsentativ, jedoch zeigt sie, wie viele verschiedene Echtzeitbetriebssysteme benutzt werden. 66

75 Einführung in Echtzeitbetriebssysteme Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Kriterien zur Auswahl eines Echtzeitbetriebssystems Antwortzeiten und Features des Echtzeitsystems Größe des Echtzeitsystems Erfahrung und Entwicklungszeit des Herstellers Kosten Schulung der Mitarbeiter Hardware des Echtzeitsystems Barr, M.: Choosing an RTOS. Embedded Systems Programming, Januar Christoffer Menk Einführung in Echtzeitbetriebssysteme 25 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Kriterien zur Auswahl eines Echtzeitbetriebssystems Vorteile eines kommerziellen Echtzeitbetriebssystems: Verbesserung der Portabilität Vereinfachte Programmierung auf komplexer Hardware Mögliche Einsparung von Kosten durch kürzere Entwicklungszeiten Erhöhte Zuverlässigkeit Nachteile eines kommerziellen Echtzeitbetriebssystems: Kosten für die Lizenzierung des Echtzeitbetriebssystems Abhängigkeit vom Hersteller Quellcode nicht immer einsehbar Einarbeitungs- und Trainingsaufwand Christoffer Menk Einführung in Echtzeitbetriebssysteme 26 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Übersicht 1 Unterschiede zu herkömmlichen Betriebssystemen 2 Aufbau eines Echtzeitbetriebssystems 3 Elemente eines Echtzeitbetriebssystems 4 Beispiele von bekannten Echtzeitbetriebssystemen 5 Schlussfolgerungen Christoffer Menk Einführung in Echtzeitbetriebssysteme 27 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Schlussfolgerungen Unterschied zu herkömmlichen Betriebssystem: zeitlicher Determinismus Kommerzielle Echtzeitbetriebssysteme benutzen Mikro-Kernel Architektur Für kleinere Echtzeitsysteme sind kommerzielle Echtzeitbetriebssysteme zu umfangreich (einfachere Kernels) Echtzeitbetriebssystem sollte nur die benötigten Funktionen enthalten Keine optimale Lösung für alle Echtzeitsysteme Echtzeitbetriebssystem stellt nur nötige Mittel für Betrieb in Echtzeit zur Verfügung Christoffer Menk Einführung in Echtzeitbetriebssysteme 28 / 30 67

76 Christoffer Menk Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Literatur Burns, A. und A. Wellings: Real-Time Systems and Programming Languages. Pearson Education Limited, Kopetz, H.: Real-time systems: design principles for distributed embedded applications. Kluwer, Laplante, P. A.: Real-time systems design and analysis: an engineer s handbook. IEEE Press, Stalling, W.: Betriebssysteme Prinzipien und Umsetzung. Prentice Hall, Witzak, M. P.: Echtzeitbetriebssysteme. Francis, Christoffer Menk Einführung in Echtzeitbetriebssysteme 29 / 30 Unterschiede Aufbau Elemente Beispiele Schlussfolgerungen Ende Vielen Dank für Ihre Aufmerksamkeit! Fragen? Christoffer Menk Einführung in Echtzeitbetriebssysteme 30 / 30 68

77 VxWorks Aufbau und Programmierung Motivation Vorstellung VxWorks Programmierung Zusammenfassung VxWorks - Aufbau und Programmierung Dominik Meyer <dmey@informatik.uni-kiel.de> Seminar Echtzeit-Betriebssysteme und -Bussysteme Gliederung Motivation Vorstellung VxWorks Programmierung Zusammenfassung SEBBS 2006/07 1 / 24 1 Motivation 2 Vorstellung VxWorks Einführung Kerneldienste weitere Dienste Besonderheiten 3 Programmierung SEBBS 2006/07 2 / 24 Motivation Vorstellung VxWorks Programmierung Zusammenfassung Motivation Welches Echtzeitbetriebssystem ist das richtige? Auswahl an Echtzeitbetriebssystemen OS/9 psos QNX RTLinux VxWorks... SEBBS 2006/07 3 / 24 Motivation Motivation Motivation Welches Echtzeitbetriebssystem ist das richtige? Auswahl an Echtzeitbetriebssystemen OS/9 psos QNX RTLinux VxWorks In [1] findet man noch mehr Echtzeitbetriebssysteme außerdem eine kleine Übersicht über ihre Feature 69

78 Dominik Meyer Motivation Vorstellung VxWorks Programmierung Zusammenfassung Motivation Welches Echtzeitbetriebssystem ist das richtige? Wie trifft man die richtige Entscheidung? Informationen Erfahrungsberichte Ausprobieren Motivation Motivation SEBBS 2006/07 4 / 24 Motivation Welches Echtzeitbetriebssystem ist das richtige? Wie trifft man die richtige Entscheidung? Informationen Erfahrungsberichte Ausprobieren Motivation Vorstellung VxWorks Programmierung Zusammenfassung Einführung in VxWorks Einführung Kerneldienste weitere Dienste Besonderheiten Was ist VxWorks Toolkit zum Erzeugen eines Echtzeitbetriebssytems Hersteller Wind River Toolkit besteht aus: Echtzeitbetriebssystemkern zusätzlichen Modulen Entwicklungsumgebung SEBBS 2006/07 6 / 24 Vorstellung VxWorks Einführung Einführung in VxWorks Einführung in VxWorks Was ist VxWorks Toolkit zum Erzeugen eines Echtzeitbetriebssytems Hersteller Wind River Toolkit besteht aus: Echtzeitbetriebssystemkern zusätzlichen Modulen Entwicklungsumgebung VxWorks nahm seinen Anfang in einer Garage erst später wurde Wind River gegründet Module gibt es von Wind River aber auch von Drittanbietern Entwicklungsumgebung wird Tornado genannt 70

79 VxWorks Aufbau und Programmierung Aufbau von VxWorks Motivation Vorstellung VxWorks Programmierung Zusammenfassung Vorstellung VxWorks Einführung Aufbau von VxWorks Einführung Kerneldienste weitere Dienste Besonderheiten Microkernel bestehend aus: Scheduler Semaphoren SEBBS 2006/07 7 / 24 Aufbau von VxWorks Microkernel bestehend aus: Scheduler Semaphoren Aufbau von VxWorks Motivation Vorstellung VxWorks Programmierung Zusammenfassung Motivation Vorstellung VxWorks Programmierung Zusammenfassung Scheduler von VxWorks Definition Task organisatorische Einheit ausführbarer Code eigener Speicher Variablen besitzt Priorität und Zustand Einführung Kerneldienste weitere Dienste Besonderheiten Schichten um den Kern bestehend aus: Speicher-Management Interrupt Verwaltung Timer Inter-Task-Kommunikation Treiberschicht Anwendungsschicht Einführung Kerneldienste weitere Dienste Besonderheiten SEBBS 2006/07 8 / 24 Task in VxWorks ähnlich Threads flat memory model gemeinsamer Speicher Task-Stack im gemeinsamen Speicher SEBBS 2006/07 10 /

80 Dominik Meyer Motivation Vorstellung VxWorks Programmierung Zusammenfassung Scheduler von VxWorks Einführung Kerneldienste weitere Dienste Besonderheiten Definition Scheduler weißt Tasks Rechenzeit und Ressourcen zu sorgt für das Einhalten von Echtzeiteigenschaften Scheduling-Algorithmen Priority Preemptive Scheduling Round Robin Mischformen Semaphore Motivation Vorstellung VxWorks Programmierung Zusammenfassung Einführung Kerneldienste weitere Dienste Besonderheiten SEBBS 2006/07 11 / 24 Semaphore-Typen Binäre Semaphore Counting Semaphore Mutual-Exclusion Semaphore SEBBS 2006/07 12 / 24 Speicherverwaltung Motivation Vorstellung VxWorks Programmierung Zusammenfassung Einführung Kerneldienste weitere Dienste Besonderheiten Speicherverwaltung flat memory model Basic Virtual Memory Interface VxVMI (erweitertes Virtual Memory Interface) privater Speicherplatz Speicher schreib- und leseschützen Speicher vom Auslagern ausnehmen Motivation Vorstellung VxWorks Programmierung Zusammenfassung Intertaskkommunikation Einführung Kerneldienste weitere Dienste Besonderheiten Möglichkeiten gemeinsamer Speicher Signals Message Queues Pipes SEBBS 2006/07 14 / 24 SEBBS 2006/07 15 / 24 72

81 VxWorks Aufbau und Programmierung Motivation Vorstellung VxWorks Programmierung Zusammenfassung weitere Besonderheiten Einführung Kerneldienste weitere Dienste Besonderheiten I/O System UNIX kompatibel unterstützt alle Ein- und Ausgabegeräte Beispiel: Aktuatoren, Sensoren, Bildschirm und Tastatur auch virtuelle Geräte (z.b. Pipes) Dateisysteme ähnlich wie UNIX oder Linux unterstützte Formate: dosfs, rawfs tapefs, cdromfs TSFs POSIX Motivation Vorstellung VxWorks Programmierung Zusammenfassung Einführung Kerneldienste weitere Dienste Besonderheiten SEBBS 2006/07 17 / 24 POSIX kompatibel zu Standard b (für Echtzeitbetriebssysteme) stehen als zusätzlich Funktionen zur Verfügung POSIX Erweiterungen 1 Clocks und Timer Memory locking Threads Scheduling Interface SEBBS 2006/07 18 / 24 POSIX Motivation Vorstellung VxWorks Programmierung Zusammenfassung Einführung Kerneldienste weitere Dienste Besonderheiten POSIX Erweiterungen 2 Semaphore Mutexes und Condition Variables Queued Signals Motivation Vorstellung VxWorks Programmierung Zusammenfassung gegenseitiger-ausschluss SEBBS 2006/07 19 / 24 Interrupt-Deaktivierung sehr mächtig, da Task durch nichts unterbrochen werden kann dadurch aber auch sehr gefährlich (Deadlock) Verwendung wenn Gegenseitiger-Ausschluß auch gegenüber von Interrupts benötigt wird dürfen keine Systemfunktionen verwendet werden, da diese die Interrupts wieder aktivieren SEBBS 2006/07 20 / 24 73

82 Dominik Meyer Motivation Vorstellung VxWorks Programmierung Zusammenfassung Gegenseitiger-Ausschluß Preemption Deaktivierung dadurch keine Kontextwechsel mehr Task kann nur durch Hardware-Interrupts unterbrochen werden es kann zu nicht-deterministischem Verhalten kommen, da die anderen Task in ihrer Responsivität eingeschränkt werden Motivation Vorstellung VxWorks Programmierung Zusammenfassung Gegenseitiger-Ausschluß SEBBS 2006/07 21 / 24 Mutual-Exclusion Semaphore im normal Fall die beste Möglichkeit nur der Prozess der die Semaphore hält, kann sie wieder freigeben dadurch wird unbeabsichtigtes Freigeben wegen Programmierfehlern verhindert ändert kaum etwas an der Responsivität des Systems, da Prozesse mit höherer Priorität preempten können, wenn sie nicht auf die gleiche Semaphore warten SEBBS 2006/07 22 / 24 Motivation Vorstellung VxWorks Programmierung Zusammenfassung Zusammenfassung VxWorks ist ein sehr mächtiges und umfangreiches Echtzeitbetriebssystem Es stellt aber auch höhere Hardwareanforderungen Nimmt dem Programmierer viel Arbeit ab Ausblick es fehlen Informationen, wie VxWorks Echtzeiteigenschaften sicherstellt auch Informationen über den genauen Aufbau des Betriebssystems fehlen SEBBS 2006/07 23 / 24 Anhang Weiterführende Literatur Weiterführende Literatur I WITZAK, M. P.: Echtzeit Betriebsysteme - Eine Einführung in Architektur und Programmierung. Franzis, VxWorks Programmers Guide. Wind River. flight/sw/vxdocs/vxworks/guide/. SEBBS 2006/07 24 / 24 74

83 Echtzeitbussysteme im Überblick Übersicht Einführung Klassifizierung von Bussystemen Ausgewählte Bussysteme Fazit Echtzeitbussysteme im Überblick Vortrag zum Seminar Echtzeit-Betriebssysteme und -Bussysteme Lars Wienbrandt Christian-Albrechts-Universität zu Kiel Echtzeitbussysteme / 29 Übersicht Einführung Klassifizierung von Bussystemen Ausgewählte Bussysteme Fazit Übersicht 1 Einführung 2 Klassifizierung von Bussystemen 3 Ausgewählte Bussysteme CAN LIN Realtime Ethernet TTP byteflight FlexRay SAFEbus 4 Fazit Echtzeitbussysteme / 29 Übersicht Einführung Klassifizierung von Bussystemen Ausgewählte Bussysteme Fazit Übersicht 1 Einführung 2 Klassifizierung von Bussystemen 3 Ausgewählte Bussysteme CAN LIN Realtime Ethernet TTP byteflight FlexRay SAFEbus 4 Fazit Echtzeitbussysteme / 29 Echtzeitbussysteme Einführung Übersicht Übersicht 1 Einführung 2 Klassifizierung von Bussystemen 3 Ausgewählte Bussysteme CAN LIN Realtime Ethernet TTP byteflight FlexRay SAFEbus Fazit 75

84 Lars Wienbrandt Übersicht Einführung Klassifizierung von Bussystemen Ausgewählte Bussysteme Fazit Motivation Situation: (Beispiel: Automobilindustrie) Kommunikation zwischen Anwendungsknoten notwendig Anzahl verteilter Systeme stetig ansteigend Zunahme von Komplexität und Sicherheitsrelevanz Motivation eines Bussystems: Einsparung von Verkabelung Kostenreduzierung Gewichtsreduzierung Einfachere Kontrolle und Wartung Echtzeitbussysteme / 29 Echtzeitbussysteme Einführung Motivation Motivation Situation: (Beispiel: Automobilindustrie) Kommunikation zwischen Anwendungsknoten notwendig Anzahl verteilter Systeme stetig ansteigend Zunahme von Komplexität und Sicherheitsrelevanz Motivation eines Bussystems: Einsparung von Verkabelung Kostenreduzierung Gewichtsreduzierung Einfachere Kontrolle und Wartung Beispiel: Automobilindustrie Tendenz von Mechanik zu Elektronik (elektr. Fensterheber) neue Sicherheitstechniken (ABS, ESP, Airbag) gehobener Standard (Klimaanlage, Funk-Schließsystem) Motivation eines Bussystems: Kosten- und Gewichtsreduzierung: um die 1000 Meter Kabel pro Serienfahrzeug gegenüber direkter Verkabelung Kontrolle und Wartung: Diagnosesysteme Übersicht Einführung Klassifizierung von Bussystemen Ausgewählte Bussysteme Fazit Vernetzungsumfang deutscher PKW Echtzeitbussysteme / 29 Echtzeitbussysteme Einführung Vernetzungsumfang deutscher PKW Vernetzungsumfang deutscher PKW bis zu 70 ECUs pro Fahrzeug in

85 Echtzeitbussysteme im Überblick Übersicht Einführung Klassifizierung von Bussystemen Ausgewählte Bussysteme Fazit Anwendungsbeispiele Anwendungen am Beispiel Automobil: sicherheitsunkritische Aufgaben, z.b. elektr. Fensterheber, Klimaanlage,... sicherheitsrelevante Aufgaben, z.b. Airbag, ABS, ESP,... x-by-wire-systeme Koordination der Karosserieelektronik Diagnosesysteme Multimedia Echtzeitbussysteme / 29 Echtzeitbussysteme Einführung Anwendungsbeispiele Anwendungsbeispiele Anwendungen am Beispiel Automobil: sicherheitsunkritische Aufgaben, z.b. elektr. Fensterheber, Klimaanlage,... sicherheitsrelevante Aufgaben, z.b. Airbag, ABS, ESP,... x-by-wire-systeme Koordination der Karosserieelektronik Diagnosesysteme Multimedia x-by-wire: Steuerung ohne Mechanik unterschiedliche Bussysteme für unterschiedliche Aufgaben Übersicht Einführung Klassifizierung von Bussystemen Ausgewählte Bussysteme Fazit Anforderungen Anforderungen an heutige Bussysteme: Zuverlässigkeit Fehlertoleranz Ausfallsicherheit Datenkonsistenz Geschwindigkeit Je nach Aufgabenbereich unterschiedliche Relevanz. Echtzeitbussysteme / 29 Echtzeitbussysteme Einführung Anforderungen Anforderungen Anforderungen an heutige Bussysteme: Zuverlässigkeit Fehlertoleranz Ausfallsicherheit Datenkonsistenz Geschwindigkeit Je nach Aufgabenbereich unterschiedliche Relevanz unterschiedlicher Erfüllungsgrad der Anforderungen impliziert unterschiedliche Kosten: ausfallsichere und fehlertolerante Systeme sind i.d.r. teurer 77

86 Lars Wienbrandt Übersicht Einführung Klassifizierung von Bussystemen Ausgewählte Bussysteme Fazit Übersicht 1 Einführung 2 Klassifizierung von Bussystemen 3 Ausgewählte Bussysteme CAN LIN Realtime Ethernet TTP byteflight FlexRay SAFEbus 4 Fazit Echtzeitbussysteme / 29 Echtzeitbussysteme Klassifizierung von Bussystemen Übersicht Übersicht 1 Einführung 2 Klassifizierung von Bussystemen 3 Ausgewählte Bussysteme CAN LIN Realtime Ethernet TTP byteflight FlexRay SAFEbus Fazit Übersicht Einführung Klassifizierung von Bussystemen Ausgewählte Bussysteme Fazit Klassifizierung Kriterien: Geschwindigkeit Sicherheitsrelevanz Aufgabenbereich Kosten Klassifizierung der Society of Automotive Engineering (SAE), Jahr 2002: Einteilung für Bussysteme im Automobil in anfangs drei Klassen Einteilung nach Bandbreite und Aufgabenbereich fließende Grenzen Echtzeitbussysteme / 29 Echtzeitbussysteme Klassifizierung von Bussystemen Klassifizierung Klassifizierung Kriterien: Geschwindigkeit Sicherheitsrelevanz Aufgabenbereich Kosten Klassifizierung der Society of Automotive Engineering (SAE), Jahr 2002: Einteilung für Bussysteme im Automobil in anfangs drei Klassen Einteilung nach Bandbreite und Aufgabenbereich fließende Grenzen Klassifizierung der SAE für echtzeitfähige Bussysteme im Automobil erweitert um vierte Klasse, s. nächste Folie 78

87 Echtzeitbussysteme im Überblick Übersicht Einführung Klassifizierung von Bussystemen Ausgewählte Bussysteme Fazit Klassifikation nach Übertragungsrate/Kosten Echtzeitbussysteme / 29 Echtzeitbussysteme Klassifizierung von Bussystemen Klassifikation nach Übertragungsrate/Kosten Klassifikation nach Übertragungsrate/Kosten schwierig andere Bussysteme, wie beispielsweise Ethernet zu klassifizieren: Datenrate ausreichend für Klasse D nicht echtzeitfähig höchstens Klasse A Einordnung in Multimedia -Bussysteme Übersicht Übersicht Einführung Klassifizierung von Bussystemen Ausgewählte Bussysteme Fazit CAN LIN Realtime Ethernet TTP byteflight FlexRay SAFEbus 1 Einführung 2 Klassifizierung von Bussystemen 3 Ausgewählte Bussysteme CAN LIN Realtime Ethernet TTP byteflight FlexRay SAFEbus 4 Fazit Echtzeitbussysteme / 29 Echtzeitbussysteme Ausgewählte Bussysteme Übersicht Übersicht 1 Einführung 2 Klassifizierung von Bussystemen 3 Ausgewählte Bussysteme CAN LIN Realtime Ethernet TTP byteflight FlexRay SAFEbus Fazit 79

88 Lars Wienbrandt Übersicht Einführung Klassifizierung von Bussystemen Ausgewählte Bussysteme Fazit CAN (Controller Area Network) CAN LIN Realtime Ethernet TTP byteflight FlexRay SAFEbus Entwicklung: 1983: BOSCH: zur Vernetzung elektrischer Systeme im Automobil 1992: Gründung der CAN in Automation (CiA) Einsatz: Automatisierungs- und Kontrollanwendungen vielseitig im Automobil Klassifizierung: Klasse B,C Bandbreite: max. 1MB/s Kommunikation: ereignisgesteuert, Busarbitrierung nach Priorität Nachteil: hochpriorer Sender kann Bus blockieren ( Fluten ) Abhilfe: Variante TTCAN: zeit- und ereignisgesteuert (Zeitfenster für jeden Knoten) Echtzeitbussysteme / 29 Echtzeitbussysteme Ausgewählte Bussysteme CAN CAN (Controller Area Network) CAN (Controller Area Network) Entwicklung: 1983: BOSCH: zur Vernetzung elektrischer Systeme im Automobil 1992: Gründung der CAN in Automation (CiA) Einsatz: Automatisierungs- und Kontrollanwendungen vielseitig im Automobil Klassifizierung: Klasse B,C Bandbreite: max. 1MB/s Kommunikation: ereignisgesteuert, Busarbitrierung nach Priorität Nachteil: hochpriorer Sender kann Bus blockieren ( Fluten ) Abhilfe: Variante TTCAN: zeit- und ereignisgesteuert (Zeitfenster für jeden Knoten) CAN: CiA: Gruppierung internationaler Nutzer und Hersteller zur Weiterentwicklung des CAN-Protokolls max. Bandbreite bei low-speed-can: 125kbit/s Buszugriff: CSMA/CD Ausblick: CAN bewährt, hohe Herstellervielfalt, relativ günstig, fast in jedem europ. PKW vorhanden höhere Sicherheitsanforderungen erfordern neue Bussysteme (TTP, FlexRay) weniger anspruchsvolle Aufgaben billiger lösbar (LIN) Übersicht Einführung Klassifizierung von Bussystemen Ausgewählte Bussysteme Fazit LIN (Local Interconnect Network) CAN LIN Realtime Ethernet TTP byteflight FlexRay SAFEbus Entwicklung: LIN-Konsortium 1998: Ziel: Audi, BMW, Daimler-Chrysler, Volvo, Volkswagen, VCT, Motorola u.a. assoziierte Mitglieder einfach zu bedienen, offener Standard, billiger als CAN Einsatz: Sub-Bus für Karosserieelektronik im Automobil: Lichtanlage Scheibenwischer elektr. Fensterheber usw. Echtzeitbussysteme / 29 Echtzeitbussysteme Ausgewählte Bussysteme LIN LIN (Local Interconnect Network) LIN (Local Interconnect Network) Entwicklung: LIN-Konsortium 1998: Audi, BMW, Daimler-Chrysler, Volvo, Volkswagen, VCT, Motorola u.a. assoziierte Mitglieder Ziel: einfach zu bedienen, offener Standard, billiger als CAN Einsatz: Sub-Bus für Karosserieelektronik im Automobil: Lichtanlage Scheibenwischer elektr. Fensterheber usw Ziel: Einsatz wo Leistung, Bandbreite und Vielseitigkeit von CAN nicht benötigt wird. 80