De auteur geeft de toelating deze SCRIPTIE voor consultatie beschikbaar te stellen en delen van de SCRIPTIE te kopiëren voor persoonlijk gebruik

Faculteit Toegepaste Wetenschappen Vak gro ep Elek tro nic a en In fo rmaties y s teme n

O n t w erp v a n e en w eb in t er f a c e v oo r vi s ua li s a ti e e n r a ad pl eg ing v a n t e s tg eg e v en s bij d e f irm a C he v ronT e x a co

Peter De Nijs

Promotor:

Prof. Dr.Ir. R. Van d e W alle

Begel eider: Lic. P. Lambert

Eind ver ha ndeli ng tot het be hal en van d e aca demische g r a a d v a n g e d i p l o m e e r d e i n d e A a n v u l l e n d e S t u d i e s va n In fo rmatic a

Aca de m ie ja a r 2002 -20 03

Voorwoord Vooreerst wil ik diegene n bedanken die mede verantwoordelijk zijn voor de realisatie van dit eindwerk. Mijn begeleider op de UGent, lic. Peter Lambert, die steeds het volledige van zichzelf heeft gegeven voor het antwoorden op mijn vragen in verband met de vele Windows-mysteries.

Ook voor nuttige tips voor het opstellen van

degelijke algoritmes kon ik steeds bij hem terecht. Daarnaast mijn begeleiders op ChevronTexaco die het weer eens mogelijk maakten om een eindwerk te maken in een interessant vakgebied. Aan allen mijn dank daarvoor

De auteur geeft de toelating deze SCRIPTIE voor consultatie beschikbaar te stellen en delen van de SCRIPTIE te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze SCRIPTIE.

Peter De Nijs , 26 mei 2003

I

Ov erzicht Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Ontwerp van een webinterface voor visualisatie en raadpleging van testgegevens bij de firma ChevronTexaco door Peter De Nijs Eindverhandeling tot het behalen van de academische graad van gediplomeerde in de Aanvullende Studies van Informatica Promotor: prof. dr. ir. R.Van de Walle Thesisbegeleider: lic. P. Lambert Academiejaar 2002-2003 Samenvatting In de Coolants groep worden koelvloeistoffen getest door middel van testopstellingen. Deze testopstellingen genereren data die bepalen of een koelvloeistof voldoet aan de interne en externe normen. Om deze data te loggen werd vroeger gebruik gemaakt van een aparte PC per testopstelling, waarbij de laborant dan manueel de data via diskette kon afhalen. In 2003 werd door de groep een eWon datalogger aangekocht die de taak overnam van het loggen. Deze eWon werd geconfigureerd zodat periodisch de logbestanden naar een server worden doorgestuurd waar de data automatisch wordt toegevoegd aan een centrale databank. Via de webtoepassing is het mogelijk deze databank te raadplegen. De opgevraagde data wordt dan voorgesteld als HTML tabel en in een Excel-bestand. Er kunnen grafieken aan dit Excel-bestand worden toegevoegd door een apart Visual Basic programma. Trefwoorden datalogger, ODBC, SSL, ASP, normalisatie, normaalvorm, stored procedures, Access, bandbreedte, server II

Inhoudstabel Voorwoord

___________________________________________________ I

Overzicht

___________________________________________________ II

Inhoudstabel

__________________________________________________ III

HOOFDSTUK I.

INLEIDING__________________________________________ 1

I.1.

Voorstelling ChevronTexaco

1

I.2.

Situering van het eindwerk

3

I.3.

Doel van het eindwerk

5

HOOFDSTUK II. eWon DATALOGGER _________________________________ 7 II.1.

Inleiding

7

II.2.

Specificaties datalogger

7

II.3.

Oplossen probleem van dataverlies

8

II.4.

eWon webserver

9

HOOFDSTUK III. DATABANK________________________________________ 10 III.1.

Inleiding

10

III.2. Ontwerp van de databank 10 III.2.1. Basisrelaties en afhankelijkheidsdiagram ______________________ 10 III.2.2. Normalisatie ____________________________________________ 13 III.2.3. Eerste normaalvorm ______________________________________ 13 III.2.4. Tweede normaalvorm_____________________________________ 13 III.2.5. Derde normaalvorm ______________________________________ 13 III.2.6. BCNF: Boyce Codd Normal Form ___________________________ 14 III.2.7. Praktisch afhankelijkheidsdiagram ___________________________ 15 III.2.8. Besluit ontwerpproces: relationeel model van de volledige databank_ 16 III.3. Implementatie databank 17 III.3.1. Inleiding _______________________________________________ 17 III.3.2. Grootte van de databank __________________________________ 18 III.3.3. Stored Procedures _______________________________________ 18 III.3.4. Initialisatie _____________________________________________ 19 III.3.5. Updates databank _______________________________________ 19 HOOFDSTUK IV. WEBTOEPASSING __________________________________ 20 IV.1.

Functionaliteit

20 III

IV.2.

Flowchart webtoepassing

21

IV.3. Overzicht en betekenis pagina’s 22 IV.3.1. index.htm ______________________________________________ 22 IV.3.2. controle.asp ____________________________________________ 22 IV.3.3. ontvangst.asp ___________________________________________ 23 IV.3.4. keuze.htm______________________________________________ 23 IV.3.5. banner.asp _____________________________________________ 24 IV.3.6. main.htm ______________________________________________ 24 IV.3.7. tags.asp _______________________________________________ 24 IV.3.8. queryform.asp __________________________________________ 25 IV.3.9. query.asp ______________________________________________ 26 IV.4. Graphs.exe 28 IV.4.1. Inleiding _______________________________________________ 28 IV.4.2. Functionaliteiten _________________________________________ 29 IV.5. GEBRUIKERS databank 30 IV.5.1. Inleiding _______________________________________________ 30 IV.5.2. ADD_USER.EXE ________________________________________ 30 IV.6. Berekening benodigde bandbreedte 30 IV.6.1. Wet van Zipf ____________________________________________ 30 IV.6.2. Toepassing wet van Zipf __________________________________ 31 HOOFDSTUK V. SERVER __________________________________________ 32 V.1.

Inleiding

32

V.2.

FTP-server

32

V.3.

Webserver

32

V.4.

Events

33

V.5. Toevoegen van de data aan de databank via events 33 V.5.1. Algoritme om de ruwe data toe te voegen aan de databank________ 34 V.5.2. Eerste algoritme zonder arrays _____________________________ 35 V.5.3. Tweede algoritme met arrays en zonder hulparray ______________ 36 V.5.4. Derde algoritme met arrays en met hulparray __________________ 38 V.5.5. Besluit algoritmes________________________________________ 42 HOOFDSTUK VI. BEVEILIGING ______________________________________ 43 VI.1.

Inleiding

43

VI.2.

Login en paswoord

43

VI.3.

Beveiligen databank ‘gebruikers’ via ODBC-link

43

VI.4.

Beveiligen databank ‘gebruikers’ door ‘one way hashing’

44

VI.5.

SSL (Secure Socket Layer)

44

HOOFDSTUK VII. BESLUIT __________________________________________ 46 VII.1.

Evaluatie oplossing

46

IV

VII.2.

Mogelijke optimalisaties

46

Lijst van figuren __________________________________________________ 48 Lijst van tabellen __________________________________________________ 49 Bijlage1:Gebruikersmanual _________________________________________ 50 Bijlage2: Administratorsmanual______________________________________ 51

V

HOOFD STUK I. I.1.

INLEIDI NG

Voorstelling ChevronTexaco

ChevronTexaco Global Lubricant Solutions ChevronTexaco Technology Ghent A Div. of S.A. Texaco Belgium N.V. Technologiepark Zwijnaarde nr 2 9052 Gent Belgium Tel: +32/9.240.72.11 Fax: +32/9.240.72.22

Oliegigant ChevronTexaco is één van de grootste olieproducenten van de wereld. Deze geïntegreerde oliemaatschappij zorgt voor de exploratie van de ruwe petroleum, voor de raffinage en de verwerking en de verkoop van de eindproducten. ChevronTexaco beheert een groot assortiment van brandstoffen, smeermiddelen, antivries en brandstofadditieven die verkocht worden in

Europa, Zuid-Amerika,

Canada, West-Afrika, USA, Azië en Oost-Afrika.

1

HOOFDSTUK I : INLEIDING

ChevronTexaco ontstond onlangs toen Chevron de groep Texaco volledig overnam. Deze groep bevat ook een joint venture met Shell (USA) en Caltex (Zuid-Afrika en Australië). In 1999 heeft ChevronTexaco Global Products (CTGP) het QS 9000 certificaat verkregen. Dit certificaat omvat ontwikkeling, productie, distributie, marketing en verkoop van de smeermiddelen en koelmiddelen in Europa. Dit certificaat betreft de activiteiten in Spanje, de verkoop van producten en de distributie in de Benelux en de smeermiddelen marketing in landen als het Verenigd Koninkrijk, Frankrijk, Spanje, Duitsland en de Benelux. Naast dit verkregen QS 9000 certificaat, heeft de ChevronTexaco Technology Ghent (CTTG) sinds 1992 het ISO 9001 certificaat. Dit omvat alle producten binnen de CTTG-groep van smeermiddelen, koelmiddelen tot de technische service. Daarbij aansluitend (bij de al verkregen certificaten) is de CTGP bezig met het invoeren van het ISO 140001 management systeem. Om een continu garantie te geven aan de klanten en om onderzoek te voeren naar nieuwe middelen, heeft ChevronTexaco verschillende onderzoekscentra over de hele wereld. Deze centra bestaan uit een groep onderzoekers die nauw samenwerken met de verkopers om zo producten te ontwikkelen die aan de vraag van de klant voldoen.

Deze

onderzoekscentra

bevinden

zich

onder

andere

in

Montebello (Californië), Beacon (New York) en Gent. Daarnaast zijn er nog nauwe samenwerkingen met technologiebedrijven in de USA. De objectieven van deze onderzoekscentra zijn hoofdzakelijk ontwikkeling van nieuwe brandstoffen, nieuwe smeermiddelen en nieuwe koelmiddelen maar daarnaast worden er ook nog chemische analyses (ongeveer 80.000 stalen per jaar) uitgevoerd voor klanten. ChevronTexaco Technology Ghent is het onderzoekscentrum in Gent-Zwijnaarde en is een onderdeel van de C TGP business unit. Dit onderzoekscentrum verricht onderzoek naar zowel oliën, koelmiddelen als brandsto fadditieven. De onderzoekscel Coolants binnen de CTTG-groep, waar dit eindwerk gemaakt werd, houdt zich vooral bezig met Extended Life Coolant (XLC). Dit koelmiddel bestaat voornamelijk uit MonoEthyleenGlycol (MEG) (C 2 H4 (OH)2 ) en

2


water. Hierbij worden inhibitoren toegevoegd die ervoor zorgen dat het koelmiddel zich minder corrosief gedraagt tegenover de verschillende metalen van het koelsysteem in de motor. Het is vooral rond deze inhibitoren dat onderzoek wordt gedaan in de onderzoekscel Coolants.

I.2.

Situer ing van het eindwer k

Om de koelmiddelen te testen zijn er proefopstellingen ontwikkeld die bepaalde fysische eisen van het koelmiddel testen die met de werkelijkheid overeenkomen. Het is op basis van deze testresultaten dat er bepaald wordt of een koelmiddel voldoet aan de interne en externe normen. De condities waaraan een proefopstelling moet voldoen wordt beschreven door een teststandaard.

Deze teststandaard

beschrijft dus welke temperatuur, druk, debiet,... moet worden gebruikt bij een bepaalde testopstelling . In totaal zijn er 4 verschillende teststandaarden waarmee men in de Coolants werkt: ‘ASTM1384’, ‘ASTM4340’, ‘SEAL TEST’ en ‘DHTT’. Elk van deze teststandaarden heeft zijn eigen ‘soort’ testopstelling. Daarmee wordt bedoeld dat men bij de teststandaard ‘ASTM1384’ spreekt van een ‘POT-opstelling’, bij ‘ASTM4340’ gebruikt men een ‘PIJP-opstelling’, de ‘SEAL TEST’ gebruikt een ‘VAT-opstelling’ en bij ‘DHTT’ is er geen specifieke benaming en spreekt men de

TEST standaard

ASTM1384

TEST POT1, POT2,… OPSTELLING

TAGS

TEMP SP TEMP

ASTM4340

SEAL TEST

DHTT

PIJP1, PIJP2,…

VAT1, VAT2,…

DHTT1,…

TEMP SP TEMP DRUK

TEMP COUP DRUK …

DRUK DEBIET …

Figuur 1: Relatie test-standaard, testopstelling en tags

3


testen apart aan: ‘DHTT1’, ‘DHTT2’,… Van elke teststandaard zijn er een aantal testopstellingen waarvan het exacte aantal steeds verschillend is. Elke teststandaard heeft een aantal tags. Tags zijn benamingen voor de parameters die in de test gebruikt worden. Voorbeelden van tags zijn temperatuur, druk, setpoint druk, enz. Deze tags bevatten de gewenste data en worden daarom periodisch gelogd. Dit wil zeggen dat periodiek (bijvoorbeeld om de twee minuten) de waarde wordt genomen van de tags en wordt opgeslagen samen met de tijd. Dit wordt gedaan via een eWon datalogger.

Het zullen deze gegevens zijn die via de

webtoepassing worden opgevraagd.

Aangezien elke teststandaard verschillende

condities oplegt en andere praktijksituaties simuleert, zal ook het aantal en de soort tags per test verschillend zijn. Een duidelijk overzicht tussen de teststandaarden, testopstellingen en tags wordt in Figuur 1 gegeven. Een overzicht van de teststandaarden, testopstellingen, aantal en tags wordt gegeven in Tabel 1. Tabel 1: Overzicht teststandaarden, testopstellingen en tags

TestTestStandaard opstelling ASTM1384 POT

Aantal Test-opstellingen 24 (POT1àPOT 24)

Soorten tags Temperatuur Setpoint Temperatuur

ASTM4340

PIJP

14 (PIJP1àPIJP14)

Temperatuur Setpoint Temperatuur Druk

SEAL TEST

VAT

15 (VAT1àVAT15)

Temperatuur Coupon Setpoint Temperatuur Coupon Temperatuur Vloeistof Setpoint Temperatuur Vloeistof Druk

DHTT

n.v.t.

5 (DHTT1àDHTT5)

Druk Setpoint Druk Debiet Setpoint Debiet

4


Temp-Input Setpoint Temp-Input Temp-Output Temp-Mid Temp Blok1 Setpoint Temp Blok1 Temp Blok2 Setpoint Temp Blok2 Temp Coupon1 Setpoint Temp Coupon1 Temp Coupon2 Setpoint Temp Coupon2 In totaal moeten er dus 271 tags gelogd worden.

I.3.

Doel van het eindwerk

Alle data wordt gelogd via de eWon datalogger. Deze data wordt inwendig in de datalogger opgeslagen in de vorm van een logbestand in tekstformaat. Aangezien de eWon datalogger een beperkt geheugen heeft voor de opslag van de data (320-384kB) en het logbestand circulair is — dit wil zeggen dat na het schrijven van de laatste lijn terug naar het begin van het bestand wordt geschreven — zal na een bepaalde tijd de data worden overschreven met nieuwe data. Het is echter duidelijk dat er geen data mag worden verloren. Een eerste opgave van het eindwerk was dus het zoeken naar een oplossing zodat er geen dataverlies meer optreedt. De eWon datalogger logt 24u op 24u, ook wanneer er geen koelmiddel getest wordt in een bepaalde testopstelling. Deze data zal geen nuttige data opleveren voor de laboranten en dus was er nood aan een systeem waarbij de laborant specifieke data kan opvragen die voor hem wél nuttig is Dit zal het hoofddoel zijn van het eindwerk en het systeem zal als functionaliteit moeten hebben dat een laborant de data kan ophalen van een door hem gekozen testopstelling en een door hem gekozen tijdsinterval. Daarnaast moet de selectief opgehaalde data worden voorgesteld in Excel-formaat zodat verdere verwerking op een eenvoudige manier mogelijk is door de laborant. 5


Daarnaast is het evident dat alles beveiligd moet worden zodat enkel bevoegde personen de data kunnen raadplegen. Een overzicht van de onderdelen en hun onderlinge interacties kan men zien in Figuur 2. Daarin kan men duidelijk zien dat er twee delen zijn, namelijk om de data toe te voegen en om opgeslagen data op te vragen. Dit zal verlopen via dezelfde server en dezelfde databank. De doelstellingen van het eindwerk kunnen dus als volgt worden samengevat: •

Oplossen probleem van data verlies van de eWon datalogger

•

Ontwerp databank voor opslaan van de data

•

Ontwerp webtoepassing voor raadplegen databank

•

Keuze server en implementatie ervan

•

Dit alles rekening houdend met een degelijke beveiliging

SERVER

PUT

GET<pagina>

FTP

HTTP

eWon

HOST

SQL-QUERY

UPDATE

DATA OPVRAGEN

DATA OPSLAAN DATABASE

Figuur 2 : Interacties tussen eWon, server en host

6

HOOFD STUK II. eWon D ATALOGG ER II.1. Inleiding Deze datalogger werd recentelijk aangekocht door de Coolants-groep en werd praktisch nog niet geïmplementeerd. Als eerste stap in dit eindwerk was het dus de bedoeling om deze eWon datalogger correct te configureren. Voorlopig is er nog maar één datalogger aanwezig voor de verschillende testopstellingen. Indien deze datalogger zijn degelijkheid heeft bewezen zou het in de toekomst de bedoeling zijn om ook in andere testen deze datalogger te gebruiken.

II.2. Specificaties datalogger Elk van de testopstellingen bestaan uit twee delen: een deel dat de fysische opstelling bevat waarin het koelmiddel wordt getest en een tweede deel dat instaat voor de logging en sturing van de test en de visualisatie van de huidige parameters. De communicatie tussen beide opstellingen gebeurt via modbus (RTU) en er wordt gebruik gemaakt van de OPC server technologie van Kepware om per test een 10-tal parameters te definiëren, deze kunnen dan gebruikt worden door OPC clients. De eWon datalogger maakt tevens gebruik van modbus en er kunnen inwendig in de datalogger verschillende tags gedefinieerd worden. Door het juiste modbus adres te gebruiken komt een eWon tag overeen met een tag van een testopstelling . In de eWon kunnen we instellen om de hoeveel seconden hij de werkelijke waarde moet gaan ophalen van een tag. Dit zal praktisch ongeveer vijf seconden zijn. Dit noemt met in de eWon ‘real time logging’. Dit wil dus zeggen dat de waarde van een tag (of parameter) in de eWon overeenkomt met de werkelijke waarde op dat moment van de respectievelijke tag in de testopstelling (op vijf seconden na). Men neemt bewust een niet al te lage logperiode om het modbus netwerk niet te overbelasten.

7

HOOFDSTUK II : eWon DATALOGGER

Aangezien ook de sturing van de testen gebeur t over modbus, is een overbelasting van het netwerk zeker niet aan te raden. Indien er nu in de eWon evenveel tags geconfigureerd zijn als er aanwezig zijn in de verschillende tests, kan de eWon periodisch de waarde van de tags gaan opslaan. Dit noemt men bij de eWon ‘historical logging’ en houdt in dat de waarde van de tags op regelmatige tijdstippen worden opgeslagen in een logbestand.

De periode

waarmee dit gebeurt noemt men de logperiode of sampleperiode en bedraagt ongeveer 120 seconden. Ook deze periode wordt bewust niet te laag gekozen door de beperkte grootte van het logbestand . Mocht een te kleine logperiode gekozen worden dan zou het circulaire logbestand te frequent de oude data overschrijven en zou er een groter gevaar voor dataverlies optreden. Merk op dat de logperiode van de ‘historical logging’ verschilt van de periode die gebruikt wordt in de ‘real time logging’. De periode bij de ‘real time logging’ kan men veel kleiner nemen omdat deze modus de data niet gaat opslaan zoals dat wel gebeurt bij ‘historical logging’.

II.3. Oplossen probleem van dataver lies De eWon beschikt over een FTP – client (FTP staat voor File Transfer Protocol). Daardoor is het mogelijk om bestanden vanuit de eWon te versturen via FTP naar een FTP-server. Dit zullen we dus ook doen om dataverlies tegen te gaan. Namelijk door het logbestand periodisch door sturen naar een server, mag de eWon zonder probleem de oude data overschrijven. Een kleine berekening toont ons aan dat indien het bestand om het uur wordt doorgestuurd naar de FTP-server er geen gevaar voor dataverlies meer bestaat: •

een logbestand met slecht 1 logging van de 271 tags heeft een grootte van 11kB (praktisch gemeten)

•

theoretisch kan de grootte van het logbestand maximaal 384kB worden

•

dit betekent dus: 384 / 11 ˜ 35 keer dat er gelogd kan worden zonder dataverlies

•

bij een logperiode van 120s betekent dit: 120s * 35 = 4200 s zonder dataverlies

8

HOOFDSTUK II : eWon DATALOGGER

Dus er kan zonder problemen 4200s = 1,17h gelogd worden zonder dataverlies. Dit betekent dus als het logbestand om het uur wordt doorgestuurd naar de FTP-server, er geen dataverlies meer kan optreden. Een periode van 1 uur is zeker voldoende omdat de grootte van het logbestand in de praktijk groter zal zijn dan 384kB. Dit komt omdat de maximale grootte van het logbestand afhankelijk is van het gebruik van het inwendig geheugen van de eWon door het aantal tags, aantal pagina’s,enzovoort. Merk op dat het wel noodzakelijk is om een telkens een bestand door te sturen met een unieke naam aangezien anders de bestanden op de server wordt overschreven.

Daarom zal de naam van het bestand telkens worden

opgebouwd uit de volgende string : “LOG_”&datum&uur&”.txt” . Waarbij “LOG” een vaste string is, “datum” de datum van vandaag voorstelt en dynamisch wordt ingevuld, idem voor “uur”, “.txt” wijst aan het bestand een textformaat toe. Door deze naamgeving is men zeker dat men nooit twee keer hetzelfde bestand zal doorsturen als men om het uur logt. De eWon laat toe om scripts te schrijven in basic. Daardoor kan het doorsturen van het logbestand via FTP geautomatiseerd worden. Daarvoor heeft de eWon een specifiek commando dat PUTFTP heet waarbij men het type van bestand opgeeft en via de instellingen van de eWon wordt het naar de desbetreffende FTP-server gestuurd. Daarbij aansluitend kan een timer ingesteld worden op een periode van 1 uur en via een trigger bij het verlopen van de timer kan dan het bestand telkens doorgestuurd worden waardoor het probleem van dataverlies wordt vermeden.

II.4. eWon webser ver De eWon datalogger heeft intern een webserver. De functionaliteit en het voorziene geheugen is echter beperkt en zou dus niet geschikt zijn om de volledige webapplicatie op de eWon te laten draaien. Toch kan deze functionaliteit van de eWon benut worden om pagina’s te tonen die de ‘real time logging’ visualiseren. Deze pagina’s geven dan aan wat de huidige waarde is van de tags op dat moment. Via de latere website kunnen dan via een redirect deze pagina’s geraadpleegd worden.

9

HOOFD STUK III . D ATAB AN K III.1. Inleiding De logbestanden die afkomstig zijn van de eWon datalogger, zijn opgeslagen in tekstformaat. Dit formaat is vooreerst absoluut onhandig om makkelijk specifieke data op te vragen en aangezien er om het uur een nieuw bestand wordt doorgestuurd, wordt het aantal bestanden dat men moet overlopen zeer groot. Een betere en handiger oplossing is door het gebruik van een databank. Telkens een nieuw bestand wordt opgeslagen in de FTP-server, wordt de aanwezige data in het tekstbestand toegevoegd aan de databank. Daardoor krijgt men een centralisatie van alle data en wordt het opzoeken eenvoudiger. Hoe het toevoegen aan de databank precies gebeurt wordt later uitgelegd in paragraaf V.5. Merk op dat in het relationeel model de termen relatie, tupel en attribuut worden gebruikt in plaats van respectievelijk de termen tabel, rij en kolom.

III.2. Ontwer p van de databank Een goed ontwerp is onontbeerlijk voor het makkelijk opvragen van de data en later onderhoud van de databank.

Bij het opstellen van de databank wordt eerst

vertrokken van één grote relatie en via normalisatie wordt dan uiteindelijk de verschillende relaties van de databank bekomen.

III.2.1. Basisrelati es en afh a nkelijkhei dsdi a gr am Per teststandaard wordt een relatie voorzien. Aangezien we vijf verschillende teststandaarden hebben, zijn er dus vijf gelijkaardige basisrelaties.

Als

voorbeeld voor het normaliseren wordt enkel de basisrelatie ‘ASTM4340’ beschouwd.

De andere vier basisrelaties worden op analoge wijze

genormaliseerd. In Figuur 3 wordt weergegeven welke afhankelijkheden de

10

HOOFDSTUK III : DATABANK

NAME TEST_ID STANDAARD

PARAMETER TAG_ID

TAGNAME MODBUS ADRES

ID

SP TEMP

DRUK DATUM TIMEINT TIJD

Figuur 3: Afhankelijkheidsdiagram voor ASTM4340

basisrelatie ‘ASTM4340’ bezit. Het attribuut id is de primaire sleutel van de relatie.

Aangezien de waarde van id automatisch wordt genummerd, kan

geen elke tupel in de relatie dezelfde id hebben. Elke tupel bevat ook een test_id. Dit attribuut bevat een nummer dat verwijst naar een combinatie van een standaard en een name . Met name wordt bedoeld de testopstelling die gebruikt

wordt

voor

een

bepaalde teststandaard.

Bijvoorbeeld

de

testopstelling met name = “PIJP1” is van de standaard ‘ASTM4340’ en heeft als test_id nummer 1. Een andere testopstelling met name = “PIJP2” van de zelfde standaard ‘ASTM4340’ heeft een andere test_id, namelijk nummer 2. Dus als men wil verwijzen naar een bepaalde testopstelling zal men niet de volledige naam en volledige standaard gebruiken, enkel de test_id. Idem voor een tag gebruikt men de tag_id in plaats van telkens de parameter, tagname en modbus adres te definiëren.

11


De attributen name en standaard zijn duidelijk functioneel afhankelijk van attribuut test_id omdat een zelfde test_id steeds overeenkomt met dezelfde name en standaard. Zelfde voorbeeld als voorheen: test_id nummer 1 komt altijd overeen met name = “PIJP1” en standaard = ‘ASTM4340’, test_id nummer 2 komt altijd overeen met name = “PIJP2” en standaard = ‘ASTM4340’.

Zo kan men dus voor alle mogelijke combinaties van

testopstellingen en teststandaarden een verwijzing maken door gebruik te maken van hun respectievelijke test_id. Dit maakt ook een uitbreiding van de bestaande testen makkelijk.

Indien men besluit om bijvoorbeeld een

testopstelling “PIJP15” toe te voegen aan de teststandaard ‘ASTM4340’, dan is het voldoende om een nieuwe test_id te creëren waarmee men naar deze combinatie kan verwijzen. Zoals eerder vermeld bezit een testopstelling verschillende tags. Tags zoals temperatuur, druk,… komen gelijk voor in een testopstelling van een zelfde teststandaard. Verschillende teststandaarden hebben meer of minder en/of gelijke of verschillende tags. Elke tag die voorkomt in een testopstelling wordt ingevoegd als attribuut in de relatie. Aangezien de teststandaard ‘ASTM4340’ voor elke testopstelling (PIJP1 à PIJP14) de tags temp, sp en druk heeft, worden deze 3 tags ingevoegd als attributen in de relatie ‘ASTM4340’. Het laatste attribuut in de relatie ‘ASTM4340’ is timeint. Dit attribuut is van het type ‘long integer’ en stelt het aantal seconden voor die verstreken zijn vanaf 1 januari 1970 tot en met het tijdstip wanneer de logging gebeurd is. Dus kan men zeggen dat timeint bepaalt wordt door de datum en de tijd wanneer het sample genomen is. Of anders gezegd kan men stellen dat de attributen datum en tijd functioneel afhankelijk zijn van attribuut timeint aangezien tupels die een zelfde waarde voor timeint hebben, een zelfde waarde hebben voor datum en tijd wat dus betekent dat beide tupels waarden bevatten die op het zelfde tijdstip genomen zijn.

In paragraaf III.2.7 wordt uitgelegd waarom

datum en tijd toch worden ingevoegd als attribuut in de relatie, niet tegenstaande ze eigenlijk overbodig zijn aangezien ze kunnen berekend worden uit het attribuut timeint.

12


III.2.2. Norm alisatie Om tot een relationele databank te komen waarin men zo weinig mogelijk redundante informatie voorkomt, kan men normalisatie toepassen.

Bij

normalisatie gaat men stap voor stap de basisrelatie opsplitsen (verliesloze decompositie) zodat men relaties krijgt in een zogenaamde hogere normaalvorm.

Opdat een relationeel model voldoet aan een bepaalde

normaalvorm, moeten de relaties aan bepaalde eisen voldoen.

Door de

basisrelatie op te splitsen kan men komen tot een eerste, tweede, derde normaalvorm en verder tot de BCNF (Boyce Codd Normal Form) en vierde en vijfde normaalvorm.

Merk op dat in de praktijk niet altijd tot de hoogste

normaalvorm wordt opgesplitst.

III.2.3. Eerste norm a alvorm De eerste normaalvorm betekent: “Alle attribuutwaarden zijn scalair.” Deze eigenschap is automatisch vervuld voor relaties dus moet er niet verder worden opgesplitst.

III.2.4. Tw ee d e n orm aal vor m Tweede normaalvorm is gelijk aan de eerste normaalvorm plus een bijkomende eigenschap die zegt: “Elk niet-sleutelattribuut is irreducibel functioneel afhankelijk van een kandidaatsleutel.”

Aangezien we geen

samengestelde kandidaatsleutel is ook aan deze eigenschap voldaan.

III.2.5. Der de nor ma alvorm Derde normaalvorm houdt in dat voldaan moet zijn aan de tweede normaalvorm en 2 bijkomende eigenschappen: 1. “Geen enkel niet-sleutelattribuut is transitief afhankelijk van een kandidaatsleute l, tenzij via een andere kandidaatsleutel.” 2. “Ingeval van 1 kandidaatsleutel zijn alle niet sleutelattributen mutueel onafhankelijk.” Aan deze eigenschappen is niet voldaan in de basisrelatie omdat de attributen name, standaard, tagname, modbus adres, datum en tijd transitief afhankelijk

13


zijn van de enige kandidaatsleutel id. Om naar de derde normaalvorm over te gaan zal men de basisrelatie moeten opsplitsen. Door te splitsen in 4 relaties voldoet men aan de voorwaarden voor derde normaalvorm zoals men ziet in Figuur 4 . Daardoor krijgen we 4 relaties met elk hun kandidaatsleutel. We zien geen transitieve afhankelijkheden meer en ook alle niet sleutelattributen zijn mutueel onafhankelijk. We kunnen dus besluiten dat deze decompositie zich bevindt in de derde normaalvorm.

III.2.6. BC NF: B oyce C o dd Nor mal F orm Deze normaalvorm eist dat de relaties zich in de derde normaalvorm bevinden en dat er voldaan is aan volgende eigenschap: “De enige pijlen die voorkomen in

het

afhankelijkheidsdiagram

zijn

pijlen

die

vertrekken

uit

een

kandidaatsleutel.” Aangezien de relaties in derde normaalvorm slechts elk 1 kandidaatsleutel hebben bevinden deze relaties zich ook automatisch in BCNF.

TEST_ID TAG_ID

PARAMETER

SP

TAGNAME

ID

TAG_ID TEMP

MODBUS ADRES

DRUK

TEST_ID

TIMEINT

NAME TEST_ID

DATUM TIMEINT

STANDAARD

TIJD

Figuur 4: Afhankelijkheidsdiagram voor ASTM4340 in derde normaalvorm en BCNF

14


III.2.7. Praktisch afh a nkelijkhei dsdi a gr am In vorige paragrafen is aangetoond uit welke relaties de databank theoretisch zou moeten bestaan.

Praktisch gezien zal er 1 relatie minder gebruikt

worden, namelijk de relatie met de attributen timeint, datum en tijd. Deze attributen zullen afhankelijk worden van de kandidaatsleutel id. De reden daarvoor is dat het attribuut timeint op zich weinig betekenis heeft voor de gebruiker qua tijd.

Zoals eerder gezegd betekent het attribuut timeint de

TEST_ID TAG_ID SP ID TEMP DRUK DATUM TIMEINT TIJD NAME TEST_ID STANDAARD

PARAMETER TAGNAME TAG_ID MODBUS ADRES TEST_ID

Figuur 5: Praktisch afhankelijkheidsdiagram voor ASTM4340

15


verstreken seconden sinds 1 januari 1970 en heeft als resultaat een ‘long integer’. Aangezien de mogelijkheid bestaat dat een gebruiker zelf de databank bekijkt, is het interessanter om de attributen datum en tijd toe te voegen aan de relatie. Daardoor wordt het voor de gebruiker makkelijker om te zien welk tijdstip een tupel bevat zonder daarvoor telkens het tijdstip te moeten opzoeken in een aparte relatie. Niettegenstaande het ongemak dat de gebruiker ondervindt qua leesbaarheid van het attribuut timeint, zal het opzoeken in de databank van een tijdstip via een SQL-query eenvoudiger zijn via het attribuut timeint dan via een combinatie van de attributen datum en tijd. Daarom zal het afhankelijkheidsdiagram zoals voorgesteld wordt in Figuur 5 als oplossing gebruikt worden.

III.2.8. Besluit ont wer ppr oces: relatio n eel mo del va n de voll edi ge dat ab a nk Als besluit van het ontwerpproces van de databank wordt het relationeel model van de volledige databank weergegeven in Figuur 6. Aangezien de teststandaarden dezelfde relaties ‘TEST’ en ‘TAGS’ gebruiken , komen deze relaties natuurlijk maar één keer voor. Om bij te houden welke logbestanden er reeds zijn toegevoegd aan de databank, wordt er een laatste relatie ‘FILES’ gedefinieerd. In deze relatie bevinden zich, naast het attribuut id, de attributen logfile, timeint en oudste. In het attribuut logfile zullen de namen van de logbestanden bevinden die reeds zijn toegevoegd aan de databank , het attribuut timeint geeft het tijdstip weer wanneer het toegevoegde bestand voor het laatst is gewijzigd en het attribuut oudste geeft het oudste tijdstip aan binnen de betreffende logfile . Het is op basis van deze twee attributen dat er bepaald wordt als een bestand moet worden toegevoegd aan de databank of niet. Namelijk wanneer de naam verschillend is of als de datum van laatste wijziging voor een zelfde logbestand ouder is.

Het attribuut oudste zal belangrijk zijn wanneer er

bepaald wordt in welke databanken er moet gezocht worden bij een bepaalde opzoeking. Na ontwerp zal de databank dus bestaan uit de relaties ‘TEST’, ‘TAGS’, ‘FILES’, ‘ASTM1384’, ‘ASTM4340’, ‘SEAL’ en ‘DHTT’. 16


1

8

8

8 1

1

8

1

1

1

8

1

1

1

1

8

1

8

1

Figuur 6: Relationeel model van de volledige databank

III.3. Implementatie databank III.3.1. Inleidi n g De databank wordt gemaakt in Microsoft Access 2002 aangezien dit software pakket al aanwezig is op het bedrijf.

17


III.3.2. Gro otte va n d e d ata b ank De data afkomstig van de datalogger bevat zeer veel lijnen. Elke lijn moet toegevoegd worden aan de databank wat betekent dat de grootte van de databank zeer snel kan groeien. Mede dankzij het ontwerp, waarbij er per lijn in de databank meerdere lijnen worden gebruikt uit het logbestand, zal de groei van databank beperkt blijven tot ongeveer 100MB per maand. In de handleiding van Access staat vermeld dat de maximale grootte van een databank 2GB is. Dus aan een lineaire groei van 100MB per maand, kan de databank theoretisch maximaal 20 maanden functioneren zonder te crashen. Een oplossing voor dit probleem kon het overstappen zijn naar MySQL aangezien er daar geen beperking bestaat op de grootte. Dit werd besproken met het bedrijf maar die opteerden toch om periodisch de databank leeg te maken. Dit werd ook geautomatiseerd waarbij telkens wordt gekeken naar de grootte van de databank wanneer er een logbestand werd toegevoegd. Indien de databank te groot is geworden, wordt de databank verplaatst naar een subdirectory ‘./Database/Updated’ en krijgt de databank een unieke naam bepaald op de huidige datum. Daarna wordt er een lege databank ‘coolants’ gekopieerd ,die zich bevindt

in de directory ‘./Databank /Initial’, naar de

directory ‘./Databank’. Het is duidelijk dat deze lege databank op voorhand moet klaar staan in de directory ‘./Databank/Initial’. Dit proces wordt ook geautomatiseerd door ASP-code (ASP staat voor Active Server Pages) die bevat is in nieuwefile.asp. Deze oplossing zal het opzoeken van data niet vereenvoudigen omdat nu de kans bestaat dat de gewenste data verspreidt is over

verschillende

databanken.

Dit

opzoeken

wordt

besproken

in

paragraaf IV.3.9.

III.3.3. Store d Pr oce d ures De queries die gedaan worden naar de databank zijn steeds van dezelfde aard. Om het opzoeken daarom te versnellen wordt er gebruik gemaakt van stored procedures.

Dit zijn queries die manueel aangemaakt zijn in de

databank, met eventueel parameters, en die worden aangeroepen via de ASP-code. Daardoor vraagt de ASP-code enkel data op via de aangemaakte queries en niet rechtstreeks via de relaties in Access. 18


III.3.4. Initialisatie Bij initialisatie worden enkel de relaties ‘TEST’ en ‘TAGS’ ingevuld en de nodige queries opgesteld nodig voor de stored procedures.

In de relatie

‘TEST’ worden alle teststandaarden en testopstellingen vermeld die de datalogger zal loggen, in de relatie ‘TAGS’ worden alle tags vermeld die de datalogger zal doorsturen.

Deze relatie is zeker nodig omdat in het

logbestand afkomstig van de datalogger enkel wordt verwezen met tag_id en niet met de volledige tag_name. Welke tag hoort bij welke tag_id kan men vinden in een apart bestand van de datalogger en het is met dit bestand dat de relatie ‘TAGS’ kan worden opgesteld. Eenmaal deze relatie ingevuld weet men perfect welke tag er overeenkomt met een bepaalde tag_id uit het logbestand . De overige relaties zullen dynamisch worden ingevuld. Merk op dat de relaties ‘TEST’ en ‘TAGS’ statisch zijn en nooit zullen veranderen, tenzij manueel door de administrator.

III.3.5. Up dat es d ata ba nk Om een overzicht te krijgen van alle databanken, wordt er gebruik gemaakt van een aparte databank ‘updates’. Deze bevat slechts één relatie, namelijk FILES met attributen id, name, begintimeint en eindtimeint. Het attribuut id wordt gebruikt als primaire sleutel, het attribuut name bevat het volledige path van de databank op de server, het attribuut begintimeint geeft het oudste tijdstip aan dat in de databank aanwezig is en het laatste attribuut eindtimeint geeft het jongste tijdstip aan aanwezig in de databank. De bedoeling van deze laatste twee attributen is om het tijdsinterval weer te geven van de data in een bepaalde databank . Dit zal belangrijk zijn wanneer men een opzoeking wil doen en aan de hand van deze attributen kan men achterhalen in welke databanken moet worden gezocht op de schijf voor een bepaald tijdsinterval. Hoe dit toevoegen en opzoeken gebeurt, wordt in paragraaf V.5 en in paragraaf IV.3.9 uitgelegd.

19

HOOFD STUK I V. WEBTOEPASSING IV.1. Functionaliteit Het belangrijkste onderdeel is ongetwijfeld de webtoepassing.

Het is via deze

webtoepassing dat de gebruikers, met name de laboranten, toegang krijgen tot de databank. De laboranten zullen via de webtoepassing een keuze hebben tot het raadplegen van verschillende zaken. Een eerste functionaliteit is de zogenaamde ‘historical logging’ waarbij de opgeslagen data van de databank wordt bevraagd. Een tweede functionaliteit is de ‘real time logging’ van de eWon waarbij de laboranten worden doorgestuurd naar een pagina op de eWon zelf van waar de werkelijke waarde van bepaalde tags wordt getoond.

Naast deze twee

functionaliteiten is er ook een derde optie voorzien die toelaat om een ‘tag list’ te krijgen van een bepaalde teststandaard.

Dit houdt in dat er een tabel wordt

weergegeven waarin de opgenomen tags met hun tag_id uit de databank worden weergegeven. Als laatste aspect van de webtoepassing kan worden vermeld dat enkel bevoegde personen toegang mogen krijgen tot de website, hetgeen inhoudt dat er nood is aan een login pagina waarin de gebruikers een login naam en paswoord moeten ingeven. Er zijn dus 4 punten die de webtoepassing minimaal aan functionaliteit moet bieden: 1. ‘historical logging’: de opgeslagen data bekijken 2. ‘real time logging’: de huidige waarden van de tags opvragen 3. ‘tag list’: een lijst van tags behorende tot een bepaalde teststandaard opvragen 4. login-pagina om de veiligheid te garanderen

20

HOOFDSTUK IV : WEBTOEPASSING

IV.2. Flowchar t webtoepassing De structuur van de webtoepassing kan het best weergegeven worden aan de hand van een flowchart.

In Figuur 7 kan men grafisch zien hoe de gebruiker door de

webtoepassing kan navigeren. De bespreking van de verschillende pagina’s wordt hierna gegeven.

BEGIN INDEX_LOGERROR.HTM of INDEX_PASSERROR.ASP

INDEX.HTM

LOGIN INCORRECT CONTROLE.ASP

3x

INDEX_LOCKED.HTM

LOGIN CORRECT ONTVANGST.ASP

TAGS.ASP

QUERYFORM.ASP

eWon – real time logging

QUERY.ASP

Figuur 7: Flowchart Webtoepassing

21


IV.3. Overzicht en betekenis pagina’s Hier volgt een overzicht van de verschillende pagina’s die in de webtoepassing worden gebruikt. Merk op dat niet alle pagina’s zijn vermeld in de flowchart om deze overzichtelijk te houden.

IV.3.1. ind ex.htm Dit is de portaalpagina van de webtoepassing. Hierin moeten de gebruikers een login en een paswoord geven die dan gecontroleerd wordt door de ASPcode in controle.asp.

IV.3.2. control e.asp Controle van de login en paswoord gebeurt aan de hand van de databank ‘gebruikers’. In die databank staan de logins van de gebruikers samen met hun paswoord. Indien een gebruiker een verkeerde login heeft gegeven, dan wordt hij doorverwezen naar de pagina index_logerror.htm.

Deze biedt dezelfde

functionaliteit aan als index.htm maar vermeld erbij dat de gebruiker een verkeerde login heeft gegeven. Indien de gebruiker een verkeerd paswoord heeft gegeven wordt hij doorverwezen naar de pagina index_passerror.htm. Deze pagina bevat ASPcode omdat bij het laden van de pagina het login veld direct wordt ingevuld door de login naam dat de gebruiker ervoor heeft ingegeven. Indien een gebruiker drie maal na elkaar het verkeerde paswoord geeft, dan wordt de desbetreffende gebruiker geblokkeerd. In de databank is er namelijk een derde booleaans attribuut locked voorzien en deze wordt dan hoog gezet. Indien een gebruiker geblokkeerd is, wordt hij doorverwezen naar de pagina index_locked.htm waarin vermeld wordt dat zijn login geblokkeerd is. Deze login blijft onbruikbaar totdat de administrator in de databank manueel de login heractiveert. Als de gebruiker een correcte login en paswoord gegeven heeft dan wordt hij doorverwezen naar de pagina ontvangst.asp.

22


Er wordt ook gebruik gemaakt van het Sessie-object om de login mee te geven die dan in andere pagina’s kan worden gebruikt. In paragraaf IV.5 wordt uitgelegd dat de paswoorden geëncrypteerd worden opgeslagen

via

een

Hash-functie.

Deze

functie

is

onomkeerbaar

(‘one way hash function’), dit wil zeggen dat uit een geëncrypteerd paswoord niet het originele paswoord kan gehaald worden.

Om nu de gebruiker te

authentiseren moet men in controle.asp het ingegeven paswoord ook eerst omzetten naar de geëncrypteerde vorm en dan vergelijken met het aanwezige (geëncrypteerde) paswoord in de databank. Indien de vergelijking klopt, dan heeft de gebruiker het juiste paswoord ingegeven en wordt de gebruiker toegelaten.

IV.3.3. ont va n gst. asp Deze pagina bevat 3 frames met verwijzingen naar de pagina’s banner.asp, keuze.htm en main.htm. Bij het laden van de pagina wordt gecontroleerd of het Sessie-object niet leeg is. Indien dit wel zo is dan wordt de pagina niet getoond maar wordt een pagina getoond waarin staat dat de gebruiker zich moet aanmelden samen met een hyperlink naar index.htm.

Dit is om te vermijden dat gebruikers

toegang zouden krijgen tot de pagina zonder in te loggen door de link rechtstreeks te typen in de adresbalk, of door gebruik te maken van hun favoriete links.

IV.3.4. keu ze. htm Deze

pagina

bevat

www.scriptocean.com.

een

keuzemenu

dat

gebruikt

werd

van

Dit keuzemenu is freeware en is makkelijk te

implementeren in de webpagina via JavaScript. In dit keuzemenu kan de gebruiker per teststandaard kiezen tussen ‘view tags’, ‘historical logging’ en ‘real time logging’. Deze link zal telkens de betreffende pagina laden in het main-frame. Zo zal de link ‘view tags’ telkens tags.asp openen, de link ‘historical logging’ zal queryform.asp laden en ‘real time logging’ zal een redirect doen naar een pagina van de eWon datalogger. 23


In deze pagina is er ook een link ‘log off’ voorzien. Deze link verwijst naar logoff.asp en zal de gebruiker uitloggen. Dit houdt in dat het Sessie-object terug geïnitialiseerd wordt zodat een volgende gebruiker van de pc niet kan inloggen via login en paswoord van de huidige gebruiker. In deze pagina is er ook een link voorzien om een e-mail te versturen naar de webmaster van ChevronTexaco. Om de gebruiker de mogelijkheid te bieden om Excel-bestanden te downloaden van de server, is er ook een link ‘downloaden Excel – bestanden’ toegevoegd. De gebruiker zal dan een tabel te zien krijgen met alle Excelbestanden op de server. Deze zijn ingevoegd als hyperlink zodat elk bestand apart kan worden afgehaald van de server. Het toevoegen van data uit de logbestanden aan de databank gebeurt automatisch via een event op de server.

Om de gebruiker toch de

gelegenheid te geven om manueel een logbestand toe te voegen, is er een link ‘manueel logfile toevoegen’ voorzien. Een laatste hyperlink verwijst naar het programma ‘graphs .exe’ dat zelf geschreven is in Visual Basic en wordt gebruikt om grafieken te maken in het Excel-bestand. Meer uitleg hierover in paragraaf IV.4.

IV.3.5. ba n ner.as p Deze pagina wordt geladen in het bovenste frame van ontvangst.asp. Deze pagina toont een gepersonaliseerde verwelkoming van de huidige gebruiker.

IV.3.6. mai n.htm Dit is de standaardpagina die in het main-frame van ontvangst.asp wordt geladen. Hierin staat een beknopte uitleg voor de gebruiker. Deze pagina wordt enkel bij het laden van ontvangst.asp getoond aangezien elke link in keuze.htm een pagina zal laden in het main-frame.

IV.3.7. ta gs.as p In de relatie ‘TAGS’ van de databank ‘coolants’ worden alle tags vermeld. Om de gebruiker een overzicht te geven van de tags die gebruikt worden voor een

24


specifieke teststandaard wordt deze pagina gebruikt. Wanneer een gebruiker de tags voor een bepaalde teststandaard wil raadplegen, zal er een ‘select query’ gedaan worden van volgende vorm: rs.Open

“select

*

from

TAGS

where

test_id

between

(&select id from TEST where naam=vat”&beginner&”) and (&select id from TEST where naam=vat”&eindnr&”)”, conn, adopendynamic, adlockpessimistic In deze query kan men drie afzonderlijke queries beschouwen. Merk op dat bij de ‘SEAL TEST’ onderscheid wordt gemaakt tussen de eerste vijf vaten en de laatste tien vaten. Dit zal zich weerspiegelen op de query waarin met een ‘between’ voorwaarde zal gewerkt worden waarin alles van de relatie ‘TAGS’ wordt geselecteerd waarvan de test_id ligt tussen de id van het beginnummer en de id van het eindnummer dat gevonden wordt via afzonderlijke queries. Het is ook duidelijk dat deze query voor elke teststandaard zal verschillen.

IV.3.8. qu eryform. asp Bij de keuze van ‘historical logging’ in het keuze menu zal men deze pagina laden in het main-frame van de ontvangst.asp pagina. De bedoeling van deze pagina is dat de gebruiker data kan opvragen van de ‘coolants’ databank . Deze data wordt bepaald door de gebruiker die, naast de teststa ndaard, ook de testopstellingen kan kiezen, het begintijdstip en het eindtijdstip van de logging waaraan voldaan moet worden.

Als laatste

invulveld kan de bestandsnaam worden opgegeven van het Excel-bestand dat aangemaakt zal worden. Wanneer de gebruiker het formulier wil doorsturen wordt eerst via client side scripting een validatie uitgevoerd.

Deze validatie houdt in dat

gekeken wordt als alle nodige gegevens zijn ingevuld. Dit heeft als voordeel dat er al een controle is vooraleer de data naar de server wordt gestuurd. Men zou deze controle ook via server side scripting doen, maar dan verliest men niet alleen tijd door de pagina’s heen en weer te sturen maar wordt de server ook meer belast.

Een laatste validatie op de juistheid van het

begintijdstip en eindtijdstip wordt toch nog gedaan aan de server zijde omdat

25


daar een VBScript-functie voor nodig is.

Bij ongeldige validatie wordt de

gebruiker dan toch naar een pagina doorverwezen waarin de foutmelding wordt weergegeven. Deze pagina heet tijdfout.htm Indien alle data correct is wordt het formulier verstuurd naar query.asp.

IV.3.9. qu ery.asp In deze pagina wordt de gewenste data uit de databank opgevraagd. Een flowchart van dit algoritme kan men terugvinden in Figuur 8. In tegenstelling tot het toevoegen van de data aan de databank zal de snelheid waarmee data opgevraagd wordt wel een rol spelen. Bij deze pagina moet de gebruiker effectief wachten tot het volledige algoritme is afgelopen en de data wordt getoond. Het toevoegen gebeurt zonder interactie met de gebruiker door te werken met een event op de server.

Dit wordt verder uitgelegd in

paragraaf V.5 In deze paragraaf wordt ook de betekenis van het deelproces ‘Static Copy’ uitgelegd. Om

het

opzoeken

te

versnelle n

wordt

er

gebruik

gemaakt

van

stored procedures. Om data op te zoeken wordt er in de ASP-code enkel gebruik gemaakt van die bepaalde query en wordt er niet rechtstreeks meer gewerkt met de relaties van de databank . De ASP-code om data op te vragen via een stored procedure zal van de volgende vorm zijn: rs.Open

standard

&

"query"

&

test_id

&

","

&

beginTimeint & "," & eindTimeint , conn, adOpenDynamic, adLockPessimistic In de databank zijn er manueel queries toegevoegd. Met elke relatie komt 1 query overeen voor het opzoeken in die relatie en is van de volgende vorm: standaard&”query”.

Bijvoorbeeld voor de relatie ‘ASTM1384’ wordt dit :

“ASTM1384query”. Nadat de juiste query geselecteerd is moeten er ook nog een aantal parameters meegegeven worden. De welke parameters en het aantal moet op voorhand ingesteld worden bij het opstellen van de query in Access.

Zo worden de parameters test_id, begintimeint en eindtimeint

meegegeven en zijn nodig voor het selecteren van de juiste data.

26


BEGIN

OPHALEN DATA UIT FORMULIER

STATIC COPY UPDATES LIJSTDB aanmaken

TESTARRAY aanmaken

N EINDE

NOG EEN TEST? J J EINDE LIJSTDB? N

(1)*

QUERY

UITSCHRIJVEN

TESTARRAY

HTML

RECORDSET EXCEL

* (1) = ASTM1384QUERY of ASTM4340QUERY of SEALQUERY of DHTTQUERY Figuur 8 : Flowchart Query.ASP

27


In Figuur 8 kan men zien dat eerst de test_id wordt gezocht in de array ‘testarray’. Hiervoor is dus geen extra query meer nodig naar de databank, wat de snelheid ten goede zal komen. Daarna wordt de betreffende databank bevraagd op basis van deze test_id en het begin- en eindtijdstip. Doordat er zeer veel data moet worden opgeslagen, is de data verspreid over verschillende databanken.

Daarom moet ook worden bepaald in welke

databanken nu juist moet worden gezocht.

Dit wordt voor het opvragen

gedaan en de databanken die moeten bevraagd worden, worden 1 voor 1 opgeslagen in de array ‘lijstdb’. Zoals vroeger vermeld, wordt in de databank ‘updates’ bijgehouden welke databanken er bestaan en in welk tijdsinterval ze data bevatten. Het is op basis van dit tijdsinterval en het gevraagde begin- en eindtijdstip dat bepaald wordt als een databank aan de array ‘lijstdb’ wordt toegevoegd. Met deze geselecteerde gegevens worden twee dingen mee gedaan. Vooreerst wordt er een tabel opgemaakt die alle geselecteerde gegevens toont maar daarnaast wordt er ook een Excel-bestand gemaakt waarin de gegevens voorkomen. Dit bestand is voor de laboranten belangrijker dan de HTML –tabel want het is dit Excel-bestand dat ze verder zullen bewerken. Er werd ook gevraagd om grafieken toe te voegen aan het Excel-bestand. Dit was echter niet evident met behulp van ASP-code en de OWC10 componenten van Microsoft Office XP, en daarom werd geopteerd om een apart Visual Basic programma te schrijven dat ‘graphs .exe’ heet.

IV.4. Graphs.exe IV.4.1. Inleidi n g Nadat de gebruiker via de webtoepassing de gewenste data geselecteerd heeft en een Excel-bestand gekregen heeft, zijn er nog geen grafieken aanwezig in het Excel-bestand.

Deze grafieken zijn voor de laboranten

belangrijker dan de data alleen en daarom zou het nuttig zijn moesten die grafieken automatisch gecreëerd worden.

28


Een eerste oplossing bestond erin om via ASP-code grafieken te maken maar door de beperkte subset van VBScript was dit niet mogelijk. Een tweede oplossing bestond erin om een macro te schrijven in Excel die deze taak op zich nam.

Dit werkte goed maar het is niet evident om de

modules van de macro steeds ingevoegd te krijgen bij een nieuw aangemaakt Excel-bestand.

Ook bestond er gevaar voor inconsistentie indien er een

aanpassing aan de module werd gedaan. Daardoor zouden in alle vroegere Excel-bestanden de oude modules moeten vervangen worden door de nieuwe, om de nieuwe functionaliteiten van de module te kunnen gebruiken. Een laatste oplossing was om een apart programma te schrijven in Visual Basic. Dit programma was nergens ingebed en bestond ook slechts één keer. Dus een aanpassing aan het programma was direct toegankelijk voor alle bestanden. Het programma kreeg de naam ‘graphs.exe’.

IV.4.2. Fu nctio naliteit en De bedoeling van het programma is duidelijk: aan een Excel-bestand waarin enkel data aanwezig is, moet er per worksheet met data een grafiek aangemaakt worden. Het programma is interactief opgebouwd in die zin dat het formulier opgedeeld is in een aantal stappen en dat de volgende stap pas zichtbaar gemaakt wordt wanneer de vorige stap is uitgevoerd.

Zo wordt een

onvolledige invoer tot een minimum herleid. De eerste stap bestaat uit het selecteren van het Excel-bestand op de schijf. Er is ook een filter toegevoegd zodat enkel Excel-bestanden met de extensie ‘.xls’ kunnen worden geopend .

Indien de gebruiker het gewenste

bestand geselecteerd heeft, wordt de tweede stap zichtbaar gemaakt en hierin bevindt zich een keuzelijst van alle attributen die in het Excel-bestand aanwezig zijn in de vorm van checkboxes.

Hierin kan de gebruiker de

attributen selecteren die in de grafiek moeten aanwezig zijn. Wanneer de attributen geselecteerd zijn, wordt de derde stap zichtbaar gemaakt en deze bestaat uit de keuze om de grafiek in te bedden of om voor de grafiek een nieuwe worksheet aan te maken. Indien dit gedaan is, wordt de laatste stap

29


zichtbaar gemaakt en deze bestaat enkel uit een knop om de grafieken daadwerkelijk aan te maken.

IV.5. GEBRUIKERS databank IV.5.1. Inleidi n g Diegene die wil gebruik maken van de webtoepassing moet een login naam hebben. In de databank ‘gebruikers’ worden in de relatie ‘USERS’ de logins en paswoorden bijgehouden.

De paswoorden worden geëncrypteerd

opgeslagen via een Hash-functie zodat ook de administrator de paswoorden nooit te zien krijgt als ‘klare tekst’.

IV.5.2. AD D_ US ER. EX E Voor elke gebruiker moet de administrator een login aanmaken. Dit kan niet rechtstreeks ingevuld worden in de relatie ‘USERS’ van de databank ‘gebruikers’ omdat dan het paswoord niet geëncrypteerd wordt. Daarom is dit apart programma in Visual Basic geschreven speciaal voor de administrators om paswoorden toe te voegen.

Daarbij wordt het paswoord eerst

geëncrypteerd en dan pas opgeslagen in de databank.

IV.6. Ber ekening benodigde bandbreedte IV.6.1. W et va n Zi pf In deze paragraaf zal een schatting worden gemaakt van de benodigde bandbreedte van de webtoepassing.

Het is zonder meer duidelijk dat het

gebruikte netwerk minimaal deze bandbreedte moet ondersteunen en liefst nog veel meer om eventuele piekmomenten goed te kunnen opvangen. Een schatting van de bandbreedte kan men maken door gebruik te maken van de wet van Zipf. Hierbij wordt eerst een rangschikking gemaakt van de meest bezochte pagina’s en wordt uitgedrukt via een populariteitsindex p. Indien men daarnaast de frequentie van optreden van deze pagina’s uitdrukt door f, dan stelt deze wet dat volgende evenredigheid geldt: f ~ 1/p. 30


IV.6.2. To e passin g w et van Zipf Na rondvraag op de Coolants afdeling, bleek dat het totaal aantal gebruikers voor de webtoepassing ongeveer 10 gebruikers per uur zal zijn. Merk op dat dit een gemiddelde waarde is en er dus op piekmomenten een hoger aantal gebruikers zal zijn. Een schatting van de populariteit van de verschillende pagina’s kan men terugvinden in Tabel 2. In de eerste kolom staat de populariteitsindex p, de tweede kolom bevat de pagina die wordt opgevraagd, de derde kolom bevat de grootte van de pagina die wordt opgehaald, de vierde kolom bevat de frequentie f van opvragen en de laatste kolom bevat het concrete aantal requests. De berekening van de requests wordt gedaan door de frequentie van optreden van een pagina te vermenigvuldigen met het totaal aantal gebruikers, namelijk 10. De benodigde bandbreedte kan men nu vinden door het aantal requests voor een pagina te vermenigvuldigen met de grootte van de pagina. Dit wordt dus: Bandbreedte =10*9+5*288+3*7+2,5*10+2*800 KB per uur =3176 KB per uur à 7,06 kbps Op de Coolants afdeling heeft men een ethernet netwerk van categorie 3 met een bandbreedte van 100 Mbps. Deze bandbreedte overtreft ruimschoots de benodigde bandbreedte waardoor verdere aanpassingen overbodig zijn. Tabel 2:Berekening bandbreedte webtoepassing

p

Pagina

1 Index.htm + ontvangst.asp

Grootte pagina (KB)

f = 1/p

Requests

8+1=9

1,00

10,0

15+117+156=288

0,50

5,0

3 Real time logging

7

0,33

3,0

4 Opvragenexcel.asp

10

0,25

2,5

5 Nieuwefile.asp

800

0,20

2,0

2

Queryform.asp + query.asp + Excel-bestand

31

HOOFD STUK V. SERVER V.1. Inleiding Bij het begin van dit eindwerk was er nog geen server aanwezig op de afdeling Coolants. De hardware was wel al voorzien maar de keuze van de software voor de server was nog niet beslist.

Aangezien de administrators van de afdeling een

voorkeur hadden voor een Windows platform werd besloten om een Windows 2000 server te installeren. Deze server zal zowel gebruikt worden als webserver en als FTP-server en vereisen dus aangepaste instellingen.

V.2. FTP-server De eWon datalogger stuurt om het uur zijn data door naar deze FTP-server. Het is duidelijk dat poort 21 moet openstaan op deze server en dat de eWon moet kunnen inloggen op deze server. Daarvoor werd een aparte login aangemaakt op de FTPserver met de nodige schrijfrechten. De FTP-server werd standaard ook ingesteld op de betreffende map waarin de bestanden van de eWon geplaatst worden. Dit om geen beveilingslek te laten voor gebruikers die toch kunnen inloggen en aan andere mappen kunnen van de server.

V.3. Webser ver Microsoft Windows 2000 server bevat IIS (Internet Information Services). Hierin kunnen de instellingen van de server worden aangepast. Er werd geopteerd om een bijkomende virtuele map Coolants aan te maken op de server waarin de pagina’s worden geplaatst. Daardoor wordt het path om de eerste webpagina te raadplegen: http:// /Coolants/index.htm 32

HOOFDSTUK V : SERVER

Op de server kan ook worden ingesteld om geen anonieme toegangen toe te laten. Hiervoor kan worden geopteerd indien men de veiligheid wenst te verhogen.

V.4. Events Op de server zal 1 event worden gebruikt. Namelijk voor het toevoegen van de data aan de databank . In een eerste oplossing werd gedacht om het toevoegen van de data aan de databank te laten gebeuren door de webtoepassing zelf.

Telkens

wanneer een gebruiker de webtoepassing gebruikt werd dan gecontroleerd of er nieuwe bestanden waren doorgestuurd door de eWon. Indien dit het geval was dan werd de data dan toegevoegd en anders kwam de gebruiker terecht in de pagina ontvangst.asp. Dit had als grote nadeel dat er een relatieve grote wachttijd ontstond, namelijk de tijd nodig om de data toe te voegen. Daardoor moest de gebruiker telkens enkele minuten wachten totdat het logbestand was toegevoegd. Dit werd niet ingevoerd en in plaats daarvan werd gewerkt met een event op de server. Deze event houdt in dat telkens wanneer de eWon een bestand plaatst op de server, dat de event wordt getriggerd en de pagina nieuwefile.asp wordt uitgevoerd.

Deze

pagina verzorgt het toevoegen van een nieuw bestand met data aan de databank. Deze methode heeft als voordelen dat ten eerste de gebruiker niet moet wachten en ten tweede er minder belang wordt gehecht aan de snelheid van het algoritme om data toe te voegen.

V.5. Toevoegen van de data aan de databank via events De ruwe data wordt automatisch via FTP naar de server gestuurd door de eWon datalogger. Opdat de gebruikers via ‘historical logging’ de gelogde data kunnen bekijken moet de ruwe data eerst nog worden opgeslagen in de databank. Dit zal gebeuren via ASP. De data afkomstig van de datalogger is zodanig opgebouwd dat er niet rechtstreeks in de databank kan geïmporteerd worden. Er is een zekere conversie nodig tussen het logbestand in tekstformaat en de Access databank. De wijze waarop de data wordt voorgesteld in het eWon logbestand wordt weergegeven in Figuur 9. Daarin kan men zien dat de eWon naar een tag verwijst via een tag_id. Dit is ook de reden 33


tagid;timeint;timestr;isinit;value 1;1050074420;"11-4-2003 15:20:20";0;80 2;1050074420;"11-4-2003 15:20:20";1;90 3;1050074420;"11-4-2003 15:20:20";2;68 4;1050074420;"11-4-2003 15:20:20";3;13 5;1050074420;"11-4-2003 15:20:20";4;16 … Figuur 9: Logfile eWon

waarom in de databank een relatie ‘TAGS’ werd opgesteld waarin staat wat deze tag_id betekent. Of met andere woorden welke tag bedoeld wordt met een bepaalde tag_id.

De volgende waarden die men in het logbestand terugvindt zijn de

voorstelling van het tijdstip, dit zowel als integer en als string. De voorlaatste waarde is de isinit parameter en daarmee wordt bedoeld wat de initiële of startwaarde is van de tag. En als laatste waarde wordt weergegeven wat de waarde is van de tag op dat specifieke tijdstip. Als besluit kan men dus stellen dat 1 lijn in het logbestand een logging voorstelt van 1 tag op 1 specifiek tijdstip. Elke lijn van het logbestand stelt dus een datalijn voor die moet toegevoegd worden aan de databank. Als de databank er nog eens wordt bijgenomen kan men zien dat in de vier relaties van de verschillende testen elke lijn in de relatie overeenkomt met de logging van alle tags van de test op 1 specifiek tijdstip. Dit komt dus niet letterlijk overeen met het logbestand waarin elke lijn overeenkomt met de logging van 1 tag op 1 tijdstip. Dit ontwerp van de databank zal enerzijds een gemakkelijke bevraging toelaten maar anderzijds een iets moeilijker probleem stellen om de data toe te voegen in de databank.

V.5.1. Al goritme om de ru w e d ata t oe te voe ge n aa n d e d at ab a nk Een bepaalde waarde van een tag op een bepaald tijdstip toevoegen aan de databank zal gebeuren in een aantal stappen. De eerste 2 stappen zullen tot doel hebben om de test_id, tag_parameter en standaard te weten te komen. Met tag_parameter wordt de parameter van een tag bedoeld die men 34


terugvindt in de relatie ‘TAGS’. Eenmaal dit gekend is kan men het gegeven toevoegen aan de databank.

Men weet nu immers door de standaard in

welke relatie de gegevens moeten toegevoegd worden en via een combinatie van test_id en timeint kan ondubbelzinnig bepaald worden waar de waarde van de tag moet worden ingevuld aangeduid door de tag_parameter. De uiteindelijke

uitwerking

van

het

algoritme

resulteerde

in

een

aantal

verschillende algoritmes.

V.5.2. Eerste al goritme zo n der arrays Belangrijkste kenmerk en nadeel van dit algoritme is dat voor elke lijn die moet toegevoegd worden aan de databank er steeds twee queries nodig zijn voor het vinden van de test_id, tag_parameter en standaard. Samen met de query nodig voor het schrijven van de data naar de databank, maakt dat dit algoritme steeds drie queries moet doen om één lijn van het logbestand te verwerken. Dit algoritme werkt niet efficiënt en dat blijkt duidelijk wanneer er een groot logbestand moet toegevoegd worden van bijvoorbeeld 16000 lijnen. Daarvoor zullen er minstens 48000 queries moeten uitgevoerd worden naar de databank! Het is duidelijk dat er nood is aan meer efficiëntere algoritmes. Een schematisch overzicht van de wijze waarop dit algoritme 1 lijn van het logbestand wordt toegevoegd aan de databank kan men zien in Figuur 10. Merk op dat met de pijl ‘à’ wordt bedoeld dat een gewenste gegeven gevonden

wordt

uit

een

ander

gegeven.

Voorbeeld:

‘tag_id à test_id + tag_parameter’, daarmee wordt bedoeld dat met tag_id, de parameters test_id en tag_parameter kan worden gevonden. Rechts in de figuur zijn de databanken voorgesteld van waaruit de gegevens worden gehaald.

35


BEGIN

Einde logfile?

J EINDE TAGS

N TAG_IDàTEST_ID+TAG_PARAMETER

TEST TEST_ID àstandaard

STANDAARD+TIMEINT+TEST_ID +TAG_ 1384 of 4340 of

PARAMETERàVALUE wegschrijven N

SEAL of DHTT

Figuur 10: Eerste update algoritme zonder arrays

V.5.3. Tw ee d e al goritm e m et arrays e n zon d er h ulp array Het was duidelijk dat het eerste algoritme niet efficiënt werkt. Een efficiëntere methode werkt met het gebruik van arrays.

Zoals eerder vermeld zijn de

relaties ‘TEST’ en ‘TAGS’ statisch. Deze relaties worden initieel ingevuld na het ontwerp van de databank en veranderen nooit tijdens het toevoegen van data aan de databank. Het is dan ook een logische stap om aan het begin van het algoritme eerst deze relaties te kopiëren naar arrays. Daarna zal het zoeken van de test_id, tag_parameter en standaard met behulp van deze arrays gebeuren en niet meer via afzonderlijke queries naar de relaties ‘TEST’ en ‘TAGS’ van de databank ‘coolants’. Dit resulteert uiteindelijk in een lus waarin slechts één query nodig is, namelijk diegene voor het wegschrijven van de data naar de databank . Daarom heeft dit algoritme voor een logbestand van 16000 lijnen maar 16002 queries nodig.

36


Begin STATIC COPY

KOPIEREN INHOUD TAGS à TAGARRAY

TAGS

TAGARRAY

KOPIEREN INHOUD TEST à TESTARRAY

TEST

TESTARRAY

Einde STATIC COPY

Figuur12: Deelproces Static Copy

Begin STATIC SEARCH

TAGARRAY TAG_ID à TEST_ID + TAG_PARAMETER

TEST_IDàSTANDAARD

TESTARRAY

Einde STATIC SEARCH

Figuur 11: Deelproces Static Search

.

37


Eerst worden de deelprocessen ‘STATIC COPY’ en ‘STATIC SEARCH’ gedefinieerd. Het eerste deelproces houdt in dat via een select query de relaties ‘TAGS’ naar de array ‘TAGSARRAY’ wordt gekopieerd en dat de relatie ‘TEST’ volledig wordt gekopieerd naar de array ‘TESTARRAY’ . Het tweede deelproces, ‘STATIC SEARCH’, betekent het zoeken naar de betreffende parameters met behulp van beide arrays. De flowchart voor het volledige algoritme kan men tenslotte terugvinden in Figuur 13.

V.5.4. Der de al goritme met arrays en m et h ul parray Het vorige algoritme met arrays is al veel efficiënter maar het kan nog beter.

BEGIN

STATIC COPY

Einde logfile?

J EINDE

N

Logfile.readLine

STATIC SEARCH

STANDAARD + TIMEINT + TEST_ID + TAG_PARAMETER àVALUE wegschrijven

1384 of 4340 of SEAL of DHTT

Figuur 13: Tweede update algoritme met arrays en zonder hulparray

38


Daarvoor moet men de sequentie van tags in het logbestand bestuderen. Als men kijkt naar het logbestand ziet men dat de tag_id sequentieel oploopt. Bij het definiëren van de tags in de eWon wordt deze tag_id automatisch toegekend, dus die kan men niet kiezen noch veranderen. Aangezien bij het invoeren de tags eerst per test zijn gegroepeerd en dan per tag_parameter is er een redelijke kans dat 2 opeenvolgende tags enige gelijkenis hebben. Een voorbeeld ter verduidelijking: neem tag_id = 1.

Deze tag behoort tot

test_id = 15 en heeft als tag_parameter = “TEMP”. Neem de volgende tag, namelijk tag_id nummer 2. Deze tag heeft als test_id = 16 en heeft tevens als tag_parameter = ”TEMP”.

Dus dit betekent dat beide tags behoren tot de

teststandaard ‘ASTM1384’ (zowel test_id 15 en 16 behoren tot ‘ASTM1384’) en dus moeten geschreven worden in dezelfde relatie. Verder ziet men dat ook de tag_parameter dezelfde is, namelijk “TEMP”. Uit deze gegevens kan men besluiten dat 2 opeenvolgende lijnen in het logbestand veel kans op gelijkenis hebben doordat: •

grote waarschijnlijkheid dat beide lijnen moeten geschreven worden naar dezelfde relatie

•

grote waarschijnlijkheid dat beide lijnen moeten geschreven worden in een zelfde attribuut maar in 2 opeenvolgende records

•

grote waarschijnlijkheid dat beide lijnen hetzelfde tijdstip hebben

Uit bovenstaand voorbeeld kan men stellen dat de eerste tag moet geschreven worden op bijvoorbeeld record 50 in de relatie ‘ASTM1384’ met als attribuut “TEMP” en dat de volgende tag in het logbestand moet tevens geschreven worden in de relatie ‘ASTM1384’ op record 51 in de relatie tevens als attribuut “TEMP”. Deze gelijkenis tussen 2 opeenvolgende tags kan men gebruiken om het algoritme nog efficiënter te maken. De flowchart voor dit algortime is te vinden in Figuur 14. Hierna volgt een korte uitleg van deze flowchart. Bij het begin van het algoritme wordt weer het deelproces ‘STATIC COPY’ uitgevoerd, waarbij de volledige relatie ‘TEST’ wordt gekopieerd naar een lokale array wat het opzoeken zal versnellen. Daarna wordt het logbestand sequentieel doorlopen en wordt telkens een nieuwe lijn vergeleken met de 39


vorige.

Indien de nieuwe lijn gelijk is aan de vorige, dan worden de

parameters opgezocht via deelproces ‘STATIC SEARCH’ en opgeslagen in de hulparray. Dit vergelijken van lijnen en opslaan in de hulparray wordt herhaald tot er een lijn gevonden die verschilt van de vorige. Indien dit het geval is dan wordt de volledige hulparray overlopen en de gegevens toegevoegd aan de databank. Indien het logbestand nog niet op het einde is, wordt de hulparray leeggemaakt en worden terug twee lijnen met elkaar vergeleken tot ze verschillen, enzovoort.

Merk op dat er geen data verloren gaat!

Bij het

vergelijken van de lijnen zal er enkel een nieuwe lijn ingelezen worden indien de vorige lijn inderdaad gelijk is.

Dit wordt uitgedrukt via de booleaanse

variabele tweedegelijk. Merk op dat niet alle variabelen in de flowchart zijn gebruikt, om het toch nog duidelijk te houden.

40


STATIC COPY

BEGIN

J

Einde logfile?

EINDE

N J

Tweedegelijk ?

1

Logfile.readLine

N STATIC SEARCH

(1)* & (2)* & (3)*

N

=hulparray(aantal-1)? HULPARRAY

J Tweedegelijk=false STANDAARD+TIMEINT+TEST_ID+TAGPARAMETERà HULPARRAY(aantal)

N

Teller<=aantal? aantal=aantal+1

J HULPARRAY(teller)àVALUE wegschrijven Tweedegelijk=true Teller=teller+1

1 1384 of 4340 of

* (1) = standaard (2) = tag_parameter

SEAL of DHTT

(3) = timeint Figuur 14 : Flowchart update algoritme met hulparray

41


V.5.5. Besluit al goritmes Als besluit van deze algoritmes kan men stellen dat het laatste algoritme het meest complexe is om te implementeren maar desondanks een serieuze daling van het aantal queries met zich meebrengt. Dit blijkt ook uit Tabel 3 waarin een vergelijking wordt weergegeven in absolute cijfers en procentuele cijfers voor een logbestand van 14667 lijnen.. Tabel 3: Vergelijking algoritmes

Eerste alg.

Tweede alg.

Derde alg.

Aantal queries

44001

14669

1711

%

300%

100%

11,67%

42

HOOFD STUK VI. BEVEILIGING VI.1. Inleiding In de doelstelling van dit eindwerk werd al vermeld dat een beveiliging een belangrijk punt is.

Het is zonder meer duidelijk dat in een professionele omgeving een

degelijke afscherming van de gegevens cruciaal is. Op de Coolants afdeling heeft men als voordeel dat men al beschikt over een hogerliggende beveiliging zodat geen rekening moet gehouden worden met externe aanvallen. Er zal dus moeten gewerkt worden aan interne beveiliging op de Coolants afdeling zelf en tussen verschillende afdelingen.

VI.2. Login en paswoord Deze beveiliging werd vroeger al besproken en houdt in dat de gebruiker eerst in een login pagina moet inloggen alvorens hij de rest van de webtoepassing kan bezoeken. Deze beveiliging zal vooral gericht zijn tegenover andere afdelingen die geen data kunnen raadplegen van de Coolants server. Deze veiligheid biedt geen beveiliging tegenover de laboranten onderling omdat deze elk een aparte login zullen krijgen.

VI.3. Beveiligen databank ‘gebr uikers’ via ODBC-link Bij een eerste implementatie van de webtoepassing werd de databank ‘gebruikers’, waarin de logins en paswoorden zitten, in dezelfde directory geplaatst als de rest van de pagina’s. Daardoor was het mogelijk de volledige databank af te halen door de naam in de typen als URL (Uniforme Resource Locator) van de webbrowser. Men kon geen leesbeveiligheid op het bestand toepassen omdat de databank wel degelijk moet worden gelezen hij het inloggen van de gebruiker. Een oplossing van dit probleem was om de databank in een aparte directory op de schijf van de server te

43

HOOFDSTUK VI : BEVEILIGING

zetten en via een ODBC-link (Open Database Connectivity) de databank te raadplegen. Deze link wordt manueel ingesteld op de server en houdt eigenlijk in dat er een DSN (Data Source Name) wordt gecreëerd die dan verwijst naar de databank op de schijf. In de ASP-code van controle.asp, waar de logins en paswoorden worden gecontroleerd, werd dan verwezen naar de databank via deze DSN. Merk op dat de databank nu op elke willekeurige plaats op de schijf van de server kan geplaatst worden behalve in de directories die bereikt kunnen worden via de webbrowser want anders kan men nog altijd de databank downloaden. Deze beveiliging richt zich nu zowel op andere afdelingen als de Coolants afdeling zelf. Als beveiliging voor de Coolants afdeling wordt dan vooral gedacht aan een gebruiker die het paswoord van een andere gebruiker kan misbruiken.

VI.4. Beveiligen databank ‘gebr uikers’ door ‘one way hashing’ Elk paswoord in de databank wordt geëncrypteerd opgeslagen door gebruik te maken van hashing. Daardoor zijn de originele paswoorden niet zichtbaar in de relatie ‘USERS’ en kan ook het originele paswoord niet meer achterhaald worden.

VI.5. SSL (Secure Socket Layer ) Wanneer het http protocol gebruikt wordt, dan wordt alle verkeer tussen client en server in ‘klare tekst’ verstuurd. Handige netwerkgebruikers kunnen makkelijk via sniffers alle paswoorden van gebruikers onderscheppen die over dat netwerk passeren. Om dit te vermijden wordt er SSL gebruikt. Dit houdt in dat men de pagina’s enkel via het https prototol kan raadplegen. Https staat voor HyperText Transfer Prococol Secure en betekent onder andere dat het verkeer tussen client en server geëncrypteerd wordt. Daardoor is alle tekst onderschept door een sniffer onleesbaar. Om SSL te gebruiken moet er op de server een Server Certificate geïnstalleerd worden.

Dit certificaat kan van externe instellingen afkomstig zijn, of kan lokaal

geïnstalleerd worden via een CA (Certification Authority) dat standaard geleverd is bij Windows 2000 server. Het is dan ook deze laatste optie die zal gebruikt worden.

44

HOOFDSTUK VI : BEVEILIGING

Momenteel is er een certificaat geïnstalleerd dat gebruik maakt van RSA (Rivest Shamir Adleman) en 512 bits als sleutelgrootte heeft. Deze beveiliging richt zich enkel tot gebruikers binnen de afdeling Coolants, aangezien de verschillende afdelingen binnen ChevronTexaco verbonden zijn via een netwerk switch. Deze switch zorgt voor een beperkend domein zodat het niet mogelijk is om van buiten het subnetwerk van de Coolants het netwerkverkeer te sniffen.

45

HOOFD STUK VII. BESLU IT VII.1. Evaluatie oplossing Bij het begin van het eindwerk was enkel de eWon datalogger aanwezig. Er bestond nog geen databank of webtoepassing en ook de server was nog niet geconfigureerd. Bij het beëindigen van dit eindwerk is er een totaaloplossing voorhanden die weinig of geen manuele tussenkomst vereist. De datalogger stuurt automatisch zijn data door naar de server die per event de data automatisch toevoegt aan de databank en de grootte van de databank controleert.

Tenslotte kan de gebruiker direct de

toegevoegde data opvragen via de webtoepassing en wordt de data op zijn pc voorgesteld in Excel-formaat. Door dit eindwerk zal er minder tijd verloren gaan voor de laboranten waar ze vroeger manueel een logging moesten uitvoeren en de data selecteren en voor alle testopstellingen zelf grafieken maken. Er bestond geen centralisatie van de data zodat het opvragen van vroegere data niet altijd evident was. Door de centrale databank is dit nu wel mogelijk . In deze tijd van internetaanvallen was het ook belangrijk om een veilig geheel te creëren. Ook hieraan is voldaan door gebruik te maken van een ODBC-link, SSL, een login pagina en een degelijke configuratie van de server met de nodige permissies ingesteld.

VII.2. Mogelijke optimalisaties Zwak punt in de oplossing blijft nog altijd de databank . De grootte van de databank werd beperkt door vanaf een bepaalde grootte de databank te verplaatsen en te vervangen door een lege. Toch wordt er maandelijks ongeveer 100MB toegevoegd waarvan niet alle data nuttig is. Op bepaalde tijdstippen worden onnodig data gelogd en toegevoegd aan de databank . Dit kon echter niet opgevangen worden in de 46

HOOFDSTUK VII : BESLUIT

oplossing van het eindwerk aangezien de data alle mogelijke waarden kan aannemen zodat geen filtering mogelijk was van de inkomende data. Een mogelijke oplossing zou zijn dat een koppeling werd gedaan met het planningsschema van de testen. Dit Excel-bestand beschrijft welke teste n lopen op een bepaald ogenblik en door dit bestand te evalueren kan men eventueel wel een filter toepassen op de inkomende data.

Dit planningsschema kan ook nog worden aangepast tot een

webtoepassing met een databank zodat de koppeling en centralisatie optimaal wordt. Gezien de complexiteit van het planningsschema en beperkte tijd voor dit eindwerk, kon dit niet meer gerealiseerd worden. Toch wordt verwacht dat dit een serieuze daling van het aantal records in de databank zou betekenen.

47

Lijst v an figuren Figuur 1: Relatie test-standaard, testopstelling en tags _______________________ 3 Figuur 2 : Interacties tussen eWon, server en host __________________________ 6 Figuur 3: Afhankelijkheidsdiagram voor ASTM4340 ________________________ 11 Figuur 4: Afhankelijkheidsdiagram voor ASTM4340 in derde normaalvorm en BCNF 14 Figuur 5: Praktisch afhankelijkheidsdiagram voor ASTM4340 _________________ 15 Figuur 6: Relationeel model van de volledige databank ______________________ 17 Figuur 7: Flowchart Webtoepassing ____________________________________ 21 Figuur 8 : Flowchart Query.ASP _______________________________________ 27 Figuur 9: Logfile eWon_______________________________________________ 34 Figuur 10: Eerste update algoritme zonder arrays __________________________ 36 Figuur 11: Deelproces Static Search ____________________________________ 37 Figuur12: Deelproces Static Copy ______________________________________ 37 Figuur 13: Tweede update algoritme met arrays en zonder hulparray___________ 38 Figuur 14 : Flowchart update algoritme met hulparray_______________________ 41

48

Lijst v an tabellen Tabel 1: Overzicht teststandaarden, testopstellingen en tags __________________ 4 Tabel 2:Berekening bandbreedte webtoepassing __________________________ 31 Tabel 3: Vergelijking algoritmes ________________________________________ 42

49

Bi jlage 1:Gebruik ersm anual

Bi jlage 2: Administratorsm anual

De auteur geeft de toelating deze SCRIPTIE voor consultatie beschikbaar te stellen en delen van de SCRIPTIE te kopiëren voor persoonlijk gebruik

Recommend Documents