Totankprosjektrapport

Høgskolen i Sør-Trøndelag Totankprosjektrapport Prosjektoppgave i Styresystemer 2AEL13H våren 2015 Gruppe 5 & 6 Emil Hatletveit Kristian Strøm Terje Magnus Sørensen Stian Berg Dyrnes Snorre Vongraven Andreas Haugen Roy Kenneth Solvang Jørgen Nordvik Aasen Andreas Stahl Rød Knut Marius Røsberg Fredrik Løkken Michael-Alexander Mcgrory 07.05.2015

ii

Forord AH Alle studenter ved automasjonslinjen ved HiST gjennomfører i fjerde semester et større prosjekt i faget Styresystemer og Reguleringsteknikk. Prosjektet har som hensikt å gi studentene trening i samarbeid, rapportskriving og praktisk problemløsning, samt øke den faglige kompetansen hos alle involverte. I totanksprosjektet har gruppe 5 og 6 blitt slått sammen for å løse problemet å regulere nivået i begge tankene på tankriggen. I denne rapporten er det gitt en detaljert beskrivelse av hvordan totanksprosjektet er blitt utført. Slik at det er mulig for en ingeniør eller student som kommer fra en lignende eller tilsvarende utdanningsbakgrunn skal kunne forstå hvordan kommunikasjonen og nivåreguleringen fungerer i vårt system. Rapporten består av arbeid utført i InTouch, ix-developer, Master-PLS og Slave-PLS ene. Det er i tillegg beskrevet hvilke bonusoppgaver gruppene har valgt og hvordan de har blitt løst. iii

Sammendrag TMS Denne rapporten har som formål å dokumentere totankprosjektet, som er en del av prosjektoppgaven i faget styresystemer og reguleringsteknikk. Vi skal i løpet av dette prosjektet regulere to forskjellige varianter av væsketanker, først med en tank, og deretter med to tanker. Disse tankene skal reguleres ved hjelp av to PLS-er. Begge disse PLS-ene er styrt av en tredje PLS, som også er programmert i Gx Works2. Det skal i tillegg lages et brukergrensesnitt både på PC og på brukerpanel. Hensikten med totankprosjektet var å nivåregulere to væsketanker ved hjelp av PLS-er. Hvordan dette er gjort er delt opp i flere elementer: - Bestemme hvem som har ansvar for den enkelte delen av prosjektet. - Velge ut det beste fra hver gruppe på PLS-program og HMI-grensesnitt. - Programmering av PLS-er. - Utarbeiding av IX-panel og InTouch. - Det ble avsluttet med at begge gruppene gjorde en bonusoppgave hver. o Gruppe 5; IP-Kamera o Gruppe 6; Autotuning Vi har i tillegg oppdatert nettsidene som rapportene blir lagt ut på. Det er med en prosjektstyringsdel for begge gruppene, som sier hvordan prosjektet ble gjennomført. I prosjektsyringsdelen er det også med en oppdatert kurve for arbeid i forhold til planlagt. Totankprosjektet ble avsluttet med demonstrasjon. Nivåreguleringen i systemet ble funnet tilfredsstillende og brukergrensesnittet brukervennlig, gruppene kan gjøre seg klar for innlevering av tidsskrift og prosjektpresentasjon. iv

Innhold Forord AH iii Sammendrag TMS iv 1 Innledning 1 1.1 Oppgavetekst TMS 1 1.2 Definisjoner TMS 2 1.3 Prosjektmål AH 4 1.3.1 Prosessmål 4 1.3.2 Resultatmål 4 2 Teknisk del 5 2.1 PLS-programmer og regulatorinnstillinger tank 1- EWH/KR/RS 5 2.1.1 PLS-programmer 5 2.1.2 Sprangrespons tank1, LV1 og LT1 14 2.1.3 Førsteordensapproksimasjon FOPDT (First order plus dead time) 15 2.1.3 Regulatorinnstillinger for tank 2 17 2.1.4 Hysterese 19 2.2 IX-panel AR, TMS, JA 22 2.2.1 Kravspesifikasjoner 22 2.2.2 Tags 23 2.2.3 Utforming og design 24 2.3 InTouch 27 33 2.3.1 Sending av verdier 34 2.3.2 IP Kamera 35 2.3.3 Alarmer 37 2.3.4 Definering av alarmer 37 2.3.5 Sikkerhet 38 2.3.6 Access Level 39 2.4 Bonusprosjekt gruppe 5 IP-Kamera AR 41 2.4.1 Oppsett: 41 2.5 Bonusprosjekt gruppe 6 Autotuning 44 2.5.1 PLS-kode SBD 44 2.5.2 Betjening av autotuning i intouch KS 51 v

3 Prosjektstyring gruppe 5 52 3.1 Deltagere 52 3.2 Tidsbruk KR 53 3.3 Prosjektstyring og samarbeid AR & KR 54 4 Prosjektstyring gruppe 6 55 4.1 Deltagere 55 4.2 Tidsbruk TMS 56 4.3 Prosjektstyring og kvalitetssikring SV 56 4.3.1 Statusrapportering 56 4.3.2 Standardiserte skjemaer 57 4.3.3 Versjonskontroll 57 4.3.4 Tester og sjekklister 57 4.4 Prosjektstyring og samarbeid SV & KS 58 5 Prosjektstyring totank AR & KR 59 6 Konklusjon SV 60 7 Litteratur TMS 61 8 Vedlegg 62 vi

1 Innledning 1.1 Oppgavetekst TMS I denne delen av prosjektet skal vi bruke nivåregulering for å få ønsket væskenivå i to tanker. Dette skal gjøres via regulatorer som er bygd opp i to PLS-er. Du skal ha mulighet til å regulere nivået i tanken med P- eller PI-regulator. I tillegg til dette skal det være mulig å bruke foroverkopling fra forstyrrelsen i tank 2. Foroverkoplingen skal kunne brukes som P-, D- eller PD-regulator. Du skal bruke pådrag fra regulatoren til å styre ventilene på innløpet. Om det er tid skal gruppene gjennomføre et bonusprosjekt, der står gruppene fritt til å velge mellom noen utvalgte oppgaver. For gruppe 5 ble bonusprosjektet oppsett av riggovervåking via et IP-Kamera, mens gruppe 6 valgte autotuning som bonusoppgave. Figur 1 Oversiktsbilde kobling mellom PLS-rig og tank-rig 1

1.2 Definisjoner TMS AD/DA-omformer: Analog-Digital Digital-Analog, Elektrisk krets som gjør om fra analog signal til binære verdier, og motsatt. HMI: Human Machine Interface. Grensesnittet som brukeren presenteres for når han/hun skal bruke en datamaskin for å utføre en oppgave. Brukergrensesnittet er bare en del av et dataprogram (InTouch). It's Learning: Nettportal tatt i bruk av HiST hvor man kan legge ut filer og faginformasjon. Matlab/Simulink: Program for programmering, brukt for modellering og simulering. GX Works2: Program for programmering av PLS. HiST: Høyskolen i Sør-Trøndelag. InTouch: Program for å konstruere brukergrensesnittet for operatør på PC. ix Panel TA100: Operatørpanel festet på PLS-rigg, med berøring og farge skjerm. PLS: Programmerbar Logisk Styring. En datamaskin med inn- og utganger som du kan koble deg på. Vi benytter to typer under prosjektet to FX1N og en Q00. Samplingstid: Tiden mellom hver gang AD-omformeren gir et signal binært signal, fra et analogt signal. Bit: Enhet for digital informasjon. Kan ha verdien 0 eller 1 (av/på), kan lagre en boolsk verdi. Kan behandles i grupper på 4 (kvartett K1), 8 (byte 1B), 16 (word/dataord) og 32 (double word). Boolsk variable: Variabel som kan ha to verdier 0 eller 1 (av/på). Bufferminne: Lagringssted for digital informasjon. I PLS-modulene er bufferminnet nummerert (D0), alle bufferminner inneholder 16 bit. I/O Input/Output: Innganger og utganger på datamaskiner. LD/ FBD Ladderdiagram/Funksjonsblokkdiagram: Grafiske programmeringsspråk for PLS. IL Instruksjonsliste: Tekst basert programmeringsspråk for PLS. Minne: Ligningssted for digital informasjon. For eksempel 1-bits minneceller (M0) og 16-bits dataregister (D0). POU: Program Organisation Unit, delprogram i GX Works2. Bygd opp av for eksempel Ladderdiagram. Tag: Digital merkelapp. Brukes for å linke dataregister, minneceller eller andre verdier for å gi bedre oversikt i programmeringen. 2

Anti-aliasingfilter: Elektronisk filter bygd opp av operasjonsforsterker, motstand og kondensator. Filteret er et lavpassfilter som vil ta bort høyfrekvent støy for å hindre nedfolding (uønskede lave frekvenser på målingene som skyldes sampling). Foroverkobling: En reguleringsmetode som legges til pådraget for raskere kompensering av forstyrrelser hvor du måler forstyrrelser (kan også kombineres med matematisk modell). Foroverkobling kombineres som regel med tilbakekoblingsregulator (PID). Eventuelle feil i foroverkoblingen vil da kompenseres av tilbakekoblingen. PI-regulator: Proporsjonal- og Integral-regulator. Elektronisk styreenhet som du programmerer med en matematisk algoritme med forskjellige operasjoner. For å regulere prosessen via pådraget. PD-regulator: Proporsjonal- og Derivat-regulator. Elektronisk styreenhet som du programmerer med en matematisk algoritme med forskjellige operasjoner. For å regulere prosessen via pådraget. 3

1.3 Prosjektmål AH 1.3.1 Prosessmål Gruppemedlemmene skal: Få økt kunnskap og erfaring innenfor prosjektplanlegging og prosjektstyring. Få bedre erfaring med gruppearbeid, og sammen sørge for at prosjektgruppens resultatmål blir oppnådd. Kunne skrive gode rapporter og presentere innholdet. Kunne anvende teorien fra de forskjellige delene av faget Styresystemer på et praktisk problem. 1.3.2 Resultatmål Prosjektgruppene skal: Utarbeide og programmere regulator system i PLS Regulatoren skal programmeres slik at den skal kunne brukes som P- og PI-regulator med rykkfri over gang ved bytte av regulatortype. Utarbeide og programmere et brukergrensesnitt ved hjelp av InTouch(PC) og et operatørpanel av typen ix Panel TA100. Her skal prosessen kunne overvåkes og styres etter gitte operatørspesifikasjoner Lage et intuitivt brukergrensesnitt med mulighet for forskjellig operatør innlogging. Kunne bruke autotuning på tank 1 til forslag for regulatorinnstillinger. Bruke webkamera til å overvåke tankriggen. Levere fullstendig dokumentasjon av alt utført arbeidet. Levere alle rapporter innen leverings frist. Sørge for at alle deltakerne er kjent med de forskjellige delene av prosjektet. Kunne redegjøre for framgang av prosjektet til veileder ved prosjektmøter. 4

2 Teknisk del 2.1 PLS-programmer og regulatorinnstillinger tank 1- EWH/KR/RS 2.1.1 PLS-programmer Når vi skulle slå sammen regulatorprogrammene fra gruppe 5 og gruppe 6, ble vi enige om å begynne med å lage to felles lister for de to slavene. Dette gjorde vi for å få en god og oversiktlig plan over hvilke minneceller og dataord som ble brukt, og for å se hvilken informasjon vi måtte kommunisere mellom slavene og masterplsen. I figurene under vises listene for slave 1 og slave 2 respektivt. Figur 2 Liste over minneceller og dataord til slave 1 5

Figur 3 Liste over minneceller og dataord til slave 2 Som figurene over viser, har vi en komplett oversikt over minnecellene og dataordene som blir brukt til å sende bit-verdier og tallverdier opp og ned fra slavene. Her måtte vi også ta hensyn til at de som jobbet med InTouch-programmet fikk den samme oversikten, slik at de kunne sette opp taglisten riktig i OPC-serveren. Vi ble enige om at gruppe 5, med sin regulator fra entanktprosjektet, skulle regulere tank 1via slave 1, og at gruppe 6, med sin regulator, skulle regulere tank 2 via slave 2. Vi valgte videre å bruke masterprogrammet fra gruppe 5 som mal, og utvidet dette til å gjelde to regulatorprogrammer i hver sin slave. Dette forenklet prosessen, da vi i utgangspunktet ikke behøvde å endre på mye annet enn adressene og dataordene. Under ser vi at masterprogrammet er så å si uendret fra entankprosjektet, bortsett fra endringene som er gjort i adresseringene. I figurene som følger vises de resterende delene av masterprogrammet. Som vi ser er disse godt dokumentert gjennom kommentarfelter. Dette gjør programmet oversiktlig og lett å sette seg inn i både for gruppemedlemmene fra begge gruppene, så vel som for veiledere. 6

Figur 4 POU for slave 1 i masterprogrammet Figur 5 POU for slave 2 i masterprogrammet del 1 7

Figur 6 POU for slave 2 i masterprogrammet del 2 Sett bort ifra disse endringene i master-programmet, er det ikke gjort noen endringer i regulatorprogrammene. Disse fungerer på akkurat samme måte som i entankprosjektet, bortsett fra at de nå styrer hver sin innløpsventil til de to tankene. Den eneste vesentlige endringen som er gjort i slaveprogrammene er alarmprogrammet. Dette måtte endres slik at alarmtilstander fra begge tankene ble varslet med lyssignal fra lampen på riggen. Dette løste vi ved å endre alarmprogrammene etter mal fra gruppe 6 sitt program, slik at de ble lik for begge tankene. Deretter la vi de modifiserte alarmprogrammene i slave 1, der lampen styres fra. I bildene som følger ser vi alarmprogrammet for tank 2, og hvilke funksjoner dette har. Dette er løst på nøyaktig samme måte for tank 1 og tank 2, så det er kun tatt med bilder av det ene programmet. 8

Figur 7 Alarmprogram for tank 2 del 1 9

Figur 8 Alarmprogram for tank 2 del 2 10

Figur 9 Alarmprogram for tank 2 del 3 Vi lagde også en felles POU for alarmaksjoner, som skulle sikre at begge programmene skulle fungere sammen og parallelt med hverandre. Her har vi blant annet lagt inn timere som styrer blinkefrekvensen til alarmlampen ved de forskjellige alarmtilstandene i begge tankene. Vi har også lagt inn funksjonen med fast lys på alarmlampen ved en stående kvittert alarm. Dette programmet vises i figurene nedenfor. 11

Figur 10 POU for alarmaksjoner del 1 Figur 11 POU for alarmaksjoner del 2 12

Figur 12 POU for alarmaksjoner del 3 Figur 13 POU for alarmaksjoner del 4 Dette er en oppsummering av endringene som er gjort i PLS-programmene, og det viser at det er nesten ingen endringer på selve slaveprogrammene. God kommunikasjon mellom gruppene har bidratt til en smidig omstilling fra regulering av en tank, til regulering av begge tankene samtidig. 13

2.1.2 Sprangrespons tank1, LV1 og LT1 Tank1 skal i totankprosjektet reguleres, utgangspunkt for reguleringsparametre blir utregnet på grunnlag av FOPDT og ITAE kriteriet. Figur 14 Sprangrespons fra trendvindu i InTouch 14

2.1.3 Førsteordensapproksimasjon FOPDT (First order plus dead time) Figur 15 Prinsippskisse FOPDT Figur 16 Målepunkt for FOPDT TC =, der y er nivåendring og x er sprangendring 15

Figur 17 ITAE tabell Parametre for PI-regulator beregnet for forstyrrelser i utløp: P= 0.9828 I = 25.8456 Parametre for PI-regulator beregnet for forstyrrelser i referansen: P= 0.757 I = 15.398 16

2.1.3 Regulatorinnstillinger for tank 2 Her besluttet vi å gjøre nye utregninger for regulatorinnstillingene til tank 2. I entankprosjektet brukte vi frekvensanalyse til å finne regulatorinnstillingene, mens vi denne gang besluttet å bruke FOPDT, med ITAE-kriteriet. Her er det også interessant å se om det blir noen store differanser i resultatet i forhold til frekvensanalysen, og om resultatet blir bedre eller verre. Først tar vi utgangspunkt i denne sprangresponsen ved sprang i referansen: Figur 18 Sprangrespons på tank 2 17

Her gjør vi den samme operasjonen som i forrige avsnitt, og vi bruker FOPDT-tilnærming. Figur 19 Målepunkt for FOPDT TC = Parametere for PI-regulator beregnet ved sprang i referanse: Kp= 7.7 Ti = 4.4 Ved testing av disse parameterne, viser det seg at de fungerer bra. Både Kp og Ti er svært lik den vi regnet ut i simnotatet i entankprosjektet. Følgelig blir innsvigningsforløpet veldig bra med disse instillingene. 18

2.1.4 Hysterese Innløpsventilen LV1 på tank 1 har vist seg å være litt vanskelig å regulere på grunn av hysterese. Derfor mener vi det er viktig å skrive ett lite notat om akkurat denne problematikken. «Hysterese, det fenomen at en tilstandsendring som følge av en ytre påvirkning ikke forsvinner når påvirkningen fjernes, men først etter at en motsatt rettet påvirkning har virket med en viss styrke.» (Jakob Sandstad, https://snl.no/hysterese 06.05.2015) For ventilen betyr det at vi ikke får reaksjon umiddelbart dersom ventilpådraget endrer retning. Hysteresen i ventilen skyldes muligens variasjon i friksjonskrefter (statisk friksjon og glidefriksjon). Når ventilen står i ro vil vi få statisk friksjon som er større enn glidefriksjonen. For å få bevegelse i ventilen trengs det litt ekstra krefter (pådrag) for å overvinne den statiske friksjonskraften. Når vi tilfører tilstrekkelig kraft vil vi få bevegelse. Ettersom glidefriksjonen gir mindre motstand vil vi oppleve oversving. 19

Dette resulterer i to problemer: 1. Endringen i ventilåpning tar tid. 2. Vi får for mye pådrag, dersom retningen på ventilåpningen endres. Dette resulterer i en treg regulering av prosessen. Friksjonskreftene tror vi delvis skyldes avleiringer og slitasje i ventilen, mistanken er på grunnlag av forurenset vann og mistanke om lite vedlikehold. Figur 20 Prinsippskisse av ventil Hysteresis is normally caused by the force that appears every time the valve stem is going to be reversed, ie moved in a direction opposite to the previous direction of movement. Valve experts have described static frictional force as the amount of force needed to bend the end-fibres of the packing material in contact with the valve stem in the new direction of motion. Once the static frictional force has been overcome by energy provided by the motive power of the actuator and the stem actually starts moving, the static friction force disappears and is replaced by a sliding frictional force which is very much less than the original static friction Subsequent equal movements of the valve stem in the same direction will then generally be greater as the static friction has now disappeared, and all the energy produced in the actuator now goes directly into moving the valve stem. It only reappears again on the next valve reversal. Any deadband (mechanical play or backlash) in the mechanisms of the valve, actuator and positioner combination, adds to the hysteresis effect when reversing the valve. Hysteresis and deadband increase control variance. In the case of self regulating processes they increase the time that the controller needs to make corrections for a load disturbance or 20

setpoint change, because every time the controller has to reverse the valve, the controller has to move the PD (controller output), through the full hysteresis range before the valve will move in the opposite direction. As this movement of the PD is performed at the integral term ramp rate, which gets less and hence slower, the closer the PV gets to setpoint, it can take a very long time for the process to finally actually settle out at setpoint. (Michael Brown Control Engineering, http://www.instrumentation.co.za/regular.aspx?pklregularid=546 06.05.2015) Det går an å måle en hystereseprosent, dette gjøres ved å kjøre sprang i referansen den ene veien, f.eks fra 50% til 40% deretter fra 40%til 50% igjen. Hysteresen vil da vises som offset på aktuatoren i forhold til ventilpådraget. Prosessen må selvfølgelig gjentas for å få mer nøyaktig resultat. I følge Michael Brown Control Engineering er hysterese inntil 1% er akseptabelt, dersom hysteresen blir større må det gjøres tiltak, evt. skifte ventil. I totankprosjektet fant vi ikke tid til å gjøre disse målingene, vi fant heller ingen måte å hanskes med hysteresen på bortsett fra tiltakene nevnt tidligere. 21

2.2 IX-panel AR, TMS, JA 2.2.1 Kravspesifikasjoner Oppgaven ga noen spesifikke krav til hva som måtte være med på panelet. Kravene er vist i tabell 1. Variable Skrives Leses Referanse til tank 1 X X Referanse til tank 2 X X Manuelt pådrag til tank 1 X X Manuelt pådrag til tank 2 X X Omstilling fra manuelt pådrag til automatisk X X nivåregulering for tank 1 Omstilling fra manuelt pådrag til automatisk X X nivåregulering for tank 2 Pådrag for tank 1 X Pådrag for tank 2 X Nivå i tank 1 X Nivå i tank 2 X Melding om alarmer fra tank 1 X Melding om alarmer fra tank 2 X Kvittering av alarmer fra tank 1 X Kvittering av alarmer fra tank 2 X Start/stopp pumpe X Tabell 1 - Tabell som viser ønskede skrive- og leserrettigheter for operatørpanelet X Det er også slik at det skal være mulig å styre panelet fra webserveren. 22

2.2.2 Tags De verdiene vi ønsker å sette og lese hos PLS-ene må legges inn som tags i ix Developer. Dette gir tag listen vist i figur 21. Vi skriver direkte adressen på det minnet vi ønsker å lese/skrive til PLS-en.. Figur 21 Tagliste IX-panel I tag listen ser man også adressen og datatypen som er brukt i Master PLS-en (Melsec Q00). Dette ser du under «Contollers». Under «Tag» feltet ser man navnet på taggen internt i programmet og datatypen det skal behandles som. Når vi nå har satt opp de objektene vi ønsker å benytte på panelet må vi knytte de opp mot tiltenkte funksjoner. Vi gjør dette ved å velge hvilken tag objektet skal knyttes til og funksjonen til tagen. 23

2.2.3 Utforming og design Siden operatørpanelet er ganske lite ble det bestemt at vi skulle lage et oversiktsbilde for de to tankene, med bare den viktigste informasjonen. Om man ønsker å se med detaljert må man på menylinjen nederst på skjermen velge hvilken tilleggsinformasjon som er ønskelig. Figur 22 Oversiktsbilde operatørpanel Om du velger tank 1 på menylinja på oversiktsbildet vil du få opp dette vinduet. Hvor du har mulighet til å gjøre alle innstillinger for tank 1 samt komme deg til alarmoversikten, trendvinduet for tank 1 og hjelpe funksjonen. Figur 23 Operatørside for tank 1 IX-panel 24

Du har mulighet får å få opp et trendvindu for hver av tankene på IX-panelet. I Trendvinduet får du tegnet, pådraget, referanse og nivå. Figur 24 Trendvindu IX-panel Det er mulighet å få fram et hjelpvindu fra alle sider dette vil se slik ut: Figur 25 Hjelpvindu IX-panel 25

Det er spesifikt satt krav til hvordan alarmene skal fungere. Det er laget en alarmlampe som lyser på alle skjermer, men du må til alarmvinduet for å kunne kvittere alarmene. Det er lagt til et alarmlys for alarmer som blir kvittert i alarmtilstand som vil lyse til du er ute av tilstanden igjen. Figur 26 Alarmvindu IX-panel 26

2.3 InTouch Når begge tankene skulle styres ble det laget ett nytt grensesnitt i intouch, bestående av de beste elementene fra begge gruppene. Figurer for tanker, ventiler og lignende kommer fra gruppe 5, mens felt for regulatorinnstillinger ble hentet fra gruppe 6. Virkemåte er stort sett lik som i gruppe 5 sitt entankprosjekt. På samme måte som i entankprosjektet skal det også være mulighet for å logge inn som tre forskjellige operatører, som har forskjellig grad av mulighet for styring av de forskjellige parameterne. Se entankrapport for mer detaljert informasjon om resirkulerte funksjoner. Grensesnittet inneholder nå også mulighet for å aktivere bonusoppgaver. Gruppe 5 har laget kameraovervåkning, som finnes i hovedmenyen. Gruppe 6 har laget autotuning av sin regulator, som regulerer tank 2, denne aktiveres fra vinduet for regulatorinnstillinger. For å få frem all informasjon så ryddig og oversiktlig som mulig fant vi ut at vi skulle benytte oss av begge skjermene vi hadde til rådighet. Vi endte opp med selve prosessen og menyen på den ene, og grafer og alarmliste på den andre. Ved starten av totank prosjektet måtte det lages et nytt brukergrensesnitt, det skulle utvides til to tanker istedenfor en. Vi slo sammen noen fra hver gruppe og plukket ut det beste fra begge prosjekter, som vi satte sammen til et nytt brukergrensesnitt med to tanker. I InTouch er det laget et passende brukergrensesnitt som skal simulere prosessen som skjer på tankriggen. Det er satt opp et hovedvindu og flere «undervinduer» som skal åpnes etter hvilken knapp en trykker på. Hovedvinduet inneholder pumpa, to ventiler, to tanker, tre magnetventiler på utgangen av tank nummer 2, en ventil under tank nummer 1, foroverkobling, nivåmålere, flowmåler, et trendvindu som grafisk viser nivået for hver av de to tankene, referansen i tankene og ventilpådraget, en liste over alarmer, en meny med knapper som åpner forskjellige vinduer. Øverst til høyre i vinduet på den ene skjermen kan operatøren se hvem som er logget inn, et display med tid og dato og en knapp for å logge ut. 27

Figur 27 Hovedvindu I figuren vises hovedvinduet av brukergrensesnittet hvor en har mulighet til å kontrollere prosessen. I hovedvinduet kan man klikke seg inn på forskjellige ruter for å endre parametere, som referanse, Kp, Ti, valg mellom P-regulator og PI-regulator og valg mellom direkte og reversert regulering. I figuren ser vi tankene fra hovedvinduet. Her kan vi se at det er nivået i tankene som vises i de blå søylene til venstre i tankene. Når InTouch kobles opp mot OPC Beijer og tankriggen, vil dette nivået følge det reelle nivået i tanken. Nivået vil være ganske nøyaktig det samme vist i InTouch som det er i tanken. Den røde streken som vises i figuren er referansen satt i InTouch eller i IX-panelet. Det er satt inn to slidere, i form av trekantene som inneholder en prosentverdi som viser prosentverdien for referansen satt i tankene. For brukeren med mest tilgang vil sliderene være funksjonell og det vil da være mulig å endre referansen ved hjelp av denne, uten å måtte klikke seg inn på parametervinduene. 28

Figur 28 Trends i hovedvindu I hovedvinduet er det vist tre trendvinduer. Her kan vi lese og ha full kontroll på hvordan prosessene i tankene fungerer. Den røde linjen er for referansen, den blå er for nivået i tanken og den grønne linjen er for ventilpådraget. Her kan vi se hvordan prosessene oppfører seg over en gitt tidsperiode. På x-aksen vises trendvinduet over de siste 2 minuttene, dette gjør da at hver av de fire rutene som vises i figuren tilsvarer 30 sekunder. Det er laget et eget vindu som heter Trends 1 og Trends 2 der en kan se prosessene for de to tankene over de siste 10 minuttene. Figur 29 Parameterknapper 29

For å endre parameterne til prosessen er det opprettet to knapper i hovedvinduet for hver av de to tankene, som åpner et nytt vindu der en kan velge de forskjellige verdiene for Kp, Ti og lignende. Her har det i totank delen blitt laget to identiske knapper for parameterinnstillingene. De er blitt navngitt som LIC1 og LIC2. Disse knappene fungerer som forklart i entankrapporten, for gruppe 5, på side 69. Figur 30 Innlogging I InTouch er det laget et verktøy for innlogging, hvor forskjellige brukere har tilgang til å sette og lese for eksempel om regulatoren står i P- eller PI-regulering. Dette gjelder for begge parameterknappene. I figuren kan vi klikke på knappene for parametere for så å komme inn til valg av parametere. Man kan her lese hvilken tilstand regulatoren står i, altså om regulatoren står i P- eller PI-regulering og om den står i auto eller manuell. Inne i parametervinduene kan en av operatørene endre på om regulatoren skal stå i P- eller PIregulering og to av operatørene kan velge om regulatoren skal stå i manuell eller auto regulering. I figuren kan også operatørene lese referansen og pådraget i tankene under reguleringen. 30

Figur 31 Parametervinduer I figuren ser vi vinduene for parameterinnstillinger. Her kan vi sette parameterne for regulatorene. Når dette bilde vises kan vi se at det er flere knapper i vinduene. Her kan vi velge at regulatorene skal ha direkte eller reversert regulering. På dette bilde ser vi at begge regulatorene står i auto med PI-regulering. Måten dette er satt opp på er forklart i entankrapporten, for gruppe 5, på side 77. Figur 32 Manuellparametere Dette er vinduet for manuellparametere. Her kan vi se de parameterne som kan endres når regulatorene står i manuell. Ved å sette regulatorene i manuell kan en styre ventilene manuelt slik at testing av reguleringen kan enklere gjennomføres. Ved å trykke knappen som heter Auto vil en sette regulatoren tilbake til automatisk regulering. Når regulatorene går fra manuell til auto vil regulatorene gå til den tidligere tilstanden den hadde før manuellregulering ble valgt. Det er laget en funksjon i PLSen som gjør dette mulig. 31

Scriptene i det nye brukergrensesnittet er litt endret, som for eksempel for parametervinduene. Da vi slo oss sammen med gruppe 6 fant vi ut at de hadde multiplisert verdiene av Kp og Ti på en enklere måte. Så vi valgte derfor å bruke deres måte. Hvor de ikke brukte script, men endret dette direkte i tagen. Dette er vist i figuren under. For foroverkoblingen ble vi enig i å bruke det som ble gjort for gruppe 5 i entankrapporten. Dette er knappen for foroverkobling. Denne fungerer som en knapp i likhet med parameterknappen. Her er det også mulig å lese verdiene for Kp_FF og TD_FF. Ved å trykke på denne knappen blir man sendt videre til vinduet for foroverkobling. Figur 33 Foroverkoblingsknapp Figur 34 Foroverkoblingsparametere 32

Her er det muligheter for å aktivere foroverkobling. Dette er kun mulig for den ene tanken, det er for tank to. Ved å klikke på de forskjellige knappene for regulering nede til venstre i figuren, settes den type foroverkobling som velges. Her gjelder det samme for sending av disse verdiene som i parametervinduet. Det sendes pulser ned til PLSen som sender tilbakemelding om type valgt foroverkobling. På dette bildet er det valgt foroverkobling av typen Dff regulering. Her kan du også endre parameterne i den øvre delen av vinduet. Foroverkoblingen vil bli deaktivert enten ved å trykke på All Off knappen nede til venstre i figuren og ved å velge P- eller PI-regulering. Det skal lages historiske trender slik at operatøren som nå logger seg inn på neste skift kan se hvordan det har gått de siste 10 minuttene i de to tankene. Her vil man kunne se om det har vært noen endringer i sprang eller forskjell i nivåene. Det er fullt mulig å endre hvor langt tilbake man ønsker å se. Dette gjøres ved å trykke på trendvinduet. Det vil da åpne seg en meny. Under Chart Lengths kan man velge hvor langt tilbake man kan se i trendvinduene. Det er laget et trendvindu for hver av tankene. I hovedvinduet ser vi at det er to knapper som henholdsvis heter Trends 1 og Trends 2, det er disse man trykker på for å få åpnet vinduene for trendvisningen. Det er også mulighet for å lagre trendvinduet. Dette gjøres ved å trykke nederst på vinduet der det står save to file. Hvis man ønsker å benytte en annen lagringsplass enn det som er oppgitt kan man trykke på Filename og sende filen dit man ønsker. I figurene under vises de to historiske trendene, Historisk trend1 og Historisk trend2. Figur 35 Historisk trend 1 33

Figur 36 Historisk trend 2 2.3.1 Sending av verdier For at tankene skal fungere på en uforstyrret måte fra entankprosjektet sammen med bonusoppgaven har vi valgt Sending av verdier ned til PLS-ene foregår på forskjellige måter fra tank-1 og tank-2. Dette er fordi at ved noen tilfeller ønsker vi kun å sende pulser og ved andre tilfeller ønsker vi å sende faste verdier. Ved for eksempel setting av tanken bruker vi funksjonen toggle som sender verdien TRUE eller FALSE konstant. Ved andre tilfeller sender vi en puls som setter verdien høy en gang, ellers holder den seg lav. Dette gjøres ved for eksempel om tanken skal stå som P- eller PI-regulator. Figur 37 Pulssending av verdier. sender høy verdi en gang 34

Ved at vi sender pulser ned til PLS-en trenger vi også en tilbakemelding fra slave-enhetene som bekrefter at verdien har blitt satt. Dermed har vi en tag som sender verdier ned til PLSene og en verdi som mottar fra PLS-ene inn til InTouch. Ved å sende verdier på denne måten får vi en bekreftelse på at verdien har faktisk blitt satt i slave-pls-ene. Dermed har vi full kontroll på tilstanden til riggen. 2.3.2 IP Kamera Når det gjelder bonusoppgaven har vi satt opp et IP kamera som skal vises både på nettsiden og i InTouch. (For oppsett av selve IP kamera se kapittel 2.4). For oppsett av IP kamera i InTouch har vi valgt å sette det inn i et nytt vindu som er tilgengelig fra Hovedvinduet. I dette vinduet krever InTouch at vi setter inn en ekstra ActiveX kontroll som kan åpne nettleseren til IP kamera. Før vi kan sette inn IP kamera krever InTouch at vi installerer en nettleser som kan åpne programmet til IP kameraet. Først må vi klikke inn på Special / Configure / Wizard/ActiveX Installation. Velg så ActiveX Control Installtion tabben øverst. Under menyen Available ActiveX controls blar vi oss ned til Microsoft Web Browser og trykker Install. Microsoft Web Browser skal nå være i menyen Installed ActiveX controls. Vi har nå muligheten til en nettleser i InTouch. Denne ligger inne på wizard selection / activex Controls / Explorer. Denne setter vi i det vinduet vi ønsker å ha IP kameraet vårt. 35

Figur 38 Visning av IP kamera i InTouch Det eneste som mangler for å få nettsiden til IP kameraet er vinduscriptet til IP kamera. I script vinduet trykker du på insert / ActiveX velg Explorer1 og navigate. I parantesen setter settes adressen til IP kameraet som vist på figuren under. Oppsettet er nå ferdig og skal ha tilgang til å se og styre IP kamera fra InTouch. Figur 39 Scriptet til IP kamera i Intouch 36

2.3.3 Alarmer Alarmer er en advarsel at en prosess har oversteget sin normaltilstand og krever operatørens oppmerksomhet og handling. En alarm skal bli satt når en prosessverdi overstiger den brukerdefinerte grensen. I vårt tilfelle er det to krav til alarmer. Det skal være en avviksalarm og to grensealarmer. Det skal gå en alarm dersom nivået avviker mer enn 25% fra referansen (25% av totalt måleområde.) Grensealarmer skal aktiveres dersom nivået i tanken overstiger 90% eller går under 10%. 2.3.4 Definering av alarmer For at vi skal lettere gjenkjenne alarmene kan vi definere de forskjellige alarmtypene. ved kritisk alarm har vi to forskjellige alarmer. En når alarmen kritisk høy og kritisk lav. For å se forskjell på disse kan vi sette alarmtilstand kritisk_hh når nivået i tanken når 90%, Kritisk_LL når nivået er under 10% og kritisk_avvik når avviket overstiger med 25% i forhold til referansen. Det er også satt opp noen ekstra alarmer utenom kravet til oppgaven og disse blir definert ved busfeil, strømbrudd, lavt_batteri osv. Se Tabellen under for å se den fulle alarmoversikten Tabell 1 alarmliste i InTouch ALARM ADRESSE ALARMVERDI FORKLARING ALARM_LAV_T2 M54 10 Kritisk lavt nivå i tank 2, mindre enn 10% ALARM_HOY_T2 M53 90 Kritisk høyt nivå i tank 2, større enn 90% ALARM_AVVIK_T2 M55 25 Nivå avvik større enn 25% fra referansen i tank 2 ALARM_AVVIK_T1 M52 25 Nivå avvik større enn 25% fra referansen i tank 1 ALARM_LAV_T1 M51 10 Kritisk lavt nivå i tank 1, mindre enn 10% ALARM_HOY_T1 M50 90 Kritisk høyt nivå i tank 1, større enn 90% Busfeil M0 TRUE (1) Mistet tilkobling til slave 1 og 2 Lav_batteri_QPLS M1 TRUE (1) Lavt batteri i Q-PLS Kritisk_lavt_QPLS M2 TRUE (1) Kritisk lavt batteri i Q-PLS 37

2.3.5 Sikkerhet Det skal lages et vindu der operatøren må logge seg inn med eget brukernavn og passord. Til programmet vi bruker er det opprettet tre brukernavn OPERATØR1, OPERATØR2 og OPERATØR3 der operatør 3 har alle rettigheter mens de to andre operatørene har mer begrenset rettighet. Passordene til de forskjellige brukerne er Op1, Op2 og Op3. For opretting av brukere se side 84 på entankprosjektet til gruppe 5. Tabell 2 Tabelloversikt av de tre brukerne, passord og tilgangsnivå User name Password Access Level OPERATØR1 Op1 1000 OPERATØR2 Op2 3000 OPERATØR3 Op3 9000 For en bedre beskrivelse av innloggingssiden se side 86 av entankprosjektet til gruppe 5. 38

2.3.6 Access Level Før vi oppretter brukerkontoer må vi bestemme hva slags sikkerhet vi ønsker å bruke. InTouch har muligheten til å begrense tilgangen til innloggede brukere avhengig av hvilket tilgangsnivå de har. Dette er mellom 0 9999, hvor 0 er lavest og 9999 er høyest (tilgang til alt.) Tilgangsnivået er taggen som brukes til å sikre InTouch applikasjonene. Det er hovedsystemet som en bruker kan eller kan ikke gjøre i Runtime. For eksempel kan ikke vil vi ikke at OPERATØR1 skal se et objekt kan vi skrive følgende i en Visibility link, $AccessLevel >=3000. Nå vil kun brukere med Access level lik 3000 eller høyere få tilgang til dette objektet. I vårt tilfelle blir det da OP2 og OP3. For en full oversikt av hvem som har tilgang til hva i InTouch se vedlegg nr. 1. Figurene under er et eksempel på hvordan parametervinduet vil se ut for de tre operatørene. Figur 40 - Parametervising for OP2 og 3 Figur 41 Parametervising for OP1 For en mer utfyllende beskrivelse av tilgangsnivåene se side 85 på entankprosjektet til gruppe 5. 39

40

2.4 Bonusprosjekt gruppe 5 IP-Kamera AR Som en bonusoppgave i dette prosjektet har vi mulighet til å ta i bruk et IP-kamera som kan fjernstyres over internett. Teknisk info: SONY RZ30P 25 x optisk zoom 340 graders rotering Innebygd webserver for fjernstyring 10/100 MBs ethernet-tilkobling. Sony-RZ30P IP-kamera Figur 42 IP-kamera Kameraet er bygd inn i hjemmesiden til prosjektet i tillegg til at det ble benyttet som en del av brukergrensesnittet i InTouch. 2.4.1 Oppsett: Kameraet er tilkoblet nettverket via den trådløse routeren. Ved første gangs tilkobling vil kameraet automatisk få en IP-adresse. Denne kan man finne ved å logge inn på routeren og se tilkoblete klienter. 41

Man kan koble til kamera ved hjelp av IP-kamera programvare eller man kan bruke en nettleser. Man vil da få valget mellom flere typer viewer hvor kompatibiliteten avhenger av typen nettleser og datamaskinen man bruker. Under ser vi Java-viewer i bruk. Man kan kontrollere kameraet ved bruk av panelet ved siden av. Figur 43 Webkameragrensesnitt i nettleser 42

For at man skal kunne nå kameraet over internett, må vi sette en port til kameraet som må portforwardes. Standardporten til kameraet er 80. Det er denne vi må endre. Figur 44 Innstilling av HTTP-port i webkamera Man finner innstillingene i Settings Network. Over ser vi at HTTP porten er endret til 3333. I routeren er det lagt opp slik at man finner kameraet over internett ved å skrive http://158.38.53.139:3333 i en nettleser. 43

2.5 Bonusprosjekt gruppe 6 Autotuning 2.5.1 PLS-kode SBD Bonusoppgaven vår går ut på å lage ei autotuning for regulatoren vår. Autotuning fungerer som en av- og på-regulator, hvor verdier fra svingningene måles, og deretter benyttes disse til å komme med et forslag til Kp og Ti parametere som vil gi et gunstig innsvingningsforløp. En av og på regulator skal gi maks pådrag dersom prosessverdien er under referansen, og minimum pådrag dersom prosessverdien er over referansen. I vår regulator blir dette 255 dersom prosessverdien er under referansen, og 0 dersom prosessverdien er over referansen. Programmet sjekker for dette ved å se på fortegnet på avviket. Dersom avviket er positivt er prosessverdien under referansen, og dersom det er negativt er prosessverdien over referansen. I tillegg til dette ønsker vi måling på periodetid, topp- og bunnpunkt. Vi finner toppunkt med å sammenligne aktuelt nivå med forrige nivå. Dersom forrige nivå er høyere enn aktuelt nivå, og nivået er over referansen, er det forrige nivået et toppunkt. Dersom det forrige nivået er lavere enn det aktuelle nivået, og nivået ligger under referansen, er det forrige nivået et bunnpunkt. Dette gjelder bare en gang hver halvperiode, ettersom nivået vil være stigende eller synkende etter bunn- og toppunktet. Periodetiden måles ved å telle opp hvert 0.1 sekund. Dette gir 10*periodetid, men vi bruker denne for ei mer nøyaktig måling. Figur 45 Samlig av måleverdier for svigningene (autotuning) 44

Periodetiden, og begge de benyttede tellerne må nullstilles ved hver nye periode. I dette programmet har vi valgt å definere en periode til hver gang prosessverdien kommer over referansen, til neste gang prosessverdien kommer over referansen. Det sendes derfor en puls som markerer ny periode hver gang avviket går fra positivt til negativt. Ved samme tidspunkt skal antall perioder som har gått telles opp. Figur 46 Start av ny periode for svigninger 45

Programmet skal regne ut parametere basert på verdier fra stående svingninger. Vi kan finne stående svingninger ved å sammenligne aktuelle verdier for periodetid, topp- og bunnpunkt, med de forrige verdiene. Dersom aktuelle verdier og forrige verdier er like, har vi oppnådd stående svingninger, og det er på tide å starte utregningen. Figur 47 Sammeligner forrje verdi med nåverdi for å se om det er stående svigninger Ettersom vi kun sampler data ved visse samplingsintervall, blir denne sammenligningen unøyaktig. Sammenligningen må være nøyaktig på bit-verdier, og vi risikerer da at programmet aldri finner punktet med stående svingninger. Programmet vil da aldri gå inn i utregningsdelen. Vi har derfor valgt en annen løsning for å gå rundt dette. Vi bruker da variabelen som teller antall perioder, og setter ei grense på hvor mange perioder som skal kjøres før programmet starter utregningen. Vi kunne satt denne grensen til hva som helst, men vi gjør et anslag og antar at vi har oppnådd stående svingninger etter 7 perioder. Erfaring fra tidligere forsøk vi har gjort med autotuning viser at systemet skal være godt innenfor stående svingninger i løpet av 7 perioder. 46

Figur 48 Sjekker om det har gått 7 perioder siden start av autotuning 47

Vi ønsker også å se hvor stor fremgang autotuningen har, altså hvor mange prosent ferdig den er. Dette kjører en sammenligning på antall perioder som har kjørt, og antall perioder som skal kjøres, og svarer skrives ut som et tall i prosent, 0-100. Figur 49 Måler hvor langt autotuning har kommet Etter dette skrives de 16-bits målte verdiene over til 32-bits dataord på samme måte som i entankprosjektet figur 16. Deretter benyttes algoritmene for utregning av kritisk forsterkning (Kk) og kritisk periodetid (Tk).. I vårt system er topp-til-bunn for pådrag en konstant. Og vi kan da sette telleren som en konstant. Ettersom programmet ikke takler desimaltall må vi benytte 127 istedenfor 1.27. Konstanten blir da 32385.. Vi benytter deretter Ziegler-Nichols tabell for å finne forslag til Kp og Ti. Ettersom autotuning er en metode som er beregnet på PID-regulatorer, blir det unøyaktig å benytte Ziegler-Nichols tabell for PI-regulator. Det blir da mer nøyaktig å stille inn regulatoren som om vi skulle hatt en D-del, men D-delen settes lik 0. Vi får da algoritmene og. Figur 50 Regner ut Kp og Ti utfra målte verdier på Kk og Tk 48

De 32-bits dataordene skrives deretter over til 16-bits dataord, på samme måte som i entankprosjektet figur 19. Etter utregningene er ferdige skal funksjonsblokken gi et signal om at autotuningen er ferdig. Dette gjøres enkelt ved at variabelen for at programmet er ferdig er avhengig av samme variabel som utregningene, og skal ligge etter utregningene i koden. Figur 51 Sender et signal for når autotuningen er ferdig Til slutt må denne funksjonsblokken inkluderes i resten av programmet. Dette ved at vi kaller på funksjonsblokken som en lokal variabel i en POU, og funksjonsblokken legges til med de parameterne vi skal bruke. Start av autotuningen skal kunne styre fra master, og autotuningen skal skru av seg selv når den har kjørt ferdig. Veriden på minnecelle M50 styres fra master, og denne får en positiv puls når autotuning aktiveres. Ettersom vi ønsker at autotuningen skal kjøre av seg selv etter dette, skal variabelen for autotuning bli satt høy helt til den blir nullstilt. Dersom autotuningen skal avbrytes mens den kjøres, settes M51 høy fra master, og variabelen for kjøring av autotuning avsluttes. Denne variabelen skal også nullstilles når programmet har kjørt ferdig. Figur 52 Viser hvordan autotuningen kjøres 49

For at autotuningen ikke skal få problemer dersom den startes mens regulatoren står som manuell regulator, må regulatortypen endres dersom autotuningen skal starte. Dette er fordi referansen settes lik prosessverdi dersom manuell modus er valgt, og vi kan da ikke kjøre utregninger med avviket. En enkel nullstillingsfunksjon settes da i starten av POUen for manuell modus. Ettersom POUen for autotuning ligger etter POUen for manuell modus, skal manuell modus kobles ut av samme knapp som autotuningen aktiveres, eller dersom autotuning allerede ligger aktiv. Figur 53 Sørger for at pådraget står i manuell under autotuning 50

2.5.2 Betjening av autotuning i intouch KS Autotuninga betjenes fra et helt eget, lite og enkelt vindu. For å få frem dette må du først åpne vinduet for regulatoren, der er det nå lagt til en egen knapp. Figur 54 Viser hvordan du velger autotuning i InTouch Nå har du to valg, enten kan du starte autotuninga, eller du kan lukke vinduet igjen. Figur 55 Viser hvordan forslaget til instillinger kommer ut Vi ville at det skulle vises en indikering på hvor lenge det er igjen til autotuninga er ferdig, så det ble lagt til en utgang fra PLS som brukes til å bestemme om vinduet skal vise verdiene regulatoren har regnet ut, eller om det skal be deg om å vente. Når du trykker «start» blir denne høy, og det vises en strek som blir grønn fra venstre mot høyre sammen med et tall som oppgir antall prosent, i henhold til verdien «Framgang» i PLS programmet. 51 Figur 56 Viser status på autotuningen

3 Prosjektstyring gruppe 5 3.1 Deltagere 52

3.2 Tidsbruk KR Her har vi timebruken gjennom hele prosjektet. Ser at vi ligger noe under helt til etter påske. Fra påske ligger vi akkurat på estimert tidsbruk. Ser også at vi ligger en del timer under etter uke 16. Vi begynte å få god kontroll på Entankprosjektet, og det var rapportskriving som var i fokus. Mener vi har estimer tidsforbruket ganske bra. 53

3.3 Prosjektstyring og samarbeid AR & KR Den 25/2 fikk vi utlevert prosjektoppgaven i faget «Styresystemer». Under løsning av prosjektet jobbet vi sammen i grupper, der to grupper skulle dele på én rigg. Det var da viktig å lage en plan på hvilken gruppe som skulle få jobbe med riggen, inndelingen ble annenhver dag. Dette fungerte veldig bra, med tanke på at vi ikke trengte stresse med å bli ferdig med riggen i tide. Et suksesskriterie for å løse oppgaven på en god og effektiv måte er godt samarbeid. Det første vi gjorde var å få opprette et felles plan på «Its Learning» som vi kalte «Prosjekt 2015». Her strukturerte vi prosjektet i de delprosjektene som hele prosjektet bestod av. Vi hadde også et system på hva vi skulle gjøre når vi la ut det vi hadde jobbet med på» Its Learning». Det var viktig at ved redigering av noe som var lagt ut fikk kommentarer på hvem som hadde redigert og når. På denne måten hadde vi hele tiden god kontroll på siste gjeldene versjon. Under arbeid av hvert enkelt delprosjekt hadde vi internmøter som gruppeleder hadde ansvar for. Dette gjorde vi for å oppdatere hver enkelt i gruppen på framgangen i arbeidspakkene vi jobbet med. På denne måten sørget vi for at vi jobbet mot samme mål slik at sammensying av hver enkelt arbeidspakke gikk greit for seg. De to første delprosjektene, Forprosjektet og Miniprosjektet gikk veldig greit. Disse delprosjektene var ganske små og i tillegg var de ikke så kompliserte. De største utfordringene kom under Entankprosjektet, som var det største delprosjektet. Her delte vi gruppen i tre par der hvert enkel par hadde sin arbeidspakke, InTouch og ix-panel, PLS og Filter. Selve arbeidet med arbeidspakkene gikk veldig greit. De som jobbet med InTouch og PLS prøvde å jobbe parallelt, men det viste seg å være vanskelig. Grunnen til dette kan være at vi ikke hadde noe felles mål på hvordan vi ønsket at det hele skulle fungere sammen, noe som vi burde gjort under internmøtet. Dette resulterte i at vi hele tiden måtte gjøre endringer for å tilpasse oss hverandre, noe som førte til at vi brukte mye unødig tid. Under arbeidet fant vi til slutt ut av dette og satte oss ned for å bli enige på hvordan det skulle fungere sammen. Vi ble til slutt veldig fornøyde med resultatet. 54

4 Prosjektstyring gruppe 6 4.1 Deltagere Stian Berg Dyrnes SBD Emil Welde Hatletveit EWH Kristian Strøm KS Terje Magnus Sørensen TMS Snorre Vongraven - SV Andreas Haugen AH Dato 07.04.2015 55

4.2 Tidsbruk TMS Vi ligger noe under det planlagte fordi det tok mye kortere tid å konstruere filteret enn planlagt, vi nærmer oss den planlagte verdien igjen grunnen til dette er at det var noe mer arbeid med samkjøring av programmene under totankprosjektet enn vi gjettet under forprosjektet. Vi la også inn litt færre timer på slutten slik at vi hadde mer tid til rådighet om vi lå litt bak skjema. Det må sies at vi har estimert bra, når vi kun fikk et avvik på ca 60 timer under hele prosjektarbeidet. 1800 1600 1400 1200 1000 800 600 400 200 Tidsbruk 0 8 9 10 11 12 13 14 15 16 17 18 19 Planlagte timer Utført arbeid 4.3 Prosjektstyring og kvalitetssikring SV Prosjektet skal til enhver tid ha en leder. Lederen byttes hver uke, og ved prosjektets slutt skal hver enkelt gruppedeltaker ha fått prøvd seg i jobben. Lederen er ansvarlig for møteinnkalling, saksliste og gjennomføring av det ukentlige møtet. Han vil også være ansvarlig for prosjektets framgang, og tidsfrister. 4.3.1 Statusrapportering Møteleder skal vær uke fremlegge en statusrapport, som skal gjennomgås på prosjektmøtet. Møteinnkallelser, møtereferat og annen relevant dokumentasjon lastes opp til felles dropbox-mappe. 56

4.3.2 Standardiserte skjemaer Gruppen skal bruke standardiserte skjemaer for møteinnkalling, møtereferat, og arbeidspakkeskjema. Disse ligger tilgjengelig på It s Learning under faget «TELE2008-A 15V Styresystemer og reguleringsteknikk». 4.3.3 Versjonskontroll Dokumenter og filer som blir produsert i forbindelse med prosjektet blir lagret i en felles Dropbox-mappe. Filene skal ha beskrivende navn, og inneholde versjonsnummer eller dato. 4.3.4 Tester og sjekklister Programmer og sjekklister skal sammenlignes mot mål og spesifikasjoner nevnt i forprosjektrapporten. Eventuelle avvik skal dokumenteres og rettes. 57

4.4 Prosjektstyring og samarbeid SV & KS Rett etter vi fikk utlevert oppgaveteksten 25/2 satte gruppe 6 seg ned og leste gjennom hele teksten grundig. Vi diskuterte ting som virket uklare, og lagde oss en teori om hvordan prosjektet skulle utføres. I løpet av forprosjektet lagde vi også en plan for hvem som skulle ha hovedansvaret for de forskjellige prosjektdelene. For å forenkle arbeidet med fildeling og kommunikasjon ble det raskt opprettet flere grupper på internett. Filer som ble delt innad i gruppen skulle legges ut på nettskytjenesten dropbox, med fornuftige navn som gir informasjon om datoen den ble laget, og hva filen inneholder. Inne i gruppe 6 sin mappe på dropbox ble det opprettet flere undermapper til hver prosjektdel, bilder og lignende. For å forenkle kommunikasjon oss imellom lagde vi en gruppe på nettsamfunnet facebook. Den bruker vi til å holde en generell oversikt over framgangen og hvor lang de forskjellige medlemmene har kommet. I tillegg til dette ble det opprettet en katalog på undervisningsnettstedet itslearning for deling av rapporter, møteinnkallinger og lignende mellom gruppen og veileder. Gruppe 5 og 6 har sammen en rigg til rådighet i prosjektet. Vi måtte da finne en ordning for hvem som skulle har riggen til enhver tid. Det ble bestemt at vi skulle ha riggen annenhver dag. Dette har fungert utmerket hele prosjektet igjennom. For å holde oversikt over adressene vi brukte i entank satte vi opp et Excel-dokument med en tabell (se vedlegg 9 i entankrapport) over alle adressene vi skulle bruke i master, slave 1, slave 2, samt hvilken retning informasjonen flyter og hva de ble brukt til. Slik kunne vi jobbe med hver vår oppgave uten å behøve å mase konstant på hverandre, samtidig som at sjansen for å få problemer med samkjøring blir minst mulig. På tross av at vår veileder ikke har fast kontor på bygget, og at de resterende veilederne ikke er å finne på campus hele uken, føler vi at veiledningen har vært tilstrekkelig. Vi har hele vegen selv måtte oppsøke hjelp når det er behøvelig, og tror dette har lagt grunnlaget for et godt samarbeide innad, og i mellom gruppene. «Å lære ved å gjøre» har vært en gjennomgående filosofi i prosjektets gang, og gruppens hoder har ofte måtte ta tak i problemer med samlet kraft. Vi sitter nå igjen med en dyptgående forståelse av prosjektet i sin helhet. 58