Entanksprosjektrapport Prosjektoppgave i faget Styresystemer og ...

Entanksprosjektrapport
Prosjektoppgave i faget
Styresystemer og Reguleringsteknikk
Pumpe
2EA
Vår 2013
Reguleringsventil
Vanntank
Magnetventilene
FT1
Vannreservoar
100 %
60 %
50 %
0 %
LT1
ref.

HØGSKOLEN I SØR-TRØNDELAG
Avdeling for teknologi
Studieprogram for elektro- og datateknikk
7004 TRONDHEIM
Prosjektoppgave i Styresystemer og Reguleringsteknikk,
Oppgavens tittel:
Prosjektoppgave i faget Styresystemer og
reguleringsteknikk
Gruppedeltagere:
Entanksprosjekt
Jostein S. Helland(JSH) 93030878
josteish@stud.hist.no
Bendik Mydland(BM) 99223347
bendikm@stud.hist.no
Olav Gabrielsen(OG) 93412152
olavgab@stud.hist.no
Erlend V. Ekren(EVE) 41767127
erlendek@stud.hist.no
Thomas I. Berge(TIB) 97425260
thomasib@stud.hist.no
Fredrik Sørvig(FS)
Studieretning:
48036012
fredrso@stud.hist.no
Oppdragsgiver:
Automatiseringsteknikk
Avdeling for Teknologi v/Per Hveem
Startdato:
27.03.13
Innleveringsdato:
01.05.13
Antall sider/vedlegg:
218/63
Veileder:
Per Hveem
Tlf: 73559593
E-post: per.hveem@hist.no
Prosjektgruppe:
1
Kontaktperson hos
oppdragsgiver:
Se veileder

Sammendrag
I følgende rapport dokumenteres entanksprosjektet til prosjektet «Prosjekt i faget
styresystemer» utført av studenter ved bachelorprogram Automatiseringsteknikk på
Høgskolen i Sør-Trøndelag. Det gjennomføres ett lignende prosjekt hver vår på
andre halvår ved denne linjen, og denne gangen omhandler det en reguleringssløyfe
som skal styre nivået i to forskjellige tanker på en tankrigg.
Ved linjen Automatiseringsteknikk blir studentene tidlig introdusert til nivåregulering i
tanker, som gjør dette til en naturlig oppgave.
Prosjektets formål er å gi trening i å gjennomføre større prosjekter for
prosjektdeltagerne.
Oppgaven består i å styre nivået i et totankssystem. I det inngår modellering og
simulering av tankene, programmering av en logisk sekvens for styring og regulering
av disse, samt programmering av brukergrensesnitt på flere plattformer og
kommunikasjon de imellom.
Denne rapporten omhandler hvordan gruppen gikk frem for å styre og regulere nivået
i en tank.
Dette innebærer utvikling av brukergrensesnitt på PC, operatørpanel og hjemmeside
samt utvikling av en teoretisk modell for den fysiske prosessen slik at gode
simuleringer kan gjøres. Kommunikasjonen mellom PC, operatørpanel, hjemmeside,
web-kamera, master-PLS, slave-PLS, Profibusnettverk og ethernet utvikles slik at
prosessen får en utmerket brukervennlighet og funksjonalitet.
Reguleringen av nivået er optimalisert ved hjelp av finregning og fintuning. Dette
sammen med et brukervennlig brukergrensesnitt, som gir nødvendig og oversiktlig
informasjon, er et bra verktøy for operatøren når væskenivået i tanken skal holdes
stabilt.
BM, FS, OG

Forord
Entanksprosjekt-rapporten er en rapport som omhandler hvordan gruppen gikk frem
for å lage program og HMI for styring og regulering av tank. Dette er den mest viktige
oppgaven i prosjektet på grunn av at studentene får gjennomført prosjektets formål
med å styre og regulere tanken.
Etter at gruppen hadde levert inn miniprosjektrapporten til arbeidsgiver, tok gruppen
fatt på å modellere prosessen i Simulink, lage program i PLS og program for HMI. De
har også beregnet filter for filtrering av støyen i nivået i tanken og støyen fra
magnetventilene.
Vi har fått nye utfordringer og sett oss inn i nye problemstillinger. Dette er noe hele
gruppen har sett frem til på grunn av at vi i større grad skal kunne få bruk for teoretisk
kunnskap fra forelesningene til praktiske løsninger i prosjektet. Oppgavene ble delt ut
slik at vi jobbet to og to sammen på hver arbeidspakke. Det endelige resultatet kan
leses om i rapporten. Resultatet av modellering og simulering av prosessen er tatt
med som vedlegg for entankrapporten.
Som mål, har gruppen satt at de vil overbevise arbeidsgiver til at de er de rette til å
gjøre denne jobben, og lage en god prosjektrapport innen alle «del-prosjektene».
Til slutt vil gruppen fortsatt takke Per Hveem og Andreas Sørvik fra HiST for
veiledning gjennom prosjekttiden. Gjennom prosjektmøte, og gode praktiske tips, har
de begge vært til god hjelp. Gruppen ser frem til videre samarbeid med begge videre
i totanksprosjektet.
Bendik
Mydland
TIB
Erlend V.
Ekren
Fredrik
Sørvig
Jostein S.
Helland
Thomas I.
Berge
Olav
Gabrielsen

1 Innholdsliste
1 Innholdsliste ......................................................................................................... 1
2 Figurliste. ............................................................................................................. 2
3 Tabelliste. ............................................................................................................. 6
4 Vedleggsliste. ....................................................................................................... 7
5 Innledning. ........................................................................................................... 8
5.1 Bakgrunn: ...................................................................................................... 8
5.2 Oppgavetekst: ............................................................................................... 9
5.3 Definisjoner: ................................................................................................ 10
6 Teknisk del. ........................................................................................................ 11
6.1 Problemstilling: ............................................................................................ 11
6.2 Prosjektmål .................................................................................................. 12
6.3 Prosjektbeskrivelse: ..................................................................................... 13
6.4 Spesifikasjoner ............................................................................................ 14
6.5 Filterberegninger og konstruksjon ............................................................... 22
6.6 PLS. ............................................................................................................. 36
6.7 PID-regulator: .............................................................................................. 63
6.8 iX-panelet. ................................................................................................... 66
6.9 Webkamera til InTouch ................................................................................ 79
6.10 InTouch .................................................................................................... 83
6.11 Nettjenester ............................................................................................ 117
6.12 Test av tankens regulering ..................................................................... 136
6.13 Problemområder for prosjektutførelsen .................................................. 139
7 Prosjektorganisering. ....................................................................................... 140
7.1 Deltakere: .................................................................................................. 140
7.2 Arbeidslokaler og utstyrstilgang: ................................................................ 144
7.3 Prosjektleveranser: .................................................................................... 145
7.4 Tids- og kostnadsplan: .............................................................................. 148
7.5 Prosjektstyring og kvalitetssikring: ............................................................. 149
8 Litteraturliste .................................................................................................... 150
9 Vedlegg ............................................................................................................ 152
1

2 Figurliste
Figur 1: MasterPLS ................................................................................................... 14
Figur 2: SlavePLS ..................................................................................................... 17
Figur 3: Eksempel på InTouch grensesnitt ............................................................... 18
Figur 4 Adgang – OP ................................................................................................ 19
Figur 5: Krav til iX-panelet ........................................................................................ 20
Figur 6:WEB-forside ................................................................................................. 21
Figur 7: Bode-diagram av åpen sløyfefunksjon ........................................................ 23
Figur 8: Støymåling LT1 ved 90 % og 1 åpen utventil .............................................. 24
Figur 9: Andreordens Butterworth-filter ..................................................................... 25
Figur 10:Støysignalet med lavest frekvens på utstrømningssignal ........................... 28
Figur 11: Førsteordens Butterworth lavpassfilter ...................................................... 29
Figur 12: Gul kurve: Utstrømningssignal før filter. Grønn kurve: Utstrømningssignal
etter filter ................................................................................................................... 31
Figur 13: Ferdig-konstruert nivåfilter ......................................................................... 32
Figur 14: IC-brikken Lm358 ...................................................................................... 32
Figur 15: Oppkobling til rigg av Flow-filter ................................................................. 33
Figur 16: Oppkobling til panel av Nivå-filter .............................................................. 33
Figur 17: Flow-filteret inne Slave-PLS skapet. .......................................................... 34
Figur 18: Nivå-filter montert på tank-rigg. ................................................................. 34
Figur 19:Regulator-Samplingstid .............................................................................. 38
Figur 20: Slave-PLS'en og AD/DA-modulene. .......................................................... 39
Figur 21: Regulator-P. .............................................................................................. 40
Figur 22:Regulator-PI ............................................................................................... 41
Figur 23:Regulator-PI-2 ............................................................................................ 42
Figur 24: Regulator-Foroverkobling-P. ..................................................................... 43
Figur 25: Utregning Regulator-foroverkobling-D. ...................................................... 44
Figur 26:Regulator-Foroverkobling-D ....................................................................... 45
Figur 27:Regulator-Oppdatering av gamle verdier .................................................... 46
Figur 28: Skriv til Profibus fra slave. ......................................................................... 47
Figur 29: Skriv til Profibus fra slave. ......................................................................... 48
Figur 30: Lese fra Profibus med slavePLS'en ........................................................... 49
Figur 31: Lese fra Profibus med slavePLS'en ........................................................... 50
2

Figur 32: Analoge utganger fra slaven. ..................................................................... 51
Figur 33: Analoge innganger til slaven...................................................................... 51
Figur 34: Alarmbehandling. ....................................................................................... 52
Figur 35: Alarmbehandling. ....................................................................................... 53
Figur 36: Alarmbehandling. ....................................................................................... 54
Figur 37: Lampen på tank-riggen. ............................................................................. 55
Figur 38: Alarmbehandling. ....................................................................................... 56
Figur 39: Styring av utløp på tank-riggen. ................................................................. 56
Figur 40: Flowmåleren som måler utløpet fra tanken og ventilene som styrer dette . 57
Figur 41: Bilde av master-PLS'en. ............................................................................ 58
Figur 42: Hendelsessikring. ...................................................................................... 59
Figur 43: Lesing av verdier fra Profibus med masteren. ........................................... 60
Figur 44: Lesing av verdier fra Profibus med masteren. ........................................... 61
Figur 45: Skriving av verdier til Profibus med masteren............................................ 62
Figur 46: Skriving av verdier til Profibus med masteren............................................ 62
Figur 47: Innhenting av blokka PIDheltall. ................................................................ 64
Figur 48: Implementering av PIDheltall. .................................................................... 64
Figur 49: Variabelliste for PIDheltall ......................................................................... 65
Figur 50: Bakgrunn til iX-panelet: ............................................................................. 67
Figur 51: Innloggingsside til iX-panelet. .................................................................... 68
Figur 52: Betingelse ved innlogging. ......................................................................... 68
Figur 53: Sikkerhetsgruppe. ...................................................................................... 69
Figur 54: Sikkerhetsbetingelser. ............................................................................... 69
Figur 55: Trendvinduet i iX-panelet. .......................................................................... 70
Figur 56: Prosessvinduet i iX-panelet. ...................................................................... 71
Figur 57: Betingelser for synlighet. ........................................................................... 72
Figur 58: Betingelser for styring. ............................................................................... 72
Figur 59: Ved aktive- og inaktive-enheter. ................................................................ 73
Figur 60: Alarmvinduet i iX-panelet. .......................................................................... 74
Figur 61: Alarmsituasjon under kjøring. .................................................................... 75
Figur 62: Alarmer i iX-panelet ................................................................................... 75
Figur 63:Alarmbetingelse og pop-up vindu ............................................................... 76
Figur 64: Alarmbetingelse i iX-panelet. ..................................................................... 77
Figur 65: Popup-vinduer ved nivå over 90 % og under 10 %. ................................... 77
3

Figur 66: Alarmbetingelser i iX-panelet. .................................................................... 78
Figur 67: Port-webkamera. ....................................................................................... 80
Figur 68: Innlogging på ruter. .................................................................................... 81
Figur 69: Port-ruter. .................................................................................................. 82
Figur 70: Port-router-kamera. ................................................................................... 82
Figur 71: Innloggingsvinduet ..................................................................................... 85
Figur 72: Operatør3 vinduet ...................................................................................... 86
Figur 73: Operatør2 vinduet ...................................................................................... 86
Figur 74: Operatør1 vinduet ...................................................................................... 87
Figur 75: Sanntidstrendvinduet ................................................................................. 87
Figur 76: Historisk trendvindu ................................................................................... 88
Figur 77: Alarmhistorikkvinduet ................................................................................ 88
Figur 78: Kameraovervåkningsvinduet ..................................................................... 89
Figur 79: InTouch I - XXXXIII .................................................................................... 91
Figur 122: Sending og mottak av informasjon. ....................................................... 118
Figur 123: Aksessfilter ............................................................................................ 119
Figur 124: Reise for IP-adresse. ............................................................................. 120
Figur 125: Styring av prosessen fra nettside. ......................................................... 120
Figur 126: Oversikt over kommunikasjonen til nettsiden......................................... 121
Figur 127: REST eksempel. .................................................................................... 122
Figur 128: Iframe-element fra iX-webserver. .......................................................... 124
Figur 129: “Unknown port"-error i Chrome. ............................................................. 125
Figur 130: Salgstall for mobiloperativsystem, hentet fra Wikipedia.org. ................. 127
Figur 131: MIT App Inventor. .................................................................................. 128
Figur 132: Grafisk fremstilling av prosessen for å bytte til et nytt brukergrensesnitt.
............................................................................................................................... 129
Figur 133: Inndeling av fragmenter. ........................................................................ 130
Figur 134: RRC ikonet. ........................................................................................... 130
Figur 135: "Splash"-side. ........................................................................................ 131
Figur 136: Oversiktsside. ........................................................................................ 132
Figur 137: WebCam. .............................................................................................. 132
Figur 138: Kontrollside. ........................................................................................... 133
Figur 139: Produktet som sett på en Samsung Galaxy S2. .................................... 135
Figur 140: Resultat fra modellering. Kurvene viser nivå i %. .................................. 136
4

Figur 141: Modellerte reguleringsparametere uten(tv) og med(th) foroverkobling .. 137
Figur 142: Finjusterte reguleringsparametere uten(tv) og med(th) foroverkobling .. 138
Figur 143: Tankriggen............................................................................................. 144
Figur 144: Nettsiden til prosjektgruppen. ................................................................ 147
Figur 145: Loggført timeforbruk. ............................................................................. 148
5

3 Tabelliste
Tabell 1: Støymåling LT1 .......................................................................................... 24
Tabell 2: Støymåling på flowsignal ........................................................................... 29
Tabell 3: Krav til iX-panelet ....................................................................................... 66
Tabell 4: Rettigheter for forskjellige operatører i InTouch ......................................... 84
Tabell 5: Tabell over finjusterte regulatorparametere ............................................. 137
6

4 Vedleggsliste.
Vedlegg A: Testskjema – 7s
Vedlegg B: PID-kode i strukturert tekst – 3s
Vedlegg C: Android programfiler – 8s
Vedlegg D: Arbeidspakker – 10s
Vedlegg E: Arbeidsnotat – 35s
7

5 Innledning.
5.1 Bakgrunn:
Ved Høgskolen i Sør-Trøndelag, HiST, program for Elektro- og Datateknikk,
studieretning Automatiseringsteknikk, skal alle ingeniørstudentene gjennomføre ett
prosjekt under vårsemesteret i det andre året i studiene. Elevene blir delt opp i
grupper på fem til seks elever og får utlevert en oppgave som skal gjennomføres som
om det var et prosjekt som forekommer i arbeidslivet. Dette er ett større prosjekt hvor
både planlegging av prosjektet i et forprosjekt og utførelsen av prosjektet inngår.
Studentene skal også presentere prosjektet når arbeidet med det er ferdig. I
prosjektet så kreves det at studentene bruker kunnskap de har fått med seg halvveis
inn i bachelorprogrammet, og setter det ut i praksis. Samtidig så må studentene for å
gjennomføre prosjektet fordype seg innen aktuelle fagområder som inngår i
oppgaven. Prosjektet utgjør 12 studiepoeng, dvs. 40 % av et semester, og tidsmessig
vil dette utgjøre cirka 320 arbeidstimer per student. Det er faglærerne som leverer ut
oppgaven til studentene, og de opptrer selv som veileder og arbeidsgiver under
prosjektet. Prosjektet går samtidig som undervisning i store deler av
prosjektperioden, mens nærmere slutten av perioden vil det bli mindre undervisninger
og mer avsatt tid til jobbing med prosjektet.
Entanksprosjektet har vært en videreføring av miniprosjektet. Kommunikasjonen på
AD-DA-modulen har blitt videreført til et større program. Vi har modellert prosessen
og funnet fram til optimale regulatorinnstillinger som vi har tatt i bruk. Vi har skrevet et
PLS-program med HMI for styring og regulering av nivået i tanken.
EVE; JSH; OG
8

5.2 Oppgavetekst:
Prosjektgruppen skal lage program for InTouch, operatørpanel og PLS’ene som
oppfyller prosjektkravene når det gjelder styring av den ene tanken på tankriggen ved
hjelp av en FX1N-PLS. Dette skal presenteres for veileder og godkjennes som
entanksprosjektet. Entanksprosjektet skal dokumenteres i en rapport.
Gruppen skal kunne bruke operatørpanelet og InTouch for å sette parametere som
referanse, og se at nivået skal svinge stille seg inn på angitt referanse.
Det skal bli lagt inn alarmer for angitte nivå i tanken, som vi kan se og behandle i
HMI-ene, som er InTouch og iX-panel. Vi skal finne frem til regulatorinnstillinger ved
å modellere og simulere prosessen i Simulink. Programmet Gx-works2 skal bli
benyttet for å programmere regulatoren med og uten forover-kobling. Den skal ha et
innsvingingsforløp av typen minimum areal.
Målet er å oppnå raskest mulig innsvingingstid ved endring i
utløpet(magnetventilene) fra 3 åpne til 1 åpen.
Programmet skal kunne fungere både som P- og PI-regulator med rykkfri overgang
ved skifte av regulatortype i tillegg til skifte mellom manuell modus og automatisk
modus.
Gruppen skal konstruere et filter for å filtrere bort støy i nivået og et filter for filtrering
av støy fra flowmåleren, som er utstrømning fra magnetventilene. De skal se hvordan
støyen blir filtrert bort ved å koble filtrene til riggen.
Gruppen vil gjennomgå egne selvlagde testskjema for «entanksprosjektet» før det
skal demonstreres for arbeidsgiver. Arbeidsgiver vil ha eget testskjema som vil bli
gjennomgått ved selve demonstrasjonen, for se at alt fungerer etter spesifikasjonene.
Nettsiden skal være oppdatert og vil bli evaluert av arbeidsgiver i løpet av
entanksprosjektet.
EVE; TIB
9

5.3 Definisjoner:
PROFIBUS: Process Field Bus, en bredt utbredt feltbuss kommunikasjonsstandard
innen automasjon.
InTouch: Programvare for å lage HMI.
iX Panel TA100: Programmerbar berøringsskjerm.
iX Developer: Utviklingsmiljø for programvaren til iX Panelet
Server: Programvare som styrer kommunikasjon på et datanettverk.
IP: Internet Protocol
FTP: Filoverføringsprotokoll. Protokoll for overføring av filer i et TCP/IP-basert
nettverk.
Router: Veiviser mellom lokale og eksterne nettverk
JavaScript: Dynamisk programmeringsspråk for nettsider.
REST api: REpresentational State Transfer application programming interface
Ethernet: Den mest vanlige teknologien brukt for kommunikasjon i lokalnett,
spesifisert i standarden IEEE 802.3.
Webkamera: Kamera brukt for å overføre video over nett.
HiST - Høgskolen i Sør-Trøndelag
PC – Personal Computer
PLS – Programmerbar Logisk Styring
HMI – Human Machine Interface
OPC: Object Linking and Embedding for Process Control
OPC-Server: Skaper kobling til PLS for visning og kontroll av verdier fra PLS.
OPC-Link: Et program som kobler InTouch opp mot OPC-Serveren.
WindowViewer: InTouch sitt testmiljø
WindowMaker: InTouch sitt utviklermiljø
JSH; EVE
10

6 Teknisk del.
6.1 Problemstilling:
Riggen er allerede ferdigkoblet. Vi må sette oss inn i koblingstegninger for å finne ut
hvordan vi skal kjøre sprang på prosessen. Deretter så må vi finne riktige regulator-
innstillinger for prosessen.
Det er viktig å modellere prosessen for å kunne oppnå best mulig regulering. Også
under filterberegningene er det viktig å finne riktige verdier for å få luket bort mest
mulig støy og ikke miste nyttesignal.
EVE; OG
6.1.1 Dagens situasjon
Per dags dato er modulenes programvare satt opp og testet ut. Filtrene er ferdig
montert og fungerer som de skal. Systemet er forsøkt regulert og prosjektgruppen er
fornøyd med resultatet de har oppnådd med prosjektet.
EVE; OG
6.1.2 Prosessbeskrivelse
Systemet reguleres og behandles i slave-PLS’en, mens den styres fra HMI’ene. Det
stilles inn ønsket nivå og reguleringsmetode i HMI’ene, før PLS’en sender verdier til
ventilen som kontrollerer hvor mye vann som strømmer inn i tanken. Tankriggen har
enheter som måler utløp og nivå, som hjelper PLS’en til å kontrollere ventilen. På
denne måten får PLS’ens regulator regulert inn nivået til innstilt referanse. Utløpene
stilles inn i HMI’ene, og der kan også alle verdier leses av.
EVE; OG
6.1.3 Løsning
Gruppen har delt opp oppgaven i flere deler. Studentene deler den opp i
programmering, modellering og filterberegning. Når alle av disse delene ble gjort,
samlet prosjektgruppen delene sammen og kontrollerte om alt fungerte. Når alle
enkeltdelene ble ferdig testet prosjektgruppen om systemet fungerte i henhold til
kravene i oppgaveteksten.
OG; EVE
11

6.2 Prosjektmål
6.2.1 Effektmål
1. Vise hvordan vi på en god måte kan styre og regulere nivået i en tank.
2. Legge grunnlaget for videre arbeid med riggen til totanksprosjektet.
3. Oppdatere fremgang gjennom nettsida.
JSH; OG
6.2.2 Resultatmål
Prosjektgruppen skal:
1. Oppdatere programvare til InTouch og iX-panelet for styring og regulering av
nivået i tanken.
2. Programmere PLS’en for å regulere nivå og behandle alarm. PLS’en skal
utvides for å ha mulighet for bruk av foroverkobling.
3. Oppdatere Q-PLS med nye kommunikasjonsadresser.
4. Måle støy, dimensjonere og lage filter.
5. Modellere prosess for å kunne beregne regulatorparametere.
6. Komme godt i gang med følgende tilleggsoppgaver:
PID-regulator i strukturert tekst.
Kameraovervåking via webkamera over internett.
7. Vurdere følgende bonusoppgaver dersom tid:
Fjernstyring av tankriggen med smarttelefon.
Regulering av nivået ved hjelp av frekvensomformer.
JSH; OG
6.2.3 Prosessmål
Studentene skal:
1. Øke kompetansen og forståelsen av styring og regulering av nivå i tank.
2. Øke kompetansen om riktig bruk av grafiske elementer i HMI, i forhold til
prosessen.
3. Øke kompetansen om kommunikasjonsprotokollene som knytter de ulike
delene sammen.
4. Øke evnen til å lære seg ny teknologi gjennom tilleggsoppgavene.
5. Øke det sosiale samarbeidet og trivselen innad i gruppa.
JSH; OG
12

6.3 Prosjektbeskrivelse:
I entanksprosjektet har gruppen jobbet med regulering og styring av tanken.
Prosessen blir styrt fra iX-panelet og InTouch, og skal regulere seg inn til referanse
ved endring i utløp.
Entanksprosjektet er «hovedprosjektet», som forprosjektet og miniprosjektet ligger til
grunnlag for. De store utfordringene vil komme i denne delen av prosjektet, hvor vi
møter problem. Entanksprosjektet vil ligge til grunnlag for totanksprosjektet som vil
komme etter entanksprosjektet er ferdig. Det er derfor viktig at entanksprosjektet blir
grundig gjennomgått, slik at totanksprosjektet blir enklere å samkjøre med den andre
gruppen.
TIB
13

6.4 Spesifikasjoner
6.4.1 PLS
PLS-Master
Anlegget består av to datanettverk som lar styringsenhetene i anlegget kommunisere
med hverandre. Dette er et Ethernet og en Profibus-DP feltbuss. MasterPLS-en er en
modulbasert PLS av typen Mitsubishi Q00 og skal være bindeleddet mellom
nettverkene. MasterPLS-en muliggjør kommunikasjon mellom SlavePLS, koblet til
Profibus-DP, og HMI, koblet til Ethernet. Produktspesifikasjoner til MasterPLS er
beskrevet i prosjektets Miniprosjektrapport.
Figur 1: MasterPLS
BM
PLS-Slave
Væskenivået i en tank skal reguleres. Denne tanken har et innløp, som styres av
reguleringsventil, og et utløp, som styres av tre magnetventiler. SlavePLS-en er en
PLS av typen Mitsubishi FX1N med mulighet for utvidelser. SlavePLS-ens oppgave
er å stå for reguleringen av nivået i tanken. Detaljerte produktspesifikasjoner til
SlavePLS er beskrevet i prosjektets Miniprosjektrapport.
Slaven skal lese nivå og utstrømning samt sende ut signal til reguleringsventilen ved
hjelp av en ekstern analog modul.
14

Slaven skal kommunisere direkte med MasterPLS-en ved hjelp av Profibus-DP og
skal sende ut følgende verdier:
- Analoge verdier:
o Avvik
o Nivå
o Utstrømning
o Manuelt pådrag
o Referanse
o Nominelt pådrag
o Pådraget til ventil
- Digitale verdier:
o Stopp av pumpe
o Alarm ved avvik over 25 %
o Alarm ved nivå over 90 %
o Alarm ved nivå under 10 %
o Resetting av kvittering
I tillegg skal Slaven motta følgende verdier fra MasterPLS-en:
- Analoge verdier:
o Referanse
o Samplingstid
o Kp
o Ti
o KpFF
o TdFF
o Nominelt pådrag
o NFF
o Manuelt pådrag
15

- Digitale verdier:
o Auto/manuell
o P/PI
o Foroverkobling på/av
o Pumpe på/av
o Utløpsventil 1 på/av
o Utløpsventil 2 på/av
o Utløpsventil 3 på/av
o Alarmkvittering
o Reverserende/direkte regulator
Programmet skal kunne fungere både som P- og PI-regulator med rykkfri overgang
(bumpless transfer) ved skifte av regulatortype. Det skal ha både direkte og reversert
modus. Det skal også være mulig å sette regulatoren i manuell modus i tillegg til den
automatiske. Regulatoren skal også inneholde mulighet for foroverkobling av PD-
type. Overgangen mellom manuell og automatisk modus skal også foregå rykkfritt.
Følgende parametere skal kunne justeres i regulatoren: proporsjonal forsterkning
(Kp), integrasjonstid (Ti), nominelt pådrag, referanse og samplingstid. I manuell
modus skal pådraget styres fra MasterPLS. I foroverkoblingsdelen skal det være
mulig å stille inn KpFF, TdFF og NFF.
Regulatoren skal justeres inn så det blir et innsvingningsforløp av typen minimum
areal når nivået har stabilisert seg uten stasjonært avvik med referanse på 60 % og
det kommer et sprang i utløpet fra 3 ventiler til 1 ventil åpen.
Det skal gå alarm dersom nivået avviker mer enn 25 % fra referansen(25 % av totalt
måleområde). Kritisk alarm skal aktiveres dersom det absolutte nivået i tanken
overstiger 90 % eller går under 10 %. Ved vanlig alarm skal ei varsellampe, koblet til
SlavePLS-ens utgang Y5, på tanken blinke med 0,5 sekunder på og 0,5 sekunder av.
Ved kritisk alarm skal blinkefrekvensen økes slik at lampa står på i 0,2 sekunder og
av i 0,2 sekunder. Dersom alarmen er kvittert ut fra operatørpanelet eller InTouch-
applikasjonen, men det fortsatt er alarmtilstand, skal lampa ha fast lys. Lampa skal bli
mørk når det ikke lenger er alarmtilstand. Hvis prosessen går ut av alarmtilstand uten
16

at alarmen er kvittert, skal lampa fortsette å blinke inntil alarmen er kvittert.
Alarmtilstander som varer mindre enn fem sekunder skal ikke utløse alarm.
Programmet må utformes slik at pumpa til tanken skal kunne slås av og på. Ved
kritisk høy alarm skal pumpa stoppes automatisk. Det er viktig at programmet
automatisk sørger for at nivået i tanken reguleres rett ved strøminnkobling etter
strømbrudd.
De tre magnetventilene som styrer utløpet er styrt av SlavePLS-ens utganger Y10,
Y11 og Y12. Programmet i PLS-en skal utformes slik at magnetventilene kan styres
av PC med HMI-programmet InTouch.
Figur 2: SlavePLS
BM
17

6.4.2 InTouch
InTouch er et operatør-grensesnitt hvor operatør kan koble seg til PC for å styre og
overvåke prosessen. Operatørgrensesnittet har tre forskjellige operatører som har
ulik tilgang til styringen av prosessen. Eksempel på hvordan operatør-grensesnittet
ser ut er vist i bildet under.
Figur 3: Eksempel på InTouch grensesnitt
Det som skal kunne settes og styres fra InTouch er vist i Figur 4for de forskjellige
operatørene. NB! Tank2 er ikke med i dette prosjektet.
TIB
18

Figur 4 Adgang – OP
Alarmer:
TIB
• Det går alarm dersom nivået har et avvik på mer en 25 % i forhold til
referansen.
• Dersom nivået er under 10 % vil kritisk alarm aktiveres.
• Kritisk alarm dersom det absolutte nivået oversiger 90 % i tanken.
• Alarmtilstand som varer i mindre enn 5 sekunder vil ikke aktiveres.
• Alarmer vil kunne kvitteres fra InTouch.
• Alarmhistorikk vil være tilgjengelig i Historikk-vinduet i InTouch.
19

6.4.3 iX-panel
iX-panelet er et operatørpanel med touchskjerm lokalt på riggen. Skjermen viser et
bilde av prosessen. Panelet er for enkelt kunne styre og overvåke prosessen, og for
å detektere og kvittere alarmer.
Figur 5: Krav til iX-panelet
OG
20

6.4.4 Nettside
Det er laget en nettside som presenterer gruppe og prosjektet på en enkel måte.
Nettsiden ligger på WEB-adressa www.hekta.org/~p2ea1.
Figur 6:WEB-forside
Figur 6 viser hvordan forsiden på nettstedet er utformet. Nettsidene inneholder
informasjon om prosjektet med beskrivelse av gruppa og oppgaven.
Dokumentarkivet på siden inneholder blant annet rapporter, innkallinger og referater.
En side presenterer fremdriften på prosjektet og blir jevnlig oppdatert.
Operatørpanelet i anlegget har en innebygget WEB-server som nettsiden bruker til å
styre prosessen med. Denne siden krever innlogging med passord for å hindre
uønsket tilgang til styringen. Den samme siden viser WEB-kamera som brukes til å
overvåke prosessen med.
BM; TIB
21

6.5 Filterberegninger og konstruksjon
Som en del av prosjektet, skal prosjektgruppen konstruere to lavpass-filtre som skal
settes inn før signalet går inn på AD-DA modulen i slave-PLS’en. Prosessen er
plaget med en god del støy, forårsaket blant annet av fallhøyden fra innløpet i tanken
til vannoverflaten, samt tankens smale radius. Ved å filtrere bort unyttig støy er
tanken å få et bedre bilde av tankens faktiske tilstand.
JSH
6.5.1 Beregningsbakgrunn
Prosjektriggen har to målepunkter som skal sendes til AD-DA omformeren i PLS’en.
Man måler nivået i tanken, samt strømningen ut av tanken. AD-DA omformeren
opererer med 8 bit, som vil si at et analogt signal inn vil tolkes som et digitalt signal
mellom 0 og 255 inn. Ønsket man har med filtrene er at støysignal, enten i selve
målingen eller fra andre omliggende støykilder, skal filtreres bort slik at det ikke gir
utslag på mer enn 1 bit på den digitale siden. Det vil si at man vil ha en maksimal
amplitude til støysignalet på under 0,5 av størrelsen til 1 bit. Man forkorter ofte dette
størrelsesmålet til ½ LSB(Least Significant Bit). Man vet at begge målerne gir ut et
signal mellom 0-5 V, og kan dermed regne ut amplituden det er ønskelig å ligge
under:
1
2
=
5 − 0
2 − 1
2
= 0.00976 ≈ 0.01
En annen viktig faktor som må tas hensyn til, er frekvensen til nyttesignalet som
kommer fra tanken. Kommer et av filtrenes knekkfrekvens for nærme, eller før
knekkfrekvensen til tanken vil dens nyttsignal bli dempet, noe som blant annet kan
skade prosessens regulator sin evne til å reagere raskt på endringer i tanken. Ved å
ta nytte av den matematiske modellen som ble laget i tilknytning til arbeidsnotatet, så
man på frekvensresponsen til tanken, her representert i et Bode-diagram.
22

Figur 7: Bode-diagram av åpen sløyfefunksjon
Man fant her fasekryssfrekvensen ved 0,367 rad/s, eller sirka 0,06 Hz. Det kan da
defineres at nyttesignalet er opp til og med denne frekvensen, da tankens system
ikke er rask nok til å følge med på innsignaler raskere enn dette. Så lenge filtrenes
knekkfrekvens ligger et godt stykke over denne frekvensen vil de ikke påvirke
prosessen i en betydelig grad.
JSH; FS
23

6.5.2 Nivåmåler
Nivåmåleren er relativt mye plaget av støy, og med ganske høy amplitude. Dette
kunne gitt store feilmeldinger om nivåets stabilitet, hvis det ikke ble filtrert bort før det
sendes inn i regulatoren.
JSH
Støymåling
For å komme frem til en god design av filteret, måtte man først finne hvilke
frekvenser man vil filtrere bort. Dette ble gjort ved at en ekstern regulator ble tilkoblet
riggen, innstilt ved hjelp av autotuner, og at man så på støyfrekvens målt ved
forskjellige høyder, samt forskjellige verdier på utløpet. Støyen ble målt med
oscilloskop ut fra LT1(-)(Level Transmitter 1) på tankriggen.
Figur 8: Støymåling LT1 ved 90 % og 1 åpen utventil
Beregning # Nivå i % Utløpsventiler Amplitude i mV Frekvens i Hz
1 90 1 48,75 208,33
2 90 3 226,62 166,67
3 60 1 210,37 454,55
4 60 3 446,25 113,64
5 10 1 370,12 208,33
6 10 3 280,87 192,75
7 Sprang 5 - 90 3 280,75 192,31
Tabell 1: Støymåling LT1
24

£Støymåling_LT1 viser gir oss verdier på hva slags støy vi måler fra LT1(-). Det man
er mest interessert i, er målingene som gir oss lavest frekvens på støyen, da det er
denne man må basere filteret ut på, men man er også interessert i hvilken amplitude
dette signalet har.
JSH
Design
Filteret som skal være tilkoblet nivåmåleren til tank 1, LT1, skal ifølge
prosjektspesifikasjonene være et andreordens Butterworth-filter.
Figur 9: Andreordens Butterworth-filter
For å finne passende verdier, begynner man som oftest ved å velge størrelsen på
kondensatorene, C1 og C2. I dette tilfellet valgte man disse lik: C1 = C2 = 1 µF.
Før man kan regne ut verdiene til R1 og R2, må man regne ut hvor man ønsker å ha
filterets knekkfrekvens. Det vil si, ved hvilken frekvens skal dempningen av signalet
begynne, og hvor mye signalet skal være dempet før man når støyfrekvensen.
=
!ø #
$
%
∗ 2' ∗ ()ø*
Fra beregningene av ½ LSB tidligere i kapittelet fant man den ønskede amplituden
etter dempning, nemlig 0,01 V. Under målingene fant man at støysignalet på sitt
laveste har en amplitude rundt 114Hz. For sikkerhets skyld rundes dette ned til
100Hz. Ved denne frekvensen måltes det en amplitude på 446 mV. Dette rundes opp
til 500 mV. Avrundingene gjøres for å ta hensyn til uforutsette hendelser. Man setter
så disse verdiene inn i formelen for å finne knekkfrekvensen. N i formelen designerer
filterordenen.
25

= 0.01
0.5 #
$
+
∗ 2' ∗ 100 ≈ 88.86 ≈ 14.14 /0
-
Så skal selve filteret beregnes. Man har allerede sett seg ut to kondensatorer, og vil
nå regne ut verdien til motstandene.
1
1 $ =
2 ∗∝∗ 3 $
1 + =
2 ∗∝
+ ∗ 3+
Variabelen α er her avhengig av graden til filteret. For et annenordens filter, vil man
ha 4 poler i det komplekse plan, og 2 poler i venstre halvdel. Disse finner man jevnt
fordelt utover enhetssirkelen, og α finnes ved hjelp av vinklene til disse i forhold til
den reelle aksen. For denne ordenen har vi 2 poler, begge med 45 graders forhold til
den reelle aksen, og vi finner α ved denne formelen:
∝ = ∗ cos7458 = 88 ∗ cos7458 = 44√2
Da er alle variablene på plass, og man kan finne motstandene.
1
1 $ =
≈ 8

Resultat
Avlesninger av nivå i PLS viser markant bedring ved tilkobling av filter. Man ser av
avlesningene at signalet, ved stabilt nivå og utløp, varierer med sirka en bit, noe som
tilsier at man har lyktes i målet om at støyen skal være mindre enn 1 LSB.
Konstruksjon av nivåfilter er derfor en suksess med tanke på de kriterier som ble satt
i spesifikasjonene.
JSH
27

6.5.3 Strømningsmåler
Strømningsmålersignalet er ikke betydelig plaget av støy og støyen er med relativt
lav amplitude. Strømningssignalet blir filtrert for ikke å få et feil bilde av hva
utstrømningen er, og videre påvirke utregninger i foroverkoblingsregulator.
FS
Støymåling
For å designe filteret på en bra måte er vi avhengig av å vite hvilke frekvenser vi ikke
ønsker, og dermed vil filtrere bort. Signalet ble logget ved hjelp av oscilloskop ved
forskjellig vannhøyde i tanken, ved forskjellig mengde på utløp og ved påfylling og
tømming av tank. Etter utførte tester stod vi igjen med støyfrekvensene som vi tok
utgangspunkt i for design av filter. Det støysignalet vi var mest interessert i var det
med lavest frekvens, samt å analysere amplituden på dette støysignalet samt
amplitude på eventuelle nærliggende støysignal.
Figur 10:Støysignalet med lavest frekvens på utstrømningssignal
28

Beregning# Nivå i % Utløpsventiler Amplitude i mV Frekvens i Hz
1 90 1 4,5 10,2
2 90 3 11,25 6,8
3 60 1 4,5 7,6
4 60 3 7,5 6,4
5 10 1 2,5 8,47
6 10 3 8,63 7,04
Tabell 2: Støymåling på flowsignal
FS
Design
Figur 11: Førsteordens Butterworth lavpassfilter
I følge prosjektspesifikasjonene var det ikke oppgitt noen andre spesifikasjoner annet
enn at det skulle være et antialiasing filter på målt utløp, og at ic-brikken LM358
skulle brukes. Valget vårt ble derfor et lavpassfilter av typen butterworth av første
orden. Bakgrunnen for at det ble valgt et første ordens filter var på bakgrunn av
analysene som ble gjort med tanke på bodediagrammet og at den laveste
støyfrekvensen som ble funnet lå ca. to dekader over maksimum frekvens systemet
greier å følge med på. Behovet for en bratt fallkurve i filteret trengs dermed ikke siden
fasekryssfrekvens og laveste støyfrekvens ikke ligger nært hverandre.
29

Vi regnet oss frem til knekkfrekvensen til filteret ved hjelp av formelen
=
!ø #
$
%
∗ 2' ∗ ()ø*
Under målingene som ble gjort på signalet fra flowmåleren fant vi den laveste
støyfrekvensen til å være 6,4Hz. Denne frekvensen ble rundet ned til 5Hz for å ta
hensyn til uforutsette hendelser. Dette kan man gjøre siden 5Hz ligger langt fra den
høyeste frekvensen systemet kan håndtere som beskrevet under
Beregningsbakgrunn. Amplituden til støysignalet på 6,4 Hz var på 7,5 mV, men
nærliggende støysignal på 6,8Hz hadde en amplitude på 11,25 mV. Det ble derfor
valgt å bruke amplituden til støysignalet på 6,8Hz. N i formelen viser til grad av
filterorden.
=
0.01
0,01125 #
$
$
∗ 2' ∗ 5 ≈ 27,93 ≈ 4 /0
-
For å finne verdier til komponentene i filteret må man først ta utgangspunkt i
størrelsen på kondensatoren. Vi valgte C1 = 1 µF. Deretter regnet vi ut størrelsen på
R1 ved formelen
1 $ =
1 $ =
1
∗ 3 $
1
= 39793 Ω
25,13 ∗ 1 ∗ 10 :;
Motstanden velger vi ut fra E-12 serien, og nærmeste verdi ble da 39 kΩ.
FS
30

Oppkobling av Flowmåler-filter
For å få analysert og målt støyen på utstrømningssignalet fant vi ikke noe god
dokumentasjon på hvor vi kunne hente ut utstrømningssignalet fra FT. Prøvde å
hente ut signalet fra koblingspanelet bak på tankriggen uten hell. Til slutt greide vi å
finne utstrømningssignalet direkte på inngangen til AD/DA modul på slave-PLS 1.
Filteret vil kobles inn i samme skap som slave-PLS 1.
FS
Resultat
Figur 12: Gul kurve: Utstrømningssignal før filter. Grønn kurve: Utstrømningssignal etter filter
Rent grafisk ser vi at vi har en tydelig forbedring av av signalet etter filteret. Etter en
litt nærmere sjekk fant vi heller ingen støyamplitude over $
feil signal på inngang til AD/DA.
FS
+ som ville kunne gitt
31

6.5.4 Konstruksjon og oppkobling
Gruppen sendte inn bestilling til arbeidsgiver med de verdiene man kom frem til
under beregningene. I tillegg bestilte man to veroboard man kunne montere filtrene
på. Komponenter og ledninger blir loddet på, og filtrene er klare til montering.
Figur 13: Ferdig-konstruert nivåfilter
JSH
Figur 14: IC-brikken Lm358
32

Flow-filter
Figur 15: Oppkobling til rigg av Flow-filter
På IC-brikken koblet vi oss på pinne 1,2,3,4 og 8 som vist på tegning over.
Nivå-filter
Figur 16: Oppkobling til panel av Nivå-filter
På IC-brikken koblet vi oss til her som vi ser: OP-AMP 1:1,2,3,4 og8. OP-AMP2:
4,5,6,7 og 8.
33

Figur 17: Flow-filteret inne Slave-PLS skapet.
Figur 18: Nivå-filter montert på tank-rigg.
OG
34

Filtrene blir forsynt med 24 V DC spenning fra riggens uttak, som går til
operasjonsforsterkerne, mens filtrenes ut- og inn-ganger kobles i serie med signalene
fra nivåmåler og flowmåler til inngangene på PLS.
JSH
6.5.5 Konklusjon filter
De to filtrene er nå konstruert og satt opp på riggen. Det kan diskuteres om filteret til
flowmåleren strengt tatt var nødvendig for stabiliteten av dens avlesninger, men det
var uansett nyttig for gruppen å gå gjennom beregninger og konstruksjon av begge,
da det var beregninger av flowmålerens filter som satte lys på problemstillingen
angående bruk av filtergrad.
Jevnt over ser man at bruk av filter mellom de analoge målerne og de digitale leserne
er svært nyttig, og var en flott måte for gruppen å få satt kunnskapen om
filterkonstruksjon ut i praksis.
JSH
35

6.6 PLS.
6.6.1 Slave-PLS:
Prosjektgruppen har tidligere under det store prosjektet vært igjennom et delprosjekt
som inneholder kommunikasjon. Under dette prosjektet ble en prosjektrapport levert,
som omhandler kommunikasjonen mellom master- og slave-PLS, HMI’ene og tank-
riggen. Derfor henviser prosjektgruppen til rapporten om det er ønsket mer
informasjon som omhandler kommunikasjonen. Der vil det også stå forklart
oppbyggingen av programmene som brukes under entanksprosjektet. Både i iX-
panelet, i InTouch og i PLS-programmet er det masse oppbygging, for eksempel i
PLS vil det brukes spesialblokker som står forklart i rapporten.
Under entanksprosjektet skal prosjektgruppen utarbeide ett program som følger alle
krav i henhold til oppgaveteksten. Programmet skal kunne fungere både som P- og
PI-regulator med rykkfri overgang ved skifte av regulatortype. Det skal ha både
direkte og reversert modus. Det skal også være mulig å sette regulatoren i manuell
modus i tillegg til den automatiske. Denne overgangen skal også foregå rykkfritt.
Regulatoren skal også inneholde mulighet for foroverkobling av P-, D- eller PD-type.
Følgende parametere skal kunne justeres: proporsjonal forsterkning, integrasjonstid,
nominelt pådrag, referanse og samplingstid. I manuell modus skal pådraget settes. I
foroverkoblingsdelen skal det være mulig å stille inn KpFF, TdFF og NFF.
I tillegg til spesifikasjonene for regulatoren forklarer oppgaven spesifikk hvilke
alarmer systemet skal inneholde og hvordan de forskjellige alarmene skal opptre. Det
skal gå alarm dersom nivået avviker mer enn 25 % fra referansen. Kritisk alarm skal
aktiveres dersom det absolutte nivået overstiger 90 % eller går under 10 %. Ved
vanlig alarm skal ei varsellampe på tanken blinke med 0,5 sekunder på og 0,5
sekunder av. Ved kritisk alarm skal blinkefrekvensen økes slik at lampen står på i 0,2
sekunder og av i 0,2 sekunder. Dersom alarmen er kvittert ut fra operatørpanelet eller
InTouch-applikasjonen, men det fortsatt er alarmtilstand, skal lampen ha fast lys.
Lampen skal bli mørk når det ikke lenger er alarmtilstand. Hvis prosessen går ut av
alarmtilstand uten at alarmen er kvittert, skal lampen fortsette å blinke inntil alarmen
er kvittert.
En annen viktig del av alarmbehandlingen er at om alarmtilstanden varer mindre enn
fem sekunder, skal ikke alarmen utløses. Pumpen på riggen skal kunne styres av
36

programmet, man skal kunne slå den av og på. Ved kritisk høy alarm skal pumpen
stoppes automatisk. Det er viktig at programmet automatisk sørger for at nivået i
tanken reguleres rett ved strøminnkobling etter strømbrudd.
En vesentlig problemstilling er at PLS programmet ikke klarer å regne med
desimaler. Derfor har prosjektgruppen opparbeidet et program der enkelte variabler
som ønskes med desimaler multipliseres med faktoren 10, for så å dividere på 10
senere i programmet så systemet ikke mister viktige verdier under utregningen. I
PLS-programmet er det også en grenseverdi for hvor høye tall som de forskjellige
dataregistrene kan håndtere. Prosjektgruppen har med tanke på denne
begrensningen tatt en gjennomgang der ekstremtilfeller regnes ut, for så å sjekke om
tallverdiene holder seg innom det mulige området.
De neste sidene inneholder en gjennomgang av prosjektgruppens program. Det har
blitt bestemt internt i gruppen at gjennomgangen vil inneholde bilder og forklaring
parallelt, så det blir enklest mulig oversikt. Det er også satt inn tekst i programmet,
som skal forklare nok til at man skal få god oversikt bare med bildene.
Prosjektgruppen har plassert formlene til regulatoren ved siden av bildene og
teksten, så leseren kan få et innsyn i bakgrunnen til programmeringen.
EVE
37

Regulatoren
Om regulatoren blir slått i manuell skal brukeren kunne styre pådraget fra en av
HMI’ene. U_m er det manuelle pådraget som setter U0, Pådraget og pådraget til PI-
regulatoren. Referansen settes lik prosessverdien, for å sikre at avviket er lik 0. U0
settes så en rykkfri overgang til P-regulator skal kunne utføres. Pådraget til PI-
regulatoren settes så en rykkfri overgang til PI-regulator skal kunne utføres.
!7A B == 08{
Figur 19:Regulator-Samplingstid
D< − 1 = D E; D0 = D E; = G; D = D E;}
Neste del av programmet sørger for at kjøringen med P-regulator og foroverkobling
skal fungere sammen, og da må U0 settes lik 0.
Som forklart i innledningen i denne teksten, så er det mange variabler som er
multiplisert med 10 for å få regnet med ønsket antall desimaler. På grunn av at de
38

forskjellige variablene allerede er multiplisert med 10, vil det ikke vises på en annen
måte enn å gi tallene samme verdi og å kalle de noe annet. Gruppen ønsket å
innføre denne biten, så det skulle bli enklere å få et raskt overblikk, for eksempel vil
Kp multiplisert med 10 bli kalt Kp10.
Samplingstiden skal stilles inn av operatører på systemet. Gruppen har bestemt at de
ville bruke en desimal på samplingstiden. Den vil bli multiplisert med 10 i iX-panelet
og i InTouch før den videresendes til master- og slave-PLS. Om dette ikke utføres
allerede i HMI’ene, vil desimaler falle av før det kommer ned til utregningene i slave-
PLS’en. Samplingstiden bestemmer hvor ofte regulatoren skal kjøre. I denne
programbiten sørger vi for med ett hopp og en timer, at regulatoren ikke kjører oftere
enn den bestemte samplingstiden tilsier. Timeren buker verdien 100ms, så til vanlig
for å få f.eks. 1s må man multiplisere verdien med 10 for å få riktig verdi inn på
timeren. Siden studentene allerede har multiplisert samplingstiden med 10 i HMI’ene,
vil gruppen slippe å gjøre ytterlige endringer før vi sender den inn i timeren.
Figur 20: Slave-PLS'en og AD/DA-modulene.
39

Figur 21: Regulator-P.
Avviket utregnes, enten i reversert eller direkte modus.
!71 H - == 18{
- {
I = − G}
I = G − }
Neste del er P-regulatoren som slår inn om det er valgt automatisk regulator og ikke
PI-regulator i HMI’ene. I en tidligere del av programmet var det en nullstillingsdel,
som nullstiller U0 om foroverkoblingen er tilkoplet, da denne ikke skal innvirke i den
situasjonen.
K!7A B == 18{ !7LK == 08{
DIM = N
10 ∗ I + N $ % I
+ D0; }
10
40

Figur 22:Regulator-PI
For å unngå å bruke verdier som PLS’en ikke aksepterer har prosjektgruppen gjort
en utregning der de for eksempel bruker «%» som betyr at man henter resten. Dette
har prosjektgruppen utført så viktige verdier ikke skal mistes, og for at utregningen
skal holde seg innen ønsket område.
PI-regulatoren skal brukes om auto og PI-regulator er aktivert i HMI’ene. Utregningen
er vanligvis mindre enn den prosjektgruppen har benyttet, fordi at prosjektgruppen
ønsket å få med en desimal på proporsjonal forsterkning og integrasjonstid.
if7Auto == 18{if7PI == 18{
ΔD I = YN $
10 ∗ I + N $ %10 ∗ I + ΔDZ[()I:$ 10
\
;
ΔD - I = N $
10 ∗ I + N $ %10 ∗ I + ΔDZ[()I:$ # %] M^ ;
10
DI = DI:$ + ΔDMI + _`
$ ∗ 7 I − I:$8 + _`%$ ∗7[ a:[ abc8
;}
$
] M^
41

Figur 23:Regulator-PI-2
42

Neste del av programmet er en bit som håndterer foroverkoblingens P-del, har
brukes utløpet sammen med en innstilt KpFF til å hjelpe systemet å håndtere en
endring i utløpet. I denne delen er det også programmert for å ta vare på verdier og
for å holde verdiene innenfor ønskede verdier.
!7A B == 18{ !7Ld == 18{
Figur 24: Regulator-Foroverkobling-P.
D ee I = N ee $
10
ΔH I = H I − H I:$ ; }
∗ ΔH I + N ee $ %10 ∗ ΔH I
10
Foroverkoblingens P-del og P- eller PI- regulatorens pådrag adderes før der
grensesjekkes.
; }
43

En grensesjekk er å sørge for at en verdi holder seg innenfor de lovlige verdiene. I
dette tilfellet er det lovlige området mellom 0 til 255, derfor utføres testen på måten
som er vist på bildet og i formelen.
Figur 25: Utregning Regulator-foroverkobling-D.
!7D I > 2558D I = 255;
!7D I < 08D I = 0;
Gjennom programmet utføres mange utregninger flere ganger. Derfor har
prosjektgruppen laget programbiter for å utregne disse, så lengre regnestykker kan
kortes ned ved at verdiene er utregnet tidligere.
44

Neste steg er foroverkoblingens D-del. For å gjøre hovedprogrambiten litt mindre
utregnes en del på forhånd. Prosjektgruppen har bestemt at de skal bruke desimaler
også på foroverkoblingen, og programmet er lagt opp ut ifra det. Det vises med at det
divideres med 10 i regnestykket, for at riktige verdier skal sendes ut.
!7A B == 18{ !7Ld == 18{
Ddee I
=
N ee $
10
Figur 26:Regulator-Foroverkobling-D
∗ ΔH I + N ee $ %10 ∗ ΔH I
10
+ ]!ee ∗ Ddee I:$ + ]!ee $ %10 ∗ Ddee I:$
10
- --]!ee
Foroverkoblingens D-del adderes så med verdien som er blitt grensesjekket tidligere,
for så å bli grensesjekket igjen.
45
; }

For å få en rykkfri overgang fra auto til manuell har prosjektgruppen legt til en del
som overfører pådragets verdi til det manuelle pådraget, så lenge regulatoren er satt
til auto.
!7A B == 18{D E = D; }
Det er også lagt inn en blokk for å få rykkfri overgang fra PI- til P-regulator, denne
delen gir U0 verdien til PI-regulatorens pådrag.
Figur 27:Regulator-Oppdatering av gamle verdier
!7LK == 18{D0 = D I; }
Etter hver gjennomkjøring skal regulatoren oppdatere verdiene sine, så det stemmer
til neste gjennomkjøring. Det er det denne programbiten utfører.
EVE
46

Profibus:
I miniprosjektet opprettet vi kommunikasjon mellom de forskjellige enhetene som
brukes i prosjektet. I entanksprosjektet viderefører prosjektgruppen kunnskapen
videre til å kunne motta og avgi de aktuelle verdiene for en bra styring av systemet.
Under er programbiten som inneholder lesing og skriving av data til bufferminnene.
EVE
Skriving til Profibus:
Her sender vi: pådraget, prosessverdien, utløpet, noen utvalgte minneceller,
referansen og det manuelle pådraget. Referansen skal kun sendes opp når
regulatoren står i manuell, og det manuelle pådraget skal kun sendes når regulatoren
står i auto. Dette har prosjektgruppen bestemt fordi at om verdiene ble sendt
kontinuerlig innvirker det på prosesstyringen.
Figur 28: Skriv til Profibus fra slave.
47

Figur 29: Skriv til Profibus fra slave.
EVE
48

Lesing fra Profibus:
Innhentingen av data er også grundig forklart i miniprosjektrapporten, og derfor vil det
også forekomme en overfladisk gjennomgang av innhentings delen. Slave-PLS
henter inn følgende data fra bufferminnene: referansen. Samplingstiden, proporsjonal
forsterkning, integrasjonstid, U0, NFF, det manuelle pådraget, et utvalg minneceller
og foroverkoblingens proporsjonale forsterkning og derivasjonstid. Referansen skal
kun leses om regulatoren står i auto, og det manuelle pådraget skal kun leses om
regulatoren står i manuell.
Figur 30: Lese fra Profibus med slavePLS'en
49

igur 31: Lese fra Profibus med slavePLS'en
EVE
50

Analog inn og ut:
I miniprosjektet var oppgaven å sende en verdi til DA modulen, for så å motta samme
verdi fra AD modulen. I entanksprosjektet har prosjektgruppen opprettet
kommunikasjon med tank-riggen. I entanksprosjektet brukes nå DA modulen til å
sende pådraget som styrer ventilen til tank-riggen. AD-modulen brukes til avlesning
av utløpet og prosessverdien.
Figur 32: Analoge utganger fra slaven.
Figur 33: Analoge innganger til slaven.
EVE
51

Figur 34: Alarmbehandling.
Digitale utganger og alarmbehandling:
I denne programbiten har gruppen satt sammen alarmbehandlingen som blant annet
styrer en lampe på tank-riggen, med styring av pumpen og utløpene. Denne delen er
programmert ut ifra kravene fra prosjektoppgaven som nevnt tidligere. Under denne
delen av programmet vil det bli satt mange minneceller for de forskjellige
alarmtilstandene og ved kvittering. Dette gjøres for å utfylle kravene som er satt i
oppgaveteksten, og for å tilfredsstille behovet i iX-panelet og i InTouch.
Prosjektgruppen har valgt å utføre kravspesifikasjonene med en lampe som blinker i
alarmtilstand og forsinkelser, med hjelp av blant annet timere. I programbiten ovenfor
er det brukt både timere og setting av minneceller, som forklart ovenfor er for å hjelpe
iX-panelet og InTouch med sin alarmkontroll.
52

Figur 35: Alarmbehandling.
Alarmene kvitteres i HMI’ene, dermed vil en kvitteringsminnecelle i programmet
utføre oppgaver ut ifra oppgaveteksten. For eksempel vil alarmlampen slutte å blinke,
men den vil fortsatt lyse om systemet fortsatt er i alarmtilstand.
53

Figur 36: Alarmbehandling.
54

På forrige side ble programbiten som styrer lempen på tanken vist, Under kan du se
et bilde av den fysiske lampen som lyser under alarmtilstand.
Figur 37: Lampen på tank-riggen.
55

Figur 38: Alarmbehandling.
Om operatøren har kvittert for en alarm så skal ikke kvitteringen være aktiv for
eventuelle senere alarmer. I programbit 9 er det opprettet en del som vil resette
kvitteringsminnecellen om en ny alarm blir aktiv.
Figur 39: Styring av utløp på tank-riggen.
56

Figur 40: Flowmåleren som måler utløpet fra tanken og ventilene som styrer dette
EVE
57

6.6.2 Master-PLS:
Prosjektgruppen har tidligere under det store prosjektet vært igjennom et delprosjekt
som inneholder kommunikasjon. Under dette prosjektet ble en prosjektrapport levert,
som omhandler kommunikasjonen mellom master- og slave-PLS, HMI’ene og tank-
riggen. Derfor henviser prosjektgruppen til rapporten om det er ønsket mer
informasjon som omhandler kommunikasjonen. Der vil det også stå forklart
oppbyggingen av programmene som brukes under entanksprosjektet. Både i iX-
panelet, i InTouch og i PLS-programmet er det masse oppbygging, for eksempel i
PLS vil det brukes spesialblokker som står forklart i rapporten.
Master-PLS’en jobber i prosjektet som bindeleddet mellom slave-PLS’en som
behandler verdiene og HMI’ene som styrer systemet. I prosjektet skulle
prosjektgruppen programmere ut ifra diverse krav satt i oppgaveteksten. Mesteparten
av kravene vil bli løst i slave-PLS’en, men det er enkelte hendelser studentene har
behandlet i master-PLS’en.
De neste sidene inneholder en gjennomgang av prosjektgruppens program. Det har
blitt bestemt internt i gruppen at gjennomgangen vil inneholde bilder og forklaring
parallelt, så det blir enklest mulig oversikt. Det er også satt inn tekst i programmet,
som skal forklare nok til at man skal få god oversikt bare med bildene.
Figur 41: Bilde av master-PLS'en.
EVE
58

Hendelsessikring:
Slave-PLS’en vil sørge for at pumpen blir avslått om nivået kommer over 90%, men i
master-PLS’en vil minneceller sørge for at brukeren også i HMI’ene kan se at
pumpen er av. For at kvitteringen skal bli deaktivert når systemet har en ny
alarmtilstand må master-PLS’en sette kvitteringen til 0 for HMI’ene, når slave-PLS’en
registrerer en ny alarmtilstand.
Figur 42: Hendelsessikring.
I programbit 3 har prosjektgruppen opprettet ett dataregister for sending av
informasjon angående alarmtilstander til nettsiden.
EVE
59

Profibus:
Spesielt denne delen av entanksprosjektet er grundig gjennomgått under
miniprosjektet, og vil stå detaljert forklart i miniprosjektrapporten. Derfor henviser
prosjektgruppen til miniprosjektrapporten om grundigere informasjon innenfor dette
feltet er ønskelig.
EVE
Lesing fra Profibus:
På forrige side sto det forklart hvordan master-PLS’en bruker verdier fra slave-
PLS’en til å utføre viktige handlinger for for eksempel HMI’ene. For å klare disse
oppgavene krever det at master-PLS’en har mottatt informasjonen. HMI’ene skal
også vise hvilke verdier systemet har til enhver tid, disse verdiene leses også fra
Profibus. Master-PLS’en leser av: avviket, nivået, utløpet, diverse minneceller, det
manuelle pådraget, referansen, U0 og pådraget. Dette utføres via lesning fra Profibus
modulen som vist under.
Figur 43: Lesing av verdier fra Profibus med masteren.
60

Noen av verdiene som leses fra Profibus skal kun leses når visse krav er oppfylt. For
eksempel skal det manuelle pådraget kun avleses om regulatoren er satt til auto og
referansen skal kun avleses om regulatoren er satt til manuell.
Figur 44: Lesing av verdier fra Profibus med masteren.
EVE
Skriving til Profibus:
For å styre systemet er prosjektgruppen avhengig av at slave-PLS’en mottar
styringsverdiene operatøren skriver til HMI’ene. Denne oppgaven utføres ved at
master-PLS’en skriver mottatte verdier fra HMI’ene til Profibus, som senere leses av
slave-PLS’en. Under denne programbiten løser også prosjektgruppen et eventuelt
strømbrudd ut ifra kravene satt i oppgaveteksten.
Om systemet mister strømmen skal prosjektgruppen sørge for at systemet ved
oppstart skal regulere nivået riktig. Prosjektgruppen har løst dette problemet ved å
bruke dataregister som husker sine verdier, og ved å bruke hendelser som skjer kun
ved oppstart. Master-PLS’en skriver følgende verdier til Profibus: referansen,
samplingstiden, proporsjonal forsterkning, integrasjonstiden, KpFF, TdFF, U0, NFF,
diverse minneceller og det manuelle pådraget.
61

Figur 46: Skriving av verdier til Profibus med masteren.
Figur 45: Skriving av verdier til Profibus med masteren.
62

Prosjektgruppen har løst problematikken med at referansen ikke klarte å huske sin
verdi etter et strømbrudd fordi dataregisteret fikk en verdi fra avlesning fra Profibus.
Studentene har satt opp et nytt dataregister som husker sin verdi som hele tiden blir
satt lik referansen, og ved ett eventuelt strømbrudd vil en spesialblokk sørge for at
referansen får sin siste verdi ved oppstart. Denne metoden brukte prosjektgruppen
også på minnecellene, da huske-minnecellene ikke fungerte optimalt.
EVE
6.7 PID-regulator:
Som en tilleggsspesifikasjon er det laget en PID-regulator programmert med
programmeringsspråket strukturert tekst i programmet GX Works 2. PID-regulatoren
er en inverterende regulator og er laget slik at den kan implementeres i prosesser
hvor slike regulatorer trengs. Det at den er laget som en funksjonsblokk gjør at de
enkelt kan kopieres over i andre PLS-er. I tillegg er det mulig å bruke flere regulatorer
i samme PLS-program. For fleksibilitet er det mulig å kjøre regulatoren manuelt og en
kan velge om en skal bruke en P(D)- eller PI(D)-regulator.
Regulatoren er laget som en funksjonsblokk med inngangene og utgangene som en
PID-regulator trenger for å kunne regulere et system. Funksjonsblokka heter
PIDheltall da den er laget for å regne med heltall da mange PLS-er ikke regner med
desimaltall. Det er i mange tilfeller ønskelig å finjustere reguleringsparameterne i
regulatoren. For å ha muligheten til å stille inn variablene med en nøyaktighet på 0,1
må verdiene ganges med en faktor på 10 før de sendes inn på regulatoren. Denne
nøyaktigheten er kun tilgjengelig på inngangene SampTid, Kp, Ti og Td. De
resterende inngangene og utgangene er enten enkelt bit, eller 8-bits analoge verdier
Ved implementering i et program hentes regulatoren frem som en funksjonsblokk og
tildeles en variabel. Denne tildelte variabelen fungerer som en adresse for
regulatoren. Funksjonsblokka inneholder flere interne variabler og for at PLS-en, ved
bruk av flere regulatorblokker, skal kunne skille mellom variablene i hver enkelt blokk
må hver av blokkene ha hver sin adresse. Innhenting av PIDheltall-blokka gjøres i
GX Works 2 ved å skrive inn PIDheltall som vist i Figur 47. Eksempel på
implementering i et PLS-program ser du i Figur 48.
63

Figur 47: Innhenting av blokka PIDheltall.
Figur 48: Implementering av PIDheltall.
I Figur 49 er det, i tillegg til PIDheltall-blokka satt inn et hopp. Dette hoppet er for å
kunne sette samplingstiden til reguleringa. Det er ikke alltid ønskelig at regulatoren
skal kjøre en sampling for hvert scan-syklus i PLS-en da dette bruker unødig
datakapasitet.
Inngangene på PIDheltall er verdier regulatoren bruker til utregning av pådraget.
Pådraget er begrenset til et 8-bits analogt signal hvilket vil si heltall området 0 til 255.
Det er også forutsatt at verdiene inn på PV, SV, uNOM og uMAN er heltall i området
0 til 255. Den regulerte verdiens settes inn på PV-inngangen (ProsessVerdi). Om det
er nivået i en tank som skal reguleres, kobles nivåverdien inn på PV. Prosessens
referanse kobles til SV-inngangen (SkalVerdi) hvilket er den verdien en ønsker
prosessen skal ha. Samplingstiden som blir brukt for regulatoren må settes inn på
inngangen SampTid da regulatoren bruker denne verdien for å regne ut pådraget.
Prosessens avvik leses av på Avvik, mens pådraget leses av på utgangen u.
Ved valg av regulator type brukes PD_PID-inngangen. Dette skal være en verdi på
en bit (TRUE/FALSE). Dersom verdien er FALSE kjøres regulatoren som en PD-
regulator. Derimot om verdien på PD_PID er TRUE vil regulatoren kjøres som en
64

PID-regulator. For å koble ut derivasjonsdelen (D-delen) i reguleringa settes
inngangen Td til 0. For å kjøre regulatoren manuelt settes inngangen Auto til FALSE.
Dermed vil regulatorens pådrag bli satt lik inngangen uMAN. For automatisk
utregning av pådraget settes Auto til TRUE.
Variablene SV, uNOM og uMAN er definert som både innganger og utganger. Dette
sørger for rykkfri overgang mellom de forskjellige regulatorfunksjonene. Rykkfri
overgang forutsetter stabil prosess idet overgangen inntreffer.
Figur 49 viser en liste over alle variablene brukt i PIDheltall-blokka. I kommentarfeltet
står det beskrevet hvilke variabler som på multipliseres med en faktor på 10 før de
sendes inn i blokka.
Figur 49: Variabelliste for PIDheltall
Koden til blokka PIDheltall er lagt ved i Vedlegg om PIDheltall
BM
65

6.8 iX-panelet.
Prosjektgruppen skulle i prosjektperioden opprette et iX-panel for styringen av
systemet. I arbeidslivet ville iX-panelet stått ved prosessen og derfor ha blitt brukt
mest av operatører. Derfor skal det ikke være for stor grad av styring fra iX-panelet. I
oppgaveteksten var det spesifisert hva som skal være med i iX-panelet, både hva
som skal skrives og leses.
Tabell 3: Krav til iX-panelet
Prosjektgruppen har utført programmeringen av iX-panelet etter kravene i
oppgaveteksten og har fokusert på å holde en oversiktlig og ryddig design.
66

Prosjektgruppen jobbet i entanksprosjektet med en stor del av ett større prosjekt som
omfatter blant annet kommunikasjon. I kommunikasjonsdelen av prosjektet
programmerte studentene opp et enkelt iX-panel som var koblet til systemet via
Ethernet og prosjektgruppen viste i det prosjektet hvordan man snakker til tags og
sender verdier. Om leseren har interesse av kommunikasjonsbiten av prosjektet
henviser prosjektgruppen til miniprosjektrapporten der kommunikasjonen er forklart
grundigere, da entanksprosjektrapporten vil være mer overfladisk og omhandle
styringen av systemet. Prosjektgruppen har valgt å bruke en fast bakgrunn som gjøre
det lett å navigere mellom de forskjellige styringsvinduene.
Figur 50: Bakgrunn til iX-panelet:
Ingen spesiell design som kan lede bort fra viktige punkter og store knapper som
fører en videre til ønsket side. Det er lagt inn tidspunkt og dato som kan være
praktisk å ha med i en hvilken som helst prosess, for eksempel om noe skal kvitteres
eller noteres. Nede i høyre hjørne på bildet er det ett flagg som varsler om alarmer og
denne biten vil bli nevnt senere i rapporten.
67

Prosessen skal ikke være åpen for alle, derfor har prosjektgruppen opprettet en
innloggingsside og ordnet panelet på en måte som gjør minimalt med informasjon
tilgjengelig for utenforstående. Det eneste en tilfeldig forbipasserende skal få tilgang
til er trend-vinduet som viser hvilke verdier prosessen har. Prosjektgruppen har valgt
å opprette iX-panelet på denne måten så ikke utenforstående skal med eller uten
hensikt fjerne viktige beskjeder eller styre systemet.
Figur 51: Innloggingsside til iX-panelet.
Når en skal hindre tilgang til komponenter eller sider på iX-panelet må man gå inn på
den gjeldende siden eller enheten å skrive inn en kode for at en valgt gruppe har
tilgang.
Figur 52: Betingelse ved innlogging.
68

Prosjektgruppen har valgt å kalle sin gruppe for «Gruppe1», som er den eneste
gruppen som har tilgang til iX-panelet. «Gruppe1» kalles for «Operators» i iX-panelet
og det er den gruppen studentene har jobbet med når de har laget begrensninger iX-
panelets innsyn.
Figur 53: Sikkerhetsgruppe.
For å ha et system som er enklest mulig å jobbe med, har prosjektgruppen satt
betingelser for det meste som en kan foreta seg. Om iX-panelet ikke brukes på 5
minutter har prosjektgruppen bestemt at brukeren automatisk skal logges ut, så det
da ikke er åpent for andre om operatøren har forlatt prosessen. Det er også
programmert slik at om brukeren uten innlogging prøver å få tilgang til en låst del av
prosessen, vil brukeren få beskjed om at innlogging kreves for å få tilgang.
Figur 54: Sikkerhetsbetingelser.
69

Det man har sikkerhetsklarering til å se uten innlogging er trend-vinduet. Det er en
side på iX-panelet der du har oversikt over de forskjellige verdiene i kretsen i sanntid.
Også i trend-vinduet har prosjektgruppen lagt vekt på et oversiktlig og enkelt bilde,
som gir brukeren en behagelig opplevelse.
Figur 55: Trendvinduet i iX-panelet.
I trenden vises Referansen i grønt, nivået i blått og utløpet i rødt. Valget av farger er
bestemt da de ikke er like på noen som helst måte, og er lette å se med den hvite
bakgrunnen i trend-vinduet. Prosjektgruppen har også bestemt bakgrunnen til trend-
vinduet til hvit, så det skal være så enkelt som mulig. Studentene har programmert
inn to knapper for bedre oversikt over hva som skjer på trenden. Den ene knappen
som heter «Vis legend», vil vise brukeren verdiene på referansen, nivå og utløp i et
popup-vindu. Prosjektgruppen ønsker også å kunne gå tilbake i tid for å få oversikt
over hvordan prosessen har blitt styrt tidligere. Dette kan de gjøre med «Endre
tidsakse» knappen som fungerer som enn inn- og ut-zoom.
70

Prosessvinduet er der brukeren får inn mest informasjon. På grunn av all den
informasjonen som skulle inn på begrenset plass valgte prosjektgruppen å holde det
som resten av iX-panelet, enkelt og oversiktlig.
Figur 56: Prosessvinduet i iX-panelet.
I prosess-vinduet skal alt av styring foregå, bortsett fra kvittering av alarmer. Det er
også i prosess-vinduet operatøren vil finne all avlesning fra prosessverdier.
Prosjektgruppen har valgt å gjøre alle komponenter tydelige, som for eksempel
bryterne som styrer pumpen og manuell- og automatisk-regulator styring. De er store
og om de aktiveres vil bryteren slå opp så du også kan se at bryteren ligger inne. Alt
av smådetaljer har prosjektgruppen programmert for å gi en mest mulig behagelig
opplevelse ved prosesstyringen.
Innstillingen av manuelt pådrag skal kun kunne utføres om regulatoren står i manuell.
Derfor har studentene valgt at ruten og teksten for innstilling av manuelt pådrag vil
være borte helt til regulatoren ikke står i auto.
71

Figur 57: Betingelser for synlighet.
På samme måte skal referansen ikke kunnes stilles ved manuell kjøring, da den får
tilgitt prosessverdien av PLS-en. Derfor har studentene valgt at ved manuell kjøring
så skal det ikke være mulig å stille inn referansen. Både slideren og ruten for
referanse innstilling vil bli «read only» som betyr at du kan lese av verdien, men ikke
stille den selv.
Figur 58: Betingelser for styring.
72

Prosjektgruppen har lagt stor vekt på at programmet skal være lett forståelig, og
derfor har de også dannet animasjoner så brukeren skal kunne se hva som hender i
systemet. Tanken vil fylle seg likt med prosessverdien i den fysiske tanken, og når
brukeren har referanse slideren ved siden av tanken så vil man fort få oversikt i om
tanken stiller seg inn til angitt referanse.
Det er også mange ventiler og en pumpe som prosjektgruppen har tatt hensyn til. Når
pumpen er aktiv vil den på iX-panelet lyse grønt så brukeren forstår at pumpen er i
gang. Dessuten vil alle ventiler som er åpne bli grønne og en signal-lampe vil tennes,
samtidig som brukeren kan avlese verdien for åpningen av ventilene. Både pumpen
og ventilene vil være grå når den ikke er aktiv eller åpen, og lampene for ventilene vil
ikke være tent.
Figur 59: Ved aktive- og inaktive-enheter.
73

Den siste delen av iX-panelet som prosjektgruppen har programmert er
alarmbehandlingen. I iX-panelet er det mange skjulte hendelser som også er forklart
tidligere i rapporten, men under alarmbehandling vil den største delen av skjulte
hendelser foregå.
Figur 60: Alarmvinduet i iX-panelet.
Selve alarmbildet er ferdigstilt i iX-panelet, med alle knapper og utseende. Derfor har
ikke prosjektgruppen jobbet med denne delen når det gjelder alarmene, det er selve
programmeringen om hva som skal utløse alarmer og hva som skal skje ved de
forskjellige alarmene.
74

I oppgaveteksten er det forklart hva som skal utløse alarmer. Om nivået i tanken
avviker mer enn 25 % fra referansen skal det gå vanlig alarm. Kritisk alarm skal
aktiveres dersom det absolutte nivået overstiger 90 % eller går under 10 %. Hvis
prosessen går ut av alarmtilstand uten at alarmen er kvittert, skal lampen fortsette å
blinke inntil alarmen er kvittert.
Figur 61: Alarmsituasjon under kjøring.
Figur 62: Alarmer i iX-panelet
75

Inne i oppbyggingen av programmet velges det ut at det skal være tre
alarmtilstander, iX-panelet vil motta verdier fra slave-PLS’en om det er alarmtilstand
via tag’ene: alarm- 1,2 og 3. Deretter har prosjektgruppen satt opp betingelser for
hver enkelt alarm, over hva som skal skje når den bestemte alarmen slår inn og hva
som skjer når den ikke lenger er aktiv eller når den blir kvittert. Dersom nivået avviker
referansen i tanken mer enn 25% vil alarm1 bli satt høy i slave-PLS’en og iX-panelet
vil registrere alarmtilstand. Deretter vil brukeren bli varslet med et popup-vindu, en
lampe og et flagg.
Figur 63:Alarmbetingelse og pop-up vindu
76

Figur 64: Alarmbetingelse i iX-panelet.
Deretter om alarmen blir inaktiv før brukeren har vært på iX-panelet vil popup-vinduet
automatisk krysses ut, og alarmoversikt-vinduet vil vises. Der vil brukeren ha
fullstendig oversikt, og kan kvittere for eventuelle aktive eller inaktive alarmer.
Flagget vil vises helt til brukeren har kvittert for både aktive og inaktive alarmer. Dette
har prosjektgruppen bestemt med tanke på at lampen vil blinke helt til det blir kvittert.
Figur 65: Popup-vinduer ved nivå over 90 % og under 10 %.
77

Flagget styres med en alarm-tag som aktiveres hver gang en ny alarm aktiveres, og
som deaktiveres hver gang alle alarmer blir kvittert. Mens alarm indikatoren kun vil
lyse om en alarm er aktiv og vil forsvinne om en alarm ikke lenger er aktiv.
Figur 66: Alarmbetingelser i iX-panelet.
iX-panelet skal samkjøres med InTouch programmet ved alle aspekter i systemet,
dermed også alarmene. Om operatøren kvitterer en alarm i iX-panelet skal alarmen
også kvitteres i InTouch og omvendt. Derfor har prosjektgruppen opprettet en
fjernstyring av kvitteringene, ved å sette inn den samme tagen som brukes i begge
HMI’ene.
EVE
78

6.9 Webkamera til InTouch
For å koble webkameraet til InTouch er port-forward brukt.
TIB
6.9.1 Port i webkamera:
For å sette eller «fremheve» en port til webkameraet, last ned
IPsetupProgramV1_4_1_10. Dette er et program som brukes for å sette porter på
Sony sine web-kamera. Programmet ligger på hjemmesiden til Sony:
http://pro.sony.com/bbsc/ssr/mkt-security/resource.downloads.bbsccms-assets-cat-
camsec-downloads-SecurityDownloadsIPCameraTools.shtml
Installer programmet og koble deg serielt til kameraet via en ethernet-kabel. Du vil da
få opp et vindu som vist i Figur 67: Port-webkamera..
IP-adressen til webkamera vil automatisk komme opp når du kobler deg til. Sett et
port-nummer til webkameraet. Vi har valgt å bruke(fremheve) Port nr. 6668, som
burde være i området rundt 6000-7000 for å være sikker porten ikke er i bruk av et
annet program.
Skriv inn brukernavn og passord. Dette er samme passord og brukernavn som gir
tilgang til routeren. Trykk OK for å lagre innstillingene.
79

Figur 67: Port-webkamera.
TIB
80

Port i ruteren
Når porten i webkameraet er fremhevet eller satt, må samme port bli fremhevet i
ruteren. For å sette eller fremheve en port i ruteren, må du koble deg serielt til ruteren
via ethernetkabel. Åpne en web-leser og skriv inn IP-adressen til ruteren.
Du vil da få opp en boks lik Figur 68: Innlogging på ruter., og på denne skal du skrive
inn brukernavn og passord til ruteren. Når brukernavn og passord er godtatt vil et
vindu som blir likt Figur 69: Port-ruter. dukke opp. Denne gir tilgang til ruterens
innstillinger.
Figur 68: Innlogging på ruter.
For å fremheve en port i ruteren for webkameraet, gå til Advanced – Virtual Server,
og skriv inn IP-adressen til webkameraet i feltet Private IP. Sett Port-nr. 6668.
Huk av Enabled og trykk Apply for å lagre innstillinger.
81

Figur 69: Port-ruter.
Videre vil du få opp kamera i listen som vist i figur Figur 70. En port i ruteren er da
fremhevet for web-kameraet.
Figur 70: Port-router-kamera.
For at en annen datamaskin som vil ha tilgang til webkamera, kan den skrive i en
web-leser: http://158.38.53.252:6668/home/JViewer.html. Datamaskinen vil da få
tilgang til port-nr.6668 hvor webkameraet ligger, og vil få sendt bilde fra webkameraet
gjennom ruteren.
TIB
82

6.10 InTouch
6.10.1 Intro
Ut fra arbeidsbeskrivelsen var det ønskelig å ha et operatørgrensesnitt på PC som
prosessen skulle kunne styres- og overvåkes fra. Grensesnittet skulle utvikles i
programmet InTouch. Programmet skulle inneholde flere forskjellige vinduer der
operatør kan få nødvendig informasjon, og utføre eventuelle tiltak.
FS
6.10.2 Beskrivelse av oppgave
I arbeidsbeskrivelsen stod det hva de forskjellige vinduene skulle inneholde. Et av
vinduene skulle inneholde et prosessbilde der det blant annet skulle fremkomme
informasjon om pumpens tilstand, nivå i tankene, pådrag og alarmtilstander. Det
skulle også være et vindu for lesing/logging av alarmer. Eventuelle alarmer skal
kunne kvitteres mot PLS. Et eller flere vinduer skulle lages for sanntidstrender, og et
eller flere vinduer skulle lages for å vise historiske trender. Programmet skulle også
inneholde et vindu for innlogging der operatøren må logge seg inn med eget passord.
De forskjellige brukerne av programmet skulle være OPERATØR1, OPERATØR2 og
OPERATØR3, med henholdsvis passordene Op1, Op2 og Op3. Videre ble det
presentert en tabell i arbeidsbeskrivelsen som beskriver hvilke rettigheter de
forskjellige brukerne av programmet skulle ha.
83

FS
Tabell 4: Rettigheter for forskjellige operatører i InTouch
84

6.10.3 Tanker rundt det endelige grensesnittet.
I gruppen kom vi frem til at vi så det som mest hensiktsmessig å ha et stilrent,
oversiktlig og ryddig grensesnitt. Bakgrunnen for det var en forelesning vi hadde i
nettopp InTouch der kurshaver fortalte om sine erfaringer med utvikling av grafiske
grensesnitt og hva kunden og operatørene erfaringsmessig ble fornøyd med. På
bakgrunn av erfaringene vi gjorde oss på forelesningen samt praktisk erfaring med
brukergrensesnitt fra enkelte av gruppemedlemmene utformet vi et grensesnitt vi tror
vil tilfredsstille arbeidsbeskrivelsen.
FS
6.10.4 De ulike vinduene.
Figur 71: Innloggingsvinduet
I innloggingsvinduet vil brukeren av programmet få muligheten til å logge seg inn. Det
er i dette vinduet at rettighetene til brukeren bestemmes ut i fra om brukeren har
tilgang på OPERATØR1, OPERATØR2 eller OPERATØR3 kontoen.
85

Figur 72: Operatør3 vinduet
Figur 73: Operatør2 vinduet
86

Figur 74: Operatør1 vinduet
OPERATØR3 er den brukeren som har alle rettigheter for styring av prosessen. Hvis
man sammenligner vinduene for de ulike operatørene ser man hvordan funksjonene
endres. Enten ved at skrivefunksjoner endres til kun å være lesbare, eller ved at dem
fjernes helt fra vinduet. Dette i henhold til arbeidsbeskrivelse og tabell for rettigheter
for de forskjellige brukerne.
Figur 75: Sanntidstrendvinduet
87

I sanntidstrendvinduet får brukeren av programmet en grafisk fremstilling av hvordan
referanse, nivå i tank og pådrag har forandret seg det siste minuttet.
Figur 76: Historisk trendvindu
I historisk trendvinduet får brukeren av programmet en grafisk fremstilling av hvordan
referanse, nivå i tank og pådrag har forandret seg historisk. I dette vinduet kan
brukeren se tilbake i tid, måle kurvenes verdi og i større grad analysere prosessen
sammenlignet med sanntidstrenden.
Figur 77: Alarmhistorikkvinduet
88

I alarmhistorikkvinduet blir alarmer registrert og vist i tabell. Her kan bruker få
informasjon om hvilken alarm som ble utløst, ved hvilket tidspunkt, om alarmen ble
kvittert mens prosessen var i alarmtilstand, hvilken prioritet alarmen har m.m.
Figur 78: Kameraovervåkningsvinduet
I kameraovervåkingsvinduet får brukeren mulighet til å overvåke prosessen live
gjennom et kamera. Ut fra bildene håper vi at du som leser får et visst inntrykk av
hvordan grensesnittet vil fungere. Gjennomgående i alle vinduene, foruten
innloggingsvinduet, har vi menyen for hvilket vindu brukeren ønsker å entre,
prosessbildet og alarmtilstander. I arbeidsbeskrivelsen var det ikke satt noe krav til at
alarmtilstander og prosessbildet skulle være i alle vinduene. Vi i gruppen kom frem til
at dette kunne være hensiktsmessig for å gi brukeren full oversikt over prosessen til
enhver tid, uavhengig av hvilket vindu brukeren er inne på. I prosessbildet får man en
rask oversikt over hvordan nivået i tanken er i forhold til innstilt referanse, hvor
mange av magnetventilene som er åpne, pumpetilstand, hvor mange prosent utløp
og prosent pådrag. Ut fra prosessbildet får man også en hvis grafisk informasjon om
hvordan prosessen er satt sammen. Dette for å gjøre det enklere for vedlikeholds
personell å kunne raskt finne eksempelvis hvor nivåmåleren sitter (bunntrykksmåler i
dette tilfellet) ved eventuell reparasjon eller utskifting.
FS
89

6.10.5 Indikasjoner
For å indikere pumpetilstand og tilstand til ventiler har vi i gruppen valgt å bruke
grønn bakgrunnsfarge når pumpen går, og grønn bakgrunnsfarge når en ventil er
åpen. Vi har også implementert en liten animasjon når pumpen går der korset i
midten roterer. Ved pumpestopp og stengt ventil er bakgrunnsfargen valgt til grå. Ved
alarmer har vi valgt å bruke rød farge. Dette for at brukeren raskt skal skjønne at nå
er tilstanden til prosessen unormal, og krever brukers oppmerksomhet. De fleste
kjent så er jo rødt en farge som ofte er forbundet med faresituasjoner i dagliglivet.
FS
6.10.6 Kommunikasjon
InTouch som grafisk grensesnitt på PC må kommunisere med PLS for at prosessen
skal kunne styres. Dette skjer først ved at et program kalt OPC-server blir satt opp til
å kommunisere med PLS. I OPC-serveren blir det opprettet såkalte tags som er
knyttet opp mot dataregistre og minneceller i PLS og gjør det mulig å skrive til dem
fra PC. Deretter settes det opp et program som muliggjør kommunikasjon mellom
OPC-server og InTouch. Dette programmet heter OPC-Link og fungerer da som
bindeleddet, tolken om du vil, mellom OPC-server og InTouch. Når både OPC-server
og OPC-Link er satt opp starter man opp et lite tilleggsprogram i InTouch kalt OPC
Tag Creator. I dette programmet hentes taggene som ble opprettet i OPC-server inn
til InTouch. Når taggene er hentet inn til InTouch er dem klare for å bli knyttet til det
grafiske grensesnittet, og kan dermed skrive til- og lese fra PLS.
90

Figur 79: InTouch I
For utfyllende info om hvordan oppsett av OPC-server, OPC-Link og innhenting av
tagger til InTouch via OPC Tag Creator vil vi henvise leseren til Miniprosjektrapport
kapittel 6.5.1.
FS
6.10.7 InTouch, AD/DA og skripting
I prosessen har slave-PLS’en en AD/DA modul på 8 bit. Det vil si at ved sending og
mottak av analoge signal i slave-PLS (0-20 mA) vil de analoge signalene bli omgjort
til et heltall med verdi på mellom 0-255. I brukergrensesnittet ville vi i gruppa omgjøre
disse verdiene til verdier som tilsvarer 0-100 % i brukergrensesnittet. Vi hadde også
andre tilfeller der vi ønsket å skalere enkelte tagger opp om de skulle leses av PLS
(PLS kan ikke håndtere desimaltall direkte), eller ned om taggen skal leses av i
InTouch. I den forbindelse ble vi i gruppa enige om å skrive en del skript i InTouch for
omregningen.
FS
91

6.10.8 Skript
For å oppnå ønsket resultat på skriptene måtte vi opprette lokale tagger i InTouch.
Følgende vil nå vise deg et eksempel på hvordan det ble gjort:
Figur 80: InTouch II
I InTouch går mann inn på fanen Special >> Tagname Dictionary. Da kommer
vinduet øverst på bildet opp. Velg New og fyll inn ønsket navn, i dette tilfellet
Kp_lokal_skriv. Etterpå velger du hvilken datatype den lokale taggen skal være, her
memory real siden vi ønsker at tallet skal kunne være desimaltall. Trykk OK og Save.
Du har nå opprettet en lokal tag.
PLS kan ikke direkte håndtere desimaltall, og måten det ble løst på var at verdier inn
til PLS ble multiplisert med en faktor på 10 (i dette tilfellet) for å bøte på problemet.
Deretter ble videre utregning utført i PLS-program. Følgende vil vise deg hvordan det
ble gjort i InTouch:
92

Figur 81: InTouch III
Vi ønsker å bestemme verdien til proporsjonalforsterking, Kp, i regulator fra InTouch.
Denne verdien sendes til PLS via taggen kalt Kp. I skriptet (data change script) på
bildet ser du hvordan det skjer ved at det er opprettet en lokal tag kalt Kp_lokal_skriv
av typen memory real (håndterer desimaltall) som multipliseres med en
skaleringsfaktor på 10. Dette for at bruker i InTouch skal ha muligheten til å ha med
et tall bak komma i verdien til Kp. I InTouch knyttes taggen Kp_lokal_skriv til der
bruker taster inn ønsket verdi til Kp. Deretter sendes Kp til PLS med rett verdi for
videre regning i PLS-program.
93

For å kunne presentere den riktige verdien til Kp i InTouch må vi gjøre det omvendt.
Følgende vil vise deg hvordan det ble løst:
Figur 82: InTouch IV
Først ble det opprettet en lokal tag kalt Kp_lokal_les av typen memory real. Denne
taggen knyttes til det grafiske grensesnittet for å vise hva Kp er i tallverdi. Siden Kp
er skalert opp med en faktor på 10 må Kp divideres på 10 for å vise den riktige
verdien i InTouch. Skriptet som ble skrevet er av typen data change script, og koden
vises i bildet.
I enkelte andre tilfeller som for eksempel tallverdi på referanse var det ønskelig å
kunne angi 0-100 % nivå i tanken. For enklere utregning i PLS-program ble vi i
gruppen enige om at verdien på referanse inn til PLS skulle være fra 0-255, og
omregningsfaktoren ble da 2,55.
Disse omregningene måtte gjøres på en rekke variabler, men fremgangsmåten for
alle er lik eksemplene presentert her.
For å tydeliggjøre når pumpen er i drift spurte vi arbeidsgiver om det kunne være
aktuelt å implementere en animasjon som viste det. Arbeidsgiver sa det ville være et
designvalg, og vi valgte derfor å ha det med for å tydeliggjøre pumpens tilstand.
Følgende vil ta deg gjennom hvordan det ble gjennomført:
Vi startet med å lage en lokal tag kalt rotasjon. Deretter ble det laget et condition
skript:
94

Figur 83: InTouch V
Vilkåret for at skriptet skal kjøres er som bildet viser at Pumpe (en tag) == 1. Her vil
rotasjon’s taggen øke med 5 helt opp til 360, for deretter å bli resatt til 0. Økningen
skjer her hvert 100 msek. Taggen rotasjon brukes videre på korset inne i
pumpeikonet.
Figur 84: InTouch VI
Dobbeltklikk på korset, og du får opp bildet:
Figur 85: InTouch VII
95

Huk av på orientation og konfigurer som vist på neste bilde:
Figur 86: InTouch VIII
Pumpeanimasjonen er nå ferdig konfigurert.
FS
96

6.10.9 Smarte valg og problemområder
InTouch overskriver verdier fra iX-panelet, og Application Scripts.
For å sende og motta verdier til og fra PLS var vi litt usikre på hvordan vi skulle gjøre
det siden PLS ikke kan håndtere kommatall uten videre, og i InTouch ville vi ha
muligheten for at bruker skulle kunne taste inn kommatall for enkelte verdier. I
enkelte andre tilfeller ville vi også skalere opp tallverdien fra InTouch fra å gå fra 0-
255.
Vi prøvde først med å legge de aktuelle verdiene i skript som oppdateres med jevne
mellomrom (application script) og regnet ut ønsket verdi. Dette skriptet fungerer som
en while-sløyfe og vil skrive med jevne mellomrom til PLS. Samtidig ønsket vi å
regne om verdien fra PLS for at rett tallområde skulle vises i InTouch. En annen ting
som ble vanskelig med while-sløyfe løsningen var at verdier til PLS fra InTouch ble
oppdatert med jevne mellomrom noe som gjorde det umulig å sende verdier fra iX-
panelet til PLS siden InTouch skrev over dem. Dette viste seg å være en vanskelig
måte å løse det på, og vi kom derfor frem til en bedre løsning ved å opprette lokale
tagger i InTouch som kunne brukes til mellomregninger. Vi slapp da også å bruke
application scripts noe som løste problemet med at InTouch overskrev iX-panelet.
FS
Flowmåler
Riggen er utstyrt med en flowmåler som måler utstrømning fra tanken. På riggen er
det også montert et display som kan vise utstrømningen i % eller i liter/time. Ønsket
fra gruppen var at vi i InTouch skulle kunne lese av hvor mange liter /time
utstrømning vi hadde til en hver tid. Fra PLS kom verdien til InTouch fra flowmåler
med en verdi fra 0-255. I InTouch regnet vi om verdien slik at vi hadde sirka samme
verdi som displayet viste. Dette skulle vise seg å endre seg med ujevne mellomrom
når vi testet på riggen, og det som skjedde var at displayet og verdien vist i InTouch
ikke stemte overens, noe den hadde gjort før. Vi tilkalte lab ingeniør Andreas Sørvik
for hjelp, men han kunne ikke finne ut hva som var feil. Flowmåler var kalibrert slik at
100 % utløp var ved sirka full tank og tre ventiler åpne, noe som var en grei
kalibrering, men verdien på liter/time som displayet viste endret seg. Vi tok derfor en
beslutning om å vise % utløp i InTouch siden det så ut til å være stabilt.
FS
97

6.10.10 Symbolbruk i InTouch
Ved bruk av enkelte symboler i InTouch, særlig med tanke på inkrementeringspiler
fikk vi i gruppen en del problemer. Det lå som regel i at ferdige symboler ikke har den
friheten til å gjøre alt man vil med et symbol. Det største problemet var at i enkelte
tilfeller ønsket vi å skjule pilene om brukeren av grensesnittet ikke skulle ha
muligheten til å taste inn en verdi. Det kunne vi ikke umiddelbart bare gjøre. Her
måtte vi først bryte symbolet for så å endre på synligheten til symbolet. Likevel ville
ikke synligheten for hele objektet forsvinne. Etter hvert fant vi en løsning på
problemet, men sett i ettertid hadde vi muligens foretrukket å lage symbolene med
kode selv for rett og slett å spare tid.
FS
6.10.11 Design
På prosessbildet ønsket gruppen at bildet skulle gi en god visuell beskrivelse av
prosessen. Noe som kanskje virker selvsagt er valg av høyden på referansemåler på
bildet. Dette var et bevisst valg ut fra hvor høy nivåmåleren på prosessbildet er.
Tanken med å ha samme høyde var at man rent visuelt skulle kunne sammenligne
nivået mot referansen.
Andre bevisste valg som ble tatt var indikasjon på hvilke ventiler (gjelder ikke for
OPERATØR1) som er åpne ved å ha grønn bakgrunnsfarge ved åpen ventil og grå
bakgrunnsfarge ved stengt ventil. Det samme gjorde vi på pumpen der grønn
bakgrunnsfarge betyr pumpe i drift og grå bakgrunnsfarge betyr pumpe stoppet. I
tillegg implementerte vi en animasjon i pumpen for ytterligere å synliggjøre drift eller
ei.
FS
98

6.10.12 Forbedringsmuligheter
Sett i ettertid kunne tidsbruken på å lage grensesnittet vært redusert. Dette grunnet
at mye tid i starten gikk til å gi grensesnittet et pent utseende, plassere ting i forhold
til hverandre og så videre. Etter hvert som vi oppdaget flere ting som måtte endres på
måtte bildene flyttes på og utseende vi hadde brukt tid på fra før av var bortkastet.
Erfaringer vi gjorde oss fra dette er at vi neste gang ikke bruker for mye tid på å få
ting til å se 100 % perfekt ut i starten, og heller venter til grensesnittet er omtrent
ferdig testet. På den måten får man også testet litt av grensesnittet etter hvert så
deler av det kan anses ferdig og dermed perfeksjoneres.
FS
6.10.13 Fremgangsmåte
Kameraovervåking
I gruppen ble vi enige om å prøve oss på bonusoppgaven «Kameraovervåking av
tankriggen via internett og kameraovervåking som eget vindu i InTouch», og vi skal
her ta for oss hvordan vi implementerte kameraovervåkingen i InTouch. For å få opp
vinduet til kameraet i InTouch måtte vi ta i bruk ActiveX. Siden vi ønsket å hente
kamerabildet over internett brukte vien Internet Explorer basert ActiveX kontroller
som vi måtte legge til InTouch.
Figur 87: InTouch IX
99

For å legge inn ActiveX kontrolleren velger du fanen «Special >> Configure >>
Wizard/ActiveX Installation…» som vist på bildet.
Figur 88: InTouch X
Nå får du opp en meny som vist på bildet. Her velger du «Microsoft Web Browser».
Figur 89: InTouch XI
Etterpå kan du finne ActiveX kontrolleren under «Wizard Selection».
100

Figur 90: InTouch XII
Legg til ActiveX kontrolleren på en ny side. På dette bildet vises det som den hvite
ruten i bakgrunnen på bildet. Nå kan du dobbeltklikke på ActiveX kontrolleren og
legge til et navn til den. Lag også en knapp (button).
Figur 91: InTouch XIII
Dobbeltklikk på knappen og velg «Touch Pushbuttons» og undermenyen «Action».
101

Figur 92: InTouch XIV
Trykk deretter på «Insert >> ActiveX…» Deretter velger du det navnet du kalte
ActiveX kontrolleren, og finner under «Method / Property» det som kalles for
«Navigate(«String», «Pointer», «Pointer»… og velg OK.
Figur 93: InTouch XV
Etterpå skal du ha noe slikt som vist på bildet. Bytt ut «String» med adresse til
kameraet (her http://158.38.53.252:6668/home/AViewer.html), og slett resten slik at
det blir som angitt. Da er kameravinduet ferdig konfigurert og vil vise bildet til
kameraet i InTouch når man trykker på knappen.
FS
102

Innlogging og forskjellige innloggingsnivå.
Det er i innloggingsvinduet det bestemmes hvilke rettigheter de forskjellige
operatørene skal få til grensesnittet. «OPERATØR1» har minst rettigheter,
«OPERATØR2» har litt flere rettigheter og «OPERATØR3» har alle rettigheter.
Oppsettet av dette er som følger:
Figur 94: InTouch XVI
Velg fanen “Special >> Security >> Select Security Type >> InTouch”.
Figur 95: InTouch XVII
103

Velg samme sti igjen men gå inn på «Log On».
Figur 96: InTouch XVIII
Da får du opp dette vinduet, og logger på med brukernavn «administrator» og
passord «wonderware».
Figur 97: InTouch XIX
Gå inn på samme sti igjen, men velg «Configure Users…».
Figur 98: InTouch XX
Da får du opp denne menyen, og her legger du inn «OPERATØR1», passord «Op1»
og «Access Level «: «1000», «OPERATØR2», passord «Op2» og «Access Level:»
«2000» og «OPERATØR 3», passord «Op3» og «Access Level:» «3000».
104

Figur 99: InTouch XXI
Lag deretter en knapp som heter «Logg på». Konfigurer knappen til å være en
«Touch Pushbutton» med undermeny «Action». Skriv inn som på bildet. Dette vil
gjøre at når du trykker på knappen «Logg på» så vil et popup vindu komme opp der
bruker kan taste inn brukernavn og passord. Hvis brukernavn og passord er korrekt
vil brukeren bli logget inn med den access levelen som ble assignert til den repektive
brukeren.
Figur 100: InTouch XXII
Etterpå lager du 3 knapper som heter «Fortsett», en for hver bruker. Deretter går du
inn en knapp på Miscellaneous og undermenyen Visibility og får opp menyen på
bildet. Her skriver du også inn som vist på bildet for «OPERATØR3». Gjør det
samme med de to andre knappene og «OPERATØR2» og «OPERATØR1», men bytt
ut «>=» med «==». Etterpå plasserer du knappene oppå hverandre.
105

Figur 101: InTouch XXIII
Figur 102: InTouch XXIV
106

Videre går du inn på de tre knappene igjen, en etter en, og velger «Touch
Pushbuttons» og undermenyen «Show Window» og send så brukeren til det vinduet
du vil, her sender jeg «OPERATØR3» til «Operatør3» vinduet. Vår struktur i
programmet ser omtrent slik ut:
Operatør1
Sanntidstrend1
Historisktrend1
Kameraovervåking1
Alarmhistorikk1
Innlogging
Operatør2
Sanntidstrend2
Historisk trend2
Kameraovervåking2
Alarmhistorikk2
Figur 103: InTouch XXV
Operatør3
Sanntidstrend3
Historisk trend3
Kameraovervåking3
Alarmhistorikk3
107

Her ser man at så lenge man er pålogget som en bruker vil man være uavhengig av
de andre brukerene av grensesnittet.
Figur 104: InTouch XXVI
Videre lager du en knapp som du kaller «Logg ut». Siden vi kun vil vise denne
knappen hvis det allerede er en bruker som er logget inn går vi inn på
«Miscellaneous» og undermenyen «Visibility». Skriv inn som på bildet. Da vil
knappen kun være synlig ved om en bruker med «Access Level» større eller lik
«1000» ha mulighet for å se knappen, og siden vi kun har brukere i dette systemet
med «Access Level» større eller lik «1000» vil alle brukerne kunne se den såfremt
dem er innlogget.
Figur 105: InTouch XXVII
Etterpå ønsker vi å gå inn på «Touch Pushbuttons» og undermenyen «Action». Her
skriver du inn som på bildet. Denne koden vil utføre en utlogging av den brukeren
som er innlogget.|
FS
108

Sanntidstrend
For å lage sanntidstrend i InTouch klikker du på et ikon i windowmaker som heter
«Real-Time trend». Deretter drar du ut et bilde slik du vil at sanntidstrenden skal
være. Klikk deretter på trenden og du har da fått opp slik som på bildet.
Figur 106: InTouch XXVIII
Her kan man gjøre forskjellige innstillinger, men i hovedsak må vi fylle ut der det står
«Pens:». Der legger vi inn de forskjellige taggene som skal vises i
sanntidsdiagrammet. Sanntidstrenden er nå ferdig.
FS
109

Historisk trend
Figur 107: InTouch XXIX
For å kunne lage en historisk trend må vi finne ut av hvilke tagger vi ønske og logge.
Vi finner derfor frem de forskjellige taggene i «Tagname Dictionary». Her i bildet har
vi funnet frem taggen referanse, og vi huker av der hvor det står «Log Data». Vi
bestemmer også Min Value og Max Value, her 0-100.
Figur 108: InTouch XXX
Etterpå henter vi ut «Hist Trend w/Scooters and Scale» i Wizard Selection under
menyen Trends. Og plasserer den i det vinduet vi ønsker å ha den i.
Figur 109: InTouch XXXI
110

Dobbeltklikk på trendvinduet, og trykk p «Suggest». Da vil «Hist Trend» og «Pen
Scale» navnene endre seg.
Figur 110: InTouch XXXII
Nå ønsker vi å legge til styringer flere muligheter i trendvinduet, som for eksempel
zoom. Vi velger da «Trend Zoom/Pan Panel» fra Wizard Selection».
Figur 111: InTouch XXXIII
Vi dobbeltklikker vi på «Trend Zoom/Pan Panel» og trykker på «Suggest». Nå er det
viktig at navnene vi får er de samme som vi fikk da vi lagde den historiske trenden.
Det for at de skal høre sammen og at for eksempel zoom funksjonen skal fungere i
rett historisk trend vindu.
111

Figur 112: InTouch XXXIV
For å kunne lese av kurvene med større nøyaktighet legger vi til en «Trend Pen
Legend» for hver tagg vi ønsker å logge. Her får vi også informasjon om hvilken farge
på kurven den tilhører.
Figur 113: InTouch XXXV
Etterpå klikker vi oss inn på «Trend Pen Legend» og får opp menyen som på bildet.
Her klikker vi igjen på «Suggest», og passer på at navnene er de samme som for de
andre konfigurasjonene ovenfor. Vi ser her at vi også velger hvilket «Pen Number» vi
vil asosiere med den «Trend Pen Legend» vi konfigurerer. Det vil si hvilken tagg som
skal tilhøre denne «Trend Pen Legend».
112

Figur 114: InTouch XXXVI
For å kunne lagre de historiske dataene ønsker vi å ha med «HistData Wizard».
Figur 115: InTouch XXXVII
Vi konfigurerer «HistData Wizard ved å dobbeltklikke på det, og menyen som på
bildet kommer opp. Her passer vi igjen på å klikke på «Suggest» og ser til at vi får det
samme navnet igjen. Vi kan også konfigurere «Numbers of Records to Write per CSV
File:». Det vil si hvor mange ganger du ønsker å få logget kurvene mellom to punkter
som du kan bestemme i historisk trendvinduet.
113

Figur 116: InTouch XXXVIII
Til slutt beveger vi oss inn på fanen «Special >> Configure >> Historical Logging».
Figur 117: InTouch XXXIX
Her huker vi av for «Enable Historical Logging», og legger inn ønsket plassering for
hvor loggene skal lagres. Oppsettet av historisk trend er da ferdig.
FS
114

Alarmer
For å knytte alarmer mot InTouch må vi inn i «Tagname Dictionary» og legge inn
noen bestemmelser for taggene vi ønsker å knytte til alarmer.
Figur 118: InTouch XXXX
På bildet har vi funnet frem niva taggen som eksempelvis er et flagg fra PLS som går
høyt når alarmtilstand er tilstede. Her vil vi velge radioknappen «Details & Alarms».
På denne menyen skriver vi inn «Alarm Comment». Husk også og sett «Alarm State»
On. Nå vil alarmfunksjoner i InTouch registrere når denne niva taggen går høy. Hvis
vi her hadde hatt en analog tagg kunne InTouch selv registrert om det var alarm ved
at vi setter inn kriterier for det i samme meny.
Figur 119: InTouch XXXXI
Videre går vi inn på «Group:…» og kan legge denne taggen inn i en ønsket
alarmgruppe, i dette eksempelet har vi lagt inn alarmgruppen «kritiskalarm». Videre
kan man ved å legge alarmer i forskjellige alarmgrupper for eksempel kvittere ut bare
en gruppe av gangen om man ikke ønsker å kvittere ut alle alarmene samtidig. Nå er
det registrert alarmlogging mot akkurat taggen niva. Hvis andre tagger ønskes å
knyttes mot alarmlogging gjennomføres det på samme måte som vist.
115

Figur 120: InTouch XXXXII
Etterpå ønsker vi å få frem alarmene i et vindu og går derfor inn på «Wizard
Selection» og finner «Dist. Alarm Display» under menyen «Alarm Displays».
Figur 121: InTouch XXXXIII
Den drar vi ut som vist på bildet. Etterpå klikker vi oss inn på alarmdiagrammet. Her
kan vi gjøre forskjellige innstillinger, men vi legger merke til der det står «Query
Type». Her kan vi velge om alarmene skal være «Summary» noe som betyr at
alarmene ikke vil logges i vinduet. Har det vært alarm og prosessen har gått ut av
alarmtilstand vil du ikke se det i vinduet. Velger du derimot «Historical» vil alarmene
bli logget i vinduet.
FS
116

6.11 Nettjenester
6.11.1 Bakgrunn
I forbindelse med prosjektet er det ikke kun arbeid som har blitt gjort ved og på selve
riggen. For å kunne presentere prosjektet for arbeidsgiver og andre interesserte,
samt å kunne holde oversikt med, og styre prosessen selv når man ikke er på
arbeidsplassen, er det satt opp flere nettjenester for å dekke disse behovene. I dette
kapittelet er det beskrevet mer om de forskjellige tjenestene, hvilke roller de fyller, og
generelt om hvordan ting har blitt satt opp.
JSH
6.11.2 Webserver
Touchpanelet som brukes i prosjektet, har en innebygd webserverfunksjonalitet.
Denne webserveren har File Transfer Protocol (FTP) -tilgang og mulighet for å vise
en nettside. Funksjonaliteten aktiveres enkelt via programmet iX-Developer, hvor
man huker av for de mulighetene man vil ha, i tillegg til at man velger portnummer og
innloggingsinfo til FTP-serveren. Det er en relativt enkel webserver, som ikke
håndterer mange påloggede klienter samtidig, men den har likevel fungert som
gruppens base for å sende sanntidsinformasjon om prosessen ut til andre
nettjenester.
JSH
117

6.11.3 Port-forwarding
Hver komponent i nettverket har sin egen IP-adresse. IP-adressen er delt opp i flere
porter. For å gjøre det enklere, kan en tenke seg at IP-adressen er en lang gate, og
portene er husene langs gaten. «Informasjonen» blir hentet fra husene langs gaten.
Datamaskinen sender og mottar informasjon gjennom portene.
Figur 122: Sending og mottak av informasjon.
Port forward går ut på å fremheve porter for sending og mottak gjennom ruteren. I
eksempelet Figur 122, er ruteren «bindeleddet» mellom Datamaskin 2 og
Datamaskin 1.
Det er illustrert et eksempel på hvordan datamaskinene sender og mottar pakker i
Figur 122. Dersom datamaskin2 har lyst å hente en spesiell «pakke» med
informasjon fra datamaskin1, vil datamaskin2 sende en forespørsel som routeren
registrerer. Ruteren vil videre sende en forespørsel til Datamaskin1 om å få tilgang til
pakken som ligger på Port-nr. 6668. Pakken som ligger på Port-nr. 6668 vil da bli
overført fra Datamaskin1 til Datamaskin2 gjennom ruteren.
For å få tilgang til ruterens Port-nr. 6668 må datamaskin2 skrive inn i adressefeltet i
en web-leser:
http://158.38.53.252:6668
TIB
118

6.11.4 Statisk IP-adresse og Aksessfilter
En statisk IP-adresse vil si at komponenten alltid vil ha den samme IP-adressa. I
forhold til HIST sitt nettverk, har ruteren på rigg1 den statiske IP-adressen:
158.38.53.252.
Figur 123: Aksessfilter
Hist har aksessfilter på web-serverne sine for IP-adressen vår. Dette er vist hvordan
fungerer i Figur 123. IP-adressen blir videresendt gjennom web-serverne uten at den
blir forandret.
Aksessfiltrene er konfigurert slik at når IP-adressen 152.38.53.252 blir sendt til web-
serveren, vil serveren videresende samme IP-adressen til neste web-server. I
eksempelet ovenfor sender vi ut IP-adressen 153.38.53.252 og mottar den samme
tilbake.
Figur 124 viser hvordan IP-adressen «reiser» gjennom systemet. I dette tilfellet
sporer vi hvilke web-serverer IP-adressen går gjennom på veien fra dataen vår til
google.com.
Vi har brukt samme fremgangsmåte i Figur 123 som Figur 124. Dette for å se
«reiseruten» til IP-adressen fra datamaskinen, ut på «nettet» og tilbake til ruteren.
119

Figur 124: Reise for IP-adresse.
Det er mulig å styre prosessen fra nettsiden til gruppen: http://www.hekta.org/~p2ea.
Eksempel er vist i Figur 125.
Fordelen med å åpne aksessfilter er at brukeren fra nettsiden kan få tilgang til port 80
på ruteren, som er koblet opp mot iX-panelet. Dermed kan nettsiden ha en eller flere
parameter som har tilgang til port nr. 80 på ruteren, og styre parameterne i iX-
panelet. Nettsiden er altså koblet opp mot IP-adressa til ruteren og portadresse 80 på
ruteren.
Måten ruteren og iX-panelet kommuniserer gjennom port nr.80 er vist i kapittelet om
port-forward.
Figur 125: Styring av prosessen fra nettside.
TIB
120

6.11.5 Nettside
Under miniprosjektet ble det opprettet en nettside, som har blitt videreutviklet under
entanksprosjektet. Gruppen fikk en del tilbakemeldinger på oppsettet av nettsiden, og
har prøvd så langt det går å forbedre de punktene som var mangelfulle. Det er gjort
enkelte grafiske endringer for å endre lettleseligheten og fremkommeligheten, blant
annet med en mer nettvennlig font og nye sider med innhold som var litt skjult ved
forrige iterasjon. Det generelle designet på siden er derimot ganske likt det
opprinnelige, med noen unntak. Selv om gruppen fikk tilbakemelding om at siden
manglet litt «wow-faktor», var det vanskelig å gjøre store endringer uten å bygge mye
av siden opp fra bunnen av igjen, som var noe man i denne omgang ikke ville ta seg
tid til. Håpet er at de små visuelle endringene som er gjort, samt et større fokus på
billedlig dokumentasjon av prosjektet vil hjelpe litt, selv om en større rekonstruksjon
kunne vært hensiktsmessig hadde prosjektets tidsramme vært større.
Figur 126: Oversikt over kommunikasjonen til nettsiden.
Funksjonelt er det en stor endring siden sist, nemlig at man nå kan styre prosessen
via nettsiden. For å kunne gjøre dette er det laget en kobling mellom iX-panelet sine
variabler, også kalt tagger, og webserveren til iX-panelet. Webserveren har to måter
man kan bruke for å hente informasjon fra variablene. Disse er beskrevet under.
JSH
121

REST api
Man vil ideelt sett bruke en protokoll kalt «REST api», som står for «Representational
State Transfer application programming interface». Ved hjelp av kommandoene GET,
PUT, POST og DELETE kan man hente og manipulere informasjonen lagret i
variablene til iX-panelet. På denne måten kan man få verdiene i variablene rett inn i
variabler i det språket man ønsker å arbeide med, i denne sammenheng JavaScript
eller PHP. Deretter kan man bearbeide disse variablene, og velge hva man vil vise til
brukeren.
Figur 127: REST eksempel.
Dessverre møtte man på problemer fra webserveren. Selv om man ganske raskt
hadde oppe kode som kunne sende kommandoer til webserveren på iX-panelet,
virket ikke alltid koden slik den skulle. Man kunne sende identisk kode, og få svar det
ene sekundet, men ingenting det neste. I tillegg fikk man etter et par forsøk en
feilmelding fra webserveren om at det var for mange tilkoblede aktive klienter. Det var
ingen dokumentasjon om denne feilmeldingen i iX-Developer sine hjelpefiler, så
gruppen henvendte seg til leverandøren av utstyret, Beijer Electronics. De kunne
fortelle at dette var et kjent problem, som kunne oppstå når webserveren ikke fikk
122

lukket forbindelsen med klienten på en god måte. Feilmeldingen som dukket opp var
et indirekte resultat av dette; når en webserveren mistet kontakt med en klient, ventet
den på svar i 15 minutter før den gav opp og koblet seg selv ned. De opplyste videre
om at det var en oppdatering på vei som forhåpentligvis ville løse en del av disse
problemene, men at den for øyeblikket var en tid unna levering. Naturligvis kunne
man ikke basere seg på en metode som kun ville vise informasjon hvert femtende
minutt, man måtte finne en annen måte å løse problemet.
JSH
JavaScript & JQuery
JQuery er et tilleggsbibliotek til programmeringsspråket JavaScript. I versjon 1.7 er
det i inkludert et bibliotek i JQuery, kalt iX.js. Dette biblioteket inneholder ferdige
funksjoner for å vise verdier fra iX-panelet på en nettside. Oppsettet og syntaksen til
biblioteket er lett å sette seg inn i, og man får raskt opp en grunnleggende nettside
hvor man kan sende og motta verdier. Ved første øyekast virker dermed denne
metoden som det naturlige valget. Dessverre har dette oppsettet et stort problem
som er vanskelig å ignorere. Nettsiden man kan konstruere, må ligge på den lokale
webserveren til iX-panelet. Da får man to mulige måter å gå videre på, enten ved å
legge hele nettsiden til prosjektgruppen ligge på den lokale serveren, eller ved å
hente inn den lokale nettsiden ved hjelp av HTML-komponenten «iframe». Skulle
man velge å legge hele nettsiden på den lokale webserveren, møter man på ett av
de samme problemene som man møtte på med REST api, nemlig enkelheten til iX-
panelets webserver. Den største utfordringen der er at man ikke kan ha mange
klienter tilkoblet samtidig. Testing har vist at panelet ikke godtar mer enn 2-3
tilkoblinger simultant, som er alt for lite for en nettside som realistisk sett i dette tilfelle
i det minste må kunne tåle et par titalls tilkoblinger simultant. Den andre løsningen er
da å hente inn den lokale nettsiden, fra iX-panelet sin webserver, inn i en «iframe».
Man vil fortsatt møte tilkoblingsproblemet, men det vil kun affektere de som logger
inn på nettsidens side for prosesstyring. Besøkende som ikke har tilgang her vil aldri
møte på problemet. Dessverre er «iframe» objektet et problem i seg selv. Opp
gjennom årene er det ingen andre html-objekter som har vært kilden til flere
sikkerhetsbrudd. Man kan finne artikkel på artikkel på nettet som advarer mot bruk av
«iframe», og gruppen var i det lengste motvillige til å bruke dette, men da man ikke
123

fikk problemene rundt REST api løst innen rimelig tid før entanksprosjektet nærmet
seg slutten, så man seg nødt til å ta det i bruk. Dagens løsning er altså en «iframe»
som viser den lokale nettsiden til iX-panelet.
Figur 128: Iframe-element fra iX-webserver.
JSH
Kameraovervåkning
En av bonusspesifikasjonene til oppgaven var overvåkning av riggen med et
webkamera som skulle vises på nettsiden samt i InTouch. HiST har satt opp et
webkamera med innebygd server, som man kan hente inn på nettsiden via et
«iframe»-element. Nettsiden man fikk opp på denne måten fremstilte bildet med en
stor svart marg på høyre side og på undersiden. Det var altså hverken en god teknisk
eller estetisk måte å importere bildet til gruppens nettside. Det dukket også opp et
annet problem i og med at nettsiden, som nevnt i miniprosjektrapporten, var designet
i hovedsak for nettleseren «Chrome». Som en sikkerhetsfunksjon i denne nettleseren
nettopp mot utnyttelse av «iframe»-elementet til uønskede aktiviteter, nekter Chrome
å laste inn den lenkede adressen når innholdet kommer fra en ukjent port ved IP-
adressen.
124

Figur 129: “Unknown port"-error i Chrome.
Problemet kan unngås, men det må gjøres endringer i sikkerhetskonfigurasjonen til
hver enkelt nettleserklient. Dette legger problemet over i brukerens hender, som på
ingen måte er ønskelig. Gruppen valgte derfor å gå tilbake til det som var
reserveløsningen mens man ventet på bekreftelse på at høyskolens webkamera
skulle settes opp, nemlig å benytte seg av et privat webkamera. Ved hjelp av et
program kalt «YAWCAM»(Yet Another WebCam software), satte man kameraet til å
laste opp et bilde hvert andre sekund til webserveren på iX-panelet, og man kunne
derfra hente ut bildet til nettsiden, slik som vist på Figur 126. Denne løsningen gir
ikke et like responsivt bilde som høyskolens webkamera, da det kun oppdateres
hvert andre sekund, men man har fordelen av å unngå et nytt «iframe»-element, det
ser mer ut som en naturlig del av siden da man kan behandle det som et vanlig bilde-
element, og det vil fungere i en hvilken som helst nettleser. Med tanke på at man på
samme side som webkamera også får opplyst de reelle verdiene til viktige variabler
fra tanken, mener gruppen at fordelene mer enn veier opp for ulempene ved å bruke
en egen kameraløsning.
JSH
125

6.11.6 Fjernstyring med smarttelefon
Bakgrunn
En bonusspesifikasjon i prosjektet var oppretting av en mobilapplikasjon for
fjernstyring og overvåkning av prosessen. En mobilapplikasjon vil være en plattform
med mange fordeler over stasjonære styringsalternativer, størst av disse er
muligheten til å holde oversikt over prosessen og ta raskt handling, selv om man ikke
er i nærheten av de statiske kontrollene.
Samtidig var det en stor utfordring for gruppen. For at systemet skulle fungere, måtte
man ha oversikt over hvordan informasjon blir sendt fra og til iX-panelet og hvordan
man enklest får tak i bilder fra webkamera. Dette stod på lik linje som ved
konstruksjon av nettsidens prosesstyring, og møtte på mange av de samme
problemene. I tillegg måtte de i gruppen som jobbet med applikasjonen sette seg inn
Java, XML(eXtensible Markup Language) og Android sitt java-bibliotek. Sistnevnte er
et språk i hurtig utvikling, med opptil flere årlige iterasjoner, noe som igjen gjorde
søket etter gode fremgangsmåter vanskelig da de allerede kunne vært utdatert.
Gruppen så allikevel på oppgaven som en givende prosess å gjennomgå, selv om
man ikke skulle nå alle mål innen fristen. Et uferdig produkt kan eventuelt
videreutvikles i et senere prosjekt.
JSH
Drøfting av valg rundt utviklingsprosessen
Et av de første valgene man måtte ta, var hvilket operativsystem man skulle basere
seg rundt, da man ikke hadde ressurser til å lage en applikasjon over flere
operativsystem. Man valgte Android OS, da dette er et av de mest åpne
operativsystemene og veldokumentert. Det ble også lagt vekt på at dette er langt på
vei det mest brukte operativsystemet, med rundt 66 % av markedsandelen ved
utgangen av 2012. Bildet under viser salgsraten til mobile enheter med forskjellige
operativsystem, også her ser man at Android er det definitivt mest brukte.
126

Figur 130: Salgstall for mobiloperativsystem, hentet fra Wikipedia.org.
Det neste valget som måtte gjøres, var hvilken måte man skulle gå frem for å bygge
applikasjonen. Google, som står ansvarlige for utviklingen av Android OS, utviklet
også noe kalt "Android App Inventor". Google selv støtter ikke lenger App Inventor,
men Massachusetts Institute of Technology(MIT) tok over kildekoden og har til en
viss grad fortsatt utviklingen. Under kan man se et eksempelbilde av hvordan en
while-løkke kan se ut i MIT App Inventor.
127

Figur 131: MIT App Inventor.
App Inventor fungerer omtrent som et puslespill, hvor man grafisk kan koble sammen
programkode. Man oppdaget ganske raskt under programmering av en test
applikasjon at denne metoden var lite fleksibel i utføringen, og ble veldig uoversiktlig
ved større program. Til sammen veide ikke lettheten i programmeringen opp for de
negative sidene, og man valgte å legge vekk App Inventor til fordel for en mer
grunnleggende fremgangsmåte, nemlig Android Software Development Kit(SDK).
Android SDK er den faktiske måten å konstruere Android baserte applikasjoner på.
Her bruker man en blanding av Java, XML og et Java - basert Android bibliotek, til å
programmere utseende og funksjonaliteten til applikasjoner. Fordelene er høy grad
av fleksibilitet, god oversikt selv ved store program og lettere videreutvikling. Dette
ble dermed det naturlige valget for gruppen.
JSH
128

Applikasjonsteori
En applikasjon bygget i Android har flere komponenter som jobber sammen for å
formidle informasjonen til brukeren. Dette delkapittelet vil gå gjennom basisen for
hvordan en applikasjon ser ut innvendig, for økt forståelse når prosjektgruppens
applikasjon beskrives.
Figur 132: Grafisk fremstilling av prosessen for å bytte til et nytt brukergrensesnitt.
I all hovedsak er en applikasjon bygget opp av tre hoveddeler; Manifestet, Java-
klassene og aktivitetene. Hvis man tenker på en applikasjon som et tre, vil Manifestet
være stammen. Manifestet er stedet operativsystemet går til først for informasjon om
applikasjonen, og om hvilke aktiviteter som skal kjøres ved oppstart. Det definerer
hvilke rettigheter man har, og hvilke rettigheter de individuelle aktivitetene har.
Grenene i treet vil dermed bli Java-klassene. Når Manifestet får en forespørsel, vil
det lete etter en Java-klasse som passer forespørselen, og starte denne. Java-
klassen inneholder hoveddelen av programmet. Her hentes informasjon inn og
legges i variabler, og variablene blir behandlet før de blir sendt videre. Det er Java-
klassen som bestemmer om, og hvilken aktivitet som skal startes. Aktiviteten blir da
bladene på treet. Når en Java-klasse gir beskjed om at aktiviteten skal startes, vil det
nåværende brukergrensesnittet bli byttet ut med den nye aktivitetens
brukergrensesnitt, eller UI(User Interface). Brukergrensesnittet består av alle de
interaktive elementene til applikasjonen, og er den delen en sluttbruker vil ha
kjennskap til. I nyere versjoner av Android kan aktivitetene også deles opp videre i
noe kalt "Fragments", eller "deler". Hver Fragment består av en eller flere grafiske
129

elementer, som kan samles i en "ramme"-aktivitet. Fordelen med denne
fremgangsmåten er økt gjenbruk av elementer som ellers ville tatt mye utviklingstid å
sette sammen for hver aktivitet.
Figur 133: Inndeling av fragmenter.
JSH
Applikasjonsinnhold
Bonusspesifikasjonen om fjernstyring via smarttelefon gir jo kravet om at
applikasjonen skal ha mulighet for å styre enkelte aspekter på riggen. I tillegg satte
gruppen seg mål om at man skulle kunne få webkameraet inn på telefonen, for å
videre øke oversikten sluttbruker har over prosessen.
Med disse kriteriene startet designet av applikasjonen. Den ble døpt til navnet
"Remote Rig Control"(RRC), og man konstruerte et lett gjenkjennelig ikon som vil
være applikasjonens ansikt utad på brukerens telefon.
Figur 134: RRC ikonet.
130

Den aller første siden brukeren får opp, er en introduksjonsside. Denne siden viser i
kort tid informasjon om gruppen og applikasjonen. I tillegg til god reklame for
gruppen, gir det også sluttbrukeren en påminnelse om hvor han eller hun kan ta
kontakt for support eller andre henvendelser.
Figur 135: "Splash"-side.
Etter en predefinert tid, sender den brukeren automatisk videre til hovedsiden. Denne
siden er bygget opp etter "Fragments"-prinsippet, og er delt opp i to fragmenter. Den
første er en konstant meny på venstre side av skjermen, som viser logoen til HiST og
alternativene på menyen. Det andre fragmentet er hovedinnholdet på siden, og
byttes ut når man velger et nytt alternativ på menyen. Når man først kommer til
hovedsiden får man opp et fragment som gir brukeren oversikt over prosessen. Har
man tilkobling til riggen, hva er nivået nå, med mer. Det var også planer om å legge
til en grafisk fremstilling av nivået i tanken og alarmtilstander.
131

Figur 136: Oversiktsside.
Via menyen kan man så navigere seg videre til andre elementer i applikasjonen. Den
neste på listen er WebCam. Tanken var at man her kunne få vist bilder fra
prosessens webkamera, som ville gitt en god oversikt over hvordan det stod til med
tanken i det øyeblikket og være utfyllende til informasjonen man kunne få fra tallene.
Figur 137: WebCam.
Den siste siden som er med, er Kontroll. Som navnet tilsier , kan man her styre mer
detaljerte aspekter ved prosessen. Spørsmålet er hvor mye kontroll man ville vurdert
det forsvarlig å legge inn på en mobilapplikasjon. Svaret blir vel at; jo mer
informasjon man kan gi til brukeren, og jo bedre protokoller man har for hva som skal
skje hvis det oppstår et kommunikasjonsbrudd, jo mer kontroll kan man gi brukeren. I
første omgang ville det nok vært naturlig, i tillegg til pumpekontrollen man har på
132

oversiktssiden, å gi kontroll over referansen og utventilene. Man kunne også vurdert,
som vist i bildet under, å gi kontroll over regulatorparametrene, men spørsmålet er
om det vil være aktuelt å gjøre så store endringer uten å være tilstedet ved
prosessen.
Figur 138: Kontrollside.
JSH
Problemområder
I det man gikk inn i arbeidet var man klar over at det var en stor bonusspesifikasjon,
og at det sannsynligvis ville dukke opp problemområder man måtte hanskes med i
løpet av prosjektet.
Et av de første problemene man møtte på, var iX-panelet sin bruk av REST api, som
beskrevet i kapittelet om fjernstyring fra nettsiden. Etter en del arbeid med generelle
REST protokoller koblet man seg opp mot iX-panelet sin server, og fikk svar med
navn på taggen man spurte etter, verdien og annen informasjon. Dessverre viste det
seg at det eksakt samme programmet ikke presterte å hente inn informasjonen når
man lastet det på nytt igjen. Hvis man prøvde å laste programmet flere ganger videre
fikk man etter hvert den kjente feilmeldingen man først møtte på når man jobbet med
REST opp mot nettsiden, om at det for tiden var for mange tilkoblede klienter, med
tilhørende 15 minutters pause før man kunne koble seg til på nytt. Man kom til
samme konklusjonen som under arbeidet med nettsiden, at man måtte prøve å finne
andre løsninger.
133

Et annet problem man møtte på, var utdatert informasjon. Mange av hjelpefilene man
kunne finne på nettet med informasjon om Android SDK var utdaterte, og det gikk
relativt lang tid før man fant ut av at en hjelpefil man fulgte var så utdatert at dog
koden fungerte for seg selv ville den ikke fungere sammen med andre elementer
man trengte. Dette førte til at det ble mye frem og tilbake med koden, og ofte
vanskelig å skille ut feilmeldinger da de kunne komme fra mange forskjellige punkter.
JSH
Sluttprodukt
Applikasjonen slik den eksisterer i dag kan finnes på prosjektets hjemmeside og
prosjektgruppens sider på It's Learning. Denne finnes som en .apk fil. Hvis man vil
installere denne på en mobil med Android OS, er det lettest å sende .apk-filen til seg
selv på e-post, og åpne e-posten på mobilen. Når man aktiverer vedlegget vil man få
spørsmål om man vil installere applikasjonen. Da det er en applikasjon fra en ukjent
utgiver, er det viktig å stille inn telefonen sin for dette i forkant. Dette gjør man ved å
gå inn på "Innstillinger -> Sikkerhet -> Enhetsadministrasjon" og huke av for "Ukjente
Kilder".
All kildekode til applikasjonen ligger som vedlegg til denne rapporten.
JSH
134

6.11.7 Konklusjon mobilapplikasjon
Som man kan se av applikasjonen, er det mye som mangler. Man har ikke stabil
kontakt med iX-panelet, som vil være nødvendig for kontroll av prosessen. Det er
heller ikke satt opp kobling til webkameraet. Etter prosjektmøte 4 så gruppen at det
var mye arbeid som gjenstod både med hovedprosessen og nettsiden. Når man i
tillegg hadde en del problemer med REST api'et til iX-panelet, valgte man å sette
tilside arbeidet med mobilapplikasjonen inntil videre. Mulighetene rundt en slik
mobilapplikasjon er enorme, men man ser at det kanskje har blitt bitt over litt mer enn
man klarer å svelge. Man har allikevel valgt å presentere arbeidet som har blitt gjort
med applikasjonen, og med den nåværende applikasjonen som et grunnlag som kan
gi arbeidsgiver en pekepinn på funksjonaliteten til den endelige applikasjonen. Skulle
det vise seg at man får tid til overs under arbeidet med totanksprosjektet er det dog
fullt mulig å legge mer arbeid i det.
Figur 139: Produktet som sett på en Samsung Galaxy S2.
JSH
135

6.12 Test av tankens regulering
Væskenivået i tanken reguleres ved hjelp av en PLS som styrer innløpet til tanken.
Tanken har da et utløp som endres ved at 3 magnetventiler som åpnes eller lukkes.
Det er satt krav og retningslinjer til hvordan tanken skal reguleres og styres. PLS-en
kommuniserer med omverdenen gjennom et operatørpanel med touchskjerm og
webserver som står ved anlegget og en PC med programmet InTouch.
I et anlegg som dette er det mange bindeledd og mange potensielle feilkilder. Det er
derfor viktig at utstyret er testet grundig slik at uforutsette hendelser unngås.
Vedlagt denne rapporten er flere testskjemaer som leder testeren gjennom en rekke
oppgaver for å sjekke funksjonaliteten til utstyr og program som inngår i reguleringen.
Dette er gjennomgått og anlegget er funnet uten feil.
Et arbeidsnotat til prosjektet er lagt ved rapporten. Arbeidsnotatet tar for seg
modellering av prosessen og beregning av reguleringsparametere som skal gi best
resultat når det gjelder stabilitet og innsvingning på reguleringen. Kravet er at
prosessen skal ha innsvingning tilsvarende minimum areal ved et sprang i utløpet fra
3 til 1 ventil åpen. I tillegg skal prosessen stabilisere seg raskest mulig. Prosessen
ansees som stabil når nivået ikke svinger mer ±2% fra referansen.
Modellen som ble laget ble simulert og gav resultatene som vist i Figur 140.
75
70
65
60
55
50
45
40
3 til 1 ventil
Uten foroverkopling
Med foroverkopling
1 til 3 ventiler
300 350 400 450
Tid [sekunder]
500 550 600 650
Figur 140: Resultat fra modellering. Kurvene viser nivå i %.
136

I Figur 140 er det brukt følgende reguleringsparametere:
Kp 2,7
Ti 35
KpFF 0,15
TdFF 20
NFF 10
Tabell 5: Modellerte regulatorparametere
Figur 141 foroverkobling viser resultat ved bruk av modellerte reguleringsparametere.
For å teste innsvingningen er det foretatt et sprang i fra 3 til 1 ventil åpen. Det viser
seg raskt at simuleringsmodellen ikke er helt i samsvar med den virkelige prosessen
da det ikke oppstår svingninger i systemet. En Ti-verdi på 35 er tydelig for stor da det
går lang tid før avviket er lik 0. Foroverkobling innkoblet gir derimot raskere
innsvingning, men fortsatt lang.
Figur 141: Modellerte reguleringsparametere uten(tv) og med(th) foroverkobling
Etter litt finjustering ved bruk av erfaring og lærte teorier ble det besluttet at følgende
verdier gir en tilfredsstillende regulering av nivået i tanken.
Kp 2,7
Ti 18
KpFF 0,4
TdFF 10
NFF 10
Tabell 6: Tabell over finjusterte regulatorparametere
137

Figur 142 viser hvordan prosessen svarer på sprang ved bruk av finjusterte
reguleringsparametere. Ved gruppens egne finjusterte verdier vises stor forbedring.
Dynamisk avvik og innsvingningstid er betydelig mindre. Ved innkobling av
foroverkoblingen, på regulatoren, blir dynamisk avvik og innsvingningstid praktisk talt
lik 0.
Figur 142: Finjusterte reguleringsparametere uten(tv) og med(th) foroverkobling
Testing av reguleringen viser at gruppen har i stor grad oppnådd kravene som stilles
til anlegget. Reguleringen fungerer utmerket til sitt forhold.
BM
138

6.13 Problemområder for prosjektutførelsen
EVE
1. Tiden prosjektgruppen får til å teste systemet er begrenset da det er en annen
gruppe som også skal ha tilgang. Problemet ble løst med at gruppene fikk
annenhver dag på systemet. At det er to grupper som skal ha tilgang på
systemet gjør også at det er mange forskjellige programmer og verdier i bruk,
derfor må prosjektgruppen huske å endre alt til sitt eget hver gang.
2. Gruppen består av seks deltakere, noe som skaper problemer ved oppdeling
og om flere jobber med samme oppgave. Prosjektgruppen har under
prosjektperioden hatt mange forskjellige oppgaver som har blitt godt fordelt, og
på grunn av dette har dette problemet blitt løst på en ypperlig måte.
3. Samkjøringen av de forskjellige enhetene er problematisk, både på design og
ved styring. Når det er to systemer som skal styre samme enheter, må det
alltid legges opp krav til sending og innhenting av verdier. Systemet må også
rapportere alt som skjer til de andre enhetene så det ikke er forskjellige
verdier.
4. Under rapportskrivingen vil det være seks personer som skriver på hver sin
måte, denne problematikken vil prosjektgruppen møte på under alle
delprosjektene når alt skal legges sammen.
5. Informasjonen til de forskjellige varierer veldig, noen enheter er godt forklart
på både internett og i lærebøker, mens andre er det vanskelig å finne
informasjon om. Dette gjør det vanskelig, spesielt om prosjektgruppen har
planlagt å gjøre noe på en måte, men finner ikke ut hvordan det utføres.
139

7 Prosjektorganisering.
«Prosjektoppgave i faget Styresystemer» er et prosjekt for en gruppe på seks
studenter ved Høgskolen i Sør-Trøndelag, som utfører en oppgave gitt av faglærerne
i faget «Styresystemer og reguleringsteknikk». HiST stiller med veiledere til
studentene. Prosjektgruppen vil få en karakter på sitt prosjekt satt av veileder fra
HiST.
7.1 Deltakere:
7.1.1 Oppdragsgiver og veiledere:
Per Hveem
Førsteamanuensis ved Program for Elektro- og Datateknikk,
Avdeling for Teknologi, HiST
Dr. Ing. reguleringsteknikk
Tlf: 73559593
E-post: per.hveem@hist.no
Andreas Sørvik
Lab-ingeniør.
Tlf: 73 55 94 50
E-post: andreas.sorvik@hist.no
7.1.2 Prosjektgruppe:
Prosjektgruppen består av seks studenter fra HiST ved linjen automatiseringsteknikk,
tredje semester. Gruppen er satt sammen av faglærerne, med tanke på bakgrunnen
til hver enkelt student. Prosjektet er vårt semesterprosjekt i faget Styresystemer og
reguleringsteknikk.
JSH; EVE
140

Jostein Svanholm Helland
Alder: 26
Tlf: 93030878
E-post: josteish@stud.hist.no
Arbeidserfaring: 2008 – 2012:
Utdanning: 2012 –
2009 – 2012:
2007 – 2009:
Prosjekter: 03.2010 – 05.2010:
Erlend Vist Ekren
Alder: 21
Tlf: 41767127
E-post: erlendek@stud.hist.no
Arbeidserfaring: 2011 – 2013:
Utdanning: 2011 –
V2011:
2009 – 2010:
2007 – 2009:
Redaktør i produksjonsavdelingen
Akademika forlag, sommer/jul
Automatiseringsteknikk, Avdeling for
Teknologi, HiST
Teknisk Kybernetikk, NTNU
Kristendom grunnfag + språkfag og
eksegese, NLA B&M
Prosjekt i faget Kybernetikk Intro,
modellering og regulering av styresystemer
på forenklet rakettmodell.
Norsk Hydro, Sunndal, sommerjobb.
Automatiseringsteknikk, Avdeling for
Teknologi, HiST
Halvårsforkurs, HiST
Sunndal VGS, Allmenn påbygg
Sunndal VGS, Elektrofag
141

Thomas Igesund Berge
Alder: 22
Tlf: 97425260
E-post: thomasib@stud.hist.no
Arbeidserfaring: S2012:
Utdanning: 2011 –
Olav Gabrielsen
Alder: 25
2007 – 2010:
Tlf: 93412152
E-post: olavgab@stud.hist.no
Arbeidserfaring: S2012:
S2010:
7.9.2009:
2007 – 2009:
Utdanning: 2011 –
2002 – 2006:
Havyard 3D-avdeling, sommerjobb.
Automatiseringsteknikk, Avdeling for
Teknologi, HiST
Studiespesialisering, Ulstein VGS
Sommerjobb Aibel
Sommerjobb Rønning Elektro
Fagprøve Automatiker
Lærling Hitec Products Drilling, Forus
Automatiseringsteknikk, Avdeling for
Teknologi, HiST
Yrkesfag, Grand VGS
142

Fredrik Sørvig
Alder: 24
Tlf: 48036012
E-post: fredrso@stud.hist.no
Arbeidserfaring: 2011 – 2012:
Utdanning: 2011 –
2010:
24.6.2009:
2006 – 2007:
2005 – 2006:
2004 – 2005:
Prosjekter: 2008 – 2009:
Bendik Mydland
Alder: 24
Tlf: 99223347
E-post: bendikm@stud.hist.no
Arbeidserfaring: S2012:
2007 – 2011:
Utdanning: 2011 –
2009 – 2011:
2004 – 2009:
Mekanisk arbeid og vedlikehold,
Bis Production Partner AS.
Automatiseringsteknikk, Avdeling for
Teknologi, HiST
Realfagskurs
Fagbrev industrimekaniker, ISS Industri
Allmennfaglig påbygning, Mosjøen VGS
VK1 Elektromekaniske fag, Vefsn VGS
GK Elektrofag, Vefsn VGS
Utskiftning av kranbane hos Alcoe,
Bis Production Partner AS
National Oilwell Varco, automatiker
Elkem Solar AS, automatiker
Automatiseringsteknikk, Avdeling for
Teknologi, HiST
Fagskole, fordypning automasjon,
Kvadraturen Skolesenter
Fagbrev, Automatiker
Mandal VGS, Elkem Solar AS
143

7.2 Arbeidslokaler og utstyrstilgang:
Prosjektgruppen er ikke tildelt noen private rom for arbeid med prosjektet, men har
tilgang til fellesrom og studieretningens klasserom ved HiST sine lokaler på
Kalvskinnet i Trondheim. Her har studentene f.eks. tilgang til datasaler, der store
deler av prosjektet har foregått. Prosjektet har også en praktisk del som krever
tilgang til en «PLS-rigg», som vil befinne seg på en lab i lokalene. Der har gruppen
bestilt tid til å utføre arbeidet som ligger i arbeidspakkene.
EVE
Figur 143: Tankriggen.
144

7.3 Prosjektleveranser:
7.3.1 Programvare:
Prosjektgruppen skulle i løpet av prosjektperioden utvikle programvare til de
forskjellige enhetene i systemet. Prosjektgruppen har programmert et PLS-program
som skal bestå av alarmbehandling og et reguleringssystem. Programmet regulerer
nivået i en tank, med mulighet for automatisk- og manuell-styring, foroverkobling med
PD-regulator og regulatoren har muligheten til å kjøres som både P- og PI-regulator. I
programmet har prosjektgruppen sørget for at reguleringen blir riktig ved oppstart
etter et strømbrudd. Systemet regulerer også inn til ønsket nivå om kontakten opp til
HMI’ene blir brutt. Ved hjelp av et en master-PLS, skal slave-PLS’en ha kontakt opp
til HMI’ene. Master-PLS’en er programmert for å motta og videresende verdier. PLS-
programmene prosjektgruppen har levert står mer detaljert tidligere i rapporten, og
prosjektgruppen vil henvise dit om mer informasjon er ønsket.
I HMI’ene har prosjektgruppen utviklet program i både InTouch og i iX-panelet. Det
var satt opp diverse krav til hva HMI’ene skulle inneholde fra oppgaveteksten, og det
er med utgangspunkt fra kravene prosjektgruppen har satt opp sine system. HMI’ene
skal la operatøren styre systemet, der en større del av styringen skal foregå i
InTouch enn i iX-panelet. Prosjektgruppen har lagt vekt på designet for å holde det
enkelt og lett forståelig. Begge HMI’ene er forklart tidligere i rapporten, og
prosjektgruppen vil henvise dit om mer informasjon er ønsket.
EVE
145

7.3.2 Skriftlige leveranser:
Entanksprosjektrapport
Rapporten skal forklare hvordan prosjektgruppen har gått frem for å fullføre
oppgaven, samtidig som de skal dokumentere at systemet fungerer som det skal.
Rapporten skal være skrevet på en måte som gjør at leseren ikke trenger å være en
ingeniør innen samme fagfelt som prosjektgruppen for å forstå hvordan systemet
fungerer og hvordan det er oppbygd.
EVE
Simuleringsnotat
Prosjektgruppen skal levere et simuleringsnotat der de skal dokumentere hvordan de
har gått frem for å finne systemets overføringsfunksjon. Studentene skal i
dokumentet vise hvordan de simulerer systemet. I simuleringsnotatet skal
prosjektgruppen ha lagt frem forslag til innstillinger for regulatoren, som er utregnet
ved hjelp av simuleringene.
EVE
Arbeidspakker
Ferdiggjorte arbeidspakker og arbeidspakker som er påbegynt, men vil fortsette å
løpe fremover i prosjektet, skal leveres inn som vedlegg til entanksprosjektrapporten.
Dette for å gi arbeidsgiver en oversikt over hvordan gruppen ligger an i forhold til
planlagte timer.
JSH
Nettside
En nettside med informasjon om prosjektet har tidligere blitt opprettet. Nettsiden vil
fortløpende legge ut informasjon som forklarer prosjektgruppens fremgang. Her
finner leseren også tidligere rapporter og innkallinger og referat fra prosjektmøtene.
Prosjektgruppen har også forklart alle delprosjekter og lagt ut annen informasjon som
er relevant til prosjektet.
EVE
146

Figur 144: Nettsiden til prosjektgruppen.
147

7.4 Tids- og kostnadsplan:
Prosjektgruppen har i et forprosjekt lagt frem et forslag til bruk av ressurser. I dette
prosjektet vil det ikke forekomme andre utgifter enn timebruk, så ressursene vil bli
arbeidstimer per student. Hvordan prosjektgruppen har kommet ut av det de planla i
forprosjektet ligger med som vedlegg, her kommer det fram hvor mye det er blitt
jobbet med hver arbeidspakke. Det vil vises at det er sprik mellom planlagt tid brukt
på de forskjellige arbeidspakkene og faktisk brukt tid, men dette er naturlig da
studentene ikke vet hva som faktisk inngår før de kommer i kontakt med oppgaven.
Antall timer
2000
1800
1600
1400
1200
1000
800
600
400
200
0
Figur 145: Loggført timeforbruk.
I Figur 145 kan man se hvordan loggførte timer er i forhold til planlagte timer.
Prosjektgruppen har utnytt arbeidsdagene i ukene de har jobbet, og jobbet frivillig
individuelt på helgene. Det kommer tydelig frem i diagrammet at timeforbruket har økt
kraftig de siste ukene før innlevering. Til tross for kraftig øking vil gruppen etter all
sannsynlighet ikke overstige endelig estimert timeforbruk. I dette prosjektet, hvor
kostnadene er direkte knyttet til timeforbruk, vil det si at kostnadene vil holdes under det
som først ble forespeilt.
EVE; BM
Timeforbruk
9 10 11 12 13 14 15 16 17 18 19 20
Estimert
Loggført
148

7.5 Prosjektstyring og kvalitetssikring:
7.5.1 Statusrapportering:
Statusrapportering er en tilbakemelding på hva som har blitt gjennomført den siste
tiden. Denne utarbeides hver andre uke av prosjektgruppen. Slike rapporter
gjennomgås på prosjektmøte med prosjektgruppe og veileder. Timebruk loggføres og
møteinnkallinger og møtereferater lastes opp på nett i tillegg til å sendes ut til
deltakere.
JSH
7.5.2 Versjonskontroll:
Under utarbeiding av filer og rapporter opplever vi ofte at vi må skrive om og
oppdatere filene. For å unngå unødvendig forvirring, i forhold til hvilken fil som er
hvilken versjon, så fører vi på dato, og eventuelt et tall for versjonsnummer. Dette er
spesielt viktig for programmeringsfiler ettersom at en ofte gjør utbedringer og
utvidelser underveis, uten å alltid være klar over at en på utvidelsen ubevisst har gjort
småfeil som resulterer i at programmet ikke fungerer. På denne måten så kan en
begrense tiden på feilsøking betraktelig. Feilfrie utbedringer som gjøres skriver vi
forklaringer på i kommentarfeltet slik at andre raskt forstår hvordan programmet
fungerer.
OG
149

8 Litteraturliste
A Deutsch, LA Grimsland & S Solvang, Prossesstyringsprogram for
silisiumsstørkningsovn, Bacheloroppgave 2010, lastet ned 5.3.2013,
https://www.itslearning.com/file/download.aspx?FileID=2371488&FileVersionID=-1
(Begrenset tilgang)
A Hofstad, PLS-Teknikk, 7. utg., 2. opplag, Kybernetes Forlag, 2009
DE Seborg, TF Edgar, DA Mellichamp, FJ Doyle III, Process Dynamics and Control,
3d edn, John Wiley & Sons (Asia) Pte Ltd, China, 2011
K Bjørvik & P Hveem, Reguleringsteknikk, Kybernetes Forlag, Trondheim, 2012
K Bjørvik & V Tyssøy, Dynamiske Systemer
NN, Training Manual, InTouch HMI 9.6 Fundamentals of Application Development
Course, WonderWare Training, 2006, Rev. E.
P Hveem & AS, Tips til prosjekt i Styresystemer våren 2012, lastet ned 20.3.2013,
https://www.itslearning.com/file/download.aspx?FileID=2371492&FileVersionID=-1
(Begrenset tilgang)
Wikipedia, Port Forwarding, lastet ned 2.5.2013,
http://no.wikipedia.org/wiki/Port_forwarding
Wikipedia, Mobile operating system, Current market share and outlook, lastet ned
2.5.2013,
http://en.wikipedia.org/wiki/Mobile_operating_system#Current_market_share_and_ou
tlook
Youtube, iX Developer Trend, lastet ned 2.5.2013,
http://www.youtube.com/watch?v=d_lztVdrYyU
Youtube, iX Developer Alarm, lastet ned 2.5.2013,
http://www.youtube.com/watch?v=hdRMkHSvtbI
150

151

9 Vedlegg
152

Vedlegg A
Testskjema
7 sider

Vedlegg B
PID-kode i strukturert tekst
3 sider

PIDheltall i strukturert tekst
(*PID-regulator (inverterende)*)
(*Med mulighet for manuell kjøring, valg av P(D) eller PI(D).*)
(*For å koble ut D-delen velges denne til 0*)
(*NB! Denne regulatoren er laget for å kunne bruke tall med ett desimal;
Det vil si at Kp, Ti, Td og SampTid må ganges med en faktor på 10
før de sendes inn i PIDheltall-blokka*)
y_k:=PV;
e_k:=SV-PV;
Tih:=Ti/SampTid;
IF Auto THEN
(*Utregning for D-delen*)
Del1:=(Td/SampTid)*10+((Td MOD SampTid)*10)/SampTid;
Del2:=(Kp/10)*Del1+((Kp MOD 10)*Del1)/10;
Del3:=(y_k-(2*y_km1)+y_km2)*10;
D_pid:=(Del2/10)*Del3+((Del2 MOD 10)*Del3)/10;
Del4:=(y_k-y_km1)*10;
D_pd:=(Del2/10)*Del4+((Del2 MOD 10)*Del4)/10;
(*Grensesjekking. D_pid holdes i området -2550 - 2550*)
IF (D_pid=2550) THEN
D_pid:=2550;
END_IF;
END_IF;
(*Grensesjekking. D_pd holdes i området -2550 - 2550*)
IF (D_pd=2550) THEN
D_pd:=2550;
END_IF;
END_IF;

IF PD_PID THEN
(*Beregning PID når PD_PID er høy*)
deltau_ik:=(Kp*e_k+deltau_irestkm1)/(Tih*10);
deltau_irestk:=(Kp*e_k+deltau_irestkm1) MOD (Tih*10);
u_k:=u_km1+deltau_ik+Kp*(e_k-e_km1)/10-(D_pid/10);
uNOM:=u_k;
ELSE
(*Beregning PD når PD_PID er lav*)
u_k:=(Kp/10)*e_k+((Kp MOD 10)*e_k)/10+uNOM-(D_pd/10);
END_IF;
ELSE
(*Manuell kjøring når Auto er lav*)
u_k:=uMAN; (*Sørger for rykkfi overgang fra Manuell til Auto*)
uNOM:=uMAN; (*Sørger for rykkfi overgang fra Manuell til Auto*)
SV:=PV; (*Sørger for rykkfi overgang fra Manuell til Auto*)
e_k:=0; (*Sørger for rykkfi overgang fra Manuell til Auto*)
u:=uMAN;
END_IF;
(*Grensesjekking. u_k holdes i området 0 - 255*)
IF (u_k=255) THEN
u_k:=255;
END_IF;
END_IF;
u:=u_k; (*u_k sendes til regulatorens utgang*)
uMAN:=u; (*Sørger for rykkfi overgang fra Auto til Manuell*)
(*Oppdatering av "gamle" verdier*)
e_km1:=e_k;
u_km1:=u_k;
y_km2:=y_km1;
y_km1:=y_k;
deltau_irestkm1:=deltau_irestk;
Avvik:=e_k;
BM

Vedlegg C
Android programfiler
8 sider

Programfiler Android Mobilapplikasjon
Android Manifest

Java classes
Splash.java

Hovedside.java

Kontroll.java, WebCam.java & Oversikt.java

HttpRetriever.java

Eksempel på vanlige og fragmenterte aktiviteter
hovedside.xml

kontroll_frag.xml

Vedlegg D
Arbeidspakker
10 sider

HØGSKOLEN I SØR-TRØNDELAG
Avdeling for teknologi
Studieprogram for elektro- og datateknikk
7004 TRONDHEIM
Fag: EDT211T Styresystemer og Reguleringsteknikk Dato: 05.03.13
Prosjekt: Nivåregulering i et totanksystem
Aktivitet: Modellering. Aktivitet nr: 07
Startdato: 03.04.13 Sluttdato: 22.04.13
Avhengighet: Foregående aktiviteter: 06 Ferdigstille rapport.
Etterfølgende aktiviteter: 11 tilleggsspesifikasjoner.
Mål: Få laget en model av prosessen.
Arbeidsbeskrivelse: Studentene skal opprette en så bra modell som mulig av systemet. Her
skal de levere arbeidsnotat og simuleringsnotat av ferdig produkt.
Timeverk: 170,5 timer Fordeling: Thomas I. Berge 63,5t
Jostein S. Helland 18,5t
Fredrik Sørvig 16,5t
Bendik Mydland 15t
Olav Gabrielsen 50,5t
Erlend V. Ekren 6,5t
Kostnader: I dette prosjektet vil det ikkje forekomme noen kostnader.
Ressurser: Ressursene som brukes i prosjektet blir bare arbeidet til studentene.
Risiko: Studentene må være flinke til å taste alt de gjør underveis så de ikke ender opp med
feil verdier og regner videre med dem.
Faglig ansvarlig:
Fredrik Sørvig tlf: 48036012 e-post: fredrso@stud.hist.no
Prosjektmedarbeidere:
Jostein S. Helland tlf: 93030878 e-post: josteish@stud.hist.no
Bendik Mydland tlf: 99223347 e-post: bendikm@stud.hist.no
Erlend V. Ekren tlf: 41767127 e-post: erlendek@stud.hist.no
Thomas I. Berge tlf: 97425260 e-post: thomasib@stud.hist.no
Fredrik Sørvig tlf: 48036012 e-post: fredrso@stud.hist.no
Olav Gabrielsen tlf: 93412152 e-post: olavgab@stud.hist.no

HØGSKOLEN I SØR-TRØNDELAG
Avdeling for teknologi
Studieprogram for elektro- og datateknikk
7004 TRONDHEIM
Fag: EDT211T Styresystemer og Reguleringsteknikk Dato: 05.03.13
Prosjekt: Nivåregulering i et totanksystem
Aktivitet: Filter. Aktivitet nr: 08
Startdato: 03.04.13 Sluttdato: 08.04.13
Avhengighet: Foregående aktiviteter: 05 Ferdigstille rapport.
Etterfølgende aktiviteter: 10 Test.
Mål: Studentene skal bygge et filter egnet for å fjerne støy i prosessen.
Arbeidsbeskrivelse: Prosjektgruppen må finne ut hvilken type støy som påvirker prosessen
for så å beregne komponenter til et filter som har i oppgave å filtrere bort støyen.
Timeverk: 62 timer Fordeling: Thomas I. Berge 3,5t
Olav Gabrielsen 4,5t
Jostein S. Helland 29,5t
Fredrik Sørvig 24,5t
Kostnader: I dette prosjektet vil det ikkje forekomme noen kostnader.
Ressurser: Ressursene som brukes i prosjektet blir bare arbeidet til studentene.
Risiko: Studentene må være flinke til å taste alt de gjør underveis så de ikke ender opp med
feil verdier og regner videre med dem.
Faglig ansvarlig:
Thomas I. Berge tlf: 97425260 e-post: thomasib@stud.hist.no
Prosjektmedarbeidere:
Jostein S. Helland tlf: 93030878 e-post: josteish@stud.hist.no
Thomas I. Berge tlf: 97425260 e-post: thomasib@stud.hist.no
Fredrik Sørvig tlf: 48036012 e-post: fredrso@stud.hist.no
Olav Gabrielsen tlf: 93412152 e-post: olavgab@stud.hist.no

HØGSKOLEN I SØR-TRØNDELAG
Avdeling for teknologi
Studieprogram for elektro- og datateknikk
7004 TRONDHEIM
Fag: EDT211T Styresystemer og Reguleringsteknikk Dato: 05.03.13
Prosjekt: Nivåregulering i et totanksystem
Aktivitet: Programmering. Aktivitet nr: 09
Startdato: 03.04.13 Sluttdato: 12.04.13
Avhengighet: Foregående aktiviteter: 05 Ferdigstille rapport.
Etterfølgende aktiviteter: 10 Test.
Mål: Studentene skal programmere de forskjellige enhetene for styring av prosessen.
Arbeidsbeskrivelse: Prosjektgruppen må lage programmer for PLS, Intouch og IX-panel.
Dette skal være enkle oversiktlige program som skal regulere nivået i entanksystemet.
Timeverk: 123,5 timer Fordeling: Jostein S. Helland 2t
Bendik Mydland 6t
Erlend V. Ekren 49t
Thomas I. Berge 2,5t
Fredrik Sørvig 64t
Kostnader: I dette prosjektet vil det ikkje forekomme noen kostnader.
Ressurser: Ressursene som brukes i prosjektet blir bare arbeidet til studentene.
Risiko: Studentene må være flinke til å taste alt de gjør underveis så de vet at problemet ikke
ligger i programmene når de skal teste dem på systemet senere.
Faglig ansvarlig:
Olav Gabrielsen tlf: 93412152 e-post: olavgab@stud.hist.no
Prosjektmedarbeidere:
Jostein S. Helland tlf: 93030878 e-post: josteish@stud.hist.no
Bendik Mydland tlf: 99223347 e-post: bendikm@stud.hist.no
Erlend V. Ekren tlf: 41767127 e-post: erlendek@stud.hist.no
Thomas I. Berge tlf: 97425260 e-post: thomasib@stud.hist.no
Fredrik Sørvig tlf: 48036012 e-post: fredrso@stud.hist.no

HØGSKOLEN I SØR-TRØNDELAG
Avdeling for teknologi
Studieprogram for elektro- og datateknikk
7004 TRONDHEIM
Fag: EDT211T Styresystemer og Reguleringsteknikk Dato: 05.03.13
Prosjekt: Nivåregulering i et totanksystem
Aktivitet: Test. Aktivitet nr: 10
Startdato: 03.04.13 Sluttdato: 12.04.13
Avhengighet: Foregående aktiviteter: 08 Filter.
09 Programmering.
Etterfølgende aktiviteter: 11 Tilleggsspesifikasjoner.
Mål: Filteret og programmene skal testes på systemet.
Arbeidsbeskrivelse: Prosjektgruppen skal teste det de har jobbet med i starten av
entankprosjektet på systemet.
Timeverk: 94,5 timer Fordeling: Fredrik Sørvig 24t
Bendik Mydland 36t
Olav Gabrielsen 4t
Erlend V. Ekren 30,5t
Kostnader: I dette prosjektet vil det ikkje forekomme noen kostnader.
Ressurser: Ressursene som brukes i prosjektet blir bare arbeidet til studentene.
Risiko: Om jobben som er gjort tidligere ikke er grundig kan det være vanskelig å få en god
gjennomkjøring.
Faglig ansvarlig:
Bendik Mydland tlf: 99223347 e-post: bendikm@stud.hist.no
Prosjektmedarbeidere:
Bendik Mydland tlf: 99223347 e-post: bendikm@stud.hist.no
Erlend V. Ekren tlf: 41767127 e-post: erlendek@stud.hist.no
Fredrik Sørvig tlf: 48036012 e-post: fredrso@stud.hist.no
Olav Gabrielsen tlf: 93412152 e-post: olavgab@stud.hist.no

HØGSKOLEN I SØR-TRØNDELAG
Avdeling for teknologi
Studieprogram for elektro- og datateknikk
7004 TRONDHEIM
Fag: EDT211T Styresystemer og Reguleringsteknikk Dato: 05.03.13
Prosjekt: Nivåregulering i et totanksystem
Aktivitet: Tilleggsspesifikasjoner. Aktivitet nr: 11
Startdato: 24.04.13 Sluttdato: 30.04.13
Avhengighet: Foregående aktiviteter: 10 Test.
Etterfølgende aktiviteter: 13 Samkjøre oppgave med gruppe 2.
Mål: Gjennomføre så mange tilleggsspesifikasjoner som mulig.
Arbeidsbeskrivelse: Studentene har rangert tilleggsspesifikasjoner etter hvilke oppgaver de
helst vil gjennomføre, målet vil være å gjennomføre så mange som mulig.
Timeverk: 145 timer Fordeling: Jostein S. Helland 93t
Bendik Mydland 8t
Thomas I. Berg 26t
Fredrik Sørvig 7t
Olav Gabrielsen 11t
Kostnader: I dette prosjektet vil det ikkje forekomme noen kostnader.
Ressurser: Ressursene som brukes i prosjektet blir bare arbeidet til studentene.
Risiko: Risikoen her handler om tidsbruk, gruppen må prioritere pprosjektet over
tilleggsspesifikasjonene.
Faglig ansvarlig:
Erlend V. Ekren tlf: 41767127 e-post: erlendek@stud.hist.no
Prosjektmedarbeidere:
Jostein S. Helland tlf: 93030878 e-post: josteish@stud.hist.no
Bendik Mydland tlf: 99223347 e-post: bendikm@stud.hist.no
Thomas I. Berge tlf: 97425260 e-post: thomasib@stud.hist.no
Fredrik Sørvig tlf: 48036012 e-post: fredrso@stud.hist.no
Olav Gabrielsen tlf: 93412152 e-post: olavgab@stud.hist.no

HØGSKOLEN I SØR-TRØNDELAG
Avdeling for teknologi
Studieprogram for elektro- og datateknikk
7004 TRONDHEIM
Fag: EDT211T Styresystemer og Reguleringsteknikk Dato: 05.03.13
Prosjekt: Nivåregulering i et totanksystem
Aktivitet: Ferdigstille rapport, entankprosjekt. Aktivitet nr: 12
Startdato: 03.04.13 Sluttdato: 30.04.13
Avhengighet: Foregående aktiviteter: 05 Ferdigstille rapport, miniprosjekt.
Etterfølgende aktiviteter: 13 Samkjøre oppgave med gruppe 2..
Mål: Prosjektgruppen skal få få ferdig et endelig produkt som skal reflektere hele
prosjektet.
Arbeidsbeskrivelse: Prosjektgruppen skal jobbe kontinuerlig med å få ned hva de gjør
underveis og dokumentere ferdige produkt.
Timeverk: 99,5 timer Fordeling: Jostein S. Helland 21,5t
Bendik Mydland 10t
Erlend V. Ekren 39t
Thomas I. Berg 5t
Fredrik Sørvig 12t
Olav Gabrielsen 12t
Kostnader: I dette prosjektet vil det ikkje forekomme noen kostnader.
Ressurser: Ressursene som brukes i prosjektet blir bare arbeidet til studentene.
Risiko: Tidsbruken kan være vanskelig å beregne og det er en frist for levering.
Faglig ansvarlig:
Jostein S. Helland tlf: 93030878 e-post: josteish@stud.hist.no
Prosjektmedarbeidere:
Jostein S. Helland tlf: 93030878 e-post: josteish@stud.hist.no
Bendik Mydland tlf: 99223347 e-post: bendikm@stud.hist.no
Erlend V. Ekren tlf: 41767127 e-post: erlendek@stud.hist.no
Thomas I. Berge tlf: 97425260 e-post: thomasib@stud.hist.no
Fredrik Sørvig tlf: 48036012 e-post: fredrso@stud.hist.no
Olav Gabrielsen tlf: 93412152 e-post: olavgab@stud.hist.no

HØGSKOLEN I SØR-TRØNDELAG
Avdeling for teknologi
Studieprogram for elektro- og datateknikk
7004 TRONDHEIM
Fag: EDT211T Styresystemer og Reguleringsteknikk Dato: 05.03.13
Prosjekt: Nivåregulering i et totanksystem
Aktivitet: Prosjektmøter Aktivitet nr: 17
Startdato: 04.03.13 Sluttdato: 15.05.13
Avhengighet: Foregående aktiviteter: Denne oppgaven går frå start til slutt, og ingen
oppgaver er avhengig av den.
Etterfølgende aktiviteter: Denne oppgaven går frå start til slutt, og ingen
oppgaver er avhengig av den.
Mål: Arbeidsgiver skal overbevises om at han har tatt det rette valget ved å ansette
prosjektgruppen.
Arbeidsbeskrivelse: Studentene skal en og en beskrive hva han har gjort siden sist
prosjektmøte. De skal lede et møte hver og alle skal ta referat fra et møte.
Timeverk: 75 timer Fordeling: Jostein S. Helland 13,5t
Bendik Mydland 12t
Erlend V. Ekren 8t
Thomas I. Berg 16t
Fredrik Sørvig 7,5t
Olav Gabrielsen 18t
Kostnader: I dette prosjektet vil det ikke forekomme noen kostnader.
Ressurser: Ressursene som brukes i prosjektet blir bare arbeidet til studentene.
Risiko: Om det er en oppgave studentane har stått fast med, så kan det være problematisk å
komme med veldig mye informasjon til arbeidsgivar.
Faglig ansvarlig:
Erlend V. Ekren tlf: 41767127 e-post: erlendek@stud.hist.no
Prosjektmedarbeidere:
Jostein S. Helland tlf: 93030878 e-post: josteish@stud.hist.no
Bendik Mydland tlf: 99223347 e-post: bendikm@stud.hist.no
Erlend V. Ekren tlf: 41767127 e-post: erlendek@stud.hist.no
Thomas I. Berge tlf: 97425260 e-post: thomasib@stud.hist.no
Fredrik Sørvig tlf: 48036012 e-post: fredrso@stud.hist.no
Olav Gabrielsen tlf: 93412152 e-post: olavgab@stud.hist.no

HØGSKOLEN I SØR-TRØNDELAG
Avdeling for teknologi
Studieprogram for elektro- og datateknikk
7004 TRONDHEIM
Fag: EDT211T Styresystemer og Reguleringsteknikk Dato: 05.03.13
Prosjekt: Nivåregulering i et totanksystem
Aktivitet: Gruppemøter. Aktivitet nr: 18
Startdato: 04.03.13 Sluttdato: 13.05.13
Avhengighet: Foregående aktiviteter: Denne oppgaven går frå start til slutt, og ingen
oppgaver er avhengig av den.
Etterfølgende aktiviteter: Denne oppgaven går frå start til slutt, og ingen
oppgaver er avhengig av den.
Mål: Gruppen skal samles hver uke for å få en bedre oversikt av prosjektets fremgang.
Arbeidsbeskrivelse: Prosjektet består mye av å dele lærdom og kunnskap underveis.
Samtidig som gruppen skal få en oversikt over fremgang og eventuelle tidsendringer ut ifra
det planlagte, så skal gruppen lære bort ny kunnskap og forklare hva de har gjort siden sist.
Timeverk: 71,5 timer Fordeling: Jostein S. Helland 11,5t
Bendik Mydland 12t
Erlend V. Ekren 15t
Thomas I. Berg 11t
Fredrik Sørvig 19t
Olav Gabrielsen 3t
Kostnader: I dette prosjektet vil det ikke forekomme noen kostnader.
Ressurser: Ressursene som brukes i prosjektet blir bare arbeidet til studentene.
Risiko: Om dette ikke gjennomføres som planlagt kan det gå utover enkelt studenter som ikke
får tatt imot den informasjonen og kunnskapen han trenger senere i prosjektet.
Faglig ansvarlig:
Jostein S. Helland tlf: 93030878 e-post: josteish@stud.hist.no
Prosjektmedarbeidere:
Jostein S. Helland tlf: 93030878 e-post: josteish@stud.hist.no
Bendik Mydland tlf: 99223347 e-post: bendikm@stud.hist.no
Erlend V. Ekren tlf: 41767127 e-post: erlendek@stud.hist.no
Thomas I. Berge tlf: 97425260 e-post: thomasib@stud.hist.no
Fredrik Sørvig tlf: 48036012 e-post: fredrso@stud.hist.no
Olav Gabrielsen tlf: 93412152 e-post: olavgab@stud.hist.no

HØGSKOLEN I SØR-TRØNDELAG
Avdeling for teknologi
Studieprogram for elektro- og datateknikk
7004 TRONDHEIM
Fag: EDT211T Styresystemer og Reguleringsteknikk Dato: 05.03.13
Prosjekt: Nivåregulering i et totanksystem
Aktivitet: Loggføring. Aktivitet nr: 19
Startdato: 08.03.13 Sluttdato: 10.05.13
Avhengighet: Foregående aktiviteter: Denne oppgaven går frå start til slutt, og ingen
oppgaver er avhengig av den.
Etterfølgende aktiviteter: Denne oppgaven går frå start til slutt, og ingen
oppgaver er avhengig av den.
Mål: Det settes av en time hver fredag for å få skrevet ned tid brukt på prosjektet.
Arbeidsbeskrivelse: Loggføring av brukt tid på prosjekt, er en viktig oppgave så arbeidsgiver
får en bedre oversikt av prosjektet.
Timeverk: 8 timer Fordeling: Jostein S. Helland 2t
Bendik Mydland 3t
Erlend V. Ekren 1t
Fredrik Sørvig 1t
Olav Gabrielsen 1t
Kostnader: I dette prosjektet vil det ikke forekomme noen kostnader.
Ressurser: Ressursene som brukes i prosjektet blir bare arbeidet til studentene.
Risiko: Om denne planen ikke blir gjennomført og det er lenge siden sist gang studentene
noterte i loggboken, kan der være vanskelig å huske når og hvor lenge man har jobbet.
Faglig ansvarlig:
Bendik Mydland tlf: 99223347 e-post: bendikm@stud.hist.no
Prosjektmedarbeidere:
Jostein S. Helland tlf: 93030878 e-post: josteish@stud.hist.no
Bendik Mydland tlf: 99223347 e-post: bendikm@stud.hist.no
Erlend V. Ekren tlf: 41767127 e-post: erlendek@stud.hist.no
Fredrik Sørvig tlf: 48036012 e-post: fredrso@stud.hist.no
Olav Gabrielsen tlf: 93412152 e-post: olavgab@stud.hist.no

Vedlegg E
Arbeidsnotat
35 sider

HØGSKOLEN I SØR-TRØNDELAG
Avdeling for teknologi
Studieprogram for elektro- og datateknikk
7004 TRONDHEIM
Prosjektoppgave i Styresystemer og Reguleringsteknikk,
Oppgavens tittel:
Arbeidsnotat
Prosjektoppgave i faget Styresystemer og reguleringsteknikk
Gruppedeltagere:
Jostein S. Helland(JSH) 93030878
josteish@stud.hist.no
Bendik Mydland(BM) 99223347
bendikm@stud.hist.no
Olav Gabrielsen(OG) 93412152
olavgab@stud.hist.no
Erlend V. Ekren(EVE) 41767127
erlendek@stud.hist.no
Thomas I. Berge(TIB) 97425260
thomasib@stud.hist.no
Fredrik Sørvig(FS)
Studieretning:
48036012
fredrso@stud.hist.no
Automatiseringsteknikk
Oppdragsgiver:
Avdeling for Teknologi v/Per Hveem
Startdato:
21.03.13
Innleveringsdato:
22.04.13
Antall sider/vedlegg:
34/00
Veileder:
Per Hveem
Tlf: 73559593
E-post: per.hveem@hist.no
Prosjektgruppe:
1
Kontaktperson hos
oppdragsgiver:
Se veileder

Arbeidsnotat
Prosjektoppgave i faget Styresystemer
Pumpe
2EA
Vår 2013
Reguleringsventil
Vanntank
Magnetventilene
FT1
Vannreservoar
100 %
60 %
50 %
0 %
LT1
ref.

Sammendrag
En tank, som inneholder vann, skal reguleres slik at nivået i tanken holdes mest
mulig stabilt under drift. Tanken består av et innløp og ett utløp, hvor innløpet blir
styrt av en pumpe og reguleringsventil i serie, mens utløpet blir styrt av tre
magnetventiler montert parallelt.
Det er gitt krav om at et sprang i utløpet skal reguleres inn raskest mulig slik at nivået
holder seg stabilt på ønsket verdi.
Nivået i tanken reguleres ved hjelp av en PI-regulator hvor det er mulighet for
foroverkobling med PD-regulator. Regulatorens innstillinger finnes ved hjelp av å lage
matematisk modell av prosessen for så å simulere og beregne regulatorene ved hjelp
av blokkskjemaregning og Ziegler-Nichols-metode. Prosessens modeller er delt opp i
reguleringsventil, tank og nivåmåler, utstrømning og regulatorene.
PI-regulatorens beste verdier er Kp = 2,7 og Ti = 35.
PD-regulatorens beste verdier er Kp = 0,15, Td = 20, n = 10
Disse verdiene gir innsvingning som tilfredsstiller kravene for prosessen og er vist i
figuren.
75
70
65
60
55
50
45
40
BM
3 til 1 ventil
Uten foroverkopling
Med foroverkopling
1 til 3 ventiler
300 350 400 450
Tid [sekunder]
500 550 600 650

Forord
Arbeidsnotatet omhandler modellering av systemet prosjektet er basert på. Det er
vanlig å lage en matematisk modell av systemet, da det ofte er billigere og mindre
tidskrevende å gjøre simuleringer av antagelser på en modell, enn å utføre det på
den faktiske prosessen. For at simuleringen på modellen skal være relevant, er det
derfor viktig at de individuelle delene av modellen representerer sin reelle motpart så
nøyaktig som mulig. Arbeidsnotatet går derfor også inn på hvordan man best går
frem for å gjøre gode målinger av moduler, og hvilke problemer man kan møte på
langs veien.
Det har for gruppen vært meget givende å gjennomføre denne simuleringen, da man
her faktisk går gjennom hele prosessen fra reelt system til matematisk modell,
regulering av denne, og får se at reguleringsparameterne man kommer frem til
stemmer i virkeligheten. Dette står i sterk kontrast til tidligere oppgaver, hvor man kun
har hatt en av delene, og som oftest ikke har hatt mulighet til å sjekke at verdier man
kommer frem til gir mening utenfor den simulerte modellen. Prosessen med å finne
frem til riktige modeller gav også mulighet for gruppen til å bli bedre kjent med
prosessen, og hvordan de forskjellige delene av prosessen fungerer individuelt, og
som en del av den større prosessen. Gruppen håper at arbeidsnotatet viser til
arbeidsgiver at man i prosjektet går frem for å gjøre en meget grundig jobb med
oppgaven, og på denne måten gjør senere arbeid og vedlikehold av prosessen
lettere.
Til slutt vil gruppen fortsatt takke Per Hveem og Andreas Sørvik fra HiST for
veiledning gjennom prosjekttiden. Gjennom prosjektmøte, og gode praktiske tips, har
de begge vært uvurderlige. Gruppen ser frem til videre samarbeid med begge.
Bendik Mydland Erlend V. Ekren Fredrik Sørvig Jostein S. Helland Thomas I. Berge Olav Gabrielsen
JSH

Innholdsfortegnelse
Innholdsfortegnelse .................................................................................................... 1
Figurliste ..................................................................................................................... 2
Innledning ................................................................................................................... 3
Skjematisk oppsett ..................................................................................................... 4
Modellering ................................................................................................................. 7
Tank, reguleringsventil & nivåmåler ........................................................................ 7
Magnetventilene .................................................................................................... 11
Flowmåler ............................................................................................................. 18
Problemområder ................................................................................................... 21
Regulering ................................................................................................................ 22
PI-regulator ........................................................................................................... 22
PI-regulator med PD-regulert foroverkobling ......................................................... 26
Resultat .................................................................................................................... 29
Litteraturliste ............................................................................................................. 30
1

Figurliste
Figur 1: Bilde av tanken .............................................................................................. 3
Figur 2: Prosesskjema ................................................................................................ 4
Figur 3: Oppkobling ved måling av tankens sprangrespons ....................................... 5
Figur 4: Oppkobling ved måling av magnetventilenes sprangrespons ........................ 6
Figur 5: Tankens sprangrespons ................................................................................ 7
Figur 6: Beregning av tankens sprangrespons ........................................................... 8
Figur 7: Modell av reguleringsventil ............................................................................ 9
Figur 8: Modell av tank med omregningsfaktor ........................................................... 9
Figur 9: Modell av måleelement ................................................................................ 10
Figur 10: Blokkskjema for tank og reguleringsventil ................................................. 10
Figur 11: Simulering av tankens sprangrespons ....................................................... 11
Figur 12: Sprangrespons for åpning av 2 magnetventiler ......................................... 12
Figur 13: Sprangrespons for magnetventil med markert tidskonstant ....................... 15
Figur 14: Sprangrespons for åpning av én magnetventil med markert tidsforsinkelse
................................................................................................................................. 16
Figur 15: Blokkskjema for magnetventilene .............................................................. 17
Figur 16: Sprang med 1 ventil åpen .......................................................................... 18
Figur 18: Blokkskjema for PI-regulator ..................................................................... 22
Figur 17: Blokkskjema for prosess med PI-regulator ................................................ 22
Figur 19: Prosessverdi og pådrag ved høy Kp-verdi ................................................. 23
Figur 20: Innsvingning med parameterverdier fra manuell selvjustering ................... 24
Figur 21: Innsvingning ved bruk av finjusterte regulatorparametere ......................... 25
Figur 22: Blokkskjema for prosessen med foroverkopling ........................................ 26
Figur 23: Innsvingninger med sprang i utløpet med og uten bruk av foroverkopling . 28
2

Innledning
I dette arbeidsnotatet presenteres en matematisk modell for nivåregulering og
foreslåtte regulatorinnstillinger. Nivåreguleringen av tanken er simulert, både med og
uten forover kobling. For å simulere og analysere modellen brukes Matlab /Simulink.
For å kunne finne en brukbar modell for prosessen er prosessen del opp i flere
komponenter. Dette forenkler muligheten for implementering av foroverkobling, med
regulatorinnstillingene, i simuleringen. Foroverkoblingen måler direkte på prosessens
forstyrrelse og gir da et ekstra pådrag i regulatoren som vil kompensere for endring i
forstyrrelsen.
Figur 1: Bilde av tanken
TIB
3

Skjematisk oppsett
Bakgrunn
For å kunne lage gode modeller er det nødvendig med måling av relevante fysiske
størrelser som finnes på anlegget. I dette tilfellet er nivå i, og utstrømning av, tanken
de relevante målbare størrelsene. Ut i fra disse målene, i kombinasjon med at
tankens fysiske mål er kjent, er det mulig å beregne de resterende fysikalske
kvalitetene som trengs for å lage nøyaktige modeller.
BM
Prosesskjema
Prosessen består av en sylindrisk tank hvor en pumpe i serie med reguleringsventil
styrer innløpet og tre magnetventiler i parallell styrer utløpet. Tankens væskenivå blir
Figur 2: Prosesskjema
BM
Pumpe
Reguleringsventil
Vanntank
Magnetventilene
FT1
Vannreservoar
100 %
60 %
50 %
0 %
LT1
ref.
målt ved hjelp av en trykkmåler
i bunnen av tanken som sender
ut et strømsignal hvor 4 – 20mA
tilsvarer et nivå på 0 – 100%.
Utløpet av tanken blir målt av
en flowmåler plassert mellom
tanken og de tre
magnetventilene. Flowmåleren
sender òg ut et strømsignal,
men som her representerer
utgående volumstrøm per
sekund
Figur 2 viser skjematisk
hvordan tanksystemet er satt
opp
4

Koblingsskjema
Måling ved tankens sprangrespons
Grunnen til at vi har valgt å koble det opp som vist i Figur 3, er at vi får kjørt ett
sprang fra 4-20mA inn på reguleringsventilen(LV1). Vi henter ut «nivået» fra LT1 over
motstanden R2. Nivået vi får ut på skopet er fra 1-5V på grunn av at vi måler over
motstanden.
TIB
Figur 3: Oppkobling ved måling av tankens sprangrespons
OG
5

Måling ved magnetventilenes sprangrespons
For å lage en modell for magnetventilene og flowmåleren ser man hvordan
utstrømningen fra tanken endrer seg i forhold til antall åpne ventiler. Det er da
nødvendig å måle endringen tankens væskenivå samtidig med utgående signal fra
flowmåler. Koblingene er vist Figur 4.
BM
Figur 4: Oppkobling ved måling av magnetventilenes sprangrespons
OG
6

Modellering
Tank, reguleringsventil & nivåmåler
Bakgrunn
Vi har valgt å isolere tank og reguleringsventil for seg selv. Nivåmåleren har vi
tilnærmet til en konstant, siden den relativ rask i forhold til resten av prosessen. I
dette tilfelle vil det si at eventuelle tidskonstanter i nivåmåleren ikke vil utgjøre en
vesentlig forskjell i simuleringa. For å finne overføringsfunksjonen til tank, ventil og
måleelement, har vi kjørt et sprang på reguleringsventilen fra 0-100 % uten utløp.
TIB
Målinger
Prosessen i Figur 5 viser hvordan nivået endrer seg når vi kjører på ett sprang på
reguleringsventilen fra 4-20mA. Det som vi oppnår med dette, er at vi får skilt ut
tidsforsinkelsen. Vi ser når spranget kommer, og når tanken er på 100 % (5V).
TIB
Figur 5: Tankens sprangrespons
7

Måleelement:
Måleelementet omformer fra høyde(%) til V(1-5V). Blokken fra Simulink er vist under i
Figur 9.
Figur 9: Modell av måleelement
TIB
Resultat
Simulert i Simulink:
For å kontrollere at overføringsfunksjonen vi har regnet er rett, har vi laget
blokkskjema, som vist i Figur 10.
Har simulert modellen med pådrag 4V inn på reguleringsventilen, og får ut Figur 11
på scoopet. Dette er likt i forhold til resultatet av Figur 5, og kan derfor si at vi har
funnet en god modell for Reguleringsventilen og tanken.
Figur 10: Blokkskjema for tank og reguleringsventil
10

Målinger
For hver ventiltilstand (1, 2, eller 3 åpne ventiler) ble det målt hvor mye
gjennomstrømning som gikk ut av tanken. Gjennomstrømning ble målt ved å se på
hvor raskt nivået sank i tanken. I tillegg ble det målt hvor mye
gjennomstrømningsmåleren, FT1, gir ut ved hver ventiltilstand. Det er her forutsatt at
alle ventilene er likt dimensjonert. Utløpet som funksjon av nivået i tanken er ikke
lineært da gjennomstrømningen er en funksjon av kvadratroten av differansetrykket
over ventilene. Dette differansetrykket endrer seg proporsjonalt med nivået i tanken.
For å gjøre simulering og beregning enklere ble det utført målinger bare rundt
arbeidspunktet til tanken og dermed beregnet som om det er lineært. Arbeidspunktet
til tanken er gitt til et nivå på 60% av maks.
Figur 12 viser målingene som ble gjort ved 2 ventiler åpne. Bildet viser nivået (Gul
kurve) og signalet fra FT1 (Grønn kurve)
Figur 12: Sprangrespons for åpning av 2 magnetventiler
BM
12

Flowmåler
Bakgrunn
Tanken har 3 magnetiske ventiler som styrer utløpet fra tanken, i tillegg til en manuell
ventil som man i dette tilfelle ikke regnes med. Utløpet blir målt med en flowmåler,
som gir et utslag mellom 0-5 V, hvor gyldig område ligger mellom 1-5 V, og 0-1 V
ansees som feilmelding.
Man har altså en måler som måler volumstrøm, og gir ut spenning. Denne
spenningen vil så bli brukt for effektivt å kunne beregne en god
foroverkoplingsregulator, og det er derfor viktig å ha en god modell av måleren.
JSH
Målinger
For å se målingene fra flowmåleren målte man signalet som gikk inn på PLS’en sin
AD-DA omformer. Fra omformeren sin andre kanal måltes samtidig nivået i tanken.
Man hadde mål for volumet i tanken fra beregninger, som vist under kapittelet om
magnetventilenes overføringsfunksjon, og kunne dermed approksimere utløpet ved å
måle hvor mye tankens nivå endret seg over en viss periode med x antall
magnetventiler aktive. Grunnet utløpets ulinearitet gjorde man små sprang rundt
arbeidspunket på 60 %. Man leste også av det flowmåleren viste i punktet 60 %, for å
kunne ha en referanse på hva man ville ha ut fra flowmåleren relativt til antall aktive
utløp.
Figur 16: Sprang med 1 ventil åpen
JSH
18

Problemområder
Under analysen av tanken møtte gruppen på noen problemer som gjorde det
utfordrende å gjengi prosessen korrekt i en matematisk modell. I stor grad utgikk de
fleste problemene fra en og samme kilde, nemlig at det, slik oppsettet av prosessen
er per dags dato, var vanskelig å skille fra hverandre de fysiske egenskapene til
selve tanken og reguleringsventilen som styrer dens innstrømning.
Problemet ble i første omgang løst ved å ta sprangresponsene over både ventil og
sprang samtidig. Det resulterte i en overføringsfunksjon som inneholdt både en
førsteordens prosess med tidsforsinkelse, samt et integratorledd. Teoretisk sett vil en
tank som oftest være en ren integrator, og man kan i likhet tenke seg at en ventil godt
kan gjengis som en førsteordens prosess med tidsforsinkelse. Det ble dermed mulig
å tilkjenne de forskjellige delene av sprangresponsen til de to modulene.
Beklageligvis forplantet denne avgjørelsen seg gjennom resten av modellen, som nå
måtte ta hensyn til denne antagelsen. I første omgang møtte man på problemet om
hvor utstrømningen skulle kobles inn i modellen. I en vanlig modell vil utstrømninger
og innstrømninger adderes rett før selve tanken, og utsignalet fra tanken da være et
godt mål på det nåværende volumet i tanken. Gruppen kom til enighet om at det ikke
uten videre ville være naturlig å gjøre dette denne gangen, men at man måtte ta
hensyn til utstrømning utenfor den sammenkoblede modellen for tank og ventil. Det
igjen førte til at man måtte legge til en integrator for innstrømningen før man kan
legge den til prosessignalet etter tankens overføringsfunksjon.
Denne fremgangsmetoden gjør at modellen ikke er skjematisk lik den reelle
prosessen, men gruppen kom frem til at det allikevel var den beste måten å
presentere den på uten å måtte ta antagelser om tanken og ventilen man ikke kunne
stå til gode for.
JSH
21

Regulering
PI-regulator
Figur 17: Blokkskjema for prosess med PI-regulator
Bakgrunn
I arbeidsnotatet er formålet å komme frem til best mulig regulatorinnstillinger for
systemet. Vi har konstruert en PI-regulator, som vist i Figur 18.
Regulatorblokken:
Figur 18: Blokkskjema for PI-regulator
Det er satt inn anti-windup på integratoren for å kunne sette grenser på maks/min
pådrag fra I-delen. Setter også metningsgrense etter regulatoren for at pådraget ikke
skal overstige maks pådrag.
TIB
22

Måling
For å finne innstillinger for regulatoren, har vi brukt manuell selvjustering som
fremgangsmåte. Regulatoren stilles inn med veldig høy P-forsterkning og
integratordelen utkoblet, slik at pådraget i dette tilfelle svinger mellom 0 % -100 %.
100
90
80
70
60
50
40
30
20
10
0
Figur 19: Prosessverdi og pådrag ved høy Kp-verdi
Referansen er stilt inn på 60 %. Grunnen til at regulatoren ikke greier å svinge rundt
60 %, er at utløpet er lite i forhold til pådraget. Regulatoren vil kunne motvirke positivt
avvik raskere enn negativt avvik. På grunn av tidsforsinkelse for pådraget, vil
regulatoren sent merke at nivået er høyere enn referansen.
TIB
Prosessverdi Pådrag
Tk
180 200 220 240 260
Tid [sekunder]
280 300 320 340
23

Resultat
I følge oppgaven skulle vi stille inn regulatoren etter minimum areal, som vil si 4-6
halvperioder, samtidig som den skal stille seg inn på ±2 % av referansen raskest
mulig.
For at nivået skal svinge seg inn etter minimum areal, har vi funnet nye
regulatorinnstillinger hvor:
Kp= 2.7
Ti= 35
80
75
70
65
60
55
50
Figur 21: Innsvingning ved bruk av finjusterte regulatorparametere
TIB
Nye regulatorinnstillinger
240 260 280 300 320
Tid [sekunder]
340 360 380 400
±2%
25

PI-regulator med PD-regulert foroverkobling
Bakgrunn
I prosjektet behandles en prosess som i hovedsak kan sees på som relativt treg. Den
er i tillegg utsatt for variable forstyrrelser i form av at utløpet kan endres relativt
drastisk. En vanlig reguleringssløyfe vil dermed få vanskeligheter med å effektivt
motvirke endringer i forstyrrelsen, og prosessen vil bruke relativt lang tid på å stille
seg inn igjen. For å motvirke dette, tilsier spesifikasjonene til prosjektet at sløyfen
skal inneholde en foroverkoplingsregulator, som er en metode for nettopp å motvirke
endringer i en forstyrrelse. Håpet er at denne regulatoren vil føre til en raskere
regulering, og bedre stabilitet for sløyfen som helhet.
Figur 22: Blokkskjema for prosessen med foroverkopling
JSH
Beregning
Tanken bak en ideell foroverkopling er å gi foroverkoplingsregulatoren en
overføringsfunksjon som gjør at utsignalet fra prosessen ikke er påvirket av
forstyrrelsen. Denne er ikke alltid fysisk realiserbar, men brukes ofte til å gi en
pekepinn på hvordan regulatoren kan gjennomføres.
26

Resultat
Gruppen har funnet frem til en modell som tilsynelatende er en god representasjon
for den reelle prosessen. Denne modellen er brukt til simuleringer ved hjelp av
programmet Simulink og det er funnet tilfredsstillende verdier for
regulatorparameterene.
PI-regulatorens beste verdier er Kp = 2,7 og Ti = 35.
PD-regulatorens beste verdier er Kp = 0,15, Td = 20, n = 10
Det er gitt krav om at nivået i tanken skal reguleres stabilt og raskest mulig ved
eventuelle sprang i utløpet. Hurtigheten er definert som tiden det tar før prosessens
avvik er stabilt innenfor 2 % av maksimalt måleområde.
Ved hjelp av foroverkobling blir krav som er stilt til hurtighet og stabilitet i tankens
nivå oppfylt tilfredsstillende ved de foreslåtte regulatorparameterene under
simulering.
BM; JSH
29

Litteraturliste
DE Seborg, TF Edgar, DA Mellichamp, FJ Doyle III, Process Dynamics and Control,
3d edn, John Wiley & Sons (Asia) Pte Ltd, China, 2011
K Bjørvik & P Hveem, Reguleringsteknikk, Kybernetes Forlag, Trondheim, 2012
P Hveem & AS, Tips til prosjekt i Styresystemer våren 2012, lastet ned 20.3.2013,
https://www.itslearning.com/file/download.aspx?FileID=2371492&FileVersionID=-1
(Begrenset tilgang)
30