Mälardalens Högskola
Institutionen för Innovation, Design och Teknik
Västerås, Sverige
Examensarbete i Flygteknik 15 hp
UNDERHÅLLSSYSTEM GRIPEN C/D
Simon Algotsson
san12016@student.mdh.se
Jonas Bjenning
jbg12006@student.mdh.se
Examinator:
PhD. Håkan Forsberg
Mälardalens Högskola, Västerås, Sverige
Mentor Högskolan: Tommy Nygren
Mälardalens Högskola, Västerås, Sverige
Mentor SAAB:
Johannes Sandå
SAAB, Linköping, Sverige
Mälardalens Högskola
Sammanfattning
Saab hade önskemål om att slå samman underhållsmanualen och konfigurationslistan för att på så sätt förbättra hur manualerna produceras och underhålls på Gripen C/D. Syftet med detta var att förenkla tolkningen och öka produktionsflödet i manualframställningen. Den utmaning som bemöttes i arbetet låg i att strukturera och reda ut vilken information som var relevant att presentera eller inte. Det skulle även läggas till ny information som tidigare inte presenterats. Det produktionsverktyg som Saab använder idag är komplicerat och svårt att använda, vilket ledde till att Saab även ville se över verktyget samt möjligheten att producera framtidens manualer med hjälp av en databas. Detta arbete fokuserade på att slå samman de två underhållsdokumentent till en lättförståelig layout, samt göra ett förberedande arbete till den tänkta databasen så att en fysisk databasmodellering ska bli så lätt som möjligt att utföra i framtiden.
Genom noggranna studier i hur människan uppfattar det hon läser samt hur information presen-teras på bästa möjliga sätt utan risk för misstolkningar, gavs en inblick i hur det sammanslagna dokumentet skulle kunna se ut. Studier i databasmodellering var även nödvändigt för att få en djupare förståelse i hur databaser byggs upp. Arbetet resulterade i ett layoutförslag på ett sam-manslaget underhållsdokument, där både underhållsmanual och konfigurationslista presenterades i ett liggande format på samma sida. Detta eliminerade helt bläddringen mellan de två olika dokumenten vid tolkning av manualen. Arbetet resulterade även i en förklaring på hur de olika manualerna relaterar till varandra vilket underlättar för en framtida databasbyggnation. Detta kommer om det implementeras att öka produktionsflödet vid framtagandet och vidmakthållandet av underhållsmanualen.
Abstract
Saab wanted to review how todays maintenance manuals are produced and maintained for Gripen
C/D, mainly by merging the maintenance manual and the configuration list. The reason for
this was to simplify the interpretation and increase production flow while producing the manuals. The challenge this thesis had to face was to structure and sort which information were relevant and needed to be featured while also adding new information which is not presented in todays documents. The production tool used today is complex and hard to use which lead to Saab wanting to review the possibility to use a database based production tool instead. This thesis focuses on merging the two documents into a more comprehensible layout as well as doing a preparation for an upcoming database.
Through careful studies in Human Factors and how to easily present information and reducing the risks of missunderstandings an understanding was given in how a merged layout would look. Studies in database modelling was necessary to get a better understanding in how databases are structured. This thesis resulted in a merged document where the maintenance manual and configuration list is presented in a landscape view on the same page. This simplified the interpretation a lot while handling the manual. This thesis also resulted in an explanation of how the documents relate to each other which could be used to build the database in the future. This would, if implemented, increase production flow and maintainability for the maintenance manual.
Mälardalens Högskola
Tack
Vi vill tacka alla personer som under arbetets gång väglett och hjälpt oss fram till
det resultat som presenteras i denna rapport.
Många tack!
Johannes Sandå med kollegor på Technical Publications
Håkan Forsberg
Tommy Nygren
Mirko Senkovski
Joakim Thörnkvist
Håkan Sundblad
Leif Gyllström
Joakim Lundqvist
Karin Högberg
Johan Michelsen
Gabriella Klas
Melker Nordqvist
Mälardalens Högskola Innehållsförteckning
Innehållsförteckning
1 Inledning 6 1.1 Syfte . . . 6 1.2 Problemformulering . . . 6 1.3 Avgränsningar . . . 7 2 Bakgrund 8 2.1 Databas . . . 8 2.2 S1000D . . . 8 2.3 State of Practice . . . 9 3 Metod 10 3.1 Introduktion . . . 10 3.2 Datainsamling . . . 10 3.3 Tidigt förslag . . . 11 3.4 Datagranskning . . . 11 3.5 Sammanställning . . . 11 3.6 Återkoppling . . . 113.7 Resultat och fortsatt arbete . . . 11
4 Tabelldesign 12 4.1 Människan upplever det hon förväntar sig . . . 12
4.1.1 Baserat på erfarenhet . . . 12
4.1.2 Baserat på kontext . . . 12
4.1.3 Baserat på mål . . . 12
4.2 Hjärnan delar själv in objekt i grupper . . . 12
4.3 Hjärnan letar struktur . . . 13
5 Databasdesign 14 5.1 Konceptuell design . . . 14
5.1.1 ER-diagram . . . 14
5.2 Logisk design . . . 17
6 Resultat 19 6.1 Förhållning till S1000D och befintlig design . . . 19
6.2 Designen . . . 19
6.2.1 Prioritering av information . . . 19
6.2.2 Sammanslagningen . . . 22
6.3 Relationer i tänkta databasen . . . 22
6.3.1 Lista entiteter . . . 23
6.3.2 Konceptuell- och logisk design . . . 24
6.4 Relation mellan layout och databas . . . 25
7 Diskussion 26 7.1 Relaterad forskning . . . 26
8 Slutsats 27 8.1 Framtida arbeten . . . 27
Referenser 29
Bilaga A Nuvande form 31
Mälardalens Högskola Innehållsförteckning
Nomenklatur
AIA Aerospace Industries Association of America
ASD AeroSpace and Defence Industries Association of Europe
ATA Air Transport Association of America
CSDB Common Source DataBase
ER Entitet- Realtion
Mälardalens Högskola Figurlista
Figurlista
1 Ett enkelt flödesschema av metoden . . . 10
2 Objekt som är nära varandra upplevs grupperade . . . 13
3 Hjärnan tolkar strukturerad data mycket fortare . . . 13
4 En simpel matris som visar samband mellan entiteter . . . 14
5 ER-diagramet i dess simplaste form . . . 15
6 ER-diagram med 1:N förhållande . . . 15
7 ER-diagram med attribut . . . 16
8 ER-diagrammet som bygger på matrisen i figur 4 . . . 16
9 Entitet med attribut blir tabell där attributen blir kolumner . . . 17
10 Ett "ett-till-många"-samband mellan entiteterna brukare och flygplan, entiteten fly-gplan har fått referensattributet ägare från entiteten brukare. . . 17
11 Visar "många-till-många"-samband där själva sambandet blir en egen tabell . . . . 18
12 Delar av både Undehållsmanualen och Konfigurationslistan . . . 20
13 Det sammanslagna dokumentets sidhuvud . . . 21
14 En liten del av det sammanslagna underhållsdokumentet . . . 22
15 Ett ER-diagram av databasen . . . 24
Mälardalens Högskola 1 Inledning
1
Inledning
Inom flygindustrin ställs höga krav på både flygplanstillverkarna och operatörerna/brukarna för att den verksamhet som bedrivs ska vara så säker som möjligt, detta gäller både den civila och militära luftfarten. Framförallt ställs höga krav på underhållet av flygplanen, det är därför viktigt att de underhållsmanualer som används är så tydliga och lättförståeliga som möjligt. Det ska inte finnas risk för missförstånd eller feltolkningar när ett underhållsdokument utläses.
När underhållsmanualen för Gripen C/D tolkas i dagens läge sker det med hjälp av
underhållsman-ualen i sig själv samt ett bifogat dokument[1], konfigurationslistan. Då en viss underhållsåtgärd ska
utföras, måste den först utläsas i underhållsmanualen angående när och var åtgärden ska utföras. Den som sedan ska planera underhållet får bläddra fram berörd åtgärd i konfigurationslistan för att kontrollera vilka flygplansindivider den berör och i så fall hur dessa individer berörs. Flera olika flygplansindivider kan bestå av flera olika komponenter. Det finns exempelvis flera olika huvar till Gripen C/D trots att det är samma modell. Detta beror bland annat på att gamla Gripen A/B har blivit uppgraderade till C/D.
1.1
Syfte
Syftet med detta arbete är att skapa förslag på hur ett sammanslaget dokument skulle kunna se ut. Underhållsmanualen sammanslagen med konfigurationslistan kommer att ytterligare minska risken för fel i hanteringen, eftersom allt hanteras i ett och samma dokument. Det blir därför mer lättöverskådligt än dagens alternativ.
Saab vill även se över möjligheten att göra en databas av underhållssystemet. Detta på grund av att kunna minska de misstag som lätt kan ske i produktionsverktyget. På köpet fås en snabbare och effektivare produktionsmiljö där underhållsdokumentet genereras med hjälp av en databas. En sammanslagen underhållsmanual tillsammans med ett nytt produktionsverktyg i form av en databas, kommer minska risken för feltolkning och medföra ett ökat produktionsflöde.
1.2
Problemformulering
Ett problem är dagens hantering av flera olika manualer. Personen som tolkar dokumenten hänvisas fram och tillbaka mellan dessa olika dokument och kan därmed lätt missa viktig information. Utöver risken för desinformation tar hanteringen också onödigt lång tid.
De två tabellerna som ska sammanställas tar i dagens läge upp hela bredden på var sitt stående A4-ark. Utmaningen ligger därmed i att få plats med all relevant information i ett och samma dokument utan att det blir för rörigt eller svårläst. I dagens läge går det inte att bara sammanställa dessa i ett liggande format då de inte kommer att få plats. Dokumentet måste dessutom ha plats för eventuella framtida tillägg eller ändringar, och dessa ska vara lätta att införa.
Ett annat problem är produktionsverkyget som används för att skriva manualerna. Arbortext som programmet heter, används för att skriva underhållsplanen. Det är kraftfullt och innehåller många användbara funktioner men problemet är att det inte har ett WYSIWYG-gränssnitt. Detta medför att det är lätt att skriva eller göra eventuella fel och det går åt mycket tid till att felsöka och åtgärda dessa. För att se hur det som skrivits kommer att se ut måste dokumentet uppdateras och sparas, sedan ska programmet stängas ner för att till sist exportera filen till ett pdf-dokument. Först där syns hur det kommer att se ut på riktigt och ska något ändras eller korrigeras måste programmet öppnas upp igen. Den här proceduren kan behöva göras om flera gånger innan det blir som tänkt och detta är därför en process som kan ta onödig tid.
Ibland är det också nödvändigt att göra vissa specifika kundanpassningar, till exempel kan en kund vilja byta ut en komponent till en annan nyare komponent. Då ska detta vara en enkel ändring att göra.
Mälardalens Högskola 1 Inledning
I detta skede börjar nyttan med en databas att bli tydlig. En databas behöver en viss förberedelse i form av kategoriseringar samt att utreda de relationer som finns mellan listorna som de ser ut idag. Därefter kan en programmerare börja bygga databasen. Då är det lämpligt att personer med flygteknisk grund gör denna kategorisering, eftersom dessa har mer kunskap om vilken information som är relevant att presentera. Det är dessutom personer med flygteknisk bakgrund som kommer använda och vidmakthålla det färdiga resultatet.
När ett nytt system utformas är det viktigt att det säkras gentemot framtida behov. Det ska vara möjligt att modifiera information eller design utan att något blir lidande. En databas är i sig själv en bra framtidssäkring eftersom en sådan är enkel att anpassa och ändra under tidens gång. Senare skulle en databas även kunna vara implementerbar i en interaktiv miljö. En virtuell
underhållsdatabas är något som anses vara nästa stora steg inom underhållssystem[2,3,4].
1.3
Avgränsningar
Att modellera och bygga upp en databas av den storlek som detta jobb undersöker är ett stort arbete som kräver mer kunskap och framförallt tid. Detta arbete reder endast ut relationen mel-lan underhållsdokumenten i syfte att förbereda inför en databas. Databasen som föreslås följer inte helt den standard som Saab använder sig av, S1000D. Denna är endast tänkt att ses som ett produktionsverktyg för att producera den sammanslagna underhållsplanen som presenteras i arbetet.
Hur produktionsverktyget sedan ska se ut, annat än att det blir en databas, tas inte upp i detta arbete. Det vill säga det grafiska gränssnittet som databasen bygger på. Arbetet belyser inte heller hur migreringen ska gå till, det vill säga hur övergången mellan nuvarande system till det system som föreslås i arbetet ska fungera.
Mälardalens Högskola 2 Bakgrund
2
Bakgrund
Saab har tillsammans med sina kunder/brukare problemet att det blir mycket bläddring fram och tillbaka mellan underhållsmanualen och konfigurationslistan. Detta ville Saab först lösa genom att slå samman dessa med varandra. Detta arbete växte sedan till att även se över hela underhålls-planen, både hur den tillverkas och dess layout. I dagsläget använder Saab ett produktionssystem som kan liknas vid HTML-kodning, en produktionsmiljö där det är lätt att göra små misstag men som kan ta mycket tid att åtgärda.
Eftersom programmet är svårt att använda tar det mycket tid för ingenjörer då de ska göra kun-danpassningar i underhållsmanualerna eller skapa nya kundspecifika underhållsmanualer. Oftast då en ny manual behöver produceras tenderar Saab att välja ut en redan befintlig manual som är mest lik den nya kundens och modifiera denna. En databas som innehåller underhållsdata som gäller för alla brukare, skulle därför underlätta framtagandet av en ny underhållsmanual. Behöver sedan kundanpassningar göras behövs bara kundspecifik data matas in i databasen för att sedan generera den kundens underhållsmanual.
Med en ny layout på ett sammanslaget underhållsdokument får både ingenjörer som skriver man-ualerna samt underhållsplanerare och tekniker all relevant information på en och samma sida. De slipper då onödig bläddring mellan flera dokument och minskar därmed både tidsåtgång och risker för felskrivning, felläsning och misstolkningar.
2.1
Databas
En databas är en samling information som är strukturerad på ett sådant sätt att det lätt går att hitta enskild information om ett specifikt objekt. Den fungerar i princip som flera olika tabeller som relaterar till varandra med hjälp av unika värden per rad i respektive tabell, dessa värden kallas nyckelvärden. Nycklarna relaterar då till varandra på ett sätt som gör att de tillsammans
skapar ett unikt objekt[5,6].
2.2
S1000D
Saab använder en standard som heter S1000D. Detta är en internationell standard för tekniska publikationer som ursprungligen utvecklades och utgavs av ASD, men numera är även AIA och ATA e-Business Program ansvariga utgivare. Standarden används mestadels inom försvarsindustrin,
men den används även inom civilflyget, byggnadsindustrin samt varvsindustrin[7].
S1000D bygger på en princip där innehållet delas upp i datamoduler[1,8]. Dessa datamoduler är
fristående och kan innehålla data som är operativ, processuell eller beskrivande och relaterar till en komponent, en plattform eller ett system. Datamodulerna är i sin tur uppdelade i två delar: identifikation och status samt innehåll.
Den del som består av identifikation och status innehåller information om hur datamodulen hanteras i systemet. Den del av datamodulen som behandlar innehållet består av beskrivande information om ett system eller den uppgift/åtgärd som modulen behandlar.
Hela S1000D innesluts i en databas, CSDB, som hanterar och behandlar alla datamoduler som hela systemet är uppbyggt av. Standarden ställer inga krav på hur funktionen i en datamodul ska
Mälardalens Högskola 2 Bakgrund
2.3
State of Practice
Slå samman olika tabeller, optimera underhållssystem samt bygga databaser är något som sker kontinuerligt med olika syften inom många branscher. Däremot ett fall där en flygplanstillverkare i försvarsindustrin har slagit samman konfigurationslistan med underhållsplanen i syfte att förenkla tolkningen av underhållsplanen samt optimera produktionsflödet är svårt att hitta arbeten om. Eftersom försvarsindustrin som regel är väldigt insynsskyddad är det inte lätt att få ta del av jämförbara arbeten som gjorts på liknande företag. Detta arbete skiljer sig därför från andra arbeten på grund av kombinationen av tabellsammanslagning samt förberedandet för en databas, i syfte att optimera hela underhållssystemet utifrån tillverkarens perspektiv.
Optimering av underhållsprogram har det gjorts på Mälardalens Högskola förut[10, 11].
Skill-naden gentemot dessa är att de fokuserar på en optimering från brukarens perspektiv, ofta för att få ett så kostnadseffektivt underhållsprogram som möjligt. Detta arbete fokuserar inte i sig på kostnadseffektivisering, men det blir en sidoeffekt av att få ett förbättrat produktionsflöde. Detta examensarbete fokuserar på Human Factors i underhållsmanualens layout, eftersom det är den som sedan brukaren ska basera sitt underhållsprogram på. Detta medför att produktionsflödet ökar eftersom missförstånden minskas. Därför blir underhållssystemet säkrare och effektivare. När det kommer till tabelldesign är det viktigt att tänka på att människans syn är programmerad att se mönster och figurer. Ibland kan också hjärnan lura oss och fylla i linjer eller mönster som inte finns för att få en komplett bild. Därför är det viktigt att också ha i åtanke hur människan fungerar när man designar tabeller för att skapa lättlästa sådana, där det tydligt framgår vilka
kolumner och rader som tillhör varandra[12,13,14].
Vid förberedelser inför en databasbyggnation är det viktigt att tänka på att skapa en så struktur-erad indata som möjligt. Genom att på ett bra sätt kategorisera all data och information som ska föras in i en databas så kommer relationerna i databasen fungera bättre och den kommer att bli
lättare att bygga[5,6,15].
Det finns viss forskning på underhållssystem i sig, att däremot hitta en studie gjord hos en fly-gplanstillverkare inom försvarsindustrin är betydligt svårare. I en studie gjord på hela system, betonas vikten av ett väl fungerande underhållssystem. Författaren till studien belyser hur viktigt det är att tänka på Human Factors i systemdesign. Det förklaras hur lite förståelse det normalt finns för Human Factors vid utvecklingen av ett system samt hur viktigt det är att ta denna i
Mälardalens Högskola 3 Metod
3
Metod
Innan examensarbetets start öppnades en dialog med Saab och högskolan angående de önskemål och målsättningar som de hade på arbetet. Detta för att minska eventuella missförstånd mellan Saabs önskemål och de krav som skolan ställde på arbetet. I figur 1 illustreras metoden och följs sedan av förklaringar på varje steg i figuren.
Figur 1: Ett enkelt flödesschema av metoden
3.1
Introduktion
I början av arbetet handlade det mestadels om att få en djupare förståelse för arbetets mål och syfte. Saab såg gärna att arbetet fortfarande bibehöll sitt ursprungliga fokus på att sammanföra konfigurationslistorna med underhållsmanualen, men även titta på möjligheterna att hantera detta i en databas. Eftersom examensarbetet skulle handla om flygteknik blev det svårt att även ta med databasbyggande i det. Kompromissen hamnade i att förbereda för en databas samt presentera förslag på alternativa layouter med en sammanslagen underhålls- och konfigurationsdel.
3.2
Datainsamling
När examensarbetet väl var inramat började litteraturstudierna. En bättre och djupare kunskap om hur tabeller bör se ut ur ett Human Factors-perspektiv samt hur databasförberedning går till. Det behövdes kunskap om hur databaser modelleras och struktureras för att en datatekniker lättare ska kunna ta vid och fysiskt modellera databasen.
Information angående vilka som kan komma att bruka det system som presenteras i arbetet behövde
kartläggas. Personer i hela produktionsledet på Saab samt deras brukare kontaktades för att
undersöka hur de använder dokumenten i dess nuvarande form. Detta för att få en tydligare bild av problemet.
Samtal med personal på IT-avdelningen hjälpte till att rama in vad som skulle göras runt databas-delen. Av samtalen framkom att det bästa vore att göra en så bra förberedning som möjligt. Det var underlättande för dataavdelningen att personer med flygteknisk grund gjorde så mycket av databasens underlag som möjligt eftersom personer som jobbar på dataavdelningen inte är lika pålästa om flygplansunderhåll och flygplanstermer. Det ansågs därför som en felförebyggande åt-gärd att flygingenjörer strukturerade upp databasens innehåll med avsikt att sedan lämna över arbetet med den fysiska modelleringen av databasen till dataavdelningen.
Ett bra bollplank att jobba gentemot då det gällde layouten på underhållsmanualen var Saabs kognitionsvetare. Det var en fördel att kunna presentera ett layoutförslag och sedan få direkt återkoppling om huruvida designen var begriplig eller inte. Till exempel vilka kolumner och rader som marginaliserades alternativt blev i för stort blickfång gentemot innebörden.
Mälardalens Högskola 3 Metod
Saab ställde inga krav på att arbetets resultat skulle följa S1000D-standarden till punkt och pricka, däremot skulle det bara vara positivt om resultatet liknade standarden. Därför blev det även nödvändigt med samtal med experter inom området S1000D och det tillhandahölls information angående detta från företagets sida.
3.3
Tidigt förslag
Genom att tidigt presentera ett förslag för både de som jobbar i dokumenten och andra berörda avdelningar, exempelvis kognitionsvetare och IT-avdelningen på Saab, kunde både positiv och
negativ kritik inhämtas. Detta var för att säkerställa att arbetet fortfarande fortskred i rätt
riktning och höll önskad kvalité.
3.4
Datagranskning
När all nödvändig data var insamlad påbörjades den fas i arbetet där syftet var att sortera in-formation som samlats in efter dess relevans. Inin-formationen som ansågs intressant för arbetet sorterades sedan upp i kategorierna: tabelldesign, databas, regelverk samt Saabs önskemål. Detta för att på så sätt kunna reda ut vad som var de viktigaste aspekterna att tänka på för att uppnå bästa möjliga resultat.
3.5
Sammanställning
I detta skede av arbetet sammanställdes ett förslag på ett tänkbart resultat baserat på den data som samlats in. Detta var ett steg som ofta återkom eftersom återkopplingen som gjordes i nästa steg ofta innehöll ny information och nya infallsvinklar som blev nödvändiga att beakta. Tanken med detta var att kunna ta fram flera förslag och därför ansågs detta som en bra metod.
3.6
Återkoppling
Då ett förslag på ett resultat uppnåddes återkopplades det framtagna materialet mot datagransknin-gen. Detta för att stämma av att det uppfyllde de krav och bemötte de önskemål som fanns samt att materialet stämde överens gentemot de källor som använts.
3.7
Resultat och fortsatt arbete
När materialet återkopplats mot datagranskningen och ansågs uppfylla de krav och önskemål som ställts, delades detta upp i två delar. Den ena delen, resultatdelen, innehöll arbetets slutgiltiga resultat. Den andra delen, fortsatt arbete, innehåller resultat som skulle gå bygga vidare på och information som insamlats under arbetets gång som gick utanför examensarbetets avgränsningar. Därför var detta inget som arbetet skulle beröra.
Mälardalens Högskola 4 Tabelldesign
4
Tabelldesign
Det system som presenteras i detta arbete är beroende av att det knappt ska vara möjligt att misstolka den information som presenteras. I systemkonstruktion är Human Factors det som ofta
anses som svårast att förstå[16].
I detta avsnitt kommer det därför förklaras lite kortfattat om Human Factors. Hur människan tolkar den information som presenteras, att hjärnan vill hitta mönster samt till hur stor del intu-itionen påverkar tolkandet av den information som presenteras.
4.1
Människan upplever det hon förväntar sig
Människans uppfattning av dess omgivning bygger till stor del på förväntningar och tidigare up-plevelser av liknande situationer. En person uppfattar den givna situationen enligt: erfarenhet,
kontext och målet med situationen[17].
4.1.1 Baserat på erfarenhet
Hjärnan sorterar och tolkar information baserat på tidigare upplevelser. För en person som tidigare upplevt en liknande situation som hon nu befinner sig i förväntar sig hjärnan samma resultat denna gång. Det kan exempelvis vara kopplat till ett ljud, om en person hör en katt jama utan att se den, förutsätter personen per automatik att det är en katt som låter och inte något annat.
4.1.2 Baserat på kontext
En person som befinner sig i en miljö som hon är van vid, drar slutsatser baserat på kontexten. Låt säga att en vaktmästare på ett flygfält får i uppgift att sanera ett avgasläckage. Dennes hjärna vet att det rör sig om ett bränslespill eftersom dennes uppgift är att sanera, samt att det sannolikt inte är första gången personen kommer i kontakt med avgas (aviation gasoline) och personen dessutom befinner sig i en kontext där avgas är bränsle och inte förbränt bränsle. Det kanske inte ter sig lika självklart för en person som aldrig stött på avgas. Låt säga en nyanställd vaktmästare, denne skulle troligen ifrågasätta hur situationen ska hanteras.
4.1.3 Baserat på mål
Då en person har ett specifikt mål med en situation tenderar denne att sortera bort irrelevant information baserat på målet. Exempelvis kan en person bli ombedd att i ett främmande garage lokalisera verktygslådan och i den hämta en polygrip. Skulle personen då hon kommer tillbaka med polygripen få frågor om vilka andra verktyg som fanns i lådan skulle hon troligtvis inte kunna svara på dessa frågor. Inte heller på frågan om det till exempel stod en flaska med smörjmedel på hyllan ovanför verktygslådan. Detta eftersom hjärnan sorterar bort information som inte är
relevant för målet[14].
4.2
Hjärnan delar själv in objekt i grupper
Hjärnan tenderar att dela upp mönster i grupper. I figur 2 går det att se hur hjärnan delar upp objekt som ligger nära varandra till grupper. Människan tolkar den vänstra delen av figur 2 som kolumner medan den högra delen upplevs som rader.
Mälardalens Högskola 4 Tabelldesign
Figur 2: Objekt som är nära varandra upplevs grupperade
Detta är någonting som går utmärkt att utnyttja i tabelldesign. Då hjärnan redan delar upp objekt
i grupper kan det med fördel vara möjligt att utesluta så mycket linjer som möjligt i en tabell[13],
se höger bild i figur 3, då dessa ofta kan skapa en viss förvirring och ibland leder till att en tabell kan se plottrig ut. Viktigt att tänka på i tabellskapande är att all text bör helst vara horisontell
och konsekvent. Vid sidbrytningar bör helst rubrikerna för tabellerna följa med[13].
4.3
Hjärnan letar struktur
Hjärnan letar struktur och mönster. Därför är det viktigt att presentera data så strukturerat som möjligt och bygga visuella hierarkier.
Figur 3: Hjärnan tolkar strukturerad data mycket fortare
I figur 3 går det tydligt att se fördelen med en strukturerad text. Ett kvitto som skulle skrivas ut i löptext ter sig närmast idiotisk eftersom det, som figur 3 visar, skulle det bli väldigt svårtolkat. Att bygga visuella hierarkier är väldigt användbart då något ska ligga i fokus. I figur 3 framgår det väldigt fort och tydligt i den högra bilden var kvittot kommer ifrån, delvis på grund av ett större typsnitt och delvis på grund av fet text.
Figur 3 visar även på en tydlig matematisk modell som är enkel att förstå och själv kontrollera. I samma figur går det även, baserat på kontext, förstå en förkortnings innebörd. Det är uppenbart
Mälardalens Högskola 5 Databasdesign
5
Databasdesign
Eftersom arbetet skulle förbereda inför en databas behöves information samlas in om hur databaser modelleras. De personer som senare kan komma att modellera denna måste förstå den struktur som i arbetet tagits fram. Vem som helst med databakgrund ska förstå strukturen som föreslås. Litteraturstudier gav den kunskap som presenteras i den här teoridelen.
Modellering av databaser sker i tre faser: konceptuell design, logisk design samt fysisk design.
Design kan ibland kallas modellering och syftar till samma sak[18]. Den första fasen, konceptuell
design, beskriver databasen i text och med ER-diagram. Logisk modellering översätter den kon-ceptuella modellen i en logisk modell och har som huvudsyfte att göra den lagringsbar i en databas. I det fysiska modelleringsstadiet skapas tabellerna fysiskt och det bestäms vilka datatyper
at-tributen ska ha[19]. Detta arbete kommer inte att beröra fysisk modellering.
5.1
Konceptuell design
Viktigt i detta steg är att databasen beskrivs så att en "icke-teknisk" person ska förstå strukturen. En fördel är därför att först förklara databasen i vanlig text som så noga och enkelt som möjligt förklarar målet med databasen, vad databasen ska lösa. Här följer ett exempel på hur en sådan text kan se ut:
"Databasen beskriver sambandet mellan brukare, flygplan och underhåll. En brukare ska kunna äga och/eller leasa sina flygplan och en brukare ska underhålla sina flygplan. Underhållet ska vara uppdelat i underhållsobjekt, varje sådant ska innehålla information om behörighet, åtgärd samt åtgärdskod. En brukare identifieras med företagsnamn, organisationsnummer samt adress. Ett flygplan ska i databasen innehålla information om namn på flygplanet, namnet bygger på tillverkare och modell. Det ska även innehålla registreringsnummer samt passagerarantal."
När den beskrivande texten av databasen är färdigställd påbörjas arbetet med att skriva ner alla entiteter, dessa blir ofta tabellerna i det slutgiltiga resultatet. Ett enkelt sätt att sedan få bra
överblick på samband mellan entiteter är att rita upp dessa i en matris[18], se figur 4.
Figur 4: En simpel matris som visar samband mellan entiteter
Samband finns i de flesta fall åt båda håll, men för enkelhetens skull tas endast det mest relevanta hållet med. Då matrisen är färdigställd och entiteterna dess relationer är klargjorda påbörjas byggandet av ett ER-diagram.
5.1.1 ER-diagram
ER-diagrammet beskriver sambandet mellan entiteterna på en visuell nivå i form av ett schema där en fyrkantig låda representerar en entitet och en diamant representerar ett samband, figur 5.
Mälardalens Högskola 5 Databasdesign
Figur 5: ER-diagramet i dess simplaste form
Då alla entiteterna har fått sina samband klargjorda påbörjas arbetet med att ange vilken sorts samband de har, det vill säga reda ut kardinaliteten mellan entiteterna. Dessa finns i följande format:
• 1:1 = "ett-till-ett"-samband • 1:N = "ett-till-många"-samband • N:1 = "många-till-ett"-samband • N:M = "många-till-många"-samband
Här bör belysas att N och M representerar "många", allt mellan 0 och oändligheten.
Figur 6: ER-diagram med 1:N förhållande
Det som kan ses på figur 6 kallas för "ett-till-många"-samband, 1:N, det vill säga ett flygplan har flera underhållsobjekt och flera underhållsobjekt tillhör ett flygplan. Låt säga att det i en databas är bestämt att det endast får finnas ett flygplan, då kan sambandet inte bli annat än 1:N. Ett N:1, "många-till-ett"-samband skulle kunna användas då det i databasen finns en brukare som exempelvis leasar flera flygplan, se figur 8.
1:1, "ett-till-ett"-samband, kan förklaras med att en pilot endast kan flyga ett flygplan åt gången samt N:M, många-till-många-samband, figur 8, som förklaras med att många brukare underhåller
många flygplan[20].
När ER-diagrammet kommit så långt att sambanden och kardinaliteterna är klargjorda mellan alla entiteter påbörjas en fas där det fastslås vilka attribut varje entitet har. Attribut ritas som ovaler. Om ett attribut är understruket markerar det något unikt, exempelvis ett personnummer, och kallas därför nyckelattribut. Exempel på detta kan ses i figur 7, två flygplan kan inte ha samma registreringsnummer.
Mälardalens Högskola 5 Databasdesign
Figur 7: ER-diagram med attribut
Figur 7 visar ett ER-diagram mellan flygplan och underhållsobjekt. Det går att utläsa från dia-grammet att ett flygplan går att identifiera med passagerarantal, namn och registreringsnummer,
där det sistnämnda är unikt för varje plan. Namnattributet delas i sin tur upp i attributen
tillverkare och modell, detta blir ett så kallat sammansatt attribut. Underhållsobjektet går att identifiera med behörighet, åtgärd och åtgärdskod, där åtgärdskod är en nyckel.
Då samband, attribut och kardinaliteter är klargjorda är det den sista modelleringen kvar, hela ER-diagrammet.
Figur 8: ER-diagrammet som bygger på matrisen i figur 4
Det framgår i diagrammet att en brukare kan ha flera samband mellan olika flygplan. Det som är nytt i figur 8 är dubbelstrecken som går via sambandet "underhåller". Dubbelstrecken indikerar ett "måste"-förhållande. I figur 8 måste alltså en eller flera brukare underhålla flygplan. Hade dubbelstrecket endast gått mellan "Brukare" och "underhåller", hade streckets innebörd varit
Mälardalens Högskola 5 Databasdesign
att en brukare (eller flera, alternativt ingen) måste underhålla något, dock inte specifikt vad en brukare skulle vara tvungen att underhålla. Följaktligen om dubbelstrecket endast hade gått mellan "underhåller" och "Flygplan" hade det inneburit att många flygplan skulle behöva bli underhållna,
men det hade inte specificerats av vem eller vilka[20].
5.2
Logisk design
I det logiska designstadiet handlar det om att översätta ER-diagrammet till ett diagram med tabeller istället. Dessa tabeller går sedan att använda i relationsdatabaser som ska fungera enligt
ER-diagrammet som skapades i det konceptuella steget[15]. För att tydliggöra sambanden mellan
dessa tabeller finns det ett antal riktlinjer att ta till hjälp. Det som i ett ER-diagram är entiteter blir i den logiska designen en egen tabell med samma namn som entiteten. Entitetens attribut blir kolumner i tabellen. Se figur 9.
Figur 9: Entitet med attribut blir tabell där attributen blir kolumner
Består ER-diagrammet av flera entiteter med olika samband mellan varandra kan även sambanden bli tabeller beroende på vilken sorts samband det är mellan entiteterna. Om det i ER-diagrammet finns entiteter med ett "ett-till-många"-samband, figur 10, får den entitet som står på "många"-sidan ett referensattribut som då kopplar till entiteten på "ett"-"många"-sidan. Hade entiteterna istället haft ett "ett-till-ett"-samband hade det funnits flera olika sätt att skriva tabellerna på. Antingen får en av tabellerna ett referensattribut från den andra tabellen eller kan de slås ihop till en tabell. Vilket av dessa alternativ som är bäst att välja är olika från fall till fall.
Figur 10: Ett "ett-till-många"-samband mellan entiteterna brukare och flygplan, entiteten flygplan har fått referensattributet ägare från entiteten brukare.
När entiteterna istället har ett "många-till-många"-samband blir själva sambandet en tabell i sig. "Sambandstabellen" tar då ett nyckelattribut från varje entitet, vilket behövs för att koppla ihop de båda entiteterna. Detta visas i figur 11.
Mälardalens Högskola 5 Databasdesign
Mälardalens Högskola 6 Resultat
6
Resultat
I denna del kommer de resultat som arbetet kom fram till att presenteras. Resultatet av det sammanslagna dokumentet finns att utläsa i bilaga B, här presenteras lite kort om tillvägagångsätt för designen och databasmodelleringen.
6.1
Förhållning till S1000D och befintlig design
I S1000D finns endast rekommendationer och förslag på hur designen i en utskriven underhållsplan
ska se ut, det vill säga layouten[8]. Teoretiskt kan underhållsplanen på papper presenteras nästan
hursomhelst, så länge den besvarar frågorna: • Vad ska underhållas?
• När ska det underhållas? • Var underhållet ska utföras? • Hur underhållet ska utföras? • Vilken sorts underhåll ska utföras? • Vem ska utföra underhållet?
För att förenkla en eventuell omställning till den design som presenteras i detta arbete behölls så mycket som möjligt av den nuvarande layouten. I bilaga B går det läsa vilka kolumner i resultatet som besvarar dessa frågor.
Databasen som beskrivs längre ner i texten är avsedd att användas som produktionsverktyg. I den
har det inte tagits hänsyn till S1000D[21], utan den modelleras utifrån hur de dokument som ska
sammanställas ser ut i dagens läge. Dock bygger dessa dokument på standarden.
6.2
Designen
Efter samtal med alla som kan tänkas komma i kontakt med det färdiga resultatet kvarstod huvud-målet, nämligen att slå ihop konfigurationsdelen med underhållsdelen. Detta var något som alla var överens om skulle underlätta tolkningen och produktionsflödet. Önskemål som dök upp både från Saab och kund var att inkludera nya kolumner med information om behörighet på vem som får utföra underhållet, tolerans på intervallet och en tabell som i detta arbete kallas "Extended designation".
Eftersom en del av arbetet bygger på att byta ut produktionsverktyget till en databas, användes fördelarna med en databas då det blev aktuellt att designa slutresultatet. Den design som presen-teras i detta arbete blir besvärlig att använda i dagens produktionsverktyg. Skulle det i framtiden bli nödvändigt med en ny rad blir allt förskjutet från den nya raden och neråt och det kan bli snett och missvisande längre ner i tabellen. Att då sitta och korrigera allt detta varje gång ett underhållsobjekt får en ny rad av någon anledning skulle leda till mer arbete än vad det är i dagens system.
6.2.1 Prioritering av information
Detta arbete har utöver sammanslagningen av underhållsdokumenten också undersökt vilken in-formation som verkligen är nödvändig att presentera. Det har lett till att det tillkommit nya kolumner och rubriker som inte finns med i något av originaldokumenten. Kolumner har också tagits bort eller ändrats för att användas på ett mer intuitivt sätt. Tanken är att endast visa relevant information som hjälper läsaren utan att det blir rörigt. Det ska gå snabbt och enkelt
Mälardalens Högskola 6 Resultat
att läsa och hitta i en underhållsmanual och det ska inte förekomma upprepningar eller onödig information.
Ett fall är rubriken "Abbreviated stores name" som återfinns i den första kolumnen i konfigura-tionslistan, som i det sammanslagna dokumentet endast blir en upprepning på "Denomination" som återfinns som kolumn två i underhållslistan. När dokumenten är separerade från varandra är dessa kolumner relevanta för att läsaren ska kunna referera mellan listorna, figur 12, men inte då båda återfinns i samma dokument, figur 13. Ett annat fall är de två kolumnerna "Action on" och "CWS" och som har de två rubrikerna "Action - peace" och "Action - war" under. Det handlar alltså om två kolumner som totalt har fyra "informationsfält".
• "Action - on" talar om ifall ett underhåll av en komponent kan göras medan komponenten sitter på flygplanet eller om den måste plockas bort för att det ska gå att utföra arbetet. Här kan det bara stå On eller Off, se figur 12.
• "CWS" talar om var en enhet eller del ska skickas utifall underhållet ska utföras av någon verkstad då den plockats bort från planet. Denna kolumn används endast då informationen i kolumnen "Action on" visar Off, den relaterar till kolumnen bredvid genom att skriva CWS. I kolumnen CWS står var delen ska skickas. Detta är onödig dubbelinformation som snarare förvirrar än hjälper läsaren, se bilaga A.
• "Action - peace" talar om var eller av vem ett underhåll ska utföras i fredstid. Här kan det exempelvis stå "S-plut" som är den personal som exempelvis gör funktionstester och annat lättare underhåll.
• "Action - war" är precis som ovannämnda fast gäller alltså endast i krigstid.
Mälardalens Högskola 6 Resultat
Figur 13: Det sammanslagna dokumentets sidhuvud
De fyra ovan nämnda informationsfält går att förenkla och förminska rejält. Till att börja med går det helt att slumpa rubriken "CWS" på grund av att information om var en enhet ska underhållas kan stå i fältet för Action-peace istället. Detta är möjligt eftersom en enhet alltid ska skickas iväg då det står CWS istället för S-plut, eller något annat i Action- peace-fältet. CWS skrivs alltså i nuläget endast ut då en enhet ska skickas iväg och då kan man skriva var den ska skickas direkt. Det är inte nödvändigt att i en kolumn skriva att en del ska skickas iväg för att i en annan kolumn skriva var den ska skickas. Teknikerna som utför underhållet vet baserat på erfarenhet och kontext att delen ska skickas till Saab Aerotech i Linköping om det endast står SAT/L.
Det finns två hela kolumner till som går att ta bort i nuvarande utförande då de inte används. Rubriken Action-war går att ta bort helt från underhållslistan då den endast används i krigstid och i dagens manual innehåller den ingen information. Den eventuella informationen om vem som ska underhålla vad i krigstid går i framtiden att lagra i den tänkta databasen istället, förutsatt att tillgång alltid finns till denna. Så länge det är fredstid visas endast Action-peace och vid ett eventuellt krig går det då att välja att endast visa Action-war istället. Den kolumn som ligger under Qty/prod som benämns "-" är en kolumn som inte används och är därför onödig.
Som ovan nämnt har det också tillkommit tre kolumner eller informationsfält vilket kan ses i figur 14. Den ena är en kolumn, Knowledge, som talar om vilken utbildning eller behörighet personalen måste ha för att få utföra en viss åtgärd. Den presenteras direkt bredvid själva åtgärden så att en planerare snabbt och enkelt kan utläsa vad som krävs för en viss åtgärd.
Den andra är ett informationsfält i en redan befintlig kolumn. Det är Tolerance och ligger i samma kolumn som Interval/Uom därför att dessa två befinner sig i samma kontext. Den talar om ifall det finns någon specifik eller generell tolerans på exempelvis hur många timmar ett underhåll kan förskjutas utöver det angivna intervallet. Det kan antingen röra sig om en exakt siffra eller en procentsats. Exempelvis kanske en underhållsåtgärd ska utföras efter 100 flygtimmar men åtgärden måste vara gjord efter senast 105 flygtimmar för att det inte ska bli flygförbud på det flygplanet. Finns inget intervall finns inte heller någon tolerans. Saab har önskat att toleransen ska presenteras som bokstavskoder. Hur dessa ska se ut och vad dessa ska innebära är ännu inte fastställt från företagets sida.
Mälardalens Högskola 6 Resultat
Figur 14: En liten del av det sammanslagna underhållsdokumentet
Den tredje tabellen som tillkommit Exended Designation ligger som ett extrafält i varje flygplan-skonfiguration, som kan ses i Bilaga B. Denna kolumn har kommit till på grund av kundönskemål. Kunden önskade ha denna kolumn för att kunna utöka kompabiliteten gentemot deras eget system. De tre kolumner som tillkommit i det förslag som presenteras i bilaga B kan komma ändras. Tolerance och Knowledge har i bilagan fiktiva värden då det inte bestämts hur de ska presenteras. Värdena i Extended Designation är i bilagan tagna från Saabs produkthanteringssystem.
6.2.2 Sammanslagningen
Resultatet på det sammanslagna dokumentet som fick bäst kritik utav alla de som presenterades under arbetets gång är det som kan ses i bilaga B. Det är alltså arbetets slutgiltiga resultat. Där kan ses att det inte är helt olikt originaldokumenten, vilket är avsiktligt, där största skillnaden som kan ses är att förslaget presenteras som ett liggande format. Det är likt originaldokumenten för att en läsare ska känna igen sig även i det nya, sammanslagna, dokumentet och därmed kunna börja jobba direkt utifrån det. Dokumentet börjar med att varje Maintenance Object ligger i en rubrik tillsammans med Denomination, Installation location, Qty/prod och Type. Detta för att det då tydligt syns att ett nytt Maintenance Object börjar, det går lätt att läsa ut informationen i rubriken samt att på detta sett sparas plats för de andra kolumnerna under rubriken. Det blir därmed inte lika rörigt, vilket det blir om all information ska ligga i egna kolumner. Personen som tolkar dokumentet kan tydligt se rubriken för varje objekt om denne letar efter en specifik rubrik i dokumentet. På nuvarande sätt sparas platsen motsvarande fyra kolumner in. I och med ett större utrymme går det också i framtiden lägga till fler kolumner om det blir aktuellt.
Dokumentet har sin konfigurationslista till vänster och underhållslista till höger och dessa skiljs
åt med hjälp av ett lodrätt, heldraget, streck för att göra det hela tydligare. Det heldragna
strecket går dock inte genom rubrikerna eftersom dessa annars lätt försvinner in i mängden av information. Nu blir det istället ett tydligt avbrott i det lodräta strecket vilket talar om att ett nytt underhållsobjekt börjar.
6.3
Relationer i tänkta databasen
En beskrivning av relationerna i den tänkta databasen och vad som ska finnas med i den, enligt teorin om databasmodellering, har i detta arbete inte gjorts. Detta på grund av att det redan finns färdiga tabeller med respektive läsmanualer, och är därför att anse som överflödigt.
Mälardalens Högskola 6 Resultat
6.3.1 Lista entiteter
I punktlistan nedan listas de entiteter som kommer finnas i databasen med dess tillhörande attribut som underpunkter. I vissa fall har även underpunkterna underpunkter, dessa är sammansatta at-tribut, förutom "Länk till Pub. Ref.", som är en entitet.
• Maintenance Object – Maintenance Object – Installation Location – Denomination – Qty/prod ∗ C ∗ D – Type • Aircraft Effectivity – Stores Designation – Original Designation – Reference Designation – Other Designation – Extended Designation – Configuration note • Action Code – Action Code – Länk till Pub. Ref. – Peace ∗ Interval Operations ∗ Tolerance Op ∗ Interval Storage ∗ Tolerance St – War ∗ Interval Operations ∗ Tolerance Op ∗ Interval Storage ∗ Tolerance St – Level – On/Off – FENIX ∗ Op ∗ St
Mälardalens Högskola 6 Resultat
– Knowledge – Remark – Note
– Action Definition
6.3.2 Konceptuell- och logisk design
I Figur 15 visas ett ER-diagram på hur databasen kommer att se ut. Där syns sambanden mellan de ovan listade entiteterna och deras olika attribut. Det är också tydligt att hela diagrammet kret-sar kring Maintenance Object som har ett "många-till-många"-samband till Config. Maintenance Object har det sambandet till Config eftersom många olika underhållsobjekt kan tillhöra många olika konfigurationer. Maintenance Object har också ett "ett-till-många"-samband till Task efter-som varje underhållsobjekt kan ha en eller flera olika åtgärder efter-som ska göras. Task har därifrån ett "många-till-ett"-samband till Publication Reference då flera olika åtgärder ibland refererar till samma beskrivningsdokument. Task har också ett "ett-till-ett"-samband till både War och Peace vilket är på grund av att till varje åtgärd måste det finnas information om när åtgärden ska utföras samt om den har en eventuell tolerans. De två sistnämnda har precis samma attribut eftersom det är tänkt att bara en av dessa två entiteter ska visas beroende på om det är freds- eller krigstid.
Figur 15: Ett ER-diagram av databasen
Entiteten längst till vänster i figur 15, Config, finns där för att göra det så enkelt som möjligt för de som producerar manualerna. Underlaget till konfigurationslistan kommer som en stor excelfil som sedan skrivs av manuellt och förs in i det nuvarande programmet. Enklast vore här att låta databasen hämta värden direkt från underlaget. Därför är då Plane nr, flygplansindivid, en relation mellan Maintenance Object och Config. detta för att på så sätt kunna filtrera databasen efter en specifik individ. Detta bygger dock på att informationen som kommer till databasen
Mälardalens Högskola 6 Resultat
i konfigurationsunderlaget är tydlig med vilka individer det gäller, alternativt att det matas in manuellt då nytt underlag kommer. Viktigt är i sådant fall även att databasen kan gruppera alla individer av viss typ till en grupp, exempelvis 39C, i de fall den ska skriva ut en fullständig underhållsmanual.
Något som också är värt att anmärka på i figur 15 är det faktum att "Maintenance Object" är den enda entiteten som har nyckelattribut. Entiteten "Config." har två attribut som nästan kan fungera som nycklar, "Stores designation" och "Original Designation", eftersom de alltid är unika. Tyvärr förekommer de inte överallt i konfigurationslistan utan kan ibland representeras av ett tomt fält. I figur 16 går det se hur databasen skulle kunna tänkas se i den logiska designen.
Figur 16: Databasen logiskt modulerad
På grund av att det saknas nyckelattribut i nästan alla entiteter måste dessa skapas. Dessa
behöver inte presenteras i den färdiga planen, utan är bara att se som just nycklar med enda syfte att identifiera respektive rad.
6.4
Relation mellan layout och databas
Sammanfattningsvis går det att utläsa att resultatet av designen samt resultatet av databasen är beroende av varandra. Designen skulle inte vara praktiskt tillämpbar utan databasen som pro-duktionsverktyg, eftersom det som tidigare nämnt skulle vara omständligt att lägga till framförallt nya rader i det slutgiltiga dokumentet med nuvarande produktionsverktyg. Därför är databasen viktig för att kunna öka produktionsflödet.
Mälardalens Högskola 7 Diskussion
7
Diskussion
Syftet med detta arbete var som tidigare nämnts att slå samman två underhållsdokument samt att undersöka möjligheterna att införa en strukturerad databas. Arbetet med sammanslagningen av underhållsamanualen och konfigurationslistan gick i stort sett som planerat och här fungerade den metod som hade valts att jobba efter bra. Genom att tidigt få fram ett utkast på det sammanslagna dokumentet gavs också tidig feedback så att arbetets riktning kunde preciseras bättre.
I detta arbete användes en testversion av det editeringsprogram som idag används för att producera underhållsdokumenten. Detta på grund av att arbetet skulle kunna framställa designförslag som liknade dagens underhållsdokument samt förstå problemet och begränsningar som förekommer i det nuvarande programmet. De begränsningar som upptäcktes var att testversionen inte tillät ändringar i linjers tjocklek eller möjligheten att dela en tabell för att få två av varandra oberoende tabeller. Dessa två begränsningar gjorde att layoutförslaget inte kunde nå riktigt hela vägen fram till ett önskvärt resultat. Det syftar exempelvis till att göra en tjockare linje varje gång ett nytt underhållsobjekt börjar. Detta för att få en tydligare visuell hierarki. Att också dela tabellen längs separationslinjen i mjukvaran skulle eliminera de ofrivilliga tomrum som nu uppstår, se bilaga B. Det sammanslagna dokumentet går i teorin att implementera så fort de sista justeringarna gjorts i editeringsprogrammet utanför testmiljön. Anledningen är att den design som presenteras i arbetet är mer svårarbetad i det nuvarande produktionsverktyget, än den redan befintliga designen. Att i en redan krånglig miljö lägga till en ännu krångligare designstruktur är inget att rekommendera. Tanken har som tidigare konstaterats varit att produktionsverktyget ska bli någon form av databas och då blir den föreslagna designen möjlig att producera på ett effektivt sätt.
Layoutförslaget som tagits fram tar upp cirka fem sidor fler än de ursprungliga kapitel i dokumentet som det baserats på. Dessa fem sidor kan sannolikt minskas något då de sista justeringarna görs men resultatet kommer förmodligen fortfarande kräva något fler sidor än dagens alternativ. Samma metod användes då arbetet med databasen påbörjades. Dock behövdes det här mer lit-teraturstudier än vad som krävdes vid arbetet med layoutförslaget. Den litteratur som användes talade på ett bra sätt om hur en databas ska planeras och byggas upp. Dock bör tilläggas att det under arbetets gång upptäcktes att en databas förmodligen kommer att förändras med tiden. Vissa saker kan te sig självklara då den planeras men under själva byggnationen visa sig vara dåliga alternativ. Därför bör man då tänka på att det är svårt att modulera en databas exakt. Det viktiga är att ha en bra beskrivning samt en modell som tydligt visar på sambanden i databasen att påbörja sitt modellerande utifrån. Exempelvis kan ett attribut komma att bli en entitet un-der uppbyggnaden på grund av att det upptäcks att det är en bättre lösning som medför bättre funktion i databasen och besvarar beskrivningen bättre.
7.1
Relaterad forskning
Forskning kring sammanslagning av olika dokument med syfte att öka säkerhet och produktions-flöde hos en flygplanstillverkare inom försvarsindustrin, är inget som sker på allmän nivå. Varje tillverkare optimerar sitt eget system efter eget behov och företagsfilosofi. Dock bör man nästan anta att varje företag i branschen driver ett förbättringsarbete av något slag. Indirekt går det dra en slutsats om att det kontinuerligt bedrivs empirisk forskning i ämnet.
Human Factors i system är ett område det bedrivs forskning på. I en studie som är gjord på hela system, poängterar artikelförfattaren hur svårt det är att förstå vikten av att tänka på Human
Factors redan i systemkonstruktionen. Författaren drar en slutsats att Human Factors är en
Mälardalens Högskola 8 Slutsats
8
Slutsats
I detta arbete har det presenterats ett sammanslaget dokument i liggande form. Detta var arbetets huvudsakliga mål. För att kunna producera och vidmakthålla detta liggande dokument ansågs det nödvändigt att använda sig av en databas, därför har detta arbete också förberett för en framtida databasbyggnation.
Baserat på omfattning, kunskap samt förutsättningar på arbetet har ett resultat som besvarar arbetets mål uppnåtts. Layoutförslaget har visats upp för flera instanser och fått bra kritik då det underlättar för många om bläddringen mellan dokumenten försvinner. Dagens produktions-och publikationssystem är gammalt produktions-och i behov av en ordentlig upprustning. Det arbete som presenteras i denna rapport skulle effektivisera hela produktionsledet och underlätta tolkningen av det färdiga resultatet. Sätts systemet en dag i bruk kommer det att vara lättare att implementera detta i en interaktiv miljö eftersom en struktur redan finns i databasen.
Kommer databasen även brukare till fördel, kan de utnyttja funktioner i databasen som underlättar i arbetet. Det handlar exempelvis om fördelarna med att använda en filtreringsfunktion och därmed kunna välja bort all information som inte är relevant för stunden.
8.1
Framtida arbeten
För att driftsätta hela systemet som presenteras i detta förslag finns det framtida arbeten som måste utföras. Det sista steget i databasmodelleringen behöver göras, det vill säga den fysiska modelleringen, för att den ska kunna bli operativ.
När databasen är i drift kommer det behövas ett användargränssnitt på databasen, samt var den ska hämta sin information, hur övergång från befintligt system till det som här föreslås ska gå till. Framtiden är svår att se, men det skulle nästan gå att utgå ifrån att en underhållsplan troligen inte kommer att presenteras på papper i all framtid. Detta är ett område där det går anta att det kommer bedrivas forskning framöver.
Mälardalens Högskola Referenser
Referenser
[1] Maintenance plans and planning, 33rd ed., Saab AB, Linköping, Sverige, 8 2015, maintenance plans.
[2] S. Li, Y. Liu, J. Liu, and N. Wang, “The application research on the virtual maintenance in air-craft design,” in Reliability, Maintainability and Safety, 2009. ICRMS 2009. 8th International
Conference on. IEEE, 2009, pp. 678–683.
[3] M. Liu, Y. Wang, K. Li, X. Wei, X. Liu, and L. Li, “Design and implementation of prod-uct management system supporting ietm generation and management function,” in 2012 In-ternational Conference on Computer Science and Information Processing (CSIP), 2012, pp. 1061–1064.
[4] T. Nicolai, T. Sindt, H. Witt, J. Reimerdes, and H. Kenn, “Wearable computing for aircraft maintenance: Simplifying the user interface,” in Applied Wearable Computing (IFAWC), 2006
3rd International Forum on. VDE, 2006, pp. 1–12.
[5] T. Padron-McCarthy and T. Risch, Databasteknik. Lund, Sverige: Studentlitteratur, 2005,
pp. 76–80.
[6] Y. Bai, Practical database programming with Visual C#. NET. Hoboken, NJ: John Wiley &
Sons, 2010, ch. 2.
[7] s1000d.org. (2015) S1000D. [Online]. Available: http://public.s1000d.org/Pages/Home.aspx
[Hämtad: 2015-10-05]
[8] S1000D, no. S1000D-I9005-01000-00, 2012, ch. 5.2.1.6.
[9] s1000d.org. (2015) S1000D. [Online]. Available: http://public.s1000d.org/Getting%20Started/
Pages/AboutS1000D.aspx[Hämtad: 2015-10-05]
[10] K. Ferreira and D. Jeleborg, "Anpassning och optimering av checkprogram för AW139", Mälardalens Högskola, Västerås, Sverige, 2015.
[11] D. Brodén and B. Blad, “Projekt- malmö aviation underhållsprogram,” Mälardalens Högskola, Västerås, Sverige, 2011.
[12] J. Johnson, Designing with the Mind in Mind: Simple Guide to Understanding User Interface
Design Guidelines. Burlington, MA: Elsevier, 2010.
[13] R. Stabina, “Quantitative data graphics: Best practices of designing tables and graphs for use in not-for-profit evaluation reports,” Master’s thesis, University of Oregon, 2005.
[14] S. Krug, Don’t make me think: A common sense approach to web usability. Bekeley, CA:
Pearson Education India, 2006, ch. 2.
[15] T. M. Connolly and C. E. Begg, Database systems: a practical approach to design,
implemen-tation, and management. Boston, MA: Pearson Education, 2010, ch. 4,12.
[16] F. E. Oliveto, “System efficiency/merit (a total system evaluation),” in Aerospace and
Elec-tronics Conference, 1998. NAECON 1998. Proceedings of the IEEE 1998 National. IEEE,
1998, pp. 51–59.
[17] J. Johnson, Designing with the Mind in Mind: Simple Guide to Understanding User Interface
Design Guidelines. Burlington, MA: Elsevier, 2010, ch. 1-3.
[18] M. Roos. (2012) Kokbok för databasmodellering. [Online]. Available: http://dbwebb.se/
kunskap/kokbok-for-databasmodellering[Hämtad: 2015-10-07]
[19] T. Padron-McCarthy and T. Risch, Databasteknik. Lund, Sverige: Studentlitteratur, 2005,
ch. 2-4.
[20] T. Padron-McCarthy. (2005) Er-modellering. [Online]. Available: http://www.databasteknik.
Mälardalens Högskola Referenser
Bilaga A
Underhållsmanual Gripen C/D
Mälardalens Högskola A Nuvande form
Bilaga A
Nuvande form
För att få en djupare förståelse för hur dokumenten är uppbyggda i nuvarande form, kommer denna bilaga ge en lättare förklaring för de rubriker som finns i manualen som den ser ut idag. Längst bak i bilagan finns två sidor ur underhållsmanualen samt en sida ur konfigurationslistan.
Underhållsmanualen
Maintenance Object: Datamodulens ID i CSDB. Tabellen är sorterad efter denna.
Denomination: Namnet på datamodulen. Föregås denna av en punkt (.) eller flera antyder detta att det är en underpunkt till föregående punkt.
Installation Location: Var på planet berört underhållsobjekt sitter. Type: Typ av åtgärd.
Qty/prod: Hur många gånger åtgärden förekommer i varje flygplanstyp. Interval/Uom: Hur ofta åtgärden ska genomföras/ Enhet det mäts i. Operations: Intervallet står i detta fält om det är baserat på användande. Storage: Intervallet står i detta fält om det är baserat på förådstid.
Action on: Förklarar om åtgärden utförs på planet eller om komponenten måste tas bort från planet för att underhållet ska kunna utföras.
CWS: Då komponenten måste tas bort från planet för att utföra underhållet, talar denna kolumn om var komponenten ska skickas för att underhållas.
Action- peace: Talar om var eller av vem ett underhåll ska utföras i fredstid. Action- war: Talar om var eller av vem ett underhåll ska utföras i krigstid.
FENIX code: En kod som används som referens i brukarens uppföljningssystem. Op= Opera-tions, St= Storage.
Remark/Note: Innehåller anmärkningar och/eller noteringar som måste förklaras för en specifik åtgärd.
Action Code: Koden som tillsammans med datamodulkoden refererar till den specifika åtgärden i CSDB.
Action Definition: Namnet på underhållsåtgärden.
Publication Reference: Referens till beskrivningsdokumentet. Hur åtgärden ska utföras.
Konfigurationslistan
Abbreviated stores name: Samma som Denomination i underhållsmanualen. Stores Designation: Komponentens artikelnummer från kunden.
Reference Designation: Komponentens artikelnummer från komponenttillverkare. (original designation): Komponentens artikelnummer från Saab.
Other reference designation: Finns det fler beteckningar representeras de i detta fält. Aircraft Effectivity: I vilket/vilka flygplan komponenten återfinns.
Materiel Type: Samma som Type i underhållsmanualen.
Maintenance Object: Samma som Maintenance Object i underhållsmanualen. Notes: Eventuella noteringar som berör komponenten.
Electrical power and lighting system
General data; Maintenance tables
1
Maintenance table
Table 1 Maintenance Object Denomination Installation location Type Qty/ prod Interval/UoM Action on CWS FENIX code Remark/Note Action Code Action Definition Publication Reference C D - Opera-tions Stor-age Action Op St peace war J1-A-39-00-00-00A ELECTRICAL POWER AND LIGHTS - CWS FOR MG39: SAT/A GE X X - OC ON S-plut -374AElectrical Power and Lighting System: Evaluation of MDR data
AMP39/J3-A-39-00-00-00A-374B-A
OC ON
S-plut
-412A
Electrical power and lighting system: Fault isolation
AMP39/J3-A-39-00-00-00A-412B-A
OC ON
S-plut
-413A
Electrical power and lighting system: Fault codes, make clear the fault codes AMP39/J3-A-39-00-00-00A-413B-A
J1-A-39-10-00-00A POWER SUPPLY GE X X - 400FH ON
FU-komp
-320A
Power supply, relay (28PA): Operation tests AMP39/J3-A-39-10-00-00A-320G-A 200FH ON FU-komp -320B
Power supply, diode (45PA): Operation tests AMP39/J3-A-39-10-00-00A-320H-A 200FH ON FU-komp -360A
Power supply, relay (20PA): Design data/tolerances check AMP39/J3-A-39-10-00-00A-360B-A 800FH ON FU-komp -320C
Check of function main switch 14PA and relay 22PA AMP39/J3-A-39-10-00-00A-320C-A 400FH ON FU-komp -320D
Power supply, relay (15PA): Operation tests AMP39/J3-A-39-10-00-00A-320D-A 400FH ON FU-komp -320F
Power supply, relay (19PA): Operation tests
AMP39/J3-A-39-10-00-00A-320F-A
OC ON
S-plut
-100A
Simulation of IDG (main generator) AMP39/J3-A-39-10-00-00A-100B-A
J1-A-39-10-01-00A MAIN GENERATOR (IDG)
10PB
LRU 1 1 - OC ON
S-plut
-920A
Main generator: To remove and install AMP39/J3-A-39-10-01-00A-920A-A
BF ON
Klargto
-310A
Check of pressure indicator oil filter AMP03/J3-A-03-22-00-01A-200B-A
50FH ON
S-plut
-310B
Check of oil level
AMP39/J3-A-39-10-01-00A-310C-A
100FH ON
S-plut
-370A
Check of chip detector
AMP39/J3-A-39-10-01-00A-370B-A
100FH ON
S-plut
-310C
Check of attachment and leak check AMP38/J3-A-38-10-01-00A-310D-A
Electrical power and lighting system General data; Maintenance tables
The information contained in this document is the property of the
originator and shall not be used, disclosed or altered in any manner
without prior written consent of the originator.
Effectivity: 39 C,D SE
J3-A-02-24-39-00A-010C-A
Table 1 (Continued) Maintenance Object Denomination Installation location Type Qty/ prod Interval/UoM Action on CWS FENIX code Remark/Note Action Code Action Definition Publication Reference C D - Opera-tions Stor-age Action Op St peace war 200FH ON FU-komp -920B Replacement of filter AMP39/J3-A-39-10-01-00A-920B-A 4000FH OFF S-plut SCR -990A Discard Not necessary OC OFF CWS SAT/L -600A Repairs TUA39/J1-A-39-10-01-00A-910A 1) ON FU-komp EX 1) 600FH or 60MTH -290A
Main generator: Change of liquid/gases AMP39/J3-A-39-10-01-00A-290B-A
60MTH OFF CWS
SAT/L ST -850A
Storage maintenance: Testing TUA39/J1-A-39-10-01-00A-910A J1-A-39-10-01-01A .GENERATOR UNIT
10PB SRU 1 1 - OC OFF CWS SAT/L -600A Repairs TUA39/J1-A-39-10-01-01A-910A J1-A-39-10-01-02A .CONSTANT SPEED DRIVE (CSD) 10PB SRU 1 1 - OC OFF CWS SAT/A -600A Repairs TUA39/J1-A-39-10-01-00A-910A J1-A-39-10-02-00A GENERATOR CONTROL UNIT 12PB LRU 1 1 - OC ON S-plut -920A
Generator control unit: To remove and install AMP39/J3-A-39-10-02-00A-920A-A 1) OFF S-plut SCR 1) F6132-001642 to be done at 8000FH. F6132-001578 to be done at 3000FH. -990A Discard Not necessary OC OFF CWS SAT/A -600A Repairs TUA39/J1-A-39-10-02-00A-910A J1-A-39-10-03-00A CURRENT
TRANS-FORMER MAIN GENERATOR 11PB BRE 1 1 - OC ON S-plut -920A
Current transformer, main generator: To remove and install
AMP39/J3-A-39-10-03-00A-920A-A 8000FH OFF CWS SAT/L -990A Testing/Discard TUA39/J1-A-39-10-03-00A-910A J1-A-39-10-04-00A AUXILIARY AC GENERATOR 20PB LRU 1 1 - OC ON S-plut -920A
Auxiliary generator: To remove and install AMP39/J3-A-39-10-04-00A-920A-A 4000FH OFF CWS SAT/L SCR -990A Discard Not necessary OC OFF CWS SAT/L -600A Repairs TUA39/J1-A-39-10-04-00A-910A 60MTH OFF CWS SAT/L ST -850A
Storage maintenance: Testing TUA39/J1-A-39-10-04-00A-910A J1-A-39-10-05-00A CURRENT
TRANS-FORMER AUXILIARY GENERATOR 21PB BRE 1 1 - OC ON S-plut -920A
Current transformer, auxiliary generator: To remove and install
AMP39/J3-A-39-10-05-00A-920A-A 4000FH OFF S-plut SCR -990A Discard Not necessary J1-A-39-10-06-00A MAIN CONTACTOR
13PB
LRU 1 1 - OC ON
S-plut
-920A
Main contactor: To remove and install AMP39/J3-A-39-10-06-00A-920A-A
Electrical power and lighting system General data; Maintenance tables
The information contained in this document is the property of the
originator and shall not be used, disclosed or altered in any manner
without prior written consent of the originator.
Effectivity: 39 C,D SE
J3-A-02-24-39-00A-010C-A
Electrical power and lighting system
Configuration
Table of contents
PageElectrical power and lighting system − Configuration ... 1
References ... 1
1 Configuration table ... 1
References
Table 1 References
Data module/Technical publication Title
None
1
Configuration table
Table 2 Abbreviated stores name Stores designation Reference designation (original designation) Other reference designation Aircraft effectivity Materiel typeMaintenance object Notes
ELECTRICAL POWER AND LIGHTS M5823−390000 39C GE J1−A−39−00−00−00A ELECTRICAL POWER AND LIGHTS M5824−390000 39D GE
POWER SUPPLY M5823−391000 39C GE J1−A−39−10−00−00A
POWER SUPPLY M5824−391000 39D GE MAIN GENERATOR (IDG) F6132−001384 SUNCO−737844A SAAB−9305000−501 39C,39D LRU J1−A−39−10−01−00A WWC
.GENERATOR UNIT F6132−001381 SUNCO−738156A SAAB−9305000−503 SRU J1−A−39−10−01−01A .CONSTANT SPEED DRIVE (CSD) F6132−001380 SUNCO−740483C SAAB−9305000−502 SRU J1−A−39−10−01−02A GENERATOR CONTROL UNIT F6132−001642 SUNCO−737846F SAAB−9305001−503 39C,39D LRU J1−A−39−10−02−00A WWC GENERATOR CONTROL UNIT F6132−001578 SUNCO−737846E SAAB−9305001−502 39C,39D LRU CURRENT TRANS-FORMER MAIN GENERATOR F6132−001383 SUNCO−737848A SAAB−9305002−501 39C,39D BRE J1−A−39−10−03−00A WWC AUXILIARY AC GENERATOR F4343−002047 LUCAS−B03102 SAAB−9305003−503 39C,39D LRU J1−A−39−10−04−00A WWC AUXILIARY AC GENERATOR F6400−086606 LUCAS−BA−03102 SAAB−9305003−505 39C,39D LRU WWC CURRENT TRANS-FORMER AUXILIARY GENERATOR F4343−001907 LUCAS−PC01301 SAAB−9305004−501 39C,39D BRE J1−A−39−10−05−00A WWC
MAIN CONTACTOR F3864−000197 HEMCO−B−435K−2 SAAB−9305918−502 39C,39D LRU J1−A−39−10−06−00A WWC TRANSFORMER RECTIFIER UNIT (TRU) F5686−000393 VARO−2030D SAAB−9305006−551 39C,39D LRU J1−A−39−10−07−00A WWC CONVERTER REGULATOR UNIT (CRU) F6000−000149 SIPRE−45178−1 SAAB−9305007−502 39C,39D LRU J1−A−39−10−08−00A
Electrical power and lighting system Configuration
The information contained in this document is the property of the
originator and shall not be used, disclosed or altered in any manner
without prior written consent of the originator.
Effectivity: 39 C,D HU
