Visualisering av Sensor Fusion Data i Stressometer 6 · Visualisering av Sensor Fusion Data i...

UMEÅ UNIVERSITET Institutionen för Datavetenskap Examensarbete

Visualisering av Sensor Fusion Data i Stressometer 6.0

Prof. Lars-Erik Janlert Prof. George Fodor Umeå Universitet ABB Automation Technology Products

Patrik Bodelid 7:e juni 2004

Handledare:

iii

Abstract This document proposes the development of a graphic user interface for the product Stressometer. The Stressometer is a measuring and control system for metal strip flatness developed by ABB that is used for cold rolling in the steel industry. There is a need for more extensive feedback from the rolling process where today mainly feedback for the flatness is given. By incorporating sensor fusion for other properties such as temperature, thickness and position etc. a “bigger picture” is presented for the users. This will help to increase the knowledge and understanding of the process and this in turn means that the rolling process can be refined, hopefully to be more time and cost efficient but also to give higher quality to the finished product. Using the strip as the starting-point, all the properties can be visualized on top of it, and it is important that all the properties can be correlated, so that different relations can be seen. By visualizing each property with a different shape and different color and by allowing the user to control which properties that should be shown and how opaque, the properties can be overlayed and shown without cluttering the screen. The HMI will be run over network (Internet) and executed in a web browser, so the choice to develop the HMI in Java was made. Since the HMI should reflect changes of the strip’s properties over time a 3D interface was implemented. For this the Java 3D is used, on account of the easy integration with Java. In discussion with the supervisor we established that the following properties should be shown in the HMI: Temperature – The temperature of the strip Thickness – The thickness of the strip Flatness – The flatness of the strip Position – The side shift of the strip Exentricity – Tension introduced when the strip is reeled Cooling – How much cooling has been applied Only flatness, position and thickness are supported in hardware and software today, but the goal is that all of the listed properties should be measured or calculated so the GUI should therefore be able to show them when they become available. How each property should be visualized was experimented with and presented to a group of users in iterations until an adequate solution had been reached. The implementation of the GUI consisted of creating each of these properties as different geometries in Java 3D. By assigning a behavior to each geometry that checks the GUI controls for opacity and changing the appearance of the geometries the user can control how opaque each property should be shown. Another behavior is assigned to update the shape and colors of each geometry to reflect the sensor inputs with low latency. The applet communicates via RMI with a server called the FSA-Server, where all data about the rolling process is stored and manipulated. By implementing separate readers as their own threads they can communicate with the FSA-Server and keep all data up to date without blocking the program flow. The finished applet is working with the current system and supports visualization of the properties yet not available, but has not yet been tested in a real application.

v

Sammanfattning I detta dokument behandlas utvecklingen av ett grafiskt användargränssnitt för produkten Stressometer. Stressometer är ett mät- och reglersystem för planhet som används vid kallvalsning inom stålindustrin. Det finns ett behov av en mer omfattande feedback från valsprocessen, där idag i huvudsak feedback för planheten ges. Genom att införa sensor fusion för andra egenskaper som t.ex. temperatur, tjocklek och position etc. ges användaren en ”större bild”. Detta kommer att hjälpa till att öka kunskapen och förståelsen av valsprocessen vilket i sin tur leder till att valsprocessen kan förfinas, och förhoppningsvis bli mer tids- och kostnadseffektiv samt även öka kvaliteten hos den färdiga produkten. Genom att använda valsämnet som utgångspunkt så kan alla egenskaper visualiseras på det. Det är viktigt att alla egenskaper kan korreleras så att samband kan ses. Genom att återge alla egenskaper med olika former och färger, och genom att låta användaren styra vilka egenskaper som skall visas och hur kraftigt de skall synas, så kan de olika egenskaperna visas ovanpå varandra utan att det blir oöverskådligt. HMI:et kommer att köras över nätverk och exekveras i en webbläsare, så valet att utveckla HMI:et i Java gjordes. Eftersom HMI:et ska reflektera förändringar av valsämnets egenskaper över tid fastslogs att ett 3D gränssnitt skulle göras. För detta valdes Java 3D för att det är enkelt att integrera med Java. I samtal med handledare fastställde vi att följande egenskaper skall gå att visa i HMI:et: Temperatur – Valsämnets temperatur fördelad över valsämnets yta. Tjocklek – Valsämnets tjocklek fördelad över valsämnets yta. Planhet – Valsämnets planhet fördelad över valsämnets yta. Position – Sidoförskjutningen hos valsämnet. Excentricitet – Spänningar introducerade i bandet när det hasplas Kylning – Hur mycket kylning som har applicerats Enbart planhet, position och tjocklek stöds i hårc- och mjukvara i nuläget, men målet är att alla listade egenskaper ska mätas eller beräknas så GUI:et ska stödja dem då de blir tillgängliga. Hur varje egenskap skulle visualiseras experimenterades med och presenterades för en grupp användare i iterationer tills en tillräckligt bra lösning hade nåtts. Implementationen av GUI:et bestod av att skapa en geometri för varje egenskap i Java 3D. Genom att tilldela ett beteende till varje geometri, som kontrollerar GUI-kontrollerna för genomskinlighet och ändrar utseendet hos geometrierna, så kan användaren styra hur genomskinlig varje egenskap skall visas. Ett annat beteende tilldelas geometrierna för att uppdatera formerna och färgerna för att reflektera givarvärdena. Java-appleten kommunicerar via RMI med en server kallad FSA-Server, där all data kring valsprocessen lagras och manipuleras. Genom att implementera separata läsare som egna trådar så kan de kommunicera med FSA-Servern och hålla all data aktuell utan att blockera programflödet. Den färdiga Java-appleten fungerar med det befintliga systemet och tillåter visualisering av egenskaper som inte är tillgängliga ännu, men har ännu inte testats i en verklig applikation.

vii

Innehållsförteckning 1 Inledning ........................................................................................................................... 1

1.1 MÅL ............................................................................................................................ 1 1.2 EGEN INSATS ............................................................................................................... 1 1.3 UPPLÄGG..................................................................................................................... 2

2 Bakgrund........................................................................................................................... 3 2.1 ABB............................................................................................................................ 3 2.2 TILLVERKNING AV METALLPLÅTAR............................................................................. 4

3 Relevanta teknologier ...................................................................................................... 7 3.1 INDUSTRIELLA MJUVARUARKITEKTURER .................................................................... 7 3.2 JAVA ......................................................................................................................... 10 3.3 HYPERTEXT MARKUP LANGUAGE ............................................................................ 11 3.4 JAVA 3D.................................................................................................................... 12 3.5 SENSOR FUSION ......................................................................................................... 14

4 Applikationsrealisation.................................................................................................. 17 4.1 STRESSOMETER FLATNESS MEASUREMENT AND CONTROL SYSTEM......................... 17 4.2 MÄTRULLEN.............................................................................................................. 18 4.3 MÄTT PLANHET......................................................................................................... 19 4.4 AKTUATORER............................................................................................................ 20 4.5 HMI .......................................................................................................................... 24

5 Problembeskrivning ....................................................................................................... 25 5.1 SYNSÄTT PÅ PROBLEMET........................................................................................... 25 5.2 PROBLEMBILD ........................................................................................................... 26

6 Krav & Mål..................................................................................................................... 29 6.1 BEHOV ...................................................................................................................... 29 6.2 VERIFIKATION ........................................................................................................... 29 6.3 MÅL .......................................................................................................................... 30

7 Användarcentrerad utveckling ..................................................................................... 31 7.1 BAKGRUND ............................................................................................................... 31 7.2 ANVÄNDBARHET....................................................................................................... 32 7.3 ANVÄNDARANALYS .................................................................................................. 33 7.4 UPPGIFTSANALYS...................................................................................................... 34 7.5 MODELLER................................................................................................................ 35 7.6 PROTOTYPING ........................................................................................................... 36 7.7 NÅGRA KOMMERSIELLA MODELLER .......................................................................... 37 7.8 UTVÄRDERINGSMETODER ......................................................................................... 38

8 Genomförandebeskrivning............................................................................................ 39 8.1 METOD...................................................................................................................... 39 8.2 MOTIVERING AV VERKTYG........................................................................................ 39 8.3 UTVECKLINGSMODELL.............................................................................................. 39 8.4 GRÄNSSNITTSDESIGN & VISUALISERING................................................................... 41 8.5 SYSTEMDESIGN ......................................................................................................... 42 8.6 MJUKVARUUTVECKLING ........................................................................................... 45 8.7 KOMMUNIKATION ..................................................................................................... 47 8.8 TESTKÖRNINGAR....................................................................................................... 48

9 Resultat............................................................................................................................ 53 9.1 BEGRÄNSNINGAR OCH FRAMTIDA ARBETE ................................................................ 54

10 Slutsats......................................................................................................................... 55 11 Tack ............................................................................................................................. 57

viii

12 Litteraturreferenser ................................................................................................... 58 APPENDIX A – INSTALLATION AV JAVA 3D ........................................................60 APPENDIX B – INSTALLATION AV FSA-SERVER ................................................61 INDEX........................................................................................................................62

ix

Figurförteckning Figur 2-1 Gjutning av metall från råmaterial............................................................................ 4 Figur 2-2 Efterbehandling av metallen...................................................................................... 5 Figur 2-3 Valsämnet introduceras mellan valsarna .................................................................. 5 Figur 3-1 Flatness System.......................................................................................................... 8 Figur 3-2 Schematiskt diagram över FSA arkitekturen i Stressometer ..................................... 9 Figur 3-3 Hello Universe Java 3D-applet ............................................................................... 13 Figur 3-4 Sensor Fusion inom robotiken. Två kameror används för att mer precist avgöra ett objekts position......................................................................................................................... 15 Figur 4-1 Schematisk bild av ett Stressometersystem .............................................................. 17 Figur 4-2 Givarnas arrangemang i mätrullen ......................................................................... 18 Figur 4-3 Givarnas funktion .................................................................................................... 19 Figur 4-4 Den relativa förlängningen. Det vänstra valsämnet är frigjort från spänningar och den ojämna förlängningen kommer att resultera i bucklor. Till höger är samma valsämne skuret i sektioner och skillnader i förlängning kan ses............................................................ 19 Figur 4-5 Stressometer mätrulle .............................................................................................. 20 Figur 4-6 Skevning av arbetsvalsarna ..................................................................................... 20 Figur 4-7 Böjning av arbetsvalsarna ....................................................................................... 20 Figur 4-8 Skiftning av stödvalsarna......................................................................................... 21 Figur 4-9 Princip för funktioner för planhetsreglering. .......................................................... 21 Figur 4-10Utvärderingsfunktion för aktuatorer ...................................................................... 22 Figur 4-11 Planhetsfel ............................................................................................................. 22 Figur 4-12 Distribution av punktkylning ................................................................................. 23 Figur 4-13 Princip för kylsystem ............................................................................................. 23 Figur 4-14 Exempel på en operatörsdisplay............................................................................ 24 Figur 4-15 Kommunikation för Stressometer server och HMI klient ...................................... 24 Figur 5-1 Gränssnitt för FSA-Objects ..................................................................................... 25 Figur 5-2 Användargränssnitt för operatörerna...................................................................... 26 Figur 5-3 Användargränssnitt för brokern .............................................................................. 26 Figur 8-1 Axlarna för 3D universumet .................................................................................... 41 Figur 8-2 Schematiskt diagram över programflödet................................................................ 44 Figur 8-3 Exempel på strukturen i scengrafen......................................................................... 46 Figur 8-4 Exempel på planheten.............................................................................................. 48 Figur 8-5 Exempel på temperaturen ....................................................................................... 49 Figur 8-6 Exempel på positionen ............................................................................................ 49 Figur 8-7 Exempel på tjockleken ............................................................................................ 50 Figur 8-8 Exempel på excentriciteten ...................................................................................... 50 Figur 8-9 Exempel på hur planhet, temperatur, tjocklek, position och excentricitet visas tillsammans. Reglagen till höger ställer in transparensgraden för de olika egenskaperna. ... 51

x

Förkortningar ABB Asea Brown Boveri API Application Program Interface AWT Abstract Windowing Toolkit DSP Digital Signal Processing ERP Enterprise Resource Planning FM/MC Force Measurements utvecklingsavdelning FSA Flatness Server Architecture GNU Gnu’s Not Unix GOMS Goas, Operations Methods and Selection rules GUI Graphical User Interface HMD Head Mounted Display HMI Human-Machine Interface HTML HyperText Markup Language I/O Input/Output IIT Industrial Information Technology IT Information Technology KLM Keystroke Level Model JNI Java Native Interface JPI Java Plug-In JRE Java Runtime Environment ORB Object Request Broker RMI Remote Method Invocation STU Signal Transmission Unit SDK Software Development Toolkit TCP/IP Transmission Control Protocol / Internet Protocol URL Universal Resource Locator

Kapitel 1. Inledning ___________________________________________________________________________

1

1 Inledning

För att minska tid och kostnader och för att höja kvaliteten på valsämnet finns inom stålindustrin ett behov av en mer omfattande feedback från valsprocessen. Befintliga mjuk- och hårdvarusystem för valsning är uteslutande baserade på den mätta planheten hos valsämnet, vilket leder till att variationer hos planheten är svåra att härleda. Det är med andra ord möjligt att se ett resultat men inte de underliggande faktorer som genererar det. Till följd av detta är det svårt att hitta metoder för att uppnå en bättre planhet. Genom att få feedback om andra egenskaper hos valsämnet kan samband mellan planheten och till exempel valsämnets temperatur och tjocklek ses, vilket sedan kan användas för att optimera processen, antingen direkt i valsprocessen eller vid utveckling av ett nytt planhetsreglersystem. Genom att skapa ett användargränssnitt som låter operatörer och processutvecklare se andra egenskaper såsom temperatur, sidoförskjutning och tjocklek relaterade till varandra så ges möjligheten att se hur förändringar i en av dessa variabler påverkar de övriga. Även risken för bandbrott, som kan resultera i dyrbara förseningar och förlorad produktionstid, kan möjligen minskas då det kan vara lättare att förutse dessa när operatören kan se fler varningstecken. Förhoppningen är att ett sådant gränssnitt ska ge ökad förståelse och kunskap kring processen, som sedan kan användas i ett flertal sammanhang, vare sig det är att förbättra befintliga metoder, utveckla nya metoder, ge bättre riktlinjer för styrning, eller felsökning.

1.1 Mål Målet med detta arbete är att fastställa kraven på just ett sådant användargränssnitt som använder sig av sensor fusion för att visualisera valda egenskaper hos valsämnet samt att implementera en fungerande prototyp. Detta i form av en Java-applet som kan integreras med befintlig mjuk- och hårdvara i produkten Stressometer. Java-appleten ska användas som ett verktyg vid kallvalsning av operatörer, processutvecklare, igångkörare och andra tänkbara användare för att ge en ökad insyn, förståelse och kontroll vid valsprocessen.

1.2 Egen insats Detta arbete har resulterat i:

• Fastställande av önskvärda egenskaper som bör kunna visas i användargränssnittet. • En design av gränssnittet för visning av egenskaper hos den valsade plåten i 3D. • Design av hur varje enskild egenskap skall visualiseras i gränssnittet. • En implementation av gränssnittet i form av en Java-applet som går att integrera med

befintligt system. • Kommunikation med FSA-Server via RMI, samt parser för datafiler. • Dokumentation av processen och installationsanvisningar.

Kapitel 1. Inledning ___________________________________________________________________________

2

1.3 Upplägg Detta dokument innehåller 12 kapitel med följande innehåll: I kapitel 2, bakgrund, ges en kort introduktion till ABB Force Measurement för vilka arbetet har utförts. Även en kortare beskrivning av tillämpningsområdet valsning ges. Kapitel 3, relevanta teknologier, behandlar de olika ämnesområden och verktyg som är av vikt för arbetet och bygger på olika litteraturstudier som genomförts för att erhålla de nödvändiga kunskaperna för arbetet. Kapitel 4, applikationsrealisation, beskriver mer i detalj produkten Stressometer och den miljö till vilket arbetet utförs. Kapitlet 5, problembeskrivning, behandlar mer i detalj problemställningar och förutsättningar för arbetet. I kapitel 6, mål och krav, redogörs de krav och mål som ställts upp före det praktiska arbetet påbörjades. Kapitel 7, användarcentrerad utveckling går igenom behovet av att involvera användare i utvecklingsprocessen och olika metoder och modeller beskrivs. Kapitel 8, genomförandebeskrivning, inleds med en beskrivning av det tillvägagångssätt som använts vid arbetet samt en ingående beskrivning av hur det praktiska arbetet har gått tillväga. Kapitel 9, resultat, går in på det slutgiltiga resultatet av arbetet, d.v.s. vilka mål som blivit uppfyllda. Här tas även begränsningar och framtida arbete upp. Kapitel 10, slutsats, handlar om olika reflektioner kring arbetet i efterhand. I kapitel 11, tack, nämner jag ett antal personer som har varit till min hjälp under denna prövande tid. I kapitel 12, källförteckning, listas alla källor som använts under arbetet.

1.3.1 Rådande konventioner: Genom texten finns några konventioner som kan vara bra att känna till. Källkodsexempel skrivs på formen: This is a code-snippet. med typsnittet ”Courier New” för att visa att det är källkod. Nyckelord skrivs med kursiv stil, detta är ord som viktiga. Hänvisningar till källmaterial skrivs på formen (Selman, 1994) där 1994 är tryckåret och Selman är författarens efternamn. I källförteckningen är källorna sorterade efter författarens efternamn i fallande ordning.

Kapitel 2 Bakgrund ___________________________________________________________________________

3

2 Bakgrund

I detta kapitel ges en kort introduktion till Force Measurement vid ABB och dess verksamhetsområde, vilket sedan följs av en kortare redogörelse av hur tillverkning av metallplåtar går tillväga.

2.1 ABB ABB Automation Technology Products är en del av ABB som utvecklar och levererar produkter och IT-lösningar för kraftmätning, styrning, optimering och skydd av processer inom industrin och inom krafttillämpningar. Applikationer finns över hela världen och inom alla branscher, som t.ex. papper och massa, livsmedel, läkemedel, kemi, järn och stål, verkstadsindustri och kraft. Force Measurement (FM) är en division som tillverkar produkter för mätning och styrning för ett brett område av applikationer, där man försöker förbättra kvalité och produktivitet. Detta arbete har utförts på enheten FM/MC som står för systemutveckling för produkten Stressometer. Man jobbar främst med långsiktig teknikutveckling för datorarkitektur, plattform och mät- och regleringsprinciper. Nya lösningar för Stressometer-produkten finns inom DSP-teknik, signalöverföring, processövervakning, kommunikation, modellbaserad reglering, objektorienterad programmering, mm. Lösningarna, ofta inspirerade av samarbete med högskolor, realiseras i projekt tillsammans med andra avdelningar. I dessa projekt utvärderas och används moderna utvecklingsverktyg för programmering, modellering och versionshantering. (ABB intranät, 2004) Tjänster som FM/MC tillhandahåller består bland annat utav: - Förstudier och prototyper - Test av nya teknologier och lösningar för mät- och regleringssystem - Teknikbevakning av högskolor och bolag - Säljstöd - Publikationer och kontakter med forskningsgrupper - Utbildning


4

2.2 Tillverkning av metallplåtar Vid produktion av tunna aluminium- och stålplåtar genomgår råmaterialet ett flertal förädlingssteg. Dessa kan grovt delas upp i två olika delar, smältningsfasen och valsningsfasen. Smältningsfasen innebär att metallen utvinns ur råmaterialet och gjuts till tjocka skivor av metallen (se fig. 2-1). Råmaterialet är oftast en blandning av återvunnet material och metallhaltig malm och blandning varierar beroende på vad stålet ska användas till. Ur malmen utvinns metallen i fast form och blandas sedan i en ugn med den återvunna metallen, där de båda smälts till flytande form. Metallen gjuts sedan kontinuerligt till tjocka skivor.

Figur 2-1 Gjutning av metall från råmaterial

Efter detta fortsätter de tjocka skivorna till valsningsfasen. I det första steget hettas de åter upp och går igenom en så kallad varmvalsning för att ge det dess form (se fig. 2-2). Sedan går det igenom betning där oxider etsas bort på kemisk väg. Ofta används någon form av salt- eller svavelsyra för betningen. Detta följs av kallvalsning där valsämnets tjocklek ytterligare reduceras och olika kvaliteter hos stålet kan styras, som till exempel valsämnets hårdhet. Det sista steget består av att värme- och ytbehandla valsämnet. Värmebehandlingen är den sista möjligheten att påverka prestandan hos valsämnet, och ytbehandlingen kan till exempel vara en förzinkning av materialet.


5

Figur 2-2 Efterbehandling av metallen

Detta arbete inriktar sig på kallvalsningsfasen. Detta stadium i processen reducerar tjockleken hos valsämnet och förbättrar dess struktur och hårdhet. Valsämnet introduceras mellan två arbetsvalsar som pressar ihop valsämnet, vilket gör att det blir tunnare och mer kompakt vilket ger ett hårdare material. Kallvalsningen görs ofta i så kallade stick där valsämnets tjocklek reduceras i steg, och hårdheten hos materialet successivt ökar (se fig. 2-3). Till exempel kan tjockleken reduceras från att vara 4mm till 2mm till 1mm och till sist 0.5mm. Det finns ofta olika metoder för hur man bäst uppnår en önskad tjocklek med önskad hårdhet. (AISI, 2004)

Figur 2-3 Valsämnet introduceras mellan valsarna

När valsämnet pressas mellan valsarna introduceras spänningar i valsämnet som resulterar i en ojämn och bucklig yta. För att minimera detta fel i planheten finns produkten ABB Stressometer Flatness Measurement Control System, som beskrivs under kapitel 4, Applikationsrealisation.


6

Kapitel 3 Relevanta teknologier ___________________________________________________________________________

7

3 Relevanta teknologier

Detta kapitel tar upp olika teknologier, verktyg och utvecklingsmiljöer som är nödvändiga för, eller på ett eller annat sätt berörts under arbetet. Först beskrivs olika koncept för industriella arkitekturer och sedan de programmeringsspråk som använts och sist beskrivs forskningsområdet sensor fusion.

3.1 Industriella mjuvaruarkitekturer Informationsteknologi har tagit en ledande roll i utvecklingen av många teknologiska sektorer. Produktion är inget undantag. Lösningar utvecklade inom informationsteknologi har visat sig användbara och tillämpbara i kontrollsystem för produktion. Samtidigt har förväntningarna och kraven för produktionskontroll ökat och det finns ett växande behov för nya metoder och algoritmer som går bortom de traditionella feedbackkontrollerna. (ABB intranät, 2004)

3.1.1 Industrial IT® Industrial IT är ABB’s koncept för en industriell mjukvaruarkitektur. Det är ett ramverk och koncept för att enkelt skapa applikationer och lösningar i industriella system, som skarvlöst sammankopplar och utbyter data med existerande applikationer, från applikationer för automation till ERP system. Mål med Industrial IT:

• Att erbjuda ett system som löser kundens behov, vilket kan sammanfattas med att det tillåter kunden att arbeta effektivt med stora mängder information i till exempel ett automationssystem.

• Att försäkra att mjukvaran och verktyg utvecklade för de olika funktionerna kan arbeta tillsammans som ett enhetligt och integrerat system

• Att erbjuda ett system där återanvändbara lösningar kan utvecklas. Eftersom ABB gör mycket affärer genom att erbjuda kunden med lösningar, är det viktigt att dessa kan återanvändas.

• Möjliggöra utveckling av mjukvara med en låg och förutsägbar kostnad. I dagsläget är de flesta industriella system uppdelade i många olika fristående system, applikationer, databaser, webbservar, intranät, protokoll, användargränssnitt, navigationsmetaforer, lösenord, skärmar och tangentbord. Syftet med IIT är att kombinera dessa under samma mjukvara, verktyg, kommunikation och användargränssnitt skarvlöst, så att informationen snabbt kan hämtas och användas i realtid. Realtidssystem reagerar omedelbart på ett kommando och är nödvändiga i de fall där en dator måste reagera på ett konstant flöde av ny information. De flesta generella operativsystem är inte realtidssystem eftersom det kan ta några sekunder, eller till och med minuter innan de reagerar. En annan


8

fördel är att det blir lättare att konfigurera, installera och flytta runt dessa produkter inom ett företag och operatörer ges tillgång till erfoderlig realtidsinformation för effektiv drift av en anläggning. (ABB E-learning course, 2004)

3.1.2 Flatness Server Architecture Stressometer Flatness System tillhandahåller integration och adaption av planhetsmätning och styrning av externa sensorer och aktuatorer för att övervaka och styra ett valsverk. FSA tillåter integration av Stressometer med plant-wide arkitekturer som till exempel IIT och ett flertal andra OEM arkitekturer.

Figur 3-1 Flatness System

FSA består av två delar:

• Base Measurement System (BMS) får värden från mätrullen och skickar ut dem som en vektor av relativa krafter per zon (se fig. 3-1). Den använder sig av en array av DSP’s för att beräkna signaler från varje rad av mätzoner samtidigt.

• Flatness System (FS) använder sig av de värden BMS:en ger tillsammans med annan information om valsämnet för att skapa en planhetsvektor. Resultatet gör tillgängligt via TCP/IP. Detta data kan pushas, pullas eller hämtas cykliskt.

Olika applikationer är realiserade som olika konfigurationer av mjukvarusystemet. Varje sådan konfiguration instansierar en FSA. Denna konfiguration görs genom att sätta upp olika FSA-Objekt som till exempel kan vara av typerna; objekt för hantering av mätvärden, matematiska beräkningstjänster, datalagring, statistik, loggning, I/O drivrutiner, planhetsreglering med mera. FSA-Broker är en mellanvara av typen Object Request Broker (ORB), som överför data mellan plattformen och applikationer. Denna typ av lösning är vanlig i de flesta objektorienterade system. Dess uppgift är att aktivera och koppla ihop FSA-Objekt manuellt eller utifrån ett fördefinierat skript. FSA-Broker kan dynamiskt förändra arkitekturen vid till exempel produktförändringar eller hårdvarufel och fungerar därmed som ett dynamiskt övervaknings- och konfigurationsverktyg. Konfiguration används för att beskriva metoden att programmera hur olika FSA-Objekt i ett system kan agera tillsammans baserat på vilken typ av komponent de är. Övervakning syftar till att systemet kontinuerligt kan kontrollera att alla FSA-Objekt existerar under körning och att de arbetar normalt. Ett Stressometersystem är uppbyggt utav FSA-Objekt och varje objekt körs oberoende av de andra och flera objekt kan köras på samma eller olika processorer.


9

Figur 3-2 Schematiskt diagram över FSA arkitekturen i Stressometer

FSA-Broker består utav tre delar:

• Object Broker som hittar object på ett distribuerat nätverk och kopplar ihop dem utifrån ett script. Kopplingen görs on-line för att tillåta flexibilitet och minska tid vid konfiguration, igångkörning och dynamisk omkonfiguration vid fall av fel.

• Transaction Broker som analyserar applikationen och statusen hos objekten. Tillåter realtidsbeteenden och felsökning.

• Object Dispatcher som placerar objekt från en förvaringsplats till den rätta enheten vid uppstart och efter ett fel.

(3BSE003213R0401, 1999)


10

3.2 Java Java är ett objektorienterat programmeringsspråk utvecklat av Sun Microsystems ursprungligen designat för inbyggda system, såsom mikrovågsugnar, kylskåp och annan elektronisk utrustning. Men den ökade populariteten kring world wide web skapade en ny miljö som var lämplig för Java, och Java är nu ett väl etablerat programmeringspråk. Javas slogan, ”write once, run anywhere”, indikerar att det har utvecklats för att vara baserat kring nätverk och vara plattformsoberoende. För att förstå vad som är unikt med Java behöver vi titta lite närmare på hur det är uppbyggt. Java kan delas upp i två delar: programmeringsspråket Java och the Java Platform. Programmeringsspråket Java kan enkelt sammanfattas med ett antal nyckelord:

• Objektorienterat • Interpreterat • Distribuerat • Multitrådat • Plattformsoberoende • Dynamiskt • Säkert

Java-plattformen är en mellanlager mellan hårdvara och Java, vilket möjliggör att språket är plattformsoberoende. Genom att olika Java-plattformar används till olika operativsystem t.ex. Windows och Unix, kan samma källkod översättas till maskinkod för just det operativ-systemet. Plattformen är uppbyggd av två delar, Java Virtual Machine (JVM) och Java Application Programming Interface (Java API). Java API:n är en stor samling av färdiga mjukvarukomponenter s.k. klasser, vilka organiseras i paket. Det finns färdig kod för allt ifrån nätverkskommunikation till grafiska användargränssnitt. JVM eller Java interpreteraren är basen i Java-plattformen. Den kompilerar och interpreterar programkoden. Kompilering sker endast en gång medan interpreteringen sker varje gång koden exekveras. (Lewis et al, 1998)

3.2.1 Java-applet En Java-applet är en applikation designad för att köras över ett nätverk, där den laddas ner från en fjärrdator och exekveras i en webbläsare. Två viktiga skillnader mellan en Java-applikation och Java-applet:

• En Java-applet saknar main-metod och körs därmed under kontrollen av en webbläsare. En Java-applikation kan köras fristående där den körs inuti JVM.

• En Java-applet körs i en s.k. sandlåda, där säkerheten för fil- och nätverksaccess är mycket mer strikt, och kan generellt inte skriva och läsa från hårdisk eller ladda data från andra URL:er än den som den själv ligger på. Säkerhetspolicyn styrs av webbläsarens JVM security manager. En Java-applikation körs som vilket annat program som helst, den enda skillnaden är att den kräver JVM och att den är plattformsoberoende.

(Lewis et al, 1998)


11

3.3 HyperText Markup Language Hypertext Markup Language (HTML) är ett skriptspråk som används av alla webbläsare för att bestämma hur en webbsida skall visas. HTML består av text och taggar, där taggar är kärnan i HTML och texten är innehållet i sidan. Taggar är speciella koder som sätts runt innehåll på sidan för att ge innehållet vissa egenskaper. Exempel på en tagg kan vara

<b> Ovanstående är en bold-tagg och satt runt en text får den den att bli i fetstil. Alltså,

<b>Denna text är fetstil</b> ger texten

Denna text är fetstil. </b> är en avslutningstagg och bestämmer var taggen upphör att påverka innehållet. De flesta taggar har en avslutningstagg. För att skapa en webbsida med en Java-applet, behövs speciell HTML kod som tvingar webbläsaren att använda JPI (Java Plug-In) VM. Ett exempel på detta är t.ex:

<applet code=”MyApplet.class” width=100 height=140></applet> Detta säger åt webbläsaren att ladda appleten som har koden kompilerad till filen MyApplet.class och att den ska sätta storleken till 100 x 140 pixel. De kontrollmöjligheter som finns tillgängliga för Java-applets i HTML är de följande: <APPLET

CODEBASE = Definierar URI för appleten. OBJECT = En resurs som innehåller en serialiserad representation av appleten. ARCHIVE = I vilken .jar fil koden ligger. CODE = Namnet på den *.class fil som innehåller appletens kompilerade data. ALT = Text som skall visas om muspekaren hålls över appleten. NAME = Vilket namn Java-appleten skall ha. WIDTH = Den vertikala storleken som ska tilldelas appleten. HEIGHT = Den horisontella storleken som ska tilldelas appleten. ALIGN = Vart på sidan Java-appleten ska placeras. VSPACE = Hur stort vertikalt mellanrum det ska vara till nästa objekt på sidan. HSPACE = Hur stort horisontellt mellanrum det ska vara till nästa object på sidan.

> (Lewis et al, 1998)


12

3.4 Java 3D Java 3D är en API utvecklad av Sun Microsystems för att rendera interaktiv 3D-grafik med programmeringsspråket Java. Java 3D API är en hierarki av Java-klasser som fungerar som ett interface till tredimensionell grafik- och ljudrendering. Genom att använda högnivåkonstrukt kan programmeraren skapa och manipulera 3D-objekt. Java 3D förlitar sig på att OpenGL eller DirectX sköter den nativa renderingen, medan beskrivningen av 3D-scenen, applikationslogiken, och sceninteraktionen ligger i Javakod. OpenGL och DirectX är inte implementerade i Java och därmed kan de inte direkt anropas från Java utan anropen måste gå genom JNI (Java Native Interface). Detaljerna för rendering sköts automatiskt och stödjer parallell rendering genom användandet av trådar. (Selman, 2002)

3.4.1 Styrkor Java 3D ger möjligheten att programmera uteslutande Java. I de flesta fall utgör koden för att rendera bara en bråkdel av hela programmet. Det kan då vara bekvämt att ha all kod för användargränssnitt, logiken i programmet, interaktion och så vidare samlat i ett lätt och portabelt språk som Java. Även om Javas slagord “Write-Once-Run-Anywhere” inte riktigt håller måttet speciellt med tanke på att Java 3D är en client-side API, så är det enkelt att flytta och köra Java 3D-applikationer och Java 3D-applets på olika plattformar. Oavsett om det är Microsoft Windows 98/NT/2000/XP, Sun Solaris, LINUX eller Mac OS. Java 3D använder sig av högnivåkontrukt som gör att koden blir lättare att läsa och förstå, mer återanvändbar, och lättare och snabbare att skriva. Det finns även inbyggt stöd för olika former av hårdvara som t.ex. HMD’s och skärmprojektorer. (Barilleaux, 2001)

3.4.2 Svagheter Många av Java 3D’s fördelar går också att vändas till nackdelar. Till exempel kan en del användare med erfarenhet av OpenGL sakna den totala kontrollen över scenen och renderingen. Även om Java 3D erbjuder enkel optimering så kan en begåvad utvecklare uppnå bättre prestanda med OpenGL och nativ C-kod än med Java 3D. Javas Garbage Collector försämrar prestandan ytterligare. Men med allt snabbare hårdvara minskas betydelsen av detta problem allt mer. Ytterligare en nackdel för Java 3D är att det är en API på klienten och måste därför distribueras till alla som vill köra en Java 3D-applet. (Barilleaux, 2001)

3.4.3 Exempel Ett enkelt exempel på en Java-applet som använder sig av Java 3D ges nedan där några av de vanliga Java-metoderna visas och några Java 3D specifika metoder också visas.

import java.applet.Applet; import java.awt.BorderLayout; import java.awt.event.*; import java.awt.GraphicsConfiguration;

import com.sun.j3d.utils.applet.MainFrame; import com.sun.j3d.utils.geometry.ColorCube; import com.sun.j3d.utils.universe.*; import javax.media.j3d.*; import javax.vecmath.*;

public class HelloUniverse extends Applet {

Standard importer för en Java-applet

Java 3D specifika importer.

Deklarering av en klass och globala variabler


13

private SimpleUniverse u = null; public BranchGroup createSceneGraph() {

BranchGroup objRoot = new BranchGroup(); TransformGroup objTrans = new TransformGroup(); objTrans.setCapability(TransformGroup. ALLOW_TRANSFORM_WRITE);

objRoot.addChild(objTrans); objTrans.addChild(new ColorCube(0.4)); Transform3D yAxis = new Transform3D(); Alpha rotationAlpha = new Alpha(-1, 4000);

RotationInterpolator rotator = new RotationInterpolator(rotationAlpha, objTrans, yAxis, 0.0f, (float) Math.PI*2.0f);

BoundingSphere bounds = new BoundingSphere(new Point3d(0.0,0.0,0.0), 10.0);

rotator.setSchedulingBounds(bounds); objRoot.addChild(rotator); objRoot.compile(); return objRoot; }

public HelloUniverse() { }

public void init() { setLayout(new BorderLayout()); GraphicsConfiguration config = SimpleUniverse.getPreferredConfiguration(); Canvas3D c = new Canvas3D(config); add("Center", c); BranchGroup scene = createSceneGraph(); u = new SimpleUniverse(c); u.getViewingPlatform(). setNominalViewingTransform(); u.addBranchGraph(scene); }

public static void main(String[] args) { new MainFrame(new HelloUniverse(), 256, 256); } }// Slut på klassen

Ovanstående kod resulterar i en roterande flerfärgad kub (se fig 3-3). Exemplet illustrerar att man kan med relativt lite kod kan skapa interaktiv 3D-grafik och samtidigt arbeta utan att behöva gå ifrån sina källkodsfiler i Java. Java 3D är relativt omfattande och långt ifrån alla dess möjligheter har utnyttjats i detta arbete. De delar av Java 3D som berörts behandlas i kapitel 8, genomförandebeskrivning. (Bouvier, 1999) Figur 3-3 Hello Universe Java 3D-applet

Konstruktor

Tillåter koden att köras som en applikation

Java 3D specifik metod. Här deklareras alla 3D objekt som skall synas i appleten. Dessa läggs till i en trädstruktur som kallas scengraf.

Vanlig Java kod och Java 3D kod blandat. 3D-universumet instansieras och läggs sedan in som en vanligt objekt i appletens layout


14

3.5 Sensor fusion Sensor fusion kan översättas till givar- eller sensorsammansmältning, men här används den engelska termen för att beteckna detta forskningsområde. Sensor fusion kan ses som ett försök att efterlikna människans förmåga att kombinera olika sensorintryck i realtid. Hos människan utgör våra allmänt accepterade fem sinnen sensorerna, d.v.s. syn-, hörsel-, smak-, känsel- och luktsinnet. Genom att ta intryck från dessa sensorer och kombinera dem kan vi skapa en bättre bild av omgivningen genom mångfald i indata. Vinsten av detta kan ta två former, antingen att vi får en mer exakt bild av det vi vill studera eller att vi får ut mer information än de olika sensorerna kan ge om de hanteras separat. För att ge ett exempel så kan vi se hur människans syn fungerar i två olika avseenden:

• De som någon gång har gjort ett syntest vet att man ser skarpare om man använder båda ögonen än om man tittar med ett åt gången, d.v.s. ett mer exakt resultat erhålls.

• Genom att båda ögonen används får man ett djupseende, något som inte kan åstadkommas om inte hjärnan har två olika sensorer att ”smälta samman”.

I fallet ovan så används två likadana sensorer i ett system, men även olika typer av sensorer kan användas, vilket brukar kallas multisensor fusion. För att anknyta till människan igen så kan en jämförelse dras till hur vi uppfattar smak, genom en kombination av lukt- och smaksinnet. Detta är lätt att testa själv genom att hålla för näsan när man smakar på något, och man märker att det smakar annorlunda (mindre). Om vi ser detta som ett sensor fusion system så samlar sensorerna in mätdata som sedan skickas till hjärnan för att behandlas, och ett resultat nås. Även om sensor fusion är grundläggande för oss människor, så är det ett relativt nytt forskningsområde. Det finns olika definitioner om vad begreppet innefattar men gemensamt är att man försöker få mer värdefull information jämfört med ett vanligt system. Troligt är att området kommer att växa då ökande beräkningshastighet i datasystem och framgångar inom sensorteknologin gör att det allt mer möjligt att efterlikna människans inneboende förmåga att kombinera flera intryckskällor. Sensor fusion kan klassas olika beroende på var i hierarkin i ett system sammansmältningen sker, och klasserna varierar beroende på litteratur. För att illustrera kan tre olika klasser förklaras:

• Data fusion. Den lägsta nivån är då ren sensordata sammansmälts. • Feature fusion. Genom att “dra ur” vissa egenskaper från viss data kan vissa problem

göras mindre komplexa. Exempel på detta är att beräkna ett medelvärde eller att använda kantigenkänning. Oftast smälts liknande egenskaper ihop.

• Information fusion. Som namnet antyder så handlar information fusion om att smälta samman information, ofta för att fatta ett logiskt beslut av något slag. (Biel, 2002)

Data Fusion

Feature fusion

Information fusion

Akustisk sensor

Seismisk sensor Kamera IR-kamera Databas

Data fusion

Feature fusion

Information fusion

Logisk behandling

Detektion

Egenskaper utläses


15

3.5.1 Tillämpningsområden De tillämpningsområden som har funnits och finns i dag kan i stort delas upp i tre tillämpningsområden: Militär – Har varit en drivande kraft bakom sensor fusion. T.ex. har IR-sensorer tillsammans med högupplösande kameror använts för att avslöja kamouflerade mål. Medicin – Inom medicin används ofta någon form av sammansmältning för olika bildanalyser. T.ex. datoriserad tomografi (CT) kombinerat med positronstrålningstomografi (PET) för att lättare/säkrare fastställa sjukdom. Dessa är ofta en lång serie av högupplösta bilder vilket kräver kraftiga arbetsstationer för att sammansmälta. Industri – Tillämpningarna har ökat kraftigt inom industrin på senare tid, mycket på grund av snabbare datorer och bättre sensorer. Mest utbrett är sensor fusion troligen inom robotiken och ett typiskt exempel på detta är att två kameror används för att med större noggrannhet fastställa ett objekts position (se fig. 3-4). (Hardin, 2004)

Figur 3-4 Sensor Fusion inom robotiken. Två kameror används för att mer precist avgöra ett objekts position

Ytterligare ett exempel på tillämpningsområde skulle kunna vara i en brandvarnare. Genom att kombinera flera sensorer, som mäter inte bara rökpartiklar, utan även värme och syrehalt osv., så kan man skapa en känsligare och mer tillförlitlig brandvarnare. Detta skulle kunna hjälpa till att rädda liv och förhindra onödiga larm som kan kosta pengar i utryckningar eller vattenskador om sprinklers används. Ett annat intressant fall där sensor fusion använts är inom astronomin. Problemet bestod i att en komet befann sig så långt från någon stjärna att den mängd ljus som träffade den var så litet att kometen inte kunde urskönjas. Genom att kombinera givare som mätte bland annat röntgen- och gammastrålning och sedan behandlade detta data kunde man skapa en överraskande precis bild utav kometen. I detta arbete kommer sensor fusion att användas på ett mindre direkt sätt. De olika mätvärdena från de olika givarna kommer inte direkt kombineras i någon form av logik i mjukvaran, utan istället kombineras som grafiska objekt i användargränssnittet. Det överlåts sedan till användaren att själv kan tolka sambanden dem emellan. Eftersom denna enkla metod används finns det inget behov att gå igenom de olika metoder som finns för att sätta upp ett system som använder sig av sensor fusion. Det kan dock nämnas att finns olika metoder beroende på kraven för prestanda/precision/kostnad/sensorer och så vidare. Senare kan någon annan form av sensor fusion komma att användas för att beräkna excentriciteter och tjockleksprofilen hos valsämnet, men detta är problem som inte kommer att beröras i detta arbete.


16

Kapitel 4 Applikationsrealisation ___________________________________________________________________________

17

4 Applikationsrealisation

I detta kapitel beskrivs mer ingående produkten Stressometer. Först ges en schematisk bild av hela systemet och sedan beskrivs hårdvaran och efter det mjukvaran.

4.1 Stressometer Flatness Measurement and Control System I dagens stål- och aluminiumindustri ställs höga krav på kvalitet och vid produktion av tunna plåtar är en bra planhet den viktigaste egenskapen. ABB Stressometer Flatness Measurement and Control System är en produkt utvecklad på ABB Automation Products (se fig. 4-1). Systemet används inom stål- och aluminiumindustrin för kallvalsning av metallplåtar. Stressometern mäter spänningen i valsämnet och kan med den informationen utföra beräkningar och justera valsverket för att uppnå optimal planhet.

Figur 4-1 Schematisk bild av ett Stressometersystem

Systemet kan delas upp i ett antal delar: • En mätrulle som mäter spänningar i valsämnet och skickar data till elektronik där det

behandlas. • En server som tar emot data från mätrullen via TCP/IP. Servern är indelad i tre delar:

o En beräkningsdel som utför olika beräkningar på data skickat från elektroniken.

o Mjukvaran broker där man konfigurerar arkitekturen i systemet. Brokern är dynamisk och tillåter därmed förändring av objekten i realtid. Konfigurationen görs genom att starta olika moduler och sätta upp kommunikation mellan dem.

o En server som tillåter klienter att ansluta med en webbläsare.

Mätrulle Valsämne

Spole

Valsverk

Mätningar

Styrning


18

• En klient som ansluter till webbservern. Detta är en vanlig PC med klientmjukvara installerad. Anslutningen sker genom att starta HMI:et (Human-Machine Interface) i en webbläsare. Användaren kan via HMI:et få information om valsprocessen och eventuellt även styra den. (3BSE003213R0401, 1999)

4.2 Mätrullen Mätrullen är tillverkad av solitt stål med kraftmätande givare inbyggda runt omkretsen av rullen och är täckta med stålringar. Givarna är uppdelade i mätzoner, som är fördelade längs mätrullens längd. Det finns fyra givare i varje mätzon, där givarna är förskjuta med 90o (se fig. 4-2).

Figur 4-2 Givarnas arrangemang i mätrullen

Detta gör det möjligt att mäta hur spänningen är fördelad över valsämnet fyra gånger per rotation. Eftersom givarna i de olika zonerna ligger vinkelrät mot rullriktningen så kommer mätningarna göras simultant över hela plåten. Eftersom mätrullen roterar under mätningarna så används en Signal Transmission Unit (STU) för att mata rullen med elektricitet och för att sända kraftmätningssignalerna från rullen. (3BSE003213R0401, 1999)

4.2.1 Mätprincip: Mätrullen använder sig av magnetoelastiska givare. Det innebär att de magnetiska egenskaperna hos stålkärnan kommer att påverkas om det utsätts för mekanisk kraft. Varje givare har ett hål genom vilket två spolar, en primär och en sekundär spole, är lindande. Den primära spolen hos alla givare är kopplad i serie i två loopar för att skapa en förhöjningsloop 1 och förhöjningsloop 2, som är försedd med en matningsspänning på 2kHz och 1.2A. Fyra givare (A, B, C, D) placerade med räta vinklar i förhållande till varandra, är kopplade i serie på den sekundära sidan för att forma en mätzon (se fig 4-3). (3BSE003213R0401, 1999)


19

Figur 4-3 Givarnas funktion

Mätprincipen är baserad på det relativa värdet. När ingen kraft är lastas på någon av givarna, induceras inte någon utspänning på den sekundära sidan. Om kraft appliceras på en givare induceras en spänning proportionell mot kraften. (3BSE003213R0401, 1999)

4.3 Mätt planhet Det inkommande valsämnet från valsverket har en profil. Denna profil är en variation av tjockleken hos valsämnet längs med dess bredd. Generellt har valsämnets profil en oregelbunden form efter varmvalsningen. Om valsgapet i valsverket inte är exakt matchat mot det inkommande valsämnets profil kommer valsämnets förlängning att bli ojämn. Skillnaden i längden kan tydligt ses om valsämnet skärs upp i separata sektioner.

Figur 4-4 Den relativa förlängningen. Det vänstra valsämnet är frigjort från spänningar och den ojämna

förlängningen kommer att resultera i bucklor. Till höger är samma valsämne skuret i sektioner och skillnader i förlängning kan ses

Denna ojämna förlängning kommer på valsämnet att synas som en dålig planhet. Detta resulterar i att valsämnet blir synligt bucklig eller så ligger det latent om valsämnet är tillräckligt stelt nog för att hålla spänningarna i valsämnet utan att skapa synliga bucklor. Variationen i den relativa förlängningen, definierad som ∆L/L, är ett mått på den faktiska planheten hos valsämnet (se fig. 4-4). För att mäta planhetsavvikelser körs valsämnet över mätrullen mellan två valsgap eller mellan valsgapet och spolen. Spänningen i valsämnet orsakar en radiell kraft på mätrullen som kommer att variera utmed mätrullens längd, orsakad av ojämn utsträckning av valsämnet. På detta sätt mäts fördelningen av spänningen utmed mätrullen. (se fig. 4-5)


20

Figur 4-5 Stressometer mätrulle

Den mätta radiella kraften på varje mätzon konverteras till spänningar hos valsämnet och avvikelser hos individuella zoner från ett medelvärde på spänningen beräknas. Dessa värden representerar den mätta planheten. (3BSE003213R0401, 1999)

4.4 Aktuatorer Det mätta planhetsfelet beskrivet tidigare används för att styra valsverkets aktuatorer, vilket ger en förändring av valsgapet. De möjligheter som finns för att reglera valsverket för att få bättre planhet är de följande: Skevning För att påverka ett generellt fel på ena sidan av valsämnet kan skevning används för att minimera felet (se fig. 4-6). Valsarna lutas för att lägga ett större tryck på den ena sidan av valsämnet. Evalueringsfunktionen av denna operation kan ses som den blå och röda linjen i fig. 4-10.

Figur 4-6 Skevning av arbetsvalsarna

Böjning För att påverka ett generellt fel på båda sidorna av valsämnet kan böjning användas för att minimera felet. Valarna utsätts för tryck i ändarna vilket gör att valsen böjs en aning och lägger ett större tryck på kanterna av valsämnet (se fig 4-7). Detta kan göras både på arbetsvalsarna och stödvalsarna vilket ger olika effekter. Evalueringsfunktionen av denna operation kan ses som den röda linjen i fig. 4-10.

Figur 4-7 Böjning av arbetsvalsarna


21

Skiftning Genom att förskjuta stödvalsarna längs med längden på arbetsvalsarna kan ytterligare ett generellt planhetsfel påverkas, och det är enkelt att lägga ett mindre tryck på ena sidan av valsämnets kant (se fig. 4-8).

Figur 4-8 Skiftning av stödvalsarna

Planhetsfelet beskrivs som spänningsvariationer över valsämnets bredd och det finns lika många värden på spänningen som det finns mätzoner. Metoden som används i Stressometer systemet för beräkning av hur aktuatorerna ska korrigeras utifrån planhetsfelet är en modell av valsverkets inverkan bestående evalueringsfunktioner och en minstakvadratminimering av planhetsfelet till denna modell. Valsarna korrigeras sedan för att nå det minimerade planhetsfelet. En schematisk bild av hur detta går till kan ses i fig. 4-9. (3BSE003213R0401, 1999)

Figur 4-9 Princip för funktioner för planhetsreglering.

4.4.1 Exempel För att illustrera kan vi föreställa oss ett enkelt valsverk som har endast tre aktuatorer (två för skevning samt en för böjning) och en Stressometer med sju mätzoner. Aktuatorerna beskrivs av en evalueringsfunktion given av matris A, där varje kolumn ger effekten av en akutator (se fig. 4-10).

⎥⎥⎥⎥⎥⎥⎥⎥⎥

⎦

⎤

⎢⎢⎢⎢⎢⎢⎢⎢⎢

⎣

⎡

=

103740152235201330251025301320352215413710

A

Stödvals

Stödvals

Arbetsvals

Arbetsvals


22

1 2 3 4 5 6 710

15

20

25

30

35

40

45

Zones

Act

uato

r effe

ct

Figur 4-10Utvärderingsfunktion för aktuatorer

Problemet att lösa är en linjär kombination av kolumnerna av matrisen A måste ge som resultat en vector b, där b är planhetsfelet som ska korrigeras. Till exempel låt:

b=[25 25 20 15 10 15 30]T1

Planhetsfelet kommer då grafiskt se ut så här:

1 2 3 4 5 6 70

5

10

15

20

25

30

35

40

45

50

Zones

Flat

ness

erro

r

Figur 4-11 Planhetsfel

Att två godtyckliga vektorer v och w är ortogonala innebär att den inre produkten av (v• w) är noll. Den inre produkten är definierad som vTw, så ortogonal innebär vTw=0. Låt r = b –Ax vara residualen (felet mellan lösningen Ax och vektorn b). Den minsta residualen är den ortogonala projektionen av r på Ax, vilken enligt definitionen är:

)(0 AxbArA TT −== (1) Genom att omarrangera termerna får vi:

))( 1 bAbAAAx PLTT == − (2) där APL = (ATA)-1 AT kallas den vänstra pseudoinversmatrisen. Lösning av den normala ekvationen ovan ger resultatet x = [0.1322 0.4938 0.2315]T, vilket representerar den korrektion som måste göras för att minska planhetsfelet. Eftersom pseudoinversen beräknar ett minimum så existerar det en ickenollresidual för felet beräknad till: r=b-Ax= [-4.083 4.0521 3.9927 0.97052 -5.0146 -3.9626 4.1265] 1 T är en transponatoperation


23

4.4.2 Kylning Kylning behövs vid valsningen för att processen inte ska överhettas men kan även användas för att korrigera planheten.. Med tidigare nämnda metoder är det bara möjligt att påverka generella planhetsfel medan isolerade planhetsfel är svåra att komma åt. Termisk planhetsreglering är en planhetsreglering där termisk expansion och krympning av arbetsvalsen används för att ändra konturen (diametern) vid olika punkter på arbetsvalsen genom att applicera ett kylmedel på valsen (se fig. 4-12). För att termisk planhetsreglering ska kunna nyttjas krävs en viss temperaturskillnad mellan kylmedlet och arbetsvalsarna.

Figur 4-12 Distribution av punktkylning

Normalt sett kan punktkylningssystem delas in i tre olika typer beroende på vilken typ av kyl system som finns i valsverket.

• On-off punktkylning (se fig. 4-13). • Multistep punktkylning (se fig. 4-13). • Pulserad kylning.

Figur 4-13 Princip för kylsystem

Feedback för den punktvisa kylningen kan fås via mätrullen. (3BSE003213R0401, 1999)

Arbetsvals

Kyldosor


24

4.5 HMI Under valsningsprocessen kommunicerar operatören med Stressometersystemet för att övervaka och styra valsningen. Information om bland annat planhet och position skickas från FSA-servern via HMI-Bussen (TCP/IP) till klienten för att presenteras på monitorn enligt fig. 14.4.

Figur 4-14 Exempel på en operatörsdisplay

Implementationen av HMI:et använder sig av en klient/server arkitektur där RMI eller sockets används kombinerat med webbläsaren för att koppla upp klienten mot servern. Ett schematiskt diagram över mjukvaruarkitekturen kan ses i fig. 4-15. (3BSE003213R0401, 1999)

Figur 4-15 Kommunikation för Stressometer server och HMI klient

HMI:et har följande funktioner: • Planhetsmätning • Automatisk planhetsreglering • Lokal- och fjärrtillgång till data • Universella kommunikationsprotokoll • Kvalitet och optimala mål

Kapitel 5 Problembeskrivning ___________________________________________________________________________

25

5 Problembeskrivning

I detta kapitel beskrivs mer i detalj utmaningar i arbetet. Först måste problemet identifieras för att det ska kunna lösas. Kapitlet börjar med olika sätt att se på problemet och avslutas med hur problembilden ser ut för detta arbete.

5.1 Synsätt på problemet För att illustrera vad som menas med olika synsätt på problemet utgår vi från den tillsynes enkla frågan ”vad gör en bil för något”? De flesta personer har en uppfattning av vad det är en bil gör, men dessa kan skilja sig avsevärt åt beroende på intresseområden och kunskaper. Till exempel skulle en vanlig förare utan några kunskaper om bilens konstruktion troligtvis beskriva bilens funktion som att den förflyttar honom från punkt a till b genom att han trycker på gasen och styr med ratten. En motortekniker däremot skulle ge en mer invecklad förklaring om hur motorn förbränner bränsle för att sätta olika mekaniska delar i rörelse som i slutändan leder till att bilen går att köra. Men för att kunna konstruera en bil så krävs förståelse och kunskaper från alla dessa aspekter på vad det är en bil gör för något. Genom att se problemet från olika vinklar och förstå problemet i ett större sammanhang kan en bättre lösning nås. Vid produktion av mjukvara så gör sig detta gällande redan vid designfasen då man vill försöka fånga mjukvarans funktion i någon form av diagram. Ett sätt att göra detta är att försöka samla all funktionalitet i ett diagram, men det är sällan lyckat. Om vi nu ser hela valsverket som ett system, finns det olika angreppspunkter på vad det är systemet gör. Dessa kan grovt ses ifrån tre olika perspektiv; strukturvy, processvy och arkitekturvy (eng. structure view, process view och architecture view). För att kunna konstruera en bra lösning krävs en viss förståelse för alla dessa.

5.1.1 Strukturvy Strukturvy kan ses som en abstrakt design av systemet, hur det fungerar och i vilket tillstånd det befinner sig. Det kan röra sig om hur de olika aktuatorerna är inställda, till exempel hur valsarna står och i vilket läge kylningen är i. Informationen av det här slaget är av intresse vid driftsskötsel och felsökning. I det här arbetet så krävs förståelse för hur detta fungerar för att kunna implementera ett fungerande HMI även om HMI:et inte i någon större utsträckning kommer att presentera information av den typen, åtminstone inte i detta skede. Men implementationen måste vara generell nog för att Figur 5-1 Gränssnitt för FSA-Objects


26

stödja att ytterligare funktionalitet ska kunna åskådliggöras, som t.ex. ställdonens positioner och kyldosor.

5.1.2 Processvy Processvy kan ses som resultatet av systemets påverkan. Här läggs ingen vikt på vad systemet gör, eller hur det är uppbyggt utan bara dess inverkan på valsämnet. Det är detta synsätt på problemet som HMI:et främst ska återge. Genom att visa hur systemet påverkar olika egenskaper hos valsämnet kan en operatör styra valsprocessen för att förändra resultatet av systemet påverkan. Det är främst detta operatören är intresserad av. Många av fabrikerna experimenterar själva för att optimera sin valsning. Det här arbetet är främst inriktat på att återge den här delen av systemet, ett verktyg som kan fungera som ett ”laboratorium” att arbeta i. ABB utvecklar normalt verktyg som de kan använda själv i första hand och prioritet faller bort för verktyg som operatörerna kan ha nytta av.

5.1.3 Arkitekturvy Arkitekturvy kan ses som hur själva mjukvaru-systemet är uppbyggt. Vilka objekt som finns och hur de är sammankopplade. För att konfigurera och bygga upp ett system finns mjukvaran Broker där det är möjligt att lägga till och ta bort olika moduler och sedan köra och stoppa dem. Förståelse för denna del av problemet krävs för att kunna kommunicera med det övriga systemet, t.ex. för datainhämtning.

5.2 Problembild Utifrån ovan givna angreppspunkter är arbetets främstett gränssnitt som kan visualisera sensor fusion datagivare och ”smälta samman” dem grafiskt, och detta sgöra detta kan de olika datamängderna korreleras. valsämnet och HMI:et ska kunna visa dessa på ett lättkompensera för mina bristande kunskaper inom valsnska en användarcentrerad utvecklingsmodell användaen Java-applet som ska gå att köra i en webbläsarmjukvarusystem. Integrationen omfattar även att det givare som finns i dagsläget. Koden ska vara generekan göras. Java-appletens främsta uppgift är att visbesitter, och göra det möjligt för användaren att korfastställdes vilka av dessa egenskaper som var viktigoch position som mäts av Stressometer i sitt nuvarand

Figur 5-2 Användargränssnitt för operatörerna

F
igur 5-3 Användargränssnitt för Brokern
a uppgift att utforma och implementera . Det vill säga läsa in data från olika ka göras med låg responstid. Genom att Varje givare mäter en egenskap hos

förståeligt och överskådligt sätt. För att ing och garantera ett önskat slutresultat s. Gränssnittet ska implementeras som e och kunna integreras med befintligt ska vara möjligt att läsa in data för de ll så att förändringar och tillägg enkelt a de olika egenskaper som valsämnet relera dessa. I samtal med handledare a att ge feedback för. Förutom planhet e tillstånd, är egenskaperna temperatur,


27

excentricitet, kylning och tjocklek av intresse. Dessa egenskaper mäts inte idag2, utan man hoppas på att inkorporera dem i hård- och mjukvaran i framtiden, och då skall HMI:et stödja visualisering av dessa. Nedan följer en kort redogörelse av de olika egenskaperna samt dess nuvarande roll i valsprocessen.

5.2.1 Planhet Planheten mäts med produkten Stressometer som beskrivs närmare i kapitel 4. Detta är den viktigaste egenskapen hos valsämnet och det är den som produkten Stressometer försöker optimera.

5.2.2 Temperatur I dagsläget tas ingen hänsyn till temperaturen hos valsämnet eller valsarna vid kallvalsningen. Tidigare examensarbeten har utförts på ABB rörande temperaturmätning, där olika metoder för mätning av temperaturen hos både valsämnet och valsarna nämns. Bland dessa kan nämnas olika pyrometrar och grey-box modellering för att beräkna hur temperaturen sprider sig inåt i metallen från den mätta punkten (Spänner, 2002). Detta kommer troligen att omsättas i praktiken då temperaturen har en viktig roll inom valsningen.

5.2.3 Tjocklek I nuläget mäts tjockleken i valsverket och valsverket korrigeras automatiskt för att uppnå en jämnare tjocklek utan användarens översyn. Tjockleksmätning är inte en del av Stressometersystemet och givaren kan ofta komma från en annan tillverkare, men Stressometersystemet kan ändå ta del av mätvärdet via nätverk. ABB har en egen tjockleksmätare, Millmate Thickness Gauging System, som använder sig av pulsed eddy current för att mäta tjockleken (se fig. 5-4). Fördelen med denna tjockleksmätare är att den är icke berörande och utsätts därför inte för slitage. Den använder sig inte heller av laser eller radioaktiv strålning vilket medför att den inte känslig för partiklar, vatten eller smutsiga ytor. Nackdelen är att den inte fungerar på metaller som är magnetiska. Tjockleken mäts på en punkt i sidan av bandet, men tjockleken varierar något över hela valsämnets bredd, och information om dessa tjockleksvariationer kan vara värdefull för att få en bättre bild av valsprocessen. Teoretiskt sett är det möjligt att mäta tjockleken över hela bandet men i praktiken är det olämpligt. Istället kommer troligen en profil för tjockleken utmed tvärsnittet på valsämnet att beräknas utifrån den givna punkten, antagligen med hjälp av planheten och/eller temperaturen på valsämnet. (ABB, 2004)

2 Tjockleken mäts men används inte i denna del av valsprocessen

Figur 5-4 Tjockleksgivare med Pulsed Eddy Current


28

5.2.4 Excentricitet Excentricitet innebär att en spänning introducerats i bandet i samband med hasplingen. Detta beror på att kraften som plåten utsätts för när den rullas upp på spolen är konstant, medan radien förändras på så sätt att den blir större vid en viss punkt vid varje varv (se fig. 5-5 a). Följden blir att det bildas spänningar i plåten med ett avstånd av spolens omkrets, och eftersom omkretsen ökar så ökar även avståndet mellan dessa spänningar. Spänningarna är även mer koncentrerade i början, det vill säga att de är kraftigare men mindre utspridda, men allt eftersom omkretsen ökar blir de svagare men mer utbredda (se fig. 5-5 b).

Figur 5-5 En spänning introduceras i valsämnet då den hasplas. Avståndet mellan dessa och dess styrka varierar alltmed att omkretsen på spolen växer.

Igenkänning eller prediktion av spänningar till följd av excentricitet finns ännu inte implementerat i någon form av hård- eller mjukvara. Storlek och position på dessa spänningar kommer troligen att beräknas matematiskt med hjälp av bland annat planhetsdata och temperaturdata.

5.2.5 Position Positionen mäter bandets sidoförskjutning i valsverket. Detta finns tillgängligt i nuvarande hårdvara, och finns som ett objekt i FSA-servern.

5.2.6 Punktvis kylning Punktvis kylning som beskrivs under kapitel 4, applikationsrealisation finns installerat i olika former hos en del valsverk. Ingen direkt feedback ges från detta förutom vilka kyldosor som är aktiva, även om ett indirekt resultat av kylningen kan ses på den mätta planheten hos Stressometer. .

a b

Kapitel 6 Krav & Mål ___________________________________________________________________________

29

6 Krav & Mål

Titeln på detta arbete ger bara en ledtråd till vilka krav som ställs på arbetet. Innan något arbete kan utföras måste kraven på arbetet fastställas. Detta görs under detta kapitel. Krav och mål är mycket nära förknippade med de problemställningar som sätts upp under Kapitel 5, problembeskrivning. Men innan kraven fastställs motiveras behovet av detta arbete och det ges en förklaring till hur det är möjligt att verifiera att kraven verkligen har uppfyllts.

6.1 Behov Valsning av stål har existerat redan sedan 1800-talets första hälft. Förfarandet är fortfarande detsamma men teknikens framsteg har förfinat processen genom tiden, och så är fortfarande fallet. Konkurrensen på marknaden är hård och kraven från industrin ökar. En viktig del inom denna process är kallvalsningen där stålet ges dess slutgiltiga egenskaper som hårdhet, tjocklek och planhet. För att vara slagkraftig på marknaden krävs ett väl fungerande system som både är tids- och kostnadseffektivt och ger en bra slutprodukt. Ett valsverk som kan producera stål med bättre kvalitet med samma kostnader och tidskonsumtion är självklart ett bättre val. Samtidigt pressas gränserna för vad man kan göra med de tillgängliga kunskaperna allt längre. Genom att skapa sig en mer fullständig bild av valsprocessen kan nya kunskaper tillgodogöras och omsättas till nya innovationer för att ytterligare förbättra och förfina processen. Detta arbete är ännu ett steg för att möjliggöra ytterligare utveckling inom valsningen.

6.2 Verifikation Genom att sätta upp kvantifierbara mål är det möjligt att på ett enkelt och säkert sätt att i efterhand se tillbaka på de uppsatta målen och avgöra vilka som har blivit uppfyllda. I följande kravspecifikation som satts upp för arbetet är alla målen formulerade på ett sådant sätt att det enkelt går att avgöra om målet är uppfyllt eller inte. På så vis undviks problem som skulle kunna följa om ett av målen var till exempel ”Gör ett lättanvänt användargränssnitt”. Här skulle det vara svårt att bedöma grad av uppfyllnad av flera anledningar. Vad avses med lättanvänt, lättanvänt för vem, och vem avgör om det är lättanvänt? Detta skulle i slutändan göra att det i efterhand skulle det vara svårt att göra en rättvis bedömning av vad som uppnåtts med arbetet. Förutom detta har även en prioritet satts för varje krav som avser att ge en indikation på hur viktigt just det målet är för arbetet. Prioriteten illustreras med en siffra mellan ett och tre där ett står för högsta prioritet och tre för den lägsta prioriteten.

Kapitel 6 Krav & Mål ___________________________________________________________________________

30

6.3 Mål Utifrån de problemställningar som satts upp och diskussioner med min handledare har följande mål har satts upp för arbetet:

Mål • Implementera ett användargränssnitt som kan visualisera utvalda

egenskaper som mäts eller beräknas. Egenskaper som är av intresse är: o Planhet – Om det är ojämn spänning i bandet blir det buckligt.

Stressometer i sitt nuvarande tillstånd fokuserar enbart på detta. o Temperatur – En egenskap som inte mäts än, men som är av

intresse för bl.a. processutvecklare. o Kylning – Kylning kan användas för att reglera planheten och det

kan vara önskvärt att se hur mycket valsen och valsämnet har påverkats av kylningen.

o Tjocklek – Om bandet är jämntjockt. Idealiskt skall bandet vara lika tjockt överallt.

o Position – När bandet hasplas upp på spolen glider det i sidled. o Excentricitet – När bandet hasplas upp bildas det mer spänning i

bandet med vissa intervall. Detta beror på att bandet hasplas med en konstant kraft men radien på spolen förändras.

• Tillägget ska göras i form av en Java-applet, som är kompatibel med befintligt HMI. Användarna ska kunna använda appleten utan tidigare erfarenheter.

• En eller flera egenskaper ska kunna visas samtidigt då det är av vikt att kunna korrelera egenskaper med varandra.

• Sätta upp kommunikation med befintlig FSA-server och läsa in värden och visualisera dem med låg responstid.

• Koden skall vara generell då mjukvaran måste kunna anpassas för olika typer av valsverk och man måste kunna lägga till ytterligare funktionalitet då sådan tillkommer utan att skriva om större delar av koden.

• Testa systemet i en verklig applikation. • Ev. modifiera befintligt kod i befintligt system, ifall det krävs eller ifall

förbättringar kan göras.

Prioritet

1 1 3 2 2 3 1 1 2 1 3 3

Kapitel 7 Användarcentrerad utveckling ___________________________________________________________________________

31

7 Användarcentrerad utveckling

I detta kapitel behandlas olika typer av användarcentrerad utveckling. Först ges en introduktion till ämnet, där olika begrepp och principer förklaras, och sedan följer en redogörelse över olika modeller för utveckling.

7.1 Bakgrund För att ett datorsystem ska kunna användas effektivt måste ett antal kriterier uppfyllas. Förutom att systemet skall fungera (det vill säga inte krascha) måste det även stödja funktioner som behövs för att utföra uppgiften som det var designat för att göra. Användarna måste veta hur man använder systemet, och användarna måste kunna utföra sitt arbete effektivt. Vid utveckling av datorsystem har det visat sig vara svårt att uppnå dessa kriterier, och det grundar sig ofta i att det är svårt att försäkra sig om att slutprodukten blir lämplig för vad den var designad att användas för. Ett krav för att lyckas med detta är att ha kunskap om vad användaren behöver och vad användaren vill ha. Om man har kännedom om detta kan det optimala systemet utvecklas för den specifika uppgiften och den specifika användaren. Om användbarhet inte beaktas kan produkten bli svår att använda, och köps därför inte och företaget förlorar pengar på försäljning. Ett annat scenario, om ett företag köper in ett program till sina anställda, och det är svårt att använda så kommer det kosta företaget pengar i förlorad arbetstid. Eller om det inte klarar att utföra vissa saker. (Faulkner, 2000) Själv kan jag se andra scenarier där användbarheten är av stor vikt, t.ex. i kritiska miljöer där ett fel kan få ödesdigra konsekvenser. T.ex. vid utveckling av livsuppehållande system eller produktionssystem där fel kan orsaka dyrbara produktionsstopp.

7.1.1 Behov Bengt Göransson et al. gjorde en undersökning av hur systemutvecklingsarbete går till i Sverige, i syfte att se hur organisationer hanterar gränssnittsdesignen. Studien visar att systemutvecklarna oftast ser sitt arbete som problemlösning. Detta leder till att stor tid läggs på att finna programmerings- och tekniklösningar, medan användbarheten får låg prioritet. Vidare försöker man att låta en funktion vara genomgående genom användargränssitt, informationslager samt databas, med följd att design av användargränssnitt blir lidande. (Göransson et al, 2000) Om man generaliserar så kan det finnas två problem med mjukvara, antingen fungerar den inte, eller så fungerar den inte för användaren. Effekten av problemen är densamma men, men enligt studien läggs mycket större vikt på att lösa det första problemet. Detta kan grunda sig i att specifikationer ofta kräver att ”det ska vara möjligt att…” men kravet kan uppfyllas även om det är i stort sett omöjligt för användaren att åstadkomma det. En bidragande orsak till behovet av användbar mjukvara är att användandet har gått från experter till att komma in i gemene mans hem och vardag. (Delta Method, 2004)


32

7.1.2 Historia Tanken på att kombinera ergonomi och datorer introducerades redan 1959 av Brian Shackel. Efter det hände inte mycket och det var troligen inte före 1971 uttrycket användbarhet användes av R.B Miller, där det baserades på om det var lätt att använda. Shackel gav 1986 en formell definition som var baserad på effektivitet, lärbarhet, flexibilitet och attityd. (Faulkner, 2000) Sedan dess har det uppkommit en hel del olika läror kring användbarhet och utvecklingsmodeller, några av dessa finns beskriva under kapitel 7.5.

7.2 Användbarhet Ett viktigt begrepp vid användarcentrerad utveckling är användbarhet (eng. usability). Det finns många olika definitioner på ordet men det mest använda är en ISO standard (ISO 9241-11 Guidance on usability) som definierar användbarhet som:

“System usability comprises the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”

Detta kan översättas till ungefär; Användbarhet innefattar till vilken utsträckning en produkt kan användas av specificerade användare för att uppnå specificerade mål, med effektivitet, produktivitet och acceptans i ett specificerat sammanhang. För att ytterligare klargöra förklarar man även de olika termerna.

• Effektivitet: Mått på den korrekthet och fullständighet som användaren uppnår uppsatta mål. Ingen hänsyn ges till hur lätt eller hur lång tid det tar.

• Produktivitet: Mått på de resurser som används i relation till korrektheten och fullständigheten som användaren uppnår uppsatta mål.

• Acceptans: Mått på avsaknaden av obekvämlighet, och positiv attityd gentemot användandet av systemet.

• Sammanhang: Användarna, uppgifterna, utrustning, (hårdvara, mjukvara och material), och den fysiska och sociala miljön som produkten används i.

• Mål: Ett medvetet resultat. • Uppgift: Aktiviteter som krävs för att nå ett mål. Dessa kan vara fysiska eller

kognitiva. • Produkt: Den del av utrustningen som användbarhet ska specificera eller utvärdera. • System: Ett system, som består av användare, utrustning, uppgifter och fysisk och

social miljö, med uppgift att uppnå vissa mål. • Användare: Personen som använder produkten.

För att ha något att jämföra med så definierar Jakob Nielsen (Nielsen, 1990) användbarhet som:

• Lätt att lära: Användaren kan snabbt få arbete gjort med systemet. • Effektivt att använda: När en användare lärt sig systemet så är en hög

produktionsnivå möjlig. • Få fel: Användare gör inte många fel under användandet av systemet, eller om de gör

fel så kan de lätt återhämta sig. Även, inga katastrofala fel får hända. • Trevligt att använda: Användare are subjektivt nöjda med att använda systemet. De

gillar det.


33

I Nielsens definition ingår lärbarhet (eng. learnability) som ett kriterium för användbarhet. I en tidigare version av ISO 9241-11 fanns lärbarhet fortfarande definierat som ett attribut av användbarhet. Detta begrepp ligger nu under ISO 9126 – Software Quality Characteristic. Nielsen sätter även upp hårdare krav för fel som kan göras i systemet. Enligt min uppfattning är ISO standarden en sundare definition, då den till större grad värderar slutresultatet än de olika momenten. Om användare gör många fel i ett system men slutresultatet blir bättre och att nå det går snabbare så har felen på vägen mindre betydelse. Faktum är att användbarhet behandlas i ett flertal ISO dokument. ISO 9241-11 (Guidance on usability) och ISO 9126-1 (Software quality model) förklarar hur användbarhet är relaterad till kvalitet och hur det kan mätas. ISO 13407 definierar de grundläggande principerna för användarcentrerad design och ISO 18528 definierar vilka aktiviteter som bör finnas med i en användarcentrerad process.

7.3 Användaranalys Att känna användaren innebär att veta vilka de är, vilken datorvana de har, vilken expertis de besitter, vad de antar om systemet de jobbar med etc. Det handlar inte om att producera det mest lättanvända, utan att producera det mest lämpliga gränssnittet för en specifik grupp användare. Oftast är det inte lämpligt att ”skapa” en generell användare, eftersom det är otroligt att alla kommer att passa in på den modellen. Det är inte heller lämpligt att anpassa systemet efter den mest/minst krävande användaren, då det kan göra systemet dåligt för majoriteten. Om ett system ska skapas för “allmänheten” krävs att man studerar utanför arbetsplatsen. Det måste gå att använda direkt, annars används det inte. Det är viktigt att involvera användarna, det är aldrig tillräckligt med dig själv för att testa användbarheten av en produkt. Syftet med användaranalysen är att ta reda på vilka användargrupper det finns för det tänkta systemet, och vilka egenskaper dessa grupper har. Skillnader mellan dessa grupper är viktig att beakta vid designen av systemet, manualer och hjälpverktyg. (Göransson et al, 2002)

7.3.1 Typer av användare Användare kan klassificeras på ett antal olika sätt, ett sätt är att dela in dem i hur de kommer i kontakt med systemet: Direkta användare: Använder personligen systemet för att utföra sina arbetsuppgifter. T.ex. en sekreterare som skriver i en ordbehandlare, eller en arkitekt som gör ritningar i CAD. Indirekta användare: Användare som ber andra personer att använda systemet för deras räkning. T.ex. en kund som kontaktar ett flygbolag för att boka en flygning. Fjärranvändare: Använder inte systemet direkt men är beroende av dess resultat, t.ex. en kund i en bank som är beroende av bankens system för information om sina konton. Supportanvändare: En del av administrationen och det tekniska teamet som ger support för arbetet som andra personer utför. Uppgiften är att arbetet flyter på problemfritt. De kan även delas in i om de måste använda systemet eller inte: Obligatoriska användare: Måste använda systemet som en del av sitt jobb. De har inget val. Om systemet är krångligt att använda kommer detta att göra att deras arbete blir svårt och besvärligt. Godtyckliga användare: Behöver inte använda system som en del av sitt arbete. De kan välja om de vill använda systemet eller inte för att utföra sitt arbete. Om ett system är lätt att använda och tar mindre tid i anspråk så kommer man att vara mer villig att använda systemet.


34

Förutom att klassificera användarna efter deras uppgift, så kan man även klassificera dem efter deras expertis och bakgrund. Även detta styr hur systemet skall designas och eventuellt även vilka krav som ställs på hjälp och träning. Några grupper som kan urskiljas är t.ex:

• Nybörjare – experter • Gamla – unga • Män – kvinnor • Vana datoranvändare – ovana datoranvändare

Detta hjälper till att generalisera, vilket underlättar design och utveckling. (Faulkner, 2000)

7.3.2 Metoder för att samla information Information kan fås från användarna på ett flertal sätt men syftet är gemensamt; att urskilja olika användargrupper. Resultatet blir ett antal användarprofiler som sedan används i underlag för design och kravspecifikation. De vanligaste metoderna är följande: Enkäter i form av checklistor eller flervalsfrågor. Frågor kan vara enkla som t.ex. kön, ålder eller datorvana, men kan även röra vana av befintligt system eller vilka funktioner som personen använder. Fördelen är att det är ett snabbt, enkelt och billigt sätt att få information om olika användargrupper, men det finns ett flertal nackdelar också. Användare kan tendera till att överdriva sina kunskaper för att ”se bättre ut”, misstolkningar av frågor kan vara svåra att upptäcka med mera. Det är vikigt att försöka göra så tydliga enkäter som möjligt. Intervjuer med användare. Dessa kan utföras lite olika, men man kan se det som om antingen intervjuaren eller användaren styr konversationen, beroende på hur frågorna är strukturerade. En stor fördel med intervjuer är att de kan fortgå ända tills intervjuaren fått all information han behöver, och om svaret är oklart så kan han be om ett mer utförligt svar. Intervjuer är bland annat lämpliga till att utreda problem med befintligt system, finna acceptans för nya idéer och hitta behov. Däremot är det relativt dyrt och tidskrävande, då det förutsätts att användarna får frångå jobbet för en tid. Observationer av användare i deras arbetsmiljö. Möjligheten att se hur användarna utför sina arbetsuppgifter kan ge god insyn i personen i fråga, och även i deras arbetsuppgifter. En nackdel är att om användaren känner sig iakttagen är det möjligt att han försöker utföra sitt arbete på ett annat sätt än normalt, för att ge ett bättre intryck. Det är viktigt att inte störa användaren, utan att han får utföra sitt arbete utan att känna sig pressad. Användare i utvecklingen där de utgör en del av designteamet. På det viset är det alltid en representant av användarna närvarande som kan föra deras talan angående designfrågor. Representanten kan ofta tillföra nyttig information till designen och även föreslå alternativa lösningar. Nackdelarna är att representanten kan vara orepresentativ för de övriga användarna, och hans värderingar inte stämmer överens med majoritetens. Eller så kan han bli van vid hur designteamet tänker och utför sina uppgifter. (Faulkner, 2000)

7.4 Uppgiftsanalys Det man vill uppnå med en uppgiftsanalys är att få en djupare förståelse i vad användarens arbetsuppgifter består i och hur dessa utförs. Detta är essentiellt för att skapa en användbar produkt. Om man inte har vetskapen om vilka uppgifter systemet måste kunna utföra, och därmed inte stödjer dem, så kommer systemet inte att användas. En annan sida av samma problem är att i ett försöka att undvika detta, så implementerar man för mycket funktionalitet som leder till att systemet blir svåröverskådligt och de relevanta funktionerna försvinner i mängden. Relevanta frågeställning kring arbetsuppgifterna kan till exempel vara:

• Varför utför användaren en viss arbetsuppgift?


35

• Hur ofta utförs arbetsuppgiften? • Hur lång tid tar det att utföra arbetsuppgiften. • Vilka steg eller handgrepp behövs för att utföra arbetsuppgiften? • Samarbetar användaren med någon annan när arbetsuppgiften utförs? • Vilka hjälpmedel; system, produkter, blanketter etc, behöver användaren för att utföra

arbetsuppgiften? • Finns det mycket kritiska arbetsuppgifter och ”flaskhalsar” vilket gör arbetsuppgiften

svår att utföra? • Hur kan arbetssituationen och informationsstödet förbättras? (Faulkner, 2000)

Syftet med uppgiftsanalysen och användaranalysen är att tillsammans med användaren fastställa vad mjukvaran ska göra, vem som ska använda den, hur den skall användas, hur den kan förbättra arbetssituationen och så vidare. Uppgiftsanalysen kan utföras på samma sätt som användaranalysen, det vill säga med hjälp av enkäter, diskussioner/intervjuer, observationer eller genom användare i designteamet. (Göransson et al, 2002)

7.5 Modeller Under den tid som användarcentrerad utveckling har uppstått har det framkommit en hel del olika teorier och modeller för utvecklingsprojekt kan utföras för att producera användbara produkter. Vissa har inte vunnit stor mark medan andra är relativt väletablerade. Några av de modeller som finns diskuteras här. Användarcentrerad utveckling är inte av binär natur, där man antingen använder det eller inte. Olika grader av användarmedverkan kan illustreras genom olika modeller av användarcentrerad utveckling. I modellbaserad design ingår användarmedverkan endast i startfasen av utveckling, där man försöker skapa en generell modell av användaren, och under resten av utvecklingsarbetet används modellen. I deltagande design däremot, ingår användarmedverkan under hela utveckling, då användare är medlemmar av utvecklingsteamet. Figuren nedan illustrerar hur olika modeller använder sig i olika grad av användarmedverkan.

(Göransson et al, 2002)

7.5.1 Modellbaserad utveckling GOMS (Goals, Operators, Methods, Selection rules) och KLM (Keystroke Level Model) är exempel på modellbaserad utveckling. Dessa modeller är de som involverar användarna minst. Man försöker bygga upp ingenjörsmässiga modeller utav användare utifrån psykologiska och kognitiva teorier på hur människan fungerar, för att sedan kunna använda dessa modeller för att förutspå hur en användare kommer att agera i en viss situation. (Göransson et al 2002)

Lågt Användarmedverkan Högt

Modellbaserad design

Usability engineering

Kontextbaserad design

Deltagande design


36

7.5.2 Usability Engineering Usability engineering uppkom ur behovet av användbara datasystem. Man vill göra det möjligt att bekräfta användbarheten av en produkt. Istället för att involvera användarna för att utvärdera användbarheten så använder man sig av olika designregler (heuristics) skapade av experter. Arbetssättet är iterativt, och genom utvärdera enligt reglerna kan en tillräckligt bra lösning nås. (Faulkner, 2000)

7.5.3 Kontextbaserad design Kontextbaserad design handlar om att förstå användarens arbetsplats, arbetsuppgifter och utifrån den förståelsen skapa en prototyp, som skall testas på arbetsplatsen, och inte i något laboratorium. Tanken är att utvecklarna ska lära sig utav användarna, och förstå hur de vill lösa sina arbetsuppgifter. (Göransson et al, 2002)

7.5.4 Användarstudier Användarstudier innebär i princip att man utför en användar- och uppgiftsanalys genom att studera användarna i sitt arbete. Dessa utförs ofta med hjälp videoutrustning, för att försöka undvika att störa användarna, vilket kan resultera i ett felaktigt resultat.

7.5.5 Reflektera med användaren Här ses användarna mer som konversationspartners för att skapa nya idéer hos designern. Genom att dela kunskap kan de tillsammans hitta nya användningsområden och nya lösningar. Designern har erfarenhet av olika designlösningar medan användaren har erfarenhet av arbetsuppgifter som behöver lösas. (Schön, 1983)

7.5.6 Deltagande design Deltagande design innebär att en användare ingår i designteamet vid utvecklingen, det vill säga, användaren skall vara med genom hela utvecklingsarbetet, från specifikation till utvärdering. (Faulkner, 2000)

7.6 Prototyping Ordet prototyp används lite annorlunda inom systemutveckling jämfört med till exempel annan produktutveckling. Inom industriell design betecknar det den första färdiga produkten, som sedan kan sättas i produktion. Inom systemutveckling används prototyp som en beskrivning på ett program som inte är helt färdigutvecklat och prototyping som en teknik att framställa dessa prototyper. Det finns ingen entydig bild av vad prototyping innefattar, det finns även skolor som ser prototyping som ett sätt att utveckla på. Dess iterativa natur gör det lätt att hitta brister och möjliga förbättringar och man kan däreftet modifiera kraven. Under utveckling så blir det lätt att hitta nya lösningar, svagheter och nya krav, samtidigt som man lätt kan testa funktionalitet och prestanda. Ytterligare en fördel med prototyper är att det utgör en bra grund för utvecklare och användare att diskutera kring, och tillåter de olika grupperna att lära av varandra. (Göransson et al, 2002) Under utvecklingen av detta arbete har det framgått tydligt för mig att kraven inte framgår förrän produkten kan börja användas till en viss grad, och det är väldigt svårt att göra en fullständig specifikation på hur produkten ska se ut och vilka krav som finns på den innan arbetet påbörjats. Det finns ett antal olika metoder för att använda sig av prototyping, och det som skiljer dem mest åt är hur tidigt i projektet de används.


37

System definition

Användar-analys

Uppgifts-analys

Design-förberedelser

Användbar-hetskrav

Implementation

Användbarhets-testing

Prototyp-design

Konceptuell design

7.6.1 Paper prototyping Paper prototyping används innan någon implementation börjar. Först bestäms vilken funktionalitet som bör finnas, varefter pappersskisser görs av gränssnittet, t.ex. knappar, menyer, dialogrutor etc., som behövs för att utföra dessa uppgifter. Sedan leder en användbarhetsexpert en testsession med användare för att testa implementationen. Eftersom allt är på papper är det snabbt och enkelt att ändra designen, samtidigt som det ger flexibelt och föränderligt intryck. En annan fördel är att risken minskas att användare hakar upp sig på små detaljer, till exempel på hur knappar ska se ut, då de är skissartade. (UsabilityNet, 2004)

7.6.2 Rapid prototyping Med rapid prototyping skapas interaktiva prototyper, som snabbt ska gå att byta ut eller ändras utifrån feedback. Denna kan komma från antingen användare eller kollegor. Tanken är att prototyperna ska slängas bort, och dess uppgift är att samla in krav och att testa designlösningar. Syftet är att man skall ha råd/tid att göra många olika lösningar, det måste därför vara billigt att framställa dessa prototyper. Det finns ett antal verktyg för att skapa dessa, t.ex. HyperCard och Visual Basic. När prototypfasen är färdig används ingen kod utan det enda man tar med sig till produkten är den kunskap man vunnit. (UsabilityNet, 2004)

7.6.3 Evolutionary prototyping Evolutionary prototyping syftar att leverera ett fungerade system till användaren, medan de tidigare metoderna mer är för att verifiera eller utreda kraven. Det kan ses som en kompromiss mellan konventionell utveckling och prototyping där man bygger systemet gradvis. Nackdelen med att utveckla samma prototyp är att det lätt blir så att utvecklarna rättar till fel och brister istället för att utvärdera andra alternativ. (UsabilityNet, 2004)

7.7 Några kommersiella modeller Det finns ett antal utvecklingsmodeller som finns väl beskriva och dokumenterade, och där det erbjuds kurser och litteratur för företag. Vissa av dessa har ett uttalat stöd för användbarhet medan andra inte har det. Här ges en kortare beskrivning av de vanligaste utvecklingsmodellerna med fokus på hur de förhåller sig till användbarhet.

7.7.1 Deltametoden Deltametoden är en utvecklingsmodell som utvecklats i samarbete mellan Ericsson och Linköping universitet som används av bland andra Ericsson och VM-data. Syftet är att konstruera ett system baserat på användarens behov, och därmed skapa ett användbart system. I början av utvecklingen görs en användar- och uppgiftsanalys, varpå man fastställer kraven på användbarheten. Efter det går man igenom konceptuell design, prototypdesign och ett användbarhetstest och omformulerar kraven på användbarhet utifrån det. Dessa moment itereras tills det att en godtagbar prototyp erhållits varefter implementeringen påbörjas. (Delta Method, 2004)


38

7.7.2 RUP RUP (Rational Unifed Process) innefattar inte något explicit stöd för användbarhet, men RUP kan ändå vara intressant att nämna då det är en väl etablerad utvecklingsmodells som används av ett flertal företag, däribland ABB. Med RUP försöker man tidigt i projektet att ta reda på användarkraven men man utför inga utvärderingar senare av dem. Däremot utförs projektet iterativt och man förespråkar användandet av prototyper. I princip kan hela projektet ses som en evolutionär prototyp som arbetas fram, men där även rapid prototyping kan användas. (Booch et al, 1999)

7.7.3 DSDM DSDM (Dynamic Systems Development Method) är ett ramverk för att leverera mjukvara med hög kvalitet snabbt. Det är framtaget i ett konsortium där ett flertal företag och enskilda bidragit med kunskap, och har börjat sprida sig allt mer. Grunden för DSDM utgörs utav nio designprinciper, där den första regeln är att aktiv användarmedverkan är imperativ. Hur detta sedan ska utföras är inte specificerat. (DSDM, 2004)

7.8 Utvärderingsmetoder Enligt många utvecklingsmodeller ska det vara möjligt att fastställa hur användbar slutprodukten är. För att detta ska vara möjligt måste användbarhet fastställas som en mätbar storhet. Detta kan utföras på ett flertal olika sätt Expertutvärdering utförs av experter på användbarhet, ofta med hjälp av checklistor, style guides och olika designregler. Användarna involveras inte, men det förutsätts att experten har förståelse för användarens kunskaper, arbetssituation, kunskaper och så vidare. Metoden är inte helt tillförlitlig men den utgör ett snabbt och billigt sätt att hitta fundamentala problem i designen, vilket ger ett mått på användbarheten. Observationer av användare kan endast användas på system som är satta i drift eller som beta-testats, ifall inte någon form av prototyping används, helst på arbetsplatsen. Genom att observera användarna och ställa frågor, kan den som studerar användarna få en god bild av hur accepterat system är bland användarna, och detta kan sedan sammanställas för att ge ett mått på hur användbart systemet är. Scenariobaserad utvärdering ät tänkt att användas under utvecklingen för att producera en mer användbar produkt. Man iscensätter ett scenario som en användare ska arbeta med samtidigt som man studerar och frågar om hur systemet fungerar. Utifrån den feedback man får så kan man modifiera designen och iterera processen tills användaren känner sig nöjd. Gruppgranskning innebär att användare, utvecklare och andra intressenter deltar i en diskussion där går igenom användarnas arbetsuppgifter och diskuterar olika problem och frågeställningar kring dessa. På detta vis får man in många olika aspekter på problemen och olika förslag till lösningar som sedan dokumenteras. Laboratorieutvärdering utförs i särskilda användbarhetslaboratorium. Användare får specifika uppgifter som de ska lösa medan de som ska utvärdera användbarheten är passiva åskådare som bildar sig en uppfattning av hur systemet används och vilka problem som uppstår. Utvärderarna analyserar sedan sina resultat för att fastställa hur användbart systemet är. (Göransson et al, 2002)

Kapitel 8 Genomförandebeskrivning ___________________________________________________________________________

39

8 Genomförandebeskrivning

I detta kapitel ges en kort beskrivning av arbetssättet som tillämpats och detta följs av en utförlig genomgång hur det praktiska arbetet har förflutit, från design till implementation.

8.1 Metod Arbetet inleddes med en kortare tid till att studera bakgrunden för applikationen, det vill säga tillverkning av stål- och aluminiumplåtar, valsningsprocessen och det nuvarande systemet Stressometer. Efter det sattes i samtal med handledare en planering upp där även krav och mål formulerades. Utifrån krav och mål fastställdes de verktyg och vilken utvecklingsmiljö som skulle användas. De fastställda verktygen installerades och konfigurerades. Sedan följde en kortare litteraturstudie för att tillgodogöra mig de nödvändiga kunskaper som krävdes. Efter detta inleddes ett designarbete av GUI:et som löpte parallellt med utvecklingsfasen som påbörjade när en första design hade skapats. Detta för att utvecklingsarbetet realiserades i prototyper där designen kunde förändras utifrån feedback från en liten användargrupp. Användargruppen bestod av ett antal arbetare på ABB Force Measurement. Målet var att försöka få in användare i utvecklingen och på så vis få relevant återkoppling och skapa en lösning som är önskvärd av användarna. Arbetet har dokumenterats fortlöpande och avslutades med att sammanställa all dokumentation till denna rapport.

8.2 Motivering av verktyg Eftersom en av premisserna var att programmet ska köras i en webbläsare, kommer applikationen att göras i form av en Java-applet. Även befintligt HMI som programmet kommer att vara ett komplement till är implementerat i Java. För att skapa en virtuell modell av valsämnets egenskaper används Java 3D. De främsta anledningarna till detta är att det är lätt att integrera med en Java-applet, och det innehåller all funktionalitet som behövs för applikationen. Installation och konfiguration är relativt lätt och går att köra på ett flertal plattformar. Anvisningar för installationer av verktygen finns i bilagor i slutet av detta dokument.

8.3 Utvecklingsmodell Att använda sig av användarcentrerad utveckling presenterar en del komplikationer i detta arbete. Detta kommer sig av att detta är en helt ny produkt, och det finns följaktligen inte några användare eller uppgifter att studera. Att identifiera de framtida användarna är inte svårt utan problemet består i:

• Användarna kanske inte direkt ser behovet, eller eventuella vinster. • Användarna är konservativa och nöjer sig med det som finns. • Användarna har inte någon erfarenhet utav den speciella tillämpningen.


40

Detta hindrar dock inte användandet av användarcentrerad utveckling men det medför att mindre vikt läggs på användaranalysen och uppgiftsanalysen, och mer på ett direkt samarbete. Genom att identifiera de som kommer att använda programmet när det är färdigt kan dessa involveras i utvecklingen. Initialt presenterar jag en arbetsuppgift och ett sätt att göra det på. Användarna kan sedan komma med synpunkter på arbetssättet och även peka på andra arbetsuppgifter som kan tänkas finnas. Fördelarna med att involvera användare blir flera:

• Experter i området, även om de inte är experter i den speciella tillämpningen • Feedback, fler personer involverade, fler synpunkter, fler idéer, mindre risk att fastna i

tankebanor • Får dem att se nyttan av verktyget. • Om jag skapar en uppgift som det finns en nytta av att lösa, kommer de att vara

användarna, och de måste bestämma hur de vill lösa uppgiften. Användar- och uppgiftsstudie - Arbetet började med en mindre användar- och uppgiftsstudie av det befintliga systemet. Detta gjordes i form av en litteraturstudie, studiebesök på ett valsverk samt i samtal med olika personer på ABB som arbetar med olika områden inom kallvalsning. Eftersom detta arbete har lett till ett tillägg till ett befintligt system så har nya arbetsuppgifter tillkommit. Uppgiftsanalys av dessa nya uppgifter har skett genom diskussion och observation i utvecklingsarbetet. Efter att den initiala analysen var färdig har en kombination av olika modeller använts. Paper prototyping – För min externa handledare, som utgjorde en part i användargruppen, presenterade jag olika visualiseringsmodeller för de olika egenskaperna på papper. Vi träffades en gång per dag varpå jag presenterade olika idéer, och fick feedback och tillsammans kom med förslag på förändringar. Evolutionary prototyping – När en vi nått en design som kändes bra började jag utveckla en interaktiv prototyp. I det här fallet valde jag att använda mig av evolutionary prototyping då rapid prototyping skulle ha tagit för mycket tid. Prototypen visades sedan för personerna i användargruppen som bestod utav min externa handledare, en igångkörare, en operatör, samt en person från produktutvecklingsavdelningen. Utifrån feedback modifierade jag prototypen och visade den för användargruppen igen. Detta itererades till dess att alla parter var nöjda, vilket tog ungefär fem-sex träffar. Reflektera med användare – Under utvecklingen har jag samtalat med inte bara personer från användargruppen utan även andra tänkbara användare. Detta har varit olika personer här på ABB som har ett intresse i det system som jag utvecklar. Tillsammans har vi diskuterat olika design och tekniklösningar. Detta har dock inte skett systematiskt utan mer varit av en sporadisk natur. Tyvärr kunde jag inte i någon större omfattning involvera användarna i utvecklingen på grund av litenheten av detta arbete, annars hade jag gärna använt mig av t.ex. deltagande design.


41

8.4 Gränssnittsdesign & Visualisering Det viktigaste momentet i arbetet var att fastställa en design för användargränssnittet och visualiseringen av indata från sensorer som är funktionell och korrekt. För att utforma vilka krav som ställdes på designen så sattes följande problemställningar upp innan något annat gjordes:

• Vilka egenskaper ska kunna visas? • Hur ska de visas för att egenskaper ska kunna korreleras? • Hur undviks att det blir för otydlig grafik? • Hur undviks att objekt skyms av varandra? • Vad är en bra balans mellan de olika variablerna? • Hur stor noggrannhet behövs? • Hur stor historik behövs? • Vilken funktionalitet bör finnas?

Utifrån dessa punkter arbetades sedan designen fram. Tidigt fastställdes att direktmanipulering skulle användas. Direkt manipulering innebär att användare får en direkt fysisk återkoppling och kontinuerlig feedback av sina handlingar. En form av detta är t.ex. skrivbordsmetaforen som återfinns i de flesta grafikiska operativsystem. (Göransson et al, 2002) I det här fallet används valsämnet som utgångspunkt för att visualisera de olika sensorernas indata. Det känns som ett bra val eftersom hela processen är fokuserad på valsämnet och alla egenskaper kan direkt eller indirekt projiceras på valsämnet, och det ger en fysik återkoppling. Genom att göra prototyper och experimentera med olika designer kunde jag genom en iterativ process med hjälp av olika användare fastställa en godkänd design för användargränssnittet.

Figur 8-1 Axlarna för 3D universumet

• Planheten kan beskrivas som bivariat datamängd. Datapunkten anges av två funktioner, f(x) och f(y), och eftersom funktionerna endast anger i vilken x- och y-koordinat datapunkten ligger så faller det sig naturligt att välja värdet på datapunkten

x

z

y


42

bestäms av dess position i z-led (se fig. 8-1). Efter tester visade det sig att det även var användbart att färgkoda datapunkterna utifrån gränsvärden för att ytterligare förtydliga dess värde.

• Tjockleken är liksom planheten en bivariat datamängd. Här måste dock en annan visualiseringsmodell väljas för att möjliggöra korrelation mellan de olika datamängderna. Genom att visa tjockleken som staplar längs med bredden på valsämnet så kan tjocklek och planheten visas samtidigt utan risk för att blanda ihop dem.

• Temperatur är även den en bivariat datamängd. Här måste ytterligare en ny modell väljas för visualisering för att möjliggöra korrelation. Genom att endast påverka färgen på datapunkten men låta z-värden vara konstant och använda unika färger för visualiseringen så kan temperaturen visas tillsammans med tjocklek och planhet utan att det blir för oöverskådligt. Färger mellan datapunkter interpoleras.

• Positionen är en univariat datamängd. Datapunkten anges av en funktion f(x) som motsvarar vars efter x-axeln den ligger och värdet motsvarar en förskjutning i y-led. Det faller sig naturligt att visualiseras som en kurva längs med längden på valsämnet som förskjuts i y-led för att visa sidoförskjutning av valsämnet.

• Excentriciteten är en bivaritat datamängd, där de olika variablerna är position i x-led, bredd och amplitud. Genom att visualisera varje excentricitet som en rektangel på valsämnet där dess bredd (x-led) avgör hur stor yta den påverkar och genom att använda olika intensiteter på färgsättningen så kan även styrkan med vilken den påverkar valsämnet uttryckas.

• Kylning har inte implementeras men skulle kunna visas som små sfärer i datapunkterna där antingen storlek eller färg anger hur mycket just den punkten påverkats av kylningen. Även en modell för visualisering av temperaturen på valsen kan vara av nytta.

Genom att låta de olika egenskaperna vara halvt genomskinliga kan en egenskap visas ovanpå en annan utan att helt skymma den men ändå lätt sättas i relation till den föregående. Genom att låta användaren individuellt styra hur starkt varje egenskap skall synas kan denne anpassa en optimal lösning för sig själv. Exempel på hur de olika egenskaperna ser ut för operatören kan ses under kapitel 8.8 Testkörningar. Efter experiment framgick att en historik av cirka 50-100 mätvärden kan visas samtidigt utan att grafiken blir för oöverskådlig samt att kraven på låg responstid upprätthålls. 100 värden motsvarar en historik på 20 sekunder förutsatt att nya mätvärden erhålls med ett intervall på 200ms, vilket anses vara tillräckligt. Appleten tillåter förändringar av detta men inte under körning.

8.5 Systemdesign Utgångspunkten vid design av systemet var att det skulle vara modulärt och återanvändbart samt att det skulle vara lätt att göra tillägg och förändringar samtidigt som prestanda skall vara godtagbar. Genom att implementera alla fristående delar som egna klasser som endast kommunicerar genom bestämda metoder undviks svårigheter vid modifikationer och tillägg och inga osynliga beroenden finns. Efter att kraven på funktion på appleten fastställts kunde jag sammanställa ett behov av följande klasser:

8.5.1 Javaklasser SceneObjects:


43

Alla 3D-object som finns i appleten instansieras här och tillstånd för skriv och läsrättigheter under körning sätts. SensorFusion: Huvudprogrammet där 2D användargränssnittet och ett universum för 3D gränssnittet skapas. Alla objekt läggs in i scengrafen och de objekt som ska vara interaktiva tilldelas beteenden. (x)StripBehavior: En grupp beteenden som uppdaterar en tillskriven geometri för att reflektera förändringarna i den egenskap som den representerat. Data hämtas genom att anropa Reader-klassen. (x)TransparencyBehavior En grupp beteenden som uppdaterar en tillskriven geometri för att reflektera förändringarna i genomskinligheten hos egenskapen den är tillskriven baserad på användarens interaktion. Data hämtas genom att anropa TransparencyValues-klassen. ButtonBeavior Här styrs navigationen i 3D-gränssnittet. TransparencyValues En klass som hämtar genomskinlighetsvärden från GUI:et och sparar dem i variabler, och sedan gör dem tillgängliga via metodanrop. Settings En klass som lagrar diverse inställningar för programmet. Reader Sätter up kommunikation med FSA-Servern och instansierar läsare för de olika egenskaperna som egna trådar. Tillhandahåller metoder för att läsa de senaste mätvärdena som lästs från FSA-Servern. FileLoader Läser in objekt i formatet *.3ds och returnerar dem som en Shape3D. Används för att ladda in valsverkets olika delar.


44

8.5.2 Programflöde Kommunikationen mellan alla klasser sker genom metodanrop och följande schematiska diagram illustrerar hur de olika klasserna anropar varandra.

Figur 8-2 Schematiskt diagram över programflödet

SensorFusion(huvudklass)

exentricityTransparencyBehavior

flatnessTransparencyBehavior

transparencyValues

Reader

SceneObjects

FileLoader

*.3ds (fil)

Settings

temperatureTransparencyBehavior

thicknessTransparencyBehavior

flatnessStripBehavior

positionTransparencyBehavior

exentricityStripBehavior

thicknessStripBehavior

temperatureStripBehavior

positionStripBehavior

Webbläsare

FSA-server Fil

Applet

buttonBehavior


45

8.6 Mjukvaruutveckling Efter att en lämplig systemdesign samt en preliminär design av användargränssnitt bestämts började själva mjukvaruutvecklingen. 2D-gränssnittet har haft en lägre prioritet i detta arbete då denna inte är vital för tillämpningen och enkel att förändras i efterhand. Fokus har legat på att implementera funktioner som krävs för att testa gångbarheten hos 3D-delen av Java-appleten. Jag kunde fastställa följande behov:

• En fönster där ett Java 3D universum kan visas. • Möjlighet att kontrollera vilka egenskaper som skall visas samt hur starkt de ska visas. • Möjlighet att navigera i 3D-miljön. • Möjlighet att kontrollera hastigheten på uppdateringen.

Gränssnittet är implementerat med Javas inbyggda Swing-klasser och de färdiga komponenter som använts är Jslider för transparangsvärden, Jbutton för navigering och kontroll, Jlabel för texter, samt Jpanel och container för gruppering av objekten. 3D-fönstret infogas sedan helt enkelt som en vanlig panel i 2D-gränssnittet. Knapparna för navigation och kontroll och sliders för transparensvärden tilldelas lyssnare för att kunna uppdatera variabler som används av 3D-delen av programmet. Ingen större hänsyn har tagits till användarvänlighet för detta gränssnitt förutom sunt förnuft. Ytterligare möjligheter för inställning av färgval samt möjlighet att påverka gränsvärden och amplitud bör läggas till.

8.6.1 Scengrafen Ett Java 3D program skapar instanser av Java 3D-objekt och placerar dem i en speciell datastruktur som kallas Scengraf. Scengrafen är ett arrangemang av olika typer av 3D-objekt i en trädstruktur, som helt bestämmer innehållet i ett virtuellt universum och styr hur det skall renderas. Dessa olika 3D-objekt kan vara:

• geometrier • ljudkällor • ljuskällor • positioner • rotationer • utseenden

I den speciella trädstrukturen representerar hörnen instanser av någon av de ovan nämnda objekten. Kanterna representerar en av två följande relationer mellan Java 3D-instanser:

• Förälder-barn relation. Ett hörn kan ha flera barn men endast en förälder. En lövnod kan ha en förälder men inga barn.

• Referens. En referens associerar en NodeComponent objekt med ett scengrafhörn. NoceComponent objekt definierar attributen för geometrin och utseendet som används vid rendering. (Bouvier, 1999)

Ett exempel på några olika delar i scengrafen kan ses i fig. 8-3.


46

Figur 8-3 Exempel på strukturen i scengrafen

8.6.2 Objekt Genom att gå igenom kraven och syftet med appleten kan en lista på vilka objekt som ska visas för användaren snabbt fastställas. Dessa är förutom de egenskaper som beskrivs under kapitel 8.4 även valsverkets olika delar. De olika egenskaperna bandet besitter måste visualiseras med någon form av grafiskt objekt. De måste gå att anpassa på ett enkelt och mångsidigt sätt. För de flesta egenskaper används en datatyp kallad quadarray. Ett objekt byggs upp som en yta bestående av ett antal delytor, där varje delyta beskrivs med fyra koordinater i rymden. På detta sätt kan ett godtyckligt objekt byggas upp. Varje hörn i en fyrkant motsvarar en mätpunkt, och eftersom antalet mätpunkter kan variera är det möjligt att justera dimensionen på quadarrayen. En annan fördel är att varje punkt kan färgsättas individuellt.

Virtual Universe

View branch graph

BGRoot

TGObjRot

TGMoveOrigo

SflatnessStrip Förklaring:

BG = BranchGroup TG = TransformGroup T = Transform B = Behavior S = Shape QuadArray

Locale

Appearance

B

B buttonBehavior

flatnessStripBehavior

Other objects

Other behaviors


47

8.6.3 Beteenden För att skapa någon form av rörelser och interaktion använder sig Java 3D av s.k. beteenden. Till det/de objekt man vill förändra över tid/händelse knyter man ett beteende. Beteendet innehåller i sin tur ett antal nyckelmetoder. Bl.a. annat sätter man upp regler för när beteendet ska aktiveras, detta kan baseras på förfluten tid, förflutna bildrutor, awt-händelser och så vidare, och sedan beskrivs vad som skall ske då ett beteende aktiveras. (Bouvier, 1999) För att uppdatera genomskinligheten så använder jag mig av tid, eftersom en awt-händelse endast reagerar på händelser i 3d-miljön. Genomskinligheten uppdateras ett par gånger i sekunden genom att värden hämtas via 2D gui:et och skrivs till utseendet på objekten. Detta görs oavsett om det behövs eller inte. Genom att kontrollera om värdet uppdaterats av användaren innan utseendet förändras och bara göra denna förändring i fall det är nödvändigt skulle en prestandavinst kunna göras, men den skulle vara marginell. Uppdateringen av geometrierna sker med ett ställbart jämt intervall som kan variera från 200ms till 2 sek. När det är dags att uppdatera geometrin hämtas det senaste lästa mätvärdet in. Alla gamla värden flyttas bakåt och det äldsta värdet skrivs över och det nyaste värdet läggs längst fram. Här upptäckte jag att vissa Java 3D metoder är väldigt långsamma och prestandavinster på över 500% kan göras genom att välja andra Java 3D metoder.

8.7 Kommunikation Kommunikationen med FSA-Servern sker med RMI (Remote Method Invocation). RMI är ett protokoll som tillåter en klient att instansiera en databas på en server som ett lokalt objekt och sedan kan göra vanliga metodanrop för att hämta data. Stressometer använder sig av RMI för andra Java-applets, så ett färdigt interface finns för kommunikation med servern. För att implementera inläsningen har jag utgått ifrån befintlig mjukvara i Stressometers HMI-system och modifierat den för att passa mina behov.

8.7.1 Datainhämtning För att inte blockera programflödet när jag pollar data från FSA-servern implementerade jag de olika läsarklasserna som egna trådar. Detta tillåter också att de olika datamängderna kan uppdateras med olika intervall, vilket kan användas för att öka prestandan hos appleten ifall de olika givarna uppdateras olika ofta. Jag har utgått ifrån befintlig mjukvara i Stressometers HMI-system vid implementation av inläsning av planhet och tjocklek och modifierat den för att passa mina behov.


48

8.8 Testkörningar Tidigt i utvecklingen genererade jag slumpmässiga tal som input till appleten. Detta för att kontrollera att grafiken ritades ut korrekt. En stor begränsning var att eftersom indata blev orealistiskt så var det svårt att se om ett bra sätt att illustrera egenskapen valts. I en verklig applikation skulle värsta fallet med hänsyn till att klottra ner grafiken inte komma i närheten av detta fall. Så genom samråd med extern handledare valde vi att läsa in data från fil. Jag implementerade en parser som läste in sparade MATLAB-vektorer som innehöll realistiska värden, och lät appleten använda sig av dem för att rita ut grafiken. Sista steget var att hämta data från en FSA-server för de egenskaper som fanns tillgängliga. Kommunikation med en FSA-server krävs för att testa programmet i en simulerad miljö och även för att köra det i ett verkligt valsverk. Som nämnts under problembeskrivning så har ingen större vikt fästs vid 2D-användargränssnittet så ingen utvärdering har gjorts av det. Testkörningarna har visat att appleten uppfyller kraven på låg responstid. För att kontrollera detta har brokerns inbyggda funktion för att visa planheten jämförts med appleten under körning. Detsamma gäller för att korrekta planhetsvärden visas. De övriga egenskaperna visas också korrekt, och det har kontrollerats genom att jämföra det data som visualiserats med de data som funnits i filen. Möjligheten att justera transparens av objekt fungerar och korrelering av egenskaper fungerar tillfredställande. Nedan följer några exempel på hur de olika egenskaperna visas separat och tillsammans.

Figur 8-4 Exempel på planheten


49

Figur 8-5 Exempel på temperaturen

Figur 8-6 Exempel på positionen


50

Figur 8-7 Exempel på tjockleken

Figur 8-8 Exempel på excentriciteten


51

Figur 8-9 Exempel på hur planhet, temperatur, tjocklek, position och excentricitet visas tillsammans. Reglagen till höger ställer in transparensgraden för de olika egenskaperna.


52

Kapitel 9 Resultat ___________________________________________________________________________

53

9 Resultat

Arbetet har förutom detta dokument resulterat i en fungerande prototyp för återkoppling av sensor fusion data i Stressometer 6.0. Nedan finns en lista med de ursprungligen uppsatta målen, där jag lagt till en kolumn med namnet Uppfyllt där de mål som uppfyllts med arbetet markeras med Ja och de som ej uppfyllts markeras med Nej.

Mål • Implementera ett användargränssnitt som kan visualisera

utvalda egenskaper som mäts eller beräknas. Egenskaper som är av intresse är:

o Planhet – Om det är ojämn spänning i bandet blir det buckligt. Stressometer i sitt nuvarande tillstånd fokuserar enbart på detta.

o Temperatur – En egenskap som inte mäts än, men som är av intresse för bl.a. processutvecklare.

o Kylning – Kylning kan användas för att reglera planheten och det kan vara önskvärt att se hur mycket valsen och valsämnet har påverkats av kylningen.

o Tjocklek – Om bandet är jämntjockt. Idealiskt skall bandet vara lika tjockt överallt.

o Position – När bandet hasplas upp på spolen glider det i sidled.

o Excentricitet – När bandet hasplas upp bildas det mer spänning i bandet med vissa intervall. Detta beror på att bandet hasplas med en konstant kraft men radien på spolen förändras.

• Tillägget ska göras i form av en Java-applet, som är kompatibel med befintligt HMI. Användarna ska kunna använda appleten utan tidigare erfarenheter.

• En eller flera egenskaper ska kunna visas samtidigt då det är av vikt att kunna korrelera egenskaper med varandra.

• Sätta upp kommunikation med befintlig FSA-server och läsa in värden och visualisera dem med låg responstid.

• Koden skall vara generell då mjukvaran måste kunna anpassas för olika typer av valsverk och man måste kunna lägga till ytterligare funktionalitet då sådan tillkommer utan att skriva om större delar av koden.

• Testa systemet i en verklig applikation.

Uppfyllt

Ja

Ja

Nej

Ja

Ja

Ja

Ja

Ja

Ja

Ja

Nej

Prioritet

1 1 3 2 2 3 1 1 2 1 3

Kapitel 9 Resultat ___________________________________________________________________________

54

• Ev. modifiera befintligt kod i befintligt system, ifall det krävs eller ifall förbättringar kan göras.

Nej

3

Som man kan se har samtliga utom de två sista målen uppfyllts samt att en modell för visualisering av kylningen inte gjorts. På grund av svårigheter med sekretess och brist på valsverk villiga att stoppa produktion för testning av mjukvara har systemet inte testats i en verklig applikation utan har körts i simulerade miljöer. Det andra målet, att modifiera befintlig kod, stötte jag inte på något behov utav då jag inte i någon större omfattning behövde sätta mig in i befintlig kod.

9.1 Begränsningar och framtida arbete Under utvecklingen samt under testkörningar upptäcktes en mängd funktioner som skulle vara användbara att inkludera i programmet men som det inte fanns tid för att implementera. Här listas en del av dessa:

• Java-appleten visar för närvarande endast planhets- och positionsdata, då det är de enda data som finns tillgängliga i nuläget. Fullt stöd för de andra datamängderna finns implementerat och skall inkorporeras när det är möjligt att få tillgång till dessa. För närvarande visas dessa med slumpade värden eller värden lästa från fil för att visa dugligheten i den grafiska representationen. Dock kan det vara en god idé att göra en modell i t.ex. Matlab för att ytterligare testa och evaluera dem.

• Möjlighet att spara till fil och öppna från fil finns ännu inte. Detta kan implementeras, men först krävs att det fastställs hur formatet för filen ska se ut och vad som är nödvändigt att spara. En viktig fråga är om det är Java-appletens uppgift att spara ner data till fil eller om det skall göras på annat håll i systemet. Då detta kan vara användbart i andra sammanhang verkar det som en bättre lösning att spara detta på en högre nivå i systemet, till exempel i servern.

• Ytterligare möjligheter att konfigurera programmet, såsom val av färger för de olika 3D-objekten och att sätta gränsvärden bör implementeras.

• Möjlighet att markera specifika punkter på valsämnet och sedan återgå direkt till dem för att studera närmare bör implementeras.

• I denna prototyp tas heller ingen hänsyn till geometrin på givarna hos mätrullen, men detta kan lösas genom att läsa av information om geometrin från FSA-servern och uppdatera geometrin för planhetsobjektet för att reflektera detta.

• En annan fråga är hur olika hastigheter hos valsämnet ska återges för användaren då detta inte återspeglas i användargränssnittet. Det blir längre avstånd mellan mätpunkterna på det verkliga valsämnet men inte det virtuella. Det finns möjlighet att öka avståndet mellan mätpunkterna hos det virtuella valsämnet men då kommer längden att variera på det grafiska objektet vilket inte är önskvärt. Detta går troligen att undvika genom att modifiera systemet en aning.

Kapitel 10 Slutsats ___________________________________________________________________________

55

10 Slutsats

Något som har varit ett mindre problem, då jag har haft väldigt mycket frihet och få riktlinjer, är mina bristande kunskaper inom stålindustrin. Vad som är viktigt och vad som måste finnas med, och vad som bör beaktas vid designen och implementationen har fått lösas med ”trial and error”. Men eftersom personer i min användargrupp på ett tidigt stadium har kunnat upptäcka eventuella fel eller brister och ge expertishjälp har större fel kunnat undvikas. Här visade det sig att involvera användarna i utvecklingsprocessen kan förhindra stora omarbetningar av mjukvaran och att fel på grund av missförstånd snabbt rättas till. Jag har inte utfört några empiriska tester av appleten men den har fått ett positivt bemötande, vilket jag tror till stor del kan tillskrivas utvecklingsmodellen. Genom att användarna själva får inflytande i hur saker ska göras, och få det förklarat varför vissa saker måste göras på ett visst sätt, försäkras man om att slutprodukten blir något användaren vill ha och att användaren förstår de begränsningar som finns. Samtidigt måste man vara medveten om att användarna kan ha förutfattade meningar och att de kan vara motvilliga mot förändringar som kan medföra förbättringar när de väl vant sig vid dem. Ett annat problem har varit sätta begränsningar på arbetet, då det är svårt att på förhand kunna förutse vilka kunskaper som behövs. Det känns lite underligt att som utvecklare inte behöva förstå varför vissa saker ska göras eller teorin bakom, utan att det är tillräckligt att kunna implementera dem. Men allt eftersom arbetet fortflöt insåg jag att det helt enkelt inte är gångbart utifrån kostnads- och tidsperspektiv att sätta sig in i alla bakomliggande detaljer. Jag tycker att arbetet har varit mycket givande och har gett en verklig inblick i hur det ser ut i arbetslivet, och hur utveckling av verkliga produkter går till. Det skiljer sig en hel del från de arbeten som utförts under universitetets regi. Den största skillnaden är självfallet skalan på arbetet men även specifikationer och tillvägagångssätt skiljer sig åt. Specifikationerna är sällan så rigorösa som under utbildningen och arbetssättet blir således mer dynamiskt. Beroenden av sina medarbetare har visats sig påtagligt, och är en nyttig kunskap att ta med sig. Min handledare har informerat mig om att det finns ett intresse av resultatet av detta examensarbete ute i industrin, vilket känns väldigt spännande. Den prototyp jag skapat kommer att produktutvecklas och bli en del av produkten Stressometer, där de nu hårdvarustödda delarna kommer att ingå, och förhoppningsvis kommer även de andra delarna till användning då mätning av de andra egenskaperna återfinns i hårdvaran. Jag vill avsluta med att rekommendera andra att utföra examensarbeten på arbetsplatser av det här slaget då jag tror att det är en bra merit att ha med sig när man ska ge sig ut i arbetslivet. I och med att man arbetar som en examensarbetare förutsätts man inte kunna allt till att börja med och man får den hjälp som behövs för att komma in på arbetsplatsen och arbetsuppgifterna, vilket man sedan kan använda på andra arbetsplatser till stor utsträckning.

Kapitel 10 Slutsats ___________________________________________________________________________

56

Kapitel 11 Tack ___________________________________________________________________________

57

11 Tack

Jag vill passa på att tacka mina handledare George Fodor och Lars-Erik Janlert som varit en stor hjälp under detta arbete, och tagit sig tid för mig. Jag vill även tacka Christine Mikkelsen som hjälpt mig med att komma igång med Java 3D och som jag kunnat bolla idéer med. Tack även till Tobias Larsen som har hjälp till i frågor om synkroniserad programmering samt frågor i allmänhet. Michael Palmberg har varit till stor hjälp med frågor kring kommunikation och FSA-Servern i allmänhet. Och sist men inte minst vill jag även tacka min flickvän Camilla som har stått ut med mig och stöttat mig då min arbetslust har varit vacklande.

Kapitel 12 Litteraturreferenser ___________________________________________________________________________

58

12 Litteraturreferenser

3BSE003213R0401 (internal document) Stressometer measurement and control system Technical Description Version 5.0 1999, ABB Automation Products AB

ABB Millmate Thickness Gauging System, 2004, ABB Automation Products AB ABB E-learning course Introduction to IndustrialIT, 2004-05-20 <http://www.abb.se> 2004-

05-20 ABB Intranät ABB Sverige, 2004-05-20 <http://www.abb.se> 2004-05-20 AISI How Steel is Made: Stealmaking Flowline, 2004-05-20 <http://www.steel.org > 2004-

05-20 Barilleaux, Jon 3D User Interfaces with Java 3D 2001, Manning Publications CO

Greenwich Biel, Lena Modeling of Perceptual Systems 2002, Universitetsbiblioteket Booch, Grady et al The Unified Modeling Language User Guide 1999, Addison Wesley Bouvier, Dennis J Getting Started with the Java 3DTM API 1999, Sun Microsystems, Inc. Delta Method Delta – a method for constructing computer systems on the basis of users’

needs, 2004-05-20 <http://www.deltamethod.net> 2004-05-20 Douglass, Bruce J Real-Time UML DSDM DSDM Consortium – Helping you deliver on time, 2004-05-19

<http://www.dsdm.org/tour> 2004-05-20 Hardin, Winn Sensor Fusion: Good for Humans, Hard on Systems, 2003-01-01

<http://www.machinevisiononline.org/public/articles/archivedetails.cfm?id=1447> 2005-05-20

Faulkner, Xristine Usability Engineering 2000, MacMillan Press LTD Göransson Bengt & Jan Gullisen Användarcentrerad systemutveckling, version 1.0, 2000

KTH Stockholm.

Kapitel 12 Litteraturreferenser ___________________________________________________________________________

59

ISO 9241-11 Guidance on usability 1998, International Organization forn Standardization,

Geneve. Lea, Doug Concurrent Programming in Java Second Edition 2000, Addison Weasly

Longman, Inc. Lewis, John & William Loftus JavaTM Software Solutions 1998, Addison Weasly Longman,

Inc. Nielsen, Jacob HyperText and HyperMedia 1990, Academic Press Boston MA Nielsen, Jacob Usability engineering 1993, Academic Press San Diego Pfleeger, Shari L Software engineering 1998 Prentice Hall, Inc Schön, Donald The ReflectivcePractioner: How Professionals Think in Action 1983, Basic

Books New York. Selman, Daniel Java 3D Programming 2002, Manning Publications CO Greenwich UsabilityNet Usability resources for practitioners and managers, 2004-05-20

<http://www.usabilitynet.org> 2004-05-20

___________________________________________________________________________

60

Appendix A – Installation av Java 3D API Installation av Java 3D för användare: Kontrollera om du har Java Runtime Environment installerad på datorn (JRE). Om inte ladda ner en korrekt version för ditt operativsystem från Suns hemsida och installera. Sedan laddar du ner Java 3D Runtime Enviroment och installerar. Välj önskad version utav OpenGL och DirectX. Om datorn inte stödjer DirectX använd OpenGL versionen, de flesta grafikkort stödjer denna standard och den ger en något bättre prestanda i de flesta fall. På Suns hemsida finns Java 3D-appletar för att kontrollera att installationen blev lyckad. För att kunna ladda Java 3D-applets som importerar *.3ds objekt behöver du även installera en 3D-loader. Denna kommer som en .jar fil som du kopierar till katalogen bin/ext i din Java Runtime Environment katalog. Filen heter StarfireExt.jar. Installation av Java 3D för utvecklare: Ladda ner J2sdk1.4 eller den version du vill använda. Ladda ner J2jre1.4 eller den version du vill använda. Ladda ner Java3D1.3sdk eller den version du vill använda. Vid installationen av STK välj att inte installera JRE. Därefter installerar du JRE separat, och installera den i en sökväg som inte innehåller några blanksteg. Efter det installerar du Java3D STK. Ladda ner rätt version, OpenGL eller DirectX. Om DirectX inte finns installerat använd OpenGL versionen, de flesta grafikkort stöder denna och den ger en något bättre prestanda. Vid installationen av STK installeras även Java Plug-In (JPI) som behövs för att köra Java 3D-applets i en webbläsare. Vissa applikationer kräver mer minne än vad som är satt som standard, detta kan ändras genom att gå in i kontrollpanelen och öppna JPI. Välj fliken Avancerade och i parametrar skriver du mx64m vilket ger applikationerna 64Mb minne. De JavaARchive (JAR) som krävs för Java 3D är vecmath.jar, j3daudio.jar, j3dcore.jar samt j3dutils.jar. Dessa skall ligga i katalogen för JRE under lib\ext. JAR filer är komprimerade filer som innehåller alla klasser som är nödvändiga för att köra en Java applikation. De kan öppnas med t.ex. winzip för att se vad de innehåller. Som utvecklingsverktyg kan en editor som heter JCreator användas. Den är gratis att använda och stödjer integration med JavaDoc, vilket är en bra feature men kräver att du laddar ner JavaDoc (ca: 168 Mb). Nu är det bara att sätta igång att utveckla, hjälp med att komma igång med Java 3D hittar du i litteraturreferenser.

___________________________________________________________________________

61

Appendix B – Installation av FSA-Server Installation av FSA-server för simuleringskörningar: För att installera FSA-server krävs att en webbserver finns installerad. Denna installations-anvisning utgår ifrån att Apache som är en gratis webbserver under en GPL-licens används. Kopiera katalogen Stressometer till C:\Stressometer Installera JRE till katalogen C:\"Program Files"\Java\j2re1.4.1_01\ Installera Apache till katalogen: C:\Program Files\Apache Group\Apache Kör filen C:\Stressometer\Application_example\ClosedLoopMechanicalControl\scripts\StartClosedLoop.bat Starta din webbläsare och skriv in din ip-adress. Nu laddas Välj Flatness Control så hamnar du i HMI:et. Installation av SensorFusion För att köra SensorFusion krävs att Java3D API är installerad (se appendix A för instruktioner). Mjukvaran har beroenden med några av filerna i Stressometer för kommunikation. För att köra det med fungerande kommunikation med FSA-server så finns det två möjligheter:

• Kopiera de kompilerade filerna till katalogen: "C:\Stressometer\Application_example\ClosedLoopMechanicalControl\wwwroot\Html_Fsa\NewHMI\SensorFusion"

• Kompilera källkoden in stressometers HmiClient.jar fil.

Starta appleten genom att köra webbsidan SensorFusion.html.

___________________________________________________________________________

62

Index

A

ABB, 3 Automation Products, 3 Force Measurement, 3

Aktuatorer, 20 Böjning, 20 Skevning, 20 Skiftning, 21

Användaranalys, 33 Användarstudier, 36 Användbarhet, 32 API, 10 applet, 10

B

Beteende, 47 broker, 17

D

Deltagande design, 36 Deltametoden, 37 DSDM, 38

E

Excentricitet, 28

F

Flatness Server Architecture. Se FSA FSA, 8

Installation, 12-2

H

HTML, 11 HyperText Markup Language. Se HTML

I

interaktion, 47

J

Java 3D, 12

Installation, 12-1

K

Kontextbaserad design, 36 Kylning, 23

M

Modellbaserad utveckling, 35

O

OpenGL, 12

P

planhet, 19 Position, 28 Prototyping, 36

evolutionary, 37 paper, 37 rapid, 37

Punktvis kylning, 28

R

Reflektera med användaren, 36 Remote Method Invocation. Se RMI RMI, 47 RUP, 38

S

Scengraf, 45 Sensor fusion, 14

T

Temperatur, 27 Tjocklek, 27

U

Uppgiftsanalys, 34 Usability Engineering, 36

___________________________________________________________________________

63

Visualisering av Sensor Fusion Data i Stressometer 6 · Visualisering av Sensor Fusion Data i...

Documents

Transcript of Visualisering av Sensor Fusion Data i Stressometer 6 · Visualisering av Sensor Fusion Data i...