Driftsättning av ett distribuerat styrsystem på hårdvara

Institutionen för Datateknik Examensarbete 10 p C-nivå Driftsättning av ett distribuerat styrsystem på hårdvara Uppsala 001-06-9 Uppdragsgivare: Mälardalens högskola, IDt CC Systems AB Box 883 Fyrisborgsgatan 5 71 3 VÄSTERÅS 754 50 UPPSALA Handledare: Christer Sandberg Handledare: Gunnar Ohlsson Examinator: Henrik Thane

001-08-4 rapport_084.doc SAMMANFATTNING CC Systems AB utvecklar styrsystem till kunder med komplexa maskiner och mellanstora serier. För att ta tillvara kompetensen från denna utveckling av skräddarsydda system pågår ett arbete med att ta fram ett mer generellt styrsystem som kan användas av mindre kunder. Detta system går att köra i en simulerad miljö på PC, och huvuduppgiften i detta examensarbete är att driftsätta systemet på Cross Fire, CC Systems hårdvarumodul. För att utföra detta anpassades de lågnivågränssnitt som förekommer i styrsystemet till Cross Fire. För att demonstrera systemet implementerades en demonstrator i form av styrning av en traktor. Denna demonstrator är inte fullständig, eftersom alla delar i driftsättningen inte genomfördes, och det inte fanns tillräckligt med hårdvara tillgänglig för att demonstrera systemet på traktorn. FÖRORD Denna rapport är skriven som en del av ett examensarbete på 10 poäng på C-nivå inom dataingenjörsprogrammet vid Mälardalens högskola i Västerås. Många personer har hjälpt mig med detta arbete. Jag vill främst tacka min handledare på CC Systems AB, Gunnar Ohlsson, som har svarat på otaliga frågor och rätat ut både stora och små frågetecken. Andra anställda på företaget har inte heller sluppit undan mina frågor. Ett stort tack till alla på CC Systems AB, bl.a. Tomas Linde på kontoret i Västerås, som har fått bistå med en hel del hjälp om Cross Fire. Ett stort tack riktas också till de som har agerat handledare och examinator på Institutionen för Datateknik vid Mälardalens högskola, Christer Sandberg och Henrik Thane.

001-08-4 rapport_084.doc INNEHÅLLSFÖRTECKNING ORDLISTA...4 1 BAKGRUND...5 PROBLEMBESKRIVNING...5 3 TEORI...5 3.1 Distribuerade styrsystem... 6 4 PROBLEMANALYS...6 5 BESKRIVNING AV SYSTEMET...7 5.1 System 000... 7 5.1.1 CAN-gränssnittens uppbyggnad... 8 5.1. IO-gränssnittens uppbyggnad... 9 5.1.3 Applikationsbeskrivning... 9 5. Cross Fire... 1 6 LÖSNING...1 6.1 Inledning... 1 6. Testprogrammet med befintliga gränssnitt... 13 6.3 Anpassning av CAN-gränssnitt... 13 6.4 Anpassning av IO-gränssnitt... 13 6.5 Applikationsbeskrivningen... 14 6.6 System 000 på Cross Fire... 15 6.7 Nedladdning av systemet till flash-minnet... 15 6.8 Traktorapplikationen... 15 7 RESULTAT...15 7.1 Mätning av svarstider... 15 7. Minnesåtgång... 16 7.3 Problem under arbetet... 16 7.4 Test, funktionalitet... 16 8 SLUTORD...17 LITTERATUR...17 BILAGOR...17 3

001-08-4 rapport_084.doc ORDLISTA Här ges en kort förklaring till vissa ord som kommer att förekomma i rapporten. Många av dessa ord kommer att förklaras noggrannare i texten. ABE Application Builder Environment. Ett program utvecklat av CC Systems för System 000 där man grafiskt kan koppla ihop komponenter, in- och utportar för att beskriva hur en applikation ska styras. Applikation - Det som styrsystemet ska styra, t.ex. en traktor. Applikationsbeskrivning En beskrivning av hur styrsystemet ska styra applikationen, vilka komponenter, in- och utportar som ingår, och hur dessa ska kopplas ihop. CAN- Controller Area Network. Kommunikationsbuss som ofta används inom fordonsindustrin där inbyggda system är förekommande. Cross Fire CC Systems hårdvarumodul, med IO-portar och processor. Demonstrator Något som demonstrerar ett system, helt eller delvis simulerat. Distribuerat styrsystem Ett system med fysiskt och logiskt separerade enheter, men som agerar som en enhet mot omvärlden. Gränssnitt kontaktytan mellan två delar i ett system, t.ex. styrsystemet och IO-enheterna. Kan vara uppbyggda i flera lager. IO-port, inport, utport delar som kommunicerar med omvärlden, i detta system är det typiskt analoga och digitala utgångar respektive ingångar. Komponent Komponenter kan motsvara fysiska ut- eller ingångar, eller vara logiska enheter som talar om hur de in- eller utgångar som kopplas till komponenten ska behandlas. I System 000 byggs en applikationsbeskrivning upp av komponenter som kopplas ihop. Lågnivåkod, lågnivågränssnitt Här menas den delen av koden som kommunicerar direkt med hårdvara på Cross Fire. Master Den nod som styr de andra noderna (slavarna) i ett nätverk. Nod En enhet i ett nätverk. Slav - En dum nod i ett nätverk som lyssnar på mastern. 4

001-08-4 rapport_084.doc System 000 Arbetsnamn på CC Systems modulbaserade styrsystem. 1 BAKGRUND CC Systems AB har lång erfarenhet av styrsystemutveckling till kunder med komplexa maskiner och mellanstora serier, som oftast ska verka i tuffa miljöer. Företaget har totalt ca 100 anställda i Alfta (där huvudkontoret ligger), Uppsala och Västerås. De styrsystem som CC Systems utvecklar är oftast skräddarsydda för kunden. För att tillvarata kompetensen från de skräddarsydda systemen även till kunder i mer prispressade segment pågår ett arbete med att ta fram ett generellt styrsystem med standardmoduler, där kunden kan designa sitt system med hjälp av ett grafiskt verktyg. Systemet har idag arbetsnamnet System 000 (alternativt Styrsystem 000 eller S000) och går att köra i en simulerad miljö på PC. PROBLEMBESKRIVNING Syftet med detta examensarbete är att driftsätta System 000-plattformen på en av CC- Systems IO-moduler, Cross Fire. En demonstrator ska sättas upp, där System 000 och Cross Fire ersätter befintligt styrsystem på en grävmaskin (traktor), som finns i Alfta. Denna demonstrator ska göra det möjligt att visa systemet till en början internt. För att kunna visa systemet i Uppsala, utan traktor, kopplas delar från traktorn till IO-portarna på Cross Fire. En utvärdering av de realtidsegenskaper som uppkommer med en viss applikation ska göras. Det som ska utvärderas är dels svarstider för traktorapplikationen, men även mindre applikationer. Med svarstider menas den tid det tar för den högst belastade noden i systemet att utföra sina beräkningar. I rapporten ska visioner, specifikationer och testresultat finnas med, och även beslutsunderlag inför eventuella omkonstruktioner av arkitekturen hos den befintliga plattformen. Parallellt med detta examensarbete pågår också ett examensarbete som går ut på att implementera det standardiserade kommunikationsprotokollet CAN-Open för Cross Fire. Dessutom pågår ett arbete med att visa hur Cross Fire klarar av de tuffa miljöer som den är tänkt för, genom att visa hur den kan fungera under vatten. Detta arbete kräver att System 000 är driftsatt på Cross Fire, så att den kan styras under vatten. Ett arbete med användargränssnitt pågår också. 3 TEORI Detta kapitel definierar ett distribuerat styrsystem, och behandlar även den princip för kommunikation mellan noderna, CAN, som förekommer i System 000. 5

001-08-4 rapport_084.doc 3.1 Distribuerade styrsystem System 000 är ett distribuerat styrsystem. Ett distribuerat styrsystem definieras som ett system med fysiskt separerade enheter och logiskt separerad hantering. Hela styrsystemet är en enhet, med avseende på dess uppgift, och det har ett väldefinierat gränssnitt mot sin omgivning, men de logiska funktionerna och fysiska komponenterna är distribuerade. Anledningen till att man distribuerar ett system, trots att det ökar komplexiteten, är flera. En anledning är att många system är distribuerade fysiskt. En annan anledning är kapacitet, den kapacitet man skulle ha fått med endast en processor är inte tillräcklig för systemet. Ur skalbarhetssynpunkt är det också motiverat att distribuera ett system, eftersom det då blir lättare att stegvis bygga ut systemet. För kommunikation mellan de olika enheterna kan olika principer användas: Punkt till punkt-nätverk, där varje enhet är kopplad till alla andra. Stjärnnätverk, där varje enhet är kopplad till en masterenhet. Ringnätverk, där varje enhet bara är kopplad till sina två grannar. Bussnätverk, där alla enheter är kopplade på en buss. Bussnätverk har flera fördelar jämfört med de andra nätverken; varje enhet behöver bara en kommunikationsport och det behövs ingen masterenhet. Bussnätverk har också den fördelen att de är inte så känsliga för nodhaveri. Huvudproblemet med ett bussystem är att ge alla enheter rättvis tillgång till bussen med hög prestanda och hög pålitlighet. En del äldre system använde en masterenhet, som kontrollerade all trafik på bussen. Nyare system använde sig av en virtuell master, en s.k. token, som den enhet som behövde använda bussen fick. Moderna bussar har ingen master, alla enheter som är kopplade till bussen kan har tillgång till den. Master ska i det här fallet inte förväxlas med en master i t.ex. ett styrsystem, här handlar det om en master som kontrollerar trafiken på bussen. Det finns två huvudprinciper för att ge enheter access till bussen, händelsestyrda och tidsstyrda principer. Ethernet och CAN (Controller Area Network) är två exempel på händelsestyrda system. Båda fungerar så att en nod som behöver sända på bussen kontrollerar om bussen är ledig eller upptagen. Om den är ledig börjar noden sända. Om två noder börjar sända samtidigt finns det två principer att lösa detta. På ett Ethernet väntar noderna en viss tid, och försöker sedan sända igen. I ett CAN-nätverk får den nod som har högst prioritet sända. CAN är anpassat för realtidssystem och är också det system som används i System 000 för kommunikation mellan noderna. En ram i ett CAN-nätverk består bl.a. av start- och stoppbitar, kontrollfält, checksumma och kvittensbitar. Dessutom innehåller ramen max 8 byte data och en identifierare. Standardformatet har en identifierare på 11 bitar, det utökade formatets (extended CAN) identifierare är 9 bitar. I identifieraren finns bl.a. information om ramens identitet och prioritet. 4 PROBLEMANALYS Att driftsätta Styrsystem 000 på Cross Fire innebär att de gränssnitt mot hårdvara som systemet använder sig av ska anpassas för den specifika hårdvaran. I simuleringen på PC använder sig systemet av andra gränssnitt, mot dll-filer som simulerar hårdvaran. De hårdvarugränssnitt som finns är anpassade för ett annat projekt med annan hårdvara, och 6

001-08-4 rapport_084.doc måste därför ändras. Lågnivåkod finns tillgänglig för Cross Fire, men ändringar kan behöva göras i denna. De gränssnitt som främst behöver ändras är de för CAN-kommunikation och IO-hantering. En del allmänna ändringar behöver göras för att anpassa koden till kompilatorn för målmiljön. Även tillvägagångssättet för systemets inhämtande av applikationsbeskrivningen, som beskriver vad som ska styras, måste ändras. Det ska gå att ladda ner systemet till Cross Fires flash-minne. Utvärderingen av realtidsegenskaper görs genom att svarstider mäts för den nod i systemet som har högst belastning. Eftersom det är masternoden som utför alla beräkningar är det den noden som kommer att ha högst belastning. Tiden mäts från det att mastern börjar samla in värden från sina slavar till att den har beräknat nya värden och skickat ut dessa. Utvärderingen ska göras för ett par olika applikationer som kräver olika sorters beräkningar. 5 BESKRIVNING AV SYSTEMET Detta kapitel beskriver System 000, och de viktigaste delarna, som sedan kommer att anpassas. En kort beskrivning av Cross Fire ges också. 5.1 System 000 System 000 är en avskalad del av ett styrsystem som konstruerades till ett tidigare projekt, som gjordes åt Bromma Conquip. Det ursprungliga styrsystemet används för att hantera containrar inom hamnindustrin. Det avskalade styrsystemet fungerar innan examensarbetets start i simulerad miljö på PC. Systemet består av minst en nod, en master. Utöver mastern kan det även finnas ett antal slavnoder. När en nod startas utförs först initieringar av mjuk- och hårdvara. Sedan avgör noden om den är master eller slav, och vilket nodnummer den har. Detta sker på olika sätt beroende på om noden exekverar simulerat eller på hårdvara. Vid simulerad exekvering får noden sitt nummer genom att titta på vilket process-id den har tilldelats av operativsystemet, och omvandla detta till nodnummer. Master har alltid nodnummer 0, slavar har 1, o.s.v. Sedan exekverar noden olika delar av koden beroende på om den är master eller slav. Masternoden tar reda på vilka andra noder som är närvarande, genom att skicka ut ett broadcast-meddelande, ett meddelande som alla noder på CAN-nätverket kan ta emot, och invänta svar från närvarande noder en viss tid. Sedan läser den in applikationsbeskrivningen, i det simulerade fallet från en fil. Utgående från denna sätter mastern upp de IO-portar och de komponenter som finns angivna i applikationsbeskrivningen. Meddelanden om att sätta upp portar skickas ut till närvarande noder. Efter detta går mastern in i sin huvudloop, där den skickar meddelanden till sina noder om att den vill ha värdena på deras IO-portar. Masternoden tar emot svar på denna förfrågan, och räknar sedan ut nya värden, beroende på applikationens utseende, d.v.s. vilka komponenter och IO-portar som finns. De nya värdena skickas ut till alla slavnoder. I slavnodens huvudloop väntar slaven i princip bara på att uppfylla de olika typer av order den erhåller från mastern. 7

001-08-4 rapport_084.doc 5.1.1 CAN-gränssnittens uppbyggnad Noderna i Styrsystem 000 kommunicerar med varandra via CAN. Gränssnitten för detta är uppbyggda i flera lager enligt nedanstående bild. Varje ruta representerar en klass eller en samling funktioner. De lager som anpassas är CCS_Can och HAL_Can. De andra lagren är helt oberoende. CanMessage (strukturen för meddelandet. Funktioner finns för att sätta olika typer, sätta data osv) CanBuffer (lagrar inkommande meddelanden, skickar utgående) CCS_Can (lågnivåkod för simulering, anropar något av nedanstående lager beroende på om systemet exekverar simulerat eller på hårdvara) HAL_Can (lågnivåkod direkt anpassad för Cross Fire) Can (lågnivåkod för simulering) HW Cross Fire CanDLL (Lågnivåkod för simulering) 8

001-08-4 rapport_084.doc 5.1. IO-gränssnittens uppbyggnad I S000 finns virtuella portar, som kan konfigureras som digitala eller analoga, och som ineller utgångar. På Cross Fire finns 4 A/D-kanaler och 8 PWM-kanaler. Dessa går att använda som fysiska portar, motsvarande de virtuella, i S000. PWM-kanalerna kan användas som digitala respektive analoga utgångar och A/D-kanalerna kan användas som digitala respektive analoga ingångar. Även dessa gränssnitt är i S000 uppbyggda av flera lager. Port (Kan vara in- eller utgång, analog eller digital. Värden kan sättas eller läsas av) CCS_Io (lågnivåkod, anropar något av nedanstående lager beroende på om systemet kör simulerat eller på hårdvara. Innehåller funktioner som port använder för att läsa av och sätta portar) PWM (lågnivåkod direkt anpassad för Cross Fires PWM-kanaler) AD (lågnivåkod direkt anpassad för Cross Fires AD-kanaler) SimIOPort (lågnivåkod för simulering) HW Cross Fire SimIOPortDll (lågnivåkod för simulering) 5.1.3 Applikationsbeskrivning Beskrivningen av det som styrsystemet ska styra, inklusive hur många noder det finns och vilka portar som finns, görs i ett grafiskt program, ABE (Application Builder Environment). Här beskrivs hur värden från inportarna ska behandlas för att avgöra vad som ska sättas ut på utportarna. Av beskrivningen i ABE genereras en textfil. Den kallas applikationsbeskrivning och kan även skrivas för hand, om inte programmet ABE finns tillgängligt. Styrsystemet läser sedan denna textfil. Det enklaste exemplet är att två digitala inportar kopplas till en AND-grind och resultatet skickas ut på en digital utport. I systemet innebär det att mastern, efter att ha läst in applikationsbeskrivningen, vet att den ska utföra en logisk AND-operation på värdet på dessa två inportar för att få resultatet som ska sättas ut på utporten. DIGIN1 DIGIN AND1 DIGOUT Värdet på den digitala utgången DIGOUT blir resultatet av en logisk AND-operation mellan de två digitala ingångarna DIGIN1 och DIGIN 9

001-08-4 rapport_084.doc Från den grafiska beskrivningen skapas sedan en textfil, som måste göras tillgänglig för systemprogrammet. Denna textfil är fullt läsbar: COMP OUTSIGNAL DIGOUT NODE 0 PORT 1 TYPE DIGITAL BABE "","" ENDCOMP COMP INSIGNAL DIGIN1 NODE 0 PORT 0 TYPE DIGITAL BABE "","" ENDCOMP COMP INSIGNAL DIGIN NODE 0 PORT TYPE DIGITAL BABE "","" ENDCOMP COMP AND AND1 CIN BABE :319,151 ENDCOMP CONN DIGIN1 OUT AND1 IN0 BABEPORT,"DIGIN1" ENDCONN CONN DIGIN OUT AND1 IN1 BABEPORT,"DIGIN" ENDCONN CONN AND1 OUT DIGOUT IN BABEPORT,"DIGOUT" ENDCONN COMP talar om att det som beskrivs är en komponent. OUTSIGNAL är typ av komponent. DIGOUT är namnet på komponenten, som sedan används i applikationsbeskrivningen när man hänvisar till komponenten Om det är en in- eller utsignal talar NODE om vilken nod porten ligger på, och PORT vilket nummer porten har hos den noden. TYPE talar om om porten är DIGITAL eller ANALOG. BABE är ett värde som talar om vart komponenten placeras grafiskt i ABE. Vid beskrivning av andra komponenter än in- och utsignaler finns det olika parametrar som behöver anges, beroende på vilken komponent det är. AND-komponenten kräver att man med CIN talar om hur många ingångar den ska ha. Med CONN talar man om hur komponenter ska kopplas ihop. Först anges vilken utgång det gäller, och sedan till vilken ingång den ska kopplas. Det finns ett antal komponenter tillgängliga, alla kan inte nämnas, men nedan följer en förklaring av några av de som kommer att användas i traktorapplikationen. SCALE Denna komponent har en analog signal som ingång, och skalar om den enligt formeln y=kx+m. Gränser för ingången respektive utgången anges i applikationsbeskrivningen. COMP SCALE SCALE1445798 SCALED_MAX_VALUE 103 SCALED_MIN_VALUE 0 MAX_INPUT_VALUE 047 MIN_INPUT_VALUE 0 BABE 1:306,68 ENDCOMP 10

001-08-4 rapport_084.doc Värdet som sätts ut på utgången från denna komponent blir halva värdet på ingången. THRESHOLD Tolkar ett analogt ingångsvärde som digitalt och lägger ut det digitala värdet på ingången. Tröskeln för när värdet ska tolkas som en etta anges i applikationsbeskrivningen. COMP THRESHOLD THRESHOLD1534976 THRESHOLD 511 BABE 1:68,49 ENDCOMP Gränsen för när den analoga insignalen ska tolkas som etta går för detta exempel vid 511. INC_REF Komponenten har en analog utgång som kan styras via två digitala ingångar. Den ena ingången ökar utgångens värde, om den sätts till etta, den andra ingången minskar utgångens värde. COMP INC_REF INC_REF1446541 DEFAULT_OUT_OFF 0 DEFAULT_OUT_ON 55 DELAY 10 INCREMENT 3 MAX_OUT 103 MIN_OUT 0 BABE 1:498,59 ENDCOMP I beskrivningen anges vilket värde komponenten ska ha från början, hur mycket den ska öka varje gång, och hur länge den digitala signalen ska vara aktiv för att ökningen eller minskningen ska ske. SPLIT Delar upp insignalen i ett antal utsignaler av samma typ och med samma värde som insignalen. COMP SPLIT _Stödben_Z COUT BABE 0:0,0 ENDCOMP Hur många utsignaler komponenten ska skapa anges av parametern COUT. I simulerad miljö läses beskrivningen som en textfil, men på målmiljön måste applikationsbeskrivningen göras tillgänglig på något annat sätt. Ett alternativ är att ladda ner applikationsbeskrivningen till flash-minnet, och sedan kan systemet läsa den därifrån. Ett annat alternativ är att kompilera in beskrivningen i koden. Det sistnämnda alternativet valdes, eftersom oklarheter rådde om vilket format filen borde vara på för att kunna laddas ner och hur nedladdningen går till rent praktiskt. Det bedömdes att det skulle vara enklare och mindre 11

001-08-4 rapport_084.doc tidsödande för tillfället att kompilera in beskrivningen i koden. En stor nackdel är att hela systemet måste kompileras om vid byte av applikation. 5. Cross Fire CC Systems hårdvarumodul har namnet Cross Fire. Den består bl.a. av en Siemens C167crprocessor (klockfrekvens 0 MHz), fyra AD-kanaler och åtta PWM-kanaler. Det finns 56 kb flash-minne (för systemprogram och applikationsbeskrivning) och 56 kb RAM. 6 LÖSNING 6.1 Inledning Efter studier av styrsystemets funktion och granskning av nödvändiga delar av koden utfördes arbetet enligt följande: Kompilering av System000 i kompilatorn för målmiljön. Konstruktion av ett testprogram, som använder sig av gränssnitten i System 000 och fungerar i simulerad miljö på PC. Anpassning av gränssnitten så att testprogrammet även fungerar på Cross Fire. - Anpassning av ett gränssnitt i taget, med hjälp av delar av testprogrammet som först testar CAN-gränssnittet, och sedan både CAN-gränssnittet och IOgränssnitten Implementation av den modul som genererar källkod av applikationsbeskrivningen Testning av System 000 med små applikationer Implementation av traktorapplikationen Test av traktorapplikationen simulerat på PC Test av traktorapplikationen på HW, försök utförs att ladda ner koden till flashminnet. Mätning av svarstider Den kompilator som används för att kompilera koden för System 000 för målmiljön är Tasking. All kod överfördes till Tasking och kompilerades. Kod som var specifik för simuleringsmiljön eller annan hårdvara kommenterades bort. Systemet använde sig av en klass Istream, för att hantera långa strömmar av tecken, i samband med tolkningen av applikationsbeskrivningen. Denna klass fanns inte att tillgå i Tasking, så en klass Hstream med nödvändig funktionalitet konstruerades. 1

001-08-4 rapport_084.doc Hstream get() eof() operator >>() När klassen skapas anges en array av tecken som inparameter till konstruktorn. Tecken kan sedan plockas ut en efter en med metoden get (). Med operatorn >> fås nästa ord. Metoden eof() kontrollerar om det är slut på tecken. En hel del inställningar behövde göras i kompilatorn, mer om detta under rubriken Problem. 6. Testprogrammet med befintliga gränssnitt Ett testprogram konstruerades för att lättare kunna ändra gränssnitten. Detta testprogram använder sig av de befintliga gränssnitten i System 000, och testades först i simulerad miljö. När programmet fungerade i simulerad miljö anpassades gränssnitten till Cross Fire, och programmet testades på hårdvara. Testprogrammet utgörs av en masternod och en slavnod som kommunicerar via CAN. Slaven har ett antal fysiska in- och utgångar som mastern genom CAN-meddelanden tar emot avläsningsresultat ifrån, respektive anger hur de ska sättas. När gränssnitten sedan testades var för sig skalades detta program ner ytterligare för att bara använda de aktuella gränssnitten. För att få detta testprogram att fungera på Cross Fire ska förändringar endast behöva göras i gränssnitten, inte i själva testprogrammet. 6.3 Anpassning av CAN-gränssnitt Styrsystem 000 arbetar med extended CAN-format på CAN-meddelandet medan lågnivågränssnitten till Cross Fire använder sig av standard-can. Detta krävde ändringar i lågnivåkoden till Cross Fire, så att extended CAN-meddelanden kan sändas och tas emot. Test gjordes så att rätt data skickades åt båda håll, och även så att rätt typ (integrerad i identifieraren) kom fram. 6.4 Anpassning av IO-gränssnitt För att sätta en analog utgång skickar System 000 ett värde mellan 0-999. 999 är maximalt värde ut, alltså 4 V. Lågnivåkoden för Cross Fire tar värden mellan 0-047, för att ställa ut något på PWM-utgångarna. En skalning fick därför göras mellan dessa värden, innan lågnivåkoden kunde användas. För att ställa ut en digital etta, ställs max PWM-värde ut på aktuell port, och för en digital nolla ställs 0 ut. Vid avläsning av en analog ingång används lågnivåkoden för Cross Fire. Värdet omvandlas till mv och skalas om till 0-4096. För att läsa av en digital ingång görs en tolkning av det analoga värdet, där 0-1 V tolkas som nolla, andra värden som etta. Numreringen av portar får vissa begränsningar när S 000 exekverar på Lilla IOn. På grund av antalet in- och utgångar, och den fysiska numreringen i lågnivåkoden, måste alla ingångar vara numrerade 0-3 och alla utgångar 0-7. En digital ingång och en analog ingång kan inte ha samma portnummer, inte heller en digital utgång och en analog utgång. 13

001-08-4 rapport_084.doc 6.5 Applikationsbeskrivningen Ett fristående program, ApdGenerator, konstruerades. Programmet tar en fil i textformat som inparameter, och skapar av den källkodsfiler, en.cpp-fil och en.h-fil. I.cpp-filen läggs hela filens innehåll, tecken för tecken, in i en konstant array av tecken. I.h-filen finns definierat hur många tecken det är i applikationsbeskrivningen och en externdeklaration av arrayen. De två filerna kompileras sedan med i hela S000, och på så sätt görs applikationsbeskrivningen tillgänglig för systemet. Detta möjliggjordes genom vissa ändringar i den del av koden som läser in och tolkar applikationsbeskrivningen. Tidigare har applikationsbeskrivningen i simulerad miljö lästs från en fil, eller från flashminnet, med en kod som var anpassad för ett tidigare projekt. *.apd ApdGenerator ApdFile.cpp ApdFile.h ApdFile.h // FILENAME: // ApdFile.h // // DESCRIPTION: // Innehåller antalet tecken i applikationsbeskrivningen // Genereras av ApdGenerator #ifndef APDFILE_H #define APDFILE_H #define APD_SIZE 8178 extern const char apd[ ]; #endif Del av ApdFile.cpp // FILENAME: // ApdFile.cpp // // DESCRIPTION: // Innehåller applikationen i form av en konstant sträng // Genereras av ApdGenerator #include "ApdFile.h" const char apd[apd_size]= {71,69,78,69,8,65,76,10,9,65,80,80,73,68,83, 3,9,9,51,10,9,65,85,84,7,79,8,3,9,9, 3,34,34,10,9,76,65,83,84,95,68,65,84,69,95, 83,65,86,69,68,9,3,50,48,48,48,45,49,56,45, 48,56,95,49,50,58,48,54,10,9,67,8,69,65,84, 14

001-08-4 rapport_084.doc 6.6 System 000 på Cross Fire När gränssnitten hade testats med hjälp av testprogrammet ersattes det av hela S 000. En enkel applikation i form av en AND-grind med två ingångar implementerades. Test gjordes både med att exekvera en slav på Cross Fire och en master simulerat på PCn, och det omvända fallet. Eftersom inga timer-funktioner fanns tillgängliga gjordes vissa justeringar. Vid uppstart tar systemet i simulerat utförande reda på närvarande noder genom att skicka ut ett broadcastmeddelande, och invänta svar en viss tid. De närvarande noderna hårdkodas istället beroende på applikation. Nodens identitetsnummer, som avgör om den ska starta som slav eller master, anges också direkt i koden, och ändras genom att kompilera systemet med preprocessordefinitionen MAST (master, nod 0), SLAV (nod 1), NOD eller NOD3. 6.7 Nedladdning av systemet till flash-minnet Ett krav är att systemet ska kunna laddas ner till Cross Fires flash-minne. Detta krav uppfylldes inte, trots test av många olika inställningar i kompilatorn. Det går i nuläget endast att exekvera System 000 på Cross Fire genom debugger. 6.8 Traktorapplikationen En applikationsbeskrivning över vad som skulle styras på traktorn fanns tillgänglig. Den anpassades till de in- och utgångar som finns på Cross Fire. Den ursprungliga traktorapplikationen bestod av två noder, med 10 ingångar och 4 utgångar på masternoden, och 5 ingångar och 8 utgångar på slavnoden. Applikationen gjordes om så att den består av 4 noder, och portarna numrerades om, enligt den för Cross Fire tillåtna numreringen. Ett schema över traktorapplikationen finns i bilaga 3. 7 RESULTAT Under denna rubrik beskrivs utvärderingen av svarstider, problem som uppstod under arbetet och hur systemet testades. De begränsningar i funktionalitet som förekommer nämns också. 7.1 Mätning av svarstider I examensarbetet ingick att göra en utvärdering av systemets realtidsegenskaper. Några olika applikationer skulle implementeras, och tid skulle mätas för hur lång tid ett varv i masterns beräkningsloop tog. Mot slutet av examensarbetet visade det sig att en sådan utvärdering inte var möjlig att göra. Minst ett, helst tre till exemplar av Cross Fire skulle behövas, men det skulle inte hinna tillverkas vid CC Systems produktionsenhet i Alfta. Dessutom lyckades ej nedladdningen av systemet till Cross Fires flashminne och timer-funktioner implementerades aldrig. 15

001-08-4 rapport_084.doc 7. Minnesåtgång Systemets nuvarande utförande kräver 100 157 byte ROM och 74 580 byte RAM, när det exekverar som masternod. Endast de komponenter som är nödvändiga för traktorapplikationen finns med. 7.3 Problem under arbetet Vid arbetet med ett stort system som var helt okänt för författaren, och utvecklingsverktyg som inte heller var bekanta uppstod problem, några av dessa tas upp under denna rubrik. De grundinställningar som behövdes för att kunna kompilera systemet i Tasking fanns tillgängliga, men en hel del ändringar behövdes göras i dessa, vilket orsakade problem. I kompilatorn krävs att minnet definieras upp, vad gäller vilka adresser som tillhör RAM respektive ROM. De ursprungliga inställningarna rymde inte all kod. När dessa ändrades upptäcktes ett problem när pekare skickades som argument till funktioner. Pekaren hade inte samma värde när den kom in i funktionen, som hade när den skickades. Problemet löstes genom att minska på ROM-arean tills koden precis fick plats. Eftersom både ROM och RAM läggs i RAM vid debug ledde detta till att RAM ökade. Detta förhindrade den sönderskrivning av minnet som troligen skedde. En heap måste definieras upp, eftersom koden använder sig av dynamisk allokering, och minnet till detta allokeras på heapen. Detta medförde problem, eftersom det var oklart hur stor den skulle vara. Systemets mjukvarurepresentation av en port (in- eller utgång), Port, finns i sin tur i en klass SetOfPorts, som innehåller alla portar. SetOfPorts Port Ett objekt av denna klass allokeras dynamiskt och detta objekt kräver mycket minne. För att minska storleken på detta objekt, som ska kunna rymma alla portar på alla noder, minskades maxantalet noder till eller 4 för tillfället. 7.4 Test, funktionalitet Test av CAN- och IO-gränssnitt beskrivs i bilaga 4. Styrsystemets funktionalitet testades genom att implementera olika applikationer. Resultatet på utportarna jämfördes med det resultat som erhölls på utportarna när samma applikation exekverade i simulerad miljö. 16

001-08-4 rapport_084.doc Systemet fungerar tillfredställande både med mindre applikationer, t.ex. den allra enklaste AND-applikationen, och mer komplicerade applikationer, som traktorapplikationen. Timerfunktioner implementerades aldrig på grund av tidsbrist. Detta får som tidigare nämnts till följd att systemet inte kan avgöra hur många noder som finns närvarande, utan detta finns istället angivet i koden. Systemet klarar inte heller av att detektera om det tappar kontakten med någon nod. Någon fullständig demonstrator sattes inte upp, eftersom det krävde att systemet skulle gå att ladda ner till flash-minnet, vilket inte lyckades. För att kunna sätta upp en demonstrator krävdes också att den hårdvara som behövdes fanns tillgänglig. 8 SLUTORD Målet med examensarbetet, att driftsätta Styrsystem 000 på Cross Fire är i stort uppfyllt. Vissa delar är inte uppfyllda, en demonstrator av traktormodellen i sin helhet har inte satts upp, eftersom all nödvändig hårdvara inte fanns tillgänglig vid tiden för examensarbetet. På grund av tidsbrist implementerades inte heller några timer-funktioner, vilket leder till att systemet inte fungerar fullt ut, eftersom vissa delar av systemet använder sig av en timer. Systemet kan inte heller laddas ner till flash-minnet på Cross Fire, vilket ledde till att utvärderingen av realtidsegenskaper inte kunde genomföras på ett tillfredsställande sätt. Tillvägagångssättet för systemets inläsning av applikationsbeskrivningen måste ändras, eftersom det inte är acceptabelt att systemet måste kompileras om vid ändring av applikation. LITTERATUR Norström C, Sandström K, Mäki-Turja J, Hansson H, Thane H och Gustafsson J (000), Robusta realtidssystem, Mälardalen Real-Time Research Centre, Västerås Edler H, Eriksson, J-E, Hedberg J, Sjöström H, (001-06-6), Definitions, http://www.sp.se/electronics/rnd/palbus/reports/palbus_10_1.pdf BILAGOR 1. Tidplan. Vision 3. Schema över traktorapplikationen 4. Beskrivning av hur CAN- och IO-gränssnitt testades 17

Bilaga 1 AKTIVITET/DELAKTIVITET Inledande studie av System000 Installation/introduktion Studiebesök Alfta Sätta upp simuleringsmiljön Studier av System000 Dokumentation vision, specifikation, arkitektur Inlärning av utvecklingsmiljöer Inlärning av C Tasking Testapplikation i C Tasking Porteringsarbete Anpassa lågnivåinterface till HWdrivrutiner Driftsättning av testapplikation på nya HW Test Utvärdering av realtidsegenskaper Dokumentation utvärderingsplan Implementera applikationer enligt utvärderingsplan Sammanställning av testresultat Implementation av demonstrator Implementera traktormodell i ABE Test av traktormodell simulerat Nedladdning av traktormodell på HW Test av traktormodell på HW, eventuellt med grävmaskin Färdigställande av rapport Granskning, upprättning TIDSÅTGÅNG 5 dgr 1 dag 1 dag 1 dag 1 dag 1 dag 5 dgr dgr 3 dgr 5 dgr 10 dgr 10 dgr 5 dgr 5 dgr 1 dag 3 dgr 1 dag 5 dgr 1 dag 1 dag 1 dag dgr 5 dgr 5 dgr

Bilaga VISION Driftsättning av distribuerat styrsystem på hårdvara (Cross Fire) INTRODUKTION Syfte Detta dokument redovisar visionen för examensarbetet Driftsättning av distribuerat styrsystem på hårdvara. isionshistoria Författare Anm 010409 HS Första version. Affärsmöjligheter/Problemformulering CC Systems har lång erfarenhet av utveckling av komplexa, skräddarsydda styrsystem till kunder med komplexa maskiner och mellanstora serier. I syfte att tillvarata kompetensen från dessa system även till kunder i mer prispressade segment pågår arbetet med att ta fram ett generellt styrsystem med standardmoduler, där kunden själv kan designa sitt system med ett grafiskt verktyg. Detta system har idag arbetsnamnet System000 och går att köra på en simulerad miljö på PC. Tanken med examensarbetet är att driftsätta System000 på CC Systems hårdvara Lilla IOn. I detta ingår att utvärdera de realtidsegenskaper som uppkommer i systemet när några enkla applikationer körs. En demonstrator ska också implementeras som ska göra det möjligt att visa systemet internt och eventuellt externt. Demonstratorn ska vara i form av en traktormodell. Eventuellt ska testningen av detta göras på en riktig grävmaskin, som finns i Alfta. En rapport ska skrivas, som ska innehålla beslutsunderlag inför eventuella omkonstruktioner i arkitekturen hos den befintliga plattformen, för att erhålla acceptabla realtidsegenskaper för aktuellt marknadssegment.

Funktionalitet Följande funktionalitet kan listas: BAS System000 ska driftsättas på Lilla IOn Demonstratorn ska kunna visa hur System000 kan användas för en traktormodell System000 ska kunna användas för traktorapplikationen System000 ska kunna köras på den riktiga grävmaskinen Systemet ska kunna köras med valfri applikation gjord i ABE Applikationen ska kunna laddas med flash-laddare, kodladdning ska EJ kunna göras

Bilaga 4 TEST AV CAN-GRÄNSSNITT (Meddelande utan speciella typer) - Slav skickar meddelande till master med HAL_CanSend, rätt data kommer fram. - Slav skickar meddelande till master med CCS_CanSend, rätt data kommer fram. - Slav skickar meddelande till master med CanBufferM.send, rätt data kommer fram. - Slav tar emot meddelande från master med CanBufferM.Receive, rätt data kommer fram. - Meddelandet som slaven skickar visas som extended CAN i CAN-Tool. (Meddelande med typer) - Slav skickar meddelande med viss typ till master med CanBufferM.send, rätt typ kommer fram. - Slav tar emot meddelande med viss typ från master, rätt typ kommer fram. TEST AV IO-GRÄNSSNITT Analog ut: - Sätter ut 0, 50, 50, 999. Det översätts till 0-047, delas upp i hög och låg byte, och sätts ut på PWM-kanalerna. Analog in: - Läser av med ReadAd. Detta värde görs om till volt enligt det förfarande som görs i det grafiska Lilla IO-testprogrammet, och slutligen till mv. Detta värde skalas i sin tur om till ett värde mellan 0-4095. Digital ut: - Sätter ut 047, delar upp i hög och låg byte för 1:a, sätter ut 0 för 0:a på PWMkanalerna Digital in: - Läser av värdet, gör om till mv på samma sätt som vid analog in. Sedan tolkas värden mindre än 1000 mv=1 V som nolla, övriga som etta. Portnummer 0-3 måste vara ingång, port med nummer 0-7 måste vara utgång. En digital utgång och en analog utgång kan inte ha samma portnummer.