Implementering av ISOBUS Virtual Terminal p˚a ...21233/FULLTEXT01.pdfa Virtual Terminal program. An...

Implementering av ISOBUS Virtual Terminal pafordonsdatorn CCP XS

Examensarbete utfort i Elektroniksystemvid Linkopings tekniska hogskola

av

Anders Oberg

LiTH - ISY - EX - - 05 / 3732 - - SE

Linkoping 2005

Implementering av ISOBUS Virtual Terminal pafordonsdatorn CCP XS

Examensarbete utfort i Elektroniksystemvid Linkopings tekniska hogskola

av

Anders Oberg

LiTH - ISY - EX - - 05 / 3732 - - SE

Handledare: Michael Johansson,CC-Systems, Uppsala

Examinator: Kent Palmkvist,Institutionen for systemteknik,Linkopings Universitet

Linkoping: december 2005

Abstract

Modern agriculture equipment are more computer based today, and many equip-ments use a terminal in the tractor where the driver have the opportunity tomake adjustments to the equipment. This is the reason why ISO developed anew standard called ISOBUS. It is a communication standard based on CANspecially adapted for agriculture equipments. The purpose of the standard isthat it should be possible to equip a tractor with a standard terminal calledVirtual Terminal that can be used to control the equipment. The use of theterminal should be independent of the manufacturer of the tractor as well as ofthe equipment.

The purpose of this report is to find a solution of how to use CC Systemson-board computer, CCP XS, as a Virtual Terminal. In the report both Hard-ware and Software requirements have been examined, but mainly the softwarerequirements. Only one suitable software vendor, Vector Informatik, was foundafter contacts with different software suppliers. It have not been possible to testthis package because of the high price for the evaluation license.

A demonstration solution has also been developed in the project. It consistsof a simulator program, that runs on a PC, connected to a CPP XS that executesa Virtual Terminal program. An ISOBUS compatible J1939 protocol stack fromIxxat Automation has been integrated in the Virtual Terminal program. It givesthe opportunity to test the protocol stack on a CPP XS. In order to limit thesize of the project, not all functions in the ISOBUS standard is implemented inthe demonstration solution.

Keywords: ISOBUS, ISO 11783, Virtual Terminal, VT, J1939, CAN,CCP XS, agriculture equipment, on-bord computer

Oberg, 2005. v

Sammanfattning

Moderna jordbruksredskap har blivit allt mer datoriserade och manga anvandersig av en terminal i traktorn dar foraren har mojlighet att gora installningar paredskapet. Darfor har en standard for detta tagits fram av ISO kallad ISOBUS.Det ar en kommunikationsstandard baserad pa CAN speciellt framtagen forjordbruksmaskiner. Syftet med standarden ar att en traktor skall kunna varautrustad med en standardterminal kallad Virtual Terminal som anvands for attstyra redskapen. Denna terminal skall kunna anvandas till samtliga redskap somkopplas till traktorn oberoende av vem som tillverkar redskapen eller traktorn.

Syftet med rapporten ar att hitta en losning for hur CC Systems fordons-dator CCP XS kan anvandas som en Virtual Terminal. I rapporten har delskraven pa hardvaran undersokts men det storsta arbetet har lagts pa att hittaen lamplig mjukvarulosning. Efter att ha kontaktat olika leverantorer av mjuk-vara har endast ett lampligt mjukvarupaket hittats och det levereras av VectorInformatik. Dock har inte detta paket kunnat testas pa grund av det hoga prisetpa en utvarderingslicens.

Det har ocksa i projektet tagits fram en demonstrator som bestar av ensimulator for PC som kopplas till en CCP XS som kor en Virtual Terminalmjukvara. I programvaran for Terminalen valdes en ISOBUS kompatibel J1939protokollstack fran Ixxat Automation att anvandas, for att fa mojlighet attprovkora den protokollstacken pa CCP XS. For att arbetet inte skulle bli forstort har dessa programvaror begransats till att endast stodja vissa funktioneri ISOBUSstandarden.

Nyckelord: ISOBUS, ISO 11783, Virtual Terminal, VT, J1939, CAN,CCP XS, jordbruksmaskiner, fordonsdator

Oberg, 2005. vii

Forord

Jag skulle vilja tacka min handledare for hjalpen under examensarbetet ochaven den ovriga personalen pa CC Systems som hjalpt till att losa problem somhar uppstatt.

Oberg, 2005. ix

Innehall

1 Inledning 11.1 Problemformulering . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Mal och syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Avgransning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Teori 32.1 Bakgrund till ISOBUS . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Oversikt av ISOBUS system . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Systemuppbyggnad . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Electronic control unit (ECU) . . . . . . . . . . . . . . . . 52.2.3 Virtual terminal (VT) . . . . . . . . . . . . . . . . . . . . 52.2.4 Tractor ECU . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.5 Task controller . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 CAN 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.1 Historien om CAN-bussen . . . . . . . . . . . . . . . . . . 72.3.2 Lager i CAN-bussen . . . . . . . . . . . . . . . . . . . . . 72.3.3 Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.4 Message Filtering . . . . . . . . . . . . . . . . . . . . . . . 122.3.5 Felhantering i noderna . . . . . . . . . . . . . . . . . . . . 12

2.4 Meddelanden pa implementbussen . . . . . . . . . . . . . . . . . 132.4.1 Exempel pa ett meddelande . . . . . . . . . . . . . . . . . 13

2.5 Detaljstudie av Virtual Terminal . . . . . . . . . . . . . . . . . . 142.5.1 Fysiska uppbyggnaden . . . . . . . . . . . . . . . . . . . . 142.5.2 Objektpott och Working sets . . . . . . . . . . . . . . . . 162.5.3 Inmatnings objekt . . . . . . . . . . . . . . . . . . . . . . 172.5.4 Special objekt . . . . . . . . . . . . . . . . . . . . . . . . . 172.5.5 Alarmmask . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5.6 Fonter i VT . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5.7 Pekskarm . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5.8 Auxiliary control . . . . . . . . . . . . . . . . . . . . . . . 182.5.9 Meddelande uppsattning for VT . . . . . . . . . . . . . . 18

2.6 Intressanta funktioner i ISOBUS standarden . . . . . . . . . . . . 192.6.1 Transportprotokoll funktionen . . . . . . . . . . . . . . . 192.6.2 Address Claming . . . . . . . . . . . . . . . . . . . . . . . 20

2.7 ISOBUS jamfort med J1939 . . . . . . . . . . . . . . . . . . . . . 222.7.1 Anvanda J1939 applikationer pa en ISOBUS . . . . . . . 23

2.8 Utvecklig av ISOBUS-standarden . . . . . . . . . . . . . . . . . . 24

Oberg, 2005. xi

xii Innehall

3 CCP XS I VIRTUAL TERMINAL UTFORANDE 253.1 Mjukvara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 Hardvara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 DISKUSSION OCH SLUTSATSER 274.1 Olika tillvagagangssatt for att implementera en VT . . . . . . . . 27

4.1.1 VT fran CANoe . . . . . . . . . . . . . . . . . . . . . . . 284.1.2 Kopt Stack till Egen VT . . . . . . . . . . . . . . . . . . . 284.1.3 Stack med oppen kallkod till Egen VT . . . . . . . . . . . 284.1.4 VT fran annan hardvarutillverkare . . . . . . . . . . . . . 294.1.5 Metod for att hitta leverantorer . . . . . . . . . . . . . . . 294.1.6 Uppfoljning av sparen . . . . . . . . . . . . . . . . . . . . 304.1.7 Resultat av sparet VT fran CANoe . . . . . . . . . . . . . 304.1.8 Resultat av sparet Kopt Stack till Egen VT . . . . . . . . 314.1.9 Resultat av sparet Stack med oppen kallkod till Egen VT 334.1.10 Resultat av sparet VT fran annan hardvarutillverkare . . 33

4.2 Slutsatser och val av lampliga mjukvara . . . . . . . . . . . . . . 344.2.1 Mjukvarulosning till en kommersiell VT . . . . . . . . . . 344.2.2 Mjukvarulosning till en demonstrator VT . . . . . . . . . 34

4.3 Testutrustning for en VT . . . . . . . . . . . . . . . . . . . . . . 354.3.1 I/O-enhet fran godtycklig maskin . . . . . . . . . . . . . . 354.3.2 I/O-enhet fran en tillverkare av enheter som man sjalv

programmerar . . . . . . . . . . . . . . . . . . . . . . . . 354.3.3 Simulering i en PC med CAN adapter . . . . . . . . . . . 354.3.4 Ytterligare en CCP XS som kors som node . . . . . . . . 36

4.4 Simuleringsmojligheter . . . . . . . . . . . . . . . . . . . . . . . . 364.4.1 CANoe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4.2 SimECU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.4.3 Egenskrivet simuleringsprogram . . . . . . . . . . . . . . . 384.4.4 Mask Generator . . . . . . . . . . . . . . . . . . . . . . . 384.4.5 CanTool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4.6 Val av simulerings mojlighet . . . . . . . . . . . . . . . . . 39

4.5 Hur paverkar utvecklingen av ISOBUS-standarden CC Systems . 404.6 Ytterligare funktioner till CCP XS . . . . . . . . . . . . . . . . . 41

5 DEMONSTRATORN 435.1 Avgransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2 Simulatorprogram . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.1 Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2.2 Uppbyggnad . . . . . . . . . . . . . . . . . . . . . . . . . 455.2.3 Anvandarmanual . . . . . . . . . . . . . . . . . . . . . . . 46

5.3 VTprogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.3.1 Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.3.2 Terminalen . . . . . . . . . . . . . . . . . . . . . . . . . . 485.3.3 Uppbyggnad . . . . . . . . . . . . . . . . . . . . . . . . . 485.3.4 Anvandarmanual . . . . . . . . . . . . . . . . . . . . . . . 54

A Ordlista 59

B Meddelande i en CAN frame 61

Innehall xiii

C Mail 63C.1 Till potentiella leverantorer . . . . . . . . . . . . . . . . . . . . . 63C.2 Angaende mjukvaruleverantorer . . . . . . . . . . . . . . . . . . . 64C.3 Angaende utveckling av ISOBUS . . . . . . . . . . . . . . . . . . 65

D CCP XS Specifikation 67

E Relationsdiagram for VT objekt 69

F Uppbyggnad av VTprogram 71

xiv Innehall

Kapitel 1

Inledning

Rapporten beskriver ett examensarbete pa civilingenjorsutbildningen i TekniskFysik och Elektroteknik (Y-linjen) pa Linkopings Tekniska Hogskola. Arbetethar utforts pa foretaget CC Systems AB kring deras fordonsdator CCP XS.

CC Systems ar ett elektronikforetag som levererar elektroniklosningar ochprogramvara till framst fordon. Exempel pa fordon som anvander CC Systemssystem ar skogsmaskiner, entreprenadmaskiner, lastbilar, fartyg, jarnvagsfordonoch militara fordon. Foretaget utvecklar ocksa hardvara som till exempel for-donsdatorn CCP XS.

I denna rapport beskrivs en studie over hur fordonsdatorn CCP XS kananvandas som terminal i jordbruksmaskiner och hur den anpassas till jordbruks-standarden ISOBUS.

1.1 Problemformulering

For jordbruksmaskiner finns en ISO-standard, ISOBUS, som beskriver hur red-skap skall kommunicera med traktorn och med en terminal som finns i traktornkallad Virtual Terminal (VT). VTn ar en fordonsdator med skarm och speciellmjukvara for att kunna kommunicera med jordbruksredskapen.

CC Systems ar intresserade av att undersoka om deras fordonsdator kananvandas som VT i jordbruksmaskiner, vilka anpassningar av hardvara somkravs och vilka mjukvarukomponenter som maste finnas i datorn for att denskall uppfylla kraven i ISOBUS standarden.

1.2 Mal och syfte

Syftet ar att kunna anpassa fordonsdatorn CCP XS sa att den gar att anvandasom VT i ett ISOBUS-system. En oversyn av krav bade vad det galler hardvaraoch mjukvara skall gors. For att uppfylla kraven kommer ett antal mjukvarukom-ponenter att kravas och det skall undersokas vilka som kravs och vad som finnsatt kopa in och vad som maste nyutvecklas.

Det skall ocksa tas fram en demonstrator for att visa hur en CCP XS fungerari ett ISOBUSsystem.

Malet med arbetet ar att hitta lampliga mjukvarukomponenter som gor CCPXS ISOBUS kompatibel och att sedan kunna implementera dessa pa datorn.

Oberg, 2005. 1

2 Kapitel 1. Inledning

1.3 Avgransning

Arbetet att ta fram en demonstrator har tva avgransningar. Det ar inte mojligtatt gora ev nodvandiga anpassningar i hardvara. Dels kommer demonstratorn evinte att kunna uppfylla alla krav i standarden da tiden begransar mojlighetenatt implementera alla funktioner som kravs. Dock skall den fungera att koramed en begransad uppsattning av funktioner.

1.4 Disposition

Rapporten ar upplagd sa att den borjar med grundlaggande teori kring ISOBUSoch CAN. Sedan beskrivs hur utvardering och val av lampliga mjukvarupakethar bedrivits och vilka som har valts. Nar det gallde att valja mjukvarukom-ponenter fanns det olika mojliga losningar som har foljts upp som olika sparparallellt. I det avsnittet beskrivs ocksa olika simuleringsmojligheter som finnsfor testning av terminaler. Slutligen kommer avsnittet som beskriver den demon-strator som utvecklats och hur den anvands.

Teoridelen beskriver bakgrunden for CAN och ISOBUS. Om detta redan arvalbekant sa gar det bra att hoppa over teoridelen och hoppa direkt fram tillavsnitten som behandlar val av mjukvarukomponenter.

I rapporeten finns ocksa nagra forslag pa hur man kan arbeta vidare medCCP XS och ISOBUS och dessutom forslag pa ytterligare funktioner som skullekunna implementeras.

For att underlatta lasningen av rapporten finns det en ordlista i bilaga Adar tekniska termer kring omradet beskrivs.

Kapitel 2

Teori

For att forsta vilka funktioner som ingar i en VT har hela ISOBUS-standardenstuderats for att fa en forstaelse for hur ett ISOBUS-system fungerar. Sedanhar en fordjupning gjorts i de delar av standarden som beror just VT. EftersomISOBUS bygger pa en CAN-buss har ocksa en grundligare studie gjorts avstandarden for CAN-bussar och hur meddelanden overfors pa en CAN-buss.

Metoden for studien har varit att lasa litteratur, dels standarddokumentfran ISO (International Organization for Standardization) och SAE (Society ofAutomotive Engineers) men ocksa olika artiklar.

For att fa svar pa fragor och funderingar kring standarden har ocksa nagrapersoner som arbetar med utveckling av ISOBUS standarden intervjuats.

2.1 Bakgrund till ISOBUS

Jordbruksmaskiner har som mycket annat blivit mer avancerade och kravermer elektronik. Manga tillverkare har darfor konstruerat egna styrsystem medegna protokoll for att styra sina maskiner. Med en sadan losning far man enkontrollenhet till varje redskap som man maste placera i hytten.

For att effektivisera jordbruket har man borjat anvanda fler redskap pa trak-torn samtidigt vilket leder till att man behover kunna styra alla dessa samtidigt.Om man inte vill ha en kontrollenhet till varje redskap kravs att man har nagonform av standard for hur ett styr- och informationssystem for redskapen skallfungera. I jamforelse med att ha fristaende styrenheter ar det betydligt billi-gare att ha ett standardsystem som fungerar till alla de olika enheterna. Demer avancerade styr- och informationssystemen som nu kravs i maskinerna led-er ocksa till att varje redskaps- och fordonstillverkare inte har mojlighet attutveckla sina system sjalva. Om alla redskap foljer en standard, blir det lattareatt handla ett fardigt system fran nagon extern tillverkare.

ISO 11783 kallas ISOBUS och ar en standard som har tagits fram av traktor-och redskapstillverkare for att reglera hur kommunikationen mellan traktor ochredskap skall fungera.

Nar standarden skulle tas fram utgick man fran befintliga standarder. Denmest lampade som redan fanns for bilar, SAE J1939, har fatt bidra med infor-mation om hur datakommunikationen och kommunikationsnatet skulle byggasupp. En annan standard, DIN 9684, som man nationellt tagit fram i Tyskland

Oberg, 2005. 3

4 Kapitel 2. Teori

for kommunikation i jordbruksmaskiner, fick bidra med information om hur in-formationspresentation till foraren och export och import av data till fordonenskulle ske. Import och export av data kan vara anvandbart nar man t ex villhamta statistik fran ett redskap. (Stone m.fl. 1999, Fellmeth 2003)

2.2 Oversikt av ISOBUS system

Figur 2.1: Oversikt av ISOBUS-system

ISOBUS-standarden ar overgripande och innehaller information om alla delari ett styr- och informationssystem for jordbruksmaskiner och dess redskap. Ettexempel pa ett ISOBUS-system finns i figur 2.1.

2.2.1 Systemuppbyggnad

ISOBUS-systemet ar uppbyggt kring en CAN 2.0b buss dar en eller flera noderkan kopplas in. Detta natverk ar uppbyggt av tva delnat. Dels en traktorbussdar kommunikation for att traktorn skall kunna koras finns. Detta nat kopplart ex ihop motor med vaxellada och styrpanel. Sedan finns det ytterligare enbuss, implement buss, dar kommunikation med redskapen finns. Dessa tva natar inte helt atskilda utan sammankopplade med en Tractor ECU for att kunnafora information mellan naten.

Implementbussen stracker sig ocksa utanfor traktorn via standardiseradekontakter placerade pa traktorn dar mojlighet finns for att montera redskap.Det finns ocksa en kontakt som sitter i forarhytten for att kunna koppla paECUer och VT i hytten.

Implementbussen maste termineras i andarna och darfor har man tagit framen kontakt som har inbyggd automatisk terminering om inget ar anslutet. Dennatyp av kontakt skall ocksa sitta pa de redskap som har mojlighet att koppla paytterligare ett redskap efter sig.

2.2. Oversikt av ISOBUS system 5

Kabeln som anvands till bussen ar en partvinnad fyrledarskabel i ett holje.De fyra ledarna benamns CAN L, CAN H, TBC PWR och TBC RTN dar detva forsta anvands for datatrafiken och de tva sista endast anvands for attstrom-forsorja termineringarna i slutet av bussen.

Bussen har fysikaliska begransningar i att den maximalt far vara 40 meterlang och man kan ansluta ECUer var som helst men inte tatare en 0,1 meter franvarandra och grenar far inte vara langre en 1 meter. Bussen ar ocksa begransadtill ett max pa 30 st ECUer. (Stone m.fl. 1999)

2.2.2 Electronic control unit (ECU)

ECUer ar noder i natverket och sitter pa alla redskapen samt i fordonet. Dessaenheter innehaller en I/O-del for att kunna gora matningar och installningarpa redskapen. For att kunna presentera information och for att kunna fa in-stallingar gjorda anvander ECUn VTn som granssnitt mot foraren. Eftersomdet finns flera olika typer av VT i standarden skickar ECUn en fraga till VTnom vilka egenskaper den har i form av display och knappar mm. Utgaende ifranden informationen kan ECUn ha olika bilder lagrade och skickar den som passarbast till VTn. Da kan foraren gora installningar pa och lasa av matdata franredskapet med hjalp av VTn i fordonet. (Stone m.fl. 1999)

2.2.3 Virtual terminal (VT)

Virtual terminal anvands for att presentera information och matdata fran red-skapen och gora installningar pa redskapen. Den ar uppbyggd av en display ochnagra typer av inmatningsmojligheter t ex knappar, joystick eller pekskarm.VTn ar helt passiv och fungerar liknande en weblasare dar de olika redskapensECUer skickar fardiga bilder att presentera pa skarmen, sa kallade masker. Imasken finns ocksa information om vad olika knappar skall ha for funktion.Varje ECU har en egen mask att presenterar pa VTn och foraren har sedanmojlighet att valja fran vilken ECU han vill se en mask for tillfallet.

En mask ar uppbyggd av in- och utmatningsfalt. Utmatninsfalten kan up-pdateras av ECU och om foraren andrar i ett inmatningsfalt overfors det nyavardet automatiskt till ECUn. VT har ocksa stod for att kunna rita olika typerav grafik. (Stone m.fl. 1999, ISO 11783-6)

2.2.4 Tractor ECU

Tractor ECU ar ett specialfall av ECU eftersom den anvands for att koppla sam-man implementbussen och traktorbussen. Denna ECU blir en sa kallad kommu-nikationsbrygga som filtrerar information fran de tva bussarna och bara slapperigenom relevant och tillaten information. De tva bussarna ar inte heller synkro-niserade med varandra sa bryggan har en buffert dar den buffrar data tills detfinns mojlighet att skicka den vidare till den andra bussen.

Bryggan tar ocksa bort en stor mangd information. Skulle all informationfran respektive nat overforas till det andra finns det risk for att bussarna bliroverbelastade. ECUerna pa implementbussen har inga begransningar i vilkainstruktioner de far skicka och for att inte olampliga instruktioner skall kunnapaverka traktorns gang filtreras dessa bort sa att de inte kan na traktorbussen.

6 Kapitel 2. Teori

Tractor ECU ar specificerad i del 9 av ISO standarden (ISO 11783-9). Stan-darden kraver att traktorn maste vara utrustad med en ECU for att formedlainformation om traktorn pa implementbussen. Tractor ECU kan vara av treklasser fran en enkel klass 1 som bara levererar matvarden fran traktorn, somt ex varvtal och hastighet. Denna klass ar tankt att anvandas for att enkelt gorabefintliga traktordesigner ISOBUSkompatibla. For nykonstruerade traktorer artanken att man skall anvanda klass 2 eller 3, dar klass 2 innehaller ytterligarematvarden och klass 3 aven kan ta emot installningar fran implement bussen.Som tillagg till klasserna finns N och F. Dar N star for att traktorn ar utrustadmed navigeringsutrustning (GPS) och F star for att traktorn har stod for attmontera redskap aven framtill. Klasser av typen N och F har da stod for ytterli-gare instruktioner relaterade till respektive funktioner. (Stone m.fl. 1999, ISO11783-9)

2.2.5 Task controller

Task controller ar en speciell komponent i ISOBUSsystemet som antingen ar enegen ECU eller implementerad i t ex VTn.

Task controllern har tva uppgifter. Den ena ar att skota kommunikationenmed omvarlden och den andra ar att genomfora s.k. tasks. Kommunikationenmed omvarlden sker med t ex flash diskar och man kan exportera och importeradata via task controllern. Man kan ocksa anvanda den till att kora tasks pa.Ett task ar en dynamisk installning av en eller flera parametrar pa ett eller fleraredskap. 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 pa CANstandarden, CAN 2.0b. For att kunna forstahur ISOBUSen fungerar beskrivs har hur CAN 2.0 fungerar. Till stora delarfoljer ISOBUSen CAN-standarden men det finns nagra funktioner i CAN 2.0-standarden som inte tillampas i ISOBUS-standarden. Har beskrivs hela CAN-standarden, men delar som inte tillampas i ISOBUS-standarden behandlas inteingaende.

CAN-bussen ar en seriebuss som saknar masternod och alla noder har mojlig-het att lasa alla meddelanden pa bussen. Olika meddelande har olika prioritetoch ar det flera noder som vill sanda pa bussen samtidigt far noderna tavlaom bussen och den nod som har ett meddelade med hogst prioritet vinner.Bussen har en hog sakerhetsniva med feldetektering och felsignalering. Om ettfel uppstar sker en automatisk omsandning nar bussen blir ledig igen. Skulle ettpermanent fel uppsta finns funktioner for att koppla bort den trasiga noden.

Kodningen av data pa CAN-bussen sker med Dominant och Recessive bitar.Om tva noder lagger ut data samtidigt, den ena en recessive bit och den andraen dominant bit kommer de andra noderna pa bussen bara att detektera endominant bit. (CAN specification 2.0, Part B)

2.3. CAN 2.0 7

2.3.1 Historien om CAN-bussen

I borjan av 1980 talet vacktes iden att borja anvanda ett elektriskt bussystemfor overforing av signaler i bilar. Ingenjorerna pa Bosch hade undersokt allabefintliga standarder och inte hittat nagon som uppfyllde alla de krav manstallde pa en sadan buss. Da borjade man att utveckla en egen buss och ifebruari 1986 kunde Bosch pa Society of Automotive Engineers (SAE) kongresspresentera en ny buss som fatt namnet Controller Area Network (CAN).

Efter detta publicerades ett antal dokument kring bussen och i mitten av1987 slapptes de forsta CAN-kontrollerchipen.

I borjan av 1990 publicerades den uppdaterade CAN bussen CAN 2.0 ochden presenterades for standardiseringsorganisationen ISO. ISO antog CAN 2.0som standard och publicerade den som ISO 11898 i november 1993.

CAN borjade anvandas i allehanda tillampningar i fordon och inom in-dustrin. Losningarna var manga och olika vad det gallde hogre lagers pro-tokoll i borjan av 1990 talet. For att styra upp de olika losningarna bildadesanvandargruppen CAN in Automation (CiA) 1992.

1992 introducerades ocksa CAN bussen i bilar. Mercedes-Benz lanserade enny modell av sin storsta kaross S-klassen det aret och de anvande CAN-bussenfor motorstyrning. Senare borjade man ocksa anvanda ytterligare ett CAN-nati bilar for att styra chassielektronik. De tva naten kunde kommunicera medvarandra via en s.k. gateway. (CAN specification 2.0, Part B)

2.3.2 Lager i CAN-bussen

CAN-bussen ar uppdelad i flera lager for att underlatta implementationen avCAN-bussapplikationer.

De olika lagrena hanterar olika funktioner och beskrivs har i ordning, franden fysiska bussen och uppat.

• Underst ligger Physical Layer som hanterar overforingen av databitar tillbussen. Detta lager ser till att signalnivaerna ar de ratta och synkroniserahardvaran med bussen. Alla noder i en buss maste ha ett likadant PhysicalLayer.

• Over Physical Layer ligger Data Link Layer som i sin tur ar uppdelad itva delar, Logic Link Control (LLC) och Medium Access Control (MAC).

LLC hanterar filtrering av meddelande och kan ocksa skicka ut over-belastningsmeddelanden.

MAC hanterar trafiken pa bussen. Den tar data fran LLC och skaparFrames med alla de delar som en Frame skall innehalla. MAC tar ocksaemot Frames fran Physical Layer och avkodar data for att skicka vidaretill Application layer. I MAC lagret sker ocksa felhantering genom kontrollav mottagna meddelande och felsignalering.

• Over detta finns ytterligare lager som t ex Application Layer dar data somskall overforas skapas.

(CAN specification 2.0)

8 Kapitel 2. Teori

2.3.3 Frames

All data pa bussen skickas i Frames. CAN 2.0 finns i version A och B, darskillnaden mellan dessa ar att B kan hantera tva format av frames. EftersomISOBUS anvander sig av 2.0B sa kommer den att redovisas har.

Det finns tva olika format pa frames som kallas Standard format (sammasom i CAN 2.0A) och Extended format. Det som skiljer dem at ar att Standardformat har en 11 bitar lang Identifier medan Extended format har en 29 bitarlang Identifier. (CAN specification 2.0, Part B)

Data Frame och Remote Frame

Dessa Frames anvands for att sanda data pa bussen respektive begara data franen annan nod. Dess uppbyggnad ar snarlik och en bit talar om att det ar enData eller Remote frame. Framen ar uppbyggd av 7 olika bitfalt som kan bestaav en eller flera bitar, som i figur 2.2.

Figur 2.2: Data frame

Start of frame - SOFForsta bitfaltet heter Start of frame och ar en bit langt och ar alltid dominant.Den anvands for att signalera att en frame har borjat sandas.

Arbitration field

Figur 2.3: Arbitration och Control field

Arbitration- och Control-faltets bestandsdelar ligger blandade i meddelandetoch bada visas i figur 2.3, dar Arbitration-faltets bestandsdelar ar graa ochControl-faltets bestandsdelar ar vita.

IdentifierIdentifiern anvands for att prioritera meddelanden och innehaller meddelandetsID. Nar identifiern laggs ut pa bussen kan flera noder gora det samtidigt. Dockkan inte flera noder sanda ett meddelande samtidigt sa de maste tavla ombussen. De noder som lagger ut bitar laser samtidigt av bussen for att se omnagon annan nod ocksa lagger ut en identifier. Sa lange som flera noder laggerut samma varde pa bitarna ar de med i tavlingen. Nar nagon nod lagger ut en

2.3. CAN 2.0 9

recessive och laser en dominant bit fran bussen har den noden forlorat och mastevanta med att sanda sitt meddelande. Det meddelande som har en identifier medlagst binart varde har hogst prioritet.

Kodning av bitar i CAN-meddelanden0 = dominant1 = recessiveOverforingen sker sa att IDets mest signifikanta bit sands forst.Identifierfaltet skiljer sig at beroende pa om det ar Standard eller Extended

format som overfors. Bada formaten har ett Base ID pa 11 bitar men skillnadenar att Extended format ocksa har ett Extended ID pa 18 bitar som standardformat saknar. Extended ID sands senare i en extendid identifier efter IDEbitfaltet.

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 for tva meddelande som forsoker sanda sam-

tidigt, det ena i standard format och det andra i extended format vinner alltidmeddelandet i standard format.

Remote Transmition Request - RTRDetta bitfalt ar en bit lang och anvands for att tala om ifall det ar en Remoteframe eller en Data frame som haller pa och sander.

Data frame = dominantRemote frame = recessive

Substitute Remote Request - SRRDet har ar ett bitfalt som bara anvands nar man sander i Extended format.Faltet bestar bara av en bit och ar en ersattning for RTR biten i standardformat.

Alltid = recessive

Control FieldIdentifier Extension Bit - IDEAnvands for att identifiera om det ar frame i Standard eller Extended format.

Extended format = recessiveStandard format = dominant

Data Length CodeI grunden bestar alltid data length code-bitfaltet av 6 bitar. Dock ar det sa iStandard format att den forsta biten i control-bitfaltet ar IDE biten som alltidskall vara dominant. Sedan kommer bitarna r1, bara i Extended format, och r0.Dessa kallas for reserved bits och skall alltid sandas dominant.

r0 alltid = dominantr1 alltid = recessive (Extended format)Efter reserved bitarna kommer 4 bitar som heter Data Length Code (DLC3

.. DLC0). Dessa bitar anvands for att tala om hur manga bytes som kommer attsandas i databitfaltet. Antalet databitar kan anges fran 0 till 8 och kodningenav dessa bitar sker binart liknade ID.

10 Kapitel 2. Teori

Om framen ar av typen Remote frame saknar den databitfalt och da saknassaledes betydelsen av ett Data Length Code, vardet satts da godtyckligt mellan0 och 8.

Data fieldI detta bitfalt sands den data som skall overforas. Faltets langd ar forbestamtoch redovisat i Control-bitfaltet och kan vara mellan 0 och 8 bitar. Skulle framenvara av typen Remote frame har alltid detta falt langden 0.

Cyclic Redundancy Code field - CRC

Figur 2.4: CRC och ACK field

I figur 2.4 visas CRC och ACK faltens delkomponenter. CRC sequence aren checksumma for att se att overforingen har blivit korrekt. I checksummaningar alla bitar fran Start Of Frame till sista data biten. Principen med CRC-koden ar att det meddelande man overfor inkl CRC-sekvensen skall ha en restpa 0 nar man dividerar (modulo-2 division) med ett fixt polynom. Att tanka paar att modulo-2 division inte ar som vanlig division utan additioner och sub-traktioner i modulo-2 sker utan minnessiffra. I CAN-standarden definieras detfixa polynomet till ’1100010110011001’. Eftersom det fixa polynomet ar kantfor bade sandare och mottagare kan sandaren latt rakna ut vilken CRC sekvenssom kravs for att fa en rest som ar 0 vid division.

Ett kort exempel pa 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 erhall en rest CM’ Mod P = C = ’1110’Skapa meddelandet T som ar M’ adderat med C.M’+C = T = ’11010110111110’Meddelandet T sands pa bussen.Mottagaren tar emot T och delar med P, vilket ger resten 0 forutsatt att med-delandet overforts korrekt.T mod P = 0

Om ett meddelande som overforts inte far resten 0 vid divisionen later mot-tagaren bli att sanda tillbaka nagot ACK meddelande. Da sander sandarenmeddelandet pa nytt. (CAN specification 2.0, A painless guide to crc error de-tection algorithms)

2.3. CAN 2.0 11

CRC delimiterCRC-koden foljs av en CRC delimiter som ar 1bit lang och sands recessive.

ACK FieldI ACK field sander mottagaren en bit for att meddela att meddelandet har mot-tagits korrekt.

ACK slotHar skall mottagaren meddela att den tagit emot ett korrekt meddelande. Sand-aren lagger ut en recessive bit pa bussen och alla mottagare som tagit emot ettkorrekt meddelande skall da lagga ut vardet dominant pa bussen.

ACK delimiterACK delimiter ar 1 bit lang och skall vara recessive.

End Of FrameVarje frame av typen Data och Remote Frame skall avslutas med en End offrame sekvens. Den bestar av 7 bitar och alla skall sandas recessive. (CAN spec-ification 2.0)

Error Frame

En error frame sands av noderna nar det har uppstat ett fel. Error framsenbestar av tva bitfalt.

Error flagDet finns tva olika error flags som kan sandas, Passive error flag och Active errorflag. Vid normal sandning pa bussen tillats bara 5 lika bitar i foljd att sandas,sedan maste en annan bit komma for att bussen inte skall tolka meddelandetsom felaktigt. Detta loser man da i sandaren genom att efter 5 lika bitar infogaen bit av motsatt tecken, avkodaren vet da att efter 5 lika bitar kommer en bitsom skall filtreras bort da den bara finns dar for att bryta sekvensen av likatecken. Denna process kallas for bit-stuffing.

Regeln att bara 5 lika bitar far sandas i rad anvands for att sanda en aktiverror flag som bestar av 6 stycken dominantbitar som sands i rad. 6 dominantabitar strider da mot regeln for bit-stuffing och det gor att alla noder latt kandetektera en aktiv error flag. Passiv error flag bestar av 6st recessivebitar somsands i foljd. Om dessa blir overskrivna av dominantbitar fortsatter noden attlagga ut recessive bitar till den har last 6 st i foljd fran bussen. (CAN specifica-tion 2.0)

Error delimiterError flag foljs av en error delimiter. Den bestar av 8 st recessivebitar. Nar ennod pa bussen detekterat en error flag borjar noden att sanda recessivebitar pabussen. Nar Noden detekterar den forsta recessiva biten pa bussen fortsatterden att sanda 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. For att sarskiljadem at far bara en Overload Frame starta vid 3 olika tillfallen i busstrafikenannars tolkas det som en Error Frame.

De tillfallen da en overload frame far borja sandas ar.

• Forsta biten av en forvantad intermission.

• Om man detekterar en dominant bit som forsta eller andra biten i enintermission (Overload framen borjar sandas en bit efter detekteringen).

• Om en dominat bit detekteras som den 8:e biten i en error intermission(Overload framen borjar sandas en bit efter detekteringen). (CAN speci-fication 2.0)

Interframe spacing Frame

Denna frame sands mellan Data frames. Den bestar av tva falt.

IntermitionIntermition bestar av 3 stycken recessivebitar. Om en node har fatt problemmed att hinna processa mottagen data kan den skicka en Overload Frame.Sandningen av en Overload Frame pa grund av overbelastning startar alltidi Intermition-faltet, det ar den enda typ av sandning som kan startas har.

Bus IdleBus Idle anvands for att signalera att bussen ar ledig. Detta bitfalt kan varahur langt som helt och den som vill sanda ar fri att skicka. Alla frames borjasmed en dominat bit, sa i bitfaltet Bus Idle skall en dominat bit tolkas som attnagon borjar sanda en frame. (CAN specification 2.0)

2.3.4 Message Filtering

I LLC-lagret finns ett filter som anvands for att filtrera vilka meddelande somskall laggas in i mottagningsbufferten. Detta filter filtrerar bort meddelande medIDn som den specifika noden inte ar intresserad av. (CAN specification 2.0)

2.3.5 Felhantering i noderna

Alla noder har ett avancerat system for felhantering. Detta for att en defektnod inte skall forstora for de ovriga noderna genom att lasta ner bussen medfelmeddelanden. En buss kan vara i tre lagen.

Active Error med mojlighet att sanda Active error frames.Passive Error med mojlighet att sanda Passive error frames men inte Active

error frames.Bus Off nar noden inte har mojlighet att sanda pa bussen alls.Feldetekteringen i noderna ar uppbyggd kring tva raknare, Transmit Er-

ror Count och Receive Error Count. Dessa raknare raknas upp och ner enligtforutbestamda regler. Se CAN 2.0 standarden for att se hur samtliga regler arutformade. Principen ar den att raknarna raknas upp nar noden har detekterat

2.4. Meddelanden pa implementbussen 13

ett fel pa bussen och ner nar den gor lyckade mottagningar och sandningar.Nar raknarna nar uppsatta brytvarden minskas eller okas nodens mojligheteratt sanda felmeddelanden eller anvanda bussen. (CAN specification 2.0)

2.4 Meddelanden pa implementbussen

I Application Layer kodas innehallet i meddelandena. Har skapas data som sedansands i Identifiern och Datafaltet i en frame.

Ett antal standardiserade parametrar finns for att beskriva information paimplementbussen. Parametrarna ar indelade i parametergrupper. En parame-tergrupp kan t ex vara Time/Date eller Lightning Data.

PGN = FF10PDU format = FFPDU specific = 10

Tabell 2.1: Exempel pa hur PGN-numret erhalls

Varje parametergrupp har ett PGN (Parameter Group Number) som bestarav PDU (Protocol Data Unit) format foljt av PDU specific, ett exempel finns itabell 2.1. Det finns tva typer av PGNs, en for att sanda globala meddelandeoch en annan for att sanda till en specifik mottagare. For att sanda globalt skallPDU format vara storre an 239 och PDU specific kan vara mellan 0 och 255.Om man skall sanda till en specifik mottagare skall PDU format vara mindrean 240 och PDU specific anvandas for mottagaradressen.

Varje parametergrupp har ytterligare egenskaper och tillsammans med PGNbildar de Frame Identifier.

Figur 2.5: Uppdelningen av Identifierbitfaltet enligt ISO 11783

Pa CAN-bussen far inget meddelande ha samma Identifier da konflikter kanuppsta nar flera noder tavlar om bussen genom att skicka samma Identifier. Avdenna anledning har man infort Source address som gor att alla noder far unikaadresser som inkluderas i Identifiern. En komplett identifierare visas i figur 2.5och identifieraren foljs sedan av 0 - 8 st databytes. (Junger 2004)

2.4.1 Exempel pa ett meddelande

Om traktor ECUn skall skicka ut information om vad klockan ar ska medde-landet se ut som foljer. I exemplet i tabel 2.2 antas att traktorns klocka star pa12:47:51,25 (GMT) med lokal avvikelse fran GMT pa -6h. Datumet for dagenar 2005-03-14. (ISO 11783-7)

14 Kapitel 2. Teori

Data length 8 byteData page 0PDU format 254 0xFE Storre an 239, Globalt meddelandePDU specifik 230 0xE6PGN 65254 0xFEE6Default priority 6

De tolv databitarna i gruppen har foljande innehallByte 1, Sekunder 0,25s/bit 205 (0xCD)Byte 2, Minuter 1min/bit 47 (0x2F)Byte 3, Timmar 1h/bit 12 (0x0C)Byte 4, Manad 1manad/bit 03 (0x03)Byte 5, Dag 0,25dag/bit 56 (0x38) Har kan dag 1 anges som

0,25; 0,5; 0,75; och 1, lik-nade galler for samtligadagar.

Byte 6, 1ar/bit + 1985 20 (0x14) Ar anges som antal ar fran1985.

Byte 7, Lokal offset 1min/bit 0 (0x0)Byte 8, Lokal offset 1h/min -24h 18 (0x12) Varde 0 anger -24h varde

1 -23 osv till 47 som anger+23h.

Tabell 2.2: Parametergruppen Date/Time

Nar detta meddelande sedan skall sandas packas det i en standard CAN framesom visas i figuren som finns i appendix B.

2.5 Detaljstudie av Virtual Terminal

For att jamfora olika mjukvarupaket for VTn beskrivs har VTn i detalj. Blandannat beskrivs vilka funktioner som ar grundfunktioner enligt standarden, ochsom maste inga och vilka eventuella funktioner som ar tillval. For att sedan kun-na implementera mjukvarupaketet pa CCP XS kommer har ocksa att beskrivashur meddelanden rorande VT byggs upp och hur de skickas pa bussen.

2.5.1 Fysiska uppbyggnaden

VT skall vara ett granssnitt mellan foraren, maskinen och de olika redskapen.Darfor har VTn funktioner for grafisk presentation och inmatning. For att intetrafiken pa CAN-bussen skall bli for stor nar en VT anvands bygger all presen-tation pa objekt som ar fordefinierade i standarden och sedan kan anropas avolika ECUer pa bussen. All information visas pa displayen som skall vara pixel-adresserbar och som sedan delas upp i olika masker, Data mask, Alarm maskoch Soft Key mask. Data till dessa masker ar unik for varje redskap och laddasin till VTn antingen fran ECUn via CAN-bussen eller fran t ex ett minneskort.Nar maskerna sedan finns i VTn kan en ECU enkelt byta mask pa displayengenom att sanda ett Change Active mask kommando.

2.5. Detaljstudie av Virtual Terminal 15

Figur 2.6: Exempel pa en VT display

VTn staller krav pa att vissa funktioner for inmatning och styrning mastefinnas. VTn skall ha ett antal knappar som antingen kan implementeras sommjukvaruknappar pa en pekskarm eller som fysiska knappar implementerade ihardvara. Anvands hardvaruknappar till Soft key funktionen bor de vara plac-erade langs skarmkanten som i figur 2.6 sa att funktion tydligt kan presenteraspa skarmen genom att skriva i skarmkanten bredvid en knapp. I figur 2.7 visasde inmatningskontroller som skall finnas.

Soft key ar en knapp som mjukvaran kan koppla olika funktionertill och som ocksa kan representera olika text beroende pafunktion. Varje mask kan innehalla 6 -64 softkeys och kaninte alla visas samtidigt skall stod finnas for att skrolla framalla knappar.

Navigationkeys

ar piltangenter som skall anvandas for att hoppa mellanolika inmatningsfalt.

Editingkeys

anvands for att andra det installda vardet i ett markeratinmatningsfalt. Med dessa knappar maste man kunna valjavilken siffra eller bokstav som helst som gar att mata in iden specifika falttypen. Detta loser man enklast med pil-tangenter for att skrolla genom alla giltiga tecken.Det skall ocksa finnas en Enterknapp for att meddela tillECUn att en datainmatning ar klar och en ESC knapp foratt meddela att man avbrutit en datainmatning.

16 Kapitel 2. Teori

Control bestar av tva knappar. En knapp som anvands for att vaxlamellan olika redskap som man vill kontrollera nar flera red-skap ar anslutna till fordonet. Denna knapp ska ha 3 pilar ien cirkel som symbol. Den andra knappen, ACK, anvandsfor att bekrafta att man mottagit en varning och den skickarda en bekraftelse till redskapets ECU.

Auxiliaryinput

ar en ytterligare uppsattning av funktioner for inmatningav data som t ex kan besta av en joystick eller rattar.

Figur 2.7: Exempel pa Inmatningskontroller

En ytterligare funktion som skall finnas i anvandargranssnittet mot forarenar ett akustiskt alarm. Detta kan vara nagon typ av ljudsignal fran enklaste sum-mer till mer avancerade enheter med variabel frekvensatergivelse. (ISO 11783-6)

2.5.2 Objektpott och Working sets

Varje redskap som kopplas till traktorn bildar ett Working set i VTn. Det aringet krav att varje redskap endast har en ECU, flera kan sitta pa sammaredskap men det maste da finnas en master som ar ansvarig for working setet.Ett working set innehaller en eller flera data, soft key- och alarm-masks. Dessamasker byggs sedan upp av objekt som finns i working setets objektpott darvarje objekt har ett unikt objektID.

For att de olika redskapens noder skall veta vilka objekt den skall sanda tillVTn skickar VTn ut information om vilket sprak, mattsystem, tidssystem mmsom den ar installd for och aven information om vilka fysiska egenskaper den harsom upplosning, fargskarm mm. Med den informationen har noderna mojlighetatt skicka olika objekt beroende pa VTns installningar och egenskaper.

VTn kan sedan visa ett working set at gangen och endast foraren har mojlighetatt byta working set. Nar foraren trycker pa Control-knappen for byte av work-ing set byter VTn aktivt working set pa displayen och ett meddelande sands utpa bussen att ett nytt working set har aktiverats.

2.5. Detaljstudie av Virtual Terminal 17

Dock kan ett working set sjalv valja vilken mask det vill visa. ECUerna kan ocksakontinuerligt byta egenskaper pa objekt oberoende av om ett visst working setar aktivt eller inte. ECUerna kan ocksa skicka instruktioner om att ta bort ochlagga till objekt under gang. (ISO 11783-6)

2.5.3 Inmatnings objekt

VT har stod for inmatning av de 4 datatyperna string, booleans, lists och num-bers. Nar anvandaren navigerar mellan olika inmatningsfalt skickas informationtill noderna om vilket falt som ar aktivt. Andringar i inmatningsfalten sandsut pa bussen nar anvandaren trycker pa Enter. Skulle anvandaren inte viljafullfolja en inmatning kan han trycka pa Escape eller hoppa till ett annat falt,i bada fallen sands ett Escapemeddelande ut pa bussen. (ISO 11783-6)

2.5.4 Special objekt

Det finns nagra specialobjekt som inte ar vanliga falt eller figurer mm. Dessaanvands framst for att gora andringar av objekt effektivare sa att de inte tarfor mycket utrymme pa bussen.Containerobjects

Anvands for att gruppera andra objekt. Ett sadant objektar t ex anvandbart nar man har en grupp av objekt somman samtidigt vill kunna dolja genom att gora contain-ern osynlig. Man kan ocksa ateranvanda en contaier i fleramasker om man enkelt vill anvanda en uppsattning av ob-jekt i flera masker.

Attributeobjekt

Anvands for att kunna andra utseende pa flera objekt sam-tidigt. Om flera objekt anvander samma font-attribut ob-jekt, och de andras, da andras alla objektens font.

Variableobjekt

Fungerar som en variabel, anvands av flera objekt som skallha en gemensam egenskap.

Makron Ett objekt som kan utfora ett antal instruktioner. Man kant ex anropa ett fardigt makro med 1 instruktion och detutfor sedan 10 instruktioner i stallet for att sanda alla 10instruktionerna over bussen.

(ISO 11783-6)

2.5.5 Alarmmask

Nar en nod vill larma visar den en alarmmask. Alarmmasken tacker hela dendel av skarmen som annars tacks av datamasken. Till alarmmasken finns ensoft key mask kopplad. Skulle flera noder forsoka att visa alarmmasks visasden mask som har hogst prioritet. Alarmmasken forsvinner sedan nar man harbekraftat den genom att trycka ACK. I vissa fall vill noden att man valjer ettalternativ med knapparna och da kommer noden att ignorera ACK tryckningaroch 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 for att man latt skall kunna placeratecken bredvid och under varandra. Teckenstorleken anges som pixlar bredd xhojd och far inte vara mindre an 6x8pixlar. Det ar fritt for konstruktoren avVTn att valja vilka och hur manga fonter han vill implementera men ett kravar att 6x8 normal skall finnas. (ISO 11783-6)

2.5.7 Pekskarm

I standarden for VT finns stod for pekskarm med det ar inget krav. En nodkan skicka en forfragan for att fa veta om VTn har pekskarm, om noden onskarkan den sedan anpassa sina objekt for pekskarm eller inte. Om skarmen ar avpekskarms typ kan knappar inkluderas i datamasken, det gar ocksa att fa ettmeddelande pa bussen var i datamasken som anvandaren har tryckt oberoendeav om det finns en knapp dar eller ej. (ISO 11783-6)

2.5.8 Auxiliary control

Auxiliarys ar inmatningsfunktioner som inte ar en del av VTn utan sitter separatsom t ex ytterligare knappar eller en joystick. Det kan dock ocksa vara en delav den fysiska VTn om den har ytterligare knappar utover de som tidigarebeskrivits for VTns funktion. Auxiliarys fungerar sa att man tilldelar dem tillen viss funktion pa ett visst redskap, och du kan da styra den funktionen medden tilldelade Auxiliaryn oberoende av vad som hander pa VTn. Ett workingset for en maskin kan innehalla Auxiliary function objects, ett sadant objekt aren koppling till en viss funktion pa ett redskap. Varje Auxiliary control, somt ex ar en kontrollada med knappar, bildar ocksa ett working set i VTen. Dettaworking set innehaller dock bara Auxiliary input objects, som ar en kopplingtill en viss knapp, ratt ect. En Auxiliary kan vara av tre typer analog, latchingboolean eller non-latching boolean. Boolean genereras av t ex knappar och enlatching innebar en knapp som stannar kvar i intryckt lage till skillnad fran non-latching som aterfjadrar nar man slapper den. Analoga Auxilirys presenterar sinposition som ett procent av maxvardet.

Kopplingen mellan Auxiliary input objekts och Auxiliary function objectssker i VTn pa en speciell skarmbild som heter Auxiliary control setup.(ISO 11783-6)

2.5.9 Meddelande uppsattning for VT

Det finns ett stort antal meddelanden som VTn skall stodja. Det ar alldelesfor manga for att ta upp har utan de finns att lasa i standarden ISO 11783-6.Dessa meddelanden ar uppbyggda enligt CAN-standarden. For att meddelande-na sedan skall fa olika innebord finns innehallet i de 8 databyten specificerade istandarden. Meddelanden till och fran VTn har identifiering enligt figur 2.3.

De olika instruktionerna som sedan skickas med meddelandet har ett funk-tionsnummer som skrivs i den forsta databyten. De ovriga 7 databyten kansedan anvandas till parametrar.

I vissa fall racker det inte med 7 databyte for parametrar t ex nar en nyobjektpott skall overforas till VTn. Da maste andra metoder anvandas och tilldet finns da Transport protocol och Extended transport protocol. (ISO 11783-6)

2.6. Intressanta funktioner i ISOBUS standarden 19

VT till ECU ECU till VTData langd 8 byte 8 byteData page field 0 0PDU format 230 231PDU special Mottagaradress MottagaradressPrioritet 7 7PGN E6XX E7XX

Tabell 2.3: Meddelande ID

2.6 Intressanta funktioner i ISOBUSstandarden

Det finns ett antal funktioner beskriva i ISOBUS-standarden men har beskrivsendast tva stycken av dem och det ar Transport Protocol och Address Claming.

2.6.1 Transportprotokoll funktionen

Som tidigare namnts finns ibland behovet att overfora storre mangder dataoch da maste man anvanda sig av ett transportprotokoll. Standardprotokolletsom enkelt kallas for Transport protocol kan overfora fran 7 till 1 785byte ochExtended transport protocol kan overfora (117 440 512 byte). Principen dessaprotokoll arbetar efter ar att de oppnar en kommunikation med mottagaren ochsedan skickar de meddelande efter meddelande med data och nar alla data arsanda skickar mottagaren ett meddelande och bekraftar att data kommit fram.Har foljer en kort beskrivning av de kommandon som anvands for att oppnaoch stanga en transportkanal. (SAE J1939-21, Junger 2004)

Transport Protocol

RTS Request to send skickas fran den nod som onskar skicka data tillden nod som den vill skicka till for att meddela att den vill borjaen overforing. I detta meddelandet finns t ex information om hurmanga paket som skall skickas och hur manga byte meddelandetar.

CTS Clear to send ar svar fran mottagaren pa ett RTS-meddelande attden ar klar att borja ta emot data.

DT Data Transfer innehaller ett datapaket om 7 byte. Den forstabyten talar om vilket paketnummer som paket i meddelandethar och de ovriga 7 innehaller data. Dessa meddelanden sands samanga som specificerats i RTS vilket max kan vara 255 stycken.

EOMA End Of Msg ACK skickas fran mottagaren av data for att meddelaatt alla data kommit fram.

En Transportprotokoll overforing finns illustrerad i figur 2.8a.Skillnaden mellan Extended Transport protocol och Transport protocol ar

inte stor. Da Transport protocol ar begransad till att bara kunna skicka 256DT-meddelanden har man i Extended Transport protocol mojlighet att skic-ka gupper om 256 DT-meddelanden. Varje sadan grupp borjar men ett DPO

20 Kapitel 2. Teori

(a) Transport protocol (b) Extended Transportprotocol

Figur 2.8: Transportprotokoll

(Data Packet Offset) meddelande. Poangen med DPO ar att om man vill vetaindexet pa ett paket som overforts tar man senaste DPO-vardet och adderarmed paketnummer (DPO offsetvarde + DP paketnummer = paketets nummeri hela overforingen).

Extended Transport Protocol

DPO Data Packet Offset anger numret pa gruppen av datapaket.En Extended Transport Protocol overforing finns illustrerad i figur 2.8b.Ovriga meddelanden for att etablera kommunikationen ar inte likadana men

har en liknade funktion som i Transport Protocol. (SAE J1939-21, Junger 2004)

2.6.2 Address Claming

Pa en ISOBUS har alla noder en unik Source Address. Den adressen anvandsnar data skall skickas till en speciell nod och som avsandare pa samtliga med-delanden en nod sander. Nar en ny nod kopplas upp pa bussen maste nodenerhalla en unik adress och det sker genom address claming. Hur en node erhallersin adress beror lite pa vilka typ av node det ar. Det finns 4 typer av noder:

2.6. Intressanta funktioner i ISOBUS standarden 21

Non configurable address ECU Noden har en fast adress sominte gar att andra.

Service configurable address ECU Noden har en fast adress menden kan andras av en ser-vicetekniker eller med ett CAN-meddelande i servicelage.

Command configurable address ECU Noden har en fast adress somkan andras med ett CAN-meddelande.

Self configurable address ECU Noden hittar sjalv en ledig adresssom den ansluter med.

De icke sjalvkonfigurerande noderna gor en forfragan om den adress deonskar ar ledig, ar adressen ledig kommer noderna att skicka ut ett meddelandeoch tala om att de har erhallit den adressen. Skulle nagon annan nod svaraatt den redan har tagit den adress som den nya noden fragar efter uppstar enkonflikt. Vem som erhaller adressen beror pa nodens namn, se nedan.

Till skillnad fran en icke sjalvkonfigurerande nod gor en sjalvkonfigurerandenod en forfragan till samtliga noder pa natet efter vilken adress de har. Da harnoden mojlighet att rakna ut vilka adresser som ar lediga och sedan skicka utett meddelande och beratta vilken adress den har valt.

Arbitrary VehicleAddress Industry System VehicleCapable Group Instance System Reserved

1 bit 3 bitar 4 bitar 7 bitar 1 bitByte 8 Byte 8 Byte 8 Byte 7 Byte 7

Function ECU Manufacturer IdentityFunction Instance Instance Code Number8 bitar 5 bitar 3 bitar 11 bitar 21 bitarByte 6 Byte 5 Byte 5 Byte 4/3 Byte 3/2/1

Tabell 2.4: Uppbyggnad av nodnamn

Bade sjalvkonfigurerade och icke sjalvkonfigurerande noder har ett namn.Namnet bestar av 8 byte och innehaller koder for vad noden har for funktion,tillverkarkod, idnummer mm se figur 2.4. Pa ett ISOBUS-nat maste samtliga up-pkopplade noder ha ett unikt namn. Detta namn avgor vilken nod som erhalleren adress om det skulle uppsta en konflikt. Nar noden skickar ut sin forfraganom en viss adress ar ledig skickar den ett CAN-meddelande dar nodnamnetutgor de 8 databyten i meddelandet. Da kan de noder som mottar forfraganoch har samma adress jamfora namnet och noden med lagst numeriskt vardepa namnet kommer att erhalla adressen.

Den mest signifikanta biten i namnet ar en indikering pa om noden arsjalvkonfigurerande, och 0 skall tolkas som sjalvkonfigurerande. Detta gor atticke sjalvkonfigurerande noder alltid vinner over sjalvkonfigurerande noder somda far soka upp en ny adress.

22 Kapitel 2. Teori

I namnet finns ocksa en parameter som heter Function Instans vilken angervilket nummer som instansen har om flera lika noder skulle kopplas till ettnat. Har man da en sjalvkonfigurerande nod som hittar flera andra noder medsamma namn kan noden andra instansvardet till det lagsta lediga instansvardetoch anda erhalla ett unikt namn. (SAE J1939-81)

2.7 ISOBUS jamfort med J1939

J1939 ar en SAE standard som tagits fram av den amerikanska bilindustrinfor kommunikation pa CAN-bussen. Den standarden fanns fore att ISOBUS-standarden antogs. Utvacklarna har tittat mycket pa J1939 nar de standard-iserade hur trafiken pa CAN-bussen skulle skotas och hur meddelanden skullebyggas upp i ISOBUS-standarden. 5 stycken av ISO 11783 kapitlena ar baseradepa SAE J1939 kapitel. Hela arbetet med att sammanstalla ISOBUS-standardenhar utforts av en arbetsgrupp kallad WG1.ISO 11783-1General standard Detta kapitel ar av forklariga skal skrivet av arbets-

gruppen WG1.ISO 11783-2Physical Layer Detta kapitel ar en hybrid av delen fran J1939 och

nyskriva delar som skrivits av WG1. Delen om diag-noskontakt ar tagen fran J1939-13, medan informa-tionen om Physical Layer och anslutningskablarna arskriven av WG1.

ISO 11783-3Data Link Layer Detta kapitel bygger helt pa motsvarande kapitel i

SAE standarden, J1939-21.ISO 11783-4Network Layer Taget fran SAE J1939-31.ISO 11783-5Network Manage-ment

Taget fran SAE J1939-81.

ISO 11783-6Virtual Terminal Detta ar en funktion som inte finns alls i J1939 men i

Tyskland fanns en standard for en sadan har utrust-ning, DIN 9684, som man har utgatt ifran.

ISO 11783-7Basic implementmessage

Har finns beskrivet olika parametrar som man kanjustera genom att skicka meddelanden pa bussen. Dear specifika for jordbruksmaskiner och darfor ocksaspecialskrivna for ISOBUS av WG1. Innehallet arliknande som SAE J1939-71 men har finns instruk-tion relaterade till t ex traktorns krafttag och hy-draulik.

ISO 11783-8Drivetrain/ appli-cation layer

Taget fran SAE J1939-71. Innehaller beskrivning avparametrar for fordonet. Har beskrivs instruktionerfor t ex ABS-bromsar och motormoment.

2.7. ISOBUS jamfort med J1939 23

ISO 11783-9Tractor ECU Skriven specifikt for ISOBUS och jordbruksmaskiner

av WG1.ISO 11783-10Task controller ochManagement com-puter interface

Standarden for denna utrustning ar tagen fran denTyska standarden DIN 9684.

En av de storre skillnaderna som beskrivs har ar de nyskriva delarna i Phys-ical Layer. Detta for att man vill kunna anvanda oskarmade kablar i ISOBUSsystemen och anda overfora data med en hastigheten 250 Kbit/s. Men Elec-tro Magnetic Compability (EMC) egenskaperna blev da oacceptabla. Man villedock inte gora avkall pa hastigheten utan man valde i WG1 att hitta en egenlosning pa problemet. Detta gjorde man genom att noggrant specificera tillatnaspanningsforandringar och stighastigheter pa bussen och kunde da uppna EMC-kraven aven med oskarmad kabel och bibehallen hastighet. (Stone m.fl. 1999)

2.7.1 Anvanda J1939 applikationer pa en ISOBUS

Nar man tittar pa likheter och olikheter kring SAE J1939 och ISO 11783inser man att skillnaderna inte ar sa stora. Utrustning konstruerad for J1939-applikationer skulle fungera bra att anvanda aven i ISOBUS-system med vissaanpassningar. Detta skiljer J1939 fran ISOBUS:

• CAN-kontakterna ar olika.

• Databasen med parametergrupper ar specifik for ISOBUS och innehallerett antal instruktioner som endast beror jordbruksmaskiner. Dock ar pa-rametergrupperna och parametrarna lika uppbyggda som parametrarnasom specificeras i J1939.

• I ISOBUS-system har noderna mojlighet att anvanda sig av VT:n somfinns ansluten till bussen. I ett J1939-nat finns ingen VT och darfor harinte J1939-noder inte nagot mjukvaurstod for VT.

• Det finns nagra specifika noder for ISOBUS som inte finns i J1939-standarden.Dessa noder ar Task Controller, Management computer interface, TractorECU och VT.

• Det finns ocksa en storre skillnad, vilken ar den oskarmade kabeln somspecificerats i ISO 11783. Med en oskarmad kabel uppstar det ett storremagnetfalt kring kabeln om signalerna som skickas i kabeln vaxlar fort.I J1939 har man for att inte fa ett for stort magnetfalt valt att anvandaen skarmad kabel men i ISOBUS har man i stallet valt att stalla hogakrav pa hur fort sandaren far vaxla fran att sanda en etta till att sanda ennolla. Genom att specificera hur snabbt en vaxling far ske kan man minskamagnetfaltet och pa sa satt klara EMC kraven. I figur 2.9 kan man se ettexempel pa skillnaden mellan en snabbt stigande och en langsamt stigandesignal.

24 Kapitel 2. Teori

Pa moderna CAN-bussdrivare finns det ofta ett slopemode att anvanda foratt kunna kora med oskarmade kablar, detta mode skulle uppfylla ISO 11783kraven. Skulle en sadan drivare sitta i en applikation byggd for J1939 gar detganska latt att gora en anpassning for att aven kunna anvanda den applikatio-nen pa en ISO 11783 buss. Den hardvaruforandring som kan kravas ar t ex attandra resistansen pa en resistor sa att drivaren gar i slope mode i stallet for t exhigh-speed mode. Skillnaden pa bussen i slope mode ar att signalerna rampasupp och ner sa langsamt som standarden tillater i stallet for att swichas pa ochav sa fort som mojligt i t ex high-speed mode. (Stone m.fl. 1999, Philips 2000)

Figur 2.9: Stigtidsskillnad for olika mod pa CANdrivaren

2.8 Utvecklig av ISOBUS-standarden

Da VTn ar den mest komplexa delen av ISOBUS standarden kommer det troli-gen att ske en del forandringar av standarden kring VT. For tillfallet ar dengallande versionen av ISO 11783-6 First Edition 2004-06-15. For att fa en upp-fattning om standardens utvecklingsprocess och hur stora forandringar man kanforvanta sig har dels Peter Fellmeth, Product Manager ISOBUS pa Vector Infor-matik, och dels Hans Jurgen Nissen, Ag Management Solutions pa John Deereintervjuats.

Peter intervjuades per telefon och han uppskattade att standarden behoverungefar 2,5 ar pa sig for att satta sig, vilket blir till slutet av ar 2007. Efter dettrodde han att standardens barnsjukdomar skulle vara borta och forandringstaktenskulle minska.

Eftersom Peter ar en potentiell leverantor av mjukvara och inte kan ses somhelt opartisk sa intervjuades ocksa Hans Jurgen som arbetar med ISOBUS paJohn Deere. Han har ganska god insyn i utvecklingsarbetet av standarden. Hanintervjuades via mail och det mailet finns bifogat i bilaga C.3.

Kapitel 3

CCP XS I VIRTUALTERMINALUTFORANDE

3.1 Mjukvara

CCP XS kan koras bade med Linux och med Windows CE.net som opera-tivsystem. For utvecklingen av VTn sa kommer Windows CE.net att anvandassom operativsystem da detta var det enda operativsystem som har hunnit attdriftsattas pa datorn nar projekt borjade. I bilaga D finns en fullstandig speci-fikation pa CCP XS och vilka val som gar att gora.

3.2 Hardvara

Om CCP XS skall anvandas i ett ISOBUS-nat maste vissa anpassningar avhardvaran goras.

CCP XS ar konstruerad for en CAN-bus med J1939-protokollet. Da J1939kors med skarmade kablar behover ingen storre hansyn tas till stig och falltiderpa bussen. Sa ar inte fallet for ISOBUS. Har anvands oskarmade kablar och stigoch falltiderna maste da beaktas. CCP XS anvander en CANdrivare fran PhilipsPCA82C251 som gar att kora i olika mode. CCP XS ar nu konstruerad for attanvanda High-Speed mode pa drivaren. Det fungerar inte for ISOBUS manmaste andra detta till Slope mode for att fa de ratta stig och falltiderna. Dennaandring ar mycket enkel och bestar i att andra resistansen mellan ben Rs paPCA82C251an och jord se figur 3.1. Nu ar benet kopplat direkt till jord for attkora drivaren i High-Speed mode men genom att infor en resistor med lampligresistans mellan Rsbenet och jord gar drivaren over till att kora i Slope modemed stig och falltider proportionella till resistansen pa Rs. Med denna andringfar man godkanda stig och falltider for anvandning i ett ISOBUS-system.

Oberg, 2005. 25

26 Kapitel 3. CCP XS I VIRTUAL TERMINAL UTFORANDE

Figur 3.1: Inforande av Slope resistansen Rs till PCA82C251T CAN-drivare

Kapitel 4

DISKUSSION OCHSLUTSATSER

I detta kapitel redovisas steg for steg de olika mojliga losningarna for att goraCCP XS ISOBUS-kompatibel. Ett antal mojliga losningsspar kommer att paborjas.Dessa kommer sedan att vagas mot varandra och avfardas ett efter ett for attsedan hitta en slutgiltig losning.

4.1 Olika tillvagagangssatt for att implementeraen VT

For att fa CCP XS att fungera

Figur 4.1: Delkomponenter i ettISOBUS-system

som VT i ett ISOBUS-system sa kravs3 delkomponenter.

• CAN drivrutin

• ISOBUS stack

• VT mjukvarua

Forhallandet mellan komponenterna visas i figur 4.1.CANdrivrutinen skoter kommunikationen mellan ISOBUS-stacken och den

fysiska hardvaran. Da hardvaran ar specifik for CCP XS maste komponentenprogrammeras for detta andamal. Drivrutinen maste ocksa vara anpassad attfungera mot den ISOBUS-stack som man anvander.

ISOBUS-stacken skoter kommunikationen mot bussen och tar hand om med-delandehantering. Detta ar en standardkomponent som finns fardig pa mark-naden om man onskar kopa in den. Det finns ocksa oppen kallkod pa marknadenfor ISOBUS-stackar.

VT-mjukvaran ar den mjukvara som tolkar informationen pa bussen och om-vandlar den till grafisk information. Den skickar ocksa information till bussen

Oberg, 2005. 27

28 Kapitel 4. DISKUSSION OCH SLUTSATSER

nar inmatningar pa terminalen har gjorts. Denna komponent behover inte varaspecialskriven for CCP XS utan kan vara en standardkomponent fran mark-naden.

For att kunna fa en CCP XS att fungera som en VT har 4 olika spar valtsatt foljas upp for att se vilken losning som ar den basta. Tanken ar att endastett spar skall fullfoljas och de ovriga 3 skall under projektets gang avbrytas narde visar sig vara mindre lampliga eller hamnar i en atervandsgrand.

4.1.1 VT fran CANoe

Pa marknaden finns ett fardigt simuleringsprogram for att simulera hela CAN-nat med alla dess komponenter. Detta program har stod for ISOBUS och VT.Mojligheten ar att anvanda VTdelen fran Vector Informatiks program CANoeoch implementera pa CCP XS tillsammans med den ISOBUS-stack som finnsi CANoe. Dock maste ett mellanlager skrivas for anpassning mot den CAN-drivare som finns pa CCP XS.

• Egen koppling mot drivrutinen• CANoe stack• CANoe VT

4.1.2 Kopt Stack till Egen VT

Det gar att fran marknaden kopa in en ISOBUS-stack som kompletteras med etteget mellanlager mot drivrutinen for att koppla den mot den hardvara som CCPXS har. ISOBUS stacken kan t ex kopas fran foretaget Vector Informatik somsaljer mjukvara till CAN applikationer. VTn far man sedan sjalv programmera.Da hela programmet tar ganska lang tid att skriva kan man inom ramen forexamensarbetet begransa sig till att bygga upp strukturen och nagra objekt avvarje typ. VTn har ganska fa olika grupper av objekt och instruktioner men detfinns ett antal liknande objekt och instruktioner i varje grupp. Om man hargjort nagra av dessa ar det sedan relativt enkelt att gora kompletteringar foratt fa en fullstandig VT.

• Egen koppling mot drivrutinen• ISOBUS stack fran Vector• Egen VT (dock inte med stod for alla instruktioner)

4.1.3 Stack med oppen kallkod till Egen VT

Om man inte vill kopa sig en ISOBUS-stack fran nagot foretag kan man skriva enegen med hjalp av komponenter som finns med oppen kallkod. En oppen kallkodsom skulle vara mojlig att anvanda ar ISOagLib som finns fritt distribuerad paInternet. Det kan dock vara tidsodande att anvanda denna kod da det inte finnsnagon bra dokumentation och support pa den. Fordelen med att skriva en egen

4.1. Olika tillvagagangssatt for att implementera en VT 29

stack ar att det ar lattare att skriva kopplingen mot drivrutinen da man harmojlighet att fa full insyn i hur alla funktioner i stacken fungerar. Till dennastack kan man sedan skriva en egen VT pa liknade satt som till den inkoptaISOBUS-stacken.

• Egen koppling mot drivrutinen• ISOBUS-stack skriven med ISOagLib• Egen VT (dock inte med stod for alla instruktioner)

4.1.4 VT fran annan hardvarutillverkare

Ute pa marknaden finns ett antal fardiga VT i form av bade hardvara ochmjukvara. En mojlighet ar att nagon av dessa tillverkare vill salja mjukvara tillVTn. Den skulle da ga att implementera pa CCP XS genom att anpassa CAN-drivrutinerna. Dock kan det vara svart att hitta en tillverkare som vill saljamjukvara eftersom CCP XS sedan kommer att konkurrera med deras produkt.

• Egen koppling mot drivrutinen• ISOBUS-stack fran annan terminaltillverkare• VT fran annan terminaltillverkare, som sitter ihop med stacken

4.1.5 Metod for att hitta leverantorer

For att hitta leverantorer for de olika losningarna har foljande metod anvants.Till att borja med har sokningar gjorts pa Internet for att hitta olika foretag somhar produkter kring ISOBUS. Dock har inga foretag hittats som pa sin hemsidaskriver att de tillhandahaller mjukvara till VT, men de har andra produkterkring ISOBUS, bla fardiga VT. Till dessa foretag har sedan ett mail skickats,mailet som sandes finns i bilaga C.1.

Nagra av foretagen har ocksa haft andra intressanta produkter som t exsimuleringsprogramvara och da har fragor kring dessa ocksa funnits med i mailet.

Dessa mail har dock inte gett sa bra utfall och inga foretag har svarat attde har nagon mjukvara for VT.

Da Vector Informatik som har simuleringsprogrammet CANoe var av stortintresse kontaktades de pa telefon i stallet da det fanns fanns ganska mangafragor att stalla kring det. Vector har ett saljkontor i Sverige som forst kontak-tades, dock fick de lov att hanvisa vidare till kontoret i Tyskland.

Da inga bra foretag hittades tipsade Claes Ulvefeldt pa CC Systems omatt kontakta Hans Jurgen Nissen som arbetar med jordbrukslosningar pa JohnDeere (traktortillverkare) i Tyskland. Han sitter ocksa med i arbetsgruppen somtagit fram ISOBUS-standarden. Han borde kanna till om det finns nagra foretagsom har utvecklat mjukvara till VT. Mailet till Hans Jurgen finns i bilaga C.2.

Hans Jurgen lamnade ett mycket utforligt svar dar han talar om att han barakanner till Vector Informatik som arbetar med mjukvara till VT, och da densom ar inbyggd i CANoe. Av det svaret kan man dra slutsatsen att det troligeninte finns nagot foretag som for tillfallet tillhandahaller mjukvara till VT. Dockfinns det nagra foretag som uppenbarligen har egenutvecklad mjukvara till sinaVT som de saljer men de verkar inte ha nagot intresse av att salja den tillkonkurrenter.


4.1.6 Uppfoljning av sparen

For att komma fram till vilka spar som kan vara lampliga att ga vidare medhar arbete lagts ner pa att hitta mer information kring de produkter som finnspa marknaden. Kontakter har forts med ett antal olika foretag parallellt, for attse vad de har for mjukvarukomponenter att leverera. Det som har gjort arbetetlite problematiskt ar att vissa foretag inte har fardiga komponenter men arintresserade av att ta fram sadana om de bara har en kund som betalar for det.Detta gor att det inte bara ar att lasa en manual och jamfora listpriser.

De olika sparen har undersokts och eftersom information har kommit in harde antingen slappts eller sa har fortsatta diskussioner forts for att fa svar paytterligare fragor.

4.1.7 Resultat av sparet VT fran CANoe

Efter att kontakter har forts med Vector Informatiks bade i Sverige och i Tysk-land kanns sparet med en CANoe-losning fardigutrett. De produkter VectorInformatiks har att erbjuda ar foljande:

• ISOBUS-stack som hanterar funktioner fran ISO11783-3/-5 som ar Datalink layer respektive Network mangement.

• Virtual Terminal implementation enligt ISO11783-6.

• Granssnitt till I/O, som skarm och knappar.

• Granssnitt till en CAN-drivare.

• Mjukvaran tillhandahalls som kallkod i Virtual C++ med kommentareroch en manual.

Da allt detta ar utvecklat for Windows XP fungerar inte programvaran attanvanda i Windows CE utan att forst gora en anpassning. Kommentarer kriganpassning till Windows CE finns samlat i avsnittet “Anpassning av VirtualC++ program till Windows CE”.

For att kunna gora en demoprodukt med Vector Informatiks mjukvara kravsatt man koper in en utvarderingslicens. En sadan kostar 10 000 EURO (90570kr, 2005-04-07). Skulle man sedan vilja anvanda mjukvaran i serieproduktionfar man kopa till en utokningslicens for ytterligare 35 000 EURO (316 995kr,2005-04-07), den enda begransning man da har ar att man inte far salja vidaremjukvara till en tredje part.

Sammanstallning:

+ Ger en komplett VT med samtliga funktioner.

+ Skriven i Virtual C++ som har stora likheter med embedded Virtual C++.

- Skriven for Windows pa PC.

- Valdigt dyr utvarderingslicens.

Den losning som Vector presenterar ar ingen “plug and play” losning utankraver en del arbete fran CC Systems sida for att fa en fardig fungerade produkt.Dock ar det arbete som kravs begransat till kopplingen mot hardvaran och attanpassa mjukvaran till Win CE. Detta ar den losning som ger en fardig VT medalla dess funktioner med minsta mojliga arbetsinsats.


Slutsats: Produkten forefaller vara lamplig for CC Systems om man skall tafram en kommersiell VT i stora serier. For en demonstrator faller produkten paatt den ar for dyr och aven vissa tveksamheter pa hur mycket jobb det ar attanpassa den.

Anpassning av Virtual C++ program till Windows CE

For att se om kallkoden till CANoe gar att anvanda i detta projekt sa har testergjorts for att se hur man kan gora en anpassning till Win CE. Program som arskrivna i Virtual C++ for Windows pa en PC fungerar nodvandigtvis inte paen Win CE plattform.

Den storsta utvecklingsmiljon for programvara for Win CE ar Microsoft em-bedded Virtual C++. Den miljon ar mycket lik Microsofts Virtual C++ medskillnaden att den har en kompilator for Win CE. Det fungerar inte att ta ettprojekt utvecklat i Virtual C++ och sedan oppna och kompilera det i embed-ded Virtual C++, dock fungerar det i manga fall att ta en c- och h-fil skriven iVirtual C++ och sedan importera till ett projekt i embedded Virtual C++. In-struktionsuppsattningen i embedded Virtual C++ ar relativt lik den som finnsi Virtual C++ och darfor ar det inte mycket som behover andras for att fakallkod fran den ena utvecklingsmiljon att fungera i den andra.

Det som skiljer ar hanteringen av hardvara. Dar fungerar t ex inte instruk-tioner for grafik att flytta mellan operativsystemen. Dock ar likheterna storaaven nar det galler grafikinstruktionerna sa det kraver inte allt for mycket ar-bete att skriva om dem for Win CE.

For att fa en uppfattning om hur mycket arbete som kravs for att konverteraCANoe-kallkoden till Win CE har lite information inhamtats fran Vector Infor-matiks om koden. Alla namn pa filer, variabler och klasser mm ar skrivna paengelska, sa aven ocksa kommentarerna. Risken nar man koper kallkod fran ettannat land som i detta fall Tyskland ar annars att de tyska programmerarna haranvant tyska. Kallkoden ar uppdelad i ca 160 c- och h-filer vilket dock inte sagersa mycket om hur mycket kod det ar i varje fil men ger en grov uppskattningav programmets omfattning. Vector Informatiks kunde inte svara pa hur mangarader kod programmet var pa men den kompilerade filen ar pa (1.6 Mbyte).Den stora delen av programmet bestar av mekanismer som hanterar busskom-munikation och objektpott. Endast en mindre del av programmet utnyttjar detgrafiska granssnittet. Troligen ar det programdelen som anvander det grafiskagranssnittet som kommer att krava mest arbete vid anpassningen.

4.1.8 Resultat av sparet Kopt Stack till Egen VT

Pa marknaden har tva leverantorer av stackar till ISOBUS hittats.Vector Informatik har en programvara for att konfigurera en stack med hjalp

av ett antal moduler som man inkluderar. Detta ar ett avancerat system menmed mojlighet att konfigurera upp en stack som passar precis till andamalet.De har ocksa en mer generellt konfigurerad stack for J1939 som de saljer, ochde verkade inte heller omojliga pa att kunna ta fram en liknande for ISOBUSom intresset finns.

Den andra leverantoren av ISOBUS-stack ar Ixxat som har foretaget Nohausom aterforsaljare i Sverige. De har en generell stack for J1939 som ar kompatibelmed ISOBUS. Denna stack konfigureras genom att man satter parametrar innan


man kompilerar den och saledes kravs det inte en hel utvecklingsmiljo for attkunna generera en fungerande stack.

For demonstratorn kanns valet av Ixxats stack bast eftersom den finns fardigpa hyllan for leverans. Skulle Vectors Informatiks losning anvanda kravs antin-gen att man skaffar hela utvecklingsmiljon for att kunna generera en fungerandestack vilket troligen tar onodigt lang tid och en fardig stack fanns ju inte hosVector Informatiks. Det kanns inte heller rimligt att forsoka fa dem att ta framen stack bara for att bygga en demonstrator. For en ev framtida produktionav terminaler bor det undersokas vilka funktioner som anvander i stacken ochutifran de ocksa titta pa vad som blir billigast. Att konfigurera en egen stack medVectors Informatiks programvara, att kopa in en stack som Vector Informatikshar konfigurerat upp eller anvanda Ixxats stack.

Stacken kommunicerar med VT-mjukvaran med ett fatal instruktioner somtroligen kommer att ha lite olika namn och parameteruppsattningar, dock medsamma funktion. Att konvertera VT-programvaran for anvandning av en annanstack bor inte utgora nagot stort problem.

Bade Vector och Ixxats stackar finns att fa levererade i ANCI-C och kansedan kompileras till WIN CE. De ar ocksa programmerade for att enkelt kunnakopplas till CAN-drivrutinen da dess anrop har kapslats in i en separat fil.

Sammanstallning:

+ Stackarna skrivna i ANCI-C

+ Har tydlig avskiljning av hardvarukopplingen for koppling mot CAN-drivaren.

- Demonstratorn ger inte en fardig VT med alla funktioner

Slutsats: En rimlig losnig for att ge en fardig produkt. Gar ocksa bra att byggaen demonstrator, dock inte med alla funktioner.

En utforligare beskrivning av Ixxats stack

Den stack som Ixxat har fardig for leverans ar en J1939-stack som sedan arutbyggnadsbar for ISOBUS genom att man kompletterar med ett Extendedtransport protocol. Stacken ar uppbyggd av totalt 7 komponenter dar 4 argrundkomponenter och ytterligare 3 ar valfria, se tabell 4.1

Grundkomponenter Valfria komponenterDLL Data Link Layer funktioner ERR Enhet for felmeddelandehanteringTPL Transport Layer funktioner TIM Enhet med tidsfunktionerAPL Application layer funktioner CYC Enhet for hantering av cykliskaNWM Network Management meddelanden

funktioner

Tabell 4.1: Komponenter i J1939 stacken

Har beskrivs inte varje komponent for ingaende. Det finns nagra sarskiltintressanta komponenter som ar varda att belysa lite extra. Den ena ar CYCCycle Unit som anvands for att skicka och ta emot cykliska meddelanden. Ettcykliskt meddelande ar ett meddelande som skickas kontinuerligt med t ex en


sekunds intervall. I VTn anvands det t ex for att varje sekund skicka ut ettmeddelande till alla noder och meddela att man fortfarande ar aktiv pa natetoch inte blivit bortkopplad. Dessa meddelanden laddas till CYC tillsammanmed de intervall de skall skickas med, och sedan skoter CYC resten. CYC harocksa en anvandbar funktion vad del galler att bevaka cykliska meddelanden.Till CYC gar att ladda in ett meddelande-ID och ett tidsintervall som dettameddelande skall tas emot med, och da bevakar CYC att meddelandet kommerinom bestamda intervall. Skulle ett meddelande inte komma genererar CYC ettfelmeddelande. Denna funktion ar ocksa anvandbar i en VT da alla noder somar inkopplade pa bussen var tredje sekund skall skicka ett meddelande och talaom att de inte har blivit bortkopplade.

En annan intressant komponent ar APL Application Layer. Detta ar denkomponent som applikationen man sjalv skriver ihop kommer att kommuniceramed. APL har 7 olika instruktioner for funktioner som initiering, skicka ochta emot meddelande. Dessa instruktioner ar lattanvanda och dokumenterade imanualen.

4.1.9 Resultat av sparet Stack med oppen kallkod till EgenVT

Detta spar har samma losning som sparet med en kopt stack till egen VT salosningen for VT-mjukvaran blir den samma. Dock finns det ett antal nackdelarmed att anvanda sig av den oppna kallkoden. Det finns ingen ordentlig doku-mentation kring kallkoden vilket gor att den blir svaranvand om man inte villsatta sig in i den grundligt. Sedan finns det inte heller nagon support till den. Omman skall kunna anvanda den i en kommersiell produkt bor man darfor byggaupp viss kompetens pa foretaget for att kunna ratta ev buggar som skulle kunnaupptackas i stacken. Det finns inte heller nagon form av support pa stacken omdet skull uppsta fragetecken. Av denna anledning star denna losning i skugganav att kopa in en stack dar man har fullstadig dokumentation och support.

Sammanstallning:

+ Skriven i C+ Gratis- Demonstratorn ger inte en fardig VT med alla funktioner- Finns ingen fullstandig dokumentation- Finns ingen support sa viss kompetens bor byggas upp pa foretaget

Slutsats: Skulle fungera for en demonstrator men kraver mer jobb an en fardigstack. For en kommersiell produkt ar det lite vagat da det inte finns nagonsupport.

4.1.10 Resultat av sparet VT fran annan hardvarutillverkare

Detta spar har inte gett nagot resultat da ingen av de andra leverantorerna harvalt att svara pa forfragan de fatt per mail. Det kan dock vara forstaeligt att deandra tillverkarna av hardvara inte ar intresserade av att salja sin mjukvara tillen konkurrent.

Slutsats: Ingen har nagon mjukvara att salja.


4.2 Slutsatser och val av lampliga mjukvara

Detta examensarbete har tva uppgifter, dels att hitta en lamplig mjukvara somkan koras pa CCP XS for att salja den som en VT och dels for att byggaen demonstrator dar CPP XS kors som VT. Till dessa tva andamal har tvaolika losningar erhallits. Anledning till att losningarna har blivit olika trots attuppgifterna till synes verkar vara ganska lika beror helt och hallet pa tillgangpa resurser, i form av ekonomi och arbetstid. Skulle losningen som valts forden kommersiella produkten aven valjas for demonstratorn skulle det kosta formycket och den avsatta tiden till detta projekt skulle inte racka till.

4.2.1 Mjukvarulosning till en kommersiell VT

Denna losning skall vara den basta for att utrusta CCP XS med mjukvara foratt sedan kunna salja den som en VT. Har vager aspekter som att fa fram enmjukvara som garanterat stodjer alla funktioner som beskrivs i standarden ochatt det finns bra losningar for uppdatering tyngre an att utvecklingskostnadernaar stora.

Den enda och tillrackligt bra losningen for att fa fram en fullstandig VTar att anvanda kallkod fran Vector Informatiks CANoe. Den mjukvaran skullestodja alla funktioner som finns i standarden och det finns goda mojligheter atthitta bra former for uppdateringar tillsammans med Vector.

Den stora nackdelen med denna losning ar att den har stora initialkostnader,dels att kopa kallkoden och dels den tid det kostar att anpassa den till WIN CE.Om mojligheterna for stora serier av VT-produkten finns torde dessa kostnaderinte vara nagot problem att rakna hem.

+ Ger en komplett VT

+ Gar att hitta en bra losning for uppdatering

- Stora utvecklingskostnader

4.2.2 Mjukvarulosning till en demonstrator VT

For demonstratorn ar det helt andra aspekter som vager tungt, har ar resursersom tid och pengar begransade och darfor vager de tungt i valet av mjukvara.

Eftersom Vectors Informatiks losning ar bade dyr och tidskravande gor detatt den inte ar lamplig for demonstratorn. For demonstratorn gar det bra attbegransa VTens funktioner till endast ett fatal for att begransa tidsatgangen.Vectors Informatiks losning har inga naturliga avgransningar utan blir mer allteller inget. Darfor ar en lampligare vag att ga for att ta fram en demonstra-tor att utveckla en egen VT-mjukvara. Nar egen mjukvaran utvecklars ar detbetydligt lattare att avgransa utvacklingen till implementera av bara ett fatalinstruktioner och darigenom spara tid. Skulle det sedan visa sig att det finnstid over finns alltid mojligheten att bygga pa med ytterliggare instruktioner.Kostnaderna halls ocksa nere om man anvander sig av egenutvecklad mjukvara.Dock finns inte tiden att bade utveckla en programvara for granssnittet i VTnoch en stack, darfor bor en fardig stack forsoka anvanda. For att pa ett enkeltsatt kunna fa fram en stack med en utvarderingslicens bor man halla sig till enstack som finns pa hyllan. Da behover inte leverantoren lagga ner nagot arbetepa produkten. Med dessa villkor faller det ut att bara Ixxat kan tillhandahalla

4.3. Testutrustning for en VT 35

detta. For att losa problemet med drivrutin till CAN-kontrollerna pa CCP XSkan man anvanda den drivrutin som redan finns skriven till CAN-kontrollernaoch skriva ett mellanlager mellan drivrutinen och stacken som anpassar stackensdrivrutinsanrop sa att de passar drivrutinen.

Saledes blir losningen for demonstratorn att utveckla en demonstrator somendast kan hantera ett fatal forutbestamda funktioner. For att astadkomma dethar en stack fran Ixxat anvands tillsamman med ett eget grafiskt granssnitt.

+ Gar bra att avgransa arbetet+ Kostar inte sa mycket pengar- Ger inte en fullstandig VT

4.3 Testutrustning for en VT

For att kunna testa den demonstrator som kommer att tas fram behovs nagonform av testutrustning att koppla demonstratorn till. De mojliga losningar somhar overvagts ar:

• I/O-enhet fran godtycklig maskin.• I/O-enhet fran en tillverkare av enheter som man sjalv programmerar.• Simuleringsprogram i en PC med CAN adapter.• Ytterligare en CPP XS som kors som nod.

4.3.1 I/O-enhet fran godtycklig maskin

Att anvanda en I/O-enhet fran en godtycklig maskin fungerar men man harda ingen mojlighet att ladda in olika working set for testning. Om man intekommer att implementera en komplett VT kommer man att fa problem meden godtycklig I/O-enhet da man inte vet vad den anvander for instruktioner.Man kommer ocksa att fa svart att veta hur systemet fungerar da man inte hardokumentation pa hur enheten skall reagera pa olika signaler.

4.3.2 I/O-enhet fran en tillverkare av enheter som mansjalv programmerar

Att anvanda en enhet som gar att programmerar ar lampligare for da finnsmojlighet att testa olika funktioner och valja vilka funktioner som anvands.Det ar ocksa kant hur enheten kommer att reagera pa olika instruktioner denfar skickat till sig. Dock har det varit svart att hitta nagon enhet som gatatt programmera sjalv, utan de som finns pa marknaden levereras med fardigprogramvara.

4.3.3 Simulering i en PC med CAN adapter

Har finns det flera losningar att valja pa beroende pa vilka programvaror somanvands. Denna losning ar mer flexibel an de andra losningarna da det ar mycketlattare att gora andringar och test nar man anvander PC som node i stallet foratt behova kodladda nagon hardvara. De olika tillgangliga programvarorna fortestning har jag gatt igenom i kapitel 4.4 Simuleringmojligheter pa sidan 36.


4.3.4 Ytterligare en CCP XS som kors som node

Denna losning fungerar sakert bra da utvacklingen kommit mot sitt slutskedeoch inte sa manga andringar behover goras i testutrustningen, annars maste ettantal kodladdningar fran utvecklingsdator sakerligen goras. Dock finns det intesa mycket programvara till Win CE for testning. I detta fall ar ar enda losningenatt skriva sina egna testprogram.

4.4 Simuleringsmojligheter

Det finns flera fardiga program pa marknaden for simulering och det finns avennagra andra satt att losa simuleringen pa. Nagra egenskaper som ar onskvardavid simulering ar dels att man vill kunna titta pa de signaler som skickas och intebara se om overforingen blev lyckad eller inte. En annan onskvard egenskap vidsimulering ar att man har full frihet att valja vad man vill skicka for instruktionerfor att t ex testa sig fram till vad som genererar ett fel. Har nedan foljer ensammanstallning av lite olika metoder att simulera pa och programvaror somkan vara anvandbara.

4.4.1 CANoe

Figur 4.2: Skarmdump fran CANoe

Till PC finns flera testmojligheter. Dels att anvanda simuleringsprogrammetCANoe som ar tillverkat av Vector Informatik som man kan bygga upp ettvirtuellt CAN-nat i och sedan med hjalp av en CAN-adapter koppla det natet

4.4. Simuleringsmojligheter 37

till ett fysiskt nat utanfor datorn. I CANoe kan man ganska enkelt bygga uppnoder som man sjalv vill. Man har ocksa mojlighet att i noderna bygga in grafiskrepresentation sa att man kan fa resultatet av instruktioner man sander presen-terade grafiskt. CANoe har ocksa en analysfunktion for att se vilka meddelandensom sands pa CAN bussen. Allt detta ar bra, men det finns ocksa en nackdeloch det ar priset. En licens med stod for ISOBUS och en CANadapter kostar106 580 kr + moms i april 2005.

CANoe finns som en demoversion dar begransningen ar att det inte gar attkoppla upp sig mot ett fysiskt nat och att bara 4 noder gar att anvanda. Dettasystem ar anvandbart aven som demo da det gar att gora simuleringar mednode och VT for att se hur trafiken mellan noden och VT ser ut. Figur 4.2 visaren skarmdump fran CANoe vid ISOBUS-simulering.

4.4.2 SimECU

Figur 4.3: Skarmdump fran SimECU

Ett biligare alternativ en CANoe ar att anvanda SimECU fran WTK Elektron-ik. Detta program kors pa en PC med CAN-adapter och PCn simulerar da ennod pa ett CAN-nat. Programmet kan ladda upp ett working set till VTn ochman kan sedan lasa av och andra parametrar. Programmet kostar 560 EURO(5 060kr, 2005-04-13). Detta program ar kompatibelt antingen med Vector In-formatiks eller Peaks CAN-adaptrar och den billigaste ar Peaks som kostar ca2000kr i april 2005. Programmet ar enkelt och overskadligt som synes i figur 4.3.


4.4.3 Egenskrivet simuleringsprogram

Man kan skriva ett eget enkelt simuleringsprogram for att kora pa en PC medCC Systems eget CAN-kort installerat. For att koppla sig mot en ISOBUSanvander man enklast en ISOBUS-stack men om man valjer att anvanda ensadan i implementeringen av VTn ar den koden redan klar att anvanda ochman behover da bara skriva applikationen. Har har man ocksa alla mojlighetertill att representera olika handelser grafiskt.

4.4.4 Mask Generator

Figur 4.4: Skarmdump fran Mask Generator

For att skapa objektpotter, som beskrivs i kapitel 2.5.2 pa sidan 16, for dentestnod man satter upp kan man anvanda programmet Mask Generator franWTK Elektronik. I det programmet kan man genom att satta in olika kompo-nenter pa en bild skapa de objektpotter man sedan vill att noden skall overforatill VTn. Programmet kostar 4 600 EURO (41 560kr, 2005-04-13). Dessa ob-jektpotter gar ocksa att skapa genom att sjalv skriva hexfilen som beskriverobjektpotten. All information om hur filen ar uppbyggd finns i ISO 11783-6.Programmet finns som en demoversion dar man inte kan spara. Det man skapardock gar det bra att oppna hexfiler man sjalv skapat for att se hur det ser ut. Ifigur 4.4 syns ett exempel pa en mask under editering.

4.4. Simuleringsmojligheter 39

4.4.5 CanTool

Figur 4.5: Skarmdump fran CanTool

CanTool som visas i figur 4.5 ar en programvara utvecklad av CC Systemsoch ingar i programpaketet CCS SimTech. Programmet anvands for att loggaoch skicka data pa en CAN-buss. Programmet kors pa en PC som ar utrustadmed CC Systems CAN-adapter. Detta program kan man ha nytta av nar mantestkor sin VT for att se att signaler man onskar skicka dyker upp pa bussensom man forvantar sig. Man kan ocksa skicka enklare sekvenser av kommandonfran programmet till sin VT. Om man anvander sig av CANoe har man dockingen nytta av detta program da CANoe innehaller en liknande analysfunktion.

4.4.6 Val av simulerings mojlighet

Valet av simuleringsmetod och utrustning ar olika till de tva olika tillampningarnademonstrator och kommersiell produkt. Detta beror som mycket annat pa ekono-mi. Men valet beror ocksa pa foretagets ambitionsniva inom ISOBUSutveckling.Skall bara en fardig VT tillverka och skeppa ut eller ar planer pa att bedrivafortsatt utvecklingsarbete av ISOBUS-produkter.

Simulering och testning for kommersiell VT

Om man har for avsikt att arbeta mycket med ISOBUS och utveckling kringVT ar CANoe det basta simuleringssystem som finns pa marknaden i dag. Deandra systemen som finns ar inte i narheten av CANoe nar det galler mojlighetertill att titta pa signaler och aven vad det galler att bygga upp lattoverskadligasystem. Det ar ocksa bara i CANoe som det gar att programmera noderna tillatt utfora olika funktioner automatiskt, i de andra systemen ar noderna heltpassiva.

Onskas mojligheten att aven kunna testa olika objektpotter bor man skaffasig Mask Generator for att pa ett latt satt gora olika objektpotter.

Finns inte avsikt att arbeta mycket med ISOBUS gar det bra att anvandasig av samma losning som for demonstratorn.


Simulering och testning for demonstratorutvecklingen

For demonstaratorutvecklingen ar det kostnaden som gor att CANoe inte ar ettalternativ. Dock kan man anvanda demoversionen av CANoe for att titta pabusstrafik i en simulerad miljo. For testning och simulering mot hardvara ar ettegenskrivet simuleringsprogram med Ixxats ISOBUS-stack ett bra alternativ.Det egenskrivnaa programmet ar ju inte lampligt att anvanda for att titta pasignaler. Men dar gar det att utover det egenskrivna programmet och anvandasig av CC Systems CAN-analyseringsprogram CanTool.

4.5 Hur paverkar utvecklingen av ISOBUS-standarden CC Systems

I kapitel 2.8 Utveckling av ISOBUS standarden pa sidan 24 redovisas intervjuer-na med Peter Fellmeth och Hans Jurgen Nissen, och som som framgar dar sasker det ett ganska omfattande forandringsarbete med ISOBUS VT standardenoch det bor man ocksa ta hansyn till nar kopa eller ev utveckla av programvaratill en VT skall ske.

Viktiga fragestallningar for CC Systems ar: Hur skall CC Systems halla siginformerad om andringar som kommer? Hur skall man gora med terminaler somredan ar ute hos kund?

Den forsta fragan om att halla sig uppdaterad pa andringar i standardenkan losas pa lite olika satt. Skulle inkop av CANoe-kallkoden fran Vector Infor-matiks valjas och sedan konvertera den till Win CE skulle det ga att teckna ettsupportavtal med Vector Informatiks sa att den nya kallkoden distrubueras narforandringar gors i CANoe. Det skulle ocksa vara mojligt att teckna ett sup-portavtal med Vector sa att information distrubueras om andringar som gors iCANoe och sedan i varje enskilt fall tars beslut om hurvida det ar nagot manvill kopa en uppdatering for. Dock bor det beaktas att den kallkod man koperfran Vector Informatiks forsta gangen kommer att behova forandras innan dengar att anvanda i sin egen VT. Kopers sedan en uppgradering fran Vector In-formatiks gar det inte att kora den utan att gora en del forandringar.

Att Vector Informatiks haller sig uppdaterad pa ISOBUS-standarden kanman vara ganska saker pa. De ar leverantorer av mjukvara till ISOBUS-organisationen som i sin tur anvander den for att certifiera ISOBUS-enheter,som olika tillverkare tar fram. Den mjukvara de anvander ar just simuler-ingsmjukvaran CANoe. Av den anledningen maste CANoe alltid vara uppdat-erat efter gallande standard.

Om CC Systems valjer en losning av VT mjukvara som inte Vector In-formatiks levererar far man forlita sig pa andra kanaler. Ett satt ar att kopastandarden nar en ny upplaga slapps fran ISO, vill man vara saker pa att faen ny standard sa fort den slapps kan man pa SIS Forlag prenumerera pa upp-dateringar. Kostnaden for en prenumeration ar 995kr/ar och sedan tillkommerkostnaden for uppdateringen. Men nar standarden redan ar publicerad ar detmojligt att man ar sent ute for att hinna uppdatera mjukvaran innan kundernaborjar krava kompabilitet med den nya upplagan av standarden.

4.6. Ytterligare funktioner till CCP XS 41

Ett annat satt att halla sig valuppdaterad och aven fa mojlighet att paverkaar att ga med i Implementation Group ISOBUS (IGI). Det kraver troligen litemer engagemang men da far man i ett tidigt stadium hora om andringar somkomma skall och man kan sedan, innan en ny version av standarden slapps,borja med sitt uppdateringsarbete.

Hur gor man da nar man gjort andringar i sin kallkod enligt en uppdateradversion av standarden? Att nya enheter som skeppas ut ar laddade med dennya mjukvaran ar sjalvklart men hur gar det med dem som redan sitter i entraktor hos en kund. Troligen kommer hansyn tas till bakatkompatibilitet i denuppdaterade standarden men det ar ju en service till kunden att de har mojlighetatt uppdatera sin enhet gratis eller till en viss kostnad. Eftersom CCP XS arutrustad med USB-portar finns ju alltid mojligheten att koppla den till en datoroch via Internet distribuera uppdateringar. Vill man inte ta med CCP XSen tilldatorn ar ett alternativ att gora uppdateringen med hjalp av ett USB-minne. Enfunktion av denna typ bor seriost beaktas vid utveckling av mjukvaran da denkan vara till stor anvandning om en kritisk bugg skulle upptackas da enheternaredan ar distribuerade till kunden.

4.6 Ytterligare funktioner till CCP XS

Eftersom CCP XS ar en kraftfull dator bor den utnyttjas till mer an att baraatt kora som VT. I ISOBUS-standarden finns ocksa en standardiserad Taskcontroller. Den skall kunna anvandas for att kora sekvenserna och den skall ocksakunna anvandas for att importera och exportera data till ISOBUS-systemet.Task managern som kor sekvenser ar ett program som fran givna indatafiler kanstyra de inkopplade redskapen via ISOBUSen. Den skulle kunna implementerastillsammans med VTn och dela pa komponenter som t ex ISOBUS-stacken ochhardvarugranssnitt.

Den andra delen av Task controllern ar en File server som kan flytta datatill och fran ISOBUSen. Den skulle kunna implementeras med hjalp av USB-portarna pa CCP XS och man skulle da kunna flytta data med hjalp av ettUSB-minne.

Andra funktioner som bor anvandas ar den inbyggda GPS-mottagaren. EnISOBUS-node som gar att kopa for att utrusta traktor med ar GPS. Da dettafinns inbyggt i CCP XS skulle det ga att se till att GPS-positionen blir tillgangligpa ISOBUSen.

CCP XSn har ocksa funktioner for video och dessa skulle ga att anvandafor att koppla in en kamera. Det skulle t ex kunna sitta en kamera bakpa ettredskap for att se sa att allting fungerar som det ska. Detta finns inte stod fori ISOBUS-standarden men det finns inget som hindrar att tva program medgrafiskt granssnitt kors samtidigt pa CCP XS och att anvandaren vaxlar mellandessa, pa samma satt som det fungerar pa en PC. Mjukvara for kamera finnsredan utvecklat till CCP XS och det som skulle behova kompletteras med arnagon funktion for att vaxla mellan programmen. Lampligt i en sadan funktionar att om ett larm visas pa VT bor VTn sattas i fokus om kameran ar det innan.

Kapitel 5

DEMONSTRATORN

Figur 5.1: Systemoversikt av demonstratorn

5.1 Avgransningar

Da detta projekt har en strikt begransning i tid for bygget av demonstratornhar avgransningar gjorts for att kunna genomfora projektet inom tidsramarna.De avgransningar som har gjorts i VT-mjukvaran ar:

• Endast stod for vissa objekt

• Endast stod for vissa CAN-meddelanden

• Ej stod for makron

Avgransningarna har valts sa att VTn fungerar fullt ut tillsamman med dentestsimulator som har utvecklats i projektet. De objekt och CAN-meddelandensom valts att implementeras ar utifran vad simulatorn anvander. I praktiken in-nebar dessa begransningar att VTn fungerar helt enligt standarden om man harbyggt sin nod sa att den inte utnyttjar funktioner som inte ar implementeradei VTn.

Testning och simulering har begransats till att endast testa VTn mot simuler-ade redskap pa en PC. Detta for att fa sa bra mojligheter for debugging sommojligt och for att det inte gick att fa fram nagon fardig nod som man enkeltkan programmera med olika working sets.

Oberg, 2005. 43

44 Kapitel 5. DEMONSTRATORN

5.2 Simulatorprogram

5.2.1 Funktion

Programmet for simulering ar ett mjukvaruprogram skrivet i C++ som kors paen PC med ett PCI CAN-kort fran CC Systems installerat. Programmet simuler-ar tva redskap, en balpress som kopplas efter traktorn och en slattermaskin somar monterad framfor traktorn. Dessa kan man i simulatorn koppla till och frantraktorn var for sig och man kan ocksa i simulatorn se olika parametrar somskickas till redskapen fran VTn.

Balpressen

Balpressen har 3 egenskaper som redovisas i tabell 5.1.

Egenskap Beskrivning Forandras genomRunning Anger om maskinen ar igang. Kommando fran VTnBale size Anger hur stor balen ar for

tillfallet.Okar kontinuerligt narmaskinen ar igang.

Yarn left Anger hur mycket garn det finnskvar for att binda ihop fardigabalar med.

Minskar varje gang en balknyts. Aterfylls med enknapp i simulatorn.

Tabell 5.1: Egenskaper pa balpress

Nar man kor balpressen vaxer balen kontinuerligt och innan den uppnar sinmaxstrorlek maste balpressen tommas annars stannar den och ett alarm skickastill VTn. Skulle man valja att tomma maskinen utan att knyta balen kommerbalen att kollapsa nar den kommer ut ur maskinen. Nar man anvander garn foratt knyta balarna forbrukas garn och nar detta ar helt slut visas ocksa ett alarmpa VTn for att meddela att det ar dags att fylla pa med garn.

Balpressen visas ocksa grafiskt i simulatorn dar visas hur den tommer utbalar och skulle balen inte var knuten kollapsar den nar den kommer ut urbalpressen.

Slattermaskinen

Slattermaskinen har 2 egenskaper som redovisas i tabell 5.2.

Egenskap Beskrivning Forandras genomRunning Anger om maskinen ar igang. Kommando fran VTTrim Finjustering av klipphojden Kommando fran VT

Tabell 5.2: Egenskaper pa slattermaskin

Slattermaskinen ar lite enklare an balpressen med sina tva egenskaper. Egen-skapen trim som anger klipphojden staller man in pa VT antingen relativt medtva knappar, Uppat och Nerat eller absolut genom att mata in ett fixt varde.

5.2. Simulatorprogram 45

5.2.2 Uppbyggnad

Programmet ar programmerat helt fran grunden och i detta program har valtsatt inte anvanda en fardig ISOBUS-stack utan, programmet skickar CAN-med-delanden direkt till CAN-kortets dll. For att kunna fa simulatorn att fungera iett ISOBUS-system maste nagra funktioner skrivas som annars ligger i stack-en, transportprotokoll och address claming. Dessa tva valdes att skrivas frangrunden enligt standarden for ISOBUS for att kunna jamfora resultatet medalternativet att anvanda en fardig stack som gors i VTn.

Nar simulatorn har oppnat en CAN-anslutning vantar den pa att ett status-meddelande skall komma fran en VT. Sa fort som det kommer ett status-meddelande fran en VT vet simulatorn att det finns en VT i drift pa CAN-natet.Da sparar simulatorn source addressen pa det inkomna statusmeddelandet saatt den vet till vilken adress som den skall skicka meddelanden.

Sa fort som anvandaren av simulatorn nu valjer att ansluta ett redskapkommer simulatorn att starta upp redskapets simulerade ECU och borja sandastatusmeddelanden och forsoka sanda over ett working set.

Nu gar det att kora de olika redskapen om VTn ar i drift pa CAN-natet.For att fa de olika redskapen att verka mer realistiska vaxer balpressens balkontinuerligt nar pressen ar igang. Detta har lost med hjalp av en timer somlater balen vaxa ett steg per tidsenhet. Pa slattermaskinen gick det inte att latanagon enhet vaxa kontinuerligt utan dar sker i stallet en slumpvis forandriggenom att en timer anropar en slumpfunktion som okar eller minskar vardetsom anger avstandet till marken slumpvis. Detta for att simulera att marken arojamn.

Address Claiming funktionen

Da det i simulatorn inte anvands nagon stack maste nagon funktion ta hand omproblemet att erhalla en adress. Darfor har en egen funktion for address claimingskrivits. Den funktion som skrivits har stod for Non configurable address ECUoch Self configurable address ECU. Egentligen skulle det racka att redskapensnoder endast har en fast adress, dvs man kor i Non configurable address lage.Men eftersom simulatorn endast har tva redskap och man eventuellt vill testaatt koppla upp mer an tva redskap till VTn kan man gora det genom att startaigang mer an en simulator och koppla upp till VTn. Skulle man kora mer anen simulator samtidigt pa ISOBUSen med fasta nodadresser skulle endast deforst uppkopplade noderna fa tillgang till ISOBUSen da de andra upptacker enadresskonflikt nar de forsoker koppla upp sig. Darfor har simulatorn valts attkoras i sjalvkonfigurerande mode sa att man kan starta flera stycken simulatorersamtidigt och noderna sjalva kan hitta lediga adresser.

Transportprotokollet

I simulatorn har ett eget transportprotokoll implementerats i tva syften. For detforsta att testa om det fungerar lika bara som att anvanda sig av en fardigkoptstack med transportprotokoll i och for det andra for att anvanda det vid uppbyg-gnaden av extended transportprotokoll. Om man anvander en J1939 stack ochvill gora den ISOBUS-kompatibel behovs en losning for att bygga upp extendedtransportprotokoll och detta gar att gora med hjalp av det transportprotokollsom finns i simulatorn. Det behovs goras en mindre utbyggnad av funktionen


men det skall fungera bra att gora pa den stomme som finns. Dock har sim-ulatorn inte nagra meddelanden som ar sa langa att det de behover overforasmed hjalp av extended transportprotokoll, och av den anledningen har imple-menteringen av extended transportprotokoll valts bort.

5.2.3 Anvandarmanual

Installation

For att kunna kora simulatorn kravs att dessa filer finns:

sim ECU2.exedata/WorkSet baler.bindata/WorkSet mower.bin

Det finns ocksa en readmefil men den ar inget krav for att kunna kora pro-grammet. Det ar dock viktigt att bin filerna ligger i underkatalogen data.

Anvandning av simulatorn

Nu gar det bra att starta programmet med hjalp av exe-filen. Se ocksa till attdu har CAN-natet med VTn ansluten till CAN1 pa datorn.

Nar du startat programmet fardu upp programfonstret somser ut som i figur 5.2. Darhar du mojlighet att oppna ochstanga CAN-kommunikationenoch aven mojlighet att se sta-tusen pa kommunikationen.

Figur 5.2: Simulator under uppstart

Nar ett CAN-nat ar oppnatkommer simulatorn att se utsom i figur 5.3.I statusraden langst ner isimulatorn har man mojlighetatt se dels status for CAN-anslutningen och dels for VTanslutningen. Dock kan maninte fa nagon status pa VTforran man har valt att kopplanagot av redskapen.

Figur 5.3: Simulator startad

5.3. VTprogram 47

Nu finns det mojlighet att kop-pla redskap till traktorn. Det-ta gor man genom att bocka irutan under bilden pa respek-tive redskap. Det kommer sedanatt ta en liten stund medan red-skapet skickar over data till VT,men det ar klart da bilden paredskapet dyker upp som detgjort i figur 5.4. Da visas ocksaadressen pa VTn som simula-torn hittat langst ner till hogeri programmet.Vill man koppla bort ett red-skap klickar man bara bortbocken i rutan under redskapet.

Figur 5.4: Simulator med redskapkopplade

Nar ett redskap ar kopplat till traktorn kan man se statusen pa redskapetsolika parametrar under bilden. Dar har man ocksa mojlighet att paverka nagraparametrar som t ex att fylla pa garn i balpressen genom att trycka pa knappenRefill Yarn. De flesta parametrar andras annars antingen genom att man tryckerpa VTn eller automatiskt av simulatorn.

Om man har bada redskapen kopplade samtidigt ser man bara parametrarnafor ett i taget, men det gar enkelt att vaxla mellan redskapen genom att tryckapa de sma bilderna pa redskapen. Da visas parametrarna for de redskap mantryckt pa.

Balpressen har ocksa animeringar som kors nar den tommer ut en bal.Skulle man vilja testa att andra lite pa working setet som skickas over till

VTn sa kan man andra i de tva bin-filerna som ligger i data katalogen. Detar dessa tva filer som skickas over till VTn da ett redskap kopplas. Nar manandrar dem kan man forslagsvis anvanda sig av programmet Mask Generatorsom beskrivs i kapitel 4.4.4 pa sidan 38.

5.3 VTprogram

5.3.1 Funktion

VTn ar programmerad i Embedded Virsual C++ for att kunna koras underWIN CE. Detta program skall fungera som VT i en jordbrukstraktor. I standar-den for VT finns ett antal olika objekt som terminalen skall stodja och kunnarepresentera grafiskt. Manga ar ganska snarlika, t ex output string och outputinteger. Da stod inte har implementerats for samtliga objekt har objekt av saolika typ som mojligt valts. Vill man sedan komplettera VTn med ytterligareobjekt skall det da finnas stod for nagot snarlikt objekt som man kan utga ifran.

Av de standardknappar som skall finnas pa VTn for navigering har samtligaimplementerats. Dessa fungerar lika oavsett vilket objekt som laddas upp tillterminalen.


5.3.2 Terminalen

Terminalen som anvands for att kora VT programmet pa ar en CCP XS franCC Systems. Det ar en kompakt fordonsdator med en fargpekskarm pa mellan 6och 15 tum. Terminalen har ocksa anslutning for mus och tangentbord via USBom man vill anvanda det. En utforlig specifikation av CCP XS finns i bilaga D.

For att kommunicera med ovriga ISOBUS-enheter anvander terminalen enav sina tva CAN-anslutningar.

5.3.3 Uppbyggnad

VT mjukvaran har tva huvudfunktioner, dels att kunna ta emot ett working setoch dels att kunna kora ett mottaget working set. Da VTn bara ar en passivterminal bygger den helt pa att fa information fran noderna om vad och hur denskall pressentera information. Av den anledningen innehaller den inte mycketfunktionalitet utan funktionerna ar inbyggda i de olika objekten som nodernaskickar. I bilaga F finns en oversikt over hur VT-mjukvaran ar uppbyggd ochhur de olika komponenterna relaterar till varandra.

Till denna mjukvara valdes en fardig mjukvarustack for CAN-kommunika-tionen.

Mottagning av working sets

Da en nod onskar en viss funktionalitet av VTn sander noden over ett work-ing set innehallande ett antal objekt till VTn. Nar VTn erhaller ett CAN-meddelande innehallande information om ett working set satter mjukvaran igangen process for att skapa de objekt som finns i working setet. Eftersom ett work-ing set innehaller ett obestamt antal objekt maste dessa objekt lagras pa ettdynamiskt satt sa att antalet och objekttyperna har mojlighet att variera. Tilldetta har valts den dynamiska datastrukturen lankad lista. Da finns mojlighetenatt enkelt lagga till och ta bort objekt i listan. Det forsta som sker nar ett nyttworking set mottagits ar att skapa en tom objektlista. Denna lista skall sedanborja fyllas med objekt efter vad som beskrivits i meddelandet fran noden. IVT mjukvaran ar de olika typerna av objekt implementerade som C++ klasseroch nar ett working set innehaller information om att ett visst objekt skapas eninstans av den klass som motsvarar objekttypen. Denna instans placeras sedani listan i tur och ordning efter nar informationen om objektet kommer i workingset meddelandet.

Varje objekt har ett unikt objekt-ID som anvands i meddelanden fran nodentill ett specifikt objekt i VTn eller i de olika objekten for att referera till andraobjekt. T ex refererar objektet av typen Output string object till ett Font at-tribute object, nar Output string objectet skapas har det bara ett objekt-ID padet Font attribute object som de skall referera till. For att gora dessa referensersnabbare och enklare sa att man inte maste leta i listan varje gang efter ett visstID lankas hela working setet da alla objekt har skapats. Da erhaller alla objektsom innehaller referenser en pekare till de objekt som de refererar till.

5.3. VTprogram 49

For att hitta pekaren tvingas man dock att soka efter objekt med det specifi-ka IDet i listan med objekt. Sokning i listor gar att gora pa manga satt, mer ellermindre snabba, men i detta fall har det gjorts pa enklast mojliga satt genomatt stega igenom listan fran borjan till slut. Detta ar inte den smartaste ellersnabbaste sokningen men eftersom listan vanligen innehaller mellan 10 och 100objekt utgor det inte nagot problem att gora pa detta satt.

Denna procedur for att skapa working sets upprepas varje gangs som en nynod kopplas till VT och darfor kommer det att skapas ett pa forhand okantantal working sets. Dessa maste man halla reda pa pa nagot satt och det gorspa liknade satt som med objekten, i en lankad lista. Nar ett nytt working setskapas stoppas det in i listan med working sets. Skillnaden pa working set listani forhallande till objektlistan ar att denna lista har valts att goras cirkular. Dettahar gjorts genom att varje element i listan har en pekare till nasta element mendet som skulle kunna ha varit det sista elementet pekar tillbaka pa det forsta.Denna finess anvands av VTn nar man vaxlar mellan olika working set, somsker genom att man trycker pa nasta working set knappen. Man vill da bladdramellan de working set som finns och aldrig komma till nagot slut.

Anvanda working sets

Nar VTn har tagit emot working set fran en eller flera noder och placerat dem ilistan med working set gar det att kora working seten. Till varje working set finnsen agarnod med en unik adress som sparas tillsammans med working setet. Denadressen anvands nar meddelanden skickas tillbaka till noden for att veta vartde skall adresseras och for att veta till vilket working set som ett inkommandemeddelande harror. Nar ett working set har placerats i listan med working setkan man vaxla till det med hjalp av knappen for nasta working set pa VTn.Da kommer den mask som finns lagrad som default i working set att ritas upppa skarmen och man har mojlighet att dels se information som presenteras menocksa att paverka den information som skickas tillbaka till agarnoden genom attt ex trycka pa olika soft buttons eller mata in varden i input falt.

Agarnoden har ocksa mojlighet att skicka meddelanden till VTn for attpaverka egenskaper pa de objekt som finns i nodens working set. Nar VTntar emot ett sadant meddelande borjar den med att leta i listan med work-ing sets efter ett working set som har en adress som overensstammer med densom sandaren av meddelandet har. Alla meddelanden som skickas av noder tillobjekt i nodens working set har objektets ID som byte tva - tre. Nar iden-tifiering av vilket working set som meddelandet harror till ar det sedan baraatt leta i det working setets objektlista efter ett objekt med ett objekt-ID somoverensstammer med byte 2-3 i meddelandet. Som tidigare namnts ar ju al-la objekt instanser av klasser som alla har en metod att ta emot meddelandemed. Nar objektet ar lokaliserat ar det bara att anropa metoden for medde-landehantering i det objektet. I objektet finns sedan inbyggda funktioner for atthantera meddelandet.

Pa detta satt kor sedan VTn sa lange som noderna som ager working setenskickar sina statusmeddelanden med max tre sekunders intervall. Skulle maxti-den om tre sekunder fran senaste statusmeddelande overskridas kommer VTnatt anta att noden blivit bortkopplad och dess working set kommer att raderasfran VTn. Skulle noden sedan kopplas in igen maste den skicka over sitt workingset pa nytt for att kunna kora pa VTn.


Objektstrukturen

Tidigare har det namnts att objekten som skapas ar klasser i C++ och att detfinns en klass for varje objekttyp som finns definierad i ISOBUS-standarden.Objekten hade kunnat implementeras rakt av med en klass for varje objektoch inget mer, men nackdelen med det ar att om flera objekt har motsvarandefunktioner maste programkoden for dessa funktioner skrivas en gang i varjeobjekt. Detta har flera nackdelar, det blir mycket kod och skall man andra ikoden maste man ga in och gora det i varje klass. Darfor valdes att i stalletutnyttja funktionen med klassarv i C++ vilket innebar att man kan skriva kodfor en basklass och sedan lata flera andra klasser arva den klassen och darigenomerhalla de funktioner som finns i basklasser. For att utnyttja funktionerna medarv identifieras gemensamma namnare for flera klasser och stoppas i en basklassoch sedan skriva de unika egenskaperna i subklasser som arver basklassen. Ibilaga E finns ett relationsdiagram som visar hur objektklasserna relaterar tillvarandra. I relationsdiagrammet finns det inte klasser for alla objekt som finnsi ISOBUS-standarden utan endast for det utvalda antal som demonstratornstodjer. Men finns viljan att bygga ut funktionaliteten pa demonstratorn foratt stodja ytterligare funktioner ar strukturen uppbyggd sa att det skall varamojligt.

Uppdelningen med hjalp av dessa basklasser har gett fordelar som t ex attfunktionen for att fa skarmen att presentera output objekten endast behoverskrivas i outputs basklass och da kan alla output objekt arva den funktionen.Andra fordelar ar att gemensamma datamedlemmar (variabler) kan laggas ibasklasser, t ex har objektid och objekttyp lagts i basklassen objects da samtligaobjekt skall ha dessa datamedlemmar.

Prioriterad visning av masker

Pa VTn visas alltid den aktuella datamasken som hor till det working setanvand-aren har aktivt om inte nagot alarm visas. Skulle nagot working setvilja visa ett alarm skall det visas i stallet. Skulle flera workingset vilja visaalarm, skall det alarm med hogst prioritet visas. Alarmen har prioritet fran 0till 2 dar 0 ar hogst prioritet. For att kunna hantera detta i VTn har en funk-tion programmerats som gar igenom samtliga working set och tittar vad de olikaworking setet har for prioritet pa den mask som de onskar visa. For att gorajamforelserna enkla oavsett om det ar en alarm mask som har prioritet 0 till 2eller en data mask som normalt saknar prioritet har en prioritet inforts avenpa datamasker som da fatt prioritet 3. Nar alla masker har prioritet valjs denmask som har hogst prioritet och den ritas ut. Skulle flera masker ha sammaprioritet och nagon av dem redan visas skall den fortsatta visas.

Denna procedur fungerar aven da anvandaren bekraftar alarm och alarmmasks tas bort. Nar en alarm mask tagits bort skannas samtliga working setigenom for att hitta den hogst prioriterade masken. Skulle ingen alarm maskhittas, utan den hogsta prioriteten efter skanning ar 3, skall man aterga till attvisa den datamask som visades innan nagot alarm visades. For att kunna goradet, har man sparat vilken data mask som visades nar man senast gick fran attvisa en data mask till att visa en alarm mask.

5.3. VTprogram 51

Beskrivning av flodet genom programmet

I bilage F kan man se hur programmet ar uppbyggt och med pilarnas hjalp serman ocksa hur flodet genom programmet ser ut. Nar ett CAN-meddelande kom-mer till programmet tolkar Meddelandetolken meddelandet for att se om det arett meddelande till ett specifikt objekt eller om det ar statusmeddelade. Skullemeddelandet vara till ett specifikt objekt tar working set listan hand om med-delande och vidarebefordrar det till ratt objekt. Ar det ett statusmeddelandehanterar Maskhanteraren meddelandet.

Beroende pa vad ett meddelande innehaller kan det vara aktuellt for objek-ten att svara eller andra nagot pa skarmen, darfor finns det en koppling franobjekten tillbaka till skarmen och mojlighet att sanda ISOBUS-meddelanden.

Alla handelser pa VTarean, dvs olika knapptryckningar antingen pa Controlbuttons eller pa Soft key buttons, skall hanteras av objekt i det aktuella workingsetet och darfor finns det en pekare till det i Maskhanteraren sa att objekt somhor till aktuellt working set far informationen om handelserna.

Trycks det pa kontrollknappen for att byta working set som skall visas paVTn finns det en koppling till maskhanteraren sa att den kan satta ett nyttworking set aktivt och anropa ritfunktionerna i det working set objektet. Dakommer det nya working setet att ritas ut pa VTn.

Till Maskhanteraren finns ocksa en timer kopplad som hanterar statusmed-delanden. Nar VTn sjalv skall sanda ett statusmeddelande gors det nar timernsager till Maskhanteraren att det ar dags att sanda ett stausmeddelande. Da an-ropar Maskhanteraren det aktiva working setets working set objekt som sandermeddelandet med information om vilket working set som ar aktivt med mera.

Men VTn maste ocksa halla koll pa att samtliga working set ar aktiva och ettworking set ar aktivt om de inte fortlopt mer an 3 sekunder fran senaste mot-tagna statusmeddelande. Darfor har samtliga working set en parameter somanger tid da working setet skall sluta att vara aktivt. Nar ett statusmeddelandetill ett visst working set kommer till meddelandetolken skickas det vidare tillworking set listan som uppdaterar giltighetstiden pa det berorda working setettill aktuell tid plus 3 sekunder. Statusmeddelandetimern skickar med jamna mel-lanrum meddelanden till working set listan att skanna igenom samtliga workingset och kontrollera att inte giltighetstiden for nagot working set har gatt ut.Skulle tiden gatt ut kommer working setet att tas bort fran VTn.

Integrering av mjukvarustacken

Den stack som valdes till VTprogramvaran var en fardig J1939-stack fran Ixxat.Stacken som ar konstruerad for CAN-protokollet J1939 ar kompatibel medISOBUS, men den behover kompletteras med ett extended trasnport protokollfor att stodja samtliga funktioner i ISOBUS standarden. Eftersom denna VTendast kommer att koras mot simulatorn som inte anvander sig av extendedtransport protocol valdes att inte komplettera stacken, utan anvanda den i sittbefintliga utforande. Eftersom stacken ar kompatibel med J1939 finns det ocksanagra J1939-funktioner implementerade i den som inte anvands nar den kors iett ISOBUS-nat, men det utgor inte heller nagot problem.


Adaptering mot hardvaran

For att kunna anvanda stacken maste den kopplas mot CCP XS hardvara ochdet gors genom att anropa CCS CAN-drivrutin. Stacken som fran borjan harstod for Ixxats CAN-adapterar har alla anrop mot hardvaran samlade i enfilen “DLLtrg.c”. Den filen far man andra sa att stacken i stallet anropar CCSCAN-drivrutin. Detta ar inget storre problem, men det finns en funktioner somCCS CAN-drivrutin inte stodjer, och det ar funktionen “CheckStatus” som skallhamta status fran CAN-adaptern. Men CCS CAN-drivrutin har ingen funktionfor att erhalla statusen. Det enda som finns i CCS CAN-drivrutin ar “GetStatis-tics” men den ger bara statistik, inte status. Dock fungerar det bra att lamnadenna funktion tom och kora stacken anda.

Det finns ocksa en funktion i “DLLtrg.c” som heter DLL InitCAN. Dennafunktion vill anropa hardvaran for att andra overforingshastigheten. Tyvarr harCCS CAN-drivrutin inget stod for att andra overforingshastigheten nar kortethar startat. For att stalla in overforingshastigheten till CCS CAN-drivrutin garman in i Windows register och andrar en parameter som heter BaudRate idrivrutinens nyckel och sedan maste man starta om datorn. Detta spelar dockingen roll da man kor ISOBUS, for overforingen skall alltid goras med 250kbit/s.

Nar anpassningarna mot hardvara ar gjorda skall aven nagra parametrar tillstacken stallas in, t ex hur stora buffrarna for meddelanden som skall skickas ochtas emot skall vara. Dessa installningar gors i filen cnf.h. Har finns ocksa en pa-rameter man skall se upp lite med och det ar “CNF TPL MSG BUFFER SIZE”som anger hur stor bufferten for mottagna meddelanden som skickas med trans-port protokoll skall vara. Med standard transport protokoll kan man skicka ettmeddelande som ar upp till 1 785 byte langt, men man behover inte stallain bufferten storre an langsta mojliga meddelandet som kommer att hanteras.Valjer man onodigt stora buffrar kommer onodigt mycket minne att allokeras.Det finns en fara med denna parameter, och det ar om det andock kommer ettmeddelande som ar langre an vad man har raknat med och stallt in buffertstor-leken efter. Da kommer stacken att ta emot detta meddelande utan att kon-trollera att tillrackligt mycket minne ar allokerat och borja skriva over annatsom ar sparat i minnet.

Integrering i mjukvara

Stacken levereras som kallkod i ANCI C men det fungerar bra att integrera den iett C++ program om man bara deklarerar att det ar C kod man har inkluderatmed hjalp av C++ kommandot, extern “C”.

Sedan ar det i princip bara att borja anvanda stacken. Lita dock inte formycket pa det som star i manualen. Det finns vissa felaktigheter i manualen vaddet galler t ex datatyper och aven vilka parametrar en viss funktion har. Foratt vara saker pa hur funktinerna skall anvandas kontrollera i filen API.h darsamtliga funktioner och parametrar finns deklarerade.

Da CCS CAN-drivrutin inte genererar nagra interrupt maste man kontin-uerligt anropa stacken for att den skall fa mojlighet att titta efter meddelandenoch aven sanda meddelanden. Enligt Ixxats rekommendation skall dessa anropske med max (5 ms) intervall men da det var svart att uppfylla det kravet iVT-mjukvaran anropas den med (10ms) intervall och det har under testningenfungerat bra.

5.3. VTprogram 53

Har finns en annan konstighet i stacken. Nar stacken anropar skall ak-tuell tid skicka med. Da kontrollerar stacken om det tillatna tidsintervallet haroverskridits, t ex de rekommenderade (5 ms). Skulle en for lang tid forflutitreturneras FALSE och ett fel rapporteras. Som man ser i det lilla kodexempletnedan uppdateras tiden pa ett ganska konstigt satt. Skulle t ex tidsintervalletoverskridas 1 gang till (6 ms) och sedan alltid vara extat (5 ms) kommer detatt rapporteras fel for all framtid. Detta gar ganska enkelt att losa i koden narproblemet ar kant. Anropas stacken pa nytt sa fort den rapporterar ett fel safinns mojligheten att kora ikapp.

If (akt_tid > sat_tid)Sat_tid = Sat_tid + 5msRapportera Fel

ElseSat_tid = Sat_tid + 5msRapportera OK

En annan sak att tanka pa, som beskrivs otydligt i manualen, ar att derekommenderar att stacken anropar sa ofta det gar. Detta kan misstolkas somatt programmet skall forsoka anropa stacken sa ofta det gar, dvs att ibland blirdet med (1 ms) intervall, och ibland med langre intervall. Sa ar det inte utantidsintrervallet som stacken skall anropas med maste fran borjan bestammas ochutifran det satta intervallparametern. For nar programmet anropar stacken upp-dateras interna timrar i stacken med den fordefinierade intervalltiden. Detta skerutan hansyn till vilken aktuell tid programmet skickar in till stacken. Anroparsstacken med kortare intervall an vad som stallts in kommer de interna timrarnai stacken att ga for fort och problem kan uppsta med CAN-kommunikationen.

Nagra andra iakttagelser som gjorts nar stacken implementerades var bla attnar programmet gor de kontinuerliga anropen av stacken maste programmet delsanropa APL main funktionen men aven DLL cycle. DLL cycle ar en lite hemligfunktion som inte star omnamnd i manualen men det kravs att den anropas daCAN-drivrutinen inte genererar nagra interrupt.

Man maste ocksa tanka pa att det finns ett inbyggt mjukvarufilter for med-delandeIDn i stacken, sa samtliga meddelanden man onskar kunna ta emot mastedeklareras i filterlistan som skickas in till stacken da den initieras.

Den inbyggda funktionen for cykliska meddelanden som till synes verkar gan-ska anvandbar i VTn visar sig inte vara fullt lika bra nar man tittar narmare paden. Detta pga att samtliga meddelanden som beror VTn har samma medde-landeid men med en unik identifierare i databyte ett. Det man skulle ha nyttaav ar en cyklisk funktion som identifierar meddelanden med hjalp av medde-landeid och forsta databyten. Funktionen fungerar bra nar det galler att skickacykliska meddelanden men nar den skall identifiera om meddelanden tas emotkontinuerligt kan den inte gora skillnad pa olika meddelande utan ser bara IDet,som ar lika for alla meddelande till VTn.


5.3.4 Anvandarmanual

Installation

VT-mjukvaran ar enkel att installera. Det ar bra att flytta filerna till fordons-datorn med hjalp av lamplig programvara t ex den inbyggda filhanteraren iMicrosoft Embedded. De filer som ingar ar:

VT.exeData mask.bmpVT area.bmp

Dessa filer maste ligga i katalogen Hard Disk pa fordonsdatorn nar program-met skall koras och CAN-natet skall vara anslutet till CAN1.

Anvandning av VT

Programmet ar bara att starta med filen VT.exe. Sedan kommer programmetatt koras maximerat pa terminalen och det blir snyggast om man valjer doljautomatisk pa Windows aktivitetsfalt.

Nar programmet startat kom-mer det att se ut som figur 5.5visar.De olika knapparna och dessfunktion kommer du att kannaigen om du jamfor med kapi-tel 2.5.1 Fysiska uppbyggnadenpa sidan 14.

Figur 5.5: VTn efter uppstart

Nar man sedan stallt in ett nytt varde maste man trycka pa Enter-knappenfor att det skall sandas over till redskapet. Om man skulle andra sig och villavbryta andringen man borjat gora, kan man i stallet trycka pa ESC-knappenfor att avbryta inmatning och aterga till ursprungsvardet.

Nar redskap kopplas bort fran VTn kommer dess skarmbild pa VTn attforsvinna inom 1 sekund och ett annat redskap som ar uppkopplat kommer istallet att visas. Finns det inga redskap anslutna visas bilden med ISOBUS-logotypen.

5.3. VTprogram 55

Nar terminalen ar startad ardet bara att koppla till ett red-skap. Da kommer informationom redskapet automatiskt attkomma upp pa skarmen som ifigur 5.6. Dar finns ocksa 4 stSoft keys for att kunna styraredskapet med.

Figur 5.6: VT med balpressansluten

Om man valjer att i simula-torn koppla till slattermaskinen(mower) kommer man att faupp tva stycken numeriska in-matningsfalt dar man kan ma-ta in nya varden till red-skapet i. Dessa hoppar manmellan med upp- och nerpilenoch ett valt inmatningsfalt harsvart streckad kant, se fig-ur 5.7. Nar faltet ar marker-at kan man andra vardet medplus- och minusknapparna. Safort man har andrat vardetfran ursprungsvardet andrarsden streckade kantens farg tillrott.

Figur 5.7: VT med slattermaskinansluten

Litteraturforteckning

CAN in Automation (CiA), (2002), CAN specification 2.0. Part B, CiA.

Fellmeth Peter, (2003),“CAN-based tractor - agricultural implementcommunication ISO 11783” i CAN Newsletter september 2003.

Junger Markus, (2004), Introduktion to J1939, Vector Informatik GmbH.

ISO, (2004), ISO 11783-6 Virtual Terminal, SIS forlag.

ISO, (2002), ISO 11783-7 Implement messages application layer,SIS forlag.

ISO, (2002), ISO 11783-9 Tractor ECU, SIS forlag.

SAE, (2001), SAE J1939-21 Data link layer.

SAE, (1997), SAE J1939-81 Network management.

Stone Marvin L. mf, (1999), ISO 11783: An electronic communicationsprotocol for agricultural equipment, ASAE.

Philips Semiconductors, (2000), PCA82C251 Can transceiver for 24Vsystems.

InternetCAN in Automation (CiA), 2005-04-10, http://www.can-cia.org

A painless guide to crc error detection algorithms, 2005-04-29,http://www.cs.waikato.ac.nz/ 312/crc.txt

Oberg, 2005. 57

58 Litteraturforteckning

Bilaga A

Ordlista

CAN Control Area Network.

CAN-adapter Koppling mellan PC och CAN-nat. T ex ett PCI-kort.

CCP XS Fordonsdatorn utvecklad av CC Systems, se specifikation i bialga D.

ECU Electronic Control Unit, utgor en nod i ett ISOBUS-system.

ISOBUS CAN-standard for jordbruksmaskiner, ISO 11783.

Objekt Modul som skickats till VTn och har oftast nagon form av grafiskrepresentation t ex en knapp.

Objektpott Ett working sets samtliga objekt. Eng Objectpool.

PGN Parameter Group Number, del av CAN-meddelandets ID.

VT, Virtual Terminal Den terminal som sitter i traktorn i ett ISOBUS-sytem.

Working set Ett redskap som ar kopplat till VTn.

Oberg, 2005. 59

60 Bilaga A. Ordlista

Bilaga B

Meddelande i en CANframe

Oberg, 2005. 61

62 Bilaga B. Meddelande i en CAN frame

Bilaga C

Mail

C.1 Till potentiella leverantorer

Hello!

My name is Anders Oberg working at CC Systems in Sweden. I’m now workingwith evaluation of ISOBUS and I’m interested in baying software for a VirtualTerminal. I can se at your homepage that you have a Virtual Terminal. And mayquestion is if you are interested to sale the software. Maybe you have purchasedyour software from same other company, in that case which company?

RegardsAnders Oberg

Oberg, 2005. 63

64 Bilaga C. Mail

C.2 Angaende mjukvaruleverantorer

Dear Mr. Nissen

My name is Anders Oberg working at CC Systems in Sweden. I have got yourname from my director Claes Ulvefeldt.I’m now working with a evaluation of ISOBUS applications and my goal is to finda solution for using our companies on-board computers as a Virtual Terminal.The solution I have for the implementation of Virtual Terminal is to by a finishedsoftware package and run it on our computer. The problem I have is to find somecompanys that supply software for Virtual Terminal. What I have heard fromClaes Ulvefeldt is that you work with the ISOBUS standard and my have somecontacts with software companies.I hope that you have some contacts that can be useful for me.

Best RegardsAnders Oberg

C.3. Angaende utveckling av ISOBUS 65

C.3 Angaende utveckling av ISOBUS

Dear Mr. Nissen

During may research for ISOBUS software some questions about requirementof updates have come up. Because you are the person that i have contact withthat seams to have the best knowledge about the Virtual Terminal parts ofthe ISOBUS standard you maybe have some good answer to may questions ormaybe know some one who have. May questions is.

As you know the standard for the Virtual Terminal is recently established, doyou think that will be same changes in the standard now in the beginning?[Ni] No doubt, WG1 just requested a new work item two days ago,to include necessary corrections in respect of language support, AuxControl support, and several other details into part 6 of the standard.

If you think it will be some changes when in time do you think the standardwill be stabilized and we see a sharp decrees of the changing frequency?[Ni] ISO11783 is a technical standard and with that it will continueto move with the new electronics available. In parallel we learn moreand more what we could do within the scope of the standard, so welearn new things while we implement the standard and we feed thisback into the standard. And last but not least; humans make errorsand therefore we need to correct certain things from time to time.The ISO directives say that an international standard (like part 6 ofISO11783) has to be reviewed every 5 years. Additionally are a max-imum of 2 corrections and amendments within that 5 years allowed.You see changes are possible, and often necessary. The frequency isvery much topic dependent and for part 6 we have plenty of ideasand needs to update this document. So I expect the new work itemto be released for first voting already in 2006; the ISO process tomove this document from draft to international standard stage willtake an other year. If and when we implement this in advance to theIS stage of the document is totally open and up to discussion in IGIand NAIITF.

If changes are made in the standard what opportunities have we applicationdevelopers to be informed of it. Have ISO some new letter subscription?[Ni] I’m not sure how that works officially. The official way is proba-bly to purchase the updates of the standard documents. However, thebest way to be informed about the current implementation stage isobviously to join the “Implementation Group ISOBUS” (IGI) underVDMA here in Germany or “North American ISOBUS Implemen-tation Task Force” (NAIITF). Here we discuss the necessary stepsand technical details during implementation. We agree on when toimplement which new function and we organize so called plugfeststo test upfront if the systems work together etc. to ensure that we

66 Bilaga C. Mail

provide the appropriate products to our customers.

The reason why I’m asking this is to estimate how much effort we shod put into making solutions in the system for easy updating.I will be grateful if you have time to answer my question or know some one whomaybe have the answers.

Best regards

Anders Oberg

Bilaga D

CCP XS Specifikation

Oberg, 2005. 67

68 Bilaga D. CCP XS Specifikation

Bilaga E

Relationsdiagram for VTobjekt

Oberg, 2005. 69

70 Bilaga E. Relationsdiagram for VT objekt

Bilaga F

Uppbyggnad av VTprogram

Oberg, 2005. 71

72 Bilaga F. Uppbyggnad av VTprogram

LINKÖPING UNIVERSITYELECTRONIC PRESS

Copyright

The publishers will keep this document online on the Internet - or its possi-ble replacement - for a period of 25 years from the date of publication barringexceptional circumstances. The online availability of the document implies a per-manent permission for anyone to read, to download, to print out single copiesfor your own use and to use it unchanged for any non-commercial research andeducational purpose. Subsequent transfers of copyright cannot revoke this per-mission. All other uses of the document are conditional on the consent of thecopyright owner. The publisher has taken technical and administrative mea-sures to assure authenticity, security and accessibility. According to intellectualproperty law the author has the right to be mentioned when his/her work isaccessed as described above and to be protected against infringement. For ad-ditional information about the Linkoping University Electronic Press and itsprocedures for publication and for assurance of document integrity, please referto its WWW home page: http://www.ep.liu.se/

Upphovsratt

Detta dokument halls tillgangligt pa Internet - eller dess framtida ersattare- under 25 ar fran publiceringsdatum under forutsattning att inga extraordi-nara omstandigheter uppstar. Tillgang till dokumentet innebar tillstand forvar och en att lasa, ladda ner, skriva ut enstaka kopior for enskilt bruk ochatt anvanda det oforandrat for ickekommersiell forskning och for undervisning.Overforing av upphovsratten vid en senare tidpunkt kan inte upphava dettatillstand. All annan anvandning av dokumentet kraver upphovsmannens med-givande. For att garantera aktheten, sakerheten och tillgangligheten finns detlosningar av teknisk och administrativ art. Upphovsmannens ideella ratt in-nefattar ratt att bli namnd som upphovsman i den omfattning som god sedkraver vid anvandning av dokumentet pa ovan beskrivna satt samt skydd motatt dokumentet andras eller presenteras i sadan form eller i sadant sammanhangsom ar krankande for upphovsmannens litterara eller konstnarliga anseende elleregenart. For ytterligare information om Linkoping University Electronic Pressse forlagets hemsida http://www.ep.liu.se/

c© 2005, Anders Oberg

Oberg, 2005. 73

Implementering av ISOBUS Virtual Terminal p˚a ...21233/FULLTEXT01.pdfa Virtual Terminal program. An...

Documents

Transcript of Implementering av ISOBUS Virtual Terminal p˚a ...21233/FULLTEXT01.pdfa Virtual Terminal program. An...