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 ändrades 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 det i Luaskript. En Mira-frame Encoder/Decoder gjordes 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årdvara

Valet 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  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     

 

1 _​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  2015­10­12  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}  2015­10­12 

   

2.2

Parametervisualisering

Test nr  Berör 

krav  Beskrivning  Datum 

3.1 Parameterutvinning

Test nr  Berör krav  Beskrivning  Datum 

3  4, 5  Kontrollera så att parameterdata skickas från delsystem 1 till _delsystem 2  2015­10­12 

 

3.2 Dataöverföring

Test nr  Berör krav  Beskrivning  Datum 

4  6  Kontrollera så att parameterdata skickas vidare till delsystem 3  2015­10­12 

 

3.3 Parametervisualisering

Test nr  Berör krav  Beskrivning  Datum 

För att kontrollera att systemet fungerar korrekt och klarar kraven som ställts i  kravspecifikationen har ett sluttest skapats. Detta test är utformat för att testa systemet med  alla funktioner i sin helhet och utförs på följande vis.  Startrutin:  ● Koppla in ström till drive  ● Koppla in drive i Freescale K64F  ● Ge Freescale K64F strömförsörjning  ● Koppla in Miramodul 2 i PC  ● Kontrollera så att de virtuella portarna inte är “broken”, om de är “broken” ta bort dem  och starta sedan om datorn och skapa nya virtuella portar  ● Kontrollera att rätt bridge är initierad  ● Använd ett terminalprogram, förslagsvis RealTerm, för att starta alla portar en gång  med baudhastighet 115200, 8 data bits, 1 stop bit, ingen flow control och skicka  meddelandet nedan med alla portar:  0xE1 0x43 0x03 0x00 0x08 0x81 0x01 0x03 0x23 0x29 0x00 0x01 0x5E 0x46 0xAF 0x7B  ● När meddelandet skickas till Miramodul 2, kontrollera samtidigt att ett meddelande  kommer tillbaka från Freescale K64F  ● Starta Gateway.exe och skicka in ett “q” för att kolla så att det stängs korrekt. Om det  stängdes, starta upp det igen och låt stå på  ● Starta om Freescale K64F på restartknappen  ● Starta ett terminalfönster och starta wsems.exe med konfigureringsfilen config.json  ● Starta ett terminalfönster och kör luaScriptResource.exe med konfigureringsfilen  configmodbus1.lua  ● Logga in på webbsidan: _​http://10.10.12.39:8080/Thingworx/Composer  ● Öppna UFI­mashup och tryck på “View mashup”     

  Test nr 1  Beskrivning:_​ Kontrollera så att kommandon skickas till frekvensomriktaren och  parameterdata skickas till Mira 1.    Tillvägagångssätt: _​Ett hårdkodat korrekt modbusmeddelande skickas till driven med MCU:n.  Miramodul 1 övervakas samtidigt i Realterm med en USB ­ UART kabel för att se om en  respons mottas.    Kommentar: _​Fungerar felfritt.    Datum: _​2015­12­01    Utfall: Godkänd       

Beskrivning: _​Kontrollera så att applikationen visualiserar parametrarna    Tillvägagångssätt: _​Detta delsystem måste testas med resten av systemet igång. Startrutinen  körs och parametrarna i mashupen övervakas för att se om de uppdateras vid nya värden.    Kommentar:_​ Parametrarna uppdateras som de ska. Om hela systemet inte är igång  uppdateras inga parametrar och det står att driven inte är ansluten.    Datum: _​2015­12­08    Utfall: Godkänd       

Beskrivning:_​ Kontrollera så att parameterdata skickas från delsystem 1 till delsystem 2.    Tillvägagångssätt:_​ Realterm används för att skicka ett Mirameddelande från Miramodul 2 till  Miramodul 1. Om ett modbusmeddelande skickas tillbaka från driven syns ett  Mirameddelande med ett inpackat modbusmeddelande i Realterm.      Kommentar: _​Fungerar korrekt.    Datum:_​ 2015­12­08    Utfall: Godkänd 

Beskrivning:_​ Kontrollera så att parameterdata skickas vidare till delsystem 3.    Tillvägagångssätt_​: Startrutinen körs. EdgeThing­properties öppnas i ThingWorx­plattformen  och uppdateras manuellt för att se om värdena ändras i parametertabellen.    Kommentar:_​ Fungerar korrekt.    Datum: _​2015­12­08    Utfall: Godkänd     

Beskrivning:_​ Kontrollera så att parameterdata skickas från delsystem 1 till delsystem 2.    Tillvägagångssätt:_​ Startrutin körs. Mashupen och Luaskriptsterminalen övervakas för att se  om värdena uppdateras som de ska.    Kommentar:_​ Fungerar men ibland uppkommer timeouts då driven inte skickar något  meddelande och då uppdateras inte värdena i Mashupen. Detta kan bero på att meddelandet  blir korrupt på vägen och slängs för att CRC­checken inte går igenom.    Datum:_​ 2015­12­08    Utfall: Godkänd       

Beskrivning: _​Systemtest    Tillvägagångssätt: _​Se systemtestbeskrivningen.    Kommentar: _​Alla krav och mål är uppfyllda och systemet är godkänt.    Datum:_​ 2015­12­08    Utfall: Godkänd 

BESKRIVNING TID VEM

Nr Beskrivning timmar Initialer 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 1 2

1 Planering LWE, SAM 0

2 Förundersökning LWE, SAM 0

3 Utbildning LWE, SAM 0

4 Gruppmöten LWE, SAM 0

5 Möten med företag LWE, SAM 0

6 Delsystem 1 - Parameterutvinning Hårdvarukonstruktion LWE 0

7 Delsystem 1 - Parameterutvinning Programmering LWE, SAM 0

8 Delsystem 2 - Dataöverföring Dataöverföring mellan delsystem 1 och 3 SAM 0

9 Delsystem 3 - Parametervisualisering Anslutning till molnserver och implementation i ThingWorx SAM 0

10 Integrering av delsystem LWE, SAM 0

In document Uppkoppling av frekvensomriktare mot internet (Page 45-102)