Ontstaan van LIN:

LIN is in 2000 geïntroduceerd door  de automobilefabrikanten Volkswagen, Audi, BMW, DaimlerChrysler en Volvo samen met communicatiespecialist Volcano en halfgeleider-concern en Motorola een nieuwe databus opgezet voor motorvoertuigen. Deze bedrijven zijn verenigd in een industrievereniging onder de naam Local Interconnect Network (LIN). Het belangrijkste doel van LIN is om zo goedkoop mogelijke componenten te bieden, waaruit hiërarchische datanetwerken in motorvoertuigen opgebouwd kunnen worden, vooral voor de verbindingen van sensoren en regelsystemen in deuren, wielen of stoelen.

LIN consortium:

De stuurgroep voor LIN bestaat uit de autofabrikanten Audi, BMW, Volkswagen, Volvo Daimler-Chrysler, de chipfabrikant Motorola en het technologie centrum Volcano Communications. Deze bedrijven zorgen voor een verdere standaardisatie van het busysteem en wijzigingen in de specificatie. Daarnaast zijn er leden, zoals de automobielfabrikanten Opel, Renault en Mitsubishi, en andere chipfabrikanten zoals Philips, Infineon, Fujitsu, Hitachi en gespecialiseerde bedrijven zoals Vector en Ihr. De deelnemende producenten zien de nieuwe bus niet als concurrent voor bestaande netwerktechnieken in voertuigen, zoals bijvoorbeeld CAN (Controller Area Network) of de nieuwe TTP-bus (Time Triggered Protocol) van DaimlerChrysler. CAN doet bij veel autofabrikanten dienst als netwerkverbinding van het motormanagement en de bodyelektronica. TTP werd door DaimlerChrysler enkel ontwikkeld vanuit het oogpunt om Drive by Wire mogelijk te maken. LIN moet daarentegen zowel de huidige analoge aansturing in de auto (bijvoorbeeld bij de regeling van de binnenverlichting) vervangen en met het centrale netwerk verbinden, alsmede nieuwe controle- en besturingsmogelijkheden bieden, bijvoorbeeld met behulp van luchtdruk- en regelsensoren.  LIN zal vooral daar worden ingezet, waar de kosten van CAN te hoog uitvallen en de datarates en de vele toepassingsmogelijkheden van deze bus niet noodzakelijk zijn. Het protocol wordt verder op deze pagina besproken. De nadruk zal liggen op de laatste revisie van het LIN protocol (Versie 2.0) omdat deze voordelen heeft ten opzichte van de voorgaande versies

LIN bus:

In tegenstelling tot CAN is LIN een master/slave-bus. LIN werkt met een enkele draadverbinding en wordt door de accu van de auto van stroom voorzien. Het communicatieprotocol is gebaseerd op de ISO 9141 NRZ-standaard. Het LIN-consortium ontwikkelt niet alleen het protocol en de hardware-specificatie zelf, maar ook alle ontwikkelingstools en API's voor bijbehorende software.  De deelnemende bedrijven verwachten dat de nieuwe bus niet alleen in de automobielindustrie zal worden ingevoerd, maar in de toekomst bijvoorbeeld ook toepassingen zal vinden in industriële fabricageprocessen of in de aansturing van huishoudelijke apparatuur. Traditioneel was er vanaf elke schakelaar op het dashboard een verbinding met de desbetreffende lampje (of andere actuator). Is er een terugmelding gewenst van een eventueel defect lampje dan is er een extra draadje nodig voor de sensor. Met de komst van een bodynetwork wordt een belangrijk stuk bekabeling vervangen door een tweedraads (CAN)  vanaf de centrale boardcomputer naar de controlunits op de vier hoeken in de auto. Van hieruit gaan nu korte verbindingen naar de actuatoren (bijvoorbeeld lampen) en de sensoren (teruglezing). Het zijn vooral deze korte verbindingen, die men in de toekomst nog verder in een netwerkarchitectuur gaat opnemen. Dit is het echte sensor/actuator netwerk in de auto. Er zijn voordelen te noemen van deze architectuur: besparing op de bekabeling, een eenvoudige diagnostiek en een snellere reparatie. Het is echter duidelijk dat de gebruikte componenten duurder zullen worden. De vraag is of de genoemde voordelen opwegen tegen deze hogere componentprijzen. Om deze hoge componentprijzen te compenseren moeten er oplossingen bedacht worden zoals goedkopere microcontrollers met geïntegreerde netwerkcontroller of enkeldraads netwerken. Echter de eis van betrouwbaarheid zal blijven bestaan. In de jaren negentig zijn verschillende automobielfabrikanten gaan experimenteren met verschillende vormen van de CAN bus. General Motors had eind jaren negentig een goed concept ontworpen voor een single-wire CAN. Dit is inmiddels ook gestandaardiseerd in de norm J2411 van de SAE (Society of Automotive Engineers). Andere bedrijven waren inmiddels naar andere mogelijkheden gaan kijken en in 2000 werd de LIN-standaard gelanceerd. Aan de verwachting van LIN is voldaan. Tot op de dag van vandaag wordt de LIN bus bij diver automotive producten “ingedesigned”. Het is een effectief low-end netwerk, dat meestal als subbus naast  CAN zal functioneren. LIN maakt meestal gebruik van een al geïntegreerde UART in de microcontroller. Door een geavanceerd synchronisatie mechanisme volstaat een eenvoudige RC-oscillator als klokgenerator.

Het protocol

LIN is een serieel, enkeldraads bussysteem. Elk LIN netwerk bevat maar één master en maximaal 16 slaves. Omdat LIN een enkeldraads protocol is, moet het asynchroon kunnen werken. Elke deelnemer zorgt voor zijn eigen klok welke op eenvoudige wijze moet kunnen worden opgewekt. Dure kristallen zijn uit den boze, een RC-klok moet volstaan. Dit is ook de reden van het master - slave principe, daarbij heeft de master de taak om de synchronisatie van de slave te verrichten.Tevens moet de master de slaves van informatie voorzien, en de informatie van de slaves opvangen. Het is alleen mogelijk om slaves onderling informatie uit te laten wisselen als de master daartoe opdracht geeft. De hoogste gedefinieerde snelheid bedraagt 20 kbit/s. Echter in de praktijk worden de gebruikelijke snelheden van seriele communicatie toegepast, te weten 2400, 9600 en 19200 bit/s. Hogere snelheden zijn natuurlijk wel mogelijk maar alleen voldoet het geheel dan niet meer aan het LIN 2.0 protocol.

Verschillen t.o.v. LIN 1.3

• Byte array signalen worden nu ondersteund, zo kunnen nu berichten groter dan 8 bit in één keer verstuurd worden.
• De checksum berekening is uitgebreid met de mogelijkheid om ook de identifier mee te nemen in de checksum.
• Een automatische synchronisatie is toegevoegd in deze specificatie.
• Signal groups zijn verwijderd.

LIN Frames

De communicatie tussen de verschillende units bestaat uit het versturen van een LIN frame. De master zendt een header (het eerste deel van een frame) waarna een response (tweede deel van het frame) volgt; de header is in de onderstaande afbeelding te zien.

Op de volgende afbeelding is de response te zien.

De header wordt alleen door master gegenereerd. Echter een response mag gegenereerd worden door zowel de master als de slave. Een response van een slave mag alleen gestuurd worden als de master daar opdracht toe geeft. De header bestaat uit drie delen: de synch break, een synchronisatie byte en een indentifier. De break dient ervoor om de deelnemers te waarschuwen dat er een nieuw frame komt. Dit frame bestaat uit 13 dominante bits (bij LIN is dit logisch “0”) inclusief een startbit gevolgd door een break delimiter. De break delimiter moet in ieder geval 1 bit tijd hoog zijn.Na de synch break volgt een synchronisatie byte, dat ervoor dient de slaves te synchroniseren. De inhoud van dit byte is $55 (afwisselend 01 patroon) inclusief start- en een stopbit. Het laatste deel van de header is de identifier, deze bestaat ook uit 8 bits. Bit 0 t/m 5 zijn de ID bits en bit 6 en 7 zijn de parity bits.
Deze 6 ID bits resulteren in een bereik van 0 tot 63 berichten ID’s.

Deze zijn als volgt verdeeld:
0 t/m 59 : Zijn vrij in te vullen
60 en 61: Gereserveerd voor gebruik van diagnostische gegevens
62: gereserveerd voor toevoegingen van de gebruiker
63: gereserveerd voor toekomstige verbeteringen van het protocol.

De functie van de twee parity bits is ervoor zorgen dat de indentifier nooit helemaal uit 0-en of 1-en bestaan. Tevens kan elke node nu controleren of de indentifier wel goed is ontvangen. In de oorspronkelijke specificatie (rev. 1.1) werden bit 5 en 6 gebruikt om de lengte van de data weer te geven. Nu gebeurt dit door middel van een configuratie file, waar alle berichten gespecificeerd zijn de parity bits in de indentifier worden als volgt berekend:

Na de indentifier volgt een response, welke bestaat uit 1 tot 8 bytes data gevolgd door een checksum. Hoeveel bytes een response bevat wordt vastgelegd in een  configuratie file. Zo weet elke gebruiker op het netwerk hoeveel data er ontvangen moet worden. Het eerste byte dat verstuurd wordt is de LSB en de laatste is MSB. Het laatste byte van een response is de checksum. Om de checksum te berekenen moeten alle data bytes opgeteld worden. De optelling wordt geïnverteerd en dat is de checksum. Er bestaat ook een “enhanced checksum”, hierbij wordt de indentifier ook meegenomen in de berekening.

Voorbeeld:
Stel dat de volgende data wordt verstuurd: 0x4A, 0x55, 0x93 0xE5. De bytes worden opgeteld tot er een carry ontstaat. Indien dit het geval is wordt de optelsom met één verhoogd en de carry wordt weer gecleared. Nadat het laatste databyte is verwerkt wordt de uitkomst geïnverteerd. De uiteindelijke checksum is 0xE6, de ontvanger kan nu door dezelfde berekening uit te voeren, controleren of de ontvangen data volgens de checksum berekening klopt. Als het om een enhanced checksum gaat dan zal de indentifier ook meegenomen worden in de berekening  (in dit voorbeeld zou dat 0x4A zijn).

Wake up en sleep mode

Als er na 4 sec. geen busactiviteit meer is, moet de node in sleep mode gaan. Pas als een node in sleep mode is mag hij een wake up ontvangen. Om een node wakker te maken moet de LIN bus  gedurende 250 ms tot 5 ms een dominant signaal op de LIN bus zetten, alles wat daarbuiten valt is geen geldige wake-up. De ontvanger moet een signaal tussen de 150 ms en de 5 ms herkennen, na maximaal 100 ms moet de node gereed zijn om de break te ontvangen. Een tweede optie om een node in sleep te krijgen is het verzenden van diagnostisch bericht $3C (bericht 60) met het eerste data byte gelijk aan $00

Als de master niet binnen 150 ms na een wake up reageert, dan zal de node drie keer de wake up herhalen. Na drie keer wacht de node nog 1,5 sec. en probeert het opnieuw. Wat hierna gebeurt staat nog niet in de specificatie. Vaak wordt er dan besloten dat de unit terug te laten gaan naar sleep mode.

De LIN communicatie verloopt via een LIN transceiver, dit component verzorgt de omzetting van LIN naar een RxD en TxD signaal. Er zijn verschillende transceivers op de markt. De meeste lijken sterk op elkaar, maar vaak zijn er kleine verschillen.

Manufacturer		Datasheet
Motorola		MC33399
Melexis		TH8082_006
Philips		TJA1020
On Semiconductor		NCV7361A

De belangrijkste kenmerken van de Motorola MC33399:

Hardware:  LIN Microcontrollers:

Hier zijn ook weer een aantal variaties mogelijk. Op dit moment zijn de MC68HC908GZ60 van motorola en de uPD78F9852 van NEC goede keuzes.

Beide controllers hebben een 8 bits databus. Het grootste verschil, is dat de Motorola een ESCI (Enhanced Serial Communications Interface) bevat en de NEC een gewone UART interface. Het voordeel van een ESCI dat de LIN opties direct meegenomen zijn. De ESCI kan bijvoorbeel een break genereren en detecteren, eigenschappen die een gewone UART niet heeft.

Hardware “master” schakeling:

Zoals gezegd is er maar één master in een LIN systeem.  Dit houdt hardwarematig gezien in dat de LIN transceiver, naast de interne weerstand, is afgesloten met een extra weerstand van 1 kW. Deze weerstand moet tussen de LIN bus (pin6) en de Vbat (pin7) geplaatst worden. De transceiver wordt direct met de RxD en de TxD pin aan een UART van de microcontroller verbonden. In de onderstaande figuur is dit te zien.

De inhibit pin is via een transistor aangesloten op de microcontroller. De wake pin is aan ground gelegd. Dit houdt in dat de LIN transceiver alleen via een dominant signaal op de LIN bus uit sleep kan komen. Als de transceiver uit sleep gehaald moet worden zal er een dominant wake up signaal op de LIN bus verschijnen, daarna zal de inhibit pin hoog worden. Deze flankverandering genereert een interrupt in de microcontroller waarna de software de enable pin van de transceiver hoog maakt. De overige componenten rond de transceiver dienen voor beveiliging en het filteren van stoorsignalen.

Hardware “slave” schakeling:

Qua hardware verschilt de hardware van een slave t.o.v. een master op de volgende punten:
De inhibit pin is door middel van een inverter aan de spanningstoevoer geschakeld.
De slaveconfiguratie bevat geen afsluitweerstand.
Bij de slave is de wake up pin aangesloten op de connector.

Kit verkopers:
http://www.hitex.co.uk/shop