LIN-Bus-Technologie wird optimiert – Teil 1
Die neue LIN-Spezifikation 2.1
Fortsetzung des Artikels von Teil 3
Netzwerk-Management
Das Netzwerk-Management beschreibt wie in der Version 2.0 die Kommunikationszustände, das „Go to Sleep“- und das „Wake-up“-Verhalten; der „Power off“-Zustand ist nicht mehr enthalten. Ein Knoten wechselt in den „Sleep Mode“ entweder nach dem Empfang des „Master Request Frame“, in dem das erste Byte Null ist (die restlichen sieben Bytes enthalten 0xFF), oder wenn auf dem Bus für mindestens 4 s Ruhe herrscht. Spätestens nach 10 s muss er in den „Sleep Mode“ gewechselt sein.
Das „Wake-up“-Signal ist ein 250 µs bis 5 ms langer Low-Pegel auf der LIN-Leitung. Die Dauer hängt von der Datenübertragungsrate ab. Wird dieser Low-Pegel durch das Senden des Byte 0xF0 erzeugt, ist der Impuls bei der maximalen Datenübertragungsrate von 20 kbit/s 250 µs lang, er dauert 5 ms bei 1 kbit/s, der niedrigsten Datenübertragungsrate. War der „Wake-up“-Versuch erfolglos, sendet der Knoten nach 150 bis 250 ms ein weiteres „Wake-up“-Signal. Dies kann er noch ein drittes Mal tun, bevor er eine Pause von mindestens 1,5 s einfügen muss. Danach kann er wieder dreimal ein „Wake-up“-Signal senden. Falls dies wieder erfolglos war, wird der Zyklus nach einer Wartezeit von 1,5 s wiederholt. Die Anzahl der Wiederholungen ist in der Spezifikation nicht begrenzt.
Ein Knoten im Sleep-Mode erkennt unabhängig von der Baudrate ein „Wake-up“-Signal nach einem Low-Pegel von mindestens 150 µs und hat dann max. 100 ms Zeit, um zu starten und den Kommunikations-Stack zu initialisieren. So kann auch ein unsynchronisierter Slave bei 20 kbit/s sicher das „Wake-up“-Signal erkennen.
Jobangebote+ passend zum Thema
- Status-Management
Das Status-Management hat sich nicht geändert und wird hier nicht näher erläutert.
Transport-Layer-Spezifikation
Das Kapitel „Transport Layer“ ist zwar erstmals in der Spezifikation vorhanden, aber nicht wirklich neu. Das Transport-Layer-Protokoll wurde bereits in LIN 2.0 im Kapitel „Diagnose and Configuration Specification“ definiert. Neu sind die Fehlerbehandlung und die „Time-out“-Zeiten, die auf der ISO 15765-3 basieren. Sie kommen nur bei der segmentierten Übertragung von maximal 4096 Byte langen Datensätzen zur Anwendung und sind in Bild 8 dargestellt.
Der „Time out“-Parameter N_As definiert die maximale Übertragungszeit eines First Frame (FF) bzw. Consecutive Frame (CF) aus Sicht des Transport Layers, diese beträgt max. 1000 ms. Der Parameter N_Cr definiert die maximale Wartezeit bis zum Empfang des nächsten CF. Sie beträgt ebenfalls 1000 ms. Der Parameter N_Cs beschreibt die maximale Zeit, in der der Master den nächs-ten Frame senden muss. Sie muss so bemessen sein, dass N_Cr nicht überschritten wird. Die Parameter können individuell für jeden Slave im „Node Capability File“ (NCF) und im „LIN Description File“ (LDF) mit den Schlüsselwörtern N_As_timeout und N_Cr_timeout hinterlegt werden.
Die LIN-Busleitung verwendet wie der CAN-Bus dominante (Low) und rezessive (High) Pegel, d.h., eine Null kann eine Eins auf der LIN-Leitung überschreiben. Antworten in dem Beispiel beide Slaves gleichzeitig, überschreiben sich die Slaves im ersten Byte des Response-Teils, in dem die PID gespeichert ist. Auf der Leitung entsteht das Bit-Muster 0001 0000 (Bild 5), das weder PID 11 noch PID 12 entspricht. Da laut Spezifikation jeder Sender überprüfen muss, ob sich sein Bit-Muster wirklich auf der Leitung befindet, und im Fehlerfall spätestens nach Ende der Übertragung des Bytes der Sendevorgang gestoppt werden muss, brechen beide Slaves die Übertragung ab. Damit erkennt der Master eine Kollision und schaltet auf die „Collision Resolving Schedule“-Tabelle um. Eine Kollision wird von den Slaves nicht als „Response Error“ protokolliert.
Wenn die beiden Slaves bit-synchron antworten (d.h., ihre „Response Space Time“ ist gleich groß), gibt es jedoch PID-Kombinationen, bei denen sich eine PID auf der LIN-Leitung durchsetzt und der Master somit keine Kollision erkennen kann. In diesem Fall muss der Slave, der die Arbitrierung verloren hat, sein Event speichern und bei der nächsten Abfrage wieder senden. In Bild 6 hat der assoziierte Unconditional Frame des Slave 1 die PID 0 und der des Slaves 2 die PID 1. Bei einer Arbitrierung setzt sich die PID 0 durch. Der Slave 2 bricht den Sendevorgang ab. Slave 1 kann seinen kompletten Response-Teil senden. Der Master erkennt in diesem Fall keine Kollision. Slave 2 muss sein Event speichern und kann es erst bei der nächsten Abfrage übertragen.
- Die neue LIN-Spezifikation 2.1
- Zuweisung einer PID zu einem Frame
- Konfiguration und Identifikation der Knoten
- Netzwerk-Management
- Schedule-Tabelle
- Frame-Struktur
