Infotainment Statische Konfiguration von MOST-Netzwerken

Autor / Redakteur: Renato Machelett * / Dipl.-Ing. (FH) Thomas Kuther

Das Konzept der Konfiguration in der Entwurfsphase eines MOST-Netzwerks reduziert Komplexität und Kosten und verringert den Prüf- und Verifikationsaufwand.

Firmen zum Thema

Einfach aber wirkungsvoll: Das Konzept der Konfiguration in der Entwurfsphase eines MOST-Netzwerks reduziert Komplexität und Kosten und verringert den Prüf- und Verifikationsaufwand.
Einfach aber wirkungsvoll: Das Konzept der Konfiguration in der Entwurfsphase eines MOST-Netzwerks reduziert Komplexität und Kosten und verringert den Prüf- und Verifikationsaufwand.
(Bild: ©djmilic/Fotolia.com)

MOST ist sehr flexibel, doch nicht jeder Autohersteller benötigt die gesamte verfügbare Flexibilität für alle Fahrzeugmodelle. Das Konzept der Konfiguration in der Entwurfsphase (Design Time Configuration) reduziert nicht nur die Komplexität und die Kosten, sondern es verringert auch den Prüf- und Verifikationsaufwand und bietet dadurch einen einfachen Zugang zu der von MOST gebotenen Funktionalität.

Bildergalerie

Automotive-Anwendungen decken das gesamte Spektrum von einfachen bis zu hochkomplexen Lösungen ab. MOST bietet weitreichende Flexibilität beim Systemdesign, bei der Konfiguration und bei Änderungen während der Laufzeit. So kommt MOST bestens mit hochkomplexen Szenarien zurecht. Einfache Anwendungsfälle benötigen jedoch nicht die gesamte gebotene Flexibilität. Dies ist beispielsweise dann der Fall, wenn ein System vorab konfiguriert wird und sich niemals ändert, wenn reduzierte Hardware- oder Performance-Anforderungen angestrebt werden oder wenn sehr spezifische Lösungen umgesetzt werden.

Ein Beispiel hierfür ist eine Head-Unit mit Kameras für Rundumsicht, die an MOST-Knoten ohne Steuergerät (remote controlled nodes) angeschlossen werden. In diesem Anwendungsfall vereinfacht die statische statt der dynamischen Adressierung das Systemdesign erheblich. Das folgende Konzept konzentriert sich auf die einfachen Szenarien und erlaubt die Implementation von MOST-Systemen mit kleinerem Footprint.

Beim Festlegen potenzieller Vereinfachungen auf Basis der MOST-Spezifikation Rev. 3.1 [1] sind drei Bereiche zu beachten: das Hoch- und Herunterfahren des Netzwerks, das Netzwerkmanagement und das Verbindungsmanagement. Die folgende Beschreibung des hier als ‚traditionell‘ bezeichneten derzeitigen Konzepts benennt auch die potenziellen Probleme.

Hochfahren und Herunterfahren des Netzwerks

Das Einschalten des MOST-Signals stößt im Zustand NetInterface Off das Hochfahren des Netzwerks an; in vielen Fällen erfolgt dies durch den PowerMaster. Die Knoten (nodes) im MOST-Netzwerk erkennen das MOST-Signal am Eingang und wechseln in den Zustand NetInterface Init. Die Knoten synchronisieren sich zum MOST-Signal des TimingMasters. Der TimingMaster setzt abschließend das System Lock Flag, was den Wechsel in den Zustand NetInterface Normal Operation bewirkt. Da diese Abfolge bereits hinreichend einfach ist, bleibt sie auch bei der Design Time Configuration erhalten.

Wenn das Netzwerk (oder ein bestimmter Teil des Netzwerks) nicht mehr benötigt wird, führt der PowerMaster folgende Aktionen aus:

  • Er initiiert das Herunterfahren des Netzwerks durch Aufruf von NetBlock.Shutdown.Start(Query).
  • Er führt die mehrphasige, mit NetBlock.Shutdown.Start(Execute) endende, Shutdown-Prozedur aus.
  • Er steuert den Energiesparmodus einzelner Geräte (Device Shutdown).
  • Er überwacht ggfs. die hitzebedingte Deaktivierung des Netzwerks.
  • Er übergibt die abschließende Phase des Shutdowns an das NetInterface, welches das Shutdown Flag setzt.

Somit werden verschiedene Prozeduren ausgeführt, bevor das Netzwerk heruntergefahren werden kann. Umfangreiche Verifikationen und Tests sind nötig, um sicherzustellen, dass das Netzwerk kontrolliert heruntergefahren wird – auch wenn möglicherweise beliebige Kombinationen widriger Bedingungen vorliegen.

Aufgaben des NetworkMasters beim Netzwerkmanagement

Der NetworkMaster ist der Hauptakteur beim Netzwerkmanagement. Im Zustand NetInterface Normal Operation übernimmt der NetworkMaster folgende Aufgaben:

  • Er nimmt FBlockIDs.Status-Meldungen von den NetworkSlaves entgegen.
  • Er erkennt und löst Konflikte durch Vergabe gültiger FBlockID/InstID-Kombinationen.
  • Er erstellt die Central Registry.
  • Er setzt abschließend den System State auf OK.
  • Er überwacht, welche NetworkSlaves das Netzwerk verlassen oder neu hinzukommen.
  • Er beantwortet Anfragen an die Central Registry durch die NetworkSlaves.

Verbindungsmanagement mit dem Connection Manager

Ein Initiator fordert bei Bedarf beim Connection Manager den Aufbau einer Verbindung an. Der Connection Manager führt daraufhin die erforderlichen Schritte aus und meldet das Ergebnis. Wird die Verbindung nicht mehr benötigt, fordert der Initiator den Connection Manager zum Abbau der Verbindung auf, woraufhin der Connection Manager erneut die nötigen Aktionen ausführt und Vollzug meldet. Problematisch ist, dass für diesen Ablauf sehr viel Kommunikation erforderlich ist und dass es keine Erfolgsgarantie gibt (wenn zum Beispiel bereits eine andere Komponente die angeforderten Ressourcen belegt).

Das Design-Time-Configuration-Konzept

Das Design-Time-Configuration-Konzept beruht auf der Annahme, dass sich die Konfiguration der Knoten im MOST-Netzwerk in vielen Fällen über die gesamte Lebensdauer eines Fahrzeugs nicht ändert, dass also die enthaltenen FBlocks und die nötigen Verbindungen erhalten bleiben. Wenn es aber keine Konfigurationsänderungen gibt, benötigt das MOST-System auch keine Komponenten, die solche Änderungen verwalten. Die Tabelle bietet einen Überblick über die entscheidenden Aspekte des Design-Time-Configuration-Konzepts im Vergleich zum traditionellen Konzept.

Vorgehen beim Hochfahren des Netzwerks

Das traditionelle und das vereinfachte Vorgehen beim Hochfahren des Netzwerks sind so lange identisch, bis der Zustand NetInterface Normal Operation erreicht wird. Es besteht aber ein struktureller Unterschied: Da es keinen NetworkMaster mehr gibt, werden die NetworkSlaves generisch als ‚nodes‘ bezeichnet. Es werden auch keine dynamischen logischen Knotenadressen mehr verwendet, sondern sämtliche Knotenadressen sind statisch. Im Zustand NetInterface Normal Operation kommunizieren die Knoten im MOST-System frei miteinander.

Wenn ein Controller einen Dienst (bzw. nach der MOST-Terminologie einen FBlock) adressiert, kann diese Anforderung je nach aktueller Verfügbarkeit des FBlock erfolgreich sein oder fehlschlagen. Da die Erstellung und Verteilung der Central Registry entfällt, nimmt der Netzwerk-Datenverkehr insgesamt trotz resultierender doppelter Dienste-Anfragen nicht zu. Um zu verhindern, dass es unmittelbar nach dem Hochfahren des Netzwerks zu erfolglosen Anfragen kommt, kann der Systemintegrator per Timer eine Verzögerung einbauen.

Verfügbarkeitsschwankungen von Diensten reduzieren

Durch die vorherige Definition der im Netzwerk existierenden FBlockID/InstID-Kombinationen werden Verfügbarkeitsschwankungen von Diensten minimiert. Sind diese Kombinationen festgelegt, müssen vom NetworkMaster keine Korrekturen mehr vorgenommen werden. Unterstützt wird dies durch Aufheben der Unterscheidung zwischen Central Registry und Decentral Registry. Stattdessen wird in jedem Knoten eine als FBlock Registry bezeichnete lokale Kopie vorgehalten.

Um das Vorhandensein oder Fehlen bestimmter FBlocks zu melden, versenden die Knoten außerdem keine FBlockIDs.Status-Meldungen mehr an den NetworkMaster, sondern an die Blocking-Broadcast-Adresse. Hierdurch werden sämtliche Knoten im Netzwerk informiert und den Empfängern wird die Möglichkeit gegeben, auf diese Information zu reagieren. Weil keine Central Registry mehr gepflegt werden muss, müssen im Zustand NetInterface Normal Operation keine Übergänge zwischen den Systemzuständen (System States) OK und NotOK angestoßen werden.

Ohne System States ist keine Unterscheidung zwischen System- und Applikations-Kommunikation notwendig: Nach dem Übergang in den Zustand NetInterface Normal Operation können alle FBlocks uneingeschränkt kommunizieren. Wenn die Netzwerk-Konfiguration in der Entwurfsphase festgelegt wird, kann der NetworkMaster, der im traditionellen Konzept die Änderungen der Netzwerk-Konfiguration überwacht, komplett entfallen. Dementsprechend werden auch der System Scan, die Central Registry, die System States und das Verhalten ‚own configuration invalid‘ nicht mehr benötigt.

Wegfall des NetworkMasters erschwert Reset-Erkennung

Der Wegfall des NetworkMasters bringt allerdings ein Problem mit sich: Das Erkennen des Resets einer Applikation kann erschwert sein. Traditionell ist ein großer Teil der Funktionalität des NetworkMasters auf diese Erkennung ausgerichtet. Ohne die Fähigkeit zum Erkennen, ob ein FBlock einen Reset ausgeführt hat, kann ein Controller fälschlicherweise annehmen, dass seine Notification-Einträge nach wie vor bedient werden.

Allerdings lässt sich dieser Nachteil einfach und elegant beheben, indem man ‚implicit notification‘ auf eine Funktion anwendet, die für die Reset-Erkennung vorgesehen ist. Dies kann zum Beispiel eine als ApplicationStarted bezeichnete Property der Funktionsklasse Switch sein. ApplicationStarted.Status wird gesendet, sobald der Knoten im Netzwerk aktiv wird. Diese Nachricht informiert die Controller, wenn der FBlock (wieder) im Netzwerk erscheint. Die Controller nutzen dies als Trigger, um die Notification-Einträge zu verifizieren und zu aktualisieren.

Wann immer ein Controller die Nachricht ApplicationStarted.Status erhält, kann er davon ausgehen, dass der betreffende FBlock einen Reset durchlaufen hat. Dieser einfache Mechanismus beseitigt eine Reihe von im traditionellen Konzept oft auftretenden Schwierigkeiten nach dem Reset eines Knotens und dem Notification-Mechanismus.

Herunterfahren des Netzwerks ohne NetBlock.Shutdown

Da die Funktion NetBlock.Shutdown nicht mehr verwendet wird, entfällt eine Vielzahl optionaler und obligatorischer Aktionen, für die der PowerMaster zuständig ist. Beim Design-Time-Konzept stößt der PowerMaster den normalen Shutdown-Prozess an, indem er ein Off-Request an das NetInterface übergibt, was zum Setzen des Shutdown-Flags im MOST-Netzwerk führt. Nach dem traditionellen Verfahren leitet ein Off-Request lediglich die finale Phase der längeren Shutdown-Prozedur ein. Device-Shutdown und Hitze-Shutdown werden nicht mehr vom PowerMaster initiiert, sondern gemäß der Design-Spezifikation des Systemintegrators aktiviert und beendet.

Vorgegebene Liste mit Verbindungen

Nach dem Design-Time-Konzept verfügt der Connection Manger über eine vorgegebene Liste mit Verbindungen. Nach dem Hochfahren des Systems richtet der Connection-Manager gemäß dieser Liste selbständig Verbindungen ein. Um verschiedenen Audio-Szenarien gerecht zu werden, lassen sich mehrere Verbindungslisten vorhalten, die vom Connection-Manager abhängig von Triggerbedingungen, die vom Systemintegrator definiert wurden, aktiviert und deaktiviert werden. Dementsprechend werden die Funktionen BuildConnection und RemoveConnection des ConnectionMaster FBlock nicht mehr benötigt.

Diagnosis-FBlocks ermöglichen End-of-Line-Setup

Um das End-of-Line-Setup, d.h. die Versorgung von Steuergeräten mit Konfigurationsdaten im Produktionsablauf, im Kontext der Design Time Configuration zu ermöglichen, besitzt jeder Knoten anfänglich einen Diagnosis-FBlock. Nach dem Verbau der Steuergeräte im Fahrzeug während der Produktion wird der TimingMaster mit einem Diagnose-Tool verbunden. Das Diagnose-Tool verteilt dann die Systemkonfiguration bestehend aus FBlock-Registry, implicit-notification-Einstellungen und der Verbindungsliste über den Diagnosis-FBlock. Letzterer wird über eine Wildcard adressiert, was den Zugriff auf den angeforderten FBlock unabhängig von der tatsächlichen InstID ermöglicht. Hierdurch ist sichergestellt, dass die erfolgreiche Bereitstellung der Konfigurationsdaten nicht davon abhängt, welche InstID voreingestellt wurde.

In statischen Anwendungs-Szenarien bietet die Konfiguration schon beim Design hervorragende Kostensenkungs- und Vereinfachungsmöglichkeiten durch den Entfall aller Teile, die die traditionelle MOST-Systemkonfiguration zur Überwachung von Konfigurationsänderungen benötigt.

Literaturhinweise:

[1] HMOST Specification Rev. 3.1 Pre-Release. MOST Cooperation, 2015.

[2] HGrzemba, A.: MOST – The Automotive Multimedia Network – From MOST25 to MOST150. Franzis Verlag, Poing, 2011, ISBN 978-3-645-65061-8.

* Renato Machelett ist Inhaber von Machelett Software & Consulting und Koordinator der MOST-Arbeitsgruppe FCat Exchange Formats.

(ID:44269261)