LIN-Bus-Technologie wird optimiert
Die neue LIN-Spezifikation 2.1 – Teil 2
Fortsetzung des Artikels von Teil 4
Transport-Protokoll-Implementierung
Im Abschnitt „Transport Protocol Handling in LIN Master“ werden das Schedule und der Zustandsautomat des Transport-Protokoll-Kommunikations-Handlers beschrieben. Diagnose-Nach-richten können entweder im „Interleaved Diagnostic Mode“ oder im „Diagnostics Only Mode“ übertragen werden, wobei den ersten Modus jeder Master unterstützen muss, der zweite ist optional.
Jobangebote+ passend zum Thema
- Schedule-Verfahren
Im „Interleaved Diagnostic Mode“ werden die „Diagnose Master Requests“ und die „Diagnose Slave Responses“ zwischen die Nachrichten einer normalen Schedule-Tabelle eingeschoben, d.h., nach jeder Diagnose-Nachricht wird mindestens eine normale Nachricht übertragen, wobei die Timeouts des Transport Layers (N_Cs und N_Cr) und des Parameters P2 (Zeit vom Empfang des letzten Diagnose-Master-Request-Frames bis zum Abfragen des Diagnose-Slave-Response) nicht überschritten werden dürfen. Zu berücksichtigen ist auch, dass sich das Zeitverhalten der normalen Schedule-Tabelle während der Übertragung von Diagnose-Nachrichten ändert.
Bild 13 zeigt ein Beispiel für die Diagnose-Kommunikation im „Interleaved Diagnostic Mode“. Der Master sendet einen Diagnose-Request und wartet auf die Antwort, bis der Slave diese zur Verfügung stellt oder die Timeouts abgelaufen sind. Im „Diagnostics only Mode“ werden keine anderen Nachrichten übertragen. Der Master wird dazu vom Tester mit dem UDS-Service „Communication control“ zum Wechseln in eine Schedule-Tabelle veranlasst, die nur Diagnose-Nachrichten enthält.
- Kommunikations-Handler
Bild 14 zeigt den Transport-Protokoll-Kommunikations-Handler des Master. Er besteht aus den fünf Zuständen:
- Idle: Ruhezustand.
- Tx functional active: In diesen Zustand wechselt der Automat, wenn ein so genannter „functional Request“ vom Tester empfangen wurde. Der Master generiert einen MRF, der durch die „functional NAD“ (NAD = 126) gekennzeichnet ist. Dieser ist eine Diagnose-Broadcast-Nachricht (immer ein Single-Frame) und wurde in LIN 2.1 neu eingeführt.
- Tx physical active: In diesem Zustand werden alle anderen Diagnose-Nachrichten versendet, d.h., das NAD-Feld enthält die NAD des adressierten Slaves.
- Rx physical active: Befindet sich der Master in diesem Zustand, wird die Antwort vom Slave zum Tester übertragen.
- Interleaved functional during Tx: Während der Master Daten zu einem Slave überträgt, kann vom Tester ein „functional Request“ eingehen. Der Master wechselt dann aus dem Zustand „Tx physical active“ in diesen Zustand und schiebt die „functional Request Message“ für das Cluster ein, die allerdings von dem Slave, zu dem gerade die Daten übertragen werden, ignoriert wird.
- Interleaved functional during Rx: Analog zu dem vorigen Zustand können auch beim Empfang von Daten von einem Slave „functional Request Messages“ in das Cluster gesendet werden.
Für weitere ausführliche Informationen insbesondere zu den Zustandsübergängen wird auf [2] verwiesen.
- Die neue LIN-Spezifikation 2.1 – Teil 2
- „Node Capability Language Specification“
- Application Program Interface (API)
- Implementierung im Slave
- Transport-Protokoll-Implementierung
