1. WAT IS CAN?
CAN maakt het mogelijk om verschillende modules met elkaar te laten communiceren via 1 bussysteem. Elke module is gelijkwaardig. We spreken dus niet van master en slave. Een zender zendt een boodschap uit naar alle andere nodes. Men noemt die broadcasten. Elke node in het netwerk kan deze boodschap ontvangen. Elke boodschap heeft een label dat uniek is binnen dat netwerk. Er zijn dus geen adressen, we sturen dus niet naar ‘?n bepaalde module. Elke node neemt de boodschappen die nut hebben op. De andere labels worden gewoon niet bekeken. De buitenspiegelmotor zal dus de motortemperatuur niet uitlezen, de dashboard-controller zal daarentegen wel het datapakket van dat label verder verwerken.
1.1 STANDAARDEN
Er zijn 2 verschillende versies van de CAN-standaard. Deze versies hebben elk hun eigen lengte van hun labels. CAN2.0A heeft een 11 bit identificatie. Bij CAN2.0B dan dit worden uitgebreid tot een 29 bit identificatiecode. De B versie is neerwaarts compatibel met de A-versie.
CAN is ‘?n van de standaarden die gedefinieerd wordt in het EOBD (European On-Board Diagnostics) standaarden. Deze is wettelijk verplicht bij elke benzine auto vanaf 2001 en elke dieselauto vanaf 2004.
Bij zwaardere voertuigen zoals vrachtwagens en bussen maakt men standaard van CAN gebruik voor diagnose. Jammer genoeg gebruikt men hier geen EOBD standaard maar echter van de SAE J1939 standaard. De standaarden zijn incompatibel met elkaar.
http://www.triangledigital.com/man2020f/ch7canauto.htm
1.2 PRIORITEIT
Naast het identificeren van de boodschap dient het label ook om de prioriteit vast te leggen. Dit zorgt ervoor dat er botsingen tussen boodschappen zullen plaatsvinden. CAN werkt op basis van CSMA/CD + AMP, wat staat voor Carrier Sense Multiple Access / Collision Detection + Arbitration on Message Priority. Dit wil zeggen dat de node eerst gaat kijken of de bus in rust is vooraleer hij gaat zenden op de bus. Wanneer de bus inactief is, maar 2 nodes tegelijkertijd willen communiceren wordt er eerst naar het prioriteit gekeken. De node met het laagste prioriteit stopt dan met zenden. Dit zorgt ervoor dat boodschappen met lagere prioriteiten boodschappen met een hoger prioriteit nooit zullen storen.
1.3 OSI-MODEL
We merken dat CANbus gebruik maakt van het OSI-model.
1.3.1 Fysische laag
CAN-bus bestaat algemeen over getwiste draden. Op deze draden worden de signalen verstuurd, ze worden hierop Differentieel verstuurd. Op deze manier is het systeem robuust tegen stoorsignalen. Doordat de draden getwist zijn en fysiek dicht tegen elkaar hangen nemen ze quasi dezelfde storingen op. Er wordt dus op beide draden dezelfde golfvorm gesupponeerd en de storingen worden door de differenti??le transmitter teniet gedaan.
Er zijn twee verschillende versies als je fysiek naar het CANbus systeem kijkt. Namelijk High speed CAN, wat gebruikt wordt in bussen en vrachtwagens en Fault tolerant CAN wat meestal toegepast wordt in personenwagen.
High speed can bevat, om reflecties te vermijden, 2 weerstanden van 120ohm op het einde van de bus. Doordat er slechts 2 weerstanden aanwezig dienen te zijn, zal je op een correct afgesloten canbus 60ohm meten. Bij deze versie zijn de spanningsverschillen belangrijk, en niet hun niveau ten opzichte van de massa.
Bij een verschil van minder dan 0,5V tussen CAN-H en CAN-L spreken we van een recessieve toestand; indien dit verschil groter is dan 0,9V, wordt dit aanzien als een dominante toestand.
1.3.2 Datalinklayer
De Datalink laag wordt onderverdeeld in 2 lagen. Namelijk MAC (Media Access control) en LLC (Logical Link Control).
1.3.2.1 MAC (Media Access control)
Deze laag houdt zich bezig met individuele bits- en bustoegang. CAN werkt met Dominante en recessieve staat zoals we hiervoor besproken hebben. In de Datalinklayer wordt deze omgezet naar 0 en 1. Omdat er gebruik gemaakt wordt van een asynchroon protocol en bovendien gebruik gemaakt wordt van een non return to zero encoding, moet er voor synchronisatie gezorgd worden bij een lange reeks van het zelfde teken. Daartoe wordt gebruik gemaakt van bitstuffing. Dit houdt in dat na 5 opeenvolgende gelijke tekens, altijd een ge??nverteerd teken verzonden wordt. Dit teken maakt geen deel uit van de verzonden bitstroom en wordt er aan de andere kant terug uitgefilterd door de MAC, voordat de boodschap verder ge??nterpreteerd wordt. Bitstuffing is te zien op het scoopbeeld in, gemeten tussen CAN-H en CAN-L.
1.3.2.1.1 Busarbitrage
Een node mag maar beginnen te zenden wanneer de bus niet in gebruik is. Dus wanneer de lijn vrij is. Wanneer er toch 2 nodes op hetzelfde moment beginnen te zenden moet de node met de laagste prioriteit stoppen met zenden en wachten totdat de lijn weer vrij is. De node met het hoogste prioriteit zullen de andere nodes dus van de bus afduwen. Dit zal dus zonder problemen of schade gebeuren.
Wanneer een node een bericht op de bus zal plaatsen zal die steeds beginnen met hun identfier te sturen. Het eerste wat in die identifier zit is het prioriteit van de node.
Hierboven zien we duidelijk dat Node 3 het hoogste prioriteit heeft. De nodes zullen terwijl ze aan het zenden zijn ook luisteren. Zolang beide controllers samen hetzelfde teken verzenden, lezen ze de correcte data terug. Indien de ene nu echter een recessieve staat en de andere een dominante staat probeert te verzenden, zal de controller die probeert de 1 op de bus te zetten, een 0 lezen. Nu weet de recessieve controller dat er een botsing is en dat hij de arbitrage verloren heeft. Hij zal nu stoppen met zenden en wachten op een volgende periode van inactiviteit op de bus om een nieuwe poging te wagen. De dominante controller heeft daar echter niets van gemerkt (hij las immers correct zijn eigen 0 uit) en zal dus gewoon doorgaan met zenden.
1.3.2.1.2 Bittiming
Een asynchroon protocol heeft nood aan een geschikte manier om zowel de zender als de ontvanger te synchroniseren. Hierboven hebben we gezien dat een boodschap altijd begint met een 0. Daar dit op de bus zichtbaar is als de overgang van recessief naar dominant, is dit de eerste flank waar alle ontvangers op synchroniseren. Daar een boodschap maximaal een honderdtal bits lang is, zouden de klokken van de verschillende ontvangers zeer nauwkeurig moeten gelijk lopen. Wil je zeker zijn dat een bit op het einde van de boodschap nog correct gesampled wordt, dan moet je tussendoor ook nog af en toe er synchroniseren. Om dit mogelijk te maken, mag een bit niet de kortste tijdseenheid zijn. Een bit wordt daarom onderverdeeld in 4 verschillende zones. Deze zones zijn onderling niet even lang en worden op hun beurt onderverdeeld in zogenaamde time quanta (tq). Dit is de kleinste tijd die gedefinieerd is in het protocol. Hij wordt in de praktijk door de controller opgewekt met behulp van een kristaloscilator en een PLL.
Een bit bestaat uit 4 segmenten. Het eerste segment, sync genaamd, is altijd 1 tq lang. Een bitovergang moet in dit segment plaatsvinden. Het tweede segment is het propagation segment. Dit zorgt er voor dat een signaal de tijd krijgt om over de bus alle nodes te bereiken, en ook terug te keren naar de zender (elke zender moet zijn eigen data teruglezen, zie hoger)
Vervolgens komen Phase Segment1 (PS1) en Phase Segment2 (PS2). Dit zijn de variabelen die zorgen voor hersynchronisatie. PS1 kan verlengd worden of PS2 kan korter gemaakt worden om de overgang terug in het sync segment te krijgen. Op het einde van PS1 wordt het niveau van de bus gesampled. De Synchronisation Jump Widthis de stapgrootte waarmee PS1 en/of PS2 aangepast worden om de timing terug juist te krijgen. Deze breedte bevat een geheel aantal tq en is meestal 1. Bij onnauwkeurige klokken kan het soms nodig zijn om de breedte groter te maken.
1.3.2.2 LLC
De Logical Link Control sub laag definieert de samenstelling van een volledig busbericht
Er zijn 4 voorkomende frames die voorkomen op de bus. Namelijk:
- Data frame
- Error frame
- Remote frame
- Overload frame
1.3.2.2.1 Data Frame
Dit is het belangrijkste frame van de 4 frames. De andere frames zijn natuurlijk ook belangrijk, want zonder de andere frames kan er geen communicatie plaats vinden.
Elk data frame is opgebouwd uit 7 verschillende velden. Zoals Start of frame, identifier field, rtr field, control field, crc field, ack field en natuurlijk het data field
In dit frame zit de data die we willen verzenden.
1.3.2.2.2 Error Frame
Hierin worden errorcodes verzonden.
1.3.2.2.3 Remote Frame
Via deze frame wordt er extra data aangevraagd bij andere nodes.
1.3.2.2.4 Overload Frame
Dit frame zorgt ervoor dat de Canbus eventjes bezet blijft, zodat de nodes die het bericht ontvangen hebben de tijd hebben om het bericht te verwerken.
2 J1939
2.1 INLEIDING
De J1939 standaard is een uitbreiding op het CAN-protocol en voegt de applicatie laag toe aan de fysische en datalink laag. De standaard definieert het gebruik van CAN bus bij vrachtwagens, bussen maar ook trekkers en aanhangwagens. In J1939 maakt men gebruik van 29 bit identifiers. Het 29 bitveld wordt opgesplitst in 5 delen:
- 3-bit prioriteitsveld. Dit wordt gebruikt om een bepaald prioriteit te geven aan de boodschap
- Gereserveerde bit
- Data pagina bit
- 16 bit parameter groep nummer (PGN). Dit veld definieert de inhoud van de datapakketten. Deze nummers en hun beschrijving staan vermeld in de SAE-subnorm j1939-71
- 8-bit bronadres. Dit veld wordt gebruikt om de bron van de info te beschrijven.
2.2 DATASNELHEDEN
In de j1939 standaard is een baudrate van 250kbaud gedefinieerd. Bij deze snelheid is een maximale segmentlengte van 40m opgegeve. Wat een zeer veilige marge inhoud ten opzichte van de CAN definitie.
2.3 DATAPAKETTEN
De andere velden blijven hun originele functie behouden zoals dit gedefinieerd is in de CAN standaard. In 99% van de berichten wordt gebruik gemaakt van 8 databytes. Enkel in de adres-claiming procedure wordt gebruikt gemaakt van een 3 bytes tellend datapakket.
2.4 ADRESCLAIMING
De belangrijkste nodes zoals de motorcontroller en de centrale computereenheid hebben een standaard adres. Andere nodes, die niet noodzakelijk in elk systeem aanwezig zijn, moeten bij de opstart van het systeem een adres claimen. Hiertoe staat een procedure uitgewerkt in de norm onder hoofdstuk J1939-21.
2.5 TRANSPORT PROTOCOLLEN
Indien men een datapakket van meer dan 8 bytes wil verzenden, voldoen de standaard pakketten van CAN niet meer. Soms moet er echter meer dan 8 byte uitgewisseld worden om bijvoorbeeld configuratiedata te verzenden van de centrale eenheid naar secundaire nodes. J1939 definieert daartoe een transport protocol. Er zijn twee mogelijkheden voor een transport: broadcasten geadresseerd.
2.5.1 Broadcast
Bij een broadcastzet de broncontroller eerst een Broadcast Announce Message PGN op de bus. Vervolgens verzendt hij de data met een minimum tussentijd van 50ms om de ontvangende nodes de tijd te geven om deze data te verwerken.
2.5.2 Peer to peer
Bij een geadresseerde boodschap zal de verzendende node eerst een Request To Send PGN (RTSPGN) verzenden. De ontvangende node, in dit geval dus ‘?n enkele node, zal dan antwoorden met een Clear To Send PGN (CTS-PGN). Ook na elk pakket data moet de zender wachten op een CTS bericht voordat het volgende pakket verzonden wordt.
2.6 INDELING VAN DE IDENTIFIER
2.6.1 Prioriteit
De eerste 3 bits bevatten de prioriteit van het bericht. De mogelijkheden lopen van 0-7, waarbij 0de hoogste prioriteit heeft. Elk bericht heeft een standaard prioriteit, die bij de PGN vermeld staat in de J1939-71 norm.
2.6.2 Res en DP
Res is een gereserveerd bit, mogelijk gebruikt in verdere ontwikkelingen van de standaard. Dit bitdient altijd op 0 te staan. DP wordt wel gebruikt en dient om eventueel een verdubbeling van het aantal PGN’s mogelijk te maken. Sommige fabrikanten gebruiken dit bit reeds.
2.6.3 PGN
Het PGN-veld wordt nog eens verder opgesplitst in 2 x 8 bits, te noemen PDU-Format (PF) en PDU specific (PS). Het protocol voorziet in 3 soorten communicatie. Dit zijn achtereenvolgens:
1. Boodschappen geadresseerd aan een specifieke ontvanger: PF 0-239 en PF 255
2. Broadcastboodschappen: PF 240-254
3. Fabrikantsafhankelijke boodschappen: kunnen gebruik maken van zowel methode 1 als 2.
2.6.3.1 Geadresseerde berichten
Indien het PF-veld lager of gelijk is aan 239, of 255, dan gaat het om een bericht geadresseerd aan een specifieke ontvanger. De eerst byte geldt dan als het PGN en definieert dus de boodschap. De volgende 8 bits, het PS-veld, bevatten het adres van de bestemmeling. (In de norm staan deze PGN’s vermeld met als dummy-doeladres 00).
2.6.3.2 Broadcast berichten
Indien PF in het bereik 240-254 lig, dan behelst het een broadcastbericht. In dat geval wordt het PS-veld gebruikt als uitbreiding van het PGN-veld en bestaat dit berichtdus uit 16 bits, in plaats van 8 bits. Logischerwijs is er dan geen doeladres.
2.6.3.3 Fabrikant specifieke berichten
Niet alle PGN-nummers zijn gedefini??erd in de norm. Een fabrikant mag de overgebleven nummers gebruiken voor eigen toepassingen. Dit gebruik dient onderling tussen de betrokken partijen afgesproken te worden en kan dus verschillen naargelang het type voertuig of de uitvoering. Vanzelfsprekend zijn deze codes eigendom van de producent en worden ze niet vrij gegeven. Deze codes dienen dus zelf bepaald te worden.
Officieel is het de bedoeling dat slechts aan een klein deel van de boodschappen door de fabrikant zelf een code gegeven wordt. In de praktijk kan de codering door de fabrikant oplopen tot meer dan de helft van de codes. Als voornaamste reden wordt opgegeven dat de norm vaak niet de nodige codes bevat om de data onder te catalogiseren of dat de gewenste data te veel verspreid is onder verschillende PGN’s.
2.6.4 Bronadres
De laatste 8 bits van de identifiervormen het bronadres; het adres van de verzendende node.
2.7 PGN
2.7.1 Eigenschappen
Een PGN definieert de inhoud van het datapakket dat na de identifierkomt. Er zijn 2 datapagina’s met elk 240 P2P en 16 x 256 broadcastboodschappen, resulterend in 8672 individuele boodschappen. Zoals hoger vermeld, zijn niet alle boodschappen door de norm vermeld. De norm benoemt slechts een deel van de PGN’s op DP1, waardoor het leeuwendeel van de PGN’s vrij blijft voor eigen definitie door de fabrikant. Een bepaalde PGN mag slechts door ‘?n enkele node verzonden worden om de consistentie in de data te behouden. Hiertoe is men soms genoodzaakt om extra PGN’s te defini??ren, omdat bijvoorbeeld 2 waarden in een PGN opgemeten worden door sensoren aangesloten op 2verschillende controllers.
Het spreekt voor zich dat de verschillende ontwerpers die controllers bouwen voor 1 bussysteem, onderling moeten afspreken wie welke PGN’s gebruikt en met welk doel. Dit zal per project (lees model en/of uitvoering) bepaald worden. Constructeurs beschouwen dit natuurlijk als bedrijfsgeheim en zullen deze info dus ook niet vrijgeven.