EXAMENS
ARBETE
Uppkoppling av frekvensomriktare mot internet
Sara Amani och Ludwig Weddig
I dagens industri växer efterfrågan på att kunna övervaka och interagera med industriella maskiner utan att vara i närheten. Detta för att kunna upptäcka maskinfel i god tid och underlätta underhåll och service .
Företaget HMS Industrial Networks AB jobbar idag med kommunikation mellan industriella maskiner och vill ta fram nya Internet of Things-lösningar.
Projektets mål är att kunna läsa ut frekvensomriktaren ATV32:s parametrar och visualisera dessa i en webbläsare med hjälp av molntjänsten ThingWorx. Detta genom att skapa en trådlös kommunikation mellan frekvensomriktaren och en gateway som skickar vidare parametrarna till internet.
Resultatet av projektet visar att det är möjligt att koppla upp frekvens-omriktaren mot internet med hjälp av trådlös radiokommunikation mellan frekvensomriktaren och en persondator samt visualisering med ThingWorx. Projektet uppfyller därför sitt syfte och mål.
Den systemprototyp som skapats bevisar att uppkopplingen är möjlig och kan användas för framtida utveckling av liknande system.
Industrial companies are investigating the possibility of monitoring as well as controlling and interacting with industrial machines remotely, in order to be able to detect errors in time to avoid downtime due to maintenance and servicing.
HMS Industrial Networks AB is a company works with communications between industrial machines and new IT-solutions. They presented a project whose goal was to read parameters from the ATV32 drive in order to provide visual data in a GUI. The GUI is a web based cloud service called Thing-Worx. In order to achieve the desired results, wireless communication has to be setup between the drive and a gateway in order to send the parameters to the Internet.
The project results have been successfully achieved by connecting the dri-ve to the Internet through a gateway in a PC. The connection was achiedri-ved with radio communication and the data is visualized in ThingWorx. The team have therefore fulfilled the purpose and goals of the project.
The prototype that has been made, demonstrates how the connection can be implemented and the project can be used as a basis for further develop-ment.
Projektet har varit väldigt lärorikt och gett oss mer kunskap inom vårt ut-bildningsområde. Det har även gett oss en chans att faktiskt känna hur det är att arbeta på ett företag och hur deras arbetssätt fungerar.
Vi vill tacka vår handledare Emil Nilsson, universitetsadjunkt på Halm-stad Högskola och Omid Manikhi, HMS, för handledning under projektets gång.
Vi vill även ge ett stort tack till Erik Halvordsson, HMS, för vägledning och stöd genom hela projektet. Det har varit ett väldigt roligt projekt att arbeta med.
1 Introduktion 1
1.1 Syfte och mål . . . 1
1.2 Frågeställningar . . . 2
1.3 Avgränsningar . . . 2
2 Bakgrund 3 3 Material och metoder 5 3.1 Komponenter . . . 5 3.2 Programspråk . . . 8 3.3 Kommunikationsprotokoll . . . 9 3.4 Visualisering . . . 11 3.5 Arbetssätt . . . 11 3.6 Delsystem 1: Parameterutvinning . . . 12 3.7 Delsystem 2: Dataöverföring . . . 18 3.8 Delsystem 3: Parametervisualisering . . . 22 3.9 Analys av resultat . . . 22 4 Resultat 23 4.1 Datautvinning . . . 23
4.2 Dataöverföring och parametervisualisering . . . 31
5 Diskussion 39 5.1 Datautvinning . . . 39
5.2 Dataöverföring och parametervisualisering . . . 40
6 Slutsats 43 7 Referenser 45 8 Bilagor 49 8.1 Bilaga A - Kravspecifikation . . . 49 8.2 Bilaga B - Testspecifikation . . . 61 8.3 Bilaga C - Tidsplan . . . 77 8.4 Bilaga D - Kretsschema . . . 81 8.5 Bilaga E - Startrutin . . . 85
1 Överblick på hur systemet kommer vara uppbyggt. . . 1 2 På sidan syns de ytmonterade pinnarna och i nedre
högerkan-ten sitter kontakhögerkan-ten där en extern anhögerkan-tenn kan kopplas på.[1] . 5 3 Freescales plattform FRDM-K64F.[2] . . . 7 4 I bilden visas HMS plattform Netbiter.[3] . . . 7 5 Ett exempel på en förfrågning och respons.[4] . . . 10 6 Meddelandet skrivs hexadecimalt och varje byte står för två
hexadecimala nummer ex: A3. . . 11 7 Systemuppbyggnad . . . 12 8 Flödet från delsystem 2 till ATV32 och tillbaka. . . 13 9 Tabellen visar alla pins på kontakten och vad dom är
koppla-de till. (1) Modbus signaler, (2) matningsspänning för RS-232 eller RS-485 om man vill driva dessa via kabeln och (3) reser-verad för CANopen moduler.[4] . . . 13 10 En exempelkoppling över hur en transceiver kopplas samman
med en ATV32 drive som slave. Överst i rött är en master och vad som behövs för att bygga en sådan. I mitten i svart är kommunikationslinjen där det kan kopplas in slave-enheter med termineringsresistorer i varsin ända. Underst i blått syns slaves numrerade från 1-n.[4] . . . 14 11 LTC1480CN8 med pinkonfigurering. . . 15 12 En grafisk förklaring av hur en CRC-kontroll går till. . . 17 13 Mirameddelanden kommer in i MCU:n från Miramodulen och
skickas ut till RS-485 som Modbusmeddelanden. Sedan kom-mer Modbusmeddelanden in i MCU:n från RS-485 och skickas ut till Miramodulen som Mirameddelanden. . . 18 14 En överblick över delsystem 2 som består av en Miramodul
och en gateway som överför information mellan ThingWorx och delsystem 1. . . 19 15 Gatewayen implementerad i en PC. . . 20 16 Gatewayen implementerad i en Netbiter. Miramodulen ansluts
direkt till en NetBiter med UART. . . 20 17 Gatewayen implementerad i en Netbiter. Miramodulen kopplas
till en RS-232 transceiver med UART och ansluts till gatewayen. 20 18 En överblick på uppbyggnaden av mjukvaran i gatewayen. . . . 22 19 Kopplingarna mellan MCU:n FRDM-K64F och driven ATV32. 24 20 Kopplingarna mellan MCU:n FRDM-K64F och Miramodulen. 25 21 Footprintet för 8 Pin DIP socket. . . 25 22 Symbol-representationen av 8 Pin DIP socket. . . 26
kortet. . . 27
24 Slutgiltigt kretskort med komponenter monterade och kretskor-tet ihopkopplat med Freescale FRDM-K64F. . . 27
25 While-loop i main koden som anropar de funktioner som be-hövs för att ta emot meddelande från gatewayen och skicka tillbaka ett svar från driven. . . 29
26 Överst visas ett Mirameddelande och ur detta tas DataSize som är Modbusmeddelandets storlek samt Data som är själva Modbusmeddelandet. På nedersta raden visas strukturen för en mottagen Modbusförfrågning. . . 30
27 Överst visas en Modbusrespons som läggs i Data delen av Mi-rameddelandet. Storleken Modbusmessage Size läggs in i Data Size för att hålla reda på hur mycket data som skickats med. . 31
28 Miramodulen som är kopplad till gatewayen. . . 32
29 Resultatet av uppbyggnaden av delsystem 2. Serieportsnummer kan variera beroende på vilken PC som används. . . 33
30 Skript som används vid konfigureringen av EMS. . . 34
31 Exempel på hur en property initieras till ThingWorx. . . 35
32 Konfigureringsskriptet som används vid start av Lua. . . 36
33 Resultatet av mashupen som visar parametrarna som hämtats från driven. . . 37
34 En överblick på det slutgiltiga systemet. . . 38
35 En grafisk förklaring av hur upplägget i ThingWorx hade kun-nat förbättras. . . 41
MCU Microcontoller unit EMS Edge Micro Server Drive Frekvensomriktare
UART Universal Asyncrounus Receiver/Transceiver ATV32 Altivar32
DIP Dual in-line package CRC Cyclic Redundancy Check
GND Ground
1
Introduktion
De flesta industriella företagen idag använder sig av maskiner av något slag. Dessa maskiner behöver regelbundet service och underhåll. Många indust-riella maskiner som används idag har inte möjlighet att kommunicera med andra maskiner och ännu mindre dela information till internet. När maskiner-na går sönder måste därför en tekniker personligen komma till företaget och lösa problemen. Innan det kan göras något åt problemet måste först orsaken fastställas och även detta leder till tidskrävande resor.
Vid mindre fel kan det finnas tekniker på plats som kan lösa problemen men oftast krävs ett besök av en extern tekniker. Tiden det tar för maskinen att lagas kan variera beroende på omfattning av felet och tillgänglighet av personal. I värsta fall stoppas hela företagets produktion under tiden och detta gör att företaget förlorar tid och pengar.
1.1
Syfte och mål
Distansövervakning med hjälp av en uppkoppling till internet ger möjlighet att smidigare kontrollera maskiners driftstatus. Genom en internetuppkopp-ling kan information om servicebehov och underhåll finnas lättillgängligt för ansvarig personal. Att få ut information fort när service behövs är viktigt för att minska produktionsavbrott. Om maskinernas parametrar övervakas konstant kan också underhåll utföras i förebyggande syfte.
En viktig del i projektet är att få en översikt över processen av att koppla upp en produkt trådlöst mot internet. Med hjälp av denna översikt vill HMS ta fram en produkt som kan användas för flera maskiner, en överblick på hur systemet kommer se ut i detta projekt visas i Fig. 1 nedan. Det kan behövas justeringar för varje fall men målet är att ha en så stor gemensam process som möjligt. Slutligen kommer projektet bli en prototyp som kan användas som bevis på att uppkopplingen är genomförbar och dess mervärde. För specifika mål se bilaga “Kravspecifikation”.
1.2
Frågeställningar
• Vilken utrustning och programspråk ska användas för att kunna läsa av parametrarna från frekvensomriktaren?
• Vad kommer att behöva implementeras i den molnapplikation som kom-mer användas för visualiseringen?
• Hur ska parametrarna skickas från den trådlösa modulen till molnap-plikationen?
1.3
Avgränsningar
Endast en produkt kommer kopplas upp mot internet, frekvensomriktare Schneider Electric Altivar 32. Vid projektets start togs beslutet att använ-da frekvensomriktaren ABB ACS350. Detta ändrades till Schneider Electric Altivar 32 på grund av att dokumentation för parameterutvinning fanns till-gänglig, till skillnad från ACS350 som saknade detta. Förundersökningen som gjordes på ABB och dess tillhörande produkter finns i Bilaga F.
2
Bakgrund
Intelligent Healthcare Service by using Collaborations between IoT Personal Health Devices
Detta projekt handlar om mätning av specifika värden hos människor som skickas till medicinska experter och patienter för utvärdering [5]. Värdena mäts med hjälp av en personlig sjukvårdsenhet och skickas vidare till en server med hjälp av trådlöst sensornätverk. Sensornätverket använder sig av radiovågor för att skicka data till en mottagare som sedan kan skicka detta vidare till en dator via tele- eller datakommunikationsnät.
Dataöverföringen i vårt projekt kommer likna det som används i detta projektet. Värden kommer att skickas till en server med radioteknik. Det som skiljer sig är att värdena i vårt projekt ska visualiseras grafiskt i en webbläsare.
A reconfigurable smart sensor interface for industrial WSN in IoT environment
Detta projektet handlar om att koppla upp ett industriellt WSN (Wireless Sensor Network) till IoT (Internet Of Things) på ett nytt sätt [6]. Tidigare problem har varit antalet anslutna enheter, samplingsfrekvens och signalty-per från sensorer som varit väldigt begränsade. Genom att designa ett om-konfigurerbart smart-sensor-gränssnitt för industriellt WSN i IoT-miljö med en CPLD (Complex Programmable Logic Device) så ska dessa problem lösas. Detta projektet hade problem med antalet anslutna enheter. För att und-vika detta i vårt projekt kommer radiomoduler med ett självläkande nätverk att användas.
Modbus/Bluetooth Gateway
Detta projekt handlar om att möjliggöra trådlös kommunikation med indust-riella maskiner [7]. Genom att skapa små billiga moduler som kan kommu-nicera med Modbus via bluetooth ger det möjlighet att övervaka maskiner utan att vara i fysisk kontakt med dessa, som kanske även är svåråtkomliga eller används i en farlig miljö.
I ‘Modbus/Bluetooth Gateway’-projektet används kommunikation med Modbus, RS485 och UART vilket är intressant då dessa standarder kommer att användas för kommunikation med ATV32.
3
Material och metoder
En förundersökning har gjorts på nedanstående komponenter och mjukvaror. Utefter denna har material samt metoder valts, dessa presenteras i kapitel 3.6, 3.7 och 3.8.
3.1
Komponenter
Schneider Electric Altivar 32
Frekvensomrikaren Altivar 32 är gjord för styrning av asynkrona och syn-krona motorer [8]. Den har integrerade säkerhetsfunktioner och PLC samt passar bra i applikationer till industriella maskiner. Användningsområden är till exempel hissanordningar, textilmaskiner och andra materialhanterings-maskiner. För kommunikation används oftast CANopen eller Modbus.
LumenRadio Mira
LumenRadio är världsledande inom trådlösa styrsystem [9]. De har nu lan-serat den ytmonterade modulen Mira som används till att skapa storskaliga IoT-lösningar för alla sorters enheter. Uppkopplingen kan göras mellan ma-skiner och mellan mama-skiner och applikationer. Plattformen är pålitlig, har högklassig radioprestanda och är väldigt enkel att implementera. Modulen har måtten 2x3cm och har en kontakt för en extern antenn som visas i Fig. 2 nedan.
Figur 2: På sidan syns de ytmonterade pinnarna och i nedre högerkanten sitter kontakten där en extern antenn kan kopplas på.[1]
Mira arbetar inom frekvensområdet 2.4 GHz och är ett mesh-nätverk [10] som kan användas i starkt belastade trådlösa miljöer upp till 200m inomhus och 1000m utomhus. På grund av LumenRadios patenterade teknologi väljer radionätverket den lämpligaste radiofrekvensen beroende på annan radioak-tivitet i området, detta för att inte dela frekvens med andra enheter.
RS-485 Transceiver
RS485 är en halvduplex (kan inte skicka och ta emot samtidigt) sändare/ mot-tagare för seriella databussar och fungerar som en slags switch som bestäm-mer åt vilket håll informationen ska skickas [11]. Till exempel i ett system uppkopplat med en master-enhet och en eller flera slave-enheter. Mastern beslutar om den ska skicka till eller ta emot information från slave-enheterna med hjälp av RS485.
RS485 har en känslighet på +/-200mV där en logisk 0 är större än +200mV och en logisk 1 är mindre än -200mV. På så sätt försvinner brus som är mind-re än 200mV. På utgången ligger nivån typiskt mellan +/-1,5V och +/-6V. Kabellängd kan vara upp till 1200m och den har en överföringshastighet på upp till 10Mbit/s vid maxlängd.
RS-232 Transceiver
RS232 är en helduplex (kan både skicka och ta emot data samtidigt) sän-dare/mottagare för seriella databussar. RS232 har en känslighet på +/-3V vilket gör att brus ända upp till 3V ignoreras. Vanligtvis ligger en logisk 1 mellan -5V och -15V samt en logisk 0 mellan +5V och +15V. Kabel längd kan vara upp till 15m och har en överföringshastighet upp till 20kbit/s vid maxlängd. [12]
Freescale FRDM-K64F
Freescale FRDM-K64F är en utvecklingsplattform med väldigt låg kostnad som passar till mikrokontrollerna Kinetis K64, K63 och K24 [13]. Dess kring-utrustning inkluderar magnetometer, 6-axlig digital accelerometer, trefärgad LED, två knappar för direkt interaktion, plats för microSD-kort, Ethernet-port, Bluetooth och 2.4 GHz radiomoduler.
Mikrokontrollern har en inbyggd seriell- och felsökningsadapter, OpenS-DAv2 [14] som kan kopplas till en dator eller annan USB-enhet för flashpro-grammering, felsökning eller seriell kommunikation.
Figur 3: Freescales plattform FRDM-K64F.[2]
Netbiter
Netbiter är en komplett fjärrstyrningslösning som gör det möjligt att moni-torera och kontrollera utrustning på nätet. Det går att få alarm vid fel och även hantera och konfigurera utrustningen via en vanlig dator eller smartp-hone. Denna möjlighet gör att företag kan minska kostnader för service och underhåll.
3.2
Programspråk
JavaJava är ett samverkande [15], objektorienterat och klassbaserat program-språk [16]. Det är utformat så att en kompilerad Java kod kan köras på alla plattformar som stödjer Java utan att behöva kompilera om programmet.
Språket är ett av de populäraste i världen, särskilt vid klient-server web-bapplikationer. Det är väldigt influerat av C och C++ men har inte lika många möjligheter för lågnivåspråk som dem. I Java är också multipla arv av klasser förbjudet, vilket är tillåtet i C och C++. Däremot kan en klass använda sig av flera gränssnitt (eng. interface).
De färdiga biblioteken och datastrukturerna som finns för Java är en stor fördel med språket.
C
C gavs ut 1972 och är idag ett av världens mest använda språk [17]. Det är ett imperativt programspråk som innebär att programmen byggs upp av kommandosekvenser [18]. C är gjort för strukturerad programmering där koden ska vara organiserad i avskilda block och undvika GOTO-satser [19].
Det finns många möjligheter för lågnivåspråk och nästan alla plattformar har C-kompilatorer.
C++
C++ är grundat på programspråket C men stödjer även objektorienterad programmering [20]. C++ är som Java och C ett av de populäraste pro-gramspråken och C++ har i många fall ersatt C. Det används i allt från datorspel till konsumentelektronik. C++ är likt Java när det kommer till klassbegreppet men skillnaden är att man i C++ kan ärva multipla klasser. Något användbart som C++ använder sig av är templates. En template bygger på att återanvända kod för olika datatyper för att undvika hårdkod-ning. Några standardtemplates är till exempel tabeller, köer och listor för olika datatyper som heltal, flyttal och strängar med mera.
Mbed
Detta verktyg är skapat av ARM för användning i IoT-lösningar [21]. Mbed består av en stor mängd utvecklare, öppen IoT-källkod, tjänster för IoT och samarbete med hårdvaruutvecklare. Med hjälp av mbed kan projekt enkelt
skapas med specialanpassade bibliotek för önskad plattform. Det går att vända deras kompilator online men det går också att installera SDK för an-vändning av andra utvecklingsmiljöer. Ett påbörjat projekt online kan även exporteras till andra utvecklingsmiljöer.
Lua
Lua är ett kraftfullt skriptspråk som är inbäddningsbart. Språket kombinerar procedurell programmering med bland annat möjligheten för datastrukturer baserade på associativa arrayer [22]. Lua skrivs dynamiskt och körs genom att tolka bytekod för en registerbaserad virtuell maskin. Detta är ett idealt språk för konfiguration och så kallad rapid prototyping på grund av den automatiska minneshanteringen och inkrementell garbage collection.
Lua går att integrera med andra programspråk som till exempel C, C++ och Java genom att använda bibliotek skrivna i andra språk eller implemen-tera Luaskript i ett annat språk.
3.3
Kommunikationsprotokoll
UART
UART står för Universal Asynchronous Receiver / Transmitter och är en hårdvara som ger funktionen att kunna göra om parallell data till seriell data och tvärtom [23]. UART gör om informationen och skickar den en bit i taget. Varje meddelande startar med en start bit och avslutas med en stopbit så att den vet när nästa meddelande kan börja skickas eller tas emot. Några standarder som använder sig av UART är RS-232, RS-422 och RS-485 som har en linje TX för transceive och en linje RX för receive.
SPI
SPI står för Serial Peripheral Interface och är ett bus interface som ofta används av microcontrollers, SD-kort och sensorer. Till skillnad från UART så är SPI en synkron data buss vilket innebär att den har en separat linje för klockfrekvensen för att hålla båda sidor av kommunikationen synkroni-serade. SPI använder sig av fyra linjer för att etablera sin kommunikation. SCK(Serial Clock), MOSI(Master In Slave Out), MISO(Master In Slave Out) och SS(Slave Select) [24].
Modbus
Modbus är ett kommunikationsprotokoll som ursprungligen är framtaget av företaget Modicon, som nu mera heter Schneider Electric [25]. I dagsläget finns det ett par olika versioner av Modbusprotokoll för både seriell- och ethernetkommunikation. Modbus definierar ett PDU (Protocol Data Unit) som innehåller den funktion som ska utföras och den data som ska skickas. PDU läggs i en ADU (Application Data Unit) som innehåller en adress till den enhet som protokollet ska skickas till samt en felkontroll.
Modbus används genom att en klient skickar ett kommando och given data till adressen för en enhet. Enheten gör då en felkontroll för att förhindra att korrupt data används och skickar sedan tillbaka efterfrågad data. Ett exempel på uppbyggnaden av ett Modbusmeddelande visas i Fig. 5 nedan. Dessa används för funktionen Read Holding Registers som kan anropas för att läsa av register från ATV32.
Figur 5: Ett exempel på en förfrågning och respons.[4]
Mira
Miramodulen kommunicerar med hjälp av LumenRadios egna Miraprotokoll. Ett protokoll som skickas till modulen via UART där modulen sedan skickar tillbaka ett bekräftelsemeddelande att den fått ett korrekt meddelande.
Figur 6: Meddelandet skrivs hexadecimalt och varje byte står för två hexa-decimala nummer ex: A3.
3.4
Visualisering
ThingWorxThingWorx är en IoT-mjukvara som kan användas för att bygga och köra applikationer för internetuppkopplade enheter [26]. Mjukvaran är unikt ut-formad för att lätt kunna skapa applikationer som representerar enheters datalagring, samarbete med andra enheter, säkerhet och visualisering.
För att representera en enhet i ThingWorx skapas en så kallad ‘Thing’ som binds samman med fjärrenheten. Enheter kan även läggas till i efterhand och därför skapas ‘ThingTemplates’ som har olika egenskaper. En egenskap kan till exempel vara ‘hastighet’. Egenskaperna kan sedan ärvas av andra ThingTemplates eller Things.
ThingWorx Mashup Builder är ett ‘drag-och-släpp’-verktyg som används bland annat för att skapa realtidsvisualisering, interaktiva IoT-applikationer och gemensamma arbetsytor utan att behöva koda. Detta verktyg minskar utvecklingstid och ger anslutna applikationer av hög kvalitet som snabbare levererar värdehöjande lösningar.
ThingWorx Edge Microserver
ThingWorx Edge Microserver (EMS), är en server som används för att kom-municera mellan fjärrenheter och ThingWorx-plattformen. Genom att konfi-gurera en gateway med Luaskript på valfri utrustning till exempel en dator, går det att skicka värden från fjärrenheten som ThingWorx sedan visar i realtid.
3.5
Arbetssätt
Arbetssättet kommer att följa en agil systemutveckling i form av metodiken ‘Scrum’ [27]. Detta används av HMS i dagsläget och föreslås av dem att användas i projektet. Där delas projektet upp i delar som sedan delas upp i mindre uppgifter över en veckas period. Genom denna mindre uppdelning fås en överblick på hur projektet ligger i fas till hur mycket tid som finns kvar till deadline.
En kravspecifikation kommer att tas fram tillsammans med kunden och utformas efter dennes behov. Vid godkännande av kunden anses specifikatio-nen vara tillräcklig.
Projektets systemuppbyggnad som visas i Fig. 7 har delats in i tre delsy-stem: • Parameterutvinning • Dataöverföring • Parametervisualisering Figur 7: Systemuppbyggnad
3.6
Delsystem 1: Parameterutvinning
I delsystem 1 ska själva utvinningen av data från driven ATV32 genomföras. Genom att koppla en mikrokontroller i drivens konfigurationsport och skicka in parameterförfrågningar med hjälp av Modbusmeddelanden kommer driven sedan att skicka tillbaka svar, även detta i form av Modbusmeddelanden.
Mikrokontrollern ska alltså ta emot en förfrågan trådlöst från delsystem 2, bearbeta denna så att en Modbusförfrågan kan skickas till driven och sedan skicka tillbaka den utvunna informationen till delsystem 2. De olika delarna som bygger upp hela delsystem 1 visas i Fig. 8 nedan.
Figur 8: Flödet från delsystem 2 till ATV32 och tillbaka.
Hårdvara
Altivar32Schneider electrics frekvensomriktare ATV32 valdes framför ABB:s frekvens-omriktare ACS350 på grund av att det fanns mer kunskap om ATV32 från HMS i form av dokumentation och kunskap om parameterutvinning.
För att koppla in sig i ATV32:s konfigurationsport används en ethernet kabel med RJ-45 kontakt. För användning av Modbus används D1, D0 samt Common som visas i Fig. 9 nedan vilket är det som ska användas i projektet.
Figur 9: Tabellen visar alla pins på kontakten och vad dom är kopplade till. (1) Modbus signaler, (2) matningsspänning för RS-232 eller RS-485 om man vill driva dessa via kabeln och (3) reserverad för CANopen moduler.[4]
RS-485: LTC1480CN8
En RS-485 valdes framför RS-232 av den anledningen att RS-232 endast kan ha en slave till en master och tanken med projektet är alltså att kunna koppla till fler slaves senare och därför ska systemet också vara förberett för detta för att minska problem med att behöva byta ut komponenter.
Att koppla upp en RS-485 transceiver kan skilja sig från system till sy-stem. Termineringsresistorer sitter i varje ände på kommunikationslinjen som visas i Fig. 10 nedan. I figuren syns också polarisationsresistorer vilket en-dast används på master-sidan av linjen. Kopplingen i Fig. 10 är från ATV32:s manual för hur en transceiver ska kopplas till driven.
Kretsen som valdes är en LTC1480CN8 som visas i Fig.11 vilket är en 8 pin DIP krets som innehåller en RS-485 transceiver som ska drivas med en matningsspänning mellan 3-3,6V. Detta eftersom den kommer att drivas av en Freescale FRDM K64F MCU som jobbar inom dessa spänningsnivåer på in- och utgångar. Därav kommer också polarisationsresistorerna skilja sig lite från Fig. 10 då den utgår från en matningsspänning på 5V.
Figur 10: En exempelkoppling över hur en transceiver kopplas samman med en ATV32 drive som slave. Överst i rött är en master och vad som behövs för att bygga en sådan. I mitten i svart är kommunikationslinjen där det kan kopplas in slave-enheter med termineringsresistorer i varsin ända. Underst i blått syns slaves numrerade från 1-n.[4]
Figur 11: LTC1480CN8 med pinkonfigurering.
Freescale FRDM-K64F
FRDM-K64F valdes på grund av att HMS är en kund till Freescale och hade redan använt sig av den tidigare. Den kommer fungera som en nod för att ta emot parameterförfrågningar från delsystem 2 i form av Mirameddelanden och skicka vidare förfrågan som ett Modbusmeddelande till driven. Den ska också kunna ta emot ett Modbusmeddelande från driven och skicka tillbaka det till delsystem 2 via Miramodulen i form av ett Mirameddelande. Detta kommer att ske med hjälp av en applikation som kommer programmeras i MCU:n.
Då både kommunikationen från MCU:n till RS-485 och MCU:n till Mi-ramodulen sker med UART uppfyller också denna MCU kravet på att ha minst två stycken in- och utgångar konfigurerbara för UART. Den har ock-så två stycken separata VCC-pins med 3,3V för spänningsmatning till både RS-485 kretsen och Miramodulen. För att koppla samman alla komponenter och moduler med MCU:n kommer det att behövas konstrueras ett kretskort som kan monteras på MCU:n som en påbyggnad.
Mira
Mira är radiomodulen som kommer att stå för den trådlösa kommunikationen mellan delsystem 1 och 2. Det kommer alltså att sitta en Miramodul som blir konfigurerad som en gateway och då kopplas till delsystem 2 och en Miramodul som konfigureras som en nod och kopplas till delsystem 1. Då
systemet kommer sättas upp med endast en gateway och en nod blir det inte mycket av ett meshat-nätverk, men det kommer finnas möjlighet att ansluta fler Miranodmoduler.
Mira valdes framför andra trådlösa alternativ som till exempel Bluetooth och WiFi då HMS var intresserade att testa LumenRadios radioteknik. Detta för att se hur bra den fungerar att använda i industriella miljöer jämfört med andra alternativ de har testat. Valet av Mira gjordes också på grund av dess räckvidd på 200 meter inomhus till skillnad från WiFi och Bluetooth som har 10 meter. Räckvidd är en viktig faktor då industrier ofta har stora fabriker.
Kretskort
För att kunna konstruera ett kretskort behövs storlek och rätt utformning av alla komponenter. Med hjälp av datablad och PCB Library Expert [28] så skapas ett footprint för varje komponent. För att få ihop alla komponenter behövs också ett kretsschema där alla komponenter kopplas ihop och detta skapas i Cadence OrCAD Capture CIS [29]. När ett kretschema för kretsen skapats behövs det också en kretskortslayout för själva utseendet på kortet som ska tillverkas. Layouten för hur alla komponenter ska sitta och hur stort kretkortet kommer bli skapas då med hjälp av Cadence OrCAD PCB Editor [30].
Mjukvara
Applikationen som ska programmeras på MCU:n FRDM-K64F kommer att göras i programspråket C samt C++. Detta för att kunna använda Mira-modulens protokoll som skrivs i C. Miraprotokollet består bland annat av uppbyggnad av meddelande samt uträkning av CRC. En annan anledning till att C++ valdes är att det tillför mycket funktionalitet i form av funktio-ner och hantering av objekt som inte finns i C. Det går dessutom att använda C kod i C++.
Det som kommer behöva implementeras i applikationen är hantering av Miraprotokoll och Modbusprotokoll.
Miraprotokoll
För Miraprotokoll behövs ett sätt att ta emot inkommande meddelanden som kommer från Miramodulen. När ett meddelande är mottaget behövs en kontroll för att se om hela meddelandet är mottaget samt för att se så att datan inte är korrupt. Kontrollen av meddelandet behöver en funktion som tar in ett meddelande, räknar ut en ny CRC för all data utom CRC:n
som skickades och jämför den nya CRC:n med CRC:n som mottogs. Om båda CRC är lika är meddelandet inte korrupt. Om meddelandet är korrekt behövs också en funktion som plockar ur datadelen ur det meddelande som mottagits vilket kommer vara ett Modbusprotokoll, detta blir då en slags decoder funktion.
Mirameddelanden måste även kunna skapas med hjälp av en slags encoder funktion som tar in den data som ska skickas och sen skapar ett meddelande med tillhörande CRC som kan skickas tillbaka till gatewayen. Upplägget för hur en CRC-kontroll går till visas i Fig. 12. Till detta behövs då även en funktion som kan skicka meddelandet till Miramodulen på rätt sätt.
Figur 12: En grafisk förklaring av hur en CRC-kontroll går till.
Modbusprotokoll
Gatewayen kommer använda sig av Luaskript med en färdigimplemente-rad Modbusstack. För att få ett konsekvent system valdes Modbus framför CANopen för kommunikation mellan mikrokontrollern och frekvensomrik-taren. Fördelen med CANopen är maxhastigheten på upp till 1Mbps till
skillnad mot Modbus 38.4Kbps. Nackdelen med att välja CANopen är att Modbus måste konverteras till CANopen och tvärtom.
För Modbusprotokoll behövs ett sätt att ta det Modbusmeddelande som plockats ur mottagna Mirameddelanden och skicka in detta till RS-485 tran-ceivern som skickar vidare till driven. För att kunna ta emot respons från driven behövs en funktion som tar emot Modbusmeddelanden genom RS-485. Även dessa meddelanden måste genomgå en CRC-kontroll. Det kommer dock behövas en till metod för uträkning av CRC då Modbus och Mira inte har samma uträkningsalgoritm. Om det mottagna meddelandet är korrekt ska det skickas vidare till encoder-funktionen för att läggas in i ett Miramed-delande.
Figur 13: Mirameddelanden kommer in i MCU:n från Miramodulen och skickas ut till RS-485 som Modbusmeddelanden. Sedan kommer Modbusmed-delanden in i MCU:n från RS-485 och skickas ut till Miramodulen som Mi-rameddelanden.
3.7
Delsystem 2: Dataöverföring
HMS vill att plattformen ThingWorx ska användas för att visualisera para-metrarna från driven och därför krävs det att ThingWorx EMS används.
I detta delsystem ska intelligensen ligga för hela systemet. Detta val gjor-des på grund av att det redan finns en Modbusstack för användning med
ThingWorx EMS. Modbusstacken används för att skapa och skicka Modbus-meddelanden och behöver konfigureras innan användning för att få önskade parametrar. Det är också osäkert om mikrokontrollern skulle klara av hante-ringen av intelligensen prestandamässigt.
En gateway ska implementeras och från den kommer kommandon skickas till Miramodulen som skickar vidare detta till delsystem 1, se Fig. 14 nedan. Miramodulen kommer därefter ta emot svaret och värdet skickas med hjälp av gatewayen vidare till delsystem 3.
Figur 14: En överblick över delsystem 2 som består av en Miramodul och en gateway som överför information mellan ThingWorx och delsystem 1.
Hårdvara
Eftersom valet gjordes att använda en Miramodul i delsystem 1 för att kom-municera med delsystem 2 måste ytterligare en Miramodul kopplas in i ga-tewayen. Valet av hårdvara för gatewayen står mellan tre alternativ.
Alternativ 1
Miramodulen kopplas med UART - USB till en Windows PC där gatewayen implementeras enligt Fig. 15. Detta är det enklare och mindre tidskrävande alternativet eftersom ingen ytterligare hårdvara behöver programmeras.
Figur 15: Gatewayen implementerad i en PC.
Alternativ 2
Miramodulen kopplas direkt till en Netbiter med UART där gatewayen im-plementeras, se Fig. 16. Netbiterns UART-kontakt sitter internt och är inte åtkomlig utan att öppna chassit.
Figur 16: Gatewayen implementerad i en Netbiter. Miramodulen ansluts direkt till en NetBiter med UART.
Alternativ 3
Miramodulen kopplas med UART till en RS-232 transceiver och ansluts till en Netbiter där gatewayen implementeras, se Fig. 17. RS-232 kommer användas för att kunna koppla Miramodulen till Netbitern utan att öppna Netbiterns chassi. Valet av RS-232 gjordes för att kommunikationen bara ska ske mellan två enheter och då är RS-485 överflödig och osmidig.
Figur 17: Gatewayen implementerad i en Netbiter. Miramodulen kopplas till en RS-232 transceiver med UART och ansluts till gatewayen.
Alternativ 1 kommer att väljas vid projektets start på grund av att det är mindre tidskrävande. Detta på grund av projektets snäva tidsramar och prioriteten är att få en fungerande slutprototyp. Om det finns tid över vid färdig prototyp kommer alternativ 3 att implementeras och programmet ska då överföras till en Netbiter som har ett Linux-operativsystem. Alternativ 3 är ett bättre val då prototypen blir mindre när en persondator exkluderas från systemet. Programmet ska konfigureras för anpassning till Linuxsystemet. Alternativ 3 valdes över alternativ 2 på grund av att det hade varit mer tidskrävande att öppna Netbitern för att koppla in Miramodulen.
Mjukvara
ThingWorx EMS programmeras med Luaskript och därför valdes Luaskript till hela gatewayen. Möjligheten finns att använda andra programspråk och integrera dessa med Luaskriptet men blandning av programspråk undviks helst då det inte är konsekvent eller optimalt.
För att Miramodulen ska kunna kommunicera med gatewayen via USB krävs en serieportshanterare, översta blocket i Fig. 18 nedan. Denna ska initiera serieporten som ska användas och konfigurera baudhastighet samt eventuell paritet.
När en förfrågning om en parameter ska skickas till driven från gateway-en måste detta Modbusmeddelande bäddas in i ett Mirameddelande. Vid respons från driven behövs Modbusmeddelandet packas upp från Miramed-delandet för att skickas vidare till internet. För detta krävs en Encoder-/Decoder-funktion, se andra blocket i Fig. 18. I denna funktionen ska datan som tas emot från båda hållen först genomgå en korruptionskontroll, genom att göra en CRC-check på både Modbus- och Mirameddelandet.
Gatewayen kommer behöva ett gränssnitt för hantering av Modbusmed-delanden, se tredje blocket i Fig. 18. Det som kommer användas i detta projekt är färdigimplementerat och medföljer i ThingWorx EMS.
EMS behöver ett konfigurationsskript som startar servern där bland annat server host, server port och eventuell kryptering initieras. För att bestäm-ma vilka properties som ska visas i ThingWorx skapas ett skript där dessa deklareras samt vilket skript som ska användas för att ta emot värden på properties, i detta fallet kommer det vara Modbusstacken i tredje blocket.
Figur 18: En överblick på uppbyggnaden av mjukvaran i gatewayen.
3.8
Delsystem 3: Parametervisualisering
Plattformen ThingWorx ska användas för att visualisera parametrarna från driven grafiskt. Detta var ett önskemål från HMS eftersom det redan används på företaget för att visualisera andra enheter.
När ThingWorx EMS har initierats måste själva plattformen konfigureras och anpassas efter enheten. Detta ska göras genom att skapa en Thing och binda den till gatewayen samt binda properties som initierats i EMS till de som skapas i plattformen.
När konfigurationen är klar ska en så kallad mashup skapas där properties i plattformen binds samman med grafiska symboler där värdena uppdateras i realtid. Ett exempel är en hastighetsmätare som visar en acceleration som mäts från driven.
3.9
Analys av resultat
För att verifiera att uppgiften är löst kontrolleras det att projektet uppfyl-ler alla krav i kravspecifikationen och att alla tester i testspecifikationen är godkända.
Det kommer att göras en utvärdering av lösningen och om andra tänkbara lösningar upptäcktes men inte testades under projektets gång, kommer den även att jämföras med dessa.
4
Resultat
Enligt projektplanen fanns det som avgränsning att endast fyra parametrar skulle tas ut. Detta beslut ändrades av kunden då fler parametrar ansågs vara viktiga. Istället tas 17 parametrar ut varav 10 är inaktiva då en drive inte är inkopplad. För en mer specifik överblick av parametrarna se Fig. 33. Ett generellt krav på hela systemet var att frekvensomriktarens paramet-rar ska kunna visualiseras på en webbläsare. Genom att skapa delsystemen nedan uppfylls detta krav. Delsystem 1 och 2 uppfyller kraven att mikro-kontrollern ska kunna skicka och ta emot parameterdata till driven samt att radiomodul 1 skickar vidare data till delsystem 2. Plattformen i delsystem 3 uppfyller kravet att servern ska kunna ta emot data från delsystem 2 och visa dessa på ett grafiskt sätt för användaren. En bild på det slutgiltiga systemet finns i Fig. 34.
För att starta systemet ska en startrutin följas för att serieportarna ska gå igång som de ska. Startrutinen hittas i Bilaga. E.
4.1
Datautvinning
För att utveckla delsystem 1 användes Freescales MCU FRDM-K64F och en applikation programmerades i programspråket C++ med inbäddad C kod. Som utvecklingsmiljö användes Kinetis Design studio med tillgång till debug-möjligheter samt Mbed för att implementera extra funktionsbibliotek. Till detta utformades ett mönsterkort som kan monteras uppe på MCU:n för att bygga ihop det som en enhet och för att ge MCU:n möjlighet att koppla in sig till driven direkt.
Hårdvara
Kommunikation FRDM-K64F till ATV32
För att MCU:n skulle kunna kommunicera med driven med UART användes en LTC1480CN8 krets som innehåller en RS-485 transceiver som gör om sig-nalen så att driven förstår den. Kretsen drivs av 3,3V från MCU:n. Eftersom polarisationsresistorerna i schemat för ATV32-kopplingen i Fig. 10 är till för 5V räknades dessa om och byttes från 650 ohm till 470 ohm.
De komponenter som behövdes till LTC1480CN8 blev två stycken 120 ohm termineringsresistorer som parallellkopplades mellan utgång A och B, en 470 ohm resistor för polarisering av utgång B till GND och en 470 ohm resistor för polarisering av utgång A till 3,3V.
För att kunna styra kommunikationen måste det bestämmas vilket håll signalen ska gå genom transceivern, antingen är DI(Driver Input) inaktiv och RO(Receiver Output) aktiv och då är A och B ingångar. Andra inställningen är att DI är aktiv, RO inaktiv och då är A och B utgångar. RO och DI styrs genom att sätta RE(Receiver Output Enable) och DE(Driver Output Enable) till 0V eller 3,3V. Då RE är inverterad kopplades dessa ihop och styrs med hjälp av en I/O-pin på MCU:n. Sätts styringångarna till 3,3V öppnas transceivern för kommunikation från MCU:n till drivern och sätts styringångarna till 0V öppnas transceivern för kommunikation från drivern till MCU:n.
Figur 19: Kopplingarna mellan MCU:n FRDM-K64F och driven ATV32.
Kommunikation FRDM-K64F till delsystem 2
Kommunikationen mellan MCU:n FRDM-K64F och gatewayen i delsystem 2 sker genom radiokommunikation mellan två stycken Miramoduler som bygger upp ett nätverk. Kommunikationen mellan Miramodulen och MCU:n sker med UART. Miramodulen kopplas med fyra kablar till MCU:n, VCC, GND, TX och RX där VCC är på 3,3V. Kommunikationen mellan Miramodulerna ska helst inte överstiga ett intervall på 0.5 sekunder för att försäkras om att modulerna hinner skicka och ta emot meddelanden korrekt.
Figur 20: Kopplingarna mellan MCU:n FRDM-K64F och Miramodulen.
Kretskort
Footprints för alla komponenter gjordes i PCB Library Expert. Färdiga mo-deller användes till resistorerna och egna momo-deller gjordes för resten av kom-ponenterna (Miramodulen, 8 Pin DIP socket, Stackable headers och RJ-45 kontakt). Programmet skapar alla lager som kan behövas för ett footprint som till exempel soldermask som är ett skyddande resistivt lager och sil-kscreen som skriver ut form och komponentnummer på kretskortet. Nedan i Fig. 21 visas ett av projektets footprints.
Figur 21: Footprintet för 8 Pin DIP socket.
För kretschemat användes OrCAD Capture CIS, även här behövdes det göras en representation av varje symbol22. Detta i form av en rektangel med rätt antal ben för att få alla pinnar att stämma överens med komponentens footprint och efter det koppla varje footprint till sin symbol. För fullständigt kretsschema se Bilaga. D.
Figur 22: Symbol-representationen av 8 Pin DIP socket.
För utformningen av kretskortets layout användes OrCAD PCB Editor. Först skapades en bräda med de mått som skulle användas för kretskortet. Där bestämdes det också hur långt ut mot kanten komponenter får sättas samt en gräns som ledningarna ska hålla sig inom. Måtten på kortet sattes till 55x70mm för att passa på MCU:n FRDM-K64F samt att det valdes ett dubbelsidigt kort. Kretschemat exporteras från Caputre CIS in i PCB Edi-tor med alla footprints och vad alla ben ska vara kopplade till. Slutlig layout visas i Fig. 23 nedan.
Viktig information vid utformningen av layout och placering av komponenter: • För att kretskortet ska kunna monteras på MCU:n måste måtten mellan
alla headers stämma överens med de på MCU:n
• På en viss yta under Miramodulens antenn skulle det undvikas att läggas kopparyta för att försäkra sig om att det inte blir störningar, därför drogs inga ledningar under Miramodulen
Figur 23: Kretskortets layout. Färgen grön visar att det tillhör topp-lagret på kortet och gult visar att det tillhör botten-lagret av kortet.
Beställning av kretskortet gjordes genom Göteborgsföretaget Cogra [31] och slutresultatet visas i Fig. 24.
Figur 24: Slutgiltigt kretskort med komponenter monterade och kretskortet ihopkopplat med Freescale FRDM-K64F.
Mjukvara
Mjukvaran består av två C++ source filer. En kallas functions.cpp där alla funktioner finns skrivna i C++. Den andra kallas main.cpp där allting initieras, till exempel in-/utgångar på FRDM-K64F. I båda dessa filer an-vänds MesssageGenerator.c, MessageDefinitions.c och CRC16.c för hanteringen av Mirameddelanden. I main ligger while-loopen som visas i Fig. 25 nedan. Där anropas alla funktioner som bygger upp programmets inläsning av meddelanden och vidarebefodran av dessa.
Först inväntas ett meddelande och sedan kontrolleras det så det är kor-rekt. I kontrollen undersöks det om varje meddelande startar på rätt adress eller startcharacter som kommer vara den första byte som kommer in. Om första byten är rätt läses den byte som innehåller information om storlek på den data som skickats med. På detta sätt räknas det skickade meddelandets längd ut och hur många bytes som ska tas emot. Meddelandet sparas undan i en array där en byte ligger på en plats.
När meddelandet har lästs in skickas det till Decodern. Modbusmedde-landet som tagits ut skickas vidare till driven och programmet lägger sig och väntar på ett svar. Vid respons från driven kontrolleras det så att det är rätt startbyte. Svaret från driven sparas undan i en array precis som Miramedde-landet och längden av svaret sparas undan i en variabel som därefter skickas in i Encodern och vidare till Miramodulen.
Figur 25: While-loop i main koden som anropar de funktioner som behövs för att ta emot meddelande från gatewayen och skicka tillbaka ett svar från driven.
Decoder
I Decoder sker avkodningen från Miraprotokoll till Modbusprotokoll. Först sker en CRC-kontroll så att inte meddelandet blivit korrupt när det skickats. Blir meddelandet inte godkänt av CRC-kontrollen skrotas det och program-met börjar lyssna efter ett nytt meddelande. Om meddelandet däremot blir godkänt tas data delen ut ur Mirameddelandet som blir det Modbusmedde-lande som ska skickas vidare in i driven.
Figur 26: Överst visas ett Mirameddelande och ur detta tas DataSize som är Modbusmeddelandets storlek samt Data som är själva Modbusmeddelandet. På nedersta raden visas strukturen för en mottagen Modbusförfrågning.
Encoder
I Encoder sker skapandet av ett nytt Mirameddelade med den Modbusre-spons som mottagits från driven. Encoder använder sig utav den C-kod som LumenRadio implementerat och de parametrar som tas in i metoden är ett Modbusmeddelande i form av en array och dess längd. Detta tillsammans med en tom array skickas sedan vidare in i MessageGenerator.c som skapar ett Mirameddelande och lägger den i den medskickade tomma array-en. Funktionen skickar tillbaka meddelandets längd och meddelandet skickas till Miramodulen.
Figur 27: Överst visas en Modbusrespons som läggs i Data delen av Mira-meddelandet. Storleken Modbusmessage Size läggs in i Data Size för att hålla reda på hur mycket data som skickats med.
4.2
Dataöverföring och parametervisualisering
Eftersom delsystem 2 och 3 konfigureras samtidigt har resultatdelen för dessa system lagts ihop.
Gatewayen implementerades i en PC och Miramodulen kopplas till PC:n via UART-USB, se Fig. 28. Den svarta antennen används för att få bättre räckvidd.
Figur 28: Miramodulen som är kopplad till gatewayen.
Serieporten för Miramodulen hanteras i en C++ applikation. I metod val-des Luaskript för hela gatewayen men detta ändraval-des till att använda C++ för Mira-frame Encoder/Decoder. Detta för att det skulle bli mer tidskrävan-de att göra tidskrävan-det i Luaskript. En Mira-frame Encotidskrävan-der/Decotidskrävan-der gjortidskrävan-des först i delsystem 1 och liknande program användes i gatewayen. För en ingående förklaring av hur den fungerar se 4.1. Skillnaden mellan dem är att i detta delsystem initieras även serieportar för kommunikation med Miramodulen och en virtuell port som går till Luaskriptet. Det finns även två trådar som körs parallellt för att kunna skicka och ta emot data samtidigt.
Luaskriptet och C++ applikationen kommunicerar med två virtuella se-rieportar med en brygga emellan, se Fig. 29 nedan. Programmet som används för att skapa virtuella portar är Free Virtual Serial Ports från HHD Software [32].
Figur 29: Resultatet av uppbyggnaden av delsystem 2. Serieportsnummer kan variera beroende på vilken PC som används.
Konfiguration av ThingWorx och ThingWorx EMS
I ThingWorx manual på nätet medföljer exempelskript på konfiguration av EMS och ThingWorx med Modbus. Dessa användes och anpassades efter projektet.
ThingWorx EMS behöver ett konfigureringsskript som används vid start av servern. I detta skript anges serverinformation och vilken gateway som ska användas för att kunna skicka data till ThingWorx plattformen, se Fig. 30 nedan.
Figur 30: Skript som används vid konfigureringen av EMS.
För hantering av Modbusmeddelanden används ett färdigimplementerat RESTful [33] API, Modbus_handler.lua. Skriptet kräver vid start en initiering av serieporten som ska användas. Det finns även andra valbara konfigurationsparametrar men den enda som används i detta projekt är baud-hastighet.
En frågeställning till projektet var vilka Templates och Things som ska skapas i ThingWorx. Då bara en drive används i projektet var det inte nöd-vändigt att skapa Templates, endast en Thing som representerar driven, Ed-geThing.
De parametrar som ska hämtas från driven måste deklareras för ThingWorx-plattformen vilket görs med hjälp av filen modbusExample.lua. Denna fanns med som exempel i manualen och anpassades efter de parametrar som specificerats i sektion 1.3. Ett exempel på hur en property initieras visas i Fig. 31.
Figur 31: Exempel på hur en property initieras till ThingWorx.
När Lua ska köras igång behöver även den en konfigureringsfil. I denna anges serverinformation, inloggningsinformation till ThingWorx, att EdgeT-hing ska använda skriptet modbusExample.lua och initiering av
Figur 32: Konfigureringsskriptet som används vid start av Lua.
Mashup
Eftersom en motor inte har varit inkopplad i driven i detta projekt är vissa parametrar inaktiva i visualiseringen. Dessa parametrar valdes att separeras från resterande för att förtydliga presentationen av mashupen.
Den gröna texten visar vilka parametrar som får ett värde i realtid från driven. Mashupen uppdateras varje sekund och varje parameter uppdateras varannan sekund.
Figur 33: Resultatet av mashupen som visar parametrarna som hämtats från driven.
5
Diskussion
Prototypen uppfyller sitt mål och alla de krav som ställts och anses därför fungera på önskvärt sätt. Vissa förbättringar kan göras vid vidareutveckling och dessa diskuteras nedan.
5.1
Datautvinning
Hårdvara
Hårdvaran som valdes fungerade utan problem när den väl blev inkopplad rätt och hänsyn tagits till de fördröjningar som behövde användas. Mycket felsökning krävdes när RS-485 transceivern skulle kopplas upp då det var okänt om det fungerade att skicka signaler från transceivern till driven med 3,3V. Felsökningen visade att det var genomförbart samt att felet egentligen låg i koden som användes för att skicka Modbusmeddelanden.
Detta löstes med hjälp av ett oscilloskop för att kontrollera signalen mel-lan driven och mikrokontrollern. Då upptäcktes det att det behövdes en för-dröjning innan toggle på transceivern sattes från ‘skicka’ till ‘ta emot’. Detta för att Modbus avslutar ett meddelande med en tystnad på minst 3 bytes och meddelandet blev då avbrutet för fort efter att det skickats.
För framtida utveckling borde hårdvaran optimeras till det användnings-område den ska användas i. Därför borde en ny hårdvara tas fram som inte har onödiga komponenter som inte används då både storlek och pris ökar på hårdvaran. En modul med en programmerbar processor samt hantering av UART tillsammans med en transceiver och radiomodul.
Mjukvaruintelligens
Systemets intelligens valdes att läggas i gatewayen (delsystem 2) istället för i noden (delsystem 1) eftersom det både var enklare med färdig Modbushan-tering och att det inte var helt säkert om MCU:n skulle ha minne att klara av det.
Nu skickar systemet en förfrågan åt gången från delsystem 2 som endast hämtar ett register då registren måste ligga på rad för att kunna hämta fler åt gången.
Skillnaden med att ha intelligensen i delsystem 1 hade då varit att Mod-bushanteringen hade funnits i MCU:n och då hade det varit möjligt att ta en förfrågan från delsystem 2 och dela upp den. Med detta menas att en förfrågan gör att MCU:n frågar driven om alla parametrar innan den sva-rar delsystem 2 och skickar tillbaka alla på samma gång i ett långt Mira-meddelande. På så sätt hade systemet kunnat snabbas upp eftersom en av
tidsbegränsningarna ligger i hur fort systemet kan skicka förfrågningar från delsystem 2 för att kunna få svar.
Programspråk
Valet av C++ som programspråk visade sig vara ett bra val eftersom det fanns smidiga och enkla funktioner för att konfigurera och använda sig av se-rieportar. Efter en del sökning såg det nämligen komplicerat ut och betydligt mycket mer kod att få igång serierportar med C-kod. Valet av C++ funkade också väldigt bra när det gällde att implementera redan skriven C-kod.
5.2
Dataöverföring och parametervisualisering
HårdvaraValet att använda Miramoduler till dataöverföring var ett bra val då det var väldigt smidigt att använda de färdigimplementerade funktionerna. Det var enkelt att förstå hur de fungerade och samtidigt skapades ett samarbete med ett intressant företag. På grund av radiomodulernas långa räckvidd passar dessa även i stora fabriker där drives används.
Projektets begränsade tidsramar gjorde att gatewayen inte implementera-des i en Netbiter. Detta hade varit den optimala lösningen då slutprototypen hade blivit mindre och projektet hade även fått använda en av HMS egna produkter. Den nuvarande lösningen uppfyller dock alla krav som ställts på systemet trots att en startrutin måste följas för att det ska fungera. Vid framtida utveckling av en färdig produkt hade det varit smidigare och sett bättre ut om gatewayen skapades i en Netbiter.
Mjukvara
Serieportarna som används för kommunikation mellan C++ applikationen och Luaskriptet går inte alltid igång och behöver startas med startrutinen. Anledningen till detta har inte hittats och har därför inte kunnat åtgärdas. Detta gör systemet ostabilt men är något som hade åtgärdats vid framtida utveckling.
En bättre lösning hade varit att integrera C++ i Luaskriptet så att endast ett program behöver köras och serieportar inte hade behövts. Vidareutveck-ling av detta hade varit av hög prioritet.
ThingWorx
Vid tillägg av fler drives till systemet kommer det att behövas skapas fler Things. För att få en bra struktur är det nödvändigt att skapa en Thing-Template som heter ‘Drives’ som har generella properties som finns i alla drives. Sådana properties kan vara exempelvis mjukvaru- och hårdvaruver-sion. Under den ThingTemplaten ska en till ThingTemplate skapas som heter ‘Schneider Electric’, denna ska ärva properties från ‘Drives’ och även ha egen-skaper specifikt för drives från Schneider Electric. För att göra det ännu mer anpassningsbart ska ytterligare en ThingTemplate skapas som kallas ‘Altivar 32’. Denna ThingTemplate ärver alla egenskaper från ‘Drives’ och ‘Schneider Electric’ och kan även tilldelas fler properties specifikt för Altivar 32 drives. Slutligen skapas en Thing kallad exempelvis ‘ATV32_1’ som representerar en ATV32 drive, i detta projekt skulle EdgeThing vara denna Thing. På det-ta sätt blir vidareutveckling av systemet mer anpassningsbart i framtiden, för en grafisk förklaring se Fig. 35 nedan.
Figur 35: En grafisk förklaring av hur upplägget i ThingWorx hade kunnat förbättras.
Mashupen hade kunnat förbättras och blivit mer representerbar om en motor hade kopplats in i driven. Då hade fler parametrar varit aktiva och mer intressanta att framhäva i mashupen. I nuläget är det väldigt få paramet-rar som ändras i realtid och därför blir visualiseringen väldigt stillastående. Bortsett från detta blev mashupen väldigt bra och tydlig.
6
Slutsats
Den systemprototyp som utvecklats i projektet visar att det är möjligt att koppla upp frekvensomriktaren ATV32 och visualisera dess parametrar med hjälp av ThingWorx. Det visas också att den trådlösa kommunikationen gick att genomföra med LumenRadios radioteknik som är framtagen för styrning av ljussättning. Frågeställningarna är besvarade, målen är uppnådda och alla krav är uppfyllda.
Systemets responstid blev slutligen cirka två sekunder per parameter som läses av. I kapitel 4 beskrivs att antalet parametrar som läses av i detta projekt är 17 stycken som resulterar i en uppdateringshastighet på under en minut för hela systemet. I jämförelse med tiden det tar för tekniker att kontrollera maskiner på plats, anses detta vara en bra uppdateringshastighet. För att kvantifiera resultatet lästes Modbusmeddelanden av som skic-kats från frekvensomriktaren med hjälp av en USB till UART-kabel kopplad mellan transceivern och mikrokontrollern. Från dessa meddelanden togs pa-rametervärden ut och jämfördes med de värden som visades i ThingWorx. Slutsatsen blev att värdena stämde överens.
7
Referenser
[1] LumenRadio. Lumenradio - LumenRadio launches mira, 2015. [Online; hämtad 4-december-2015].
[2] Freescale. Freedom development platform for kinetis, 2015. [Online; hämtad 4-december-2015].
[3] Netbiter remote management: Monitor and control field equipment on-line, 2015. [Online; hämtad 3-december-2015].
[4] Schneider Electric. ATV32 Modbus manual, 2015. [Online; hämtad 4-december-2015].
[5] Byung Mun Lee and Jinsong Ouyang. Intelligent healthcare service by using collaborations between iot personal health devices. blood pressure, 10:11, 2014.
[6] Qingping Chi, Hairong Yan, Chuan Zhang, Zhibo Pang, and Li Da Xu. A reconfigurable smart sensor interface for industrial WSN in IoT environ-ment. Industrial Informatics, IEEE Transactions on, 10(2):1417–1425, 2014.
[7] Martin Malmström. Modbus/Bluetooth Gateway. 2015. Examensarbete på Högskolan i Halmstad. 2015-04-28.
[8] Schneider Electric. Altivar 32. [Online; hämtad 30-november-2015]. [9] LumenRadio. Mira, 2015.
[10] Wikipedia. Wireless mesh network — wikipedia, the free encyclopedia, 2015. [Online; hämtad 8-oktober-2015].
[11] Wikipedia. RS-485 — wikipedia, the free encyclopedia, 2015. [Online; hämtad 8-oktober-2015].
[12] Lou Frenzel. What’s the difference between the RS-232 and RS-485 serial interfaces?, 2013. [Online; hämtad 30-november-2015].
[13] FRDM-K64F: Freescale freedom development platform for Kinetis K64, K63, and K24 MCUs. [Online; hämtad 14-oktober-2015].
[14] OpenSDAv2. [Online; hämtad 14-oktober-2015].
[15] Wikipedia. Concurrent computing — wikipedia, the free encyclopedia, 2015. [Online; hämtad 1-December-2015].
[16] Wikipedia. Java (programming language) — wikipedia, the free encyclo-pedia, 2015. [Online; hämtad 1-december-2015].
[17] Wikipedia. C (programspråk) — wikipedia,, 2015. [Online; hämtad 1-december-2015].
[18] Wikipedia. Imperativ programmering — wikipedia,, 2013. [Online; häm-tad 1-december-2015].
[19] Wikipedia. Strukturerad programmering — wikipedia,, 2015. [Online; hämtad 1-december-2015].
[20] Wikipedia. C++ — wikipedia,, 2015. [Online; hämtad 1-december-2015].
[21] What is mbed? [Online; hämtad 1-december-2015].
[22] About, 2015. [Online; hämtad 3-december-2015].
[23] James J Willkie and James A Hutchison IV. Uart based autobauding without data loss, July 13 1999. US Patent 5,923,705.
[24] Emil Lambrache and Benjamin F Froemming. Serial peripheral interface (spi) apparatus with write buffer for improving data throughput, July 25 2006. US Patent 7,082,481.
[25] Wikipedia. Modbus — wikipedia, the free encyclopedia, 2015. [Online; hämtad 8-oktober-2015].
[26] PTC. ThingWorx IoT Platform, 2015. [Online; hämtad 2-oktober-2015].
[27] Ken Schwaber. Agile project management with Scrum. Microsoft Press, 2004.
[28] PCB Library Expert, 2015. [Online; hämtad 4-december-2015].
[29] Cadence OrCAD Capture / Capture CIS, 2015. [Online; hämtad 4-december-2015].
[30] Cadence OrCAD PCB Editor, 2015. [Online; hämtad 4-december-2015]. [31] Cogra. Cogra Pro AB, 2015. [Online; hämtad 7-December-2015].
[32] HHD Software. Free Virtual Serial Ports, 2015. [Online; hämtad 7-December-2015].
[33] Wikipedia. Representational state transfer — wikipedia, the free en-cyclopedia, 2015. [Online; hämtad 5-December-2015].
[34] ABB. ABB general machinery drives, 2009. [Online; hämtad 1-oktober-2015].
[35] ABB. Flashdrop, 2015. [Online; hämtad 1-oktober-2015].
[36] ABB. FPBA-01 PROFIBUS DP adapter module, 2015. [Online; hämtad 2-oktober-2015].
[37] Wikipedia. Profibus — wikipedia,, 2013. [Online; hämtad 8-oktober-2015].
[38] ABB. Drive PC tools - startup and maintenance - drivewindow light, 2011.
8
Bilagor
KRAVSPECIFIKATION
PROJEKTIDENTITET
2015 HT
Uppkoppling av frekvensomriktare mot internet
Namn E-post
Sara Amani sarama12@student.hh.se
Ludwig Weddig ludwed12@student.hh.se
Kund: Erik Halvordsson, HMS Kontaktperson hos kund: erh@hms.se Kursansvarig: Björn Åstrand, bjorn.astrand@hh.se
Handledare: Emil Nilsson
2 Examensarbete
1 Översikt av systemet ... 5 1.1 Grov beskrivning av produkten ... 5 1.2 Produktkomponenter ... 5 1.3 Beroende till andra system... 5 1.4 Ingående delsystem ... 5 1.5 Avgränsningar ... 6 1.6 Generella krav på hela systemet ... 6 2 Delsystem 1: Parameterutvinning ... 7 2.1 Inledande beskrivning av delsystem 1 ... 7 2.2 Gränssnitt och funktionella krav för delsystem 1 ... 7 3 Delsystem 2: Dataöverföring ... 8 3.1 Inledande beskrivning av delsystem 2 ... 8 3.2 Gränssnitt och funktionella krav för delsystem 2 ... 8 4 Delsystem 3: Parametervisualisering ... 9 4.1 Inledande beskrivning ... 9 4.2 Gränssnitt och funktionella krav för delsystem 3 ... 9 4.3 Användargränssnitt ... 9 5 Tillförlitlighet ... 10 6 Ekonomi ... 10 7 Leverans och delleveranser ... 10 8 Utbildning ... 10
3 Examensarbete
Version Datum Utförda förändringar Utförda av Granskad
0.1 2015-10-01 Första utkastet Grupp
Grupp Grupp Grupp
4 Examensarbete
Figur 1. En grov översikt av systemet.
1.1 Grov beskrivning av produkten
Frekvensomriktarens parametrar ska överföras med hjälp av plattformen Mira till internet där programmet ThingWorx ska visualisera parametrarna.
1.2 Produktkomponenter
Systemet består av:
• Plattformen Mira från LumenRadio
• RS-485
• Frekvensomriktare Schneider electric ATV32
• Plattformen ThingWorx
• Mikrokontroller Freescale FRDM-K64F
1.3 Beroende till andra system
För att systemet ska fungera behövs tillgång till pålitligt internet.
1.4 Ingående delsystem
Systemet delas in i följande delsystem: 1. Parameterutvinning
2. Dataöverföring
3. Parametervisualisering
5 Examensarbete
electric ATV32
• Parametrar som kommer mätas är: – Versioner av hård-/mjukvara – Drifttimmar
– Driftstatus
– Energiförbrukning
1.6 Generella krav på hela systemet
Följande generella krav ställs på systemet:
Krav nr 1 Original Frekvensomriktarens parametrar ska kunna visualiseras på en webbläsare Bas
Krav nr 2 Original Systemet ska varatestat enligt testspecifikationen Bas
6 Examensarbete
Figur 2. Flödesschema av delsystem 1.
2.1 Inledande beskrivning av delsystem 1
Delsystem 1 består av ATV32, RS-485, FRDM-K64F samt Mira som ska ta emot och skicka vidare de parametrar som utvinns från frekvensomriktaren vidare till delsystem 2.
2.2 Gränssnitt och funktionella krav för delsystem 1
Krav nr 3 Reviderat
2015-10-09
Mikrokontrollern ska genom RS-485 skicka kommandon till frekvensomriktaren och
ta emot parameterdata som skickas vidare till radiomodulen Mira Bas
Krav nr 4 Original När parameterdata hämtats till radiomodulen ska data skickas vidare till delsystem 2 Bas
7 Examensarbete
Figur 3. Flödesschema delsystem 3
3.1 Inledande beskrivning av delsystem 2
Delsystem 2 består av en radiomodul Mira som ska ta emot parameterdata från delsystem 1 och skicka vidare detta till delsystem 3 via internet.
3.2 Gränssnitt och funktionella krav för delsystem 2
Krav nr 5 Original Ska kunna ta emot parameterdata från delsystem 1 Bas
Krav nr 6 Original Ska kunna skicka vidare parameterdata till delsystem 3 Bas
8 Examensarbete
4.1 Inledande beskrivning
Delsystem 3 består av en applikation som ska skapas i ThingWorx där frekvensomriktarens parametrar ska visualiseras.
4.2 Gränssnitt och funktionella krav för delsystem 3
Krav nr 7 Original Servern ska kunna ta emot data från delsystem 2 och visualisera dessa Bas
4.3 Användargränssnitt
Krav nr 8 Original Applikationen ska visualisera parametrarna för användaren Bas
9 Examensarbete
Krav nr 9 Original Den slutgiltiga produkten ska vara godkänd på samtliga punkter i
testspecifikationen Bas
6 Ekonomi
Krav nr 10 Original Varje person ska minst utföra 20 timmars arbete per vecka Bas
7 Leverans och delleveranser
Krav nr 11 Original Vid leverans till kund ska minst alla krav med basprioritet vara uppfyllda Bas
8 Utbildning
Krav nr 12 Original Samtliga gruppmedlemmar ska ha tillräckliga kunskaper inom programmering av
inbyggda system och ThingWorx innan halvtidspresentationen Bas
10 Examensarbete
Version 0.1
2015 HT
Uppkoppling av frekvensomriktare mot internet
Namn Epost Sara Amani sarama12@student.hh.se Ludwig Weddig ludwed12@student.hh.se Kund: Erik Halvordsson, HMS Kontaktperson hos kund: erh@hms.se Kursansvarig: Björn Åstrand, bjorn.astrand@hh.se Handledare: Emil Nilsson1 Inledning 4 1.1 Testspecifikationens struktur 4 1.2 Ej godkända tester 4 2 Komponenttest 5 2.1 Parameterutvinning 5 2.2 Parametervisualisering 5 3 Integrationstest 6 3.1 Parameterutvinning 6 3.2 Dataöverföring 6 3.3 Parametervisualisering 6 4 Systemtest 7 5 Testprotokoll 8
Version Datum Utförda förändringar Utförda av Granskad 0.1 20151012 Första utkastet Grupp
Testspecifikationen beskriver de test som ska utföras på enskilda delsystem och på systemet i sin helhet. Detta för att se till att systemet uppfyller de krav som finns i kravspecifikationen.
1.1
Testspecifikationens struktur
Testen kommer att utföras under projektets gång och kommer vid projektets avslut att redovisas. I redovisningen kommer testens tillvägagångssätt samt resultat att visas.1.2
Ej godkända tester
Tester som inte godkänns ska diskuteras på gruppmöten där beslut om åtgärder ska tas.2.1
Parameterutvinning
Test nr Berör
krav Beskrivning Datum
1 3 Kontrollera så att kommandon skickas till frekvensomriktaren och parameterdata skickas till Mira 1 20151012
2.2
Parametervisualisering
Test nr Berör
krav Beskrivning Datum
