2009:004 HIP
B A C H E L O R ' S T H E S I S
Simulation Environment for Further Development of Distributed
Milking Products
Timur Ullman-Önener
Luleå University of Technology BSc Programmes in Engineering BSc programme in Computer Engineering
Department of Skellefteå Campus Division of Leisure and Entertainment
2009:004 HIP - ISSN: 1404-5494 - ISRN: LTU-HIP-EX--09/004--SE
Simulation environment for further devel opment of distribu ted
Milking products
Timur UllmanÖnener
16 juni 2008
i
Förord
Syfte med rapporten
Syftet med rapporten är att förklara mitt examensarbete som DeLaval International AB har anförtrott mig med och hur det gick till. Rapporten speglar det arbete och arbetssätt som jag valde för att lösa min uppgift.
Erkännanden, handledare
Under min tid på DeLaval har jag fått hjälp av ett antal olika personer som jag vill tacka för det stöd jag fått.
Olof Rydlund för att jag fick göra mitt examensarbete på Milking Systems Embedded Software Engineering.
Lars‐Arne Axelsson för all den hjälp jag fått med att förstå hur mjölkenheten fungerar samt idéer.
Jerker Hagman för de idéer och hjälp med diverse debugning av koden samt diverse problem med ClearCase versionshanteringsprogram.
Jimmy Gunnarsson för all hjälp med att övergå till C# och diverse idéer på lösningar till en del problem jag stött på.
Jag vill också tacka min examinator Patrik Holmlund på Luleå Tekniska Universitet.
ii
Abstract
To ease any further development of today’s software I have continued to develop the simulation environment of one of the milking units that already exists in the company today. The simulation environment shall ease further development of bigger systems for bigger farms. What the system will help on doing is the setup of a farm with a number of cows and a number of milking units.
The previous environment was written in MFC but in order to meet the requirements of tomorrow it had to be rewritten in C# .NET with the help of Windows Forms. The program that I initially wrote was built with C++/CLI which in the long run turned out to be too hard to understand and maintain so I switched to C# .NET. The environment runs under Windows and to simulate the bluetooth
connection between the milking unit and the wireless proxy unit I made use of the ethernet connection that every computer has. The graphical user interface which I have written reads the debug messages sent by the milking unit and either writes on the display or switch on/off a light.
iii
Sammanfattning
För att underlätta vidareutvecklingen av dagens programvara har jag fortsatt att utveckla den
simuleringsmiljö som redan finns på företaget idag för en av produkterna som används vid mjölkning.
Simuleringsmiljön skall underlätta utvecklingen av större system för större gårdar. Det som systemet hjälper till med är just uppsättningen av en gård med ett visst antal kor och ett visst antal
mjölkningsmaskiner.
Den tidigare miljön var skriven i MFC men för att möta morgondagens krav har denna blivit omskriven till C# .NET med hjälp av Windows Forms. Det program jag skrev först använde sig av C++/CLI vilket var väldigt krångligt att använda, det resulterade i att jag helt och hållet gick över till C# .NET. Miljön körs på windowsdatorer, för att simulera blåtandskoppling mellan en trådlös enhet och mjölkenheten använde jag mig av datorernas ethernet kontakt. Det GUI som jag skrivit läser av de debugmeddelanden som kommer in för att sedan antingen visa något på displayen eller
tända/släcka en lampa.
iv
v
Innehåll
Förord ... ii
Syfte med rapporten ... ii
Erkännanden, handledare ... ii
Abstract ... iii
Sammanfattning ... iv
Förklaringar och begrepp ... 1
Introduktion ... 2
Bakgrund ... 2
MU ... 2
WPU ... 2
Syftet med arbetet ... 3
Bluetoothservern ... 4
Platform dll ... 4
CAN‐server ... 4
CanKing ... 4
Genomförande ... 5
Analys/Design ... 5
Indelning av arbetet ... 6
Grafiskt användargränssnitt ... 6
Interface mot CAN ... 6
Layout av GUI:t ... 7
Bilder... 8
Simulering av bluetooth ... 8
Resultat ... 10
Användargränssnittet ... 11
Bluetoothservern ... 12
Diskussion ... 13
Framtida förändringar ... 13
Användargränssnittet ... 13
Bluetoothservern ... 13
Summering ... 13
Referenser ... 14
Förklaringar och begrepp
MU Milking Unit, mjölkningsutrustningen som sköter mjölkningen.
WPU/WU Wireless Proxy Unit/Wireless Unit, den trådlösa enhet som tar emot
data/rapporter från mjölkenheten.
MM Milk Meter, mjölkmätare som mäter och rapporterar mjölkflödet vid
mjölkning.
CAN Controller Area Network, en nätverksklass som används för att skicka
data mellan de olika maskinerna.
BT Bluetooth, ytterligare en nätverksklass. Dock avser bluetooth trådlös
kommunikation.
TCP/IP Transmission Control Protocol / Internet Protocol, vanligt förekommande protokoll för att skicka data över ethernet som är den vanligaste nätverks‐‐
klass som används för kommunikation mellan datorer.
DSA DeLaval System Application, företagets egna system applikation.
DDM DeLaval Dairy Management, företagets egen programvara för
mjölkproduktion.
Tied‐Up Uppbunden stalltyp, korna står mestadels i spiltor.
GUI Graphical User Interface, ett grafiskt användargränssnitt.
MFC Microsoft Foundation Classes är ett bibliotek/API för att underlätta
programmeringen av windowsbaserade applikationer.
1
Introduktion akgrund
redan finns ute idag och används på olika bondgårdar passar endast för en viss mängd kor
m, med
är den mjölkutrustning som idag används vid tied‐up mjölkning och den kopplar upp sig mot WPU:n
WPU
är den enhet i ladugården som alla MU:ar kopplar upp sig mot då de ska skicka sina mjölkrapporter
B
De system som
och med ett ökande intresse för större produktion hos bönderna måste systemen anpassas för att möta morgondagens krav. Det finns även ett fåtal problem med dagens system som gör att kommunikationen mellan mjölkenheten och den trådlösa enheten ibland förlorar kopplingen p.g.a att avståndet för bluetoothkommunikation är begränsat. Det som är på gång idag är en lösning på just detta proble fler trådlösa enheter, men för att det ska fungera måste det kunna testas redan i utvecklingsfasen.
MU Mu:n
som finns i ladugården dels för att skicka mjölkrapporter men också för att ta emot förslag på nästa ko (nummer) att mjölka m.m.
WPU:n
osv. WPU:n skickar sedan vidare all data till DSA:n som finns i bondens dator där denne kan få upp bl.a en tabell över hur mycket en specifik ko har mjölkat under dagen/veckan/månaden/året.
2
Syftet med arbetet
För att förbättra utvecklingsmöjligheterna av den nuvarande programvaran, behövdes det först och främst ett lite modernare grafiskt användargränssnitt för den mjölkenhet (MU) som existerar i dagsläget. Nedan‐
stående figur är en förenklad bild av hur produkterna är kopplade. Bilden är en skiss av vad som finns i dagsläget (markerat med rött) och vad som senare skall ingå i den simuleringsmiljö som skall byggas (markerat med grönt). Det som även skulle åstadkommas var att skära ner på antalet program/script som kördes för att kunna simulera kontrollen av mjölkenheten i datorn.
smöjligheterna av den nuvarande programvaran, behövdes det först och främst ett lite modernare grafiskt användargränssnitt för den mjölkenhet (MU) som existerar i dagsläget. Nedan‐
stående figur är en förenklad bild av hur produkterna är kopplade. Bilden är en skiss av vad som finns i dagsläget (markerat med rött) och vad som senare skall ingå i den simuleringsmiljö som skall byggas (markerat med grönt). Det som även skulle åstadkommas var att skära ner på antalet program/script som kördes för att kunna simulera kontrollen av mjölkenheten i datorn.
Mjölkenheten kopplar även upp sig via bluetooth (BT) för att skicka data om senaste mjölkningen och få uppdateringar från WPU:n som tiden osv. För att detta skall göras möjligt och det hela ska verka så verklighetstroget som möjligt så måste man ta fram en teknik för att simulera denna BT‐koppling.
Mjölkenheten kopplar även upp sig via bluetooth (BT) för att skicka data om senaste mjölkningen och få uppdateringar från WPU:n som tiden osv. För att detta skall göras möjligt och det hela ska verka så verklighetstroget som möjligt så måste man ta fram en teknik för att simulera denna BT‐koppling.
MM MM MM MM
MM MM
MU MU MU MU
MU MU
DDM
MIP TCP/IP
DSA
WU
CAN
WU WU WU
BT
3
Bluetoothservern
För att hantera och simulera blåtandskopplingen mellan MU:n och WPU:n, behövdes det en server som svarar och agerar med bluetoothkommandon, dock över sockets/ethernet. Servern ska ligga som ett transparant lager mellan klienterna som kommunicerar via bluetooth. Servern använder sig av de
kommandon som finns dokumenterade från Ezurio[1], tillverkaren av de bluethoothchip som finns i MU:n och WPU:n.
Exempel på kommandon:
1 Klient: ATH<CR><LF>
2 Server: NO CARRIER<CR><LF>
3 Klient: AT<CR><LF>
4 Server: OK<CR><LF>
5 Klient: AT+BTX<CR><LF>
6 Server: OK<CR><LF>
7 Klient: ATI4<CR><LF>
8 Server: 008098D41234<CR><LF>OK<CR><LF>
Platform dll
För att enkelt kunna skicka meddelanden över CAN användes en på företaget egenutvecklad DLL. Genom denna DLL kan man både skicka och ta emot debugmeddelandet som kommer från/till MU:n/GUI:t/WPU:n.
CANserver
CAN‐servern består av Kvaser Virtual CAN Driver[2] vilken startar en CAN‐server i PC:n så man kan koppla samman flera produkter som kommunicerar via CAN API:et med sin dator genom en USB‐TO‐CAN adapter.
Servern agerar som ett lager mellan en eller flera applikationer och en eller flera produkter.
CanKing
Kvaser CanKing[3] är ett verktyg för att skicka CAN meddelanden från datorn via en USB‐TO‐CAN adapter till en CAN‐server m.fl. Dessa meddelanden kunde sedan tas emot från CAN‐servern till det GUI som
utvecklats.
Adressfält till CAN‐applikation/produkt.
Antal bitar i meddelandet t.ex 8
Enskilda bitar i ett 8 bitars meddelande
4
Genomförande
När jag började med mitt projekt måste jag först ta mig igenom ett stort antal dokument som innehöll dokumentationen för de olika produkterna/protokoll och som jag skulle komma i kontakt med under mitt projektarbete. Efter att jag gått igenom dokumenten fick jag en bättre förståelse för hur produkterna kommunicerar med systemet och kunde därefter börja analysera min uppgift.
Analys/Design
När jag skulle påbörja mitt arbete undersökte jag hur den gamla GUI applikationen var skriven och jag kunde faktiskt återanvända en del av den koden, vilket gjorde att jag kom igång ganska snabbt. Den gamla GUI applikationen var skriven i C++ (MFC) men de ville att jag skulle skriva om den till .NET miljön. Med hjälp av Windows Forms började jag återskapa samma GUI struktur som den gamla hade. Eftersom mitt GUI skulle interagera exakt likadant som om jag tryckte på självaste MU:n så var det mycket som skulle stämma överens med den verkliga produkten.
Det gamla GUI:t saknade några funktioner som finns i produkten så jag fokuserade på att designa så att jag skulle kunna implementera det i mitt GUI. Det som preliminärt behövde implementeras var följande:
• Stöd för att skriva ut punkter
• Stöd för stora och små bokstäver
• Stöd för att kommunicera med platform‐dll:en
• Stöd för att aktivera vilka debugmeddelanden man vill lyssna på
• Tolka och skicka degubmeddelanden
• Möjlighet att skapa ett GUI som kan lyssna på valfri MUG adress
• Möjlighet att starta en ny instans av MU:n i hostmiljö från GUI:t
• Låta platform‐dll:en hålla koll på vilka GUI:n som skapats och vilka MUG: adresser de kommunicerar med.
Jag använde mig av Visual Studio .NET miljön och C++/CLI med Windows Forms för att skapa mitt GUI med en del placeholders för bilder så att programmet/GUI:t ska se så autentiskt ut som möjligt. GUI:t kan endast köras på Windows datorer då det är vad majoriteten på företaget använder som operativsystem, vilket gjorde att jag inte behövde lägga ner någon energi på att försöka göra GUI:t plattformsoberoende.
Ganska tidigt i utvecklingen stötte jag på en del svårigheter med språket (C++/CLI). Jag sökte en hel del information i Microsofts utvecklingsnätverk (msdn[7]). Vad som gjorde att utvecklingen tog längre tid var den nya syntaxen i språket som jag inte var van vid. C++/CLI innebär en eftersträvan att kunna använda både managed och unmanaged kod, vilket betyder att man ska kunna skriva kod som kan garbage collectas och sådan kod som man måste hantera själv. Garbage collect är en automatisk metod för dynamisk
minneshantering, t.ex när en variabel inte längre används så frigörs det arbetsminne som den variabeln tagit upp när den skapats för att lämna plats åt andra program som då kan använda minnesutrymmet.
Ett exempel på annorlunda syntax kan vara följande då jag försökte deklarera en array som skulle innehålla bitmapsbilder som jag skulle läsa in från en resursfil som finns i projektet.
5
Jag sökte hjälp på ett forum för C++/CLI användare och beskrev mitt problem nedan:
1 private: array<System::Drawing::Bitmap^)^ m_MyBmpArray;
2 m_MyBmpArray = gcnew array<System::Drawing::Bitmap^)(10);
3 m_MyBmpArray[0]->FromFile(filename);
Denna tilldelning kunde inte användas då det visade sig att jag försökte hämta ut information från index 0 i min array och inte sätta den till ett värde, som jag trodde att jag gjorde. Detta löstes emellertid genom att skapa en temporär variabel som fick tillhandahålla informationen om bilden för att sedan spara variabeln på önskad plats i min array. Ur denna lösning uppstod ett nytt problem: Hur kan man lägga in
bitmapsinformationen i variabeln?
För att spara bitmapsinformationen i variabeln kunde jag använda FromResource() funktionen för att hämta data från resursfilen och spara den i variabeln. FromResource() behövde en referens till filen vilket jag hade i form av ID‐taggen som filnamn, men även en IntPtr (integer pekare) för att kunna hantera den data som används från resursfilen till mitt program, som jag inte hade. Jag var tvungen att skapa min IntPtr genom att skriva (IntPtr)GetModuleHandleW(0), där W kan bytas ut mot A för ansi kodning eller som nu W för unicode kodning. 0:an betecknar resursfilen som programmet tydligen redan kände till. Den siffran byts då ut mot en annan siffra om man har flera resursfiler i projektet.
1 m_Array->FromResource((IntPtr)GetModuleHandleA(0), "IDB_BITMAP_16_SEGMENT_0" );
Jag fortsatte att använda C++/CLI tills jag stötte på ett problem som jag inte lyckades hitta någon direkt lösning på, vilket resulterade i att jag bytte språk till C# (.NET) ungefär efter halva utvecklingstiden. Det tog mig ungefär 2 dagar att byta från C++/CLI till C#. Jag har aldrig tidigare programmerat i C# men det skiljer sig inte så mycket syntaxmässigt från C++/Java.
Indelning av arbetet
Jag började med att utveckla GUI:t för att senare ta mig an blåtandssimuleringen vilket visade sig vara svårare att simulera än jag trodde. Efter lite undersökning så visade det sig att man skulle kunna simulera blåtanskommunikation i Linux. Då jag inte hade tillgång till en dator med Linux installerat fick jag leta efter en alternativ lösning. Jag kom fram till att jag skulle kunna programmera en server som använder sig av sockets och skickar bluetoothkommandon över socketen.
Grafiskt användargränssnitt Interface mot CAN
För att kunna ta del av de debugmeddelanden som skickas över CAN från MU:n så använde jag den
platforms dll som utvecklats här på företaget, dock fick jag göra en del förändringar i koden för dll:en så att den skulle kunna kommunicera med mitt GUI. Till en början användes pytonscript för att aktivera vilka debugmeddelanden som man vill lyssna på, detta sköts numera via platforms dll:en.
Platforms dll:en fungerar som ett lager mellan mitt GUI och de produkter som kan vara inkopplade på CAN nätverket. Fördelen med att använda dll:en är att gamla/framtida program kan utnyttja samma dll för liknande ändamål. Dessutom, om något måste uppdateras så behöver man bara ändra på ett ställe för att alla andra ska bli uppdaterade.
6
Layout av GUI:t
Layouten var ganska så rättfram vilket framgår av bilden i figur 1. Dock var jag tvungen att ta reda på hur jag skulle kunna interagera med MU:n genom att klicka på knapparna som finns på den.
Jag fick ett dokument med diverse
debugmeddelanden av min handledare, där han förklarade att de id:n samt argument som finns i dokumentet är de som de använder för att skicka och ta emot information till och från
mjölkenheten. Det som då återstod var att tänka ut hur jag skulle kunna skicka dessa kommandon via knapptryckningar till mjölkenheten, samt tolka de debugmeddelanden som kommer in till mitt GUI från mjölkenheten.
Lösningen var att använda mig av platform dll:en för att skicka mina meddelanden samt ta emot de debugmeddelanden som den skickade till mig.
Bild på mjölkenhet. Figur 1
7
Bilder
För att kunna editera de bilder som jag hade till hands använde jag mig av gratisverktyget GIMP 2[4]. Det har stöd för många olika filformat vilket passade mig ganska bra då jag behövde konvertera från jpg/gif till bmp och fortfarande behålla bildkvaliteten.
Simulering av bluetooth
För att kunna efterlikna Bluetooth utan att använda en bluetoothdongle så finns det lite olika alternativ, varav ett är att skicka all information över sockets. Även här finns det några olika metoder att använda. Den första som jag stötte på när jag letade information om hur jag skulle göra var att använda Linux och några av operativsystemets nätverkhanteringsprotokoll. Då jag som sagt inte hade tillgång till en dator med Linux letade jag efter möjligheten att simulera Linux på en dator med Windows genom att använda Cygwin[5] och något som heter BlueHoc[6].
Det tredje alternativet jag undersökte var att skriva en egen server som tillhandahåller socket
kommunikationen och som agerar som en bluetoothmodul. För att uppnå detta sökte jag i msdn[7] och fann några exempel som var till stor hjälp och jag beslutade mig för att använda dessa exempel som grund för min bluetoothmodulsimulering.
8
Ex. utskrift av init 1
Ex. utskrift av frånkoppling 1
Servern använder sig av 2 olika sockets, en för att skicka data på och en för att kunna skicka kommandon till servern så man t.ex kan koppla ner en pågående datakoppling. För att detta skulle vara möjligt behöver den ett sätt att hålla reda på vilka sockets som hör till vilken enhet. Detta görs genom att ta reda på deras adresser som de är kopplade med och para ihop dessa i ett dictionary. Dictionaryt består av en nyckel och ett värde där värdet till exempel kan vara en klass som har 2 sockets. Nyckeln är enheternas unika
bluetoothadress och med hjälp av denna kan man då para ihop de två olika sockets som en enhet är kopplad med.
9
Resultat
Jag har lyckats skapa ett fungerande användargränssnitt som kan styra MU:n via en dator. Det är även möjligt att starta flera instanser av MU:n på en och samma dator. Detta möjliggör att man då kan starta igång en simulation av ett mjölkpass med flera mjölkenheter samtidigt som information även ska skickas till WPU:n. I det nya system som håller på att utvecklas på företaget ska det finnas flera WPU:er som
mjölkenheterna ska kunna koppla sig till för att skicka sin information samt ta emot förslag på nästa ko att mjölka m.m, detta görs idag med endast en WPU. Med hjälp av detta nya användargränssnitt kan
vidareutvecklingen av systemet fortskrida snabbare än tidigare då möjligheten att se och avhjälpa eventuella fel som dyker upp under simuleringens gång förbättras.
Servern, som agerar som det bluetoothchip som finns monterat på alla mjölkenheter och WPU:er, kan ta emot och svara på kommandon som skickas till den. Det som inte fungerar är kopplingen mellan en WPU och en mjölkenhet, dvs. när en mjölkenhet försöker koppla upp sig till en viss adress så skickas förfrågan via bluetoothchippet, i detta fall simuleringsservern. Mjölkenheten kopplas sedan ihop med en WPU och överföring av mjölkrapporter etc. sker. Denna koppling mellan mjölkenhet och WPU fungerar inte i servern i dagsläget.
10
Användargränssnittet
Reslutatet här är ett nytt och mera funktionellt användargränssnitt än det som tidigare fanns.
Detta innebär att all den funktionalitet som fanns i det tidigare programmet också finns i mitt program, men med de extra funktionerna av att kunna:
• Skriva ut exaktare värden med hjälp av punktnotationer
• Lyssna på valfri MUG adress
• Instansiera flera mjölkenheter i hostmiljö med hjälp av GUI:t
• Aktivera vilka debugmeddelanden man vill lyssna på
• Skriva meddelanden i både stora och små bokstäver
11
Bluetoothservern
Servern agerar och svarar på den fördefinierade initieringssekvensen, precis som om det hade varit ett bluetoothchip som sitter på mjölkenheten eller WPU:n. Ovan är en exempelutskrift av hur det ser ut när en enhet kopplar sig till servern och börjar skicka initieringskommandon till den. Enheter kan koppla sig till bluetoothservern och skicka kommandon. Dock fungerar det inte att kommunicera mellan två (eller flera) olika enheter via servern då denna koppling ej finns implementerad.
12
Diskussion
Jag tycker att jag har lyckats med att skapa ett fungerande program baserat på den uppgift som ålagts mig.
Det är möjligt att starta flera instanser av GUI:t på en och samma dator för att kunna simulera ett mjölkpass med fler än en mjölkenhet och därigenom snabbare kunna avhjälpa eventuella fel som uppstår. Om jag hade haft mer tid på mig hade jag även kunnat få igång bluetoothsimuleringen till en acceptabel nivå. Som det är idag kan man endast koppla sig till servern och köra en initiering.
Jag är nöjd med den struktur på koden som används för mjölkenhetens GUI, men strukturen på koden för bluetoothsimuleringen kunde ha varit bättre. Hade jag tidigare börjat undersöka hur kommunikationen skulle ske i bluetoothservern hade jag kanske fått en mer användbar server idag. En klar fördel hade varit om vi hade varit två personer som arbetat på samma projekt. Då hade man kunnat dela upp arbetet och därigenom fått en bättre kvalitet på samtliga lösningar.
Framtida förändringar
Användargränssnittet
Eventuell vidareutveckling av programmet skulle inte skada så att man från applikationen även kan styra värden som mjölkmätaren skickar till mjölkningsmaskinen. Detta för att simulera en ko som antingen har ett för lågt mjölkflöde eller ett för högt flöde. Därefter ska mjölkmaskinen agera enligt de regelverk som finns uppsatta för vad som ska ske.
Till exempel om mjölkflödet är för lågt i början av mjölkningen så kan det tolkas som att mjölkningskurvan är i slutskedet av mjölkningen och då skall maskinen sluta mjölka och larma. Detsamma gäller vid för högt mjölkflöde för tidigt i mjölkningen.
Bluetoothservern
Servern behöver vidareutvecklas i och med att den inte är fullständig, men även i utvecklingsfasen finns det en och annan implementering som skulle kunna göras bättre. Man skulle kunna göra koden mer
lättöverskådlig för programmerarna.
Summering
Jag har lyckats skapa ett fungerande användargränssnitt som tolkar och skickar kommandon över CAN till en WPU och berikat den med ytterligare funktioner för att underlätta debuggning och vidareutveckling av produkten. Jag har delvis lyckats med att få igång en fungerande bluetooth simuleringsserver om än visst arbete kvarstår för att den ska fungera som det är tänkt.
13
14
Referenser
1. Ezurio dokumentation ‐ http://www.tdksys.com/products/at/ (20081014) 2. Kvaser Virtual CAN Driver ‐ http://www.kvaser.com/
Developer>Downloads (Top 10 Downloads) Drivers for Windows (20081014) 3. Kvaser CanKing ‐ http://www.kvaser.com/
Developer>Downloads (Top 10 Downloads) Kvaser CanKing (20081014) 4. GIMP The GNU Image Manipulation Program – http://www.gimp.org/
5. Cygwin, en Linux liknande miljö för Windows‐ http://www.cygwin.com/ (20081030) 6. BlueHoc, simulering av bluetoothtrafik i Linux‐ http://bluehoc.sourceforge.net/ (20081030) 7. MSDN, Microsoft Developer Network http://www.msdn.com/ (20081103)
