Masterproef Trends binnen de gebouwenautoma sering

Masterproef Trends binnen de gebouwenautoma sering

Studiegebied Industriële wetenschappen en technologie Opleiding Master Of Science in de industriële wetenschappen: elektrotechniek Afstudeerrich ng Automa sering Academiejaar 2011-2012

Pieterjan Bulteel Academische bachelor- en masteropleidingen, Graaf Karel de Goedelaan 5, 8500 Kortrijk

Masterproef Trends binnen de gebouwenautoma sering

Studiegebied Industriële wetenschappen en technologie Opleiding Master Of Science in de industriële wetenschappen: elektrotechniek Afstudeerrich ng Automa sering Academiejaar 2011-2012

Pieterjan Bulteel Academische bachelor- en masteropleidingen, Graaf Karel de Goedelaan 5, 8500 Kortrijk

Voorwoord In dit voorwoord zal ik van de gelegenheid gebruik maken om de mensen te bedanken die mijn masterproef en ook mijn opleiding als industrieel ingenieur mogelijk gemaakt hebben. In de eerste plaats zou ik mijn ouders willen bedanken omdat zij het mogelijk gemaakt hebben dat ik deze studies kunnen volgen heb. Zij hebben mij daarin zowel op financieel vlak als op mentaal vlak gesteund. Daarnaast zou ik ook mijn vrienden en familie willen bedanken omdat zij mijn steun en toeverlaat waren jdens moeilijkere periodes doorheen mijn studies. Omtrent mijn masterproef binnen Catael zou ik alle medewerkers willen bedanken in bijzonder : Nikolas Taelman, mijn externe promotor en Bert Hervent. Zij stonden mij bij met raad en daad voor zowel theore sche als technische aspecten van deze masterproef. Daarnaast bedank ik ook Henk Capoen, mijn interne promotor, voor zijn geduld, ps en feedback omtrent de poster, samenva ng en thesis. Verder zou ik ook nog alle docenten van de afdeling Industriële Wetenschappen Elektromechanica willen bedanken voor de uitstekende opleiding. Mijn afstudeerrich ng Automa sering is veruit de meest grondige en innoverende opleiding binnen onze school en andere scholen in België. Daarom zou ik uitdrukkelijk nog eens het puike leerkrachtenteam van de rich ng Automa sering willen bedanken. Als laatste bedank ik dan ook graag nog eens mijn medestudenten waar ik 4 jaar mee samen in klas gezeten heb. Men zegt wel eens de studenten jd zijn de beste jaren, ik kan alleen maar beves gen dat dit inderdaad een zeer mooie 4 jaar geweest zijn.

i

Abstract This document will briefly explain the cause, the approach and the conclusion of this thesis. I did my thesis in Catael; this is an automa on company who defines itself within 4 branches of automa on namely industrial automa on, consultancy, building automa on and machine building. My thesis is fully located within the branch building automa on. The thesis concludes 4 goals; the first goal is to get a theore cal basis by studying 3 building automa on standards namely KNX, DALI and EnOcean. KNX is used to connect all sorts of sensors en actors (for example switches and blinds) to a central bus. Digital Addressable Ligh ng Interface (DALI) is used to address and control digital ballasts. EnOcean is a wireless protocol; it uses wireless components that don't need power supply. Next I have to build a demonstra on case where the 3 standards are combined to an industrial network. With this demonstra on case I will be able to test the configura on en programming of a few devices. Because Phoenix Contact wanted to get more involved into building automa on they designed and fabricated a KNX-to-Ethernet gateway which makes communica on between a Programmable Logic Controller (PLC) and a KNX network possible. They asked Catael if I could fully test this gateway and write a so ware library to control it. The last goal is to implement the gateway and the so ware library in various industrial projects. I started with a protocol study about KNX, DALI and EnOcean; this study has been integrated in the thesis but has been wri en in Dutch. With the knowledge I had from the protocol study I started to build a building automaon network. I used a central controller from Phoenix Contact that was connected thru the new KNX-to-Ethernet gateway with an underlying KNX network. The controller was also connected with a DALI master that managed 3 DALI ballasts. I did a few tests with EnOcean but didn't use it within the rest of the thesis. Then I fully tested the new gateway of Phoenix and I found 2 errors within the hardware. Next I developed a so ware library which could be used to control a KNX network. I could test it and adjust since I had implemented it in the demonstra on case. When the library was fully developed, the gateway and the library were used in 2 industrial projects of Catael. The protocol studies can be used as an educa onal document in school and in the company. Catael will now be able to give demonstra ons and lessons about KNX en DALI with the demonstra on suitcase. Also Phoenix Contact can now distribute their gateway and the new so ware library.

ii

Lijst met a or ngen A ASK

Amplitude Shi Keying

B BLC BbC

BACL Light Configurator Backbone Coupler

C CTRL CSMA CA CD CRC

Control Field Carrier Sense Mul ple Access Collision Avoidance Collision Detec on Cyclic Redundancy Check

D DALI

Digital Addressable Ligh ng Interface

E EIB EHS ETS ERP ESP3

European Installa on Bus Emergency Home Systems Engineering So ware Tool EnOcean Radio Protocol EnOcean Serial Protocol 3.0

F FTP

File Transfer Protocol

iii

H howest

Hogeschool West-Vlaanderen

I ILC IP ID

Inline Controller Internet Protocol Iden fica on

L LC

Line Coupler

M MAU MAC

Medium A achement Unit Medium Access Control

O OSI-model

ISO Reference Model for Open Systems Interconnec on

P PC PLC PL

Personal Computer Programmable Logic Controller Power Line

R RF

Radio Frequency

T

iv

TCP

Transmission Control Protocol

U USB

Universal Serial Bus

W WLAN

Wireless Local Area Network

v

Inhoudsopgave 1 Inleiding 1.1 Bedrijfsvoorstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Projectaanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 KNX 2.1 Inleiding . . . . . . . . . . . . . . . . 2.2 Fysische Laag . . . . . . . . . . . . . 2.2.1 Medium . . . . . . . . . . . . 2.2.2 Twisted Pair . . . . . . . . . . 2.2.3 Modula e . . . . . . . . . . . 2.2.4 Netwerk topologie . . . . . . 2.3 Datalink Laag . . . . . . . . . . . . . 2.3.1 Seriële asynchrone transmissie 2.3.2 Dataframes . . . . . . . . . . 2.3.3 MAC . . . . . . . . . . . . . 3 DALI 3.1 Inleiding . . . . . . . . . . . . . . . . 3.2 Fysische laag . . . . . . . . . . . . . 3.2.1 Medium . . . . . . . . . . . . 3.2.2 Modula e . . . . . . . . . . . 3.2.3 Netwerk topologie . . . . . . 3.3 Datalink Laag . . . . . . . . . . . . . 3.3.1 Seriële asynchrone transmissie 3.3.2 Dataframes . . . . . . . . . . 4 EnOcean 4.1 Inleiding . . . . . . . 4.2 Radio protocol . . . . 4.2.1 Fysische laag 4.2.2 Datalink laag 4.3 Serieel protocol . . . 4.3.1 Fysische Laag 4.3.2 Datalink laag

1 1 1 2

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

3 3 3 3 4 4 7 13 13 13 17

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

19 19 21 21 21 22 23 23 23

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

25 25 26 26 27 29 29 29

5 Demokoffer 5.1 Opstelling . . . . . . . . . . . 5.1.1 Principeschema . . . . 5.1.2 Uitvoering Demokoffer 5.2 DALI configura e . . . . . . . 5.3 KNX configura e . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

31 31 31 31 33 36

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

vi

6 Prak sche Implementa e 6.1 So ware bibliotheek . . . . . . 6.1.1 KNX-to-Ethernet gateway 6.1.2 Hardwarema ge testen . 6.1.3 So warema ge testen . 6.2 Industrieel project . . . . . . . . 7 Conclusies

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

41 41 41 41 45 50 51

vii

Lijst van tabellen 4.1 4.2

Maximum communica e jden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Soorten datapakke en . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28 30

viii

Lijst van figuren 1.1 1.2

Catael . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aanpak masterproef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23 2.24 2.25 2.26 2.27

KNX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schema sche voorstelling van de fysische laag . . . . . . . . . . . . . Logische '1' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logische '0' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aanvullende gegevens bij figuur 2.4 . . . . . . . . . . . . . . . . . . . Van een analoog signaal naar een seriële bitstroom . . . . . . . . . . . Fysisch segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Het verbinden van Zones a.d.h.v. een Router . . . . . . . . . . . . . . Realis sche zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structuur van een adres binnen KNX . . . . . . . . . . . . . . . . . . . KNX gateway van Phoenix Contact . . . . . . . . . . . . . . . . . . . . De IP interface van ABB verbindt de KNX bus met het Ethernet netwerk Karakterframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . L_Data_Standard Frame format . . . . . . . . . . . . . . . . . . . . . L_Data_Standard Frame format in detail . . . . . . . . . . . . . . . . . Check octet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . L_Data_Extended Frame format . . . . . . . . . . . . . . . . . . . . . L_Data_Extended Frame format in detail . . . . . . . . . . . . . . . . Extended control field . . . . . . . . . . . . . . . . . . . . . . . . . . L_Poll_Data Request Frame format . . . . . . . . . . . . . . . . . . . . L_Poll_Data Response Frame format . . . . . . . . . . . . . . . . . . . Acknowledgement Frame Format . . . . . . . . . . . . . . . . . . . . CSMA ingevuld volgens het KNX protocol . . . . . . . . . . . . . . . . Het CSMA/CA principe als er een collision gebeurt . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

3 4 5 6 6 7 8 8 9 10 11 11 12 12 13 14 14 14 15 15 15 16 16 16 17 17 18

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11

DALI protocol . . . . . . . . . . . . . . . . . . DALI Vs. 0-10 V . . . . . . . . . . . . . . . . . De mogelijkheden om verlich ng aan te sturen Manchester coding . . . . . . . . . . . . . . . Cyclus om vier forward berichten te sturen . . Backward bericht . . . . . . . . . . . . . . . . Lijntopologie bij DALI . . . . . . . . . . . . . . Parameters in een DALI slave . . . . . . . . . . Forward bericht . . . . . . . . . . . . . . . . . Verschillende manieren tot adresseren . . . . Backward bericht . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

19 20 20 21 22 22 22 23 24 24 24

4.1 4.2

EnOcean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EnOcean protocollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25 25

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

1 2

ix

4.3 4.4 4.5 4.6 4.7 4.8

Vergelijking met bestaande draadloze netwerken Amplitude Shi Keying . . . . . . . . . . . . . . EnOcean topologie . . . . . . . . . . . . . . . . Dataframe van een subtelegram . . . . . . . . . ESP3 . . . . . . . . . . . . . . . . . . . . . . . . ESP3 dataframe . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

26 27 27 28 29 29

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13

Principeschema van de demokoffer . . . . . Demokoffer . . . . . . . . . . . . . . . . . DALI configura e : opbouw in PC Worx . . . BLC : Startpagina . . . . . . . . . . . . . . BLC : Se ngs ballast . . . . . . . . . . . . BLC : Instellingen i.v.m. groepen en scènes . KNX USB interface . . . . . . . . . . . . . . Verbinden met een Ethernet interface . . . Netwerk topologie . . . . . . . . . . . . . Een KNX deelnemer op een lijn ze en . . . Instelbare parameters van een component . Groepaddressen . . . . . . . . . . . . . . . Programmeerknop op een KNX component

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

31 32 33 34 35 36 37 37 38 38 39 39 40

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15

KNX-to-Ethernet gateway van Phoenix Contact . Configura e van de gateway . . . . . . . . . . Ini alisa e van de gateway . . . . . . . . . . . Commando om een byte te schrijven . . . . . . Sturen van het commando met data 63 . . . . Antwoord vanuit de gateway . . . . . . . . . . Sturen van het commando met data 64 . . . . Fout antwoord vanuit de gateway . . . . . . . KNX_Server . . . . . . . . . . . . . . . . . . . Opstart procedure . . . . . . . . . . . . . . . . KNX_Byte . . . . . . . . . . . . . . . . . . . . Ini alisa e en vervolgens luisteren op de bus . KNX_Bit . . . . . . . . . . . . . . . . . . . . . KNX_Integer . . . . . . . . . . . . . . . . . . . KNX_Floa ng_Point . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

41 42 42 43 43 44 45 45 46 46 47 47 48 48 49

. . . . . . . . . . . . .

x

1

Inleiding

Het automa seren van verlich ng, verwarming, airco en dergelijke wordt al een jdje toegepast in zowel huizen als kantoren. Veel intelligen e zat er echter niet in deze componenten en controllers, die de overkoepelende naam domo ca kregen. Dit alles wordt naar een hoger, meer industrieel niveau, gebracht door het ontwikkelen van bussen specifiek voor gebouwenautoma sering. Deze bussen zijn voorzien van een eigen intelligent protocol; KNX, DALI en EnOcean zijn daarvan drie toonaangevende voorbeelden. Net als bij industriële veldbussen wordt er ook gebruik gemaakt van een centrale intelligente component, hoewel dit meestal geen vereiste is. Deze centrale intelligen e zorgt er bijvoorbeeld voor dat er een webbased visualisa e kan geïntegreerd worden. Het kan nog een stap verder door een PLC te gebruiken als intelligente controller zodat er een netwerk kan gemaakt worden van industriële veldbussen gecombineerd met de nieuwe technologie uit de gebouwenautoma sering.

1.1 Bedrijfsvoorstelling Catael is een automa seringsbedrijf geves gd in Bellegem, vlakbij Hoog Kortrijk. Het bedrijf is opgestart door Nikolas Taelman en Henk Capoen, docent aan Howest in 2007. Ondertussen werkt het bedrijf al met een dynamisch en jong team van 8 uitstekende industriële ingenieurs.

Figuur 1.1: Catael

Catael profileert zich binnen vier verschillende takken van de automa sering, namelijk consultancy, industri�le automa sering, machinebouw en gebouwenautoma sering. Het bedrijf was al wat vertrouwd met gebouwenautoma sering op vlak van Dali en EnOcean, KNX was echter een volledig nieuw gegeven.

1.2 Doelstellingen Om met een goede theore sch onderbouwde achtergrond te kunnen starten is het belangrijk dat er een protocolstudie uitgevoerd wordt naar de drie protocollen KNX, DALI en EnOcean. Een studie naar de fysische laag en de datalink laag binnen het ISO Reference Model for Open Systems Interconnec on (OSI-model) van de protocollen zou al een degelijk inzicht moeten verschaffen. Vervolgens moet er een demokoffer ontworpen en uitgewerkt worden. In deze demokoffer moeten de protocollen vertegenwoordigt zijn met enkele componenten en deze moeten allemaal aanstuurbaar zijn via een centrale controller. Het is de bedoeling dat Catael later met deze koffer demonstra es kan geven aan klanten en opleidingen kan geven rond de protocollen aan bedrijven. Om te kunnen volgen in de trends van de gebouwenautoma sering hee Phoenix Contact een ethernet-to-KNX

1

gateway gemaakt. Deze is nog een prototype en is nog niet op de markt verkrijgbaar. Er werd aan Catael gevraagd om deze gateway volledig te testen en een so ware bibliotheek er rond te schrijven. Een laatste doelstelling bestaat erin de nieuwe gateway samen met de ontworpen so ware bibliotheek te integreren in diverse industriële projecten.

1.3 Projectaanpak In figuur 1.2 wordt in blokschema weergegeven hoe de aanpak van de masterproef verloopt.

Figuur 1.2: Aanpak masterproef

Er wordt gestart vanuit de protocolstudie zodat een goede werking van de protocollen verkregen wordt. Vervolgens wordt een demokoffer gemaakt waarin alle nodige elementen aanwezig zijn zodat een geheel van netwerken rond een centrale controller kan gebouwd worden. In deze demokoffer zi en onder andere een DALI master en een KNX gateway die volledig getest moeten worden. Eerst dient de nieuwe KNX gateway volledig getest te worden zodat er zeker geen hardware fouten meer in zi en. Nu kan aan de so ware bibliotheek begonnen worden op basis van de informa e die er reeds bestaat rond de gateway. Deze so ware kan vervolgens getest worden met de demokoffer en opnieuw aangepast worden tot het op punt staat. Pas dan kan de so ware bibliotheek en de gateway geïntegreerd worden in verschillende projecten.

2

2

KNX

2.1 Inleiding Technologie uit de gebouwenautoma sering zoals KNX [1] is een gespecialiseerde vorm van industriële automa sering, aangepast aan de noden van een huis of een kantoorgebouw. Ook zoals bij industriële automa sering zal KNX een netwerk vormen van actoren en sensoren. Enkel zijn de sensoren hier termperatuur- en lichtmeters en zijn de actoren zonneweringen en verlich ng. KNX (figuur 2.1) is het resultaat van de samensmel ng van drie toonaangevende systemen voor gebouwenautoma sering, namelijk European Installa on Bus (EIB), Emergency Home Systems (EHS) en Ba Bus. Dit zorgde ervoor dat de beste oplossingen van de drie standaarden gecombineerd werden in een nieuwe standaard, KNX. Bovendien zijn alle toestellen van EIB nog volledig compa bel met het nieuwe KNX. Op deze manier werd ook een standaard gemaakt dat door de Europese en buitenlandse standardisa ekringen aanvaard werd. KNX voorziet ook PC tools, zoals Engineering So ware Tool (ETS) voor Windows, waarmee bepaalde actoren en sensoren kunnen ingesteld en gegroepeerd worden.

Figuur 2.1: KNX

KNX wil vooral de energie efficiën e van huizen en kantoorgebouwen verbeteren. Aangezien alle actoren afzonderlijk aangestuurd worden zal er nooit energie verspild worden zonder dat het nodig geacht wordt. Zo zal er nooit verlicht of verwarmd worden zonder menselijke aanwezigheid. Het resultaat van KNX is dus dat het energieverbruik geop maliseerd zal worden, terwijl het comfort s jgt.

2.2 Fysische Laag 2.2.1 Medium KNX ondersteunt verschillende media, deze kunnen dan nog eens gecombineerd worden aan de hand van routers. De verschillende media zijn : - Twisted Pair : De belangrijkste kenmerken van twisted pair zijn : data en voeding over één kabelpaar, asynchrone character geöriënteerde datapakke en en half duplex communica e. De baudrate bedraagt 9600 bit/s. - Power Line (PL) 110 : Dit medium maakt communica e over het voedingsnetwerk mogelijk. De belangrijkste kenmerken zijn : hoogfrequente signalen, asynchrone communica e van datapakke en, en half duplex. De baudrate bedraagt 1200 bit/s. - Radio Frequency (RF) : Maakt gebruik van radio golven in de 868,3 MHz band voor toestellen met een kort bereik.

3

- Naast deze media hee KNX ook ongedefinieerde integra e oplossingen voor Ethernet, Bluetooth, WiFi, ... In deze masterproef werd gebruik gemaakt van twisted pair, de uitleg van het verdere protocol zal dus hierop gebaseerd zijn.

2.2.2 Twisted Pair De fysische laag type TP1, zoals afgebeeld in figuur 2.2, bestaat uit 4 belangrijke blokken : 1. Het medium, hier twisted pair. 2. De connector (C) die een deelnemer of een bridge met het medium verbindt. 3. Medium A achement Unit (MAU) : Deze zet het analoog signaal vanop het medium om tot een seriële bitstroom en stuurt dit door naar de logical unit. En omgekeerd, de seriële bitstroom die van de logical unit komt, wordt omgezet tot een analoog signaal. 4. Logical Unit : Hier wordt de seriële bitstroom omgezet naar afzonderlijke bytes en omgekeerd, deze bytes worden dan naar de bovenliggende lagen verstuurd.

Data Link Layer

Physical Layer

TxD

RxD

Medium Attachement Unit ADC

DAC

Transmitter

Receiver

C Medium met het analoog signaal en voeding

Figuur 2.2: Schema sche voorstelling van de fysische laag

2.2.3 Modula e Met modula e wordt bedoeld hoe de databits als analoog signaal op het medium geplaatst worden. Er wordt een onderscheid gemaakt tussen een logische '0' en een logische '1'.

4

Logische '1' Een logische '1' kan aanzien worden als de 'Idle State' van de bus, dit wil eigenlijk zeggen dat er niets gebeurd. De MAU wordt zogezegd uitgeschakeld bij het versturen van een '1', dit wordt voorgesteld in figuur 2.3. Als de bus in 'Idle State' staat moet het bussignaal binnen bepaalde toleran es blijven. Als DC-Part het 24V signaal voorstelt dan mag het signaal niet groter worden dan 24,3 V en niet kleiner dan 22 V (Up = 0,3 V en Un = -2 V), de maximale helling of 'slope' bedraagt 400mV/ms.

Up Un

Figuur 2.3: Logische '1'

Logische '0' Om een logische '0' op de bus te ze en wordt een spanningsdaling op het analoge signaal van de bus geplaatst gedurende een jd tactive . Vervolgens wordt het signaal boven 24V getrokken om het verlies aan vermogen bij de deelnemer te compenseren. Het analoog signaal zal zich binnen het grijs gearceerde gebied bevinden, dit wordt gedefinieerd in figuur 2.5.

5

Figuur 2.4: Logische '0'

Figuur 2.5: Aanvullende gegevens bij figuur 2.4

Een logische '0' is dominant over een logische '1', dus als op de bus zowel een '1' als een '0' gezet worden, zal enkel de logische '0' doorgestuurd worden. Zowel een logische '1' als '0' duurt 104 µs, hieruit kan er besloten worden dat de baudrate ongeveer 9600 bits/s bedraagt. Van analoog signaal naar seriële bitstroom Nu geweten is hoe een logische '0' en '1' eruit ziet, kan er gekeken worden naar de omze ng van een analoog signaal naar een seriële bitstroom en de opdeling in bytes.

6

Figuur 2.6: Van een analoog signaal naar een seriële bitstroom

In figuur 2.6 kan aangetoond worden dat KNX werkt met asynchrone seriële communica e, de 8 databits worden ingepakt in een startbit, een pariteitsbit en een stopbit.

2.2.4 Netwerk topologie Een KNX netwerk bestaat uit een aantal fysische segmenten die aan elkaar kunnen gekoppeld worden door toestellen die hieronder uitgelegd worden. Fysisch segment Alle KNX toestellen worden gekoppeld op een fysisch segment, in dit geval op een Twisted Pair EIB kabel. Zo'n segment kan volgens de lijntopologie, stertopologie of boomtopologie of een combina e van de drie. Er kunnen tot 64 toestellen op een fysisch segment met TP1-64 aangesloten worden of tot 256 toestellen op een fysisch segment met TP1-256. De maximum lengte tussen twee toestellen op een segment bedraagt 700 m, de maximum lengte van een segment ligt rond de 1000 m.

7

Figuur 2.7: Fysisch segment

In figuur 2.7 wordt een KNX segment voorgesteld, de lijnen stellen de bustopologie voor en de vierkanten zijn de toestellen. Ieder toestel hee zijn fysisch adres :

Zone adres . Lijn adres . Adres van de busdeelnemer Het wordt aangeraden om geen lussen te leggen in het netwerk, er dienen ook geen afsluitweerstanden geplaatst te worden. Bridge Een bridge wordt gebruikt om een segment uit te breiden zodat er tot 255 toestellen op een lijn (figuur 2.8) kunnen met TP1-64 alsook dat er langere afstanden kunnen overbrugd worden. Bridges kunnen gebruikt worden om vier segmenten met elkaar te verbinden zodat een totale lengte van 3000 m kan afgelegd worden, hierdoor wordt de maximum lengte tussen twee deelnemers 2100 m. Deze 'repeaters' hebben geen individueel adres op het KNX netwerk, ze ze en enkel de ontvangen frames van de datalink laag over naar de andere kant van de bridge.

Figuur 2.8: Bridge

Hierboven wordt een verbinding tussen twee segmenten voorgesteld, in KNX termen wordt dit een lijn genoemd. Router In tegenstelling tot een bridge hee een router wel een individueel adres op het KNX netwerk. De router zal enkel de frames op de datalink laag doorsturen indien zij een des na on address beschikken die zich aan de andere kant van de router bevindt. Voor grotere netwerken kunnen zes en lijnen gecombineerd worden tot een zone aan de hand van vij ien routers. Er mogen niet meer dan twee routers in het pad staan tussen twee deelnemers binnen dezelfde zone. Routers die meerdere lijnen koppelen tot een Zone worden Line Coupler (LC) genoemd, zoals afgebeeld in figuur 2.9

8

Figuur 2.9: Zone

Met behulp van bridges kan een zone 4096 toestellen beva en. Routers kunnen ook gebruikt worden om meerdere zones aan elkaar te koppelen, deze worden Backbone Coupler (BbC) genoemd. Er kunnen zes en zones aan elkaar gekoppeld worden indien vij ien backbone couplers gebruikt worden, tussen twee deelnemers mogen niet meer dat twee backbone couplers zi en. Hierdoor mogen maar maximum zes koppelingen (routers en bridges) zi en tussen gelijk welke twee deelnemers. De maximum groo e van een KNX netwerk kan hierdoor oplopen tot 65 536 deelnemers, zoals voorgesteld in figuur 2.10

9

Figuur 2.10: Het verbinden van Zones a.d.h.v. een Router

In de prak jk is het echter volledig anders, elke lijn moet voorzien worden van een KNX voeding, deze voeding bepaalt hoeveel toestellen er mogen aangesloten worden. Volgens de vuistregels geldt dat elke KNX component 10 mA verbruikt, aangezien de grootste voeding 640 mA bedraagt kunnen er dus maximum 64 componenten op een lijn aangesloten worden. Ook telkens er een buskoppelaar of line coupler aan het netwerk toegevoegd wordt moet er opnieuw een voeding voor deze lijn voorzien worden. In figuur 2.11 wordt afgebeeld hoe een zone er in werkelijkheid uitziet.

10

Figuur 2.11: Realis sche zone

Adressering Nu ligt de adressering voor de hand, ieder element, lijn en zone hee een eigen deel in het adres. Per lijn zijn maximaal 255 deelnemers verbonden, hierdoor zijn acht bits gereserveerd in het adres voor het device address. Per netwerk kunnen maximaal vij ien zones zijn met elk maximaal vij ien lijnen, daarom zijn voor de lijn en de zone elk vier bits gereserveerd, respec evelijk het line Address en area Address. Figuur 2.12 toont de structuur van een source address of een des na on address.

Figuur 2.12: Structuur van een adres binnen KNX

Gateway Gateways kunnen gebruikt worden om een ander netwerk met het KNX netwerk te verbinden, deze krijgen geen adres op het KNX netwerk. In deze masterproef werd gebruik gemaakt van een gateway tussen Ethernet Trans-

11

mission Control Protocol (TCP)/Internet Protocol (IP) en het KNX netwerk. Deze gateway is volledig transparant en zet alles wat verstuurd wordt op het KNX netwerk over op het Ethernet TCP/IP netwerk. Met dit toestel kan een PLC gekoppeld worden aan het KNX netwerk. In figuur 2.13 wordt de interface voorgesteld die er gebruikt werd voor het KNX project.

Figuur 2.13: KNX gateway van Phoenix Contact

Interface Een interface wordt ook gebruikt om een ander netwerk te koppelen aan het KNX netwerk, maar deze krijgt wel een adres op het KNX netwerk. In de masterproef werd een dergelijk toestel gebruikt om het KNX netwerk te configuren met ETS4. De configura e van het KNX netwerk wordt verder uitgelegd in het prak sche deel van deze thesis. In figuur 2.14 wordt de interface voorgesteld die er gebruikt werd voor het KNX project.

Figuur 2.14: De IP interface van ABB verbindt de KNX bus met het Ethernet netwerk

12

2.3 Datalink Laag 2.3.1 Seriële asynchrone transmissie KNX werkt op het principe van half duplex met gebruik van seriële asynchrone transmissie. Half duplex wil zeggen dat alle communica e over hetzelfde kabelpaar gebeurd, maar er kan maar één deelnemer tegelijk sturen. Met seriële asynchrone transmissie wordt bedoeld dat zender en ontvanger ona ankelijke klokken hebben. De bitsynchronisa e is gebaseerd op de interne klok van de ontvanger. In figuur 2.15 wordt het karakterframe voorgesteld waarin telkens een databyte ingepakt wordt.

Figuur 2.15: Karakterframe

De startbit zal al jd een nega eve flank genereren waardoor geweten is dat hierna acht databits volgen die moeten binnengelezen worden. Door die nega eve flank wordt de ontvangstklok gestart die aan dubbele frequen e binnenleest zodat telkens in het midden van iedere bit gelezen wordt. Na de acht bits data volgt een pariteitsbit die gebruikt wordt om te controleren of er jdens de communica e geen databits zijn verloren gegaan. Als laatste worden er aan het frame één of meerdere stopbits toegevoegd, na ontvangst van de stopbits kan een volgend karakterframe binnengelezen worden. Een stopbit is al jd een logische '1', zodat bij de opeenvolging van een stop- en een startbit al jd een nega eve flank gegenereerd wordt. Een nadeel is natuurlijk dat hier een aantal overtollige bits gebruikt worden die geen betekenis hebben.

2.3.2 Dataframes De datalink laag gebruikt drie dataframes, enkel deze dataframes kunnen verstuurd of ontvangen worden. In de dataframes zal de data voorgesteld worden aan de hand van octe en, om het lezen wat gemakkelijker te maken. Er kunnen drie dataframes onderscheiden worden : 1. L_Data Frame Format 2. L_Poll_Data Frame Format 3. Acknowledgement Frame Format Control Field Het eerste octet uit een frame zal het Control Field (CTRL). Met dit control field kan het type van het frame bepaald worden, de prioriteit en of het frame al dan niet moet herhaald worden. Dit wordt in figuur 2.16 weergegeven.

13

Figuur 2.16: Control field

Het control field maakt dus onderscheid tussen L_Data_Standard Frame, L_Data_Extended Frame, L_Poll_Data Frame of acknowledgement frame. Als er gelijk jdig gestuurd wordt zullen de 2 prioriteitsbits beslissen welke deelnemer zijn data op de bus mag plaatsen. L_Data_Standard Frame Dit dataframe wordt gebruikt om rela ef korte berichten te versturen, berichten langer dan 23 bytes dienen gebruik te maken van het L_Data_Extended Frame. In respec evelijk figuur 2.17 en figuur 2.18 wordt een algemene en een gedetailleerde weergave van dit dataframe afgebeeld.

Figuur 2.17: L_Data_Standard Frame format

Figuur 2.18: L_Data_Standard Frame format in detail

Source Address : Dit is het adres dat in octet 1 en 2 staat, het is het individueel adres van de deelnemer die de communica e start. Des na on Address : Dit adres, bestaande uit octet 3 en 4, staat voor de deelnemers die het frame moeten ontvangen. Het adres kan een individueel of een groep adres zijn, het onderscheid kan gemaakt worden door de bit voor adress type in octet 5 hoog te maken voor groep adres en laag voor individueel.

14

Length : Aangezien het frame een variabele lengte kan hebben, moet deze informa e meegegeven worden in octet 5. Check octet : Met dit laatste octet wordt de pariteit van het volledige dataframe gecontroleerd (figuur 2.19).

Figuur 2.19: Check octet

L_Data_Extended Frame Het L_Data_Extended Frame wordt gebruikt om berichten te versturen met data groter dan vij ien bytes, die dus niet in het Standard Frame passen. Ook wordt het gebruikt om berichten te versturen met uitgebreide adresmogelijkheden. De structuur van het dataframe wordt voorgesteld in figuur 2.20 en figuur 2.21.

Figuur 2.20: L_Data_Extended Frame format

Figuur 2.21: L_Data_Extended Frame format in detail

Extended Control field : In beide figuren valt op dat er een extra veld werd toegevoegd, dit is het extended control field. Als het frame type flag hoog staat in het CTRL, dan wordt er een extended control field toegevoegd. Figuur 2.22 toont welke informa e dit extra frame bevat.

15

Figuur 2.22: Extended control field

Het address type hee opnieuw aan of het om een individueel adres of een groep adres gaat. De hop count is het aantal keer dat het bericht mag geregenereerd worden door bridges en routers. Als het Extended Frame Format verschillend is van '0000' dan wordt er gewerkt met speciale adressen en tabellen. Length :De lengte van het frame wordt opnieuw teruggevonden in het Length karakter, nu kan deze een waarde van 0 tot 254 hebben. L_Poll_Data Frame Een L_Poll_Data Frame wordt gebruikt om eenvoudig een groep slaves af te pollen. De master stuurt een L_Poll_Data Request Frame Format (figuur 2.23) naar een groepadres van een groep slaves en ontvangt een L_Poll_Data Response Frame Format (figuur 2.24) als antwoord.

Figuur 2.23: L_Poll_Data Request Frame format

Het des na on address zal al jd een poll group address zijn. De master stuurt ook het aantal aan data mee die hij verwacht van alle slaves, dit moet overeen komen met het aantal Poll_Data die in het L_Poll_Data Response Frame zit.

Figuur 2.24: L_Poll_Data Response Frame format

In figuur 2.24 stelt ieder grijs kader een karakter voor. Het duurt vijf bi jden vooraleer een Poll_Data karakter

16

verstuur wordt door een slave en zes bi jden vooraleer de master een FILL karakter stuurt. De slaves zullen hun Poll_Data in het voorziene deel (0 tot 14) van het response frame invullen. Acknowledge Frame Het acknowledge frame wordt verzonden als antwoord op een Request frame zoals in figuur 2.26. Vooraleer dit frame, bestaande uit één karakter, verzonden wordt moet er vij ien bi jden gewacht worden. In figuur 2.25 worden de corresponderende codes voorgesteld.

Figuur 2.25: Acknowledgement Frame Format

2.3.3 MAC Het Medium Access Control (MAC) dat gebruikt wordt bij KNX is volgens het Carrier Sense Mul ple Access (CSMA)/Collision Avoidance (CA) [2] principe. Iedere deelnemer kan ini a ef nemen om te zenden (Mul ple Access), maar deze zal eerst luisteren op de bus of er geen andere zender bezig is (Carrier Sense). Na een bericht wordt een vaste jd gewacht, hier 50 bi jden, pas dan mag er een nieuw request frame verstuurd worden. Figuur 2.26 toont het aantal bi jden dat er moet gewacht worden bij de verschillende berichten.

Figuur 2.26: CSMA ingevuld volgens het KNX protocol

Als twee slaves willen sturen op hetzelfde moment dan zou er in principe een botsing moeten optreden, echter aangezien KNX het CSMA/CA principe hanteert zullen de berichten een bepaalde prioriteit bezi en. Aan de hand van deze prioriteit zal bepaald worden welk bericht verstuurd wordt, op deze manier is er zekerheid dat er al jd minstens één bericht verstuurd wordt. Om deze prioriteit te controleren wordt iedere bit uit het dataframe apart gelezen. Aangezien een logische '0' dominant is over een logische '1' zal het frame met de meest opeenvolgende nullen de hoogst prioriteit hebben, figuur 2.27 toont daar een voorbeeld van. Als een deelnemer die een logische '1' op het medium gezet hee , ziet dat datzelfde medium op een logische '0' staat dan weet deze deelnemer dat

17

er een collision gebeurt is. Zo weet deze deelnemer dat er een andere deelnemer met hogere prioriteit aan het sturen is. Deelnemer 1 Deelnemer 2 Deelnemer 3 Figuur 2.27: Het CSMA/CA principe als er een collision gebeurt

18

3

DALI

3.1 Inleiding DALI (figuur 3.1) [3] is een protocol dat voornamelijk gebruikt wordt om verlich ng aan te sturen en dan vooral ook om ze te dimmen. Het dimmen van verlich ng wordt in de prak jk veel gebruikt in combina e met een bewegingsmelder, deze meet de verlich ngssterkte in een kamer en op basis daarvan worden de lampen meer of minder uitgestuurd. Ook in bureaus wordt dimmen vaak toegepast zodat de werknemers zelf de verlich ngssterkte kunnen instellen en in een geop maliseerde omgeving kunnen werken. Verlich ng dimmen is geen nieuw gegeven binnen de automa sering, zo bestaan er 0-10 V ballasten die eenvoudig vanuit een PLC aan te sturen zijn. Dit zijn analoge sturingen, deze kunnen vervangen worden door digitale sturingen zoals DALI die een aantal voordelen met zich meebrengen. DALI wordt vooral gebruikt om digitaal dimbare verlich ngsballasten aan te sturen.

Figuur 3.1: DALI protocol

Het voordeel van DALI is dat de besturingseenheid, in ons geval de PLC, op eender welke plaats gezet kan worden zonder een s jging in kosten aan kabel te hebben. Namelijk een alterna ef is dat de aansturing van de ballasten gebeurt door 0-10 V sturing vanuit de PLC. Maar dan moet iedere 0-10 V ballast apart aangestuurd worden en apart bekabeld worden, terwijl bij DALI één gemeenschappelijke bus kan getrokken worden (figuur 3.2). In de prak jk wordt zelfs een 5-aderige kabel met sec e 1 mm² gelegd waarbij drie aders gebruikt worden om parallel de voeding door te schakelen en twee aders voor de DALI bus. Nog een voordeel van DALI ten op zichte van analoge sturing is het indelen van groepen. Met de DALI configura e tool kunnen verschillende ballasten in groepen onderverdeeld worden. Met analoge sturing kunnen natuurlijk ook aparte verlich ngskringen gebruikt worden, deze worden dan fysisch opgedeeld terwijl dit bij DALI digitaal gebeurt. Als die ballasten later in een andere groep moeten komen kan dit zeer eenvoudig met de DALI configura e tool. Bij een analoge sturing zullen de verlich ngskringen moeten herzien worden met alle gevolgen van dien. Digitale sturing hee ook het voordeel dat de ballasten informa e kunnen terugsturen, met andere woorden een status. Op die manier kan de master weten wanneer een slave weggevallen is of wanneer een lamp kapot is. Deze gegevens kunnen dan verwerkt worden in de PLC zodat de verlich ngsinstalla e gemakkelijk te onderhouden valt.

19

0-10 V sturing

DALI sturing

Voeding

0-10 V

DALI bus Figuur 3.2: DALI Vs. 0-10 V

Nog een alterna ef bestaat erin om een 0-10 V bus te gebruiken, dit is echter een duurdere oplossing. In figuur 3.3 staan de drie mogelijkheden in een grafiek afgebeeld.

Figuur 3.3: De mogelijkheden om verlich ng aan te sturen

20

3.2 Fysische laag 3.2.1 Medium DALI maakt gebruik van het medium twisted pair, verdere media zijn niet bekend. Hieronder staan enkele kenmerken van DALI over twisted pair : - Master - Slave - Asynchrone seriële transmissie - Half duplex - Baudrate : 1200 bits per seconde

3.2.2 Modula e DALI is zeer eenvoudig om te bekabelen aangezien polariteit geen rol speelt, er wordt gekeken naar het spanningsverschil tussen de twee buslijnen. Een spanningsverschil groter dan 9,5 V wordt gedetecteerd als een 'hoog' signaal, een spanningsverschil kleiner dan 6,5 V is een 'laag' signaal. Als er niets op de bus gebeurt dan staat de bus op een 'hoog' signaal, dus als de slave een hoog signaal wil sturen moet hij niets aan de bus veranderen. Als een slave een laag signaal wil sturen dan zal hij een kortstondige kortslui ng tussen de twee signaaldraden veroorzaken wat een spanningsval tot gevolg hee . Deze kortslui ng is niet schadelijk aangezien de stroom beperkt wordt tot 250 mA. De bus maakt gebruik van Manchester coding [2], ook wel biphase level genoemd, hierbij wordt er gewerkt met flanken. Een s jgende flank wordt aanzien als een logische '0', een dalende flank is dan een logische '1' zoals afgebeeld in figuur 3.4.

Figuur 3.4: Manchester coding

DALI werkt op een baudrate van 1200 bits per seconde, dus één bitperiode is 834 µs. Een bericht van Master naar Slave, ook wel een Forward bericht genoemd, bestaat uit negen en bits. Tussen twee zo'n berichten is er een rus jd van 9,17 ms. De totaliteit van vier masterberichten en vier rus jden komt dan neer op 100 ms, figuur 3.5. Het duurt dus 100 ms om vier berichten te sturen, dit maakt dat de DALI bus een trage bus is wat in de prak jk tot de nodige frustra es kan leiden.

21

Figuur 3.5: Cyclus om vier forward berichten te sturen

Voor een bericht van de Slave naar de Master wordt de term backward bericht gebruikt, dit bericht bestaat uit elf bits. De slave hee dus 9,17 ms nodig om een bericht terug te sturen naar de master. Daarom is de rus jd minstens 9,17 ms zodat de slave de kans krijgt om een bericht terug te sturen, krijgt de master na die jd geen bericht terug dan zal hij aannemen dat de slave niet terugstuurt en zal hij de andere slaves verder afpollen. Tussen een forward bericht en een backward bericht zit een rus jd van 2,92 ms - 9,17 ms, zie figuur 3.6.

Figuur 3.6: Backward bericht

3.2.3 Netwerk topologie De netwerktopologie die bij DALI gebruikt is een lijntopologie, zoals afgebeeld in figuur 3.7. Het adres van iedere slave wordt genoteerd als 'A' met daarnaast het short address van de slave. Iedere lijn hee een eigen master nodig, per master mogen er maximum 64 slaves aangesloten zijn. Bij Phoenix Contact wordt eerst een DALI PWR PAC geplaatst waarop vier masters kunnen aangesloten worden. Indien nog verder uitgebreid wil worden dan moet er opnieuw een DALI PWR PAC voorzien worden op de rack.

PLC

Ballast A 63

...

DALI DALI DALI Master Master Master

Ballast

Ballast

A0

A0

...

Ballast A4

Ballast A0

Ballast A 64

Figuur 3.7: Lijntopologie bij DALI

22

3.3 Datalink Laag 3.3.1 Seriële asynchrone transmissie Dit werd al besproken bij het onderdeel seriële asynchrone transmissie 2.3.1 in het hoofdstuk KNX.

3.3.2 Dataframes Iedere slave hee een aantal parameters opgeslaan (figuur 3.8). Aan de hand van berichten met verschillende commando's kan de master deze waarden aanpassen of opvragen.

Figuur 3.8: Parameters in een DALI slave

Zoals eerder vermeld wordt er een verschil gemaakt tussen een bericht van master naar slave, een forward bericht en een bericht van slave naar master, een backward bericht. Forward frames Opdat de master een slave zou kunnen aansturen, moet hij twee zaken meesturen, het adres van de slave en het commando dat uitgevoerd moet worden. In figuur 3.9 wordt een forward bericht voorgesteld, in de rode byte wordt het slave adres geplaatst en in de gele byte wordt het commando geplaatst. De twee bytes worden ingesloten tussen een startbit en twee stopbits.

23

Figuur 3.9: Forward bericht

Een slave kan op verschillende wijzes aangesproken worden, daarom kan de adres byte op meerdere manieren ingevuld worden (figuur 3.10).

Figuur 3.10: Verschillende manieren tot adresseren

Het short address is het logische adres van de ballast, dit adres kan toegekend worden a.d.h.v. een configura e so ware. Een ballast kan ook tot een groep ballasten behoren, deze groep hee dan ook een uniek group address. Om instellingen in een ballast te wijzigen wordt de adres byte gebruikt om extra gegevens met een commando mee te sturen, de zogenaamde special commands. Als bit S '0' is in de eerste drie gevallen dan wordt in de command byte een dimwaarde meegegeven, staat deze bit op '1' dan wordt een commando meegegeven. In de commando byte moet het nodige commando gebracht worden, in het document 'Digitally Addressable Lighng Interface (DALI) Unit Using the MC68HC908KX8' staat een tabel met alle mogelijke commands en special commands. Backward frames Aangezien er slechts één master op een lijn van 64 slaves is, hebben de slaves geen adres nodig om een bericht naar de master te sturen. Zoals in figuur 3.11 afgebeeld wordt moet er dan ook maar één byte voorzien worden voor het antwoord van de slave, opnieuw wordt deze byte vergezeld door een startbit en twee stopbits.

Figuur 3.11: Backward bericht

24

4

EnOcean

4.1 Inleiding EnOcean (figuur 4.1) staat voor energievriendelijke draadloze sensoren die weinig onderhoud nodig hebben en erg flexibel op te stellen zijn. EnOcean stelt producten voor die zowel in industriële automa sering als gebouwenautoma sering toegepast wordt.

Figuur 4.1: EnOcean

De sensoren zijn draadloos, hebben geen ba erij nodig en dus ook geen bijhorend onderhoud. De energie om een bericht te sturen wordt opgewekt door de sensor zelf, bijvoorbeeld het indrukken van een drukknop. Er zijn vijf verschillende manieren om energie op te wekken : licht, druk, temperatuursverandering, rota e en trilling. EnOcean voorziet in allerlei soorten schakelaars, temperatuursensoren, voch gheidssensoren, aanwezigheidsmelders, lichtsterktesensoren, etc. Het EnOcean protocol bestaat eigenlijk uit twee protocollen zoals aangeduid in figuur 4.2, een protocol dat de radiofrequente communica e beschrij tussen zenders en ontvanger en een protocol dat de communica e tussen een ontvanger en een controller bespreekt.

Figuur 4.2: EnOcean protocollen

25

4.2 Radio protocol In deze sec e wordt het EnOcean Radio Protocol (ERP) [4] toegelicht.

4.2.1 Fysische laag Medium Het medium dat het radio protocol gebruikt is natuurlijk lucht. EnOcean maakt gebruik van de 868 MHz band of van de 315 MHz band voor wereldwijd gebruik. Deze frequen ebanden worden gebruikt opdat de berichten niet in conflict zouden komen met de berichten over Wireless Local Area Network (WLAN) die zich op de 2,4 GHz band bevinden. Het bereik bedraagt tot 30 meter binnen gebouwen en tot 300 meter in open lucht, al zijn er ook repeaters beschikbaar die het bereik uitbreiden. In figuur 4.3 wordt de vergelijking met andere draadloze protocollen gemaakt.

Figuur 4.3: Vergelijking met bestaande draadloze netwerken

Modula e [2] Om berichten op het draadloze medium te plaatsen moet het baseband signaal gemoduleerd worden op een draaggolf. Om data te versturen kan de draaggolf in amplitude, fase of frequen e aangepast worden. Bij EnOcean wordt gebruik gemaakt van acASK (figuur 4.4) , hierbij wordt een logische '1' en '0' voorgesteld door twee verschillende amplitudes van de drager. Deze vorm van modula e vereist weinig bandbreedte maar is zeer gevoelig aan interferen e.

26

Figuur 4.4: Amplitude Shi Keying

Topologie Een netwerk kan bestaan uit draad- en ba erijloze sensoren of drukknoppen, gevoede actoren en gevoede bidirec onele netwerkcomponenten, zoals aangegeven in figuur 4.5.

Figuur 4.5: EnOcean topologie

De ba erijloze sensoren zullen data ofwel rechtstreeks ofwel via een netwerkcomponent naar de actor sturen. Een gateway kan gebruikt worden om een controller in het netwerk te betrekken. Op die manier kan eerst alle data binnengenomen worden in de controller, vervolgens kan de beslissing gemaakt worden welke actor aangestuurd moet worden.

4.2.2 Datalink laag Dataframes Het ERP hee geen handshake procedure of een dergelijke controle. Om de transmissie te verzekeren, worden drie dezelfde subtelegrammen binnen een bepaalde jdspanne verstuurd. Het geheel van deze drie iden eke subtelegrammen wordt dan een telegram genoemd.

27

Figuur 4.6: Dataframe van een subtelegram

In figuur 4.6 wordt de structuur van een subtelegram, hieronder wordt de betekenis van elk afzonderlijk deel uitgelegd : • RORG (1 byte) : Een header die het type van de subtelegram definieert. • DATA (1...x bytes) : De data die moet verstuurd worden. • TXID (4 bytes) : Dit is de Iden fica on (ID) van de zender. • STATUS (1 byte) : Toont aan of de subtelegram verstuurd werd door een repeater. • HASH (1 byte) : Checksum, wordt gebruikt om te controleren of de data correct verstuurd werd. Subtelegram ming Zoals eerder vermeld bestaat een telegram uit drie subtelegrammen, iedere subtelegram wordt binnen een verschillend jdsinterval verstuurd. Deze subtelegrammen moeten weliswaar binnen een bepaalde maximum jd verzonden en ontvangen worden, deze worden gedefinieerd in tabel 4.1. De jd om te verzenden, gaande van de start van het eerste subtelegram tot het einde van de laatste subtelegram, moet kleiner zijn dan de maximum Tx jd. Voor het ontvangen moet de jd, gaande van het einde van het eerste subtelegram tot het einde van de laatste subtelegram, kleiner zijn dan de maximum Rx jd. Tabel 4.1: Maximum communica e jden

Omschrijving

Parameter

Maximum Tx Maximum Rx

40 ms 100 ms

Medium Acces Control [2] EnOcean gebruikt CSMA/CD, dit is een techniek die vaak voorkomt bij draadloze communica e. CSMA staat voor Carrier Sense with Mul ple Access, Carrier Sense betekent dat elke deelnemer eerst zal luisteren of de bus bezet is vooraleer hij data zal versturen. Mul ple Access slaat dan weer op het feit dat meerdere deelnemers ini a ef mogen nemen om te starten met het versturen van data. Collision Detec on (CD) betekent botsingen detecteren, eerder werd Collision Avoidance (2.3.3) al besproken bij het KNX protocol. Als twee deelnemers gelijk jdig proberen te sturen zal een botsing optreden, CD zal dit detecteren waarop beide deelnemers moeten stoppen met sturen. Vervolgens moeten beide deelnemer een willekeurige jd wachten alvorens ze opnieuw mogen starten met het sturen van data. Dit principe wordt bij iedere subtelegram toegepast, maar als de willekeurige wach jd groter wordt dan de maximum Tx jd zal de deelnemer tocht starten met sturen ongeacht andere deelnemers.

28

4.3 Serieel protocol In deze sec e wordt het EnOcean Serial Protocol 3.0 (ESP3) [5] toegelicht. ESP3 definieert de seriële communica e tussen een EnOcean module en een host, wat een Personal Computer (PC) of een PLC voorstelt.

4.3.1 Fysische Laag Een host en een EnOcean module worden verbonden door een 3-draads verbinding gebaseerd op de RS-232 interface.

Figuur 4.7: ESP3

4.3.2 Datalink laag Dataframes Het dataframe van ESP3 is eenvoudig en wordt voorgesteld in figuur 4.8.

Figuur 4.8: ESP3 dataframe

De aparte velden worden hieronder verder toegelicht : • Sync. Byte (1 byte) : Seriële synchronisa e byte, deze hee al jd de waarde 55h. • Header : – Data Length (2 bytes) : Aantal bytes data die verstuurd worden.

29

– Op onal Length (1 byte) : Aantal bytes op onal data die verstuurd worden. – Packet Type (1 byte) : Definieert het type data packet dat verstuurd wordt. • CRC8 Header (1 byte) : Cyclic Redundancy Check (CRC) checksum van de totale header. • Data (x bytes) : Bevat de effec eve data. • Op onal Data (y bytes) : Bevat eventueel extra data die het gewone dataveld uitbreidt. • CRC8 Data (1 byte) : CRC checksum voor zowel data als op onal data. In het veld Packet Type wordt meegegeven om welk soort datapakket het gaat, de mogelijkheden worden in tabel 4.2 opgesomd. Tabel 4.2: Soorten datapakke en

Hex waarde

Packet type

Omschrijving

00 01 02 03 04 05 06 07 08...7F 80...FF

--Radio Response Radio_sub_tel Event Common_command Smart_ack_command Remote_man_command --Beschikbaar

Gereserveerd Radio telegram Antwoord op eender welk pakket Radio subtelegram Event bericht Commando Smart Ack command Remote management command Gereserveerd voor EnOcean Ruimte voor fabrikant specifieke berichten

Voor iedere Packet Type hee het ESP3 een uitgewerkte structuur, meer info rond deze verschillende datapakketten staat in het document 'EnOcean Serial Protocol 3'.

30

5

Demokoffer

5.1 Opstelling 5.1.1 Principeschema Om tot een demokoffer te komen moeten drie protocollen gecombineerd worden, elk met hun aparte hardware. Om daar een overzicht van te krijgen, wordt best gestart van een structureel schema. In figuur 5.1 wordt een mogelijke combina e voorgesteld.

Figuur 5.1: Principeschema van de demokoffer

Er wordt gestart vanuit een centrale controller, namelijk een Inline Controller (ILC) van Phoenix Contact. Vervolgens is er een gateway nodig tussen de ethernetverbinding van de PLC en het KNX netwerk. Met deze KNX gateway en een bijhorende voeding van maximum 640 mA kunnen dus maximaal 64 KNX modules geschakeld worden. Om het DALI netwerk te kunnen binnenlezen, moet er gebruik gemaakt worden van een DALI interface. Op deze interface, met geïntegreerde voeding, kunnen ook maximaal 64 DALI ballasten aangesloten worden. Als laatste dient nog een RS-485 module toegevoegd te worden die een seriële verbinding maakt met de antenne, deze antenne moet ook met 24 V gevoed worden. De EnOcean modules, die zoals eerder uitgelegd niet gevoed moeten worden, kunnen dan draadloos verbinden op de antenne.

5.1.2 Uitvoering Demokoffer Aangezien de markt van gebouwenautoma sering nog maar weinig vraag toont naar EnOcean producten, toch niet binnen industriële projecten, zi en er geen in de demokoffer vervat. Echter een veel gebruikte combina e is verlich ng aansturen via DALI en schakelcomponenten aansturen en binnenlezen via KNX, deze combina e wordt voorgesteld in de demokoffer. In figuur 5.2 wordt een foto van de demokoffer afgebeeld.

31

Figuur 5.2: Demokoffer

1. Automaat : Deze wordt gebruikt om de 230V voeding van de ballasten te schakelen zodat indien de DALI interface niet gebruikt wordt de lampen kunnen uitgeschakeld worden. 2. Voeding : De 24V voeding die de PLC, de switch en de KNX gateway voedt. 3. PLC : Als PLC wordt een ILC 130 van Phoenix Contact gebruikt. 4. DALI interface : Om het DALI netwerk te sturen wordt gebruik gemaakt van een DALI PWR PAC, deze voorziet een gepaste voeding voor de DALI bus. In deze DALI PWR PAC wordt reeds één DALI master voorzien maar er kan nog uitgebreid worden tot vier DALI masters. Om verder uit te breiden moet opnieuw een DALI PWR PAC geplaatst worden. 5. DALI ballasten : Op de achterzijde van het paneel zijn de drie DALI ballasten gemonteerd, deze sturen telkens twee lampen aan. 6. Switch : De switch wordt gebruikt om te connecteren tussen de PLC, de KNX gateway, de KNX programmeermodule en eventueel nog een PC. 7. KNX gateway : Dit is een nieuwe KNX-to-ethernet gateway die Phoenix Contact op de markt brengt. 8. KNX voeding : Aangezien het hier toch om een demokoffer gaat wordt een voeding gebruikt van 160 mA, hier kunnen dus zes en toestellen op aangesloten worden. 9. KNX programmeermodule : Met deze module kunnen de KNX componenten geconfigureerd worden met het ETS4 programma.

32

5.2 DALI configura e BACL Light Configurator (BLC) is een configura etool die kan gebruikt worden om alle ballasten, aangesloten op de Dali-module, te configureren. Elke ballast kan volledig ona ankelijk ingesteld worden en de ballasten kunnen gegroepeerd worden, zodat een gezamelijke aansturing ook mogelijk is. De configura e tool werkt over ethernet via de PLC en gebruikt de DALI PWR PAC als master. Er bestaan ook configura etools die gebruik maken van een Universal Serial Bus (USB) interface die zelf als master fungeert, de DALI PWR PAC wordt dan uitgesloten als master. Aangezien de BLC de DALI PWR PAC als master gebruikt moet er connec e gemaakt worden. Dit gebeurt door een cyclische task aan te maken, genaamd DALI, die draait op een cylus jd van 20 ms. Deze task voert cyclisch de instance van het programma DALI uit, in dit programma dient de DALI_Server func eblok te staan (figuur 5.3). Per DALI master of dus per DALI lijn moet zo'n task gemaakt worden. Het is belangrijk dat alle namen correct zijn, anders bestaat de mogelijkheid dat de BLC niet zal werken.

Figuur 5.3: DALI configura e : opbouw in PC Worx

Met de globale variabelen IN_dwPDDali en OUT_dwPDDali wordt de link naar de hardware gelegd. Nadat dit programma in de PLC gedownload is en deze in RUN mode staat, kan de BLCso ware opgestart worden. Om te starten moet het IP-adres van de PLC ingegeven worden, vervolgens wordt dit scherm verkregen : figuur 5.4.

33

Figuur 5.4: BLC : Startpagina

Om een lijn te configureren dient met de rechter muisknop de op e 'Go Online And Sync' gekozen worden, vervolgens zal deze lijn groen gearceerd worden. Een op e die nu mogelijk is, is een wire test. Hierdoor worden alle lampen op de lijn zichtbaar, indien er lampen niet knipperen die wel tot deze lijn behoren kan het zijn dat de Dali bus ergens onderbroken is. Nu bestaan er drie mogelijkheden om ballasten op de bus te zoeken : • Find exis ng ballasts : Dit wordt gebruikt indien er al ballasten over een adres beschikken, op deze manier kunnen deze ballasten hun adres behouden. Eerst moeten de reeds bestaande ballasten gezocht worden, pas hierna kan de keuze 'Find new ballasts' gebruikt worden. • Find new ballasts : Hiermee worden de ballasten gezocht die nog geen adres hebben, deze ballasten worden een willekeurig adres toegekend. • Find all ballasts : Hierbij worden alle ballasten gezocht en een nieuw willekeurig adres toegekend. Van iedere ballast kunnen afzonderlijke instellingen gedaan worden, deze se ngs worden afgebeeld in figuur 5.5. De ingestelde se ngs worden dan gedownload naar de bijhorende ballasten.

34

Figuur 5.5: BLC : Se ngs ballast

• Max level • Min level : Het laagste minimum niveau blij het fysisch minimum niveau die ook in de se ngs staat. • Power-on level : Als de voeding aangelegd wordt zal de ballast met dit niveau aangestuurd worden. • System failure level : Bij het falen van de PLC of bij het onderbreken van de bus zal de ballast op dit niveau aangestuurd worden. • Fade me : Hoe snel of hoe traag de ballasten mogen veranderen van niveau. • Fade rate : In hoeveel stappen per seconde de ballasten mogen veranderen van niveau. • Set new dim level : Met de schui alk kan de ballast aangestuurd worden. • Dali Groups : De ballasten kunnen onder één of meerdere groepen ondergebracht worden. • Dali Scenes : Hierover later meer uitleg. De ballasten kunnen elk apart in de se ngs een groep toegewezen krijgen, maar ze kunnen ook in de startpagina in bepaalde groepen gesleept worden. Een volgende mogelijkheid is het indelen van scènes. Dit laatste wordt overbodig aangezien er een PLC gebruikt wordt die alles stuurt. Als alles ingesteld staat zullen de gewijzigde instellingen geel gearceerd zijn.

35

Figuur 5.6: BLC : Instellingen i.v.m. groepen en scènes

De instellingen moeten nu gedownload worden enerzijds naar de File Transfer Protocol (FTP)-server van de PLC en anderzijds naar de ballasten. Vervolgens kunnen de DALI groepen rela ef gemakkelijk aangestuurd worden met de func eblokken die Phoenix Contact voorziet in de BACL bibliotheek.

5.3 KNX configura e KNX is eigenlijk een protocol dat geen nood hee aan een PLC die als master en centrale intelligen e alles gaat binnenlezen en sturen. Bij KNX zit de intellegen e in de KNX componenten met andere woorden verspreide intelligen e in plaats van centrale intelligen e. Deze KNX componenten vereisen uiteraard een aantal instellingen zodat ze met elkaar kunnen communiceren. Aangezien deze instellingen via een so ware gebeuren, is er een configura e of programmeer component nodig. Er bestaan een aantal mogelijkheden : • Ethernet interface : Niet te verwarren met de KNX gateway, de configura e module kan enkel de configura e downloaden in de componenten. Het nadeel aan deze module is dat er eigenlijk nog een andere configura e module nodig is om de ethernet gebaseerde module een IP-adres te geven. • Seriële interface : Aangezien nog weinig computers een seriële poort hebben, wordt deze module weinig gebruikt. • USB interface : Dit is de beste oplossing aangezien elke computer een aantal usb-poorten hee en er geen extra instellingen moeten gebeuren.

36

Figuur 5.7: KNX USB interface

De so ware die gebruikt wordt om alle componenten te programmeren heet ETS. ETS is ontwikkeld door de KNX Associa on en is de enige so ware die kan gebruikt worden. Op die manier hee de KNX Associa on ook in de hand welke fabrikanten welke producten op de markt mogen brengen. Daarom verschilt KNX van elke andere open standaard binnen gebouwenautoma sering, alle componenten hebben een gemeenschappelijke programma e. Binnen Catael wordt gewerkt met de meest recente versie van ETS, namelijk ETS4. Nog vooraleer een nieuw project aangemaakt wordt, moet de interface met het KNX netwerk bepaald worden zoals afgebeeld in figuur 5.8. In dit voorbeeld wordt gebruik gemaakt van een Ethernet interface, over de gehele masterproef werden alle opgesomde interfaces wel eens toegepast.

Figuur 5.8: Verbinden met een Ethernet interface

Als alle instellingen correct verlopen zijn en de communica e posi ef getest geweest is, mag een nieuw project aangemaakt worden. De ETS omgeving wordt opgedeeld in de netwerk topologie en de logische structuur. In de netwerk topologie (figuur 5.9) komt de structuur terug die uitgelegd werd in de theorie rond KNX 2.2.4.

37

Figuur 5.9: Netwerk topologie

Op een lijn kunnen dan verschillende deelnemers toegevoegd worden. Om dat te kunnen doen moet er eerst een catalogus van producten van een bepaalde fabrikant toegevoegd worden. Er zijn al heel wat fabrikanten die KNX producten maken, als deze de goedkeuring van de KNX Associa on krijgen dan mag hun productendatabase als ETS file uitgebracht worden. Een aantal fabrikanten waarmee gewerkt werden jdens de masterproef : GIRA, ABB, Schneider Electrics, Siemens. Als de catalogus toegevoegd werd in ETS dan kunnen producten vanuit de catalogus op een lijn gesleept worden (figuur 5.10).

Figuur 5.10: Een KNX deelnemer op een lijn ze en

Deze component kan vervolgens volledig geconfigureerd worden met het tabblad parameters, zoals in figuur 5.11. De fabrikanten voorzien bij ieder toestel enorm veel parameters, maar meestal hoeven ze niet allemaal ingesteld te worden. Onder de component worden de ac es opgelijst die deze kan uitvoeren, aan de hand van de parameters kunnen meer ac es toegevoegd worden.

38

Figuur 5.11: Instelbare parameters van een component

Opdat deze ac es op de bus zouden verschijnen en herkend worden door actuatoren moeten logische groepadressen aangemaakt worden. Dit gebeurt uiteraard in het tabblad groepadressen zoals in figuur 5.12.

Figuur 5.12: Groepaddressen

De opbouw van deze logische adressen is volledig a ankelijk van de gebruiker, iedere programmeur zal dit anders indelen. Vervolgens kan de ac e van de component gelinkt worden aan de logische groep. Vervolgens als de ac e uitgevoerd wordt zal een bit, byte of twee bytes, a ankelijk van de ingestelde parameters, op de KNX bus verschijnen samen met het gelinkte groepadres. Deze procedure moet voor alle KNX componenten op het netwerk gebeuren. Tenslo e moeten alle parameters, adressen, ac es en bijhorende groepadressen gedownload worden naar de componenten op het netwerk. Elke deelnemer moet apart gedownload worden, opdat ETS zou weten naar welke component dit moet gebeuren, is er een programmeerknop (figuur 5.13) die moet ingedrukt worden.

39

Figuur 5.13: Programmeerknop op een KNX component

De meest efficiënte manier om alle componenten te programmeren is om dit op voorhand te doen voor ze geplaatst worden. Zo niet moeten alle componenten één voor één uitgehaald worden om vervolgens op de programmeerknop te drukken en terug te monteren. Dit laatste leidt natuurlijk naar vele verloren uren.

40

6

Prak sche Implementa e

6.1 So ware bibliotheek 6.1.1 KNX-to-Ethernet gateway Een trend binnen de gebouwenautoma sering is het integreren van een PLC in het netwerk. Phoenix Contact hee daarom een KNX-to-Ethernet gateway uitgebracht die de PLC over ethernet met het KNX netwerk verbindt. De gateway wordt afgebeeld in figuur 6.1.

Figuur 6.1: KNX-to-Ethernet gateway van Phoenix Contact

Naast een gateway naar KNX is het ook een gateway naar BACnet, wat ook een communica eprotocol is voor gebouwenautoma sering. Het toestel bevat ook een USB memory s ck datalogger met ingebouwde FTP-server. Vervolgens kan er ook serieel verbonden worden met een RS-485 interface en een RS-232 interface. Tenslo e is er nog een I/O interface voorzien voor het binnennemen van tellerpulsen van energiemeters en het aansturen van LED's. In opdracht van Phoenix Contact werd de KNX-to-Ethernet gateway getest, zowel hardwarema g als so warema g. Omdat deze nieuwe ethernet-to-KNX gateway volledig past in het concept van gebouwenautoma sering, werd deze geïntegreerd in de demokoffer. Phoenix Contact had enkele KNX componenten opgestuurd zodat de testen grondig konden uitgevoerd worden.

6.1.2 Hardwarema ge testen Eerst en vooral werd de hardware getest, enerzijds de configura e van de gateway, anderzijds de werking in corresponden e met de reeds bestaande so ware bibliotheek. De configura e van de gateway gebeurt zeer vlot via de webpagina, zoals afgebeeld in figuur 6.2

41

Figuur 6.2: Configura e van de gateway

Op de webpagina moeten enkele instellingen gedaan worden in verband met de ethernet connec e, dit is voornamelijk het ip-adres aanpassen. Bij de gateway was al een so warebibliotheek voorzien die zeker moest werken in combina e met de gateway. Na enkele testen bleek dat de PLC wel de juiste berichten naar de gateway stuurde maar dat de gateway er onregelma g op reageerde. Er haperde iets in de opstart van het toestel, a eelding 6.3 toont welke berichten noodzakelijk zijn voor de opstart.

Figuur 6.3: Ini alisa e van de gateway

Het probleem was dat na het sturen van bericht 4, niet al jd het gewenste antwoord '$07' teruggestuurd werd. Hierdoor star e de gateway constant opnieuw op. Na een mee ng met de fabrikant werd dit probleem opgelost.

42

Na het opstellen van een eigen so ware bibliotheek werd er nog een fout in de hardware gevonden. Namelijk bij het versturen van een byte kan deze niet hoger zijn dan 63 of 16#3F hexadecimaal. Het hee waarschijnlijk te maken met het feit dat het getal 63 als '111111' binair voorgesteld wordt en het getal 64 als '1000000', wat één bitje meer is. Figuur 6.4 toont welke berichten gestuurd moeten worden om een byte te schrijven.

Figuur 6.4: Commando om een byte te schrijven

Dit werd eens bekeken in Wireshark, figuur 6.5 toont wat de PLC stuurt om het getal 63 of 16#3F te schrijven.

Figuur 6.5: Sturen van het commando met data 63

Vervolgens wordt dit bericht vanuit de gateway naar de PLC teruggestuurd (figuur 6.6). Dit is de rou ne zoals deze beschreven staat in de theore sche procedure.

43

Figuur 6.6: Antwoord vanuit de gateway

Als dit gebeurt met de data 16#40 dan stuurt de PLC het volgend bericht (figuur 6.7). Dit bericht klopt volledig met de vooropgelegde structuur, het probleem komt dus niet vanuit de PLC.

44

Figuur 6.7: Sturen van het commando met data 64

Vervolgens wordt er een fout bericht verstuurd vanuit de gateway naar de PLC (figuur 6.8), het is dus duidelijk dat er nog ergens een fout in de hardware zit.

Figuur 6.8: Fout antwoord vanuit de gateway

Deze laatste fout in de harware is voorlopig nog niet opgelost.

6.1.3 So warema ge testen Phoenix Contact had ook een so ware bibliotheek opgestuurd met de vraag of deze zou voldoen om de gateway aan te sturen en zo niet om zelf een bibliotheek samen te stellen. Het bleek al vlug dat de so ware bibliotheek niet de meest ideale was om het KNX netwerk via de gateway aan te sturen. Eerst werd er een hele jd gespendeerd aan het uitpluizen naar de werking van de reeds bestaande bibliotheek. Vervolgens kon de stap gezet worden om

45

zelf een so ware bibliotheek te maken. KNX_Server Met de KNX_Server figuur 6.9 wordt een client-server verbinding opgesteld met de bestaande IP_Connect funceblok van Phoenix Contact.

Figuur 6.9: KNX_Server

Daarop moet het IP adres als ingang voorzien worden, de poort waarop geconnecteerd moet worden is 6416. In de vorige so ware bibliotheek moest het IP adres als vier aparte integers ingevuld worden, dit is nu vereenvoudigd tot een string. Vervolgens moet een IP_Send en een IP_Receive func eblok ingevoegd worden zodat berichten verstuurd en ontvangen kunnen worden. Vervolgens moeten een aantal berichten verstuurd worden om de opstart tot stand te brengen (figuur 6.3 en 6.10).

Figuur 6.10: Opstart procedure

46

Als stap 4 of 7 goed verlopen zal de gateway op een bericht wachten tot ini alisa e. Dit commando wordt uitgevoerd in andere func eblokken per groepadres die communiceren met de KNX_Server. KNX_Byte en KNX_nByte

Figuur 6.11: KNX_Byte

Nu de gateway opgestart is moeten de groepadressen nog geïni aliseerd worden, dit gebeurt in de KNX_Byte en in de KNX_nByte gezien dit de twee basisblokken zijn. Om deze ini alisa e te doen moet het volgend commando gestuurd worden : figuur 6.12.

Figuur 6.12: Ini alisa e en vervolgens luisteren op de bus

Zoals voorgesteld moet de PLC het commando 'trs' met bijhorend groepadres sturen en zal de gateway antwoorden met het commando 'tei' samen met de ini ële data. Het commando 'trs' kan ook gebruikt worden om op ieder moment de status van een groepadres uit te lezen.

47

In figuur 6.4 worden de commando's getoond om data naar een groepadres te sturen. Commando 1 zal gebruikt worden om één byte te versturen, commando 2 zal gebruikt worden om meerdere bytes te versturen. Het laatste commando dat gebruikt wordt is 'tdi' (figuur 6.12), dit wordt gestuurd door de gateway als er een groepadres van status veranderd is op het KNX netwerk. KNX_Bit

Figuur 6.13: KNX_Bit

Deze func eblok maakt gebruik van de KNX_Byte waarbij enkel de eerste bit aangepast of uitgelezen wordt. KNX_Bit wordt gebruikt om ac es uit te voeren of te registreren van één bit groot, bijvoorbeeld het schakelen van een schakelaar. KNX_Integer

Figuur 6.14: KNX_Integer

Deze func eblok maakt gebruik van de KNX_nByte waarbij enkel het eerste woord aangepast of uitgelezen wordt. KNX_Integer wordt gebruikt om ac e uit te voeren of te registreren van twee bytes groot, bijvoorbeeld het aansturen van een dimbare ballast.

48

KNX_Floa ng_Point

Figuur 6.15: KNX_Floa ng_Point

Deze func eblok maakt gebruik van de KNX_nByte waarbij enkel het eerste woord aangepast of uitgelezen wordt. In tegenstelling tot wat de gewoonte is binnen PC Worx bestaat een floa ng point of m.a.w. een real niet uit vier bytes maar uit twee bytes. Dit zorgt ervoor dat er een algoritme moet gebruikt worden om een woord om te ze en naar een floa ng point. KNX_Floa ng_Point wordt gebruikt om ac e uit te voeren of te registreren van twee bytes groot, bijvoorbeeld het binnenlezen van een lichtsterkte of temperatuur.

49

6.2 Industrieel project Catael hee een opdracht van Phoenix Contact gekregen om een gebouw met labo's van Pfizer te voorzien van KNX en DALI. Het gaat om een volledig nieuw gebouw op de cite van Pfizer in Louvain-La-Neuve. Het gebouw bestaat uit vier verdiepingen, 500 KNX schakelaars, 600 DALI ballasten en ongeveer 120 bewegingsmelders. Er wordt verdiep per verdiep afgewerkt en aangezien enkel het eerste verdiep afgewerkt was, kon enkel daar alles geïnstalleerd worden. Het eerste verdiep bestaat uit 67 bewegingsmelders en 100 schakelaars op KNX en 184 ballasten op DALI. Aangezien er meer dan 64 KNX deelnemers aanwezig zijn, zijn er meerdere KNX voedingen nodig, drie van 640 mA om precies te zijn alsook twee buskoppelaars. Voor DALI worden de ballasten opgesplitst in vier lijnen, dit wil zeggen dat er vier DALI masters nodig zijn. Op lijn 1 zi en 54 ballasten, op lijn 2 37 ballasten, op lijn 3 39 ballasten en op lijn 4 54 ballasten. Aangezien het hier over gebouwenautoma sering gaat, hee Pfizer gevraagd om enkele scenario's te programmeren. Er wordt gesproken over zones met langdurige beze ng zoals bijvoorbeeld de labo's en zones met kortstondige passage zoals bijvoorbeeld de gangen. Scenario's voor zones met langdurige beze ng Als de bewegingsmelders niets detecteren moeten de bijhorende verlich ngselementen uitgeschakeld worden. Als er beweging gedetecteerd wordt moet de verlich ng naar 50% gebracht worden, vervolgens kan met de schakelaar van die zone de verlich ng verder gedimd worden. Als er geen beweging meer gedetecteerd wordt dan zullen de ballasten na een bepaalde jd terug naar 0% zakken. Stel dat de bewegingsmelder stuk is dan moet met één duw op de schakelaar de verlich ng naar 50% gebracht worden. Vervolgens kan ook weer van 50% tot 100% gedimd worden. Scenario's voor zones met kortstondige passages Als de bewegingsmelders niets detecteren moeten de bijhorende verlich ngselementen uitgeschakeld worden. Als er beweging gedetecteerd wordt moet de verlich ng naar 100% gebracht worden. Wordt er geen beweging meer gedetecteerd dan zullen de ballasten na een bepaalde jd terug naar 0% zakken. Indien de bewegingsmelder stuk is dan kan met de schakelaar de verlich ng naar 100% gebracht worden. Aanpak Er wordt gestart met het configureren van de DALI lijnen, door een DALI configura etool te gebruiken konden alle ballasten een adres krijgen. Deze ballasten dienen per lokaal in een logische groep gestopt te worden zodat ze gezamelijk vanuit de PLC aangestuurd kunnen worden. Vervolgens moet ook het KNX netwerk geconfigureerd worden, door een programmeermodule aan te sluiten op het netwerk kon dit aan de hand van ETS gebeuren. Voor iedere KNX deelnemer moeten dus een aantal parameters ingesteld worden, deze konden dan vervolgens naar het respec evelijke toestel gedownload worden. Nu hadden alle toestellen, zowel DALI als KNX, een adres, dus kunnen ze vanuit de PLC aangestuurd worden. Op deze manier hebben de gateway en de so ware bibliotheek een industriële test op grote schaal voorgeschoteld gekregen. Deze hebben ze beiden glansrijk doorstaan, tot op heden zijn er nog geen klachten geweest.

50

7

Conclusies

Het was bij de start van deze masterproef moeilijk om eenduidig de doelstellingen te bepalen. Aangezien gebouwenautoma sering een ruim begrip is, is het niet eenvoudig om er een onderwerp uit te kiezen. Na eens samen te zi en met de promotoren zijn we tot de vier eerder geformuleerde doelstellingen gekomen. Door de doelstellingen stap voor stap aan te pakken, ben ik toch tot een mooi eindresultaat gekomen. Aangezien KNX en EnOcean al geves gde waarden binnen de gebouwenautoma sering zijn, is er veel informa e beschikbaar. DALI is echter een nieuwe speler waar nog weinig informa e rond te vinden is, maar aangezien dit een eenvoudig protocol is verliep de protocolstudie toch vlot. Zowel Howest als Catael zullen deze protocolstudie nog kunnen gebruiken voor opleidingen aan klanten en studenten. De demokoffer bevat nu drie DALI ballasten en een ethernet-to-KNX gateway waaraan een achterliggend KNX netwerk kan gekoppeld worden. Met deze demokoffer kan Catael demonstra es en opleidingen aanbieden aan bedrijven. Met deze demokoffer kunnen ook nieuwe KNX toestellen getest worden aangezien er standaard niets op de KNX bus aangesloten is. Een eventuele verbetering naar de toekomst toe is het integreren van enkele EnOcean toestellen. De nieuwe gateway en so ware bibliotheek voor KNX zijn zo veel mogelijk op punt gesteld geweest door te testen met de demokoffer. Beide werden ook getest in een grootschalig industrieel project, dit verliep ook vrij vlot. Catael zal deze so ware bibliotheek ook in volgende projecten kunnen implementeren. Op basis van mijn bevindingen, aanpassingen en uitbreidingen werd een rapport gemaakt voor Phoenix Contact. Ondertussen is de library op basis van mijn studies volledig aangepast. De implementa e binnen een industrieel project hee voor heel wat feedback aan Catael gezorgd. Dit was het eerste project waar Catael de besproken KNX gateway geïmplementeerd hee , dit hee heel wat kinderziektes aan het licht gebracht. Met deze feedback zal later misschien met een iets andere aanpak aan een project begonnen worden.

51

Literatuurlijst [1] ``Knx system specifica ons,'' 2009. [2] I. H. Capoen, ``Industriële automa sering,'' in Cursus Factory and Process Automa on, 2010. [3] M. Grampp, Digitally Addressable Ligh ng Interface (DALI) Unit Using the MC68HC908KX8. Grampp R & D HB, Skimmelvagen 14 SE-252 86 Helsingborg Sweden, v 3.0 ed., 2002. [4] ``Enocean radio protocol,'' 2011. [5] ``Enocean serial protocol 3,'' 2011.

52