Datorbaserat stöd för driftövervakning

Examensarbete 20 poäng D-nivå Datorbaserat stöd för driftövervakning Reg.kod: Oru-Te-AUT067-Mag106/04 Per Jonhed Automatiseringsmagisterprogrammet 160 p Örebro vårterminen 2004 Examinator: Dag Stranneby COMPUTER BASED SUPPORT OF PROCESS MONITORING

Sammanfattning Detta examensarbete handlar om att ta fram ett verktyg åt AssiDomän Frövi för datorstödd processövervakning av en kartongmaskin. Verktyget skall använda sig av dynamiska larmgränser, dvs gränser som ändras för att passa den kartongkvalité som tillverkas. Om någon gräns överskrids skall detta indikeras på en processbild till operatörerna där även hänvisning till en sida för att åtgärda problemet visas. Verktyget har utvecklats i informationssystemet PIs miljö som är AssiDomän Frövis toppnivåsystem. En struktur med samtliga parametrar byggs upp i en databas som sedan Visual Basic-program använder sig av för att uppdatera gränser, övervaka processen och ge eventuella larm. Ett program för att generera en processbild över databasen har konstruerats och där indikeras eventuella larm med hjälp av färger och text. Inom ramen för detta examensarbete har endast en del av processen, nämligen bottenskiktets linje från doseringskar till inloppslåda, beaktats. Verktyget är dock generellt designat, så att det kan användas tillsammans med AssiDomäns samtliga system. Abstract This thesis is about developing a tool for computer based process monitoring of a carton machine by request by AssiDomän Frövi. The tool will use dynamic alarm limits, i.e., limits which are changed according to the carton quality produced. If a limit is crossed an indication at an operator s process picture shall be presented together with information on how to solve the problem. The tool has been developed in the information system PI s environment, which is AssiDomän Frövi s top level information system. A structure with all parameters has been built in a data accessed base and is used by Visual Basic programs to update limits, monitor the process and present any alarm that may occur. A program to generate a process picture of the data base has been made where alarms are presented by text and colours. In this thesis only a part of the whole process, from the dosage tank to the headbox at the bottom layer, been considered. But the tool is general and designed to be able to work with any of the systems at AssiDomän Frövi.. Sid 2 (40)

Innehållsförteckning SAMMANFATTNING... 2 ABSTRACT... 2 FÖRORD... 4 OM EXAMENSARBETET... 4 OM RAPPORTEN... 4 TACK TILL... 4 ASSIDOMÄN FRÖVI HISTORIK OCH NUTID... 5 INLEDNING... 6 BAKGRUND TILL ARBETET... 6 ARBETETS SPECIFIKATION... 6 METOD OCH VERKTYG... 8 TEORI OCH LITTERATURSTUDIE... 8 Larmhantering... 8 Att presentera information... 9 VERKTYG...13 PI-systemet...13 Microsoft Visual Basic 6.0...16 Referensgruppen...16 ANALYS OCH RESULTAT...17 NULÄGESANALYS...17 SYSTEMIDÉER...18 Koncept 1 Positioner i PI Module Data Base...18 Koncept 2 PI Process Templates 1.2...19 Koncept 3 GoalArt Diagnostic Station...20 Koncept 4 Vidarutveckling av Koncept 1....20 Val av koncept...21 BESKRIVNING AV DET IMPLEMENTERADE SYSTEMET...21 LimitUpdater...22 LimitCheck....24 AlarmGenerator...25 Drift_Status...26 PictureGenerator...27 DISKUSSION OCH SLUTSATS...29 ARBETETS GENOMFÖRANDE OCH UTFALL...29 FÖRDELAR/NACKDELAR MED IMPLEMENTERAT KONCEPT...29 PROBLEM UNDER ARBETETS GÅNG...30 FÖRBÄTTRINGSFÖRSLAG/VIDAREUTVECKLING...31 Checklista...31 Färg i ListBox...31 REFERENSER...32 BILAGOR...33 BILAGA 1 SPECIFIKATION AV EXAMENSARBETE...33 BILAGA 2 PLANERING...36 BILAGA 3 EXEMPEL PÅ KÖRREKOMMENDATION...39 Sid 3 (40)

Förord Om examensarbetet Detta examensarbete är genomfört inom ramen för Magisterprogrammet i Automatiseringsteknik vid Örebro universitet. Dess syfte är att studenten skall tillämpa sina kunskaper på ett praktiskt sätt med eget ansvar för utformning, genomförande och dokumentering av arbetet. Examensarbetet har gjorts på uppdrag åt AssiDomän Frövi där jag även varit stationerad. Detta har gett en närhet till processen och frågeställningarna och gjort det enklare att förstå hur allting hänger ihop. Det gav även närhet till handledares hjälpande hand i mödosamma stunder. Om rapporten Denna rapport är skriven i Microsoft Word. Författaren förutsätter att läsaren besitter grundläggande tekniskt kunnande samt särskild kunskap inom programmering. Där källor ej är angivna anser författaren att kunskapen är allmänt vedertagen inom den tänkta målgruppen för rapporten. Tack till Det är många personer som jag har att tacka för att arbetet har fungerat. De jag nämner nedan är de som jag absolut inte hade klarat mig utan. Först och främst tack till AssiDomän Frövi för att jag fick arbeta hos er, och då särskilt till mina två handledare, Per Rudfjäll och Jan Sjögren, som stöttat, inspirerat och hjälpt mig. Ett stort tack vill jag även rikta till de medarbetare som ingick i min referensgrupp och som utanför ordinarie arbetstid kom på möten och gav synpunkter, tips och inspiration. Tack till min handledare vid universitetet, Lennart Schön, för tips, vägledning och lagom uppmanande om att rapporten nog borde börja skrivas snart. En tacksamhetens tanke vill jag även skänka de lärare jag haft under min studietid vid universitetet. Vidare vill jag säga tack till mina samåkningskompanjoner för enkla och roliga transporter, till Örebrospexet och KFUM Örebro Orientering som förgyller min fritid samt till min vackra Jessica som trots allt står ut med mig. Denna rapport tillägnas min handledare Per Rudfjäll som mycket hastigt och oväntat avled i arbetets slutskede. Vila i frid fantastiska människa. Per Jonhed Sid 4 (40)

AssiDomän Frövi historik och nutid AssiDomän Frövi ingår i AssiDomän Cartonboard AB, ett företag i Sveaskogskoncernen. Bruket är beläget ca 3 mil nordöst om Örebro, ca 2 kilometer utanför Frövi. Platsen har anor ända från 1500-talet då Gustav Wasa lät anlägga stångjärnshammaren Fröuij Hamar. Under 17- och 1800-talet blomstrade järnhanteringen i Bergslagen, men sedermera byttes järntillverkningen i Frövi ut mot mer lönsam skogshantering. Sångjärnshammaren lades ner år 1891 och året efter togs ett träsliperi och ett pappersbruk i drift. Dessa kompletterades med en sulfatfabrik och ett kraftpappersbruk år 1901. Kraftpappersbruket lades ner 1981 och ersattes då av ett helt nytt kartongbruk som idag är världsledande inom vätske- och förpackningskartong. Den nuvarande kartongmaskinen byggdes för en kapacitet på 160 00 ton per år, men har genom investeringar och kontinuerlig optimering utvecklats till att nu tillverka ca 370 000 ton prima kartong per år. AssiDomän Frövi är ett så kallat integrerat bruk. Detta innebär att massa- och kartongtillverkningen sker på samma plats. Bruket har ca 670 anställda, omsätter drygt 2 miljarder SEK per år, exporterar ca 90 % av sin produktion och har egna försäljningskontor i ett flertal europeiska länder. Figur 1. Visar den ca 300 meter långa Kartongmaskin 5 (KM5) från 1981. Sid 5 (40)

Inledning Bakgrund till arbetet Tillverkningen vid Frövi Kartongbruk sker i en kontinuerlig process på en enda kartongmaskin. Detta innebär att ett produktionsavbrott ger stora ekonomiska förluster i sig självt, och det kan även ge upphov till allvarliga följdkostnader, bland annat leveransförseningar. Tillverkningsprocessen övervakas och kontrolleras av ett antal skiftgående operatörer. Antalet signaler i systemet som övervakas och skall kontrolleras är mycket stort, varför operatörerna har flera olika automatiska styr- och mätsystem till sin hjälp. Dock finns det så många signaler att det ändå inte är ovanligt att en signal kan avvika från optimalt läge en relativt lång tid utan att detta uppmärksammas. I de flesta fall störs ej processen nämnvärt av detta men i värsta fall innebär det att den producerade kartongen måste kasseras eller att hela maskinen måste stoppas. Vid Frövi tillverkas ca 30 olika kvalitéer av kartong, alla med sina speciella egenskaper och egna recept att följa. För dessa kvalitéer är många parametrar lika, och de har då fasta larmgränser, men för att erhålla de speciella egenskaperna som varje kvalité skall ha är det också många som ändras. Det kan vara ytvikten, kemikalieblandningen, ph-nivån mm. Varje kvalité har en körrekommendation där varje parameter som ändras har ett riktvärde som är anpassat till just den kvalitén. Dessa riktvärden kommer automatiskt upp i systemet, men det saknas larm som talar om ifall är-värdet är lika med riktvärdet eller ej. Med dessa problem som bakgrund uppstod ett behov av ett system som hjälper operatörerna att snabbt och enkelt få en överblick av de signaler som varierar från kvalité till kvalité. Arbetets specifikation Det som AssiDomän Frövi anser behövs är ett verktyg som på ett enkelt sätt visar statusen på de parametrar som är kopplade till varje kvalités körrekommendation; om parametrarna är inom rimliga gränser från riktvärde eller om de borde åtgärdas. Systemet skall inte vara tvingande, utan skall endast upplysande operatören om signalers tillstånd så att denne så snabbt som möjligt kan justera felet. Systemet skall kontinuerligt jämföra nuvarande processvärde mot gränsvärdet och indikera om gränserna överträds. Dessa gränsvärden skall automatiskt uppdateras vid produktionsomställning så att varje produkt jämförs mot rätt värde. Då driftlinjen består av ett antal processelement som olika operatörer ansvarar för skall dessa element organiseras så att larm kan propageras uppåt i hierarkin och endast ge indikering till berörd operatör. Systemet skall kunna kommunicera med andra informationssystem som används vid bruket samt använda sig av databasen för körrekommendationer för att inhämta aktuella gränsvärden. Systemet skall vara användarvänligt och lättförståeligt. För att systemframtagningen skall rymmas inom ett examensjobb begränsas det till att omfatta en viss del av bottenskiktslinjen, från doskaret till inloppslådan. Dock skall systemet vara enkelt att bygga ut och konfigurera för att gälla hela kartongmaskinen. Sid 6 (40)

De parametrar som skall bevakas är de som finns på riktvärdeskorten och är relaterade till det avgränsade området, ca 10-20 st samt övriga kontrollsignaler (pumpar, ventiler o dyl) som ryms inom beskrivningen ovan. Under arbetet skall olika systemlösningar tas fram och utvärderas. Den bästa systemlösningen väljs tillsammans med handledare innan arbetet fortsätter. AssiDomän Frövi tillsätter en referensgrupp som kan vara bollplank under arbetet och som hjälper till så att det slutresultatet blir ett verktyg som de behöver och kommer att använda. Arbetet innebär också att skapa ett verktyg för konfiguration av systemet och ett användargränssnitt för operatörerna. Mängden eget programmeringsarbete beror på systemlösning, dvs hur mycket av funktionaliteten i befintliga system som ska användas och hur mycket som skall skapas från grunden. Sid 7 (40)

Metod och Verktyg Teori och litteraturstudie I specifikationen av arbetet framkom det att verktyget som skall tas fram skall bestå av ett program som övervakar processen och som genererar larm då gränser överskrids samt en bild som presenterar processens status. Ur detta kan man skönja tre teoretiska områden som författaren bör vara kunnig inom: larmhantering, informationspresentation och programmering. De två första områdena anser författaren att han inte har tillräckligt med kunskaper inom. Av detta skäl har han gjort en litteraturstudie över dessa två vetenskaper. Det tredje området anser författaren att han behärskar och att de som läser rapporten också bör behärska, varför han här inte kommer att beskriva det. Larmhantering I denna litteraturstudie har det framkommit att larmhantering, likt de flesta vetenskaper som har datorer som grund, är en ung vetenskap. Forskningen kring larmhantering och relaterade psykologiska processer fick sitt genombrott efter härdsmältan i kärnkraftverket på Three Mile Island, USA, 1979. Olyckan inträffade dels pga mänskliga felbedömningar och dels pga felaktigt inställda mätinstrument. Målet med forskningen blev att minimera, helst bygga bort den mänskliga faktorn, och samtidigt få fram mer tillförlitliga mätmetoder och larmsystem. Studien är gjord med inriktning mot processindustri i allmänhet och pappers/kartongbruk i synnerhet. Definition av larm Enligt Andreas Bye (1997) definieras ett larm på följande vis: ett larm indikerar ett onormalt tillstånd eller kombination av onormala tillstånd som kräver uppmärksamhet av operatören 1. Denna definition är snarlik den som återges i det interna dokumentet Policy och anvisningar för AssiDomän Frövis larmsystem, med den skillnaden att definitionen har modifierats för att bättre passa in på ett kartongbruk: Definition av processrelaterade larm är en händelseavvikelse som kräver åtgärd av operatör eller berörd personal av styrsystemet. Mats Hallin (1997) väljer att definiera ett larm på följande vis: En signal från process eller utrustning som kräver att en åtgärd måste utföras för att undvika att fel uppstår. Detta medför att larmsystemet får kravet att larm skall genereras enbart när en åtgärd måste göras (Hallin, 1997). Grundkrav Ett larmsystems syfte är att övervaka en process och indikera om processen inte beter sig normalt. För att på ett effektivt vis göra detta skall det larmsystem uppfylla följande fyra grundläggande kriterier (Bye, 1997): Det skall uppmärksamma operatören att en avvikelse i processen eller systemet har uppstått. Det skall informera operatören om avvikelsens natur och dess egenskaper Det skall sända operatörens svar till avvikelsen Det skall konfirmera operatören om dennes svar korrigerade avvikelsen. 1 An alarm indicates an abnormal state or combination of states which requires attention from the operator Översättning: Per Jonhed. Sid 8 (40)

Design av larmsystem De flesta informationssystem i processanläggningar är enligt Hallin (1997) indelade i flera nivåer, t ex nivå1, nivå2 och nivå3. Nivå1 är det grundläggande styrsystemet och de övriga är högnivåsystem som används för utvärdering av processen och långsiktig uppföljning. Detta kan och bör utnyttjas vid design av larmsystem. För ett erhålla ett väl fungerande larmsystem skall det efterlikna den mänskliga hjärnan i så stor utsträckning som möjligt (Bye, 1997). Man skall utnyttja de sidor som hjärnan är bra på, såsom associeringsförmågan och mönsterigenkänning och låta datorn ta hand om de områden som den är bättre än hjärnan på, såsom minnes- och arbetskapacitet. Ett bra sätt att utforma larm som Bye beskriver är att avbilda dem efter operatörens mentala bild av processen. Man kan då bygga larm som indikerar ifall en viss del av processen är felaktig, och sedan, om operatören vill, visa exakt vilken t ex ventil eller pump som gav upphov till larmet. Dessa larm byggs då i nivå2 eller högre i informationssystemet, eftersom det där oftast finns tillgång till alla enskilda parametrar från de olika underliggande nivåerna. En annan viktig del i utformningen av ett larmsystem är hur larmen skall presenteras. Detta bör systemskaparen vara väl medveten om från ett tidigt stadium av utvecklingsarbetet. För att minska arbetsbelastningen och undvika överbelastning av operatörens mentala kapacitet bör informationen visas på en enda processbild (Bye, 1997). På denna bild bör larmen presenteras tillsammans med relaterande processinformation. På detta vis underlättas åtgärdsbeslutet för operatören och åtgärden kommer att ske tidigt och med hög tillförlitlighet. Vid larmpresentation är det bra om flera sinnen kan aktiveras så att larmen enkelt går att urskilja från övrig information. En kombination av text på skärmen samt ljus och ljud är att föredra vid större larm (Harlin, Palo, 1998). Att presentera information Att förmedla information mellan människor har alltid varit en viktig del i samhället. Det gäller att få mottagaren att verkligen förstå budskapet och minimera risken för feltolkningar. Denna vetenskap har i o m reklamens inträde i samhället accelererat kraftigt och det finns mycket forskning kring vilket media, vilken färg, vilket typsnitt etc som syns bäst och därmed säljer bäst. När datorn introducerades uppkom nya aspekter på hur man presenterar information. En av datorns stora fördelar, att kunna hantera stora mängder data, är också ett av de stora hindren i målet att bygga användarvänliga program. Fördelen uppstår när data presenteras på ett meningsfullt sätt så att det blir till information för användaren, men försvinner nästan helt när presentationen misslyckas. Detta medför att allt som presenteras på en dataskärm bör fylla en funktion, onödig information skall sorteras bort och det viktiga skall lyftas fram. Hur gör man då det? Nedan redogörs för några ledande metoder för att framställa användarvänlig presentation av information på dataskärmar. HMI: Human Machine Interface HMI behandlar gränssnittet där människa och maskin möts. Det är ett tvärvetenskapligt område som har rötter inom kognitiv psykologi, ergonomi, sociologi, organisation och ingenjörskonst. För att konstruera ett väl fungerade HMI krävs att alla delar finns med under hela utvecklingsprocessen. Sid 9 (40)

Då detta arbete enbart skall ta fram en applikation inom ett befintligt informationssystem och inte ett nytt, fristående system, presenteras här viktiga delar ur HMI-vetenskapen som belyser informationsutbytet mellan människa och maskin. Heuristik Heuristisk utveckling är att under hela utvecklingsarbetet av ett användargränssnitt systematiskt kontrollera att det är användarvänligt (Noyes, Baber, 1999). Det vanligaste tillvägagångssättet är att tillsätta en mindre grupp som med jämna mellanrum undersöker om designen följer de uppsatta designprinciperna (heuristikerna). Principer som ofta finns med är enkelhet, struktur, kompabilitet, kontroll, anpassning och konsekvent design. Enkelhet - Med enkelhet menas att designen skall hållas så ren och relevant som möjligt för att inte överbelasta den mänskliga kapaciteten. Struktur Människor tenderar att organisera och dela in sin omgivning i grupper. Om sidan organiseras så att information som hör samman grupperas tillsammans minskar komplexiteten i sidan drastiskt. Kompabilitet När en användare för första gången ser ett program utgår den från att programmet beter sig som andra program den använt tidigare. Detta bör utnyttjas för att underlätta inlärning och förståelse av programmet. Därför bör man använda sig av de riktlinjer som finns för knappar, menyer med mera. Ett exempel på sådana riktlinjer är GUI Guidelines, se avsnitt nedan. Kontroll Det är användaren som skall ha kontrollen, inte programmet. Om det t ex är inmatningar av siffror för att sedan kalkylera en budget, så bör programmet vänta med uträkningen till dess att användaren trycker på knappen beräkna. På så vis får användaren ta den tid på sig som den känner sig behöva och upplever kontroll över händelserna. Om kontrollen flyttas från användaren upplevs programmet som stressande och kommer att bli föga omtyckt. Anpassning Ett bra designat program anpassar sig både till den erfarne användaren och till nybörjaren. Ett program kan göras enklare genom lättåtkomliga förklaringsrutor och en erfaren användare uppskattar att det finns genvägar till funktioner med hjälp av Access Key 2. Konsekvent design Om en applikation består av flera fönster och delmoment bör tillvägagångssättet vara detsamma i möjligaste mån. Knappar alltid placerade i samma hörn, liknande menyrader etc. Symbolik Symbolik är en utbredd metod inom datorindustrin för att på ett enkelt sätt få användaren att förstå vad en viss funktion gör. Ett bra exempel är filhanteringsprogrammen (Preece, 2002). Dessa använder sig av något som finns utanför datorvärden och som nästan alla vet vad det är: mappar och filer. Det är allmänt känt att filer med lätthet kan organiseras och sparas i mappar. Genom att ge programmet som skall hantera filerna samma struktur känner sig användaren hemmastadd och förstår instinktivt hur programmet fungerar. Samma sak gäller den digitala papperskorgen. Precis som i verkligheten passerar allt som man slänger i regel papperskorgen. De slängda sakerna finns fortfarande kvar, men när man anser att det är för mycket saker i 2 Access Key = kortkomando på svenska. Tangentkombination som ersätter ett menyval. Sid 10 (40)

papperskorgen så tömmer man den. Men fram till dess att man aktivt tömmer papperskorgen så finns fortfarande möjligheten att ta tillbaka det som man kastat. Symbolik finns överallt i samhället och detta bör utnyttjas i programvaror. En viktig aspekt inom symboliken är färgvalet. Om allt är som det ska, om allt fungerar, bör färger vara neutrala alternativt gröna. Detta upplevs som positivt. Om något däremot går snett bör en klart avvikande färg användas, t ex rött, som nästan alla förknippar med Fara eller Stanna (Noyes, Baber, 1999). GUI Graphic User Interface GUI Guidelines är ett samlingsbegrepp för riktlinjer vid design av datorprograms grafiska gränssnitt. När GUI skapades låg enligt Ascension Labs hemsida (2004) Microsoft Windows 95/NT 4.0 interface guidelines som grund. Sedan dess har konceptet utvecklats, uppdaterats och ändrats. Idag finns det riktlinjer för alla standardkomponenter och nästan samtliga special-komponenter. Riktlinjerna bygger i grund och botten på sunt förnuft, men det finns även mycket forskning bakom som styrker dem. Nedan presenteras de mest grundläggande och de för detta arbete relevanta punkterna. Färg Att färgge ett objekt är ett effektivt sätt att göra objektet utmärkande. Det är därför lockande att färglägga de objekt som är av vikt i olika färger. Detta är dock inte god design. Enligt Ascension Labs hemsida blir det förvirrande med fler än 2-3 objekt i olika färger och redan vid så få färger har effekten tappats. Samma uppgifter står att finna i Harlin och Palo (1998). En annan viktig aspekt vid användandet av färger är hänsyn till färgblinda. Därför bör t ex en indikering inte endast ske genom att man byter mellan två färger. Bättre är då att även ljusheten på färgerna ändras eller använd ett unikt mönster tillsammans med varje färg. Text Typsnittet på en text är delvis en smaksak. Rådet är att hålla sig till rena och enkla typsnitt för att inte trötta ut läsaren i onödan. Rubriker bör vara av sanserif-typ (utan flaggor) och löpande text av serif-typ (med flaggor). Storleken bör vara 10 12 punkter för löpande text. Färgen på text skall alltid vara svart eller mycket mörk mot vit eller ljus bakrund, se nedan. Bakgrund Bakgrunden är en stor del av en bild, men en bra bakgrund är en som inte syns. Enligt Diane Zak (2001) skall den alltid vara ljus, t ex vit, ljusgul, ljusblå, grå eller off-white 3. Undvik starka färger då dessa kommer att trötta ut användaren mycket snabbt. Struktur på skärmen Objekt och kontroller behöver ha en ordnad och genomtänkt struktur på skärmen. Det skall vara naturligt för ögat att vandra mellan objekten och det viktigaste skall ögat dras till först. Nedan några punkter som hjälper till att erhålla detta: Använd samma avstånd mellan objekten Gör objekt av samma typ lika stora, t ex knappar Arrangera objekten i raka linjer, både horisontellt och vertikalt Gruppera objekt som hör ihop, t ex radioknappar, i en ram. 3 Off-white = som har huvudsakligen vit färg, men med ngn inblandning av annan vanl. med dragning åt beige (www.ne.se, 2004) Sid 11 (40)

Interaktion med användaren Att interagera med användaren är ett viktigt inslag i ett väldesignat program. Det ger upplysningar om vad användaren kan göra, får göra och när det kan göras. En interaktion som få tänker på men som är väldigt viktig är att visa för användaren när programmet arbetar. Det måste snabbt och på ett tydligt sätt framgå att programmet tagit emot ett kommando och att det arbetar med att utföra uppgiften. Om ingenting händer kommer användaren att inom en kort stund skicka kommandot igen eller börja felsöka. Hur tydligt man bör visa att kommandot är mottaget beror på hur lång tid som uppgiften tar att utföra. Om det tar upp till 5 sekunder räcker det med att muspekaren blir ett timglas. Om det tar upp mot 30 sekunder skall programmet berätta hur många procent som är kvar/är gjorda av kommandot, och om det tar längre tid bör även en dialogruta med möjlighet att avbryta processen finnas. Interaktion är också att visa på möjligheter för användaren och kanske framförallt, att begränsa användarens möjligheter. Detta åstadkommer man genom att göra funktioner tillgängliga eller inte. T ex: Om användaren i ett ordbehandlingsprogram vill klistra in ett objekt, måste användaren först klippa ut ett, annars går det inte att välja klistra in - alternativet i menyn. Detta underlättar för användaren som får reda på vad denne får göra och inte göra, och det är viktigt ur driftsäkerhetssynpunkt eftersom det förhindrar att förbjudna kommandon utförs. Kommandoknapp Kommandoknapp är en knapp med etikett som utför en operation när den blir aktiverad. Etiketten kan bestå av en text eller en bild som skall referera direkt till den uppgift som knappen utför. Viktiga riktlinjer för kommandoknappar är: Om mer information följer efter klicket innan operationen utförs, skall etiketten följas av ( ). Ex: Edit Man skall kunna använda Access keys, shortcut keys och tabulering för att flytta fokus och trycka ENTER för att aktivera den knapp som har fokus. Man bör välja en Default-knapp, den knapp som får fokus när fönstret öppnas. Det bör vara det alternativet som är troligast att användaren kommer att välja. Om det är en till tre knappar i ett fönster, skall de ordnas bredvid varandra längst ner. Om det är fler knappar ordnas de under varandra längs högra kanten. Sid 12 (40)

Verktyg PI-systemet PI ProcessBook PI ACE PI databas PI Module DataBase Styrsystem Data från lab Data från andra system Figur 2. PIs databas är hjärtat i systemet som samlar in data från styrsystem, från laboratoriet och flera andra system. Med hjälp av beräkningsprogrammet PI ACE och struktureringsprogrammet PI Module Database fås relevent information fram som presenteras i PI ProcessBook. År 2003 installerade AssiDomän Frövi PI-systemet för realtidshantering av signaler och data. Systemet är utvecklat av OSIsoft Inc. med hänsyn till all sorts kontinuerlig processindustri som kräver hög tillförlitlighet och driftsäkerhet, såsom pappersbruk, järnverk och kärnkraftverk. I PI-familjen ingår ett antal programmoduler som tillsammans bygger upp systemet. Grunden i systemet är en databas där samtliga signaler (kallat taggar) loggas och sparas. Till detta finns det program för presentation (PI ProcessBook), för beräkningar (PI ACE), för struktureringar av databasen (PI Module Database) och många fler program för att tillsamman generera den funktion som efterfrågas, se figur 2. Hela systemet är kompatibelt med Microsoft Office genom olika Add-Ins. I detta arbete har Excel använts för inmatning av data till systemet och vid skapandet av nya taggar. Nedan följer en närmare presentation av de PI-program som jag har använt mig av. Informationen är hämtad dels från handledare på AssiDomän Frövi och dels från OSIsofts hemsida, www.osisoft.com PI ProcessBook PI ProcessBook är dels systemets presentationsverktyg, dels det verktyg som skapar processbilderna. Med ett musklick växlar man mellan Build -mode och View -mode. Presentationen är mycket flexibel. Processbilderna byggs genom klicka-och-drag -principen vilket gör arbetet effektivt och enkelt att lära sig. Det är särskilt viktigt när man skall underhålla eller uppdatera bilder. Ett exempel på en PI-bild är figur 2 som visar tre kvarnar. ProcessBook har inbyggt VBA (Visual Basic for Applications) som möjliggör mer avancerade och dynamiska bilder. Man kan t ex få lampor att blinka vid larm, popup-bilder på processvärden och indikationer ifall något värde på bilden ändras. Sid 13 (40)

Figur 3. Exempel på Processbild i PI. Här visas de tre kvarnarna på bottenskiktet. PI Module Data Base PI Module Data Base är ett databasprogram som gör det möjligt att strukturera information i hierarkisk ordning. Denna hierarki är snarlik vanliga filhanteringsprogram, t ex Utforskaren, men det finns även klara skillnader som jag återkommer till. Hierarkin byggs upp av moduler som kan organiseras i obegränsat många nivåer, och varje nivå i ett obegränsat antal moduler. I modulerna kan det finnas några olika slags informationsbärare, nämligen dessa: PI Alias: Ett alias kan beskrivas som ett namn man tilldelar en tagg. Det är användbart på flera sätt. Dels kan man ge taggarna ett enklare namn så att man förstår direkt vad de mäter, t ex döpa den till Harstlim_status istället för 53FY067.STS. Dels kan man i flera moduler ha en alias med samma namn, t ex Status, men de är kopplade till olika taggar. Detta utnyttjas i programmeringen där man slipper hårdkoda taggnamnet för varje modul, utan kan använda sig av alias Status i samtliga. PI Properties: En property är en variabel som lika gärna kan användas som konstant. De kan innehålla de flesta typer av data, såsom strängar, heltal, booleska uttryck, flyttal m fl och dessa värden kan man läsa och skriva från t ex ett Visual Basic-program. Sid 14 (40)

Figur 4. Bilden visar PI ModuleDB. I vänstra delen av bilden ser man att modulen AssiDomän har sju undermoduler varav 6 av dessa har minst en undermodul var (det ser man på +-tecknet framför). På bildens högra del ses ett exempel på att även Properties kan organiseras hierarkiskt. Här framgår att i modulen ProductChange finns propertyn Tags som har 4 undermoduler där samtliga har minst en underproperty var. Både PIAlias och PIProperty kan organiseras i en hierarkisk ordning inom varje modul, precis som moduler organiseras. Alltså kan en Property ha underproperties och en alias ha underalias. Se figur 3. Den stora skillnaden mot andra databasprogram är att samma modul kan finnas på flera ställen samtidigt, kallat länkade moduler. Detta gör att det räcker att uppdatera en av dessa för att förändringen skall ske i samtliga länkade instanser. PI ACE ACE står för Advanced Computing Engine och är ett kraftfullt verktyg för beräkningar av alla de slag. Grunden i ACE är Visual Basic. Allt som kan göras i VB kan också göras i ACE. Detta betyder att ACE kan fungera som en länk mellan olika informationssystem inom ett företag, t ex scheman, relationsdatabaser och underhållsystem. PI ACE fungerar så den funktion man söker programmeras med hjälp av Visual Basic och det programmet kopplas till en modul i PI Module DataBase. Då genererar programmet automatiskt den kod som behövs för länkning mellan Visual Basic, PI Module DataBase och PI-serverns databas. En stor fördel med ACE är att när en funktion är färdigbyggd kan man koppla den till så många moduler som man vill utan att behöva ändra något i programkoden. I detta examensarbete användes ACE för att koppla samman körrekommendationernas databas med databaser som innehåller PI-taggar och för att använda dem i PI Module DataBase. Sid 15 (40)

Microsoft Visual Basic 6.0 Microsoft Visual Basic (VB) bygger på programstråket BASIC (Beginner s All-purpose Symbolic Instructions Code). VB uppfanns enligt www.johnsmiley.com av Alan Cooper 1988, då kallat Tripod. Microsoft köpte programmet och gav ut det under namnet Visual Basic 1.0 1991. Sedan dess har språket varit ett av de ledande för utveckling av små och medelstora applikationer. VisualBasic 6 är både ett programspråk och en utvecklingsmiljö. Språket är händelsestyrt och objektbaserat, dock ej objektorienterat. Visual Basic var det första programspråk där programmeraren slapp att själv koda utseendet på grafiska objekt, såsom knappar och textrutor, dvs utvecklingsmiljön är delvis grafisk. Den stora fördelen är att även en medelmåttig programmerare kan skapa snygga program och det är som tidigare sagt i kapitlet om GUI, något man ej skall underskatta. Referensgruppen AssiDomän Frövi utsåg en referensgrupp som deltog i utvecklingsarbetet vid 6 möten tillsammans med författaren och hans två handledare på företaget. Här presenterades vad som åstadkommits och vad tanken och visionen var. Referensgruppen diskuterade och kom med förslag och konstruktiv kritik på arbetet för att slutprodukten skulle bli ett verktyg som efterfrågades och inget annat. I gruppen ingick: Johan Magnusson mälderist 4 Per Wester - maskinförare Johan Miller - driftsingenjör Leif Karlsson driftstekniker Niklas Sander automationsavdelningen Kent Åkerberg - driftsingenjör Andreas Fröberg automationsavdelningen 4 En mälderist är en operatör som arbetar i mälderiet. Mälderiet är den del av kartongmaskinen där cellulosafibrer och kemikalier blandas med vatten och behandlas till en mäld. Sid 16 (40)

Analys och Resultat Nulägesanalys Larmhanteringen hos AssiDomän Frövi sköts dels om av Honeywells DCS-system som kallas TDC3000 och är en del av deras system TPS (Total Plant System) som har hand om parametrar och I/O-signaler från själva kartongtillverkningen (Ph-värden, kemikaliedoseringar, ytvikt etc) och dels av systemet ABB 450 som har hand om maskindriften (motorer, pumpar etc). Detta visas översiktligt i figur 5. Dessa system larmar genom att dels ge indikation på skärmen, dels en ljudsignal och dels en ljussignal. Båda dessa system ligger under PI, deras signaler går att nå från PI. Om den aktuella bilden som larmet härrör från inte är framme på skärmen ser man larmet i larmlistan. Här visas den felande komponentens taggnamn, dess status och en kortare larmtext. Från larmlistan kan larmet bekräftas. Om skärmen har framme den bild där larmet härrör från, kommer den felande komponenten att blinka rött. Operatören kan då klicka på komponenten och få fram en kortare larmtext. Det går att bekräfta larmet direkt på skärmen. Larmet går även att se i larmlistan där alla larm loggas och sparas för statistik och analys. Larmen är indelade i tre prioritetsnivåer: Emergency (Högsta prioritet) - Larmnivå Emergency ges då det är stor fara för produktionsstopp eller mycket bristande kvalité. High (Hög prioritet) High ges då det är ett fel som bör åtgärdas inom en väldigt snar tidsperiod. Low (lägst prioritet) Low är i stort sett bara ett informationslarm som inte kräver direkt åtgärd. Ljudsignalen som ges vid larm är densamma oavsett larmets prioritetsnivå, men ljussignalen är olika. Denna signal ges från en ljuspelare, kallad julgran, i taket som består av en grön (low), en gul (high) och en röd (emergency) lampa. Några mälderister och maskinförare har fått säga vad de tycker om larmsituationen. På maskinförarsidan var läget helt acceptabelt, där kom det mestadels relevanta larm och det var sällan det var larm som var helt felaktiga. På mälderisidan 5 var det däremot sämre ställt. Där kommer det många onödiga larm, och det beror inte främst på felaktigt inställda gränsvärden, utan snarare på avsaknad av inbyggd logik i systemet som skulle kunna sålla bort följdlarm. PI Honeywell ABB Mätramar Pumpar, ventiler Motorer, drifter Figur 5. Signalers väg till PI. 5 Mälderiet är den del av kartongmaskinen där kartongmassan, mälden, bereds och där flera av kartongens egenskaper bestäms. Mälderiet sköts av mälderisten. Sid 17 (40)

Ett exempel: Mälderisten stänger av en av kvarnarna för att den inte behövs. Då kommer det att komma ca 10-15 larm om att pumpar och ventiler runt denna kvarn har stannat, att flödet till kvarnen är för lågt osv. Detta trots att det var mälderisten som beordrade stoppet. Detta är inte bra och kan leda till att andra, betydligt allvarligare larm, missas i denna larmlavin som väller in över listan. Att situationen för mälderisten stundtals kan vara kaotisk framgår av larmlogfilen. Författaren har titta i en dylik mellan den 17 och den 23 februari 2004, och där ser man att det kommer en mängd onödiga larm till mälderisten, larm som med största säkerhet är följdlarm och därmed enbart förvillande. En sak som framkommit under nulägesanalysen är att operatörer ogillar system som är tvingande. De flesta operatörer har sitt speciella sätt att handskas med maskinen och sitt sätt att utföra vissa operationer. Ett tvingande system hamnar då snabbt i onåd hos operatörerna. Självklart finns det vissa fel som måste åtgärdas enligt ett visst mönster och i sådana fall skall ett tvingande system användas. I andra fall bör larmsystemet enbart upplysa om möjliga tillvägagångssätt för att avstyra felet och sedan är det upp till operatören att välja den väg som passar bäst. Systemidéer I början av arbetet togs det fram ett antal olika systemidéer, koncept, på hur systemet skulle se ut. Tillsammans med mina handledare valdes ett koncept att arbeta vidare med. De olika koncepten var följande: Koncept 1 Positioner i PI Module Data Base Tanken var att dela in den lina som skall övervakas i ett antal positioner, PosA, PosB osv, där varje position representeras av en modul. Varje position motsvarar en fysisk del av linan, ex en kvarn och alla signaler som skall övervakas runt kvarnen läggs till i kvarnens positionsmodul. Om det behövs logik eller formler för att ta fram ett passande mätvärde för en signal kan dessa lagras som strängar i PI Properties i respektive modul. Sedan kan man i huvudprogrammet skriva t ex: Calc(PosB) och då hämtas PosBs värden in och dess formler maskas ur sina strängar. En av fördelarna med att lägga formlerna i modulerna än att hårdkoda dem är att varje signal som skall övervakas kan ha sina egna villkor. En annan stor fördel är att om/när man vill lägga till en modul i efterhand behöver man inte kompilera om huvudprogrammet. Dessa fördelar gäller även ändringar, uppdateringar och justeringar av formler i befintliga moduler. Positionerna läggs i en lista som går från PosA till PosB osv. Vid vanlig processövervakning loopas listan igenom och kontrollerar ifall någon signal i någon position avviker från körrekommendationerna. Vid framtagande av en checklista använder man positionerna för att stegvis ändra körrekommendationerna för signalerna. Om PosA ändras vid tid 0, kan man i PosB-modulen lägga in en PIProperty som talar om hur lång tid efter föregående modul i listan (i detta fall PosA) som den skall ändras, t ex 8 min. Sid 18 (40)

Programmets arbetsgång: Ta reda på vilken kvalité som körs nu och hämta in dess körrekommendation. Tilldela positionerna sina respektive parametrar med gränsvärden. Loopa igenom listan och jämför är-värdet mot gränsvärdena. Ger en indikering om någon parameter ej är inom gränserna. Skall slockna antingen genom bekräftelse från operatören eller när parametern är inom gränserna igen. Fördelar: Bra grund för att skapa checklistor vid produktionsomställning PI Module Data Base är mycket flexibelt och tillåter stort eget tänkande Det är lätt att skriva Visual Basic-program till PI Module DataBase PI Module DataBase ger god översikt och är lätt att underhålla och uppgradera All programvara och maskinvara finns redan och är välkänd inom företaget. Nackdelar: Kan endast komma åt signaler som redan finns i PI-systemet och det gör inte alla signaler än. Koncept 2 PI Process Templates 1.2 Liknar till stora delar koncept 1, men man använder PI Process Templates istället. PI Process Templates-konceptet är flera underprogram som tillsammans tar hand om felhantering. Det går till så här: För varje tag/parameter som man vill övervaka skapar man en template. Denna består av jämnt fördelade övre och undre gränsvärden samt ett mittvärde. Alla templates sparas i PI Module DataBase. Varje template tilldelas till en PI Batch Unit som utför realtidsövervakning av parametern. Övervakningen visas i Process Template Monitor och kontrolleras ständigt mot gränsvärdena. Med hjälp av PI ProcessBook skapar man bilder som visar en tags historia, dess templatesvärden och nuvarande larmstatus. Process Templates bygger på Batch-teknik, dvs. satsproduktion och inte kontinuerlig produktion. Detta är en nackdel, men man borde kunna komma runt den om man ser t ex en tamour (kartongrulle) som en batch eller en kvalitésekvens som en batch. Process Templates kan även läsa in värden från tidigare, lyckade körningar och anpassa sina gränsvärden efter dessa. Fördelar: Färdiga verktyg att arbeta med Kommunikationen mellan de olika delarna är klar Instruktioner finns Läsa av värden för föregående körningar och anpassa sina gränsvärden efter dessa. Nackdelar: Bara centrerade larmgränser Sid 19 (40)

Kan endast komma åt signaler som redan finns i PI-systemet och det gör inte alla signaler än Kan vara svårt att få exakt den funktion som efterstävas eftersom strukturen redan är klar och man kodar mindre själv PI Process Templates är utvecklat för Batchprocesser och inte för kontinuerliga processer. Koncept 3 GoalArt Diagnostic Station GoalArt är ett företag i Lund vars huvudprodukt kallas GoalArt Diagnostic Station (GDS). Det är ett system för larmhantering som innehåller ett flertal funktioner som skulle kunna vara användbara för AssiDomän Frövi. Några av de mest utmärkande funktionerna är: Tillståndsbaserade larmprioriteringar Funktionen känner av nuvarande tillstånd och använder den informationen till att göra tillståndsspecifika larmklasser. Larmanalys Funktionen använder hela systemets information för att ta reda på vad som är primärlarmet och vad som är konsekvenslarm. Trendanalys Visar historiska mätningar från databas och använder statistikalgoritmer för att förutsäga problem och upptäcka fel så tidigt som möjligt så att de inte hinner skada processen. Larmrensning Funktionen visar larm vars gränsvärden är felkalibrerade, dvs fel som händer väldigt ofta eller väldigt sällan. Ger även förslag om hur larmgränserna skall justeras för bättre resultat. Det finns även funktioner för sensorkontroll, feldiagnostik, framtidsscenario m fl. Ovanstående information är hämtad från GoalArts hemsida (GoalArt, 2004). Systemet som presenteras verkar vara ett väl genomtänkt system, som innehåller flera av de funktioner som AssiDomän Frövi efterfrågar. Särskilt intressant är Larmanalysfunktionen som verkligen skulle kunna göra nytta på AssiDomän Frövi. Den stora nackdelen som kan ses är att det är en stor investering som företaget måste göra och frågan är om det då är ett sådant system som efterfrågas? Om GoalArts program skulle införskaffas handlar det om att köpa in ett helt nytt larmsystem och en sådan frågeställning ryms inte inom detta examensarbete. Koncept 4 Vidarutveckling av Koncept 1. En utveckling/förenkling av systemidé nr 1. Man kopplar en modul till ett ACE-program. Detta program tar in vilken produkt som körs. I modulen finns alla de signaler som skall läsas in sparade i PIProperties. Programmet sorterar ut de parametrar som skall användas och listar dem. Till varje tagg, t ex Processtag1, finns flera taggvarianter med samma namn fast med olika ändelser, t ex Processtag1.rv (riktvärde) Sid 20 (40)

Processtag1.la (låg larmgräns) Processtag1.lla (låglåg larmgräns) Processtag1.ha (hög larmgräns) Processtag1.hha (höghög larmgräns) Processtag1.pv (processvärde) Produktnamnet används för att hitta rätt körrekommendationer så att gränstaggarna kan sättas. På detta sätt kan man logga och visa trendkurvor för processvärdet tillsammans med dess riktoch gränsvärden vilket är mycket användbart både ur övervakningssynpunkt och ur uppföljnings- och utvärderingssynpunkt. Programmeringsmässigt underlättar denna struktur på flera sätt. Dels genom att man endast behöver hämta in och sortera receptet en gång, dels genom att man jämför med sig själv, eftersom namnet är lika och endast suffixet ändras. Processtaggarna skapas enkelt i ett excel-dokument med Add-In-funktionen för just detta ändamål. Därifrån läses de automatiskt in i PI-systemet. Om någon parameter saknar en eller flera larmgränser kan man sätta dessa till no data. Val av koncept Författaren och hans två handledare kom efter fundering och diskussion fram till att koncept 4 är det bästa alternativet. Detta av flera anledningar: dels ger PI Module DataBase en bra översikt och det är lätt att underhålla/uppdatera, dels finns alla utrustning som behövs redan hos företaget. Eftersom PI ProcessBook redan används av de flesta operatörer blir verktyget med större sannolikhet bättre mottaget och snabbare accepterat än om det varit ett helt nytt system. Beskrivning av det implementerade systemet Till grund för systemet ligger Koncept 4. Utifrån detta har arbetet gjorts med vissa modifieringar under processens gång. Nedan följer en redovisning av de ingående programmen, vad de gör, hur de gör det och varför de gör det. Systemet kan grovt delas in i två delar. Den ena delen tar hand om att övervakningen och genereringen av eventuella larm, och den andra delen tar hand om presentationen av eventuella larm samt hur dessa bilder byggs upp. I den första delen ingår tre ACE-program som författaren har gjort från grunden: LimitUpdater, LimitCheck och AlarmGenerator. Dessutom används ett ACE-program, Drift_Status, som handledare Jan Sjögren gjort i ett tidigare projekt. Samtliga ACE-program är kopplade till var sin gren i PI Module DataBase. Den andra delen består av Visual Basic-programmet PictureGenerator. Figur 6 visar förhållanden mellan programmen och Tabell 1 visar vad som startar de olika programmet. Sid 21 (40)

LimitUpdater Uppdaterar alla taggars rikt- och gränsvärden Hämtar riktvärden och kontrollerar logik. Sätter statustaggar Drift_Status PI Module Database LimitCheck Hämtar gränser och sätter PI- Properties ifall de överskrids Hämtar PI-Properties med larm och sätter dess statustagg AlarmGenerator PI ProcessBook Statustaggarnas värden används i bilderna för att generera rätt färg på larmen. PictureGenerator Skapar nya bilder på begäran. Figur 6. Översiktlig bild av hur de olika programmen samarbetar. Program Startvillkor LimitUpdater Taggen ProductCode ändras LimitCheck Riktvärden eller larmgränser ändras AlarmGenerator Startar automatiskt var 60:e sek Drift_status Startar automatiskt var 60:e sek PictureGenerator Uppdaterar listboxen var 20:e sek Tabell 1. Vad programmen startas av. LimitUpdater Detta ACE-program kopplas till PI Module DataBase-modulen ProductChange som innehåller samtliga taggar som skall övervakas, se figur 7. Där ser man även att varje tagg innehåller 8 stycken parametrar. Tagname anger taggens namn i PI-systemet. RecipeID anger vilket nummer som taggen har i körrekommendationen. RelativeLimits anger om taggen skall använda sig av de larmgränser som finns i körrekommendationerna eller om gränserna skall sättas relativt riktvärdet. RelLimitXX anger gränser som skall användas till respektive gräns ifall RelativeLimits är TRUE. Om RelLimType är TRUE skall de värden som är angivna i RelLimitXX användas i absoluta värden gentemot riktvärdet, annars skall de användas procentuellt mot riktvärdet. Sid 22 (40)

Figur 7. Visar hur taggen Alun Premix är inlagd i systemet. Det framgår att taggen har ID-nummer 251 i körrekommendationen, samt att den skall använda relativa gränser i procent gentemot riktvärdet. Hämta rätt körrekommendation (KR) Hämta första tagnummret i körrekommendationen Matcha tagnr. mot RecipeID Loopa tills rätt RecipeID hittas Är RelativeLimits TRUE eller FALSE? TRUE Är RelLimType TRUE eller FALSE? TRUE Använd RelLimitXX för att sätta gränserna i absoluta värden gentemot riktvärdet FALSE FALSE Sätt larmgränserna efter de värden som finns i KR Använd RelLimitXX för att sätta gränser i procent gentemot riktvärdet. Figur 8. Flödesschema över programmet LimitUpdater. Sid 23 (40)

Programkoden är uppbyggd så, att först öppnas databasen där körrekommendationerna finns. Taggen ProductCode avläses och rätt körrekommendation inhämtas och sparas i en tvådimensionell vektor, kallas vdata. Vektorn matchas mot den första taggens RecipeIDnummer. När den hittar rätt kontrolleras ifall RelativeLimits är satt eller ej. Om den är satt sätts varje gräns till respektive värde. Om RelLimType är TRUE sätts de i absoluta tal relativt riktvärdet, om den är FALSE sätt de i procent. Om RelativeLimits ej är satt (FALSE) hämtas gränsvärdena för taggen från vdata och gränserna sätts. När detta är gjort loopar programmet genom samtliga taggar som ligger i ProductChange och upprepar ovanstående procedur. Se figur 8 för programmets flödesschema. LimitCheck. LimitCheck är det enklaste av de tre programmen som har hand om larmgenereringen, eftersom här kopplas varje signalmodul till ACE-programmet. Detta medför att inga loopar eller genomsökningar av trädstrukturer behövs. Programmet har som insignaler samtliga gränser, dvs riktvärdet (RV), låglarm (LA), låglåglarm (LLA), höglarm (HA), höghöglarm (HHA) samt nuvarande processvärdet, (PV). Programmet triggas automatiskt var 60:e sekund. Det första som sker är att PV testas först mot de yttre gränserna, HHA och LLA och sedan mot de inre, HA samt LA. Om någon gräns överskrids sätts signalens statustagg till respektive larmstatus. Om inget larm påträffas sätts statustaggen till OK. Sid 24 (40)

Figur 9. AlarmGenerator är kopplad till modulen KM5 liksom PictureGenrator, vilket medför att ett likadant träd kommer att genereras. Jämför med Figur 11. AlarmGenerator Detta program är det mest omfattande av de tre larmgenereringsprogrammen. Det är kopplat till en egen gren i PI Module DataBase där indelningen sker efter hur man vill att bilden på operatörens skärm skall bli, se figur 9. Mer om detta under PictureGenerator. AlarmGenerators uppgift är att kontrollera ifall någon statustagg inte är OK och i så fall vidtaga åtgärder. Detta sker på följande sätt (för flödesschema, se figur 10): Huvudprogrammet triggas automatiskt var 60 sekund. Det sköter om initiering och konfiguration av variabler och databaser innan den anropar funktionen Get_Alarms. Denna subrutin letar sig ner till botten av databasen genom ett rekursivt anrop. När botten är nådd kontrolleras ifall någon av variablerna ej har statusen OK, dvs har ett larm. Hittas ett larm skrivs detta larm in som en PIProperty i den modul som programmet är kopplat till. Tillsammans med larmets art (HA, HHA, LA eller LLA) sparas även dess sökväg i trädet. Sid 25 (40)

Initiering och konfigurering Är denna modul längs ned i trädet? Ja Nej Rekursivt anrop som stegar ett steg nedåt i ModuleDBhierarkin. Nästa modul Se om modulen har en statustag OK True False Sätt OK Skriv larminfo till modulen KM5 Sätt statustaggen till respektive larm. Alla moduler kontrollerade Figur 10. Flödesschema över AlarmGenerator. Under hela den rekursiva funktionen arbetar en vektor och en sträng med att hålla ordning på var i trädet som man befinner sig. Strängen, strpath, har hela tiden sökvägen till den modul som programmet är i just nu. Denna sökväg sparas tillsammans med larmet i modermodulen och används för att visa för operatören var larmet härstammar ifrån. Vektorn, strworsealarm, sparar det sämsta larmet som har uppstått på respektive nivå. Detta utnyttjas sedan när den rekursiva funktionen nystas upp igen genom att tilldela varje nivås statustag den sämsta statusen (HHA, LLA är sämst, sedan LA och HA, och bäst är naturligtvis OK). På så vis kommer rätt nivå få rätt färg i bilden. Även detta beskrivs närmare i PictureGenerator. Drift_Status Detta ACE-program är gjort av Jan Sjögren, handledare till detta examensarbete. Programmet är skrivet till ett system för driftsrapporter på AssiDomän Frövis sulfatfabrik och har exakt de funktioner som eftersträvas i detta arbete. Programmet används när övervakningen skall innehålla logik för hur larmet skall ges. I AlarmGenerator kontrolleras en tag i taget mot sina gränsvärden, men i Drift_Status går det att övervaka flera taggar samtidig och generera ett larm om någon av dem är felaktig. Programmet fungerar så att man för varje tag skapar en modul i PI Module DataBase. I modulen skall det finnas en Property som heter States, och under den skall det finnas 5 properties som var och en definierar det villkor som krävs för att just det larmet skall gälla. Programmet hämtar in dessa villkor, undersöker ifall något blir sant och sätter i så fall taggens status till respektive värde. Sid 26 (40)

På detta sätt kan man bygga statustaggar som täcker större områden. Ett exempel i detta arbete är statustaggen Kvarn7.sts. Under den ligger 9 taggar som samtliga har direkt koppling till den kvarnen. Larm ges om någon av dessa nio är felaktig, dock får operatören inte reda på vilken. PictureGenerator Detta VBA-program (Visual Basic for Applications) har till uppgift att generera en PI-bild som motsvarar den trädstruktur som används i AlarmGenerator, se figur 11. Bilden ser ut som ett vanligt filhanteringsprogram, t ex Utforskaren, för att enkelt kunna se varifrån ett larm kommer. Om inga larm finns är hela trädet grönt, och uppstår ett larm ändras färgen i den grenen larmet kommer från till antingen gult (HA, LA) respektive rött (HHA, LLA). I en ListBox under trädet visas larmens data; larmets art, signalens namn, i vilken modul den ligger samt i vart man enklast åtgärdar felet 6. Listan sorteras i fallande skala med de allvarligaste larmen överst. ListBoxens storlek varierar med antalet larm som finns i listan. Vid 1 9 larm är den antal larm + ett rader hög, vid fler än 9 är den 10 rader hög. Om det inte finna några larm blir listboxen osynlig. Bilden genereras automatiskt genom att man anger från vilken modul i PI Module DataBase som den skall börja ritas. Då öppnas en delvis färdig sida som innehåller ListBoxen med tillhörande kod och på denna ritas trädstrukturen upp. Automatiskt kopplas respektive nivås rektangel till dess statustag, och taggen värde bestämmer färgen på rektangeln (OK = grönt, LA, HA = gult och LLA, HHA = rött). Bilden kan nu sparas och man kan använda den som den är eller lägga till den information som man tycker sig behöva. 6 I PI-systemet kan operatörerna ej styra kartongmaskinen, endast övervaka den. Därför måste de byta system för att korrigera ett eventuellt fel. Programmet berättar här på vilken sida som korrektionen enklast görs. Detta underlättar för operatörerna, särskilt vid inskolning av ny personal. Sid 27 (40)

Figur 11. Två likartade träd 7 fast i olika tillstånd: till vänster när det inte finns några larm, alla rutor är gröna och larmlistan är osynlig, till höger när det finns 4 larm i listan, tre stycken LLA och ett LA, med respektive färg. Sökvägen upp i hierarkin får samma färg som det allvarligaste larmet som finns under den. Varför gjordes detta program och inte bara en färdig bild? Jo, dels för att mitt arbete skall vara skalbart, det kommer att bli fler moduler och undermoduler allt eftersom systemet byggs ut. Att då även behöva rita om bilden kan vara ett tillräckligt stort hinder för att inte fortsätta använda systemet. Dessutom kommer säkerligen olika operatörer vilja ha olika stora träd, och då skulle det behövas en ny bild för varje operatör. Om man bygger ut databasen med fler moduler behöver man bara starta om PictureGenerator för att erhålla ett träd med rätt kopplingar till hela databasen. 7 I detta arbete är det endast delar av bottenskiktet som skall implementeras. Dessa träd är byggda för att visa hur en struktur sedan kan se ut, med hela kartongmaskinen överst, som kan delas in i Mälderidel och Maskindel. Mälderiet kan sedan delas in i BottenSkiktet, MittSkikten, ToppSkiktet och Övrigt, där parametrar som inte tillhör något specifikt skikt hamnar. Sid 28 (40)