LIN-Bus-Technologie wird optimiert Die neue LIN-Spezifikation 2.1 – Teil 2

Der erste Teil dieses Beitrags stellte die Neuerungen der Kapitel 2 bis 4 der LIN-Spezifikation vor [1], der hier vorliegende zweite Teil setzt sich mit den Kapiteln 5 bis 9 auseinander.

LIN-Bus-Technologie wird optimiert

Der erste Teil dieses Beitrags stellte die Neuerungen der Kapitel 2 bis 4 der LIN-Spezifikation vor [1], der hier vorliegende zweite Teil setzt sich mit den Kapiteln 5 bis 9 auseinander.

INHALT:
Transport-Protokoll-Implementierung
Bitübertragungsschicht (Physical Layer)
Application Program Interface (API)
„Node Capability Language Specification“
„Configuration Language Specification“
Beziehungen der Spannnungspotentiale
Literatur
Autor

Die Diagnose-Spezifikation wurde komplett überarbeitet. Die Erfahrungen aus LIN 2.0 zeigten, dass die OEMs die Diagnose-Funktionen unterschiedlich implementiert haben, was die Compliance-Tests erschwerte. Die Diagnose-Spezifikation besteht nun aus den drei Teilen:

  • Definition der Diagnoseklassen,
  • Standardisierung des „Multi Frame Transport Layer“-Protokolls entsprechend der ISO 15765-2,
  • Implementationsvorschrift für das Transport Layer in Master und Slave.

Die Spezifikation definiert drei Diagnose-Klassen:

  • Diagnoseklasse I. Sie ist für intelligente Sensoren und Aktoren mit einfachen Diagnose-Funktionen vorgesehen und ist signalbasiert, d.h., Fehlerinformationen werden mittels signaltragenden Frames transportiert. Hierfür ist ein „Single Frame Transport Layer Protocol“ ausreichend. Für die Knoten-Identifizierung muss nur der Service „Read by Identifier“ mit dem Identifier = 0 (Auslesen der Hersteller-ID, Funktions-ID sowie der Versionsnummer) unterstützt werden. Der Fehlerspeicher ist im Master implementiert, der ihn mit den empfangenen Signalen auf dem neuesten Stand hält.
  • Diagnoseklasse II. Sie beinhaltet alle Funktionen der Klasse I, unterstützt aber zusätzlich die Knoten-Identifikation gemäß ISO 14229-1 (Unified Diagnostic Services; UDS). Hierfür muss das vollständige Transport Layer mit dem „Multi Frame Support“ implementiert werden. Der Zugriff auf die Sensor- und Aktor-Daten erfolgt über Signale. Es können Parameter gelesen und beschrieben werden.
  • Diagnoseklasse III. Sie enthält alle Funktionen der Klasse II, zusätzlich sind weitere UDS-Services implementiert. Es kann der Speicher des Slaves direkt gelesen oder beschrieben werden, um beispielsweise die Sensor-Rohdaten auszulesen oder den Knoten zu parametrieren. Die Slaves haben einen eigenen lesbaren Fehlerspeicher und können einen Programm-Download unterstützen.

Die Signale, die Diagnose-Daten transportieren, können periodisch (Typ 1) oder nicht-periodisch (Typ 2) übertragen werden. Sie haben die Zustände „no test result available“, „test result failed“ oder „test result passed“ und können im NCF und im LDF (Node Attributes) hinter dem Schlüsselwort fault_state_signals gelistet werden, so dass sie für die Entwicklungs- und Testtools gekennzeichnet sind. Nach wie vor ist eine nutzerspezifische Diagnose möglich. Dazu können die NADs 128 bis 255 benutzt werden. Allerdings sollten möglichst immer die standardisierten Diagnose-Klassen verwendet werden.