HMILØSNING MEDWONDERWARE. ITF32012BacheloroppgaveB FJERNSTYRINGAVMODELLBYMEDENMODERNEINDUSTRIELLITPLATTFORM

Transkript

1 HMILØSNING MEDWONDERWARE FJERNSTYRINGAVMODELLBYMEDENMODERNEINDUSTRIELLITPLATTFORM ITF32012BacheloroppgaveB NilsMikalLerøy KarzanSalihi TorArneTorgersen AjwanMamshi InnlevertJuni2014

2

3 HØGSKOLEN I ØSTFOLD Avdeling for Informasjonsteknologi Remmen 1757 Halden Telefon: URL: BACHELOROPPGAVE Prosjektkategori: Hovedprosjekt, Bacheloroppgave Omfang i studiepoeng: 20 Fagområde: Industriell IT X Fritt tilgjengelig Fritt tilgjengelig etter Tilgjengelig etter avtale med oppdragsgiver Tittel: HMI Løsning med Wonderware Forfatterere: Ajwan Mamshi, Nils Mikal Lerøy, Karzan Salihi og Tor Arne Torgersen Avdeling / Program: Avdeling for Informasjonsteknologi, Studieprogram dataingeniør og informatikk Oppdragsgiver: HiØ/IT Dato: Veileder: Einar Krogh Prosjektnummer: BO Kontaktperson hos oppdragsgiver: Robert Roppestad, Aksel Lindberg (Invensys) Ekstrakt: Utvikling og testing av Wonderware HMI mot en av skolens labmodeller for å styre og overvåke prosesser på denne. Utifra dette grunnlaget vil vi se om det er en programvare som kan være til nytte for undervisning ved Høgskolen. 3 emneord: HMI PLS Wonderware

4

5 ØSTFOLD UNIVERSITY COLLEGE Information Technology and Informatics Remmen 1757 Halden Phone: URL: PROJECT REPORT Category of Project: Bachelor thesis Number of stp (1stp=1ECTS): 20 Engineering field: Industrial IT X June 07, 2014 Free accessible Free accessible after Accessible after agreement with the contractor Title: HMI Solution using Wonderware Authors: Ajwan Mamshi, Nils Mikal Lerøy, Karzan Salihi og Tor Arne Torgersen Department / line: Department of Information Technology, Course: Engineer and Computer Science Contracting Authority: HiØ/IT Date: may 22, 2014 Instructor: Einar Krogh Project code: BO Contact person at the contractor: Robert Roppestad, Aksel Lindberg (Invensys) Extract: In this project we will make a HMI to control different parts of a model city. The result will be used as the basis for making lab assignments for new engineer students. 3 indexing terms: HMI PLS Wonderware

6

7 Sammendrag Oppdraget er å implementere Wonderware System Platform mot modellbyen. Vi utviklet et brukergrensesnitt (HMI) som kjører på ulike plattformer. Gruppen tester ut moduler som håndterer produksjonsmåling, sporing og rapportering. Alt har blitt dokumentert slik at resultatet kan benyttes i undervisning og selvstudium. Hensikten med oppdraget er å se hvordan Wonderware pakken fungerer, og om dette er noe skolen kan bruke videre. Basert på våre tester og det ferdige produktet, ser vi at dette er en robust programpakke som vi kan anbefale vår oppdragsgiver. Wonderware har også implementert løsninger som gjør at det er lett å ta i bruk løsningen på nettbrett og andre mobile enheter som støtter HTML 5 nettlesere. Brukerveiledningen vil være et godt utgangspunkt for både studenter og ansatte på IT avdelingen. Ved å følge veiledningen kan de raskt få satt opp et eget HMI. Oppdragsgiver vil også sette pris på brukerveiledningen som er et godt utgangspunkt for å utforme laboppgaver. Bruk av denne programpakken gir studenter et godt innblikk i en moderne industriell IT plattform, og gjør at de selv kan prøve seg på å lage egne systemer. i

8

9 Takk til Først vil vi spesielt takke vår veileder Einar Krogh. Han har tatt seg tid til å sette seg inn i vårt prosjekt, vært tilgjengelig både i tide og utide, og gitt oss gode tilbakemeldinger på hvordan vi skal få til en god rapport. Vi vil også takke vår arbeidsgiver Robert Roppestad for all hjelp og støtte. Når vi har stått fast har han alltid tatt seg tid til å hjelpe oss igang igjen. Spesielt vil vi takke for den hjelpen han bidro med når det gjaldt å få igang PLS-en, som noen ganger kunne være litt vanskelig å forstå seg på. Videre ønsker vi å takke Aksel Lindberg fra Invensys, som var behjelpelige med veiledning, og sponsing av programvare med lisenser til Wonderware programpakken. Når vi stod fast med Historian kom Tom Qviller oss til unnsetning og satte av flere timer per telefon. Uten hans hjelp hadde vi nok ikke fått til databasen. Ikke nok med det, han har også bidratt med to gode og informative kurs hvor vi lærte mye om Wonderware og hvordan dette systemet fungerte. Vi ønsker også å takke Invensys for kursmateriale som ble utlevert. Dette var utformet på en så god måte at det ga oss mange nyttige og gode ideer som vi kunne bruke når vi utarbeidet brukerveiledningene for fremtidige studenter her på Høgskolen i Østfold. Så vil vi takke Olav Aaker som satte av mye tid til å hjelpe oss igang med PLS-en og veiledet oss i hvordan vi skulle programmere den på en god og riktig måte. Avslutningsvis vil vi bruke anledningen til å takke alle ved Høgskolen i Østfold som har vært med å forberedt oss til denne oppgaven, vi setter stor pris på alle gode råd og den hjelp vi har fått til å fullføre dette prosjektet. iii

10

11 Innhold Sammendrag Takk Til Figurliste Terminologi i iii ix xi 1 Introduksjon Prosjektgruppen Oppdragsgiver Oppdraget Formål, leveranser og metode Rapportstruktur Analyse Dagens Modellbysituasjon Oppsett av vårt system Andre tilsvarende oppgaver eller oppsett Utforming og Planlegging Innhold HMI Oppsett PLS og PC Nettbrett og mobil Kommunikasjon Andre funksjoner i Wonderware v

12 INNHOLD vi 3.6 Brukerveiledning Kurs hos Invensys Gjennomføring og implementering Forberedelser Klargjøring av en klient Opprette kommunikasjon med OPC Server Innledende konfigurasjon Oppsett PLS PC Oppsett av HMI Overgang til Server 2008 R Nettbrett løsning Database Problemer underveis Spørsmål og svar Evaluering og utprøving av systemet Installasjon, bruk og konfigurasjoner Utviklings muligheter Brukervennlighet Hjelperessurser Ekstra utover selve HMI Diverse Diskusjon 68 7 Konklusjon 71 Bibliografi 74 Register 75

13

14 Figurer 1.1 HMI fjernstyring av Modellbyen Modellby Modulene er senket ned i bordplaten PLS og alle andre elementene montert på veggen Wonderware System Platform. (bilde fra Ivensys sine nettsider) Et eksempel på et HMI. (bilde fra Invensys sine nettsider) Utkast til vår HMI løsning Et eksempel på funksjonsblokkdiagram Et eksempel på Layout En illustrering på HMI Hele systemet snakker sammen på denne måten PC-en vi har installert Wonderware og VMware på To virtuelle PC-er med samme spesifikasjoner Installasjon av Wonderware Hovedbilde av ArchestrA License Manager Her vises hvordan legge til OPC objekter i SMC Kommunikasjon OPC modellbyen mot HMI Dette vinduet kommer opp når man trykker på knappen Browse OPC Items Lister over navnene på Device Items Første vindu for å opprette en galaxy Lage ny InTouch applikasjon OPC kobling 1, fått på mail fra Invensys tekniker viii

15 FIGURER ix 4.12 OPC kobling 2, fått på mail fra Invensys tekniker I/O test Grafikknapp Grafikkelementer Tag tilknytning mot grafikk En modul fra Phoenix. (bilde fra Variabler mot I/O koblinger del Variabler mot I/O koblinger del Funksjonsblokker del 1 for trafikkryss Funksjonsblokker del 2 for trafikkryss Opprette en ny InTouch Applikasjon HMI vindu: Overblikksbildet HMI vindu: Trafikklys HMI vindu: Trafikklys HMI vindu: Huset Den skjulte knappen i HMI-et HMI vindu: Vannpumpe HMI vindu: Gatelys HMI main med 3 trender Skript-kode for vannpumpe Skript-kode for fotgjengerknappen i trafikklys IP instillinger for Windows server Opprettelse av brukernavn og passord Valg av funksjoner for server Installasjon av Wonderware Installasjon av Remote Desktop Services Inn logging på InTouch Access Anywhare oå nettbrett HMI på nettbrett via InTouch Access Anyware Programmet Query. Brukes til å lese tabeller med data Programmet Trend. Brukes til å representere data fra PLS-tagene

16

17 Terminologi HMI Human Machine Interface. Dette er et grafisk grensesnitt som sørger for at en operatør kan styre og overvåke prosesser gjennom en datamaskin. Er mye brukt i industrien, hvor operatøren styrer en prosess ute i fabrikken, som gjerne er knyttet til en PLS. PLS Programmerbar Logisk Styring. Denne enheten er en enkel datamaskin som kan sende ut signaler til enheter og prosesser som en del av et automasjonssystem. OPC Åpenhet, produktivitet og kontroll. (Openness Productivity and Collaboration). Er en verdensomspennende standard for hvordan data skal bli behandlet mellom forskjellige mykvare. Brukes til å dele I/O fra en PLS. I/O prosess Er en prosess som er koblet til en PLS. Dette kan feks være en pumpe, ventil, lys, sensor osv. I/O står for Input Output, og sier at dette er noe man kan sende signaler inn til, eller hente signaler ut ifra. Phoenix Contact Er en tysk produsent av teknisk utstyr som brukes i industriell automatisering. Modellbyen Modellen vi styrer fra det HMI vi har utviklet. Inneholder trafikklys, et smarthus, gatelys og vannpumpe. Dette er koblet opp mot en PLS. VMware En programvareprodusent som lager programvare for skylagring og Virtualisering av operativsystemer. Galaxy Det er navnet på en hel Wonderware applikasjon som også inkluderer et HMI. xi

18

19 Kapittel 1 Introduksjon 1.1 Prosjektgruppen Gruppe 21 består av fire medlemmer, tre fra dataingeniør linjen og en fra informatikk. Vi har samarbeidet tidligere i andre fag og har derfor noe kjennskap til hverandre fra før. Deltagere: Navn: Ajwan Mamshi Født: 1987 Linje: Informatikk - Design og utvikling av IT-systemer. Om: Kommer fra Moss og studerer informatikk på Høgskolen i Østfold. Han ble interessert i informatikk fordi alt som har med utvikling av systemer å gjøre fascinerer ham. Navn: Karzan Salihi Født: 1985 Linje: Dataingeniør Om: Studerer til dataingeniør og holder til i Sarpsborg. Grunnen til at han valgte dataingeniør var fordi det er den mest spennende linjen. Han har alltid vært nysgjerrig på teknologi og hvordan ting fungerer. Navn: Nils Mikal Lerøy Født: 1978 Linje: Dataingeniør Om: Valgte Dataingeniør siden han tidligere har jobbet med IT og kunne tenke seg tilbake i den bransjen. Tok først fullt forkurs, da høgskolen ikke godkjente highschool diplom fra USA som fullverdig videregående fra Norge. Han begynte med data da han var 10 år gammel, og har siden den tid hatt stort interesse for faget. Navn: Tor Arne Torgersen Født: 1986 Linje: Dataingeniør Om: Utdanner seg som dataingeniør, fordi han alltid har hatt dette som interesse. Kom til Høgskolen via Y-vei, da han hadde yrkesfaglig bakgrunn fra før. Tor Arne var med i det første kullet som fikk denne mulighetn. Han holder til både i Mysen og i Halden. 1

20 1.2. Oppdragsgiver Oppdragsgiver Oppdragsgiver for dette prosjektet er Høgskolen i Østfold og Invensys. Høgskolen er representert av Robert Roppestad, og Invensys av Aksel Lindberg. Robert er studieleder ved avdeling for Informasjonsteknologi og underviser i faget Industriell IT, Aksel Lindberg er ingeniør og salgsdirektør ved Invensys. Invensys leverer Wonderwares Archestra System Platform som brukes i prosjektet. Programpakken brukes i alt fra maskin- og robotstyringer til styring av oljeplattformer. Det er satt opp to kurs i regi av Invensys. Gruppen er tilbudt plass på kurset, noe vi vil dra stor nytte av. Kurset gir gruppen grunnleggende innføring i hvordan software løsningen fungerer, slik at vi lettere kan sette oss inn i mer av programvaren på egen hånd. Tom Qviller er kursleder, og gir gruppen god innsikt i flere av de mulighetene programpakken gjør tilgjenglig. Tom Qviller er også vår tekniske støtte hvis vi skulle trenge det i løpet av prosjektet. Aksel Lindberg gir oss lisenser for testing, og gir også oppfølging vedrørende programvaren. 1.3 Oppdraget Oppdraget består i å bruke Invensys sitt produkt til å utvikle et grafisk brukergrensesnitt (HMI) som kontrollerer høgskolens modellby. Til dette bruker vi den profesjonelle industrielle IT plattformen Wonderware, med sitt InTouch HMI. Intouch HMI er Wonderware sitt program for å utvikle og vise profesjonelle brukergrensesnitt tilknyttet prosesser i industri og andre virksomheter som bruker automasjon. Den er anerkjent i fagmiljøet, og gjør at man raskt kan lage gode standariserte løsninger som kan brukes på PC såvel som på nettbrett og mobil. Systemet kobles opp mot PLS-en som styrer Modellbyen. PLS-en har forskjellige enheter koblet til seg. Disse enhetene består av trafikklys, vannpumpe, og et legohus med sensorer. Først setter vi opp en maskin med Windows OS. Vi har valget mellom en server versjon av windows eller standard version. Server versjoner blir vanligvis brukt for dette systemet, men vi ønsker å se på hvordan et vanlig operativsystem takler Wonderware pakken, og velger derfor å kjøre Windows 7. Vi setter opp et brukergrensesnitt med InTouch. Dette er den viktigste delen av oppgaven som vi gjør så profesjonelt som mulig. Resultatet ser vi fungere på forskjellige plattformer som PC, nettbrett og mobil. Vi tester ut moduler som håndterer produksjonmålinger, sporing, rapportering, alarmer og trender. Det er ønskelig å overvåke prosesser og lagre dette i et system som igjen kan presenteres ved en senere anledning. Denne informasjonen formidler vi på en slik måte at en operatør skal kunne lese av historikken til forskjellige prosesser.

21 1.4. Formål, leveranser og metode 3 Figur 1.1: HMI fjernstyring av Modellbyen Gjennomføringen dokumenteres slik at vår erfaring og kompetanse kan komme nye studenter til gode både i undervisningsøyemed, og ved arbeid med lab oppgaver. Vi utarbeider en solid brukerveiledning som beskriver hvordan man setter dette opp fra bunnen av. Denne brukerveildningen vil være et godt utgangspunkt for oppdragsgiver som skal bruke den i undervisning og til lab oppgaver. Vi bygger opp guiden på en slik måte at det skal være mulig for en fersk student å sette seg ned med den og bygge opp ett helt nytt system. De vil ved å ha fulgt guiden få innsikt nok til selv å sette opp egne HMI applikasjoner. 1.4 Formål, leveranser og metode Hvordan kan den profesjonelle plattformen Wonderware brukes i eventuell undervisning i Industriell IT, og hva kan vi gjøre med denne pakken? Hvordan kan man koble Wonderware Intouch HMI opp mot modellbyen, og hvor avansert kan vi få det til å bli? Formål Hovedmål Etablere et profesjonelt HMI grensesnitt mot modellbyen på skolen ved hjelp av Wonderware sin programpakke, for eventuell bruk i skolens undervisning Delmål 1 Sette opp et HMI mot modellbyen på høgskolen Delmål 1. 1 Installere og få Wonderware opp å gå på PC og koble den mot PLS og OPC Delmål 1. 2 Teste ut at vi kan styre landsbyen rett fra vår PC Delmål 1. 3 Utvikle et brukervennlig HMI på PC-en vår som kan styre det meste i landsbyen

22 1.4. Formål, leveranser og metode 4 Delmål 2 Lage en brukerveiledning som viser fremtidige studenter hvordan man setter opp et HMI system Delmål 3 Utvide HMI-et til å brukes på nettbrett og telefoner Delmål 4 Utforme en rapport som viser vårt arbeid og resultat fra prosjektet Gjennom disse punktene vil vi med dette prosjektet sørge for at Høgskolen får et innblikk i en programvare som kan være aktuell å bruke i undervisningen, og demonstrere hva Wonderware sin plattform kan brukes til. Med bakgrunn i denne rapporten tar lærere ved skolen en avgjørelse om Wonderware er noe de vil satse på, og ta med i undervisningen for nye IT-studenter Leveranser Hovedresultatet er et ferdig system basert på InTouch HMI. Fra HMI-et vi lager kan vi fjernstyre modellbyen vi har på Høgskolen. Funksjoner inkluderer muligheten til å slå av og på lys, styre pumpefunksjoner, aktivere program og lese av variable verdier som temperatur og lysstyrke i rommet. Det er et ønske fra oppdragsgiver av vi skal lage en brukerveiledning som kan bli brukt i fremtidig undervisning i faget Industriell IT. Dette tar vi høyde for når vi planlegger hvordan vi skal sette opp guiden. Vi kjenner til hvor lite vi selv kunne når vi begynte på skolen. Fant derfor forsøkspersoner som fulgte guiden og kom med kommentarer på hva som var uklart slik at vi kunne gjøre enda mer presis og enkel å følge. Derfor er en del av leveransen en god brukerveiledning som gir en innføring i bruk av InTouch. Ved hjelp av denne veildningen skal studenter klare å sette opp sitt eget HMI. Arbeidet med brukerveiledningen danner store deler av grunnlaget for denne rapporten. Oversikt over hovedelementene: Et ferdig system for fjernstyring ved hjelp av InTouch HMI Brukerveiledning for InTouch fra WonderWare Hovedrapport for prosjektet Metode For å komme i mål med dette prosjektet deltar vi på kurs i regi av Invensys, distributør av Wonderware i Skandinavia. Her lærer vi mer inngående om hvordan programmpakken fungerer. Dette er essensielt for å klare å gjennomføre prosjektet, da programvaren er veldig omfattende.

23 1.4. Formål, leveranser og metode 5 Vi velger å sette opp faste dager hver uke hvor vi setter av tid til å jobbe med prosjektet. Dette for å holde en jevn flyt i prosessen, og sørge for at vi har en detaljert plan for når det skal jobbes med de forskjellige delene av prosjektet. Vi holder ukentlige møter, og passer på at alle jobber med sine delegerte oppgaver til enhver tid. Vi dokumenterer arbeidet underveis, og der det er relevant sjekker vi at utført oppgave fungerer tilfredstillende. Vi bruker ressurspersoner her på skolen og hos Invensys når det gjelder tekniske spørsmål og problemer, slik at vi ikke står alene hvis det skulle være noe. Vi setter oss inn i den programvaren vi benytter. Setter oss også inn i hvordan modellbyen er satt opp, hvordan PLS-en er koblet opp og dokumentasjonen til modellbyen. Vi holder jevn kontakt med Aksel Lindberg og Tom Qviller fra Invensys. På Høgskolen i Østfold blir kontaktpersonen Robert Roppestad. Det blir gjennom programvaren Wonderware InTouch vi skal nå målet. Vi skriver logg og dokumentasjon kontinuerlig, så kan vi spore tilbake hva som ble gjort hvis noe ikke skulle fungere som forventet. Fremgangsmåten: Setter opp utstyr: PC med InTouch HMI, og gjøre denne klar for bruk. Lærer om programvaren via seminaret og nettkilder, samt sjekker hjelpesider eller kontakter Aksel fra Invensys. Setter oss inn i rapporten for modellbyen og finne ut av alle prosessene vi kan styre. Starter med design og tester InTouch mot modellbyen ved å koble oss til OPC serveren og prøver å aktivere tagger via InTouch. Designer så selve HMI-et, og kommer med første versjon. Vi tester ut funksjoner og prøver å få kontakt med alle tagger. Vi mestrer programmet godt nok og videreutvikler første versjon for å få et mer profesjonelt preg. Rapport og brukerveiledningen lager vi underveis. Vi vet at det lønner seg å skrive fortløpende, ikke spare alt til slutt. Brukerveiledningen settes opp slik at ferske studenter skal kunne sette opp et like bra HMI som vi nå setter opp. Avslutningsvis leverer vi en god og ryddig rapport med de tilhørende vedlegg.

24 1.5. Rapportstruktur 6 Problemer: Det å koble opp mot OPC server og direkte mot PLS kan by på problemer. Bugs og uforutsette utfordringer vil sannsynligvis dukke opp. Når det skjer må vi se til at vi raskt løser det, og om nødvendig spørre Robert som kjenner til systemet. Det er mange forskjellige funksjoner i InTouch HMI. Vi må sørge for at vi ikke går oss vill i alle funksjonene. Når situasjoner oppstår og ting ikke fungerer som vi forventer, kan det by på problemer som stjeler mye tid. Det er ofte de små feilene som tar mest tid og ressurser. Gruppe medlemmene har forskjellige fag og fokus. Dette kan bidra til å dra fokus bort fra hovedprosjektet. Utfordringer med kommunikasjon vil sansynligvis dukke opp. Laben kan tidvis være opptatt siden det er flere klasser som bruker den. Vi må prøve å få jobbet de tidene som det er minst aktivitet der. 1.5 Rapportstruktur I kapittel 2 ser vi på dagens situasjon når det gjelder modellbyen. Vi går litt inn på selve PLS-en, og får med mer om OPC serveren vi skal bruke. Videre gir vi en kort beskrivelse av selve Wonderware programpakken, og hva den inneholder. Selve HMI-et vil vi også gå inn på, samt hva vi har tenkt å gjøre. Til slutt vil vi skrive om andre tidligere oppgaver tilknyttet modellbyen. I kapittel 3 går vi gjennom planleggingsfasen. Her vil vi forklare nærmere hva vi har sett for oss at vi skal gjøre, hvordan vi har tenkt å gjøre dette, og hva vi skal ha med i systemet. Vi starter med innholdet i HMI-et, fortsetter så med oppsett av PLS PC-en, integrering mot flere enheter, hvordan kommunikasjonen gjøres, andre relevante funksjoner i Wonderware, og til slutt; vil vi snakke litt om brukerveiledningen. Kapittel 4 tar for seg selve gjennomføringen av prosjektet. Her er kjernen av oppgaven nøye dokumentert. Her skal vi ha med alt vi har gjort, hvordan vi har gjort det, og hvorfor vi har gjort det på den måten. Til slutt oppsummerer vi oppgaven og resultatet ved å drøfte, konkludere og skrive litt om problemer underveis.

25 Kapittel 2 Analyse Her vil vi vise frem hvordan vi implementerer en profesjonell industriell IT plattform mot Modellbyen. Før vi beskriver det, skal vi se på hva som er implementert og hvordan Modellbyen og PLS systemet er satt opp per dags dato. Vi skal også se hva slags programvarer og utstyr vi bruker for å kunne fjernstyre. 2.1 Dagens Modellbysituasjon Modellbyen vi fjernstyrer er bygd opp av tre deler. Den første er Modellbyen av lego med de forskjellige komponentene, et tilhørende PLS system montert på veggen. Den siste delen er en PC med en OPC server installert. Figur 2.1: Modellby 7

26 2.1. Dagens Modellbysituasjon Modellbyen Modellbyen består av forskjellige komponenter. Den er satt opp av fire plater som kan kobles fra hverandre, noe som er praktisk når man må flytte modellen. Figur 2.2: Modulene er senket ned i bordplaten. Modellbyen er satt opp av tidligere studenter som et hovedprosjekt. På Modellbyen er det montert forskjellige komponenter av typen trafikklys, gatelys, vanntank og vannpumpe. Komponentene kan ikke styres eller overvåkes direkte, men ved hjelp av PLS systemet får man kontakt med komponentene. Mer om PLS systemet kommer vi tilbake til i punkt Oversikt over delene til modellbyen Trafikklys Det er to lyskryss, ett fireveiskryss med fire trafikklys og fire fotgjengeroverganger. Det andre er et T-kryss med en fotgjengeroverganger. Disse trafikklysene må programmeres på PLS-en for å kunne fungere. Gatelys Det er tre seriekoblede gatelys. Disse gatelysene er koblet til en analog modul som gjør at vi kan regulere styrken på lyset fra et HMI. Intelligent hus Modellbyen har et lite smarthus. Her vil du finne temperaturmåler, varmeelement, ledlys samt en dør bryter. Reguleringstank Det er montert tre kapasitive sensorer som leser av vannivået i tanken. De er nyttige sensorer med tanke på programmering og styring av pumpen.

27 2.1. Dagens Modellbysituasjon 9 Bluetooth enheten Denne kommuniserer med den andre bluetooth enheten som finnes er montert på PLS systemet, er der for å demonstrere at det er mulig å ha moduler tilkoblet systemet uten at de må være tilkoblet med kabel. Phoenix Contact kontroller Phoenix kaller denne enheten for inline-kontroller men den er også kjent som I/O enheter PLS systemet Brettet som PLS-en montert på er et resultat fra et tidligere bachelorprosjekt fra PLS-pakken er fra Phoenix Contact som er en tysk aktør i automasjonsmarkedet og leverer fullstendige automasjonsløsninger. Utenom selve PLS-en er det en industriell ethernet (switch), to bluetooth mottakere, en strømforsyning og to inline-kontroller. Figur 2.3: PLS og alle andre elementene montert på veggen. Phoenix Contact PLS: PLS-en er koblet til switchen med en RJ45 kabel. Phoenix Contact Switch:

28 2.2. Oppsett av vårt system 10 Her blir all kommunikasjonen i systemet tatt av switchen. Switchen er koblet til PLS-en, PC med OPC server, bluetooth enheten og til den ene inline- kontroller. Phoenix Contact Bluetooth: Bluetooth enheten koblet til switchen og er en del av systemet på brettet og den kan snakke med den andre bluetooth enheten som er montert på Modellbyen. Phoenix Contact 24V power supply: Her er det en strømforsyning på 24 volt som er koblet til alle enhetene på brettet. Phoenix Contact Inline controller: Denne enheten er koblet til Modellbyens kontroller ved hjelp av en kabel OPC Server OPC (Openness Productivity and Collaboration) er en plattformuavhengig standard for sikker og trygg samhandling og kommunikasjon med data innen automasjon. Den sørger for sømløs datadeling mellom mange forskjellige leverandører. The OPC Foundation har ansvaret for vedlikeholdet og utviklingen av denne teknologi. Se for mer informasjon. 2.2 Oppsett av vårt system Her beskriver vi hva programvaren vi skal bruke inneholder, hva vi kan gjøre med den, og hva som gjør den egnet. Videre vil vi forklare fremgangsmåten vi skal løse oppgaven vår på, og hvordan vi ser for oss at den skal bli når det er ferdig Litt om Wonderware programpakke Wonderware er en samling av programvare som er rettet mot industri og automasjon. Den er veldig anerkjent i industrien, men det er ikke så mye informasjon om den tilgjengelig. Det holdes stadig kurs for de som kunne tenke seg å lære seg disse programmene. Det er også mulig med teknisk support for de som trenger det. Wonderware sin samling dekker alt fra PLS programmering og styring, Oppsett av et overordnet system for kommunikasjon og samhandling, til HMI brukergrensesnitt og operatørovervåkning og interaktivitet. Wonderware er basert på en objektorientet tankegang. Det vil si at alt av prosesser og I/O er såkalte objekter. Dette vil i praksis si at all kommunikasjon med f eks en vanntank, som et objekt, går via metoder tilknyttet dette objektet. En måte å si det på er at et objekt er en prosess med sine metoder. Metoder er ting som skal gjøres med objektet eller hente ut data fra objektet. Wonderware har et overordnet system som holder kontroll på alle undermodulene som går under navnet ArchestrA som kan ses på (figur 2.4). Ved å opprette og starte en galaxy,

29 2.2. Oppsett av vårt system 11 Figur 2.4: Wonderware System Platform. (bilde fra Ivensys sine nettsider) kan man legge til forskjellige moduler på forskjellig PC-er, eller ha alt på samme maskin. Det kan for eksempel legges til Intouch komponenter her, legge til en ekstra plattform, og så legge komponenten inn under denne plattformen. Alt dette vises oversiktlig i systemet. Alt dette lærte vi når vi var på kurs hos leverandøren Invensys, i Sandvika. Noen deler av pakken: Archestra IDE Selve utviklingsmiljøet for prosessene og systemet InTouch HMI delen til systemet InControl PLS styringsdelen System Management Console Et grensesnitt mot Windows sin egen Management Console WindowMaker/Viewer Viser og programmerer HMI. Hører til under Intouch Historian Lagring av prosessdata for senere bruk Information Server Vising av data, eventuelt på nettbrett og mobil

30 2.2. Oppsett av vårt system 12 SQL server for lagring (Microsoft) Her ligger hele systemet lagret Oppsett av HMI Vi vil teste ut Intouch HMI ved å se hvordan de forskjellige funksjonene kan kommunisere med modellbyen på laben. Vi setter opp styring av trafikklys, vannpumpe og andre prosesser som vi får kontakt med. Ved å ta i bruk skript som er innebygd i programpakken vil vi prøver å få til et oppsett som muliggjør automatisk logikk styring fra HMI-et på klienten. Det som skiller disse skriptene fra PLS funksjonsblokker, er at det ligner mer på et slags programmeringsspråk, hvor vi kan bruke if tester, boolsk logikk og muligens timere. Noe av dette er selvfølgelig også mulig med funksjonsblokker. Det skal også lages funksjonalitet for manuell overstyring av den automatiske logikken, slik at vi kan f eks endre på lyskrysset manuelt, eller velge å f eks starte eller stoppe vannpumpa. Vi burde også sette opp litt feilkontroll, som å stoppe vannpumpa uansett hvis den skulle kommer over det høyeste nivået. Figur 2.5: Et eksempel på et HMI. (bilde fra Invensys sine nettsider) InTouch HMI kommer med veldig mye grafikk innebygd gjennom Archestra. Dette gjør at vi kan bruke eksisterende grafikk for lyskryss, brytere osv. Det er også mulig å lage egen grafikk. Det man da må gjøre er å koble skript og tagger til hver grafikkenhet. Dette lærte vi på et kurs omhandlet programvaren.(se kapittel 4.3 Kurs i Sandvika) Vi tenkte å lage en skisse av Modellbyen sett ovenfra, ved å tegne opp veier, gress og lignende. Vi vil så koble grafikk fra prosessene til de riktige stedene på denne skissen, slik at vi kan vise Modellbyen i aksjon bare ved å se på klienten, og vårt HMI. Av utstyr vi har til rådighet, er det en kraftig klient med mulighet for virtualisering. Vi

31 2.3. Andre tilsvarende oppgaver eller oppsett 13 skal i denne oppgaven bruke Vmware løsningen. Klienten har en i7 4 kjerners prosessor, og 16 GB RAM. Vi burde kunne kjøre 4 virtuelle på denne hvis vi trenger det. For å få til alt dette, vil vi ta i bruk den velkjente teknologien OPC. Dette gjør at det blir mye enklere for oss å styre Modellbyen, da OPC er en teknologi som gjør det enkelt å dele tagger med andre enheter, og støtter mange forskjellige programvarer. Vi har en OPC Server på maskinen som er koblet til PLS-en, og den har taggene vi skal bruke definert i serveren. Videre kobler vi oss da til denne. Utfordringer i dette prosjektet er å få til en logikk som gjør at vi kan overstyre et allerede kjørende PLS program uten at det blir uønskede feil som f eks at lysene ikke lyser riktig vei. Vi vil også se på om det i det hele tatt er mulig å overstyre et PLS program, eller om vi må kjøre manuelt fra HMI, med et skript hvis vi skal ha automatikk. Det neste blir å få til kommunikasjon mellom vårt HMI og Modellbyen, da vi har hørt det har vært problemer med dette før. Hensikten med dette systemet er å se hva vi kan gjøre med Intouch fra Wonderware. Vi skal finne ut så mye som mulig om programvaren, slik at vi kan levere vårt arbeid til arbeidsgiver, sammen med en innføring/brukerveiledning. Arbeidsgiver vil da få se på oppsettet vi har laget, og se om han eventuelt vil bruke dette som et ledd i skolens undervisning. Han kommer til å prøve ut HMI-et vi har laget, og se om han er fornøyd. Arbeidsgiver var veldig interessert i om dette kan styres fra nettbrett og mobile enheter, og hva styrkene til denne programpakken er. 2.3 Andre tilsvarende oppgaver eller oppsett Det finnes tidligere oppgaver relatert til modellbyen. I hovedrapporten for PLS systemet er det blitt brukt et HMI for å teste systemet[4], mens den andre tar for seg oppkobling av modellbyen og funksjonsblokkprogrammering direkte til PLS[3] En artikkel om HMI I en artikkel skrevet av Professor Akram Hossain, og Ms Tanima Zaman fant vi noen retningslinjer for hvordan man skulle sette opp et HMI på en god måte.[5] De forklarer at hoved formålet for et HMI er å være et godt verktøy for operatøren, slik at denne kan få en god oversikt over den prosess han skal styre eller overvåke. (Side 3 i artikkelen) De forklarer at det er en misforståelse at jo mer rådata man får presentert jo bedre er det. Videre ser man at mange design ingeniører ikke følger praktiske industrielle standarder når de designer et HMI. Mange designere har en tendens til å ha skarpe farger og komplisert grafikk. Som for eksempel 3D prosesser, animerte bilder, hjul som spinner, eller bevegelige deler. Dette gjør bare at kontrolløren blir distrahert fra det han egentlig skal følge med på. Det

32 2.3. Andre tilsvarende oppgaver eller oppsett 14 poengterer at det er viktig å følge den spesifiserte industrielle farge koden, slik at kontrollører ikke blir forvirret, da det er ønskelig med så få menneskelige feil i en prosess som mulig. To viktige faktorer som må fokuseres på er, at HMI-et må holde operatørens fokus med best mulig klarhet, og at designet må være så enkelt at en person med lite kunnskap om prosessen vil kunne kontrollere HMI-et. Det er flere viktige ting å tenke på når man designer et HMI, og Akram og Tanima pengterer dette. Layout Det å ha en riktig layout er veldig viktig, i hovedsak så begynner en operatør å se etter viktig informasjon oppe til venstre på en skjerm. Derfor bør den viktigste informasjonen være plassert der. For eksempel bør alarmer være plasert på toppen av siden. Grafikk bør plasseres på venstre siden, men hoveddata på høyre side. Det er anbefalt at start og stopp kontrollere er plassert nede til venstre og at navigering er plassert ned til høyre. Videre bør alle objekter være markert med sort outline. Farger Farger velges med omhu. Primærfarger som rød grønn og blå bør aldri brukes som bakgrunn på et HMI. Selv om sort og hvit gir gode kontraster bør disse også unngås. I artikkelen blir det anbefalt å bruke pastell skygge farger, sånne som lys grå og lyse brun. Disse gir et godt utgangspunkt. Det kan også være lurt å ha forskjellige nyanser på de forskjellige sidene, for å lett se forskjell på dem fra avstand. Vi har i motsettning til det anbefalte valg å bruke grønn bakgrunn, da vi syntes dette var fint. SCADA/HMI Design Standard er viktig å følge. Her er følgende fargekoder satt opp. Rød: stop, nødtilfelle Grønn: Start, trygt Gul: Advarsel Blue: Påkrevd operasjon I motsetning til det mange kan tro bør et HMI se kjedelig ut. Dette betyr at et godt HMI vil ikke inneholde bevegelige deler. Store fargede elementer som tar fokuset bort fra det som er viktig. Et HMI bør i hovedsak ha en grå bakgrunn. Ingen animasjoner, og ingen linjer som krysser. I hovedsak er det viktig å representere hele prosessen i HMI vinduet. Dette er noe vi har gjort på det første vinduet vi har laget, kalt Overview. Her kan man se begge lyskryssene, og status for pumpe, gatelys og smarthuset. Et godt HMI bør også markere hvilken vei prosessen kjører, med sorte indikatorer. Farger bør være så minimalt brukt som mulig.

33 2.3. Andre tilsvarende oppgaver eller oppsett 15 Teksten Anbefalt tekst på et HMI er Arial eller lignende font. Størelsen bør være stor nok til at operatøren kan lese dette fra avstand. Tekst for titler og beskrivelser bør være større en tekst som blir brukt til knapper og alarmer. For mange forskjellige størrelser på tekst bør man også unngå, og helst unngå bare store bokstaver i ord. Ønsker man å bruke store bokstaver bør det bare brukes i overskrifter, og ved eventuelle beskrivelser. Resten bær være i små bokstaver. For skjermer er det sans-serif fonter som er enklest å lese. Data Det bør settes opp grupper med data, slik at det ikke blir uoversiktlig. Data som blir plassert i nærheten av grafikk blir ofte vanskelig å se, og data som skal sammenlignes med annen data bør plasseres sammen, slik at operatøren lett kan følge med. Benevnelsen bør også med, og da spesielt hvis det er flere forskjellige typer data som vises. Det er også alltid ønskelig å få data presentert grafisk, da det er lettere for operatøren å respondere til. Alarmer En viktig del av et HMI er alarmene, og bør være gruppert som følger: 1. Informative. 2. Advarsel. 3. Sperringer. Det kan også være ønskelig å legge inn lydeffekter på alarmer for å gjøre operatøren mer oppmerksom. Navigering Det er viktig for en operatør at han har mulighet til å veksle mellom HMI-ets sider raskt og enkelt. Som skrevet over, bør disse plasseres nede til høyre. Vi valgte å plassere dem øverst til venstre da det var denne metoden som ble brukt på kurset vi var på. Videre bør det være frem og tilbake knapper tilgjengelige. Dette har vi sett bort i fra, da vi har så få knapper at vi så det som unødvendig. Det er viktig at alle knapper er merket på en god måte. At knappene er store nok til lett å kunne trykkes på hvis man skulle presantere HMI-et på en trykkfølsom skjerm. Alle knapper bør bli gruppert sammen i bunnen av skjermen, vi har valgt å ha knappene litt mer plassert der det ser pent ut i forhold til design. Når man aktiverer en kommando med et trykk bør det komme opp et pop up vindu hvor

34 2.3. Andre tilsvarende oppgaver eller oppsett 16 man bekrefter hendelsen, med OK, eller avbryt, for å unngå uhell ved at noen kommer borti skjermen. Side rekkefølge Sidene bør reflektere dybden på den informasjonen man får presentert. Det er da naturlig at oversiktsbilde kommer først, og man derfra går mer i dybden. Da vi har forskjellige deler på oversiktsbilde er det naturlig for oss å heller ha beskrivende informasjon på knapper, slik at operatør kan gå rett til den visningen som er ønsket, heller en å ha frem og tilbake knapper. Sikkerhet Det bør implementeres sikkert slik at ikke uvedkommende kan aksessere et HMI å sette igang prosesser. Derfor bør det settes passordbeskyttelse på HMI-et.

35 Kapittel 3 Utforming og Planlegging Vi vil i dette kapittelet skrive hvordan vi har tenkt til å sette opp vårt HMI. Vi skal også beskrive hvordan vi har tenkt til å programmere PLS-en, slik at vi kan få et bra utgangspunkt for å vise data på HMI, eventuelt overstyre. Vi skal finne ut av hvordan vi bruker HMI-et på nettbrett, slik at vi kan implementere det i gjennomføringen av prosjektet. Det er også ønskelig med logging av data fra oppdragsgivers side, og vi skal finne ut hvordan vi gjør dette, eventuelt planlegge hva vi skal logge. 3.1 Innhold HMI Måten vi tenkte å bygge HMI-et på, er å starte med å lage en ramme hvor alle vinduene blir vist i, og som har knapper på siden hvor man kan se I/O mer detaljert i et nytt vindu. Vi ser for oss å vise et oversiktsbilde med en gang man starter HMI-et, hvor dette viser modellbyen sett ovenfra, med sine veier, gress, og I/O. Dette skal da være hovedvinduet. Her skal det også være mulig å styre de forskjellige prosessene, hver fra sitt respektive vindu. Vi tenkte å ha et vindu som viser stort bilde av trafikklysene, et for vannpumpa, et for huset, og eventuelle andre I/O vi skal bruke. Vi skal også se på forskjellige måter å vise data på, og se på hvilke muligheter vi har med InTouch ved å prøve litt forskjellige funksjoner og grafikk. Det er også ønskelig å legge til grafer som viser aktiviteten til enkelte prosesser, og vi skal prøve å få til dette også. Alarmer skal vi også ha med, et sted som kan ses på skjerm uavhengig av hvilket vindu man har oppe. I første omgang tenkte vi å bruke trafikklys, vannpumpe, og smarthus. Dette har vi alt testet det meste av, og dette blir enklest å finne. Avhengig av hvor bra med tid vi har, kommer vi til å prøve å få til gatelysene, varmeelementet og føleren i smarthuset. Mer om dette under PLS oppsett. Vi skal finne ut hvordan vi kan gjøre styringen mellom PLS og HMI på en bra måte. I 17

36 3.1. Innhold HMI 18 Figur 3.1: Utkast til vår HMI løsning. industrien er det PLS-en som skal ha den harde logikken, det vil si at den skal ha grunnstyringen, og det skal ikke gå å overstyre denne logikken fra HMI. Dette har med sikkerhet å gjøre, ved at hvis HMI-et feiler, vil fortsatt PLS-en kjøre sin logikk, slik at det ikke blir noen problemer. Det vi da skal finne ut er om det går å overstyre PLS logikken med vårt HMI, eller om det må legges inn logikk for overstyring i selve PLS-en for at det skal fungere. Dette er også interessant for oppdragsgiver. Vi har også funnet en temperaturføler av typen PT100 under modellbyen. Denne kan brukes til å måle temperaturen i rommet der modellbyen står. Vi kommer kanskje til å implementere denne i systemet vårt. Vi ble anbefalt av kursleder at når det gjelder et bra HMI, er det viktig at brukeren får et så fargenøytralt bilde som mulig, der det kun er relevante I/O og alarmer som skal skille seg ut. Det er veldig vanskelig å skille elementer hvis man har for mange og eventuelle sterke farger og mye grafikk. Det enkle er ofte det beste gjelder her, og vi skal lage vårt HMI slik at det blir enkelt og oversiktlig, etter dette prinsippet. Det finnes mulighter for skript i InTouch. Dette kan f. eks. være ting som aktiveres eller endrer en variabelverdi ved trykk på en knapp, eller holder musen over et område. Vi har ikke tenkt ut noen mulige måter å implementere dette på, men kommer tilbake til det hvis vi tar det i bruk.

37 3.2. Oppsett PLS og PC 19 Vi er også i dialog med oppdragsgiver kontinuerlig for eventuelle ønsker for systemet, som vi da kan legge til etter hvert. 3.2 Oppsett PLS og PC Vi starter med å lage en kopi av laboppgaven vi hadde i industriell IT. Dette var en oppgave hvor vi fikk systemet ferdig konfigurert, slik at vi ikke må sette opp all konfigurasjon og moduler på nytt. Dette er veldig tungvint, og vi ble heller anbefalt å gjøre det som vi gjorde. Da trenger vi bare lage selve variablene, knytte de til I/O, og lage selve logikken ved hjelp av enten funksjonsblokker eller strukturert tekst. Vi skal også teste om vi kan overstyre logikken fra PLS programmet fra vårt HMI. Oppdragsgiver vil ha svar på dette, og det blir vår oppgave å teste ut det. Hvis det ikke lar seg gjøre, må vi legge til logikk i PLS for at vi skal kunne kjøre andre programmer enn det som er standard. Et eksempel på dette er hvis vi lager en boolsk (0 og 1) variabel som kjører ett program ved true, og et annet ved false. Figur 3.2: Et eksempel på funksjonsblokkdiagram. Det vi må jobbe med er å finne alle I/O vi skal bruke. Vi må så koble alle disse til egne variabler. Hvilke I/O vi tenkte å benytte oss av er beskrevet under kapittelet innhold HMI og litt lenger ned. Vi må finne ut hvilke I/O som går hvor ved å lese hovedrapporten til de som satte opp modellbyen, og lese av fysisk serienummere og navnene på de diverse modulene som har ledninger koblet til seg. Det finnes litt informasjon på undersiden av modulene, så vi må ta de ut for å sjekke de. Vi har erfart at det er litt feilkoblet her, så vi må teste at vi har riktige koblinger. Vi må ha en slags farestyring hardkodet i PLS. Med farestyring mener vi f eks at hvis vannet i vannpumpa holder på å gå over kanten, så skal pumpa automatisk stoppe uavhengig av hva vi gjør i HMI-et. En grunn til at dette må ligge i PLS er fordi et HMI lett kan feile eller miste kommunikasjonen med PLS, og da er det viktig at det er selve PLS som stopper ved truende situasjoner. Vi tenkte i første omgang å lage programmer for å skru trafikklys av eller på, sette alle røde eller grønne, eller kjøre en annen variant av standard styringsprogram. Angående vannpumpe, tenkte vi å sette opp slik at den får flere moduser. Dette gjør at vi kan ha et program som kjører den middels opp, mens et annet kjører den helt opp. For smarthuset, skru lys av og på, måle temperatur, og også kanskje stille inn varmeelementet som er der. Dette er stort sett det vi vil ha i første omgang. Da kan vi f eks trykke inn knapper i vårt

38 3.2. Oppsett PLS og PC 20 Figur 3.3: Et eksempel på Layout. HMI, som starter disse programmene. Denne logikken tenkte vi å legge inn på PLS Trafikklys: Trafikklys begge kryss. En logikk for vanlig lysregulering her. Overstyre denne reguleringen ved å sette alle til grønn eller rød. Slå trafikklys av eller på. Skru av logikk og styre alt manuelt. Gatelys: Skru det av og på fra HMI. Ha puls bredde modulering for å regulerer gatelys etter lys i rommet ellers regulere gatelys fra HMI. Smarthus: Skru lyset av og på fra HMI. Regulere varme, også kanskje bruke varmesensor for å nå ønsket setpunkt. Maks temperatur styrt fra PLS (failsafe). Måle varme og vise på HMI. Vannpumpe: Ha flere programmer for å styre vannpumpe. Skru den av og på. Automatisk stoppe vannpumpe ved nivå høy (øverste sensor). Vise nivå i HMI, bruke sensorene til å vise. Temperaturføler PT100 Måle temperatur i rommet.

39 3.3. Nettbrett og mobil Nettbrett og mobil Oppdragsgiver er veldig interessert i å få opp HMI-et på nettbrett og smartmobiler, da dette skal være mulig med InTouch. Vi skal derfor se på hvordan dette fungerer, og prøve en løsning for dette selv. Figur 3.4: En illustrering på HMI. Det skal være mulig å kjøre dette på alle enheter som støtter HTML 5, slik at det går å bruke både Android og ios. Dette i følge informasjon fra Invensys 1 og Wonderware 2 sine nettsider. Vi må sette oss inn i hva av programvare vi må ha for å få dette til, hvor Internet Information Services IIS vil være en sentral del. IIS er et verktøy for å publisere nettsider. Det vil muligens også bli brukt Wonderware sin Information Server. Dette er noe vi må finne ut av mens vi jobber med dette, hvordan vi setter det opp og hva som trengs. Vi vil også se om det bare lar seg gjøre å endre verdier på en annen enhet, eller om det bare er mulig å lese. RTOL 3 er sentralt her. 3.4 Kommunikasjon Hva vi må gjøre for å få kommunikasjonen mellom maskinene til å fungere. Det å opprette kommunikasjon mellom en HMI klient mot et PLS system er ikke alltid like enkelt. Etter litt undersøkelser på nett, tekniker fra kurs og samtaler med fagfolk fra skolen viser det seg at det har noe med sikkerhet å gjøre. Mer spesifikt DCOM 4 innstillinger, som styrer kommunikasjon fra én PC til en annen. Vi fant ut at Windows XP SP2 har litt strengere sikkerhet som vi må konfigurere. Det er også viktig at brukernavn og passord er aspx 3 Real Time Operational Intelligence. Et begrep for å ha tilgang til prosesser uansett hvor man befinner seg. 4 DCOM står for Distributed Component Object Model og er en proprietær Microsoft-teknologi for kommunikasjon mellom komponenter og programvare fordelt på datamaskiner i nettverk.

40 3.5. Andre funksjoner i Wonderware 22 likt for både PLS PC og HMI PC. Muligens ikke et krav, men kan løse problemet. Vi må også sette opp kommunikasjon i Wonderware sin egen System Management Console. Figur 3.5: Hele systemet snakker sammen på denne måten Vi valgte å bruke OPC teknologien i vår oppgave. Det er den vi er kjent med, og denne er også universiell for flere systemer og utstyr. Vi legger inn Phoenix sin egen OPC Server, kalt AutomationWorx OPC på PLS PC-en. Her kan vi også teste at taggene hvor vi har åpnet for OPC, vises i test klienten som følger med. Vi må videre finne ut i programpakken hvordan vi oppretter en kobling mot OPC serveren og bruker dette i InTouch. 3.5 Andre funksjoner i Wonderware Vi vil også etter at vi har gjort oss ferdig med systemet vi planla, prøve å utvide systemet ved å prøve litt mer avanserte funksjoner, og se på hva vi kan få ut av programmene i pakken. Vi vil også muligens skrive et kort resonnement om hva vi føler er styrker og svakheter i Wonderware sin programpakke i forhold til andre leverandører, f eks Rockwell. Oppdragsgiver er interessert i hva som er fordeler med å bruke et system fra denne leverandøren, så det er ønskelig at vi gjør en vurdering og demonstrerer hva man kan gjøre med det. Det finnes en programvare for lagring av data i pakken, kalt Historian. Vi tenkte at hvis vi får tid vil vi prøve å bruke denne til å lagre historiske data som f eks temperatur i rommet over tid. Dette kan være en nyttig funksjon. Av andre programvarer som vi skal se litt på, er det de som er relevante for å utvide HMI-et til andre enheter. Her er det ArchestrA Secure Gateway og Information Server som kommer inn i bildet. Secure Gateway gir et grensesnitt for sikker kommunikasjon over internett mot HMI-et, og Information Server er HTML systemet som gir tilgang til HMI-et fra andre enheter over denne gateway.

41 3.6. Brukerveiledning Brukerveiledning Vi skal i løpet av gjennomføringen lage en brukerveiledning som viser andre hvordan man kan sette opp et HMI med Wonderware. Vi lager denne fordi det er ønskelig for oppdragsgiver å bruke denne som et utgangspunkt for å lære systemet og til å bruke denne i faget sitt. Det kan være aktuelt for to fag, og vi lager da denne for at den skal kunne være et grunnlag for å lære andre studenter å bruke Wonderware InTouch. Vi lager denne brukerveiledningen for andre dataingeniørstudenter. Det er kun på ingeniørlinjen innen data at disse fagene undervises, Integrerte IT systemer og Industriell IT, da disse er tekniske spesialiseringsfag for dette studiet. Disse fagene undervises 3. året. Vi forventer derfor at de som skal bruke denne veiledningen har et godt grunnlag innen IT, og har god kunnskap og kompetanse på avansert bruk av datateknologi. Vi vil alikevel gjøre det detaljert og enkelt, slik at også andre som kanskje ikke er så flinke kan følge denne veiledningen og klare å lage noe enkelt utifra den. Lærerne vil nok også bearbeide den og teste den før de bruker den videre. Angående hva den skal ha av innhold, skal den minst ha en innføring som gjør at brukeren skal kunne lage et enkelt HMI, basert på InTouch og modellbyen med dens PLS og moduler. Den skal vise hvordan man kobler til PLS og hvordan man setter opp OPC og styringsprogrammer, avlesing av I/O og styring av I/O. Den skal vise hvordan man lager grafikk og andre ting som vi har jobbet med under prosjekttiden. Vi kommer til å gjøre det så avansert vi kan, og det er ikke sikkert det er nødvendig å gjøre alt som vi gjør i brukerveiledningen. Vi kommer alikevel til å ha med det meste som vi har gjort selv, så er det opp til oppdragsgiver å begrense den eller tilpasse den før bruk i undervisning. Vi tenkte å lage den så detaljert at det ikke skal være vanskelig å kunne gjenta alt vi har gjort. Selv om man ikke kan så mye, skal man følge den og sette opp fra bånn av. Vi tar derimot et forutsetning at bruker har kjennskap til generell bruk av datamaskin, og nødvendig forkunnskap i PLS programmering. For å bruke InTouch HMI, er det nødvendig å ha gjort klar PLS maskinen for kommunikasjon med en OPC server. Vi valgte å bruke OPC teknologi for denne oppgaven, men det er nok mulig med andre måter også. Vi må ha OPC for å kunne få tilgang til prosesser fra vår HMI PC. Det er nødvendig å programmere PLS ved hjelp av funksjonsblokker eller strukturert tekst, og sørge for at alle variabler som er knyttet til I/O har OPC støtte aktivert. Det er nødvendig å sørge for at PLS programmet har støtte for at HMI-et kan styre slik det er tenkt at det skal. PLS programmet må derfor bygges med tanke på at det skal gå an å overstyre prosesser, og kjøre egne programmer, eller bytte mellom forskjellig styring av Modellbyen.

42 3.7. Kurs hos Invensys Kurs hos Invensys Invensys Norge har hovedkontoret sitt i Sandvika. De har forskjellige kurs for kundene sine. Vi deltok i to av kursene som ble holdt av Invensys. Det første kurset (Wonderware Application Server 2012 R2) gikk ut på hvordan setter man opp en galaxy i ArchestrA 5. Det andre kurset (Intouch for System Platform 2012 R2) gikk ut på hvordan man setter opp selve HMI-et. Begge kursene varte i 3 dager hver. Hver dag startet vi fra kl. 9:00 til kl. 17:00. Det første kurset lærte vi om hvordan man kommer i gang med Wonderware. Vi hadde hver en egen PC med to virtuelle PC-er installert. Den ene kalt for server PC og det var ment for at alt av utviklingen skulle skje der. Den andre var klient PC som var ment for å være sluttbrukerens PC. På server PC-en opprettet vi en galaxy i programmet ArchestrA. Vi lærte grundig om hvordan man oppretter objekter og kobler dem sammen. Vi lærte også om hvordan man lagrer data i databasen og hvordan man bruker dataene for å få trender. Det andre kurset var oppbygd på det første kurset og det var det som var mest relevant for oss. Vi lærte hvordan vi satt opp Intouch Window Maker 6 for å opprette et HMI med forskjellige funksjoner. Vi brukte en del av dette som mal for hvordan vårt HMI skulle se ut, og har fått med en perm med funksjoner som kan brukes av oss. Alt vi lagde gjorde vi i server PC-en og vi kunne se resultatet på klient PC-en på InTouch Window Viewer 7. Vi fikk mye god kunnskap fra disse kursene, som hjalp oss veldig i vårt prosjekt. Ingen hadde kjennskap til programmet fra før, slik at det ble lettere for oss når vi skulle komme i gang. Kurset dekket et vidt spekter, og dokumentasjon fra kurset er også tilgjengelig for oss ved at vi fikk med oss en perm hver. Dette materialet vil også bli gjort tilgjengelig for skolen. På begge kursene fikk vi med oss en treningsmanual på det vi lærte på kursene. Disse manualene bruker vi som referanser. [2] og [1] 5 ArchestrA er et av programmene i Wonderware pakken som man bruker til å utvikle systemet med. 6 InTouch Window maker er det programmet som blir brukt til å sette opp et HMI. Det er bare tilgjengelig for utviklere. 7 InTouch WindowViewer er det programmet som er tilgjengelig for bruker på klient PC-en.

43 Kapittel 4 Gjennomføring og implementering 4.1 Forberedelser Vi starter med å ha et innledende møte med oppdragsgiver og veileder. De gir oss programvare samt informasjonen vi trengte for å komme igang. Vi tar kontakt med IT-drift 1 for å få tildelt en kraftig PC. Da har vi ekstra datakraft hvis det skulle trenges. Vi får utlevert en PC med i7 prosessor, den har 16 GB RAM, og en 500 GB harddisk. Det dukker opp problemer med kompatibiliteten til Windows server 2013, så etter noe diskusjoner velger vi Windows 7 etter anbefalt fra IT-drift. Videre velger vi VMware Player for bruk på maskinen. Da kan vi kjøre et utviklingsmiljø i den ene, og legge til flere ved behov. Figur 4.1: PC-en vi har installert Wonderware og VMware på. Windows 7 og VMware Player laster vi ned fra OnTheHub 2 sidene. 1 IT-drift har ansvaret for IT-tjenestene i høgskolen og har personale ved begge studiestedene som skal sørge for drift av IT-systemene, og hjelp og støtte ved bruk av disse relatert til undervisning, forskning og administrasjon. 2 OnTheHub er en tjeneste for IT-studenter der de har tilgant til gratis programvare fra forskjellige ITselskaper som for eksempel Microsoft eller VMware. 25

44 4.2. Klargjøring av en klient 26 Vi får vite at rommet med modellbyen hadde fått vannskader, den må flyttes til robotlaben i rommet ved siden av. Vi bruker et par dager på å flytte den. 4.2 Klargjøring av en klient Operativsystem og VMware Vi starter med å koble opp maskinen og installerer Windows 7 Professional på den. Hvis man skal bruke Windows Server, bør man ikke bruke nyere enn Windows Server 2008 R2 på grunn av komtabilitetsproblemer med Wonderware. Dette er fordi nyeste versjon av Wonderware fortsatt ikke støtter nyeste versjon av Windows Server, dette fikk vite fra Tom Qviller, tekniker for Wonderware. Når installasjonen av Windows 7 Pro 64-bit er ferdig, legger vi inn alle drivere som trengs. Dette gjør man enkelt ved å sjekke serienummer og modell og hente de fra hjemmesiden til fabrikanten. Kode til Windows 7 får man gratis som student ved Høgskolen, og man kan få koder og ISO filer til andre OS også fra OnTheHub. Vi fortsetter så med installasjon av VMware Player, som vi også henter fra OnTheHub for VMware. Versjonen vi bruker er gratis, men man kan få utvidede funksjoner eller bedre VMware programvare med lisenser gjennom Høgskolen. Figur 4.2: To virtuelle PC-er med samme spesifikasjoner. For at virtualisering skal virke, må vi aktivere VT-X i BIOS, under security settings. Vi velger så å lage 2 virtuelle maskiner på klienten vår. En til utvikling og en til testing. Vi setter de opp med 1 prosessor, 4 GB RAM, 100 GB HDD, Bridged Network (Hver maskin har egen IP) og resten med standard innstillinger. For å sette IP innstillinger riktig, må vi sette begge de virtuelle maskinene på samme nettverk som PLS maskinen.

45 4.2. Klargjøring av en klient 27 PLS PC IP Nettmaske Gateway DNS DNS Tabell 4.1: PLS PC Vi setter opp klienten på samme nettverk som PLS PC-en, men endrer IP-adressen og setter den lik: IT-drift anbefaler sammen bruker og passord på både klienten og PLS PC, på grunn av sikkerhetsmessige hensyn Installasjon Wonderware Vi får programvaren fra oppdragsgiver, og midlertidige lisensfiler fra Aksel Lindberg fra Invensys. Lisensene må vi stadig oppdatere da de kun gjelder for en gitt periode. Figur 4.3: Installasjon av Wonderware.

46 4.2. Klargjøring av en klient 28 Vi starter med installasjon av programvaren, og legger inn alle programmene som følger med i pakken. Wonderware InTouch (HMI programmet) Access Anywhere Secure Gateway (kommunikasjon over internett med HMI) Information Server (for deling av informasjon over internett,trenger IIS) Historian (Valgfritt, men kan brukes til å logge over tid.) Wonderware Application Server (Hovedprogrammet for systemet) Licensing (Lisensieringsprogrammet) Videre oppretter vi en bruker det med brukernavn og passord. Før vi kan bruke programmet, må vi legge inn lisenser som på bildet under. Figur 4.4: Hovedbilde av ArchestrA License Manager

47 4.3. Opprette kommunikasjon med OPC Server Opprette kommunikasjon med OPC Server Vi trenger en OPC server for å dele I/O med andre maskiner. Den vi nå har fungerer ikke, så vi må legge inn en ny. AutomationWorx OPC Server fra Phoenix Contact heter den nye, og den fikk vi fra faglærer. PLS klienten er satt opp på et VLAN som bare er tilgjengelig for dette PLS systemet. Den har to nettverkskort, et for VLAN med IP: XX, og ett lokalt PLS LAN med IP: XX. Alle tagger (I/O) som skal brukes i InTouch, må ha avkrysning for OPC i PCWorx. Dette gjør vi for alle variabler fremover, slik at OPC serveren kan sende de videre til klienten. Vi endrer i OPC server konfiguratoren slik at IP adressen der står på LIC 3.XX for PLS-en, og velge IP: som er adresse til PLS-en. Modellnummer til PLS-en står skrevet på framsiden av den. Firmware til PLS fant vi under properties på modulen i PCWorx. Det er viktig å bruke samme navn på PLS prosjekt og selve PLS. Navnet vi bruker er: ilc-350-pn b Dette setter vi opp under DNS name i Bus Configuration i PCWorx. Figur 4.5: Her vises hvordan legge til OPC objekter i SMC.

48 4.3. Opprette kommunikasjon med OPC Server 30 Vi tester så med OPC Test Client 3 og legger inn taggene vi skal bruke. Vi bruker så OPC Test Client for å se at variablene dukker opp, og har verdier. (bad vil si at den ikke får kontakt, 0 eller -1 er OK). Figur 4.6: Kommunikasjon OPC modellbyen mot HMI Vi bruker Matrikon Explorer 4 for å teste OPC serveren fra vår klient. Vi velger å koble til PROFINET 5 ved å skrive inn PROFINET in i Matrikon. Får da opp listen over OPC servere, og velger vår nyinstallerte OPC server. Så tester vi om vi kan manipulere taggene vi får tilgang til. Vi ser at vi kan manipulere og tester så ut diverse tagger. Dette er fint for å se om man får kontakt med PLS maskinen og I/O. Vi går så videre å bruker Wonderware sin System Management Console (SMC) til å legge til en kobling opp mot OPC serveren som vi nettopp installerte. Dette må vi gjøre slik at InTouch finner OPC serveren. Vi bruker ArchestrA FSGateway 6 og lager et nytt objekt kalt OPC Object. Dette linker vi da mot modellbyen ved å klikke på OPC objektet og skrive inn server node PROFINET. Der får vi se PhoenixContactAXServer i server name og velger dette. (Figur 4.6) 3 Et program som er på PLS maskinen for å teste OPC server 4 Et program for å teste OPC server. 5 En type kommunikasjons protokoll som brukes på PLS maskinen, som også er selve navnet på PLS pc 6 FSGateway er linken mellom OPC server og HMI

49 4.3. Opprette kommunikasjon med OPC Server 31 Figur 4.7: Dette vinduet kommer opp når man trykker på knappen Browse OPC Items Lager så en ny gruppe under dette, og legger til et nytt OPC Group Object. Her kan vi legge til de taggene vi vil ha, ved å klikke på knappen Browse OPC Items. Et nytt vindu popper opp. (Figur 4.7) Figur 4.8: Lister over navnene på Device Items Vi velger å bruke enkle beskrivende navn (Figur 4.8), da vi må bruke disse igjen når vi skal sette opp variabler i InTouch. Avsluttningsvis aktiverte vi FSGateway serveren fra SMC.

50 4.4. Innledende konfigurasjon Innledende konfigurasjon Oppsett av en ny InTouch Galaxy Vi starter opp ArchestrA IDE etter vi har satt opp OPC koblingen. Her velger vi å lage en ny InTouch Galaxy, da dette er enklest for å sette opp en ren InTouch applikasjon. Figur 4.9: Første vindu for å opprette en galaxy. Figur 4.10: Lage ny InTouch applikasjon.

51 4.4. Innledende konfigurasjon 33 Vi lager nå en InTouch applikasjon ved å legge ut en Derived Template av InTouchView- App, og lage vårt program utifra den. Sånn det fungerer i ArchestrA, er at den har Templates som er kun lesbare. Man må så lage en derivert template av denne som man må jobbe med videre. ArchestrA er et objektorientert system, og fungerer i praksis ved at man kan lage en overordnet mal for en objekttype, og sette egenskaper på denne. Da kan man så lage underobjekter av denne igjen, hvor alle arver fra overordnet objekt. Dette er en av styrkene til et objektorientert system. Dette fikk vi en innføring i når vi var på opplæring i systemet Testing av OPC mot InTouch Vi lager inne i InTouch applikasjonen et overordnet vindu som vi kan bygge videre på. Vi starter med å legge inn InTouch variabler for I/O som ligger i OPC serveren for å teste kommunikasjon. Det må først opprettes Access Name som linker til Wonderware System Management Console. Inne i SMC kobler vi til OPC gruppen vi satt opp tidligere. Videre må vi knytte en variabel opp mot OPC elementet. Vi går inn i tagname dictionary og lager variabler for 3 trafikklys som er i OPC. Vi setter et lokalt navn, velger så I/O Discrete, som er en variabel knyttet direkte mot en I/O prosess, og som er en 0 og 1 diskret variabel. Videre velger vi det Access Name som vi nettopp lagde, og limer inn OPC taggen nederst i vinduet. Så lagrer vi til slutt. Figur 4.11: OPC kobling 1, fått på mail fra Invensys tekniker Videre testet vi ut litt grafikk og knytter dette opp mot I/O. En funksjon i InTouch kalt ArchestrA Graphic har en liste over forskjellig grafikk variabler som I/O variabler kan

52 4.5. Oppsett PLS PC 34 Figur 4.12: OPC kobling 2, fått på mail fra Invensys tekniker knyttes mot. Vi kobler opp mot et trafikklys for å teste funksjonaliteten. Dette gjør vi for å sjekke at ting fungerer som det skal. Setter man opp alle variabler på forhånd og finner ut at noe er feil på slutten så må man gjøre alt om igjen. Vi setter så opp et grafikk element for selve lyset og to knapper som skruer lysene av og på. (Figur 4.13) Vi programmerer knappene med en toggle verdi som grønt og rødt lys skrus av og på med. Teksten over knappene har forskjellig tekst basert på om I/O er 0 eller 1, og det siste, selve lyset, viser hvilke av lysene som er aktiv. Vi kjører en test, men uten å få noe resultat. Lysene reagerer ikke. Vi starter feilsøking og kommer frem til at måten Windows XP SP2 er satt opp sperrer for kommunikasjon mellom klient og PLS maskin (PLS maskinen kjører XP SP2). Vi fikk en guide tilsendt fra Invensys, vedlagt, og kjørte en.exe fil kalt OSconfigurationutility som automatisk endrer i oppsettet. Når vi så prøver å koble oss til får vi kontrollert lysene, og ser at kommunikasjonen fungerer som den skal. Nå er det riktig kobling i Tagname Dictionary mot Access Name, Access Name mot OPC gruppe i Wonderware SMC, og SMC mot OPC Server AutomationWorx på PLS maskin. 4.5 Oppsett PLS PC Testing og kartlegging av I/O Vi starter med å teste alle I/O-ene og modulene på modellbyen. Siden modellbyen er mer enn fem år gammel er det også viktig å teste selve elementene. Derfor gjør vi dette på

53 4.5. Oppsett PLS PC 35 Figur 4.13: I/O test Figur 4.14: Grafikknapp

54 4.5. Oppsett PLS PC 36 Figur 4.15: Grafikkelementer Figur 4.16: Tag tilknytning mot grafikk

55 4.5. Oppsett PLS PC 37 en detaljert måte for å unngå feil når vi skal programmere PLS-en og for å få en bedre oversikt over modellbyen. Elementer som mangler eller ikke virker De fleste elementene virker, men når vi tester sensorene under veien er de borte, og gangfeltknappen ved trafikklys 7 samt grønt lys på trafikklys 7 som peker mot nord er også ute av funksjon. Detaljert oversikt over alle modulene ligger som vedlegg Konfigurasjon med funksjonsblokker Sette navn på I/O Først leser vi av navnet på hver modul. for eksempel en modul som har DO 4-ME under lysene øverst hører her til én med navnet IB IL 24 DO 4-ME. Under ser man at de er nummerert med 5, 9, 10, 11 og 12. Dette er rekkefølgen de er i på kretsbrettet på modellbyen nummerert fra venstre mot høyre. 1.1, 2.1 osv er hvilken kontakt de er i på gjeldende modul. Figur 4.17: En modul fra Phoenix. (bilde fra Betraktninger vi gjør under utvikling av PLS programmet Starte og stoppe alle program fra HMI: Alle programmene som lages skal startes og stoppes fra HMI. Alt skal gå gjennom ferdiglagde programmer. Det går an å lese av ett og ett trafikklys men ikke skrive til hvert enkelt, kun skrive til programmene. Sjekker at programmet fortsatt er aktivt ved hver endring av utganger:

56 4.5. Oppsett PLS PC 38 Alle lys stopper med en gang programmet avsluttes. På denne måten kan man stoppe programmet uansett hvor programmet befinner seg, og så starte et annet program øyeblikkelig. Tidligere måtte man vente på en syklus. Et minus er at tidstelleren fortsatt går, så hvis man starter programmet på nytt fort, vil den fortsette der den slapp i syklusen. Men når den første telleren er ferdig, vil den aktiverte syklusen resettes. Skru av andre program før det nye starter: Vi setter opp programmene slik at når man starter et nytt program, skal dette resette det aktive programmet som er tilknyttet samme prosessgruppe. Dette gjør vi for at ikke to programmer skal kjøre samtidig. Dette gjør vi ved å lage 2 tidstellere og en RS vippe for hvert program. Når programmet starter settes utgangen lik 1. Vi setter også opp en ekstra tidsteller som resetter RS vippen. Den tidstelleren tar imot inngang fra variabelgruppen som brukes til å resette programmet, sammen med negasjon av programvariabelen. Disse er da koblet sammen med OR, slik at hvis en av dem er aktive, vil dette gjøre at programmet resettes. Resetvariabelen kan da settes lik 1 fra andre program, slik at tidstelleren stopper. Duplikate I/O koblinger: Ved duplikate I/O-er oppstår problemer ved å programmere PLS-en. Hvis en I/O skal være logisk 0 et sted, vil dette overstyre logisk 1 et annet sted. Dette spesielt ved bruk av AND og NOT. Løsningen er å lage interne variabler, flere, som alle er koblet til en utgang ved hjelp av OR blokker. Hvis man igjen knytter dette mot de forskjellige programvariablene, blir det mulig å kjøre logikk for en utgang flere steder, uavhengig av hverandre. Figur 4.18: Variabler mot I/O koblinger del 1 Figur 4.19: Variabler mot I/O koblinger del 2

57 4.5. Oppsett PLS PC 39 Ingen program i konflikt med hverandre: Det skal ikke gå å kjøre flere programmer samtidig, da konflikter vil oppstå. Et eksempel på dette er hvis de gule lysene blinker samtidig som det blir både rødt og grønt i program 1. Det skal kun være mulig med ett av gangen. Løsning: Vi lager en løsning som skrur alle andre program av når et nytt program starter. Dette gjøres ved hjelp av en RS blokk og en reset funksjon. Dette er nærmere beskrevet tidligere. En sjekk for å se om andre programmer er aktive kan også legges inn i starten av hvert nytt program, som da gjør at et nytt ikke starter før det gamle er stoppet. Litt om hvorfor vi velger disse programmene: Vi vil lage programmene for trafikkryssene slik at det er mulig å veksle mellom forskjellige moduser, som kan gi et bra bilde på HMI. Ved å endre til for eksempel alle røde lys, er det enkelt å vise litt variasjon på HMI-et. Vi vil også ha flere programmer slik at det ikke blir så kjedelig. Da kan man også få opp litt styring i HMI, slik at det ser proffere ut. Angående vannpumpen, valger vi å bruke nivå set verdier, det vil si at vannstanden holder seg på et gitt nivå. Dette er for å forenkle programmeringen, mens det samtidig viser en del på HMI. Vannivået ses på HMI, og knappene setter da nivå. Vi tenker at dette holder for pumpa, fordi selv med dette enkle programmet viser det mye om hva HMI-et er godt for. Trafikkryss 1 Trafikkryss 1 er det som er nærmest vannpumpa. Vi skal kjøre flere 3 programmer på dette krysset. Det ene er en slags automatisk modus, som styrer lysene som det vil være gjort ellers i en trafikksituasjon. Det andre programmet setter lysene i en slags standby modus hvor de gule lysene blinker. Det siste programmet lar fotgjengere passere ved å gi de grønt. Kun et av programmene skal kjøre av gangen. Program 1: Er et vanlig trafikkreguleringsprogram. Dette gir fotgjengere rødt når det er grønt for bilene, og omvendt. Mellom rødt og grønt for biler lyser det gult en periode. Det er også lagt opp slik at når bilene får grønt, blir det grønt først for det ene krysset, så grønt for det andre. Dette for at ikke begge skal ha grønt samtidig. Etter det går begge bilkryss over til gult, og så rødt. Program 2: Dette er et program som bruker kun de gule lysene. Programmet vi lager her gjør at de gule lysene blinker av og på. Program 3: Vi lager også til et fotgjenger program. Programmet gjør at fotgjengere får grønt umiddelbart ved aktivering, og bilenes trafikklys blir da satt til rødt. Under er punktene som er viktige for dette krysset:

58 4.5. Oppsett PLS PC 40 Figur 4.20: Funksjonsblokker del 1 for trafikkryss 1. - Ikke restarte et allerede kjørende program. Det skal ikke være mulig å starte et program flere ganger etter hverandre før det er ferdig med sin syklus. Hvis man starter fort 2 ganger etter hverandre før en syklus har løpt, vil logikken gå dobbelt, og da kan man få både grønt og rødt lys samtidig, noe som ikke er ønskelig. Løsning: Setter opp en variabel på automatisk modus kalt running1. Så lenge denne er aktiv, vil det ikke gå å starte på nytt før den er resatt. variabelen resettes ved slutten av syklusen, som igjen tillater at det kjører en ny syklus. - Kjøre en loop En while løkke lages for at programmet skal starte på nytt etter hver ender syklus. Løsning: Vi setter opp en RS vippe, som lagrer en bit, som igjen kan resettes til 0. Variabelen running1 sette da til 0 hver gang syklusen slutter, hvor på slutten loop1 og reset1 blir satt til 1. reset1 setter da running1 lik 0, og loop1 starter da syklusen på nytt. En negasjon på running1 AND et med loop1 vil da starte programmet på nytt. Hvis vi får problemer med å restarte syklusen, kan vi løse problemet med RS vippen. - Logikk for automatisk modus. Reguleringen foregår ved hjelp av TP blokker, nemlig Puls Timere. Disse fungerer ved at når det kommer et signal, vil utgangen bli høy for et gitt tidsintervall. Tiden blir også sendt ut via en ET utgang. Denne utgangen går videre til en EQ blokk, Equal, som sjekker om verdien er lik sin egen, en TIME variabel. Når tiden har gått til et visst punkt gjennom EQ blokka, sender den igjen et signal videre som setter igang neste lys. Da får man først grønt, og etter litt, gult, og så til rødt, før den starter på nytt. Fotgjengerlysene skal kobles slik at når det er grønt for bilene, blir det rødt for

59 4.5. Oppsett PLS PC 41 Figur 4.21: Funksjonsblokker del 2 for trafikkryss 1. fotgjengere. - Logikk for gule blinkende lys. Denne bruker også timere, og kjører bare når program2, og ikke annet, kjøres. Den setter gult lys på, som sender et signal om at den skal være av like lenge, før den restarter. Denne bruker også en RS vippe, og en feilsjekk med running2 og reset2. - Logikk for fotgjengerpasseringsmodus Her er det ganske enkelt at fotgjengerlysene bli satt grønt ved å sjekke om program 3 er aktivert. I tillegg vil da lysene for biler bli røde. Trafikkryss 2 Trafikkryss 2 er det som er nærmest brannstasjonen. Vi skal kjøre 3 programmer også på dette krysset. Det ene er en slags automatisk modus, som styrer lysene som det ville vært gjort ellers i en trafikksituasjon, akkurat som på kryss 1. Det andre programmet setter alle lys røde. Det siste programmet lar fotgjengere passere ved å gi de grønt for disse og rødt for bilene. Her blir logikken stoppet etter en viss periode for fotgjengerprogrammet. Her er det også slik at vi kun tillater ett program av gangen Program 1: Automatisk regulering, akkurat som i trafikken ellers. Når kjørelys nord og sør er grønt, er kjørelys øst og vest rødt. Fotgjengerlysene lyser rødt nord og sør når kjørelys øst og vest er grønt og motsatt. Program 2: Her settes alle lysene til rødt. Program 3: Fotgjengerregulering. Skal gi fotgjenger grønt slik at de kan passere, mens alle kjøreretninger blir røde. Varer en viss periode, før den skrur seg av.

60 4.5. Oppsett PLS PC 42 Under er punktene som er viktige for dette krysset: - Ikke restarte et allerede kjørende program. - Kjøre en loop Punktene ovenfor er alt blitt forklart. De gjelder både for kryss 1 og 2. - Logikk for automatisk modus Vi bruker også her puls timere som i trafikkryss 1 program 1. Vi gjør det samme her som vi gjør i program 1 i det andre krysset. Eneste forskjellen blir at vi har andre lys koblet til utgangene i puls blokkene. - Logikk for alle lys røde Her er det enkelt å greit bare å sende signal høy til variabler som er knyttet opp mot de røde lysene. Det er viktig at vi ikke bruker I/O variabelen flere steder direkte. Dette på grunn av at hvis den er 0 et sted, går det ikke å sette den 1 et annet sted. Derfor bruker vi OR kretser som knytter flere variabler opp mot samme utgang. Da kan flere programmer bruke samme utgang uten konflikt. - Logikk for fotgjengerpassering Enkelt og greit. Fotgjenger får grønt mens biler får rødt. Vannpumpe Her lagert vi kun et program, men i dette programmet går det an å sette 3 setpunkter. Vannpumpen har 3 sensorer koblet til glassrøret. Et langt nede, ett i midten og ett på toppen. Vi har valgt å kjøre systemet slik at man velger hvilket nivå vannet skal ligge på i glasstuben, ved å bruke knappene i HMI. Da går pumpen til dette nivået, og holder seg der. Videre skal vi manuell starte på den, og en tidsteller som stopper pumpa automatisk etter en viss periode. Vi valger dette fordi det ikke er så vanskelig å lage dette i PLS, mens det samtidig får demonstrert en del i HMI delen, som er det viktigste. Tidstelleren er slik at pumpa ikke går evig hvis vi glemmer den. Logikk: Hver av sensorene er AND-et med nivåvalget sitt, og når de er høy begge to sender signalet videre til en stop variabel, som kobles til en annen variabel som deles av andre nivåers stop variabel. Hvis denne da blir høy stoppes pumpa, selv om knappen for start pumpe er aktiv. Dette ved hjelp av enda en AND. En sikkerhetssjekk skal også implementeres slik at når nivået går til høyeste nivå vil den stoppe uansett. Reset blokksystemet fra trafikkkryssene videreføres til dette programmet også, slik at andre setverdier blir resatt ved valg av nytt nivå. Mer om dette på bildene fra funksjonsblokkene. Smarthus Det første vi gjør her er å opprette en variabel knyttet mot det blå lyset i huset, og gjør den tilgjengelig fra OPC. Da kan vi skru lyset direkte av og på fra HMI.

61 4.5. Oppsett PLS PC 43 Gatelys Pulsbredde modulering - PWM modulen brukes til dette. Det er utgangen OUT32 på modul 13 som man kan sende en DWORD til for å styre lysene. Man kan lese gjeldende verdi på IN32 på samme modul. DWORD som skal sendes inn er en sekvens på 16 bit, hvor de tre MSB, mest signifikante bit, altså tre første bit, sier noe om hvilket program som skal kjøre på modulen. Puls bredde er De 5 neste bit sier noe om hvor lang periodetiden er på PWM modulen. For eksempel er hex tallet 59 pulsbredde program, 10 sekunders periode. De siste 8 bit sier hvor ofte signalet skal være på i løpet av perioden. FF hexverdi sier at den skal være alltid på, mens 00 er at den skal være av. 00 til slutt skrur av modulen. For å for eksempel sende puls bredde program, 10 sekunders periode og alltid på i den perioden, sender man 59FF til modulen, ved å skrive 16#59FF direkte i PLS programmet som en DWORD. Hvis man skal gå via OPC, må man gjøre om hexverdien til desimaltall, som da blir Et hextall er 4 bit, derfor vil 4 hextall fylle de 16 bit som kreves av PWM. For å bruke styrkenivå etter lysstyrke, bruker man en raskere periode, for eksempel 20 millisekunder, og sender en variabel syklustid etter hvor sterkt lyset er. Lysene står på uavhengig av PLS. Det vil si at hvis PLS blir stoppet, vil lysene fortsatt fungere. Dette kan være et problem med testing av gatelys, da man må vite hvordan man skrur de av. En måte er å sørge for at syklustiden er 0 ved å sette 8 siste bit til 0, eller, som vi skal få til, er å laste opp programmet til PLS på nytt, og da hardkode variabel mot gatelys med verdien 0. Se datablad for PWM modul på I vårt program skal vi lage en SELECT blokk. Denne skal ha 2 DWORD verdier, for alltid på, og for alltid av. Utgangen, gatelysene, settes da lik en av disse, avhenging av en boolsk verdi som også er inngang på blokka. Den boolske skrus da av og på fra HMI, som igjen setter lyset av og på. Diverse Det skal brukes egenlagde blokker i Pcworx. Dette gjør det enklere ved at man kan pakke inn programmer i egne blokker, og definere input og output variabler til disse. Det er bare å høyreklikke på POU i Funksjonsblokk vinduet, listen der main program, variabelliste og strukturert tekst programmet er. Man lager en ny custom blokk som da kommer ved siden av main. På en måte akkurat lik som main programmet. For å da bruke den blokka, legger man den inn i main ved å velge navnet på prosjektet på høyre side, der hvor de forskjellige blokkene er. Man legger det til som en vanlig blokk. Man må ikke ha input output koblet til den, men da må man ha globale variabler for den. Brytere for fotgjengere: I modellbyen er det bryter for fotgjengere ved siden av veien. Det er meningen at fotgjengere skal trykke på disse når de vil passere. Vi skal koble de mot OPC, slik at man kan få opp på en klient når disse er trykket ned. En tidsteller har også blitt implementert, slik at variabelen som sier at fotgjenger vil passere er på en viss tid. Da vil melding på HMI stå oppe lenger. Temperaturføler, PT100: Vi har også en temperatursensor, av typen PT100. Dette er en

62 4.6. Oppsett av HMI 44 digital måler, som gir ut en verdig basert på temperatur i rommet. Denne har vi tatt i bruk, hvor vi deler verdien på et gitt tall for å få ut i celsius. Dette sendes da så videre til HMI, hvor vi bruker denne temperaturen i en graf. Lyssensor, måler lysstyrke: En lyssensor som måler styrken på lys i rommet. Denne skal vi ta i bruk og gjør om til prosent, med cirka verdier. Så sender vi denne cirka verdien til HMI. Vi skal teste med mye og lite lys. Denne har vi også i en graf. 4.6 Oppsett av HMI Vi benytter WindowMaker for å lage et HMI. Før vi kan benytte det programmet må vi sette opp en Galaxy i ArchestrA IDE. Figur 4.22: Opprette en ny InTouch Applikasjon. Vi deler opp modellbyen i fem forskjellig deler og velger en hoveddel der informasjon om hele modellbyen ligger. Hovedvinduet kaller vi Overview, her får man en full oversikt over hele modellbyen. De andre vinduene kalles Traffic lights 1, Traffic lights 2, House, Water pump, og Streetlight. I feltet under hvert vindu la vi til et felt som inneholder trender for temperatur i rommet, lysstyrke i rommet samt en historisk trend for begge. Feltet til venstre for vinduet heter Navigation, det inneholder knappene til å navigere mellom vinduene, samt varsel for alarm. Vi legger til gatelys på Overview som vi har på modellbyen. Disse kan man se når de er på eller av. Man kan få status, varsel, av og på fra Streetlight vinduet. Vi legger en trending på Main vindu som er koblet mot lysføleren som vises lysstyrke i rommet. Trending er en type graf som viser liv data. Vi har en trending for temperatur måleren i rommet. Det ligger en vannpumpe på Overview som skal vises vanntilstand på den vannpumpen vi har på mobellbyen. Man skal få status om vannnivå, alarm, valg av programmer som skal kjøres. Det skal være en nød knapp som kan stoppe vannpumpen hvis vanntilstanden skal overstige maks volum.

63 4.6. Oppsett av HMI 45 Det er mange muligheter for egenlagd grafikk i Archestra System Platform I tillegg til selve grafikken kan mye av den egne grafikken knyttes mot forskjellige animasjoner. Man kan bygge et element av flere deler, og hver del kan få egen kode for animasjoner og variabler. Man kan så legge inn elementet i grafikken, hvor da det går an å koble enda mer inne i selve HMI, ved å velge Animation Links der også. Noen eksempler på egenlagd animasjon er ved at noe gjøres ved museklikk på objektet, eller objektet forstørres, gjøres synlig osv. Dette er en styrke i programmet Overview Dette vinduet er selve overblikksbildet, der man kan se alle prosessene på samme sted. Her har vi trafikklysene, vannpumpa, gatelys, og huset. Det er ikke mulig å styre noe herfra, da må man inn på hver del. Grunnen til dette er at det blir for mye å legge inn på et bilde, og vi mente at en operatør her kun skal ha et overblikk, derav navnet. Hvis han da ser noe og vil endre, går han inn på de detaljerte vinduene. Figur 4.23: HMI vindu: Overblikksbildet Traffic Lights 1 Her har vi første kryss som vi kaller for T-kryss. Det ligger tre ulike programmer som hentes fra PLS-programmet. Vi har valgt å legge inn tre knapper som kan velges av operatør. Den første knappen som kalles for program 1 fungerer som en vanlig regulerings

64 4.6. Oppsett av HMI 46 trafikk lys. Det legges ved tekst på siden av hver knapp på hvordan dem fungerer. Knapp 2 som starter program 2 skal lys være gult for alle retninger. Vi satt opp en fotgjenger knapp som vi kobler mot knapp 3 og da blir grønt for alle fotgjenger og rødt for biler. Når program 3 eller fotgjenger knapp trykkes så lyses det grønt for fotgjengere. Vi har også lagt ikon for fortgjengere som reguleres mellom rødt og grønt. På samme vindu har vi lagt inn noe som utvider informasjonen om hele vinduet Ved å klikke på den så kan man få en detaljert informasjon om hver knapp. Figur 4.24: HMI vindu: Trafikklys Traffic lights 2 Her har vi den andre krysset i modellbyen, et 4-veis kryss. Vi kjører også her 3 programmer, slik at operatør kan ha noe å velge mellom. Disse har da hver sin knapp, hvor knappene er plassert under hverandre. Litt tekst er også med til knappene. Selve bildet av krysset er da på høyre side, og viser hvilke lys som er aktive. De 3 programmene: Automatisk regulering - Fungerer som et vanlig lyskryss. Alle får rødt Stopper all trafikk. - Kan for eksempel være ved utrykning Fotgjenger grønt, biler rødt - For fotgjengerpassering, slår seg automatisk av etter 10 sekunder. Ellers er disse programmene nærmere beskrevet i PLS delen av rapporten.

65 4.6. Oppsett av HMI 47 Vi har også satt opp en teller, som teller antall ganger en fotgjenger trykker på bryteren på modellen. I tillegg utløser en av de bryterne i det krysset et skript, som er da den delen som oppdaterer telleren. Program for fotgjenger starter også automatisk ved hjelp av dette skriptet, når fotgjengere trykker på knappen. Grafikken som er laget for selve bildet av lyskrysset, er laget selv av gruppen. Vi har laget egne gatelysbilder for å få det mer oversiktlig. Vi så nemlig andre bruke det slik for enkelthetens skyld, og da gjorde vi det også. Selv bakgrunnsbildet er også laget av gruppen. Det er i tillegg en infoknapp som viser et hjelpevindu. Figur 4.25: HMI vindu: Trafikklys House Huset har vi ikke klart å få så mye ut av som vi trodde. Vi håpet på temperaturlesing og regulering, men klarte ikke å få til dette. Vi har klart å styre lyset der, så det har vi nå fått opp i HMI. Vinduet viser en skisse av et hus, med 4 blå lys i hvert hjørne. Vi har her en knapp som skrur lyset av og på, og dette vises da her i huset, og på oversiktsbildet ved hjelp av et ekstra lys der. Lyset er egenlagd, som vi har gjort slik at det skinne utover selve lykta. Da ser det mye bedre ut, og fyller mer av skjermen. Angående sensorer her, så var det noen som ikke virket. Noen er vi usikre på, men magneten på døra er ikke i drift.

66 4.6. Oppsett av HMI 48 Figur 4.26: HMI vindu: Huset Vi har også laget en spesiell knapp, som er noe vi la inn for moro skyld. Se under Dødningehode: Dette er et lite påskeegg som finnes i vinduet for huset. Når man trykker på en knapp som det står ikke trykk på, skjer det ting i vinduet. Dette går da ikke an å få vekk igjen med samme knapp. For at ikke folk skal bli redde, har vi et triks for å fjerne den. Området til høyre under husgrafikken, har et lite firkantet felt. Når du holder musen over dette området i over 2 sekunder forsvinner dødningehode Water pump På dette vinduet har vi ulike knapper som lar operatøren velge mellom ulike vannnivåer. Vi har tre sensor nivåer på selve pumpesylinderen.det laveste nivået er nivå en da skal den velges ved å trykkes på knapp low og velges start. Ved at vannstanden går fra null til nivå en. Vi har programmert slik at vi får en live data på hvor pumpesylinderen. Medium knappen skal øke vannstanden vannnivået til medium nivå så vi har på figuren under. Den siste knappen high som setter vannstanden til høyeste nivå. Vi har valgt å ha trend på vannpumpen, slik at bildet viser litt mer. Her har vi en variabel som leser av nivået i pumpesylinderen, og setter verdi utifra den. Denne verdien bruker vi da i en graf, som vi setter min og maksverdi en under og en over min og maksverdi på variabel. Da slipper vi at den skal gå helt opp eller helt ned, men holde seg i midten av graf. Fra den kan vi da se hvordan nivået har forandret seg.

67 4.6. Oppsett av HMI 49 Figur 4.27: Den skjulte knappen i HMI-et Figur 4.28: HMI vindu: Vannpumpe

68 4.6. Oppsett av HMI Street light Vi har klart å få gatelyset til å fungere, ved å skjønne hvordan Puls Bredde modulen virker. Derfor har vi tatt med et eget vindu om dette. Meningen var at vi skulle regulere lyset utifra en regulator på HMI, og i tillegg velg å autostyre lyset etter rommets egen lysstyrke, men kom ikke så langt. Nå har vi kun en Av/På regulering. Vi har i tillegg en graf, som viser 0 og 1 fra den boolske bryteren for lyset. Vi har ikke fått den helt til, da den restarter på nytt hele tiden. Designet av lysene laget vi selv, og satt en Visibility animasjon på den gule delen av grafikken, selve lyset. Denne knyttet vi da selvfølgelig opp mot bryteren. Figur 4.29: HMI vindu: Gatelys Trend Vi har laget Trender i HMI-et vårt. Trender er grafer som viser data over en gitt periode. Vi har øyeblikkstrender, som viser realtime data, og vi har også laget historiske trender, som bruker databasen vi opprettet. Vi har trender flere steder i programmet vårt. Noen vinduer vises alltid, som undervindu main og menyvinduet navigation. I main har vi 3 trender, hvorav de 2 første er øyeblikksdata for temperatur og lysstyrke, mens den helt til høyre er en historisk trend som viser samme data, bare over lengre tidsrom. Denne kobler da til database for å hente data. Ellers har vi en graf for vannpumpe, og en for gatelys.

69 4.6. Oppsett av HMI Skript Figur 4.30: HMI main med 3 trender Vi har laget noen skript i HMI-et vårt. Skript er et viktig verktøy i utformingen av et HMI, og kan noen ganger virke som en egen logikk som kan styre IO uavhengig av PLS programmeringen. Det ene skriptet styrer nivået på pumpa. Dette skriptet brukes til å lese av nivå på pumpe, og setter en variabel utifra dette. Brukes til å oppdatere pumpesylinderen, og kjøres hvert sekund. Figur 4.31: Skript-kode for vannpumpe Det andre teller antall fotgjengerpasseringer, og starter programmet for fotgjengere.

70 4.7. Overgang til Server 2008 R2 52 Figur 4.32: Skript-kode for fotgjengerknappen i trafikklys 1 Vi har også et par andre, som at dødninghode resettes og at man åpner nye vinduer ved venstre museklikk. Kode for å vise vindu: Show vindunavn ; Kode for å fjerne dødninghode: boolean death = 0, hvert 2. sekund ved mus over Design Som vi har tidligere nevnt så har vi lagd våre egne knapper, trafikklys, gatelys og plantegning på huset.alt har blitt lagd i ArchestrA. untatt plantegning av huset som vi benytter en annen verktøy som kalles Lucidchart. Vi har lest om hvordan en hmi design skal se ut som vi forklarer bedre på analyse delen. Det har vi også lært på kurs at et hmi skal ses enkelt uten veldig mye farge. Vi designet de ulike delene fordi vi ville teste mulighetene Wonderware kunne tilby. Vi hadde lyst å lage noe som var personlig. 4.7 Overgang til Server 2008 R2 Når vi hadde laget systemet vårt i Windows 7, fant vi ut at dette OS ikke støttet alle funksjoner vi ville bruke. Hvis vi skulle få til nettbrett løsning, måtte vi legge inn Server

71 4.7. Overgang til Server 2008 R2 53 OS. Vi lastet ned bildefil fra OnTheHub for Server 2008 R2. Vi lager en ny virtuell maskin. Denne setter vi opp med 2 CPU, 4 GB RAM, 100 GB HDD, og Bridged Network. Vi laster inn bildefilen på denne og valger en hurtiginstallasjon. Setter opp brukere, én skal kalles opc, og setter passord på Administrator kontoen. Setter navn på maskinen til SERVER-HMI. Vi setter også egne IP innstillinger på denne til det som er gjort på de andre, som DNS og gateway, men setter unik adresse for maskinens egen IP. Denne blir Figur 4.33: IP instillinger for Windows server 2008 Vi må installere SQL Server for å få mest mulig ut av Historian, som følger med Wonderware. Historian er et program som bruker SQL til å lagre data over tid, og kan ha oversikt over for eksempel temperatur til alle døgnets tider i rommet.

72 4.7. Overgang til Server 2008 R2 54 Vi laster ned SQL Server 2008 R2 med SP1, fra samme sted som før, OnTheHub Dreamspark. Når vi installerer velger vi dette: Kjører en New Installation Velger All features with defaults Instance ID: MSSQLSERVER På SQL Server Agent og Server Analysis, brukes: Administrator Når vi blir bedt om hvilken autentiseringsmodus, velger vi Mixed Setter SQL bruker til : sa På alle spørsmålene om brukertilgang, legger vi til alle administratorkontoene som ble opprettet i Windows, og sa brukeren. Dette er en innebygd konto i OS-et (Windows Authentication) Setter resten av oppsett til standard. Figur 4.34: Opprettelse av brukernavn og passord Nå legger vi inn Wonderware pakken også her, på denne maskinen. Vi setter først opp rollene som behøves av Information Server og Access Anywhere Server, nemlig IIS og Remote Desktop Services. Vi bruker guiden som ligger vedlagt for å få informasjon om hvordan det skal settes opp. Viktig å også velge ASP.NET under IIS Første som installeres fra Wonderware, er Access Anywhere Secure Gateway, som sørger

73 4.7. Overgang til Server 2008 R2 55 Figur 4.35: Valg av funksjoner for server for sikker kommunikasjon fra andre enheter. Denne legger vi inn alene, så starter vi installasjonsprogrammet på nytt. Når vi har startet installasjonen på nytt, legger vi inn alle programvarer i pakken. Legger inn alle Prerequisite files. Hvis alle nødvendige komponenter er lagt inn, som SQL Server og IIS, skal installasjonen gå bra. Vi fikk ikke advarsler siste gang vi installerte, som er et tegn på at alt er riktig konfigurert. Lager en bruker med navnet admin når vi blir bedt om det Wonderware er nå installert på Server 2008 R2. Vi må også her legge inn lisensene vi får for å bruke programmene. Vi må opprette OPC kobling i System Management Console når Wonderware settes opp. Vi bruker samme oppsett som ble gjort tidligere i prosjektet, på Windows 7 maskinen. Det viktige er at Access Name objektet, inne i WindowMaker får samme navn som det har i HMI fra annen maskin. Dette for at tagene skal bli konfigurert mot riktig OPC kobling når vi importerer de senere. Aktiverer så FSGateway, og velger auto-start Det vi gjør nå, etter at Wonderware er klart, er å importere vårt allerede ferdigutviklede HMI. Da vi alt har laget dette på Windows 7 maskinen, er det bare å eksportere det derfra og importere det til Server 2008 maskinen. Vi eksporterer HMI fra Windows 7 PC ved å først kjøre en Check In. Deployer så HMI ved å følge stegene beskrevet under brukerveiledning og det står også kort om det under

74 4.7. Overgang til Server 2008 R2 56 Figur 4.36: Installasjon av Wonderware kapittelet om Nettbrett. Høyreklikker vi så på HMI og velger Export - Object(s) Åpnet Archestra IDE på den nye maskinen vår og velger Import - Object(s). Finner fram til.aapkg filen vi lagde Importerer.aaPKG fra prosjektet. Beholder standard import innstillinger. Endrer i Access Name i WindowMaker slik at modellby fra importert objekt samsvarer med modellby som vi opprettet i SMC, under FSGateway. Lager så ny Instans av modellbyhmi. Lager deretter ny derived Template av WinPlatform og ViewEngine. Når det er gjort, lages så ny instans av den deriverte WinPlatform og den deriverte ViewEngine. Gi de passende navn. Legg så ViewEngine instans under WinPlatform instans, og til slutt modellbyhmi instans under ViewEngine instans igjen. Deploy WinPlatform. Standard Deploy innstillinger. Nå har vi satt opp hele systemet på nytt, men med Windows Server 2008 som OS. Vi bruker så denne videre når vi jobber med systemet. Nettbrett løsning og Historian databaseprogram blir også konfigurert her, men det er nærmere beskrevet under egne kapitler.

75 4.8. Nettbrett løsning Nettbrett løsning Vi vil gjerne prøve å få til dette, da oppdragsgiver er veldig interessert i denne egenskapen. Vi fant ut ved å gjøre litt undersøkelser, at denne løsningen bruker noe som heter Remote Desktop Services og at det kreves en Server versjon av Windows. Remote Desktop Services er en tjeneste som lar en bruker logge seg på en maskin fra en annen maskin, akkurat som TeamViewer. Dette blir mye brukt for å administrere servere i arbeidslivet. En av oss har selv jobbet med dette, og brukt dette mye til fjernadministrering. For å få opp dette, begynner vi med å lage en maskin som støtter dette, ved å legge inn Windows Server 2008 R2. Da får vi full funksjonalitet fra programvaren. Vi må legge inn rollen Remote Desktop Services fra menyen Roles and Features i Server Manager. Denne gjør det mulig å aksessere Intouch WindowViewer fra en annen enhet. Vi følger guiden InstallingRemoteDesktopServices.... [6] som ligger vedlagt rapporten. Figur 4.37: Installasjon av Remote Desktop Services Når vi setter opp rollen, installerer vi Intouch Access Anywhere Server fra installasjonsmenyen for Wonderware. Kan være at Intouch Access Anywhere Secure Gateway må installeres først. Secure Gateway må installeres alene, det vil si kun den og ikke annet samtidig. Da kjører man heller de andre programmene ved å starte installasjon på nytt. Så setter det opp, følger vi manualen som ligger i menyen til Wonderware. Denne heter Intouch Access Anywhere Manual. Denne manualen følger med Wonderware, og finnes i

76 4.8. Nettbrett løsning 58 startmenyen til Intouch. Her følger vi det som står skrevet på side 10, Getting started in 5 minutes. Vi følger de siste stegene i guiden som sier noe om rollen Remote Desktop Services. Tester med IP:Port til klient, :8080 i vårt tilfelle, med bruker som vi alt har lagd. Figur 4.38: Inn logging på InTouch Access Anywhare oå nettbrett Vi tester så med et HMI vi har laget. Dette må være Deployed for at det automatisk skal komme opp i Intouch. Deploye et HMI: Lager så ny Instans av modellbyhmi. Lager deretter ny derived Template av WinPlatform og ViewEngine. Når det er gjort, lages så ny instans av den deriverte WinPlatform og den deriverte ViewEngine. Gi de passende navn. Legg så ViewEngine instans under WinPlatform instans, og til slutt modellbyhmi instans under ViewEngine instans igjen. Deploy WinPlatform. Standard Deploy innstillinger. Vi testet løsningen og er imponert. Vi logger inn og velger hvilket HMI vi vil se på. Dette kommer opp i nettleseren, og vi kan styre akkurat som om det skal være en vanlig PC. Vi er glad det fungerer, og dette er også noe som er veldig interessant for oppdragsgiver.

77 4.8. Nettbrett løsning 59 Figur 4.39: HMI på nettbrett via InTouch Access Anyware

78 4.9. Database Database Wonderware har med programvare for å logge historiske data. Oppdragsgiver er veldig interessert i dette og vil gjerne at vi skal prøve å få det opp å gå. Vi klarer det, og har prøvd en del testdata. Historian er det programmet som logger til MS SQL aktiviteten vi har tilgang til via I/O. For å sette opp Historian måtte vi installere Microsoft SQL Server 2008 R2. Når SQL Server er installert og er satt opp, er det få konfigurasjoner som skal til før Historian kan begynne å logge data. Før vi kan bruke Historian må vi først konfigurere Historian server. Det innebærer at vi lager Historian oppå SQL Server med kobling mellom de, og med ferdige tabeller og kolonner i databasen. Neste steg blir da å legge til PLS-tagene. System Management Console er det programmet som brukes til å sette opp hvordan man henter tagene fra PLS-en. Når Historian Server kjører og tagene er lagt til kan vi logge data. Wonderware har to tilleggsprogrammer for å se og presentere data. Det ene er Query og det andre er Trend. Begge kan brukes for å se data på hver tag. Det som blir forskjell på dem er at på Query kan lage og endre tabeller og kolonner, mens Trend viser grafer på de ønskede tagene som vi kan legge til. Figur 4.40: Programmet Query. Brukes til å lese tabeller med data. Dette programmet viser alle oppføringer for I/O som er lagt til i systemet. Her kan man hente opp historiske data fra forskjellige variabler ved å søke og filtrere. Man kan få opp

79 4.10. Problemer underveis 61 mange detaljer om hver variabel, men det viktigste her er selve navnet, verdien, og datoen. Man ser også her hvor ofte data lagres i databasen. Figur 4.41: Programmet Trend. Brukes til å representere data fra PLS-tagene. Dette er et bra program hvis man vil se data over tide mer grafisk. Dette gjør enkelte elementer mye enklere å studere og lese av, og vi bruker noe av dette i vårt HMI. Man kan sette opp flere variabler i samme trend, slik at man sparer plass. Her kan man se langt tilbake, ved å velge forskjellige tidsrom. Man kan velge siste dagen, timen, eller til og med uka. Så får man opp alle verdiene for den tiden. Veldig bra program Problemer underveis Måtte bruke en.exe fil kalt OSConfigurationUtility.exe for å klargjøre PLS maskinen Sjekket og endret DCOM innstillinger. En av tingene vi gjorde for å få det til å fungere, men vet ikke om det hadde noe å si. Etter.exe filen fungerte det. Denne fant vi etter et søk på google. Vi jobbet mye med å finne ut hvordan OPC kobles opp på InTouch og ArchestrA. Det viste seg at det var en egen SMC, System Management Console som sto for kommunikasjonen, og variabler måtte lages lokalt i InTouch og knyttes opp mot dette. Hvis det ikke fungerer, får man ikke feilmelding, så dette er en svakhet i systemet Det ble litt problemer med å få et program opp å gå på PLS. Det viste seg at det hadde blitt noe merkelig med DNS navn på prosjekt mot PLS, slik at navnene på selve PLS og