Al sinds de middeleeuwen is Antwerpen een belangrijke haven en vinden schepen hun weg tot ver op de Schelde. De laatste 5 eeuwen heeft Antwerpen zich ontwikkeld van rivierhaven tot wereldhaven en hebben ze zichzelf doorheen de tijd op de kaart gezet.
Het totale havengebied is goed voor 150.000 jobs, samen werken ze aan de motor van de Belgisch economie. Iedereen heeft zijn eigen taak binnen dit geheel. Het grote deel van deze mensen werkt voor één van de 900 privé bedrijven. Deze kan je onderverdelen van grote chemiereuzen tot kleinschalige bedrijven.
Figuur 1.1 havenkaart Antwerpen
Enkele indrukwekkende cijfers; een oppervlakte van 20.000 voetbalvelden, 400 km wegen, 1.000 km spoorrails, 1.000 km pijpleiding, 8 sluizen, 157 kilometer kade, 48 dokken en 25 bruggen.
1.3 Havenbedrijf Antwerpen
Het Havenbedrijf Antwerpen nv van publiek recht ofwel Port of Antwerp speelt een zeer belangrijke rol in de dagelijkse werking van de haven van Antwerpen. Het Havenbedrijf Antwerpen zorgt dagelijks samen met zijn 1.650 medewerkers voor een vlotte werking en verloop van de haven. Het takenpakket is divers en uitgebreid, het beheren en onderhouden van kaaimuren, sluizen, bruggen, dokken, kranen. Ook het inzetten van kranen en sleepboten, verrichten van baggerwerkzaamheden en onderhouden van dienstgebouwen is deel van het takenpakket. Met als belangrijkste hoofddoel het ondersteunen van de scheepsvaart binnen het havengebied Antwerpen.
Het Havenbedrijf Antwerpen beheert een 200 tal dienst gebouwen, zoals: wachthuisjes, controletorens voor de sluizen, datacenter, scheepswerven…
Omdat de taken van dit bedrijf zo uiteenlopend zijn, zijn hier vele beroepen aanwezig. Van boekhoudkundige tot kraanmachinist van promotiemedewerker tot sluiswachter. Samen werken ze aan de toekomst van de Antwerpse haven.
Op 1 januari 2016 werd het Gemeentelijk Havenbedrijf Antwerpen omgevormd naar een NV van publiek recht, “Havenbedrijf Antwerpen”. Op deze manier is het Havenbedrijf Antwerpen NV veel flexibeler op een snel evoluerende maritieme markt.
1.4 Structuur
De structuur van de verschillende diensten en afdelingen van het Havenbedrijf Antwerpen vind je terug in het onderstaande organogram.
Figuur 1.4 organogram Havenbedrijf nv van publiek recht
De plaats waar ik mijn stage zal lopen is te vinden onder de afdeling gebouwen en energie dienst elektriciteit. Zij ondersteunen volgende zaken: elektriciteit in dienstgebouwen (domotica, brand, inbraak, sterk en zwakstroom), hoogspanning, openbare verlichting, walstroom voor zee- en binnenvaart en nieuwbouwprojecten binnen de haven van Antwerpen. Deze afdeling valt onder infrastructuur, ruimtelijke ordening en milieu.
In totaal zijn er een +- 80 gebouwen waar noodverlichting in is geïntegreerd. Deze gebouwen zijn interessant voor de stage die ik loop binnen het bedrijf. In de toekomst zal de uitgewerkte stage ook verwezenlijkt worden op deze gebouwen, namelijk het automatisch loggen van de status van noodverlichting.
(Port of antwerp info, 2016)
1.5 Besluit
Het bedrijf is een zeer belangrijk factor binnen de Antwerpse haven. Ze zorgen voor vele voorzieningen in de haven. Het Havenbedrijf Antwerpen werkt samen met haar werknemers aan de groeiende economie van België.
2 UITWERKEN PROBLEEMSTELLING
2.1 Inleiding
Het Havenbedrijf Antwerpen beschikt over een 80 tal gebouwen waar noodverlichting in is geïntegreerd. Deze visueel elke maand gaan controleren op goede werking en op fouten is onbegonnen werk. Daarom onderzoekt de stage een mogelijkheid tot het automatisch loggen van fouten op noodverlichting samen met een visualisatie op NETx Automation, waaruit een rapportering kan getrokken worden.
De opdracht houdt in de mogelijkheid te bestuderen van deze logging via een systeem dat onafhankelijk is van commerciële systemen die merkt gebonden zijn.
2.2 Achtergrondinformatie
De normen NBN C 71-100 artikel 7.1 en NBN EN 50172 art. 7.1 leggen op dat er een verplichte maandelijkse logging aanwezig moet zijn waaruit de correcte werking van de noodverlichting in een gebouw blijkt. Daarom kiest het Havenbedrijf Antwerpen om de gebouwen onder hun beheer automatisch te gaan loggen op vlak van noodverlichting en waar dit mogelijk is.
De norm schrijft:
• De beheerder (eigenaar/bewoner) is verantwoordelijk voor de goede werking van de installatie.
• De beheerder zal een competent persoon aanduiden die instaat voor de supervisie van het onderhoud van de installatie. Deze persoon moet voldoende bevoegdheden hebben om de werkzaamheden uit te (laten) voeren.
Omdat de eigenaar/bewoner verantwoordelijk is, wordt deze ook strafrechterlijk aansprakelijk gesteld. Omdat het bijhouden van logboeken verplicht is (zie verder) ligt de bewijslast bij de beheerder: hij moet kunnen aantonen dat hij aan zijn verplichtingen heeft voldaan.
(documentatie noodverlichting, 2011)
De norm verwijst naar de verplichting van een automatische of visuele test met het aanvullen van een logboek. Alle fouten die zich in het systeem bevinden zullen hier aanwezig moeten zijn. Bij een automatische test bevat het logboek alle resultaten van deze functietest.
Omwille van de verplichting van het maandelijks controleren, opteert het Havenbedrijf Antwerpen om een automatische noodverlichting logging te voorzien. Een visuele controle elke maand zou namelijk veel te omslachtig zijn omdat de te controleren installaties verspreid liggen over een gigantisch gebied. Een automatische logging vergemakkelijkt dit proces en de operationele kosten dalen hierbij sterk.
2.3 Probleemanalyse
2.3.1 Onderdelen en geschiedenis
In de dienstgebouwen van het Havenbedrijf Antwerpen is noodverlichting aangebracht (een +/- 80 tal gebouwen). Zoals eerder vermeld zal de logging hiervan gerealiseerd worden door een automatische test. Dit zal gebeuren via EIB/KNX door de ABB DALI Gateway Emergency Lighting DGN/S 1.16.1.
2.3.2 Belang
Het gebruik van noodverlichting is vandaag de dag een belangrijk aspect, het veilig verlaten van gebouwen bij noodgevallen heeft prioriteit. Stel een brand voor, samen met een spanningsuitval hierbij kan noodverlichting van levensbelang zijn.
Het duidelijk loggen van de huidige instanties is een actueel punt binnen bedrijven. Het weten welke fout en vooral waar door middel van een logging is belangrijk. Zo ziet men geen fouten over het hoofd en heeft het bedrijf een duidelijke zicht dat de installatie up-to-date is.
2.3.3 Onderwerp
Het maandelijks controleren van noodverlichting is een belangrijk item.
Het monitoren van noodverlichting en hierbij de opgetreden fouten zo snel mogelijk te verhelpen is essentieel.
Een ander belangrijk punt hierbij is dat een visuele controle te omslachtig is en dat de kosten veel hoger uitkomen, de personeelskost om deze controle te verwezenlijken zou hoog oplopen. Het Havenbedrijf Antwerpen beschikt over een 80 tal gebouwen waar deze systemen ingewerkt zijn. Het maandelijks visueel controleren is geen optie. Dus kiezen ze in de toekomst voor een automatische controle voor gebouwen die worden uitgebreid met intelligente noodverlichting.
2.4 Doelstelling
De belangrijkste doelstelling houdt in om in de toekomst de noodverlichting van de gebouwen van het Havenbedrijf Antwerpen te gaan monitoren en loggen op een NETx Automation pakket ofwel het GBS of BMS (gebouwbeheersysteem), waar men de DALI-Noodarmaturen gaat uitlezen en via KNX gaat implementeren in het gebouwbeheerssysteem. Dit via een tijd gestuurde routine zodat deze logging automatisch gebeurd één keer per maand voor alle gebouwen met intelligente noodverlichting. Allereerst in testopstelling via Domotica testbank, waarna uitlezing op de verschillende dienstgebouwen gebeurt. De testresultaten worden door het systeem automatisch verzonden in PDF formaat naar verschillende email-adressen. De ontvangers van dit rapport kunnen dan gepaste acties geven.
2.5 Resultaten
Een systeem uitwerken dat zich gemakkelijk laat kopiëren om te gebruiken voor verschillende gebouwen. Hierdoor zal het gemakkelijk en duidelijk zijn om nieuwe of gerenoveerde gebouwen te voorzien van intelligente noodverlichting met logging. Een duidelijk overzicht waar en welke fout zich er bevindt in het systeem.
2.6 Besluit
Om de veiligheid te allen tijde te garanderen en om te voldoen aan de wettelijke verplichtingen binnen het Antwerpse Havenbedrijf zal er in de nabije toekomst een logging worden verwezenlijkt op de noodverlichting. De resultaten van de maandelijkse testen zullen visueel weergegeven worden op het GBS NETx.
3 PLAN VAN AANPAK
3.1 Inleiding
De stage kan onderverdeeld worden in 3 grote delen, dit verspreid over een 17 weken durende stage.
• Initiatiefase (+/- 5 weken)
• Realisatiefase (+/- 12 weken)
• Evaluatiefase (juni)
De takenlijst en mogelijke knelpunten zullen kort aangehaald worden.
3.2 De verschillende fasen
3.2.1 Initiatiefase
De eerste fase is de initiatiefase, dit houdt in het verkennen van de werkplek, uitwerken van de probleemstelling, het opstellen van de planning, mogelijke knelpunten, enzovoort. Vervolgens zal dit gepaard gaan met het uitwerken van de noodverlichtingslogging via de ABB DALI Gateway met noodverlichtingsfunctie, en het uitwerken van een automatische test die de fouten gecodeerd terugstuurt via de gateway.
3.2.2 Realisatiefase
Dit omvat het verder uitwerken van de noodverlichtingslogging. Als dit uitgewerkt en getest is, volgt er een visualisatie op een GBS van het Havenbedrijf Antwerpen. Zodat er maandelijks mogelijke fouten in de armaturen weergegeven en gelogd worden. Het uitwerken van deze visualisatie zal gebeuren in NETx via de programmeertaal Lua.
De structuur van Lua moet overzichtelijk zijn zodat het in de nabije toekomst eenvoudig wordt om een noodverlichting logging te verwezenlijken op bijkomende gebouwen.
3.2.3 Evaluatiefase
In de laatste fase zal er een evaluatiegesprek doorgaan en bijkomend de eigenlijke presentatie en verdediging van het eindwerk.
3.3 Verloop
In eerste instantie zal er een automatische logging worden verwezenlijkt. Het uitwerken van deze logging zal gebeuren op het testbord, dat voorzien is van de nodige componenten.
in het begin zullen de verschillende mogelijkheden van de DALI gateway worden uitgezocht. De functietesten en duurtesten zullen eerst met de hand getriggerd worden. Via deze testen kunnen de gecodeerde foutmeldingen vertaald worden door middel van hexadecimale en binaire conversies. Na verloop van tijd zullen de testen automatisch verlopen na een eerste opstart. De armaturen gaan de testen doorlopen volgens de ingestelde cycli.
Vervolgens zal het testbord verbonden worden d.m.v. een IPR/S router met de server via een ethernet verbinding. Hierdoor kunnen de gegevens van de testbank naar een GBS gestuurd worden.
Verder zal na de uitwerking van de automatische testen voor de noodverlichting een visualisatie worden voorzien op het GBS. De codes die de gateway terug krijgt van de DALI convertors zullen weggeschreven moeten worden en gememoriseerd worden door NETx (NETx pakket is het GBS). Dit door middel van het schrijven van een script in de programmeertaal Lua.
In een latere fase zal na het uitwerken van de vorige stappen en het uitwerken van het eindwerk. De noodverlichtingslogging met een maandelijkse rapportering geworden toegepast op een bestaand gebouw. Het duidelijk en overzichtelijk uitwerken hiervan is een must. Dit project zal ook mee geïmplementeerd worden in het GBS.
3.4 Mogelijke knelpunten
In de loop van de stage kunnen er enkele knelpunten voorkomen. De bedoeling is hier om zo overzichtelijk mogelijk te werken zodat er geen fouten kunnen optreden.
Een belangrijk knelpunt is het gebruiken van nieuwe toestellen en dan vooral het grote pakket aan nieuwe parameters. De mogelijkheden bij de DGN/S 1.16.1 noodverlichting gateway zijn uitgebreid. Het veelvuldig testen van de mogelijke parameters om zo met het beste resultaat naar buiten te komen is belangrijk.
De visualisatie gebeurt op het NETx pakket van de afdeling gebouwen en energie dienst elektriciteit. De programmatie in het NETx pakket gebeurt via de programmeertaal Lua. Deze taal is een zeer uitgebreide programmeertaal, om dit zo leesbaar mogelijk te houden zal de programmatie zeer overzichtelijk moeten gebeuren en voorzien worden van bijgevoegde commentaar in samenspraak met de dienst elektriciteit.
3.5 Besluit
Het goed opvolgen van de planning en het zo overzichtelijk mogelijk houden van de uitwerking is een belangrijk punt. Zo moet het in de nabije toekomst mogelijk zijn om op eenvoudige wijze de opdracht door te kopiëren naar nieuwe gebouwen en dit door de medewerkers binnen de dienst elektriciteit.
4 REALISATIE INLEIDING
4.1 Inleiding
In dit hoofdstuk zal de volledige realisatie worden uitgewerkt. Naast de uitgewerkte realisatie en de behaalde resultaten, vindt u kort algemene achtergrondinformatie die de stage zal verduidelijken.
4.2 Algemeen
4.2.1 Wat is domotica?
Het woord domotica is afkomstig van het Latijnse woord domus (wat huis betekend), en tica (wat duid op toegepaste wetenschap). Domotica draait niet enkel om het integreren van technieken, maar ook om de dienstverleningen mogelijk te maken vanop afstand.
Domotica is niet te vergelijken met klassieke installaties, bij klassieke installaties bedient men de lamp met de daarbij horende schakelaar. De schakelaar staat hierbij dus steeds onder spanning. Een gewone schakelaar beperkt zich maar tot 1 functie, het aan of uitschakelen van lampen. Moesten er aanpassingen gebeuren of wil de eindgebruiker een lamp met een andere schakelaar bedienen. Dan is hiervoor een aanpassing nodig binnen de installatie, het aanleggen van extra kabels, aanpassingen aan het huis zelf, …
Bij een domotica systeem zijn de verschillende componenten met elkaar verbonden via een bus systeem en zijn de functies van de schakelaar afhankelijk van de programmatie en hardware die erachter zit. De componenten in de installatie communiceren met elkaar door middel van een eigen intelligentie. Omdat het systeem de componenten uit elkaar kan houden wordt elke component onderscheiden d.m.v. een uniek adres.
Op bovenstaande foto is te zien dat bij het klassieke systeem elke schakel component onder spanning blijft staan, pas wanneer de schakelaar/component schakelt geeft hij spanning door. Dit is niet het geval bij domotica. Hier worden de verbruikers onder spanning gezet d.m.v. schakelactors, voorzien van een eigen intelligentie. Elke component, zowel schakelcomponenten als bedieningen zijn verbonden met een EIB/KNX bus. Via deze buskabel zullen de schakelcomponenten communiceren naar de verbruikers via de hardware.
4.2.2 KNX
Knx is de meest gebruikte standaard in de domotica wereld. De knx standaard is een samensmelting van 3 vroegere standaarden; EHS, Batibus en EIB/instabus.
(KNX standaard, 2016)
KNX is een standaard die weergeeft hoe sensoren en actoren met elkaar dienen te communiceren. Deze standaard wordt vooral toegepast bij domotica. KNX Association zorgt ervoor dat verschillende producten kunnen gecertificeerd worden zodat deze samen in één systeem kunnen werken ongeacht de fabrikant.
KNX heeft een zeer brede waaier aan toepassingen, samen met haar 370 KNX-leden en bijna 7000 KNX-producten, zijn ze in staat volgende toepassingen te ondersteunen.
(KNX inleiding, 2016)
Figuur 4.3 KNX standard
4.2.3 Configuratiemodus
Voor de KNX standaard zijn 2 verschillende configuratiemogelijkheden mogelijk:
• E-mode
Deze configuratiemogelijkheid is bedoeld voor mensen met een KNX-basisopleiding, busdeelnemers hebben beperkte functies. Deze functies zijn reeds voorgeprogrammeerd met standaard parameters. De deelnemers kunnen gemakkelijk aangepast worden.
• S-mode
Deze configuratiemogelijkheid is voor ervaren KNX-installateurs, met de S-mode kunnen er uitgebreide gebouwcontrolefuncties gerealiseerd worden. De bestaande componenten in S-mode kunnen geprogrammeerd worden met een gewone software-tool (ETS Professonal). Met ETS kunnen de busdeelnemers geconfigureerd worden met de hoogste graad van flexibiliteit.
(KNX configuratiemodi, 2016)
Figuur 4.4 E-mode en S-mode
4.2.4 Software ETS
Zoals hierboven vermeld is er voor de S-mode een tool nodig, genaamd ETS (Engineering Tool Software). ETS is de software waarmee een KNX systeem kan ontworpen worden. ETS is de standaard software van KNX Association. Via ETS worden unieke adressen (individuele adressen en groepsadressen) toegewezen aan apparaten, en wordt de functie van de schakelaar ingesteld. De verbinding van de ETS software met het domotica systeem kan verwezenlijkt worden door een seriële poort (rs232), een usb verbinding of via ethernet.
ETS bevat een uitgebreide database met alle gecertificeerde KNX apparaten. Komen er nieuwe op de markt dan geven de fabrikanten een daarbij horende EDS (Electronic Data Sheet) of plug-in vrij zodat het apparaat kan ingeladen worden in ETS. Het domotica deel zal uitgewerkt worden met deze software, namelijk ETS4.
4.2.5 Buskabel
Zoals eerder vermeld zijn alle componenten verbonden met elkaar door middel van een EIB/KNX buskabel. Voor KNX is er een onderverdeling van de verschillende mediums, het meest gebruikt is het twisted pair medium (TP). De kabel die wordt gebruikt bestaat uit 4 geleiders die samen getwisted zijn. De rode en zwarte ader zijn de hoofdgeleiders, elke component wordt aan de rood en zwarte geleiders gekoppeld. Dit om de communicatie te kunnen verzekeren. De witte en gele geleiders zijn ‘reserve geleiders’, die kunnen gebruikt worden om extra voeding naar andere speciale componenten te brengen. Sommige componenten in een domotica systeem hebben extra 30V DC voeding nodig, zoals de IP-router.
Figuur 4.5 EIB/KNX buskabel
Er zijn verschillende manieren mogelijk hoe de componenten onderling in verbinding staan met elkaar. We maken een onderscheid tussen lijn-, ster- en boomstructuur.
Figuur 4.6 lijn-, ster- en boomstructuur
De groene EIB/KNX buskabel heeft een snelheid van 9600 bits/s.
Buiten de TP bestaan er nog enkele andere manieren hoe componenten met elkaar in verbinding kunnen staan.
• Verbinding met power line (verbinding over het lokale elektriciteitsnet)
• RF (draadloze radio frequentie)
• IP (verbinding over het lokale netwerk)
(KNX communicatiemedia, 2016)
4.3 Werking domotica
Vooraleer we aan de werking komen moeten er enkele zaken verduidelijkt worden.
4.3.1 Topologie
4.3.1.1 Individuele adressen
Elke deelnemer die aangesloten wordt op de bus krijgt een uniek adres. Het adres dat hier aan de componenten gegeven wordt noemt men het individueel adres. Hiermee worden de verschillende componenten door het systeem herkend. Enkele richtlijnen binnen de KNX topologie:
• Maximum 64 deelnemers per lijn (0 tot 63).
o Met toepassing van lijnversterkers 255 deelnemers mogelijk.
• Maximum 15 lijnen per zone.
• Maximum 15 zones.
• Maximum 700 meter tussen 2 componenten op dezelfde lijn.
• Maximum 350 meter tussen een voedingen en een busdeelnemer.
• Minimum 200 meter afstand tussen 2 voedingen op één lijn
De EIB norm schrijft voor dat er reserves moeten voorzien worden per lijn. De voedingen die gebruikt worden hebben een waarde van maximaal 640 mA, dit wil zeggen dat elke bus deelnemer gemiddeld 10 mA mag verbruiken bij een installatie met 64 deelnemers. Indien er deelnemers worden gebruikt met een groter verbruik (bv. display) dan kunnen er minder deelnemers aangestuurd worden op deze voeding.
Bij de lijnen begint het adres met 2. Plaats 0 is immers ingenomen door de lijnkoppelaar en plaats 1 is ingenomen door een intelligente voeding.
4.3.1.2 Toekennen individueel adres
Het individueel adres is dus de naam van de componenten. Het adres ziet er als volgt uit.
ZONE . LIJN . DEELNEMER
ZZZZ . LLLL . DDDDDDDD
• Z: De linkse 4 bits (ZZZZ) verwijzen naar de zone waar ze zich in bevinden. Deze kan een waarde bevatten tussen “0 en 15”. Met 4 bits kunnen er 16 combinaties gemaakt worden. Adres 0 is echter niet toegelaten.
• L: Middelste 4 bits (LLLL) verwijzen naar de lijn waaraan ze verbonden zijn. Hier ook weer tussen “0 en 15”. Met 4 bits kunnen er 16 combinaties gemaakt worden. Adres 0 is echter niet toegelaten.
• D: Deze 8 bits verwijzen naar de deelnemer zelf (DDDDDDDD). 8 bits maken hier maximum het getal 255 (8 bits = max. 256 mogelijkheden van 0 tot 255). 64 deelnemers kan je uitbreiden naar 255 door middel van lijnversterkers.
4.3.1.3 Groepsadressen
Om alle componenten binnen het domotica systeem met elkaar te laten communiceren zijn er groepsadressen nodig. De informatie die doorgestuurd wordt kan een waarde bevatten tussen de 1 bit en 14 bytes.
Een simpele switch aan/uit bevat 1 bit, gaat het om ingewikkeldere codes met foutmeldingen en een verwijzing naar de juiste lamp dan wordt dit gegeven doorgestuurd op het groepsadres door middel van enkele bytes (dit wordt later zeer duidelijk bij de foutcodes in de DGN/S 1.16.1).
De keuze van de groepsadressen wordt door de programmeur vrij gekozen. Hij kan een duidelijk overzicht maken van de mogelijke groepsadressen. Groepsadressen worden meestal in 3 lagen opgebouwd. Het eerste getal geeft de hoofdgroep weer, 2de getal is de subgroep en als laatste het 3de getal geeft de eigenlijke functie weer.
4.3.1.4 Toekennen groepsadres
Het groepsadres wordt bijvoorbeeld als volgt opgesteld:
GEBOUW / VERDIEPING / FUNCTIE
HOOFDFUNCTIE / MIDDENFUNTIE / FUNCTIE
Dit zijn enkele voorbeelden hoe de structuur kan opgebouwd worden, de programmeur is hier vrij in.
In de laatste laag (3de laag) vinden we de functie terug. Hier komen de eigenlijke groepsadressen in. Groepsadressen zijn nodig om componenten met elkaar te laten communiceren.
Onderstaande foto geeft de structuur weer die men hanteert binnen het Havenbedrijf Antwerpen.
Het bedrijf waar ik de stage realiseer gebruikt voor elk project een vaste structuur voor de groepsadressen. Er is een uitbreiding gebeurd op deze vaste structuur om de groepsadressen van de noodverlichting te integreren.
Dezelfde structuur gebruiken voor elk project is zeer overzichtelijk zeker als meerde programmeurs binnen eenzelfde project moeten samenwerken. Zij passen elke project toe met dezelfde structuur, zo blijft het overzichtelijk voor iedereen.
Voor deze stage werden groepsadressen onder adresgroep 7 bijgemaakt. Dit wordt later duidelijk.
Via een groepsadres wordt een commando doorgegeven van bijvoorbeeld een drukknop naar de actor die dan de lampenkring schakelt.
Het domotica systeem bestaat uit een zeer uitgebreid netwerk met vele lijnen en zones. Het is aan te raden om de filtertabellen zo in te stellen dat enkel de nodige groepsadressen door de lijnkoppelaars gaan. Zo beperk je het dataverkeer op de bus en zal deze sneller reageren.
4.3.2 Werking
Hoe werkt dit nu juist allemaal? Als we een domotica systeem gaan herleiden naar de kleinste mogelijk installatie dan wordt dit duidelijk. Op onderstaande foto zien we een simpele voeding zonder adres, een drukknop bediening en een schakelactor.
De drukknop krijgt adres 1.1.1, dit wilt zeggen dat het toestel zich bevindt in zone 1, lijn 1 en het toestelnummer 1 is in deze lijn (dit kan men vrijuit kiezen). Een gewone voeding krijgt geen adres, later in de realisatie worden er intelligente voedingen gebruikt dewelke wel een adres hebben.
We koppelen aan de schakelactor en aan de drukknop hetzelfde groepsadres 2/2/2 om de communicatie mogelijk te maken.
Figuur 4.9 visueel KNX opstelling
De drukknop is een switch en stuurt een 1 bit signaal op de bus, hij stuurt een 1 of een 0 (aan of uit). Geven we nu de drukknop en de schakelactor hetzelfde groepsadres 2/2/2, dan zullen deze met elkaar gaan communiceren als er een waarde verzonden wordt.
Figuur 4.10 visueel KNX opstelling telegram versturen
Als we op de drukknop (verzender) drukken wordt het groepsadres 2/2/2 met als waarde 1 verzonden over de gehele installatie. Enkel de schakelcomponenten die hetzelfde adres hebben zullen hierop reageren.
De schakelactor (ontvanger) zal dus reageren. Hij schakelt zo de voeding door naar de lamp en zal blijven branden.
Enkel wanneer hier terug een puls (uit commando) verstuurd wordt vanuit dezelfde schakelaar, zal de lamp uitschakelen.
4.4 DALI gateway
Het eerste deel van de stage is het uitwerken van het domotica gedeelte. Dit omvat een noodverlichting logging via een ABB DALI gateway. Vooraleer we starten met de uitwerking, vind je hieronder enkel eigenschappen van het gebruikte onderdeel DGN/S 1.16.1.
4.4.1 Beschrijving DGN/S 1.16.1
Het belangrijkste onderdeel van de domotica opstelling is de DGN/S 1.16.1 KNX ABB i-bus DALI gateway met noodverlichting functies. De DALI uitgang kan gebruikt worden voor het aansluiten van 64 DALI apparaten. Aan de DGN/S kunnen ook gewone armaturen aangesloten worden. Er is dus een mix mogelijk van gewone armaturen en armaturen met ingebouwde zelfvoorzienende batterijen. Alle 64 lampen kunnen onderverdeeld worden in 16 groepen. Voor de noodverlichting gaan we de groepen niet gebruiken. De armaturen kunnen ook afzonderlijk aangestuurd worden. De storing van elk individueel armatuur kan worden uitgelezen (lamp-, ballast-, convertor- en batterijfouten).
Hieronder staat een mogelijk aansluitschema van de DALI gateway. De DGN/S vereist aan de onderzijde een aansluiting van de voeding en een aansluiting met de KNX buskabel. Aan de bovenzijde kunnen tot 64 lampen, aangesloten worden via de DALI bus
Naast de standaard functies (schakelen, dimmen en het aanpassen van de helderheid met de nodige feedback), heeft DGN/S ook trappenhuisverlichting en scenes als extra functies.
Aparte normale verlichtingsgroepen kunnen dus zo opgenomen worden in de noodverlichting gateway naast de noodverlichting sturing.
de noodverlichting tests kunnen automatisch getriggerd worden. Er zijn functie-, duur en gedeeltelijke duurtesten mogelijk.
• functie-test
Deze functietest wordt aangevraagd via een parametreerbare interval in de noodverlichting converter of door een KNX communicatieobject.
De betrouwbaarheid van de noodverlichting converter, de correcte werking van de lamp, en een korte inschakeling van de batterij worden getest.
• duurtest
Deze test wordt gebruikt om te bepalen of de batterijen per armatuur nog voldoen volgens de eisen. Er wordt getest of de batterij binnen de grenzen van de nominale bedrijfsduur bij noodverlichting zit.
• Gedeeltelijke duurtest
De gedeeltelijke duurtest wordt gecontroleerd door de gateway. De gedeeltelijke duur test is niet beschreven door de normen.
Deze test is om snel en eenvoudig te kunnen testen zonder de batterij volledig te ontladen.
Een verdere verduidelijking van de component DGN/S 1.16.1 vindt u hieronder.
1 Plaats voorzien om een label aan te brengen
2 Programmeer knop (KNX)
3 Rode programmeer LED (KNX)
4 Grijs/rode buskabel aansluitfiche (KNX)
5 LED geel (DALI fout)
6 LED rood (gateway actief)
7 Aansluiting voeding 230V
8 Output A (DALI)
9 Testknop (DALI)
10 DALI apparaten, met of zonder zelfvoorzienende noodverlichting.
Als we kijken naar de plaatsing van deze DALI noodverlichtingsgateway, moeten we rekening houden met enkele voorwaarden als het gaat over kabellengtes naar de apparaten. De verschillende doorsnede en afstanden zijn duidelijk weergegeven in de tabel hieronder.
(DGN/S 1.16.1 product manual, 10/2011)
4.4.2 Software i-bus Tool
Zoals eerder vermeld kunnen er maximum 64 apparaten aangesloten worden aan de DALI noodverlichtingsgateway. De noodverlichtingsarmaturen zijn voorzien van een intelligente ballast, hierop kan men het adres van de lamp instellen. Deze functie kan overgenomen worden door de i-bus Tool. Hierin heeft men een duidelijk overzicht welke lampen er zich op de bus bevinden. De lampen kunnen via deze weg kort getest worden met een status tot gevolg (d.m.v. een klik op de lamp).
Hieronder is het overzichtsscherm te zien van de i-bus Tool. Nadat je een verbinding hebt gemaakt met het domotica systeem en als de DGN/S 1.16.1 toegevoegd is in ETS4 (zie later), kan je door middel van een individueel adres inloggen in de DGN/S 1.16.1. Nadat de i-bus Tool gekoppeld is, zoekt hij automatisch naar de lampen die aanwezig zijn op de DGN/S output. In het overzicht is er gekozen om de lampen op plaats 1, 2, 3 en 4 te zetten.
Zijn er fouten in het systeem of zijn er fouten in de lampen, dan zijn deze onmiddellijk te zien in de I-bus Tool door een verandering van het symbool.
Bij lamp 33 is de lamp stuk, en bij lamp 34 is de verbinding verbroken.
Figuur 4.15 foutmeldingen I-bus Tool
5 PROGRAMMEREN DALI GATEWAY
5.1 Inleiding
In dit hoofdstuk zal het eerste grote deel van de stage besproken worden. De volledige realisatie van de DGN/S 1.16.1 KNX ABB i-bus DALI gateway met noodverlichting functies zal terug te vinden zijn in onderstaand hoofdstuk.
5.2 Uitwerking in ETS4 (DGN/S 1.16.1)
Het programmeren (instellen) van de DGN/S 1.16.1, zal gebeuren via ETS4 software.
De testbank is voorzien van een vaste apparaten structuur, hierop is de DGN/S 1.16.1 KNX ABB i-bus DALI gateway met noodverlichting functies op gemonteerd. Hierdoor wordt de DGN/S opgenomen in een realistische omgeving.
Allereerst zal er een nieuw project aangemaakt worden, met de naam demo bord. Hierin zal de stage uitgewerkt worden. Als ETS4 geopend wordt zien we een overzichtsscherm. Op dit scherm kan men een nieuw project aanmaken.
onder het tabblad projecten kunnen we op de knop +New klikken. Verder verschijnt er een nieuw venster waar het project kan aangemaakt worden.
De naam van het project is vrij te kiezen, onder backbone en medium kan men kiezen hoe de verbinding onderling zal verlopen. De verbinding op de testbank wordt volgens twisted pair (TP) verwezenlijkt (zie onderstaande afbeelding).
Het groepsadres wordt drievoudig opgesteld, dit om een overzichtelijk geheel te behouden. Het bedrijf heeft vele projecten waarbij een drievoudige onderverdeling veel overzichtelijker is.
De testopstelling bevat een vaste structuur, deze wordt in elk gebouw en elke opstelling gehanteerd. Ook hier zullen deze vaste apparaten toegevoegd worden aan het project.
Via de catalogi die bovenaan het scherm te vinden is, kunnen alle componenten voor dit project toegevoegd worden. Hierin is een uitgebreide catalogus te vinden van de apparaten. Zijn de apparaten niet aanwezig wegens te nieuw of is er een update beschikbaar op dat apparaat, dan kan er een plug-in geïnstalleerd worden. Deze zijn te vinden op de websites van de fabrikanten. Voor de DGN/S