Das optimale Betriebssystem für FlexRay

Das optimale Betriebssystem für FlexRay

Bei einer verteilten Regelung wird eine Funktion über mehrere Steuergeräte im Netzwerkverbund verteilt. Die Totzeit, verursacht durch die Signallaufzeit von Senderapplikation zu Empfängerapplikation, kann dabei einen entscheidenden Einfluss auf die Regelgüte haben. Grundsätzlich wirkt sich eine geringe Totzeit günstig aus.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

---

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Bei ereignisgesteuerten Kommunikationssystemen wird der Datenaustausch zwischen CC und Host grundsätzlich per Interrupt gesteuert; beim Zugriff auf den Bus entstehen gegebenenfalls Wartezeiten. Die Signallaufzeit lässt sich nicht genau vorhersagen, es wird daher typischerweise eine Worst-Case-Abschätzung durchgeführt. Erst durch die Bereitstellung einer globalen Zeit des FlexRay-Protokolls wird es dem Betriebssystem ermöglicht, Dienste zur Synchronisation auf diese Zeit anzubieten. Durch das TDMA-VerfahrenTime Division Multiple Access) ist allen beteiligten Steuergeräten der genaue Sende- bzw. Empfangszeitpunkt jeder Botschaft im statischen Bereich des FlexRay-Zyklus bekannt. Diese beiden Eigenschaften minimieren die Unschärfe bezüglich der Signallaufzeit einer FlexRay-basierten Anwendung.

Für die Synchronisierung des Datenaustauschs bei einer FlexRay-basierten Anwendung lassen sich je nach Bedarf und verfügbaren Betriebssystem-Eigen-schaften mehrere Lösungsansätze realisieren. Die Kommuni-kations-Tasks sollten grundsächlich mit dem FlexRay-Timer des CC getriggert werden. Die Aktivierung der Applikations-Tasks könnte hingegen durch einen beliebigen Timer erfolgen. Hieraus ergeben sich vier mögliche Lösungsansätze:

• Alarme, die am OS-System-Timer hängen, triggern die Applikations-Tasks. Am Anfang jedes Grundzyklus wird der „FlexRay-Cycle Start Interrupt“ durch den FlexRay-Controller ausgelöst. Die Kommunikations-Task wird sofort aktiviert. Die Kette von Applikations-Tasks wird unabhängig davon vom Betriebssystem-Timer angestoßen. Bild 4 stellt vereinfacht mit nur einer Applikations- und einer Kommunikations-Task diesen Lösungsansatz dar. Zu beachten ist, dass eine spätere Auslösung eines Cycle Start Interrupts, zum Beispiel durch eine Drift zwischen CC- und Host-Quarz verursacht, eine verspätete Abarbeitung der übertragenen FlexRay-Daten (z.B. aus Frame 2) von Δt_OS = 1 ms als Konsequenz hat. Erwartet die Applikation keine längere Reaktionszeit, ist dafür ein OSEK-OS ausreichend.
• Erfordert die Regelung eine kürzere Antwortzeit (weniger als 1 ms), dann ist für die Auslösung der Applikations-Tasks ein High Resolution Timer (Auflösung ca. 10 µs) beim OSEK-OS notwendig. Dafür wird allerdings ein geeigneter Timer benötigt.
• Falls das Steuergerät nicht über einen High Resolution Timer verfügt, kann der FlexRay-Timer zusätzlich für die Aktivierung der zeitkritischen Applikations-Tasks benutzt werden(Bild 5). FlexRay-unabhängige Tasks können weiterhin an den OS-System-Timer gehängt werden. Beim Aufstartverhalten ist zu beachten, dass der FlexRay-Timer und damit die durch ihn aktivierten Tasks erst zur Verfügung stehen, nachdem der FlexRay-Controller sich erstmalig auf das Netzwerk synchronisiert hat. Sollte anschließend die Synchronisierung verloren gehen, kann der FlexRay-Timer auf Basis seiner lokalen Zeit weiterhin arbeiten, falls der FlexRay-Controller entsprechend konfiguriert wurde. Ein AUTOSAR-OS der Scalability Class 1 mit Schedule Tables ist dazu ausreichend. Diese Lösung erlaubt eine über mehrere Steuergeräte verteilte Regelung, da die FlexRay-Globalzeit die Synchronisierung über alle Steuergeräte sicherstellt.
• Falls in obigen Fällen zusätzlich die Einhaltung der Task- und Interrupt-Laufzeiten überwacht werden soll, ist ein AUTOSAR-OS der Scalability Class 2 oder 4 erforderlich. Damit werden Laufzeitüberschreitungen verhindert; ein zeitlich deterministisches Verhalten wird erreicht.

Eine FlexRay-basierte Anwendung erfordert nicht zwingend ein zeitgesteuertes Betriebssystem. Die Festlegung des geeigneten Betriebssystems sollte unter Berücksichtigung der Anwendung und Architektur individuell für jedes Steuergerät erfolgen. Dazu ist eine Analyse in Bezug auf Steuergeräte-übergreifende Synchronität, Sicherheitsanforderungen, Antwortzeit und Zeitüberwachung notwendig. Für alle FlexRay-Anwendungen bietet Vector Informatik dem Entwickler ein entsprechendes Betriebssystem: das nach dem OSEK/VDX-Standard zertifizierte osCAN mit oder ohne High Resolution Timer oder osCAN AUTOSAR, das die Scalability Classes SC1-SC4 gemäß AUTOSAR-OS V2.0 abdeckt. Die Vector-FlexRay-Softwarekomponenten arbeiten mit jeder dieser OS-Varianten zusammen. Der osCAN TimingAnalyzer analysiert hierbei die Einplanbarkeit von Tasks mit einer Worst-Case-Betrachtung.

Für die durchgängige Entwicklung von FlexRay-Systemen bis zum Serieneinsatz unterstützt Vector den Anwender mit Softwarekomponenten und individueller Dienstleistung. Ausgereifte und aufeinander abgestimmte Tools wie der DaVinci Network Designer für alle FlexRay-typischen Entwurfsaufgaben oder CANoe.FlexRay 5.2 für Simulation und Stimulation eines Netzwerkes, Integrationstests und Restbussimulation sowie Analyse des fertigen FlexRay-Netzwerks erleichtern die Entwicklung. Der Zugriff auf alle internen Parameter des FlexRay-Steuergerätes über das standardisierte Mess- und Kalibrierprotokoll „XCP on FlexRay“ erfolgt mit CANape 6.0. Für die erste, schnelle und flexible Implementierung eines FlexRay-Netzwerks sorgt das FlexRay Evaluation Bundle. Diese integrierte Umgebung aus Softwarekomponenten und Werkzeugen beinhaltet auch eine Beispielanwendung für ein FlexRay-System mit zwei Knoten

	Dipl.-Ing. Pascale Morizur studierte Physik-Elektronik an der Grande Ecole ICPI in Lyon (F). Nach ihrem Abschluss 1986 arbeitete sie zehn Jahre bei MAN-Nutzfahrzeuge in der Vorentwicklung im Bereich CAN, J1939 und Diagnose. Sie ist bei Vector als Product Management Engineer im Bereich FlexRay-Embedded-Softwarekomponenten tätig. pascale.morizur@vector-informatik.de
	Dipl.-Ing. Winfried Janz studierte an der Universität Stuttgart Elektrotechnik. Nach vier Jahren in der Software-Entwicklung für Embedded Controller in der Regelungs- und Automatisierungstechnik kam er 1995 zu Vector. Hier ist er seit 1997 als Teamleiter und Produktmanager für die Entwicklung von OSEK-Echtzeit-Betriebssystemen zuständig. Er hat in den Arbeitskreisen OSEK und AUTOSAR die Spezifikationen Betriebssystem und Konfiguration mitgestaltet. winfried.janz@vector-informatik.de
	Dipl.-Ing. Dirk Grossmann studierte Elektrotechnik an der Universität Stuttgart. Nach seinem Abschluss 1997 arbeitete er zunächst in der Betriebssystem-Entwicklung der ETAS GmbH, bevor er für zwei Jahre als Produktmanager Nordamerika den Bereich Betriebssystem verantwortete. Seit 2003 ist er bei Vector als Teamleiter für die Entwicklung der FlexRay-Embedded-Softwarekomponenten verantwortlich. dirk.grossmann@vector-informatik.de

1. Das optimale Betriebssystem für FlexRay
2. Synchronisierung über Globalzeit
3. Das optimale Betriebssystem für FlexRay