Wireless Sensor Networks & Creative Wind Turbine Technology. Experts In Teams Project

Transkript

1 Wireless Sensor Networks & Creative Wind Turbine Technology Experts In Teams Project Udarbejdet af: Jens Bjarke Pedersen [jped606] Daryosh (Danni) Derakhshan [dader06] Anders Steffen Andersen [ander06] Simon Tobias Busch [sbusc06] Kasper Rytter Sæderup [ksaed06] Morten Thule Hansen [mhan406] Ahmad Parwiz Jamal [ahjam06] Gruppe nr.: Gruppe 2 Undervisningsinstitution: Syddansk Universitet - Det tekniske fakultet Kursus: Expert in Teams Vejleder: Jørgen Jeppe Madsen Kurt Bloch Jessen Periode: Efterår 2008 Afleveringsdato:

2 Synopsis I forbindelse med projektet Expert In Teams, er der i en gruppe bestående af stærkstrømsingeniør- og datateknologistuderende i samarbejde blevet udarbejdet et projekt omhandlende trådløs styring, regulering og overvågning af en eller flere vindmøllegeneratorer. Projektet er opdelt i to faglige områder, en omhandlende stærkstrømsingeniørernes faglighed og en omhandlende datateknologistuderenes faglighed. I stærkstrøms faglighed arbejdes der med vindmøllegeneratorens regulering og effektproduktion, samt hvilke parametre der sendes/modtages til generatoren. I datateknologis faglighed udvikles et softwaresystem til overvågning af en eller flere vindmøller, ved brug af trådløse sensornetværk. Softwaresystemet behandler de parametre der ønskes sendt til- og modtaget fra generatoren. EIT-gruppen har løbende afholdt møder angående tværfagligheden i projektet. Der er her blevet opsat fælles mål og snitflader for projektet og taget tværfaglige beslutninger. De to retninger har ud fra den fundne snitflade, arbejdet parallelt mod de fælles opsatte mål. Daryosh Derakhshan: Jens Bjarke Pedersen: Anders Steffen Andersen: Simon Tobias Busch: Kasper Rytter Sæderup: Morten Thule Hansen: Ahmad Parwiz Jamal: Side 2

3 Indhold 1 Prolog Forord Målgruppe Rapportens opbygning Problemstilling Problemformulering Projektets snitflader Læringsmål og forventede resultater Arbejdsmetode og proces Delrapport 1 - Wireless Wind Turbine Control System Læsevejledning Projektværktøjer og projektstyring for datateknologi Projektværktøjer Projektstyring Milepælsplan Tidsplan Projektgrundlag Problemstilling Problemformulering Kravspecifikation for systemet Afgrænsning af systemets funktionalitet Brugsmønsterbeskrivelser Mål og forventede resultater Analyse af de udvalgte brugsmønstre Systemets anvendte teknologi Trådløse kommunikationsenheder Trådløs kommunikation og protokoller Delkonklusion af systemteknologi Systemarkitektur Klient-server struktur Pakkestruktur Kommunikation Tekniske memoer Delkonklusion af systemarkitektur Design af systemet Forretningsmodellen for W 2 T CS Design af systemets infrastruktur Side 3

4 2.6.3 Design af Login Design af Send status Design af Send set-punkt Design af Angiv ønsket genereret effekt Design af Automatisk nødstop Delkonklusion Implementering af W 2 T CS Implementering af RMI Implementering af kommunikation med board et C implementering af temperaturrutine C implementering af PWM-rutine Test af W 2 T CS Test metode Navigationsdiagram Test af send set-punkt og send status Delkonklusion Konklusion for W 2 T CS Perspektivering for W 2 T CS Delrapport 2 - Stærkstrøm vindmølle projekt 67 4 Epilog Konklusion Perspektivering A Analyse af de udvalgte brugsmønstre 130 A.1 Korte brugsmønstrebeskrivelser A.2 Krydstabel mellem krav og brugsmønstre A.3 Krydstabel A.3.1 Krydstabel over funktionelle krav og brugsmønstre A.3.2 Krydstabel over funktionelle krav og brugsmønstre A.3.3 Krydstabel over ikke-funktionelle krav og brugsmønstre A.4 Analyse af Login A.5 Analyse af Send status A.6 Analyse af Send Set-punkt A.7 Analyse af Angiv ønsket genereret effekt A.8 Analyse af Automatisk nødstop af vindmølle B Test af W 2 T CS 145 B.1 Test type B.2 Test af login Side 4

5 C Samarbejdskontrakt Experts in Teams 147 D Fordel/ulempe tabeller for arkitektur 148 E Kildekode for W 2 T CS 150 E.1 W 2 T CS - Applikations-Server E.1.1 Connector-Pakken E.1.2 Entity-Pakken E.1.3 Mediator-Pakken E.1.4 Foundation-Pakken E.2 W 2 T CS - Central-Klient E.2.1 Presentation-Pakken E.2.2 Control-Pakken E.2.3 Control.Connector E.3 W 2 T CS- WCom E.3.1 Presentation-Pakken E.3.2 Control-Pakken E.3.3 Control.ConApp-Pakken E.3.4 Control.ConRaven-Pakken Side 5

6 1 Prolog 1.1 Forord Denne rapport er udarbejdet i forbindelse med kurset Experts in Teams(EIT) som løber over efterårssemesteret Projektet er i samarbejde udarbejdet af de to studieretninger; stærkstrømsingeniør og civilingeniør i datateknologi. EIT skal forberede de studerende på erhvervslivet, hvor flere fagligheder skal arbejde sammen om fælles projekter. Inden semesterstart skulle hver kursustilmeldt vælge et projekt blandt 21 mulige. Pga. manglende fagligheder i flere af projekterne, blev de to projekter, som denne rapport spænder over, slået sammen. Disse projekter hed Wireless Sensor Networks og Creative Wind Turbine Technology, og tilsammen blev målet at fremstille et kombineret produkt, bestående af trådløse sensornetværk samt vindmølleteknologi. Til den trykte rapport er der vedlagt en CD-ROM/DVD-ROM med alt materiale gruppen har udarbejdet i løbet af semesteret. Dette inkluderer det udarbejdede software, LabView programmer, en digital version af rapporten, tidsplan, referater mm. 1.2 Målgruppe Rapporten er skrevet til en læser, som minimum er på samme faglige niveau som projektgruppen. For at få maksimalt udbytte af den samlede rapport, skal læseren have kendskab til programmeringssprogene Java og C, UML og LabView. Java, C og UML er en forudsætning for at læse den første delrapport (Datateknologi). Kendskab til Labview, grundlæggende teori bag asynkronmaskiner, switch mode effektelektronik og klassisk reguleringsteknik er en forudsætning for anden delrapport (Stærkstrøm). Delrapporterne kan læses uafhængigt af hinanden. 1.3 Rapportens opbygning Rapporten er opbygget af en fælles prolog, efterfulgt af to delrapporter og afsluttes med en fælles epilog. Den første delrapport (Se Kapitel 2) er skrevet af de datateknologistuderende og omhandler deres faglighed, den anden delrapport (Se Kapitel 3) er skrevet af de stærkstrømstuderende og omhandler deres faglighed. Der vil under hver delrapport være en specifik læsevejledning, problemstilling samt konklusion. På grund af anvendelse af forskellige tekstbehandlingsprogrammer, er anden delrapport sat ind som en rapport i den samlede projektrapport. Dermed vil anden delrapport have egen indholdsfortegnelse og bilag. Stærkstrømsstuderende vil, i det fælles afsnit, blive benævnt ved SS og datateknologistuderende vil blive benævnt ved DAT. Side 6

7 1.4 Problemstilling De teknologiske fremskridt, der er sket indenfor offshore vindmølleindustri de sidste årtier, har gjort vindmøller mere og mere komplekse. Dette skyldes dels at vinden i sig selv er meget kompleks og varierer meget. Alt efter i hvilket geografisk område vindmøllen befinder sig i, en fællesnævner for alle områder er at vinden er turbulent. Denne turbulens, giver en uregelmæssig effektproduktion, hvilket ikke er ønskeligt og derfor er en regulering af effektflowet fra vindmøllen uundværlig. Reguleringen giver fleksibilitet mht. at ændre effektproduktionen. De mange sensorer der er placeret i en vindmølle i dag er forbundet til en styring via kabler. Dette begrænser fleksibiliteten mht. at ændre position på en sensor, da dette som oftest vil medføre en del kabelarbejde. Derfor vil benyttelse af trådløs sensorteknologi være en ideel løsning, og dermed give en mere fleksibel placeringsmulighed. Ved benyttelse af et overvågningssystem der kommunikerer med en styreboks i vindmølle (se figur 1.1) vil vindmøllens styreboks giver besked når en potentiel farlig situation er opstår og kan derved forebygge skader på vindmøllen, hvis der handles på advarslen. Foruden at overvåge vindmøller er det ønskeligt at sende instruktioner til vindmøllerne, fx kan der ændres på en række forskellige parametre, der optimerer vindmøllernes energiproduktion samt formindsker energitab og dermed unødig slitage på vindmøllerne. Figur 1.1: Overvågningssystemets opbygning Side 7

8 1.5 Problemformulering Der er ud fra problemstillingen i det tværfaglige projekt lavet en fælles overordnet problemformulering. Der vil i hver delrapport være en uddybende og mere detaljeret problemformulering. Det ønskes igennem SS s faglige projekt at modellere en dobbeltfødet asynkron maskine, med henblik på at kunne regulere dennes effektflow. Reguleringen laves ikke analogt men digitalt i LabView. For at kunne regulere/styre den producerede effekt, skal der dimensioneres switch mode effektelektronik. Effektelektronikken skal bruges i rotorkredsløbet på maskinen og styre effekten i rotoren. Der ønskes i DAT s faglige projekt at udvikle et softwaresystem, der kan overvåge og interagere med vindmøllers generator. Softwaresystemet skal give et samlet overblik over vindmøllernes produktion og status. Derudover skal det være muligt at se detaljeret status for den enkelte vindmølle. Statusparametrene er de parametre der kan måles ud fra SS s faglige projekt fx aktuel temperatur i generatoren, effekt, moment etc. Det skal ligeledes være muligt at styre vindmøllernes produktion, bremsen mm. gennem softwaresystemet. For at optimere effektproduktionen skal vindmøllens aktuelle produktion kunne overvåges. Yderligere skal det være muligt at ændre reguleringssløjfen for at tilnærme den ønskede effektproduktion. Reguleringssløjfen ændres ved at sende set-punkter til vindmøllen, ud fra et format specificeret af SS s faglige projekt. De forskellige parametre der måles i vindmøllen skal måles via sensorer der trådløst sender informationerne videre til en styreboks placeret i vindmøllen. Denne trådløse kommunikation vil forøge fleksibiliteten i forhold til placering af sensorer i vindmøllen. 1.6 Projektets snitflader I forbindelse med udarbejdelse af problemstilling og problemformulering, har de faglige grupper diskuteret hvor grænsefladerne skal placeres mellem de faglige projekter. Som det fremgår af problemformuleringen, se afsnit 1.5, arbejder SS med vindmøllegeneratorens regulering og effektproduktion, samt hvilke parametre der sendes/modtages til denne. DAT arbejder med udviklingen af softwaresystemet til overvågning af en eller flere vindmøller, ved brug af trådløse sensorer. Yderligere kan softwaresystemet sende set-punkter til generatoren for at ændrer dennes reguleringssløjfe. Der har i projektet været en meget naturlig opdeling af snitfladerne, i kraft af de fagligheder der har været inddraget og projektets udformning. Figur 1.2 viser snitfladen for projektet. Side 8

9 Figur 1.2: Snitflader for projektet 1.7 Læringsmål og forventede resultater Der ønskes gennem EIT projektet at opnå en række læringsmål, samtidig forventes en række faglige resultater inden for de forskellige studieretninger. Det ønskes at opnå følgende læringsmål for personlig udvikling indenfor EIT projektet: Samarbejde på tværs af fagligheder. Kommunikation mellem fagligheder. Opstille fælles mål og arbejde parallelt mod disse. Udarbejde klare snitflader mellem fagligheder der giver mulighed for uafhængigt arbejde. Tage hensyn til andres arbejdsmetoder. Forståelse og benyttelse af andres ekspertise. Håndtere og afhjælpe konflikter i projektet. Træffe beslutninger på tværs af fagligheder og overskue konsekvenser heraf. Udarbejde en fælles tidsplan for EIT gruppen, samt interne tidsplaner for undergrupper. Der er en række overordnede forventede resultater for faglighederne i EIT projektet. Disse mål vil blive yderligere behandlet i de respektive fagligheders afsnit af rapporten. Derfor præsenteres kun de overordnede mål for faglige resultater i projektet. Udarbejde en rapport bestående af fælles prolog og epilog, samt to delrapporter der behandler de faglige aspekter i projektet. Udvikle et softwaresystem, der benytter et trådløst sensornetværk til aflæsning af parametre fra vindmøllen. Side 9

10 Det forventes at den kørende version af overvågningssystemet indeholder en række kernefunktioner for systemet. Kernefunktionerne er: Sende set-punkter til vindmøllens reguleringsløjfe for at ændre effektproduktionen. Automatisk nødstop vha. sensorer, ved en række parameteroverskridelser. Et login-interface således der oprettes forskellige brugerrettigheder, afhængig af brugertypen. Vis status for en specifik vindmølle, herunder temperatur og aktuelt set-punkt. Det forventes at analyser/designe en funktion der automatisk opdatere set-punkt ud fra ønsket effekt. Teste den udviklede software og den trådløse kommunikation. Dimensionere en reguleringssløjfe til en dobbeltfødet vindmølle generator. Således at et konstant effektflow opnås. Styre/regulere generatorens producerede effekt. Dimensionering af en regulator ud fra systemets overføringsfunktion. Programmere reguleringen i LabView. Styre rotoreffekten med effektelektronik. Eftervise/afprøve reguleringen/styringen i en testopstilling for SS faglighed. Det er de faglige læringsmål der lægger til grund for visse milepæle i den udarbejdede tidsplan. Konklusionen for projektet vil tage udgangspunkt i de opstillede læringsmål. 1.8 Arbejdsmetode og proces Arbejdsmetode Der er i starten af projektet brugt tid på de indledende undersøgelser, problemstilling, tidsplan mm., hvor hele gruppen har været tilstede. Der er afholdt EIT gruppemøder, når det har været nødvendigt. Størstedelen af kommunikationen er foregået elektronisk, gennem , for at opnå større fleksibilitet. Der er blevet udarbejdet en samarbejdskontrakt mellem gruppens medlemmer, se bilag C. Der er i projektet blevet benyttet både Microsoft Word og L A TEX som tekstbehandlingsprogram. Udarbejdelsen af snitfladerne, se afsnit 1.6, i projektet har gjort det muligt at lave en faglig opdeling af EIT gruppen, således der kan arbejdes parallelt mod det fælles mål. Der er i kraft af udformingen af projektet, inddragelsen af fagligheder og snitfladerne, været en stor arbejdsbyrde i faggrupperne og ikke fokus på tværfaglighed. Side 10

11 Proces Der er blevet udarbejdet en overordnet tidsplan, med henblik på at styre projektprocessen bedst muligt, hvor de vigtigste milepæle er angivet. Herudover har hver undergruppe kørt med egne interne tidsplaner, disse kan ses i afsnit (DAT) og i kapitel 3 bilag 1 (SS). 12. september Aflevering af projektbeskrivelse. 17. september Endelig godkendelse af projektbeskrivelse og endelige snitflader. 24. november Test af samlet projekt. 1. december Påbegyndelse af fælles afsnit. 5. december Færdiggørelse af fælles afsnit. 16. december Aflevering af projekt. Figur 1.3 beskriver den samlede tidsplan for projektet i overenstemmelse med de opstillede milepæle. Figur 1.3: EIT projektets tidsplan Side 11

12 2 Delrapport 1 - Wireless Wind Turbine Control System Dette kapitel indeholder den datateknologiske delrapport. Der vil blive beskrevet hvordan softwaresystemet er blevet udviklet til at kommunikere med brugere gennem en grafisk brugergrænseflade, og gennem trådløse sensorboards op mod snitfladen Læsevejledning Dette afsnit beskriver tegn og symboler samt 1giver en læsevejledning for delrapporten. Kapitler opgives på formen 1, 2,... og underafsnit på formen 1.1 og Tabel- og figurtekst er placeret under elementet, og er nummereret på formen x.y, hvor x er kapitelnummer, og y er løbende nummerering. Kildehenvisninger er på formen: [x] - Side y, hvor [x] henviser til kilde nr. x på kildelisten. Side y, er siden i kilden der henvises til. Formler i rapporten er nummereret på formen (x.y), hvor x er kapitelnummer og y er løbende nummerering. Analyseafsnittet er lagt i bilag pga. begrænsninger af sideantal. Afsnit 2.3 giver et resumé af analyseafsnittet, der præsenterer de fundne problematikker og introducerer disse til læseren. Denne introduktion er tilstrækkelig for at forstå efterfølgende afsnit i delrapporten. Ønskes en mere detaljeret gennemgang af analysen, henvises til bilag A. I afsnit 2.6 vil der i forbindelse med sekvensdiagrammer, optræde ufuldstændige kald efterfulgt af en sort prik, betydende at sekvensdiagrammet fortsættes i et andet sekvensdiagram, med samme sorte prik som begyndelsespunkt. I afsnit 2.7 kan der fremkomme kodeeksempler der ikke er direkte kopi af den implementerede system kode. Der kan således være fjernet dele af koden for at holde fokus på den ønskede del. Når der gennem rapporten optræder et ikon ved et diagram, henviser det til den fysiske placering. Figur 2.1 viser de anvendte ikoner. Figur 2.1: Ikoner anvendt i rapporten Side 12

13 2.1 Projektværktøjer og projektstyring for datateknologi Formålet med dette afsnit er at beskrive hvilke projektværktøjer, der er benyttet til at gennemføre DAT fagprojektet. Der vil heriblandt blive beskrevet hvilket udviklingsmiljø og konfigurationsstyringsværktøj der er anvendt. Afsnittet vil også præsentere generelle projektstyringsværktøjer, der er blevet benyttet til at optimere projektprocessen Projektværktøjer Delrapporten skrives i L A TEX, da dette kan benyttes sammen med SubVersion (SVN) til versionstyring, som også bliver anvendt i forbindelse med softwarekonstruktionen. SVN er et godt værktøj når der er flere deltagere i samme projekt, da det effektiviserer arbejdsprocessen ved at muliggøre at flere deltagere kan arbejde på samme afsnit i rapporten samtidig. Til softwarekonstruktion benyttes udviklingsmiljøet Eclipse, og tilhørende plugins i forbindelse med UML-diagrammer og SVN. De fleste figurer i rapporten er udarbejdet i tegneprogrammet OmniGraffle Projektstyring Det er valgt at benytte Unified Process (UP) som processmodel til dette projekt samt at benytte SCRUM til projektadministration. Disse to projektværktøjer udgør tilsammen projektstyringen for dette projekt. Figur 2.2 viser en UP-model 1, som illustrerer arbejdsmængden faseafhængigt af den enkelte aktivitet. Figur illustrerer processen for et sprint i SCRUM, som oftest varer 30 dage, med scrummøder hver dag, som illustreret ved pilene. Ønskes yderligere information omkring SCRUM 3, se henvisning. Figur 2.2: UP model Figur 2.3: SCRUM model Som fremhævet med rødt på figur 2.2, udarbejdes projektet under elaborationsfasen. Dette indebærer at kravene i højere grad bliver fastlagt, analysen bliver udarbejdet, det grundlæggende designarbejde bliver udført og der arbejdes imod implementering af systemets skelet med kernefunktionaliteter. 1 [5] - Side 38 - Figur archive/scrum1.gif 3 [3] - Kap 1 og 3 Side 13

14 2.1.3 Milepælsplan Der er i dette afsnit opstillet vigtige milepæle for projektet, der er ligeledes beskrevet hvornår et sprint (jf. Scrum) slutter. Milepælene er opstillet i tabel 2.1, hvor kolonnen Milepæl indeholder overskrifter for milepælene, kolonnen Dato angiver deadline for milepælen og kolonnen Beskrivelse beskriver milepælens mål. Milepæl Dato Beskrivelse Projektgrundlag 17/10/08 Projektgrundlaget udarbejdet. Problemstilling og problemformulering er skrevet. Der er opstillet krav, korte brugsmønstrebeskrivelser, krav er tildelt brugsmønstrene, brugsmønstrene er prioriteret og projektet er afgrænset. Sprint 1 24/10/08 Sprint 1 afsluttes. Trådløs enhed kommunikation og kapiteloversigt 07/11/08 Kommunikation med de trådløse enheder er oprettet. Det første udkast til rapportens kapiteloversigt er udarbejdet. Systemfunktionalitet 1 13/11/08 Første del af systemfunktionaliteten er blevet a- nalyseret, designet, implementeret og testet. Review afsnit 14/11/08 Et udvalgt afsnit af rapporten afleveres til et review hold. Der afholdes et reviewmøde med formål for konstruktiv feedback. Sprint 2 14/11/08 Sprint 2 afsluttes. Systemfunktionalitet 2 03/12/08 Anden del af systemfunktionaliteten er blevet a- nalyseret, designet, implementeret og testet. Sprint 3 05/12/08 Sprint 3 afsluttes. Rapport rettet 15/12/08 Gennemretning af projektrapporten er udført. Endelig rapport 15/12/08 Rapporten er rettet, printet og indbundet. CD med krævet dokumentation er fremstillet. Sprint 4 16/12/08 Rapporten afleveres og sprint 4 afsluttes. Tabel 2.1: Milepælsplan Tidsplan Der vil i dette afsnit blive opstillet en tidsplan for projektet. Denne vil afspejle forskellige opgaver der har tilknytning til projektet, herunder både iværksætteri, research af trådløs kommunikation, udarbejdelse af brugsmønstre og dokumentation. Figur 2.4 beskriver den sidste og endelige tidsplan. Side 14

15 Figur 2.4: Tidsplan 2.2 Projektgrundlag Dette afsnit beskriver problemstilling, problemformulering, kravspecifikation, afgrænsning, brugsmønsterbeskrivelser og mål og forventede resultater, for W 2 T CS Problemstilling I nutidens vindmølleindustri er der et stigende behov for, at overvåge vindmøllerne i en offshore vindmøllepark, da det er mere besværligt for teknikere, at besøge vindmøllerne for at bekræfte, at de opererer som ønsket. Det vil derfor være en fordel at overvåge kritiske faktorer omkring vindmøllerne, uden fysisk tilstedeværelse. Dette er i dag muligt, men med begrænset fleksibilitet, da alle sensorer er forbundet med ledninger. Anvendelsen af flere sensorer resulterer i flere kabler tilkoblet en styreboks. Dette begrænser fleksibiliteten, da et positionsskifte af sensorer bliver besværliggjort af ledningsarbejde. I kraft af disse begrænsninger er det ønsket at tilføje trådløs sensorteknologi, således sensorerne er så fleksible at placere som muligt. Trådløs sensorteknologi vil derfor udvide mulighederne med henblik på at overvåge specifikke parametre i vindmøller. Figur illustrerer én løsningen, hvor en styreboks er placeret i tårnet umiddelbart under toppen og slæberingen. En styreboks kan herfra kommunikere med samtlige trådløse sensorenheder placeret i vindmøllens top. Udover trådløse sensorenheder, kan andre trådløse enheder placeres i vindmøllen, for at sende instruktioner til vindmøllestyringen. Slæberinge bliver ofte nedslidt og kan i værste tilfælde resultere 4 Side 15

16 Figur 2.5: Problemstillingen vedrørende vindmøllen i at det ikke er muligt, at sende vindmøllen nye instruktioner. Styreboksen benytter luften som medie, og ikke de ledninger som løber gennem slæberingen, derfor har en nedslidt slæbering ingen påvirkning på kommunikationen, og det vil stadig være muligt at sende vindmøllen instruktioner om nødstop eller lign. Derfor kan den trådløse kommunikation mellem styreboksen og de trådløse enheder benyttes til, at forhindre potentielt farlige situationer, hvilket øger sikkerhedsniveauet i en vindmøllepark Problemformulering Det ønskes at udvikle et softwaresystem kaldet Wireless Wind Turbine Control System (W 2 T CS), som kan overvåge samt interagere med offshore vindmøller. Disse vindmøller er placeret i vindmølleparker og W 2 T CS skal derfor opsættes til at kunne overvåge alle vindmøllerne. Softwaresystemet skal give et samlet overblik over vindmølleparkens produktion og status. Derudover skal det være muligt at se status for den enkelte vindmølle. Parametre i denne status er fx aktuel temperatur i generatoren og genereret effekt. Det skal ligeledes være muligt at styre vindmøllernes produktion, bremse, vingespidser mv. gennem softwaresystemet. For at optimere effektproduktionen skal vindmøllens aktuelle effektproduktion kunne overvåges. Yderligere skal det være muligt at ændre fx reguleringssløjfen for at tilnærme den ønskede effektproduktion, ved at sende set-punkter til vindmøllen. Softwaresystemet skal herudover kunne oplyse om evt. fejl i vindmøllernes komponenter, samt kategorisere disse efter hvor alvorlige de er, og derved om udbedring kan vente til næste service. De forskellige parametre der måles i vindmøllen skal måles via sensorer der trådløst sender informationerne videre til en styreboks placeret i vindmøllen. Denne trådløse kommunikation vil forøge fleksibiliteten i forhold til placering og tilføjelser af sensorer i vindmøllen. Overvågningen og interaktionen med vindmøllerne skal kunne foregå via en almen computer, som er koblet op mod Internettet. Softwaresystemet skal være sikkert, således kun autoriserede personer kan benytte systemet. Side 16

17 2.2.3 Kravspecifikation for systemet Der vil i dette afsnit blive opstillet en kravspecifikation der har til formål, at beskrive kravene til systemets funktionalitet. De funktionelle krav vil blive opdelt i funktionsområder. Et funktionsområde beskriver kravene i forhold til vindmølleparken, et funktionsområde der beskriver kravene for en specifik vindmølle, et funktionsområde der beskriver krav for hele systemet og et funktionsområde der beskriver krav for mobile klienter. Der vil ligeledes blive opstillet en række ikke-funktionelle krav, disse vil omhandle kvalitets krav for W 2 T CS. Funktionelle krav: De funktionelle krav (F) vil blive kategoriseret indenfor følgende kategorier: FVP: FVI: FVS: FVC Krav vedrørende vindmølleparken som helhed. Krav vedrørende individuelle vindmøller. Krav der behandler statistisk analyse. Krav vedrørende mobile klienter. ID Detaljer ID Detaljer FVP01 W 2 T CS skal informere om vindmølleparkens aktuelle samlede effekt FVP02 W 2 T CS skal informere om vindmølleparkens aktuelle gennemsnitlige effekt pr. vindmølle FVP03 W 2 T CS skal give et overblik over hvilke vindmøller der i givet fald ikke arbejder optimalt FVP04 Det skal være muligt at fastlægge den samlede generede effekt der ønskes produceret, således W 2 T CS optimerer hvor meget effekt hver vindmølle skal producere FVP05 W 2 T CS skal holde log over hvilke brugere der sender instruktioner til FVP06 Det skal være muligt at tilføje og fjerne en vindmølle fra W 2 T CS vindmøllerne, og hvilke instruktioner der sendes FVP07 W 2 T CS skal informere om vindretningen FVP08 W 2 T CS skal alarmere PDA- omkring vindmølleparken klienterne hvis en fejl opstår Side 17

18 FVI01 W 2 T CS skal informere om en vindmølles aktuelle generede effekt FVI03 W 2 T CS skal informere om en vindmølles moment FVI05 W 2 T CS skal informere om temperaturen for forskellige dele vedrørende vindmøllen FVI07 W 2 T CS skal informere om fejl ved en vindmølle hvis en fejl er opstået FVI09 W 2 T CS skal gøre det muligt at aktivere og deaktivere en vindmølle FVI11 Det skal være muligt at sende instruktioner til en vindmølle FVI13 W 2 T CS skal holde log over hver informationsændring på en vindmølle FVI15 Det skal være muligt at slå fejlalarmeringen til og fra på en vindmølle FVI17 Det skal være muligt at sende et setpunkt, således reguleringssløjfen på vindmøllen kan optimeres FVC01 PDA-klienten skal indeholde alle overvågningsaspekterne i systemet FVI02 FVI04 FVI06 FVI08 FVI10 FVI12 FVI14 FVI16 FVS01 FVC02 W 2 T CS skal informere om vindhastigheden omkring en vindmølle W 2 T CS skal informere om omdrejningstallet for en vindmølle W 2 T CS skal informere om rotationshastigheden for en vindmølle Hver fejlmeddelelse på en vindmølle skal identificeres, således fejlene kan prioriteres W 2 T CS skal gøre det muligt ved en nødssituation at bremse vindmøllen Det skal være muligt at ændre informationer omkring en vindmølle W 2 T CS skal holde log over hvilke bruger der sender instruktioner til hver vindmølle, og hvilken instruktion der bliver sendt W 2 T CS skal angive den optimale generede effekt for en vindmølle baseret på vindhastighed og de fysiske dele i vindmøllen W 2 T CS skal kunne udarbejde statistisk dokumentation udfra genereret effekt produceret af hver vindmølle samt hele vindmølleparken Det skal være muligt at slå fejlalarmeringen i vindmølleparken til og fra Side 18

19 Ikke-funktionelle krav ID Detaljer ID Detaljer K01 Der skal være en forbindelse til hver vindmølle i vindmølleparken K02 Der skal være placeret en klient i hver vindmølle, der kommunikerer med en række sensorer K03 Kommunikationen mellem styreboksen og sensorene skal være trådløs K04 Det skal være muligt at kommunikere pålideligt med vindmøllens generator K05 For at øge sikkerheden, skal W 2 T CS besidde et login-interface K06 W 2 T CS skal have en database hvor alle instruktioner og data fra vindmøllerne bliver gemt K07 Der må ikke være tab af data under datatransport. K08 Der må maksimalt gå 10 sek. fra en vindmølleinteraktion fra Centralklienten til vindmøllen har modtaget instruktionen K09 W 2 T CS skal være platformsuafhængigklient, K10 Der skal være en såkaldt Centralmen der kan installeres på en al- bærbar computer. Denne skal kunne kommunikere og styre vindmøllerne K11 Softwaresystemet på Centralklienten K12 Softwaresystemet på Centralklienten skal indeholde en grafisk brugergrænseflade skal være overskuelig og brugervenlig K13 Det skal være muligt at interagere K14 Overvågningsaspektet i systemet med vindmøllerne 24 timer i døgnet skal kunne implementeres i en mobil-klient Afgrænsning af systemets funktionalitet For at afgrænse systemets funktionaliteter, er det nødvendigt at prioritere brugsmønstrene, således der dannes et overblik over hvilke funktionaliteter der er nøglefunktioner og hvilke risici der er forbundet med de enkelte funktioner. Dette er gjort med henblik på at behandle de dele af systemet, som bedst dækker den grundlæggende funktion af systemet, samt de fagligheder der ønskes arbejdet med i forbindelse med semesteret. I tabel 2.6, er gruppens prioritering præsenteret. Gruppen har valgt af benytte en modificeret version af RUP attributter, for at analysere på brugsmønstrene før de prioriteres. De attributter der er valgt at fokusere på er: Benefit - beskriver hvor vigtig funktionen er, fra kundens synspunkt. Den kan have tre værdier, critical, important og useful. Side 19

20 Critical vælges når funktionaliteten er yderst vigtig for systemet, og kunderne ikke vil acceptere hvis funktionen udebliver. Important vælges når funktionaliteten er vigtig men ikke altafgørende for kundens accept, og formindsker dermed kundens tilfredshed. Useful vælges når funktionaliteten er brugbar, men ikke gør nogen forskel for kundens overordnede billede af systemets funktionalitet. Effort - et estimat der beskriver hvor mange resurser der skal bruges for at virkeliggøre funktionen. I denne sammenhæng fokuseres der på arbejdsdage. Risk - beskriver risikoen ved at implementere funktionen. Risikoen kan afhænge af erfaring indenfor implementeringen, samt manglende teknologi til realisering af funktionaliteten. Der findes ofte en sammenhæng mellem effort og risiko. Risk kan have værdierne high, medium og low. Stability - et estimat over hvor meget funktionen vil ændre sig i løbet af processen. Denne kan også have værdierne high, medium og low. Ved at betragte og vurdere ovenstående parametre for hvert brugsmønster, var det muligt at prioritere brugsmønstrene. Prioriteringen vægtes med tal fra 1-5 hvor 5 vægtes højst. Resultatet kan ses i følgende tabel. Tabel 2.6 viser samtidig den afgrænsning gruppen har foretaget, og denne afgrænsning er foretaget med attributterne skal, bør og kan. I denne afgrænsningsproces har det naturligvis været for øje, at inddrage brugsmønstre med relevans til de fagligheder gruppen ønsker inddraget i løbet af dette semester. Resultatet af afgrænsningen giver et system der både opbygger rygraden i det færdige system samt giver projektet en faglig relevans, og er markeret på figur 2.6. Figur 2.6: Projektafgrænsning Side 20

21 2.2.5 Brugsmønsterbeskrivelser Dette dokument er begyndelsen på udforskningen af hvilke aktører og brugsmønstre der tilhører softwaresystemet W 2 T CS Sammen med aktørlisten, de funktionelle og ikke-funktionelle krav, vil disse udgøre en stor del af dokumentationen, der lægger til grund for projektet. Aktørliste Navn Ansat Administrator Overvågningsmedarbejder Analytiker Ikke-ansat Styreboksen Beskrivelse Denne aktør er ansat i virksomheden der benytter W 2 T CS. Dette er en generalisering, der indeholder administrator og overvågningsmedarbejder. Administratoren overvåger status af vindmøllen og opdaterer setpunkter hvis nødvendigt. Sørger desuden for at informere nødvendigt personel i forbindelse med eftersyn af en vindmølle. Aktøren har mulighed for at overvåge vindmøllernes status. Analysere lagret data indsamlet fra vindmøllerne for at optimere driften, ved fx at opdatere reguleringsalgoritmen. Aktøren er en udefrakommende person, der ikke er ansat i virksomheden og ikke har et brugerlogin. Sender status videre i systemet. Tabel 2.2: Aktørliste for W 2 T CS Korte brugsmønsterbeskrivelser Der er udarbejdet korte brugsmønsterbeskrivelser. Afsnittet vil kun beskrive de korte brugsmønstre der bliver behandlet i rapporten. For at læse alle korte brugsmønsterbeskrivelser henvises der til bilag A.1. Brugsmønster: Send set-punkt ID 1 Aktør: Administrator Formål: Sende set-punkter til vindmøllen. Kort oversigt: Administratoren skal kunne sende set-punkter til vindmøllen for at optimere dennes reguleringssløjfe. Brugeren og instruktionerne bliver automatisk logget af systemet. Tabel 2.3: Kort brugsmønsterbeskrivelse for Send set-punkt til vindmølle. Side 21

22 Brugsmønster: Automatisk nødstop ID 7 Aktør: Styreboksen Formål: Styreboksen skal kunne stoppe en vindmølle til et hvilket som helst tidspunkt, hvis der opstår potentielle farlige situationer, fx ved for høj temperatur i generatoren. Kort oversigt: I tilfælde af potentielle farlige situationer skal styreboksen aktivere vindmøllens nødstop. Tabel 2.4: Kort brugsmønsterbeskrivelse for Automatisk nødstop. Brugsmønster: Login ID 8 Aktør: Ansat Formål: At uautoriserede brugere ikke kan benytte W 2 T CS Kort oversigt: W 2 T CS skal kunne skelne mellem forskellige brugertyper, således de får forskellige rettigheder for, at sikre at kun administratorer kan udføre kritiske ændringer ved en vindmølle Tabel 2.5: Kort brugsmønsterbeskrivelse for Login. Brugsmønster: Angiv ønsket genereret effekt ID 11 Aktør: Administrator Formål: At angive den ønskede genererede effekt fra vindmølleparken. Kort oversigt: Administratoren skal kunne angive den ønskede effekt vindmølleparken skal producere. Dette gøres ved at angive den ønskede effekt, hvorefter W 2 T CS selv regulerer vindmøllernes produktivitet, således den ønskede produktion, om muligt, opnås. Tabel 2.6: Kort brugsmønsterbeskrivelse for Angiv ønsket generet effekt. Brugsmønster: Send status ID 13 Aktør: Styreboksen Formål: Ansat skal have overblik over en specifik vindmølle. Kort oversigt: En ansat skal kunne få et overblik over en specifik vindmølles status; den producerede effekt, moment, mm. Tabel 2.7: Kort brugsmønsterbeskrivelse for Send status Side 22

23 For at give et enkelt overblik over de udvalgte brugsmønstre, og deres respektive aktører, bliver der i figur 2.7 præsenteret et brugsmønstre diagram. Når styreboksen sender vindmøllens status, Figur 2.7: Brugsmønstre diagram fpr W 2 T CS er der kun visse aktøre der har mulighed for at se denne vindmøllestatus. Dette er illustreret, på figur 2.7, ved at kun en ansat har mulighed for at se status for en specifik vindmølle.se status for specifik vindmølle er kun medtaget for at vise hvilke aktører der har mulighed for benytte denne funktionalitet. Se status for specifik vindmølle er ikke et selvstændigt brugsmønster, men en yderligere specificering af Send status Mål og forventede resultater Det er et naturligt ønske at analysere, designe og implementere hele systemet. Pga. tid- og pladsmæssige begrænsninger er dette ikke muligt. Udfra afgrænsningen, er det muligt at beskrive de forventede resultater. Nedenstående punkter beskriver mål og forventede resultater: Vælg kit til trådløs kommunikation. At opnå en generel forståelse af grunbegreberne inde for programmeringssproget C, for derved kunne programmere microcontrollere på det valgte kit. At få det valgte kit til at sende og modtage data. Analysere og bearbejde de udvalgte krav. Analysere og bearbejde de udvalgte brugsmønstre. Designe en vedligeholdelsesvenlig og skalerbar softwareløsning. Implementere datakommunikation mellem klient og server. Skrive en rapport hvor projektafgrænsningens omfang er analyseret og designet i en sådan grad, at en 3. part kan implementere softwaresystemet. Side 23

24 Udarbejde en kørende version af W 2 T CS som indeholder de behandlede funktionaliteter. Det forventes at den kørende version vil indeholde en række kernefunktioner for systemet. Disse vil være: Sende set-punkter til vindmøllens reguleringsløjfe. Automatisk nødstop vha. sensorer, ved en række parameteroverskridelser. Et login-interface således det er muligt at oprette forskellige brugerrettigheder, afhængig af brugertypen. Vise status for en specifik vindmølle, herunder temperatur. Herudover forventes det at analysere og designe brugsmønsteret Angiv ønsket genereret effekt. Ovenstående punkter er gruppens forventede resultater, og på den baggrund, udgør visse af punkterne vigtige milepæle i tidsplanen, som beskrives i afsnit Analyse af de udvalgte brugsmønstre Der gives her en kort gennemgang af de fundne problemstillinger gennem analyseafsnittet, der kan læses i dets fulde længde i bilag A. Brugsmønsteret Login omhandler systemets sikkerhed. I et system der kan kommunikere med en hel vindmøllepark, stilles der krav til sikkerheden. Således har uvedkommende ikke adgang til systemet og brugerrettighederne er afhængig af, hvilken ansat der benytter systemet. Det skal være muligt for en ansat, at logge sig ind i systemet med brugernavn og kodeord. Brugsmønsteret Send status behandler hvilke parametre der skal overvåges på vindmøllerne. Vindmøllecentralen ønsker at se status på de vindmøller der overvåges. Der kan overvåges temperaturen ved generatoren, den aktuelle effekt hver vindmølle producerer, vindhastigheden ved vindmøllen og omdrejningstallet på rotoren. Der vil i dette brugsmønster kun betragtes problemstillingen ved temperaturen ved vindmøllens generator, da anden status blot ses som ekstra parameteroverførsler. Det skal besluttes hvorledes status skal overføres med push- eller pull operation. Ved pulloperation efterspørger styreboksens status fra en sensorer med et forudbestemt tidsinterval, ved push-operationen sender en sensorer status til styreboksen med et forudbestemt tidsinterval. Derudover skal styreboksen kun videresende informationer når statusparametrene ændres, således der ikke skabes unødvendig datatrafik. Brugsmønsteret Send set-punkt omhandler hvordan effektproduktionen skal optimeres. Administratoren skal have mulighed for at ændre reguleringssløjfen, ved at sende set-punkter til vindmøllens generator, og derved styre den effekt vindmøllen producerer. Brugsmønsteret Angiv ønsket genereret effekt omhandler de situationer hvor vindmølleparkens effektproduktion ikke kan optages på elnettet. Svingende energiforbrug og manglende mulighed for oplagring, gør det ønskeligt at kunne neddrosle vindmøllernes produktion. Det vil ligeledes bidrage med mindre slitage på møllerne, hvis disse står stille når produktion ikke er nødvendige. Brugsmønsteret kan udføres på to måder, manuelt eller automatisk. Ved manuelt forstås at en administrator på centralen angiver den ønskede Side 24

25 energi en vindmøllepark skal producere. Ved automatisk sætter systemet selv den ønskede energi fra vindmølleparken baseret på efterspørgslen på elnettet. Skal det vurderes om vindmølleparken genererer den ønskede energi, er det nødvændigt med en sensor i hver vindmølle, som angiver den aktuelle effektgenerering. Vindmøller er ikke altid i stand til at producere den ønskede effekt, hvilket bl.a. afhænger af vindforholdene omkring vindmøllen. Hvis én vindmølle ikke kan generere nok energi, må flere vindmøller sættes igang for at levere den ønskede effekt. W 2 T CS skal dermed finde de nye set-punkter til hver vindmølle og udsende disse for at imødekomme ønsket om produceret effekt. I kritiske situationer skal brugsmønsteret Automatisk nødstop af vindmølle sættes igang, da kritiske fejl på en vindmølle i værste tilfælde kan resultere i skade på vindmøllen. For at foregribe begivenhedernes gang og bremse en vindmølle til stilstand, før den kritiske fejl opstår, overvåges parametre som bl.a. generatorens temperatur og vindhastighed omkring vindmøllen. For at realisere systemets funktionaliteter er det nødvendigt at opdele systemet i subsystemer der kommunikerer. Systemets opdeling i disse subsystemer præsenteres i afsnit Systemets anvendte teknologi Ud fra de opstillede problemer i analysekapitlet, se kapitel 2.3, er det nødvendigt at træffe en række beslutninger vedrørende den trådløse kommunikation i vindmøllen. Det skal herunder besluttes hvilken type enhed, der skal være tilsluttet sensorerne i vindmøllen. Yderligere skal det besluttes hvordan kommunikationen med det resterende system skal opsættes. Afsnit vil beskrive hvilke fysiske enheder der benyttes til at modtage instruktioner fra systemet, og sende information fra sensorerne. Afsnit beskriver hvordan der kommunikeres mellem sensorer og styreboksen. Herunder hvilken metode der benyttes til at oprette kommunikationen og hvilken protokol der benyttes Trådløse kommunikationsenheder Der skal i projektet benyttes et trådløst netværk mellem sensorenheder og en stationært placeret styreboks i vindmøllen. Der er forskellige muligheder for opsætning af den trådløse kommunikation, herunder en række prefabrikerede produkter. Det valgte produkt er et AVR Raven Kit fra producenten Atmel 5. Dette kit består af en USB-enhed der kan tilsluttes styreboksen, samt en række trådløse enheder, der kan kommunikere med USB-enheden via en trådløs 2,4GHz forbindelse, der benytter standarden IEEE Hver enhed, herefter kaldet boards, består bl.a. af 2 microcontrollere, et LCD og en transciever der varetager den trådløse kommunikation. Den første microcontroller er en ATmega 3290P 6 med en række I/O porte heriblandt D/A og A/D. ATmega 3290P styrer det tilhørende LCD, der er placeret på boardet. Den anden microcontroller er en ATmega 1284P 7, denne styrer kommunikationen mellem transcieveren 8 og ATmega 3290P. Boardets preimplementerede muligheder for bl.a. temperaturmåling og analogt output, betyder at Side 25

26 konstruktion af eksterne hardwareenheder ikke er nødvendigt, for at påbegynde test-programmering. Ønskes en dybere teknisk redegørelse for disse microcontrollere, henvises til producentens hjemmeside 9. Valget af det anvendte Raven kit bestående af board et og USB-enheden, se figur 2.8, herefter Figur 2.8: AVR Raven kit benævnt kit, er baseret på en række aspekter, bl.a. et grundlæggende kendskab til microcontrollere fra Atmel, gennem undervisning på tidligere semestre. En anden væsentlig årsag til valget af kit et, er USB-interfacet der giver mulighed for kommunikation mellem microcontrollerne og styreboksen. Således skal der ikke benyttes eller udvikles andet hardware, for at oprette kommunikation mellem den udviklede Java-applikation og kit et. Der er udviklet en række frit tilgængelige applikationer til kit et, der gør det muligt at opsætte kommunikationen med trejdeparts protokoller. Valget af kit et giver øget fleksibilitet i kraft af, at forskellige protokoller kan benyttes, herunder ZigBee 10 og TCP/-IPv4 og -IPv6. En ulempe ved kit et er, at det indeholder mange unødvendige funktionaliteter for projektets formål. Dette resulterer i, at de unødvendige hardwarekomponenter optager størstedelen af microcontrollernes porte, således de ikke er anvendelige til andre formål. Kit et er valgt bl.a. pga. god dokumentation, let kommunikationsetablering samt mange programeksempler Trådløs kommunikation og protokoller Kommunikationen til boards ne foregår trådløst, der skal dermed implementeres en metode, der gennem en Java-applikation, placeret på styreboksen, kan oprette forbindelse til boards ne. På boards ne tilkobles de sensorer der skal måle på vindmøllens tilstand. Styreboksen har til ansvar at udsende instruktioner til boards ne gennem en Java-applikation. Dette sker via den tilkoblede USB-enhed, der skal tilgås gennem Java. Eftersom Sun Microsystems Java 2 Platform, Standard Edition (J2SE), ikke har mulighed for at kommunikere med USB-enheder, er det nødvendigt at benytte en API der giver denne mulighed. Dette kunne være RXTX-API en 11, der benytter Suns Java communications-api. RXTX læser fra en seriel COM-port, der skal hermed opsættes en virtuel COM-port hvorfra data kan læses. Det kræves dermed, at der implementeres en FTDI-chip 12 (USBserial), enten som en ekstern enhed der tilsluttes mellem USB-enheden og styreboksen, eller chippen monteres direkte på USB-enheden. Begge implementationer kræver, at der skrives et nyt program til Denne API kan frit downloades til alle platforme: Side 26

27 USB-enheden. Dette vil medføre en uønsket kompleksitet, hvorfor RXTX-API en ikke benyttes som løsning på kommunikationen mellem styreboks, USB-enhed og boards ne. En anden metode til at oprette forbindelse mellem enhederne er at benytte et IP baseret netværk. Arch Rock 13 har udviklet et operativsystem der benytter TCP/IP. Arch Rocks operativsystem er udviklet med henblik på, at blive benyttet i industrien til kommunikation mellem sensorer der måler forskellige parametre. Yderligere er der udviklet en udgave der understøtter det valgte kit (evalueringsudgave der medfølger ved køb af Atmels Raven kit 14 ). Arch Rock understøtter standarderne IP/6LoWPAN 15 og den trådløse standard IEEE Det er hermed muligt at opsætte en trådløs kommunikation mellem boards ne og USB-enheden. Da Arch Rocks operativsystem understøtter IP, kan der via sockets kommunikeres med boards ne fra Java. Arch Rocks operativsystem til kit et vil blive benyttet i dette projekt, da det er udviklet til trådløse sensornetværk og der er mulighed for at videreudvikle på operativsystemet. Opsætning af Arch Rocks IP/6LoWPAN operativsystem Arch Rocks operativsystem skal installeres på både boards ne og USB-enheden 17. USB-enheden agerer router og routerens informationer kan, pga. en webserver herpå, vises via en browser. Der kan derudover benyttes kommandobaseret kommunikation med boards ne, hvilket yderligere beskrives under afsnittet om Telnet-protokollen. Figur 2.9 giver et eksempel på kommunikation mellem USBenheden, boards og sensorer. Figur 2.9: Kommunikation melem USB-enhed, boards ne og sensorerne Netværksprotokollen Telnet Telnet er en netværksprotokol, der er indeholdt i TCP/IP-protokolstakken til fjernafvikling af metoder på serveren. Der medfølger en Telnet-klient i de fleste styresystemer, som kan benyttes til http : //asdsupport.archrock.com/ 15 Arch Rock er udviklet til at benytte low-power, wireless personal area networks (LoWPANs). 16 For en mere detaljeret gennemgang se http : //asdsupport.archrock.com/docs/arch Rock Overview.pdf og http : // P AN tutorial.pdf 17 For opsætning/ installering af software se http : //asdsupport.archrock.com/docs/quickstart /QUICKST ART.htm Side 27