Masterproef Link a Lot

Masterproef Link a Lot Studiegebied Industriële wetenschappen en technologie Opleiding Master of Science in de industriële wetenschappen: elektrotechniek Afstudeerrich ng Automa sering Academiejaar 2011-2012 Niels Tanghe Academische bachelor- en masteropleidingen, Graaf Karel de Goedelaan 5, 8500 Kortrijk

Masterproef Link a Lot Studiegebied Industriële wetenschappen en technologie Opleiding Master of Science in de industriële wetenschappen: elektrotechniek Afstudeerrich ng Automa sering Academiejaar 2011-2012 Niels Tanghe Academische bachelor- en masteropleidingen, Graaf Karel de Goedelaan 5, 8500 Kortrijk

Voorwoord In het kader van het behalen van het diploma Master of Science in de industriële wetenschappen: elektrotechniek, afstudeerrich ng automa sering werd deze masterproef gerealiseerd met als tel 'Link a Lot'. Voor het realiseren van deze masterproef had ik het genoegen op enkele mensen beroep te kunnen doen. Door deze mensen was ik in staat deze masterproef tot een goed einde te brengen. Vooreerst bedank ik het team van Catael en in het bijzonder mijn externe promotor dhr. Nikolas Taelman. Zij toonden geduld bij het helpen en ondersteunen van deze masterproef. In het bijzonder richt ik ook een woord van dank aan mijn interne promotor dhr. Henk Capoen. Hij maakte jd vrij om mij bij te scholen, te helpen en mee te denken. Ook jdens het maken van voorstellingen of het schrijven van deze scrip e kon ik al jd bij hem terecht. Ook wil ik graag nog dhr. Dieter Vandenhoeke bedanken voor het ondersteunen en meehelpen aan deze masterproef. Tenslo e wil ik graag mijn familie en vriendin bedanken om mij de kans te geven, deze opleiding te volgen. Zonder deze steun zou ik deze opleiding en masterproef nooit tot een goed einde gebracht hebben. i

Abstract Link a Lot is a project where several different aspects and possibili es of data logging are brought together. Implemen ng a new product from Phoenix Contact called AXWeb, a few smaller projects were created to analyse the possibili es and benefits of the product. AXWeb is mainly a regular SQL-server that is able to store data gathered from PLC's spread over the internet. In addi on to the SQL-server, AXWeb also provides a webservice. This provides a webpage that is hosted on the server. This webpage can be used to view or manipulate data. One of the strengths of the product is the possibility to configure the webpage online, in any browser. No knowledge of any programming so ware is required. ii

Lijst met a or ngen 3 3G 3th Genera on A AJAX AP APN ASP Asynchronous JavaScript And XML Access Point Access Point Name Ac ve Server Pages C CIM Computer Integrated Manufacturing F FK FTP Foreign Key File Transfer Protocol I ID ILC IP ipc IPsec IT Iden fica on InLine Controller Internet Protocol Industrial PC IP Security Informa on Technology iii

L LAN LED LLC Local Area Network Light Emi ng Diode Logical Link Control M MAC MDI mguard Media Access Control Medium Dependent Interface Machine Guard N NAT Network Address Transla on O OLE OPC Object Linking and Embedding OLE for Process Control P PC PK PLC PLS PMA PSK Personal Computer Primary Key Programmable Logic Controller Physical Signaling Physical Medium A achment PreShared Key R RFC RTE RTU Remote Field Controller Real-Time Ethernet Remote Terminal Unit iv

S SCADA SIM SMS SOD SQL Supervisory Control And Data Acquisi on Subscriber Iden ty Module Short Message Service Send On Delta Structured Query Language T TCP Transmission Control Protocol U UPS Uninterrupted Power Supply V VPN Virtual Private Network W WAN WYSIWYG Wide Area Network What You See Is What You Get X XML extensible Markup Language v

Inhoudsopgave 1 Inleiding 1 1.1 Bedrijfsvoorstelling.......................................... 1 1.2 Probleemstelling........................................... 1 1.3 Doelstellingen............................................ 2 1.4 Projectaanpak............................................ 2 2 Datalogging 4 2.1 Voorbereiding............................................ 4 2.2 Opbouw centrale server....................................... 6 2.3 Medium................................................ 7 2.3.1 LAN.............................................. 7 2.3.2 WAN............................................. 7 2.3.3 Mobiel telefoonnetwerk................................... 8 2.4 Data visualiseren........................................... 9 3 AXweb 10 3.1 Doelstelling.............................................. 10 3.2 Opbouw en interne werking..................................... 10 3.3 Logging................................................ 11 3.4 Visualisa e.............................................. 13 3.4.1 Omgeving.......................................... 14 3.4.2 Pagina's editeren....................................... 14 3.4.3 Koppelen van data...................................... 15 3.4.4 Usermanagement...................................... 16 3.4.5 Tijdzones........................................... 17 4 Opgebouwde applica es 18 4.1 Inleiding................................................ 18 4.2 Industriële applica e......................................... 18 4.3 4-op-een-rij-robot.......................................... 20 4.4 Kleinere applica es.......................................... 22 4.4.1 Hoofdbord.......................................... 22 4.4.2 Blower............................................ 25 4.4.3 Meetkoffer.......................................... 27 4.4.4 Profinet sta on met UPS................................... 29 4.4.5 Datalogger met automa sche hardwareconfigura e.................... 30 4.4.6 Visualisa e.......................................... 30 5 Security 31 5.1 Inleiding................................................ 31 5.2 Theore sche begrippen....................................... 31 5.2.1 Por orwarding........................................ 32 5.2.2 Firewall............................................ 33 5.2.3 VPN.............................................. 34 5.3 Prak sche uitwerking......................................... 38 5.3.1 Vanuit bedrijfsnetwerk.................................... 40 vi

5.3.2 Van buitenaf......................................... 41 6 Resultaat 42 6.1 Xplore New Automa on Award 2012................................ 42 6.2 AXweb................................................ 44 7 Conclusie 47 7.1 Wedstrijdverloop........................................... 47 7.2 Catael................................................. 47 7.3 Howest................................................ 47 vii

Lijst van tabellen 2.1 Voorbeeld van gelogde data..................................... 6 4.1 Kenmerken van Interbus....................................... 19 viii

Lijst van figuren 1.1 Catael logo.............................................. 1 1.2 AXweb logo.............................................. 2 2.1 Analoge waarde........................................... 5 2.2 Analoge waarde met interval..................................... 5 2.3 Analoge waarde met hysteresis................................... 5 2.4 Rela onele database......................................... 6 2.5 Netwerkconfigura e LAN....................................... 7 2.6 Netwerkconfigura e WAN...................................... 8 2.7 Netwerkconfigura e met mobiel telefoonnetwerk......................... 9 3.1 Opbouw van een AXweb server................................... 10 3.2 Principe van datacompressie..................................... 11 3.3 Communica e tussen func ebouwstenen.............................. 12 3.4 Interne communica e........................................ 13 3.5 Inlogscherm.............................................. 13 3.6 Editor................................................. 14 3.7 Fieldeditor.............................................. 15 3.8 Elementeditor............................................ 15 3.9 Verbindingseditor........................................... 16 4.1 Overzicht............................................... 18 4.2 InterBus principe........................................... 19 4.3 InterBus opstelling.......................................... 20 4.4 4-op-een-rij.............................................. 21 4.5 4-op-een-rij-principe......................................... 21 4.6 Demostand.............................................. 22 4.7 Algemeen principe.......................................... 23 4.8 WLAN-client............................................. 24 4.9 Inclina esensor met CANOpen.................................... 24 4.10 OSI-model toegepast op CAN(Open)................................. 25 4.11 Principeschema blower........................................ 26 4.12 OSI-model toegepast op Modbus.................................. 27 4.13 Principeschema meetkoffer..................................... 27 4.14 EmPro als energiemeter....................................... 28 4.15 Principeschema Profinetsta on................................... 29 4.16 Flexibiliteit bij Log-IC......................................... 30 5.1 Communiceren doorheen CIM-piramide............................... 31 5.2 NAT-tabel............................................... 32 5.3 Firewall................................................ 33 5.4 Leased lines met koper of glasvezel................................. 34 5.5 Leased lines met straalverbinding.................................. 35 5.6 IPsec in het OSI-model........................................ 36 5.7 Transportmode............................................ 36 5.8 Tunnelmode............................................. 37 ix

5.9 Cer ficaten.............................................. 38 5.10 Demo opstelling security....................................... 39 5.11 mguard................................................ 40 6.1 Xplore New Automa on Award 2012-1............................... 42 6.2 Xplore New Automa on Award 2012-2............................... 42 6.3 Xplore New Automa on Award 2012-3............................... 43 6.4 Xplore New Automa on Award 2012-4............................... 43 6.5 De gelogde ac es van de 4 op een rij-robot in Howest....................... 44 6.6 Actuele waarden uit de luchtwasser in Merksplas.......................... 44 6.7 Overzicht van de demostand..................................... 45 6.8 Actuele waarden van de energiemeter op de demostand...................... 45 6.9 Grafiek van de spanning van de UPS-ba erij............................. 46 x

1 Inleiding 1.1 Bedrijfsvoorstelling Deze masterproef werd gerealiseerd in samenwerking met Catael. Catael staat in voor de engineering, programma e en implementa e van automa seringsprojecten. In 2007 werd Catael opgericht door Henk Capoen en Nikolas Taelman. De combina e van jarenlange exper se in automa sering en een frisse kijk hierop maakt van hen een sterk team. Samen met enkele jonge, bekwame ingenieurs vervullen ze zeer uitdagende automa seringsopdrachten. Catael is zowel te vinden in de gebouwenautoma sering, installa es in de waterwereld, als in de industriële automa sering. Het is als student een echt voorrecht om te mogen samenwerken met een sterk groeiende speler op de automa seringsmarkt. Meer informa e kan gevonden worden op h p://www.catael.be of via info@catael.be. [1] Figuur 1.1: Catael logo 1.2 Probleemstelling Het loggen van data begint steeds vaker standaard te worden in de industriële wereld. Het vindt zijn weg in de meest uiteenlopende toepassingen. Zo kan logging terug gevonden worden in de wereld van de hernieuwbare energie, gebouwenautoma sering en industriële installa es. De reden hiervoor is niet ver te zoeken; het opvolgen en loggen van procesparameters kan zorgen voor een verhoging van de produc viteit, het efficiënter aansturen van installa es, kwaliteitsgaran e of de mogelijkheid bieden tot an ciperen op mogelijke meldingen of storingen. Om dit mogelijk te maken moet er eerst data ter beschikking zijn. Hiervoor zijn er talloze meetsystemen en sensoren op de markt die aangesloten kunnen worden op een Programmable Logic Controller (PLC). De sensoren zijn meestal via verscheidene protocollen te benaderen zoals RS485, Modbus, Ethernet Transmission Control Protocol (TCP)/Internet Protocol (IP),.... Naast het loggen is het meestal gewenst dat ook parameterdata op afstand gewijzigd kan worden. Deze parameters zijn in vele gevallen reeds beschikbaar in de PLC. Daarna moeten zowel parameter- als procesdata beschikbaar worden gesteld voor de gebruiker. De vraag naar het loggen op een centrale server s jgt progressief. Hier kan ook voor verscheidene mogelijkheden geopteerd worden: het gebruik van een File Transfer Protocol (FTP)-server, Structured Query Language (SQL)-server, het zenden van een email of Short Message Service (SMS),.... Deze servers kunnen zich enerzijds in het bedrijfsnetwerk bevinden maar anderzijds ook ergens 'op het internet' gesitueerd zijn. Waar geen internetaanslui ng ter beschikking is, kan er geopteerd worden om te loggen over het (mobiel) telefoonnetwerk. Eenmaal de data op een centrale plaats ter beschikking is, wil de gebruiker de data kunnen bekijken aan de hand van grafieken, tabellen, etc. En dit alles van zowel binnen het bedrijfsnetwerk als van buitenaf. In beide gevallen moet er voor gezorgd worden dat elke gebruiker enkel en alleen de data ziet die voor hem of haar bedoeld is. 1

Deze masterproef brengt de verschillende mogelijkheden van logging in kaart. Dit aan de hand van een nieuw visualisa e/serverpakket AXweb, ontworpen door Phoenix Contact. Anderzijds worden ook verschillende industriële veldbussen geïmplementeerd die gebruikt worden om data te verzamelen. 1.3 Doelstellingen Deze masterproef is een deelname aan de Xplore New Automa on Award 2012. Deze wedstrijd, die uitgaat van Phoenix Contact - Duitsland, ondersteunt meer dan 100 interna onale teams die hun automa seringsideeën mogen verwezenlijken. In het voorjaar van 2011 werd het voorstel ingediend, waarna deze geselecteerd werd om het te mogen uitwerken voor de wedstrijd [2]. Het voorstel bestond uit twee grote delen: Enerzijds het verzamelen van data in een PLC. Deze data komt van allerhande plaatsen; een opera onele, industriële applica e waar procesparameters ter beschikking zijn. Ook wordt een remote 4 op een rij-robot ingezet die zijn ac es logt en op afstand bespeelbaar is. Verder worden enkele kleinere applica es ingezet om data te verzamelen. Daarvoor worden PLC's gebruikt die sensoren uitlezen, gebruik makende van verschillende veldbussen (CANbus, InterBus, Profibus, Modbus Remote Terminal Unit (RTU), Modbus TCP, RS485). Naast de standaard veldbussen wordt ook Profinet ingezet als Real-Time Ethernet (RTE)-communica emiddel. Anderzijds moet deze data op een centrale server gelogd worden. Hiervoor wordt voor een nieuw visualisa epakket van Phoenix Contact gekozen. Het pakket 'AXweb' is gebaseerd op een zelf-onderhoudende database. Eenmaal de controllers hun data in de database geplaatst hebben, is het pakket in staat om de gegevens te verwerken tot grafieken, tabellen,.... Deze worden dan ter beschikking gesteld op het internet. Zodat enkel de bevoegde persoon de data kan bekijken of manipuleren. Figuur 1.2: AXweb logo 1.4 Projectaanpak Vooreerst werd een grondige studie gedaan van de AXweb server en de daarbij horende func ebouwstenen die in de PLC geïmplementeerd worden. Zowel de opbouw van de database als het communiceren over SQLcommando's werden onder de loep genomen. Daarnaast werden de mogelijkheden van de webinterface uitgetest en de verschillende soorten van datavoorstellingen gehanteerd. Na een grondige studie van het AXweb-product werd er op zoek gegaan naar één of meerdere applica es die het nut ervan kunnen bewijzen. Zo was een klant van Catael geïnteresseerd in het AXweb-concept. Deze klant hee een installa e beschikbaar waar vele sensoren aanwezig zijn; een uitgelezen kans om echte, grote hoeveelheden data te kunnen loggen. Hierbij zal ook het concept van datacompressie aan bod komen. Zie hiervoor hoofdstuk 3. Om een voorbeeld te geven van 'remote control' en datalogging werd een bestaande 4-op-een-rij-robot omgebouwd tot een van op afstand bestuurbaar spel. Het 4-op-een-rij-spel bestaat uit een XYZ-tafel die gele of rode blokken kan verplaatsen op een spelbord. De motoren van deze applica e worden aangestuurd door een Remote Field Controller (RFC) van Phoenix Contact. Het programma dat hierin aanwezig is, is erop voorzien dat alles via 2

OLE for Process Control (OPC) gecommuniceerd wordt. Daarnaast werd ervoor gezorgd dat alles kon worden gevolgd met een IP-camera. Ook is het mogelijk met een zelfgeschreven applica e ac es te ondernemen die dan door een logging-plc worden behandeld, zodat in AXweb alle ze en zichtbaar zijn. Uiteindelijk werd er voor de wedstrijd Xplore ook nog een a rac eve demostand gebouwd die logging en communica e over veldbussen in de kijker moest ze en. Zo werd er gekozen om via allerhande protocollen enkele uiteenlopende sensoren uit te lezen en daarna ook in de AXweb server te loggen. 3

2 Datalogging Het proces waarbij informa e verzameld wordt van sensoren, verwerkt en opgeslagen wordt, noemt datalogging. Door de hoge eisen die gesteld worden, zoals de grote hoeveelheden data en de hoge nauwkeurigheid, wordt hier meestal voor een PLC, Personal Computer (PC) of Industrial PC (ipc) gekozen. 2.1 Voorbereiding Voor het starten met een loggingsproces, moeten eerst enkele zaken in acht genomen worden. Vooreerst wordt er afgevraagd welke types logging inzetbaar zijn. Hierbij zijn er verschillende mogelijkheden met elk hun func onaliteiten: Alarm/event logging: bij dit type loggen, zorgt de so ware ervoor dat er gelogd wordt als er zich een alarm of gebeurtenis voordoet. Elk event/alarm gaat gepaard met enkele parameters om de oorzaak en plaats van de fout te traceren. Zo zal zeker een mestamp aanwezig zijn, alsook de plaats en ernst van de fout. Eventueel wordt ook de parameter meegegeven die de fout triggerde. Trend logging: Hier worden geselecteerde procesparameters opgevolgd. Dit zal gebruikt worden om parameters van de sturing of de kwaliteit van het eindproduct te controleren. Report logging: Dit omvat het dagelijks, wekelijks of maandelijks rapporteren van procesparameters (berekende waarden kunnen ook toegevoegd worden). On demand logging: De operator kan een jdelijke logfunc e inschakelen. Dit om kort de machine te kalibreren of te controleren. De operator kan dan bijvoorbeeld waarden zien in de vorm van grafieken, real me waardes, tabellen,.... [3] Enkele zaken moet in acht genomen worden bij trend of demand logging. Digitale in- of uitgangen vormen meestal geen probleem. Ze kunnen gelogd worden telkens ze een statusverandering ondergaan. Dit gaat niet op voor analoge waardes. Zij hebben de eigenschap om constant te veranderen. Meestal is het niet gewenst om bij de minste verandering te loggen. Dit zou kunnen leiden tot een overbelast netwerk of een te grote hoeveelheid aan data in de server. Stel dat een analoge waarde een verloop kent zoals in figuur 2.1, dan zal zonder enige maatregel zeer veel overbodige informa e gelogd worden. Iedere cyclus jd zal de PLC de analoge waarde uitlezen. Indien een buffer in de controller aanwezig is, zal hier jdelijk alle data worden opgeslagen en dan in één geheel verzonden worden naar de server. Als er echter geen buffer aanwezig is, zal de PLC de data zo snel mogelijk naar de server versturen. Snelheden hier zijn a ankelijk van de verwerkingssnelheid van de server. 4

Figuur 2.1: Analoge waarde Om overtollige logging te vermijden is er nood aan enige intelligen e om te beslissen wanneer analoge waardes gelogd worden. Er kan beslist worden om te loggen op jdsbasis. Tussen elke waarde zit een vast interval, zoals te zien op figuur 2.2. Figuur 2.2: Analoge waarde met interval Loggen op basis van een jdsinterval kan nog al jd een overtollige hoeveelheid aan data bezorgen. Het instellen van een hysteresis kan hierbij een oplossing bieden. Enkel wanneer een analoge waarde buiten de aanvaardbare grenzen komt, zal er gelogd worden. Dit zorgt ervoor dat er minder data moet opgeslagen worden in de server, waardoor de server wat kleiner kan gedimensioneerd worden. Ook wordt de poten ële overbelas ng van het netwerk verholpen. Deze manier van loggen hee nog een ander voordeel. Áls er gelogd wordt, kan er al vanuit gegaan worden dat een warning zal gegenereerd worden. Een nadeel is dat binnen de hysteresis geen data beschikbaar is. Figuur 2.3: Analoge waarde met hysteresis Andere triggerop es en hun combina es zijn uiteraard ook mogelijk. Eenmaal dit alles beslist is, is loggen mogelijk. Een mogelijke entry in de database is te zien in tabel 2.1. 5

Tabel 2.1: Voorbeeld van gelogde data Timestamp Type Categorie Plaats Parameter Status 2011/10/12 12:34:55 Event Process Boiler Temp 15 High 2011/11/10 6:02:14 Alarm Process Turbine Vibra on High 2012/01/04 12:3:1 Command User Substa on Circuit breaker Closed Als alle data in de server aanwezig is, kan een bovenliggend pakket hiervan gebruik maken om een visualisa e op te bouwen. 2.2 Opbouw centrale server Een tradi onele database kan mysql zijn, SQL-server, Microso Acces, Oracle. Een PLC kan hierin data lezen, schrijven, aanpassen of verwijderen door gebruik te maken van SQL-commando's. Deze databases kunnen gebaseerd zijn op verschillende data modellen: hiërarchisch model; rela oneel model; object model; extensible Markup Language (XML) model; etc. Een veel gebruikt model is de rela onele database. Een voorbeeld is te zien in figuur 2.4. Figuur 2.4: Rela onele database Hierin zijn drie tabellen te onderscheiden. Elk van deze tabellen stelt een object voor; een PLC, een func ebouwsteen en een waarde. Elk object wordt gekenmerkt door verschillende parameters. Vooreerst wordt aan elk object een Iden fica on (ID) toegekend. Deze wordt de Primary Key (PK) genoemd. De logica van de database kent deze automa sch toe aan iedere entry in de tabel. Zo wordt ervoor gezorgd dat geen enkele entry dezelfde ID meekrijgt zodat elke ingave uniek is. Daarnaast kan er een structuur opgebouwd worden. In figuur 2.4 wordt voorgesteld dat een of meerdere waarden toegekend zijn aan een func ebouwsteen. Deze func ebouwsteen kan dan weer gelinkt zijn aan een PLC. Elke waarde kan maar tot één func ebouwsteen behoren zodat in de parameterlijst van 'Waarde' een extra kolom wordt gecreëerd. In de kolom 'Foreign Key (FK)1' wordt de PK geplaatst van de func ebouwsteen waartoe deze waarde behoort. Hetzelfde geldt voor de func ebouwsteen die tot een PLC behoort. 6

2.3 Medium 2.3.1 Local Area Network (LAN) Indien de data binnen een bedrijf of site ter beschikking gesteld moet worden, bestaat de keuze om de server niet van een internetverbinding te voorzien. Daarbij is de server geconnecteerd op het bedrijfsnetwerk of een automa seringsnetwerk. Alle data vanuit PLC's, PC's,... wordt verzameld op een centraal punt in het bedrijf. Hier zullen de verworven gegevens dienst doen als logging of kunnen parameters beïnvloed worden. Een mogelijk principeschema is te zien in figuur 2.5. Figuur 2.5: Netwerkconfigura e LAN Zo kan het bijvoorbeeld dat verschillende PLC's aanwezig zijn in het automa seringsnetwerk die hun gecollecteerde data versturen naar de server. Eenmaal dit gebeurd is, is het mogelijk om met de PC deze data te bekijken, te analyseren,.... 2.3.2 Wide Area Network (WAN) Ook is het mogelijk om de server op het internet ter beschikking te stellen. Zo kunnen geografisch gescheiden applica es toch met de server communiceren. Daarbij is het mogelijk dat een verantwoordelijke data van thuis uit kan opvragen waardoor gepast en snel op een stoornis gereageerd kan worden. Indien dit geïmplementeerd moet worden, moeten enkele zaken zeker in acht genomen worden. Zo moet er gezorgd worden dat de verantwoordelijke de server kan bereiken. Mede moet er ook voldoende beveiligd worden zodat geen onbevoegde personen toegang hebben tot de server/data. Om dit te bereiken, worden routers ingeschakeld. Deze scheiden twee netwerken en zorgen dat de onderliggende structuur voor de buitenwereld niet bekend wordt. Een mogelijke implementa e is te zien op figuur 2.6. 7

Figuur 2.6: Netwerkconfigura e WAN Dezelfde func onaliteit in het netwerk wordt behouden als bij paragraaf 2.3.1; PLC's zenden data naar de server. Daarnaast is ook een verbinding gelegd met een router. De zijde waar het bedrijfsnetwerk aan gekoppeld is, wordt de LAN-zijde genoemd. De andere zijde, die in verbinding staat met het internet, wordt de WAN-zijde genaamd. Indien de server van buitenaf bereikt moet worden, dient het IP-adres van de router bekend te zijn. Dit zou als eerste security-maatregel kunnen gerekend worden, alhoewel het een zeer zwakke is. Verdere security maatregels kunnen geïmplementeerd worden. Hiervoor wordt verwezen naar hoofdstuk 5. 2.3.3 Mobiel telefoonnetwerk Naast het (bedrade) internet, is het ook mogelijk om via het mobiel telefoonnetwerk toegang tot het internet te verkrijgen. Zo wordt, op de plaats waar in voorgaande voorbeelden de aanslui ng van het internet was, een modem geplaatst met antenne. Deze bevat één of meerdere (redundan e mogelijk) Subscriber Iden ty Module (SIM)-kaart(en). Door de antenne kan de modem toegang tot het mobiel telefoonnetwerk verkrijgen (iden ek zoals dit met een GSM zou gebeuren). Indien de modem dit toelaat, kan ook gekozen worden om te connecteren op een 3Gnetwerk, welke een hogere data-throughput hee. Eenmaal geconnecteerd, is het mogelijk om via het Access Point Name (APN) toegang te verkrijgen tot het internet. Figuur 2.7 toont hoe de implementa e mogelijks kan gebeuren. [4] 8

Figuur 2.7: Netwerkconfigura e met mobiel telefoonnetwerk 2.4 Data visualiseren De data die terecht komt in de server kan op verscheidene manieren opgevraagd worden. Vooreerst zijn er tal van so ware-pakke en ter beschikking. Deze kunnen standaard verbindingen met servers aanmaken en sluiten wanneer nodig. Ook moet hierbij (bijna) niet geprogrammeerd worden, enkel geconfigureerd. In de meeste gevallen is geen kennis omtrent het opbouwen van SQL-queries vereist. Een nadeel zou hier de kost aan licen es kunnen zijn. Een andere manier is het zelf maken van een visualis e vanuit bijvoorbeeld een.net-omgeving. Hierbij is wel enige kennis vereist omdat de programmeur zelf instaat voor de verbinding, query-opbouw en datamanipula e. Het voordeel van zelf een programma te creëeren is de vrijheid. Hierdoor kan de so ware op maat gemaakt worden en zullen geen overbodige zaken het systeem belasten. Wat als een nadeel kan aanschouwd worden, is het feit dat deze manier verschillende implementa es kent naargelang de persoon die het schrij. 9

3 AXweb 3.1 Doelstelling AXweb is een webgebaseerd monitoringsysteem, gebaseerd op Ac ve Server Pages (ASP).NET en Asynchronous JavaScript And XML (AJAX). Het is een SQL-server met daarboven een 'visualisa epakket'. Van een visualisa epakket kan niet echt gesproken worden, daar er niets moet gemaakt worden, enkel geconfigureerd. Daarboven komt de volledige configura e van de visualisa e in de server terecht. Zowel pagina-achtergronden, knoppen, links en a eeldingen worden in de server opgeslagen. Zo is het mogelijk om de ganse server en visualisa e te verplaatsen door middel van het exporteren van één enkele database. [5] De versie waarmee gewerkt werd in deze masterproef, is nog steeds de demoversie. Daardoor is het volledige pakket nog niet vertaald naar het Engels (of andere talen) waardoor alles in het Duits weergegeven wordt. 3.2 Opbouw en interne werking Figuur 3.1: Opbouw van een AXweb server De opbouw en werking kan best verklaard worden aan de hand van figuur 3.1. De SQL-database beschikt over allerhande tabellen. Elke PLC die geconnecteerd is met de server, beschikt over een inbox-tabel. De PLC communiceert via deze tabel naar de server toe. Het schrijven vanuit de server naar een PLC gebeurt aan de hand van 10

één gezamelijke outbox-tabel. Elke PLC leest cyclisch deze data en kijkt indien deze moet opgehaald worden. Naast de server draait een service die de tabellen onderhoud. Deze zorgt dat de informa e uit de inbox tabellen verwerkt en in de correcte tabellen geplaatst wordt. Zo kunnen bijvoorbeeld tabellen geconfigureerd worden die zuivere data opslaan voor logging-doeleinden. Deze zuivere data zijn de waarden die de PLC cyclisch verzendt (bijvoorbeeld om de 10 seconden). Indien deze data om de 10 seconden gedurende een jaar gelogd wordt, is er (te) veel data die bijgehouden moet worden, terwijl dit in de meeste gevallen niet gewenst is. Daarom werd het begrip datacompressie ingevoerd. Zo kan de service, die de verwerking doet, geconfigureerd worden om extra tabellen aan te maken (te zien in figuur 3.2). Er kan bijvoorbeeld ingesteld worden dat de ruwe data 3 uur bijgehouden wordt. Voor ieder uur kan het gemiddelde berekend worden en weggeschreven worden in een nieuwe tabel. Zo is het mogelijk om telkens verder te gaan in compressie om de datahoeveelheid op de server te beperken. Figuur 3.2: Principe van datacompressie Uiteindelijk zijn er dan ook nog de tabellen waarin de configura e geschreven staat die elke pagina van de visualisa e omschrijven. Elke bu on, label, image,... wordt hierin opgeslagen. Ook het gehele user-management komt hierin terecht. Boven de server draait een webservice die een website host. Het is deze website die de visualisa e van de server ter beschikking stelt. Van hieruit kunnen lees- en schrijfac es uitgevoerd worden. Deze ac es worden daarna door AXweb doorgegeven aan de desbetreffende PLC('s). 3.3 Logging De PLC dient van enkele func ebouwstenen voorzien te zijn om AXweb te implementeren. Vooreerst moet een communica eblok geïmplementeerd worden. Deze legt de connec e met de database op basis van een IP-adres en een poortnummer. Daarnaast moet ook de tabelkeuze ingegeven worden. Iedere PLC moet voor de server uniek adresseerbaar zijn waardoor een naam voor de controller moet opgegeven worden. Verder zijn nog tal van func ebouwstenen beschikbaar om data te kunnen verzenden. AXweb kent drie belangrijke groepen: het verzenden en ontvangen van integers, reals en strings. Een belangrijke parameter op deze func ebouwstenen (uitgezonderd bij de string-func ebouwstenen) is Send On Delta (SOD). Dit betekent dat de func ebouwsteen pas ini a ef tot verzenden zal nemen indien één van de waarden een afwijking kent, die groter of gelijk is aan de SOD-waarde ten opzichte van de vorige gelogde waarden. Naast deze func onaliteiten kent AXweb ook nog andere mogelijkheden zoals de func ebouwsteen 'Ping'. Deze houdt in dat PLC zich om een bepaalde jd moet melden aan de server. Indien dit niet gebeurt, wordt de PLC 11

beschouwd als 'Niet verbonden'. Dit kan voorgesteld worden met een mestamp in een message table. Ook kan vanuit de server een tabel worden doorgestuurd naar een PLC met daarin de taken (met bijhorende jdsstempel) die deze moet uitvoeren. Figuur 3.3: Communica e tussen func ebouwstenen In de PLC verloopt de communica e onderling aan de hand van eenzelfde variabele. De variabele in de PLC is van het type STRUCT; een verzameling van allerhande basisvariabelen. Bij het koud starten van de PLC zoekt de communica ebouwsteen naar de verschillende AXweb-bouwstenen die aanwezig zijn in het programma. Indien de eerste aangesproken wordt, wordt het type doorgezonden alsook de naam van de func ebouwsteen naar de communica ebouwsteen. Daarna voorziet de communica ebouwsteen de andere van een volgnummer. Dit wordt herhaald voor alle volgende func ebouwstenen tot geen enkele meer reageert op het register-bericht. In regime, spreekt de communica ebouwsteen iedere func ebouwsteen apart aan (te zien in figuur 3.4). Indien deze over data beschikt die verzonden mag worden, wordt dit doorgestuurd naar de communica eblok. Deze zal het bericht ontleden en die data in een SQL-query plaatsen. De query wordt op zich dan verstuurd naar de inbox van de server, die dan de rest voor zich neemt. Na iedere AXweb-cyclus kijkt de communica ebouwsteen ook als er geen berichten aanwezig zijn in de outbox van de server. Indien data aanwezig, wordt dit doorgestuurd in de volgende AXweb-cyclus naar de desbetreffende func ebouwsteen. 12

Figuur 3.4: Interne communica e 3.4 Visualisa e Indien de webpagina als gebruiker opgevraagd wordt, is een gebruikersnaam en wachtwoord vereist, zoals te zien is op figuur 3.5. Indien deze gebruiker enkel gemach gd is om pagina's te bekijken, zullen de func es van de editor niet zichtbaar zijn. Indien wel gemach gd, dan handelen volgende paragrafen over het gebruik van de editor. Figuur 3.5: Inlogscherm 13

3.4.1 Omgeving Figuur 3.6: Editor Op figuur 3.6 zijn de verschillende onderdelen van het hoofdscherm van de editor te zien: 1. werkbalk voor snelnavagita e; 2. menubalken; 3. werkblad, weergave van huidige pagina; 4. indica e indien de server bezig is met data te verwerken. Bij een eerste opstart van AXweb, is standaard één lege pagina aangemaakt die als mainpagina ingesteld staat. Van hieruit kunnen dan verscheidene ac es ondernomen worden: nieuwe pagina's toevoegen (al dan niet gebaseerd op templates), instellingen in verband met verbonden PLC's, elementen toevoegen aan of verwijderen uit de pagina, etc. 3.4.2 Pagina's editeren Indien een nieuw element aangemaakt wordt op een pagina, dient een plaats gekozen te worden binnen het raster (te zien op figuur 3.6). Van hieruit wordt dan de fieldeditor geopend zoals in figuur 3.7. 14

Figuur 3.7: Fieldeditor Zo zijn er drie delen te onderscheiden in de fieldeditor (figuur 3.7). Vooreerst een oplijs ng met de elementen die al toegekend zijn aan deze coördinaten in het raster. Hier kunnen er ook toegevoegd worden, alsook de volgorde gewijzigd worden. Er kan uit verscheidene standaardelementen gekozen worden: a eeldingen, knoppen, tekst, menu's, kalender, grafieken, tabellen,.... Daarnaast bevindt zich een preview van de cel waarop deze elementen gelden. Als laatste is er ook een snelnaviga emenu. 3.4.3 Koppelen van data Indien data vanuit een PLC op een pagina zichtbaar moet zijn, kan een tekstelement aan de pagina toegevoegd worden. Een voorbeeld van de in te stellen eigenschappen bij een tekstelement is te zien op figuur 3.8. Figuur 3.8: Elementeditor Er kunnen font-instellingen gemaakt worden en het formaat waarin de tekst komt kan aangepast worden. Met dit formaat is in te stellen hoe getalwaarden voorgesteld worden (het aantal cijfers na de komma, wetenschappelijke nota e, procentnota e). Daarnaast is ook te zien dat er een prefix en een suffix mogelijk is. Dit om bijvoorbeeld 15

de eenheid van de parameter mee te geven; deze wordt dan dynamisch na de waarde geplaatst. In de rechterkolom is een instelling van allerlei dynamische parameters mogelijk. De belangrijkste is het koppelen aan een variabele uit de PLC (Datenverbindungen festleggen). Figuur 3.9 toont een voorbeeld hoe dit menu er kan uitzien. Figuur 3.9: Verbindingseditor Op deze pagina zijn volgende onderdelen te onderscheiden: 1. Opsomming van de eigenschappen die veranderd kunnen worden; 2. Koppelen van data als in- of output van de PLC; 3. 'Verbinden' toont de oorsprong van de waarde (intern of extern), 'Rückmeldung' staat in voor de garan e van echtheid van de waarde; 4. Snelmenu. Zo kan niet alleen tekst ingesteld worden maar ook andere eigenschappen zoals hoogte, breedte, offset, zichtbaarheid,.... Daarna moet deze eigenschap gekoppeld worden aan de waarde van een PLC. Indien de data a oms g is van de controller dient 'Eingang' geselecteerd te worden. Als de data echter naar de PLC geschreven moet worden, wordt 'Ausgang' geselecteerd. Eenmaal de PLC gekozen, moet ook de func ebouwsteen geselecteerd worden waar deze waarde te vinden is, om uiteindelijk de variabele te kunnen selecteren. 3.4.4 Usermanagement Op elke pagina kan ingesteld worden welke gebruiker gemach gd is om deze te zien of te editeren. Daarnaast kan voor elk element op de pagina ook ingesteld worden welke gebruiker of gebruikersgroep deze te zien krijgt. Er kunnen instellingen gemaakt worden per persoon; GSM-nummers en emailadressen kunnen opgegeven worden. Zo kan hier ingesteld worden wie een email of SMS krijgt als er iets verkeerd gaat bij een bepaalde installa e. Indien een SMS dient verzonden te worden, moet een PLC wel verbonden zijn met de server die zich voordoet als 'SMS-centrale'. Deze beschikt dan over een connec e naar het (mobiele) telefoonnetwerk. 16

3.4.5 Tijdzones Een belangrijke eigenschap van AXweb is hoe het omgaat met verschillende jdzones. Stel, een PLC staat in voor de centrale verwarming, die om 8u00 opstart, in een gebouw in de Verenigde Staten. Met AXweb is het mogelijk om deze star jd in te stellen in Europa, zonder rekening te houden met verschillen in jd. Wel is het belangrijk dat de jdzone van de controller correct ingesteld staat. 17

4 Opgebouwde applica es 4.1 Inleiding Na een grondige studie van AXweb werden enkele kleinere projecten uitgewerkt om de mogelijkheden van het pakket in kaart te brengen. Op figuur 4.1 is te zien dat de AXweb server opgesteld is in Catael in Bellegem. Verder werden verscheidene opstellingen en installa es gebruikt om de eigenschappen en grenzen van AXweb te ontdekken. Figuur 4.1: Overzicht Zo werd de AXweb-server in Catael opgesteld en werden verder drie applica es gedefinieerd: een industriële applica e in Merksplas, een 4 op een rij-robot in Howest en een mobiele demostand. 4.2 Industriële applica e Één van de klanten van Catael was geïnteresseerd in AXweb en stemde in om een deel van hun installa e ter beschikking te stellen, om een democoncept te ontwikkelen. Deze klant beschikt over een installa e in Merksplas, die mest verwerkt van varkens en kippen. In dit systeem zit een luchtwasser verwerkt die ervoor zorgt dat de uitgestoten lucht aan de vooropgestelde kwaliteit voldoet. Het spreekt voor zich dat in dit onderdeel een behoorlijk aantal sensoren aanwezig zijn. Hier zijn onder andere luchtdruk-, temperatuur- en Ph-sensoren terug te vinden. Deze sensoren zijn verspreid over de gehele installa e zodat de nood aan een goede veldbus zich opdrong. Één van de eisen waaraan de veldbus moet voldoen, is het overbruggen van meer dan 400 meter tussen twee veldbuseilanden. Deze eis was dan ook doorslaggevend om te kiezen voor Interbus, gestuurd door een Phoenix Contact PLC. Enkele karakteris eken van InterBus zijn te zien in tabel 4.1. 18

Tabel 4.1: Kenmerken van Interbus Topologie Logische dataring, elektrisch opgebouwd als boomstructuur Fysieke snelheid 500Kbps, 2Mbps voor speciale doeleinden Access Single master / gesynchroniseerd shi register ( jdmul plex) Maximum IO punten 8192 Maximum modules 512, maximum 254 deelnemers op de remote bus Maximale buslengte 12,8 kilometer elektrisch, 80 kilometer op sch Er wordt elektrisch een logische ring opgebouwd zoals te zien is in figuur 4.2. Een master verstuurt een telegram via DO2. De eerstvolgende slave leest dit bericht, haalt de data uit het telegram die voor hem bedoeld is en plaatst zijn meest recente data op diezelfde plaats. Daarna wordt dit verstuurd via DO2 van deze slave. Ook de volgende slave zal het bericht herkennen en handelen naar de opdrachten die het gekregen hee. Stel dat deze tweede slave de laatste in de InterBus-kring is, dan wordt dit automa sch gedetecteerd. DO2 wordt automa sch doorgekoppeld naar DI2, waarna de chip dit verzendt over zijn DO1 uitgang. De oorspronkelijk eerste slave neemt op DI2 de data binnen en verstuurd het terug op DO1 waarna de InterBus master het telegram terugkrijgt via DI2. In dit telegram is dan de meest recente data van alle slaves aanwezig. [6] Door het feit dat elke slave zich gedraagt als een versterker voor de volgende, kan makkelijk begrepen dat Inter- Bus hier primeert op andere veldbussen. Zo worden afstanden gegarandeerd van 400 meter tussen twee Interbus slaves. Figuur 4.2: InterBus principe Na het kiezen van InterBus, werden rondom de installa e kleinere schakelkasten geplaatst met daarin InterBuseilanden. Op die eilanden zijn temperatuur-, druk- en Ph-sensoren aangesloten. Een schema sch overzicht van deze opstellingen is te zien in figuur 4.3. 19

Figuur 4.3: InterBus opstelling Vanuit de PLC vertrekt een Interbuskabel die Interbuseilanden verbindt, alsook Fieldbus gateways van enkele drives. In totaal moet de PLC 30 drives besturen, 70 analoge ingangen verwerken en 150 digitale in- en uitgangen respec evelijk lezen en sturen. De controller beschikt ook over een Ethernet-aanslui ng waardoor deze gemakkelijk geconnecteerd kan worden op het internet. Eenmaal deze connec e er is, kan een verbinding gelegd worden met de AXweb server die in Catael (Bellegem, Kortrijk) opgesteld staat. Data wordt verzameld overheen Interbus en verwerkt om daarna verzonden te worden naar de server. Door het opnemen van deze applica e in Link a Lot wordt de nadruk gelegd op het correct loggen van grote hoeveelheden data. Met correct loggen wordt bedoeld dat geen onnodige data in de server terecht komt. Het instellen van triggers was noodzakelijk om geen overmaat aan data over het internet te verzenden en de server onnodig te belasten. Ook werd in de server een op male manier ingesteld om data bij te houden. Zo zijn voor elke set aan waarden datacompressieniveaus ingesteld waardoor het loggingsinterval tussen twee me ngen groter wordt naarmate er verder in de geschiedenis teruggekeken wordt. 4.3 4-op-een-rij-robot Onder het luik remote control en remote diagnose werd een 4-op-een-rij-robot omgebouwd tot een op afstand bespeelbare machine. Deze robot wordt gebruikt in labosessies in de afstudeerrich ng automa sering in Howest, campus Graaf Karel de Goedelaan. Het spel bestaat uit een speelveld van zes rijen en zeven kolommen, een magazijn waar de niet gebruikte pionnen in terecht komen en een score-indica e. De pionnen worden verplaatst door een portaalrobot, zoals te zien is op figuur 4.4. 20

Figuur 4.4: 4-op-een-rij In de labosessies is het de bedoeling om de PLC en drives te aanzien als een blackbox. Er moet een applica e aangemaakt worden in een.net-omgeving waarin de logica van het spel terechtkomt. Communica e tussen PLC en applica e verloopt via OPC. Voor deze masterproef werd de opstelling uitgebreidt met een IP-camera en een 3th Genera on (3G)-modem. Deze uitbreiding zorgt ervoor dat 4-op-een-rij van op afstand (over het internet) bespeelbaar is. Door het feit dat de internet-security van Howest het niet toelaat om een verbinding te leggen vanop het internet naar een toestel in het schoolnetwerk, moest gebruik gemaakt worden van het mobiel telefoonnetwerk. Zo werd een 3G-modem van Phoenix Contact geïmplementeerd die de verbinding met het internet tot stand bracht. Verder werd een logging-plc toegevoegd die elke ac e ontvangt en deze doorzendt naar de AXweb-server in Catael. Figuur 4.5: 4-op-een-rij-principe 21

Op figuur 4.5 is de structuur van de aangepaste 4-op-een-rij te zien. Het originele programma dat gemaakt werd in de labosessies werd gebruikt als basis voor het nieuwe programma. Deze basis was de spellogica met OPC-Client. Op diezelfde PC werd ook de OPC-server geplaatst. Deze OPC-server communiceert met de PLC (hier een RFC van Phoenix Contact) die instaat voor het uitvoeren van de ze en. Voor deze masterproef werd boven het bestaande programma een TCP-server geplaatst. Hierop kan geconnecteerd worden van buitenaf, om commando's uit te wisselen die ac es en beves gingen voorstellen. Ook werd via dit kanaal de camerabeelden verzonden. Daarnaast beslist het programma wanneer wat gelogd moet worden (berichten, ze en en alarmen). Indien iets gelogd moet worden, wordt dit doorgezonden naar de logging-plc via de OPC-server. Deze zendt het bericht op zijn beurt door naar de AXweb server. 4.4 Kleinere applica es Aangezien de Xplore New Automa on Award zich afspeelde in Bad Pyrmont in Duitsland, was er nood aan een fysiek tastbare opstelling waarmee enkele kenmerken van datalogging naar voor gebracht werden. Hierbij was het doel van de opstelling om data te verzamelen vanuit allerhande sensoren die, via verscheidene protocollen, communiceren met de hoofd-plc. Deze controller zorgt er dan weer voor dat de data naar de AXweb server gelogd worden. Figuur 4.6: Demostand 4.4.1 Hoofdbord Het volledige principe van de opstelling is te zien in figuur 4.7. Het gearceerde deel symboliseert de componenten die deel uitmaken van het hoofdbord. 22

Figuur 4.7: Algemeen principe Netwerk Het eerste bord dat te zien is op figuur 4.6 is het hoofdbord (1). Deze is voorzien van de hoofd-plc die logt naar de AXweb-server. Deze moet van een internetverbinding voorzien zijn om te kunnen connecteren met de server. Daarom werd een WLAN-client van Phoenix Contact (figuur 4.8) gemonteerd. Deze beschikt over een antenne om op een draadloos netwerk te connecteren en de controller toegang tot het internet te verschaffen. 23

Figuur 4.8: WLAN-client Daarnaast werden heel wat andere PLC's geïmplementeerd. Deze staan echter niet in verbinding met de server maar verzenden hun data, via allerhande protocollen, naar de hoofdcontroller. Daarenboven wordt, in het kader van mobiliteit, voor deze connec es Bluethooth Access Point (AP)'s gebruikt. Siemens PLC Ook op het eerste bord wordt data 'gegenereerd'. Daarom werd onderaan een Siemens-PLC gemonteerd die beschikt over een naderingssensor. Deze naderingssensor is aangesloten op de analoge ingangsskaart van de PLC en verscha een stroomwaarde evenredig met de afstand tot het eerste object in diens gezichtsveld. Deze waarde wordt over Ethernet TCP/IP verzonden naar de hoofd-plc. CAN Verder werd ook het CAN-protocol en bovenliggend CANOpen-protocol geïmplementeerd. Hiervoor werd een inclina esensor gebruikt zoals in figuur 4.9. Deze werd aangesloten op een CAN-master; een nieuwe communica ekaart van Phoenix Contact die nog niet uitgetest was voor het CANOpen-protocol. Figuur 4.9: Inclina esensor met CANOpen Het verschil tussen CAN-bus en CANOpen kan verduidelijkt worden aan de hand van het OSI-model of ISO-OSImodel (ISO Reference Model for Open System Interconnec on)(figuur 4.10). Het gearceerde deel in de figuur stelt het terrein voor dat gedefinieerd is voor CAN-bus. Zo behoort de volledige datalinklaag tot CAN-bus. Dit zijn de Media Access Control (MAC)-laag (die instaat voor frame-opbouw, busarbitrage en fout a andeling) en Logical Link Control (LLC)-laag (welke zorgt voor de filtering van berichten, overload berichten herkennen en het herstellen van de bus). Verder zijn het enkel Physical Medium A achment (PMA) (beschrijven van de transceiver) en Physical Signaling (PLS) (staat in voor bit ming, synchronisa e en encoding) van de fysieke laag waarvoor CAN-bus een invulling 24

voorziet. Dit betekent dat CAN-bus niet vastlegt welke kabels of connectoren aangeraden worden. Wel zijn dan verschillende standaarden, zoals de ISO 11898-2 en CiA DS-102, die hier een mogelijke invulling aan kunnen geven. Verdere lagen worden door CAN-bus niet ingevuld. Figuur 4.10: OSI-model toegepast op CAN(Open) Een beperking van CAN-bus zijn de 8 bytes data die maar kunnen verzonden worden per bericht. Ook moeten nodes geconfigureerd kunnen worden over het netwerk en moet diagnose mogelijk zijn. Door dit alles werd onder andere CANOpen in het leven geroepen. Deze beschrij de applica elaag. CANOpen zal van CAN-bus gebruik maken en aanvullend enkele nieuwe func onaliteiten invoegen. Zo wordt bij CANOpen een structuur in het geheugen opgebouwd; de object dic onary. Zo hee elke parameter die ingesteld kan worden (fabrikantgegevens, datatypes, instellingen, etc.) een index en een eventuele subindex die aangesproken kunnen worden. [7] Overige Om de stand wat interac ef te maken, werd een Light Emi ng Diode (LED)-bar geïnstalleerd die aangestuurd wordt over Ethernet TCP/IP. Deze LED-bar is voorzien van verschillende modes, kleuren en ac es die aangestuurd kunnen worden via EnOcean-schakelaars. Deze schakelaars zijn draadloos en beva en geen ba erij. Met de energie die vrijkomt indien de knop ingedrukt of losgelaten wordt, wordt een bericht verzonden naar de EnOceanontvanger. Deze wordt dan door de hoofd-plc binnengelezen via de RS485-communica ekaart. Als laatste werd nog een Visu+-scherm van Phoenix Contact op het eerste bord gemonteerd. Dit zal dienst doen als interface om parameters in te stellen en op te volgen, alsook diagnose van het Ethernet-netwerk te verkrijgen. 4.4.2 Blower In figuur 4.11 zijn terug in het gearceerde deel, de componenten terug te vinden van het tweede bord met 'de blower'. 25

Figuur 4.11: Principeschema blower Info Bij de blower zijn twee plexi buizen aanwezig die bovenaan met elkaar verbonden zijn door een railsysteem. De bedoeling is dat een plas ek bal in een van de buizen zit en dat een blower deze bal via de rail in de andere koker blaast. De blower wordt aangedreven door een motor, gestuurd door een drive. Deze drive wordt bestuurd door een PLC, over Modbus RTU. Verder is nog een op sche sensor aanwezig, om te controleren of de bal daadwerkelijk in de tweede buis terechtgekomen is. Indien niet, dan wordt een bericht verstuurd naar de hoofd-plc over Modbus TCP, gebruik makende van Bluetooth. Als laatste is ook een webpanel aanwezig waarmee commando's en modes geselecteerd kunnen worden. Parameters zijn in te stellen via het Visu+ scherm op het eerste bord. Modbus Over hét Modbus-protocol kan niet gesproken worden daar enkel de applica elaag van het OSI-model een invulling krijgt. Onderliggend kunnen verschillende implementa es en protocollen plaatsvinden. Zo worden voor 26

Modbus RTU de onderliggende lagen ingevuld als RS232/485. Daartegenover steunt Modbus TCP op Ethernet TCP/IP. Figuur 4.12: OSI-model toegepast op Modbus 4.4.3 Meetkoffer Figuur 4.13: Principeschema meetkoffer 27

De voeding van de demostand wordt voorzien vanuit een driefasig net (3x400V + N). Vooraleer de spanning doorgeschakeld wordt naar de aparte borden, moet het eerst door de meetkoffer (zie 3 op figuur 4.6). Deze is voorzien van een InLine Controller (ILC) van Phoenix Contact met een RS485-communica ekaart. Deze kaart zorgt voor de Modbus RTU-connec e met de energiemeter (zie figuur 4.14). Om veiligheidsredenen wordt de spanning naar de andere borden pas doorgeschakeld als de connec e tussen de PLC en de energiemeter opgebouwd is. Ook als de connec e wegvalt, wordt de spanning weggenomen. Figuur 4.14: EmPro als energiemeter Verder wordt ook de data verzameld vanuit de energiemeter (spanning, stroom, vermogen, power factor), over Modbus TCP (gebruik makende van Bluetooth) verstuurd naar de hoofd-plc, welke op zijn beurt dit dan kan verzenden naar de AXweb-server. 28

4.4.4 Profinet sta on met UPS Figuur 4.15: Principeschema Profinetsta on Op bord 5, dat te zien is in figuur 4.6 werd een drive geïnstalleerd die beschikt over een Profinet IO-interface. Deze werd bedraad verbonden met de hoofd-plc welke de drive bestuurt. Aan de drive hangt een servomotor die gekoppeld is aan een slede. In de drive zijn enkele posi es geconfigureerd welke afgelopen kunnen worden. Hiervoor zendt de hoofd-plc de gewenste stap naar de drive. De slede zelf werd voorzien van een mobiele applica e. De applica e omvat een Profinet-kopsta on van Phoenix Contact. Deze communiceert over Bluetooth met de hoofd-plc. Daar deze applica e draadloos dient te zijn, wordt alles gevoed vanuit een Uninterrupted Power Supply (UPS). De spanning van de UPS (ideaal gezien 24V) wordt via een spanningsdeler op een analoge ingangskaart geplaatst, die zich in de local bus van het Profinet-kopsta on bevindt. De gemeten spanning wordt door de hoofd-plc binnengenomen over Profinet via Bluetooth. Zolang de UPS voldoende opgeladen is, zal de slede zijn normale posi es doorlopen. Indien de spanning te laag wordt, zal de controller opdracht geven aan de drive om de slede te laten zakken. Eenmaal beneden, is het bord voorzien van een laadsta on waardoor de UPS terug oplaadt. 29

4.4.5 Datalogger met automa sche hardwareconfigura e Naast de AXweb-implementa es werd ter volledigheid een onderdeel toegewijd aan de flexibiliteit inzake logging. Hiervoor werd 'Log-IC' ingezet. 'Log-IC' is een applica e met volledig automa sche hardwareconfigura e. Zowel de hardware is variabel (gemakkelijk toevoegen en verwijderen van IO-kaarten), alsook de so ware (makkelijk toekennen van func es via webbased tool). Deze opstelling is ideaal om te gebruiken bij jdelijke logging waarbij een verandering van configura e vaak voorkomt. Het configureren gebeurt aan de hand van een webpagina die aanwezig is op de PLC. Hier kan ingesteld worden welke ac es wanneer ondernomen worden. Hier kan gekozen worden om een digitale uitgang aan te sturen, te loggen naar een FTP- of SQL-server. [1] Figuur 4.16: Flexibiliteit bij Log-IC 4.4.6 Visualisa e Om aan te tonen dat de data daadwerkelijk in de AXweb-server terecht komt en deze ook gevisualiseerd kan worden, werd een scherm gemonteerd op bord 3, te zien op figuur 4.6. Hier kan de actuele data bekeken worden. Ook enkele grafieken van de UPS zijn ter beschikking waardoor duidelijk wordt waartoe AXweb in staat is. 30

5 Security 5.1 Inleiding Daar alle applica es gebruik maken van het internet en daarmee kwetsbaar zijn, werd ook aandacht besteed aan de security van de opstellingen. Steeds meer wordt dit topic een niet te vermijden onderdeel wanneer er een verbinding met internet is. Zelfs indien het netwerk niet over een internetaanslui ng beschikt, dient er gecontroleerd te worden of het netwerk als veilig wordt beschouwd. Vroeger werden automa seringsnetwerken als alleenstaand geïmplementeerd. Communica e tussen produc e en produc ebeheer was overbodig. Moderne automa seringsnetwerken worden gekenmerkt door open systemen en communica enetwerken, gebaseerd op Ethernet TCP/IP. Zo wordt steeds meer verwacht dat PLC's communiceren met een produc ebeheersysteem, welke zich in de tweede laag in de Computer Integrated Manufacturing (CIM)-piramide bevindt. [8] Figuur 5.1: Communiceren doorheen CIM-piramide Terwijl in de Informa on Technology (IT)-afdeling alle security so warema g geïmplementeerd wordt, is dit niet mogelijk in de automa seringstak. Deze oplossing is moeilijk te implementeren in oudere systemen en zouden de industriële controller te veel belasten. Daarom wordt in automa seringsnetwerken meestal gebruik gemaakt van afzonderlijke hardwaremodules die instaan voor de security van de machine(s). Om deze security toe te passen werd een demo-opstelling gecreëerd. Om de instellingen in de hardwaremodules te verklaren, moeten eerst enkele begrippen verklaard worden. 5.2 Theore sche begrippen In volgende drie paragrafen zullen volgende zaken verklaard worden: 1. por orwarding; 31

2. firewall; 3. VPN. 5.2.1 Por orwarding Bij por orwarding wordt gebruik gemaakt van de Network Address Transla on (NAT)-tabel in de router. Hierbij dient een onderscheid gemaakt te worden tussen de dynamische en sta sche tabel. De dynamische tabel kan niet aangepast of bekeken worden maar wordt onderhouden door de router. Indien een PC een webpagina wil opvragen, wordt een aanvraag ingediend bij de gateway, welke hier een router is. Deze router zal het onderliggend netwerk beschermen en alle verkeer gaat doorheen één IP-adres (deze van de router). Het IP-adres en bijhorende TCP-poort van de aanvrager wordt opgeslaan in een tabel (de dynamische NAT-tabel). In de tabel wordt hieraan een andere poort gekoppeld, die verwijst naar een poort op de router. Als de aanvraag beantwoord wordt, bijvoorbeeld door een webserver, zal dit bericht aankomen bij de router op die laatste poort. De router zoekt in de NAT-tabel de bestemming op en ziet de gegevens van de aanvrager. Hierna hee de router alle gegevens om dit bericht door te zenden naar de aanvrager. Doordat de router onderliggend netwerk beschermt, moet deze weten naar welke aanvrager een antwoord moet teruggezonden worden. Hiervoor wordt het IP-adres gebruikt. De reden waarom ook een TCP-poort opgeslaan wordt, is omdat een PC meerdere applica es hee die een aanvraag kunnen doen. Zo kan een mail-programma ac ef zijn, terwijl een webpagina wordt opgevraagd. Een mogelijke invulling hiervan is te zien op figuur 5.2. Figuur 5.2: NAT-tabel Indien twee PC's zich in het lokaal netwerk bevinden van een router, kunnen die een aanvraag doen om een webserver te bereiken over het internet. Stel dat de PC met IP-adres 192.168.150.2 een webbrowser hee die gebruik maakt van TCP-poort 3600, dan kan deze een verzoek verzenden doorheen de router naar de server. Doordat de 32

router onderliggend netwerk beschermt, zal het IP-adres en poortnummer van deze PC opgeslagen worden in de NAT-tabel. Hieraan koppelt de router een poort van zichzelf die nog vrij is. Indien een antwoord gestuurd wordt naar de router, zal dit op poort 5400 terechtkomen. De router zoekt op in de NAT-tabel en ziet dat de PC met IP-adres 192.168.150.2 daaraan gelinkt is met poort 3600. Zo kan de router het bericht forwarden naar de PC. Hetzelfde geldt voor andere PC's of toestellen die een aanvraag doen naar buitenliggend netwerk. Een sta sche NAT-tabel komt perfect overeen qua opbouw met een dynamische. Het verschil is dat deze regels zelf ingesteld kunnen worden. 5.2.2 Firewall Zowel in de IT-wereld als deze van de automa sering komen firewalls voor. Respec evelijk zullen dit, in de meeste gevallen, so ware- en hardware-firewalls zijn. Volgende paragraaf geldt enkel indien gekozen wordt voor een hardware-invulling van de firewall. Naar werking bestaan verschillende soorten. Het onderscheid kan gemaakt worden door hoe diep een firewall gaat kijken in een bericht om te bepalen of het bericht al dan niet corrupt is. Zo kunnen twee grote groepen gemaakt worden; de stateless en de statefull inspec on firewall. Een stateless firewall screent ieder voorbijkomend bericht oppervlakkig. Enkel herkomst en bestemming worden onderzocht, de inhoud wordt niet bekeken. Zo kan een stateless niet reageren indien er plotseling verdachte inhoud in de berichten aanwezig is, als er bepaalde patronen in te herkennen zijn, etc. Daarnaast staat de veel intelligentere stateful inspec on firewall. Naast de func onaliteiten van een stateless firewall controleert deze ook de inhoud van berichten. Complexe algoritmen onderzoeken een sessie tussen twee deelnemers en zoeken naar verdachte patronen. Ook man-in-the-middle a acks (iemand anders die zich voordoet als zender/ontvanger) kunnen herkend worden. Figuur 5.3: Firewall Stel een opstelling zoals weergegeven in figuur 5.3. Een PLC (192.168.150.2) en een FTP-server zijn aanwezig in een netwerk. De gateway van dit netwerk is een router. Aan de andere zijde van de router is een PC (192.168.100.101) aanwezig. In de router is een firewall ac ef. Deze kan zowel ingesteld worden voor ingaand als voor uitgaand verkeer, gezien vanaf de local-zijde van de router. Figuur 5.3 toont een invulling van een firewall die geldt voor 33

inkomend verkeer (van rechts naar links). A ankelijk van het type router zal de lijst met firewall-rules van onder naar boven of omgekeerd overlopen worden. In een Machine Guard (mguard) wordt deze van onder naar boven overlopen. Zo kan, uit de onderste regel, afgeleid worden dat data, a oms g van eender welk IP-adres naar eender welk IP-adres niet toegelaten wordt. De router zendt ook geen bericht terug naar de aanvrager om de weigering aan te geven. Hier kan ook 'Reject' ingesteld worden, zodanig dat de ontvanger op de hoogte wordt gebracht van de weigering. Op de tweede regel is te zien dat eender welk IP-adres een aanvraag mag doen naar de webpagina (poort 80) van de PLC. Daarboven, in de eerste regel, staat dat enkel het toestel met IP-adres 192.168.100.101 gebruik kan maken van de FTP-server (poort 21). Bij het connecteren met een FTP-server komt een ander voordeel van een stateful inspec on filter naar boven. Zo werd ingesteld dat enkel poort 21 open staat naar de FTP-server. Maar eenmaal een connec e opgebouwd, kiest de server een random poort waarop verdere bestandsoverdrachten zullen plaatsvinden. Dit bericht wordt van server naar aanvrager gezonden zodat die laatste weet over welke poort verder gecommuniceerd wordt. Als dit bericht door de router gaat, herkent deze het bericht en zal deze automa sch die poort gaan openstellen. Hierdoor moeten geen extra maatregels getroffen worden in zowel de aanvrager, FTP-server of router. Ook kan een firewall ingesteld worden op basis van MAC-adressen. Dit zorgt ervoor dat de firewall niet a ankelijk is van vluch ge IP-adressen. 5.2.3 VPN Inleiding Indien vroeger twee sites met elkaar verbonden waren, op een veilige manier, gebeurde dit meestal met 'leased lines'. Dit is een rechtstreekse verbinding in koper, glasvezel of via schotelantennes die in staat zijn twee netwerken met elkaar te verbinden. Dit is een zeer betrouwbare verbinding echter, de kosten s jgen ook lineair met de afstand tussen de twee sites. Een invulling hiervan is te zien in figuur 5.4 en 5.5. Figuur 5.4: Leased lines met koper of glasvezel 34

Figuur 5.5: Leased lines met straalverbinding Met de komst van het internet werd het verbinden van twee sites gemakkelijker en goedkoper. Hiervoor wordt wel ingeboet aan veiligheid. Data wordt van de ene plaats verstuurd naar de andere waardoor het makkelijk is om het bericht te onderscheppen of vervalsen. Om dit te verhelpen werd Virtual Private Network (VPN) het leven in geroepen. Dit zorgt ervoor dat veiligheid van data opnieuw gegarandeerd is. Een VPN-verbinding kan aanzien worden als een rechtstreekse tunnel tussen twee netwerken of gebruikers over het internet. Niemand kan in de tunnel kijken of zaken aanpassen. Enkel aan beide uiteinden kan de data op een correcte manier geïnterpreteerd worden. Een VPN-verbinding garandeerd volgende zaken: confiden ality: data is enkel leesbaar door rechtma ge ontvanger; integrity: data is niet aanpasbaar door onbevoegde; authen ca on: controle dat ontvanger is wie hij beweert te zijn. Daarnaast kunnen die verbindingen opgedeeld worden in drie soorten verbindingen. host-to-host: twee gebruikers leggen een verbinding naar elkaar; network-to-network: twee netwerken zijn met elkaar verbonden; host-to-network: een gebruiker legt een verbinding met een netwerk. De invulling van VPN is beschreven door verscheidene protocollen. De meest gebruikte zijn OpenVPN en IP Security (IPsec). In de 'bureau-omgeving' wordt meestal gebruik gemaakt van OpenVPN, daar dit ondersteund wordt door Windows. IPsec zal echter meer terug te vinden zijn op automa seringsniveau. Daarom zal hieropvolgend enkel van IPsec gesproken worden. IPsec Zoals de naam doet vermoeden, deze invulling zal zich manifesteren op het IP-niveau in het OSI-model. 35

Figuur 5.6: IPsec in het OSI-model Naargelang de soort verbinding zal in de IP-pakke en een andere structuur aanwezig zijn. Zo zal bij een host-tohost verbinding of een network-to-host verbinding de samenstelling van het pakket er uit zien zoals in figuur 5.7. Deze mode wordt de transportmode genaamd. Hierbij wordt de data versleuteld en ingekapseld in een IPsecheader. Daarboven komt een normale IP-header zodoende dat het pakket toch bij de bestemming geraakt. Figuur 5.7: Transportmode Indien een network-to-network verbinding gelegd wordt, zien de berichten er uit zoals in figuur 5.8. Het originele IP-pakket wordt versleuteld. Hieraan wordt een IPsec-header toegevoegd. Om terug te voldoen aan een volwaardig IP-pakket komt dit alles tussen een normale IP-header en -trailer. 36