Onderzoek in het kader van SMART Steven Hoedt Promotoren: Henk Capoen, dhr. Niels Tanghe Begeleider: Dieter Vandenhoeke Masterproef ingediend tot het behalen van de academische graad van Master of Science in de industriële wetenschappen: elektrotechniek Vakgroep Industrieel Systeem- en Productontwerp Voorzitter: prof. Kurt Stockman Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2013-2014
Onderzoek in het kader van SMART Steven Hoedt Promotoren: Henk Capoen, dhr. Niels Tanghe Begeleider: Dieter Vandenhoeke Masterproef ingediend tot het behalen van de academische graad van Master of Science in de industriële wetenschappen: elektrotechniek Vakgroep Industrieel Systeem- en Productontwerp Voorzitter: prof. Kurt Stockman Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2013-2014
Voorwoord Deze masterproef heb ik als een leerrijke en aangename periode ervaren. Het is een ideale manier om de opleiding van Master of Science in de indutriële wetenschappen af te sluiten. Ondanks de goede opleiding die ik gehad heb de voorgaande jaren, heb ik toch het verschil tussen onderwijs en werk ondervonden. Bij deze wil ik ook alle mensen bedanken die mij geholpen bij mijn masterproef. Met een speciale vermelding voor alle medewerkers van mijn masterproe edrijf: Catael. Waarbij ik in het bijzonder mijn externe promotor Niels Tanghe erg dankbaar ben voor alle jd en raad die ik gekregen heb. Ook mijn interne promotor Henk Capoen die het mogelijk maakte om een gevariëerde masterproef te hebben en mij ondersteuning geboden hee bij de opbouw van zowel mijn geschreven thesis als mijn thesisverdedinging wil ik bij deze uitvoerig bedanken. Tot slot wil ik ook mijn ouders bedanken omdat zij mij de kans geboden hebben om deze opleiding te volgen. i
Abstract The internet of things and remote access are only a few terms that have been become more popular than ever. The management of a factory wants to be able to follow up their process always and everywhere. That s why the concept about SMART is introduced in Catael. SMART stands for Smart Monitoring and Repor ng Tool. SMART should be the general web applica on that can be offered to customers who want to have an overview of their produc on process. That should also help to create some upgrades to the process. SMART must be seen as a kind of template from a web applica on that easily can be edited to the specific needs of the customer. The goal of this thesis is helping with the development of SMART on different levels. There are three levels that can be separated. First of all there is the lowest level that concerns the data capture. There are two op ons to do that: a PLC or an applica on. Both op ons will be used, pendent on the customers needs. Just above that level there is the data management. Data management includes choosing a good structure of the used database as there is also avoiding data overhead in the dataset by compressing this data. The truly visualiza on of data is the last step. The design pa ern that is used for SMART calls MVC which means Model View Controller. A study about this pa ern and its advantages and disadvantages is also part of this thesis. ii
Lijst met a or ngen B BLL Business Logic Layer C CSS Cascade Style Sheet D DAL Data Acces Layer G GUI Graphical User Interface I IP Internet Protocol M MBAP MVC Modbus Applica on Model View COntroller P PDU PLC Protocol Data Unit Programmable Logic Controller iii
R RTU Remote Terminal Unit S SQL SMART Structured Query Language Smart Monitoring and Repor ng Tool T TCP Transmission Control Protocol V VB Visual Basic iv
Inhoudsopgave 1 Inleiding 1 1.1 Bedrijfsvoorstelling.......................................... 1 1.2 Probleemstelling........................................... 1 1.3 SMART................................................ 2 1.4 Projectaanpak............................................ 3 2 Algemene situering 4 2.1 Energiemonitoring.......................................... 4 2.2 Gegevens verkrijgen en opslaan................................... 4 2.3 Webvisualisa e............................................ 4 3 MVC (Model-View-Controller) 6 3.1 MVC vs n-tier............................................. 6 3.2 Voor- en nadelen van MVC...................................... 7 4 Modbus TCP 8 4.1 Inleiding................................................ 8 4.2 Dataframe............................................... 8 4.3 Applica e: Modbus - SQL server................................... 9 4.3.1 Doel.............................................. 9 4.3.2 Func onele werking..................................... 9 4.3.3 Structurele opbouw van de so ware............................. 10 4.3.4 Fouta andeling....................................... 11 5 Opslag en compressie van data 13 5.1 Structuur van de database...................................... 13 5.1.1 Horizontale structuur..................................... 13 5.1.2 Ver cale structuur...................................... 14 5.2 Comprimeren van data........................................ 15 5.2.1 Compressie bij horizontale logging.............................. 16 5.2.2 Compressie bij ver cale logging............................... 16 6 Webvisualisa e 18 6.1 Inleidend project: Powerqualitymonitor............................... 18 6.1.1 Doel.............................................. 18 6.1.2 Beschrijving van de func onele werking........................... 18 6.1.3 Mogelijke oplossingen.................................... 18 6.1.4 Beschrijving van de gekozen methode............................ 18 7 Conclusies 21 A Handleiding Modbus-SQL-Applica e 23 v
Lijst van figuren 1.1 Logo van Catael............................................ 1 1.2 Logo van SMART........................................... 2 2.1 Overzicht van webvisualisa e.................................... 5 3.1 So ware architecturen van een webpagina............................. 7 4.1 Modbus TCP dataframe........................................ 9 4.2 Overzicht van de interfaces van de applica e............................ 10 4.3 So warestructuur van de applica e................................. 11 4.4 Try-catch structuur.......................................... 12 5.1 Opbouw van een database voor horizontale logging........................ 14 5.2 Opbouw van een database voor ver cale logging.......................... 14 5.3 Tabel met parameters........................................ 15 5.4 Compressie bij horizontale logging.................................. 16 5.5 Compressie bij ver cale logging................................... 17 6.1 Weegave van de opstelling...................................... 19 6.2 Lay-out van de gemaakte webpagina................................. 20 vi
1 Inleiding 1.1 Bedrijfsvoorstelling Catael is een bedrijf dat geves gd is in Bellegem en is opgericht in 2007. De naam Catael is a oms g van de twee grondleggers van dit project, Henk Capoen en Nikolas Taelman. Algemeen gezien is het een bedrijf dat zich bezig houdt met alles wat te maken hee met automa sering. Meer concreet zijn er vier verschillende takken die daaruit voortkomen: Building Automa on, Industriële Automa sering, Machinebouw en Consultancy. Zoals de pijler Consultancy doet vermoeden, houdt Catael zich niet enkel bezig met prak sche toepassingen, maar ook met het verlenen van support. Deze support is een vorm van service engineering waarbij de klanten geholpen worden met problemen en vragen. Figuur 1.1: Logo van Catael 1.2 Probleemstelling De centrale term waar rond gewerkt wordt is Industrie 4.0 ofwel The internet of things. Dit houdt in dat alles binnen een produc eproces kan opgevolgd worden via het web. Om dit te verwezenlijken zijn er verschillende elementen nodig. Elk element van deze structuur zal binnen het kader van deze masterproef aan bod komen. De opkomst van Industrie 4.0 is vooral te wijten aan de grote vraag naar het kunnen opvolgen van een produc eproces en om deze te op maliseren. Wanneer veel parameters van een produc eproces opgevolgd worden, zal het gemakkelijker zijn om een op maal proces te bekomen. Vaak worden factoren als temperatuur, druk,.. over het hoofd gezien. Door het opvolgen van deze parameters, zullen er veel rela es tussen zo n factoren en de efficiën e van een produc eproces het daglicht zien. Op die manier is het mogelijk om naar een nagenoeg op maal proces te streven. Ook wil een producent ten alle jde kunnen zien hoe het met zijn bedrijf staat, dit liefst zo up to date mogelijk. Om alle gegevens op het web te plaatsen, moeten er ook gegevens zijn. Deze gegevens worden gecapteerd door allerhande mee oestellen. Een me ng doen is één zaak, maar deze me ng moet ook opgeslagen worden. Zo n gegevens worden het best opgeslagen in een database. Deze kunnen vast op een server binnen het bedrijf gezet worden of op een server on the cloud. Een eerste luik in deze masterproef zal een beschrijving geven over de manier waarop data vanuit mee oestellen gecapteerd kan worden en zo naar een database geschreven kan worden. Daar ligt de nadruk op Modbus TCP, aangezien dit een veel toegepast communica eprotocol is bij ne en en registra etoestellen. Een tweede luik zal dan bestaan uit het beheer van deze gegevens. Met het beheer van gegevens wordt enerzijds bedoeld dat de gegevens op een gestructureerde manier moeten worden opgeslagen. Aan de andere kant is ook het beperken van een zogenaamde overload aan gegevens een belangrijk topic. Het verwerken van deze 1
overbodige data wordt dan ook binnen het kader van de masterproef naderbij bekeken. Overbodige gegevens kunnen bijvoorbeeld gedateerde gegevens zijn, die in het heden niet meer belangrijk zijn. Een voorbeeld: als in een bepaald proces elke seconde de temperatuur gemeten wordt om deze dan actueel voor te stellen op een webpagina, dan is het niet nodig om 2 jaar later de waarde van de temperatuur tot op de seconde te kennen. Zo'n data wordt dan best gecomprimeerd door uitgemiddelde waarden op te slaan. Hoe dit het best kan gebeuren wordt verder uitvoerig besproken. Eens de nodige gegevens gecapteerd en opgeslagen zijn op een goede manier, is het belangrijk om deze op een goede, overzichtelijke manier naar de gebruiker voor te stellen en een overzichtelijke samenva ng van het proces te tonen. Het presenteren van de gegevens wordt gedaan met behulp van een webpagina. Om een webpagina te maken zijn verschillende methodes mogelijk. Er wordt onderscheid gemaakt tussen het n- ermodel en het MVC-model. Het grote verschil tussen beide is de fysische plaats waar de verschillende lagen of ers draaien. Het n- ermodel bestaat meestal in de vorm van een 3- erstructuur. Deze 3 ers (Datalink Business logic- Representa on) kunnen ona ankelijk gebruikt worden van elkaar. Bij het MVC-model daarentegen hangen alle lagen (Model-View-Controller) vast aan elkaar. Beide modellen hebben hun eigen voor- en nadelen. Zo kan er bij het n- ermodel gemakkelijk een er gebruikt worden voor verschillende applica es. Dit leidt tot een meervoudig gebruik van deze er. Aan de andere kant is het MVC-model veel gemakkelijker wat ontwikkeling betre. De onderlinge ac es tussen alle lagen kunnen gemakkelijk geanalyseerd worden. Het MVC-model is eigenlijk een soort template die door Microso naar voor geschoven wordt om webpagina's te maken. Een vergelijkende studie maken van deze modellen is het laatste onderdeel van deze masterproef. 1.3 SMART Binnen Catael is SMART een term die het volledige concept van webvisualisa e omvat, de bedoeling is vooral om dit op industrieel niveau te gebruiken. SMART staat voor Smart Monitoring and Repor ng Tool. Daar remote access heden ten dage een steeds belangrijker topic wordt, is het als bedrijf in de automa seringssector uitermate belangrijk om op de s jgende vraag van de markt in te spelen. Door die s jgende vraag naar visualisa e via het web, is het idee rond SMART ontstaan. Het is de bedoeling om voor elk project in zake webvisualisa e, vanaf een basisproject te kunnen beginnen en dit dan verder uit te bouwen naar de specifieke behoe en van de klant. Binnen deze masterproef wordt vooral onderzoek gedaan naar de ontwikkeling van dit basisconcept. De verschillende keuzes voor ieder deel van een visualisa eproject worden grondig bestudeerd. Na de studie van alle mogelijkheden zal voor SMART de beste oplossing gekozen worden. Naast het afwegen van verschillende oplossingen is het ook de bedoeling om prak sch ook enkele zaken te verwezelijken die nu g zijn voor het SMART-principe. Figuur 1.2: Logo van SMART 2
1.4 Projectaanpak Als aanzet voor deze masterproef wordt eerst een project gemaakt om voeling te krijgen met alle elementen van webvisualisa e. De func onaliteit van dit project wordt samen met de achterliggende theorie verder besproken. Daarna wordt specifiek ingegaan op het capteren van data. Dat zou moeten resulteren in een Windows Forms Applica on die gegevens uit een toestel haalt dat modbus TCP ondersteunt en rechtstreeks deze waarden naar een SQL server schrij. Deze Windows Forms Applica on moet vooral flexibel, robuust en efficiënt zijn. Ten laatste wordt een analyse gemaakt van alle mogelijke structuren voor het opslaan van gegevens in een database. Alle voor- en nadelen zullen bekeken worden. Hieruit zal dan een keuze gemaakt worden hoe de data standaard binnen Catael zal opgeslagen worden. Het is ook de bedoeling om een service te maken die het comprimeren van data toepast indien nodig. 3
2 Algemene situering 2.1 Energiemonitoring SMART wordt zoals eerder gezegd vooral gezien op industriële schaal. Binnen de industrie is het vooral belangrijk om te weten hoeveel energie in een proces kruipt. Op die manier kan bijvoorbeeld een analyse gemaakt worden van welk deel van het proces geop maliseerd kan worden. Ook de harmonischen van de stroom en spanning kunnen van belang zijn, alsook de cos (ϕ). Zo kan naast de hoeveelheid ook de kwaliteit van de energie bekeken worden. Naast deze elek sche grootheden kunnen ook parameters als temperatuur, druk en voch gheid belangrijk zijn in bepaalde processen. Vooral in de voedingsector zijn deze waarden van belang. Binnen een produc eproces kan het voorbeeld voorkomen dat een bepaalde temperatuur niet overschreden mag worden. De visualisa e van deze waarden wordt meestal weergegeven op een grafiek in func e van de jd, maar het kan ook voorkomen dat enkel de actuele waarde van belang is. Om die reden moeten verschillende elementen voorzien worden om een webpagina op te vullen. Zowel grafieken als actuele meters moeten bijvoorbeeld beschikbaar zijn. 2.2 Gegevens verkrijgen en opslaan Om data te capteren zijn er twee mogelijkheden. Een eerste mogelijkheid is data loggen via een PLC. De PLC haalt de data uit de toestellen en logt deze direct door naar een database. Dezelfde func onaliteit kan bekomen worden door een VB.NET-applica e. De snelheid van beide mogelijkheden verschilt echter wel. Een PLC zal de data over het algemeen sneller loggen dan de applica e omdat een PLC minder belast is dan een server die een applica e bevat. Langs de andere kant kan de aankoop van een PLC vermeden worden door een applica e te gebruiken. Wanneer er natuurlijk al een PLC die nog niet volledig belast wordt, ter beschikking is, is het aangeraden om te loggen via een PLC. De keuze hangt ook af van het soort mee oestellen er gebruikt worden. De manier waarop de data in een database komt, is een eerste keuze. Een tweede keuze bestaat er in hoe de data opgeslagen wordt. Met andere woorden: Hoe ziet de structuur van de database er uit?. Hier zijn verschillende mogelijkheden voor. Er kunnen twee grote structuren onderscheiden worden. Een horizontale structuur en een ver cale structuur. Binnen elke structuur zijn nog enkele mogelijkheden. Een gedetaileerde analyse van alle mogelijkheden wordt verder besproken. 2.3 Webvisualisa e Er zijn enkele criteria die de kwaliteit van een webpagina beïnvloeden. De snelheid van de visualisa e is daar één van. De snelheid van de visualisa e hangt af van de achterliggende manier waarop de visualisa e tot stand komt. Het is dan ook belangrijk dat de dataopslag op een goede manier gebeurt. Ook het comprimeren van data kan de snelheid van de visualisa e op een goede manier beïnvloeden. Een tweede zaak is het overzichtelijk zijn van de visualisa e. Een mooie maar sobere visualisa e is noodzakelijk. Vandaar dat ook een strakke lay-out voor SMART gecreeërd wordt. De lay-out ligt vooral vast door de HTML-code en de CSS (Cascade Style Sheet). Maar voor bewegende elementen is er ook het gebruik van javascript nodig. Alle nodige elementen voor de opbouw van een webpagina (grafieken, 4
tabellen,...) worden standaard gemaakt, met als gevolg dat enkel de nodige elementen per project nog in de webpagina gezet moeten worden. Om de data vanaf de database tot aan het scherm van de gebruiker te brengen, wordt gebruik gemaakt van MVC (Model-View-Controller). De drie aparte componenten werken samen als één geheel. De interac e tussen alle componenten zorgt voor een efficiënte overdracht en verwerking van gegevens. Het MVC-model wordt verder uitvoerig besproken. Figuur 2.1 gee de opbouw van een geheel visualisa eproject schema sch weer. Dit overzicht kan aanzien worden als de algemene opbouw van SMART. Figuur 2.1: Overzicht van webvisualisa e 5
3 MVC (Model-View-Controller) Om een webpagina te maken zijn er tal van oplossingen, daardoor is het soms niet eenvoudig om een oplossing te kiezen. De architectuur van een webpagina is dus niet éénduidig. De architectuur kan vooral verschillen in hoe verschillende func onaliteiten van elkaar gescheiden worden en hoe ze met elkaar in verbinding staan. 3.1 MVC vs n-tier Er zijn drie componenten die belangrijk zijn binnen de opbouw van een webpagina: het ophalen van data, het bijhouden van data en het presenteren van data. Deze componenten komen in alle soorten structuren voor, maar het is de scheiding van verschillende func onaliteiten die de efficiën e bepaalt. Daarnaast is ook de interac e tussen de verschillende lagen een belangrijk gegeven. Het MVC-model bestaat uit een Model, View en Controller. Elk van deze componenten hee een specifieke taak bij de werking van de webpagina. Het model is zoals in objectgeoriënteerd programmeren een klasse. Het model hee een naam en bevat verschillende proper es die kunnen aangepast worden of opgevraagd worden. Algemeen wordt het Model gezien als de link met gegevens van buitenaf. Zo is het gebruikelijk om de func onaliteit om gegevens uit een database te halen, in het model te programmeren. Alle bewerkingen op deze gegevens worden dan binnen de Controller uitgevoerd en naar buiten gebracht via het Model. De Controller staat ook in voor het aanpassen van de View. Er kunnen verschillende Views gedefiniëerd worden in één project. Aan de hand van de handelingen van de gebruiker wordt een bepaalde View getoond. Één bepaalde View stelt enkel de presenta e naar de gebruiker voor. Deze omvat een vaste structuur door de HTML-code en bestaat uit tekst, bu on's, grafieken,... Wanneer op een bu on gedrukt wordt door de gebruiker, zet de View, de Controller of een Model in werking. A ankelijk van welke ac e de gebruiker doet, zal een bepaalde func e opgeroepen worden. Het uitzicht van de View is ook a ankelijk van de waarden van de proper es die een Model omvat. Een voorbeeld hiervan is een webpagina die variërende waarden die a oms g zijn uit een database moet weergeven in een grafiek. Op die manier hebben alle afzonderlijke componenten contact met elkaar. Daartegenover staat het n- ermodel dat het vaakst voorkomt als een 3- ermodel. Deze bestaat dan uit 3 ers. Een er is net zoals een laag, maar hee de bijkomende eigenschap dat het standalone kan draaien. Daarmee wordt bedoeld dat een er niet noodzakelijk onderdeel moet zijn van één enkele applica e, maar dat deze voor verschillende applica es kan dienen. De 3 ers die binnen het 3- ermodel gebruikt worden zijn voor de presenta e, de logica van de applica e en de dataopslag. Dit is zeer analoog aan het MVC-model, maar de interac es tussen deze ers zijn net iets verschillend. Zoals eerder vermeld staan de 3 ers van een applica e los van elkaar. Daarom kan er geen driehoeksverhouding tussen de verschillende lagen tot stand gebracht worden. Hier wordt gebruik gemaakt van een bepaalde hiërarchie, zo staat de presenta elaag bovenaan, daaronder de logica en helemaal onderaan de dataopslag. Een bepaalde laag kan enkel communiceren met de laag erboven of eronder. In het geval van 3 ers is de laag voor de logica de middelste en moet deze de verbinding tussen de data en de presenta e voorzien. Een directe koppeling tussen presenta e en dataopslag kan dus niet gemaakt worden, in tegenstelling tot het MVC-model waar het Model en de View aan elkaar gelinkt worden. 6
(a) MVC-model (b) 3- ermodel Figuur 3.1: So ware architecturen van een webpagina 3.2 Voor- en nadelen van MVC Door func onaliteiten te scheiden is het gemakkelijk om de werking van de webpagina te analyseren. Daardoor is het MVC-model zeer gemakkelijk in de ontwikkeling ervan omdat eventuele fouten gemakkelijk kunnen achterhaald worden. Ook bij het testen van een webapplica e kunnen de 3 lagen apart getest worden zonder interface naar een andere laag. Dit hee als gevolg dat deel per deel gemaakt kan worden en bij ieder onderdeel meteen getest kan worden op fouten zonder het aanwezig zijn van de andere 2 lagen. Dit in tegenstelling tot het n- ermodel waar effec ef moet getest worden met verschillende lagen samen, een project moet dan bijna helemaal af zijn voor het getest kan worden. Dat neemt een zekere complexiteit met zich mee. Ook is de reproduceerbaarheid van een Model voordelig. Daarmee wordt bedoeld dat een Model aan verschillende View's kan gekoppeld worden. Door één keer het model aan te passen zijn alle View's dus aangepast en up to date. Wat dan weer in het voordeel van het n- ermodel spreekt, is het feit dat bij een n- ermodel alle aparte lagen kunnen gebruikt worden door verschillende webpagina's. Maar dan moet veel aandacht besteed worden aan de interac e tussen verschillende lagen, met name aan het gebruik van de interface van een bepaalde laag. 7
4 Modbus TCP 4.1 Inleiding Modbus is een veelgebruikt protocol binnen de industrie wanneer het aankomt op mee oestellen. De sterkte van Modbus is dat ieder modbusdevice een eigen register hee met daarin verschillende waarden over het device. Dit kunnen opgemeten waarden zijn, maar sommige plaatsen kunnen ook voorzien zijn om het toestel te parametreren. Door deze registers is enorm veel informa e beschikbaar voor de buitenwereld. Het register, in een toestel dat Modbus ondersteunt, bestaat standaard uit 4 soorten data: coils, discrete inputs, een input register en holding register. De startadressen van de verschillende "subregisters"binnen het groot Modbusregister zijn ook standaard vastgelegd, deze zijn evenwel a ankelijk van de ontwikkelaar van het toestel. Een coil is een bit die zowel gelezen als geschreven kan worden. Dit is typisch een bit die door een applica e bewerkt wordt. Voor de applica e die het toestel gebruikt om aan te sturen of uit te lezen, is dit dus meestal een output. Deze bit kan bewerkt worden door de applica e om het device aan te sturen. Een discrete input is dan gelijkaardig met de coil, een input voor de applica e, daar deze readonly is. Een input register levert analoge inputs aan een applica e, ook deze is readonly. Een holdingregister is net zoals een inputregister, maar bij deze kunnen de waarden ook aangepast worden vanuit een applica e. Een holdingregister kan een analoge meetwaarde beva en, maar kan ook een parameter voorstellen die door een applica e aangepast kan worden, een voorbeeld hiervan is de jd of datum die via een applica e kan aangepast worden. Door de verschillende registers kan Modbus een grote diversiteit aan data beschikbaar stellen, wat het grote voordeel van deze veldbus is. Er zijn drie bekende varianten op Modbus: Modbus RTU, Modbus TCP en Modbus Plus. De laatst genoemde wijkt echter wat af van het standaard protocol, daar het werkt met een tokensysteem dat ieder device elk zijn beurt gee om een bericht op het netwerk te plaatsen. Modbus Plus wordt bij toepassingen van webvisualisa e nooit gebruikt, vandaar dat deze verder niet meer besproken wordt. Modbus RTU is een protocol dat serieel werkt en via een modbusslaveadres werkt, dit is een master-slavesysteem. Zowel RS485 als RS232 kunnen hier als fysiche laag gebruikt worden. Modbus TCP is dan logischerwijs gelijkaardig aan Modbus RTU, maar dan met als fysische laag ethernet en is een client-serversysteem. 4.2 Dataframe Het dataframe van Modbus TCP is opgedeeld in een Modbus Applica on Header (MBAP header) en een Modbus TCP/IP Protocol Data Unit (PDU). De header zorgt voor een correcte adressering van het bericht. Het transac on ID wordt door de client bij een aanvraag meegegeven, de server zal op dit bericht antwoord geven met hetzelfde transac on ID. Zo kan de client weten op welke aanvraag de server een bericht terug zendt. De Protocol Iden fier is voor Modbus TCP standaard 0. Verder wordt ook de lengte van het bericht meegegeven van het Modbus PDU bericht. Voor een leesopdracht (func e 3 = read holding register) is dit al jd gelijk aan 6. Deze 6 worden opgedeeld in 2 bytes voor de func ecode, 2 bytes voor het startadres van de gevraagde gegevens binnen het register en de hoeveelheid data die opgevraagd wordt. Verder is er ook nog de Unit Iden fier, deze is vooral belangrijk bij Modbus RTU. Er kan een waarde van 255 gekozen worden als Unit Iden fier om enkel het IP-adres en de poort te laten gelden als voorwaarde voor de communica e. Wanneer echter met Modbus RTU gewerkt wordt, zullen er geen IP-adressen zijn en moet er gewerkt worden met het Modbus slave adress als Unit Iden fier. 8
(a) Opbouw dataframe (b) Voorbeeld van een modbus dataframe Figuur 4.1: Modbus TCP dataframe Het dataframe van Modbus TCP bestaat niet enkel uit de hierboven beschreven elementen. Deze zit verpakt in eerst een Ethernet frame, dan een Internet Protocol (IP) pakket en een Transmission Control Protocol (TCP) segement. In het TCP/IP-gedeelte worden dan respec evelijk de des na on en source IP-adressen en des na on en source poorten meegegeven. Op die manier kan de communica e tussen 2 toestellen opgezet worden. 4.3 Applica e: Modbus - SQL server 4.3.1 Doel Om een alterna ef te bieden aan het loggen van gegevens via een PLC, werd een windows forms applica on gemaakt om rechtstreeks gegevens uit een toestel dat Modbus TCP ondersteunt te halen en weg te schrijven naar een SQL server. Het is de bedoeling dat het programma zo flexibel mogelijk is. Dit wil zeggen dat het verschillende soorten toestellen moet kunnen aanspreken alsook verschillende soorten en hoeveelheden gegevens moet kunnen ophalen en wegschrijven. Er zijn een aantal verschillende soorten nota es om in een register een waarde weg te schrijven. Zo kan de waarde al dan niet een teken beva en, kan deze met een vermenigvuldigingsfactor in het register staan,.... Al deze mogelijkheden moeten voorzien worden binnen het programma. Op die manier zal het programma in verschillende toepassingen inzetbaar zijn. 4.3.2 Func onele werking Concreet moet de gebruiker enkele parameters kunnen instellen. Hiermee wordt bedoeld dat de gebruiker enkele toestellen kan toevoegen met daarbijhorend IP-adres, poort, naam en modbus slave adress. Per toestel kunnen dan parameters ingesteld worden met daarbijhorend de naam, de plaats in het register, de groo e van de parameter, het datatype en de vermenigvuldigingsfactor. Op die manier kan een structuur gecreëerd worden. Eenmaal deze structuur ingesteld, kan de structuur opgeslagen worden. Dit gebeurt via een XML-file die gegenereerd wordt met alle huidige instellingen. Later kunnen deze instellingen dan ook terug geladen worden. Na de configura e van de toestellen kan het eerste luik van het programma al in werking gezet worden. Het uitlezen van de waarden kan gevolgd worden in de lijst met de parameters. Vervolgens moeten de gegevens nog gelogd worden naar een database op de server. Daarvoor moet het IP-adres, de poort en de loginnaam- en paswoord ingegeven worden. Ook moet de gebruiker een naam voor de database kiezen. Het schrijfinterval naar de SQL server is standaard een seconde, maar kan door de gebruiker aangepast worden. Vooraleer het loggen kan starten moet de database met de nodige tabellen aangemaakt of bijgewerkt worden. Per toestel wordt een tabel aangemaakt met voor iedere parameter een kolom. In de bijlage bevindt zich een handleiding om het programma te gebruiken. 9
Figuur 4.2: Overzicht van de interfaces van de applica e 4.3.3 Structurele opbouw van de so ware Wat de gebruiker te zien krijgt is de GUI (Graphical User Interface), hier gebeurt de interac e tussen de gebruiker en het programma. Het de bedoeling om via de GUI, de juiste zaken naar voor te brengen voor de gebruiker en de ac es (click-events) van de gebruiker op te vangen. Onder de GUI ligt dan de BLL (Business Logic layer). De taak van de BLL is om de click-events die vanuit de GUI komen, te vertalen in logische ac es binnen het programma. De BLL houdt ook de configira e van de toestellen en parameters bij. De communica e met de Modbus TCP toestellen en SQL server zijn zaken die niet tot het takenpakket van de BLL horen. Deze worden gedaan door de bijhorende DAL's (Data Acces Layer). Ook het opslaan van de configura e en laden van een configura e vanuit een XML-file is geen zuiver logische bewerking en wordt door een aparte DAL gedaan. Een overzicht van deze structuur is weergegeven in Figuur 4.3 Deze structuur hee het voordeel dat bij fouten in een bepaald deel, de diagnose sneller verloopt en dat een aanpassing in één van de DAL's geen effect hee op de andere. Het is perfect mogelijk om alle func onaliteiten in één klasse te stoppen. Dit hee als voordeel dat het compacter lijkt. Het feit dat het compacter lijkt, brengt wel met zich mee dat het programma moeilijk te begrijpen is voor buitenstaanders. Zo zal er veel jd verloren kunnen gaan als een ander persoon de so ware moet aanpassen. 10
Figuur 4.3: So warestructuur van de applica e 4.3.4 Fouta andeling Zoals bij elk programma kunnen er zich verschillende fouten voordoen waardoor het programma vast loopt. Deze fout kan bijvoorbeeld een oneindige loop zijn. Voor het gemaakte programma moest vooral de aandacht geves gd worden op de communica e tussen de applica e en de SQL-server alsook de communica e tussen de applica e en een modbustoestel. Hieronder zijn verschillende mogelijke fouten beschreven, samen met de oplossing om deze tevermijden. Foute IP-adressen Het ingeven van een incorrect IP-adres kan leiden tot het niet tot stand komen van een verbinding en er zal bij gevolg een fout optreden. Daarom is er binnen de applica e een rou ne aanwezig om te controleren of het IP-adres wel degelijk een juiste waarde is. Zo zullen waarden boven 255 niet aanvaard worden en moeten er 4 cijfers gesplitst door punten aanwezig zijn. Als dit niet het geval is krijgt de gebruiker een melding dat het IP-adres dat ingevoerd werd niet correct kan zijn. Verbinding maken met de server Om te voorkomen dat het programma vast loopt bij het opstarten van de verbinding met de database wordt eerst gecontrolleerd of het IP-adres van de server weldegelijk bereikbaar is met een ping-commando. Wanneer deze posi ef reageert zal de verbinding opgestart worden, zo niet zal de gebruiker een melding krijgen dat de server niet tot het netwerk behoort. Na de controle op het IP-adres wordt geprobeerd om de verbinding effec ef op te starten binnen een try-catchstructuur zoals Figuur 4.4 weergee. Op die manier kunnen mogelijke problemen bij het verbinden, het programma niet doen vastlopen. Wanneer dan een excep on opgevangen wordt, dan verschijnt een melding die weergee dat ofwel de poort, de login of het 11
paswoord niet correct is, aangezien dit de enige criteria zijn die mogelijk niet voldoen om een verbinding tot stand te brengen. Figuur 4.4: Try-catch structuur Verbinding maken met een modbusdevice Het vermijden van fouten bij het opbouwen van de verbinding met de modbustoestellen is analoog aan dat bij een server. Het enige verschil is dat er geen login en paswoord moet meegegeven worden. De kans dat de verbinding niet tot stand komt is met andere woorden kleiner. Wel is er een Modbusslaveadres dat correct meegegeven dient te worden. Om problemen daaromtrent te vermijden kan ook het broadcast slaveadres gekozen worden. Op die manier zal enkel het IP-adres van het toestel belangrijk zijn. Wegvallen van een verbinding Bij het wegvallen van een verbinding is de oorzaak zeker niet omdat het wachtwoord of login van de database fout zijn. Daarom is de oplossing voor zowel de server als een mee oestel gelijkaardig. Wanneer de verbinding wegvalt is dit het gevolg van een breuk binnen het netwerk of een verandering van IP-adres of het fysisch wegvallen van een toestel. Wanneer de verbinding wegvalt met de server, zal het loggen uiteraard stoppen. Maar vanaf het ogenblik de verbinding wegvalt wordt cyclisch opnieuw geprobeerd verbinding te maken met de server. Datzelfde concept wordt ook gebruikt wanneer een modbusdevice wegvalt uit het netwerk. Er kunnen wel verschillende toestellen hun connec e verliezen, deze worden in een aparte lijst bijgehouden. Om het programma niet te vertragen bij het uitlezen van de andere toestellen, worden deze verloren toestellen op een andere thread afgepold tot er terug connec e gemaakt kan worden. Dat wil zeggen dat het uitlezen van de toestellen parallel verloopt met het proberen te herstellen van de verloren verbindingen. Specifieke modbusfouten Wanneer een modbusframe ontvangen wordt met een errorcode in plaats van de gebruikelijke dataframes wordt a ankelijk van de errorcode een andere melding getoond naar de gebruiker toe. Wanneer zo'n frame slechts één keer voor komt in een lange jd zal geen aandacht geschonken worden aan deze error. Want dat betekent dat er slechts één maal een fout opgetreden is wat er op kan wijzen dat het niet om een erns ge fout gaat. Wanneer er echter bij verschillende cyclussen na elkaar dezelfde fout wordt meegegeven vanuit het toestel, zal de gebruiker hiervan op de hoogte gebracht worden. Fouten door de gebruiker Ten slo e kan de gebruiker nog steeds handelingen doen die niet echt logisch beschouwd kunnen worden. Een voorbeeld hiervan is beginnen loggen voordat er waarden uit de toestellen gehaald worden. Op die manier zou binnen het programma een query naar de database gestuurd worden zonder values. Dat zal door de database als een foute query bestempeld worden en er zal een error naar de applica e gestuurd worden. Om deze fout en gelijkaardige fouten te voorkomen, worden enkel de bu ons ac ef die actueel mogen bediend worden. De gebruiker wordt zo behoed voor eigen fouten. 12
5 Opslag en compressie van data Om een efficiënte visualisa e te verkrijgen moet goed nagedacht worden over de opslag van gegevens alsook de hoeveelheid gegevens die worden opgeslagen. Om een beeld te scheppen van deze mogelijkheden worden verschillende manieren voor het opslaan van gegevens besproken. Daarna wordt bekeken hoe de compressie van data moet toegepast worden op verschillende manieren. Dé oplossing of dé beste manier is er echter niet, alles hangt af van project tot project. 5.1 Structuur van de database Er zijn verschillende structuren mogelijk om gegevens op te slaan. De keuze van welke structuur gebruikt wordt, hee een invloed op de snelheid bij het opvragen van gegevens. Het is namelijk zo dat een select-query langer duurt naargelang er meer records zijn binnen de tabel waar gezocht wordt. Natuurlijk moet de structuur overzichtelijk zijn. Er moet dus een compromis gevonden worden tussen efficiën e en overzichtelijkheid. Een andere factor die ook meespeelt bij de keuze van de structuur is de uitbreidbaarheid. Hiermee wordt bedoeld dat er niet veel aanpassingen dienen te gebeuren wanneer er paramaters worden toegevoegd. Er kunnen 2 grote groepen van logging onderscheiden worden: horizontale en ver cale logging. Hieronder worden beide structuren met hun varianten besproken en worden de voor- en nadelen blootgelegd. Enkele zaken zijn noodzakelijk om de database op te bouwen: Alle parameters moeten in de database opgenomen worden Per parameter moet er geweten zijn van welk toestel en welke loca e deze a oms g is Er moet telkens een jds p zijn bij elke gemeten waarde 5.1.1 Horizontale structuur Met horizontale logging wordt bedoeld dat elke parameter een eigen kolom krijgt. Er wordt steeds een overzichtstabel aangemaakt die de structuur van het bedrijf bevat. De structuur van een gebouw of bedrijf is opgedeeld in loca es, eventueel subloca es en meters. Verdere opslitsingen zijn ook mogelijk. De verhouding ten opzichte van elkaar wordt weergegeven door twee kolommen. Een eerste die meegee of het om een loca e, subloca e, meter, etc. gaat. Dit gebeurt met een getal dat het "niveau"vastlegd. De tweede kolom zegt waar de subloca e of meter zich bevindt. Dit is telkens een object van bovenliggend niveau. Voor een toestel kan dat dan een subloca e zijn, voor een subloca e is dat dan weer een loca e. Het getal dat aangee waar het object deel van uit maakt refereert naar de primary key van de "parent". In de meeste gevallen zijn er verschillende meters waaruit waarden gelogd moeten worden. Elk van die meters moeten ook meestal dezelfde parameters meten en loggen. Bijvoorbeeld: een produc eproces met verschillende afdelingen en per afdeling wordt het energieverbruik bijgehouden alsook de spanning en stroom. Dan kan een tabel gemaakt worden met een kolom: energieverbruik, spanning en stroom. Dit met een extra kolom om aan te geven van welke meter de meetwaarden a oms g zijn. Hier zal de primary key van de overzichtstabel gelinkt worden aan die extra kolom die dan de foreign key voorstelt in de tabel met meetwaarden. Een voorbeeld van deze structuur wordt hieronder weergegeven. 13
Figuur 5.1: Opbouw van een database voor horizontale logging Figuur 5.1 toont het systeem waar verschillende equivalente meters moeten gelogd worden. Deze methode hee het nadeel dat er meer records in de tabel aanwezig zijn dan wanneer er per toestel één tabel aangemaakt wordt. Dit hee nefaste gevolgen op de snelheid. Vertrekkende van dat opzicht kan dus overwogen worden verschillende tabellen te maken voor ieder toestel. Om dan vanuit de overzichtstabel te kunnen refereren naar een bepaald toestel, wordt in de overzichtstabel een extra kolom aangemaakt die de naam van de tabel voor elk toestel bevat. Deze methode moet ook al jd gehanteerd worden als verschillende mee oestellen, niet dezelfde parameters moeten loggen. Het is wel zo dat deze horizontale structuur toelaat om gemakkelijker gegevens te loggen. Zo kunnen met één INSERT-commando verschillende gegevens gelogd worden. In dat opzicht is deze vorm van loggen een goede keuze wanneer de datacapta e moeilijker is dan de visualisa e. 5.1.2 Ver cale structuur De basis van ver cale logging is een tabel met een oplijs ng van alle parameters. Om de meetwaarden te loggen wordt een tabel gemaakt met minstens vijf kolommen. Deze kolommen bestaan uit een primary key (index), het jds p van de mee ng, de waarde van de me ng zelf, de betreffende parameter en het toestel die de me ng deed. Er zijn dus als het ware 2 overzichtstabellen, 1 voor de hiëarchie van het gebouw en 1 voor de verschillende parameters. In figuur 5.2 wordt de beschreven structuur visueel weergegeven. Figuur 5.2: Opbouw van een database voor ver cale logging 14
Bij deze structuur kan er zich wel een probleem voordoen. Omdat er slechts 1 kolom is om alle meetwaarden in te plaatsen, kan slechts 1 datatype gebruikt worden. Wanneer meerdere soorten datatypes moeten gelogd worden, is het noodzakelijk om het datatype van de kolom in te stellen als "nchar()", dit neemt met zich mee dat alle waarden eerst geconverteerd moeten worden van string naar bijvoorbeeld een integer of real/double. Dit vraagt extra werk van de visualisa e en leidt ook tot een vertraging van de visualisa e. Om dit probleem op te lossen kan voor elk datatype een andere tabel gemaakt worden. Wel moet gezegd dat er in de meeste gevallen enkel numerieke waarden nodig zijn en met het type decimal(,) gewerkt kan worden. Er kan ook per toestel een tabel gemaakt worden met ver cale logging, dit om het aantal records per tabel te verkleinen en de zoekac e te versnellen. Ook hier moet in de overzichtstabel dan verwezen worden naar welke tabel bij welk toestel hoort. Een andere variant op ver caal loggen is dat een tabel wordt bijgehouden met de verschillende paramaters en dat binnen die tabel enkele malen dezelfde parameter voorkomt, maar dan gelinkt aan een ander toestel. Een voorbeeld daarvan is hieronder te zien. In dit voorbeeld zijn 3 mee oestellen aanwezig die spanning en stroom opmeten, de figuur toont aan hoe de tabel met parameters er dan uitziet. Lijnrecht tegenover de horizontale structuur is de ver cale structuur veel minder gebruiksvriendelijk wat het loggen van gegevens betre. Per parameter moet een INSERT-commando gedaan worden en er moet steeds een link gelegd worden tussen de waarde en de plaats in de lijst met parameters. Langs de andere kant is deze structuur wel handig voor de visualisa e. Door alle waarden te voorzien van een Foreign Key met de parameter, kunnen snel alle waarden van 1 bepaalde parameter opgevraagd worden. Dat is een op e die veel nodig is bij het visualiseren van data doorheen de jd. Figuur 5.3: Tabel met parameters 5.2 Comprimeren van data Het comprimeren van data is zoals herhaaldelijke keren aangehaald essen eel voor de snelheid van het opvragen van gegevens. Proefondervindelijk werd vastgesteld dat vanaf een aantal om en bij de 800 000 records een storend effect wordt ervaren bij de visualisa e van gegevens. De wach jd is iets die ten alle jde moet geminimaliseerd worden. De resolu e van de visualisa e mag natuurlijk niet lijden onder de compressie, maar bij een groot aantal me ngen is de resolu e van het scherm de beperkende factor. Daardoor is het geen probleem om de gegevens te comprimeren. Het comprimeren op zich is eigenlijk gebaseerd op het uitmiddelen van waarden. Dit gebeurt als volgt: er worden een aantal waarden samengenomen en van deze waarden wordt het gemiddelde genomen. Er wordt al jd gezorgd voor een oneven aantal omdat dan gemakkelijk het jds p van de middelste waarde kan genomen worden. Dit is mogelijk omdat er gelogd wordt met een constant interval. De gecomprimeerde data kunnen dan verwijderd worden of in een back-up bewaard worden indien nodig. Zo wordt het aantal 15
rijen gereduceerd. Soms is het ook handig om een minimum- en maximumwaarde binnen het interval te kennen. Dan kunnen ook deze waarden bijgehouden worden. Voor de verschillende databasestructuren wordt de compressie anders toegepast. Wat gebeurt met de gecomprimeerde data wordt verder buiten beschouwing gelaten omdat dit telkens op hetzelfde neerkomt: er zijn twee mogelijkheden, deze kan verwijderd worden of ergens apart opgeslagen worden in een back-upfile. 5.2.1 Compressie bij horizontale logging Bij horizontale logging worden alle meetwaarden in één keer uitgemiddeld. De eerste "x aantal rijen, gesorteerd op jd van laat naar vroeg van éé toestel worden geselecteerd. Daarna worden de gemiddeldes van alle kolommen met meetwaarden berekend en de resultaten worden in de tabel geplaatst. Het nadeel bij horizontale logging is dat als er een minimim- en maximimwaarde moet bijgehouden worden, er twee extra kolommen nodig zijn per parameter die oorspronkelijk niet gebruikt worden. Dit kan overzichtelijker gemaakt worden door twee extra iden eke tabellen te maken voor de minimum- en maximumwaarden. Als dan gewerkt wordt met een aparte tabel voor ieder toestel, zijn er drie tabellen nodig per toesel wat minder overzichtelijk is. Figuur 5.4 toont aan hoe de compressie kan gebeuren bij horizontale logging. De tabellen met minima en maxima zijn niet al jd nodig. Figuur 5.4: Compressie bij horizontale logging 5.2.2 Compressie bij ver cale logging Bij ver cale logging is het principe voor het comprimeren van data gelijkaardig aan dat van horizontale logging. Wel moet iedere parameter apart aangesproken worden over een bepaald jdsdomein en daarna kan de gemiddelde waarde binnen dat domein bepaald worden. Om mininum- en maximumwaarden bij te houden moeten enkel in de tabel met de oplijs ng van welke parameters er bestaan, 2 nieuwe parameters aangemaakt worden per oorspronkelijke parameter. Figuur 5.5 verduidelijkt het principe dat gehanteerd kan worden. Zoals eerder vermeld is ver caal loggen flexibel bij uitbreidingen. Daar data comprimeren ook als een soort van uitbreiding kan gezien worden, is deze vorm van loggen dan ook gemakkelijker wat compressie van data betre. 16
Figuur 5.5: Compressie bij ver cale logging 17
6 Webvisualisa e 6.1 Inleidend project: Powerqualitymonitor 6.1.1 Doel Om vertrouwd te raken met MVC en webmonitoring is een inleidend project een perfecte instap. De doelstelling van dit project is meetwaarden vanuit een EMpro, een toestel dat allerhande elektrische grootheden opmeet, visueel te maken op een webpagina. Dit mee oestel ondersteunt Modbus TCP. Alle waarden die dit toestel meet, bevinden zich dus in de modbusregisters van het toestel. Het is de bedoeling om alle relevante waarden uit het register te halen, op te slaan in een database en te visualiseren met behulp van een MVC-project. Het project wordt toegepast op een bestaande mobiele opstelling waar 3 EMpro's aanwezig zijn. 6.1.2 Beschrijving van de func onele werking Op de webpagina moeten er twee verschillende tabbladen voorzien worden, één om drie grafieken te tonen per EMpro en één om een tabel met alle gewenste waarden te tonen, om de seconde moeten de gegevens in deze tabbladen upgedatet worden. De webpagina wordt gebruikt om voorstellingen te geven en een verschil in powerquality te demonstreren bij verschillende aanslui ngmethodes en belas ngen. Vanuit dat standpunt is de vraag er ook om de grafieken te kunen freezen. Daarmee wordt bedoeld dat de grafiek jdelijk stopt met het tonen van de actuele waarde, maar de waarde vasthoudt van wanneer deze func e opgeroepen wordt. Op deze manier kunnen twee toestanden gemakkelijk vergeleken worden. Zo kan het verschil getoond worden tussen het moment voor een belas ng wordt ingeschakeld en erna. Er zijn drie soorten grafieken voorzien: een staafdiagram met de harmonische waarden van stroom en spanning, een grafiek met het signaal van de stroom en spanning en één met het fasediagram van de stroom ten opzichte van de spanning. De lijst is ongeveer voorzien van dezelfde grootheden, maar daar komen de precieze waarden in terecht, deze worden dus niet bewerkt. 6.1.3 Mogelijke oplossingen Om de gegevens uit het toestel te halen zijn er verschillende mogelijkheden, er kan gebruik gemaakt worden van een.net- applica e of er kan gebruik gemaakt worden van een PLC die de data ophaalt en wegschrij naar een database. Deze database kan op een locale server draaien, maar het is ook mogelijk om een server op het web te gebruiken. Ook de structuur van de database (horizontaal of ver caal) ligt niet vast. Zo zijn er enkele beslissingen die dienen gemaakt te worden alvorens het project te beginnen. De structuur van de webapplica e is uiteraard het MVC-model, dat doorheen de gehele masterproef gebruikt wordt. 6.1.4 Beschrijving van de gekozen methode De jd om een.net-applica e te creëren is beduidend hoger dan een PLC-programma te maken. Dit omdat er reeds func ebouwstenen bestaan voor zowel Modbus TCP als SQL server. Omdat het project geen al te grote jdspanne in beslag zou nemen en de.net-applica e nog niet gemaakt was op het moment van dit project, is dus voor de kortste oplossing gekozen. Het feit dat in de opstelling al een PLC ter beschikking is, zorgt er voor dat deze keuze geen kosten met zich meebrengt. Het PLC-programma moet dus data wegschrijven naar een SQL server. Deze staat lokaal binnen het netwerk van de opstelling. Dit is de beste oplossing aangezien de opstelling een 18
mobiele opstelling is en overal moet kunnen werken. Wanneer er geen verbinding is met het web kan de opstelling zo blijven werken. Verder wordt een horizontale structuur van de database gekozen omdat deze gemakkelijker is om gegevens te loggen. Aan de kant van de visualisa e is dan wel meer werk om de gegevens op te halen en te plaatsen. Het extra werk dat door de horizontale structuur voortkomt is wel beperkt aangezien het niet over een groot en complex project gaat. De datastroom kan met behulp van Figuur 6.1 verduidelijkt worden. Alle toestellen zijn verbonden binnen één netwerk via een switsch. Eerst zal de PLC gegevens opvragen via Modbus TCP vanuit de 3 EMpro's. De PLC verwerkt deze gegevens en logt deze via TCP/IP naar de database die op de IPC staat. Ten slo e zal het MVC-project de gegevens ophalen vanuit de database. Ook dit gebeurt via TCP/IP (intern in de IPC) daarna wordt de visualisa e op basis van die gegevens naar de gebruiker weergegeven. Figuur 6.1: Weegave van de opstelling De visualisa e begint dus bij het PLC-programma dat de gegevens logt naar de database. De database zorgt niet enkel voor het loggen van gegevens, maar ook voor het leegmaken van de tabellen op regelma ge basis. Wanneer dit niet zou gebeuren zou er na verloop van jd een storende vertraging merkbaar zijn bij het visualiseren. Dit door het grote aantal records dat zich in de database zouden bevinden. Een select-query duurt over het algemeen niet lang. Door het gebruik van een IPC, waarvan de processor niet de snelheden haalt van die van een gewone PC, lopen die jden na verloop van jd toch stevig op. Daarom is het noodzakelijk om het aantal records in de database te beperken. De opstelling wordt ook enkel gebruikt om voorstellingen te geven, dus is enkel de actuele waarde van belang. Vanaf het moment dat er gegevens in de database beschikbaar zijn is het de beurt aan het MVC-project om de visualisa e van de gegevens te maken. Verder worden de func es van dit project beschreven. MODEL Het Model is een datastructuur die voorzien is van verschillende eigenschappen. In dit project wordt gebruik gemaakt van een Model, "Mee ng", met als eigenschappen: jd, spanning, stroom,.... Het is de bedoeling dat deze ingevuld worden door de gegevens in de database en dan verder kunnen verwerkt worden binnen het project. 19
CONTROLLER De Controller zorgt voor alle interac es tussen Model en buitenaf (Database) en tussen de View en de User. Hier is de Controller dus verantwoordelijk om de gegevens uit de database op te vragen en deze binnen het Model Mee ng te stoppen. Verder wordt de getoonde View ook bepaald door de controller aan de hand van de ac es van de gebruiker van de webpagina. De ac es voor het veranderen van View is het klikken op de ene of het andere tabblad bovenaan de webpagina. Volgens de theorie zou de interac e met de database eigenlijk via het Model moeten gebeuren. Om prak- sche redenen wordt deze func onaliteit binnen het project echter gedaan in de Controller. De Controller zal dan na het opvragen van gegevens, deze verwerken en wegschrijven in het Model. VIEW Een View is de visuele weergave van de webpagina, deze ligt vast, op enkele parameters na. Er bevinden zich twee tabbladen in dit project, één met de grafieken en één met de tabel. Dit vertaalt zich in twee Views die moeten gemaakt worden. Om dynamische elementen binnen deze Views te bekomen moet er gebruik gemaakt worden van javascript. Het javascript zal zo de grafieken maken en om de seconde updaten. Verder zal het javascript een klik op bepaalde knoppen die aanwezig zijn in de View opvangen en de gewenste ac e ondernemen. Zelf een grafiek ontwerpen ligt niet binnen het bereik van deze masterproef, daarvoor worden bepaalde bibliotheken gebruikt. Deze zijn ook in de vorm van een javascript dat toegevoegd moet worden in het project. Zo kan er op een snelle manier gewerkt worden. Deze bibliotheken zijn gra s op het web te verkrijgen. De bibliotheek die in dit project gebruikt wordt heet: "Jquery". Deze bestaat uit verschillende soorten grafieken met voor elke soort grafiek een aangepast script. Figuur 6.2: Lay-out van de gemaakte webpagina 20