Implementering av ISOBUS Virtual Terminal på fordonsdatorn CCP XS. Anders Öberg

Implementering av ISOBUS Virtual Terminal på fordonsdatorn CCP XS Examensarbete utfört i Elektroniksystem vid Linköpings tekniska högskola av Anders Öberg LiTH - ISY - EX - - 05 / 3732 - - SE Linköping 2005

Implementering av ISOBUS Virtual Terminal på fordonsdatorn CCP XS Examensarbete utfört i Elektroniksystem vid Linköpings tekniska högskola av Anders Öberg LiTH - ISY - EX - - 05 / 3732 - - SE Handledare: Michael Johansson, CC-Systems, Uppsala Examinator: Kent Palmkvist, Institutionen för systemteknik, Linköpings Universitet Linköping: december 2005

Abstract Modern agriculture equipment are more computer based today, and many equipments use a terminal in the tractor where the driver have the opportunity to make adjustments to the equipment. This is the reason why ISO developed a new standard called ISOBUS. It is a communication standard based on CAN specially adapted for agriculture equipments. The purpose of the standard is that it should be possible to equip a tractor with a standard terminal called Virtual Terminal that can be used to control the equipment. The use of the terminal should be independent of the manufacturer of the tractor as well as of the equipment. The purpose of this report is to find a solution of how to use CC Systems on-board computer, CCP XS, as a Virtual Terminal. In the report both Hardware and Software requirements have been examined, but mainly the software requirements. Only one suitable software vendor, Vector Informatik, was found after contacts with different software suppliers. It have not been possible to test this package because of the high price for the evaluation license. A demonstration solution has also been developed in the project. It consists of a simulator program, that runs on a PC, connected to a CPP XS that executes a Virtual Terminal program. An ISOBUS compatible J1939 protocol stack from Ixxat Automation has been integrated in the Virtual Terminal program. It gives the opportunity to test the protocol stack on a CPP XS. In order to limit the size of the project, not all functions in the ISOBUS standard is implemented in the demonstration solution. Keywords: ISOBUS, ISO 11783, Virtual Terminal, VT, J1939, CAN, CCP XS, agriculture equipment, on-bord computer Öberg, 2005. v

vi

Sammanfattning Moderna jordbruksredskap har blivit allt mer datoriserade och många använder sig av en terminal i traktorn där föraren har möjlighet att göra inställningar på redskapet. Därför har en standard för detta tagits fram av ISO kallad ISOBUS. Det är en kommunikationsstandard baserad på CAN speciellt framtagen för jordbruksmaskiner. Syftet med standarden är att en traktor skall kunna vara utrustad med en standardterminal kallad Virtual Terminal som används för att styra redskapen. Denna terminal skall kunna användas till samtliga redskap som kopplas till traktorn oberoende av vem som tillverkar redskapen eller traktorn. Syftet med rapporten är att hitta en lösning för hur CC Systems fordonsdator CCP XS kan användas som en Virtual Terminal. I rapporten har dels kraven på hårdvaran undersökts men det största arbetet har lagts på att hitta en lämplig mjukvarulösning. Efter att ha kontaktat olika leverantörer av mjukvara har endast ett lämpligt mjukvarupaket hittats och det levereras av Vector Informatik. Dock har inte detta paket kunnat testas på grund av det höga priset påenutvärderingslicens. Det har också i projektet tagits fram en demonstrator som består av en simulator för PC som kopplas till en CCP XS som kör en Virtual Terminal mjukvara. I programvaran för Terminalen valdes en ISOBUS kompatibel J1939 protokollstack från Ixxat Automation att användas, för att få möjlighet att provköra den protokollstacken på CCP XS. För att arbetet inte skulle bli för stort har dessa programvaror begränsats till att endast stödja vissa funktioner i ISOBUSstandarden. Nyckelord: ISOBUS, ISO 11783, Virtual Terminal, VT, J1939, CAN, CCP XS, jordbruksmaskiner, fordonsdator Öberg, 2005. vii

viii

Förord Jag skulle vilja tacka min handledare för hjälpen under examensarbetet och även den övriga personalen på CC Systems som hjälpt till att lösa problem som har uppstått. Öberg, 2005. ix

x

Innehåll 1 Inledning 1 1.1 Problemformulering... 1 1.2 Målochsyfte... 1 1.3 Avgränsning... 2 1.4 Disposition... 2 2 Teori 3 2.1 Bakgrund till ISOBUS... 3 2.2 ÖversiktavISOBUSsystem... 4 2.2.1 Systemuppbyggnad... 4 2.2.2 Electronic control unit (ECU)... 5 2.2.3 Virtual terminal (VT)... 5 2.2.4 Tractor ECU... 5 2.2.5 Task controller... 6 2.3 CAN2.0... 6 2.3.1 Historien om CAN-bussen... 7 2.3.2 Lager i CAN-bussen... 7 2.3.3 Frames...... 8 2.3.4 Message Filtering... 12 2.3.5 Felhantering i noderna... 12 2.4 Meddelanden på implementbussen... 13 2.4.1 Exempel på ett meddelande... 13 2.5 Detaljstudie av Virtual Terminal... 14 2.5.1 Fysiska uppbyggnaden... 14 2.5.2 Objektpott och Working sets... 16 2.5.3 Inmatnings objekt... 17 2.5.4 Special objekt... 17 2.5.5 Alarmmask.... 17 2.5.6 Fonter i VT.... 18 2.5.7 Pekskärm... 18 2.5.8 Auxiliary control... 18 2.5.9 Meddelande uppsättning förvt... 18 2.6 IntressantafunktioneriISOBUSstandarden... 19 2.6.1 Transportprotokoll funktionen... 19 2.6.2 Address Claming... 20 2.7 ISOBUS jämfört med J1939... 22 2.7.1 Använda J1939 applikationer påenisobus... 23 2.8 UtveckligavISOBUS-standarden... 24 Öberg, 2005. xi

xii Innehåll 3 CCP XS I VIRTUAL TERMINAL UTFÖRANDE 25 3.1 Mjukvara... 25 3.2 Hårdvara... 25 4 DISKUSSION OCH SLUTSATSER 27 4.1 Olika tillvägagångssätt förattimplementeraenvt... 27 4.1.1 VT fråncanoe... 28 4.1.2 Köpt Stack till Egen VT... 28 4.1.3 Stack med öppen källkod till Egen VT... 28 4.1.4 VT från annan hårdvarutillverkare... 29 4.1.5 Metod för att hitta leverantörer... 29 4.1.6 Uppföljning av spåren... 30 4.1.7 Resultat av spåret VT fråncanoe... 30 4.1.8 Resultat av spåret Köpt Stack till Egen VT... 31 4.1.9 Resultat av spåret Stack med öppen källkod till Egen VT 33 4.1.10 Resultat av spåret VT från annan hårdvarutillverkare.. 33 4.2 Slutsatser och val av lämpliga mjukvara... 34 4.2.1 Mjukvarulösning till en kommersiell VT... 34 4.2.2 Mjukvarulösning till en demonstrator VT... 34 4.3 Testutrustning förenvt... 35 4.3.1 I/O-enhet frångodtyckligmaskin... 35 4.3.2 I/O-enhet från en tillverkare av enheter som man själv programmerar... 35 4.3.3 Simulering i en PC med CAN adapter... 35 4.3.4 Ytterligare en CCP XS som körssomnode... 36 4.4 Simuleringsmöjligheter... 36 4.4.1 CANoe... 36 4.4.2 SimECU... 37 4.4.3 Egenskrivet simuleringsprogram.... 38 4.4.4 Mask Generator... 38 4.4.5 CanTool... 39 4.4.6 Val av simulerings möjlighet... 39 4.5 Hur påverkar utvecklingen av ISOBUS-standarden CC Systems. 40 4.6 Ytterligare funktioner till CCP XS...... 41 5 DEMONSTRATORN 43 5.1 Avgränsningar... 43 5.2 Simulatorprogram... 44 5.2.1 Funktion... 44 5.2.2 Uppbyggnad... 45 5.2.3 Användarmanual... 46 5.3 VTprogram... 47 5.3.1 Funktion... 47 5.3.2 Terminalen... 48 5.3.3 Uppbyggnad... 48 5.3.4 Användarmanual... 54 A Ordlista 59 B Meddelande i en CAN frame 61

Innehåll xiii C Mail 63 C.1 Till potentiella leverantörer... 63 C.2 Angående mjukvaruleverantörer... 64 C.3 Angående utveckling av ISOBUS... 65 D CCP XS Specifikation 67 E Relationsdiagram för VT objekt 69 F Uppbyggnad av VTprogram 71

xiv Innehåll

Kapitel 1 Inledning Rapporten beskriver ett examensarbete på civilingenjörsutbildningen i Teknisk Fysik och Elektroteknik (Y-linjen) på Linköpings Tekniska Högskola. Arbetet har utförts på företaget CC Systems AB kring deras fordonsdator CCP XS. CC Systems är ett elektronikföretag som levererar elektroniklösningar och programvara till främst fordon. Exempel på fordon som använder CC Systems system är skogsmaskiner, entreprenadmaskiner, lastbilar, fartyg, järnvägsfordon och militära fordon. Företaget utvecklar också hårdvara som till exempel fordonsdatorn CCP XS. I denna rapport beskrivs en studie över hur fordonsdatorn CCP XS kan användas som terminal i jordbruksmaskiner och hur den anpassas till jordbruksstandarden ISOBUS. 1.1 Problemformulering För jordbruksmaskiner finns en ISO-standard, ISOBUS, som beskriver hur redskap skall kommunicera med traktorn och med en terminal som finns i traktorn kallad Virtual Terminal (VT). VTn är en fordonsdator med skärm och speciell mjukvara för att kunna kommunicera med jordbruksredskapen. CC Systems är intresserade av att undersöka om deras fordonsdator kan användas som VT i jordbruksmaskiner, vilka anpassningar av hårdvara som krävs och vilka mjukvarukomponenter som måste finnas i datorn för att den skall uppfylla kraven i ISOBUS standarden. 1.2 Mål och syfte Syftet är att kunna anpassa fordonsdatorn CCP XS så att den går att använda som VT i ett ISOBUS-system. En översynavkravbåde vad det gäller hårdvara och mjukvara skall görs. För att uppfylla kraven kommer ett antal mjukvarukomponenter att krävas och det skall undersökas vilka som krävs och vad som finns att köpa in och vad som måste nyutvecklas. Det skall också tas fram en demonstrator för att visa hur en CCP XS fungerar i ett ISOBUSsystem. Målet med arbetet är att hitta lämpliga mjukvarukomponenter som gör CCP XS ISOBUS kompatibel och att sedan kunna implementera dessa på datorn. Öberg, 2005. 1

2 Kapitel 1. Inledning 1.3 Avgränsning Arbetet att ta fram en demonstrator har två avgränsningar. Det är inte möjligt att göra ev nödvändiga anpassningar i hårdvara. Dels kommer demonstratorn ev inte att kunna uppfylla alla krav i standarden då tiden begränsar möjligheten att implementera alla funktioner som krävs. Dock skall den fungera att köra med en begränsad uppsättning av funktioner. 1.4 Disposition Rapporten är upplagd så att den börjar med grundläggande teori kring ISOBUS och CAN. Sedan beskrivs hur utvärdering och val av lämpliga mjukvarupaket har bedrivits och vilka som har valts. När det gällde att välja mjukvarukomponenter fanns det olika möjliga lösningar som har följts upp som olika spår parallellt. I det avsnittet beskrivs också olika simuleringsmöjligheter som finns för testning av terminaler. Slutligen kommer avsnittet som beskriver den demonstrator som utvecklats och hur den används. Teoridelen beskriver bakgrunden för CAN och ISOBUS. Om detta redan är välbekant så går det bra att hoppa över teoridelen och hoppa direkt fram till avsnitten som behandlar val av mjukvarukomponenter. I rapporeten finns också några förslag på hur man kan arbeta vidare med CCP XS och ISOBUS och dessutom förslag på ytterligare funktioner som skulle kunna implementeras. För att underlätta läsningen av rapporten finns det en ordlista i bilaga A där tekniska termer kring området beskrivs.

Kapitel 2 Teori För att förstå vilka funktioner som ingår i en VT har hela ISOBUS-standarden studerats för att få en förståelse för hur ett ISOBUS-system fungerar. Sedan har en fördjupning gjorts i de delar av standarden som berör just VT. Eftersom ISOBUS bygger på en CAN-buss har också en grundligare studie gjorts av standarden för CAN-bussar och hur meddelanden överförs på en CAN-buss. Metoden för studien har varit att läsa litteratur, dels standarddokument från ISO (International Organization for Standardization) och SAE (Society of Automotive Engineers) men också olika artiklar. För att få svar på frågor och funderingar kring standarden har också några personer som arbetar med utveckling av ISOBUS standarden intervjuats. 2.1 Bakgrund till ISOBUS Jordbruksmaskiner har som mycket annat blivit mer avancerade och kräver mer elektronik. Många tillverkare har därför konstruerat egna styrsystem med egna protokoll för att styra sina maskiner. Med en sådan lösning får man en kontrollenhet till varje redskap som man måste placera i hytten. För att effektivisera jordbruket har man börjat använda fler redskap på traktorn samtidigt vilket leder till att man behöver kunna styra alla dessa samtidigt. Om man inte vill ha en kontrollenhet till varje redskap krävs att man har någon form av standard för hur ett styr- och informationssystem för redskapen skall fungera. I jämförelse med att ha fristående styrenheter är det betydligt billigare att ha ett standardsystem som fungerar till alla de olika enheterna. De mer avancerade styr- och informationssystemen som nu krävs i maskinerna leder också till att varje redskaps- och fordonstillverkare inte har möjlighet att utveckla sina system själva. Om alla redskap följer en standard, blir det lättare att handla ett färdigt system från någon extern tillverkare. ISO 11783 kallas ISOBUS och är en standard som har tagits fram av traktoroch redskapstillverkare för att reglera hur kommunikationen mellan traktor och redskap skall fungera. När standarden skulle tas fram utgick man från befintliga standarder. Den mest lämpade som redan fanns för bilar, SAE J1939, har fått bidra med information om hur datakommunikationen och kommunikationsnätet skulle byggas upp. En annan standard, DIN 9684, som man nationellt tagit fram i Tyskland Öberg, 2005. 3

4 Kapitel 2. Teori för kommunikation i jordbruksmaskiner, fick bidra med information om hur informationspresentation till föraren och export och import av data till fordonen skulle ske. Import och export av data kan vara användbart när man t ex vill hämta statistik från ett redskap. (Stone m.fl. 1999, Fellmeth 2003) 2.2 Översikt av ISOBUS system Figur 2.1: Översikt av ISOBUS-system ISOBUS-standarden är övergripande och innehåller information om alla delar i ett styr- och informationssystem för jordbruksmaskiner och dess redskap. Ett exempel på ett ISOBUS-system finns i figur 2.1. 2.2.1 Systemuppbyggnad ISOBUS-systemet är uppbyggt kring en CAN 2.0b buss där en eller flera noder kan kopplas in. Detta nätverk är uppbyggt av två delnät. Dels en traktorbuss där kommunikation för att traktorn skall kunna köras finns. Detta nät kopplar t ex ihop motor med växellåda och styrpanel. Sedan finns det ytterligare en buss, implement buss, där kommunikation med redskapen finns. Dessa två nät är inte helt åtskilda utan sammankopplade med en Tractor ECU för att kunna föra information mellan näten. Implementbussen sträcker sig också utanför traktorn via standardiserade kontakter placerade på traktorn där möjlighet finns för att montera redskap. Det finns också en kontakt som sitter i förarhytten för att kunna koppla på ECUer och VT i hytten. Implementbussen måste termineras i ändarna och därför har man tagit fram en kontakt som har inbyggd automatisk terminering om inget är anslutet. Denna typ av kontakt skall också sitta på de redskap som har möjlighet att koppla på ytterligare ett redskap efter sig.

2.2. Översikt av ISOBUS system 5 Kabeln som används till bussen är en partvinnad fyrledarskabel i ett hölje. De fyra ledarna benämns CAN L, CAN H, TBC PWR och TBC RTN där de två första används för datatrafiken och de två sista endast används för att ström-försörja termineringarna i slutet av bussen. Bussen har fysikaliska begränsningar i att den maximalt får vara 40 meter lång och man kan ansluta ECUer var som helst men inte tätare en 0,1 meter från varandra och grenar får inte vara längre en 1 meter. Bussen är också begränsad till ett max på 30 st ECUer. (Stone m.fl. 1999) 2.2.2 Electronic control unit (ECU) ECUer är noder i nätverket och sitter på alla redskapen samt i fordonet. Dessa enheter innehåller en I/O-del för att kunna göra mätningar och inställningar på redskapen. För att kunna presentera information och för att kunna få inställingar gjorda använder ECUn VTn som gränssnitt mot föraren. Eftersom det finns flera olika typer av VT i standarden skickar ECUn en fråga till VTn om vilka egenskaper den har i form av display och knappar mm. Utgående ifrån den informationen kan ECUn ha olika bilder lagrade och skickar den som passar bäst till VTn. Då kan föraren göra inställningar på och läsa av mätdata från redskapet med hjälp av VTn i fordonet. (Stone m.fl. 1999) 2.2.3 Virtual terminal (VT) Virtual terminal används för att presentera information och mätdata från redskapen och göra inställningar på redskapen. Den är uppbyggd av en display och några typer av inmatningsmöjligheter t ex knappar, joystick eller pekskärm. VTn är helt passiv och fungerar liknande en webläsare där de olika redskapens ECUer skickar färdiga bilder att presentera på skärmen, så kallade masker. I masken finns också information om vad olika knappar skall ha för funktion. Varje ECU har en egen mask att presenterar på VTnochföraren har sedan möjlighet att välja från vilken ECU han vill se en mask för tillfället. En mask är uppbyggd av in- och utmatningsfält. Utmatninsfälten kan uppdateras av ECU och om föraren ändrar i ett inmatningsfält överförs det nya värdet automatiskt till ECUn. VT har också stöd för att kunna rita olika typer av grafik. (Stone m.fl. 1999, ISO 11783-6) 2.2.4 Tractor ECU Tractor ECU är ett specialfall av ECU eftersom den används för att koppla samman implementbussen och traktorbussen. Denna ECU blir en så kallad kommunikationsbrygga som filtrerar information från de två bussarna och bara släpper igenom relevant och tillåten information. De två bussarna är inte heller synkroniserade med varandra så bryggan har en buffert där den buffrar data tills det finns möjlighet att skicka den vidare till den andra bussen. Bryggan tar också bort en stor mängd information. Skulle all information från respektive nät överföras till det andra finns det risk för att bussarna blir överbelastade. ECUerna på implementbussen har inga begränsningar i vilka instruktioner de får skicka och för att inte olämpliga instruktioner skall kunna påverka traktorns gång filtreras dessa bort så att de inte kan nå traktorbussen.

6 Kapitel 2. Teori Tractor ECU är specificerad i del 9 av ISO standarden (ISO 11783-9). Standarden kräver att traktorn måste vara utrustad med en ECU för att förmedla information om traktorn på implementbussen. Tractor ECU kan vara av tre klasser från en enkel klass 1 som bara levererar mätvärden från traktorn, som t ex varvtal och hastighet. Denna klass är tänkt att användas för att enkelt göra befintliga traktordesigner ISOBUSkompatibla. För nykonstruerade traktorer är tanken att man skall använda klass 2 eller 3, där klass 2 innehåller ytterligare mätvärden och klass 3 även kan ta emot inställningar från implement bussen. Som tillägg till klasserna finns N och F. Där N står för att traktorn är utrustad med navigeringsutrustning (GPS) och F står för att traktorn har stöd för att montera redskap även framtill. Klasser av typen N och F har då stöd för ytterligare instruktioner relaterade till respektive funktioner. (Stone m.fl. 1999, ISO 11783-9) 2.2.5 Task controller Task controller är en speciell komponent i ISOBUSsystemet som antingen är en egen ECU eller implementerad i t ex VTn. Task controllern har två uppgifter. Den ena är att sköta kommunikationen med omvärlden och den andra är att genomföra s.k. tasks. Kommunikationen med omvärlden sker med t ex flash diskar och man kan exportera och importera data via task controllern. Man kan också använda den till att köra tasks på. Ett task är en dynamisk inställning av en eller flera parametrar på ett eller flera redskap. Ett task kan vara av tre typer: time-, distance- eller locationbased. (Stone m.fl. 1999, Fellmeth 1998) 2.3 CAN 2.0 ISOBUS-standarden bygger på CANstandarden, CAN 2.0b. För att kunna förstå hur ISOBUSen fungerar beskrivs här hur CAN 2.0 fungerar. Till stora delar följer ISOBUSen CAN-standarden men det finns några funktioner i CAN 2.0- standarden som inte tillämpas i ISOBUS-standarden. Här beskrivs hela CANstandarden, men delar som inte tillämpas i ISOBUS-standarden behandlas inte ingående. CAN-bussen är en seriebuss som saknar masternod och alla noder har möjlighet att läsa alla meddelanden på bussen. Olika meddelande har olika prioritet och är det flera noder som vill sända på bussen samtidigt får noderna tävla om bussen och den nod som har ett meddelade med högst prioritet vinner. Bussen har en hög säkerhetsnivå med feldetektering och felsignalering. Om ett fel uppstår sker en automatisk omsändning när bussen blir ledig igen. Skulle ett permanent fel uppstå finns funktioner för att koppla bort den trasiga noden. Kodningen av data på CAN-bussen sker med Dominant och Recessive bitar. Om två noder lägger ut data samtidigt, den ena en recessive bit och den andra en dominant bit kommer de andra noderna på bussen bara att detektera en dominant bit. (CAN specification 2.0, Part B)

2.3. CAN 2.0 7 2.3.1 Historien om CAN-bussen I början av 1980 talet väcktes iden att börja använda ett elektriskt bussystem för överföring av signaler i bilar. Ingenjörerna på Bosch hade undersökt alla befintliga standarder och inte hittat någon som uppfyllde alla de krav man ställde på en sådan buss. Då började man att utveckla en egen buss och i februari 1986 kunde Bosch på Society of Automotive Engineers (SAE) kongress presentera en ny buss som fått namnet Controller Area Network (CAN). Efter detta publicerades ett antal dokument kring bussen och i mitten av 1987 släpptes de första CAN-kontrollerchipen. I början av 1990 publicerades den uppdaterade CAN bussen CAN 2.0 och den presenterades för standardiseringsorganisationen ISO. ISO antog CAN 2.0 som standard och publicerade den som ISO 11898 i november 1993. CAN började användas i allehanda tillämpningar i fordon och inom industrin. Lösningarna var många och olika vad det gällde högre lagers protokoll i början av 1990 talet. För att styra upp de olika lösningarna bildades användargruppen CAN in Automation (CiA) 1992. 1992 introducerades också CAN bussen i bilar. Mercedes-Benz lanserade en ny modell av sin största kaross S-klassen det året och de använde CAN-bussen för motorstyrning. Senare började man också använda ytterligare ett CAN-nät i bilar för att styra chassielektronik. De två näten kunde kommunicera med varandra via en s.k. gateway. (CAN specification 2.0, Part B) 2.3.2 Lager i CAN-bussen CAN-bussen är uppdelad i flera lager för att underlätta implementationen av CAN-bussapplikationer. De olika lagrena hanterar olika funktioner och beskrivs här i ordning, från den fysiska bussen och uppåt. Underst ligger Physical Layer som hanterar överföringen av databitar till bussen. Detta lager ser till att signalnivåerna är de rätta och synkronisera hårdvaran med bussen. Alla noder i en buss måste ha ett likadant Physical Layer. Över Physical Layer ligger Data Link Layer som i sin tur är uppdelad i två delar, Logic Link Control (LLC) och Medium Access Control (MAC). LLC hanterar filtrering av meddelande och kan också skicka ut överbelastningsmeddelanden. MAC hanterar trafiken på bussen. Den tar data från LLC och skapar Frames med alla de delar som en Frame skall innehålla. MAC tar också emot Frames från Physical Layer och avkodar data för att skicka vidare till Application layer. I MAC lagret sker också felhantering genom kontroll av mottagna meddelande och felsignalering. Över detta finns ytterligare lager som t ex Application Layer där data som skall överföras skapas. (CAN specification 2.0)

8 Kapitel 2. Teori 2.3.3 Frames All data på bussen skickas i Frames. CAN 2.0 finns i version A och B, där skillnaden mellan dessa är att B kan hantera två format av frames. Eftersom ISOBUS använder sig av 2.0B så kommer den att redovisas här. Det finns två olika format på frames som kallas Standard format (samma som i CAN 2.0A) och Extended format. Det som skiljer dem åt är att Standard format har en 11 bitar lång Identifier medan Extended format har en 29 bitar lång Identifier. (CAN specification 2.0, Part B) Data Frame och Remote Frame Dessa Frames används för att sända data på bussen respektive begära data från en annan nod. Dess uppbyggnad är snarlik och en bit talar om att det är en Data eller Remote frame. Framen är uppbyggd av 7 olika bitfält som kan bestå av en eller flera bitar, som i figur 2.2. Figur 2.2: Data frame Start of frame - SOF Första bitfältet heter Start of frame och är en bit långt och är alltid dominant. Den används för att signalera att en frame har börjat sändas. Arbitration field Figur 2.3: Arbitration och Control field Arbitration- och Control-fältets beståndsdelar ligger blandade i meddelandet och båda visas i figur 2.3, där Arbitration-fältets beståndsdelar är gråa och Control-fältets beståndsdelar är vita. Identifier Identifiern används för att prioritera meddelanden och innehåller meddelandets ID. När identifiern läggs ut på bussen kan flera noder göra det samtidigt. Dock kan inte flera noder sända ett meddelande samtidigt så demåste tävla om bussen. De noder som lägger ut bitar läser samtidigt av bussen för att se om någon annan nod också lägger ut en identifier. Så länge som flera noder lägger ut samma värde på bitarna är de med i tävlingen. När någon nod lägger ut en

2.3. CAN 2.0 9 recessive och läser en dominant bit från bussen har den noden förlorat och måste vänta med att sända sitt meddelande. Det meddelande som har en identifier med lägst binärt värde har högst prioritet. Kodning av bitar i CAN-meddelanden 0 = dominant 1 = recessive Överföringen sker så att IDets mest signifikanta bit sänds först. Identifierfältet skiljer sig åt beroende på om det är Standard eller Extended format som överförs. Båda formaten har ett Base ID på 11 bitar men skillnaden är att Extended format också har ett Extended ID på 18 bitar som standard format saknar. Extended ID sänds senare i en extendid identifier efter IDE bitfältet. Base ID = ID 10.. ID 0 (standard format) Base ID = ID 28.. ID 18 (extended format) Extended ID = ID 17.. ID 0 (extended format) Skulle Base ID vara det samma för två meddelande som försöker sända samtidigt, det ena i standard format och det andra i extended format vinner alltid meddelandet i standard format. Remote Transmition Request - RTR Detta bitfält är en bit lång och används för att tala om ifall det är en Remote frame eller en Data frame som håller på och sänder. Data frame = dominant Remote frame = recessive Substitute Remote Request - SRR Det här är ett bitfält som bara används när man sänder i Extended format. Fältet består bara av en bit och är en ersättning för RTR biten i standard format. Alltid = recessive Control Field Identifier Extension Bit - IDE Används för att identifiera om det är frame i Standard eller Extended format. Extended format = recessive Standard format = dominant Data Length Code I grunden består alltid data length code-bitfältet av 6 bitar. Dock är det så i Standard format att den första biten i control-bitfältet är IDE biten som alltid skall vara dominant. Sedan kommer bitarna r1, bara i Extended format, och r0. Dessa kallas för reserved bits och skall alltid sändas dominant. r0 alltid = dominant r1 alltid = recessive (Extended format) Efter reserved bitarna kommer 4 bitar som heter Data Length Code (DLC3.. DLC0). Dessa bitar används för att tala om hur många bytes som kommer att sändas i databitfältet. Antalet databitar kan anges från 0 till 8 och kodningen av dessa bitar sker binärt liknade ID.

10 Kapitel 2. Teori Om framen är av typen Remote frame saknar den databitfält och då saknas således betydelsen av ett Data Length Code, värdet sätts då godtyckligt mellan 0och8. Data field I detta bitfält sänds den data som skall överföras. Fältets längd är förbestämt och redovisat i Control-bitfältet och kan vara mellan 0 och 8 bitar. Skulle framen vara av typen Remote frame har alltid detta fält längden 0. Cyclic Redundancy Code field - CRC Figur 2.4: CRC och ACK field I figur 2.4 visas CRC och ACK fältens delkomponenter. CRC sequence är en checksumma för att se att överföringen har blivit korrekt. I checksumman ingår alla bitar från Start Of Frame till sista data biten. Principen med CRCkoden är att det meddelande man överför inkl CRC-sekvensen skall ha en rest på 0 när man dividerar (modulo-2 division) med ett fixt polynom. Att tänka på är att modulo-2 division inte är som vanlig division utan additioner och subtraktioner i modulo-2 sker utan minnessiffra. I CAN-standarden definieras det fixa polynomet till 1100010110011001. Eftersom det fixa polynomet är känt för både sändare och mottagare kan sändaren lätt räkna ut vilken CRC sekvens som krävs för att få enrestsomär 0 vid division. Ettkortexempelpå hur en CRC kod fungerar: M: Originalmeddelande: 1101011011 P: Fixt polynom: 10011 (n bitar) M : Originalmeddelande med n-1 nollor efter: 11010110110000 Dividera M med P och erhåll en rest C M Mod P = C = 1110 Skapa meddelandet T som är M adderat med C. M +C = T = 11010110111110 Meddelandet T sänds på bussen. Mottagaren tar emot T och delar med P, vilket ger resten 0 förutsatt att meddelandet överförts korrekt. TmodP=0 Om ett meddelande som överförts inte får resten 0 vid divisionen låter mottagaren bli att sända tillbaka något ACK meddelande. Då sänder sändaren meddelandet på nytt. (CAN specification 2.0, A painless guide to crc error detection algorithms)

2.3. CAN 2.0 11 CRC delimiter CRC-koden följs av en CRC delimiter som är 1bit lång och sänds recessive. ACK Field I ACK field sänder mottagaren en bit för att meddela att meddelandet har mottagits korrekt. ACK slot Här skall mottagaren meddela att den tagit emot ett korrekt meddelande. Sändaren lägger ut en recessive bit på bussen och alla mottagare som tagit emot ett korrekt meddelande skall då lägga ut värdet dominant på bussen. ACK delimiter ACK delimiter är 1 bit lång och skall vara recessive. End Of Frame Varje frame av typen Data och Remote Frame skall avslutas med en End of frame sekvens. Den består av 7 bitar och alla skall sändas recessive. (CAN specification 2.0) Error Frame En error frame sänds av noderna när det har uppståt ett fel. Error framsen består av två bitfält. Error flag Det finns två olika error flags som kan sändas, Passive error flag och Active error flag. Vid normal sändning på bussen tillåts bara 5 lika bitar i följd att sändas, sedan måste en annan bit komma för att bussen inte skall tolka meddelandet som felaktigt. Detta löser man då isändaren genom att efter 5 lika bitar infoga en bit av motsatt tecken, avkodaren vet då att efter 5 lika bitar kommer en bit som skall filtreras bort då den bara finns där för att bryta sekvensen av lika tecken. Denna process kallas för bit-stuffing. Regeln att bara 5 lika bitar får sändas i rad används för att sända en aktiv error flag som består av 6 stycken dominantbitar som sänds i rad. 6 dominanta bitar strider då mot regeln för bit-stuffing och det gör att alla noder lätt kan detektera en aktiv error flag. Passiv error flag består av 6st recessivebitar som sänds i följd. Om dessa blir överskrivna av dominantbitar fortsätter noden att lägga ut recessive bitar till den har läst6stiföljd från bussen. (CAN specification 2.0) Error delimiter Error flag följs av en error delimiter. Den består av 8 st recessivebitar. När en nod på bussen detekterat en error flag börjar noden att sända recessivebitar på bussen. När Noden detekterar den första recessiva biten på bussen fortsätter den att sända ytterligare 7 st recessivebitar. (CAN specification 2.0)

12 Kapitel 2. Teori Overload Frame En overload frame ser likadan ut som en Active Error Frame. För att särskilja dem åt får bara en Overload Frame starta vid 3 olika tillfällen i busstrafiken annars tolkas det som en Error Frame. De tillfällen då en overload frame får börja sändas är. Första biten av en förväntad intermission. Om man detekterar en dominant bit som första eller andra biten i en intermission (Overload framen börjar sändas en bit efter detekteringen). Om en dominat bit detekteras som den 8:e biten i en error intermission (Overload framen börjar sändas en bit efter detekteringen). (CAN specification 2.0) Interframe spacing Frame Denna frame sänds mellan Data frames. Den består av två fält. Intermition Intermition består av 3 stycken recessivebitar. Om en node har fått problem med att hinna processa mottagen data kan den skicka en Overload Frame. Sändningen av en Overload Frame på grund av överbelastning startar alltid i Intermition-fältet, det är den enda typ av sändning som kan startas här. Bus Idle Bus Idle används för att signalera att bussen är ledig. Detta bitfält kan vara hur långt som helt och den som vill sända är fri att skicka. Alla frames börjas med en dominat bit, så ibitfältet Bus Idle skall en dominat bit tolkas som att någon börjar sända en frame. (CAN specification 2.0) 2.3.4 Message Filtering I LLC-lagret finns ett filter som används för att filtrera vilka meddelande som skall läggas in i mottagningsbufferten. Detta filter filtrerar bort meddelande med IDn som den specifika noden inte är intresserad av. (CAN specification 2.0) 2.3.5 Felhantering i noderna Alla noder har ett avancerat system för felhantering. Detta för att en defekt nod inte skall förstöra för de övriga noderna genom att lasta ner bussen med felmeddelanden. En buss kan vara i tre lägen. Active Error med möjlighet att sända Active error frames. Passive Error med möjlighet att sända Passive error frames men inte Active error frames. Bus Off när noden inte har möjlighet att sända på bussen alls. Feldetekteringen i noderna är uppbyggd kring två räknare, Transmit Error Count och Receive Error Count. Dessa räknare räknas upp och ner enligt förutbestämda regler. Se CAN 2.0 standarden för att se hur samtliga regler är utformade. Principen är den att räknarna räknas upp när noden har detekterat

2.4. Meddelanden på implementbussen 13 ett fel på bussen och ner när den gör lyckade mottagningar och sändningar. När räknarna når uppsatta brytvärden minskas eller ökas nodens möjligheter att sända felmeddelanden eller använda bussen. (CAN specification 2.0) 2.4 Meddelanden på implementbussen I Application Layer kodas innehållet i meddelandena. Här skapas data som sedan sänds i Identifiern och Datafältet i en frame. Ett antal standardiserade parametrar finns för att beskriva information på implementbussen. Parametrarna är indelade i parametergrupper. En parametergrupp kan t ex vara Time/Date eller Lightning Data. PGN = FF10 PDU format = FF PDU specific = 10 Tabell 2.1: Exempel på hur PGN-numret erhålls Varje parametergrupp har ett PGN (Parameter Group Number) som består av PDU (Protocol Data Unit) format följt av PDU specific, ett exempel finns i tabell 2.1. Det finns två typer av PGNs, en för att sända globala meddelande och en annan för att sända till en specifik mottagare. För att sända globalt skall PDU format vara större än 239 och PDU specific kan vara mellan 0 och 255. Om man skall sända till en specifik mottagare skall PDU format vara mindre än 240 och PDU specific användas för mottagaradressen. Varje parametergrupp har ytterligare egenskaper och tillsammans med PGN bildar de Frame Identifier. Figur 2.5: Uppdelningen av Identifierbitfältet enligt ISO 11783 På CAN-bussen får inget meddelande ha samma Identifier då konflikter kan uppstå när flera noder tävlar om bussen genom att skicka samma Identifier. Av denna anledning har man infört Source address som gör att alla noder får unika adresser som inkluderas i Identifiern. En komplett identifierare visas i figur 2.5 och identifieraren följs sedan av 0-8 st databytes. (Junger 2004) 2.4.1 Exempel på ett meddelande Om traktor ECUn skall skicka ut information om vad klockan är ska meddelandet se ut som följer. I exemplet i tabel 2.2 antas att traktorns klocka står på 12:47:51,25 (GMT) med lokal avvikelse från GMT på -6h. Datumet för dagen är 2005-03-14. (ISO 11783-7)

14 Kapitel 2. Teori Data length 8 byte Data page 0 PDU format 254 0xFE Större än 239, Globalt meddelande PDU specifik 230 0xE6 PGN 65254 0xFEE6 Default priority 6 De tolv databitarna i gruppen har följande innehåll Byte 1, Sekunder 0,25s/bit 205 (0xCD) Byte 2, Minuter 1min/bit 47 (0x2F) Byte 3, Timmar 1h/bit 12 (0x0C) Byte 4, Månad 1månad/bit 03 (0x03) Byte 5, Dag 0,25dag/bit 56 (0x38) Här kan dag 1 anges som 0,25; 0,5; 0,75; och 1, liknade gäller för samtliga dagar. Byte 6, 1år/bit + 1985 20 (0x14) År anges som antal år från 1985. Byte 7, Lokal offset 1min/bit 0 (0x0) Byte 8, Lokal offset 1h/min -24h 18 (0x12) Värde 0 anger -24h värde 1-23 osv till 47 som anger +23h. Tabell 2.2: Parametergruppen Date/Time När detta meddelande sedan skall sändas packas det i en standard CAN frame som visas i figuren som finns i appendix B. 2.5 Detaljstudie av Virtual Terminal För att jämföra olika mjukvarupaket för VTn beskrivs här VTn i detalj. Bland annat beskrivs vilka funktioner som är grundfunktioner enligt standarden, och som måste ingå och vilka eventuella funktioner som är tillval. För att sedan kunna implementera mjukvarupaketet på CCP XS kommer här också att beskrivas hur meddelanden rörande VT byggs upp och hur de skickas på bussen. 2.5.1 Fysiska uppbyggnaden VT skall vara ett gränssnitt mellan föraren, maskinen och de olika redskapen. Därför har VTn funktioner för grafisk presentation och inmatning. För att inte trafiken på CAN-bussen skall bli för stor när en VT används bygger all presentation på objekt som är fördefinierade i standarden och sedan kan anropas av olika ECUer på bussen. All information visas på displayen som skall vara pixeladresserbar och som sedan delas upp i olika masker, Data mask, Alarm mask och Soft Key mask. Data till dessa masker är unik för varje redskap och laddas in till VTn antingen från ECUn via CAN-bussen eller från t ex ett minneskort. När maskerna sedan finns i VTn kan en ECU enkelt byta mask på displayen genom att sända ett Change Active mask kommando.

2.5. Detaljstudie av Virtual Terminal 15 Figur 2.6: Exempel på en VT display VTn ställer krav på att vissa funktioner för inmatning och styrning måste finnas. VTn skall ha ett antal knappar som antingen kan implementeras som mjukvaruknappar på en pekskärm eller som fysiska knappar implementerade i hårdvara. Används hårdvaruknappar till Soft key funktionen bör de vara placerade längs skärmkanten som i figur 2.6 så att funktion tydligt kan presenteras påskärmen genom att skriva i skärmkanten bredvid en knapp. I figur 2.7 visas de inmatningskontroller som skall finnas. Soft key Navigation keys Editing keys är en knapp som mjukvaran kan koppla olika funktioner till och som också kan representera olika text beroende på funktion. Varje mask kan innehålla 6-64 softkeys och kan inte alla visas samtidigt skall stöd finnas för att skrolla fram alla knappar. är piltangenter som skall användas för att hoppa mellan olika inmatningsfält. används för att ändra det inställda värdet i ett markerat inmatningsfält. Med dessa knappar måste man kunna välja vilken siffra eller bokstav som helst som går att mata in i den specifika fälttypen. Detta löser man enklast med piltangenter för att skrolla genom alla giltiga tecken. Det skall också finnas en Enterknapp för att meddela till ECUn att en datainmatning är klar och en ESC knapp för att meddela att man avbrutit en datainmatning.

16 Kapitel 2. Teori Control Auxiliary input består av två knappar. En knapp som används för att växla mellan olika redskap som man vill kontrollera när flera redskap är anslutna till fordonet. Denna knapp ska ha 3 pilar i en cirkel som symbol. Den andra knappen, ACK, används för att bekräfta att man mottagit en varning och den skickar då en bekräftelse till redskapets ECU. är en ytterligare uppsättning av funktioner för inmatning av data som t ex kan bestå av en joystick eller rattar. Figur 2.7: Exempel på Inmatningskontroller En ytterligare funktion som skall finnas i användargränssnittet mot föraren är ett akustiskt alarm. Detta kan vara någon typ av ljudsignal från enklaste summer till mer avancerade enheter med variabel frekvensåtergivelse. (ISO 11783-6) 2.5.2 Objektpott och Working sets Varje redskap som kopplas till traktorn bildar ett Working set i VTn. Det är inget krav att varje redskap endast har en ECU, flera kan sitta på samma redskap men det måste då finnas en master som är ansvarig för working setet. Ett working set innehåller en eller flera data, soft key- och alarm-masks. Dessa masker byggs sedan upp av objekt som finns i working setets objektpott där varje objekt har ett unikt objektid. För att de olika redskapens noder skall veta vilka objekt den skall sända till VTn skickar VTn ut information om vilket språk, måttsystem, tidssystem mm som den är inställd för och även information om vilka fysiska egenskaper den har som upplösning, färgskärm mm. Med den informationen har noderna möjlighet att skicka olika objekt beroende på VTns inställningar och egenskaper. VTn kan sedan visa ett working set åt gången och endast föraren har möjlighet att byta working set. När föraren trycker på Control-knappen för byte av working set byter VTn aktivt working set på displayen och ett meddelande sänds ut på bussen att ett nytt working set har aktiverats.

2.5. Detaljstudie av Virtual Terminal 17 Dock kan ett working set själv välja vilken mask det vill visa. ECUerna kan också kontinuerligt byta egenskaper på objekt oberoende av om ett visst working set är aktivt eller inte. ECUerna kan också skicka instruktioner om att ta bort och lägga till objekt under gång. (ISO 11783-6) 2.5.3 Inmatnings objekt VT har stöd för inmatning av de 4 datatyperna string, booleans, lists och numbers. När användaren navigerar mellan olika inmatningsfält skickas information till noderna om vilket fält som är aktivt. Ändringar i inmatningsfälten sänds ut på bussen när användaren trycker på Enter. Skulle användaren inte vilja fullfölja en inmatning kan han trycka på Escape eller hoppa till ett annat fält, i båda fallen sänds ett Escapemeddelande ut på bussen. (ISO 11783-6) 2.5.4 Special objekt Det finns några specialobjekt som inte är vanliga fält eller figurer mm. Dessa används främst för att göra ändringar av objekt effektivare så att de inte tar för mycket utrymme på bussen. Container objects Attribute objekt Variable objekt Makron (ISO 11783-6) 2.5.5 Alarmmask Används för att gruppera andra objekt. Ett sådant objekt är t ex användbart när man har en grupp av objekt som man samtidigt vill kunna dölja genom att göra containern osynlig. Man kan också återanvända en contaier i flera masker om man enkelt vill använda en uppsättning av objekt i flera masker. Används för att kunna ändra utseende på flera objekt samtidigt. Om flera objekt använder samma font-attribut objekt, och de ändras, då ändras alla objektens font. Fungerar som en variabel, används av flera objekt som skall ha en gemensam egenskap. Ett objekt som kan utföra ett antal instruktioner. Man kan t ex anropa ett färdigt makro med 1 instruktion och det utför sedan 10 instruktioner i stället för att sända alla 10 instruktionerna över bussen. När en nod vill larma visar den en alarmmask. Alarmmasken täcker hela den del av skärmen som annars täcks av datamasken. Till alarmmasken finns en soft key mask kopplad. Skulle flera noder försöka att visa alarmmasks visas den mask som har högst prioritet. Alarmmasken försvinner sedan när man har bekräftat den genom att trycka ACK. I vissa fall vill noden att man väljer ett alternativ med knapparna och då kommer noden att ignorera ACK tryckningar och alarmmasken visas tills man valt ett av alternativen. (ISO 11783-6)

18 Kapitel 2. Teori 2.5.6 Fonter i VT Alla tecken i en font har samma storlek för att man lätt skall kunna placera tecken bredvid och under varandra. Teckenstorleken anges som pixlar bredd x höjd och får inte vara mindre än 6x8pixlar. Det är fritt för konstruktören av VTn att välja vilka och hur många fonter han vill implementera men ett krav är att 6x8 normal skall finnas. (ISO 11783-6) 2.5.7 Pekskärm I standarden för VT finns stöd för pekskärm med det är inget krav. En nod kanskickaenförfrågan för att få veta om VTn har pekskärm, om noden önskar kan den sedan anpassa sina objekt för pekskärm eller inte. Om skärmen är av pekskärms typ kan knappar inkluderas i datamasken, det går också att få ett meddelande på bussen var i datamasken som användaren har tryckt oberoende av om det finns en knapp där eller ej. (ISO 11783-6) 2.5.8 Auxiliary control Auxiliarys är inmatningsfunktioner som inte är en del av VTn utan sitter separat som t ex ytterligare knappar eller en joystick. Det kan dock också vara en del av den fysiska VTn om den har ytterligare knappar utöver de som tidigare beskrivits för VTns funktion. Auxiliarys fungerar så att man tilldelar dem till en viss funktion på ett visst redskap, och du kan då styra den funktionen med den tilldelade Auxiliaryn oberoende av vad som händer på VTn. Ett working set för en maskin kan innehålla Auxiliary function objects, ett sådant objekt är en koppling till en viss funktion på ett redskap. Varje Auxiliary control, som t ex är en kontrollåda med knappar, bildar också ett working set i VTen. Detta working set innehåller dock bara Auxiliary input objects, som är en koppling till en viss knapp, ratt ect. En Auxiliary kan vara av tre typer analog, latching boolean eller non-latching boolean. Boolean genereras av t ex knappar och en latching innebär en knapp som stannar kvar i intryckt läge till skillnad från nonlatching som återfjädrar när man släpper den. Analoga Auxilirys presenterar sin position som ett procent av maxvärdet. Kopplingen mellan Auxiliary input objekts och Auxiliary function objects sker i VTn på en speciell skärmbild som heter Auxiliary control setup. (ISO 11783-6) 2.5.9 Meddelande uppsättning för VT Det finns ett stort antal meddelanden som VTn skall stödja. Det är alldeles för många för att ta upp här utan de finns att läsa i standarden ISO 11783-6. Dessa meddelanden är uppbyggda enligt CAN-standarden. För att meddelandena sedan skall få olika innebörd finns innehållet i de 8 databyten specificerade i standarden. Meddelanden till och från VTn har identifiering enligt figur 2.3. De olika instruktionerna som sedan skickas med meddelandet har ett funktionsnummer som skrivs i den första databyten. De övriga 7 databyten kan sedan användas till parametrar. I vissa fall räcker det inte med 7 databyte för parametrar t ex när en ny objektpott skall överföras till VTn. Då måste andra metoder användas och till det finns då Transport protocol och Extended transport protocol. (ISO 11783-6)

2.6. Intressanta funktioner i ISOBUS standarden 19 VT till ECU ECU till VT Data längd 8 byte 8 byte Data page field 0 0 PDU format 230 231 PDU special Mottagaradress Mottagaradress Prioritet 7 7 PGN E6XX E7XX Tabell 2.3: Meddelande ID 2.6 Intressanta funktioner i ISOBUS standarden Det finns ett antal funktioner beskriva i ISOBUS-standarden men här beskrivs endast två stycken av dem och det är Transport Protocol och Address Claming. 2.6.1 Transportprotokoll funktionen Som tidigare nämnts finns ibland behovet att överföra större mängder data och då måste man använda sig av ett transportprotokoll. Standardprotokollet som enkelt kallas för Transport protocol kan överföra från 7 till 1 785byte och Extended transport protocol kan överföra (117 440 512 byte). Principen dessa protokoll arbetar efter är att de öppnar en kommunikation med mottagaren och sedan skickar de meddelande efter meddelande med data och när alla data är sända skickar mottagaren ett meddelande och bekräftar att data kommit fram. Här följer en kort beskrivning av de kommandon som används för att öppna och stänga en transportkanal. (SAE J1939-21, Junger 2004) Transport Protocol RTS Request to send skickas från den nod som önskar skicka data till den nod som den vill skicka till för att meddela att den vill börja en överföring. I detta meddelandet finns t ex information om hur många paket som skall skickas och hur många byte meddelandet är. CTS Clear to send är svar från mottagaren på ett RTS-meddelande att den är klar att börja ta emot data. DT Data Transfer innehåller ett datapaket om 7 byte. Den första byten talar om vilket paketnummer som paket i meddelandet har och de övriga 7 innehåller data. Dessa meddelanden sänds så många som specificerats i RTS vilket max kan vara 255 stycken. EOMA End Of Msg ACK skickas från mottagaren av data för att meddela att alla data kommit fram. En Transportprotokoll överföring finns illustrerad i figur 2.8a. Skillnaden mellan Extended Transport protocol och Transport protocol är inte stor. Då Transport protocol är begränsad till att bara kunna skicka 256 DT-meddelanden har man i Extended Transport protocol möjlighet att skicka gupper om 256 DT-meddelanden. Varje sådan grupp börjar men ett DPO

20 Kapitel 2. Teori (a) Transport protocol (b) Extended Transport protocol Figur 2.8: Transportprotokoll (Data Packet Offset) meddelande. Poängen med DPO är att om man vill veta indexet på ett paket som överförts tar man senaste DPO-värdet och adderar med paketnummer (DPO offsetvärde + DP paketnummer = paketets nummer i hela överföringen). Extended Transport Protocol DPO Data Packet Offset anger numret på gruppen av datapaket. En Extended Transport Protocol överföring finns illustrerad i figur 2.8b. Övriga meddelanden för att etablera kommunikationen är inte likadana men har en liknade funktion som i Transport Protocol. (SAE J1939-21, Junger 2004) 2.6.2 Address Claming På en ISOBUS har alla noder en unik Source Address. Den adressen används när data skall skickas till en speciell nod och som avsändare på samtliga meddelanden en nod sänder. När en ny nod kopplas upp på bussen måste noden erhålla en unik adress och det sker genom address claming. Hur en node erhåller sin adress beror lite på vilka typ av node det är. Det finns 4 typer av noder:

2.6. Intressanta funktioner i ISOBUS standarden 21 Non configurable address ECU Noden har en fast adress som inte går att ändra. Service configurable address ECU Noden har en fast adress men den kan ändras av en servicetekniker eller med ett CANmeddelande i serviceläge. Command configurable address ECU Noden har en fast adress som kan ändras med ett CANmeddelande. Self configurable address ECU Noden hittar själv en ledig adress som den ansluter med. De icke självkonfigurerande noderna gör en förfrågan om den adress de önskar är ledig, är adressen ledig kommer noderna att skicka ut ett meddelande och tala om att de har erhållit den adressen. Skulle någon annan nod svara att den redan har tagit den adress som den nya noden frågar efter uppstår en konflikt. Vem som erhåller adressen beror på nodens namn, se nedan. Till skillnad från en icke självkonfigurerande nod gör en självkonfigurerande nodenförfrågan till samtliga noder på nätet efter vilken adress de har. Då har noden möjlighet att räkna ut vilka adresser som är lediga och sedan skicka ut ett meddelande och berätta vilken adress den har valt. Arbitrary Vehicle Address Industry System Vehicle Capable Group Instance System Reserved 1 bit 3 bitar 4 bitar 7 bitar 1 bit Byte 8 Byte 8 Byte 8 Byte 7 Byte 7 Function ECU Manufacturer Identity Function Instance Instance Code Number 8 bitar 5 bitar 3 bitar 11 bitar 21 bitar Byte 6 Byte 5 Byte 5 Byte 4/3 Byte 3/2/1 Tabell 2.4: Uppbyggnad av nodnamn Både självkonfigurerade och icke självkonfigurerande noder har ett namn. Namnet består av 8 byte och innehåller koder för vad noden har för funktion, tillverkarkod, idnummer mm se figur 2.4. På ett ISOBUS-nät måste samtliga uppkopplade noder ha ett unikt namn. Detta namn avgör vilken nod som erhåller en adress om det skulle uppstå en konflikt. När noden skickar ut sin förfrågan om en viss adress är ledig skickar den ett CAN-meddelande där nodnamnet utgör de 8 databyten i meddelandet. Då kan de noder som mottar förfrågan och har samma adress jämföra namnet och noden med lägst numeriskt värde på namnet kommer att erhålla adressen. Den mest signifikanta biten i namnet är en indikering på om noden är självkonfigurerande, och 0 skall tolkas som självkonfigurerande. Detta gör att icke självkonfigurerande noder alltid vinner över självkonfigurerande noder som dåfår söka upp en ny adress.