Vb.net planningstool en Scada applicatie

Masterproef VB.net planningstool en Scada applicatie

Studiegebied Industriële wetenschappen en technologie Opleiding Master of Science in de industriële wetenschappen: elektrotechniek Afstudeerrichting Automatisering Academiejaar 2011-2012

Diederick Lambert

Vb.net planningstool en Scada applicatie

Voorwoord Als laatste jaarstudent wou ik mijn opgedane kennis testen in de praktijk. Zo ben ik gericht gaan zoeken om mijn eindwerk te verwezenlijken in het vakgebied rond VB.net implementatie. Daardoor ben ik terecht gekomen bij de Balta Group. Balta Group is een bedrijf die voornamelijk vloerbekleding maakt. Hier kreeg ik de kans om een bestaande situatie te analyseren en later het project te realiseren. Het project bestaat erin om een bestaand VB6 programma te vervangen door een nieuw dynamisch programma die niet enkel meer inzetbaar is in één afdeling maar ook op andere afdelingen zal worden gebruikt. Graag wil ik ook een dankwoord plaatsen voor de mensen die mij hebben geholpen bij het realiseren van dit eindwerk. Tijdens het ontwikkelingsproces waren mijn interne promotors Koen Berth en Bart Rommens steeds bereid mij te helpen zodat alles vlot verliep. Ook de mensen van de engineering afdeling waren steeds bereid mij bij te staan waar nodig. Mijn externe promotor wil ik natuurlijk ook bedanken voor de hulp bij het controleren van het script en ook voor de goede raad die mij werd gegeven. Dank u voor de steun en advies.


Inhoudsopgave VOORWOORD ............................................................................................................................. 4 INHOUDSOPGAVE....................................................................................................................... 5 ABSTRACT ................................................................................................................................... 7 LIJST MET AFKORTINGEN ........................................................................................................... 8 FIGUURLIJST ............................................................................................................................... 9 TABELLIJST ................................................................................................................................ 10 INLEIDING ................................................................................................................................. 11

1 BEDRIJFSVOORSTELLING .................................................................................................... 12 1.1. Algemene bedrijfsinformatie ......................................................................................................................... 12 1.1.1. Balta Rugs Avelgem ................................................................................................................................. 13 1.2. Geschiedenis Balta ......................................................................................................................................... 13

2 PROBLEMATIEK .................................................................................................................. 14 2.1. Probleemstelling Balta ................................................................................................................................... 14 2.2. Doelstellingen ................................................................................................................................................ 14 2.2.1. Scada ....................................................................................................................................................... 14 2.2.2. Programma .............................................................................................................................................. 15 2.2.2.1. GUI ................................................................................................................................................... 15 2.2.2.2. Programmering ................................................................................................................................ 15

3 COMPUTER INTEGRATED MANUFACTURING .................................................................... 16 3.1. Productiesoftware .......................................................................................................................................... 18 3.2. Object georiënteerd programmeren.............................................................................................................. 19 3.2.1.1. Implementatie vb.net....................................................................................................................... 20 3.3. OPC ................................................................................................................................................................. 21 3.3.1. OPC specificaties ..................................................................................................................................... 23 3.3.2. OPC .net applicatie .................................................................................................................................. 24 3.3.3. Kepware .................................................................................................................................................. 25 3.3.4. Keuze software OPC ................................................................................................................................ 26 3.4. Database ........................................................................................................................................................ 27 3.4.1. Database systeem architectuur .............................................................................................................. 27 3.4.1.1. File georiënteerd systeem ................................................................................................................ 27 3.4.1.2. Server georiënteerd systeem ........................................................................................................... 27 3.4.2. Database model ...................................................................................................................................... 28 3.5. SQL ................................................................................................................................................................. 29 3.5.1. DML ......................................................................................................................................................... 30 3.5.1.1. Select statement .............................................................................................................................. 30 3.5.1.2. Insert statement ............................................................................................................................... 30 3.5.1.3. Delete statement ............................................................................................................................. 30 3.5.1.4. Update statement ............................................................................................................................ 31 3.5.2. SQL in vb.net ........................................................................................................................................... 31


4 ANALYSE SOFTWARE ......................................................................................................... 32 4.1. Applicatie structuur ........................................................................................................................................ 32 4.1.1. Standalone vs. Client server‐model ........................................................................................................ 32 4.1.2. Opbouw VB.net klassen .......................................................................................................................... 33 4.1.2.1. Form ................................................................................................................................................. 33 4.1.2.2. Database klasse ................................................................................................................................ 33 4.1.2.3. Planningsklasse ................................................................................................................................ 35 4.1.2.4. Scada klasse...................................................................................................................................... 36 4.1.2.5. Persoon Klasse ................................................................................................................................. 36 4.1.2.6. Machine Klasse ................................................................................................................................. 37 4.1.2.7. Punt Klasse ....................................................................................................................................... 37 4.1.3. Setup ....................................................................................................................................................... 38 4.2. Opbouw SQL server ........................................................................................................................................ 41 4.2.1. Tabel tblConflogPlanningPersoon ........................................................................................................... 41 4.2.2. Tabel tblConflogPlanningMachine .......................................................................................................... 42 4.2.3. Tabel tblConflogPlanningTasks ............................................................................................................... 43 4.2.4. Tabel tblConflogPlanningTijdskrediet ..................................................................................................... 44 4.2.5. Tabel tblConflogPlanningPloegMatrix ..................................................................................................... 45 4.2.6. Relatie tussen de tabellen ....................................................................................................................... 45 4.2.7. Opslaan Planning schema’s ..................................................................................................................... 46 4.2.8. Tabel tblConflogProductie ...................................................................................................................... 46 4.2.9. Tabel tblConflogProductieMachines ....................................................................................................... 47

5 HANDLEIDING SOFTWARE ................................................................................................. 48 5.1. Installatie ........................................................................................................................................................ 48 5.1.1. Aanmaken Tabellen op database ............................................................................................................ 48 5.1.2. Instellen app.config ................................................................................................................................. 48 5.1.3. Aanpassen tabelnamen ........................................................................................................................... 49 5.1.4. Toekenning van de privileges aan de gebruiker ...................................................................................... 50 5.1.5. Setup & installatie ................................................................................................................................... 50 5.2. Werking Planningstool ................................................................................................................................... 51 5.2.1. Toevoegen van machines en personen ................................................................................................... 51 5.2.2. Functionaliteiten planningstool .............................................................................................................. 53 5.2.2.1. Aanmaken nieuwe planning ............................................................................................................. 53 5.2.2.2. Planning inladen ............................................................................................................................... 53 5.2.2.3. Planning opslaan .............................................................................................................................. 53 5.2.2.4. Planning Verwerken Excel ................................................................................................................ 54 5.3. Werking Scada ................................................................................................................................................ 54

BESLUIT ..................................................................................................................................... 59 BRONVERMELDING .................................................................................................................. 60 BIJLAGE ..................................................................................................................................... 61 Vb.net planningstool en Scada applicatie

Abstract The title of the thesis is ‘vb.net planning tool and Scada application’. This project is initiated by the company Balta Group. The aim of this project is to make a total new program that will replace an old system. In the current situation there is only an old VB6 program that is used as a Scada application. This program isn’t up to date anymore and can’t be adjusted. To make up the planning of a curtain division they still use an Excel worksheet. To fill in the planning sheet they have lists of data they need to manually pick out and retype it in Excel. So the goal of the new program is to make a dynamic Scada system so machines can be easily updated, moved and deleted. For the planning tool we want that all data is gathered on a central database. To achieve these goal we talked about the expectation the end users had in mind. With this guideline the program was build. The final build of the program made up with every goal. It is so dynamic that it will be used in other divisions as well.


Lijst met afkortingen B2MML CAD CAM CIM DCL DDL DML DMS FK GUI KMO LIMS MES NV OOP OPC PLC Scada SOA SQL RPC VB6 VB.net UML WMS XML

Business To Manufacturing Markup Language Computer Aided Design Computer Aided Manufacturing Computer Integrated Manufacturing Data Control Language Data Definition Language Data Manipulating Language Database Management System foreign key Graphical user interface Kleine of Middelgrote Onderneming Laboratory Information Management Systems Manufacturing Execution Systems Naamloze Vennootschap Object‐oriented programming OLE for process control Programmable logic controller supervisory control and data acquisition Service Oriented Architecture Structured Query Language Remote Procedure Call Visual Basic 6 visual Basic .net (net framework) Unified Modeling Language Warehouse Management System Extensible Markup Language


Figuurlijst Figuur 1: Topografie Balta .................................................................................................................................... 12 Figuur 2: Balta Avelgem Rugs ............................................................................................................................... 13 Figuur 3 : De CIM piramide ................................................................................................................................... 16 Figuur 4 : Opbouw Object in OO ........................................................................................................................... 19 Figuur 5 : Opbouw drivers voor OPC ..................................................................................................................... 21 Figuur 6 : Opbouw Drivers volgens OPC standaard .............................................................................................. 21 Figuur 7 : OPC in de CIM piramide ........................................................................................................................ 22 Figuur 8 : OPC WRAPPER ....................................................................................................................................... 24 Figuur 9 : Boomstructuur OPC ............................................................................................................................... 24 Figuur 10 : KepServerEx mogelijkheden ................................................................................................................ 25 Figuur 11 : LinkMaster mogelijkheden .................................................................................................................. 26 Figuur 12 : Opbouw database systeem ................................................................................................................. 27 Figuur 13 : Form met koppelingen naar onderliggende klassen ........................................................................... 33 Figuur 14 : Database klasse met koppelingen naar onderliggende klassen ......................................................... 33 Figuur 15 : Planningsklasse met koppelingen naar onderliggende klassen .......................................................... 35 Figuur 16 : Scada klasse met koppeling naar onderliggende klasse ..................................................................... 36 Figuur 17 : Opbouw van de klasse Persoon ........................................................................................................... 36 Figuur 18 : Koppelingen van de klasse machine .................................................................................................... 37 Figuur 19 : VB.net project toevoegen aan solution ............................................................................................... 38 Figuur 20 : Setup project toevoegen aan solution ................................................................................................. 39 Figuur 21 : Implementatie van msiexec.exe in setup ............................................................................................ 39 Figuur 22 : Voorbeeld van een ingevulde tblConflogPlanningPersoon ................................................................. 41 Figuur 23 : Voorbeeld van een ingevulde tblConflogPlanningMachine ................................................................ 42 Figuur 24 : Voorbeeld van een ingevulde tblConflogPlanningTasks ...................................................................... 43 Figuur 25 : Voorbeeld van een ingevulde tblConflogPlanningTijdskrediet ............................................................ 44 Figuur 26 : Ingevulde tabel tblConflogPlanningPloegMatrix ................................................................................ 45 Figuur 27 : Ingevulde tabel tblConfLogProductie .................................................................................................. 46 Figuur 28 : ingevulde tabel tblConflogProductieMachines ................................................................................... 47 Figuur 29 : Interface voor het toevoegen van machines in de planningstool ....................................................... 51 Figuur 30 : Interface om een persoon toe te voegen ............................................................................................ 52 Figuur 31 : Interface Kepware ............................................................................................................................... 54 Figuur 32 : Interface om machines toe te voegen in scada app ............................................................................ 55 Figuur 33 : Scada rooster ...................................................................................................................................... 56 Figuur 34 : Algemeen overzicht Scada gedeelte .................................................................................................... 57 Figuur 35 : Detail view met alle parameters ......................................................................................................... 57 Figuur 36 : Detail view van een bepaalde parameter ........................................................................................... 58


Tabellijst Tabel 1 : Select statements ................................................................................................................................... 30 Tabel 2 : Insert statements .................................................................................................................................... 30 Tabel 3 : Delete statement .................................................................................................................................... 30 Tabel 4 : update statement ................................................................................................................................... 31


Inleiding In een bedrijf is productie essentieel. Daarom zal een productie proces zo goed mogelijk worden opgevolgd.Om dit te doen is er kennis nodig van het product maar ook van de machines en omliggende invloeden. Eenmaal al deze factoren gekend zijn kan het proces ontleed worden. Om daarna een grondige analyse te kunnen opbouwen zal men gegevens uit de machines loggen en deze in aan Scada systeem binnen lezen. Hier kan de productieverantwoordelijke dan zien hoe alles verloopt en op tijd ingrijpen. In de hedendaagse industrie is dit niet meer weg te denken. Daardoor heb ik voor dit project gekozen om meer te weten te komen over hoe zo een systeem in de industrie wordt geïntegreerd. Het bestaande Scada systeem is reeds verouderd en niet meer onderhouden. Hierdoor zijn verschillende machines niet meer gelogd. En zijn er nieuwe machines die niet geïntegreerd zijn. Het nieuwe systeem zal dynamisch worden opgebouwd zodat eenvoudig machines kunnen worden gewijzigd. Naast het analyseren van productiedata moeten er ook planningen worden opgebouwd. Dit is belangrijk voor het beheren van een productie. Want als er geen goede planning is opgebouwd kan het gebeuren dat een machine zonder grondstof valt. Of kan het zelf gebeuren dat de werknemers niet komen opdagen door gebrek aan informatie. Helaas worden de meeste planningen nog opgemaakt met de hand. Hierdoor is de kans op fouten zeer groot. Daarom zal er vanaf heden een software worden gebruikt die de gebruiker zal begeleiden bij het plannen. Dit zal niet enkel de fouten minimaliseren maar zal ook nog eens voor een efficiënter gebruik zorgen. Om dit project zo vlot mogelijk te laten verlopen zal eerst worden overlegt wat de eindgebruiker juist verlangt van het programma. Met deze input zal er dan een basis software worden geschreven. Zodat er grondig getest kan worden. Zo kan er aan de hand van een “trail and error” systeem een software bekomen worden waar de eindgebruiker volledig mee tevreden is.


11

1 Bedrijfsvoorstelling 1.1. Algemene bedrijfsinformatie Balta Group is één van de wereldleiders in vloer‐ en muurbekleding. Balta is begonnen als KMO en is uitgegroeid tot een groep die verschillende bedrijfstakken huisvest. De topografie wordt beschreven in figuur 1. Door de samenwerking tussen de bedrijfsunits is de groep in staat een totaal oplossing te bieden voor woondecoratie; gaande van karpet, laminaat, kamerbreed tapijt, vinyl, behang tot gordijnstoffen. Door een strikt kwaliteitsbeleid, goede dienst na verkoop en een constante innovatie van technieken en trends zijn de producten die deze groep leveren van uiterste topkwaliteit. De gedrevenheid van deze groep zit in de inzet en de werkkracht van zijn medewerkers. Er heerst een teamverband met de mens als centrale speler. Alles is gericht op een professionele, klantvriendelijke aanpak waardoor de groep zich kan profileren als een betrouwbare partner.

Figuur 1: Topografie Balta


12

1.1.1. Balta Rugs Avelgem In de afdeling in Avelgem worden de geweven karpetten gefabriceerd. Zoals de pure wollen tapijten en de B‐tron (polypropyleen) karpetten. Doordat deze afdeling alles zelf produceert en beschikt over moderne en flexibele machines is men in staat vlot in te spelen op nieuwe trends, wat deze site uniek maakt. Op de site maakt men gebruik van de laatste nieuwe managementsoftware, waaronder een Warehouse Management System (WMS) zodat alles vlot kan gestockeerd en geleverd worden.

Figuur 2: Balta Avelgem Rugs

1.2. Geschiedenis Balta In 1964 werd Balta NV opgericht in St.‐Baafs‐Vijve door de familie Balcaen. Er werkten toen amper 50 mensen. Maar om producten te leveren tegen een betaalbare prijs en een hoge kwaliteit, heeft men geïnvesteerd in hoogtechnologische machines. Hierdoor is de Balta bedrijvengroep in amper één generatie uitgegroeid van een kleinschalige KMO tot een wereldleider. Balta is in 2004 voor het grootste deel overgenomen door het Londense Doughty & Co.


13

2 Problematiek 2.1. Probleemstelling Balta Op de site wordt de planning nog steeds opgemaakt in een eenvoudige Excel sheet. Telkens word de beschikbaarheid van de machine bepaald aan de hand van de beschikbare gekwalificeerde personen. Alle machines in de afdeling zijn uitgerust met de laatste technologieën zoals bijvoorbeeld een Scada systeem. Scada staat letterlijk voor het Supervisory Control And Data Acquisition. Het is een systeem dat ontwikkeld is om data (meet‐en regelgegevens) over de productieomgeving ter beschikking te stellen. Doordat het machinepark al enige veranderingen heeft ondergaan worden niet alle gegevens meer gelogd. Dit doordat het Scada‐systeem beheert wordt door een oud VB6‐programma. Dit programma is niet in staat om aanpassingen door te voeren. Ook zijn hierdoor verschillende databases ontstaan die niet samenwerken met het centrale systeem en men zo dus de data niet kan verzamelen. In de toekomst zal voor deze afdeling één software tool gebruikt worden die alles omvat.

2.2. Doelstellingen De hoofddoelstelling is het ontwikkelen van één softwaretool. Deze tool moet een Scada systeem en een planningstool bevatten. Het planningsgedeelte zal de persoonlijke gegevens bijhouden van alle werknemers alsook de machines deze persoon kan bedienen.

2.2.1. Scada Om een Scada systeem te ontwikkelen moet men in staat zijn de data op een correcte manier te verzamelen en te visualiseren. Om zo gestructureerd mogelijk te werk te gaan moet de data op één centrale database worden gelogd. Voor het loggen van data moet eerst worden nagegaan welke data relevant is om te visualiseren. Hiervoor zal een lijst worden opgemaakt met alle nuttige data die uit de PLC’s kan worden gelogd. Hierna zal alles worden gecapteerd via Kepware software en worden gelogd op de centrale database.


14

2.2.2. Programma Omdat het oude programma in Vb6 is geschreven zal het nieuwe programma worden herschreven. Hierbij zal alles worden herzien en enkel nog de nuttige data worden gevisualiseerd.

2.2.2.1. GUI De Grafische User Interface (GUI) moet zo worden opgebouwd dat een eenvoudige navigatie tussen de planningstool en Scada applicatie mogelijk is. Het planningsgedeelte zal niet enkel instaan voor het visualiseren en opmaak van de planning. Maar zal ook instaan voor het invoegen van nieuwe gebruikers en Excel rapportering. Het Scada gedeelte zal worden opgebouwd aan de hand van dynamisch opgebouwd rooster. Zo zullen machines eenvoudig kunnen worden verplaatst. Hierbij zullen buttons voorzien zijn waardoor er een detail view zal tevoorschijn komen. De bediening en opmaak van het Scada gedeelte zal ongeveer het zelfde blijven als het oude programma zodat de gebruikers er niet veel hinder van ondervinden.

2.2.2.2. Programmering Het programma zal worden opgebouwd in VB.net aan de hand van Unifief Modeling Language (UML). Hierdoor zal alles worden voorgesteld door een basisklasse. Hierdoor kan een eenvoudige programmeerinterface worden gemaakt. Dit helpt om de code zo eenvoudig mogelijk te houden maar ook om de code gelijkaardig te houden per machine. Naast de opbouw van de code zal het programma instaan voor het initialiseren van de data bij het laden. Hierbij zal reeds het gehele machinepark worden ingeladen in een lijst die bestaat uit een basis klasse van een machine. Voor meer gedetailleerde data zal dan via een bedieningspanel een bepaalde eis worden ingesteld om dan de rest van de data in te lezen van de database.


15

3 Computer Integrated Manufacturing Eind de jaren 60 wanneer de computer al meer commercieel was ontwikkeld is er actief gezocht hoe deze zou kunnen worden geïmplementeerd binnen een bedrijf. Doordat de computer nog niet zo een grote rekenkracht had werd deze vooral ingezet ter ondersteuning van de werknemer. Naarmate de computer meer ontwikkelde werd zijn rol groter in de industrie. Deze werd dan vooral gebruikt voor Computer Aided Design/ Computer aided Manifacturing (CAD/CAM). Hierbij werd vooral gebruik gemaakt voor het ontwikkelen van nieuwe machines en voor het controleren/aansturen van deze ene machine. Zo werd in de jaren 70 de term Computer Integrated Manufacturing (CIM) geïntroduceerd. Alles omtrent CIM beschreef toen hoe computers konden worden geïntegreerd in één productiecel. Later werd dit zodanig uitgebreid dat op heden de CIM alles beschrijft qua integratie in een bedrijf. Omdat het CIM begrip zodanig uitgebreid is, is er een piramide opgesteld die alle gebieden wat van elkaar splits (Figuur 3). Hierdoor kan alles per laag (gebied) worden besproken en kan de link tussen de lagen worden verduidelijkt. Onderaan bevindt zich de productie controle. Hier worden vooral de processen aangestuurd aan de hand van PLC’s, sensoren en actoren. De laag erboven houdt zich vooral bezig met het management van de productie zelf. Hierdoor zal een uitwisseling nodig zijn van data die wordt gecapteerd en gemanipuleerd. De bovenste laag is de laag van de commerciële activiteiten zoals marketing, inkoop, materiaal management, etc. De bovenste laag moet natuurlijk communiceren met de productie. Want zonder de optimale communicatie kan er heel wat mislopen. De piramide is ook zo opgesteld dat enkele eigenschappen eigen zijn aan elke laag. Zo zijn de tijdsconstanten en uitgewisselede data op elke laag anders. De tijdsconstante is des te groter hoe hoger je bent in de piramide. Op de onderste laag en de tussenlaag spreekt men van minuten, seconden tot real‐time terwijl op de bovenste laag men meer zal spreken van dagen, weken tot zelfs maanden. Want op de bovenste laag is er geen interesse wat er op de werkvloer gebeurd. Er is enkel interesse in wat er effectief wordt geproduceerd.

Figuur 3 : De CIM piramide


16

Naast de tijdconstante varieert ook de datahoeveelheid die in één keer wordt uitgewisseld. Op de onderste laag gaat het van bits tot enkele bytes. Terwijl op de lagen erboven men veel grotere bestanden zal gaan versturen die tot enkele kilobytes zal oplopen. Als dit in verband wordt gebracht met de tijdsconstante lijkt het logisch dat het minder lang zal duren om enkele bits te versturen dan dat je kilobytes moet versturen. Door deze twee factoren is er voor data uitwisseling op elke laag praktisch een andere manier nodig om te voldoen aan de vooropgestelde eisen. Wat het uiteindelijk moeilijk maakt om direct te gaan communiceren tussen verschillende lagen. Om dit op te lossen zijn verschillende methodes ontwikkeld om data uit te wisselen. De uitwisseling van data tussen het bovenste en het middelste niveau zal vaak gedaan worden aan de hand van 4 methodes. 

RPC



SOA



Database interface



OPC

De eerste methode is Remote Procedure Call (RPC). Bij RPC wordt een procedure aangeroepen op een computer op een bepaalde locatie in het bedrijfsnetwerk. Een tweede om informatie uit te wisselen, is via het gebruik van web services. Die technologie is gebaseerd op een Service Oriented Architecture (SOA). Een Client doet een verzoek aan een bepaalde service om een taak uit te voeren. De server ontvangt het verzoek en antwoordt met de nodige gegevens. Deze protocollen maken vaak gebruik van http en TCP/IP. Een derde methode is via een database interface. En de laatste methode is via een bestandinterface. Beide applicaties hebben een aantal gemeenschappelijke mappen. Indien een applicatie informatie wil versturen dan plaatst de applicatie een bestand in een gedeelde map. De andere applicatie leest dan het bestand in, verwerkt het en verwijderd het ui de gedeelde map. Hierbij wordt vaak gebruik gemaakt van XML‐bestanden. De uitwisseling tussen de middelste en de onderste laag gebeurd het vaakst via OPC (Ole for Process Control) die later wordt besproken. Voor deze thesis wordt vooral toegespitst op database communicatie. Want voor het uitwisselen van gelogde data van Plc’s maakt Kepware gebruik van een database logprogramma. Om elke laag van de CIM piramide te kunnen verwerken, wordt gebruik gemaakt van software. Om bijvoorbeeld orders te verwerken en te kunnen opvolgen tot de levering is software beschikbaar onder de naam ERP software.


17

3.1. Productiesoftware Productiesoftware is de naam die gebruikt wordt om softwarepakketen te omschrijven die zich bevinden op het productiemanagement niveau (middelste laag). Deze software bevat één of meerdere functionaliteiten die te maken hebben met productie. Enkele typische voorbeelden zijn Manufacturing Execution Systems (MES), Warehouse Management Systems (WMS) en Laboratory Information Management Systems (LIMS). Maar deze software kan ook modules bevatten die deel uitmaken van de bovenste en de onderste laag zoals ERP of SCADA systemen enkel voorbeelden hiervan zijn SAP en Microsoft Dynamics. Dergelijke softwarepakketten kunnen zelf worden ontworpen of er kan een bestaand softwarepakketten worden aangekocht. Bij de grotere softwarepakketten is standaardisatie van groot belang. Hierbij is de opbouw van het programma ontwikkeld volgens bepaalde standaarden. De standaarden worden ontwikkeld door erkende internationale organisaties zoals ISA, MESA, etc. De data uitwisseling zal vaak gebeuren via business to manufacturing Markup Language (B2MML). Bij sommige toepassingen is het vaak te duur om zo een pakket aan te schaffen en zal er vaak zelf een software worden geschreven. Hierbij wordt vaak afgeweken van dergelijke standaarden. Zoals elke standaard is de gebruiker vrij van deze te gebruiken. Wat niet wil zeggen dat deze niet kunnen worden geïmplementeerd. Maar doordat dit vaak heel wat kennis met zich meebrengt zal er meestal een eigen invulling worden gegeven aan de opbouw van het programma. Onze softwaretool zal voornamelijk een basis deel omvatten van een Planning System en een deel van het SCADA gebeuren. Omdat het niet te verantwoorden is om een bestaand pakket aan te kopen en de kennis binnen het bedrijf wil gehouden worden, wordt geopteerd zelf de software te schrijven. Hierbij zal ook geen standaard worden geïmplementeerd. Omdat hiervoor een heel wat voorbereidingen moeten worden getroffen en dit onmogelijk is om in een korte tijdspanne te verwezenlijken.


18

3.2. Object georiënteerd programmeren Object georiënteerd programmeren heeft zijn oorsprong rond de jaren 1960. Toen werd er redelijk wat onderzoek gedaan hoe OOP zou kunnen worden geïmplementeerd in verschillende codetalen. De eerste implementatie volgde nog in dezelfde periode. Deze codetaal werd Simula genoemd. Slechts 10 jaar later werd de tweede ondersteunde taal vrijgegeven die smalltalk noemde. Maar de grote doorbrak kwam er toen C++ werd voorgesteld. Deze taal was goed te implementeren in verschillende branches. Zo heeft dit geleid tot het ontstaan van veel verschillende invullingen van OOP. Redelijk recent is de implementatie in .NET platform van Microsoft. Zo werden vb.net en C# uitgebracht. Voordat er object georiënteerd geprogrammeerd werd waren de standaard programma’s redelijk complex en langdradig. Naarmate de lengte toenam werd er vaak code gegroepeerd in secties. Maar dit was vaak niet voldoende om een mooi overzicht te behouden. Zeker wanneer er een aanpassing nodig was, had dit vaak ernstige gevolgen. Het programma zat dan vaak vol met bugs. In contrast met OOP zal bepaalde code worden afgesplitst van het hoofd programma. Deze code is dan niet rechtstreeks aanspreekbaar, maar zal worden aangesproken via functies die methodes worden genoemd. Hierdoor zal een stuk code verantwoordelijk zijn voor een bepaalde bewerking. Dit maakt het ook eenvoudigere om een programma later aan te passen. Vaak zullen een groep methodes worden gebundeld omdat deze iets gemeen hebben. De code die hiervoor verantwoordelijk is zal niet enkel de methodes bundelen maar zal ook de data die bewerkt wordt onderhouden. Deze code word een object genoemd.

Object Propertie

Methode

(atribuut of status)

(functie of procedure)

Figuur 4 : Opbouw Object in OO

Zo zal een object georiënteerd programma een verzameling zijn van deze objecten. Elke object zal dan een bepaalde datagroep onderhouden. Deze groep zal vaak een stuk complexe code voorstellen of een object uit de ‘echte’ wereld. Zo zal in het programma die geprogrammeerd werd voor de planning een paar objecten aanwezig zijn die de planning, machines en personen voorstellen. Naast deze basis objecten zullen er ook kopieën aanwezig zijn van deze objecten. Zo zal er een lijst zijn van personen die elk een andere invulling krijgen. Maar de methodes die kunnen worden aangesproken zullen nog steeds dezelfde zijn.


19

Objecten kunnen zo worden geprogrammeerd dat deze niet enkel de data bijhouden maar ook nog eens controle kunnen uitvoeren op deze data. Doordat dit allemaal intern gebeurd is het eenvoudig een aanpassing te doen aan object zonder enige code te wijzigen buiten dit object. Dit kan nog verder worden uitgebreid zodat methodes kunnen worden gestandaardiseerd over verschillende projecten. Zo kan één methode voorkomen in elk object maar bij elk object een eigen invulling geven aan deze methode. Een standaard methode die in elk object aanwezig is de new methode. Hierbij wordt bij de aanmaak van het object enkele data direct een juiste invulling gegeven. Een ander krachtig instrument van OO is de mogelijkheid tot hiërarchische classificatie. Een superklasse op het hoogste niveau kan in meerdere niveaus opgesplitst worden in lagere klassen. Daarbij 'erft' elke klasse op het lagere niveau de attributen en methoden van de klassen op het niveau boven de klasse. Dat mechanisme noemen we overerving (inheritance). Overerving laat ook toe varianten van klassen te maken. Deze varianten worden basis‐ en specifiekere klassen genoemd. In sommige situaties kan de basisklasse aangeven welke operaties mogelijk zijn op een object, terwijl een specifieke klasse een specifieke implementatie van de operatie geeft. Zo kan een basisklasse "figuur" gemaakt worden, met specifieke implementaties "cirkel" en "vierkant". Wanneer gebruikgemaakt zou worden van een door figuur gedefinieerde methode (bijvoorbeeld voor het verkrijgen van de oppervlakte), is het niet langer nodig om te weten welke vorm het object precies heeft; of het intern met een straal of met een lengte of breedte wordt opgeslagen. Dit concept wordt polymorfisme genoemd.

3.2.1.1. Implementatie vb.net Zoals in de meeste talen worden objecten voorgesteld door klassen. Dit is in vb.net ook zo. In deze klassen worden dan Fields, properties en methodes onderscheiden. De fields stellen de data voor die worden bijhouden in het object. De properties geven de mogelijkheid om deze data op te vragen buiten het object zelf. En de methodes zijn de functies die instaan voor het controleren en bewerken van deze data. In vb.net is een mogelijkheid voorzien die al deze objecten grafisch zal voorstellen. Het zogenaamde klasse diagram een voorbeeld hiervan is weergegeven in figuur 13. Van hieruit kunnen de connecties tussen de objecten worden weergegeven maar kan je de objecten zelf aanpassen ook. Zo kan je fields, properties of methodes toevoegen/aanpassen of verwijderen. Ook kan je in het overzicht een nieuwe klasse definiëren. Een mooi voorbeeld van een koppeling tussen 2 klassen wordt weergegeven in figuur 18.


20

3.3. OPC Datacaptatie wordt vooral toegepast om op management niveau analyses uit te voeren op machineparameters. Omdat het capteren van data uit een PLC niet vanzelfsprekend is zijn hiervoor drivers ontwikkeld die met een PLC kunnen communiceren. Elke fabrikant levert zijn eigen driver mee bij de PLC en om met een pc software te communiceren zoals Excel of VB.NET is telkens nieuwe driver nodig. Dit bracht vaak conflicten met zich mee. Onderstaande figuur heeft een inzicht hoe omslachtig dit was.

Figuur 5 : Opbouw drivers voor OPC

Hierdoor is in 1994 het OPC Task Force opgericht. Waar enkele bedrijven (Rockwell, Siemens, …) zich onder koppelen om een standaard uit te brengen voor deze drivers. Ondertussen is het OPC Task Force geëvolueerd tot OPC Foundation en bestaat ze reeds uit meer dan 270 leveranciers van hard‐ en/of software en werden reeds tal van specificaties uitgebracht. Het basis idee achter OPC is dat alle drivers zouden worden vervangen en dat er één standaard interface wordt uitgebracht. Aangezien de technologie gebaseerd is op COM, zal het geheel functioneren in een client‐server architectuur. Waar vroeger een driver zorgde voor de communicatie zal nu een OPC server worden voorzien. Deze zal aan de ene zijde de standaard interface aanbieden en aan de andere zijde zal deze met een producteigen protocol communiceren met het device. De opbouw wordt voorgesteld in figuur 6.

Figuur 6 : Opbouw Drivers volgens OPC standaard


21

Deze server wordt beheerd door de producent zelf en dient dus te worden aangekocht. Naast de server dient natuurlijk ook een Client te worden voorzien. Deze kan een programma zijn die de producent levert bij een bepaalde toepassing. Hierbij hoeft de klant zich geen kennis te verschaffen van het OPC gebeuren en kan de configuratie gebeuren via een GUI. Vaak hebben dergelijke programma’s beperkingen en staan deze niet toe te communiceren met andere merken van PLC’s. Dit is natuurlijk een nadeel als er gewerkt wordt met verschillende soorten PLC’s. Hierdoor hebben de producenten hun eigen OPC klasse vrijgegeven zodat een bedrijf een eigen applicatie kan ontwikkelen. Hierbij is natuurlijk enige kennis nodig hoe OPC werkt. Maar omdat dit vaak zeer omslachtig is zal er beroep worden gedaan op een firma die hierin is gespecialiseerd. Eén van deze firma’s is Kepware. Een groot voordeel van deze client‐server architectuur is dat deze kan worden uitgebreid naar de hogere lagen van de CIM piramide. De tussenlaag zal dan communicatie verzorgen met de onderste laag en zal op zijn beurt weer een OPC server zijn voor de bovenliggende laag. Zo wordt alle communicatie in één standaard verwerkt en is het eenvoudiger om data uit te wisselen. Deze uitwisseling wordt voorgesteld in figuur 7.

Figuur 7 : OPC in de CIM piramide


22

3.3.1. OPC specificaties Sinds het ontstaan van de OPC Foundation en dankzij het grote succes van hun eerste specificatie, volgden nog heel wat nieuwe standaarden. Iedere nieuwe specificatie leverde telkens weer een oplossing voor specifieke gevallen van communicatie op.  OPC Data Access De OPC DA specificatie is de originele specificatie van de OPC Foundation. Het doel is ‘real‐time’ data overdracht realiseren tussen de field (PLC’s) en de hogere lagen van de CIM piramide. 

OPC Alarms & Events



OPC Batch



OPC Data eXchange



OPC Historical Data Access



OPC Security



OPC XML‐DA Hier wordt hetzelfde resultaat beoogd als bij OPC DA maar wel via een andere technologie. OPC DA heeft als nadeel dat het gebaseerd is op COM technologie, wat de inzetmogelijkheden beperkt tot Windows gebaseerde systemen. OPC XML‐DA werkt via een webservice (SOAP = XML gebaseerd). Aangezien XML zelf beschrijvende tekstdata is, is het dan ook OS onafhankelijk. 

OPC Complex Data



OPC Commands



OPC Unified Architecture OPC UA is de meest recente specificatie en verschilt qua techniek sterk van al zijn voorgangers. Het doel is één overkoepelende structuur te creëren waarin alle voorgaande standaarden vervat zitten. De focus ligt dus op de combinatie van voorgaande functionaliteiten en de communicatie tussen die mogelijkheden onderling.


23

3.3.2. OPC .net applicatie Zoals reeds eerder vermeld is zal OPC op verschillende manieren worden geïmplementeerd. Eén mogelijk hiervan is het ophalen van data via vb.net. Deze applicatie zal in dat geval communiceren met 1 van de 2 interfaces die zijn voorzien op de OPC server nl. de Custom interface en de Automation interface. Aangezien de Automation interface niet altijd ter beschikking wordt gesteld moet er een bibliotheek worden ingeladen die de vertaalslag levert naar de andere interface zo een vertaler wordt ook wel eens een Wrapper genoemd. Deze bibliotheek wordt toegevoegd aan de hand van een dll. Zo wordt voorkomen dat wanneer de automation interface niet beschikbaar is de applicatie er toch mee kan communiceren. Deze wrapper kan gebruikt worden voor verschillende servers aangezien de communicatieopbouw gestandaardiseerd is. Hoe de wrapper werkt is te zien in figuur 8.

Figuur 8 : OPC WRAPPER

Eenmaal de wrapper is toegevoegd kan de structuur van de OPC klasse worden opgebouwd. Eerst dient de server te worden gedefinieerd in de klasse. Dit gebeurd aan de hand van een serverobject die een servernaam en een IP adres nodig heeft waarop de echte server is aangesloten. Zo weet de applicatie waar de server zich bevind. Hierna dient een boomstructuur opgebouwd te worden met itemgroepen en items in deze groepen. Als deze boomstructuur is gemaakt kan dan een read or write worden gedaan naar de OPC server. Hierdoor wordt data gemanipuleerd en kan ermee worden gewerkt in de programma’s. Het enige nadeel is dat deze applicatie een standalone programma is. Tenzij er een client server model wordt van gemaakt. Maar dan moet de andere software die de client zal zijn deze data wel op de juiste manier binnen lezen. Wat op zich een vertaalslag met zich meebrengt of er moet weer een eigen applicatie worden geschreven die de verwerking doet.

Figuur 9 : Boomstructuur OPC


24

3.3.3. Kepware Kepware is een pakket die communicatie verzorgt tussen verschillende toepassingen binnen een bedrijf. Het pakket heeft verschillende uitbreidingsmogelijkheden en is zo opgebouwd dat alles eenvoudig aan elkaar te linken is. Zo staat KEPServerEX in voor de communicatie tussen de OPC drives. Aan de hand van de aangeboden data kunnen dan eigen applicaties worden gemaakt. Of er kan gekozen worden om een extra plug in te installeren die dan alle data op een database zal loggen. Hierdoor wordt niet meer gekeken naar een lokale applicatie maar wordt de mogelijkheid geboden om meerdere applicatie te draaien op verschillende pc’s. Omdat er deze applicaties dan dezelfde gelogde data gebruiken is het onmogelijk om corrupte data te hebben.

Figuur 10 : KepServerEx mogelijkheden

Kepware wordt voornamelijk gebruikt om OPC drives te beheren. Hierdoor hoeft in een applicatie slechts met één OPC server connectie worden gemaakt. Toch zullen alle data beschikbaar blijven. Wat een groot voordeel met zich meebrengt.


25

Een andere software tool nl. LinkMaster wordt gebruikt om communicatie mogelijk te maken tussen PLC’s onderling. Hierdoor hoeven geen dure gateways aangekocht te worden die telkens de vertaalslag moet leveren tussen de verschillende netwerken. Eenmaal deze software is aangekocht kan deze overal worden ingezet en vervangt deze al de gateways. Ook is deze software in staat verschillende OPC drives te combineren zodanig dat van de ene drive eenvoudig data kan worden overgezet naar de andere.

Figuur 11 : LinkMaster mogelijkheden

3.3.4. Keuze software OPC Hoe de software wordt gebruikt staat hier centraal. Omdat Balta een groot bedrijf is en verschillende afdelingen heeft die met elkaar communiceren is 1 lokale applicatie niet echt opportuun. Om eenvoudig te kunnen communiceren tussen de verschillende afdeling is geopteerd voor KEPServerEX met een datalogger plug‐in. Met behulp van deze plug‐in kan via verschillende netwerken data worden gelogd op een database. Hierdoor is eenvoudige communicatie mogelijk tussen de verschillende afdelingen. Nog een doorslaggevend punt is dat de software eenvoudig uit te bereiden is met plug‐ins. Mocht hiervoor een eigen applicatie geschreven zijn zou er een heleboel code moeten worden aangepast i.p.v. een plug‐in te installeren. Omdat de keuze van deze software al vastlag voor het eindwerk werd opgesteld heb ik gebruik gemaakt van de reeds bestaande opstelling.


26

3.4. Database Nu alle data uit de onderliggende lagen is opgehaald moet deze worden opgeslagen. Zodat later de bovenliggende lagen de vertaalslag kunnen doen met deze gelogde data. Omdat dit vaak over grote hoeveelheden data gaat is er een manier gevonden om deze data op te slaan zonder in te boeten aan de snelheid waarmee data terug kan worden opgehaald. Deze manier van opslaan gebeurd aan de hand van databases. De manier van opslaan is uniek omdat deze wordt gemanaged door een Database Management System (DMS). Dit systeem zorgt ervoor dat alle gegevens die bij elkaar horen aan elkaar gekoppeld zijn op een logische manier. Zonder dit systeem is de database een file met data die niet logisch kan worden geïnterpreteerd. Een voorstelling van dit systeem wordt weergegeven in onderstaande figuur.

Figuur 12 : Opbouw database systeem

3.4.1. Database systeem architectuur Bij het kiezen van een database systeem moet rekening gehouden worden hoe deze zal worden gebruikt. Zo heeft men keuze uit 2 architecturen.

3.4.1.1. File georiënteerd systeem Bij deze architectuur wordt de volledige database ondergebracht in een enkele file. Ze worden ook desktop databases genoemd aangezien ze eerder bedoeld zijn voor lokaal gebruik. Deze databases zijn minder geschikt om op een server te plaatsen, daar bij remote access telkens een kopie gemaakt wordt naar het lokale systeem om query’s op uit te voeren. Dit brengt twee nadelen met zich mee: 

Netwerkbelasting Een hogere graad van netwerkbelasting wordt bekomen door de grote hoeveelheid data die moet worden versluisd



Trage verwerking Een tragere verwerking daar niet de krachtige server maar de lokale pc de verwerkingen moet uitvoeren Bij multi‐user gebruik dient op de server bovendien nog een extra file aanwezig te zijn om de manipulaties van de verschillende gebruikers te coördineren, wat het maximum aantal gebruikers sterk reduceert.

3.4.1.2. Server georiënteerd systeem Bij deze zogenaamde client‐server databases is niet echt een file meer te vinden, maar worden een reeks files door een server beheerd. Wanneer hier opdrachten worden gelanceerd door een gebruiker, wordt alles op de server zelf verwerkt. De komt zowel de prestaties als de netwerkbelasting ten goede.


27

3.4.2. Database model Naast het kiezen van een architectuur is het model even belangrijk. Dit beslist hoe de DMS intern zal werken. Aan de hand van de keuze zal ofwel een snellere en betere georganiseerde database worden bekomen. Platte model Bij dit model wordt alle data ondergebracht in een grote tabel. Een spreadsheet is een uitstekend voorbeeld van een implementatie volgens dit model. Hierbij is voornamelijk de lay‐out de bepalende factor voor de structuur van de data. Hiërarchische model Hier bestaat de database uit meerdere tabellen die zich volgens een boomstructuur tegenover elkaar verhouden. Deze manier van data bijhouden is zeer efficiënt wanneer data wordt opgevraagd volgens de voor gedefinieerde parent‐child verbindingen, maar is niet echt handig voor ander vraagstellingen. Dit model werd ondertussen reeds lange tijd voorbijgestoken door het relationele model, maar wordt nog altijd ingezet voor specifieke doeleinden. Daarbij speelt de XML standaard in vele gevallen een bepalende rol. Netwerk model Het netwerkmodel kan gezien worden als een verdere evolutie van het hiërarchisch model. In het hiërarchisch model is de parent‐child verhouding altijd 1‐ n, bij het netwerkmodel kan dit n‐n zijn. Hoewel hier meer mogelijkheden voor handen zijn om verschillende zoekpaden te definiëren, blijft de beperking dat enkel de op voorhand gedefinieerde paden efficiënt zijn in gebruik. Relationele model Dit is al een relatief lange tijd het meest verspreidde datamodel. Ook hier wordt de data ondergebracht in tabellen. De verhouding tussen de tabellen wordt beschreven als een relaties, naar analogie met de term uit de verzameling leer. De theorie rond dit model werd ontwikkeld door Ted Codd. Het grote voordeel van dit model, is dat alle relaties niet expliciet gedefinieerd moeten worden. De aanwezige gegevens zijn bepalend voor het verband, waardoor de data vlot op een willekeurige manier gecombineerd kan worden. Het is niet per definitie nodig om bij het ontwerp van de database te weten welke gegevens met elkaar gekoppeld zullen worden tijdens het bevragen. Relationele databases worden meestal gebouwd volgens een genormaliseerd model, wat ervoor zorgt dat gegevens niet gedupliceerd worden opgeslagen. Dit reduceert het nodige geheugen en biedt gelijktijdig voordeel op gebied van maintenance. Bekende voorbeelden van dit model zijn Access, SQL Server, MySQL, Oracle, DB2, .. Object model Bij dit model worden de gegevens opgeslagen als objecten, waarbij alle kenmerken van Object‐oriented programming (OOP) van kracht zijn. de graad van implementaties van dit model ligt echter nog zeer laag. Ondertussen zijn wel al een aantal hybride situaties ontstaan waarbij relationele systemen de mogelijkheid bieden om objecten uit externe programmeertalen bij te houden en te manipuleren via het relationele database managementsysteem.


28

3.5. SQL Naast de opbouw van de database moet er ook nog een manier zijn om te communiceren met de DMS. Hiervoor werden vroeger verschillende talen ontwikkeld. Elke producent van had wel een eigen interpretatie hoe deze taal moest worden opgebouwd. Een hiervan was Standaard Query Language (SQL). Deze taal werd ontwikkeld door IBM. Na verloop van tijd zijn verschillende versies uitgebracht en is de taal ondertussen een standaardtaal geworden. Deze werd opgenomen door ANSI en ISO. Doordat dit een standaardtaal is geworden kan er nu op alle relationele database gewerkt worden met deze taal. De taal wordt altijd geïmplementeerd maar omdat dit vaak niet volstaat zal de producent nog een eigen invulling geven aan de taal waardoor meer mogelijkheden ontstaan. Omdat deze materie zeer complex is, is het vaak niet mogelijk om te verlangen dat de eindgebruiker al deze syntax hoeft te kunnen. Waardoor deze taal vaak wordt gebruikt door een tussenapplicatie. Dit maakt het mogelijk om alles te vereenvoudigen voor de eindgebruiker en hoeft hij geen kennis te hebben van SQL. De naam van deze taal doet het al vermoeden deze taal werd opgesteld om query’s uit te voeren. Maar door de verdere ontwikkeling van deze taal is deze uitgegroeid tot meer dan juist een query taal. Tegenwoordig wordt de taal onderverdeeld in 3 sub categorieën. 

DML (Data Manipulating Language) Deze subset staat in voor de statements die dienen voor het lezen en bijwerken van gegevens. Vooraleer er echter gegevens bijgehouden kunnen worden, dient er eerst een database structuur aanwezig te zijn.



DDL (Data Definition Language) De subset die instaat voor het definiëren en wijzigen van de database structuur.



DCL (Data Control Language) Deze subset dient voor het beveiligen van de gegevens

Doordat de producent vaak programma’s voorziet om de opbouw te voorzien van de database is DDL en DCL vaak geïmplementeerd in GUI. Zodat de opbouw vrij vlot verloopt en enkel nog de DML taal hoeft gebruikt te worden in een eigen applicatie. Want uiteindelijk zal de applicatie enkel instaan voor het manipuleren van data die werd opgeslagen op de database.


29

3.5.1. DML De DML subset is opgebouwd uit 4 statements die op zich zijn opgebouwd uit verschillende clausules.

3.5.1.1. Select statement Het SELECT statement is bedoeld op gegevens op te vragen uit de database. Telkens een SELECT opdracht naar het RDBMS wordt gestuurd, retourneert deze een resultaattabel. Dit is geen nieuw structuurelement binnen de database, maar een tabel met een vluchtig karakter. Een SELECT statement is samengesteld uit een aantal vaste en een aantal optionele clausules die in een vooraf gedefinieerde volgorde dienen te staan. Clausule Doel SELECT Bepaald welke kolommen in de resultaattabel zullen voorkomen FROM Legt vast uit welke tabel(len) de gegevens afkomstig zijn [WHERE] Beslist welke records in de resultaattabel zullen voorkomen [GROUP BY] Groepeert records op basis van de veldinhoud [HAVING] Legt voorwaarden op de gegroepeerde gegevens [ORDER BY] Bepaald de volgorde van de records in de resultaattabel Tabel 1 : Select statements

3.5.1.2. Insert statement Het INSERT statement dient om nieuwe records toe te voegen in een tabel. Na de ‘INSERT INTO’ clausule volgt de naam van de tabel waarin nieuwe records moeten. De ‘VALUES’ clausule bevat tussen haakjes een opsomming van de veldinhouden die in de nieuwe rij moeten komen. Alle velden dienen aan bod te komen (in dezelfde volgorde als in de tabeldefinitie). Indien een bepaald veld geen specifieke invulling nodig heeft, dient de waarde NULL meegegeven te worden. Clausule Doel INSERT INTO Bepaald in welke tabel een record moet worden geplaatst VALUES Bevat de records die moeten worden in de tabel geplaatst Tabel 2 : Insert statements

3.5.1.3. Delete statement Eenmaal de gegevens in de tabel zijn geplaatst kan het gebeuren dat deze na enige tijd ook mogen verwijderd worden. Dit gebeurd aan de hand van de delete statement. Hierbij kan men ofwel een gehele tabel wissen door juist de basis query uit te voeren. Maar omdat dit vaak niet de bedoeling is zal men hierbij nog een where clausule voorzien zodat enkel bepaalde records zullen worden verwijderd. Als er iets wordt verwijderd moet er ook rekening mee worden gehouden dat sommige gegevens worden gedeeld met andere tabellen zoals foreign keys (FK). Hierdoor kunnen problemen ontstaan. Dus moet je altijd eerst de gegevens uit de Child tabel verwijderen voordat deze worden verwijderd uit de parent tabel. Clausule Doel Delete From Bepaald in welke tabel records moeten verwijderd worden [where] Beslist welke records zullen worden verwijderd Tabel 3 : Delete statement


30

3.5.1.4. Update statement Dit is de laatste statement. Deze wordt gebruikt indien er een wijziging moet gebeuren aan een record. Meestal doordat bij het aanmaken van een record niet alle gegevens reeds bekend zijn. Net zoals bij de delete statement is er een optionele ‘where’ clausule voorzien. Wordt deze niet toegepast dan zal de gehele tabel de ingegeven waarde krijgen. Clausule Doel Update Bepaald in welke tabel records moeten worden upgedate Set Beslist in welke kolom een record moet worden upgedate [Where] Beslist welke records zullen worden upgedate Tabel 4 : update statement

3.5.2. SQL in vb.net Om te kunnen communiceren met een database in een vb.net programma moeten er eerst enkele stappen worden doorlopen. Eerst moet er gekeken worden als de ADO.net provider aanwezig is die kan communiceren met de database. In een standaard project zitten OLE DB, ODBC en SQLClient dit is vaak niet de provider die zal worden gebruikt. Hierdoor moet een extra provider worden toegevoegd aan het project. Dit gebeurd door bij de ‘references’ map een extra dll‐file in te lezen. Eenmaal dit is gedaan heb je de gereedschappen om met de database te communiceren. Het eerste wat dan hoort gedaan te worden is bij het aanmaken van de database klasse de connectiestring juist in te stellen. Zo weet het programma naar welke database deze moet connecteren. Een connectie string is per database verschillend en kan je opzoeken op www.connectionstrings.com. Eenmaal dit is gedaan kan er data worden gemanipuleerd.


31

4 Analyse software Voordat daadwerkelijk kan worden geprogrammeerd moet eerst worden overlegt wat er wordt verlangt van de software, met andere woorden wat zijn de gevraagde functionaliteiten. Na het programmeren kan telkens verder geoptimaliseerd worden tot het programma klaar is voor publicatie.

4.1. Applicatie structuur Na het overleg tussen de klant en programmeur zal da programmeur nadenken hoe het programma zal worden opgebouwd. Er zal worden gekeken hoe het programma zal communiceren met andere systemen. Ondertussen wordt er een methode gekozen hoe alles zal worden gecodeerd.

4.1.1. Standalone vs. Client server‐model Een standalone applicatie wordt deels al uitgelegd door de naamomschrijving. Het is een onafhankelijk programma. Hierbij zal bij de installatie alles wat dit programma nodig heeft op de lokale computer worden geïnstalleerd. Hierdoor is het programma niet afhankelijk van netwerk connecties. Meestal heeft zo een applicatie wel de mogelijkheid om data uit te wisselen. Bij het creëren van een file wordt dan een eigen opmaak gebruikt of een standaard protocol zoals XML, B2MML,... Na dit is gedaan kan deze file dan worden getransporteerd naar een andere pc. Een mooi voorbeeld van een standalone applicatie is een tekstverwerking programma. Naast de standalone applicaties zijn er natuurlijk ook de client applicaties. Deze maken gebruik van netwerk connecties om data te verkrijgen en te manipuleren. De netwerk connectie is een groot nadeel want zonder deze connectie kan het programma meestal niet werken. Omdat het data nodig heeft die niet lokaal is bewaard maar beschikbaar is op een server. Het is natuurlijk wel een voordeel als er wordt gewerkt met data die real time moet worden verwerkt. Zo kunnen verschillende pc’s toch beschikkend over de meest recentste data. Dus zal bij de installatie enkel de client worden geïnstalleerd. Dit heeft dan als voordeel dat deze applicaties vaak kleiner zijn qua grote dan een standalone applicatie. Voor de ontwikkeling van het programma dat zal worden gebruikt bij Balta is gekozen voor een Client applicatie. Dit om de simpele redenen dat alle data die wordt gecapteerd uit de Devices wordt gelogd via Kepware op een server. Hierdoor kunnen verschillende users ter gelijker tijd werken met de real time gelogde data.


32

4.1.2. Opbouw VB.net klassen Bij object georiënteerd programmeren (UML) wordt aan de hand van klassen de werkelijk zo goed mogelijk benaderd. Zo krijgt ieder werkelijk object zijn eigen klasse. Om uit een proces klassen te kunnen ontleden moet er een goede kennis zijn van het proces. Eenmaal het proces volledig gekend is kan men eenvoudig de klassen opbouwen. Voor de opbouw van het programma zijn de klassen zo gemaakt dat deze door zowel de planningstool als het SCADA gedeelte kunnen worden gebruikt.

4.1.2.1. Form De form zal het basis aanspreekpunt zijn van het programma. Want via de GUI die gemaakt is in de form zal kunnen worden geïnteracteerd met de onderliggende klassen. De form zal zelf niets van bewerkingen uitvoeren en zal enkel gegevens opvragen uit de onderliggende klassen. De form heeft een directe link naar de database klasse en de Excel klasse. Zoals weergegeven in figuur 13.

Figuur 13 : Form met koppelingen naar onderliggende klassen

4.1.2.2. Database klasse Omdat de informatie niet rechtstreeks wordt ingegeven via de GUI maar wordt uitgelezen via een database zal er dus een klasse moeten worden voorzien die de interactie met de database op zich neemt. Omdat we OOP toepassen zal deze klasse de database voorstellen. Omdat noch de planning noch de Scada applicatie in dit programma kunnen werken zonder deze gegevens zijn deze klassen onderliggend aan de database. Dus zal alles worden aangesproken via de database klasse. De koppeling tussen deze klassen kan je zien in figuur 14.

Figuur 14 : Database klasse met koppelingen naar onderliggende klassen


33

4.1.2.2.1. Interne werking database klasse Importeren van SqlClient bibliotheek Omdat de gebruikte server een server is van Microsoft zit de bibliotheek al standaard in Vb.Net. Hierbij moet de klasse enkel worden geïmporteerd. Dit wordt gedaan door op de eerste regel in de klasse onderstaande code te schrijven. Dit heeft als voordeel dat niet telkens het gehele path moet opsomd worden om bij het element uit deze bibliotheek te komen. Code: Imports System.Data.SqlClient

Connectie string Om connectie te kunnen maken met een database moet de applicatie weten waar deze zich bevind. Hierdoor zal bij het aanmaken van de database klasse eerst de locatie van de database worden opgeslagen in een Sqlconnection object. De connectiestring zelf wordt opgeslagen in een app.config file. Deze string wordt dan uitgelezen in de Globals klasse die alle globale variabelen bijhoudt van het programma. Code: Public Class clsDataBase Private _oConn As Object … Public Sub New() Try _oConn = New SqlConnection(Globals.ConnectionString) …

De string zelf wordt dus bijgehouden in het aap.config bestand dit is een XML bestand die kan worden aangepast wanneer een programma al reeds gemaakt is. De code zit er dan uit als volgt. Code: …


34

Werking database Nadat alle nodig instellingen zijn gedaan voor de connectie mogelijk te maken kunnen er nu bewerkingen worden uitgevoerd. Bij de opstart zullen alle basis gegevens worden ingeladen van de planning. Dit wil zeggen dat alle werknemers en alle machines reeds zullen worden ingeladen in een basis lijst. Dit omdat er een module aanwezig is die alle bestaande gegevens van deze klassen kan aanpassen. Eenmaal dit gedaan is wacht deze klasse op aanvragen. Dit wil zeggen dat de database enkel de planning van data zal voorzien wanneer er op de GUI iets gebeurd. Stel dat er een planning van een bepaalde dag moet worden ingeladen of opgeslagen dan zal de desbetreffende methode worden aangesproken. En de data in de planning worden bewerkt. Naast de planning is er ook een Scada klasse die gekoppeld is aan deze database. Deze klasse wordt bij de opstart enkel aangemaakt en wordt er verder niets mee gedaan. Want het Scada gedeelte heeft input nodig van de GUI om een bepaald tijdsinterval te kunnen weergeven.

4.1.2.3. Planningsklasse De planningsklasse omvat alle intelligentie van hoe een planning moet worden opgebouwd. De opbouw van zo een planning bestaat uit lijsten die gevuld worden met objecten. Deze objecten zijn ofwel kopieën van de persoon of machine klasse. Doordat deze lijsten worden ingevuld met bepaalde eisen kunnen er verschillende eigenschappen worden toegekend aan elke lijst. Zo zijn er lijsten voor mensen die ziek zijn, inhaalrust hebben,… maar is er ook 1 algemene lijst voor machines. Zo wordt voor iedere ploeg een ander invulling gegeven aan deze lijsten. Zo kunnen er mensen ingeplant worden uit andere ploegen. En wordt dit bijgehouden zodat deze mensen niet worden dubbel geboekt op 1 zelfde dag.

Figuur 15 : Planningsklasse met koppelingen naar onderliggende klassen


35

4.1.2.4. Scada klasse Naast de planningsklasse is er nog een 2de grote klasse die logica bevat zijnde het Scada gedeelte. Deze klasse bevat de logica om alles grafisch te gaan voorstellen. Zo is er een lijst aanwezig met machines die in het machinepark staan. Deze machines hebben een iets andere invulling dan deze dat worden gebruikt in de planningsmodule. Hier worden de machines ook voorzien van logpunten. Deze punten kunnen dan worden gevisualiseerd. Naast deze lijst houdt deze klasse ook het tijdsinterval bij van de opgevraagde periode.

Figuur 16 : Scada klasse met koppeling naar onderliggende klasse

4.1.2.5. Persoon Klasse Deze klasse is één van klassen die geen logica bijhoudt. Deze klasse staat enkel in voor het bijhouden van de data die een persoon beschrijft. Dit omvat de persoonlijke gegevens zoals de naam maar ook het telefoonnummer. Naast de persoonlijke gegevens staat deze klasse ook in voor het bijhouden van de data die nodig zijn om deze persoon te kunnen inplannen zijnde de taken, ploeg, tijdskrediet en als deze al dan niet een meestergast is. Bij het aanmaken worden deze gegevens automatisch ingevuld. Maar natuurlijk kunnen al deze gegevens later nog worden aangepast. Een gedetailleerd overzicht wordt voorgesteld in figuur 17.

Figuur 17 : Opbouw van de klasse Persoon


36

4.1.2.6. Machine Klasse Deze klasse is ook een van de klassen die geen intelligentie bevat. Deze klasse houdt de data bij die nodig is om bewerkingen te doen met een machine. Voor beide gedeelten is de naam belangrijk. Buiten dit zijn er ook data die enkel wordt gebruikt bij een van de 2 toepassingen. Voor het planningsgedeelte kan een er op de machine een persoon worden geplaatst die de machine bediend. Zo kan er op de planning worden gezien of de machine reeds bezet is en zo ja welke bediener aan de machine staat. In het Scada gedeelte is er een lijst voorzien van punten. Deze lijst bevat alle gelogde punten tussen een bepaalde geselecteerd tijdsinterval. Voor het visualiseren is er ook een leesoptie voorzien van elke parameter. Deze optie toont dan de laatste nieuwe gegevens. Deze koppelingen worden weergegeven in figuur 18.

Figuur 18 : Koppelingen van de klasse machine

4.1.2.7. Punt Klasse Deze klasse bevat één enkel punt die gelogd is van een bepaalde machine. Deze klasse wordt gebruikt om de gelogde data zo goed mogelijk te kunnen beheren. Hierdoor zal de grafiekopbouw veel eenvoudiger verlopen. Deze klasse bestaat dus uit een tijdsstip die wordt ingegeven op het x‐coördinaat en een waarde die wordt ingegeven op het y‐coördinaat. En bevat een beschrijving van het punt.


37

4.1.3. Setup Nadat een programma volledig geprogrammeerd is moet een definitieve versie worden gemaakt. Dit wordt gedaan aan de hand van een ‘build’ tool van vb. Hierdoor staat dan een *.exe file in de release map. Maar voor sommige programma’s is dit niet voldoende. Sommige programma’s hebben DLL’s, frameworks, … nodig die niet standaard geïnstalleerd zijn op een pc. Aangezien het programma afhankelijk is van deze componenten. Heeft men een setup programma uitgevonden. Deze setup zal alle files bundelen die het programma nodig heeft om te kunnen functioneren. Vb.net voorziet een standaard setupwizard die een eenvoudige te implementeren is. Maar deze setup is voorziet enkel het installeren van het programma. Als er extra’s voorzien moeten worden zal er zelf een setup file worden aangemaakt. Hierdoor kan er een snelkoppeling, remove file, of extra files toevoegt worden aan het startmenu/bureaublad of install folder. Om dit te verwezenlijken moet er met de rechtermuisknop worden geklikt op de solution label. Hierbij kan er dan via ‘add’ een nieuw project worden toegevoegd. Zoals je kan zien in figuur 19.

Figuur 19 : VB.net project toevoegen aan solution


38

Hierna kan er een projecttype geselecteerd worden. Aangezien dit geen Windows form of iets dergelijks is moet je dus onder een andere categorie gaan zoeken. Een setup kan je terugvinden onder ‘other project types’ bij ‘setup and deployment’. Zoals wordt weergegeven in figuur 20.

Figuur 20 : Setup project toevoegen aan solution

Eenmaal dit is gedaan zal er in de solution een standaard setup file aanwezig zijn. Deze zal de afhankelijke DLL’s, frameworks, … detecteren en integreren in de setup. Hierna kan je enkel instellingen doen zoals de uitgever, bedrijf, etc. . Hierna kunnen de extra files worden toegevoegd. Bij ons programma is ervoor geopteerd om een snelkoppeling op het bureaublad te plaatsen en de app.config en remove file te voorzien in de menufolder. Om de remove file te importeren moet een system32 file (msiexec.exe) worden mee geïnstalleerd. Deze moet geplaatst worden in system folder van de setup. Figuur 21 toont hoe zo een file wordt toegevoegd en de file na implementatie.

Figuur 21 : Implementatie van msiexec.exe in setup


39

Nu deze file aanwezig is hoeft er enkel nog maar een snelkoppeling te worden voorzien. Deze snelkoppeling wordt dan ‘uninstall’ genoemd en wordt geplaatst in de map Planning & Scada Balta. Hetzelfde wordt gedaan voor een snelkoppeling op het bureaublad. Een snelkoppeling wordt dan gelegd naar de ‘primary output’ file in de Application folder. Maar de snelkoppeling moet in de ‘User’s Desktop’ worden geplaatst. Naast deze methode is er nog een andere methode voorzien in Vb.net. Hierbij wordt gebruik gemaakt van een ‘publish’ functie. Dit houdt in dat je moet beschikken over een server waar al de pc’s met dit programma kunnen naar connecteren. Het voordeel van een publish is dat deze setup functie een mogelijkheid heeft om telkens wanneer het programma opstart te kijken als er geen nieuwere versie beschikbaar is op de server. Is er dan een nieuwe versie beschikbaar zal deze automatisch worden geïnstalleerd. Aangezien dit een wizard is die geïntegreerd wordt in het project kunnen hier niet veel instellingen gedaan worden. Bij het eerste keer publishen van het project vraagt Vb.net waar de servermap zich bevindt voor het plaatsen van de Setup. Hierna kan je via de eigenschappen nog instellen of deze een snelkoppeling moet voorzien en wanneer deze moet controleren op updates (voor het starten van het programma of bij het afsluiten). Hierna kan bij een aanpassing het project eenvoudig worden vrijgeven en wordt het automatisch geïnstalleerd op de pc’s waar het al aanwezig is.


40

4.2. Opbouw SQL server Bij de opbouw van de SQL server moet er eerst een onderscheid worden gemaakt van wat er juist zal worden opgeslagen. Doordat object georiënteerd geprogrammeerd wordt is dit simpel af te leiden uit de klasse opmaak. De 2 grootste tabellen zullen de persoon (werknemer) en de machine zijn. Om deze 2 grote tabellen met elkaar te kunnen verbinden is er een tussentabel ingevoegd. Deze tabel bevat de taken die een werknemer kan uitvoeren. Door deze verbinding kan er een verband worden gelegd tussen de persoon en de machine. Om een zo optimaal overzicht te behouden op de server hebben alle gebruikte tabellen voor dit programma een prefix gekregen. Deze prefix is tblConflogPlanning.

4.2.1. Tabel tblConflogPlanningPersoon Deze tabel zal alle personen bevatten. Zo is deze tabel opgebouwd uit verschillende kolommen. Elke kolom bevat een eigenschap van een persoon. 

perId (PK, integer) o Is de unieke id waarmee een persoon wordt gekenmerkt.



perVoornaam en perNaam (string) o Deze twee kolommen bevatten de naam en de voornaam van een persoon. Deze namen zijn zeer uiteenlopend en uniek binnen het bedrijf.



perMeesterGast (boolean) o Hiermee wordt aangeduid als deze persoon al dan niet een meestergast is



perTelefoon en perTelefoon2 (string) o Deze 2 kolommen bevatten de telefoonnummers van de persoon. Deze zijn optioneel en kunnen dus geen info bevatten.



ppPloeg (integer) o Deze kolom bevat een verwijzing naar de tabel tblConflogPlanningPloeg. Hiermee wordt aangeduid in welke ploeg de persoon is ingedeeld.



ptTijdskrediet (integer) o Deze kolom bevat een verwijzing naar de tabel tblConflogPlanningTijdskrediet. Deze houdt bij welke dagen een persoon tijdskrediet heeft.

Figuur 22 : Voorbeeld van een ingevulde tblConflogPlanningPersoon


41

4.2.2. Tabel tblConflogPlanningMachine Deze tabel omvat alle machines die gebruikt worden om de planning op te maken. Hierbij kan een machine dus opgedeeld worden in verschillende stukken. Deze lijst wordt dan binnen gelezen om bij de opstart zowel de lijst van machines aan te maken alsook het visuele aspect in te vullen. 

macId (PK, integer) o Is de unieke ID waarmee een machine wordt gekenmerkt.



macMachine (string) o De naam van de machine of omschrijving van een deel van de machinegroep.

Figuur 23 : Voorbeeld van een ingevulde tblConflogPlanningMachine


42

4.2.3. Tabel tblConflogPlanningTasks Deze tabel is een tussentabel die de koppeling tussen de tabel van de personen en machines verzorgt. Dit komt doordat er een veel op veel relatie nodig is om personen te koppelen met machines. Dus een persoon kan vele machines bedienen maar elke machine kan ook worden bediend door vele personen. 

tasId (Pk, integer) o Is de unieke ID waarmee een Task wordt gekenmerkt.



tpId (FK, integer) o Deze waarde zal verwijzen naar een PK van de tabel personen. Zo kan een bepaalde persoon gekoppeld worden aan deze taak.



tmId (FK, integer) o Deze waarde zal verwijzen naar een PK van de tabel machines. Zo kan er een bepaalde machine aan deze taak gekoppeld worden.

Figuur 24 : Voorbeeld van een ingevulde tblConflogPlanningTasks


43

4.2.4. Tabel tblConflogPlanningTijdskrediet Deze tabel houdt het tijdskrediet bij. Omdat de kans vrij groot is dat verschillende personen zelfde dagen tijdskrediet hebben is hiervoor een aparte tabel voorzien die een schakelmatrix bijhoudt. 

tijId (Pk, integer) o Is de unieke ID waarmee een bepaalde mogelijkheid van tijdskrediet wordt gekenmerkt.



tijDag (Boolean) o Al deze kolommen bevatten een patroon van 1 bepaald tijdskrediet. Zo wordt aangegeven op weekbasis welke dag(en) een persoon tijdskrediet heeft.

Figuur 25 : Voorbeeld van een ingevulde tblConflogPlanningTijdskrediet


44

4.2.5. Tabel tblConflogPlanningPloegMatrix Deze tabel dient om te beslissen welke ploeg er in een bepaalde periode werkt. Aangezien er wordt gewerkt met een 3 ploegensysteem moet er per week een wisseling gebeuren. De namiddag en voormiddag ploeg worden dan omgewisseld. Om dit ook te doen in het programma is onderstaande matrix opgesteld. Zo kan er gezien worden welke ploeg wanneer werkt. Deze regel is gebaseerd op het weeknummer. Is deze even dan zal de periode uit de plomEven kolom worden genomen en is deze oneven dan zal deze uit plomOneven worden genomen. Omdat dit op voorhand wordt bepaald kan dit niet via het programma worden ingegeven en moet dit dus via de database worden geregeld. Indien dit niet wordt gedaan zal het programma niet werken. 

plomId (Pk, integer) o Is de unieke ID waarmee een ploeg wordt gekenmerkt.



plomNaam (string) o De omschrijving van de ploeg. In ons voorbeeld is geopteerd om te werken met ploegnummers.



plomEven (string) o Hier wordt getoond tot welke periode een ploeg behoort in een even week.



plomOneven (string) o Hier wordt getoond tot welke periode een ploeg behoort in een oneven week.

Figuur 26 : Ingevulde tabel tblConflogPlanningPloegMatrix

4.2.6. Relatie tussen de tabellen Door bovenstaande kenmerken kan een volledige database structuur worden opgebouwd zoals in onderstaande figuur. Deze structuur is de basis voor het planning gedeelte van de software. Hier worden de statische gegevens bijgehouden. Maar als men planningen wil opslaan voor later gebruik is nog een extra tabel nodig die de lijsten en commentaar bijhoudt die reeds werden ingevuld. Tijdskrediet Persoon Tasks

Ploeg Machine


45

4.2.7. Opslaan Planning schema’s Planning schema’s voor de toekomst zullen niet direct worden geëxporteerd naar Excel. Dit omdat er in de toekomst nog veel wijzigingen kunnen plaats vinden. Dus zullen deze eerst worden opgeslagen op de database. Hiervoor is een aparte tabel voorzien. Elke element die tot een planning behoort is gekenmerkt door de datum en de ploeg. Daarnaast zijn de lijsten waarin een persoon zich kan bevinden ook aanwezig (werkloosheid, Ziekte, …). Natuurlijk is de koppeling naar een machine ook voorzien. En een extra veld voor commentaar in te voegen.

4.2.8. Tabel tblConflogProductie Deze tabel is de tabel die gebruikt wordt om data te loggen. Omdat de logging gebeurd via een tussensoftware namelijk Kepware ligt de opmaak van deze tabel vast. Deze opmaak kan teruggevonden worden in een template die Kepware heeft opgesteld. Hierin worden de gegevens volgens een bepaalde methode gelogd op de SQL server. Onderstaande tabel geeft weer hoe deze moet worden opgemaakt. 

ID (Pk, integer) o Is de unieke ID waarmee een logging wordt gekenmerkt.



Item (string) o Omschrijving van het loggingspunt



Value (integer) o Geeft de waarde van het gelogde punt weer



Quality (integer) o Geeft de kwaliteit aan van de verbinding



DatumCreatie (datetime) o De datum waarop het punt gelogd is



DatumUpdate (datetime) o De datum waarop het punt het laatst is geupdate. Wordt niet gebruikt in mijn applicatie maar is nodig voor Kepware.



LastUser (string) o Geeft de gebruikersnaam weer van de laatste gebruiker



LastHost (string) o Geeft de hostnaam weer van de laatste gebruiker

Figuur 27 : Ingevulde tabel tblConfLogProductie


46

4.2.9. Tabel tblConflogProductieMachines Om te weten welke machines juist moeten worden weergegeven op het Scada rooster is er een extra tabel voorzien. Deze tabel houdt de naam van de machine bij en de plaats op het rooster. 

prmacId (Pk, integer) o Is de unieke ID waarmee een machine wordt gekenmerkt.



prmacNaam (string) o De naam van de machine.



prmacBoxNummer (integer) o Is een unieke nummer die overeenstemt met een nummer van een box op het Scada rooster.

Figuur 28 : ingevulde tabel tblConflogProductieMachines


47

5 Handleiding software 5.1. Installatie 5.1.1. Aanmaken Tabellen op database Voordat met het programma kan worden gewerkt moeten tabellen op de database worden aangemaakt. Een gedetailleerde beschrijving is te vinden in vorig hoofdstuk. Vergeet niet om de ploeg tabel volledig in te vullen. Want het programma heeft deze data nodig om te kunnen functioneren.

5.1.2. Instellen app.config In de app.config file zijn alle variabelen naar buiten gebracht die eventueel kunnen veranderen. Om niet het hele programma te hoeven aanpassen kan deze XML file worden gewijzigd via kladblok of een ander programma. Het eerste dat moet worden ingesteld is de connectiestring. Zonder de connectiestring kan geen toegang worden bekomen op de database. Ook moeten de locaties vanwaar de Excels en errorfiles worden opgeslagen aangepast worden. Omdat het programma zal worden gebruikt op verschillende afdelingen is er in het app.config file een sleutel voorzien. Deze sleutel zal later bepalen welke tabellen zullen worden gebruikt (in het huidige programma zijn reeds twee instellingen mogelijk). In dit geval is deze ingesteld op 1. Hierdoor zullen de tabellen worden gebruikt uit de eerste instelling. Code:

Locatie: Door het gebruik te maken van een serversetup is de naam een veranderd naar ScaPla.exe . Je kan diet herkennen aan het XML formaat. Voor windows vista en windows 7 : c:\users\username\AppData\Local\Apps\2.0\ random gegenereerde naam \ random gegenereerde naam Voor oudere windows versies: C:\Documents and settings\USERNAME\local settings\Apps\random gegenereerde naam\ random gegenereerde naam


48

5.1.3. Aanpassen tabelnamen Om het programma perfect te laten functioneren moeten de tabelnamen juist zijn ingesteld. Deze kunnen worden ingesteld in de app.config file. Hierin zijn reeds twee instellingen voorgeprogrammeerd. Mochten er meer dan twee afdelingen zijn zal dit moeten worden uitgebreid. In onderstaande code is de tabel van de persoon als voorbeeld gebruikt. De zelfde aanpassingen zullen moeten worden gedaan voor de andere tabellen. Code:

In bovenstaande code zijn twee mogelijkheden voorzien. Elke mogelijkheid kan een andere tabelnaam bevatten. Voor een derde mogelijkheid zal bovenstaande code moeten uitgebreid worden met een extra sleutel. Dit kan gebeuren door een vorige sleutel te kopiëren en de index te verhogen. Dit zit er dan als volgt uit : Code:

Omdat er in het bestaande programma maar twee instellingen zijn voorgeprogrammeerd zal in het programma zelf moeten worden bij gecodeerd. Hierbij hoeft enkel de Globals klasse aangepast te worden. Code: Public Shared ReadOnly Property TabelPersoon() As String Get Select Case ConfigurationManager.AppSettings.Item("Cijfer") Case 1 Return ConfigurationManager.AppSettings.Item("TabelPersoon1") Case 2 Return ConfigurationManager.AppSettings.Item("TabelPersoon2") End Select End Get End Property

De code is zo geprogrammeerd dat het Cijfer bepaald welke tabel zal worden gebruikt in het programma. Dus indien je een derde instelling gaat voorzien hoeft hier enkel een derde case worden toegevoegd en daaronder een verwijzing voorzien naar de derde tabel.


49

5.1.4. Toekenning van de privileges aan de gebruiker Het laatste wat nog moet worden ingesteld zijn de privileges van de gebruikers. Aangezien deze software overal kan worden geïnstalleerd en niet iedereen toegang mag hebben tot de planningstool zijn deze functies beveiligd. Om niet telkens een passwoord te moeten ingeven is geopteerd om te werken met de loginnaam van de gebruiker op de pc. Aangezien deze voor iedereen uniek is kan dus een onderscheid worden gemaakt wie het programma gebruikt. Bij de app.config‐file kunnen de gebruikers die toegang hebben tot de planningstool worden ingegeven. Doordat de loginnaam bij het inloggen in windows niet hoofdlettergevoelig is moeten dus 3 variaties worden ingegeven. Een voorbeeld van een gebruiker is dan “DILA_Dila_dila”. Waarbij de _ wordt aanzien als een spatie. Code:

5.1.5. Setup & installatie Na alles is geconfigureerd kan het programma gepubliceerd worden. Hoe dit best wordt aangepast bekijk je best in 4.1.3. Dit is het geval als er meerdere dezelfde programma’s gebruikt worden. Wat noodzakelijk zal zijn als het programma gebruikt wordt in verschillende afdelingen. Moet een nieuwe upload locatie worden bepaald zodat de verschillende programma’s niet worden overschreven. Hierna kan het programma worden geïnstalleerd op de pc’s.


50

5.2. Werking Planningstool 5.2.1. Toevoegen van machines en personen Het eerste wat moet worden gedaan is het toevoegen van personen en machines. Als dit niet gebeurd, is er geen data waar mee gewerkt kan worden. Het toevoegen van gegevens kan gedaan worden via het extra tabblad planning gegevens. Deze kan geopend worden door in het menu onder planning op planning gegevens te klikken. Om het machinepark voor te stellen moet in de database een lijst aanwezig zijn met machinenamen. Deze kan toegevoegd worden in het geopende tabblad. Zoals voorgesteld wordt in onderstaande invulmodule. Hier kan een machine worden toegevoegd door de naam in te geven op de button add te klikken. Mocht de naam veranderen, moet de machinenaam worden aangeklikt. Hierna komt de naam in de textbox terecht waar deze kan worden aanpast. Na de aanpassingen kan er op dezelfde button worden geklikt waar nu edit zal staan. Het is ook mogelijk om de volgorde van de machines te herschikken. Dit is belangrijk want de volgorde zal worden overgenomen voor de lay‐out van de planning. Mocht er een machine dan toch nog overbodig zijn kan deze verwijderd worden door deze te selecteren en op de delete knop te drukken.

Figuur 29 : Interface voor het toevoegen van machines in de planningstool


51

Voor het toevoegen is een zelfde interface voorzien. Met weliswaar iets meer mogelijkheden om gegevens in te geven. De interface is hieronder te zien. Het is dus mogelijk een nieuwe persoon in te voegen door gewoon alle velden in te vullen en op add te klikken. Net zoals bij de machines kan een persoon worden aanpast mocht er een wijziging nodig zijn. Dit ook door in de lijst de persoon aan te klikken en daarna de gegevens aan te passen en vervolgens op de edit button klikken. Wanneer een geselecteerde persoon niet meer geselecteerd hoeft te worden, wordt de unselect button gebruikt. Ook is er een mogelijkheid voorzien om een persoon te verwijderen uit de database. Merk wel op dat hierna deze persoon uit alle gelegde verwijzingen zal verwijderd worden.

Figuur 30 : Interface om een persoon toe te voegen


52

5.2.2. Functionaliteiten planningstool 5.2.2.1. Aanmaken nieuwe planning Na het invoegen van de gegevens kan een nieuwe planning worden aangemaakt. Hierbij moet er een datum worden geselecteerd. Hierna moet vervolgens een ploeg worden gekozen aan de hand van welke periode deze werken bv. NA voor nachtploeg. Nu dit is gedaan word automatisch een lijst aangemaakt met de personen die beschikbaar zijn. Mocht een persoon in die ploeg tijdskrediet hebben wordt deze automatisch toegevoegd aan de lijst tijdskrediet. Nu kan er worden gepland. Personen kunnen op machines geplaatst worden door te klikken op een persoon in de lijst en vervolgens te klikken op een machine. Merk op dat enkel personen kunnen geplaatst worden op een machine als deze oranje is opgelicht. Is dit niet zo dan betekend dit dat deze persoon deze machine niet kan bedienen. Is de machine groen dat staat er een persoon op. De naam van deze persoon staat dan naast de machine. Naast het plaatsen van een persoon kan deze ook verwijderd worden van een machine. Dit gaat net andersom. Er wordt geklikt op de naam van de persoon die naast de machine staat. En vervolgens wordt er terug geklikt op de lijst waar de personen normaal staan indien ze niet zijn ingeplant. Of als de persoon in een andere lijst moet komen kan deze ook daar geplaatst worden. Naast het plannen van een persoon op een machine kan deze op de zelfde manier worden geplaatst in een lijst. Deze lijsten geven dan weer welke status deze persoon meekrijgt. Enkele lijsten zijn onder ander als een persoon ziek is, tijdskrediet heeft, … Om een persoon te verwijderen uit een lijst moet er worden gedubbeld klikt. Dit is de basis om een normale planning aan te maken. Natuurlijk is er een uitgebreidere functie voorzien. Hierbij bestaat de mogelijkheid om personen in te plannen van een andere ploeg. Dit gebeurd door onder de lijst met beschikbare personen een andere ploeg te selecteren in de dropdownbox. Hierna zal een lijst worden getoond van de andere ploeg. Deze personen kunnen net zoals de normale ploeg ingepland worden. Merk op dat als een persoon uit een andere ploeg ingeplant wordt dat deze niet meer kan ingeplant worden in een andere ploeg diezelfde dag.

5.2.2.2. Planning inladen Naast het aanmaken van een nieuwe planning kan er ook een oude planning worden ingeladen. Dit gebeurd aan de hand van de 2 buttons die voorzien zijn naast de datum selectie. Zo kan een planning van gisteren of een planning van 2 weken geleden worden ingeladen. Merk op dat op Maandag enkel de planning van 2 weken geleden kan worden ingeladen. Dit doordat op maandag de ploegwisseling plaats vind. Eenmaal de planning is ingeladen kunnen aanpassingen worden gedaan.

5.2.2.3. Planning opslaan Na een planning te hebben ingeladen of gemaakt te hebben kan deze ook worden opgeslagen. Het opslaan van de planning gebeurd dan op de database. Dit is handig indien er bv een persoon zich ziek heeft gemeld, zodoende dat dit al kan ingegeven worden. Ook is dit nodig als er gebruik wordt gemaakt voor het inladen van oudere planningen.


53

5.2.2.4. Planning Verwerken Excel Als er een planning verwerkt dient te worden naar Excel kan dit door op de ‘maak Excel’ knop te klikken. Hierdoor wordt een volledig Excel file aangemaakt. Die later dan kan worden afgedrukt.

5.3. Werking Scada Voordat kan worden gewerkt met het Scada gedeelte moeten eerst de database tabellen worden aangemaakt. Vervolgens moeten de Kepware parameters juist worden ingesteld zodat gelogd worden op de database. Als dit gebeurd is kunnen de juiste instellingen gedaan worden om data binnen te lezen. Vergeet niet dat de naamgeving in Kepware vast ligt. Naamgeving : PRODUCTION_LOGGING.PORTAALROBOT_SHAGGY.Bundels@st

Het punt geeft een scheiding aan tussen de elementen binnen kepware. Dit wordt automatisch gedaan door kepware. Production_logging slaat op de verzamelgroep die werd aangemaakt. Hierna kan in de groep PLC’s worden toegevoegd. Elke PLC komt overeen met een machinenaam. Zo is Portaalrobot_shaggy de plc van de portaalrobot. Hierna zijn parameters toegevoegd in de PLC connectie. Hierbij wordt de omschrijving meegegeven en de eenheid. Het programma ziet dit onderscheidt door het @ teken. Ook zal het programma alle _ vervangen door een spatie.

Figuur 31 : Interface Kepware


54

Doordat het Scada gedeelte dynamisch is opgebouwd hoeft geen code worden geschreven mocht er een machine worden bijgevoegd. Er hoeft enkel een machinenaam en plaats worden toegevoegd in een tabel. Om deze naam en plaats in de tabel te schrijven is een extra tabpagina voorzien die terug te vinden is onder menu>Scada>Gegevens Machines. Hierin moet de naam en plaats worden ingegeven.

Figuur 32 : Interface om machines toe te voegen in scada app


55

De plaats komt overeen met een plaats in het Scada scherm. De machinenaam moet de exacte zelfde naam bevatten als deze dat gebruikt wordt bij het Kepware gedeelte. Als dit juist gebeurd is zal vervolgens de machine verschijnen in het Scada gedeelte. Er zijn een totaal van 51 vakken voorzien.

Figuur 33 : Scada rooster


56

Hierna kan aan de hand van een selectie bepaalde data worden weergegeven. Dit doe gebeurd door bovenaan een bepaald tijdsinterval te kiezen. Dit kan zijn op ploegniveau, dag niveau, weekniveau, maandniveau of jaarniveau. Hierna zal na enige tijd de verwerkte data worden weergegeven. En kan er eventueel een detail view worden geopend.

Figuur 34 : Algemeen overzicht Scada gedeelte

Figuur 35 : Detail view met alle parameters


57

Figuur 36 : Detail view van een bepaalde parameter


58

Besluit Dit eindwerk beschrijft de analyse en opbouw van het software programma die ik heb geschreven voor de firma Balta Group. Het was de bedoeling dat alles van de planning gecentraliseerd zou worden. Hierin ben ik geslaagd aangezien alle gegevens die nodig zijn om een planning op te bouwen op één database worden opgeslagen. Hierdoor hoeft er geen opzoekingswerk meer gedaan te worden in tabellen, wat de fout‐kans verkleint. Bij het programmeren is er ook een bekwaamheid matrix geïntegreerd. Deze zorgt ervoor dat mensen enkel maar kunnen worden ingeplant op een machine die ze daadwerkelijk kunnen bedienen. Hierdoor is de fout‐kans zo goed als onbestaande. Door deze aanpassingen kan de planning in een veel kortere tijd en veel efficiënter worden opgemaakt. Hierdoor kan deze tijdswinst worden geïnvesteerd in ander werk. Naast het planningsgedeelte is er ook een Scada gedeelte geïntegreerd. Dit programma moest vlot aanpasbaar zijn. Hierin ben ik ook geslaagd omdat de machines worden ingegeven in een tabel die los staat van het programma. De invulling van het Scada gedeelte is dus vrij dynamisch door de afspraken die werden gemaakt met de beheerder van de Kepware logging. Naast enkele software specifieke problemen is alles toch redelijk vlot verlopen. En wordt de software reeds gebruikt in de afdeling nabewerking. De toekomst en uitbereiding van de software is reeds verzekerd aangezien men deze software wil gebruiken op alle andere afdelingen. Als de software succesvol wordt geïmplementeerd op de ganse site Avelgem is de kans groot dat het zelfs wordt gebruikt op andere sites van Balta Group.


59

Bronvermelding 

Balta Group, (2011). Balta Group. 12 december 2011 : www.baltagroup.com



Kepware, (2012). Advanced communication and interoperability platform. 16 maart 2012 : http://www.kepware.com



Wikipedia, (2012). Objectgeoriënteerd. 9 april 2012 : http://nl.wikipedia.org/wiki/Objectgeori%C3%ABnteerd



Wikipedia, (2012). SQL. 9 april 2012 : http://en.wikipedia.org/wiki/SQL



Vandenhoeke, D. (2011). Data management. Cursus Howest Kortrijk.



Vandenhoeke, D. (2011). Communication. Cursus Howest Kortrijk.



Cottyn,J. (2011). Total plant automation1. Cursus Howest Kortrijk.


60

Vb.net planningstool en Scada applicatie

Recommend Documents