Modellering och simulering av hydraulik för användning i hardware-in-the-loop

Modellering och simulering av hydraulik för

användning i hardware-in-the-loop

Examensarbete utfört i Hydraulikmodellering vid Tekniska högskolan i Linköping

av

Erik Israelsson

LiTH-IEI-TEK-A--12/01359--SE Linköping 2012

Modellering och simulering av hydraulik för

användning i hardware-in-the-loop

Examensarbete utfört i Hydraulikmodellering

vid Tekniska högskolan i Linköping

av

Erik Israelsson

LiTH-IEI-TEK-A--12/01359--SE

Handledare: Robert Braun

iei, Linköpings universitet

Mattias Arnsby

Toyota Material Handling Examinator: Karl-Erik Rydberg

iei, Linköpings universitet Linköping, 7 juni, 2012

Avdelning, Institution

Division, Department IEI

Department of Management and Engineering Linköpings universitet

SE-581 83 Linköping, Sweden

Datum Date 2012-06-07 Språk Language  Svenska/Swedish  Engelska/English   Rapporttyp Report category  Licentiatavhandling  Examensarbete  C-uppsats  D-uppsats  Övrig rapport  

URL för elektronisk version

http://www.iei.liu.se/flumes http://www.ep.liu.se ISBN — ISRN LiTH-IEI-TEK-A--12/01359--SE

Serietitel och serienummer

Title of series, numbering

ISSN

—

Titel

Title

Modellering och simulering av hydraulik för användning i hardware-in-the-loop Modeling and simulation of hydraulics for use in hardware-in-the-loop

Författare

Author

Erik Israelsson

Sammanfattning

Abstract

Modeling and simulation is growing ever more important in the development of new products. This thesis describes the use of Hopsan for hydraulic modeling and its use in conjunction with Simulink with the intent of using the model in a hardware-in-the-loop setup. A sensor layer has been created in Simulink to emulate all the internal sensors in a modern forklift. The details of using legacy C-code instead of a hardware MCU for a fully simulated environment, software-in-the-loop has been outlined. There are two major routes one can follow implementing software-in-the-loop, exporting the C-functions to CAPL via a export layer or creating an s-function in Simulink. Of the two the export layer method is the most promising since it is easier handling different execution times in CAPL than in Simulink.

Nyckelord

Abstract

Modeling and simulation is growing ever more important in the development of new products. This thesis describes the use of Hopsan for hydraulic modeling and its use in conjunction with Simulink with the intent of using the model in a hardware-in-the-loop setup. A sensor layer has been created in Simulink to emulate all the internal sensors in a modern forklift. The details of using legacy C-code instead of a hardware MCU for a fully simulated environment, software-in-the-loop has been outlined. There are two major routes one can follow implementing software-in-the-loop, exporting the C-functions to CAPL via a export layer or creating an s-function in Simulink. Of the two the export layer method is the most promising since it is easier handling different execution times in CAPL than in Simulink.

Sammanfattning

Modellbygge och simulering blir en allt mer prominent del inom produktutveckling. Exjobbet behandlar modellering av hydrauliken i en gaffeltruck. Hydraulikmodel-len kopplas samman med ett sensorlager i Simulink för att till sist kunna användas i hardware-in-the-loop tillämpningar. Även möjligheterna att använda äldre C-kod tillsammans med modellen, software-in-the-loop har undersökts och riktlinjer för en framtida fullskalig implementation har tagits fram. Det finns två principiella sätt som software-in-the-loop kan användas, genom att exportera C-funktionerna via exportlager till CAPL alternativt skapa en s-funktion i Simulink. Av de två är exportlagret det mest lovande tack vare CAPLs förmåga att hantera olika exekve-ringstider.

Tack

Inledningsvis vill jag tacka elektronikavdelningen på BT och min handledare, Mat-tias Arnsby för att jag har fått utföra mitt examensarbete där. Även hydraulikav-delningen (Lena förtjänar ett speciellt omnämnande) har varit mycket hjälpsam-ma och svarat på frågor och ställt upp med sin tid för att modifiera ventilblock med sensorer. Robert Braun, min handledare från skolan, har varit en stor hjälp när Hopsan har strulat och givit värdefulla tips vid rapportskrivningen. Profes-sor Karl-Erik Rydberg för sitt kunnande inom hydrauliksystem och hans roll som examinator.

Sist men inte minst vill jag tacka alla ni som bidrar till LA_{TEX. Utan er hade jag}

spenderat all min tid med att bekämpa Word istället för att färdigställa rapporten.

Linköping, Maj 2012 Erik Israelsson

Innehåll

1 Introduktion 3 1.1 Bakgrund . . . 3 1.2 Syfte . . . 3 1.3 Disposition . . . 4 1.4 Avgränsningar . . . 4 2 Teori 5 2.1 Transmission line modelling . . . 5

2.2 Hydraulik . . . 6 2.2.1 Ventiler . . . 6 2.2.2 Pumpar . . . 7 2.2.3 Hydraulcylinder . . . 7 2.2.4 Hydraulsystem . . . 7 3 Simuleringsmiljö - Översikt 9 3.1 Hydraulik - Programval . . . 9 3.1.1 Hopsan . . . 10 3.2 Simulink - CANoe . . . 11 4 Hydraulikmodell 13 4.1 Grundläggande modell - Utskjut ”reach” . . . 13

4.2 Utökad modell - Fri och huvudlyft . . . 17

4.3 Mätresultat, kalibrering och validering . . . 21

4.3.1 Innan kalibrering . . . 22 4.3.2 Kalibrering . . . 23 5 Simulink gränssnitt 27 5.1 Positionssensor . . . 27 5.2 Styrsignaler - Ventiler . . . 29 5.3 Trycksensor . . . 30 5.4 Prestanda . . . 30 ix

x Innehåll

6 HIL - Hardware In the Loop 33

6.1 SIL - Software In the Loop . . . 35

6.1.1 CAPL . . . 35

6.1.2 S-funktion . . . 38

7 Användarhandledning 41 7.1 Hopsan . . . 41

7.1.1 Exportera Hopsan till s-funktion . . . 41

7.1.2 Hopsan och Python . . . 42

7.1.3 Felsökning . . . 43

7.2 Simulink till .dll via Simulink Coder . . . 43

7.2.1 Felsökning . . . 44

7.3 Importera Simulink-dll till CANoe . . . 44

8 Diskussion 47 8.1 Framtida arbete . . . 48

9 Slutsats 49

Symbol Förklaring Enhet Symbol Förklaring Enhet

A area [m2_{] }

p Ställtal [-]

Cq flödeskoefficient [-] δ Dämpning [-]

D deplacement [m3_{/rad] s slaglängd [m]}

F last,kraft [N] Bp Viskös friktion [Ns/m]

J tröghetsmoment [kgm2_{] Beta}

e Bulk modulus [Pa]

M massa [kg] τ Tidskonstant [s] Np pumpvarvtal [rad/s] V volym [m3] p tryck [P a] q flöde [m3/s] t tid [s] xv läge (servoventil) [m] xp läge (cylinderkolv) [m] ρ densitet [kg/m3_] ω vinkelfrekvens [rad/s] Tabell 1: Nomenklatur

HIL Hardware in the loop SIL Software in the loop

TMHE Toyota Material Handling Europe CAN Controller Area Network

CANoe Utvecklings och testprogram primärt för ECU (electronic control unit)

CAPL Händelsebaserat scriptspråk till CANoe DLL Dynamicly linked library

MCU Main control unit

HAL Hardware abstraction layer

Reach Rörelse då gaffelpaketet skjuts ut ifrån trucken

Huvud/Fri-lyft

Höj och sänkning av gaffelpaketet. Rörelsen sker i två steg, först sker frilyftet innan två andra cylindrar tar över rörelsen.

Hopsan Simulering och modelleringsprogram utvecklat av Linköpings Uni-versitet

RRE Reach Rider Electric , trucktypen som modelleras Tabell 2: Ordlista

Kapitel 1

Introduktion

1.1

Bakgrund

BT Products AB grundades 1946 och blev en del av Toyota Material Handling år 2000. BT Products tillverkar truckar i alla storlekar och prisklasser. Gemen-samt är att mängden kod som styr truckens funktioner och körupplevelse ständigt ökar. Toyota är kända för sitt kvalitetsarbete, ord som kaizen och lean production har spritts över världen och tillämpas inom allt fler områden. Den röda tråden i deras produktionsfilosofi är att synliggöra problem och åtgärda orsaken till upp-komsten. Detta gäller även för den kod som hamnar i en färdig truck. Utveckling av styrsystem är en intrikat del av den upplevda kvalitetskänslan i en färdig gaf-feltruck. Därför måste koden genomgå rigorösa funktionstester innan koden är redo för leverans. Det är med den bakgrunden som det har beslutats att ett HIL (hardware-in-the-loop) system skall införskaffas. HIL används för att simulera en truck som koden testas mot. Fördelarna med HIL jämfört med att testa kod mot en riktig gaffeltruck är många. Reglerstrategier kan utvärderas tidigt i utveck-lingscykeln mot en modell istället för att behöva vänta på en färdig prototyp. En högre grad av automatisering av tester är möjligt vilket leder till att fler funk-tioner kan testas. Automatiseringen medför också att utvecklare frigörs från det monotona arbetet att manuellt testa funktioner i styrsystemet. Allt detta leder till kortare utvecklingscykler och att buggar upptäcks snabbare. För att en HILrigg skall fungera krävs en modell av trucken och omvärlden för att ge realistisk data till styrsystemen.

1.2

Syfte

Examensarbetet har sin utgångspunkt i att en modell över hydrauliken i en färdig-utvecklad gaffeltruck skall modelleras. De sensorer som finns på trucken (position i höjdled för gafflarna t.ex.) måste finnas med för att koden ska få verklighetstroget stimuli. Därför behövs även skattningar av den resulterande rörelsen som hydrau-liken bidrar till. Det slutgiltiga målet är att ha en modell som kan kopplas till det

4 Introduktion

inköpta HIL-systemet och vara modifierbart för att anpassas till andra hydraulsy-stem. Modellen skall vara ”enkel” i den mening att det ska gå att använda den i realtidstillämpningar utan att avvika allt för mycket från verkligheten. Riktlinjer för hur test kan skrivas för att utnyttja den framtagna modellen samt användar-handledning för hur hydraulikmodellen kan anpassas till andra hydrauliksystem skall även tas fram.

1.3

Disposition

Kapitel 2 innehåller teori bakom TLM simuleringstekniken. Även grundläggande hydraulikomponenter beskrivs. Kapitlet är tänkt fungera som en kort introduktion till de olika hydraulikkomponenternas funktion och beteende. Det är med andra ord ingen komplett hydraulikformelsamling. Kapitel 3 är ett försök att ge en över-blick av den resulterande simuleringsmiljön. Kapitlet ligger i början av rapporten i hopp om att resterande kapitel skall bli lättare att följa. Kapitel 4 och 5 redovisar för modellerna i Hopsan och Simulink. Kapitel 6 är en redogörelse för arbetet med möjligheterna till en SIL-miljö.

1.4

Avgränsningar

Brist på licenser samt hårdvara gjorde det omöjligt att implementera modellen i HILriggen. Den fysiska MCU som skulle användas fanns ej tillgänglig och HILrig-gen var under hela exjobbet ockuperat av testinHILrig-genjörer som utförde mer direkt värdehöjande arbete. Vector CANoe kräver en hårdvaru-dongel i licenssyfte, det fanns en sådan på företaget, tillgängligheten var med andra ord högst begränsad. I ljuset av detta undersöktes möjligheterna till SIL-simulering (Software in the loop), dvs. en fullständigt simulerad miljö.

Kapitel 2

Teori

”All models are wrong, some are useful” - George E.P. Box

Modellbygge handlar i många fall om att skapa matematiska modeller över verkligheten. Dessa modeller kan man sedan använda för att simulera olika intres-santa körfall eller aspekter av systemet. De flesta modeller byggs upp av differen-tialekvationer t.ex. Newtons andra rörelselag som beskriver förhållandet mellan en kropps massa, acceleration och pålagd kraft.

m∂

2_x

∂t2 = F (x(t)) (2.1)

Dessa ekvationer brukar benämnas ODE (ordinary differential equation) och utnyttjas i t.ex. Modelica. Linjära differentialekvationer kan oftast lösas expli-cit men då verkligheten sällan är så linjär som vi skulle vilja krävs oftast olinjära differentialekvationer för att beskriva ett system. Dessa ekvationer löses genom nu-merisk analys där en lösning approximeras. En nackdel med system beskrivna med differentialekvationer är att de är svåra att parallellisera lösningarna då ekvatio-nerna innehåller många beroenden till andra variabler i systemet. Vid modellering av hydraulik är det möjligt att utnyttja den inneboende vågkaraktäristiken som propagerar genom systemet, detta kallas TLM.[3]

2.1

Transmission line modelling

Hopsan utnyttjar TLM (transmission line modelling) vilket innefattar transmission

line elements. Tanken är att bygga en modell av flertalet numeriskt separerade

element. Där varje element kan beräknas oberoende av resten av systemet. För att uppnå denna numeriska separation ersätts kapacitiva komponenter (t.ex. volymer i hydraulik) med ett ’rör’ med tidsfördröjning. En illustration ges i figur 2.1. Denna tidsfördröjning ger en fysikaliskt korrekt modellering av hur en våg propagerar i systemet.

6 Teori

Zc

p1,q1 p2,q2

Figur 2.1: Transmission line element

En transmissions lina kan med negligerbar friktion beskrivas enligt ekvationer-na nedan, se ekvation (2.2) och (2.3)

p2(t) = p1(t − T ) + Zcq2(t) + Zcq1(t − T ) (2.2)

p1(t) = p2(t − T ) + Zcq1(t) + Zcq2(t − T ) (2.3)

p och q är tryck respektive flöde, Zc är impedansen. För att kunna lösa den

här ekvationen införs två nya hjälpvariabler enligt följande.

c1(t) = p2(t − T ) + Zcq2(t − T ) (2.4)

c2(t) = p1(t − T ) + Zcq1(t − T ) (2.5)

Ekvation (2.4) och (2.5) beskriver hur vågorna i systemet rör sig i systemet.

p1(t) = c1(t) + Zcq1(t) (2.6)

p2(t) = c2(t) + Zcq2(t) (2.7)

Ekvation (2.6) och (2.7) kan nu lösas med hjälp av randvillkor för tryck och flöde. En transmissions lina representerar avståndet mellan komponenterna som en tidsfördröjning i vågpropageringen en tidsfördröjning som är lika lång som tidsste-get i simuleringen. Eftersom vågor utbreder sig med ljudhastigheten kan man alltså beräkna längden på komponenten t.ex. en slang i ett hydraulsystem. Avstånden -tidsfördröjningen - i systemet är en fysikalisk motiverad uppdelning av systemet till mindre oberoende undersystem som kan till väldigt hög grad parallelliseras.[2]

2.2

Hydraulik

2.2.1

Ventiler

Ventiler används för att styra flödet i hydraulsystem. Det finns olika typer av ventiler där de enklaste fungerar som på eller av för ett visst delsystem. Andra kan användas för att skicka flödet i olika riktningar t.ex. för att flytta en cylinder i motsatt riktning. Gemensamt är att alla beskrivs av samma ekvation för turbulent flöde enligt ekvation (2.8), tryckskillnaden exemplifieras i figur 2.2.

q = CqA

r 2

2.2 Hydraulik 7

p1 p2

q

Figur 2.2: Laminär flödesrestriktor

Ventiler kan användas för att styra mängden vätska som flödar igenom ventil-blocket, då kallas ventilerna för proportionella. Genom att justera öppningen via en aktuator kan flödet varieras.

A = 2πdf x (2.9)

Ekvation (2.9) visar hur arean som är tillgänglig för flödet ändrar sig vid ändrad styrsignal x, d är diametern på spolen och f är förskjutningen hos spolen. Ventiler har även viss dynamik modellerad som ett enkelt lågpassfilter med dämpning och bandbredd som parametrar.

2.2.2

Pumpar

En hydraulpump har två primära parametrar som bestämmer dess prestanda. Has-tigheten som ofta mäts i RPM (revolutions per minute) samt dess deplacement, mängden vätska som förflyttas varje varv. En mer avancerad modell beaktar även volymetrisk verkningsgrad samt pumpens ställtal. Ställtalet motsvaras av insigna-len till pumpen i Hopsanmodelinsigna-len. Ekvationen för pumpen beskrivs i sin helhet i ekvation (2.10).

q = pDpnpηvolp (2.10)

2.2.3

Hydraulcylinder

Hydraulcylindrar används för att omvandla vätsketrycket i systemet till mekaniskt arbete. Hydraulcylindern fungerar genom att olja pressas in genom en öppning i änden av cylinder vilket ger upphov till en tryckdifferens, denna differens tvingar kolven att röra sig. Ekvation (2.11) beskriver sambandet mellan den kraft som kolven pressar med och trycket i en kammare (trycket i den andra kammaren antas i detta fall vara noll), inget läckflöde beaktas.

F = AP (2.11)

2.2.4

Hydraulsystem

Hydraulsystem är uppbyggda av bland annat de komponenter som har beskri-vits ovan. För att kontrollera funktionen t.ex. cylinderhastigheten måste flödet i systemet kontrolleras. Det finns två principiella sätt för att kontrollera flödet.

• Pumpstyrning • Ventilstyrning

8 Teori

Vid pumpstyrning används en pump med variabelt ställtal för att minska eller öka varvtalet. Varje enskild funktion i systemet behöver en egen pump för att kunna styras individuellt vilket snabbt gör enbart pumpstyrning till en kostsam lösning. En tänkbar lösning är ventilstyrning där en eller flera ventiler används för att styra de enskilda funktionerna i systemet. Det finns ett flertal lösningar på hur pumpen skall styras för att ge ett tillräckligt flöde till de olika funktionerna. Konstantflödessystem och konstanttryckssystem tillhör de vanligaste och enklaste designmässigt, förlusterna är dock högre än i t.ex. lastkännande system.

Kapitel 3

Simuleringsmiljö - Översikt

För att underlätta för läsaren följer här en översikt av de program som används och hur de interagerar med varandra.

3.1

Hydraulik - Programval

För att modellera hydrauliken finns det ett flertal alternativ. Amesim och Dy-mola är båda baserade på Modelica. Modelica är ett språk som används för att modellera allehanda fysikaliska system. Projektet hade sin början 1996 då Hil-ding Elmqvist initierade samarbetet. Modelica är idag ett mycket kraftfullt och vida använt språk. Det finns ett flertal kommersiella programvaror som har fär-diga objektbibliotek för olika discipliner t.ex. mekanik, hydraulik, elektronik etc. Det finns även OpenModelica vilket är en GPL-licensierad Modelica kompilator utvecklad på Linköpings Universitet. Det existerar även ett opensource GUI till OpenModelica som är resultatet av ett examensarbete på Linköpings Universitet [1].

Hopsan har utvecklats på Linköpings Universitet sedan 1970-talet. En ny ver-sion, Hopsan-NG har varit i utveckling sedan 2009 och har en objektorienterad design. Den nya versionen är skriven i C++ och har ett GUI skapat i Qt1. Pro-grammet fungerar under Windows, Linux och MacOS. Hopsan utnyttjar TLM (transmission line modelling) där varje objekt beskrivs som ett element av antingen C-typ (volymkomponenter) eller Q-typ (flödeskomponenter)[8]. Varje komponent utnyttjar vågkaraktäristik för att kunna beräkna flöde och tryck. Fördelen med detta är att varje element kan ha en egen lösare för de beskrivande ekvationerna, de är även numeriskt separerade. Det leder till att komplexa system kan byggas upp av små undersystem som kan lösas parallellt. Sammantaget leder detta till att Hopsan är ett väldigt effektivt sätt att modellera och simulera hydraulik på. Modellerna kan med fördel användas i realtidssimuleringar[6].

1_{Qt är ett ramverk som används för att skapa grafiska program} 9

10 Simuleringsmiljö - Översikt

Det finns för- och nackdelar med de båda alternativen. Det som väger över i Hopsans fördel är de snabba simuleringarna vilket lämpar sig för de realtids-tillämpningarna som finns i åtanke. Närheten till utvecklarna och möjlighet till support är ytterligare något som talar i stark favör för Hopsan.

3.1.1

Hopsan

Hopsan har ett flertal standard hydraulikkomponenter i sitt bibliotek samt objekt för att modellera mekaniska fenomen t.ex. roterande kroppar, fjädrar etc. Även om Hopsan är till stor del inriktad på hydraulikmodellering finns även bibliotek med elektronikkomponenter. Även om utbudet inte är i närheten av det hos Simulink finns ett flertal Signal-objekt för att skapa styrsignaler, återkopplingar och även mer avancerade reglersystem. Det finns även möjlighet att analysera modeller i frekvensplanet. Skärmdump av Hopsan kan beskådas i figur 3.1.

Figur 3.1: Skärmdump Hopsan, bild från www.iei.liu.se/flumes/system-simulation/hopsanng/

Det finns andra finesser i Hopsan som är värda att nämna. Den integrerade Pythonkonsolen är ett mycket kraftfullt verktyg då det öppnar för scriptade simu-leringar och modifikation av simuleringsparametrar mellan körningar. Ett exempel på vad som är möjligt är det tillhörande optimeringsfunktionen som genererar ett Pythonscript. Vid optimeringen ger man funktionen ett antal målvariabler samt strafffunktioner t.ex. översläng, minsta kvadrat avvikelse etc. Optimeringsfunktio-nen användes vid kalibrering av hydraulikmodellen i kapitel 4.

3.2 Simulink - CANoe 11

3.2

Simulink - CANoe

Figur 3.2: CANoe Simulink I/O-bibliotek

Hydraulikmodellen exporteras från Hopsan och importeras i Simulink som en s-funktion, se kapitel 7 för tillvägagångssätt. I Simulink blir de in och utgångar som specificerats i Hopsan tillgängliga. Eventuella sensorer som krävs modelleras i Simulink och signalerna mappas mot I/O-biblioteket som tillhandahålls av Vector CANoe, se figur 3.2. CANoe bygger upp ett nätverk av noder som kommunice-rar via CANbussen. Figur 3.4 visar det nätverk som CANoe simulekommunice-rar. Varje nod kan vara en fysisk enhet t.ex. gasreglage, joystick, MCU osv. Noderna kan även vara helt simulerade i form av en DLL från en Simulinkmodell, C/C++ kod eller CAPLscript. Det finns även möjlighet att skapa interaktiva GUIs för att kontrol-lera och visualisera simuleringen. Två principiella sätt som CANoe kan använda för att simulera system existerar, online eller offline.

Online

I onlineläget körs simuleringen i realtid helt fristående från Simulink. Simulink-modellen exporteras via Simulink Coder till en DLL som kan användas som en fristående simulerad nod i CANoe. Figur 3.3 och 3.4 visar hur Hopsanmodellen exporteras till Simulink som i sin tur exporteras till CANoe som en nätverksnod.

Offline

I offlineläget körs inte simuleringarna i realtid utan Simulink bestämmer simule-ringstakten. CANoe agerar slav till Simulink och CANtrafiken simuleras mellan de två programmen. Simulinmodellen behöver inte kompileras och exporteras till en DLL utan kan simuleras direkt. Figur 3.5 är en representation över hur CAN-trafiken simuleras mellan CANoe och Simulink.

12 Simuleringsmiljö - Översikt Hopsan: Hydraulikmodell Simulink: Sensorer Mappning av signaler Vector CANoe: CAN S-funktion DLL

Figur 3.3: CANoe Onlineläge - Importerad fristående DLL med hydraulik och simulinkmodell. CAN BUS 1 CAB BUS 2 CID GFU ICH MCU

Simulerad

Nod

Figur 3.4: CANoe - Simuleringsnätverk

Hopsan: Hydraulikmodell Simulink: Sensorer Mappning av signaler Vector CANoe: CAN S-funktion

CAN

Figur 3.5: CANoe Offlineläge - Simulering styrs via Simulink, hydraulikmodell importerad som s-funktion.

Kapitel 4

Hydraulikmodell

Den truck som modelleras är RRE250, pumptyp ”247453” och masttyp ”Nessie 2.5”. En grundläggande modell över utskjutning av masten skapas och utökas sedan med mer funktionalitet.

4.1

Grundläggande modell - Utskjut ”reach”

Figur 4.1: Schematisk skiss över hydrauliken som styr utskjutsfunktionen. Utskjutsfunktionaliteten är vital i trucken och innebär att masten rör sig ifrån gaffeltrucken för att lättare kunna nå pallar, se figur 4.2. Schematiskt är det he-la väldigt enkelt. En pump (250119-002) kopphe-lad till en 4/3 riktningsventilpaket följt av en cylinder. En förenklad schematisk skiss kan ses i figur 4.1, figuren visar inte de perifera hydraulikkomponenterna som existerar se figur 4.5 för en komplett överblick. Funktionen styrs av varvtalet hos pumpen samt ventilutstyr-ningen. Styrsystemet beräknar det flöde som krävs utifrån önskad hastighet och ställer in pumpen därefter, ventilen öppnas efter det önskade flödet.

4/3 ventilen är proportionell och behöver justeras för att släppa igenom rätt mängd hydraulvätska. Hydraulpumpen är anpassad efter leverantörens datab-lad. Hydraulpumpens deplacement är 19cm3_{/varv vilket ger ett flöde på 57}

li-ter/min vid 3000 rpm. Maximalt tillåten hastighet är 4000rpm vilket resulterar i ett maximalt tillåtet flöde på 76 liter/min. Cylindern har två olika areor vid

14 Hydraulikmodell

Reach

Lift

Figur 4.2: Utskjut, ”reach”, innebär att masten skjuts ut ifrån trucken.

de två in och ut portarna. Utifrån leverantörsritningar beräknades de två areor-na. Ventilblockets insignal enligt leverantörens datablad ligger mellan 300-900mA. Mätningar visar att den riktiga insignalen snarare ligger mellan ≈ 400mA −

900mA.F lödetsomskallpasseragenomventilpaketetskattasistyrsystemetutif rånettmedelvärdeavmätningarsomgjortspåventilpaketavleverantören.Dessavärdenharanväntsf örattanpassaventilpaketetiHopsan.F igur4.3visarhurinsignalentilldetvåsolenoidernapåverkarf lödetgenomventilen.Detärutif rånmätdatatif igur4.3somventilensparametrarärsatta.Denf ärdigamodellenkansesif igur4.4.Simulinkanvändsf örattmodelleradödbandetochanpassastyrsignalentillventilblocket.T abell4.1innehållerallparameterdatahosdeolikakomponenterna.

300 400 500 600 700 800 900 0 2 4 6 8 10 12 14 16 18 20

Control signal to valve [mA]

Flow liter/min

Proportional Valve Reach

Q6 − ReachIn Q7 − ReachOut

Figur 4.3: Ventilkaraktäristik som används av styrsystemet för att skatta flödet genom ventilpaketet för utskjut (reach), x-axeln motsvarar insignalen till solenoi-derna.

4.1 Grundläggande modell - Utskjut ”reach” 15

Pump 250119-002 Pressure relief valve

Parameter Värde Enhet Parameter Värde Enhet

ω 314 rad/s Pmax 150 00000 Pa

Dp 1.9E-5 m3/rev τ 0.01 s

Kc,p 0 m3/s/P kes,1 1E-8 m3/s/P

p 1 - qnom 0.1 m3/s

ph 500000 Pa

4/3 Directional Valve Cylinder

Parameter Värde Enhet Parameter Värde Enhet

Cq 0.512 - A1 7.0686E-4 m2

ρ 880 kg/m3 _{A2 4.9087E-4 m}2

d 0.0000145 m sl 1 m

fpa 0.64 - V1,2 0.003 m3

xv,max 1 - Bp 1000 Ns/m

xpa,pb,at,bt -1E-6 m Betae 1E9 Pa

ωh 1000 rad/s Cleak 0

-δh 78

-Tabell 4.1: Parameterdata för komponenterna relevanta för utskjutningsfunktio-nen.

16 Hydraulikmodell

4.2 Utökad modell - Fri och huvudlyft 17

Q3 Directional valve Laminar restrictor

Parameter Värde Enhet Parameter Värde Enhet

Cq 0.67 - Coefficient 2E-18 m3/N s

ρ 880 kg/m3 _{Turbulent orifice cyl}

d 1e-5 mP Parameter Värde Enhet

f 1 - Area 1.1E-14 m2

x 1 m Turbulent orifice low

ωh 150 rad/s Parameter Värde Enhet

δh 10 - Area 1.8E-14 m2

Q5 Directional valve Cylinder

Parameter Värde Enhet Parameter Värde Enhet

Cq 0.67 - A1 0.0014 m2

ρ 880 kg/m3 _{A2 0.0014 m}2

d 1.889E-5 m sl 4 m

f 1 - V1,2 0 m3

xv,max 1 - Bp 1000 Ns/m

x -1E-6 m Betae 1E9 Pa

ωh 150 rad/s Cleak 0

-δh 1

-Tabell 4.2: Parameterdata för komponenterna relevanta för huvud/fri-lyft.

4.2

Utökad modell - Fri och huvudlyft

I den utökade modellen införs fyra nya proportionella ventiler som styrs av fyra so-lenoider. Tre ytterligare cylindrar (en för frilyftet och två för huvudlyftet) har även tillkommit. En schematisk skiss över hydrauliken kan ses i figur 4.5. Lyftet sker genom att önskat flöde beräknas utifrån önskad hastighet och riktningsventilen öppnas därefter. Vid sänkning av stativet stängs tillflödesventilen och sänkhastig-heten styrs endast av utflödesventilen. Systemet växlar mellan att vara pump och ventilstyrt till att enbart förlita sig på ventilstyrning.

Cylindrarna modelleras efter ritningar (areor, slaglängd etc) som har tillhan-dahållits av BT Products. Ventilerna anpassas efter mätningar som leverantören har gjort, se figur 4.6 och 4.7. I övrigt är tillvägagångssättet samma som för den ti-digare utskjutsmodellen. Parametervärden för komponenter relaterade till frilyftet finns i tabell 4.2

18 Hydraulikmodell

Q2 Directional valve Q4 Directional valve

Parameter Värde Enhet Parameter Värde Enhet

Cq 0.67 - Cq 1 -ρ 880 kg/m3 _{ρ 880 kg/m}3 d 0.0576 mP d 1e-8 m f 1 - f 1 -xmax 1 m xmax 1 m ωh 100 rad/s ωh 50 rad/s δh 25 - δh 10 -Cylinder

Parameter Värde Enhet

A1 0.0008 m2 A2 0.0008 m2 sl 4 m V1,2 0 m3 Bp 1000 Ns/m Betae 1E9 Pa Cleak 0

4.2 Utökad modell - Fri och huvudlyft 19

Pos i on Tra ns duce r_2 xFri

Fre e _Fl ow C-type Pi s ton_1

Fre e _Pre s s ure Tra ns l a ona l Ma s s

Force Source _1 fri Force

Los s l e s s Q-type Conne ctor_2

Fl ow Ra te Tra ns duce r_2

Pre s s ure Tra ns duce r_2 Hydra ul i c Vol ume Mul Port_5

La mi na r Ori fice fri LOW 2/2 Di re c ona l Va l ve _1

ori fice _cyl Turbul e nt Ori fice

l a m_re s Los s l e s s Tra ns mi s s i on Li ne _1

q5 Ta nk_2 Pos i on Tra ns duce r_3

2/2 Di re c ona l Va l ve _4 xMa i n2 q2 2/2 Di re c ona l Va l ve _3 fri ON/OFF q3 ma i n Force 2 Ma i n_l i Force Source _2 Ta nk_3

Hydra ul i c Vol ume Mul Port_4

Los s l e s s Tra ns mi s s i on Li ne Ta nk_4 Ma i n_l i 2 ma i n Force 1 Force Source _3 2/2 Di re c ona l Va l ve _2 ma i n ON/OFF ma i n LOW

Turbul e nt Ori fice _1 q4

ori fice _fre e _out Ta nk

Ta nk_1 Pos i on Tra ns duce r_4

xMa i n1

Hydra ul i c Vol ume Mul Port_1

Ta nk_5

Figur 4.5: Hopsanmodell över huvud och frilyftet. Utskjutningsmodellen syns ej här

20 Hydraulikmodell 200 300 400 500 600 700 800 900 0 10 20 30 40 50 60 70 80 90

Control signal to valve [mA]

Flow liter/min

Proportional Valve Main

Q2 − MainLift Q4 − MainLower

Figur 4.6: Ventilkaraktäristik - Huvudlyft, Solenoid Q2 och Q4, x-axeln motsvarar insignalen till solenoiderna

200 300 400 500 600 700 800 900 0 10 20 30 40 50 60 70 80 90

Control signal to valve [mA]

Flow liter/min

Proportional Valve Free

Q3 − FreeLift Q5 − FreeLower

Figur 4.7: Ventilkaraktäristik - Frilyft, Solenoid Q3 och Q5, x-axeln motsvarar insignalen till solenoiderna

4.3 Mätresultat, kalibrering och validering 21

4.3

Mätresultat, kalibrering och validering

För att undersöka hur väl modellen stämmer överens med verkligheten genomför-des mätningar på en RREtruck. Trucken utrustagenomför-des med två trycksensorer och en flödesmätare. Modifierad programkod användes för att läsa av information från CANbussen som annars ej är tillgänglig. Tabell 4.4 visar datat som samlades in under experimentet.

Externa sensorer

Pumptryck

Cylindertryck frilyft Flöde genom ventilen

CAN

Önskad pumphastighet Aktuell pumphastighet Styrsignal ventil Q3 (sänk) Styrsignal ventil Q5 (lyft) Höjd frilyft

Tabell 4.4: Mätdata till valideringsexperiment

Pågrund av bristande takhöjd var det omöjligt att utföra huvudlyftet. Ut-skjutsfunktionen gick ej heller att mäta då ventilblocket som modifierades med sensorer är placerat så att den endast blir synlig och tillgänglig för modifikation när masten har skjutits ut. Således kan modellen endast valideras för frilyftet.

22 Hydraulikmodell

4.3.1

Innan kalibrering

Eftersom systemet är pumpstyrt vid lyftrörelsen och ventilerna sedan tidigare an-passats efter leverantörsdata stämmer redan hastighetsprofilen när gaffelpaketet höjs. Sänkningen av gaffelpaketet är ventilstyrt och beror på tryckdifferensen över sänkningsventilen. Sänkningsventilen leder i modellen direkt ut till tank (atmo-sfärstryck) vilket resulterar i för hög sänkhastighet. Figur 4.8 visar hur positionen hos gaffelpaketet ser ut vid ett körfall hos den okalibrerade modellen.

0 10 20 30 40 50 60 70 0 500 1000 1500 2000 2500 3000 3500 Time [s] Height [mm] Position measured Position simulated

Figur 4.8: Ursprunglig modell, positionen stämmer överens när gaffelpaketet lyfts. Sänkningen beror på tryckdifferensen över sänkningsventilen och ger upphov till att sänkrörelsen börjar för tidigt.

Figur 4.9 visar hur pumptrycket och cylindertrycket varierar för den okalibre-rade modellen. Tydligt är att det finns en statisk förskjutning hos alla trycknivåer samt att tryckfallet över höjningsventilen är felaktigt. Pumptrycket sjunker även till atmosfärstryck när pumpvarvtalet går mot noll detta har modellerats med en ventil som endast öppnar sig när insignalen till pumpen är ≈ 0.

0 10 20 30 40 50 60 0 5 10 15 20 25 30 35 40 45 Time [s] Pressure [bar] Cylinder measured Pump measured Pump simulated Cylinder simulated

Figur 4.9: Ursprunglig modell, trycknivåer och tryckdifferensen mellan cylinder-tryck och pumpcylinder-tryck är fel.

4.3 Mätresultat, kalibrering och validering 23

4.3.2

Kalibrering

Det statiska tryckfelet åtgärdades genom att höja lastkraften och justera friktionen som uppstår i cylindern. Tryckfallen över ventilerna justerades genom att införa strypningar efter ventilerna. Dessa strypningar existerar i ett riktigt system i form av slangförluster och andra imperfektioner i konstruktionen. Ett lyft genomfördes med noll i last (ingen extra last på gafflarna) resultatet kan beskådas i figur 4.10 och figur 4.11.

0kg last

Figur 4.10 visar en tämligen välfungerande modell som fångar den primära dyna-miken. Vid t = 20s sjunker gaffelpaketet snabbare i den simulerade modellen än vid mätningarna. Insignalen till ventilen är vid det tillfället väldigt nära dödbandet och förändringar av dödbandet ger stort utslag vid högre insignalsnivåer. Det figur 4.10 visar är en avvägning för att få den bästa anpassningen i hela arbetsområdet för ventilen. Figur 4.11 visar att modellen fångar stora delar av karaktäristiken, t.ex. tryckspiken vid t = 18s.

0 10 20 30 40 50 60 70 0 500 1000 1500 2000 2500 3000 3500 Time [s] Height [mm] Measured Simulated

Figur 4.10: Kalibrerad modell: Sänkhastigheten har anpassats genom att införa en strypning efter sänkventilen.

0 10 20 30 40 50 60 0 10 20 30 40 50 Pressure [bar] Time [s] Cylinder measured Pump measured Pump simulated Cylinder Simulated

Figur 4.11: Kalibrerad modell: En strypning efter lyftventilen används för att an-passa tryckfallet.

24 Hydraulikmodell

500kg last

För att undersöka hur modellen hanterar last utfördes ett lyft med 500kg. Figur 4.12 och 4.13 visar resultatet från lyftet. Det är lätt att konstatera genom att studera figur 4.13 att trycknivåerna överlag stämmer. Det är även lätt att konsta-tera att något är fel i figur 4.12. När lasten sänks vid t = 15s är sänkhastigheten helt olik den uppmätta. Sänkningen av lasten vid t = 50s har samma utseende som det uppmätta om än något förskjuten. För att undersöka fenomenet närmare genomfördes experimentet ytterligare en gång med en ny truck. Figur 4.14 visar resultatet från experimentet. Insignalen till sänkventilen ligger på en nivå så att gaffelpaketet precis rör sig. Ett rimligt antagande är att dödbandet är felkalibrerat. Genom att höja dödbandet till ventilen erhålls beteendet i figur 4.15. Föränd-ringar i temperatur kan vara en orsak till förändringen i dödbandet. Även det ökade trycket som följer av ökad last kan vara en starkt bidragande orsak. Tryckökning-en resulterar i att dTryckökning-en statiska friktionTryckökning-en som måste övervinnas när solTryckökning-enoidTryckökning-en ska öppna ventilen ökar. Vid närmare studier av insignalen till ventilen blir det tydligt att det som skiljer sänkningen vid t = 15s och t = 50s är den senare ligger på en högre nivå och således inte blir lika påverkad av det förhöjda dödbandet. Styrförmågan i trucken vid låga styrsignaler till ventilen blir kraftigt begränsad när trucken är lastad. 0 10 20 30 40 50 60 70 0 500 1000 1500 2000 2500 3000 Time [s] Height [mm] Measured Simulated

Figur 4.12: Kalibrerad modell: 500kg last, den felaktiga sänkhastigheten vid 20s beror på ökat dödband i ventilen. Truck nr1

0 10 20 30 40 50 60 0 10 20 30 40 50 60 70 80 90 Time [s] Pressure [bar] Cylinder measured Pump measured Pump simulated Cylinder simulated

4.3 Mätresultat, kalibrering och validering 25 0 5 10 15 20 25 30 35 40 45 50 0 500 1000 1500 2000 2500 3000 3500 Time [s] Height [mm] Position measured Position simulated Valvesignal

Figur 4.14: Position och insignal till ventil. Uppmätt på en annan truck för att undersöka hurvida det förändrade dödbandet var en engångsföreteelse. Insignalen till ventilen har ej korrekt skala i figuren.

0 10 20 30 40 50 60 70 −500 0 500 1000 1500 2000 2500 3000 Time [s] Height [mm] Measured Simulated

Kapitel 5

Simulink gränssnitt

MATLAB/Simulink används för att skapa ett gränssnitt mot styrsystemet genom att simulera de sensorer och mätdata som styrsystemet utnyttjar. Nedan följer en beskrivning av alla de signaler som modelleras i Simulink. Vissa signaler är snar-lika varandra där endast konstanter skiljer dem åt, dessa kommer inte redovisas separat.

5.1

Positionssensor

Höjden på stativet och positionen av gaffelpaketet mäts via två sorters enkodrar. En linjär linjal mäter utskjutningen av gaffelpaketet. Sensorer sveper över linjalen och pulserar enligt figur 5.1b. Signalerna följer mönstret

00 01 11 10

när gaffelpaketet skjuts utåt. Mjukvaran utnyttjar mönstret hos signalen för att ad-dera respektive subtrahera pulser vid positionsberäkningen. Höjdmätningen sköts av en cirkulär enkoder likt den i figur 5.1a. I mjukvaran modelleras även den fixe-rade linjalen som en cirkulär enkoder för att kunna utnyttja samma algoritmer för

θs ω (a) Enkoder B(θ) A(θ) θ θ θs θp (b) Pulssekvens positionsenkoder Figur 5.1: Positionsenkoder 27

28 Simulink gränssnitt Pulse_2 2 Pulse_1 1 Theta_s Pulses / Revolution Theta_s Pulses / Revolution 100 Pulses Radian Theta_s Pulse_1 Pulse_2 EncoderWheel Meter Circumference [m] Radians Circumference [m] 1.2 Meter 1

Figur 5.2: Enkoder - Pulses blocket innehåller implementationen av ekvation (5.3) och (5.4).

positionsberäkningen. En Simulinkmodell över den cirkulära enkodern modelleras med antalet pulser per varv som variabel för att justera avståndet mellan pulserna.

θs=

2π

pulses/revolution[rad] (5.1)

θs, ekvation (5.1) motsvarar rotationsvinkeln som krävs för att en puls skall

genereras. Enkodern skickar pulser i cykler enligt figur 5.1b; det går fyra pulser per cykel. Ekvation (5.3), (5.4) och ekvation (5.2) visar teorin bakom modelleringen av enkodern. Den resulterande Simulinkmodellen kan beskådas i figur 5.2.

θp= 4θs (5.2) A(θ) = ( 1 if 0 < modθp(θ − θs) < θp 2 0 if θp 2 < modθp(θ − θs) < θp (5.3) B(θ) = ( 1 if 0 < modθp(θ) < θp 2 0 if θp 2 < modθp(θ) < θp (5.4)

Fri / Huvudlyft Höjdsensorer

Utöver positionssensorn finns även signaler som aktiveras när gaffelpaketet närmar sig botten samt när den närmar sig toppen hos frilyftet. Alla dessa signaler modelle-ras på samma principiella sätt med den enda skillnaden i vilka nivåer som signalen skall triggas på. Tabell 5.1 visar på vilka sensorer som finns i de två olika graderna av utrustning på trucken, basic sensor solution samt full sensor solution. Figur 5.3 visar en av dessa sensorer. När gaffelpaketet ligger mellan 0 < x < 400mm sätts signalen till 1.

5.2 Styrsignaler - Ventiler 29

Above 0mm

Under 400mm

CAN = 1 if AND == TRUE

Mast_near_lower 1 TempVar3 1 TempVar2 0 TempVar1 0 TempVar 1 Switch2 >= Switch >= 0 Logical Operator AND Height 1

Figur 5.3: Signaler för höjdsensorerna i fri och huvudlyftet.

Basic sensors Position [mm] Mast split sensor Binär sensor Forks near top sensor x < 400 from free lift top

Mast near lower position sensor 0 < x < 400 Full sensor solution Position [mm]

Mast split sensor Binär sensor Free lift reference sensor 0 < x < 800 Lift height encoders Se kap. 5.1

Tabell 5.1: Sensorer vid olika utrustningsnivåer, x representerar position och mäts i [mm]

5.2

Styrsignaler - Ventiler

Alla ventiler styrs av solenoider med en insignal mellan 0-1 A. Solenoider betecknas

Q[1 . . . ∞]. Ventilerna som styr huvud och frilyftet har endast en solenoid som

verkar. Övriga funktioner t.ex. reach, cabin-tilt, sideshift etc har två solenoider som verkar från två håll för att öppna respektive stänga ventilen. Hopsan har inte ventiler med två solenoider utan använder positiva respektive negativa insignaler för att åstadkomma samma sak. I Simulink skalas alla signaler efter mätdata för att ge korrekt flöde i Hopsanmodellen. Figur 5.4 visar konverteringen med dödzon samt erforderlig skalfaktor. Switchblocket används endast för att välja mellan de två insignalerna till Hopsanmodellen. Mjukvaran ska i teorin aldrig ställa ut signaler till Q6 och Q7 samtidigt, om det mot förmodan skulle ske är det lätt att detektera genom att använda ett logiskt AND på Q6 och Q7. Värdet kan sedan skickas som en Environmentsignal till CANoe.

30 Simulink gränssnitt valveSignal 1 q6/q7 switch > 0 ScaleFactor1 −1.8182 ScaleFactor 1.8182 Dead Zone1 Dead Zone q7 2 q6 1

Figur 5.4: Simulinkmodell för översättning från Q6/Q7

5.3

Trycksensor

En trycksensor i trucken används för att skatta vikten hos lasten på gafflarna. Sensorn registrerar 500mV vid 0 bar och 4500mV vid 250 bar. Figur 5.5 visar dess linjära beteende. 500 2500 4500 mV mV 125 250 0 bar

Figur 5.5: Analog tryckmätare

5.4

Prestanda

Eftersom målet är att kunna använda modellen i realtids applikationer är det intressant att undersöka vilken prestanda modellerna har. Hopsan kan tack vare utnyttjandet av TLM simulera komplexa hydrauliksystem väldigt snabbt[3]. När en Hopsanmodell exporteras till en s-funktion skickas lösaren med i exporten. Viss overhead är ändå att vänta då Simulink vid varje tidssteg ber Hopsan-s-funktionen att simulera sig själv. Ett experiment genomfördes där modellen simulerades i Hopsan för att sedan jämföras med samma modell exporterad till Simulink.

En modell av de delar i trucken specifika för reach användes och simulerades åtta gånger i Hopsan och ett medelvärde av simuleringen användes. Modellen

ex-5.4 Prestanda 31

Tabell 5.2: Hårdvara och mjukvara Intel Pentium 4 3.4GHz 2.0 GiB RAM

Microsoft Windows XP SP3 Matlab R2011b

Hopsan 0.5.4

porterades sedan till en s-funktion och importerades i Matlab/Simulink. Modellen simulerades sedan och tiden mättes genom tic,sim(’modell.mdl’),toc. Sampeltid 0.001s och simuleringstid var i båda fallen 10s.

Avg [s] Hopsan 0.062 0.062 0.062 0.079 0.078 0.063 0.062 0.069 0.0668 Simulink 0.689 0.751 0.720 0.757 0.733 0.746 0.722 0.716 0.729

Tabell 5.3: Simuleringstid, Hopsan och Simulink med s-funktion

Simuleringstiden ökar i det här fallet med en faktor 11 vilket är en klar för-sämring av prestandan. Trots förför-sämringen är det mer än tillräckligt för att si-muleringar i realtid skall vara möjligt. Det är värt att poängtera att det inte är möjligt att av detta exempel dra slutsatser om den exakta overheaden vid export till simulink då det statistiska underlaget är för litet.

Kapitel 6

HIL - Hardware In the Loop

HILriggen som kommer användas är VT Systems CANoe tillverkad av det tyska företaget Vector. Systemet är baserat kring en ordinär PC som använder Windows CE som operativsystem. Till skillnad från vanliga versioner av Windows så är Windows CE ett realtidsoperativ. Realtid innebär att det inte bara är korrektheten i beräkningen som är intressant utan även att de är klara i tid. En vanlig dator är väldigt snabb på att räkna men kan ej garantera att data skickas ut i rätt tid. Realtid är alltså inte nödvändigtvis hastighet och beräkningskraft utan snarare om förutsägbarhet i när data är redo för leverans.

HIL

Main Control Unit - MCU

I/O

Reach

Lift

Figur 6.1: Hardware in the loop CANoe används för att simulera

de bussar och kringutrustning som finns i en komplett truck. För att styrsystemen ska erhålla verklighets-troget stimuli kopplas hydraulik och omvärldsmodellen till CANoe via ett interface-bibliotek med I/O-block. Sig-nalerna mappas även mot en CAN-databas för att ge ett så verklighets-troget intryck som möjligt. Figur 6.2 visar hur man enkelt mappar signa-ler och variabsigna-ler från CAN-databasen i CANoe till I/O-block i Simulink.

CANoe kan användas på två

pri-mära sätt, offline och online (HIL). I offlineläget styrs simuleringen från MAT-LAB/Simulink, CANoe agerar slav och alla debugverktyg i MATLAB/Simulink kan användas. Offlineläget används med fördel tidigt i utvecklingen då Simulink-modellen inte behöver kompileras efter varje ändring. I onlineläget (hardware-in-the-loop) kan riktig hårdvara kopplas till nätverket. Simuleringarna körs i realtid och Simulinkmodellen måste kompileras till en dll som laddas in i CANoe. När den av Simulink Coder framtagna dll-filen är inladdad kan alla parametrar och

34 HIL - Hardware In the Loop

Figur 6.2: Mappning av Environmentsignaler i Simulink

signaler loggas och ändras genom CANoe.

Figur 6.3: CANoe - Nätverksnoder

Figur 6.3 är en skärmdump från Vector CANoe. CANnätverket skapas auto-matiskt när projektet associeras med en CANdatabas. CANdatabasen innehåller information om alla CANmeddelanden som existerar i trucken. Databasen kan lätt modifieras med nya signaler och meddelanden för att hantera behovet av signaler till t.ex. debug-funktioner.

CANdatabasen modifierades med ett antal extra Environmentvariabler att an-vända för styrning av Simulinkmodellen i brist på en MCU. En kontrollpanel skapa-des i CANoe Panel Designer för enkel styrning och visualisering av simuleringen, se

6.1 SIL - Software In the Loop 35

Figur 6.4: Kontrollpanel till CANoe

figur 6.4. Kontrollpanelen ger användaren möjlighet att manuellt styra pumpvarv-tal och ventilutstyrning till ventiler ansvariga för utskjut, huvud och fri-lyft/sänk. Positionen visualiserades i en enkel stapelgraf och LED-lampor representerade de övriga höjdsensorerna.

6.1

SIL - Software In the Loop

Modellen är tänk att användas i en HILuppställning där en fysisk MCU är in-kopplad. De digitala I/O-portarna samt CAN-trafiken med hydraulikmodellen sker via I/O-bibliotek som tillhandahålls av Vector CANoe. Ytterligare en intressant tillämpning är en SIL (software-in-the-loop) där även MCUn är simulerad. Det finns ett flertal sätt som detta kan ske på, varav två kommer tas upp här, CAPL och S-funktion.

6.1.1

CAPL

CAPL (CAN Access Programming Language)1 _{är ett C-liknande språk som}

an-vänds av Vector CANoe för att programmera beteendet hos nätverksnoder. Det är specifikt utvecklat för att hantera CAN-trafik och då speciellt i Vectors program-varusviter. CAPL är ett händelsebaserat (event based) språk som kan utnyttjas för att reagera vid knapptryckningar eller förändringar i signaler. Detta gör det möjligt emulera beteendet hos noder som inte är fysiskt inkopplade till HILriggen.

36 HIL - Hardware In the Loop

Teoretiskt kan all funktionalitet och beteende hos MCUn implementeras direkt i CAPL. Detta är tidsödande och ger inga garantier att produktionskoden hanterar situationer som uppkommer på samma sätt. Därför är det önskvärt att med så små modifikationer av produktionskoden som möjligt få den att interagera med övriga nätverket.

Utifrån produktionskoden kan man skapa en DLL (Dynamic-link library). DLL i sig är inte synlig för CAPL utan ett specifikt exportlager måste skrivas. CAPL använder en egen syntax för hur exportfunktionerna skall se ut, se listing 1.[7]

Name Address return datatyp argc Param datatype Paramdepth CAPL_DLL_INFO CAPL_DLL_INFO_LIST[] = {

{"Dec2Hex", (CAPL_FARCALL)appDecToHex, ’V’, 2, "LC", "\x0\x1"}, {0,0}

};

Listing 1: CAPL DLL-export funktion

Detta måste upprepas för alla funktioner i DLLen som skall vara synliga för resten av nätverket. Den färdiga DLLen länkas sedan till projektet via en GUI-meny. Figur 6.5 visar hur funktionsanropen skickas genom ett exportlager för att slutligen nå funktionerna som finns i truckmjukvaran. För att det överhuvudtaget skall vara möjligt att skapa en DLL av koden måste ett HAL för den simulerade miljön skapas.

CAPL FUNCTIONS CALL CAPL EXPORT LAYER

DLL

hydraul() reach() sensor() start() lift() stop()

Figur 6.5: När ett anrop sker via CAPL i CANoe till mjukvarubiblioteket krävs ett exportlager

Example 6.1.1. HAL (hardware abstraction layer) är ett mellanliggande lager

som separerar hårdvaran från högnivå koden. Istället för att använda adressen till porten som styr PWMsignalen till en ventil abstraherar vi adressen och ger den ett

6.1 SIL - Software In the Loop 37

mänskligt läsbart namn. Även funktioner för att läsa och skriva till minnesplatser, digitala portar etc innefattas i ett HAL.

#define PWM_VALVE_CHANNEL 24

Mjukvaran i en truck har ett sådant HAL för alla de in och utgångar och andra plattforms beroende egenskaper som det är önskvärt att abstrahera.

Exekveringstid

I en riktig truck exekveras huvudloopen var 20ms, andra rutiner exekveras mer frekvent t.ex. de funktioner som ansvarar för insamlandet av data från interrupt-funktionerna. Dessa olika exekveringstider måste lösas vid en implementation av SIL. I CAPL är det möjligt att använda ”timers” för att styra exekveringen av olika rutiner.

Hantering av interruptfunktioner

A(θ)

θ

Change Detection Trigger Trigger Trigger Trigger

CAPL HANDLER

caplfunction() {

sensorinterrupt();

}

Figur 6.6: A(θ) representerar pulser från en av sensorerna. Change Detection rea-gerar vid varje flank och triggar CAPL HANDLER blocket. För varje gång CAPL HANDLER triggas sker ett funktionsanrop till CAPL-scriptet som i sin tur anro-par DLLen som innehåller mjukvaran i trucken.

IRQ (interrupt request) är en signal som skickas till mikroprocessorn för att avbryta pågående bearbetning av data. Sensorerna i RRE trucken är kopplade till interruptportar hos MCUn. Dessa portar är kopplade till funktioner som hanterar t.ex. positionsberäkningen av gaffelpaketet. Interruptfunktionerna skall triggas vid

38 HIL - Hardware In the Loop

varje flank hos utsignalen från positionssensorn. Detta måste lösas i modellen då inga fysiska portar existerar i en simuleradmiljö. En möjlig lösning till detta pro-blem är att utnyttja Change Detection blocket i Simulink, Change Detection har som utsignal ett Boolsk TRUE/FALSE vilket kan användas som en trigger-signal till ett CAPL Handler block. När CAPL Handler triggas skickas ett funktionsanrop till en CAPL funktion, den CAPL funktionen används för att kalla på sensorinterruptfunktionen, se figur 6.6 och 6.7.

Theta_s Pulses / RevolutionTheta_s Saturation Ramp Pulses / Revolution 100 Pulses Radian Theta_s Pulse_1 Pulse_2 EncoderWheel Meter Circumference [m] Radians Detect Change1 U ~= U/z Detect Change U ~= U/z Circumference [m] 1.2 CAPL_Handler_Sensor_B_Interrupt sensor_b_interrupt CANoe CAPL_Handler_Sensor_A_Interrupt sensor_a_interrupt CANoe

Figur 6.7: CAPL Handler och Detect Change i Simulink för att anropa interrupt-funktioner

6.1.2

S-funktion

Introduktions till S-funktioner

S-funktioner används för att kapsla in C/C++/Fortran-kod och skapa ett gräns-snit mot Simulink. En s-funktion består av två huvudsakliga delar, en initialise-ring och en beräknande del. Initialiseinitialise-ringen innebär att dimensionerna hos in och utgångarna definieras och s-funktioner fungerar på liknande sätt som C/C++, mdlOutputs() är jämförbar med main() och all extern kod måste synliggöras ge-nom att inkludera deras headerfiler. Koden kompileras sedan med mex komman-dot.

#mex sfunktion.c externCfile.c secondCfile.c

Scope Reach_Prod_Code

goldMEX HydReachCmd

3

6.1 SIL - Software In the Loop 39

S-funktionen hanteras i Simulink precis på samma sätt som övriga blockkompo-nenter, figur 6.8. Det finns mer att läsa om s-funktioner som inte tas upp i denna rapport, den intresserade läsaren hänvisas till Mathworks hemsida2.

Implementation av reach()

Den primära funktionen som hanterar reachfunktionen är reach(). reach() kallas på av hydraul() som hanterar alla hydraulikfunktioner i trucken. Ett försök att skapa en fristående modul av de filer och är relaterade till reachfunktionen resulterade i ett beroende av 15 källkodsfiler. Ett flertal kalibreringsvariabler var fortfarande tvunget att manuellt defineras, även funktioner relaterade till t.ex. digital I/O, PWM och förarparametrar definierades som funktioner som endast returnerar vo-id alternativt standardvärden. Produktionskoden är en affärshemlighet och kan således ej bifogas, en exempelfunktion kan däremot beskådas i listing 2.

Bool gw_loggedOn(void) { // Check if user is logged on

return TRUE; }

Listing 2: Exempelfunktion, funktionen används för att kontrollera att användaren har loggat in korrekt.

S-funktionen används sedan precis som vanligt. In och utsignaler specificeras i mdlOutputs, initiering av parameterdata sker i mdlStart. mdlStart exekveras endast en gång, mdlOutputs är den funktion som körs varje programloop. Den resulterande s-funktionen kan utifrån insignal ställa ut korrekt pumpvarvtal, ven-tilstyrningen implementerades aldrig pågrund av tidsbrist. I listing 3 följer ett exempel på hur mdlOutputs kan se ut för reachfunktionen.

40 HIL - Hardware In the Loop

static void mdlOutputs(SimStruct *S, int_T tid) {

SByte In1; // Joystick Input UByte Cc;

SWord Flow; UWord Rpm;

int_T i;

InputType uPtrs = ssGetInputPortRealSignalPtrs(S,0); real_T *y = ssGetOutputPortRealSignal(S,0); real_T *y1 = ssGetOutputPortRealSignal(S,1); real_T *y2 = ssGetOutputPortRealSignal(S,2); int_T width = ssGetOutputPortWidth(S,0);

In1 = *uPtrs[0]; // Avoid ptr as function parameter setHydReachCmd(In1);// Hydraulic reach command

updateReach(); // Update sensorinformation

reach(); // Main reach function

pump(); // Main pump function Flow = getReachPumpFlowRequest();

Cc = 19; // Pump displacement // Calculate motor RPM for the requested flow Rpm = (UWord)(((ULong)Flow * 10) / Cc); /*---*/ /* Output signals /*---*/ *y = Rpm; // Output Rpm to hydraulicmodell *y1 = getParamData(TRUCK_TYPE); *y2 = getPWM(VALVE_Q7}; }

Kapitel 7

Användarhandledning

7.1

Hopsan

Hopsan kan hämtas från www.iei.liu.se/flumes/system-simulation/hopsanng?l=en.

7.1.1

Exportera Hopsan till s-funktion

KRAV:

Visual Studio 2010 ( Express Edition fungerar) Hopsan > 0.5.3

Tidigare versioner av Hopsan stödjer endast Visual Studio 2008 vilket blir ett problem då Vector CANoe samt senare versioner av Matlab endast stödjer Visual Studio 2010.

• Öppna modellen ni vill exportera.

• Byt ut insignalerna och eventuella scopes mot Input Interface och Output

Interface

• Välj menyvalet Export -> Simulink S-function, figur 7.1. Det skapas nu ett antal filer i mappen modellen exporterades till: . .. HopsanCore.dll HopsanCore.exp HopsanCore.lib HopsanSimulink.cpp HopsanSimulinkCompile.m HopsanSimulinkPortLabels.m externalLibs.txt include/ reach.hmf 41

42 Användarhandledning

• Välj Visual Studio 2010 som kompilator i mex -setup i Matlab. • Kör HopsanSimulinkCompile.m.

• Använd namnet hos den genererade .mex32-filen i ett s-funktionsblock.

Figur 7.1: Exportera modell till s-funktion

7.1.2

Hopsan och Python

Hopsan stödjer även Python vilket gör det enkelt att skriva script som simulerar och ändrar parametrar. Nedan följer ett enkelt exempel på vad som är möjligt, scriptet öppnar och kör en modell för att spara ned flödet genom en ventil till en komma-separerad textfil. Figur 7.2 visar Pythonkonsolen ser ut, det är möjligt att skriva kommandon direkt i prompten eller ange en .py-fil.

Figur 7.2: Hopsan Pythonkonsol

import os

log_file = open(’C:\\logfile.txt’,’w’) hopsan.closeAllModels()

hopsan.loadModel("C:/valve.hmf") hopsan.simulate()

Flow = hopsan.component("q3").port("PA").getDataVector("Flow") log_file.write("%s \n" %(Flow,))

7.2 Simulink till .dll via Simulink Coder 43

7.1.3

Felsökning

OBS! Om ni använder en äldre version av Hopsan kan det vara nödvändigt att

ta bort följande rad i HopsanSimulink.cpp innan det går att köra HopsanSimu-linkCompile.m.

mexCallMatlab(0,0,0,0); // Remove this line

OBS! Om ni har exporterat en modell med en äldre version än Visual Studio

2010 kommer det uppstå felmeddelanden. Det är då nödvändigt att ta bort alla filer som Hopsan exporterat innan det är möjligt att exportera på nytt med en senare version av Visual Studio.

. .. include/ HopsanCore.dll HopsanCore.exp HopsanCore.lib

7.2

Simulink till .dll via Simulink Coder

För att få tillgång till CANoe I/O-bibliotek i Simulink är det nödvändigt att installera Vector CANoe Matlab Interface:

C:\Documents and Settings\All Users\Documents\... Vector\CANoe\7.6\CANoe Demos\Demo_Addon\Matlab

Environment, Signal och Message blocken används för att skicka data mellan no-derna i CANoe. Dessa mappas mot en environmentsignal eller message-variabel från CANdatabasen som är aktiv i CANoe.

Om simuleringen skall ske offline med Simulink som master och CANoe som slav måste följande block vara närvarande i modellen. Blocket påverkar inte om modellen exporteras med Simulink Coder.

Simulation step Synchronized / Offline

Under Simulation Parameters ( Ctrl + E ) måste följande parametrar ändras:

SOLVER

Stop time Inf

Solver options, Type Fixed-step

Code Generation

System target file: cn.tlc

För att parametrisering av Simulinkmodellen skall vara möjlig via CANoe mås-te följande parametrar ändras:

Tools -> Code Generation -> Build Model, bygger modellen. Den resulterande dll-filen kan nu importeras i CANoe.

44 Användarhandledning

Code Generation

Interface: C-API

signals parameters

CN code generation Export CAPL Functions

Enable Parametrization from CANoe Enable Simulink Signal Analysis

7.2.1

Felsökning

Om Enable Parametrization from CANoe är aktivt kan följande felmeddelande uppstå:

Generating Code ... ### Linking ...

Creating library Release/modellnamn.lib and object Release/modellnamn.exp *** Created nodelayer module modellnamn.dll

Creating parameter files ...

Error: Cannot load library ’Release/modellnamn.dll’. Creation of parameter files failed.

Lösning: Ta bort slprj/ och modellnamn_cn_rtw.Fungerar inte detta kan den resulterande .dll filen fortfarande användas. Det som misslyckas är skapandet av parametriseringspaneler i CANoe, något som är enkelt att skapa själv då det genereras systemvariabler för alla parametrar när dll-filen läggs till i CANoe.

7.3

Importera Simulink-dll till CANoe

För att kunna köra simuleringar måste självklart en CANdatabas finnas tillgänglig, de övriga noderna konfigurerade korrekt osv. Den här användarhandlingen kommer inte ta upp dessa aspekter då det finns fullgod dokumentation[5] tillgänglig från Vector. Endast de specifika detaljerna som krävs för att importera en dll skapad av Simulink Coder beaktas.

För att köra simuleringar utan Simulink måste en ny nätverksnod skapas och associeras med en dll-fil.

• Nätverksnoden skapas genom att högerklicka i nod-listan och välja Insert

Network Node.

• Högerklicka på noden och välj Properties

• Under fliken Simulink, lägg till Simulinkmodellen (.mdl, den genererade bitmappen av modellen (.ini) samt RealTime-Workshop (Simulink Coder) dll-filen, se figur 7.3.

7.3 Importera Simulink-dll till CANoe 45

Kapitel 8

Diskussion

Arbetet har till stor del varit utforskande i sin natur då det ej fanns möjlighet att implementera en riktig hardware-in-the-loop miljö. Den modell som tagits fram i Hopsan och kopplats samman med sensorgränssnittet i Simulink bör ge en god grund för en framtida fysisk HIL-miljö.

Hydraulikmodellen är till stor del baserad på mätningar som leverantören av komponenterna tillhandahållit. Frilyftet validerades mot en riktig truck och ka-librerades för att få korrekta trycknivåer. Utskjut och huvudlyftet har ej kunnat valideras och trycknivåerna är garanterat felaktiga. Position och hastighet bör däremot stämma bättre då arean hos cylindrarna är kända från ritningar.

Både hydraulikmodellen i Hopsan och det överliggande gränssnittet i Simulink är enkla att förändra vid tillkomst av nya hydrauliksystem, nya sensorer och andra ändringar av designen. Hopsan har visat sig vara ett väldigt lättarbetat program. De korta simuleringstiderna i samband med de inbyggda funktionerna för bland annat känslighetsanalys bjuder in till experimenterande då resultaten av ändringar visar sig direkt.

Efterforskningarna kring möjligheten till software-in-the-loop har resulterat i ett antal insikter. Den första är att det är möjligt med SIL både i form av en dll med ett CAPL exportlager, samt i form av en s-funktion för simulering i Mat-lab/Simulink. Det finns dock ett aber med SIL i praktiken; för att få en funktion t.ex. reach() att fungera krävs flera delar av koden, förarparametrar, EEPROM, CAN, kalibrering, sensorinformation etc. EEPROM måste emuleras, kalibreringen använder sensorer som i sin tur förlitar sig på interruptstyrda funktioner osv. Man ställs inför ett ”allt eller inget” val, där man antingen måste implementera ersätt-ningar för det som inte existerar i en simulerad miljö t.ex. EEPROM, alternativt kapa bort stora delar av koden och endast använda de bitar som direkt påverkar PWM-signaler till ventiler, hastighetsprofiler etc. Det som återstår när man tar bort allt som inte direkt låter sig fungera i en simulerad miljö kan liknas med en glorifierad uppslagstabell varpå syftet med det hela kan ifrågasättas.

Att importera kod till en s-funktion är mer problematiskt än att skapa en 47

48 Diskussion

DLL och exportera funktionerna till CAPL. Framförallt uppstår problem när de-lar av koden skall exekveras var 20ms och vissa mer frekvent. I Simulink kan Rate Transition-block användas för att hantera olika samplehastigheter i samma mo-dell. Ytterligare är ett alternativ att skriva egna rutiner för att emulera de olika exekveringstiderna. CAPL hanterar detta med ”timers” för att exekvera rutiner olika ofta.

8.1

Framtida arbete

Något som ligger nära till hands är att koppla samman en riktig MCU med Si-mulinkmodellen. Det innebär nog ett visst arbete med att få modellen och MCUn att samspela även om det teoretiskt endast bör vara att mappa I/O-portar mot Environment/CAN-signaler/meddelanden.

Vidare kan det finnas fördelar med att finjustera hydraulikmodellen för att ännu bättre efterlikna någon av de truckar som finns tillgängliga i labbet. Det finns nackdelar med att anpassa modeller för bra mot mätdata då det är lätt att man missar beteenden som kanske inte är uppenbart i den mätserien. Fördelen är däremot att man kan vara säker på att inom vissa intervall så beter sig modellen precis som den fysiska trucken. Något som skulle tillåta ingenjörerna att utföra delar av sitt arbeta från sitt skrivbord istället för att boka tid i labbet. Ytterligare finns det säkerligen mer dynamik och mer realistiskt beteende om mekaniken i trucken modelleras. Modellen tar idag ingen hänsyn till hastigheten hos trucken eller hur t.ex. reach-rörelsen ser ut vid kraftig inbromsning. Rörelseenergin i en truck är inte att förakta i dessa sammanhang.

Mjukvarusimuleringen, software-in-the-loop, är ett lovande område. Att arbeta med att implementera ett HAL specifikt för Vector CANoe skulle möjliggöra att koden kan byggas specifikt i simuleringssyfte.

Kapitel 9

Slutsats

Genom att skapa ett HAL specifikt för simuleringsmiljön är det möjligt att använ-da mjukvaran i trucken i en software-in-the-loop miljö. Det är möjligt att skapa en DLL som med ett exportlager till CAPL kan användas som en nätverksnod i CANoe. Alternativt skapas en s-funktion för direkt integration med Simulink. Den enklare hanteringen av skilda exekveringstider samt interruptfunktioner gör DLL och CAPL till ett attraktivare val.

Hydraulikmodellen som skapats över delar av gaffeltrucken stämmer väl över-ens med verkligheten förutom när insignalerna till ventilblocken ligger nära dess dödband. Den friktion som uppstår i ventilen vid högre lasttryck förflyttar död-bandet och ger upphov till ett olinjärt beteende. Förlusterna som uppkommer när Hopsan exporteras till Simulink utgör inget hinder för realtidssimuleringar. Den kombinerade hydraulik och sensorgränssnittet i Simulink kan exporteras till C-kod med Simulink Coder. Den resulterande C-C-koden är sedan enkel att importera i CANoe för realtidssimuleringar.

Litteraturförteckning

[1] Syed Adeel Asghar and Sonia Tariq. Design and implementation of a user friendly openmodelica graphical connection editor, 2010.

[2] Mikael Axin, Robert Braun, Alessandro Dell´Amico, Björn Eriksson, Peter Nordin, Karl Pettersson, Ingo Staack, and Petter Krus. Next Generation Si-mulation Software using Transmission Line Elements. In Fluid Power and Motion Control, pages 265–276, 2010.

[3] Robert Braun. Multi-threaded real-time simulations of fluid power systems using transmission line elements, -.

[4] Vector CANtech Inc. Programming With CAPL, Dec 2004.

[5] Vector CANtech Inc. CANoe Test Feature Set Tutorial, May 2009. AN-AND-1-118.

[6] Petter Krus. Robust modelling using bi-lateral delay lines for high speed simu-lation of complex systems. In DINAME 2011 : 14th International Symposium on Dynamic Problems in Mechanics, 2011. Invited conference contribution. [7] Jun Lin. Implementing and Integrating CAPL DLLs, July 2008.

[8] Martin Söderlund and Fredrik Öhman. Simulering av hydrauliken i haldex-kopplingen, 2005.