1
2
3
früher: Anzahl der Funktionen im Kfz gering direkte Verdrahtung jetzt: starker Zuwachs im Bereich Komfort zu hoher Verdrahtungsaufwand Suche nach: einem einfachen & kostengünstigen Bussystem Standard für Sensor & Aktor Anwendung Überqualifikation des CAN-Bus im Subbus-Bereich 4
5
LIN-Bus etablierte sich als Standardsystem in mechatronischen Applikationen im Automobil Einsatzfelder des LIN-Busses im Auto: z.b. Vernetzung der Reifendrucksensoren unterhalb der CAN-ECU (Steuereinheit) der Lichtdrehschalter zum CAN-Bedienfeld von Diebstahlschutzfunktionen zur CAN-Zentral-ECU vom Wischer zur CAN-Zentral-ECU 6
1998: Idee von einem einheitlichen Kommunikationsstandard für mechatronische Systeme, führte zur Gründung einer Arbeitsgruppe durch die Firmen DaimlerChrysler, BMW, Audi, Volkswagen, Volcano Communication Technologies und Motorola aus diesen Firmen setzt sich heute das LIN-Konsortium zusammen 2000: März: Vorstellung des LIN-Systems vor einem breitem Fachpublikum April: Version 1.1 wird veröffentlicht November: Version 1.2 wird veröffentlicht 2001: erster Serieneinsatz eines LIN-Bus-Systems beim Automobilhersteller DaimlerChrysler in der SL-Klasse 2002: September: die wichtigsten europäischen Automobilhersteller bekennen sich eindeutig zum LIN-Bus als Subbus für mechatronische Applikationen November: Version 1.3 wird veröffentlicht 2003: Erweiterung des Protokolls durch Version 2.0 7
8
Master-Task steuert die Kommunikation Master-Knoten besteht aus Master-Task und Slave-Task Alle Slave-Tasks können mithören Master-Task beginnt die Kommunikation durch Senden eines Headers mit Frame Identifier Jeder Slave-Task entscheidet, was er bei diesem Frame Identifier tun soll 9
Aufbau des LIN-Knoten vergleichbar wie bei CAN LIN-Transceiver: u.a. Umwandlung von Logik-Pegeln in LIN-Bus-Pegel LIN-Controller: Umsetzung des LIN-Protokolls Microcontroller: Anwendungsabhängige Aufgaben 10
keine definierte Leitungsimpedanz Open-Collector-Schaltung 11
12
13
Break Field Aufgabe: Signalisierung des Beginns eines neuen Frames Master: Senden von mindestens 13 Low-Bits und mindestens einem High-Bit (kein Standard UART-Zeichen) Slave: Erkennen von mindestens 11 Low-Bits Sync Field Aufgabe: Synchronisation der Slaves (diese können dadurch einfache RC-Oszillatoren besitzen) Master: Vorgabe der Bitrate (T bit ) durch Senden des Standard UART- Zeichen 0x55 Slave: Synchronisationsprozess über das Messen der Zeitspanne zwischen fallenden Flanken 14
Protected Identifier Field Aufgabe: inhaltesbezogene Addressierung besteht aus dem Frame Identifier und zwei Paritätsbits 15
Übertragung eines Wortes beginnt mit dem Low-Byte (little-endian- Übertragung) 16
Checksumme Invertierte Modulo-256-Summe: Der Übertrag der 8-Bit-Addition wird zum LSB des Zwischenergebnisses hinzuaddiert. Die Gesamtsumme wird anschließend invertiert. 17
18
Unconditional Frame (Standardframe) Master-Task arbeitet eine feste Time-Schedule-Tabelle ab bei jedem Frame Identifier antwortet nur ein Slave-Task 19
Sporadic Frame (Sporadic Frame) Time-Schedule-Tabelle enthält Time-Slots in denen zwischen verschiedenen Identifiers gewechselt werden kann 20
Event Triggered Frame (Ereignisgesteuerter Frame) mehrere Slave-Task werden zu einem Event Triggered Frame zusammengefasst bei einem Identifier können mehrere Slave-Tasks antworten bei einer Kollision wird die Übertragung abgebrochen Master-Task erkennt die Kollision über die fehlerhafte Checksumme und fragt jeden Slave-Task nacheinander ab 21
Diagnostic Frames (Diagnoseframe) mit diesen Frames wird die Konfiguration und Diagnose der Slave- Knoten durchgeführt das aufgesetzte Protokoll wird auf der Folie Transport Layer erläutert. User-defined Frames reserviert für kundenspezifische Erweiterungen Framelänge kann auch über 8 Byte sein Reserved Frames für zukünftige Entwicklungen reserviert 22
Initializing Initialisierung aller notwendigen Komponenten Operational normaler Betriebsmodus (Senden und Empfangen von Frames) Go-to-Sleep-Befehl: ID: 0x60 mit dem ersten Datenbyte 0x00 und 7 Datenbytes mit 0xff nur der Master-Task kann den Go-to-Sleep-Befehl senden Bus Sleep Mode Bus ist auf high (rezessive) Wake-Up-Befehl: Bus wird von irgendeinem Knoten für 250 µs bis 5 ms auf low gezogen 23
Bit-Fehler Sender überwacht den Bus und prüft, ob der rückgelesene Pegel mit dem gesendeten Pegel übereinstimmt die Übertragung wird abgebrochen Checksummenfehler Vergleich der gesendet mit der aus dem Frame berechneten Checksumme Identifier-Parity-Fehler Vergleich der gesendeten mit der aus dem Frame berechneten Parität Slave-Not-Responding-Fehler angesprochener Slave-Task antwortet nicht in der maximalen Übertragungszeit Inconsistent-Synch-Field-Fehler Slave kann sich nicht auf dem Mastertakt synchronisieren, da das Synchronisationsfeld außerhalb der Toleranzen liegt Physical-Bus-Fehler statischer High oder Low-Pegel z.b. bei Kurzschluss zu Masse oder Versorgungsspannung oder parasitäre Impedanz Fehlerbehandlung Reaktion ist in der Spezifikation nicht festgelegt, um das Protokoll möglichst einfach zu halten. 24
Request: vom Master gesendet (ID: 60) Response: vom Slave gesendet (ID: 61) NAD: Node Adress for Diagnose Knotenadresse PCI: Protocol Control Information Protokolltyp LEN: Length Nachrichtenlänge SID: Service Identifier kennzeichnet den Nachrichteninhalt zum Slave RSID: Response Service Identifier kennzeichnet den Nachrichteninhalt vom Slave D1 D6: Datenbytes 25
wichtig ist das Verhindern von Konflikten zwischen Knoten jeder Knoten hat eine LIN Product Identification, eine initiale NAD und optional eine serial number dadurch kann für jeden im Cluster gesendeten Frame ein Identifier definiert werden LIN Product Identification Serial number (optional) Initial NAD (node address of a packet data unit) Verwendung einer bestimmten PDU-Struktur verschiedene Service Identifier (SID) sind spezifiziert z.b. Assign NAD, Read by Identifier, Save Configuration usw. die Response SID für eine positive Antwort ist immer SID+0x40 26
definiert Methoden zum Übertragen von Diagnosedaten zwischen Master bzw. Tester und Slave-Knoten (TL) Diagnose Dienste werden immer von einem externen oder internen Test- Tool ausgelöst zwei Möglichkeiten existieren 1. Tester (z.b. über CAN-Gateway) überträgt eine Anfrage zum LIN- Slave 2. LIN-Slave überträgt eine Antwort zum Tester für die Diagnose wird die NAD als Quelladresse für die Angeforderte Information genutzt jedem Slave-Knoten wird eine von drei möglichen Diagnose Klassen mit unterschiedlich komplexer Diagnose Funktionalität zugewiesen Class I Einfache Geräte ohne oder mit nur geringer Diagnosefunktionalität z. B. intelligente Sensoren Class II gleich Class I unterstützt jedoch auch Knotenidentifikation Class III Für Slave-Knoten die wesentlich mehr als die normale Sensor/Aktor-Funktionalität haben, z.b. Sensordaten auswerten und gleich den Aktor ansteuern 27
Node Capability Language Specification standardisierte Syntax zum Beschreiben der Eigenschaften von Slave-Knoten auf Basis der Node Configuration and Identification Specification stellt Grundlage zum automatischen Erzeugen eines LDF durch ein Design Tool dar Configuration Language Specification beschreibt eine Sprache zum Erstellen des LIN Description File (LDF) LDF enthält die Konfiguration des kompletten Clusters Knoten Signale (Daten) Frames und Scheduling-Tabellen bietet eine Schnittstelle zwischen Entwickler und Zulieferer einzelner Knoten stellt Grundlage für die Eingabe in Entwicklungs- und Analyse- Tools dar 28
die Node Capability Files enthalten alle notwendigen Informationen über die einzelnen Knoten des Clusters Definitionen des Knoten Beziehung zu anderen Knoten Logischer Signalverlauf das Design Tool generiert aus den Node Capability Files ein LIN Discription File (LDF) aus dem LDF generiert das Node Configuration Tool automatisch die benötigten LIN-Funktionen für die einzelnen Knoten (LIN node application code) das LDF wird weiterhin zum Debuggen und Analysieren des Clusters durch den Bus-Analyzer und Emulator genutzt (z.b. Timing Analysis) der LIN node application code wird zusammen mit dem Anwendungscode kompiliert 29
definiert eine Softwareschnittstelle zum vereinfachten Erstellen von Anwendungsprogrammen für ein LIN-ECU ohne die spezielle über die LIN-Cluster-Konfigurationen (LDF) bietet dem Anwender die Möglichkeit Software für LIN-Teilnehmer zu erstellen ohne sich mit den LIN-spezifischen Details beschäftigen zu müssen definiert einen Satz von C-Funktionen als Schnittstelle es ist unterteilt in 3 Teile: LIN core API Initialisierung, Steuerung und Wechselwirkung zwischen Anwendung und LIN-Core LIN node configuration and identification API stellt Funkionen zum Konfigurieren und Identifizieren der Slave-Knoten durch den Master bereit basiert auf Node configuration and identification Spec LIN transport layer API stellt Funktionen für die Implementierung der Diagnosefunktionalität bereit steuert die Kommunikation mit einem externen Diagnose- Tool (Tester) 30
Transceiver z.b. TI TPIC1021 System-Basis-Chips z. B. Melexis TH8061, Freescale PC933895 Single-Package-Lösungen Realisierung eines Knoten mit nur einem Bauelement (Chip) mehrere Chips zusammen gehaust z.b. Freescale MM908E62x, Melexis MLX80103 usw. intelligente Sensoren mit Sensor, ADC, DSP, LIN-Controller, LIN- Transceiver z.b. Micronas HAL2810 Mikrocontroller (MCU) mit integrierten Hardware-LIN-Controller von einfachen 8-Bit-Controllern mit integriertem Harware-LIN- Interface (z.b. ATmegaxxM1/C1) bis hin zu hochintegrierten Chips mit ARM7-Core, USB-, 2xCAN-, 2xLIN-Interface usw. zur Realisierung komplexer Steuergeräteund Gateway-Funktionalität (z.b. NXP LCP292x) 31
durch Standardisierung bis in den Design-Prozess ist der Einsatz von Off-The-Shelf-Knoten möglich und dadurch auch die Vergabe von Entwicklungsarbeit an Zulieferer für einfache Komfortanwendungen mit geringen Datenmengen ist LIN günstiger als CAN für komplexere Anwendungen mit hohen Datenmengen und Sicherheitsrelevanz ist Flexray besser geeignet als CAN durch die Vielfalt von CAN-Standards entstand der Bedarf nach einem einheitlichen Standard für einfache Anwendungen LIN wird als Subbus in Zukunft Marktanteile vom CAN-Bus abgreifen auch im Zusammenspiel mit Flexray und MOST wird der etablierte CAN- Bus nicht ganz verschwinden 32
33
34