Voorwoord. Uitbreiden van domoticasysteem in een distributiebedrijf

Voorwoord Ik zal mezelf eerst even voorstellen alvorens aan de thesis te beginnen. Ik ben Bart Nottebaert en zit momenteel in het laatste jaar van de opleiding ‘master in de industriële wetenschappen elektrotechniek afstudeerrichting automatisering’ aan de HOWEST te Kortrijk. Ik ben begonnen aan de vierjarige master opleiding in september 2007 na mijn middelbare studies in het ‘Spes Nostra Instituur’ te Kuurne. Als laatstejaarsstudent is het de bedoeling om een eindwerk of masterproef te maken. Deze masterproef biedt de mogelijkheid om te bewijzen dat je in staat bent om in het bedrijfsleven te stappen na het behalen van uw diploma. De masterproef die ik gekozen heb, handelt over het thema domotica. In de opleiding wordt domotica niet of nauwelijks toegelicht. Dit is de belangrijkste reden waarom ik deze masterproef heb gekozen. De titel van deze masterproef luidt ‘Uitbreiden van domoticasysteem in een distributiebedrijf’. Het distributiebedrijf waar deze masterproef doorgaat is Thermote & Vanhalst. Dit is een firma die gespecialiseerd is in heftruckonderdelen en al wat daarbij komt kijken. Ik heb deze masterproef uitgevoerd in de afdeling SCADA met de hulp van de mensen die daar werken. Zonder hen was het onmogelijk om deze masterproef tot een goed einde te brengen. Daarom wil ik de ganse afdeling bedanken voor hun ondersteuning en in het bijzonder Stijn De Smet. Hij is de persoon die het meest bij het domoticasysteem betrokken is en dus de uitgelezen persoon voor de nodige ondersteuning. Wie ik ook nog moet bedanken is mijn interne promotor, Henk Capoen en mijn externe promotor, Erik Deceuninck. Dankzij deze twee personen was het mogelijk om deze masterproef uit te voeren en waar nodig te ondersteunen. Ik wil Erik Deceuninck ook nog eens bedanken voor de opleiding die ik heb mogen meemaken in Duitsland. Dankzij deze opleiding heb ik veel nuttige zaken geleerd over het domoticasysteem die ik heb toegepast in mijn masterproef. Ik zou ook graag de mensen van de firma WAGO en SOCOMEC willen bedanken voor al hun deskundige antwoorden op mijn vragen. Ook dankzij deze mensen was het mogelijk om deze masterproef tot een goed einde te brengen. Tot slot wil ik nog mijn ouders en mijn broer bedanken voor al hun steun doorheen het jaar. Mijn dank gaat ook uit naar mijn oom voor het vele nalees- en verbeterwerk van deze thesis.

Uitbreiden van domoticasysteem in een distributiebedrijf

I

Abstract This paper is about an enlargement of a building automation system at the company Thermote & Vanhalst. This is a well known company in selling all kind of forklift parts, they can deliver more than 450 000 parts. The parts are stored in a huge warehouse with automatic cranes. To deliver the parts with a competitive price to the customer it is necessary to have a efficient organization of the company. With the build of the site at Waregem they installed an intelligent building automation system. This system can increase the efficiency of the company with an intelligent lightning control, solar blends control, heating control and much more. At the beginning of this paper Thermote & Vanhalst had two problems, a problem with the heating and a problem with manual listen of all electrical consumptions. The solution for the first problem is an intelligent heating control and the solution for the second problem is an energy management system. Each solution must be realized in this paper. The heating problem is located at the offices of the building where many people are together in one room. Not everybody wants it as cold or as heat as the others, so there are many adjustments to the radiators. This causes an inefficient use of the heating system. Because of this, the responsible employee of the room needs to do every evening a tour to shut down all radiators in the room. It would be better to control all radiators automatically and intelligent with the building automation system. To make such a intelligent heating control system all components need to be searched and be chosen. The most important components will be a valve to control the hot water circuit, a sensor to measure the room temperature and a controller to calculate the value for the valve. All those components need to be implemented in the building automation system. With those components is an basic heat control system realized but that wasn’t according the instruction to create an intelligent heat control system. So it is necessary to make a study if it is possible to add some intelligence to het heating control. It would be nice to create some intelligence to calculate the optimal start time for the heating control. This kind of intelligence calculates the optimal start time with the combination of the room temperature and the outdoor temperature. The second mission is about the energy management system. In each electrical cabinet is a measure module installed who measures current, voltage, electrical power and many more electrical parameters. The module must be read out into a controller. The controller has to convert the data to the protocol used in the building automation system. When the data is available on the building automation system, the server of the system analyses all the data. In a first stage, all needed components need to be searched and ordered. The second stage consist of programming the controller to get the data outside the measure module and translate them into the right protocol for the building automation system. In the last stage the server must be programmed to analyze, visualize, archive, alarming the data from the measure modules. It must also be possible to mail the electrical consumptions to the responsible employee. The most important alarm in the energy management system is when the voltage drop or rises above a defined lower and upper limit. Before this paper there was no possibility to alarm when the voltage drops of rises above the limits.


II

Inhoudsopgave VOORWOORD ...................................................................................................................................... I ABSTRACT .......................................................................................................................................... II INHOUDSOPGAVE ........................................................................................................................... III FIGURENLIJST .................................................................................................................................. VI TABELLENLIJST ............................................................................................................................ VIII 1

INLEIDING .................................................................................................................................... 1

2

DOELSTELLINGEN...................................................................................................................... 2

2.1. Verwarmingsregeling ................................................................................................................................ 2 2.2. Energiebeheersysteem .............................................................................................................................. 2

3

BEDRIJFSVOORSTELLING ....................................................................................................... 3

3.1. Algemeen .................................................................................................................................................. 3 3.2. Geschiedenis ............................................................................................................................................. 3

4

DOMOTICA MET KNX................................................................................................................ 4

4.1. Algemeen .................................................................................................................................................. 4 4.2. Evolutie in TVH .......................................................................................................................................... 5 4.3. Huidig domoticasysteem ........................................................................................................................... 6

5

SOFTWARE ................................................................................................................................... 7

5.1. WAGO CoDeSys V2.3 ................................................................................................................................. 7 5.2. ‘ETS3’......................................................................................................................................................... 8 5.3. GIRA Expert ............................................................................................................................................... 9

6

VERWARMINGSREGELING ................................................................................................... 10

6.1. Inleiding .................................................................................................................................................. 10 6.2. Actor ....................................................................................................................................................... 10 6.2.1. Mogelijkheden ........................................................................................................................................ 10 6.2.2. Uiteindelijke keuze .................................................................................................................................. 11 6.2.3. Configuratie in ‘ETS3’ .............................................................................................................................. 11 6.3. Regelaar .................................................................................................................................................. 12 6.3.1. Mogelijkheden ........................................................................................................................................ 12 6.3.2. Uiteindelijke keuze .................................................................................................................................. 13 6.4. Sensor ..................................................................................................................................................... 14 6.4.1. Mogelijkheden ........................................................................................................................................ 14 6.4.2. Uiteindelijke keuze .................................................................................................................................. 14 6.4.3. configuratie in ‘ETS3’............................................................................................................................... 15 Uitbreiden van domoticasysteem in een distributiebedrijf

III

6.5. Extra intelligentie .................................................................................................................................... 15 6.5.1. Mogelijkheden ........................................................................................................................................ 15 6.5.2. Implementatie ......................................................................................................................................... 16 6.6. Resultaten ............................................................................................................................................... 17 6.6.1. Zonder extra intelligentie ........................................................................................................................ 17 6.6.2. Met extra intelligentie............................................................................................................................. 19 6.7. Besluit ..................................................................................................................................................... 20

7

ENERGIEBEHEERSYSTEEM .................................................................................................. 21

7.1. Inleiding .................................................................................................................................................. 21 7.2. Meetmodule ........................................................................................................................................... 22 7.2.1. Algemeen ................................................................................................................................................ 22 7.2.2. Communicatiemodule ............................................................................................................................. 23 7.3. Busconfiguratie ....................................................................................................................................... 24 7.3.1. Keuze ....................................................................................................................................................... 24 7.3.2. Installatie ................................................................................................................................................. 24 7.3.3. Versterker ............................................................................................................................................... 25 7.4. Controller ................................................................................................................................................ 27 7.4.1. Algemeen ................................................................................................................................................ 27 7.4.2. WAGO Ethernet Settings (4.7) ................................................................................................................ 28 7.4.3. Programmeerbare RS485-klem ............................................................................................................... 29 7.4.4. WAGO-IO-Check 3 (3.2)........................................................................................................................... 30 7.4.5. WAGO Controller in ‘ETS3’ ...................................................................................................................... 32 7.5. GIRA FacilityServer .................................................................................................................................. 35 7.5.1. Algemeen ................................................................................................................................................ 35 7.5.2. Registratie en Bewaking .......................................................................................................................... 35 7.5.3. Visualisatie .............................................................................................................................................. 35 7.6. Realisatie ................................................................................................................................................. 36 7.6.1. Overzicht ................................................................................................................................................. 36 7.6.2. Controller software project ..................................................................................................................... 36 7.6.3. ‘ETS3’ configuratie .................................................................................................................................. 43 7.6.4. GIRA FacilityServer .................................................................................................................................. 44 7.6.5. Opmerkingen........................................................................................................................................... 49 7.6.6. Uitbreiding: compressor ......................................................................................................................... 49 7.6.7. Uitbreiding: spanningsmeting ................................................................................................................. 50 7.7. Besluit ..................................................................................................................................................... 51

8

MODBUS ..................................................................................................................................... 52

8.1. Algemeen ................................................................................................................................................ 52 8.2. Applicatielaag .......................................................................................................................................... 52 8.2.1. Protocol ................................................................................................................................................... 52 8.2.2. Datamodel ............................................................................................................................................... 53 8.2.3. Functiecodes ........................................................................................................................................... 54 8.3. Datalinklaag ............................................................................................................................................ 56 8.3.1. Algemeen ................................................................................................................................................ 56 8.3.2. Adressering ............................................................................................................................................. 56 8.3.3. Transmissie mode ................................................................................................................................... 57 8.4. Fysische laag ............................................................................................................................................ 59 Uitbreiden van domoticasysteem in een distributiebedrijf

IV

9

KNX .............................................................................................................................................. 61

9.1. Inleiding .................................................................................................................................................. 61 9.2. Open standaard ....................................................................................................................................... 61 9.3. Systeemstructuur .................................................................................................................................... 62 9.3.1. Topologie................................................................................................................................................. 62 9.3.2. Niveaus .................................................................................................................................................... 63 9.3.3. Adressering ............................................................................................................................................. 64 9.3.4. Programmatie ......................................................................................................................................... 65

10 LITTERATUURLIJST ............................................................................................................... 66


V

Figurenlijst figuur 1: Logo TVH................................................................................................................................................... 3 figuur 2: Conventionele schakeling ......................................................................................................................... 4 figuur 3: Schakeling met KNX .................................................................................................................................. 4 figuur 4: Iconag internetapplicatie.......................................................................................................................... 5 figuur 5: Configuratie domoticasysteem ................................................................................................................. 6 figuur 6: Startscherm CoDeSys V2.3 ........................................................................................................................ 7 figuur 7: Startscherm van ‘ETS3’ ............................................................................................................................. 8 figuur 8: Startscherm GIRA Expert .......................................................................................................................... 9 figuur 9: Algemeen regelschema verwarming ...................................................................................................... 10 figuur 10: GIRA verwarmingsactor met aangesloten ventielen ............................................................................ 11 figuur 11: Instellingen in ‘ETS3’ van de verwarmingsactor ................................................................................... 12 figuur 12: Verwarmingsregelaar ........................................................................................................................... 13 figuur 13: Ingestelde verwarmingsregelaar .......................................................................................................... 14 figuur 14: Theben RAM 712 .................................................................................................................................. 14 figuur 15: Instellingen in ‘ETS3’ van de Theben RAM 712 ..................................................................................... 15 figuur 16: 'Optimized start - stop' algoritme ......................................................................................................... 16 figuur 17: Client-applicatie verwarmingsregeling deel 1 ...................................................................................... 17 figuur 18: Client-applicatie verwarmingsregeling deel 2 ...................................................................................... 18 Figuur 19: Grafiek verwarmingsregeling ............................................................................................................... 18 figuur 20: Grafiek verwarmingsregeling met 'Optimized start - stop' algoritme .................................................. 19 figuur 21: Principeschema energiebeheer ............................................................................................................. 21 figuur 22: Diris Ap module..................................................................................................................................... 22 figuur 23: Modbus communicatiemodule ............................................................................................................. 22 figuur 24: Modbusconfiguratie met omvormer .................................................................................................... 23 figuur 25: Klassieke Modbus RTU configuratie ..................................................................................................... 23 figuur 26: Communicatiemodule aangesloten op Diris Ap .................................................................................... 23 figuur 27: Schematische voorstelling busconfiguratie .......................................................................................... 25 figuur 28: Busconfiguratie op het grondplan ........................................................................................................ 25 figuur 29: Socomec versterker............................................................................................................................... 26 figuur 30: Aansluitschema .................................................................................................................................... 26 figuur 31: Locatie van afsluitweerstanden ............................................................................................................ 27 Figuur 32: Wago controller 750-849 ..................................................................................................................... 27 figuur 33: Opbouw Wago KNX/IP-controller ......................................................................................................... 28 figuur 34: WAGO Ethernet Setttings (4.7) ............................................................................................................. 29 figuur 35: Programmeerbare RS485-klem ............................................................................................................ 29 figuur 36: Aansluitschema RS485-klem ................................................................................................................. 30 figuur 37: WAGO-IO-Check 3 (3.2) ........................................................................................................................ 31 figuur 38: Instellingen van programmeerbare RS485-klem .................................................................................. 31 figuur 39: Scherm ‘Options’ ................................................................................................................................... 32 figuur 40: Scherm ‘Set object attributes’............................................................................................................... 33 figuur 41: Configuratie WAGO controller .............................................................................................................. 34 figuur 42: IP settings voor de KNX/IP-controller ................................................................................................... 34 figuur 43: Hardware configuratie energiebeheer ................................................................................................. 36 figuur 44: Projectstructuur WAGO controller ........................................................................................................ 37 Uitbreiden van domoticasysteem in een distributiebedrijf

VI

figuur 45: Modbus task ......................................................................................................................................... 38 figuur 46: Functieblok Modbus master ................................................................................................................. 39 figuur 47: '4-byte float' KNX-telegram .................................................................................................................. 42 figuur 48: Groepsadressen in ‘ETS3’ ...................................................................................................................... 44 figuur 49: Archief van module 22 via ‘Internet Explorer’ ...................................................................................... 45 figuur 50: Configuratie 'Grafic logic editor' van Module 1 .................................................................................... 46 figuur 51: Menustructuur van de client- applicatie voor module 22 ..................................................................... 47 figuur 52: Hoofdscherm visualisatie ...................................................................................................................... 47 figuur 53: Visualisatiepagina van module 22 ........................................................................................................ 48 figuur 54: Automatische e-mail met meterstanden .............................................................................................. 48 figuur 55: IN/OUT module ..................................................................................................................................... 50 figuur 56: Modbus communicatie stack ................................................................................................................ 52 figuur 57: Algemeen Modbus frame ..................................................................................................................... 52 figuur 58: Standaard Modbus communicatie........................................................................................................ 53 figuur 59: Fout bij Modbus communicatie ............................................................................................................ 53 figuur 60: Datamodel Modbus .............................................................................................................................. 54 figuur 61: Publieke functiecodes ........................................................................................................................... 55 figuur 62: Foutafhandeling bij functiecode 3 ........................................................................................................ 56 figuur 63: Invulling van Modbus ADU frame volgens seriële communicatie......................................................... 56 figuur 64: Modbus request/reply bericht .............................................................................................................. 57 figuur 65: Modbus multicastbericht ...................................................................................................................... 57 figuur 66: Modbus RTU karakter ........................................................................................................................... 58 figuur 67: Modbus RTU frame ............................................................................................................................... 58 figuur 68: Modbus RTU timing .............................................................................................................................. 58 figuur 69: Modbus ASCII karakter ......................................................................................................................... 58 figuur 70: Modbus ASCII frame ............................................................................................................................. 59 figuur 71: busstructuur Modbus met seriële communicatie ................................................................................. 59 figuur 72: KNX logo ............................................................................................................................................... 61 figuur 73: KNX bus ................................................................................................................................................. 61 figuur 74: KNX bustopologie ................................................................................................................................. 63 figuur 75: Structuur van een lijn ............................................................................................................................ 63 figuur 76: Structuur van een hoofdlijn .................................................................................................................. 64 figuur 77: Structuur van een backbone ................................................................................................................. 64 figuur 78: Logo ETS4.............................................................................................................................................. 65


VII

Tabellenlijst tabel 1: I/O van verwarmingsregelaar .................................................................................................................. 13 tabel 2: Kostprijs met klassieke Modbus RTU configuratie ................................................................................... 24 tabel 3: Kostprijs met Modbus omvormer ............................................................................................................. 24 tabel 4: Mappingparameters Diris Ap meetmodule.............................................................................................. 38 tabel 5: Beschrijving IO Modbus master ............................................................................................................... 39 tabel 6: Structuur van 'ReceiveBuffer' ................................................................................................................... 40 tabel 7: datamodel van Modbus ........................................................................................................................... 54 tabel 8: Request bij functiecode 03 ....................................................................................................................... 55 tabel 9: Response bij functiecode 03 ..................................................................................................................... 55 tabel 10: Foutbericht bij functiecode 03................................................................................................................ 55 tabel 11: Aanbevolen kleurencode voor RS485 Modbus kabel ............................................................................. 60


VIII

1

Inleiding

Thermote & Vanhalst, afgekort TVH is al jaren gekend als het bedrijf bij uitstek voor heftruck onderdelen, verhuur, reparatie en nog veel meer. Om al die onderdelen en services te kunnen leveren, moet het bedrijf enorm goed en efficiënt georganiseerd zijn. Alleen dan zal het mogelijk zijn om concurrentiële prijs te vragen voor de onderdelen en services. Deze masterproef heeft feitelijk niets te maken met heftrucks maar wel met de goede werking van TVH. Deze masterproef beschrijft twee opdrachten die een algemene verbetering moeten brengen binnen TVH. Beide opdrachten moeten geïmplementeerd worden in het domoticasysteem dat al aanwezig is in het bedrijf. De eerste opdracht moet zorgen voor een verwarmingsregeling met ingebouwde intelligentie. In het bedrijf zijn veel lokalen voorzien van centrale verwarming met handbediende, thermostatische kranen. De gebouwen zijn voornamelijk ingedeeld in grote bureau-eilanden waardoor veel mensen in één grote ruimte zitten. Dit heeft als gevolg dat niet op iedere plaats een zelfde temperatuur heerst waardoor de verwarming veel manueel bijgeregeld wordt. Ook het feit dat niet iedereen graag even warm of koud heeft, zal voor problemen zorgen bij het instellen van de verwarming. Dit resulteert in slordig gebruik van de thermosstatisch kranen en dus ook van energie. Uit dit probleem komt al snel de eerste opdracht, namelijk het voorzien van een slimme verwarmingsregeling. Hiermee moet het mogelijk zijn het lokaal bij openingstijd op de gewenste temperatuur te krijgen. Zo is het voor de werknemers mogelijk zich volledig op hun werk te concentreren en niet meer onnodig de thermostatische kranen te regelen. Daarnaast moet het mogelijk zijn om de verwarming op één plaats met één wenswaarde te voorzien zodat alle radiatoren eenzelfde instelling hebben. Dit moet het werk van de verantwoordelijke verminderen omdat die iedere avond alle radiatoren moet manueel afschakelen. Een tweede probleem bij TVH is het loggen van de elektrische verbruiken. Per schakelkast is een meetmodule voorzien die heel wat verschillende elektrische grootheden meet. Iedere maand moet iemand alle meterstanden van de verbruiken aflezen, opschrijven en loggen in een Excel bestand. Dit is een zeer tijdsrovende bezigheid en het zou goed zijn als dit automatisch zou verlopen. Aangezien de meetmodules niet enkel het verbruik maar ook stromen, spanningen en vermogens is het mogelijk om een energiebeheersysteem op te zetten. Het energiebeheersysteem moet ook geïmplementeerd worden in het domoticasysteem zodat de elektrische parameters gevisualiseerd, gearchiveerd, geanalyseerd worden. indien het nodig is, moet ook gealarmeerd worden naar de verantwoordelijken zodat tijdig een gepaste actie kan ondernomen worden. In deze opdracht staan twee netwerkprotocollen centraal, namelijk Modbus voor de meetmodules en KNX voor het domoticasysteem. Het uitvoeren van deze twee opdrachten zal voor het bedrijf een besparing betekenen in personeelskosten en energie. De verwarmingsregeling zal een besparing in personeel en een comfortverhoging betekenen voor het bedrijf. Maar ook het energiebeheersysteem levert een enorme meerwaarde op omdat allerlei problemen aan het licht kunnen komen. Als deze problemen op een goede manier geanalyseerd worden, kan er terug veel bespaard worden.


1

2

Doelstellingen

De algemene doelstellingen van domotica zijn energiebesparing en het verhogen van het comfort van de gebruikers of bewoners van het gebouw. Het systeem staat in dienst van de gebruikers en werkt volledig in de achtergrond. In TVH is het huidige domoticasysteem aan uitbreiden toe met onder andere een verwarmingsregeling in alle ruimtes met centrale verwarming en een energiebeheersysteem. Elk van deze opdrachten heeft zijn eigen doelstellingen. Maar voor er gestart kan worden met deze twee opdrachten moet het domoticasysteem bestudeerd worden. Daarvoor is het nodig om een studie te maken van het KNX-protocol en het huidige domoticasysteem.

2.1. Verwarmingsregeling De bedoeling van dit deel is om een goede regeling te ontwerpen zodat een ruimte op de gewenste temperatuur gebracht wordt. In eerste instantie moeten de nodige componenten uitgezocht worden om de regeling te integreren in het domoticasysteem. Daarna moet de regelaar voorzien en getest worden zodat er een goed basis resultaat ontstaat. En tot slot kan nog een extra stukje intelligentie toegevoegd worden dat rekening houdt met de buitentemperatuur en binnentemperatuur. Dit houdt in dat er een soort algoritme berekent wanneer de verwarming aangeschakeld moet worden om op openingstijd de gewenste temperatuur te hebben. Als dit alles gerealiseerd is, moet als laatste nog een visualisatie geïmplementeerd worden in het domoticasysteem.

2.2. Energiebeheersysteem Hierbij moet in eerst instantie een Modbus netwerk voorzien worden om te kunnen communiceren met de Diris meetmodules. Daarvoor moet Modbus protocol bestudeerd en geanalyseerd worden. Ook moeten de nodige onderdelen voor dit netwerk geïmplementeerd worden. In tweede instantie moet een conversie gemaakt worden van Modbus naar KNX zodat de meetmodules in iedere schakelkast gelogd kunnen worden in het domoticasysteem. Er is al een controller voorzien die in staat is de conversie te realiseren maar nog geen programmatie. Eens de conversie van Modbus naar KNX goed werkt, kan het energiebeheersysteem ontwikkeld worden. Het is de bedoeling om de belangrijkste elektrische parameters zoals de stromen, spanningen en vermogens te implementeren. Hierbij moeten de waardes continu bewaakt worden op grenswaardes, ook een visualisatie is wenselijk. Als de grenswaarde overschreden worden, moet een alarm gestuurd worden naar de verantwoordelijke personen. Als laatste moet een manier gevonden worden om een maandelijks rapport te creëren met de meterstanden van het verbruik per meetmodule.


2

3

Bedrijfsvoorstelling

figuur 1: Logo TVH

3.1. Algemeen Deze masterproef handelt over een project in het bedrijf Thermote & Vanhalst in de hoofdvestiging in Waregem. Thermote & Vanhalst is opgericht in 1969 en is gekend als een firma met een grote passie voor onderdelen van heftrucks, hoogwerkers en industriële in-plant voertuigen. Momenteel heeft de firma zo’n twintigduizend klanten in ongeveer honderdzestig verschillende landen. Dit vereist een goed en uitgebreide logistieke infrastructuur. Daavoor is de vestiging van Waregem voorzien van een zeer groot en uitgebreid magazijn met meer dan 450 000 onderdelen in stock en veertien miljoen referenties. Daarmee heeft Thermote & Vanhalst de grootste voorraad in onderdelen voor heftrucks, hoogtewerkers en industriële in-plant voertuigen van Europa. Figuur 1 toont het logo van de firma Thermote & Vanhalst.

3.2. Geschiedenis De firma Thermote & Vanhalst werd opgericht in 1969 door Dhr. Paul Thermote en Dhr. Paul Vanhalst. Het begon allemaal met het aankopen, herstellen en verkopen van oude legerheftrucks. Aanvankelijk richtte Thermote & Vanhalst zich toe op de Belgische en Duitse marktmaar na een tijdje bleek er al vlug een schaarste aan tweedehands heftrucks in Europa. Daardoor is de stap gezet richting Japan, dit heeft voor een sterke boost gezorgd van Thermote & Vanhalst. Het verkopen van tweedehandse heftrucks wordt op die manier hun hoofdactiviteit. Maar door de grote verkoop van al die heftrucks is al snel een probleem van wisselstukken ontstaan. Vanaf de jaren negentig verschuift hun hoofdactiviteit naar het leveren van wisselstukken en herstellen van heftrucks. In combinatie met de unieke know-how die opgebouwd werd door de jaren heen is Thermote & Vanhalst geworden wat het nu is. Thermote & Vanhalst is nog altijd een op en top familiebedrijf. De stichters Paul Thermote en Paul Vanhalst vormden de eerste generatie. Nu wordt de groep TVH geleid door de tweede generatie. De sterke bestuursleden bestaan nog steeds uit de families Thermote & Vanhalst.


3

4

Domotica met KNX

4.1. Algemeen Voor er kan begonnen worden met het project moet duidelijk zijn wat domotica exact is. Een domoticasysteem zorgt voor extra comfort en meer energie-efficiëntie in vergelijking met een conventionele elektrische installatie. Domotica is niet zichtbaar voor de gebruiker, het staat in dienst van de gebruiker. Een domoticasysteem is niet volledig hetzelfde als een conventionele schakeling. De verschillen worden verklaard aan de hand van een eenvoudig voorbeeldje. In figuur 2 is een conventionele schakeling van een lamp en een schakelaar zichtbaar. Als de gebruiker de lamp wil aansturen, moet de drukknop bediend worden. In figuur 3 is de lamp uit de conventionele schakeling geïntegreerd in een domoticasysteem met een KNX-netwerk. Als de gebruiker de lamp wil schakelen, zal dit niet meer rechtstreeks gebeuren. Voor een domoticasysteem is een drukknop een sensor. De sensor detecteert of een knop al dan niet wordt bediend. Als de drukknop wordt bediend, zendt de sensor een bericht via het netwerk dat hij ingedrukt werd. Het bericht wordt gelezen door de actoren die eveneens aangesloten zijn op het netwerk. Indien het bericht voor een bepaalde actor bestemd is, zal deze actor schakelen. In dit geval zal de actor de lamp aanschakelen waardoor de lamp zal branden. Dit is een zeer eenvoudige voorstelling hoe domotica werkt, er zijn echter nog meer mogelijkheden.

figuur 2: Conventionele schakeling

figuur 3: Schakeling met KNX

Een groot voordeel van een domoticasysteem is dat één sensor meerdere actoren kan aansturen. Zo kan bijvoorbeeld één knop een lamp, koffiemachine en de verwarming tegelijk aanschakelen. Zo’n systeem is meteen ook zeer flexibel. Bij gelijk welke sensor kan gelijk welke actor aangestuurd worden. Het bepalen van welke sensoren, welke actoren aansturen gebeurt met software. De software voor het configureren van een KNX-netwerk heet ETS en wordt later kort in de tekst besproken. Een domoticasysteem met KNX werkt dus op een decentrale manier. Dit is een enorm groot voordeel want eenmaal geprogrammeerd zal het blijven werken zonder extra apparatuur die kan falen. Indien er één toestel defect is, zal niet het volledige systeem in de fout gaan. Als later nog een module moet toegevoegd worden, moet het volledige systeem niet afgezet worden. Het volstaat om het toestel aan te sluiten en te configureren via ETS. Dit zijn de grote voordelen van een KNX domoticasysteem. Toch wordt in sommige gevallen overgeschakeld naar een centraal systeem met een server. Deze server zal zorgen voor het makkelijk implementeren van klokfunctie, multimedia diensten over internet, Uitbreiden van domoticasysteem in een distributiebedrijf

4

alarmmeldingen via mail, client-applicaties,… . Het gevolg is dat er een tweede programma zal instaan voor de configuratie van deze server. In deze masterproef is dit de GIRA FacilityServer, de configuratiesoftware heet eveneens GIRA FacilityServer. Dit softwarepakket wordt verder in de tekst ook kort toegelicht.

4.2. Evolutie in TVH Bij TVH is het domoticaverhaal een zevental jaren terug begonnen tijdens de bouw van de huidige site in Waregem. Initieel is een basisinstallatie aangekocht, vooral om het concept domotica eens uit te proberen. In die tijd was domotica nog niet wat het nu is en er waren nog twijfels over de mogelijkheden en de toekomst van domotica. Er werden enkele basiszaken geprogrammeerd zoals een sturing van buitenlichten, zonneweringen en verluchtingskoepels. Dit zijn allemaal outputs of actoren maar er waren ook enkele inputs of sensoren geïnstalleerd. Deze zijn een helderheidssensor en enkele knoppen voor alles-uit-schakelaars. Het systeem werkte met een EIB bus, de voorloper van KNX. Alles kon aangestuurd worden met een internetapplicatie van ‘Iconag’. Dit is te zien op figuur 4. Maar enkele jaren terug is besloten om een nieuw systeem te installeren, namelijk de GIRA FacilityServer. In het begin werd een beetje de kat uit de boom gekeken en geëxperimenteerd met tal van nieuwe functies. De GIRA FacilityServer werkt niet meer met het oude EIB maar met de opvolger KNX. Op zich maakt dit niet veel verschil want de gelijkenissen tussen EIB en KNX zijn enorm groot. Om dit systeem te programmeren zijn twee programma’s nodig, één voor het programmeren van de bus (ETS) en één voor het programmeren van de server met al zijn functionaliteiten (GIRA FacilityServer). Na een tijdje te experimenteren met het systeem werd duidelijk dat het systeem veel potentieel had. Zo werd het systeem ondermeer uitgebreid met meer en meer intelligentie. Alle aanwezige actoren worden op een intelligentere manier aangestuurd met behulp van klokken. Ook alarmmeldingen via mail zijn mogelijk zodat de nodige personen tijdig gewaarschuwd worden. Er werden steeds meer actoren aangesloten en het systeem kende plots een enorme boost. Al die verbeteringen zorgen voor een steeds groeiend en efficiënter werkend systeem waar veel logica achter zit.

figuur 4: Iconag internetapplicatie


5

4.3. Huidig domoticasysteem Het domoticasysteem in TVH communiceert via KNX met een centrale server waardoor het decentrale karakter van KNX verdwijnt. Maar in de plaats daarvan wordt het mogelijk om veel meer intelligentie toe te voegen met de centrale server. Deze server is van het merk GIRA met de naam FacilityServer en staat afgebeeld op figuur 5. Uit dezelfde figuur wordt afgeleid dat het domoticasysteem in TVH bestaat uit twee implementaties. Een gedeelte over IP en een gedeelte over twisted-pair. twisted Deze eze twee delen zijn aan elkaar gekoppeld met een KNX/IP router. Deze router ‘vertaalt’ de berichten van de ene kant naar de andere kant en omgekeerd. In de router kan een filter ingesteld worden zodat telegrammen uit het ene deel niet op de andere deel de terecht kunnen komen. De meeste modules zijn aangesloten op het twisted-pair twisted pair gedeelte waardoor alles van twisted-pair twisted kant moet vertaalt worden naar IP kant, omgekeerd zal niet altijd nodig zijn. Dit komt omdat de meeste inputs en outputs ingelezen of aangestuurd angestuurd worden met de server. Er zijn ook inputs die rechtstreeks gekoppeld zijn aan outputs zonder tussenkomst van de server. Een voorbeeld daarvan is de bediening van de zonnewering. Als de server uitvalt, is het nog steeds mogelijk om de zonnewering te bedienen via drukknoppen.

f figuur 5: Configuratie domoticasysteem

De mogelijkheden van de GIRA FacilityServer zijn quasi onbeperkt, het is mogelijk om een SMS of e-mail e te verzenden. Ook berichten versturen en ontvangen via TCP/IP en natuurlijk ook via KNX/IP. Intern kunnen onder andere klokfuncties, mathematische berekeningen en foutmeldingen geprogrammeerd worden. Dit zijn enkele belangrijke functionaliteiten maar er zijn er uiteraard nog veel meer. In deze masterproef zal blijken hoe krachtig de server is.


6

5

Software

5.1. WAGO CoDeSys V2.3 Met dit softwarepakket wordt de WAGO controller geprogrammeerd uit de opdracht energiebeheersysteem. Figuur 6 toont het startscherm van dit programma. Bij het starten van het programma zal het laatste bijgewerkt project automatisch geopend worden. Het belangrijkste gedeelte is de linkerkant van het scherm, er kan gekozen worden tussen vier tabbladen. Onder het eerste tabblad ‘POUs’ kunnen alle functies, functieblokken en programma’s aangemaakt worden. In het grijze gedeelte van figuur 7 moet de programmatie gebeuren. Onder het tweede en het derde tabblad ‘Data types’ en ‘Visualizations’ worden respectievelijk de eigen data types geprogrammeerd en de visualisatie. Het laatste tabblad ‘Recources’ is voorbehouden voor al wat nog rest zoals de globale variabelen, bibliotheken en configuratieparameters. Onder ‘Library Manager’ moeten alle nodige bibliotheken toegevoegd worden. Als de gebruiker een voorgeprogrammeerde functieblok van de fabrikant wil gebruiken, moet de respectievelijke bibliotheek hier toegevoegd worden. Als er meerdere tasks in één controller zitten, dan moeten deze geconfigureerd worden onder ‘Task configuration’. Dit zijn de belangrijkste onderdelen van de programmeeromgeving. Om een programma te downloaden naar de controller moet de gebruiker klikken in de menu op ‘Online > Login’. Het project moet opnieuw gedownload worden als nog geen programma aanwezig is in de controller of als het programma gewijzigd is. Het programma zal dit automatisch detecteren en vragen om opnieuw te downloaden. Daarna zit het programma in de controller maar het wordt nog niet uitgevoerd door de controller. Daarvoor moet de gebruiker klikken op ‘Online > Run’ om het programma te starten in de controller. Door in ‘Online’ mode te klikken op een programma of functieblok kunnen de real-time waardes bekeken worden.

figuur 6: Startscherm CoDeSys V2.3


7

5.2. ‘ETS3’ In ‘ETS’ worden alle deelnemers van de KNX bus geconfigureerd. De benaming ‘ETS3’ slaat op de derde versie van ‘ETS’, momenteel is ook de nieuwste versie ‘ETS4’ beschikbaar maar wordt niet gebruik in deze masterproef. Dit softwarepakket is fabrikant onafhankelijk en volledig volgens de KNX standaard ontwikkeld. Als een toestel gecertificeerd is door KNX, is het zeker dat dit toestel geconfigureerd kan worden met ‘ETS’. Het configureren van een toestel bestaat uit het toekennen van het busadres en de nodige groepsadressen aan een module. Daarnaast kunnen er nog optionele parameters ingesteld worden tijdens de configuratie. ‘ETS3’ is opgebouwd uit vier hoofdschermen zoals in figuur 7. Het scherm ‘Gebouwen in TVH’ toont alle schakelkasten met bijbehorende KNX-modules. Het scherm ‘Groepadressen in TVH’ is één van de belangrijkste schermen en geeft een overzicht van alle groepsadressen in het KNX-netwerk. De groepsadressen worden gebruikt om de KNX-telegrammen te verzenden over de bus. Iedere KNX-module weet welke groepsadressen voor hem bedoeld zijn. Op deze manier weet iedere module als het bericht al dan niet voor hem bedoeld is. Het volgende scherm ‘Alle Busdeelnemers in TVH’ geeft een overzicht van alle modules die aangesloten zijn op het KNXnetwerk. Als één van de modules geselecteerd is, worden alle mogelijke KNX-telegrammen zichtbaar. Door deze telegrammen te koppelen aan een groepsadres kan een telegram verzonden worden. Het laatste scherm ‘Topologie in TVH’ geeft een overzicht van de fysische structuur van het KNX-netwerk. Daarin wordt duidelijk hoeveel zones en lijnen gebruikt worden in het netwerk.

figuur 7: Startscherm van ‘ETS3’


8

5.3. GIRA Expert Met de GIRA Expert software kan de GIRA FacilityServer geprogrammeerd worden met al de nodige functionaliteiten. In figuur 8 staat het startscherm van de Expert software. In het centrale gedeelte staan de meest gebruikte functionaliteiten en de linkerkolom kunnen alle functionaliteit teruggevonden worden onder een categorie. Achter ieder icoontje zit een functionaliteit, bijvoorbeeld onder het icoontje ‘Menu’ kan de volledige menu structuur opgemaakt worden voor de client-applicatie van de server. Iedere functionaliteit kan in elkaar verweven zitten. Bijvoorbeeld in de menu structuur kan een grafiek toegevoegd worden die onder het icoontje ‘Graphs’ is aangemaakt. In deze masterproef wordt ook veel gebruik gemaakt van de ‘Graphic Logic Editor’. Hier kan de gebruiker zelf een functionaliteit programmeren aan de hand van voorgeprogrammeerde functiebouwstenen. Het is niet mogelijk om zelf functieblokken te maken waardoor de vrijheid van de gebruiker soms beperkt wordt.

figuur 8: Startscherm GIRA Expert


9

6

Verwarmingsregeling

6.1. Inleiding Om de verwarming automatisch te regelen zijn meestal 3 hoofdcomponenten nodig. Een eerste component is een sensor om de actuele waarde op te meten. Een tweede component is een actor om de kleppen van de verwarmingskring te regelen. Tot slot is er natuurlijk nog een regelaar nodig die een waarde kan uitsturen naar de actor afhankelijk van de sensorwaarde. Op figuur 9 is een principeschema van de verwarmingsregeling afgebeeld. De regelaar verwerkt het verschil tussen de wenswaarde en sensorwaarde tot een uitgangswaarde voor de actor. Dit is een eenvoudige regeling van de verwarmingmaar soms kan het nodig zijn om nog meer intelligentie toe te voegen. De wenswaarde zal niet steeds constant zijn, het is logisch dat de wenstemperatuur overdag en ’s nachts verschillend is. Daarom wordt er in sommige gevallen nog extra intelligentie toegevoegd die de wenswaarde bepaalt. Dit stuk intelligentie zal ook beslissen op welk tijdstip de verwarming ingeschakeld wordt en met welke wenstemperatuur de verwarming ingesteld wordt. Als het enigszins mogelijk is, kan nog verder gegaan worden door rekening te houden met de binnen- en buitentemperatuur. Op deze manier kan op een zeker wenstijdstip een bepaalde wenstemperatuur altijd bereikt worden.

figuur 9: Algemeen regelschema verwarming

Voor ieder onderdeel van de regeling wordt een studie gemaakt van de mogelijkheden. Daarna wordt één van de opgesomde mogelijkheden gekozen als oplossing. Bij de keuze moet rekening gehouden worden met prijs, kwaliteit, levertermijn en uitbreidbaarheid. Voor ieder onderdeel moet een goed evenwicht gevonden worden tussen deze criteria. Nadien moeten de onderdelen geïnstalleerd en geconfigureerd worden in het domoticasysteem. En als laatste moet nog een visualisatie aangemaakt worden.

6.2. Actor 6.2.1. Mogelijkheden In een verwarmingsregeling is de actor een ventiel dat in zijn uitgang procentueel kan sturen. De meest gebruikte ventielen voor deze toepassing zijn elektrothermische ventielen. Deze ventielen kunnen procentueel aangestuurd worden door een waselement in de actor. Dit element in was wordt elektrisch verwarmd waardoor een uitzetten gecreëerd wordt. Door het element meer of minder op te warmen is het mogelijk om een procentuele aansturing te realiseren. Met zo’n ventiel alleen zal het nog niet mogelijk zijn om de verwarming te regelen via het KNX-netwerk. Daarom zal nog een uitgangsmodule nodig zijn om het KNXnetwerk aan het ventiel te koppelen. Vrijwel iedere fabrikant van domotica heeft zo’n uitgangsmodule standaard in zijn gamma.


10

6.2.2. Uiteindelijke keuze De actor bestaat feitelijk uit twee delen, één deel is gekoppeld aan het KNX-netwerk, en het andere deel zal het water door de leidingen regelen met een klep. Het deel dat gekoppeld is aan het KNX-netwerk is een uitgangsmodule die een KNX-bericht vertaalt in een geschikte spanning voor de klep. De keuze voor deze module is gevallen op een analoge actor met vier uitgangen van GIRA. Er is geen specifieke reden voor de keuze, want de prijzen tussen de verschillende fabrikanten zijn min of meer gelijk. Aangezien het meest met materiaal van GIRA gewerkt wordt, is de keuze van fabrikant dan ook vlug gemaakt. Op figuur 8 staat de actor van GIRA afgebeeld samen met de elektrothermische ventielen. Er kunnen tot vier ventielen op één uitgang aangesloten worden maar dan moeten de ventielen wel in dezelfde ruimte zitten want de aanstuurwaarde zal dezelfde zijn.

figuur 10: GIRA verwarmingsactor met aangesloten ventielen

Het tweede deel van de actor bestaat uit een elektrothermische klep die de hoeveelheid warm water door de radiatoren kan regelen. Ook hierbij zijn de prijzen van de verschillende fabrikanten gelijkaardig, daarom zal de keuze niet verder toegelicht worden. Op figuur 10 staan tien elektrothermische kleppen afgebeeld. Deze zijn aangesloten op de koude kant van het verwarmingssysteem. De ventielen zouden minder goed tegen de warmte kunnen als ze op de warme kant zouden zitten. Voor de verwarmingsregeling maakt het niet veel uit waar de ventielen zitten. Als ze gesloten zijn, is er geen doorstroming mogelijk en als ze open zijn, is er wel stroming en warmte afgifte mogelijk.

6.2.3. Configuratie in ‘ETS3’ De configuratie in ‘ETS3’ vraagt enige aandacht van de gebruiker. Omdat het mogelijk is om de actor te koppelen aan een KNX-thermostaat zonder tussenkomst van een server zijn er veel instellingen voorzien. In deze toepassing moet de actor niet gekoppeld worden aan een fysische KNX-thermostaat maar aan een softwarematige thermostaat of regelaar. De actor moet in staat zijn om de aanstuurwaarde in te lezen, verder moet de actor geen functionaliteiten hebben. Daarom moet de actor ingesteld worden om een procentuele waarde te kunnen binnenlezen. Op figuur 11 staan de belangrijkste configuratieparameters weergegeven. Onder de parameter ‘Ventil im spannungslosen Zustand’ moet voor ‘geschlossen’ gekozen worden omdat de kleppen sluiten als er geen spanning aangelegd wordt. De volgende parameter geeft aan met welke aanstuurwaarde moet gewerkt worden. In deze toepassing is dit procentueel met een waarde van één byte.


11

Daarom moet gekozen worden voor ‘Stetig (1 Byte)’. Dit zijn de belangrijkste parameters om de actor te laten werken in deze toepassing, de ander parameters mogen op de standaard instelling blijven staan.

figuur 11: Instellingen in ‘ETS3’ van de verwarmingsactor

6.3. Regelaar 6.3.1. Mogelijkheden De regelaar kan op verschillende manieren geïntegreerd worden. Een eerste manier is softwarematig in de GIRA FacilityServer. Daar is een functieblok beschikbaar om de verwarming procentueel te regelen. Het voordeel hiervan is dat er geen kosten zijn en er kunnen zoveel functieblokken toegevoegd worden als gewenst. Nog een voordeel is dat het aantal berichten op het KNX-netwerk wordt beperkt tot een minimum. Er is een bericht met de ruimtetemperatuur en een bericht met de aanstuurwaarde van de actor. De waarde van de wenstemperatuur kan dan via een interne variabele worden ingegeven en zal dus niet op het KNX-netwerk terecht komen. Een tweede mogelijkheid bestaat erin om een thermostaat met ingebouwde temperatuursensor aan te kopen. De meeste fabrikanten bieden dergelijke modules aan die direct op het KNXnetwerk kunnen aangesloten worden. De configuratie gebeurt via de ‘ETS3’ software. Het aantal berichten op het KNX-netwerk zal bijgevolg één bericht meer bevatten, de wenstemperatuur, de ruimtetemperatuur en de aanstuurwaarde van de actor. Het is belangrijk om deze drie waarden binnen te lezen om het gedrag van de verwarming per ruimte te kunnen analyseren en visualiseren. Daarom heeft de laatste mogelijkheid twee negatieve puntjes ten opzichte van de eerste mogelijkheid. Het is een duurdere oplossing en er zal een bericht meer op het KNX-netwerk komen. In eerste instantie kan opgemerkt worden dat het aantal berichten op het KNX-netwerk van minder belang kan zijn maar dit is zeker niet zo. In het bedrijf wordt het KNX-netwerk continue bewerkt met uitbreidingen en optimalisaties. Daarom is het van belang om de berichten tot een minimum te beperken om uitbreiding in de toekomst nog mogelijk te maken.


12

6.3.2. Uiteindelijke keuze Voor de regelaar is gekozen voor de softwarematige functieblok in de GIRA FacilityServer, deze oplossing is het meest flexibel. Zo bestaat de mogelijkheid om zelf te beslissen welke intelligentie er nog bijkomend geprogrammeerd wordt. In de toekomst zijn nog veel uitbreidingen gepland waardoor deze oplossing een goede keuze is. Als een nieuwe ruimte toegevoegd wordt, moet de regeling gewoon gekopieerd worden en dient enkel de I/O aangepast te worden. Op deze manier is het zeer eenvoudig om softwarematig een nieuwe ruimte toe te voegen aan het systeem. Ook wordt het aantal KNX-berichten met één per lokaal gereduceerd. Dit is een voordeel om toekomstige uitbreiding toe te laten. Het grootste voordeel is dat het volledig gratis ter beschikking is in de ‘Graphic Logic Editor’. Figuur 12 toont hoe deze bouwsteen er visueel uitziet en tabel 1 beschrijft alle inputs en outputs van de regelaar.

figuur 12: Verwarmingsregelaar

tabel 1: I/O van verwarmingsregelaar

Ingangen Setpoint(in °C) Actual Value (in °C) 100% Range Factor (init==1) Cycle (Sec.) Lock-Out (1=blocked) Uitgangen Corrected Variable Corrected Variable (sbc) Number of Cycles

Beschrijving De gewenste waarde van de temperatuur. De gemeten temperatuur in het lokaal afkomstig van de sensor. geeft aan vanaf welk verschil tussen wenswaarde en actuele waarde de uitgang voor honderd procent wordt uitgestuurd. Stelt de steilheid van de uitsturing in. Bij een waarde één staat de regelaar zeer zacht. Bij hogere waardes zal de regelaar zijn uitgang veel steiler uitsturen. De tijd die aangeeft om de hoeveel seconden de regelaar zijn uitgangswaarde opnieuw berekend. Bij een waarde nul is de regelaar geblokkeerd. Deze bit kan de werking van de regelaar blokkeren. Beschrijving De uitgang met een waarde tussen 0 en 100%. De uitgang met een waarde tussen 0 en 100%, enkel verzonden op de bus als de waarde veranderd is. Het aantal cyclussen dat de regelaar zijn berekening heeft gedaan.

Met bovenstaande info kunnen nu alle ingangen en uitgangen aangesloten of ingesteld worden. Figuur 13 toont de afstelling voor de afdeling depannage. Er zijn twee regelaars voorzien, één voor overdag en één voor ‘s nachts. Het setpoint voor overdag is een interne variabele die aangepast kan worden door de gebruiker via de client-applicatie. Het setpoint voor ’s nachts is ingesteld op een vaste waarde van vijftien graden. De actuele waarde is de gemeten temperatuur die afkomstig is van een temperatuursensor en is voor beide regelaars hetzelfde. Verder zijn de cyclustijd, de factor en de honderd procent rage vast ingesteld. Via de Lock-out ingang kan een keuze gemaakt worden tussen de regelaar voor overdag en ’s nachts. Het overschakelen van de ene regelaar naar de andere gebeurt met een interne klok die de variabel ‘Lock Verwarming depannage’ aanstuurt naargelang het tijdstip. De uitgang die gekozen is van de regelaar zendt enkel zijn waarde als de waarde verandert. Dit is bedoeld om de bus wat te ontlasten, anders zullen er onnodige berichten verstuurd worden over de bus. Uitbreiden van domoticasysteem in een distributiebedrijf

13

figuur 13: Ingestelde verwarmingsregelaar

6.4. Sensor 6.4.1. Mogelijkheden Een temperatuursensor kiezen lijkt een simpele opgave maar dat is het niet. Vele fabrikanten hebben altijd wel ergens een temperatuursensor maar die zit meestal ingebouwd in een toestel met extra functionaliteiten. Het is moeilijk om een eenvoudige temperatuursensor te vinden die aan het KNX-netwerk kan gekoppeld worden. De enige oplossing die er bestaat is een pt100 of pt1000 aan te kopen en deze koppelen aan een KNX ingangsmodule maar dit is een dure aangelegenheid. Voor een verwarmingsregeling moet de nauwkeurigheid van de sensor niet zo hoog zijn, er kan zeker gewerkt worden met een nauwkeurigheid tussen 1 en 0,5 °C. Daarom zal het goedkoper uitkomen om een thermostaat met ingebouwde temperatuursensor aan te schaffen in plaats van een aparte sensor te voorzien. Er komen heel wat fabrikanten in aanmerking die dergelijke thermostaten hebben zoals: ABB, Siemens, GIRA, Theben. De meeste fabrikanten hebben de meest uiteenlopende thermostaten, met of zonder display, met extra knoppen en functionaliteiten enzovoort. Uit de mogelijkheid moet een goedkope thermostaat met een deftige temperatuursensor gekozen worden.

6.4.2. Uiteindelijke keuze De keuze van de sensor is gevallen op de goedkoopste temperatuurssensor namelijk de ‘RAM 712’ van Theben. Dit is eigenlijk ook een thermostaatmaar hier wordt enkel de sensor zelf gebruikt. Het was goedkoper om een volledige thermostaat met ingebouwde temperatuursensor te kopen. De thermostaat is afgebeeld op figuur 14. De nauwkeurigheid van de geïntegreerde temperatuursensor bedraagt twee tienden en is zeker voldoende voor deze toepassing.

figuur 14: Theben RAM 712


14

6.4.3. configuratie in ‘ETS3’ De configuratie in ‘ETS3’ is zeer eenvoudig omdat enkel de temperatuursensor wordt gebruikt van de thermostaat. In figuur 15 staan de instellingen voor de temperatuursensor. Zo kan een offset worden ingegeven om eventuele fouten op de sensor te corrigeren. Door een meting te doen met een geijkt toestel is gebleken dat een offset van min twee graden nodig is. De twee andere instellingen hebben betrekking tot de zendfrequentie van de temperatuur. Volgens de instellingen wordt om de twee minuten een bericht verzonden met de actuele waarde van de temperatuur. Als de temperatuur verandert van waarde met twee tienden binnen de twee minuten wordt er toch nog een bericht verzonden met de actuele waarde. Op deze manier moet het mogelijk zijn om de regelaar met de meest recente waarde van de temperatuur aan te sturen.

figuur 15: Instellingen in ‘ETS3’ van de Theben RAM 712

6.5. Extra intelligentie 6.5.1. Mogelijkheden Met bovenstaande componenten kan een goede regeling worden bekomen maar in sommige gevallen is nog meer intelligentie vereist. Die extra intelligentie kan bijvoorbeeld rekening houden met de buitentemperatuur om de radiatoren te gaan aansturen. Zo kan bij een lage buitentemperatuur iets vroeger gestart worden met verwarmen. Maar dit principe zal niet veel nut hebben aangezien de ketels meestal een dergelijke sturing hebben. Hierdoor zal het moeilijk worden om een goed resultaat te bekomen want twee gelijkaardige regelingen in één systeem kunnen niet goed afgesteld worden. Een ander principe van extra intelligent is het ‘optimized start-stop’ algoritme, dit algoritme zoekt de optimale starten stoptijden voor de verwarming. Dit algoritme werkt aan de hand van een tabel waar een combinatie van binnen- en buitentemperatuur overeenkomt met een starttijdstip en een stoptijdstip. Door de aanwezigheid van zelflerende intelligentie zal het algoritme ook in staat zijn steeds slimmer te worden naarmate het ouder wordt. In figuur 16 staat het ‘optimized start-stop’ algoritme grafisch voorgesteld. De volle lijn is van toepassing voor het verwarmen van een ruimte en de stippellijn is van toepassing voor het koelen van een ruimte.


15

figuur 16: 'Optimized start - stop' algoritme

De waarde SPV geeft de setpoint temperatuur aan, daarnaast moet ook nog een comfortzone rond het setpoint worden ingesteld, SPV+TROS en SPV-TROS. De kamertemperatuur moet tijdens de werkuren tussen deze zone liggen om een minimaal comfort te bieden aan de gebruikers van de ruimte. Als het algoritme de eerste keer start, dan zal de logica op zeker spelen en de verwarming op een zo vroeg mogelijk tijdstip laten starten (a). Daarna zal de kamertemperatuur toenemen en is het de bedoeling om bij openingstijd net aan de setpoint temperatuur uit te komen. Als het algoritme ziet dat de temperatuur eerder bereikt is, zal de logica dit onthouden waardoor de volgende keer iets later gestart zal worden. Het omgekeerde kan ook, als de logica ziet dat de temperatuur het setpoint niet bereikt, wordt dit ook gecompenseerd. Al deze starttijden worden in combinatie met een binnen- en buitentemperatuur bijgehouden in een centrale tabel. Ook bij het afschakelen is de logica in staat om de optimale stoptijd te bepalen. Daar is het de bedoeling om op sluitingstijd nog net op het minimum van de comfortzone uit te komen. De volledige uitleg kan nog eens worden overgedaan maar dan omgekeerd voor het koelen van een ruimte. Maar voor deze opdracht is die niet van toepassing omdat er enkel verwarmd wordt.

6.5.2. Implementatie Het ‘optimized start-stop’ algoritme implementeren in het domoticasysteem is niet eenvoudig. Omdat het algoritme een centrale tabel met gegevens eist, is het niet mogelijk om dit te programmeren in de GIRA FacilityServer. Dit kan omzeild worden door een externe controller toe te voegen in het KNX-netwerk zoals gebruikt is in de opdacht rond energiebeheer. De controller kan dan de wenstemperatuur, binnentemperatuur en buitentemperatuur binnen lezen via KNX/IP. Daarmee kan de controller de nodige bewerkingen doen en een centrale tabel bijhouden met alle starten stoptijden bij respectievelijke buiten- en binnentemperatuur. De controller stuurt dan een bericht naar de GIRA FacilityServer als de verwarming mag gestart worden. Dit is perfect mogelijk en is ook gerealiseerd. Er is een programma voorzien dat het optimaal starttijdstip bepaalt in de controller. Het stoptijdstip is niet geïmplementeerd omdat dit afhankelijk is van lokaal tot lokaal en wordt op een vast tijdstip ingesteld in de GIRA FacilityServer.


16

6.6. Resultaten 6.6.1. Zonder extra intelligentie Als alles ingesteld en gedownload is, kan er een gebruikersscherm opgebouwd worden in de client-applicatie. Daarna kunnen de resultaten bekeken en geanalyseerd worden. Het resultaat wordt toegelicht aan de hand van de eerste ruimte die geïmplementeerd werd, namelijk het bureel depannage. Figuur 17 geeft het eerste deel van het gebruikersscherm weer. Het is mogelijk om de wenstemperatuur in te geven door op ‘Setpoint Temperatuur’ te klikken. Daarnaast kunnen de actuele temperatuur en de actuele aansturing van de kleppen afgelezen worden. Er is ook een mogelijkheid om een grafiek op te vragen die een dag terug in de tijd gaat. Op deze grafiek staat het setpoint, de actuele temperatuur en de procentuele aansturing van de kleppen. Het volgende deel van de client-applicatie staat afgebeeld op figuur 18. Het is mogelijk om een grafiek die een week terug in de tijd gaat op te vragen. Daarnaast is er nog een klok die geconfigureerd moet worden met een starten stoptijdstip voor de verwarming. Als de verwarming aan ligt, werkt de regelaar voor overdag. Als de verwarming af ligt, werkt de regelaar voor ’s nachts. Om de verwarming manueel aan te schakelen is als laatste een knop voorzien om te schakelen tussen verwarming aan en verwarming af. Dit zorgt ervoor dat ofwel de dag regelaar ofwel de nachtregelaar actief zal zijn. De nachtregelaar zal dus altijd in werking zijn als de verwarming af ligt. Dit is om te vermijden dat het lokaal te sterk afkoelt tijdens de nacht. De wenswaarde voor de nachtregelaar ligt op vijftien graden. Deze waarde is nog nooit bereikt in één van de lokalen waardoor de regelaar voor ’s nachts normaal nooit in actie zal komen.

figuur 17: Client-applicatie verwarmingsregeling deel 1


17

figuur 18: Client-applicatie verwarmingsregeling deel 2

Figuur 19: Grafiek verwarmingsregeling

In figuur 19 staat een grafiek van een meting van de verwarmingsregeling, de meting start op 26/10/2010 om 08u39 en eindigt op 28.10.2010 om 08:37. Hieruit is af te leiden dat de verwarming steeds in de ochtend een klein beetje uitgestuurd wordt. Verder moet de verwarming niet in actie komen omdat het lokaal naar het zuiden gericht is. Er valt ook op te merken dat de temperatuur bijna altijd boven zijn setpoint ligt. Maar volgens de mensen die er werken is het lokaal altijd aan de warme kant. De regeling doet blijkbaar goed zijn werk en


18

springt bij als het nodig is. Dit is een representatieve meting voor alle lokalen die al geïmplementeerd zijn. Voor ieder ander lokaal moet de verwarming enkel in de ochtend een beetje bijspringen.

6.6.2. Met extra intelligentie De implementatie met extra intelligentie is getest met de WAGO controller die gebruikt wordt in de opdracht rond energiebeheer. Het zelf geschreven algoritme is getest op een goede werking maar niet met een werkende verwarming. Tijdens de test lag de verwarming niet aan omdat het al te warm was. In figuur 20 staat het resultaat van deze test die gedurende een week uitgevoerd werd. De blauwe lijn is de aansturing van de verwarming, de rode lijn is de kamertemperatuur in het lokaal ‘Burelen A+2’ en de groene lijn is de buitentemperatuur. Merk op dat de aanstuurwaarde vlug naar honderd procent gaat. Dit komt omdat de regelaar een waarde uitstuurt maar er komt geen reactie aan de sensorzijde. Hierdoor zal de regelaar zijn waarde steeds hoger instellen tot op de maximale grens van honderd procent. Dit is normaal want er stroomt geen warm water door de leidingen omdat de ketels afgeschakeld zijn. Er valt ook uit af te leiden dat de temperatuur in het lokaal amper stijgt of daalt gedurende de test periode. Dit wijst erop dat het gebouw goed geïsoleerd is en dat deze extra intelligentie niet veel meerwaarde meer kan bieden. Om het 'Optimized startstop' algoritme te implementeren is een extra WAGO controller nodig en die is niet beschikbaar. Er kan dus gesteld worden dat het uitvoeren van deze regeling enkel maar kosten met zich zal meebrengen. De meerwaarde zal echter zeer beperkt blijven en niet opwegen tegen de kostprijs van een extra controller. Tot slot kan nog opgemerkt worden dat de sturing één nacht wel uitgestuurd werd en is aangegeven door de rode cirkel in figuur 19. Er zal waarschijnlijk iemand de verwarming manueel verzet hebben waardoor deze ‘s nachts bleef aanliggen totdat het algoritme de volgende ochtend de verwarming uitstuurde.

figuur 20: Grafiek verwarmingsregeling met 'Optimized start - stop' algoritme


19

6.7. Besluit Er is een zeer degelijke basisverwarmingsregeling gerealiseerd die goed functioneert. De temperatuur kan door één persoon per lokaal ingesteld worden. Hierdoor moeten de werknemers niets meer bijregelen aan de radiatoren en zal in de achtergrond alles geregeld worden door het domoticasysteem. Het grootste voordeel is dat er maar één iemand één instelling moet veranderen om alle radiatoren in één lokaal in te stellen. Op de oude manier moeten alle radiatoren manueel ingesteld worden. Dit verhoogt de efficiëntie van Thermote & Vanhalst omdat de werknemers zich meer kunnen toeleggen op hun werk. Deze verwarmingsregeling is momenteel al voor enkele lokalen toegepast maar het is de bedoeling om nog meer lokalen te implementeren. Dit zal in de toekomst nog moeten gebeuren. Uit de studie om extra intelligentie toe te voegen in deze verwarmingsregeling is gebleken dat dit niet veel meerwaarde met zich mee brengt. Daarom is deze doelstelling niet gerealiseerd maar er wel een beperkte testversie beschikbaar met een optimaal starttijdstip. Als in de toekomst meer ruimte geïmplementeerd zijn, kunnen nog meer intelligente functies toegevoegd worden. Zo kan een alles-uit-schakelaar voorzien worden om alle verwarmingen in één keer uit te schakelen. Het zou bijvoorbeeld ook perfect mogelijk zijn om het koelsysteem te integreren in het domoticasysteem waardoor de volledig climatisatie van het gebouw in één systeem vervat zit. Dit zal zorgen voor een comfortverbetering en energiebesparingen als het systeem goed geïmplementeerd wordt.


20

7

Energiebeheersysteem

7.1. Inleiding Het principeschema voor dit gedeelte van de masterproef is al uitgewerkt en staat afgebeeld op figuur 21. De meeste toestellen en benodigdheden zijn al aangekocht waardoor er geen marktstudie meer nodig is. Enkel de busconfiguratie voor het uitlezen van de gegevens moet nog geanalyseerd worden. De bus moet met het Modbus protocol werken want de Diris Ap meettoestellen kunnen enkel op deze manier communiceren. Er zijn twee mogelijkheden, ofwel werken met Modbus TCP over de ethernetkabel, ofwel werken met Modbus RTU over een klassiek twisted-pair bussysteem. In iedere elektrische schakelkast zitten Diris Ap meetmodules met de nodige gegevens voor het energiebeheersysteem. Om de gegevens uit de Diris Ap meetmodules te halen, moet de WAGO controller iedere meetmodule afpollen via Modbus. In de meetmodules zijn verschillende gegevens beschikbaar, onder andere alle stromen, spanningen, vermogens en de meterstand van het verbruik. De WAGO controller is ook in staat om te communiceren via het KNX/IP-protocol zodat er communicatie ontstaat met de GIRA FacilityServer. Via de ‘Graphic Logic Editor’ kunnen de gegevens geanalyseerd en verwerkt worden om er nuttige data van te maken. Het is duidelijk dat de meeste intelligentie in de GIRA FacilityServer aanwezig is. De WAGO controller dient enkel als ‘tolk’ tussen het Modbus en KNX gedeelte.

figuur 21: Principeschema energiebeheer

Om te communiceren tussen de WAGO controller en de GIRA FacilityServer bestaat ook een mogelijkheid om te werken met gewone IP berichten. Zowel de controller als de server zijn in staat om gewone IP berichten te ontvangen en te verzenden. Maar dit wordt niet toegepast omdat deze specifieke KNX/IP-controller toch al aangekocht is. Het aantal IP berichten zal toch hetzelfde zijn omdat het niet mogelijk is om meerdere waardes in één bericht te plaatsen. Omdat de KNX/IP berichten op het IP-netwerk terecht komen, zullen deze ook gezien worden door de KNX/IP router van het domoticasysteem. Deze zal de KNX-berichten vertalen van IPkant naar twisted-pair kant en omgekeerd. Gelukkig bestaat de mogelijkheid om een filter in te stellen in de KNX/IP router. Hierdoor worden de KNX/IP berichten niet verzonden op het twisted-pair gedeelte. Het risico op overbelasting aan twisted-pair kant wordt hierdoor tot een minimum beperkt.


21

7.2. Meetmodule 7.2.1. Algemeen In iedere schakelkast is een Diris Ap meetmodule aanwezig die allerhande elektrische grootheden opmeet zoals spanningen, stromen, vermogens, powerfactor, … Figuur 17 toont zo’n Diris Ap module van het merk Socomec.

figuur 22: Diris Ap module

Deze meetmodules hebben standaard geen mogelijkheid tot uitlezen van de gegevens, enkel een visuele uitlezing via de display. Maar de fabrikant voorziet extra uitbreidingsmodules die op de meetmodules gemonteerd worden om te communiceren met een bussysteem, namelijk Modbus. Omdat deze Diris Ap meetmodules wat oudere toestellen zijn, ondersteunen deze enkel Modbus RTU. Daarvoor moeten de meetmodules uitgerust worden met een extra communicatiemodule zoals op figuur 23.

figuur 23: Modbus communicatiemodule

Er bestaat ook een mogelijkheid om met Modbus TCP te werken, dit is Modbus over de Ethernetkabel. De bekabeling zal dan beperkt blijven aangezien er overal in het bedrijf al een ethernetkabel aanwezig is. Deze oudere Diris meetmodules ondersteunen echter geen Modbus TCP. Daarvoor moeten alle meetmodules vervangen worden door nieuwe meetmodules. Dit is een veel te dure oplossing en zal niet worden toegepast. De fabrikant kan een alternatief bieden om het probleem met de oudere meetmodules te omzeilen. Er bestaat een omvormer die kan aangesloten worden op de nieuwere meetmodules en is in staat om Modbus RTU om te zetten in Modbus TCP. Dit is te zien op figuur 24. Deze oplossing impliceert dat er een drietal nieuwere meetmodule moeten aangekocht worden plus elk een omvormer. Dit zal een grote kost met zich meebrengen, zeker omdat de klassieke Modbus RTU busconfiguratie ook gerealiseerd moet worden. Daarom bestaat het vermoeden dat het goedkoper is om te kiezen voor een volledige klassieke Modbus RTU uitvoering zoals afgebeeld op de figuur 25. Daarbij moet rekening worden gehouden met een maximum van tweeëndertig Uitbreiden van domoticasysteem in een distributiebedrijf

22

toestellen en een maximum lengte van anderhalve kilometer. Als aan één van de twee voorwaarden niet meer voldaan wordt, moet er een versterker tussen de twee lijnen geschakeld worden.

figuur 24: Modbusconfiguratie met omvormer

figuur 25: Klassieke Modbus RTU configuratie

7.2.2. Communicatiemodule Dit is een optionele module die aan de achterkant van de meetmodule gemonteerd moet worden. Op figuur 26 is zo’n module afgebeeld die aangesloten is op de achterkant van een Diris Ap meetmodule. Bovenaan de communicatiemodule zit een dipswitch om een afsluitweerstand te activeren. Dit moet enkel gebeuren aan het begin en het einde van de bus. Om de module te kunnen gebruiken moet de Diris Ap meetmodule eerst eens zonder spanning gezet worden. Daardoor zal de meetmodule de communicatiemodule herkennen en kan ze gebruikt worden. De configuratie van communicatiemodule gebeurt via de display van de meetmodule, daarvoor wordt verwezen naar de handleiding van de communicatiemodule in de bijlage.

figuur 26: Communicatiemodule aangesloten op Diris Ap


23

7.3. Busconfiguratie 7.3.1. Keuze Zoals eerder vermeldt zijn er twee mogelijke oplossingen voor de busconfiguratie. Een klassieke Modbus RTU uitvoering met een seriële verbinding of met een Modbus omvormer om over te gaan naar Modbus TCP. Voor beide mogelijkheden moet een Modbus RTU configuratie gerealiseerd worden. Bij de klassieke Modbus RTU uitvoering moeten twee versterkers worden bijgekocht en bij de configuratie met de Modbus omvormer moeten drie nieuwe meetmodules en drie omvormers worden aangekocht. Om te beslissen welke oplossing het best is, wordt een schatting gemaakt van de kosten voor de twee mogelijkheden. Tabel 2 geeft de geschatte kosten weer voor de klassieke Modbus RTU configuratie en tabel 3 geeft de geschatte kosten weer voor de configuratie met een Modbus omvormer. tabel 2: Kostprijs met klassieke Modbus RTU configuratie

Aantal 27 2

Omschrijving Modbus communicatiemodule RS 485 RS 485 versterker Totaal

Prijs (€) 67,10 468,50

Totaal (€) 1811,70 937,00 2748,70

tabel 3: Kostprijs met Modbus omvormer

Aantal 24 3 3

Omschrijving Modbus communicatiemodule RS 485 Diris A40 meetmodule Modbus omvormer Totaal

Prijs (€) 67,10 241,36 240,24

Totaal (€) 1610,40 724,08 720,72 3055,20

De totale kostprijs van de klassieke Modbus RTU configuratie is duidelijk lager dan de kostprijs voor de oplossing via de Modbus omvormer. De kosten voor de plaatsing en aankoop van de bekabeling is hier niet meegerekend omdat deze ongeveer hetzelfde zal zijn in beide gevallen. Laat duidelijk zijn dat deze kostenraming louter indicatief is omdat alle bedragen netto prijzen zijn. Hieruit kan besloten worden dat de configuratie zal bestaan uit een klassieke Modbus RTU uitvoering met een seriële verbinding. Dit zal de beste en goedkoopste optie zijn voor deze toepassing.

7.3.2. Installatie Om een Modbus RTU bekabeling uit te tekenen moeten twee heel belangrijke regels nageleefd worden. De maximum lengte van anderhalve kilometer per lijn en maximaal tweeëndertig toestellen per lijn. Het ontwerp is gerealiseerd in samenspraak met de fabrikant om een zo goed mogelijk resultaat te bekomen. In figuur 27 en figuur 28 staat het resultaat van deze samenwerking. Op figuur 27 staat de schematische voorstelling van de volledige busconfiguratie. Er zijn drie lijnen voorzien: de rode lijn, de groene lijn en de rest vormt samen de laatste lijn. Om de drie lijnen te verbinden met elkaar wordt een versterker gebruikt, op de figuur wordt deze aangeduid met de benaming ‘splitter’. De reden hiervoor wordt later duidelijk als de versterker wordt toegelicht. Voor de meest kritische lijnen qua lengte is een schatting gemaakt van de afstanden tussen de meetmodules. Voor de lijn die blauw en zwart gekleurd is, bedraagt de lengte ongeveer 820 meter en voor de rode lijn 290 meter. Deze lijnen zitten nog ver van de grens van 1200 meter maar er is rekening gehouden met voldoende marge voor mogelijke uitbreidingen. Het aantal meetmodules per lijn blijf beperkt tot maximaal twaalf meetmodules. Daarmee is ook hier uitbreiden zeker nog mogelijk. Op figuur 28 is de busconfiguratie op het grondplan van het bedrijf getekend, daarbij is rekening gehouden met de kleuren uit figuur 27.


24

figuur 27: Schematische voorstelling busconfiguratie

figuur 28: Busconfiguratie op het grondplan

7.3.3. Versterker Omdat de Modbusconfiguratie uit meer dan 1 lijn bestaat, is er nood aan een versterker om de lijnen met elkaar te verbinden. Het is belangrijk om de versterker goed in te stellen en aan te sluiten op de correcte manier zodat de volledige bus goed kan werken. De versterker is van dezelfde fabrikant als van de meetmodules, namelijk Socomec. Dit is een versterker die op verschillende manieren kan gebruikt worden en kan dienen voor verschillende veldbussen. Het is dus van uiterst belang dat de versterker juist ingesteld wordt naar de gebruikte veldbus. Figuur 29 toont de versterker van Socomec.


25

figuur 29: Socomec versterker

De versterker heeft drie aansluitklemmen: één voor de interne voeding, één voor een lijn A en één voor een lijn B. In de bijlage bevindt zich de handleiding van dit toestel, hierin staan alle mogelijke instellingen en configuraties. Verder zullen enkel de gebruikte instellingen voor deze toepassing worden toegelicht en verklaard. De fysische configuratie is afgebeeld op figuur 30, de versterker lust lijn A gewoon door en takt een nieuwe lijn B af. Daarom is de benaming versterker hier misschien niet zo’n goede keuze, want het zou beter zijn om te spreken over een ‘splitter’. De aansluitklemmen van lijn A en B bestaan uit vier aansluitingen, omdat Modbus RTU werkt met RS485 moeten enkel de aansluiting T+ en T- aangesloten worden.

figuur 30: Aansluitschema

Naast de fysische configuratie moeten nog vier dipswitches ingesteld worden voor de interne configuratie van de splitter. De eerste dipswitch stelt de transmissie snelheid en de lengte van een karakter in. Voor Modbus RTU wordt standaard 9600 bps en een 11-bit karakter gebruikt. Dit zal ook het geval zijn voor deze toepassing. De tweede dipswitch stelt enkele functies in zoals antiblokkering en her-synchronisatie. Daarnaast moet worden aangegeven of lijn A en lijn B van het twee- of vierdraadstype zijn. De her-synchronisatiefunctie wordt gedeactiveerd omdat dit enkel van toepassing is op hoge transmissie-snelheden. De antiblokkeringsfunctie wordt wel geactiveerd waardoor de transmissies beveiligd worden aan de twee kanten van de splitter. Tot slot worden de twee lijnen A en B ingesteld als tweedraadstype omdat dit standaard is voor Modbus RTU. Met de derde dipswitch worden de eigenschappen van lijn A beschreven. Het beveiligingsniveau voor het vierdraadstype wordt op inactief gezet en het beveiligingsniveau voor het tweedraadstype wordt op actief gezet. De afsluitweerstand voor de lijn A wordt niet gebruikt omdat dit niet nodig is. Een overzicht van de nodige afsluitweerstanden is te vinden op figuur 31. Daar zijn de afsluitweerstanden aangeduid met een grijs vakje. Het is logisch dat telkens op het begin en op het einde van een lijn, een afsluitweerstand zit. De laatste dipswitch is net dezelfde als de vorige maar nu voor lijn B. Merk op dat er voor lijn B wel een afsluitweerstand nodig is volgens figuur 31 omdat dit het begin is van een nieuwe lijn.


26

figuur 31: Locatie van afsluitweerstanden

Volgens figuur 31 moeten twee van de zes afsluitweerstanden in de splitter geconfigureerd worden maar de ander vier moeten ingesteld worden via de extra communicatiemodule op de Diris meetmodules. Bovenaan de communicatiemodule is een dipswitch aanwezig om de afsluitweerstand te activeren.

7.4. Controller 7.4.1. Algemeen De controller is het belangrijkste onderdeel voor de opdracht rond energiebeheer. Het is hier dat de omzetting van Modbus naar KNX moet gebeuren. De controller zal aan de ene kant een Modbus master zijn, en aan de andere kant zijn data op het KNX-netwerk plaatsen. In het bedrijf is al onderzoek verricht naar een gepaste controller voor de aanvang van deze masterproef. De keuze is gevallen op een WAGO controller, namelijk de WAGO 750-849, afgebeeld op figuur 32. Dit is een controller die het KNX/IP-protocol ondersteunt waardoor er communicatie mogelijk is met de GIRA FacilityServer. Deze controller is aangekocht in een pakket met enkele I/O modules en een extra KNX interfacemodule voor een twisted-pair netwerk. Dit pakket heeft de naam ‘Starterkit 2’ en is bedoeld als een promotiepakket om de werking van deze controller te testen. Om ook te kunnen communiceren met Modbus RTU is er nog een extra programmeerbare RS485/RS232 seriële interface nodig.

Figuur 32: Wago controller 750-849


27

De controller ziet er niet groot of ingewikkeld uit maar niets is minder waar. De controller is hardware matig één toestel maar op KNX niveau bestaat de controller uit twee KNX-toestellen. Er is een KNX router en een KNX/IP-controller, dit is duidelijk te zien op de figuur 33. Het toestel kan op het bedrijfsnetwerk gekoppeld worden via de RJ45 connector. Daarvoor moet eerst een IP-adres toegekend zijn aan het toestel. De twee interne KNX-toestellen zijn dan bereikbaar via hetzelfde IP-adres maar met een andere poort. Dit is eigenlijk niet belangrijk want de gebruiker zal hier niets van merken aangezien alles door de software geregeld wordt.

figuur 33: Opbouw Wago KNX/IP-controller

Het eerste interne KNX-toestel is een KNX/IP-controller. Met dit toestel is het mogelijk om gelijk welke data te vertalen naar KNX-telegrammen. Die data kan afkomstig zijn van allerhande andere bussystemen via een interface module zoals Modbus, Dali, Enocean, Profibus, CANbus,… Ook data die afkomstig zijn van input en output kaarten die op de controller zitten, kunnen omgezet worden naar KNX-telegrammen. Het is duidelijk dat dit toestel zeer flexibel is omdat de gebruiker alles zelf kan programmeren en zelf kan beslissen welke data over KNX/IP verzonden of ontvangen worden. De enige beperking voor de KNX/IP-controller is het maximaal aantal KNX-telegrammen van 255. Voor deze opdracht wordt enkele gebruik gemaakt van de KNX/IP-controller omdat het gemakkelijk te koppelen is op het bedrijfsnetwerk. Er moet enkel communicatie mogelijk zijn met de GIRA FacilityServer. Aan deze voorwaarde is zeker voldaan omdat de server ook aangesloten is op het bedrijfsnetwerk en ook het KNX/IP-protocol ondersteunt. Het tweede interne KNX-toestel is een router die zorgt voor het routeren van een KNX/TP1-module. Met deze module kan een klassiek twisted-pair KNX-netwerk gekoppeld worden op een KNX/IP-netwerk. Dit is niet van toepassing voor deze opdracht en wordt niet verder toegelicht.

7.4.2. WAGO Ethernet Settings (4.7) Om een IP-adres toe te kennen aan de controller moet het bijgeleverde programma ‘WAGO Ethernet Settings‘ gebruikt worden. Door de USB kabel te verbinden met de computer wordt een verbinding gemaakt. Hiervoor moet wel de driver voor de USB kabel geïnstalleerd zijn op de computer. Deze driver is te vinden op de website van WAGO [4]. Figuur 34 toont de belangrijkst instellingen die gemaakt zijn met dit programma. Als de tekst onder de laatste knop niet de juiste COM-port aangeeft, moet de gebruiker erop klikken en kiezen voor de juiste COM-poort. De huidige instellingen kunnen geladen worden uit de controller door op de knop ‘Read’ te Uitbreiden van domoticasysteem in een distributiebedrijf

28

drukken. Het belangrijkste tabblad is dat voor TCP/IP waar de instellingen gemaakt worden voor het IP-adres, subnet mask en gateway. Om de instellingen te downloaden naar de controller moet de gebruiker op de knop ‘Write’ drukken. Hierdoor zitten de instellingen in de controller en kan het programma afgesloten worden met de knop ‘Exit’.

figuur 34: WAGO Ethernet Setttings (4.7)

7.4.3. Programmeerbare RS485-klem De controller moet kunnen communiceren via Modbus RTU met de Diris meetmodules en daarvoor is een extra seriële klem nodig op de controller. Deze klem is in staat om te communiceren volgens RS485, zoals Modbus RTU het voorschrijft. WAGO heeft verschillende RS485-klemmen ter beschikking maar voor deze toepassing is gekozen voor een programmeerbare RS485-klem. De gebruiker kan deze klem instellen volgens de noden van de toepassing zoals baudrate, aantal stopbits, pariteit, karakterlengte,… Op figuur 35 is zo’n klem afgebeeld met bestelnummer 750-653/003-000.

figuur 35: Programmeerbare RS485-klem


29

De instellingen van de programmeerbare RS485-klem worden geprogrammeerd via het programma ‘WAGO-IOCheck’. De klem heeft twee keer vier aansluitingen, deze zijn te zien op figuur 36. De aansluitingen bestaan uit een plus en min voor het zenden (TxD) en een plus en min voor het ontvangen (RxD) van data. De twee aansluitingen met ‘M’ is voor de massa van de bus en de ‘S’ is bedoeld voor het schild van de datakabel. Op figuur 36 is ook het aansluitschema getekend voor een RS485 bussysteem. De twee positieve en negatieve klemmen voor het zenden en ontvangen zijn met elkaar doorverbonden omdat bij RS485 de bus voor zowel zenden als ontvangen wordt gebruikt. Op het begin en het einde van de bus is een afsluitweerstand nodig om geen reflecties te hebben.

figuur 36: Aansluitschema RS485-klem

7.4.4. WAGO-IO-Check 3 (3.2) Met dit softwarepakket is het mogelijk om de programmeerbare klemmen te configureren. Daarnaast is het ook mogelijk om de waardes van de I/O’s uit te lezen en te manipuleren. In figuur 37 staat de gebruikersinterface van het programma ‘WAGO-IO-Check 3’. Het uitlezen van de I/O’s is niet echt nuttig omdat dit ook kan via de CoDeSys-programmeeromgeving. Het programma is wel nuttig om de programmeerbare RS485-klem in te stellen. Daarvoor moet de gebruiker de klem selecteren en op de knop ‘Settings’ drukken. Daarna krijgt de gebruiker een scherm te zien zoals in figuur 38.


30

figuur 37: WAGO-IO-Check 3 (3.2)

figuur 38: Instellingen van programmeerbare RS485-klem


31

De gebruiker kan de instellingen naar eigen wensen aanpassen. Bij het kiezen van een bepaalde instelling zal deze instelling ook op ieder ander toestel in het netwerk dezelfde moeten zijn. De keuze van een Modbus RTU netwerk legt al verschillende instellingen vast zoals de ‘Duplex Mode’ en de lengte van de ‘Databits’ onder de parameter ‘Dataframe’. Ook het ‘Module Type’ wordt bepaald door de eisen van Modbus RTU, namelijk RS485. De pariteit en het aantal stopbits kan vrij gekozen worden volgens de wensen van de gebruiker. Dit zijn de belangrijkste instellingen voor de programmeerbare klem, de andere parameters kunnen op de standaard instelling blijven staan.

7.4.5. WAGO Controller in ‘ETS3’ Als de benodigde data uit de Diris meetmodules beschikbaar is in de controller, moet deze data één voor één in een KNX-telegram gestopt worden. Maar met deze telegrammen kan nog niets aangevangen worden indien er geen groepsadres aan toegekend is. Daarvoor moet de controller opgenomen worden in de configuratie van het KNX-netwerk, dit gebeurt altijd via de ‘ETS3’ software. In de programmeeromgeving van WAGO, CoDeSys V2.3, is het mogelijk om een configuratie bestand voor ‘ETS3’ te creëren. Dit bestand wordt gecreëerd op het moment dat het programma gecompileerd en gedownload wordt naar de controller. De extentie van dit bestand is ‘.SYM_XML’ en de naam is hetzelfde als dat van het project. Dit bestand moet later in de ‘ETS3’ software geïmporteerd worden maar eerst moet in CoDeSys v2.3 de optie voor het creëren van deze SYM_XML-file aangevinkt worden. Daarvoor moet geklikt worden op ‘options…’ onder de menu ‘project’. Daarna krijgt de gebruiker een scherm gelijkaardig aan figuur 39. Door te klikken op ‘Symbol configuration’ onder ‘Category’ wordt het scherm bekomen zoals in figuur 39. De gebruiker moet ervoor zorgen dat ‘Dump XML symbol table’ aangevinkt is, daarna kan op de knop ‘Configure symbol file …’ geklikt worden. Hierdoor wordt een nieuw scherm zichtbaar zoals in figuur 31. Het is van groot belang om ‘Export variables of object’ uit en weer aan te vinken. Hierna is alles ingesteld en de vensters kunnen afgesloten worden via de ‘OK’ knop.

figuur 39: Scherm ‘Options’


32

figuur 40: Scherm ‘Set object attributes’

Na het Downloaden van het controllerprogramma is de configuratie file beschikbaar en klaar om te importeren in de ‘ETS3’ software. Door met de rechtmuistoets op de controller te klikken in ‘ETS3’ en te kiezen voor ‘Editeer parameter’, kan de controller geconfigureerd en later ook opgenomen worden in het KNX-netwerk. Hierna komt een scherm te voorschijn zoals in figuur 41 voor het configureren van de controller. Door op het icoontje links van het icoontje voor ‘Save’ te drukken, kan de SYM_XML-file geïmporteerd worden. Daarna komen alle geprogrammeerde KNX-telegrammen in het venster ‘List of netwerk variables’. Om een KNXtelegram uit de controller toe te kennen aan een groepsadres moet eerst het groepsadres geselecteerd worden. Daarna kan het KNX-telegram in het groepsadres gesleept worden. Hierdoor is het KNX-telegram gekoppeld aan een groepsadres. Verder moet er niets veranderd worden aan de instellingen van de KNXtelegrammen.


33

figuur 41: Configuratie WAGO controller

Om de groepsadressen te downloaden naar de controller moeten de IP instellingen correct zijn. Daarvoor moet op de respectievelijk knop gedrukt worden. Door het MAC adres van de controller in te vullen, zal de software zelf het IP-adres zoeken van de controller door op de knop ‘Scan IP’ te drukken. Op deze manier is het IP-adres correct ingesteld en kunnen alle instellingen gedownload worden naar de controller. De instellingen zijn te zien op figuur 42.

figuur 42: IP settings voor de KNX/IP-controller


34

7.5. GIRA FacilityServer 7.5.1. Algemeen Tot nu toe is een installatie mogelijk waarbij gegevens via Modbus RTU uit de Diris meetmodules gehaald worden. Deze gegevens kunnen omgezet worden in KNX-telegrammen met de WAGO controller maar met enkel wat gegevens wordt er niet aan energiebeheer gedaan. Daarvoor moet nog iets nuttigs gebeuren met de gegevens en daarvoor is de GIRA FacilityServer zeer geschikt. Deze server is in staat om grote hoeveelheden data van op het KNX-netwerk te verwerken tot nuttige data. De gebruiker moet eerst bepalen welke grootheden of parameters nuttig zijn voor het energiebeheersysteem. De Diris meetmodules vormen hierin wel de beperkende factor, want deze toestellen moeten de grootheden of parameters meten. Het is zo dat de toestellen zeer geavanceerd zijn en zeer veel kunnen meten zoals stromen, spanningen, frequentie, arbeidsfactor, zelfs harmonischen behoren tot de mogelijkheden. In deze toepassing is gekozen om voor iedere meetmodule de stromen, het driefasig actueel vermogen en het verbruik op te nemen in het energiebeheersysteem. Daarnaast wordt de lijnspanning gemeten in de meetmodules bij de hoofdtransfo’s. Het verbruik moet niet constant geregistreerd worden maar er moet iedere maand automatisch een bericht verzonden worden met alle meterstanden naar een persoon die deze waarden bijhoudt.

7.5.2. Registratie en Bewaking De waardes van de stroom en driefasig actueel vermogen zullen voor iedere meetmodule constant uitgelezen worden. Deze waardes moeten gecontroleerd worden op een bepaalde maximum grenswaarde. Op deze manier is het mogelijk om in te grijpen als de waardes te hoog zijn. Bij overschrijden van de maximum waarde moeten de verantwoordelijken een e-mail ontvangen met desbetreffende foutmelding. Dit is makkelijk realiseerbaar met de GIRA FacilityServer in de ‘Graphic Logic Editor’. De waarde wordt vergeleken met een bepaalde maxima waarde en als deze groter is, wordt er een alarm geactiveerd onder de vorm van een e-mail. Daarnaast is het aangewezen om een archief bij te houden van de afgelopen weken zodat de gebruiker na een alarm de nodige conclusies kan trekken. Er kan opgemerkt worden dat de bewaking van de stroom en het driefasig actueel vermogen ongeveer op hetzelfde neerkomt. Dit klopt volledig want door de constante waarde van de spanning en een goede arbeidsfactor door de condensatorbatterijen zal dit ook zo zijn. Maar de bewaking van de stroom kan gezien worden als een fase bewaking en het driefasig actueel vermogen als een globale bewaking. De lijnspanningen worden enkel bij de hoofdtransfo’s opgenomen in het energiebeheersysteem. Het is wenselijk dat de spanning tussen een minimum en maxium waarde moet liggen, anders is iets fout gegaan. De foutmelding kan net zoals bij de stroom en het driefasig actueel vermogen via een e-mail naar de verantwoordelijken doorgestuurd worden. Het aanhouden van een archief is hier ook noodzakelijk om eventuele trends of gebeurtenissen voorafgaand aan een spanningspiek of spanningsdal te analyseren.

7.5.3. Visualisatie Via de client-applicatie van GIRA is er een mogelijkheid om de gemeten waardes uit de Diris meetmodules te visualiseren. Behalve de actuele waarde voor de stroom, het driefasig actueel vermogen en in sommige gevallen de lijnspanningen is een grafiek van de afgelopen vierentwintig uur erg handig. Op deze manier kan de


35

gebruiker op regelmatige basis de waarden vlug en nauwkeurig bekijken. Voor het driefasig actueel vermogen is het handig om een grafiek te hebben van een week terug om eventuele trends op te merken.

7.6. Realisatie 7.6.1. Overzicht Om een goed overzicht te verkrijgen is op figuur 43 een schets zichtbaar van de hardware opstelling. De belangrijkste onderdelen zijn op de schets benoemd. In de schets staan vier Diris meettoestellen, dit is louter indicatief want in werkelijkheid zijn er ongeveer dertig meetmodules. Alles begint bij de Diris meetmodules, deze krijgen een Modbus slave adres en worden afgepold door de Modbus master in de controller. Het Modbus RTU netwerk is aangesloten op de programmeerbare RS485-klem van WAGO en is op zijn beurt aangesloten op de controller. De controller is in staat om de data uit de meetmodules te vertalen naar KNXtelegrammen en verzendt deze over het bedrijfsnetwerk. Op een andere locatie is de GIRA FacilityServer op het bedrijfsnetwerk aangesloten, deze kan de KNX/IP bericht lezen en gebruiken. Op nog een andere locatie zit een KNX/IP router, dit toestel vertaalt berichten van KNX/IP naar KNX TP en omgekeerd. Mits de data van de meetmodules enkel door de GIRA FacilityServer gebruikt worden, moet een filter ingesteld worden in de KNX/IP router. Op deze manier kunnen de KNX-telegrammen voor energiebeheer niet op het KNX twisted pair netwerk terecht komen. Dit zou immers een risico op overbelasting betekenen.

figuur 43: Hardware configuratie energiebeheer

7.6.2. Controller software project 7.6.2.1. Algemeen Het project van de controller bestaat uit twee delen, een Modbus en een KNX gedeelte. Omdat voor beide delen een master nodig is, is het aangewezen om twee aparte functieblokken aan te maken. Deze functieblokken moeten elk in een apart programma aangeroepen worden om geen problemen te krijgen met cyclustijden. Omdat de data uit het ene programma ook de data is voor het andere programma zijn twee globale variabelen voorzien. De variabele ‘oModules’ bevat alle nodige gegevens per Diris meetmodule en de Uitbreiden van domoticasysteem in een distributiebedrijf

36

variabele ‘sModuleMislukt’ geeft aan welke module niet uitgelezen is. Dit heeft te maken met een foutmelding om problemen met Modbus op te sporen. Figuur 44 toont de projectstructuur van de controller.

figuur 44: Projectstructuur WAGO controller

Omdat er twee aparte programma’s zijn, moeten ook twee tasks aangemaakt worden in de controller. In de CoDeSys programmeeromgeving kunnen verschillende tasks toegevoegd worden. Daarvoor moet de gebruiker op ‘task configuration’ klikken onder het tabblad ‘Resources’. Hierbij moeten nog enkele instellingen gebeuren, zoals de naam en de prioriteit van de task. Als laatste moet het type gekozen worden, daar zijn drie mogelijkheden voor ‘Cyclic’, ‘Freewheling’ of ‘Triggerd by event’. Bij de keuze voor ‘Cyclic’ moet een vooraf gedefinieerde cyclustijd ingesteld worden, de cyclustijd is dus een constante. ‘Freewheling’ betekent dat de controller het programma constant uitvoert, dit resulteert in een variabele cyclustijd. Tot slot bestaat de keuze ‘Triggerd by event’, hierbij moet een event gekozen worden om het programma uit te voeren. In deze toepassing wordt steeds voor de instelling ‘Freewheling’ gekozen. De prioriteit van de Modbus task moet hoger zijn dan deze van de KNX-task omdat dit de meest kritische task is. Als dit niet zo is, ontstaat er een probleem met het bufferen van de Modbus berichten. Dit probleem heeft zich voorgedaan tijdens de testfase. Op figuur 45 is de instelling te zien van de Modbus task, deze heeft de prioriteit één. De task voor KNX heeft een lagere prioriteit namelijk negen. Het laatste wat nog moet gebeuren is de task linken aan een programma, daarvoor moet de gebruiker op de task klikken met de rechtermuisknop en kiezen voor ‘Append Program Call’. Daarna kan een programma toegekend worden door te drukken op de ‘…’ knop en het juiste programma te selecteren.


37

figuur 45: Modbus task

7.6.2.2. Modbus Om zeker te zijn dat het programma voor de Modbus communicatie zal werken, moeten de instellingen voor Modbus van de programmeerbare RS485-klem overeenkomen met deze van alle Diris meetmodules. Het is belangrijk te kiezen voor acht databits omdat er gebruik gemaakt wordt van Modbus RTU. Daarnaast is gekozen voor één stopbit en geen pariteit. Deze instellingen moeten overal gelijk zijn, anders zal de bus niet werken en voor problemen zorgen. Om de instellingen op de Diris meetmodules te configureren wordt verwezen naar de handleiding in de bijlage. Het is ook belangrijk om de afsluitweerstanden niet te vergeten aan te zetten op de communicatiemodules waar nodig. Om te beginnen programmeren is het noodzakelijk om een lijst met de mappingparameters te raadplegen zodat de gebruiker kan achterhalen op welk register welke parameters zitten. In de bijlage zit de volledige lijst maar in tabel 4 zijn alle benodigde parameters opgegeven. Al deze waarden zijn dubbelwoorden en worden uitgelezen via het Modbus netwerk met de functiecode 03. Voor meer informatie over Modbus wordt verwezen naar het respectievelijke hoofdstuk. tabel 4: Mappingparameters Diris Ap meetmodule

Adres (Hex) 300 302 304 306 308 30A 30C 316 358

Aantal woorden 2 2 2 2 2 2 2 2 2

Benaming Stroom fase 1 Stroom fase 2 Stroom fase 3 Stroom fase N Lijnspanning U12 Lijnspanning U23 Lijnspanning U31 Σ actief vermogen Actieve energie

Eenheid mA mA mA mA V/100 V/100 V/100 kW/100 kWh


38

Het belangrijkste in het Modbus programma is ongetwijfeld de Modbus RTU master, dit is het kloppende hart van het programma. Om deze master te kunnen gebruiken moeten de bibliotheken ‘Modb_l05.lib’, ‘Sercomm.lib’, ‘Mod_Com.lib’ en ‘Serial_Interface_01.lib’ gedownload worden van de WAGO website. Daarna kunnen de bibliotheken in het project opgenomen worden via het tabblad ‘Resources’ in de CoDeSys V2.3 programmeeromgeving. In figuur 46 staat de functieblok ‘MODBUSMASTER_RTU’ afgebeeld met al zijn in- en uitgangen, deze zit in de bibliotheek ‘Modb_l05.lib’. De ingangen ‘cbCOM_BAUDRATE’, ‘cpCOM_PARITY’, ‘csCOM_STOPBITS’, ‘cbsCOM_BYTESIZE’ en ‘cfCOM_FLOW_CONTROL’ moeten niet ingevuld worden want deze liggen vast door de instellingen van de programmeerbare RS485-klem.

figuur 46: Functieblok Modbus master

In tabel 5 staat een beschrijving van alle andere IO van de functieblok ‘MODBUSMASTER_RTU’. De waarde van de variabelen ‘FunctieCode’, ‘TimeOut’ en ‘bCOM_PORT’ zijn vaste waardes en zijn respectivelijk drie, 250 milliseconden en twee. De waarde twee voor de ‘bCOM_PORT’ geeft aan dat het om de eerste seriële interface gaat, in dit geval de programmeerbare RS485-klem. De variabelen ‘SlaveAddress’, ‘FunctionCode’, ‘StartAddress’ en ‘NumberOfPoints’ zullen steeds veranderen bij het verzenden van een bericht en moeten op voorhand juist ingesteld worden. Daarna kan de variabele ‘StartFunction’ hoog gemaakt worden. Pas als deze variabele terug laag komt, is het antwoord beschikbaar in de variabele ‘ReceiveBuffer’. Deze variabele is een struct die de fabrikant heeft aangemaakt en bevat een integer ‘Index’ die aangeeft hoeveel bytes in het antwoord zitten. Daarnaast bevat de struct nog een array ‘Data’ van 256 bytes waar het antwoord per byte beschikbaar is. In deze variabele staat altijd het meest recente antwoord dat de master heeft teruggekregen. Als de uitgang ‘Error’ nul is, dan kan er van uitgegaan worden dat het antwoord in ‘ReceiveBuffer’ juist is. tabel 5: Beschrijving IO Modbus master

Type IN IN IN IN

Variabele SlaveAddress FunctionCode StartAddress NumberOfPoints

Datatype byte byte word word

IN IN IN/OUT

bCOM_PORT TimeOut StartFunction

byte time bool

IN/OUT IN/OUT OUT

ReceiveBuffer SendData Error

typRING_Buffer typRING_Buffer byte

Beschrijving Adres van slave waarvoor request bedoeld is. Geeft de functiecode aan. Geeft het startadres van de waarde in het register. Aantal woorden die uitgelezen worden vanaf het startadres. Poortnummer van de seriële interface klem. Binnen deze tijd verwacht de master reactie van de slave. Moet hoog gemaakt worden om het bericht te verzenden. Als het antwoord ontvangen is, komt de bit laag. Hierin zit het antwoord van de slave. Hierin wordt de te verzenden data geplaatst. Foutcode, is nul als er geen fout is.


39

Bij het ontvangen van een antwoord zal alles terug te vinden zijn in de ‘ReceiveBuffer’, hierin bevinden zich onder andere de gewenste gegevens en ook enkele andere data. De structuur van de ‘ReceiveBuffer’ staat weergegeven in tabel 6. tabel 6: Structuur van 'ReceiveBuffer'

ReceiveBuffer .Index .Data[0] .Data[1] .Data[2] .Data[3] .Data[4] … .Data[n-3] .Data[n-2] .Data[n-1]

Beschrijving Aantal ontvangen bytes (n) Slave adres Functiecode Aantal data bytes (k) DATA[0] DATA[1] … DATA[k-2] DATA[k-1] CRC

Omdat er gewacht moet worden het op laag komen van ‘StartFunctie’ alvorens de ‘ReceiveBuffer’ uit te lezen, is het aan te raden om een stappensturing te voorzien. Deze stappensturing is geldig voor iedere meetmodule, daarom zal de stappensturing steeds opnieuw beginnen. Bij het opnieuw beginnen, houdt een variabele bij hoeveel keer de stappensturing doorlopen is. Deze variabele wordt ook gebruikt om het slave adres te vormen. Normaal moet elke parameter apart uitgelezen worden maar als de parameters na elkaar staan in het register, is het mogelijk om deze samen op te vragen in één bericht. Zo kunnen de vier stromen en de drie spanningen telkens samen opgevraagd worden. Om een waarde binnen te nemen in de controller is er nood aan twee stappen. De eerste stap zal alle parameters goed instellen om een correcte request te versturen. Ook de variabele ‘StartFunction’ wordt hoog gemaakt. Daarna kan de stap verhoogd worden. Als voorbeeld is hieronder stap nul weergegeven waarbij het actueel driefasig vermogen opgevraagd wordt . 0:(*actueel vermogen opvragen*) bSlaveAddress:=INT_TO_BYTE(i+1); bFunctionCode:=3; wStartAddress:=16#316; wNumberOfPoints:= 16#2; xRead := TRUE; iStatus := iStatus + 1; iAantalMislukkingen:=0; In de tweede stap moet gewacht worden tot de variabele ‘StartFunction’ door de master op laag geset wordt. Als deze voorwaarde voldaan is, kan er nog een controle gebeuren opdat het bericht wel het juiste is en correct ontvangen is. Daarna kan de data uit de ‘ReceiveBuffer’ opgeslagen worden in de controller. Daarvoor zijn enkele bewerkingen nodig omdat van vier bytes een dubbelwoord moet gemaakt worden. Als voorbeeld is de code van stap één hieronder weergegeven.


40

1:(*actueel vermogen ontvangen*) IF NOT xRead THEN(*wachten op antwoord van de slave*) IF oOntvangenData.Data[1]=bFunctionCode AND oOntvangenData.Data[0]=bSlaveAddress AND NOT BYTE_TO_BOOL(oMaster.error) THEN dwData:=oOntvangenData.Data[6]; dwData:=ROR(dwData,8); dwData:=dwData + oOntvangenData.Data[5]; dwData:=ROR(dwData,8); dwData:=dwData + oOntvangenData.Data[4]; dwData:=ROR(dwData,8); dwData:=dwData + oOntvangenData.Data[3]; dwData:=ROR(dwData,8); rGetal:=DWORD_TO_REAL(dwData)/100; oModules[BYTE_TO_INT(bSlaveAddress)].rActueelVermogen:=rGetal; iStatus := iStatus + 1; ELSE xRead:=TRUE; iAantalMislukkingen:= iAantalMislukkingen + 1; IF iAantalMislukkingen > 50 THEN xRead:=FALSE; iStatus:=iStatus + 1; iTotaalMislukt:=iTotaalMislukt+1; END_IF END_IF END_IF Indien het ontvangen bericht niet klopt, zal opnieuw geprobeerd worden door de variabele ‘StartFunction’ weer hoog te maken. Via de variabele ‘iAantalMislukkingen’ wordt het aantal mislukte pogingen bijgehouden. Als deze groter zijn dan vijftig wordt overgegaan naar de volgende stap. Dit is om te vermijden dat de stappensturing vast loopt. De variabele ‘iTotaalMislukt’ houdt bij hoeveel keer bij een bepaalde module het zenden niet lukt. Deze variabele wordt in de laatste stap gebruikt om een foutmelding te genereren op het KNX-netwerk. De gebruiker wordt dan verwittigd via een mail die door de GIRA FacilityServer verstuurd wordt. Daarvoor dient ook de globale variabele ‘sModuleMislukt’ om het module nummer mee te geven dat niet is uitgelezen. Dit geeft kort weer hoe één parameter opgevraagd wordt uit de Diris meetmodules. Voor de andere parameters wordt op gelijkaardige manier gewerkt. Daarbij moeten de variabelen ‘StartAddress’ en ‘NumberOfPoints’ telkens anders ingesteld worden. Alle gegevens worden in een array van een zelf gemaakte struct bewaard, de grobale variabele ‘oModules’. Hieronder staat de structuur weergegeven, alle waarden zijn ‘real’ variabelen omdat het KNX-gedeelte dit vereist.


41

TYPE MODULE : STRUCT rActueelVermogen:REAL; rU12:REAL; rU23:REAL; rU31:REAL; rStroom1:REAL; rStroom2:REAL; rStroom3:REAL; rStroomN:REAL; rMeterstand:REAL; END_STRUCT END_TYPE

7.6.2.3. KNX De functieblok voor het KNX-gedeelte bevat eigenlijk geen logica maar enkel een KNX-master en alle KNXtelegrammen. Om te kunnen programmeren moeten eerst nog vijf bibliotheken toegevoegd worden, deze zijn ‘KNX_IP_750_849_01.lib’, ‘KNX_Standard.lib’, ‘SYSLIBCALLBACK.lib’, ‘SysLibGetAddress.lib’ en ‘WAGOLibKNXDevice.lib’. In de eerste bibliotheek bevindt zich de functieblok voor de KNX-master, deze heet FbKNX_Master_849. Dit is een zeer eenvoudige functieblok met twee uitgangen en één in/out variabele. De in/out variabele heet ‘typKNX’ en wordt gebruikt om de KNX-telegrammen te synchroniseren met de master. Verder is er nog de uitgang ‘xProg_Mode’ die aangeeft of de controller aan KNX-kant in programmeertoestand staat. Deze variabele wordt niet gebruikt en is van minder belang. Tot slot is er nog een variabele ‘enumDeviceStatus’, deze geeft aan of de master goed werkt of niet. Om een bepaalde waarde op het KNX-netwerk te plaatsen moet een KNX-telegram aangemaakt worden. Er zijn veel verschillende KNX-telegrammen te vinden in de ‘KNX_Standard.lib’ bibliotheek. Omdat de meeste meetwaardes kommagetallen zijn, is gekozen voor het KNX-telegram ‘4-byte float’. Dit telegram kan een real waarde op het KNX-netwerk plaatsen, de structuur is te zien op figuur 47.

figuur 47: '4-byte float' KNX-telegram

Alle KNX-telegrammen in de ‘KNX_Standard.lib’ bibliotheek kunnen waardes zenden naar of waardes ontvangen van het KNX-netwerk. Afhankelijk van de keuze moeten verschillende in- en uitgangen ingevuld worden. In deze toepassing wordt enkel verwacht dat er waardes naar het KNX-netwerk verzonden worden. Daardoor mogen alle uitgangsvariabelen leeg gelaten worden. De ingang ‘rValue_IN’ is voor de effectieve waarde die verzonden moet worden. In deze toepassing zitten alle waardes in een globale variabele, een array van het type Module waardoor ze makkelijk te bereiken zijn. Vervolgens kunnen er drie variabelen naar eigen wensen en noden al of niet gebruikt worden. De eerste is ‘xUpdate_KNX’, door een stijgende flank zal het telegram op het KNX-netwerk geplaatst worden. De tweede is ‘rSendOnDelta’ en zorgt dat er pas een telegram verstuurd wordt bij een minimum verschil tussen de huidige en vorige waarde. Tot slot is er de variabele ‘tMinSendTime’ waar de maximale tijd tussen twee telegrammen gedefinieerd wordt. De variabele ‘typDPT’ Uitbreiden van domoticasysteem in een distributiebedrijf

42

heeft hier geen betekenis en is enkel van belang bij het ontvangen van data maar moet toch ingevuld worden om goed te werken. De laatste ingangsvariabele ‘typKNX’ dient om te synchroniseren met de KNX-master en moet gekoppeld zijn aan de gelijknamige uitgang van de master. Als voorbeeld staat hieronder de KNX-master met de KNX-telegrammen van module 1. Er is gekozen om een telegram te zenden bij een minimaal verschil van een halve eenheid, dit is de beste oplossing om het aantal berichten min of meer te beperken. FbKNX_Master_849(typKNX:=typKNX , enumDeviceStatus=>Status , xProg_Mode=>xProgmode ); OUT_Module1_U12(rValue_IN:=oModules[1].rU12 ,xUpdate_KNX:= ,rSendOnDelta:=0.5 ,tMinSendTime:=,typDPT:=typDummy ,typKNX:=typKNX ); OUT_Module1_U23(rValue_IN:=oModules[1].rU23 ,xUpdate_KNX:=,rSendOnDelta:=0.5 ,tMinSendTime:=, typDPT:=typDummy ,typKNX:=typKNX ); OUT_Module1_U31(rValue_IN:=oModules[1].rU31 ,xUpdate_KNX:=,rSendOnDelta:=0.5 ,tMinSendTime:=,typDPT:=typDummy ,typKNX:=typKNX ); OUT_Module1_AV(rValue_IN:=oModules[1].rActueelVermogen ,xUpdate_KNX:=,rSendOnDelta:=0.5 ,tMinSendTime:=, typDPT:=typDummy ,typKNX:=typKNX ); OUT_Module1_Stroom1(rValue_IN:=oModules[1].rStroom1 , xUpdate_KNX:= ,rSendOnDelta:=0.5 ,tMinSendTime:= ,typDPT:=typDummy ,typKNX:=typKNX ); OUT_Module1_Stroom2(rValue_IN:=oModules[1].rStroom2 , xUpdate_KNX:= ,rSendOnDelta:=0.5 ,tMinSendTime:= ,typDPT:=typDummy ,typKNX:=typKNX ); OUT_Module1_Stroom3(rValue_IN:=oModules[1].rStroom3 , xUpdate_KNX:= ,rSendOnDelta:=0.5 ,tMinSendTime:= ,typDPT:=typDummy ,typKNX:=typKNX );

7.6.3. ‘ETS3’ configuratie Om de KNX-telegrammen te kunnen gebruiken, moet de controller geconfigureerd worden in ‘ETS3’. Hierin worden de telegrammen gelinkt aan een groepsadres. Hoe dit moet gebeuren is al eerder vermeld in de tekst. Maar naast het configureren van de controller moet ook de KNX/IP router ingesteld worden. Er moet gezorgd worden dat de berichten niet van IP kant naar Twisted-Pair kant kunnen gaan. Standaard is er geen filter ingesteld en worden de berichten naar beide kanten vertaald. De router kan enkel maar groepsadres veertien en vijftien blokkeren. Daarom zullen alle groepsadressen voor het energiebeheersysteem uit de hoofdgroepen veertien en vijftien moeten komen. De groepsadressen mogen niet zomaar gekozen worden want er moet gezorgd worden dat alle data binnen deze twee hoofdgroepen vallen. In figuur 48 staan de groepsadressen in ‘ETS3’ afgebeeld. Onder de subgroepen met de lijnspanningen zijn maar drie eindgroepen toegevoegd voor de hoofdtransfo’s. Onder de andere subgroepen van de stromen, het verbruiken en actueel vermogen is telkens ieder module toegevoegd als eindgroep. Er zijn een dertigtal modules geïntegreerd per subgroep. Tot slot is er nog de subgroep ‘Andere’ met enkele uitbreidingen en een foutmelding indien een module niet is uitgelezen.


43

figuur 48: Groepsadressen in ‘ETS3’

7.6.4. GIRA FacilityServer Het laatste wat nog moet gebeuren is de verwerking van de meetgegevens in de GIRA FacilityServer. In het energiebeheersysteem moet het mogelijk zijn om de gegevens te archiveren. Daarom worden alle data ongeveer zestien dagen bijgehouden met een meetfrequentie van vijf minuten. Dit moet de gebruiker in staat stellen om de gegevens te analyseren na een foutmelding. Met de gegevens is het ook mogelijk om een trend op lange termijn te bestuderen. Uit deze studie kan de gebruiker eventuele maatregelen nemen zodat het elektrische verbruik vermindert. Via een internetbrowser kan het volledige archief geraadpleegd worden. Daarvoor is het belangrijk om te weten dat ieder archief een uniek naam heeft, namelijk ‘energie’ gevolgd door het module nummer. Het browser adres is ‘http://172.16.102.199/hslist’, daarbij moet de gebruiken een gebruikersnaam, wachtwoord en archiefnaam ingeven om toegang te verkrijgen. In figuur 49 staat het archief van module 22 afgebeeld.


44

figuur 49: Archief van module 22 via ‘Internet Explorer’

Naast archiveren moeten de elektrische parameters gecontroleerd worden op grenswaardes. Voor de stromen I1, I2 en I3 is gekozen om een maximum grensbewaking in te stellen. De bepaling van de maximale grenswaarde per lijn is experimenteel bepaald. Uit het archief is voor iedere stroom het maximum gehaald en vermeerderd met een marge van twintig procent. Deze waardes worden in de ‘Graphic Logic Editor’ vergeleken met de actuele stroomwaarde. Als de actuele stroomwaarde in minstens één lijn hoger is dan de ingestelde grens, wordt een e-mail verstuurd met een foutmelding. Als de stoombewaking geïntegreerd is, kan het zijn dat nog enkele experimentele aanpassingen moeten gebeuren. Het is mogelijk dat een grenswaarde toch nog te nauw gekozen is waardoor er te veel foutmelding verstuurd worden. In het energiebeheersysteem worden ook alle nulleider stromen binnengelezen. De controle van deze stroom is iets anders dan voor de lijnstromen. Als de som van de stromen I1, I2 en I3 groter is dan de nulleiderstroom, wordt er een foutmelding verstuurd via een e-mail. Tot slot wordt ook het driefasig actueel vermogen gecontroleerd op een maximale grenswaarde. Deze waarde is eveneens experimenteel bepaald uit het maximum van het archief met een marge van twintig procent. In figuur 50 is de configuratie van de ‘Logic Editor’ te zien van module 1. Nadat de GIRA FacilityServer opnieuw gedownload is, kan het zijn dat nog niet alle data binnengelezen werden. Daardoor zal de server ongewenste mails verzenden met verkeerde data. Om dit te vermijden is een bitje ter beschikking dat hoog wordt na tien minuten als er een herstart gebeurd is.


45

figuur 50: Configuratie 'Grafic logic editor' van Module 1

In figuur 50 staat de bewaking die altijd geldig is maar daarnaast is nog een bewaking voorzien voor ’s nachts. Deze nachtbewaking moet detecteren als er ergens nog toestellen aanliggen die niet moeten aanliggen. De bepaling van de grenswaardes is gebeurd aan de hand van een experimentele bepaling. Door de grafiek van de afgelopen dag te analyseren wordt de maximale waarde voor ’s nachts bepaald. De nulleiderstroom wordt ook gecontroleerd op een maximum en niet meer op hoger zijn dan de som. Dit zal voor te veel foutmeldingen zorgen omdat ’s nachts de stroom het laagst en het minst evenwichtig verdeeld zal zijn over de drie lijnen. Met als gevolg dat de nulleiderstroom vlug een hogere waarde zal bereiken dan de som van de drie lijnstromen. Voor het bewaken van de spanning op de hoofdtransfo’s is een boven- en ondergrens ingesteld. Als de actuele waarde van de drie lijnspanningen niet tussen de grenzen valt, wordt een e-mail verstuurd. De configuratie in de ‘Graphic Logic Editor’ is gelijkaardig als bij de configuratie van de drie lijnstromen. Na het archiveren en controleren van de data moet alles nog gevisualiseerd worden. De visualisatie wordt op twee manieren geïmplementeerd, via de menustructuur en via een visualisatiepagina. In figuur 51 toont een deeltje van de menustructuur van één meetmodule. Hierin staan alle stromen en het actueel vermogen, zowel de actuele waarde als een grafiek van de afgelopen vierentwintig uur. Bijkomend is nog een grafiek voorzien van het driefasig actueel vermogen van de afgelopen maand. Voor de meetmodules op de hoofdtransfo’s komen de drie lijnspanningen er nog eens bij met de actuele waarde en een grafiek. In figuur 52 staat de hoofdvisualisatiepagina en hierin staan alle modules afgebeeld op de plattegrond van het bedrijf. Door op een module te klikken krijgt de gebruiker een pagina te zien met alle actuele data en alle beschikbare grafieken zoals in figuur 53.


46

figuur 51: Menustructuur van de client- applicatie voor module 22

figuur 52: Hoofdscherm visualisatie


47

figuur 53: Visualisatiepagina van module 22

Op figuur 52 staat onderaan ook een knop om de meterstanden van het verbruik uit te lezen. Hierbij wordt een e-mail verstuurd met de meest recente meterstanden van alle modules naar de verantwoordelijke persoon. Zo’n e-mail wordt ook op iedere eerste dag van de maand automatisch verzonden naar de verantwoordelijke persoon. Normaal moet de knop niet gebruikt worden maar indien er iets fout gaat met de automatische email kunnen de data manueel uitgelezen worden. In figuur 54 staat zo’n automatische e-mail van de maand mei.

figuur 54: Automatische e-mail met meterstanden


48

7.6.5. Opmerkingen Tijdens het testen van het volledige energiebeheersysteem hebben zich enkele problemen voorgedaan. Uit deze problemen kunnen enkele opmerkingen geformuleerd worden om de goede werking van het systeem te garanderen. Deze opmerkingen hebben betrekking tot de communicatie met Modbus of KNX. Een eerste opmerking heeft te maken met het programma in de WAGO controller. In de ‘online’ mode is duidelijk op te merken dat een Modbus bericht soms meerdere malen moet verzonden worden alvorens een antwoord te verkrijgen. Dit is op zich niet zo erg maar het kan wijzen op een probleem met de cyclustijd. Indien het aantal pogingen rond de vijf keren ligt, is er niet echt een probleem. Maar als dit frequent voorkomt zal er ergens een probleem zijn met de cyclustijd van de het Modbus- of KNX-programma. Merk daarbij ook op dat de tijd om alle modules af te pollen sterk zal toenemen indien er veel nieuwe verzendpogingen ondernomen worden. Onder normale omstandigheden duurt het maximaal dertig seconden om alle slaves af te pollen. Deze tijd is misschien iets aan de hoge kant maar kan niet meer verbeterd worden. De oorzaak ligt aan de cyclustijd van de task met alle KNX/IP telegrammen. Door de baudrate van het Modbus RTU netwerk te verhogen, zal weinig verbetering opleveren want de cyclustijd van de KNX/IP telegrammen blijft de beperkende factor. Een veel voorkomend probleem in het KNX-programma is dat de SYM_XML-file niet overeenkomt met de file die in ‘ETS3’ geïmporteerd is. De master zal dan de foutmelding ‘KNX_APPL_CRC_ERR’ geven. Dit kan opgelost worden door de SYM_XML-file opnieuw te importeren in ‘ETS3’ en te kiezen voor een update van de file. Daarna moet de KNX/IP-controller opnieuw geprogrammeerd worden in ‘ETS3’. Dit zorgt ervoor dat alles geüpdate is maar zorgt ook dat het programma uit het geheugen van de controller gewist is. Daarom moet het programma opnieuw gedownload worden in de controller en zal het probleem opgelost zijn. Tijdens het testen van het programma in de WAGO controller zijn bij sommige modules extreem hoge waardes voor het driefasig actief vermogen gemeten. Bij nader onderzoek is gebleken dat dit te maken heeft met de zonnepanelen die aangesloten zijn op de hoofdtransfo’s. De extreem hoge waardes werden dan ook gemeten bij de meetmodules op de hoofdtransfo’s. Dit verschijnsel doet zich voor als de zonnepanelen energie terug in het net stoppen en dit resulteert in een negatief actief vermogen. Blijkbaar kunnen de meetmodules geen negatief driefasig actief vermogen meten en sturen de modules een incorrecte waarde. In de lijst van de mappingparameters staat het negatief actief vermogen apart maar er is uiteindelijk niet gekozen om deze waarde uit te lezen. Er bestaat een vermoeden dat de waardes van het negatief actief vermogen niet volledig correct zijn. Dit is gebleken tijdens een kleine test om deze waardes uit te lezen. Een tweede reden waarom deze waardes niet geïmplementeerd worden, is omdat de meetmodules niet zo’n grote nauwkeurigheid hebben. Om de hoge waardes van het positief driefasig actief vermogen te maskeren worden deze waardes naar nul herleid. Er wordt dan tenslotte ook geen energie verbruikt uit het net van de elektriciteitsleverancier. Er zijn wel plannen om in de toekomst de groene-stroomtellers uit te lezen. Dit zal een beter beeld geven van wat er effectief is opgewekt en voor het bedrijf is deze data veel nuttiger.

7.6.6. Uitbreiding: compressor Tijdens de testfase van het energiebeheersysteem is alles goed verlopen. Daarom is er enige ruimte om aan kleine uitbreidingen te denken. In het magazijn staat een compressor die ook Modbus RTU ondersteunt. Aangezien de bus langs de compressor loopt, is het een kleine moeite om die te implementeren. Om de gegevens uit de compressor te halen, moeten de mappingparameters gekend zijn van de fabrikant. Er is een lijst ter beschikking gesteld door de fabrikant maar na testen is gebleken dat deze niet altijd kloppen. Daarom worden maar twee parameters uitgelezen waarvan de waarde correct lijkt. Deze parameters zijn de


49

druk en het toerental. Het toerental zelf is niet correct en daarom wordt het toerental niet gebruikt als data maar wel om te bepalen of de compressor al dan niet draait. De compressor heeft tijdens de testperiode goed gewerkt maar plots kon geen enkele waarde meer uitgelezen worden. Door de hoofdspanning van de compressor uit te schakelen en terug in te schakelen kan het probleem opgelost worden. De compressor houdt het dan weer een paar dagen vol vooraleer de uitlezing weer stopt. Omdat dit enige locatie is in het bedrijf waar de Modbus kabel langs een frequentiesturing passeert, is onderzocht of de storing niets te maken heeft met elektromagnetische storingen. Dit bleek niet het geval te zijn waardoor de beslissing in gevallen om de compressor definitief uit het Modbus netwerk te halen en niet meer uit te lezen. Het is zinloos om iedere keer opnieuw de voedingskabel te onderbreken en terug aan te sluiten.

7.6.7. Uitbreiding: spanningsmeting Tijdens het testen is gebleken dat het ongeveer twintig seconden duurt alvorens alle meetmodules uitgelezen zijn. Daardoor kunnen spanningspieken of spanningsdalen niet gezien worden, behalve bij een toevallige situatie. Om dit te vermijden moet een manier gezocht worden om alsnog de spanningspieken of -dalen te meten. De meetmodules kunnen maar om de seconde een waarde meten, dit wil zeggen dat een afwijking van de spanning minimum langer of net één seconde moet zijn om de waarde te kunnen meten. Daarom zijn drie optionele IN/OUT modules aangekocht die in staat moeten zijn om de spanningen te bewaken op grenswaardes. Deze modules worden gekoppeld op de drie meetmodules van de hoofdtransfo’s. Intern wordt de controle gedaan op een overschrijding. Deze waarde kan opgevraagd worden via Modbus om te verwerken. In figuur 55 staat zo’n optionele IN/OUT module afgebeeld. Om deze modules in te stellen moet de spanning van de meetmodule even afgelegd worden. Daarna kan de meetmodule geprogrammeerd worden volgens eigen wensen. Om de configuratie goed te laten verlopen zijn twee handleidingen nodig namelijk de handleiding van de meetmodule en de IN/OUT module. Deze bevinden zich in de bijlage.

figuur 55: IN/OUT module

Normaal kunnen deze modules de laatste tien alarmen onthouden. Deze waardes zijn ook uit te lezen via Modbus maar dit is enkel mogelijk bij de nieuwere meetmodules en niet bij de Diris Ap meetmodules. Daarnaast is het mogelijk om een contact aan te sluiten op een uitgang van deze IN/OUT module. Dit contact is momenteel niet gebruikt maar kan wel later geïmplementeerd worden. Op deze manier kan via een lampje aangegeven worden als de spanning te laag of te hoog is. Dit contract zou ook gekoppeld kunnen worden op het domoticasysteem zodat een waarschuwing kan verstuurd worden via e-mail of SMS. Het zal in dit geval niet mogelijk zijn om de waarde mee te sturen. De mappingparameters van de IN/OUT module staan in de handleiding van de communicatiemodule en bevindt zich in de bijlage. Omdat er geen waardes onthouden worden, moet een tussenoplossing gezocht Uitbreiden van domoticasysteem in een distributiebedrijf

50

worden. Deze bestaat erin om na iedere uitlezing van een meetmodule, één van de drie hoofdtransfo’s uit te lezen. Daarbij wordt enkel de actuele waarde van de foutmelding opgevraagd en als deze verschillend is van nul wordt de waarde verzonden via een KNX/IP-telegram. Op deze manier worden de drie modules maximaal om de drie seconden uitgelezen. Deze tijd is experimenteel vastgesteld maar is meestal zeer klein en een tijd van drie seconden is eerder uitzonderlijk. Eens de waardes in de vorm van een KNX/IP-telegram in de FacilityServer zitten, kan een e-mail of SMS verzonden worden met een waarschuwing.

7.7. Besluit Na de studie van alle mogelijkheden omtrent het energiebeheersysteem is een opstelling gerealiseerd die in staat is om de spanningen, stromen en driefasig actueel vermogen te monitoren en bewaken. Daarnaast is het mogelijk om iedere maand een e-mail met de meterstanden te zenden naar de verantwoordelijke. Het systeem is ook voorzien om uitbreidingen toe te staan. In het bedrijf zijn veel elektrische kasten voorzien van een Diris meetmodule maar nog niet allemaal. In de toekomst kunnen deze zeker nog geïmplementeerd worden in het systeem. Het energiebeheersysteem biedt voor het bedrijf een zeer grote meerwaarde want nu is het mogelijk om de energie contant te bewaken. Als er ergens iets fout gaat, worden de nodige personen tijdig verwittigd. Daardoor kan snel ingegrepen worden om de fouten te verhelpen. Als bijvoorbeeld een andere installatie een foutmelding geeft en er komt tegelijk ook een foutmelding van het energiebeheersysteem dan is de kans groot dat er iets elektrisch niet juist is. Op deze manier moet niet ver meer gezocht worden naar de oorzaken van het niet falen van de andere installatie. Dit kan een grote tijdsbesparing betekenen voor het personeel dat de foutmeldingen afhandelt. De gebruiker kan ook na een foutmelding ook de archieven op verschillende manieren opvragen. Op deze manier is het mogelijk om gelijk waar, op gelijk welk toestel in het bedrijfsnetwerk de gegevens te raadplegen. Dit kan een toestel zijn met een internetbrowser of een toestel waarop de client-applicatie geïnstalleerd is.


51

8

Modbus

8.1. Algemeen Modbus is een veelvoudig toegepast industrieel communicatieprotocol dat ontworpen is in Amerika door Group-Modicon. Dit protocol beschrijft enkel laag zeven van het OSI-model, namelijk de applicatielaag. In figuur 56 is het groene gedeelte de applicatielaag. Uit dezelfde figuur blijkt dat de onderste twee lagen vrij in te vullen zijn. Zo bestaan er verschillende implementatiemogelijkheden, deze zijn Modbus+, het master/slave principe en Modbus TCP. Maar er kan ook gekozen worden voor een eigen invulling van de onderste twee lagen. Het meest toegepast is het master/slave principe dat met RS232 of RS485 werkt. De laatste jaren is ook het Modbus TCP protocol aan een opmars bezig omdat dit stilaan meer en meer ondersteund wordt door de fabrikanten. In figuur 56 is ook duidelijk dat Modbus TCP niet enkel meer uit de bovenste en twee onderste lagen van het OSI model bestaat. Het bericht moet geïmplementeerd worden over de TCP/IP-stack waardoor er meer lagen van het OSI model gebruikt worden.

figuur 56: Modbus communicatie stack

8.2. Applicatielaag 8.2.1. Protocol Het Modbus protocol wordt in de applicatielaag beschreven en bestaat uit een eenvoudig Protocol Data Unit (PDU) en is te zien op figuur 57. De PDU is onafhankelijk van de onderliggende lagen en bestaat uit een veld met de functie code en het dataveld. Als een PDU verstuurd wordt over een medium is het nodig om nog enkele extra velden toe te voegen. Alles samen vormt dan de Applicatie Data Unit (ADU), te zien op figuur 57. Deze aanvullingen zullen afhangen van de fysische laag en worden verder in de tekst besproken.

figuur 57: Algemeen Modbus frame

de communicatie is gebaseerd op het client server model. De client bouwt een PDU bericht op en aan de hand van de functiecode weet de server welke actie er ondernomen moet worden met de data. Het initiatief ligt dus bij de client. De functiecode wordt voorgesteld door één byte wat betekent dat er 255 unieke codes mogelijk Uitbreiden van domoticasysteem in een distributiebedrijf

52

zijn. Maar niet alle codes worden gebruikt als geldige code, zo is de code nul niet geldig en de range van 128 tot 255 is gereserveerd voor foutafhandeling. Als er communicatie plaatsvindt van client naar server, dan bevat het dataveld extra gegevens die nuttig zijn bij de meegestuurde functiecode. Dit kunnen gegevens zijn zoals registeradressen, het aantal items in het register waarvoor de actie geldig is en het aantal data bytes. Het is mogelijk dat het data veld leeg blijf want in sommige gevallen volstaat het om enkel de functiecode door te sturen. Als de server het bericht ontvangen heeft, zal hij de actie uitvoeren die beschreven staat in het bericht. Hierna verzendt de server een antwoord naar de client. Dit antwoord bestaat uit dezelfde functiecode als in de request en een dataveld met de gevraagde data. In figuur 58 staat de standaard communicatie schematisch voorgesteld. Als de server een fout ontdekt in de functiecode of in het dataveld van de request, dan kan deze een foutbericht sturen naar de client zoals te zien is op figuur 59. Een fout kan ook resulteren in een time-out. Hoe de fouten afgehandeld worden, hangt af van de client-applicatie en wordt niet beschreven in het protocol.

figuur 58: Standaard Modbus communicatie

figuur 59: Fout bij Modbus communicatie

De grootte van de Modbus PDU is bepaald bij de eerste implementatie, dit was met RS232/RS485. Het maximum aantal bytes op dit medium is vastgelegd op 256, dit slaat op de grootte van het ADU frame. Voor het PDU frame blijven er nog 253 bytes over als er één byte server adres en twee byte foutcontrole worden afgetrokken. Het protocol beschrijft dat het PDU frame, ongeacht het medium, maximaal 253 bytes groot mag zijn. Het is wel zo dat de maximale grootte van het ADU frame niet vast ligt, want dit hangt af van de implementatie. Er kan dus besloten worden dat Modbus een zeer eenvoudig protocol is met een functiecode en data die meegestuurd worden. Uit het voorgaande moet duidelijk zijn dat er maar drie mogelijke PDU’s bestaan, een vraag (request), een antwoord (response) en een foutmelding die tevens een antwoord (response) is.

8.2.2. Datamodel Het datamodel van Modbus is gebaseerd op vier types tabellen die elk hun eigenschappen hebben. Tabel 7 toont een overzicht van al deze tabellen. Dit wil niet zeggen dat in het toestel zelf die structuur ook terug te vinden is. De structuur waar de data in opgeslagen zit van het toestel is fabrikantspecifiek maar om te kunnen communiceren via Modbus moet de data ingedeeld worden volgens het datamodel. Iedere tabel kan tot 65536 Uitbreiden van domoticasysteem in een distributiebedrijf

53

data items bevatten, die elk apart geadresseerd kunnen worden. Dit zal later als het startadres gedefinieerd worden en is twee bytes lang. De functiecode zal bepalen welke tabellen er aangesproken worden en welke actie er zal ondernomen worden: lezen of schrijven. De mapping van het Modbus datamodel met het toestel is volledig afhankelijk van de fabrikant. Figuur 60 toont duidelijk hoe het datamodel opgebouwd is en ook dat de mapping afhangt van het gebruikte toestel. Het is dus perfect mogelijk om twee dezelfde toestellen met verschillende mapping met elkaar te laten communiceren via Modbus. De plaats in het Modbus data model moet dan wel gekend zijn. tabel 7: datamodel van Modbus

Tabel Discretes input Coils Input registers Holding registers

Datatype 1 bit 1 bit 16 bit woord 16 bit woord

Toegang Alleen lezen Lezen en schrijven Alleen lezen Lezen en schrijven

figuur 60: Datamodel Modbus

8.2.3. Functiecodes Er zijn drie soorten functiecodes beschikbaar. Een eerste zijn de publieke functies die beschikbaar zijn voor iedereen en beschreven staan in de Modbus standaard. De publieke functies zijn gegarandeerd uniek en zullen ten allen tijde werken. Een tweede soort kunnen door de gebruiker gedefinieerd worden, hierbij bestaat de kans dat de code niet meer uniek is en niet meer ten allen tijde zal werken. De derde soort functiecodes zijn gereserveerd en zijn niet beschikbaar voor regulier gebruik. Dit zijn codes die toegekend zijn aan specifieke fabrikanten. In deze tekst worden enkel de publieke functiecodes nader toegelicht omdat dit de belangrijkste functiecodes zijn. In figuur 61 is een overzicht gegevens van alle mogelijke publieke functiecodes. De belangrijkste groep zijn de functiecodes bij ‘data access’. Er kunnen zowel lees- als schrijfacties ondernomen worden afhankelijk van de gebruikte functiecode. Soms kan het zijn dat er sub-codes gedefinieerd zijn maar hierop wordt niet verder ingegaan.


54

figuur 61: Publieke functiecodes

In deze masterproef worden enkel waardes uitgelezen die zich in de holding registers bevinden, daarom zal enkel functiecode 03 verder toegelicht worden. Voor meer informatie over de andere functiecodes wordt verwezen naar de Modbus standaard. [2]

8.2.3.1. Functiecode 03 Deze functiecode wordt gebruikt voor het uitlezen van de holding registers van een toestel dat gekoppeld is op Modbus. De functiecode in de request-PDU moet drie zijn, het dataveld moet ingevuld worden met respectievelijk het startadres van het register en het aantal registers dat uitgelezen moet worden. Bij het kiezen van het startadres en de aantal registers is het belangrijk rekening te houden dat één register bestaat uit één woord ofwel twee bytes. De data uit het register wordt dan verzonden per byte in een response-PDU. De eerste byte bevat de meest significante bits en de tweede byte de minst significante bits. In tabel 8 wordt een request-PDU beschreven met alle maximale en minimale waardes. In tabel 9 is een response-PDU weergegeven met alle mogelijke waardes. In tabel 10 staat de inhoud van een foutbericht bij functiecode 03 en in figuur 62 toont in welke volgorde de fouten opgespoord worden. Een foutbericht bestaat uit een vaste code gevolgd door een beschrijving van een fout type. tabel 8: Request bij functiecode 03

Beschrijving Functiecode Startadres Aantal registers

Aantal bytes 1 byte 2 bytes 2 bytes

Waarde (dec) 3 0 tot 65535 1 tot 125

tabel 9: Response bij functiecode 03

Beschrijving Functiecode Aantal bytes Register waardes

Aantal bytes 1 byte 1 byte Aantal registers uit request x 2 bytes

Waarde (dec) 3 2 x aantal registers uit request Data uit registers

tabel 10: Foutbericht bij functiecode 03

Beschrijving Fout code Fout type

Aantal bytes 1 byte 1 byte

Waarde (dec) 131 1, 2, 3 of 4


55

figuur 62: Foutafhandeling bij functiecode 3

8.3. Datalinklaag 8.3.1. Algemeen De datalinklaag van Modbus ligt niet eenduidig vast, er kan gekozen worden tussen seriële communicatie over RS232 of RS485, ethernet of Modbus +. De eerste implementatie gebeurde met seriële communicatie en later zijn de twee andere varianten gevolgd. In deze masterproef wordt enkel gebruik gemaakt van seriële communicatie over RS485, daarom zal enkel deze implementatie besproken worden. Alhoewel de opmars van ethernet niet verwaarloosd mag worden. Bij al deze implementaties komt het erop neer om het Modbus PDU frame te verpakken zodat het frame foutloos en op een correcte manier bij de ontvanger toekomt. In de applicatielaag staat beschreven dat het Modbus PDU frame niet voldoende is om te kunnen communiceren. De datalinklaag beschrijft de aanvullende velden om die communicatie wel mogelijk te maken. In het geval van seriële communicatie is dit een slave adres en een checksom. Figuur 63 stelt een Modbus ADU frame voor waarin het PDU frame ‘verpakt’ zit.

figuur 63: Invulling van Modbus ADU frame volgens seriële communicatie

8.3.2. Adressering Het Modbus protocol over seriële communicatie beschrijft het master/slave principe. Er kan maar één master zijn die communiceert met meerdere slaves op eenzelfde netwerk. In geen enkel geval kunnen de slaves onderling met elkaar communiceren want de communicatie wordt gestart vanuit de master. De master kan maar met één slave tegelijk communiceren en kan maar met één Modbustransactie bezig zijn. Het is niet mogelijk om meerdere requests tegelijk te versturen, dit is op figuur 64 duidelijk zichtbaar. Maar er is één Uitbreiden van domoticasysteem in een distributiebedrijf

56

uitzondering want bij een multicastbericht worden alle slaves aangesproken. De slaves moeten deze actie aanvaarden en geen antwoord meer terug sturen. Op figuur 65 is een multicastbericht weergegeven.

figuur 64: Modbus request/reply bericht

figuur 65: Modbus multicastbericht

Het is duidelijk dat in normale werking de master steeds zijn slaves cyclisch zal afvragen, daarom is het nodig om iedere slave van een uniek adres te voorzien. Op deze manier wordt de slave een uniek toestel voor de master. Het adres bestaat uit één byte, wat resulteert in 255 mogelijke adressen. Het adres nul is het multicast adres en mag niet worden gebruikt, de adressen 248 tot 255 mogen ook niet worden gebruikt omdat deze gereserveerd zijn. Een slave krijgt dus een adres van één tot 247 binnen eenzelfde netwerk. Dit legt meteen ook het maximum aantal slaves in één netwerk vast. De master heeft geen adres nodig doordat de slaves antwoorden met hun adres en de functiecode, hieruit kan de master afleiden van wie het bericht komt.

8.3.3. Transmissie mode De transmissie mode beschrijft de manier van verzenden over de fysische laag. Hierin staat beschreven hoe de datapakketjes ‘verpakt’ worden op het medium. Voor Modbus over seriële communicatie zijn er twee mogelijkheden, Modbus RTU of Modbus ASCII. Modbus RTU is de standaard maar in sommige toepassingen is Modbus ASCII beter. Ieder toestel op eenzelfde netwerk moet dezelfde transmissie mode hebben, anders zal de communicatie niet mogelijk zijn.

8.3.3.1. Modbus RTU In deze transmissie mode worden elke acht bits in een bericht voorgesteld als twee, vier bit hexadecimale karakters. Dit betekent dat de eerste en de laatste vier bits elke een hexadecimaal getal voorstellen in één karakter. Een karakter is elf bits groot en bestaat uit een startbit, acht data bits, één bit voor pariteit en één stopbit. Dit is te zien op figuur 66. De minst significante bit van de data bits wordt eerst verzonden. Voor de pariteit kan gekozen worden tussen even pariteit, oneven pariteit of geen pariteit. Als er geen pariteit gekozen is, moet het bericht twee stopbits bevatten. Zo blijft de lengte van elf bits behouden zoals de standaard dit voorschrijft. Elke frame wordt in een continue stroom van karakters verzonden over het medium.


57

figuur 66: Modbus RTU karakter

Het laatste onderdeel van een Modbus RTU frame is de error detectie en wordt ingevuld door een 16 bits CRC check om het dataframe te controleren op juistheid. In figuur 67 is het volledige Modbus RTU frame te zien.

figuur 67: Modbus RTU frame

Er is al beschreven hoe een karakter en een frame opgebouwd zijn in Modbus RTU. Maar hoe zal een toestel het verschil zien als meerdere frames na elkaar verzonden worden? Het antwoord op deze vraag is terug te vinden in figuur 68. De tijdsbalk is ingedeeld in verschillende tijdsloten waarbij de lengte zal afhangen van de baudrate van het toestel. In elke van deze kleine tijdsloten verzendt een toestel één karakter over het netwerk, dit is de karaktertijd. De karakters binnen één frame moeten elkaar opvolgen binnen anderhalve karaktertijden. Indien de karaktertijd groter is, wordt het bericht als fout aanzien. De tijd voor en na één frame bedraagt minimum drie en een half karaktertijden.

figuur 68: Modbus RTU timing

8.3.3.2. Modbus ASCII In deze transmissie mode worden elke acht bits voorgesteld door twee ASCII karakters. Deze methode is minder efficiënt in vergelijking met de Modbus RTU omdat er twee keer meer karakters nodig zijn. Desondanks het grote nadeel wordt deze methode in specifieke gevallen gebruikt. Een karakter is 10 bits groot en bestaat uit een start bit, zeven data bits, één bit voor pariteit en één stopbit, dit is te zien op figuur 69. De minst significante bit van de data bits wordt eerst verzonden. Voor de pariteit kan gekozen worden voor even pariteit, oneven pariteit of geen pariteit. Als er geen pariteit gekozen is, moet het bericht twee stopbits bevatten. Zo blijft de lengte van 10 bits behouden zoals de standaard dit voorschrijft. Elke frame wordt in een continue stroom van karakters verzonden over het medium.

figuur 69: Modbus ASCII karakter

Een Modbus ASCII frame bestaat uit meer velden dan een Modbus RTU frame. Aan het begin en het einde van elke frame wordt een starten eindveld gedefinieerd. Het startveld is het ASCII karakter “:” en het eindveld Uitbreiden van domoticasysteem in een distributiebedrijf

58

bestaat uit twee ASCII karakters namelijk een “carriege return” en een “line feed”. Hierdoor heeft een karakter een gekend starten stopteken. Merk op dat de andere ASCII karakters enkel in de range van 0h tot Fh liggen. Dit heeft als gevolg dat de tijd tussen twee karakters kleiner moet zijn dan de time-out tijd, die zelf in te stellen is. Zo is duidelijk dat Modbus ASCII ook voordelen heeft. Het veld na de data van een Modbus ASCII frame is de error detectie en wordt ingevuld door een LRC check om het ganse frame te controleren op juistheid. De LRC check is één byte lang en wordt dus voorgesteld als twee ASCII karakters. In figuur 70 is het volledige Modbus ASCII frame te zien.

figuur 70: Modbus ASCII frame

8.4. Fysische laag Voor Modbus met seriële communicatie zijn twee elektrische interfaces gedefinieerd, RS232 en RS485. Het is dus mogelijk om een punt-tot-punt verbinding of een busstructuur op te bouwen. Standaard moet een kabel met twee signaaldraden voorzien zijn en een shield voor de aarding. In figuur 71 is de algemene structuur van een Modbus netwerk afgebeeld. Alle toestellen kunnen zenden en ontvangen over hetzelfde medium, het is ook mogelijk om vier signaaldraden te voorzien. Het eerste paar is voor berichten van master naar slave, het tweede paar is voor berichten van slave naar master. De baudrate is vrij te kiezen maar er zijn twee veel gebruikte standaarden 9600 bps en 19200 bps.

figuur 71: busstructuur Modbus met seriële communicatie

De RS232 interface wordt minder toegepast omdat dan enkele een punt-tot-punt verbinding mogelijk is waar de lengte beperkt blijft tot twintig meter. De RS485 interface wordt meer toegepast, want dan kunnen er meer toestellen aangesloten worden. De lengte is beperkt tot 1200 meter en er kunnen maximaal tweeëndertig toestellen aangesloten worden. Als dit nog niet voldoende is, kunnen versterkers zorgen voor een koppeling van meerdere Modbus subnetwerken. De bus bestaat uit een twisted-pair kabel die voorzien is van een shield en is voorzien van twee afsluitweerstanden van 120 ohm. Voor de mechanische interface zijn drie mogelijkheden: een RJ45 connector, een sub D9 connector en schroefklemmen. Hoe de aansluiting gebeurt, is afhankelijk van de gebruikte kabel maar kan met een twee of vier aderige signaaldraad uitgevoerd worden. Daarvoor wordt verwezen naar de bijlage van het gebruikte toestel. Het is altijd belangrijk om de polariteit van de bus te controleren. In tabel 11 staan de aanbevolen kleurencodes voor een RS485 Modbus kabel.


59

tabel 11: Aanbevolen kleurencode voor RS485 Modbus kabel


60

9

KNX

9.1. Inleiding KNX is de nieuwste wereldwijde, open standaard voor gebouwenautomatisering en is erkend door verschillende internationale standaarden. De KNX-associatie garandeert dat alle gecertificeerde KNX-producten compatibel zijn met elkaar. Dit wil zeggen dat KNX een fabrikant onafhankelijke standaard is. De KNX-standaard is gepubliceerd in het voorjaar van 2002 en is een samenraapsel van drie andere standaarden, namelijk Batibus, EIB en EHS. De meeste specificatie zijn overgenomen van het Duitse EIB, aangevuld met de nieuwe configuratiemechanismen en transmissiemedia van Batibus en EHS. In 1997 zijn deze drie consortiums gefuseerd om samen aan een industriële standaard voor gebouwenautomatisering te werken. In november 2006 is KNX erkend als open internationale standaard als ISO/IEC 14543-3-X voor gebouwenautomatisering, bestaand uit vier transmissiemedia. De vier transmissiemedia zijn twisted-pair, powerline, radiofrequentie en IP. Figuur 72 toont het logo van KNX.

figuur 72: KNX logo

9.2. Open standaard Volgens de standaard worden alle sensoren en actoren op een netwerk aangesloten zodat alle deelnemers fysisch verbonden zijn met elkaar. De beslissing om een bericht te zenden ligt bij de sensoren, de actoren zullen reageren als het nodig is. Er is dus geen centrale eenheid nodig om te kunnen communiceren waardoor de bedrijfszekerheid stijgt. In figuur 73 staat een schematische voorstelling van de KNX bus, op de figuur wordt deze aangeduid met EIB. Dit heeft te maken met de vele gelijkenissen tussen de vroegere EIB bus en de huidige KNX bus.

figuur 73: KNX bus


61

De KNX standaard biedt zeer veel mogelijkheden en heeft ook veel voordelen door het open protocol. Zo heeft de gebruiker de zekerheid van een lange termijngarantie en er zal altijd een breed productengamma bestaan van verschillende fabrikanten. De associatie heeft ook een fabrikanten onafhankelijke configuratiesoftware ontwikkeld zodat alle KNX producten geconfigureerd kunnen worden. Dit softwarepakket heet ‘ETS’ waarvan de laatste versie ‘ETS4’ heet. Dit is voor een configuratie met een computer en is de meest geavanceerde manier van configureren. Dit wordt de ’S-Mode’ genoemd, daarnaast bestaan nog twee andere configuratie modes die eenvoudiger zijn. Bij de ‘E-mode’ wordt de configuratie gedaan met een controller en bij de ‘Amode’ bestaat de configuratie uit ‘plug & play’. Deze laatste mode is de meest eenvoudige manier van configureren. Om zo veel mogelijk gebruikers te kunnen bereiken zijn vier verschillende communicatiemedia geïmplementeerd in de standaard. Een eerste is via een klassieke ‘twisted-pair’ netwerk waarbij twee draden gebruikt worden voor communicatie en twee voor een optionele voeding. Een tweede communicatiemedium is ‘powerline’ waarbij de signalen voor communicatie op de bestaande elektrische bekabeling geplaatst worden. Het derde communicatiemedium bestaat uit draadloze communicatie over radiofrequentie. Als laatste bestaat de mogelijkheid om te communiceren over de ethernetkabel. Met deze vier communicatiemedia kan de standaard voor zeer veel toepassingen een oplossing bieden.

9.3. Systeemstructuur Het meest toegepaste en het belangrijkste transmissiemedium is twisted-pair, daarom zal enkel deze implementatie verder toegelicht worden. De andere implementaties maken gebruik van bestaande systeemstructuren zoals een bedrijfsnetwerk of het lichtnet. De implementatie met radio frequentie wordt meestal toegepast als een uitbreiding op een bedraad netwerk. Op deze manier kunnen moeilijk bereikbare plaatsen toch bereikt worden. In deze toepassing wordt meestal één access-point aangesloten op een bedraad netwerk dat dan communiceert met de draadloze sensoren en actoren.

9.3.1. Topologie Een KNX-netwerk kan op een zeer flexibele manier opgebouwd worden omdat er zowel een boom-, lijn- als stertopologie toegestaan is. In figuur 74 wordt een KNX-netwerk afgebeeld met de drie topologieën in verwerkt. Dit biedt voor de gebruiker veel flexibiliteit omdat de gebouwenstructuur weinig beperkingen oplegt aan de bekabeling. Tijdens het bekabelen moet er steeds nagegaan worden als nergens een ringstructuur is ontstaan. Dit zal zorgen voor een slechte werking van het volledige systeem. Om de goede werking van de bus te garanderen moet enkele afstanden gerespecteerd worden. De maximale lengte van een lijn, inclusief de aftakkingen bedraagt één kilometer. Tussen twee deelnemers mag maximaal 700 meter zitten om geen problemen te hebben. Per lijn moet ook een voeding voorzien worden, de afstand tussen de voeding en een deelnemer mag maximaal 350 meter bedragen. Er wordt ook aangeraden om de voeding in het midden van de lijn te plaatsen zodat de uiterste deelnemers nog voldoende spanning hebben.


62

figuur 74: KNX bustopologie

9.3.2. Niveaus Een KNX-netwerk zal meestal geïmplementeerd worden in een gebouw. Om de implementatie zo overzichtelijk mogelijk te houden is de systeemstructuur opgedeeld in verschillende niveaus. Er bestaan drie niveaus namelijk lijnen, hoofdlijnen en een backbone. Het laagste niveau bestaat uit een lijn zoals afgebeeld op figuur 75. Op iedere lijn is een voeding aangesloten voor de busvoeding, daarnaast is het mogelijk om maximaal vierenzestig deelnemers aan te sluiten. De lijn wordt opgebouwd zoals beschreven staat in het bovenstaande puntje ‘Topologie’. Omdat vierenzestig toestellen niet veel is, kunnen meerdere lijnen toegevoegd worden in een KNXnetwerk. Dit staat afgebeeld op figuur 76 en beschrijft het middelste niveau, namelijk een hoofdlijn. Door maximaal vijftien lijnen te koppelen aan één hoofdlijn via een lijnkoppelaar wordt een KNX-netwerk uitgebreid. Op de hoofdlijn moet ook altijd een voeding toegevoegd worden. Het is dus mogelijk om maximaal vijftien maal vierenzestig toestellen te koppelen op een KNX-netwerk. Als dit nog niet voldoende is, kunnen er verschillende hoofdlijnen aan elkaar gekoppeld worden tot één zone die gekoppeld is op de backbone. Dit is te zien op figuur 77. Er kunnen maximaal vijftien zones gekoppeld worden op de backbone. De koppeling gebeurt met een zonekoppelaar en alle zone koppelaars worden aangesloten op de voeding van de backbone. Het is dus mogelijk om maximaal 14400 busdeelnemers aan te sluiten op één KNX-netwerk.

figuur 75: Structuur van een lijn


63

figuur 76: Structuur van een hoofdlijn

figuur 77: Structuur van een backbone

In de meeste gevallen worden enkel de lijnen geïmplementeerd met een twisted-pair kabel. De hoofdlijnen en de backbone worden meestal geïmplementeerd op een bedrijfsnetwerk. De zone- en lijnkoppelaars zijn niet zomaar toestellen die berichten doorgeven aan de verschillende niveaus. Deze toestellen kunnen filtertabellen bezitten om bepaalde berichten niet door te sturen naar andere lijnen of zones. Als dit niet mogelijk is, kan het gebeuren de bus niet meer zal werken omdat er te veel berichten verstuurd moeten worden.

9.3.3. Adressering De KNX-standaard beschrijft twee soorten adressen in hun protocol, een moduleadres en een groepsadres. De moduleadressen geven de fysische actoren en sensoren elk hun eigen adres en is gebaseerd op de drie niveaus in een KNX-netwerk. Dit adres bestaat uit drie cijfers die gescheiden zijn met een punt, bijvoorbeeld ‘1.2.3’. Uit het adres kan de locatie van de module achterhaald worden. Het voorbeeldadres is voor module drie in de tweede lijn van de eerste zone. Het eerste cijfer is dus voor de zone, het tweede cijfer voor de hoofdlijn en het derde cijfer voor het nummer van de module. Dit adres wordt enkel gebruikt om instellingen naar de module te Uitbreiden van domoticasysteem in een distributiebedrijf

64

downloaden tijdens de installatiefase. Het tweede adres is het groepsadres dat geen fysische betekenis heeft. Een groepsadres beschrijft een bepaalde functie en koppelt sensoren aan actoren. Een sensor heeft één uniek groepsadres. Als een telegram moet verstuurd worden dan wordt het groepsadres meegestuurd als bestemmingsadres. De actoren hebben een lijst waar verschillende groepsadressen in staan. Als een telegram wordt verzonden met één van die groepsadressen weet de actor dat dit bericht voor hem bestemd is. De groepsadressen zijn onafhankelijk van een moduleadres. Als een module niet meer werkt, kan deze vervangen worden door een andere module met eventueel een ander moduleadres. Het is niet nodig om de groepsadressen te wijzigen maar deze moeten wel gekoppeld worden aan de nieuwe module. Groepsadressen bestaan uit drie cijfers gescheiden door een ‘/’, bijvoorbeeld ‘1/2/3’. Het eerste getal beschrijft de hoofdgroep, het tweede beschrijft een subgroep en het derde beschrijft een groep. De groepen moeten aangemaakt worden naar functies. Een hoofdgroep kan bijvoorbeeld de verlichting zijn, een subgroep kan de verlichting in de keuken zijn en een groep kan één specifieke lamp zijn.

9.3.4. Programmatie De programmatie van een KNX-netwerk gebeurt aan de hand van de fabrikanten onafhankelijke software ‘ETS’. Dit softwarepakket is ontwikkeld door de KNX-associatie om al het nodige te configureren in een KNX-netwerk. Bij het toevoegen van een module moet eerst een moduleadres toegekend worden. Door de module in programmeertoestand te plaatsen kan de module gedetecteerd worden. In ‘ETS’ kan nu het moduleadres gedownload worden naar de module. Daarna moeten de beschikbare KNX-telegrammen van de module gekoppeld worden aan goed uitgekozen groepsadressen. Bij sommige modules moeten nog andere instellingen geconfigureerd worden. Hierna kunnen alle instellingen en groepsadressen naar de module gedownload worden met ‘ETS’. Om de module te bereiken zal ‘ETS’ gebruik maken van het moduleadres. Op deze manier moet een module geïmplementeerd worden in een KNX-netwerk. De laatste versie van het softwarepakket ‘ETS’ is sinds oktober 2010 beschikbaar en heet ‘ETS4’, het logo is te zien op figuur 77. ‘ETS4’ is beschikbaar in verschillende versies waarbij de functionaliteiten van de lagere versies beperkt worden. De volledige versie heet ‘ETS4 professional’ en bevat alle functionaliteiten.

figuur 78: Logo ETS4


65

10 Litteratuurlijst [1] Wago Kontakttechnik. Wago [ON LINE]. http://www.wago.com/wagoweb/documentation/app_note/libdoku/ml01101e.pdf (datum van opzoeking: 21/12/2010) [2] Modbus Organization (2005-2010). Modbus [ON LINE]. http://www.Modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf (datum van opzoeking: 23/09/2010) [3] Modbus Organization (2005-2010). Modbus [ON LINE]. http://www.Modbus.org/docs/Modbus_over_serial_line_V1_02.pdf (datum van opzoeking: 23/09/2010) [4] Wago Kontakttechnik. Wago [ON LINE]. http://www.wago.com/cps/rde/xchg/wago/style.xsl/nlb-index.html (datum van opzoeking: 09/08/2010) [5] SOCOMEC. Documentation SOCOMEC [ON LINE]. http://www.socomec.com/webdav/site/Socomec/shared/DOCUMENTATION/SCP_hors_cata/doc_116012B.pdf (datum van opzoeking: 09/08/2010) [6] VDAB, Domotica-gebouwenautomatisering EIB-Basis, editie januari ’97, p 1-140


66

Voorwoord. Uitbreiden van domoticasysteem in een distributiebedrijf

Recommend Documents