Katholieke Hogeschool Brugge-oostende Oostmeers 27, 8000 Brugge Www.khbo.be

Transcript

Katholieke Hogeschool Brugge-Oostende Oostmeers 27, 8000 Brugge www.khbo.be Departement industriële wetenschappen en technologie Campus Oostende – Zeedijk 101, 8400 Oostende Tel. (059) 56 90 00 – fax. (059)56 90 01 Een studie rond canbus systemen op vrachtwagens en hoe deze te manipuleren of onafhankelijk aan te sturen Mei 2009 Deze eindverhandeling was een examen. De tijdens de verdediging geformuleerde opmerkingen werden niet opgenomen De auteur en promotoren geven de toelating deze scriptie voor consultatie beschikbaar te stellen en delen ervan te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting uitdrukkelijk de bron te vermelden bij het aanhalen van resultaten uit deze scriptie. Binnenpromotor Buitenpromotor Auteur ing. P. D'Hulster ing. P. Deckmyn B. Zwaenepoel Woord Vooraf Doordat ik met een zeer specifieke materie bezig was, heb ik zeer veel ervaringen en kennis zelfstandig moeten opzoeken en verwerken. Waar mogelijk kreeg ik wel ondersteuning van iedereen in het bedrijf. Zowel van dhr. Deckmyn als van zijn collega Demeersseman, kreeg ik altijd direct de nodige info over de zaken die mij verder konden helpen. Ook de informatica-afdeling is mij behulpzaam geweest met het vinden van de nodige software-library's die ik nodig had om mijn IC's te programmeren. De 3 avonden bijscholing die ik gevolgd heb, hebben me niet alleen een duidelijk beeld gegeven van mijn project, maar ook een ruimere kadering gegeven op de hele problematiek waar ik tijdens mijn stage mee geconfronteerd werd. Dit werd mogelijk gemaakt door mijn stagebedrijf; de firma Turbo's Hoet Parts en Revisie n.v. Mijn uiterste dank gaat dan ook uit naar ing. Peter Deckmyn (mijn buitenpromotor / stagebegeleider), en zijn collega's ing. Erik Demeersseman (elektro-diesel) en Patrik Decroubele (Preventieadviseur / Milieuraadgever). Ook de andere werknemers van Turbo's Hoet verdienen een dankwoord, voor de leuke momenten, spontane babbels en toffe werksfeer. Verder wens ik ook mijn binnenpromotor, ing. Peter D'Hulster, te bedanken voor zijn inzet, raad en daad. Daarnaast zijn ook de leden van EDAboard.com van harte bedankt, voor hun antwoorden op mijn, vaak complexe, vragen rond elektronica, pcb ontwerp en dergelijke meer. Tot slot verdienen ook mijn familie en vrienden een dankwoord voor de vele uren die zij naar mijn, voor hen volstrekt oninteressante, verhalen geluisterd hebben en voor de steun doorheen dit project. Speciaal wil ik ook mijn vriendin, ir. Annelies Verlee bedanken, niet enkel om te luisteren, maar ook om actief mijn pennenvruchten na te lezen. Brecht Zwaenepoel Samenvatting Moderne vrachtwagens worden steeds meer elektronisch bediend. Waar vroeger voor elke functie een eigen elektrisch circuit aanwezig was, is dit nu vervangen door enkele microcontrollerschakelingen, die onderling met elkaar verbonden zijn via een bussysteem. Indien componenten afzonderlijk getest moeten worden, stelt zich een probleem voor de onafhankelijke garagisten. Deze kunnen immers niet beschikken over de ondersteuning van de betreffende fabrikanten. Eén van de grootste problemen is het testen van een elektronisch geregelde motor op een testbank. Daar deze motoren voor een deel afhankelijk zijn van data die over het netwerk geleverd wordt (o.a. de gaspedaalstand), dient dit netwerk ook aanwezig te zijn bij het proefdraaien. In vrachtwagens is dit netwerk standaard een Controller Area Network. Deze netwerkstandaard wordt beschreven in de SAE J1939 norm. Deze norm bestaat uit vier belangrijke subnormen, die elk een deel van het OSI-model beschrijven. Dit model begint de fysische laag, die de elektrische en mechanische kenmerken beschrijft en over de data link laag waar de opbouw en timing van de boodschappen gedefinieerd wordt. In de SAE J1939 norm worden een aantal OSI-lagen samengenomen om de transportprotocollen en adresclaiming te bepalen. Tot slot wordt duiding gegeven bij de applicatie laag, die betekenis geeft aan de verschillende boodschappen en hun bijhorende data. Na het doorgronden van de SAE 1939 norm wordt in dit eindwerk een interface gezocht om de data op het bussysteem zichtbaar te maken. Aan de hand van de norm en de interface wordt bepaald welke boodschappen noodzakelijk zijn voor de werking van de motorcontroller. Hiertoe werden een aantal testen uitgevoerd op zowel een vrachtwagen van Volvo als van Scania. Aan de hand van deze testen is een lijst opgesteld met de noodzakelijke data die de motorcontroller moet aangeboden krijgen om zelfstandig zijn werk te kunnen doen. Wegens tijdsgebrek is het microcontrollerprogramma niet af. Wel worden een aantal werkende tussenoplossingen weergegeven. Dit werk bevat bovendien alle nodige gegevens om een vlotte finalisatie van een microcontrollerprogramma mogelijk te maken. Inhoudsopgave Woord vooraf........................................................................................................................................ Samenvatting......................................................................................................................................... Inhoudsopgave....................................................................................................................................6 Verklarende woordenlijst..................................................................................................................9 Inleiding.............................................................................................................................................16 1 Situering probleem........................................................................................................................17 1.1 Een stukje geschiedenis:..........................................................................................................17 1.2 Probleemstelling......................................................................................................................18 1.3 Toekomst / Uitbreiding............................................................................................................19 2 Inleiding in J1708 standaard........................................................................................................20 2.1 J1708........................................................................................................................................20 2.1.1 Inleiding...........................................................................................................................20 2.1.2 Protocol............................................................................................................................21 2.1.3 J1708 busbelasting...........................................................................................................21 2.2 J1587........................................................................................................................................23 2.2.1 Inleiding:..........................................................................................................................23 2.2.2 Opbouw van een boodschap............................................................................................23 3 De CAN-bus...................................................................................................................................24 3.1 Inleiding...................................................................................................................................24 3.2 Geschiedenis............................................................................................................................24 3.3 Gebruik....................................................................................................................................24 3.4 Wat is CAN..............................................................................................................................25 3.5 Het osi-model van de can-bus..................................................................................................27 3.5.1 Fysische laag....................................................................................................................27 3.5.2 Datalinklayer....................................................................................................................29 3.5.2.1 MAC (Media Acces Control)...................................................................................29 3.5.2.2 LLC..........................................................................................................................31 3.6 Besluit......................................................................................................................................33 4 J1939...............................................................................................................................................34 4.1 Inleiding...................................................................................................................................34 4.2 Datasnelheden..........................................................................................................................34 4.3 Datapakketten..........................................................................................................................34 4.4 Adres claiming.........................................................................................................................34 4.5 Transport protocollen...............................................................................................................34 4.5.1 Broadcast..........................................................................................................................35 4.5.2 Peer to peer.......................................................................................................................35 4.6 Indeling van de identifier.........................................................................................................35 4.6.1 Prioriteit...........................................................................................................................35 4.6.2 Res en DP.........................................................................................................................35 4.6.3 PGN..................................................................................................................................35 4.6.3.1 Geadresseerde berichten...........................................................................................35 4.6.3.2 Broadcast berichten..................................................................................................36 4.6.3.3 Fabrikant specifieke berichten..................................................................................36 4.6.4 Bronadres.........................................................................................................................36 4.7 PGN.........................................................................................................................................36 4.7.1 Eigenschappen.................................................................................................................36 4.7.2 Voorbeeld PGN................................................................................................................37 4.7.3 Voorbeeld SPN................................................................................................................38 6 5. Metingen........................................................................................................................................40 5.1 Inleiding...................................................................................................................................40 5.2 Metingen Volvo FH.................................................................................................................40 5.3 Vergelijking met nieuwe systemen..........................................................................................42 5.4 Scania R-serie..........................................................................................................................45 5.4.1 Inleiding...........................................................................................................................45 5.4.2 Metingen..........................................................................................................................45 5.4.3 Resultaten.........................................................................................................................48 6 Elektronica.....................................................................................................................................53 6.1 Inleiding...................................................................................................................................53 6.2 Commerciële oplossingen:.......................................................................................................53 6.3 Alternatieven:...........................................................................................................................54 6.4 Ic's............................................................................................................................................54 6.5.1 MCP2515.........................................................................................................................55 6.5.1.1 Inleiding....................................................................................................................55 6.5.1.2 Onderdelen...............................................................................................................55 6.5.1.3 Registers...................................................................................................................57 6.5.1.4 Verzenden van boodschappen..................................................................................57 6.5.1.5 Ontvangen van boodschappen..................................................................................59 6.5.1.6 Interupts....................................................................................................................60 6.5.1.7 Reset:........................................................................................................................61 6.5.1.8 Operationele modes..................................................................................................61 6.5.1.9 Oscilator...................................................................................................................61 6.5.1.10 SPI-interface...........................................................................................................61 6.5.2 Mcp2551..........................................................................................................................62 6.5.3 65HVD21.........................................................................................................................63 6.5.4 PIC18F2550.....................................................................................................................64 6.6 CAN-explorer..........................................................................................................................67 6.7 Eigen ontwerpen......................................................................................................................68 6.7.1 Inleiding...........................................................................................................................68 6.7.2 USB 2 CAN.....................................................................................................................68 6.7.3 CANtroller.......................................................................................................................71 6.8 PICkit Serial Analyzer.............................................................................................................72 6.9 Varia.........................................................................................................................................73 7 Software...........................................................................................................................................74 7.1 Inleiding...................................................................................................................................74 7.2 Commerciële oplossingen........................................................................................................74 7.3 Alternatieven ...........................................................................................................................74 7.4 Can-explorer............................................................................................................................75 7.4.1 Werkwijze........................................................................................................................75 7.4.2 Bewerkingen....................................................................................................................78 7.4.2.1 Identifier...................................................................................................................78 7.4.2.2 Data .........................................................................................................................79 7.4.2.3 Tijden........................................................................................................................79 7.5 MCP2515.................................................................................................................................80 7.5.1 Configuratie.....................................................................................................................80 7.5.2 Commando's.....................................................................................................................81 7.5.3 Opmerkingen....................................................................................................................81 7.6 USB..........................................................................................................................................82 7.6.1 Eerste testen.....................................................................................................................82 7 7.6.2 PICKit Serial Analyzer....................................................................................................82 7.7 DataTap....................................................................................................................................83 7.7.1 Inleiding...........................................................................................................................83 7.7.2 Programmacode achter het datatap scherm......................................................................84 7.7.3 Programmacode in de CAN-module................................................................................85 7.8 CANtroller...............................................................................................................................89 7.8.1 Inleiding...........................................................................................................................89 7.8.2 Code.................................................................................................................................89 7.9 Besluit......................................................................................................................................93 Algemeen Besluit...............................................................................................................................94 Bijlage.................................................................................................................................................95 1 Schema's Volvo...............................................................................................................................95 2 Schema's Scania...............................................................................................................................99 Literatuurlijst....................................................................................................................................112 8 Verklarende woordenlijst AMP Arbitration on Message Priority Beslissingsmethode om te bepalen welke boodschap als eerste op de bus komt. Deze beslissing wordt gebaseerd op de prioriteit van het bericht. Zie ook CSMA/CD. API Application Programming Interface Een set met routines, datatypes, protocollen samengevat in een bibliotheek om een programma te kunnen schrijven. Application Layer Zevende en hoogste laag van het OSI-model. Dit is de eigenlijke toepassing van het model en geeft betekenis aan de verzonden data. Zie ook OSI. ASIC Application Specific Integrated Circuit IC dat speciaal vervaardigd is om een specifieke taak uit te voeren. Dit in tegenstelling tot programmeerbare bouwstenen die voor zeer veel verschillende taken kunnen ingezet worden. Baudrate Dit is het aantal veranderingen per seconde van discrete symbolen op een datatransmissielijn. Dit is niet hetzelfde, maar is wel gerelateerd aan de bruto bitrate (in bps). De eenheid van baudrate is de Baud, genoemd naar Emile Baudot, een pionier in het telegrafietijdperk. Bitstuffing Methode waarbij er extra, niet coderende bits in de datastroom tussengevoegd worden. Vaak gebruikt om bij een NRZ-encoding voldoende flanken te garanderen zodat de ontvanger kan synchroniseren met de zender. In dat geval wordt er na een bepaald aantal gelijke tekens, een extra tegengesteld teken tussengevoegd. Bij ontvangst zal dit teken er automatisch tussenuit gehaald worden, daar dit geen informatie codeert. BMS Brake Management System Controllermodule die zich op de remmen richt. Hier zit onder andere de ABS. bps Bit Per Second Eenheid die het aantal bit per seconde aanduidt. Zie ook Bps, Baud. Bps Byte Per Second Eenheid die het aantal byte dat per seconde verzonden wordt aanduid. Zie ook bps, Baud. Broadcast Methode om een boodschap naar alle ontvangers op een netwerk te verzenden. In plaats van een bericht naar elke deelnemer afzonderlijk te adresseren, wordt een broadcast gebruikt. CAN Controller Area Network Serieel protocol om data tussen verschillende controllers uit te wisselen. Ontworpen met het oog op het gebruik in voertuigen. Gespecificeerd in ISO11898. COO Coordinator Naam van de VCU bij Scania . CRC Cyclic Redundancy Check Controlesom op fouten in opgeslagen of verzonden data. Met behulp van een CRC-code kan gecontroleerd worden of de data geen fouten bevat. 9 CSMA/CD Carrier Sense Multiple Access with Collision Detection Bustoegangsmethode die de zenders verplicht om te wachten tot het medium een zekere tijd vrij is, voor deze zelf een bericht mag proberen te verzenden. Tijdens het verzenden dient een node actief te luisteren om botsingen van data te detecteren. Een botsing kan ontstaan als twee zenders na een tijd van inactiviteit op de bus gelijktijdig beginnen te zenden. Zie ook AMP. Data Link Layer Tweede laag van het OSI-model. Bestaat uit de MAC en LLC sublagen. Zie ook OSI, MAC, LLC. DLC Data Length Code Veld in een CAN-frame dat specifieert hoeveel databytes er in het bericht aanwezig zijn. DLL Dynamic Link Library Een bibliotheek met een aantal softwarefuncties die kunnen aangeroepen worden uit een programma. De bestandsnaam eindigt op .DLL. ECU Engine Controller Unit Geïntegreerd elektronisch regelorgaan dat ontworpen is om alle elektrische functies rond een motor te bedienen, vb. de inspuithoeveelheid, inspuittiming, bediening van de startmotor,... . Ook zijn alle sensoren die rechtstreeks op de motor geplaatst zijn op deze unit aangesloten. Deze controller kan zelfstandig werken of afhankelijk zijn van data afkomstig van andere ECU’s. ECU Electronic Controller Unit Elektronisch systeem dat een bepaalde taak bestuurt in een voertuig. Deze systemen bieden meestal extra functionaliteit ten opzichte van klassiek bedrade elektrische systemen. Een ECU kan voor veel verschillende taken ingezet worden, gaande van motormanagement tot het bedienen van de elektrische achterruitverwarming. EOBDEuropean OnBoard Diagnostics Diagnoseprotocol dat wettelijk verplicht op nieuwe wagens moet geïnstalleerd zijn. Dit maakt het mogelijk om ook milieugerelateerde diagnose uit te voeren tussen de verplichte autokeuring. Flexray Opvolger van de CAN-bus. Deze standaard is ontworpen om CAN in de toekomst te vervangen. Naast de hogere snelheid (tot 20Mbps) biedt deze techniek ook een deterministisch gedrag. De sterkhouders achter deze nieuwe standaard zijn BMW, Volkswagen, Daimler AG, GM, Robert Bosch GmbH, NXP Semiconductors en Freescale. FMI Failure Mode Identification Foutcode. Op het display of op de voertuigdiagnosestekker worden fouten aangegeven d.m.v. hun FMI-nummer. Het opzoeken van hun betekenis in handboeken is noodzakelijk. FMS Fleet Management System Controller die data van het voertuig naar buiten brengt via een CAN-bus. Deze controller fungeert als een firewall en voorkomt dat externe systemen de interne communicatie in het voertuig kunnen storen. Deze aansluiting wordt vaak gebruikt om gegevens over afgelegde weg, rijsnelheid, enz. te koppelen aan een radiozender. Hiermee kan het hoofdkantoor volgen wat er met de vrachtwagen gebeurt. FTCAN Fault Tolerant Controller Area Network Implementatievorm van CAN die een breed scala aan busfouten tolereert, onder andere kortsluiting tussen CANH en CANL. ISO 11898-3. 10 Gateway Speciale netwerkcontroller die twee netwerken die incompatibel zijn met elkaar koppelt. Ook bepaalt deze controller welke berichten van het ene netwerk beschikbaar zijn op een ander netwerk. Hij fungeert dus ook als firewall. GMS Gear Management System Controller die de transmissie bestuurt. Green CAN Can-bus op Scania voertuigen die alle comfortsystemen met elkaar verbindt. Deze bus is niet kritisch voor de correcte werking van een voertuig. Zie ook Red CAN, Yellow CAN HSCAN High Speed Controller Area Network Implementatie van CAN die hogere snelheden toelaat dan FTCAN, echter ten koste van de bescherming tegen een aantal busfouten. Wordt hoofdzakelijk gebruikt in vrachtwagen- en offroad toepassingen. ISO 11898-2. I²C Inter IC Seriële verbinding om digitale logica met elkaar te verbinden. Deze verbinding heeft voldoende aan 2 draden om data uit te wisselen. Zie ook SPI. IC Integrated Circuit Elektronische schakeling op microscopische schaal uitgevoerd op het oppervlak van een siliciumkristal. Deze bouwstenen van de elektronica bestaan uit miljoenen transistoren die onderling geschakeld zijn op een microscopisch klein oppervlak. ISO 11783 Landbouwversie van CAN (ISO-bus). ISO 11898 CAN-bus basis standaard. Zie ook CAN. ISO 11992 CAN-bus specifiek aangepast voor truck-trailer communicatie. Is gebaseerd op SAE J1939 en FTCAN. ISO 9141 Eerste versie van OBD uit 1989. ISOBUS Landbouwversie van CAN. Zie ook ISO11783. K-lijn Onderdeel van de OBD-stekker. Eerste diagnoselijn. LIN Local Interconnect Network Eenvoudig en goedkoop serieel netwerk. Dit wordt hoofdzakelijk gebruikt als sub-netwerk van CAN. Een toepassingsvoorbeeld is de verbinding binnen een deurpaneel: bediening van de elektrische ramen, centrale vergrendeling, spiegelafstelling en spiegelverwarming. LLC Logical Link Layer Sublaag van de Data Link Layer. Deze laag is verantwoordelijk voor multiplexing en doorstroming van de verschillende pakketten data. Zie ook OSI, Data Link Layer. LSB Least Significant Bit Dit is het bit met de laagste waarde; in de klassieke schrijfwijze het meest rechtse bit van een byte. Zie ook MSB. MAB Message Assembly Buffer De buffer in de MCP2515 waar berichten samengesteld worden voor ze verzonden worden. Hier wordt de inhoud van de ID en datavelden samengesteld, worden stuffbits toegevoegd en de CRC berekend. 11 MAC Media Access Control Sublaag van de Data Link Layer. Deze laag is verantwoordelijk voor bustoegang en adressering. Zie ook OSI, Data Link Layer. MID Message Identification Code die de herkomst en het soort van data aanduidt. MOSTMedia Oriented Systems Transport Dit is een op glasvezels gebaseerde bustechniek die het mogelijk maakt om grotere datastromen te versturen. Deze techniek is hoofdzakelijk bedoeld om mediasystemen in voertuigen te verbinden (achteruitrijcamera, entertainment,...). MSB Most Significant Bit Dit is het bit met de hoogste waarde; in de klassieke schrijfwijze het meest linkse bit van een byte. Zie ook LSB. Network Layer Derde laag van het OSI-model. Deze regelt het routen van verschillende pakketten tussen twee eindpunten. Zie ook OSI. NMEA 2000 Protocol gebruikt om elektronische toestellen op zee via een bus met elkaar te laten communiceren. Gebaseerd op J1939. NRZ Non Return to Zero Lijn encoding algoritme bestaande uit twee discrete toestanden, waarbij de ene een logische 0 voorstelt en de andere een logische 1. OSI Open Systems Interconnection reference model Dit is een abstractie van een gelaagd communicatieprotocol. Dit model bestaat uit 7 lagen; namelijk: 1) Physical layer 2) Data Link Layer 3) Network Layer 4) Transport Layer 5) Session layer 6) Presentation layer 7) Application Layer Niet elk netwerkprotocol valt in dit model in te passen en niet elk protocol dient alle lagen te bezitten. PCB Printed Circuit Board Een plaat, meestal van een met glasvezel versterkte kunststof (FR4) die als drager dient voor elektronische componenten. Op het oppervlak zijn koperbanen aangebracht die de componenten met elkaar verbinden en zo een elektrische schakeling vormen. Ook wel printplaat genoemd. PDU Protocol Data Unit Dit is de naam die aan een bericht gegeven wordt in SAE J1939. PF PDU Format Eerste byte van een PGN. Hiermee kan bepaald worden of de boodschap een broadcast, een propretairy of een geadresseerd bericht is. Zie ook PGN, PS. PGN Parameter Group Number Identificatie van een groep parameters in de datavelden. Bestaat uit PF en PS. Zie ook PS, PF. 12 Physical Layer Onderste laag van het OSI-model. Deze regelt de fysieke eigenschappen van de bus. Zie ook OSI. PIC Peripheral Interface Controller Microcontrollerfamilie van Microchip. Deze familie van controllers is zeer populair onder ontwikkelaars en hobbyisten omwille van de uitgebreide set aan ontwikkeltools, beschikbaar tegen een zeer lage prijs of zelfs gratis. Deze microcontroller wordt ook zeer frequent besproken op internetfora, waar zeer grote gebruikerscommunities aanwezig zijn die met veel plezier hulp en ondersteuning bieden. PID Parameter Identification Code die de parameter specifieert. De betekenis van deze codes kan men opzoeken in een datasheet. PKSA Pic Kit Serial Annalyzer (Ontwikkel)tool van Microchip, gebaseerd op een PIC18F2550 die een verbinding gateway vormt tussen USB en een aantal seriële protocollen. Ondersteunde protocollen zijn SPI, I²C master, I²C slave, USART en LIN. PLL Phase Locked Loop Systeem om een kloksignaal af te leiden uit een andere klok. Een PLL produceert een foutsignaal, waarmee een klokgenerator kan bijgeregeld worden om zowel in fase als in frequentie gelijk te lopen met een referentieklok. Presentation Layer De zesde laag van het OSI-model. Hier wordt de data verwerkt om gebruikt te worden door de applicatie. Zie ook OSI. Prop Propagation Segment Dit is het tweede segment van een CAN-bittijd. Dit segment voorziet in tijd voor het signaal om zich van de zender tot de verst gelegen ontvanger te verplaatsten. PS PDU Specifiek Verdere specificatie van een PGN, indien het PF-veld aangeeft dat het een broadcast is. Indien PF aangeeft dat het een geadresseerd bericht is, bevat dit veld het adres van de bestemming. Zie ook PGN. PS1/PS2 Phase Segment 1 / 2 Dit zijn het derde en vierde segment van een bittijd op de CAN-bus. Op de overgang van PS1 naar PS2 wordt het niveau op de bus gesampled. Red CAN De CAN-bus in Scania vrachtwagens die alle kritische data bevat. ECU, COO, BMS, GMS en gelijkwaardigen zijn op deze bus aangesloten. Zie ook Green CAN, Yellow CAN SAE Society of Automotive Engineers Internationale organisatie die zich richt op het ontwikkelen van standaarden voor professionals in de automobielsector, de lucht- en scheepvaart. SAE J1587 Diagnoseprotocol aanwezig op oudere voertuigen. Dit protocol kan verschillende fysische implementaties hebben. Meestal is dit gebaseerd op SAE J1708. SAE J1708 Specificatie van de Physical en DLL laag voor een verbinding tussen twee controllers in een voertuig. Is gebaseerd op RS-485 SAE J1922 Eerste versie van een datalink in een multicontroller systeem. Werd gebruikt om de ABScontroller te laten ingrijpen op het motormanagement. SAE J1939 13 Protocol dat gebruik maakt van het CAN low level protocol. In deze standaard zijn onder andere de snelheid van de data en de betekenis van elk byte gedefinieerd. Session Layer Vijfde laag van het OSI-model. Met deze laag kan een semi-permanente verbinding opgezet worden tussen twee systemen. Indien de verbinding wegvalt zal deze laag proberen een nieuwe verbinding tot stand te brengen. Zie ook OSI. SJW Synchronization Jump Width Aantal TQ waarmee PS1 of PS2 kunnen aangepast worden indien de bitovergang niet meer in het SYNC-segment valt. Meestal is dit ingesteld op 1 TQ. SMS Suspension Management System Controller die de ophanging regelt. 14 SPI Serial Peripheral Interface Seriële verbinding, ontworpen om op een eenvoudige manier digitale IC's met elkaar te verbinden. Deze bus bestaat minimaal uit drie verbindingen, meestal uit 4. Meestal blijft deze bus op de zelfde PCB. Zie ook I²C. SPN Suspect Parameter Number Identificatie van een individuele parameter SYNC Synchronization Segment Het eerste segment van een CAN-bittijd. Dit is altijd 1 TQ lang. De overgang van laag naar hoog op de bus moet in dit tijdsinterval plaats vinden. Dit wordt aangepast door PS1 of PS2 te verlengen en/of te verkorten. Zie ook PS1/2, Prop. TQ Time Quantum Kleinste tijdseenheid van een CAN-bus. Een bit bestaat uit meerdere segmenten, die op hun beurt weer bestaan uit time quanta. Tranceiver Schakeling (meestal een IC) met zowel een transmitter (zender) en een receiver (ontvanger) aan boord. Transport Layer Vierde laag in het OSI-model. Deze laag splitst de data op in afzonderlijk te verzenden pakketten aan de kant van de zender en zal deze pakketten aan de ontvangerszijde terug samenstellen in de juiste volgorde. Zie ook OSI. USART, UART Universal Synchronous Asynchronous Receiver/Transmitter Digitale bouwsteen die parallelle data omzet in een seriële bitstroom. VCU Vehicle Controller Unit Centrale controller waar de hoofdfuncties van een voertuig geregeld en gecontroleerd worden. Na de ECU is dit de meest voorkomende controllerunit in voertuigen (1 per voertuig). Yellow CAN CAN-bus op een Scania voertuig die alle secundaire systemen met elkaar verbindt. Op deze bus zijn onder andere het instrumentenbord, lichten, deurvergrendeling,... te vinden. Zie ook Red CAN, Green CAN. 15 Inleiding Dit eindwerk is geschreven in opdracht van de firma Turbo's Hoet. Het vormt een uitbreiding op het eindwerk van D'hondt Dieter (2008). De voorvermelde thesis omhelsde de regeling van dieselmotoren . Meer concreet handeld deze thesis over het aanpassen van de stuurdoos van een elektronisch geregelde motoren, om deze geschikt te maken als stationaire motor. Voorliggende thesis vormt een uitbreiding van bovenvermelde thesis aangezien hier verder ingegaan wordt op de nieuwe generatie motoren, die digitaal communiceren met de andere componenten in het voertuig. De motoren die het voorwerp zijn van zowel voorgaande als voorliggende thesis zijn afkomstig uit wrakken van geaccidenteerde vrachtwagens, en krijgen een tweede leven als aandrijving in een stroomgroep. De motoren die in voorgaande tekst gebruikt worden, zijn echter motoren van de 'oude' generatie die worden gestuurd door middel van een enkele stuurdoos. Deze bevat alle elektronica om de motor op een correcte manier te laten draaien. Deze motoren worden helaas schaarser, nu de elektronica steeds verder een opmars neemt in de nieuwe vrachtwagens. Behalve de motorstuurdoos, bevatten moderne vrachtwagens ook nog verschillende elektronische stuurdozen in de cabine, op de versnellingsbak en in het dashboard. Deze elektronische modules communiceren over een seriële verbinding, namelijk de Can-bus. Bij afwezigheid of defect van één of meerdere van deze modules, weigeren de andere soms ook dienst. Dit heeft als gevolg dat bijna het hele elektronische systeem van de vrachtwagen dient gebruikt te worden om een motor te laten draaien op de testbank, of om deze te gebruiken als aandrijving in een generatorset. Deze thesis tracht voornoemd ingewikkeld kluwen aan draden en stuurdozen te analyseren, en waar mogelijk te vereenvoudigen. Er wordt getracht om enkel de motorcontroller en een interface-print over te houden, die het mogelijk maakt om snel en met zo weinig mogelijk noodzakelijk materiaal, een motor te laten draaien en een aansturing mogelijk te maken. Hiertoe zal in de eerste plaats een diepgaande studie gemaakt worden over de werking en de communicatie van de verschillende controllers in het systeem. Weten welke functies uitgevoerd worden door welke module, is een essentieel onderdeel van dit werk. Vervolgens zal het noodzakelijk zijn om de signalen die toekomen op de motorstuurdoos, en die niet afkomstig zijn van sensoren op of rond de motor, te bestuderen, en hier voor vervangende signalen aan te bieden en/of in een interface te voorzien. Verder zal de Can-communicatie onderzocht worden. Een van de boodschappen binnen deze communicatie is het gas-signaal, want in de originele configuratie is het gaspedaal aangesloten op de cabine-controller. Eenmaal we de functie van deze signalen kennen, kunnen we met een Cantranceiver zelf deze boodschappen op de bus plaatsen en zo de motorstuurdoos correct laten functioneren. Indien mogelijk, en bij uitbreiding, is het de bedoeling om ook elektronische transmissies aan te sturen. Om te beginnen zal er gewerkt worden op de motor van de Volvo FH en FM-series. Daar dit een veel voorkomende motor is, is dit een interessant vertrekpunt, waar snel een economische omzet mee te halen is. De thesis kan dan verder het vertrekpunt worden voor gelijkaardige aanpassingen aan andere types van motoren. 16 1 Situering probleem Het probleem waar de onafhankelijke garagist mee geconfronteerd wordt, is de veelheid aan kabels, aansluitingen en elektronische modules in een moderne vrachtwagen. Indien deze motoren uitgebouwd worden en dienen te draaien op een testbank, moet ook alle aanwezige elektronica overgebracht worden naar de testbank. Deze volledige overbrenging vraagt veel ruimte en tijd. Door de elektronica onder te brengen in één handige module om zo het gehele netwerk te symuleren kan veel tijd en ruimte bespaard worden. Bij het gebruik als generatorset, moeten ook alle stuurdozen meegeleverd worden, en verwerkt worden in het eindproduct. Dit is op z'n minst een erg omslachtige, en weinig flexibele methode. 1.1 Een stukje geschiedenis: In de eerste generatie motoren was de regeling simpel; de motor bestond uit een hendel, waarmee de gasklep op de carburator of de dieselpomp geregeld werd. Na enige tijd voldeden deze eenvoudige motoren niet meer op verschillende vlakken (o.a. …). Men begon elektronica aan te wenden om de inspuitingen te regelen. Ook de eerste generatie elektrisch gestuurde motoren hadden nog een eenvoudig aansluitschema; een krukassensor en enkele verstuivers waren aangesloten op de stuurdoos. Eventueel werden (en worden) er nog extra sensoren zoals luchtdebiet, temperatuur, klopsensor, turbodruk enzovoort aangesloten om een betere regeling mogelijk te maken. Het gaspedaal wordt bij deze motoren niet meer mechanisch overgebracht, maar via een potentiometer uitgelezen, en gedigitaliseerd in een controller. Het is nu een microprocessor die bepaalt hoe lang en wanneer welke verstuiver diesel inspuit in welke cilinder. Hierdoor is een veel nauwkeurigere regeling van emissies en vermogen mogelijk. Stillaan begon men met veel meer parameters rekening te houden dan enkel met de stand van het gaspedaal om de inspuithoeveelheid te bepalen. Deze exponentieel toegenomen intelligentie in een motor maakte het noodzakelijk om deze parameters bij het testen, programmeren of voor diagnose doeleinden uit te lezen. Om dit mogelijk te maken, brachten de fabrikanten een diagnosesignaal naar buiten dat digitaal uitgelezen kan worden. Al snel werd duidelijk dat deze lijn niet enkel voor diagnose gebruikt kon worden, maar ook voor interne communicatie in het voertuig. In het begin kwam elke fabrikant met zijn eigen systeem naar voor, maar dit bleek praktisch niet houdbaar. Enige standaardisatie in de communicatieprotocollen drong zich op. Het resultaat is terug te vinden in de combinatie van SAE-standaarden J1587/J1708. Dit communicatieprotocol is gebaseerd op RS-485 en maakte het mogelijk om de intelligentie in het voertuig nog op te drijven en (vracht)wagens nog met talloze extra mogelijkheden uit te rusten. Nog eerder dan de J1587 was de J1922 standaard, die ook samen met J1708 een geheel vormt. Dit protocol was bedoeld als communicatie tussen de motor en het ABS-systeem, om het motorvermogen te kunnen begrenzen bij het inwerking treden van de ABS. Door verdere ontwikkeling, gekoppeld met de wens om nog meer data digitaal uit te wisselen over een digitale verbinding, bleek ook de J1708 niet meer te volstaan. CAN werd ontworpen. Dit nieuwe protocol maakte een echte busstructuur mogelijk. Het kan bovendien een groot aantal node's aan. Er zijn nu zo veel modules in een vrachtwagen aanwezig, dat het eenvoudiger is om het gaspedaal te digitaliseren in de dichtstbij gelegen controller, en niet meer in de motormodule. De analoge kabels van het gaspedaal gaan nu eerst naar een centrale body module waar het signaal 17 gedigitaliseerd wordt. Het signaal wordt dan via CAN of RS-484 overgeseind naar de EEC. Dit systeem maakt enerzijds de bedrading eenvoudiger, doordat er niet meer voor elke functie een aparte kabel hoeft getrokken te worden; anderzijds is hierdoor een exponentiële groei in het aantal (veiligheid)functies in het voertuig mogelijk. 1.2 Probleemstelling Er stelt zich nu echter het probleem dat een motor die van al deze nieuwe technologie voorzien is, niet meer eenvoudig op de testbank te plaatsen is. De motorcontroller is afhankelijk van het voertuignetwerk voor zijn noodzakelijke gegevens, en kan zonder dit netwerk dus niet draaien. Om dit systeem werkend te krijgen, is er dus een volledige testomgeving nodig die de noodzakelijke functies van het voertuig simuleert. Dit kan door de elektronica uit de vrachtwagen uit te bouwen, en in een aparte stuurkast te plaatsen die naast de testbank geplaatst kan worden. Echter, dit moet voor elke nieuw type vrachtwagen afzonderlijk gedaan worden, en is dus zeer omslachtig. Het zou wenselijk zijn, indien het plaatsen van het voertuignetwerk op een testbank eenvoudiger en multifunctioneler (voor de verschillende stuurkasten op een gelijkaardige manier) kon verlopen. De complexiteit van de kabelboom en de gebruikte communicatieprotocollen maken het 'ontmantelen' van dit systeem echter niet eenvoudig. In onderstaand blokschema zien we de situatie zoals bij een Volvo FH systeem eenvoudig voorgesteld. Motor Dashboard Controller + onboard diagnose RS-485 J1708 Can J1939 Aansluitingen motor Meerdraads verbinding Motor ECU Voertuig ECU Gaspedaal Sensoren Afbeelding 1: Origineel blokschema 18 Bovenstaand schema (Afbeelding 1) zouden we graag vereenvoudigd zien naar een eenvoudiger te bedraden systeem, met een losse aansturing die niet afhankelijk is van de aanwezigheid en correcte werking van subsystemen. De ideale oplossing wordt verduidelijkt in volgende blokschema: Motor Motor ECU Digitale stuurschakeling Can J1708 Sensoren Can J1939 Aansluitingen motor Meerdraads verbinding USB PC (Optioneel) Afbeelding 2: Vereenvoudigd blokschema De digitale stuurschakeling dient de taken van de voertuig ECU en de dashboard-controller over te nemen en moet deze van een interface voorzien voor communicatie met de gebruiker, sensoren en eventueel een pc. Deze stuurschakeling zal dus minstens een can-tranceiver moeten hebben; eventueel ook enkele analoog-digitaal omzetters voor extra sensoren. Enkele druktoetsen en een display zullen instaan voor de communicatie met de gebruiker. 1.3 Toekomst / Uitbreiding Indien er nog tijd over is, zou een verbinding met de pc een welkome uitbreiding zijn. Deze kan gebruikt worden in een testomgeving, om de schakeling op afstand te monitoren of in te stellen. Naast de Canbus zijn ook andere netwerken in opmars. Concreet gaat het hier over Most, Flexray en byteflight. Eventueel zou ook FireWire hier gebruikt kunnen worden. Deze protocollen zijn hoofdzakelijk een verbetering op het vlak van bandbreedte, met het oog op de toegenomen multimediatoepassingen in voertuigen. Deze protocollen worden op dit ogenblik nog niet gebruikt in vrachtwagens (enkel in personenwagens), maar de mogelijkheid bestaat dat deze binnen enkele jaren ook in de industriële voertuigen hun ingang zullen vinden. 19 2 Inleiding in J1708 standaard Door de complexiteit van de steeds meer toegepaste controllers was het wenselijk om een digitaal communicatiesysteem te ontwerpen voor het gebruik in de automobielindustrie. In het begin had elke fabrikant zijn eigen systeem, maar dit bleek niet houdbaar (zie vorig hoofdstuk). Om de kosten te drukken en om uitwisselbaarheid van componenten te garanderen, werd er een standaard in het leven geroepen. Een eerste communicatieprotocol dat we aantreffen op de motorcontroller is SAE J1587/J1708. Dit zijn in principe 2 verschillende standaarden, maar de J1587 beschrijft de applicatielaag; J1708 de fysysche en de datalinklaag. 2.1 J1708 2.1.1 Inleiding De J1708 standaard is een aanpassing van de bestaande RS-485 norm. RS-485 is een differentiëel protocol dat meerdere masters op 1 bus toelaat zodat eender welke node data op de bus kan plaatsen (zie figuur1). De belangrijkste punten in de standaard: • • • • • • • differentiele interface busstructuur 1 enkele 5V voedingsspanning nodig -7 tot + 12V common mode spanning toegelaten tot 32 node's op 1 bus maximum 10Mbps bij 12m buslengte maximum 120m kabellengte bij 100kbps Afbeelding 1: Overzicht RS-485 systeem In de J1708 standaard worden deze eigenschappen enger gesteld dan in RS-485, omwille van de hoge eisen gesteld aan de betrouwbaarheid. Zo wordt de kabellengte beperkt tot 40m bij 9600bps en het aantal nodes tot 20. De kabel dient een getwiste draad te zijn met minimum 1 draai per 2cm. Elke node mag op gelijke basis toegang vragen op de bus, op voorwaarde dat deze voor een minimumtijd vrij is. Indien twee nodes gelijktijdig toegang vragen, wordt de bus toegewezen aan de 20 node met de hoogste prioriteit. Daar er slechts acht prioriteitenniveaus zijn en er 20 mogelijke deelnemers zijn, kan er nog steeds een botsing optreden. In dat geval krijgt de node met de kortste bustoegangstijd voorrang. De bustoegangstijd is de tijd die een node dient te wachten tot een volgende poging om toegang te vragen tot de bus. 2.1.2 Protocol Het protocol is een standaard UART systeem. Een boodschap bestaat uit een identifier, data en een checksum. Eén karakter bestaat uit 10 bits. Het eerste is het startbit, logisch 0. Dit wordt gevolgd door 8 databits en een stopbit, logisch 1. Afbeelding 2: Karakterformaat 2.1.3 J1708 busbelasting In figuur 3 zien we de aanbevolen belasting voor de bus J1708. Afbeelding 3: Busaansluiting De weerstanden en de condensatoren vormen een laagdoorlaatfilter, om de uitgezonden radiostraling te beperken. R3 en R4 vormen een pseudo-afsluiting voor de bus, daar deze geen afzonderlijke afsluiting heeft. Een tranceiver (Afbeelding 4) kan best aangesloten worden zoals in Afbeelding 5, gevolgd door het filter van Afbeelding 3. 21 Afbeelding 4: RS-485 tranceiver voor J1708 Een driver in een J1708 toepassing wordt in dominante mode gebruikt. Dit wil zeggen dat de data in (DI) met de grond verbonden is, en dat de driver enable aangestuurd wordt door de TX. Hier uit volgt dat een logische 0 vertaald wordt door een dominante staat op de bus. Een logische 1 is bijgevolg een onderdrukte staat. Het gevolg van deze methode is dat een 0 altijd als dominante toestand op de bus zal overschrijven. Afbeelding 5: Blokdiagram van een J1708 node Daar elke node verplicht dient te luisteren naar zijn eigen verzonden data, kan deze controleren of deze wel correct op de bus komt. Indien dit niet het geval is, omdat een andere node een recessive staat overschrijft met een dominante, dient deze node ogenblikkelijk te stoppen met zenden. In figuur 5 staat een overzicht van een complete node. 22 2.2 J1587 2.2.1 Inleiding: Het J1587 protocol is een applicatielaag die gebruik maakt van de J1708 datalink en fysische lagen. Het kan gebruikt worden voor verschillende toepassingen, waaronder: • • • • loggen en monitoren van het voertuig Navigatie en planning Bestuurdersinfo; tripinfo, tachograaf ladingsinformatie. J1587 definieert de structuur van de boodschappen die tussen verschillende controllers uitgewisseld worden. Een boodschap bestaat uit een MID (Message Identifier), PID (Parameter Identifier) en data. Zoals in J1708 gedefinieerd, mag een boodschap niet langer zijn dan 21 bytes. 2.2.2 Opbouw van een boodschap De maximum lengte van een boodschap is 21 bytes; deze worden als volgt ingevuld: 1. Het eerste byte is de MID. Deze byte is uniek voor de node in het netwerk. Enkel waarden tussen 128 en 255 zijn mogelijk. 2. Het eerste byte na de MID is de eerste PID. Deze byte definieert de inhoud van de komende data. Een PID is gewoonlijk 8 bits lang, maar kan verlengd worden tot 2 bytes indien het eerste byte 255 is. Dit laat een maximum van 511 PID's op het netwerk toe. Een enkele boodschap kan meerdere PID's bevatten. 3. De eigenlijke data, gedefinieerd door de voorafgaande PID. De lengte van deze data is afhankelijk van de PID, maar is altijd een veelvoud van 8 bit. 4. De boodschap wordt afgesloten met een checksum. Dit is het 2's complement van de som van alle voorgaande bytes. Data wordt met het LSB eerst verzonden. De prioriteit en herhalingstijd van een boodschap wordt vastgelegd door de fabrikant van een toestel. Om overbelasting van de bus te voorkomen, zal de norm echter wel aanbevelingen doen voor verschillende types boodschappen. Om de data correct te interpreteren, kun je de eigenschappen van elke PID opzoeken in de norm. 23 3 De CAN-bus 3.1 Inleiding De belangrijkste communicatie tussen de verschillende modules verloopt over een CANbussysteem (Controller Area Network). CAN is een standaard communicatieprotocol dat de fysische en de datalinklaag beschrijft. 3.2 Geschiedenis Het CAN-protocol is in 1983 ontwikkeld door Robert Bosch GmbH als een communicatie-protocol voor voertuigen. In 1986 is het officieel voorgesteld op het SAE (Society of Automotive Engineers) congres in Detroit. Philips Semiconductors en Intel hebben de eerste CAN-ASIC's op de markt gebracht in 1987. In 1991 vervolgens publiceerde Bosch de CAN 2.0 specificaties en in 1993 is dit protocol ook opgenomen in de ISO-normen als ISO11898. In de volgende figuur zie je de belangrijkste mijlpalen in de geschiedenis van CAN-bus. 1983: Bosch start met de ontwikkeling van CAN 1988: CAN aangekondigd in Detroit 1987: Eerste CAN controllers van Intel en Philips 1991: Bosch publiceert CAN2.0B 1992: Mercedes gebruikt als eerste CAN in hun topsegment 1993: ISO11898 gepubliceerd 1995: ISO11898 amendement gepubliceerd 1996: OBDII verplicht in Californie 2001: EOBD verplicht op europese benzineauto's 2002: CAN toegevoegd aan SAE J1979 (OBDII) 2004: EOBD verplicht in europese dieselvoertuigen CAN verplicht in de VS Afbeelding 1: CAN Tijdslijn 3.3 Gebruik CAN is één van de standaarden die gedefinieerd wordt in de EOBD (European On-Board Diagnostics) standaarden. Deze laatste standaarden beschrijven de applicatielagen en komen dus boven op de CAN-standaard. In Europa is productie volgens de EOBD-standaarden verplicht voor alle benzineauto's verkocht vanaf 2001 en voor alle dieselvoertuigen verkocht vanaf 2004. Bij zwaardere voertuigen zoals vrachtwagens en bussen is CAN de de facto standaard voor diagnosesystemen. Echter, hier wordt geen gebruik gemaakt van EOBD-standaarden (ISO 157654), maar van de SAE J1939 norm. Jammer genoeg zijn deze standaarden incompatibel. Voor de interne communicatie tussen controllers maken veel automobielfabrikanten gebruik van een CAN-netwerk. Daarnaast worden ook andere overdrachtsystemen gebruikt, zoals onder andere LIN (low level communicatie, bijvoorbeeld in een deurmodule), MOST (digitale media en entertainment) of Flexray (hogesnelheidsverbinding, nog in volle ontwikkeling). 24 3.4 Wat is CAN CAN maakt het mogelijk om meerdere modules te verbinden via één bussysteem. Alle nodes zijn gelijkwaardig, er is dus geen master of slave. Een zender zendt zijn boodschap naar alle andere nodes in het netwerk. Er is dus steeds sprake van broadcasting. Elke node in het netwerk kan deze boodschap ontvangen. Elke boodschap heeft een label dat uniek is binnen het netwerk. Bij CAN wordt dus niet de node van een adres voorzien, maar krijgt de boodschap een label. Een ontvangende node bekijkt deze identificatie en aan de hand daarvan wordt bepaald of de inhoud relevant is voor die node. De buitenspiegels zijn bijvoorbeeld niet geïnteresseerd in een boodschap met info over de motortemperatuur, maar de dashboard-controller kan hier wel iets mee aanvangen en zal dus het datapakket, dat na het label komt, verder verwerken. Afbeelding 2: Broadcast en message filtering Naast het identificeren van de boodschap dient het label ook om de prioriteit van de boodschap vast te stellen. Deze prioritisering maakt het mogelijk om 'botsingen' tussen boodschappen op te lossen/vermijden. CAN werkt op basis van CSMA/CD + AMP (Carrier Sense Multiple Access / Collision Detection + Arbitration on Message Priority). Dit wil zeggen dat een node eerst moet luisteren of de bus in rust is voor hij mag beginnen met zenden. Indien de bus inactief is, maar twee verschillende nodes op het zelfde moment zouden beginnen zenden, wordt er voor gezorgd dat de node met de laagste prioriteit (= hoogste identifier) stopt met zenden. De prioritisering maakt het overbodig om het zenden te hervatten bij een botsing, want een node die een boodschap met een lagere prioriteit probeert te verzenden, zal automatisch stoppen met zenden indien die een botsing detecteert. Dit garandeert dat prioritaire boodschappen nooit gestoord worden door minder prioritaire. Er zijn twee versies van de CAN-standaard. Deze versies hebben elk een eigen (en verschillende) lengte van de labels; CAN2.0A heeft een 11-bit identificatie; bij CAN2.0B kan dit uitgebreid worden tot een 29-bit identificatiecode. De B-versie is neerwaarts-compatibel met de A-versie. Het is dus belangrijk dat een tool de B-versie ondersteunt, zodat je alle bussen kan monitoren. Hoewel de EOBD-standaard de twee-draad CAN-bus voorschrijft, zijn er ook fabrikant25 afhankelijke versies zoals GMLAN. Dit is een één-draad versie gebruikt door General Motors. Voordelen van de CAN-bus. − Hoge datasnelheden: Omdat CAN werkt met een getwist paar draden kunnen veel hogere datasnelheden gehaald worden dan met vergelijkbare enkel-draad-systemen. EOBD specificeerd datarates tot 500 kb per seconde; de CAN2.0B gaat zelfs tot 1Mb per seconde. Echter, hoe hoger de baudrate, hoe korter de toegestane lengte van een segment. − Betrouwbaarheid: CAN bevat een zeer uitgebreid controlemechanisme dat op elk datapakket toegepast wordt. Het protocol heeft ook een degelijke oplossing voor het gelijktijdig zenden door verschillende bus-deelnemers, waardoor de belangrijke boodschappen zonder onderbreking voorrang krijgen op de boodschappen met een lagere prioriteit. − Bus-gebaseerd: Doordat er meerdere stations op een enkele kabel geplaatst kunnen worden, kan het aantal draden in een voertuig sterk beperkt worden. Dit heeft als bijkomend voordeel dat extra functionaliteiten ingebouwd kunnen worden zonder dat andere, reeds bestaande modules aangepast moeten worden. − Data consistentie: Doordat alle pakketten ofwel door alle busdeelnemers, ofwel door niemand worden ontvangen, weet de zender dat zijn data ongeschonden alle uithoeken van de bus bereikt heeft. 26 3.5 Het osi-model van de can-bus Het osi-model beschrijft de verschillende functionaliteiten in een netwerk als verschillende lagen. Deze lagen communiceren als het ware horizontaal met elkaar, terwijl de werkelijke datastroom naar beneden in het model loopt, over de bus en bij de ontvanger terug omhoog. Niet alle protocollen moeten alle functionaliteiten van het osi-model implementeren, omdat de natuur van het specifieke systeem deze functionaliteiten overbodig maakt. Afbeelding 3: OSI-model bij CANbus Afbeelding 3 is een voorstelling van de can-bus, de applicatie laag is echter niet gedefinieerd in de standaard. 3.5.1 Fysische laag. De CAN-bus bestaat over het algemeen uit een getwist paar draden. Op deze draden wordt een differentieel signaal verzonden. Door deze manier van werken is het systeem behoorlijk robuust tegen ingekoppelde stoorsignalen. Doordat de draden getwist zijn, liggen ze steeds fysiek dicht tegen elkaar, waardoor ze quasi de zelfde storingen oppikken. Er wordt dus op de beide draden de zelfde golfvorm gesuperponeerd en de storing wordt door de differentiële transmitter teniet gedaan. Een voorbeeld van een transmitter zie je in figuur 4. Een laag signaal wordt verzonden als een gelijk Afbeelding 4: Driver (vb MCP2551) 27 potentiaal op de beide draden en een dominante staat door een spanningsverschil groter dan 1,8V. Het laag niveau wordt niet hard opgelegd (hoge impedantie), waardoor een dominante toestand, verzonden door een andere zender, altijd voorrang heeft. Er bestaan 2 verschillende versies: High speed CAN voor vrachtwagens en fault tolerant CAN, vaak gebruikt in personenwagens. Fault tolerant CAN herken je door de busniveaus van 0V en 5V op respectievelijk CAN-L en CAN-H bij een recessieve staat, en 1,4V en 3,6V bij een dominante staat. Deze implementatie is bestand tegen busfouten zoals onderbreking van 1 ader, kortsluiting van 1 ader naar massa of voeding of zelfs kortsluiting van CAN-H en CAN-L onderling. 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. Afbeelding 5: Canbus 28 3.5.2 Datalinklayer Daar waar de fysieke laag de elektrische aspecten beschrijft, zal deze laag de data zelf beschrijven. De datalinklaag kan nog eens onderverdeeld worden in 2 lagen: MAC (Media Acces Control) en LLC (Logical Link Control). 3.5.2.1 MAC (Media Acces Control) We beginnen met de MAC (Media Acces Control). Deze laag houdt zich bezig met de individuele bits en bustoegang. Hierboven hebben we gezien dat CAN werkt met een dominante en een recessieve staat. Dit vertaalt zich als respectievelijk een 0 en een 1 op de hogere niveaus. 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 figuur 6, gemeten tussen CAN-H en CAN-L. Afbeelding 6: Bitstuffing om de 5 gelijke bits 29 Busarbitrage Node 1 Node 1 Node 2 Node 2 Node 3 Node 3 bus level bus level SOF SOF Afbeelding 8: Bus arbitrage(11-bit identifier) RTR RTR Een node mag maar beginnen zenden als hij een vrije lijn detecteert. Indien twee verschillende nodes op het zelfde moment beginnen te zenden, zal automatisch de node met de hoogste prioriteit de lagere van de bus duwen. Hiertoe hoeft geen actie ondernomen te worden. Het dominante bericht zal zelfs zonder schade doorkomen, zodat dit niet opnieuw verzonden hoeft te worden. Visueel kun je dit proces volgen in afbeelding 7. 10 9 8 7 6 5 4 3 2 1 0 Control recessive 10 9 8 7 6 5 4 3 2 1 0 Control recessive recessive recessive Data Data Af beelding 7: Bus arbitrage(11-bit identifier) Busarbitrage gaat als volgt in zijn werk: bij het begin van een bericht wordt een 0 (dominante staat) verzonden. Tijdens het zenden, luisteren de beide controllers naar de bus. Ze detecteren beiden een 0, dus alles gaat goed. Vervolgens beginnen ze elk hun eigen identifier te verzenden. 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. (zie afbeelding 5). 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 hersynchroniseren. 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). 30 Vervolgens komen Phase Segment 1 (PS1) en Phase Segment 2 (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 Width is 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. A fbeelding 9: Bittiming 3.5.2.2 LLC De Logical Link Control sublaag definieert de samenstelling van een volledig busbericht, dus meerdere bits na elkaar. Om te beginnen definiëren we 4 soorten frames die kunnen voorkomen op de bus; • Data frame • Error frame • Remote frame • Overload frame 31 Afbeelding 10: Can-frame Data frame Dit is het meest gebruikte frame op de bus. Dit frame bevat de eigenlijk te verzenden data. Het bestaat vooraan uit een arbitrage-veld dat de prioriteit op de bus en de identiteit van het pakket vastlegt. Als tweede deel bevat het een controleveld met de lengte van de boodschap. De derde serie bits zijn de eigenlijke data en kan bestaan uit 0 tot 8 bytes aan data. Vervolgens wordt er een 15-bit CRC verzonden om de integriteit van de data te controleren. Als laatste worden er nog een acknowledement bit (verzonden door de ontvangers ter bevestiging dat de boodschap door ten minste 1 ontvanger correct ontvangen is) en een end of frame bit verzonden. Dit laat toe dat de andere nodes een fout in de boodschap ontdekken en signaleren. Het remote-frame Dit frame laat een node toe om een bepaalde boodschap aan te vragen op het netwerk. Overload frame Het overload frame is een soort van dataframe dat verzonden wordt door een node die bezig is met verwerken van data. Het zorgt er voor dat andere nodes even moeten wachten met het verzenden van nieuwe data, tot de betreffende node klaar is om het volgende datapakket te ontvangen. Error frame Als een node een fout ontdekt in een boodschap, dan zal deze automatisch dominante bits verzenden, waardoor alle andere nodes ook weten dat er een fout verzonden is. Deze automatische verzending bestaat minstens uit 6 opeenvolgende dominante toestanden en interfereert dus met de bit-stuffing regel. Hierdoor zullen ook alle andere controllers een errorframe gaan zenden en dus bevestigen dat de data ongeldig is. Om te vermijden dat één node alle busverkeer blokkeert, zal elke node zijn eigen error-counter bijhouden. Als deze 127 overschrijdt, zal de node overschakelen naar de error passive mode. Dit betekend dat die node geen actieve error frames meer zal zenden. 32 Als een node dan nog 127 errors detecteert, dan zal hij off-bus gaan. Dit betekend dat hij zichzelf isoleert van de bus en uitschakelt. Volgende diagram toont deze verschillende error states. Afbeelding 11: Error handling Hier zie je dat een controller zijn foutenteller kan verminderen bij elke correct verzonden of ontvangen frame. 3.6 Besluit Om het mogelijk te maken CAN-boodschappen op de bus te volgen, te identificeren en zelf boodschappen toe te voegen, zal ik zelf een transmitter maken. De specifieke hardware kan gevonden worden op de website van microchip. Deze fabrikant biedt een volledig scala aan IC's die gebruikt kunnen worden in dit project. Verdere uitleg over deze schakelingen staat in het hoofdstuk over de elektronica. 33 4 J1939 4.1 Inleiding De J1939 standaard is een uitbreiding op het CAN-protocol en voegt de applicatielaag toe aan de fysische en datalink laag. Deze standaard definieert het gebruik van de CAN-bus in vrachtwagens en bussen als verbinding tussen de verschillende controllers, alsook tussen trekker en aanhanger. In J1939 maakt men enkel gebruik van de 29 bit identifiers. Het 29-bit lange id-veld (afbeelding 1) wordt opgesplitst in 5 delen: 1) 3-bit prioriteitsveld. Dit veld wordt gebruikt om een prioriteit te koppelen aan een bepaalde boodschap. Prioriteit 0 is de hoogste prioriteit; prioriteit 7 heeft het minst belang. 2) Gereserveerd bit 3) Data pagina bit 4) 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. 5) 8-bit bronadres. Dit veld wordt gebruikt om de bron van de info te beschrijven. Afbeelding 1: Indeling ID 4.2 Datasnelheden De J1939 standaard definieert ook de baudrate; deze bedraagt 250kbaud. Bij deze snelheid is een maximale segmentlengte van 40m opgegeven, wat een zeer veilige marge inhoudt ten opzichte van de CAN definitie. 4.3 Datapakketten De andere velden blijven hun originele functie behouden zoals dit gedefinieerd is in de CANstandaard. In 99% van de berichten wordt echter gebruik gemaakt van 8 databytes. Enkel in de adres-claiming procedure wordt gebruik gemaakt van een 3 bytes tellend datapakket. 4.4 Adres claiming 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. 4.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 34 daartoe een transport protocol. Er zijn twee mogelijkheden voor een transport: broadcast en geadresseerd. 4.5.1 Broadcast Bij een broadcast zet 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. 4.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. 4.6 Indeling van de identifier Prioriteit Res DP 3 1 1 PGN SA PF PS 8 8 8 4.6.1 Prioriteit De eerste 3 bits bevatten de prioriteit van het bericht. De mogelijkheden lopen van 0-7, waarbij 0 de hoogste prioriteit heeft. Elk bericht heeft een standaard prioriteit, die bij de PGN vermeld staat in de J1939-71 norm. 4.6.2 Res en DP Res is een gereserveerd bit, mogelijk gebruikt in verdere ontwikkelingen van de standaard. Dit bit dient 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. 4.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) Broadcast boodschappen: PF 240-254 3) Fabrikantsafhankelijke boodschappen: kunnen gebruik maken van zowel methode 1 als 2. 4.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). 35 4.6.3.2 Broadcast berichten Indien PF in het bereik 240-254 lig, dan behelst het een broadcast bericht. In dat geval wordt het PS-veld gebruikt als uitbreiding van het PGN-veld en bestaat dit bericht dus uit 16 bits, in plaats van 8 bits. Logischerwijs is er dan geen doeladres. 4.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. 4.6.4 Bronadres De laatste 8 bits van de identifier vormen het bronadres; het adres van de verzendende node. 4.7 PGN 4.7.1 Eigenschappen Een PGN definieert de inhoud van het datapakket dat na de identifier komt. Er zijn 2 datapagina's met elk 240 P2P en 16 x 256 broadcast boodschappen, 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 2 verschillende 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. (Dit zal het nodig maken in ons specifiek project om per model vrachtwagen zelf enkele PGN's te bepalen, zie later in dit werk). 36 4.7.2 Voorbeeld PGN De opbouw van een PGN zullen we hier demonstreren aan de hand van PGN 61443: in de norm vind je volgende informatie terug: (zie tabel 1) (R) PGN 61443 Electronic Engine Controller 2 EEC2 Identifies electronic engine control related parameters. Transmission Repetition Rate: 50 ms Data Length: 8 Extended Data Page: 0 Data Page: 0 PDU Format: 240 PDU Specific: 3 PGN Supporting Information: Default Priority: 3 Parameter Group Number: 61443 (0x00F003) Start Pos Length Parameter Name SPN 1.1 Idle Switch 1.3 Kickdown Switch 1.5 1.7 Idle Switch 2 1 3 Current Speed 4 Position 5 2 6.1 Limit Status 6.3 Maximum Power 2 bits 558 2 bits 559 2 bits 1437 2 bits 2970 1 byte 91 1 byte 92 1 byte 974 1 byte 29 2 bits 2979 2 bits Accelerator Pedal 1 Low Accelerator Pedal Road Speed Limit Status Accelerator Pedal 2 Low Accelerator Pedal Position Engine Percent Load At Remote Accelerator Pedal Accelerator Pedal Position Vehicle Acceleration Rate Momentary Engine Enable Feedback 7 Available Engine - 5021 1 byte Actual Maximum Percent Torque 3357 37 ID Pri RES DP DLC PGN 3bit 1bit 1bit 8bit 3 0 0 Data SA 8bit 8bit D1 8bit 8bit 61443 Spn 558 Spn 559 Spn 1437 Spn 2970 PDF PGS 2bit 2bit 2bit 2bit xx xx xx xx 240 3 xx 8 D2 D3 D4 D5 8bit 8bit 8bit 8bit Spn 91 Spn 92 Spn 974 Spn 29 xx xx xx xx D6 8bit Spn Spn 2979 5021 / 2bit 2bit 2bit xx xx xx D7 D8 8bit 8bit Spn 3357 / xx xx Tabel 1: Indeling in parameters Als eerste lezen we de naam van deze PGN. In dit geval is dat dus EEC2. Vervolgens wordt er beschreven wat men in deze parametergroep terug kan vinden. Hier gaat het om bijkomende informatie over de toestand van de motor, meer specifiek de ingestelde waarden. Als derde staat er vermeld met welke tussentijd deze boodschap op de bus komt. Bij deze is dat nu een vaste waarde, maar er zijn ook boodschappen die verzonden worden afhankelijk van het motortoerental. Vervolgens vinden we een lijst met de Suspect Parameter Number (SPN). Deze codes refereren naar een specifieke parameter. Voor elke SPN is de positie binnen de 8 bytes van het volledige datapakket, het aantal bits dat hij gebruikt en een korte beschrijving van de parameter gegeven. 4.7.3 Voorbeeld SPN Elk van de SPN's worden nog eens afzonderlijk beschreven in document J1939-71. Afhankelijk van het soort data, kan de informatie een verschillende lengte hebben. Zo zijn er parameters die slechts 2 bits innemen (meestal schakelaars) en andere die enkele bytes innemen (meetwaarden). Als eerste voorbeeld wordt SPN 558 bekeken: SPN 558 Accelerator Pedal 1 Low Idle Switch Switch signal which indicates the state of the accelerator pedal 1 low idle switch. The low idle switch is defined in SAE Recommended Practice J1843. 00 - Accelerator pedal 1 not in low idle condition 01 - Accelerator pedal 1 in low idle condition 10 - Error 11 - Not available Data Length: 2 bits Resolution: 4 states/2 bit, 0 offset Data Range: 0 to 3 Operational Range: same as data range Type: Measured Supporting Information: PGN reference: 61443 38 Hier kan men zien dat het om een schakelaar gaat (2 bits). Voor de verdere eigenschappen, plaatsing en normering wordt verder verwezen naar een andere norm, die de doelstelling van dit werk voorbij gaat. Vervolgens wordt er een opsomming gegeven van de verschillende mogelijke statussen. Tot slot wordt er nog een samenvatting gegeven van de toegestane waarden. Een tweede mogelijkheid is de weergave van een meetwaarde, bijvoorbeeld SPN 513 SPN 513 Actual Engine - Percent Torque The calculated output torque of the engine. The data is transmitted in indicated torque as a percent of reference engine torque (see the engine configuration message, PGN 65251). The engine percent torque value will not be less than zero and it includes the torque developed in the cylinders required to overcome friction. Data Length: 1 byte Resolution: 1 %/bit, -125 % offset Data Range: -125 to 125 % Operational Range: 0 to 125% Type: Measured Supporting Information: PGN reference: 61444 Deze beschrijving is ongeveer hetzelfde als de beschrijving bij een toestandsgrootheid, echter, nu ontbreekt - uiteraard - de beschrijving van de verschillende toestanden. Bij de operational range staat nu echter wel een beperking: niet alle mogelijke waarden liggen binnen het toegelaten bereik. Aan de hand van deze informatie kun je dus de binaire code omzetten naar een fysische grootheid, of omgekeerd, indien men zelf een bepaalde toestand of waarde op de bus wensten te zetten. Het is ook mogelijk om data aan de hand van ASCII tekens te verzenden. Dit wordt bijvoorbeeld gedaan om configuratiedata te verzenden. Alle toegelaten mogelijkheden, alsook de richtlijnen tot plaatsing van de data binnen een PGN, staan beschreven in J1939-71. Indien men de indeling van een fabrikantspecifieke PGN wil weten en de afzonderlijke velden vertalen naar een fysische waarde, dan kan dit document uiteraard niet gebruikt worden. Zijn er geen publieke SPN's bekend, dan moeten we dus gissen naar de omzetting van de binaire waarde naar een fysische grootheid. Verderop wordt meer uitleg gegeven naar de manier waarop we dit zullen aanpakken. 39 5. Metingen 5.1 Inleiding In de loop van mijn stage heb ik een aantal metingen uitgevoerd op de bussystemen. Daar het de bedoeling was om de data van de VCU (Vehicle Control Unit) na te bootsen, was het in eerste instantie nodig om verder in te gaan op de communicatie onder de standaard gebruiksvoorwaarden. De eerste metingen zijn uitgevoerd op de Volvo FH proefstand. Dit is een stuurkast zoals deze momenteel gebruikt wordt in de garage van Turbo's Hoet. In deze stuurkast is de minimale configuratie aangesloten die momenteel nodig is om een motor correct te laten werken: de motorcontroller (buiten de kast, op de motor zelf gemonteerd), een VCU, het dashboard, gaspedaal en enkele schakelaars om de standen van de contactsleutel te emuleren. Een serie overbodige sensoren en schakelaars zijn hier niet aangesloten (cfr. minimale configuratie). Daar uit voorgaande studie (zie hoofdstuk 3 en 5) blijkt dat de J1939 en J1708-links niet evenwaardig zijn, besluiten we om in eerste instantie te focussen op de J1939-link. De J1708-link wordt hoofdzakelijk als back-up gebruikt, en is in latere modellen zelfs volledig afwezig. Op de CAN-link sluiten we de can-explorer uit Elektuur (Krüger F. (2008)) aan (zie hoofdstuk 7: elektronica). Hierna is de data op de bus te bekijken via de pc met CANKing (zie hoofdstuk 8: software). Aan de hand van deze tools kunnen we gaan bekijken hoe en wat er uitgewisseld wordt door de verschillende controllers. 5.2 Metingen Volvo FH In dit deel zal ik onderzoeken welke signalen uitgewisseld worden tussen de verschillende nodes. Aan de hand van de schema's (zie appendix I) kunnen we analyseren op welke controller welke noodzakelijke sensoren zitten. We kunnen verwachten dat de ECU alle relevante data op de bus zal zetten, ten einde deze op het dashboard zichtbaar te maken. Omgekeerd zijn er een aantal ingangen aanwezig op de VCU (gaspedaal, retarder, contactsleutel,...), die noodzakelijk zijn voor de correcte werking van de ECU. Dus ook deze data zullen we onder de ene of andere vorm moeten terug vinden in de communicatie. Na de eerste metingen (zie verder) blijkt dat er heel wat niet gestandaardiseerde boodschappen uitgewisseld worden (2 gedefinieerde tegen 7 ongedefinieerde boodschappen). Het is daarom noodzakelijk ongeveer te weten wat de ECU exact nodig heeft aan data. Deze informatie is ook belangrijk in het licht van de uitbreiding naar andere modellen en merken toe. We zien in eerste instantie dat het merendeel van de noodzakelijke sensoren op de ECU zelf aangesloten is. Enkel de directe interface met de gebruiker, zoals het gaspedaal, rempedaalcontact en cruisecontrol is aangesloten op de VCU. Uit deze informatie blijkt dat waarschijnlijk het grootste deel van de boodschappen door de ECU uitgezonden wordt. Dit zal hopelijk onze taak vereenvoudigen, doordat we zelf minder boodschappen moeten versturen. Wanneer we dit ook testen op de ECU van de scania R serie, zien we dit inderdaad bevestigd (zie verder). Zonder aanwezige COO, zien we 15 verschillende boodschappen verschijnen. Enkel de PGN 61443, 61444, 30207 en 30335-boodschappen herkennen we aangezien deze ook aanwezig zijn in de Volvo. De eerste twee zijn niet toevallig de enige PGN's die ook in de J1939-71 gedefinieerd zijn. Indien we nu de opgemeten boodschappen die uitgewisseld worden op de can-link zonder een 40 aangesloten motor bekijken, dan zien we de volgende PID's opduiken: PGN Procentueel voorkomen Titel 34824 0,1 ? 36012 0,1 + 6200 0,1 + 3080 0,2 ! 2060 0,2 ! 52043 0,1 ! 61443 9,2 61444 24 65282 49 65292 4,5 3662 0,1 + 52878 0,1 ! 30808 0,1 ? 30207 0,4 Update om de 5 sec 30335 0,1 Update om de 5 sec 30591 0,15 bij inschakelen en uitschakelen 30720 4,6 32623 1,6 32632 5 Bevat startmotor byte1bit0 Boodschappen in normaal bedrijf. Signalen die aanwezig blijven na het uitschakelen. Signalen ook aanwezig zonder ECU 41 5.3 Vergelijking met nieuwe systemen. Indien we het onderzochte systeem vergelijken met nieuwere modellen, zien we dat deze laatste veel meer gebruik maken van verschillende CAN-bussen. Daarnaast wordt de J1708 volledig overboord gegooid; deze wordt op geen enkele nieuwe vrachtwagen nog gebruikt. Ook perifere componenten worden van een intelligente controller voorzien (bv. buitenspiegels,...). Opvallend is dus dat er meerdere databussen ingeschakeld worden om de data uit te wisselen. Deze bussen hebben elk hun eigen deel van het systeem. Door deze gescheiden aanpak is het bijna onmogelijk dat bv. de airco de data van de transmissie verstoord. De verschillende bussystemen worden aan elkaar gekoppeld door verschillende controllers, zoals aangegeven in onderstaande schema's. A fbeelding 1: DAF met AS-tronic Elk van deze bussen heeft dus zijn eigen functie. Dit maakt het ook eenvoudiger om deelsystemen te isoleren van elkaar. Echter, in hoeverre deze systemen ook op dataniveau gescheiden zijn, zal pas na metingen duidelijk worden. Een voorbeeld van zo'n afzonderlijk systeem met eigen communicatienetwerken en discrete componenten vind je bijvoorbeeld bij het DAF AS-tronic schakelsysteem (Zie afbeelding 3). Afbeelding 2: Scania 42 Afbeelding 3: DAF AS-tronic systeem Dit systeem bestaat uit de AS-tronic module D954. Dit is de controller die boven op de versnellingsbak gemonteerd is. Dit is het eigenlijke brein van de vrachtwagen. Via een eigen canbus is deze controller verbonden met de D955-module. Dit is de versnellingspook die in de cabine gemonteerd is. Onder deze component zien we de E590, de keuzeschakelaar. B385 stelt de schakelspoelen voor die in de versnellingsbak aanwezig zijn. De controller communiceert met de rest van het systeem via de triebstang-can. Afbeelding 4: TEPS: Het nieuwe elektronische systeem van MAN Deze bus is op zijn beurt dan weer aangesloten op de ZBR2: De Zentrahle Bord Rechner Zwei. Dit is één van de twee of drie interfaces in het systeem, die alle deelbussystemen aan elkaar koppelt. Het systeem is zo opgezet, dat alles rond ZBR0 met de opbouw te maken heeft en alle systemen 43 verzameld rond ZBR2 in het chassis terug te vinden zijn. Uit deze structuur kunnen we opmaken welke data we waarschijnlijk op welke bus kunnen aantreffen. Daar alles logisch gescheiden is, kunnen we verwachten dat we een statusverandering van bijvoorbeeld de boordlichten niet zullen terugvinden op de Triebstang-CAN. Omgekeerd, zal er heel wat info over de status van de verschillende motorsystemen verzonden worden naar het dashboard. 44 5.4 Scania R-serie 5.4.1 Inleiding Tijdens mijn stageperiode werd duidelijk dat de technologie aanwezig in de Volvo FH-modellen verouderd was. Daar deze nog afkomstig was uit het begintijdperk van de CAN-bus, bevat deze nog een tweede, in principe overbodige link, de J1708. In samenspraak met mijn promotoren is er dan besloten om over te schakelen naar de Scania R-serie (Zie afbeelding 5). Daar in Turbo's Hoet nog niet veel kennis over deze motoren ter beschikking was, was dit ook voor hen een interessante uitdaging. Veel werk zou gespaard kunnen worden indien er voor deze serie ook niet zo'n stuurkast als voor de andere motoren moet samengesteld worden en indien deze stuurkast meteen gebruik kan maken van dit werk. Afbeelding 5: Scania R In afbeelding 2 zien we een overzicht van de aanwezige bussystemen in de Scania R uit Afbeelding 2. Scania verdeelt de data over 3 verschillende bussen, zodat de belasting van elk van deze bussen relatief laag blijft en de bedrijfskritische data niet gestoord wordt door uitbreidingsmodules. Scania verklaart op zijn website het volgende over hun can-bussysteem: Het hart van de Scania CANbus vormt de centrale controle-eenheid (coördinator) waar doorheen alle functies worden bekeken en geregeld – inclusief externe apparatuur. Van hieruit worden de elektronische functies van de truck verdeeld in drie circuits: rood, oranje en groen. De rode functies bestrijken alle hoofdsystemen: motor, versnellingsbak, remmen en vering. Geel bestrijkt de instrumenten, carrosseriesystemen, vergrendelings- en alarmsystemen en de verlichting. Groen bestrijkt de comfortsystemen zoals klimaatregeling, audio en onboard computers. Een storing in het oranje of groene systeem heeft geen enkele invloed op het eigenlijke functioneren van het voertuig. Bij geel krijgt de chauffeur een seintje en een foutcode. Een rode fout zet het voertuig om veiligheidsredenen stil. Het mankement wordt ook doorgegeven aan de chauffeur door een serie foutcodes die de oorzaak ervan aangeven. Snel herstellen langs de kant van de weg bestaat tot de mogelijkheden. 5.4.2 Metingen Aan de hand van deze informatie zijn we zelf beginnen testen. Voor onze test hebben we een model genomen met een handmatige versnellingsbak om niet het risico te lopen dat, indien we een elektrische fout veroorzaken bij draaiende motor, de versnellingsbak uit zichzelf zou beginnen te schakelen en we de vrachtwagen beschadigen of mensen verwonden. Onder het dashboard vinden we 3 stekkers terug, die de centrale verbinding vormen van alle can45 bussen. In de schema's (bijlage I) zien we deze stekkers op schema T1, D2-D3. De stekkers bevatten een connectorblok die de inkomende draden, CAN-H en CAN-L afzonderlijk (uiteraard), met elkaar verbindt. In een eerste fase hebben we de gele en groene CAN-bussen apart genomen. Hierna hebben we een poging ondernomen om de motor te starten. Dit bleek geen probleem. Wel merkten we op dat op het dashboard een hele rist aan foutmeldingen verschenen. Logisch natuurlijk, want dit dashboard is met de coördinator verbonden via de gele bus, die we net onderbroken hadden. Bijkomend werkte geen van de instrumenten nog. De motor kan wel normaal bediend worden via het gaspedaal. Na het terug uitschakelen van de motor, bestudeerden we het schakelpaneel onder de zekeringkast. Hier vinden we verschillende controllers terug, die o.a. instaan voor de vering en de remmen. Deze waren ook verbonden met de rode CAN-bus. We verwijderden deze stekkers en deden vervolgens een nieuwe poging om te starten. Volgens de informatie van scania zou dit niet meer mogen lukken, , want we hebben immers kritische componenten van de bus verwijderd. De motor sloeg echter, zonder problemen aan en we konden het gas nog steeds bedienen als voorheen. Dit betekent een serieuze doorbraak, daar blijkbaar enkel de motor en de coördinator aanwezig dienen te zijn om de motor correct te laten draaien. De volgende stap was om ook de rode can volledig uit bedrijf te nemen, door ook deze stekker te verwijderen uit het schakelpaneel. Nu konden we de motor niet meer doen starten; zelfs de startmotor sloeg niet aan. Na verdere studie van de elektrische schema's blijkt dat dit een logische uitkomst is. We nemen even schema B1 ter hand. Dit schema toont alle aansluitingen van de EMS naar de binnenzijde van de vrachtwagen. De aansluitingen zijn allen gegroepeerd op stekker E44, die op de motorcontroller ingeplugd wordt. Afbeelding 6 toont een foto van de betreffende stekker zoals die op de vrachtwagen aangetroffen wordt. De rode draden zijn de voedingsaansluitingen; de massa wordt gevormd door de zwarte draden. Raar maar waar, de rode can-bus is hier uitgevoerd met een blauwe en witte draad, respectievelijk CAN-H en CAN-L (rode CAN-H en witte CAN-L overal in de cabine). Tot slot is er nog de groene draad; deze bevat een wake-up signaal, afkomstig van de coördinator. In het labo deden we de test op een losse EMS en zagen we dat het signaal Afbeelding 6: Stekker E44 actief wordt indien er op de pin een spanning hoger dan ca. 4V geplaatst wordt. Op schema B1 zien we de aansluitingen van de startmotor. Deze gaan enkel naar de voeding en naar de EMS. We kunnen dus veilig besluiten dat het startcommando voor de startmotor enkel via de CAN-bus doorgegeven wordt. Een volgende test die we uitgevoerd hebben, na eerst de rode can weer aangesloten te hebben, is het opnieuw starten van de motor. Nu maken we bij draaiende motor de rode CAN los. De motor reageert hier op door van een stationair toerental van ongeveer 570 omwentelingen per minuut (omw/min) te versnellen naar ongeveer 750 omw/min. Deze toerentallen konden we uiteraard niet uitlezen op de toerenteller in het dashboard, maar wel via de CAN-explorer. Want ondanks het feit dat er geen communicatie meer was tussen de coördinator en de EMS, bleef deze laatste wel actief 46 zijn data op de bus plaatsen. Deze data werd dan door de CAN-explorer doorgestuurd naar de pc. De bediening van het gaspedaal had uiteraard geen effect meer in deze situatie. Na het terug aansluiten van de CAN-lijnen, nog steeds bij draaiende motor, reageerde deze echter weer zoals tevoren. Er bleef nu nog één test over. Als de motor kan draaien zonder coördinator, maar de startmotor niet bediend kan worden zonder verbinding, dan kunnen we proberen de startmotor met de hand te bedienen. De startmotor is aangesloten op connector A2 van de EMS (zie schema B1). We hebben deze connector losgemaakt van de stuurdoos en met de hand een spanning van 24V op pin 6 van deze connector geplaatst. De connector laat het vermogenrelais in de startmotor aantrekken. We konden duidelijk horen dat de startmotor aansloeg en begon te draaien. De motor zelf sloeg echter niet aan. Vervolgens sloten we de CAN-bus terug aan en plaatsten we het contactslot in de rijstand. Nu kreeg de motor de noodzakelijke informatie van de coördinator. Het met de hand bedienen van de startmotor in deze situatie gaf wel resultaat. De motor sloeg aan, zonder commando van de COO. Met deze informatie konden we aan de slag. Dit betekende dat we slechts enkele signalen op de bus moesten krijgen om de motor effectief te laten draaien. Het programmeren van deze signalen in een passende controller is echter een ander paar mouwen, en zou nog heel wat tijd vergen. 47 5.4.3 Resultaten. Nu geweten is onder welke situatie de motor draait, bleef nog over te bepalen welke signalen nu precies op de bus nodig zijn om de EMS tevreden te stellen. Bij al onze bovenstaande experimenten hebben we de CAN-explorer aangesloten en de data op de bus gelogd. Een logbestand bestaat uit een gewoon textbestand dat geïmporteerd kan worden in een spreadsheetprogramma voor verdere verwerking. De werkwijze om dit te doen staat beschreven in het hoofdstuk over software. Meetresultaten Een sample van de opgemeten data ziet er als volgt uit (alles is weergegeven in hexadecimale waarden, behalve de laatste kolom cijfers): 0CFE6CEE X 8 FF FF FF FF FF FF 00 00 784.740 0CF00400 X 8 F0 7D 87 E6 12 FF FF FF 784.740 0CFF8027 X 8 0C 00 0D 0F 3F FC 37 00 784.740 18FEF100 X 8 F7 00 00 34 03 FF 1F FF 784.740 18FF8700 X 8 FF FF FF FF FF FF FF FF 784.740 0CFE6CEE X 8 FF FF FF FF FF FF 00 00 784.740 0CF00400 X 8 F0 7D 87 D9 12 FF FF FF 784.751 18FEDF00 X 8 8B FF FF FF FF FF FF FF 784.751 0CFE5A27 X 8 FF FF FF FF FF FF FF FF 784.751 18FEF127 X 8 F7 FF FF 37 03 FF FF FF 784.751 0CF00300 X 8 FD 00 0E FF FF FF FF FF 784.759 0CFE6CEE X 8 FF FF FF FF FF FF 00 00 784.759 0CF00400 X 8 F0 7D 87 D2 12 FF FF FF 784.764 0CFF8027 X 8 0C 00 0D 0F 3F FC 37 00 784.775 18FEF200 X 8 32 00 00 00 FF FF FF FF 784.775 0CF00400 X 8 F0 7D 87 E1 12 FF FF FF 784.784 0CFF8027 X 8 0C 00 0D 0F 3F FC 37 00 784.799 18F00029 X 8 D0 7D FF FF FF FF FF FF 784.799 0CFE6CEE X 8 FF FF FF FF FF FF 00 00 784.799 18FFA027 X 8 03 0F 00 FF FD FF FF FF 784.799 0CF00400 X 8 F0 7D 87 EA 12 FF FF FF 784.820 0CF00300 X 8 FD 00 0D FF FF FF FF FF 784.820 R R R R R R R R R R R R R R R R R R R R R R De eerste kolom is de weergave van de ID. De X toont aan dat het gaat om een extended identifier. Vervolgens is de datalengte gevolgd door de data zelf (hier telkens 8 bytes) aangegeven,. In de laatste 2 kolommen vinden we respectievelijk de tijdstempel en de R wil zeggen dat het een ontvangen (received) boodschap is. 48 Uit een datastroom als deze dienen we te bepalen welke data van welke module afkomstig is. Om dit te weten te komen, worden 2 verschillende metingen na elkaar uitgevoerd: Na het inschakelen van de motor nemen we een sample en daarna maken we de verbinding van de rode CAN los. De data die we nu nog meten is de zuivere data die de betreffende module op de bus plaatst. We kunnen dan vergelijken of de som van de 2 metingen de zelfde resultaten geeft als een aparte meting. Het zou namelijk kunnen dat een boodschap enkel op de bus gezet wordt als antwoord op een vraag van een andere module. Dat was hier niet het geval. In onderstaande tabel zien we een overzicht van de codes die opgemeten worden van beide modules. EEC COO EBFF F006 ECFF FE5A F000 FE6C F003 FEF1 F004 FEF5 FECA FEFC FEDF FF80 FEE5 FF89 FEE9 FFA0 FEEE FFA1 FEEF FFB0 FEF1 FEF2 FEF6 FF81 FF87 Met de linkerkolom hoeven we in principe geen rekening te houden, daar deze data door de EEC verzonden wordt. De rechter kolom is echter van groter belang voor ons. Dit is de data die door de ECU op de rode CAN-lijn gezet wordt, en wij dus zullen moeten emuleren. 49 120 2000 T erugmeldwaarde gaspedaal T oerental motor Gewenste gaspedaalstand 100 80 1500 60 40 1000 20 0 40000 500 41000 42000 43000 44000 45000 46000 47000 48000 49000 50000 Afbeelding 7: Meetcyclus In afbeelding 6 tonen we de gemeten waarden op de CAN-bus. Voor deze meting waren de coördinator en de EMS met elkaar verbonden. Tijdens de meting is drie maal op het gaspedaal gedrukt. Daar we reeds weten welke pgn's van de motor afkomstig zijn, hebben we nog maar een beperkte set met ID's waarin we moeten zoeken naar de stand van het gaspedaal. We kunnen nu het verloop van de terugmeldwaarde, die we uitlezen in pgn 61443, vergelijken met de andere datavelden. Uit deze manuele vergelijking zien we al snel dat pgn 65408 de gezochte waarde bevat. De benodigde waarde bevindt zich in databyte 2 van deze parametergroep. We weten ook dat er een idle schakelaar op het gaspedaal aanwezig is en vermoeden deze in het derde byte. Daar zien we dat de waarde 0D veranderd naar 0C bij het indrukken van het pedaal. Dit wordt in de volgende verschijning van pgn61443 overgenomen in het eerste byte, de laatste 2 bits. en komt overeen met spn2970, wat normaal de accelerator pedal 2 idle swith zou moeten zijn. Dit bevestigt ons vermoeden dat het derde byte inderdaad de idle schakelaar bevat. Bovendien kunnen we uit de tabel aflezen dat de schakeldrempel voor dit bit op 10% ligt. De derde lijn in afbeelding 6 toont ons het motortoerental. We zien dat dit perfect reageert op de verandering van het gaspedaal, zij het met enige vertraging. Dit toerental kunnen we berekenen uit PGN 61444. 50 De gegevens die we nu nog nodig hebben om de data te versturen, is de timing van al deze boodschappen. In afbeelding 7 zien we de verstreken tijd sinds de vorige verzending van een boodschap. dT COO 220 200 180 FE5A FE6C FEF1 FF80 FFA0 FFA1 FFB0 160 140 dT 120 100 80 60 40 20 0 0 500 1000 1500 2000 2500 3000 3500 T Afbeelding 8: Timing Daar deze grafiekgegevens opgenomen zijn voor een variërend toerental (drie bursts van stationair naar 50% en 100% gas, 570-1800omw/min, zie afbeelding 6) van de motor, kunnen we stellen dat de herhalingstijd onafhankelijk is van het toerental. De variatie die we zien, wordt veroorzaakt door de botsingen op de bus. Op de plaatsen waar we een verdubbeling zien van de tussentijd, kunnen we stellen dat de COO niet probeert om een mislukte poging ogenblikkelijk te herhalen, maar gewoon wacht tot de volgende geplande verzending. Dit is het geval met FEF1 en FFA1. Bij de andere MIDs zal er geprobeerd worden om verder te zenden, tot de boodschap op de bus raakt. Onderstaande tabel heeft de richtwaarden voor de tussentijden. Hier staan ook de codes vermeld die niet in de grafiek weergegeven zijn, omwille van een te grote tijd. 51 COO DT (ms) F006 500 FE5A 100 FE6C 20 FEF1 100 FEF5 2000 FEFC 1000 FF80 20 FF89 1000 FFA0 100 FFA1 100 FFB0 200 De bijhorende datavelden zijn als volgd: 52 6 Elektronica 6.1 Inleiding Van in het begin was het duidelijk dat er elektronica nodig zou zijn om met deze bussystemen te communiceren. In het eerste semester is er dan ook heel wat onderzoek gedaan naar wat er mogelijk is op dat gebied. In wat volgt zullen eerst de eisen geformuleerd worden waar de hardware aan moet voldoen. Zonder bestek kan er immers geen gegronde keuze gemaakt worden. Daar de hardware in eerste instantie gebruikt zal worden in de garage als meetapparatuur, moet deze een zekere mechanische sterkte hebben. Vervolgens zou het mogelijk moeten zijn om uit deze basistoepassing verder te groeien naar een volwaardige stand-alone toepassing, zodat de motor kan gebruikt worden buiten de testomgeving. Hierbij denken we aan generatorsets, onsite testen,... . Deze stand-alone toepassing willen we liefst zo goedkoop mogelijk realiseren. Na een verkennend onderzoek was duidelijk dat Volvo twee verschillende protocollen gebruikt op zijn vrachtwagens: een CAN-bus en een RS-485 bussysteem (zie hoofdstuk 3 en 4). Om deze beide bussen te kunnen monitoren is verschillende hardware nodig. Het te gebruiken systeem (de hardware) zal de beide bussen moeten ondersteunen. Bij de keuze van de hardware is de bijhorende software van zeer groot belang. Gezien mijn beperkte voorkennis omtrent programmeren (Visual Basic, VHDL en noties van C), was een uitgebreid gedocumenteerde API (Aplication Programming Interface) van primordiaal belang voor het welslagen van dit project. In het volgende stuk zal ik de verschillende opties overlopen en hun voor- en nadelen bespreken. 6.2 Commerciële oplossingen: Er zijn verschillende bedrijven die toestellen op de markt brengen die op de één of andere manier communiceren met de CAN-bus. Het aanbod aan deze toestellen is behoorlijk ruim; van zeer goedkope tot zeer dure, van eenvoudige tot complexe. De toestellen verschillen onderling in hardware en software. Na een eerste zoektocht kwam ik vaak dezelfde bedrijfsnamen tegen: nl. Kvaser en Vector. Beiden hebben ze een hele serie aan tools die kenmerkend zijn voor de hele markt. Andere producten zijn vaak afgeleid van de producten van deze twee fabrikanten. Ze maken gebruik van hun software of hardware. De tools variëren van de eenvoudige CAN naar USB-omzetters tot complete testsuites. De bijhorende prijzen variëren van een kleine €100 tot een stevige €5000. De meeste van deze tools (de meest uitgebreide -en navenant dure- systemen buiten beschouwing gelaten) werken allemaal onder toezicht van een pc. Deze tools zijn een zeer interessante optie voor het labo, maar de noodzakelijke afhankelijkheid van een pc is hun grootste nadeel naar verdere ontwikkeling toe. Meer over de bijhorende software kun je terugvinden in het volgende hoofdstuk. National Instruments biedt converters aan die werken met LabView. Deze converters zijn ter beschikking vanaf ongeveer €250 tot meer dan €1000. De mogelijkheden ervan zijn ongeveer vergelijkbaar met het middensegment van Kvaser en Vector. De tijd die nodig is om een licentie te verwerven voor deze software, naast het in acht nemen van een leertijd, zou het in het ter beschikking gestelde tijdsbestek, onmogelijk maken om deze weg te bewandelen. 53 6.3 Alternatieven: In het begin van dit project, toen de keuze van ontwikkelplatform moest gemaakt worden, was ik bezig met de specifieke eisen rond de (verouderde) Volvo FH-reeks. Het probleem daarbij was dat deze reeks over 2 verschillende links beschikt, namelijk een canbus en een RS-485. Geen van bovenstaande producten bood de mogelijkheid om deze 2 kanalen tegelijk te besturen. Een tweede systeem parallel gebruiken was geen optie, omdat de onderlinge relatie en timing op de 2 dataverbindingen gekend moest zijn en de software die bij deze producten geleverd wordt deze mogelijkheid niet biedt. Het was dus noodzakelijk om verder te kijken naar andere mogelijkheden, met name zelfbouw. Voor dit project heb ik verschillende printplaten gebouwd. Daar een complete commerciële testsuite enorm duur is -zeker voor de testen en studiedoeleinden die we bij dit project beogen- is zelfbouw een valabele optie. Een bijkomend voordeel is dat alles precies op maat van het project gemaakt kan worden, met de blijvende mogelijkheid tot uitbreiding in de toekomst. 6.4 Ic's De zoektocht naar meer informatie over de mogelijkheden van zelfbouw, ben ik gestart in de bibliotheek, met name het archief van Elektuur (inmiddels elektor). Uit dit onderzoek kwam al snel de can-explorer naar voor als ideaal instapsysteem. Deze schakeling maakt gebruik van 2 IC's van microchip; de MCP2515 canbus controller en de MCP2551 tranceiver. Een voorbeeld van een netwerk met deze controllers zie je in afbeelding 1. Afbeelding 1: Netwerk met de discrete controller en driver van microchip In onze toepassing zal er slechts één MCP2515 gebruikt worden, samen met een tranceiver. De andere nodes worden gevormd door de controllers in het netwerk van de vrachtwagen. 54 6.5.1 MCP2515 6.5.1.1 Inleiding De belangrijkste chip is de can-controller MCP2515 van Microchip. Deze chip bevat de 2e laag van het osimodel, nl de datalinklaag in de vorm van een state-machine (zie hoofdstuk 4). 6.5.1.2 Onderdelen In het blokschema in afbeelding 2 kunnen we de verschillende delen van de chip onderscheiden. Afbeelding 2: MCP2515 Linksboven zien we de CAN protocol engine. Dit is de module die de boodschappen samenstelt en zorgt dat de data aan de normen voldoet. We slaan het blok met de buffers even over (zie verder) en komen zo bij de SPI-interface. Dit is de andere zijde van de controller. Deze interface verzorgt de verbinding met de achterliggende controller (die de aplicatielaag bevat). In het midden zien we de controlelogica, die alle onderdelen met elkaar verbindt. Links daarvan is de occilatormodule geplaatst. Onder het controleblok zien we de registers die alle instellingen van de interface bevatten. Rechts onderaan zijn er nog een aantal lijnen naar buiten weergegeven. Deze lijnen kunnen gebruikt worden om de microcontroller een signaal te geven over de toestand van de buffers, of om een boodschap te laten versturen uit het geheugen van de can-module. In het midden bovenaan zien we de zend- en ontvangstbuffers. Voor het verzenden zijn er drie geheugenlocaties voorzien. Hier kan een te verzenden boodschap, die verzonden wordt op commando van de spi-interface of getriggerd door de respectievelijke TX_RTS-pin, opgeslagen worden. 55 V o or Afbeelding 3: MCP2551 ontvangst buffer de ontvangst van data zijn er 2 buffers voorzien. De Message Assembly Buffer is de plaats waar de ontvangen boodschappen eerst binnenkomen. Na de volledige ontvangst in de MAB worden deze boodschappen vergeleken met de acceptancefilters en de acceptancemaskers van de twee andere buffers. Met deze filters kun je enkel de boodschappen filteren die voor deze specifieke node noodzakelijk zijn. Ze laten dus toe om de hoofdcontroller te ontlasten van de taak om te bepalen of een bepaalde boodschap al dan niet verwerkt moet worden. Filtering op dit niveau maakt dus heel wat rekentijd vrij in de hoofdcontroller. De ontvangstbuffers zijn verbonden met een externe pin. Indien er een boodschap in een RXB geplaatst is, zal de respectievelijke pin laag gemaakt worden om de microcontroller te laten weten dat er een datapakket klaar staat. Ook kan de MCP2515 via een interupt laten weten aan de hoofdprocessor dat er een geldig datapakket klaar staat. De interrupt-pin is volledig configureerbaar en kan gebruikt worden om elke statuswijziging te laten weten aan de hoofdcontroller. 56 6.5.1.3 Registers In figuur 4 zien we een overzicht van alle registers die in de MCP2515 aanwezig zijn. De belangrijkste registers zullen verder geduid worden in de betrokken secties verder in dit document. Gedetailleerde informatie over elk afzonderlijk register is te vinden in de datasheet. Afbeelding 4: Registermap (gearceerde registers kunnen op bitniveau gewijzigd worden) 6.5.1.4 Verzenden van boodschappen Om een boodschap op de bus te kunnen zetten zijn er 3 zendbuffers (TXB<0-2>) ter beschikking. Deze buffers bestaan uit elk 14 byte ram. De buffers zijn onderling identiek qua opbouw en mogelijkheden. Het eerste byte is TXBnCTRL, waar n het nummer van de buffer is. Hier worden de contolebits voor de betreffende buffer opgeslagen. Vervolgens zijn er 5 bytes om de identifiers en arbitragedata op te slaan, het DLC-byte en acht bytes voor de data. Om een datapakket te verzenden dient op z'n minst TXBnSIDH, TXBnSIDL en DLC geladen te zijn en in ons geval (omdat we altijd met een extended frame werken) ook TXBnEID8 en TXBnEID0. De volgorde waarin de controller de boodschappen op de bus zet, is onafhankelijk van de identifier. In plaats daarvan moet er een prioriteit opgegeven worden in TXBnCTRL. Om het verzenden te starten zijn er verschillende mogelijkheden; rechtstreeks schrijven naar het TXBnCTRL.TXREQ register, via het commando RTSn of door de betreffende TxnRTS pin laag te maken. Vervolgens zal de controller wachten tot de bus vrij is voor hij begint met zenden. Eenmaal een buffer verzonden is, zal de controller automatisch de betreffende TXREQ vlag wissen, het TxnIF bit setten en eventueel een interupt aanvragen. Indien de buffer in de one-shot mode staat, zal bij een mislukte poging de TXREQ vlag ook gewist worden. Indien dit niet het geval is, zal bij een eventuele fout in het verzenden, of bij verloren arbitrage, automatisch opnieuw geprobeerd worden om het bericht te verzenden. In beide gevallen zal bij een fout de TXBnCTRL.TXERR en het CANINTE.MERRE bits geset worden. Bij verloren arbitrage zal bijkomend het TXBnCTRL.MLOA-bit geset worden. Indien de bijhorende error enable bits geactiveerd zijn, zal het setten van deze bits een interupt genereren. Bij het starten van een nieuwe boodschap worden 57 deze bits automatisch gewist. Afbeelding 5: Flowchart verzenden 58 6.5.1.5 Ontvangen van boodschappen In figuur 7 staat de procedure die doorlopen wordt bij het ontvangen van een bericht. Afbeelding 6: Flowchart ontvangen. 59 Afbeelding 7: Overzicht van de ontvangstbuffers en filters In deze controller zitten 2 volwaardige ontvangstbuffers: RXB<0:1> en de MAB (Message Assembly Buffer). In de MAB worden de net ontvangen berichten bewaard tot ze getest zijn aan de verschillende filters (met toepassing van een masker). Indien een bericht aanvaard wordt in één van de buffers zal het bijhorende CANINTF.RXnIF geset worden. Dit bit moet door de MCU gewist worden voor er een nieuw bericht ontvangen kan worden in de buffer. Op het ogenblik dat er een RXnIF geset wordt, zal er ook een interupt gegenereerd worden naar de CPU en zal eventueel ook de bijhorende RXnBF-pin laag gemaakt worden. 6.5.1.6 Interupts Er zijn acht mogelijke bronnen in deze controller die een interupt kunnen genereren. Elk van deze bronnen kan individueel in- of uitgeschakeld worden door het corresponderende bit in CANINTE. Als een interupt gesignaleerd wordt door het laag worden van de INT-pin kan men de bron van deze interupt terug vinden in CANINTF. Volgende bronnen van een interupt zijn mogelijk: • Message Error • Wakeup Interupt • Error Interupt • TXn verzonden • RXn buffer vol 60 6.5.1.7 Reset: De MCP2515 kan zowel hardwarematig als softwarematig gereset worden. De gevolgen van deze resets zijn identiek. 6.5.1.8 Operationele modes De controller kan zich in 5 verschillende mode’s bevinden: • Configuratie • Normaal • Sleep • Listen-only • Loopback. Normaal gezien zal deze controllerchip zich in de Normale mode bevinden, tenzij voor testdoeleinden de listen-only gebruikt wordt. Bij een reset zal de controller zich altijd in configuratiemode bevinden. In deze toestand kunnen verschillende instellingen geladen worden, zoals bijvoorbeeld de boudrate. 6.5.1.9 Oscilator Om te werken heeft deze controllerchip een eigen klok nodig. De chip ondersteunt verschillende bronnen voor de klok, maar in dit geval gebruiken we daar slechts 1 van: een kristal. Standaard gebruiken we een 16MHZ-kristal, samen met 2 condensatoren van 22pF. Afbeelding 8: Klokschakeling 6.5.1.10 SPI-interface De verbinding van de MCP2515 met de achterliggende microcontroller gebeurt via de SPIinterface. Dit is een standaard single-master, multislave interface die op heel veel microcontrollers standaard aanwezig is. In het geval dat deze interface toch niet aanwezig is, is het protocol vaak zo eenvoudig dat het gemakkelijk in software te implementeren is. In de eenvoudigste vorm bestaat deze interface uit 3 draden: • SCK: de klok • SI: data in • SO: data uit. 61 Bij een stijgende flank van de klok zal de data op de SI-pin bemonsterd worden; bij een dalende flank zal de data op de SO-pin geplaatst worden. Op deze manier kan zeer eenvoudig en met weinig middelen data uitgewisseld worden tussen twee digitale systemen. Naast deze drie lijnen is er nog een vierde lijn aanwezig, namelijk de Chip Select. Als deze laag staat, zal er gevolg gegeven worden aan de klok en zullen er dus bits gelezen en weggeschreven worden. Als deze lijn in de hoge toestand staat, dan wordt de SO-pin in hoge impedantie geplaatst en zullen er geen bits ingelezen worden die op de SI-pin aangeboden worden. Dit maakt het mogelijk om meerdere slaves op 1 master aan te sluiten en toch elke slave individueel aan te sturen. Onze controller herkent 9 verschillende commando's; Instructie Binair formaat Beschrijving Reset 1100 0000 Terug keren naar de begintoestand Read 0000 0011 Data lezen beginnende op het adres volgend op de instructie Read RX 10010nm0 Lezen van een RX-buffer gedefinieerd door nm (zie verder datasheet) Write 0000 0010 Data schrijven beginnende op het adres volgend op de instructie Load TX Buffer 0100 0abc Schrijven naar een TX buffer gedefinieerd door abc (zie verder datasheet) Request to send 1000 0nnn Setten van het RTS-bit, elke n staat voor een RTS-bit Read Status 1010 0000 Snelle methode om het statuswoord te lezen RX Status 1011 0000 Retourneert de status van de RX buffers Bit Modify 0000 0101 Laat toe om een enkel bit te wijzigen, enkel geldig op een beperkt aantal registers Het eerste byte dient altijd één van deze commando's te zijn. De volgende bytes die verzonden worden zijn afhankelijk van het commando en volgen gewoon na dat commando. Op het einde van elke instructie dient de CS-lijn even hoog gemaakt te worden. 6.5.2 Mcp2551 De tranceiver zet de ttl niveau's van de controller om in de benodigde spanningen op de bus. Dit is eigenlijk de hardware implementatie van de fysische laag uit het osi-model, besproken in hoofdstuk 3. Het inwendige van dit IC wordt hier nogmaals weergegeven in afbeelding 9. De belangrijkste onderdelen van de tranceiver zijn natuurlijk de drivertransistoren. Hier kun je Afbeelding 9: Driver (vb MCP2551) duidelijk zien dat de dominante staat hard opgelegd wordt en dat de recessieve staat een floating line is. Door de afsluitweerstanden 62 zullen de 2 buslijnen dus op gelijke potentiaal komen op het ogenblik dat er geen enkele driver een dominante status oplegd. Het slope control blok is verantwoordelijk voor de steilheid van de flanken. Indien er problemen zijn met EMI, veroorzaakt door de can-bus, kan de flanksteilheid verlaagd worden door deze pin te gebruiken. Op deze manier worden storingen onderdrukkt. Een speciale beveiliging is ingebouwd onder de vorm van een TXD Dominant Detect. Deze zorgt er voor dat, indien op de TXD-pin een continue dominante staat wordt aangeboden, de driver wordt uitgeschakeld. Hierdoor zal een eventuele fout op de print of in de controller de bus niet volledig onbruikbaar gemaken door een continue dominante staat van één driver. 6.5.3 65HVD21 Na het bestuderen van bovenstaande controllers, ben ik op zoek gegaan naar mogelijkheden om ook de tweede link, de J1587, aan te sturen. Daar de combinatie CAN-RS485 niet gevonden werd in de commerciële producten ben ik op zoek gegaan naar een mogelijkheid ter aanvulling van de MCP2515. Die vond ik in de gedaante van de Texas Instruments 65HVD21 (afbeelding 10). Dit is een RS485 driver-ic. Daar RS485 op logisch niveau compatibel is met RS232, volstaat een controller met een UART Afbeelding 10: 65HVD21 (Universal Asynchronous Receiver Transmitter) aan boord, om deze functionaliteit te integreren. Daar bijna alle microcontrollers dit functieblok aan boord hebben, is het combineren van beide functionaliteiten geen enkel probleem. 63 6.5.4 PIC18F2550 Om al deze bovenstaande logische bouwstenen met elkaar te verbinden, hadden we een controller nodig. Deze kan bestaan uit een pc, zoals in de CAN-explorer (zie verder), ofwel uit een microcontroller. De microcontroller dient dan als een stuurorgaan voor de MCP2515 en de 65HVD21. Daar ik reeds een (weliswaar beperkte) ervaring had met PIC-controllers en er voor deze controllers uitgebreide documentatiebronnen en fora beschikbaar zijn, is mijn keuze op deze familie van microcontrollers gevallen. Er restte echter nog de keuze uit het zeer uitgebreide arsenaal van mogelijke PIC-controllers. Omwille van de eenvoud (lees: mijn beperkte programmeerkennis) werd de keuze beperkt tot de 8-bit reeks (10, 12, 16 en 18 prefix). Verder moest de moeilijke keuze gemaakt worden tussen een controller met geïntegreerde CAN-module of een controller met USB aan boord. Daar de MCP2515 reeds ter beschikking was en ik die al grondig bestudeerd had, is de keuze op een controller met USB gevallen. Er bleef nu nog een familie van 4 controllers over, die onderling verschillen in geheugen en aantal pinnen. In afbeelding 11 staan de verschillen beschreven tussen deze microcontrollers. 64 Afbeelding 11: Onderlinge vergelijking PIC18F2455/2550/4455/4550 Ik koos uiteindelijk voor PIC18F2550-controller, in een 28-pin DIP. 65 Het blokschema van de 28-pin versie van deze controller vind je in figuur 12 Afbeelding 12: Blokschema van de PIC18F2455/2550 66 6.6 CAN-explorer Als eerste schakeling heb ik de Can-explorer gebouwd. Deze schakeling is beschreven in Elektor nummer 532 van februari 2008. Afbeelding 13: Can-explorer Deze schakeling laat toe om de CAN-bus af te luisteren en de boodschappen op de pc zichtbaar te maken. De MCP2515 wordt hier bestuurd vanuit de parallelle poort van de pc. Om alles elektrisch te bufferen zijn tussen de printerpennen en de controller twee 74HCT245N octale bus tranceivers met tristate uitgangen geplaatst. Alle instructies worden uit de pc verzonden met behulp van het programma CANKING van Kvaser. Dit bordje heb ik opgebouwd op een gaatjesbord en is gebruikt om de bussen uit te lezen. Helaas is deze applicatie niet in staat om data op de bus te zetten, zodat ik genoodzaakt was om verder te gaan met een andere schakeling. 67 6.7 Eigen ontwerpen 6.7.1 Inleiding Daar deze eenvoudige schakeling dus niet meer voldeed, moest ik dus op zoek naar een uitgebreider systeem. Ik wou kunnen controleren uit welke richting op de bus de boodschappen komen en dus moest er een soort brug beschikbaar zijn tussen de 2 secties. Omdat er niet direct commerciële oplossingen tegen een betaalbare prijs (voor kort onderzoek) voorhanden zijn, heb ik besloten om een eigen schakeling te ontwerpen. Deze schakeling moet dus in staat zijn om een bestaande bus in 2 delen op te splitsen en moet over een richtingsgevoelige ontvanger beschikken. Ook moet het mogelijk zijn om verbinding te leggen met de J1708-bus. Dit liefst simultaan, zodat ook de onderlinge timing van de boodschappen kan gelogd worden. Om deze schakeling te bouwen, moeten er heel wat ontwerpkeuzes gemaakt worden. De eerste keuze is de communicatie met de pc. Volgende mogelijkheden werden tegen elkaar afgewogen: • de printerpoort • de seriële verbinding • de USB-poort. De schakeling van Elektor maakt gebruik van de printerpoort. Daar dit een oude en relatief trage poort is die op nieuwe pc's maar zelden meer gevonden wordt, is dit geen optie meer voor de nieuwe versie. Een andere mogelijkheid is de seriële verbinding. Deze is relatief eenvoudig aan te sturen en is uitgebreid gedocumenteerd op het internet. Maar ook deze poort begint zeldzaam te worden en bovendien is de dataoverdracht ook relatief traag. Ten slotte is er de USB-poort. Dit is de defacto standaard voor nieuwe hardware. Deze poort is echter heel wat complexer in gebruik dan de hiervoor besproken opties. Dit bemoeilijkt het ontwerpproces heel sterk. Bij deze optie is de snelheid echter geen bottleneck meer en kunnen er meerdere transmitters aangesloten worden op 1 poort. 6.7.2 USB 2 CAN (Zie afbeeldingen 14 en 15) Om het mogelijk te maken de sectie van waar de signalen komen te onderscheiden, maak ik een 'bridge' met twee tranceivers. De TX- en RX-pinnen knopen we aan elkaar. Hierdoor zal wat door de ene ontvangen wordt zonder vertraging doorgegeven worden door de andere. Indien we nu op beide signaallijnen een ontvanger plaatsen in de vorm van 2 x de MCP2515 hebben we de beschikking over 2 onafhankelijke ontvangers. Door middel van 2 jumpers kan gekozen worden tussen een stereo- of een monoversie. In de enkelvoudige mode, kan er ook data verzonden worden uit de pc. Dit is niet mogelijk indien van de richtingsdetectie gebruik gemaakt wordt. De twee CAN-controllers zijn met de microcontroller verbonden door een SPI-bus. De microcontroller heeft hardware ingebouwd om met deze bus te werken en dus is deze bus aangesloten op de daarvoor bestemde pinnen. Pinnen 10 en 11 van de MCP2515 signaleren een ontvangen bericht in hun ontvangstbuffer. Deze pinnen zijn aangesloten op RB4-RB7 van de pic zodat deze een interupt genereren. De bovenste MCP2515 heeft nog 3 lijnen die gebruikt kunnen worden om instantaan een datapakket dat in hun verzendbuffer zit te versturen. Deze pinnen zijn aangesloten op poort A. Ook de reset voor beide controllers is verbonden met deze poort. 68 Vervolgens is er op de resterende pinnen van RB3 nog een RS485 tranceiver aangesloten om ook communicatie met de J1708 bus mogelijk te maken. Als laatste zijn de standaardcircuits bijgevoegd, zijnde de voeding, de oscilatoren en de USBconnector op RC4 en RC5. Omdat er behoorlijk wat verbindingen moesten gelegd worden die een hoge datarate hebben, heb ik voor deze schakeling een printplaat ontworpen. Dit biedt een stabielere oplossing dan het opbouwen op een gaatjesbord. Om deze schakeling te tekenen en vervolgens hier een print van te ontwerpen, heb ik gebruik gemaakt van het pakket EAGLE. Daar het ook de eerste keer was dat ik een print moest ontwerpen, heb ik daar toch wel wat tijd aan besteed. Op de site van microchip zijn verschillende voorbeeld-printlayouts te vinden, evenals ontwerptips om met deze ic's aan de slag te gaan en op een correcte methode te plaatsen. Ondanks deze voorzorgen zaten er nog enkele foutjes in het ontwerp. Zo waren de datalijnen op de usb-conector omgewisseld. Dit heb ik kunnen oplossen door de usb-poort op de achterkant van de printplaat te monteren. Ten tweede heb ik de verkeerde printkroonsteentjes gekocht en kwam de afstand tussen de pennen niet overeen met de afstand op de print. Als gevolg moesten de aansluitingen rechtstreeks op de print gesoldeerd worden. Als laatste ontwerpfout ontdekte ik dat het niet slim was om printsporen naar elko's en cristallen aan de componentenzijde te plaatsen. Hierdoor moest ik deze op enkele mm van het oppervlak monteren om er nog bij te kunnen met de tip van de soldeerbout. Alles was nu elektrisch in orde, maar helaas bleek het concept van de schakeling niet te werken. Het bleek niet mogelijk om te ontdekken welke kant van de bus nu de data op de lijnen plaatste. De tranceivers die de data doorgeven van de ene sectie naar de andere dienen in beide richtingen aangesloten te zijn en de 2 aanwezige controllers kunnen geen onderscheid tussen de richting waar de data vandaan komt, daar beide lijnen continu op het zelfde potentiaal staan. Zodra een tranceiver een dominante staat op de bus zet via de write-lijn, leest hij die dominante staat uit op de read lijn. Dit maakt de schakeling praktisch onbruikbaar. Ook bleek het ontwikkelen van een eigen USB-verbinding met de pc zeer complex, ondanks de uitgebreide toolset op de site van microchip,. Het ontwerpen from scratch is praktisch onmogelijk, dus heb ik dan maar een aantal voorbeelden opgezocht op het internet. Daar dit hoofdzakelijk om software draait, zijn deze zijsprongen verder uitgewerkt in het software hoofdstuk. Eenmaal dat bleek dat het oorspronkelijke concept van de schakeling niet voldeed, heb ik de print omgebouwd. De controller werd vervangen door de PICkit Serial Analyzer van microchip en de tweede MCP2515 werd verwijderd. Ook de RS485-module moest, voorlopig, sneuvelen. Op deze manier konden we data uitlezen van de bus en zichtbaar maken op de pc. Ondanks het feit dat schrijven principieel mogelijk was, is dit nooit volledig uitgewerkt gezien de traagheid ervan. 69 Afbeelding 14: Schema USB 2 CAN Afbeelding 15: Print-layout USB 2 CAN 70 6.7.3 CANtroller Mijn tweede ontwerp, de CANtroller is een stuk bescheidener van ontwerp. De bedoeling is dat deze print in eerste instantie zelfstandig kan werken, zonder tussenkomst van een pc. Dit ontwerp bestaat dus uit de controller PIC18F2550, een mcp2515, mcp2551 en een voedingsdeel. Op de pic is een potentiometer aangesloten waarmee we een parameter, de gaspedaalstand, ingeven. Er is ook een uitbreidingsconnector aanwezig die kan dienen als aansluiting voor de PKSA, zodat deze schakeling eventueel toch nog aan de pc kan verbonden worden via I²C. Om pinnen te sparen zijn de TX en de BF-pinnen van de mcp2515 niet meer aangesloten. Dit zou bovendien de software alleen maar complexer maken. Al de commando's worden nu via de software en de interuptpin gegeven. 71 6.8 PICkit Serial Analyzer In afbeelding 16 zien we een afbeelding van de PICkit serial analyzer. Dit is een ontwikkeltool van Microchip die dienst doet als een verbinding tussen pc en de hardware. Dit board kan fungeren als een SPI, I²C, asynchrone of synchrone USART. Deze schakeling communiceert met het embedded systeem via een 6-polige connector. Afbeelding 16: PICkit Serial Analyser Daar deze schakeling zeer flexibel te programmeren valt, is deze zeer eenvoudig aan te passen aan de schakeling waar deze in gebruikt wordt. Afbeelding 17: Systeemoverzicht PKSA De interface uit afbeelding 18 met het embedded systeem bestaat uit 6 pinnen die afhankelijk van de toepassing een andere functie krijgen. 72 Afbeelding 18: Pin-configuratie PKSA In de test-fase heb ik ook gebruik gemaakt van het 28-pin DEMO I²C board. Dit bord bevat een piccontroller die een eeprom en een real time klok emuleert. Daar dit gebruik enkel als inlering bedoeld was, verwijs ik verder naar de betreffende handleiding op de site van microchip. Tijdens de ontwikkeling is er van deze schakeling ook een eenvoudige versie gemaakt die gebruik maakt van de PCB die voor de USB2CAN ontwikkeld werd. Deze modificatie bestond er in dat de uitgangsdrivers die in de originele versie aanwezig zijn niet gebruikt worden. De schakeling wordt dus direct aangesloten op de pinnen van de PIC-controller. 6.9 Varia In de loop van de stageperiode zijn er een aantal eenvoudige testopstellingen opgebouwd op een steekbordje, om enkele functies te testen, die daarna opgebouwd zijn op een gaatjesbord. Dit zijn bijvoorbeeld het resetcircuit van de MCP2515 en de eerste vereenvoudigde versie van de PKSA. Terwijl ik bezig was met het evalueren van de mogelijkheid om alles vanuit LABView aan te sturen, heb ik gebruik gemaakt van een zeer eenvoudige schakeling die enkel uit een PIC18F2550, een 20MHz kristal en wat condensatoren bestond. Dit is een standaardschakeling om een controller aan de USB-poort te koppelen. 73 7 Software. 7.1 Inleiding In dit hoofdstuk wordt alle software besproken die gebruikt is om dit eindwerk tot stand te laten komen. In de mate van het mogelijke zal er parallel gewerkt worden met hoofdstuk 7: elektronica. In de eerste plaats was het de bedoeling om een kant en klaar product te zoeken, dat onze doelstellingen zou kunnen concretiseren. Er diende echter ook zelf software geschreven te worden. Mijn beperkte kennis van programmeren in C++ (of andere afgeleide talen, waar de meeste tools gebruik van maken) heeft mij in belangrijke mate beperkt in het uitvoeren van dit eindwerk. 7.2 Commerciële oplossingen Samen met de hardware (hoofdstuk 7 §1) bieden de firma’s Kvaser en Vector uiteenlopende software aan. De door hen geproduceerde software is, net als hun hardware, kenmerkend voor de gehele markt. Het productgamma gaat van eenvoudige tools tot zeer complexe. De prijs van deze tools loopt dan ook uiteen van freeware, tot enkele duizenden euro's. Omwille van de redenen aangehaald in het vorige hoofdstuk, nl. prijs, bruikbaarheid (de meeste van deze programma's zijn enkel beperkt bruikbaar als testsuite, niet in een finale toepassing) en leercurve zijn programma’s van deze firma’s in eerste instantie verworpen voor gebruik binnen dit eindwerk. Van veel toepassingen is het niet duidelijk welke onderdelen en bijbehorende kosten, noodzakelijk zijn om een werkend systeem op te bouwen. Bij de goedkope producten, is dan vaak vereist dat de gebruiker zelf een eigen programma ontwerpt, en is de API niet duidelijk gedocumenteerd (liefst met voorbeeldcode). Dit was voor dit werk echter noodzakelijk omwille van mijn, al eerder aangehaalde, beperkte kennis van het programmeren. Een economisch en bruikbaar product, CAN-explorer, werd gevonden in het Elektuur-artikel CANExplorer (Krüger F., 2008). Bijbehorende software is ter beschikking en de mogelijkheden van de goedkope systemen worden aangeboden tegen een zeer gunstige prijs; namelijk de onderdelenprijs van de IC's. Met dit systeem is al heel wat mogelijk, en derhalve is besloten om daarmee verder te werken. Verder in de stageperiode werd duidelijk dat het ontwikkelen van een eigen programma niet zo eenvoudig was als eerst begroot. Aangezien de leercurve van de complexe software behoorlijk steil is, was het dan te laat om nog over te stappen op een complexer en navenant duur systeem van bijvoorbeeld Kvaser of National Instruments. Naast deze hoofdzakelijk praktische redenen voor het gebruik van eigen software, moeten we ook verder kijken. Indien gewerkt zou worden met volledig voorgeprogrammeerde software, zou dit proces opnieuw doorlopen moeten worden om tot een standalone applicatie te komen. Het spreekt voor zich dat, indien het eenvoudiger en goedkoper kan, het niet de bedoeling is dat per afgeleverde motor een pc met bijhorende softwarelicenties aangeschaft moet worden door de generatorfabrikant. 7.3 Alternatieven Gelijklopend met de hardware, is er onderzoek gedaan naar de softwarematige oplossingen / mogelijkheden die Microchip ter beschikking stelt. Daar de eerste testen gebruik maakten van de 74 CAN-explorer, deze IC's ter beschikking waren en Microchip een degelijke ondersteuning biedt in de vorm van Application Notes en programmeervoorbeelden, is besloten gebruik te maken van de Microship ontwikkeltools. 7.4 Can-explorer Aan de pc-zijde wordt gebruik gemaakt van de software van Kvaser: nl. CANKing. Deze software laat toe om over de parallelle poort te communiceren met een CAN-bus. Tevens kan deze module zelf boodschappen filteren en deze weergeven op het scherm. In het begin van de stageperiode bij Turbo's Hoet is deze schakeling gebruikt om de communicatie af te luisteren. De schakeling doet perfect waar hij voor gebouwd is, maar Afbeelding 1: About CANKing we kunnen er de richting van de boodschappen niet mee bepalen. Het bepalen van de richting van de boodschappen zal echter noodzakelijk zijn om te weten welke berichten gesimuleerd moeten worden en wat we kunnen verwachten als antwoord van de ECU. Ook laat de Can-explorer niet toe om de data op de J1708link uit te lezen of zelf data te versturen op deze bus. 7.4.1 Werkwijze In hoofdstuk 6 zijn de boodschappen opgetekend die bepaald zijn met deze software. In volgende paragraaf zal beschreven worden hoe deze data bepaald kan worden. In eerste instantie wordt geprobeerd om van zo veel mogelijk controllers de stekkers te verwijderen, om de busbelasting zo laag mogelijk te maken. Dit wordt gedaan tot de motor niet meer op de normale manier wil starten, of niet meer reageert op het gaspedaal. Op het ogenblik dat de motor net wel nog start en reageert is het minimum aantal boodschappen op de bus aanwezig. In het geval van de Scania R, waar deze resultaten op gebaseerd zijn, zijn dan enkel de ECU en de COO nog aangekoppeld. Vervolgens wordt de CAN-explorer aangesloten op de rode CANbus. Pin 7 van de MCP2551wordt verbonden met de rode draad (CANH), pin 6 met de witte draad (CANL). Dan wordt de CANexplorer onder spanning gebracht. Vervolgens starten we CANKing Kies na het opstarten van CANKing voor template en MCP2515 basic. Druk OK en het basisvenster van CANKing verschijnt (Afbeelding 2). Op het controlevenster dienen eerst enkele parameters ingesteld te worden. De betrokken parameters zijn te vinden op het tabblad ‘Bus Parameters’. Selecteer hier 250.000 kbit/s. Laat de andere parameters zoals ze zijn (Sampling Point 75%, SJW $2 en Driver Mode Normal). Klik op Apply en ga terug naar tabblad ‘Bus Statistics’. 75 Afbeelding 2: CANKing Na een druk op ‘Go On Bus’, zal de MCP2515 data beginnen doorsturen naar de PC. Deze data verschijnt in het output window. Standaard zal voor elke boodschap een nieuwe regel aangemaakt worden. Voor sommige metingen is dit de aangewezen methode (bepalen van tussentijd), voor andere metingen is het eenvoudiger als bestaande boodschappen telkens geüpdated worden. In afbeelding 3 is CANKing in werking te zien. In het output window worden de data in een aantal kolommen weergegeven. 76 Afbeelding 3: CANKing in werking De eerste kolom is de identifier. Dit is de decimale weergave van het 29- bit ID-veld. De ‘x’ in de FLG kolom geeft aan dat het om een extended identifier gaat. Daar J1939 enkel gebruik maakt van extended identifiers, is dit dus altijd een ‘x’. Vervolgens is er een kolom met de DLC. Meestal zal deze 8 databytes (enkel bij adresclaiming maakt J1939 gebruik van 3 databytes) aangeven. De volgende 8 kolomen geven de databytes weer. De laatste twee kolomen geven respectievelijk de tijd en de richting aan. Aangezien met deze applicatie enkel berichten ontvangen kunnen worden, is dit altijd een R(eceive). Indien deze weergave niet voldoet, kun je in het scherm ‘Select Formatters’ de weergave aanpassen. Klik hiervoor eerst op ‘Standard Text Format’ en vervolgens op ‘Options’. Er kan hier bv. voor een hexadecimale notatie van de data gekozen worden (vergemakkelijkt het bekijken van bitpatronen). Door rechts te klikken in het ‘Output Window’ kun je ‘fixed positions’ selecteren. Indien een identifier dan reeds voorkomt in het scherm, wordt de oude data overschreven. Dit biedt uitermate interessante mogelijkheden voor het zoeken naar berichten. Erg veel bewerkingen kun je in de Microchip-versie niet doen (enkel deze versie heeft een driver voor de MCP2515) en dus moet de data geëxporteerd worden naar een rekenblad. Dit kan door de data eerst te exporteren naar een ASCII tekstbestand (.txt) en dan te importeren (kopiëren en plakken) in het rekenblad. Selecteer bij het importeren als scheidingsteken een spatie en vink scheidingstekens samenvoegen aan (Afbeelding 4). Na het importeren in het rekenblad kunnen er bewerkingen op losgelaten worden. 77 Afbeelding 4: Tekst importeren 7.4.2 Bewerkingen 7.4.2.1 Identifier De identifier dient in de eerste plaats gesplitst te worden. Daar dit de complete 29 bit identifier is zoals gedefinieerd in CAN, moet deze nog opgesplitst worden tot de velden zoals in de J1939 standaard. In afbeelding 5 is een overzicht van de indeling opgenomen. Afbeelding 5: Indeling ID De drie MSB's (28-26) geven de prioriteit. Deze kunnen afgezonderd worden door het hexadecimale ID om te zetten naar een decimale en vervolgens naar een binaire waarde, daarna de eerste 3 bits te nemen en dan terug om te zetten naar een decimale waarde; =BIN.N.DEC(DEEL(BASIS(HEX.N.DEC(ID);2);1;3)) Let op! Voorloopnullen worden in de bewerking niet meegenomen. Dit is belangrijk bij prioriteiten 1, 2 en 3, want hier zijn voorloopnullen. Ook alle volgende bewerkingen dienen hier rekening mee te houden, want de gehele combinatie kan hierdoor 1 of 2 bits verschuiven. Op de zelfde manier kun je ook de PDU geheel of afzonderlijk uit het bericht halen: PF: =256*BIN.N.DEC(DEEL(BASIS(HEX.N.DEC(ID);2);6;8)) Destination: =BIN.N.DEC(DEEL(BASIS(HEX.N.DEC(ID);2);14;8)) PDU: =256*BIN.N.DEC(DEEL(BASIS(HEX.N.DEC(ID);2);6;8)) 78 +BIN.N.DEC(DEEL(BASIS(HEX.N.DEC(ID);2);14;8)) Tot slot kun je ook het Source Address uit het ID op splitsen: =DEEL(BASIS(HEX.N.DEC(ID);2);21;8) 7.4.2.2 Data De data kan op een gelijkaardige manier omgezet worden. Deze data dient (indien alles geïmporteerd is in hexadecimale waarden) eerst omgezet te worden naar decimalen. Vervolgens kan de data omgezet worden met de gegevens uit SAE J1939 (2009). 7.4.2.3 Tijden Tussentijden zijn te bepalen door eerst alles te sorteren op ID en vervolgens op de tijdstempel. Door het aanmaken van een extra kolom met het verschil tussen twee opeenvolgende boodschappen kan de tussentijd bepaald worden. Om een duidelijker overzicht te krijgen, kunnen de resultaten best in grafiekvorm weergegeven worden. 79 7.5 MCP2515 Het gekozen IC; de MCP2515, dient ingesteld te worden voor onze toepassing. 7.5.1 Configuratie De timing is daar de belangrijkste van. De MCP2515 is behoorlijk ingewikkeld om in te stellen met betrekking tot de baudrate. Alle CAN-controllers hebben deze complexe werkwijze echter op gelijkaardige manier geïmplementeerd. Eén bittijd wordt onderverdeeld in 4 verschillende zones (zie Afbeelding 6). Deze zones gebruikt de controller voor de synchronisatie, daar de zender en ontvanger op verschillende klokken draaien. Elk van deze zones zijn een veelvoud van een interne klok. De periode van deze klok noemt men een Time Quantum (TQ). Deze wordt intern bepaald met behulp van een PLL uit de externe oscilator. J1939 heeft een baudrate van 250kBit/s. De bittijd wordt onderverdeeld in 16 Afbeelding 6: Onderverdeling bittijd TQ's. Dit geeft dat 1 TQ 250µs lang is. De BaudRatePrescaler bepaald de verhouding tussen Tosc en TQ aan de hand van volgende formule: TQ = 2 x BRP x Tosc. Hieruit volgt dat BRP 2 moet zijn. Er moet echter een 1 in de registers geladen worden, want er wordt automatisch 1 bij opgeteld daar een BRP van 0 niet kan. Ook de lengte van de drie laatste segmenten moet geprogrammeerd worden. Eén bittijd wordt hier verdeeld in 16 TQ's. Deze worden naar voorbeeld van de datasheet verdeeld als volgt: Propseg = 2 TQ, PS1 = 7 TQ en PS2 = 6 TQ. De SynchronisationJumpWidth is de stapgrootte waarmee PS1 en/of PS2 aangepast worden om de timing terug juist te krijgen. Deze stellen we op 1. Dit geeft de waarde 65 die in het CNF1 register geplaatst wordt op adres 2Ah. BTLMODE = 0 bepaald dat de waarde voor PS2 opgeven zal moeten worden in CNF3. SAM wordt op 0 gezet om één maal te samplen. PHSEG1<2..0> bepaalt de lengte van PS1, dus moet dit 7 zijn. PRSEG<2..0> bepaalt de lengte van PropSeg. Dit is dus 2. Als CNF2 dient dus 00111010 of decimaal 58 geschreven te worden op adres 29h. Als derde moet CNF3 bepaald worden. Dit bevat SOF = 0 (deze functie wordt niet gebruikt) en WAKFIL 0 (uit). De laatste 3 bits bepalen de lengte van PS2 nl. 6. Dit is meteen ook de waarde die naar CNF3 op adres 28h geschreven wordt. Vervolgens worden de interrupts ingesteld. Dit gebeurt met behulp van het CANINTE-register. Voor de exacte betekenis van elk bit in dit register, wordt verwezen naar de datasheet van de MCP2515. Na het schrijven van deze configuratiewaarden, kan de MCP2515 omgeschakeld worden naar de normale werking. Dit gebeurt door b000 te schrijven naar de eerste 3 bits van het CANCTRLregister. Indien de andere bits ook nog moeten geset worden, kan dit met een gewone write operatie via SPI; indien dit niet gewenst is, met een bit modify commando. Na deze operaties is de controller ingesteld om berichten te verzenden en/of te ontvangen. 80 7.5.2 Commando's De MCP2515 wordt via de SPI-interface aangestuurd. Via deze interface kan de controller bediend worden. Elk commando begint met het laag maken van de CS-lijn. Na het in acht nemen van een korte pauze om de controller de kans te geven zich klaar te maken voor ontvangst, kan dan via de SPIverbinding een commando gegeven worden. Mogelijke commando's zijn te vinden in afbeelding 7 Afbeelding 7: Comando's van MCP2515 Afhankelijk van het commando, zullen er daarna eventueel nog een of meerdere bytes met data volgen. 7.5.3 Opmerkingen Indien het niet gewenst is om boodschappen te ontvangen, zijn er twee manieren om in dit geval de MCP2515 ervan te weerhouden om boodschappen te accepteren: ofwel door met de acceptance filters een precieze boodschap in te stellen die niet in het repertoire van de ECU voorkomt ofwel door het RXBxCTRL.RXM-register op 01 te zetten. Deze laatste methode weerhoudt de controller ervan om boodschappen met een extended identifier te accepteren. (MCP2515 datasheet p27, 2007). Hardware werkt uiteraard niet zonder bijpassende software. De software in dit project zal bestaan uit twee verschillende delen. Het ene deel draait op de pc en vormt de communicatie met de gebruiker, terwijl het andere deel door de microcontroller uitgevoerd wordt. Deze programma’s worden elk afzonderlijk besproken. Omdat de controller het belangrijkste werk moet doen, wordt deze als eerste besproken. 81 Het programma in de controller is geschreven in de programmeertal C. Assembler zou in principe ook kunnen, maar is behoorlijk ingewikkeld, vnl. om achteraf de werking van het programma te begrijpen. De C-taal is gekozen omdat deze relatief eenvoudig is, maar tegelijkertijd toch een relatief grote abstractiegraad biedt ten opzichte van assembler. De controller bevat een hele rits aan subroutines die elk hun eigen taak hebben binnen het geheel. Eerst wordt de CAN-module besproken, omdat deze module de eigenlijke kern van dit project is. CanInit CanInit wordt aangeroepen na het hoog maken van de juiste CS-lijn. CanInit verzorgd de instellingen van de CAN-controller. Verderop in dit werk (zie MCP2515) zal beschreven worden hoe de instellingen bepaald worden. 7.6 USB Initieel was het de bedoeling om de CANtroller via USB te laten communiceren. Doordat er uitgegaan was van 2 gelijktijdige kanalen van 250kbit/s (gebruikt met een busbelasting van 50%, overhead van 25%) bleek RS-232 niet snel genoeg. De parallelle poort is moeilijker te programmeren en is bovendien een zeldzaamheid geworden op pc en laptop. Microchip bood evenwel de aantrekkelijke belofte van eenvoudige USB-implementatie. 7.6.1 Eerste testen Aan de hand van het Microchip MCHPFSUSB Framework v2.4 is een poging ondernomen om USB zelf te implementeren. Helaas bleek dit niet zo straigt-forward als door microchip beloofd wordt. De implementatie van dit protocol zou een zeer diepgaande studie van USB noodzakelijk maken en zou op zich al het onderwerp kunnen uitmaken van een eindwerk. Vervolgens zijn een aantal kleinere projecten bekeken, die al een USB-interface aan boord hadden, met de bedoeling deze aan te passen aan de noden van dit eindwerk. Een bruikbaar project is niet direct gevonden. Alle geschreven code is te complex om snel aan te passen. Het dichtst in de buurt komende ontwerp was de USBSine interface van Osolong (2007). Dit project bood de communicatie tussen de pc met labview en een PIC18F2550. Dit werkte naar behoren, maar de minste aanpassingen in labview maakten het project onbruikbaar. Daar dit complexe materie is, veel ingewikkelder dan een klassiek Virtual Instrument, is een grondige kennis van labview noodzakelijk om dit op te lossen. Daarom is deze mogelijkheid overgeslagen. 7.6.2 PICKit Serial Analyzer Na bovenstaande beproevingen, bleek dat zelf communicatie ontwerpen niet zo eenvoudig is en is onderzoek gedaan naar de mogelijkheid om een USB naar SPI interface te gebruiken. Dit zou echter betekenen dat het geplande ontwerp met twee of drie kanalen niet uit te voeren is. Deze functionaliteit werd opgegeven ten voordele van eenvoudigere communicatie. Hier komt de PKSA in beeld. Dit is een ontwikkelplatform van Microchip, dat bestaat uit een print met een PIC18F2550 controller, passende firmware en een DLL die de communicatie uit de PCzijde regelt. Deze API is zeer uitgebreid gedocumenteerd en bevat duidelijke voorbeelden. Op basis van dit systeem is een applicatie ontwikkeld in Visual Basic. 82 7.7 DataTap 7.7.1 Inleiding In afbeelding 8 is het hoofdscherm te zien van het datatap scherm. Deze applicatie is speciaal voor dit project ontwikkeld op basis van de PKSA DLL. Na initialisatie van de PKSA wordt de MCP2515 opgestart in listen-only mode, waarna de data binnen gelezen wordt. Deze data wordt dan weergegeven in het bovenste tekstvak. Het was de bedoeling om dit project verder uit te bouwen, zodat hieruit direct een lijst te maken zou zijn met data die naar de ECU gestuurd dient te worden. Helaas bleek de PKSA niet snel genoeg om de data over te hevelen. Slechts 2 tot 3% van de boodschappen op de bus bereikten het scherm. De implicatie van dit probleem was dat er meer intelligentie in de microcontroller dient te zitten en minder op de PC. Afbeelding 8: Datatap scherm van de PC applicatie 83 7.7.2 Programmacode achter het datatap scherm Public Class FormListenOnly Private Sub FormListenOnly_FormClosed(ByVal sender As Object, ByVal e As System.Windows.Forms.FormClosedEventArgs) Handles Me.FormClosed PICkitS.Device.Cleanup() End Sub Private Sub FormListenOnly_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load If Can_bus.SetSPI() Then Can_bus.SetTiming() Can_bus.SetMode(3) End If ToolTip1.SetToolTip(BtnShowSourceAddr, "Toon alle PGN's met zelfde bronadres") TmrRead.Enabled = True 'lus() End Sub Private Sub BtnADDStatus_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles BtnADDStatus.Click End Sub Private Sub BtnADDValue_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles BtnADDValue.Click DlgAddValue.ShowDialog() End Sub Private Sub LstSourceAddr_MouseDoubleClick(ByVal sender As Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles LstSourceAddr.MouseDoubleClick InputBox("Voer de naam van de bron in", LstSourceAddr.SelectedIndex) End Sub Private Sub TmrRead_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles TmrRead.Tick TmrRead.Enabled = False Dim actie As Byte = Can_bus.CheckIncomingData() Dim ID As Integer Dim strID As String If actie <> 255 Then ID = Can_bus.RXB0ID(0) 'sidH ID = (ID << 3) + (Can_bus.RXB0ID(1) >> 5) 'sidL ID = (ID << 2) + (Can_bus.RXB0ID(1) And &H3) 'eid17 and 16 ID = (ID << 8) + Can_bus.RXB0ID(2) 'eid8 ID = (ID << 8) + Can_bus.RXB0ID(3) 'eid0 strID = CStr((ID >> 8) And &H3FFFF) 'remove right 8bit and left 3bit ==> PGN, then convert to string Dim exist As Boolean = False For index As Integer = 1 To LstPGN.Items.Count 'search if current pgn exist in the list If strID = LstPGN.Items.Item(index - 1) Then exist = True 'item found Exit For End If Next If exist = False Then 'if item not found LstPGN.Items.Add(strID) 'add item Me.Refresh() End If End If TmrRead.Enabled = True End Sub 84 Private Sub lus() Dim actie As Byte = Can_bus.CheckIncomingData() Dim ID As Integer Dim strID As String Me.Show() While True actie = Can_bus.CheckIncomingData If actie = 0 Then ID = Can_bus.RXB0ID(0) ID = (ID << 3) + (Can_bus.RXB0ID(1) >> 5) ID = (ID << 2) + (Can_bus.RXB0ID(1) And &H3) ID = (ID << 8) + Can_bus.RXB0ID(2) ID = (ID << 8) + Can_bus.RXB0ID(3) strID = CStr((ID >> 8) And &H3FFFF) and left 3bit ==> PGN, then convert to string Dim exist As Boolean = False If LstPGN.Items.Count <> 0 Then For index As Integer = 0 To LstPGN.Items.Count current pgn exist in the list If strID = LstPGN.Items.Item(index) Then exist = True Exit For End If Next If exist = False Then found LstPGN.Items.Add(strID) End If End If End If Me.Refresh() End While End Sub 'sidH 'sidL 'eid17 and 16 'eid8 'eid0 'remove right 8bit 'search if 'item found 'if item not 'add item Private Sub ToolStrip1_ItemClicked(ByVal sender As System.Object, ByVal e As System.Windows.Forms.ToolStripItemClickedEventArgs) Handles ToolStrip1.ItemClicked End Sub End Class 7.7.3 Programmacode in de CAN-module Module Can_bus '---------------------------------------------------------------------------------' '-- module contains all procedure's and data for accessing a J1939 network --' '-- This code uses the microchip PICKIT Serial Analyzer firmware to control --' '-- a microchip MCP2515 canbus controller. --' '-- Reference DS21801E - MCP2515 --' '-DS51647B - PICkit Serial Analyzer --' '---------------------------------------------------------------------------------' '---' '-- Written by: __________________________ --' '-B. ZWAENEPOEL --' '-- for __________________________ --' '---' '-Turbo's Hoet --' '-and KHBO dep. IW&T --' '---' '-P. Deckmyn --' '-P. D'Hulster --' '---' '-- c2009 --' '---------------------------------------------------------------------------------' 'Buffer's for passing data to other modules 85 'ID-buffer's Public RXB0ID(4) As Byte Public RXB1ID(4) As Byte 'Data-buffer's Public RXB0D(8) As Byte Public RXB1D(8) As Byte Public Sub SetTiming() 'Configuratie van de timing 'Details in DS MCP2515 p.37 Dim ConfigData(4) As Byte Dim Return_Str As String = "" ConfigData(0) = &HC0 'reset If PICkitS.SPIM.Send_Data(1, ConfigData, True, True, Return_Str) Then ConfigData(0) = &H2 'write command ConfigData(1) = &H28 'adress of cnf3 ConfigData(2) = &H6 'cnf3 ConfigData(3) = &H58 'cnf2 ConfigData(4) = &H65 'cnf1 If PICkitS.SPIM.Send_Data(5, ConfigData, True, True, Return_Str) Then Else MsgBox("Configuratie van de CAN-controller mislukt - timing data", MsgBoxStyle.OkOnly, "Configuratie error") FormListenOnly.Close() End If Else MsgBox("Configuratie van de CAN-controller mislukt - reset", MsgBoxStyle.OkOnly, "Configuratie error") FormListenOnly.Close() End If 'MsgBox(Return_Str) End Sub Public Sub SetMode(ByVal Mode As Byte) 'Hier wordt de mode van de controller gezet 'mode 0: Normal 'mode 1: Sleep 'mode 2: Loopback 'mode 3: Listen-only 'mode 4: config mode 'Details in DS MCP2515 p.58 Dim ConfigData(2) As Byte Dim Return_Str As String = "" ConfigData(0) = &H2 ConfigData(1) = &HF 'write command 'adress of ConfigData(2) = Mode << 5 'Allign mode bits CANCTRL left PICkitS.SPIM.Send_Data(3, ConfigData, True, True, Return_Str) ConfigData(0) = &H3 'read command ConfigData(1) = &HE 'CANSTAT PICkitS.SPIM.Send_Data(2, ConfigData, True, False, Return_Str) PICkitS.SPIM.Receive_Data(1, ConfigData, False, True, Return_Str) If ((ConfigData(2) And &HE0) <> (ConfigData(0) And &HE0)) Then MsgBox("Configuratie van de CAN-controller mislukt - mode", MsgBoxStyle.OkOnly, "Configuratie error") FormListenOnly.Close() Else MsgBox("Configuratie ok", MsgBoxStyle.OkOnly) End If End Sub 86 Public Function SetSPI() As Boolean 'Configureert de pksa als spi-master op 1MHz 'retourneert true als de configuratie gelukt is 'Dim status As Boolean If (PICkitS.Device.Initialize_PICkitSerial()) Then If (PICkitS.SPIM.Configure_PICkitSerial_For_SPIMaster()) Then PICkitS.SPIM.Set_SPI_BitRate(1000) 'bitrate 1MHz Return True 'config SPI OK Else MsgBox("Herprogrammeer de firmware in de controller", MsgBoxStyle.OkOnly, "Firmware error") FormListenOnly.Close() Return False End If Else MsgBox("Controleer de USB-verbinding van de CANController", MsgBoxStyle.OkOnly, "CANController niet gevonden") FormListenOnly.Close() Return False End If End Function Public Function CheckIncomingData() As Byte 'Check RX status and load eventualy received messages 'returns 0 if data in RXB0 ' 1 if data in RXB1 ' 10 if data in both ' 255 if no data Dim ConfigData(4) As Byte Dim Return_Str As String = "" ConfigData(0) = &HB0 Status command PICkitS.SPIM.Send_Data(1, ConfigData, True, False, Return_Str) PICkitS.SPIM.Receive_Data(1, ConfigData, False, True, Return_Str) If (ConfigData(0) And &HC0) <> 0 Then received If (ConfigData(0) And &HC0) = &H40 Then RXB0 ConfigData(0) = &H90 Buffer 0 PICkitS.SPIM.Send_Data(1, ConfigData, True, False, Return_Str) command PICkitS.SPIM.Receive_Data(4, RXB0ID, False, False, Return_Str) ID PICkitS.SPIM.Receive_Data(8, RXB0D, False, True, Return_Str) data Return 0 ElseIf (ConfigData(0) And &HC0) = &H80 Then RXB1 ConfigData(0) = &H91 Buffer 1 PICkitS.SPIM.Send_Data(1, ConfigData, True, False, Return_Str) command PICkitS.SPIM.Receive_Data(4, RXB1ID, False, False, Return_Str) ID PICkitS.SPIM.Receive_Data(8, RXB1D, False, True, Return_Str) data Return 1 Else ConfigData(0) = &H90 Buffer 0 PICkitS.SPIM.Send_Data(1, ConfigData, True, False, Return_Str) command PICkitS.SPIM.Receive_Data(4, RXB0ID, False, False, Return_Str) ID PICkitS.SPIM.Receive_Data(8, RXB0D, False, True, Return_Str) 'RX 'byte(s) 'byte in 'Read RX 'send 'receive 'receive 'byte in 'Read RX 'send 'receive 'receive 'Read RX 'send 'receive 'receive 87 data ConfigData(0) = &H94 'Read RX PICkitS.SPIM.Send_Data(1, ConfigData, True, False, Return_Str) 'send PICkitS.SPIM.Receive_Data(4, RXB1ID, False, False, Return_Str) 'receive PICkitS.SPIM.Receive_Data(8, RXB1D, False, True, Return_Str) 'receive Buffer 1 command ID data Return 10 End If End If Return 255 messages End Function Public Sub SetFilter(ByVal PGN As Integer) Dim ConfigData(4) As Byte Dim Return_Str As String = "" Dim Mode As Byte Mode = GetMode() SetMode(4) ConfigData(0) = &H2 ConfigData(1) = &H0 ConfigData(2) = PGN And &HFF ConfigData(3) = PGN And &HFF End Sub 'No 'save current mode 'set config mode 'write command 'RXF0SIDH 'sidH 'sidL Public Function GetMode() As Byte 'This function returns the current mode setting of the controller 'mode 0: Normal 'mode 1: Sleep 'mode 2: Loopback 'mode 3: Listen-only 'mode 4: config mode 'Details in DS MCP2515 p.58 Dim ConfigData(2) As Byte Dim Return_Str As String = "" ConfigData(0) = &H3 ConfigData(1) = &HE 'read command 'adress of CANSTAT PICkitS.SPIM.Send_Data(2, ConfigData, True, False, Return_Str) PICkitS.SPIM.Receive_Data(1, ConfigData, False, True, Return_Str) Return ConfigData(0) >> 5 End Function End Module 88 7.8 CANtroller 7.8.1 Inleiding Nadat bleek dat het niet mogelijk was om zelf de MCP2515 van op de pc aan te sturen, is een poging ondernomen om alle inteligentie in de PIC18F2550 te steken. Dit zou uiteindelijk een standalone systeem moeten worden, dat het netwerk kan nabootsen. Er werden pogingen ondernomen met kant en klare libraries voor de MCP2515 (van CCS). Helaas is deze library niet compatibel met de Microchip C Compiler, waardoor het noodzakelijk was deze aan te passen aan de specifieke eisen van de MCC. Dit zou echter onbegonnen werk zijn in het kader van dit eindwerk, waardoor de noodzaak zich aandiende om toch zelf een eigen code te schrijven. Hiervoor is wel gebruik gemaakt voor een deel van de headerfile van de CCS library. Deze code was echter nog niet af bij het drukken van dit werk. 7.8.2 Code #include // function prototypes void initPIC(); void initCAN(); void SDELAY(int ms); void FillRAM(); //nodig???? void low_isr_clk(); void high_isr_CAN(void); //ISR installation #pragma code high_vector=0x08 void interrupt_at_high_vector(void) { _asm GOTO high_isr_CAN _endasm } #pragma code low_vector=0x18 void interrupt_at_low_vector(void) { _asm GOTO low_isr_clk _endasm } #pragma code //MCP2515 register locations #define REG_BFPCTRL 0x0C #define REG_TXRTSCTRL 0x0D #define REG_CANSTAT 0x0E #define REG_CANCTRL 0x0F #define REG_TEC 0x1C #define REG_REC 0x1D #define REG_CNF3 0x28 #define REG_CNF2 0x29 #define REG_CNF1 0x2A #define REG_CANINTE 0x2B #define REG_CANINTF 0x2C #define REG_EFLG 0x2D #define REG_RXB0CTRL 0x60 #define REG_RXB1CTRL 0x70 89 //MCP2515 commands #define write #define read #define reset #define readStatus #define loadTXB0 #define loadTXB1 #define loadTXB2 #define RTS0 #define RTS1 #define RTS2 #define bitmod 0x02 0x03 0XC0 0xA0 0x40 0x42 0x44 0x81 0x82 0x84 0x05 //pin names #define CHIPSEL PORTAbits.RA5 //variable declaration unsigned char SPI(unsigned char myByte); void main() { initPIC(); // initCAN(); SDELAY(10); CHIPSEL = 0; SDELAY(1); SPI(0xC0); CHIPSEL = 1; SDELAY(20); CHIPSEL = 0; SDELAY(1); SPI(write); SPI(REG_CNF3); SPI(6); //CNF3 SPI(58); //CNF2 SPI(65); //CNF1 SPI(0xBC); //CANINTE CHIPSEL = 1; SDELAY(1); CHIPSEL = 0; SDELAY(1); SPI(write); SPI(REG_RXB0CTRL); SPI(0x20); selecting only std frames CHIPSEL = 1; SDELAY(1); CHIPSEL = 0; SDELAY(1); SPI(write); SPI(REG_RXB1CTRL); SPI(0x20); selecting only std frames CHIPSEL = 1; SDELAY(1); CHIPSEL = 0; SDELAY(1); SPI(write); SPI(REG_CANCTRL); SPI(0x00); CHIPSEL = 1; //DEBUG //disable reception //by //disable reception //by 90 PORTAbits.RA4 = 1; CHIPSEL = 0; SDELAY(1); SPI(loadTXB0); SPI(0x57); SPI(0x34); SPI(0x89); SPI(0x78); SPI(0x08); SPI(1); SPI(2); SPI(3); SPI(4); SPI(5); SPI(6); SPI(7); SPI(8); CHIPSEL = 1; SDELAY(1); CHIPSEL = 0; SDELAY(1); SPI(RTS0); CHIPSEL = 1; PORTA = 0xFF; //END DEBUG while(1); } void initPIC() { // SPI INSTELLEN SSPSTAT =0; SSPCON1 =0x22; ENABLE, FOSC /64 TRISC=0; //PORTC output TRISB=0; //PORTB OUTPUT TRISBbits.TRISB0 = 1; TRISA = 0; //Port A is input debug TRISAbits.TRISA5 = 0; CHIPSEL = 1; //Deselect MCP2515 // ADC INSTELLEN ADCON0 = 0x01; and turn ADC on ADCON1 = 0x0E; as ref, Only AN0 selected ADCON2 = 0x05; justified, Tacq is user, //SID //DLC //DATA //MASTER SPI //EXCEPT SDI, is input //Chip Select is output //Select CH1 //VSS and VDD //Left ADC Clk is Fosc/16 (Fosc max = 22MHz) interrupt enabling RCONbits.IPEN = 1; INTCONbits.GIEH = 1; INTCON3bits.INT2IP = 1; INTCON3bits.INT2IE = 1; } void initCAN() { // INTCONbits.GIE = 0; //Disable interrupts 91 CHIPSEL = 0; SDELAY(1); SPI(0xC0); CHIPSEL = 1; SDELAY(20); CHIPSEL = 0; SDELAY(1); SPI(write); SPI(REG_CNF3); SPI(6); //CNF3 SPI(58); //CNF2 SPI(65); //CNF1 SPI(0xBC); //CANINTE CHIPSEL = 1; SDELAY(1); CHIPSEL = 0; SDELAY(1); SPI(write); SPI(REG_RXB0CTRL); SPI(0x20); selecting only std frames CHIPSEL = 1; SDELAY(1); CHIPSEL = 0; SDELAY(1); SPI(write); SPI(REG_RXB1CTRL); SPI(0x20); selecting only std frames CHIPSEL = 1; SDELAY(1); CHIPSEL = 0; SDELAY(1); SPI(write); SPI(REG_CANCTRL); SPI(0x00); CHIPSEL = 1; // INTCONbits.GIE = 1; } unsigned char SPI(unsigned char myByte) { SSPBUF = myByte; while(!SSPSTATbits.BF); PORTAbits.RA4 = 1; return SSPBUF; } //disable reception //by //disable reception //by //enable interrupts //wait till done void SDELAY(int ms) { unsigned int i, j; for (i=0;i