De-Icing Management Tool V2

Examensarbete

De-Icing Management Tool V2

Utveckling av grafiska gränssnitt till ett system för hantering av avisning

Författare: Daniel Lycksén &

Malin Brolien Termin: VT12 Ämne: Datateknik Nivå: Grundnivå Kurskod: 2ED13E

Organisation/ Organization Författare/Author(s) LINNÉUNIVERSITETET

Matematiska och systemtekniska institutionen Daniel Lycksén Linnaeus University/ Malin Brolien School of Mathematics and Systems Engineering

Dokumenttyp/Type of document Examensarbete/ Diplomawork

Titel och undertitel/Title and subtitle

De-Icing Management Tool V2 - Utveckling av grafiska gränssnitt till ett system för hantering av avisning

De-Icing Management Tool V2 - Development of graphical user interfaces to a system for handling deicing processes

Sammanfattning

Denna rapport beskriver ett examensarbete i datateknik för högskoleingenjörer vid

Linnéuniversitetet i Växjö som gjorts av Malin Brolien och Daniel Lycksén. Utförandet av arbetet har genomförts på Saab AB i Växjö.

Projektet är en del av ett forskningsprojekt inom EU, där det huvudsakliga målet har varit att utveckla ett system för hantering av avisningsprocesser på en flygplats. Avisning av flygplan görs av flygsäkerhetsskäl under vintertid och förhindrar att is bildas på flygplanet. Systemet planerar och schemalägger avisning beroende på olika parametrar som till exempel

väderförhållanden. Det finns även möjlighet att påverka schemaläggningen genom manuella inmatningar till systemet. Det totala projektet är en prototyp (DIMT V2) som ska användas för att göra en simulering med exempeldata. Applikationen ska i framtiden vidareutvecklas till DIMT V3 för användning med verklig flygplatsdata på flertalet flygplatser runt om i Europa.

Vår del i projektet har varit att utveckla de grafiska gränssnitten till systemet. För att kunna göra utvecklingen möjlig har stor vikt lagts vid att förstå den process som sker vid en avisning. Interaktivt arbete har gjorts kontinuerligt mot flygplatspersonalen under

utvecklingens gång för att undersöka hur användarna på bästa sätt kan dra nytta av systemet.

Det resultat som åstadkommits är två väl anpassade gränssnitt för De-Icing Management Tool, med möjlighet att ge inmatningar till systemet. Det finns goda förutsättningar för vidareutveckling av DIMT V3.

Nyckelord

Webbapplikation, avisning, grafiska gränssnitt, flygplan Abstract

This report describes the bachelor degree thesis in computer technology at Linnaeus University in Växjö, and is written by Malin Brolien and Daniel Lycksén. The project has been made at Saab AB in Växjö.

The project is a part of a EU research programme, where the main goal has been to develop a

system for handling of de-icing processes at airports. De-icing of aircrafts is made during the

winter period for the reason to increase the flight security, and it prevents ice formation on

the aircraft. The system plans and schedules de-icing depending on different parameters as

for example weather conditions. There is also a possibility of affecting the scheduling

through manual input to the system. The total project is a prototype (DIMT V2) which is

going to be used to make a simulation with example data. The application will later be

further developed to DIMT V3 that will be used with proper airport data at several airports in

Europe.

Our part of the project has been to develop two graphical user interfaces to the system. Great emphasis has been placed on how the process of deicing works for making the development possible. Interactive work have been done continuously with the staff at the Arlanda airport during the development to make researches how the users on the best way can take advantage of the system.

The result that has been achieved is two well adapted graphical interfaces for De-Icing Management Tool V2, with the possibility to give input to the system. There are good conditions for further development of DIMT V3.

Key Words

Webapplication, de-icing, graphical interface, airplane

Utgivningsår/Year of issue Språk/Language Antal sidor/Number of pages

ABSTRACT

This report describes the bachelor degree thesis in computer technology at Linnaeus University in Växjö, and is written by Malin Brolien and Daniel Lycksén. The project has been made at Saab AB in Växjö.

The project is a part of a EU research programme, where the main goal has been to develop a system for handling of de-icing processes at airports. De-icing of aircrafts is made during the winter period for the reason to increase the flight security, and it prevents ice formation on the aircraft. The system plans and schedules de-icing depending on different parameters as for example weather conditions. There is also a possibility of affecting the scheduling through manual input to the system. The total project is a prototype (DIMT V2) which is going to be used to make a simulation with example data. The application will later be further developed to DIMT V3 that will be used with proper airport data at several airports in Europe.

Our part of the project has been to develop two graphical user interfaces to the system. Great emphasis has been placed on how the process of deicing works for making the development possible. Interactive work have been done continuously with the staff at the Arlanda airport during the development to make researches how the users on the best way can take advantage of the system.

The result that has been achieved is two well adapted graphical interfaces for De-Icing

Management Tool V2, with the possibility to give input to the system. There are good

conditions for further development of DIMT V3.

INNEHÅLL

1 INLEDNING ...1

1.1 PROBLEMFORMULERING ...1

1.2 BAKGRUND ...1

1.2.1 SAAB AB ...1

1.2.2 SAAB ATM ...2

1.2.3 Swedavia ...2

1.2.4 Single European Sky - ATM Research Programme ...3

1.2.5 Kopplingen mellan intressenterna ...3

1.3 SYFTE ...3

1.4 FÖRKORTNINGAR ...3

2 TEORI ...5

2.1 PROJEKTBESKRIVNING ...5

3 METOD ... 10

3.1 INFORMATIONSINSAMLING ... 10

3.2 VERKTYG ... 10

3.2.1 NetBeans ... 10

3.2.2 WampServer ... 10

3.2.3 Chrome ... 10

3.3 TEKNIKER... 10

3.3.1 Extensible HyperText Markup Language (XHTML) ... 11

3.3.2 Cascading Style Sheets (CSS) ... 11

3.3.4 SQL Databas ... 12

3.3.5 Hypertext Preprocessor (PHP) ... 12

3.3.6 Extensible Markup Language (XML) ... 12

4 PROCESS ... 13

4.1 PLANERINGSFASEN ... 13

4.2 UTVECKLINGSFASEN ... 15

4.2.1 Flight list ... 15

4.2.2 Flight Information ... 18

4.2.3 General information ... 22

4.2.4 General settings ... 24

4.2.5 Units view (“grid”) ... 27

4.2.6 Operator view ... 30

5 RESULTAT ... 32

5.1 RESULTAT GENTEMOT PROBLEMFORMULERING ... 32

5.2 FUNKTIONALITET AV GRÄNSSNITTEN ... 34

5.2.1 Flight List ... 34

5.2.2 Flight Information ... 35

5.2.3 General Information... 36

5.2.4 General Settings ... 38

5.2.5 Units View (”Grid”) ... 40

5.2.6 Operator View... 41

6 DISKUSSION ... 42

REFERENSER ... 43

BILAGOR

1. Det gamla användargränssnittet

2. Programmeringskod

1

1 INLEDNING

1.1 PROBLEMFORMULERING

Single European Sky ATM Research Programme, SESAR, är ett EU-projekt för att utveckla metoder och standarder för effektivare och säkrare flygledning och på så sätt bidra till ett enat luftrum i Europa.

Ett av SESARs delprojekt har som avsikt att minimera ”turn a round”-tiden för flygplan på en flygplats. ”Turn a round”-tiden är den tid det tar från det att ett flygplan landar på en flygplats tills dess att det lyfter igen.

En del av ”turn a round”-processen är hantering av avisning av flygplan, vilket är något som görs av flygsäkerhetsskäl under vintertid och förhindrar att is bildas på flygplanen. Idag fungerar inte hanteringen av avisningsprocessen på ett tillfredsställande sätt, då det inte finns något verktyg för noggrann uppskattning av avisningstider för flygplan. För att effektivisera processen ska en webbapplikation skapas som ska kunna utföra beräkningar och planera avisning av flygplan. Både långsiktig planering som startar sex månader före en specifik dag av planerad avisning och kortsiktig planering för de närmaste 24 timmarna ska kunna göras.

Applikationen ska visa och ge möjlighet att hantera information om avgående flygplan, som till exempel vilken tid och vilken plats avisning ska göras. Analys ska även kunna göras av den gångna avisningssäsongen för att öka noggrannheten i kommande beräkningar. För att kunna dra så stor nytta som möjligt av applikationen ska den kunna användas både av en koordinator som hanterar planeringen av när och vilka flygplan som ska avisas, samt operatörer vilka är de som utför avisningen.

Applikationen ska komma att vara en prototyp som i ett första skede ska användas under test.

Den görs i två delar, serversidan och klientsidan, där den för rapporten relaterade uppgiften riktar sig mot klientsidan och dess grafiska gränssnitt. Forskning i form av undersökningar görs mot flygplatspersonal på Swedavia för att ta reda på hur gränssnittens synliga

information och dess struktur lämpligast bör vara uppbyggd. Applikationen får inte upplevas som en belastning för användarna, utan ska istället vara ett viktigt verktyg för att effektivisera deras arbete. För att uppnå detta ska denna rapport svara på följande problem:

 Hur mycket och vilken information ska visas och kunna ändras i de grafiska gränssnitten till systemet för de olika parterna?

 På vilket sätt ska de grafiska gränssnitten till systemet vara upplagda för att de ska bli lättöverskådliga?

Saab AB är de som har ansvaret för utvecklingen av applikationen och har tidigare inte arbetat med uppgifter inom just ”turn a round”-processen, varför nya begrepp och ny information kommer att behöva gås igenom noggrant av inblandade.

1.2 BAKGRUND 1.2.1 SAAB AB

Saab AB är ett svenskt företag som grundades år 1937 som Svenska Aeroplan AB och inriktar

sig huvudsakligen mot högteknologiska lösningar inom försvarsindustri, civil säkerhet samt

luftfart (Saab Group, 2012-04-25a). Företaget grundades med uppgiften att bidra till att

upprätthålla Sveriges säkerhet genom att säkra tillverkningen av svenska militärflygplan, då

2

Europa vid denna tid var på gränsen till en stor konflikt.

Produktionen av militära flygplan ledde de efterföljande åren till uppkomsten av ett antal andra affärsverksamheter och produkter inom företaget. Bland annat startade företaget

tillverkning av bilar i slutet av 1940-talet och år 1969 gjordes en sammanslagning med Scania tillsammans formade Saab-Scania med avsikt att kombinera flygplans- och säkerhetssystem med tillverkningen av bilar, lastbilar och bussar (Saab Group, 2012-04-25b). År 1990

övergick personbilsdivisionen till att istället bli ett oberoende företag, Saab Automobil, och 5 år senare delades Saab-Scania till att återigen bli två separata företag.

Idag förser Saab AB den globala marknaden med produkter, tjänster och lösningar med allt från militärt försvar till civil säkerhet, där regeringar, myndigheter och företag är de främsta intressenterna (Saab Group 2010-04-26a). Den gemensamma nämnaren för företagets

affärsområde är strävan efter att hålla samhället och människor säkert, vilket görs möjligt med hjälp av system och lösningar som ökar säkerheten.

Företaget har delat in sin verksamhet i fem affärsområden:

 Aeronautics

 Dynamics

 Electronic Defence Systems

 Security and Defence Solutions

 Support and Services

1.2.2 SAAB ATM

Under området Security and Defence Solutions finns hantering och utveckling av

flygledningstjänster, Air Traffic Management Solutions. Detta är en del av kategorin civil säkerhet och hanterar de processer, procedurer och resurser som spelar in för att flygplan kan styras på ett säkert sätt i luftrummet och på marken (Eurocontrol, 2012-04-27).

Inom Saab AB finns, på ett antal orter, avdelningar som arbetar med just dessa system, där några produkter och tjänster är flygtornsverksamhet, navigationshjälpmedel och procedurer vid landning (Saab Group, 2012-04-26b). Remote Tower, i-TWR, Flight Inspection Services och Transportable Tower är exempel på några av de större projekt dessa avdelningar för närvarande fokuserar på.

1.2.3 Swedavia

LFV, som innan år 2007 hette Luftfartsverket, har som huvuduppgift att tillhandahålla flygtrafiktjänst för civil och militär luftfart i Sverige (Wikipedia, 2012-04-30). När det gäller flygtrafiktjänsten så ska det finnas konkurrens i Sverige inom detta. En annan aktör på den svenska marknaden när det gäller flygtrafiktjänst är till exempel ACR, Aviation Capacity Resources.

För att bland annat kunna konkurrera på en öppen marknad delades LFV upp och Swedavia

AB bildades. Swedavia är ett statligt ägt företag som grundades 1 april 2010 och tog då över

elva flygplatser runt om i Sverige från Luftfartsverket. Swedavia driver och utvecklar dessa

flygplatser och eftersom Swedavia ägs av staten ska de vara ett föredöme inom hållbar

utveckling (Swedavia, 2012-04-25a). Hållbar utveckling består av ekonomisk, social och

ekologisk hållbarhet, där ekologisk hållbarhet innebär att utvecklingen ska ha minsta möjliga

påverkan på miljön (Swedavia, 2012-04-25b).

3

1.2.4 Single European Sky - ATM Research Programme

Idag har Europa inte ett gemensamt luftrum och därför finns inga flygtrafiktjänster för hantering på europeisk nivå (SESAR, 2012-04-30a). Dessutom är det europeiska luftrummet ett av de mest trafikerade i världen där det kan uppgå till över 33 000 flygningar per dag. Det nuvarande systemet för flygledningstjänsten lider av flera brister och det blir inte bättre av den trafiktäthet som finns i dagens läge.

Single European Sky är ett initiativ från den Europeiska kommissionen för att förnya och förändra uppbyggnaden av den europeiska flygledningstjänsten (SESAR, 2012-04-30a).

SESAR, Single European Sky ATM Research Programme, är en del av EU:s Single European Sky. SESAR vill tillsammans med Europas främsta företag inom utveckling av flygledning och flygtrafik, bland annat Swedavia, utveckla metoder och standarder för effektivare och säkrare flygledning. En av målsättningarna med SESAR är att under utvecklingsfasen 2008 till 2013 generera den nya teknologin som behövs för ett framtida enat luftrum i Europa.

SESAR består idag av ungefär 300 projekt sammanlagt och ett av dessa projekt heter P 12.6.2 The Airport Operations Plan (AOP), decision support tools and conflict detection tools to be integrated in APOC for managing the overall performance of the airport (SESAR, 2012-04- 30b). En del av det här projektet innehåller att försöka att minimera ”turn a round”- tiderna för flygplanen på en flygplats, vilket även innefattar att effektivisera processerna för avisning av flygplanen.

1.2.5 Koppling mellan intressenterna

Då SESAR startade år 2004 så gick LFV med i projektet, eftersom Swedavia inte var grundat vid denna tidpunkt. LFV gick med i SESAR via ett konsortium, det vill säga en bildad

sammanslutning mellan företag för att göra gemensamma affärer. Detta konsortium fick namnet NORACON, the North European and Austrian Consortium, och består av åtta europeiska bolag som tillhandahåller flygtrafiktjänster (SESAR, 2012-05-15a). Då Swedavia senare grundades fick de ta över vissa av de delar LFV tidigare haft inom detta projekt.

Även Saab AB gick med i SESAR via ett konsortium kallat NATMIG, North European ATM Industry Group, och består av fyra av de ledande nordeuropeiska företag som är involverade i lösningar för flygledningstjänster. (SESAR, 2012-05-15b).

Genom SESAR blev på så sätt Saab AB och Swedavia AB sammanlänkade till detta specifika projekt, P 12.6.2. Swedavia äger bland annat Arlanda Airport och det är där validering och testning av prototypen kommer att genomföras.

1.3 SYFTE

Att skapa två användarvänliga och anpassade webbgränssnitt till systemet De-Icing Management Tool V2.

1.4 FÖRKORTNINGAR

Förkortning Förklaring

A-CDM Airport Collaborative Decision Making

ACZT Actual Commence of De-icing Time

4

ADIT Actual De-icing Time

ACZT Actual Commence of De-icing Time AEZT Actual End of De-icing Time

AHOT Actual Hold over time

AOP Airport Operations Plan

ARZT Actual Ready for De-icing Time

ATC Air Traffic Control

ATM Air Traffic Management

ECZT Estimated Commence of De-icing Time EDIT Estimated De-icing Time

EEZT Estimated End of De-icing Time EHOT Estimated Hold Over Time

ERZT Estimated Ready for De-icing Time EXOT Estimated Taxi Out Time

OSED Operational Services and Environment Description

SOBT Scheduled Off Block Time TOBT Target Off Block Time

TTOT Target Take Off Time

TWR Air Traffic Services, Tower

5

2 TEORI

Applikationen som ska åstadkommas ska vara en prototyp vid namn De-Icing Management Tool V2, som sedan kommer vidareutvecklas DIMT V3 i slutet av år 2013 av Saab ATM. När väl slutversionen är färdig år 2013 är det tänkt att den ska användas på flera flygplatser runt om i Europa för att komma ett steg närmare ett gemensamt luftrum i Europa.

Här nedan följer en beskrivning av systemet i sin helhet som vår uppgift är en del av.

2.1 PROJEKTBESKRIVNING

Runt om på flygplatser i Europa är det i dagens läge brist på samarbete och all information delas inte mellan aktörerna som är inblandade i en ”turn a round”-process. Information delas till exempel inte mellan avisningsföretag och personalen som arbetar på marken med

inkommande och avgående flygplan. Bristen gör att flygplatsens totala kapacitet och

förutsägbarheten av avisningsprocessen påverkas på ett negativt sätt och då speciellt när svåra vinterförhållanden råder.

Idag finns inte något verktyg som hanterar en långsiktig planering för avisning och inte heller görs någon analys av den gångna säsongen. Istället planeras allt kort tid i förväg och endast av avisningsföretagen, som inte delar informationen till övriga på flygplatsen. När en avisning ska planeras in, är det piloten som meddelar via radio att denne vill ha sitt plan avisat och då oftast kort inpå att avising ska ske.

Det övergripande målet med att utveckla DIMT är att i version 3 göra avisninings-processen

till en mer integrerad del av den befintliga A-CDM-processen, vilket är flygplatsens totala

process i hantering av ankomster, ”turn a round” och avgångar för en flygning. Strukturen

över systemet och interaktionen mellan dess data visas i flödesschemat nedan.

6

Flödesschema över DIMT V2

Det totala systemet ska fungera som ett planeringsverktyg för avisning där avisningsprocesserna ska delas in tre olika faser:

 Medium/short term planning phase:

Denna fas ska påbörjas som en långtidsplanering och startar sex månader före en specifik dag av planerad avisning (OSED, 2011 s. 54). Planeringen ska kunna fortlöpa ända till några timmar inpå dagen av planerad avisning. Ju närmare man kommer exekveringsfasen desto mer specifik data kommer att finnas tillgänglig som till

exempel väderprognoser och tillgänglighet av olika resurser, vilket gör att planeringen i slutet kan bli mer noggrann. I denna fas ska systemet generera uppskattningar i tider relaterat till avisningsprocessen, baserat på den data som för tillfället finns tillgänglig.

 Execution phase:

Övergången från planeringsfasen till exekveringsfasen ska uppstå då en pilot utfärdar en ARZT, Actual Request of De-Icing, och pågår fram tills dess att

avisningsprocessen är avslutad (OSED, 2011 s. 55). Om de faktiska tiderna inte stämmer överens med de uppskattade tiderna så ska nya beräkningar göras i systemet och en ändring i schemat för avisning av flygplan kan komma att genereras.

 Post flight analysis phase:

Då AEZT, Actual End of De-icing Time, har registrerats, det vill säga att avisning av

7

ett flygplan har slutförts, ska en övergång ske från exekveringsfasen till en fas där den slutgiltiga informationen används för analys (OSED, 2011 s. 59). Denna information ska sedan komma att användas som indata till nästkommande planeringsfas, vilket betyder att DIMT ska ha intelligensen att lära sig från de faktiska värdena då den i nästa planeringsfas föreslår uppskattningar för olika tider. Den data som genereras i denna fas kan också fungera som feedback till avisningsbolaget.

EDIT, Estimated De-Icing Time, är en faktor som har identifierats som en av de viktigaste faktorerna för att förbättra förutsägbarheten av avisning i A-CDM processen (OSED, 2011 s.

48). Genom systemet ska en uppskattad tid räknas ut för hur lång tid avisning ska ta för ett specifikt flygplan och på så sätt ska en så korrekt avisningsplanering som möjligt kunna genereras. Efter att ett flyg har avisats fås en slutgiltig tid för hur lång tid avisningen faktiskt tog, dvs. ADIT (Actual De-Icing Time). Detta värde loggas och tas senare med i beräkning för att kunna ge ytterligare bättre förutsägbarhet av EDIT för flyg som ska avisas under liknande förhållanden.

Genom att få planeringen av avisning så korrekt som möjligt kan detta bidra till att andra viktiga hålltider, så som Take-Off Time, för ett flyg också kan bli mer korrekta. Även avisningsbolag får fördel på så sätt att de enklare kan förutse sitt kapacitetsbehov.

Det finns en mängd olika parametrar som behöver tas med i beräkning relaterat till en de-icing process. För att EDIT ska kunna beräknas och ge ett så realistiskt värde som möjligt har fyra huvudsakliga faktorer identifierats som de mest viktiga parametrarna i denna beräkning:

 Väder typ:

Vilket väderförhållande som råder är den viktigaste faktorn som påverkar den uppskattade avisningtiden (OSED, 2011 s.49). Olika väderförhållande ska genom DIMT mappas till tre olika väderkategorier: Light, Moderate och Severe. Eftersom olika flygplatser kan ha skillnader i lokala väderförhållanden på grund av dess

geografiska läge, ska denna mappningen kunna vara olika från flygplats till flygplats.

En kombination av lufttemperatur och övriga väderförhållanden, så som

nederbördstyp, ska kunna mappas till en viss väderklassifikation som i sin tur påverkar EDIT.

 Flygplansstorlek:

Klassifikationen av ett flygplans storlek baseras på bestämmelser av ICAO, International Civil Aviation Organization (OSED, 2011 s.50).

Indelningen sker från A till F där ett flygplans vingbredd avgör:

A: 0 - 15 m B: 15 - 24 m C: 24 - 36 m D: 36 - 52 m E: 52 - 65 m F: 65 - 80 m

 Avisnings metod:

Hur man avisar ett flygplan och vilken vätskeblandning som används, påverkar

tidsåtgången för avisningen(OSED, 2011 s.50). Typen av vätska delas in i olika

klassifikationer (I-IV). Själva avisningsprocessen delas in i tre delar: snöröjning,

8

avisning på vingar, avisning på flygplanskroppen. Dessa tre delar i kombination med en vätsketyp ger en viss avisningsmetod.

 Truckar / avisningsenheter:

Vilken typ av fordon som används för att avisa ett flygplan samt hur många av dessa enheter som används är också en parameter som påverkar EDIT (OSED, 2011 s.50).

Beroende på hur många fordon som finns tillgängliga och även hur många som faktiskt behövs användas, i förhållande till flygplansstorlek och väderförhållanden, kan antalet fordon som används variera.

Olika kombinationer av dessa fyra ovanstående faktorer ska genom DIMT kunna mappas och ge individuella uppskattningar i hur lång tid avisningen tar för varje flygplan (OSED, 2011 s.52).

Exempel på mappningstabell för beräkning av EDIT

På så sätt ska DIMT kunna fungera som ett planeringsverktyg för avisningen av flygplanen, där noggrannheten av EDIT blir bättre allt eftersom systemet används eftersom ADIT sedan tas med i framtida beräkningar.

Det finns tre olika sätt att utföra en avisning på:

 On Stand: Avisning görs på plats där flygplanet står parkerat och görs vanligtvis av truckar (OSED, 2011 s.55). Därefter är flygplanet redo för att köras ut till sin

startbana.

 After Push: Innan avisning sker måste flygplanet flyttas bakåt ett kort avstånd eller till en annan plats där avisning är tillåten (OSED, 2011 s.57). Sedan görs avisning av exempelvis truckar och sedan är flygplanet redo för att köras ut till sin startbana.

 Remote: Flygplanet körs iväg till en specialutrustad plats med möjligheter till avisning (OSED, 2011 s.58). Det kan till exempel vara en stor hall som man kör igenom med flygplanet. Det här är det mest effektiva sättet att göra en avisning på.

Vilken av dessa tre som används påverkar den totala avisningssekvensen.

Andra tider som också är av vikt är EHOT, Estimated Hold Over Time, och AHOT, Actual

Hold Over Time och anger hur lång tid det får gå innan ytterligare en avisning måste göras

(OSED, 2011 s.68). Detta på grund av att de olika vätskeblandningarna enbart verkar under en

viss tid. En flygning har, innan avisning skett, en EHOT vilken sedan övergår till AHOT då

avisning är avslutad. Fördelaktigt är därför om dessa tider finns väl synliga för användare av

systemet.

9

Koordinatorn är den som har huvudansvar för att avisning sker och i vilken ordning den görs (OSED, 2011 s.8). DIMT ska föreslå en optimerad avisningssekvens för flygningarna de kommande 24 timmarna. För att systemet ska kunna beräkna en optimerad avisningssekvens så måste även uppkörningstider, för en truck till ett flyg, tas med i beräkning. Hur lång tid det tar för en truck att köra mellan olika plattformar, ska kunna mappas till en tabell specifikt för flygplatsen. Koordinatorn ska också ha möjligheten att göra manuella uppdateringar för att korrigera automatiskt uträknade tider.

En operatör är en person som sitter i ett avisningsfordon. Operatören ska få sitt körschema presenterat och enbart kunna ge enklare input till systemet, så som start- och sluttid för en avisning.

Med planeringsverktyget DIMT ska tid och pengar sparas för att flygplatsens kapacitet ska kunna utnyttjas på ett bättre sätt än den gör idag. Eftersom kapaciteten utnyttjas på ett bättre sätt sparar man på till exempel bränsle i truckarna och bidrar på så sätt till minskad

miljöpåverkan. En annan stor fördel blir att alla relevanta aktörer kommer att kunna ta del av samma information vid samma tidpunkt, vilket möjliggör för bättre samarbete på flygplatsen.

Tanken är att prototypen ska ha en simuleringsfunktion där historisk flygdata används i systemet för att man på så sätt ska kunna testa systemet innan det tas i bruk för användning.

Under simuleringen ska koordinatorn kunna utföra manuella uppdateringar och korrigeringar för olika parametrar i systemet, och se hur den simulerade schemaläggningen av avisning påverkas av detta.

Den här rapporten riktar sig till de grafiska användargränssnitten till systemet för

koordinatorn och operatören. Serversidan till systemet ska utvecklas av en medarbetare på

Saab ATM i Göteborg. Prototypen av De-Icing Management Tool, kommer att testas och

valideras utefter en verifikationsplan, på Arlanda Airport i Stockholm. Testerna kommer att

utföras av Swedavia medan valideringen kommer att göras av SESAR.

10

3 METOD

I detta avsnitt beskrivs de metoder som har använts för att finna svar på rapportens problem.

Vidare beskrivs de verktyg och tekniker som har använts, liksom motivering av valen till dessa.

3.1 INFORMATIONSINSAMLING

Tillvägagångssättet för att få reda på vad intressenterna främst ville ha ut av systemet, var att göra undersökningar av strukturen för hur de grafiska gränssnitten av Arlandas tidigare system för avisning sett ut. Även kontinuerliga interna möten och diskussioner inom projektgruppen, samt externa med Swedavia, bidrog till att komma närmre svaren på

rapportens problem. Det blev tydligare hur mycket och vilken information som skulle visas.

Likaså klarnade det på vilket sätt de grafiska gränssnitten till systemet skulle vara upplagda för att vara lättöverskådliga.

3.2 VERKTYG

Att göra de grafiska gränssnitten till systemet så effektiva och lätthanterliga som möjligt var av stor vikt, varför val av verktyg och tekniker kom att ha betydelse. I dokumentet Feasibility Study (2011) finns en sammanställning av några som är lämpliga, med för och nackdelar.

Utifrån detta gjordes val för vilka verktyg och tekniker som skulle användas för utvecklingen av de grafiska gränssnitten. Men även andra som inte var omnämnda i detta dokument valdes att arbeta med. I detta och följande avsnitt beskrivs valen som gjordes av verktyg och

tekniker, och varför.

3.2.1 NetBeans

För utveckling av systemet valdes NetBeans IDE (Integrated Development Environment) 7.1.1, vilket är en utvecklingsmiljö väl anpassad för att skapa olika typer av

webbapplikationer. Något som är positivt med NetBeans är att det innehåller

autokomplettering, viket innebär att förslag ges på metoder och variabelnamn då man programmerar. Denna utvecklingsmiljö är gratis och smidig att arbeta i, vilket gjorde att denna valdes.

3.2.2 WampServer

WampServer 2.2D är ett paket som innehåller servrarna Apache och MySQL, skripttolken PHP samt ett antal stödprogram. Med dessa program kunde klientsidan smidigt testköras lokalt mot serversidans PHP-filer under utvecklingens gång. Bland annat smidigheten att komma åt databasens struktur och innehåll gjorde att valet föll på WampServer.

3.2.3 Chrome

Enligt dokumentet rekommenderades Google Chrome som den webbläsare som passar bäst i förhållande till applikationens ändanmål. Det är en snabb webbläsare som bland annat stödjer många HTML5 funktioner. Den innehåller även en bra funktion för att granska komponenter på en webbsidas struktur. All utveckling av applikationen har därför främst anpassats för denna webbläsare.

3.3 TEKNIKER

Vad gäller teknikerna har vissa använts mer än andra för utvecklingen av klientsidan. De som

använts mest frekvent är de tre förstnämnda i kommande beskrivning. Här beskrivs även

varför just dessa valdes. Övriga tre tekniker var redan förbestämda av utvecklaren på

serversidan, varav ingen motivering över dessa val beskrivs.

11

3.3.1 Extensible HyperText Markup Language (XHTML)

XHTML är ett märkspråk och används som den grundläggande koden av en webbapplikation.

Här igenom styrs grunden för de olika webbsidornas struktur och utseende. Olika tillägg så som till exempel CSS (Cascading Style Sheets) och JavaScript kan sedan tillämpas till denna kod för att ge extra funktionalitet och smidighet.

XHTML är vidareutveckling av HTML som till största del syftar till att skapa XML- kompatibilitet (W3C, 2012-05-04a). Tolkning av den ursprungliga HTML-syntaxen är betydligt mer komplex än för XHTML. Detta på grund av att XHTML är ett mer strikt språk som därmed inte kräver lika mycket arbete av tolken. HTML tillåter fel i kodens uppbyggnad som tolken behöver korrigera vilket tar en hel del extra kraft samt att felaktig kod blir svår att upptäcka. Vid användning av XHTML krävs att dokumentet ska vara korrekt formaterat, vilket till exempel innefattar att alla element alltid måste stängas och inte får överlappas.

HTML5 har ytterligare funktionalitet gentemot HTML. Många av funktionerna har byggts för att på ett bättre sätt köras på mobila enheter. XHTML5 är en XML-serialiseringen av HTML5 (Wikipedia, 2012-05-03). Då korta svarstider och effektivitet var av stor vikt för DIMT blev XHTML5 det självklara valet att använda för systemets grafiska gränssnitt. Även det faktum att webbsidan för operatören skulle köras på en mobil enhet gjorde valet extra tydligt, eftersom det är viktigt att inte slösa på resurser för onödiga uppgifter på mobila enheter.

3.3.2 Cascading Style Sheets (CSS)

CSS används för att skapa den visuella layouten av en webbsida och är en av grundstommarna för att kunna skapa en webbapplikation (W3C, 2012-05-04a). Färger, fonter och storlekar är något av det som kan definieras med hjälp av språket CSS. Att använda separata CSS-filer istället för inbäddat i HTML-kod gör det möjligt att på ett smidigt sätt dela stil mellan olika webbsidor. Detta var något som var självklart att använda eftersom det är den främsta teknik som används för designen av webbsidor.

3.3.3 JavaScript

JavaScript är en vidareutveckling av ECMAScript som presenterades första gången i slutet av år 1995 (Wikipedia, 2012-05-04a). ECMAScript är ett skriptspråk som används på klientsidan i webbsammanhang. Det blev som standard kallat ECMA-262.

Ett skript är programkod som inte behöver kompileras innan det ska användas (W3C, 2012- 05-04b). Webbsidor använder skript i form av JavaScript som körs när sidan laddas eller när användaren till exempel trycker på en knapp som har ett skript kopplat till sig. Webbläsaren arbetar då mot ett gränssnitt som kallas Document Object Model (DOM), som gör åtkomst och dynamisk uppdatering möjlig av ett dokuments innehåll, stuktur och formatering.

DOM tillsammans med XMLHttpRequest-objekt, XHTML eller HTML och XML är tekniker som går under samlingsnamnet AJAX (Wikipedia, 2012-05-04b). AJAX gör webbsidor mer dynamiska och gör att data kan utbytas med servern och presenteras utan att hela sidan laddas om.

För att kunna ta del av AJAX och för att förenkla modifikationen av webbsidan valdes JavaScript-biblioteket Jquery att användas i gränssnitten för DIMT. Det har bland annat använts för att ändra innehåll när man växlar mellan olika flikar på gränssnittet för

koordinatorn respektive operatören. Även när data hämtas från eller skickas till serversidan

12

görs AJAX-anrop. I retur erhålls ett XML-svar där Jquery används för att plocka ut informationen som behövs.

Jquery har använts för de flesta funktionerna i DIMT V2 för att kunna generera ny HTML- kod till sidan utan att behöva ladda om hela webbapplikationen. Detta för att effektivisera och göra DIMT V2 mer användarvänligt.

3.3.4 SQL Databas

I en databas lagras information på ett organiserat sätt (SearchSQLserver, 2012-05-04). Som databashanterare har MySQL valts. MySQL Server bygger på en relationsdatabas vilket är en databastyp där informationen är organiserad i relation till vartannat, vilket gör att det är lätt att registrera, uppdatera, ta bort samt söka information (Wikipedia, 2012-05-21).

För att lagra data, så som information om avgående flygningar, olika värden till de olika mappningstabellerna, har en MySQL databas använts. Interaktion med databasen sker kontirnuerligt då applikationen körs.

3.3.5 Hypertext Preprocessor (PHP)

PHP är ett skriptspråk som främst körs på webbservrar (Wikipedia, 2012-05-04c). Det underlättar att använda PHP då man skapar webbsidor som använder sig av dynamiskt innehåll som genereras från till exempel databaser.

All data i databasen hämtas med hjälp av PHP-filer som skapats av en medarbetare, som arbetat med serversidan. Beräkningar på data i databasen görs genom PHP-filerna. För de grafiska gränssnitten kommer dessa till användning genom att PHP-filerna genererar XML- svar, vilket gör det enkelt att plocka ut den väsentligaste informationen. Även uppdateringar som görs genom de grafiska gränssnitten, till databasen sker via dessa PHP-filer.

3.3.6 Extensible Markup Language (XML)

Avsikten med användning av XML är att utbyta data mellan olika informationssystem och används för att strukturera och organisera data (Wikipedia, 2012-05-04d). Den information som skickas skrivs in i en XML-fil enligt en viss struktur och det krävs att både sändare och mottagare av filen vet hur strukturen är uppbyggd med dess element och attribut, för att filen effektivt ska kunna hanteras.

Den data som genereraras från databasen, via PHP-filer, kommer som XML-svar till

klientsidan. Stor del av den information som visas i de grafiska gränssnitten är data som, via

Jquery, plockats ut från XML-strukturen.

13

4 PROCESS

I detta avsnitt beskrivs hur processen fortlöpte, för att få fram hur mycket och vilken

information som skulle visas i de grafiska gränssnitten till DIMT V2. I denna process beskrivs även arbetet för att få fram två lättöverskådliga grafiska gränssnitt till systemet. Hela

processen består av två faser: Planeringsfasen och Utvecklingsfasen.

4.1 PLANERINGSFASEN

Innan utvecklingen av applikationen startade lades tid ner på att sätta sig in i hur processerna fungerar vid en ”turn a round”- och avisningsprocess samt att överlag förstå de problem som skulle lösas.

Två huvudsakliga dokument gällande projektet fanns tillgängliga. Dessa lästes igenom för att kunna sätta sig in i uppgiften.

 P06.06.02- D01 –Operational Service and Environment Definition (OSED):

Detta är ett dokument framtaget av Swedavia i samarbete med medlemmar inom SESAR. Dokumentet beskriver detaljerat både hur avisningsprocessen på flygplatser tidigare fungerat, och hur tanken är att denna process sedan ska fungera med hjälp DIMT.

Att läsa igenom detta dokument gjorde att helhetsbilden av uppgiften tydliggjordes samt även att delen för hur avisningsprocessen överlag fungerar blev klarare. Många viktiga parametrar rörande avisning identifierades, så som till exempel EDIT och strukturen för de olika mappningstabellerna.

 P12.06.02-D06 – Feasibility Study Report Edition: 00.01.01:

Beskriver rekommendationer av vissa tekniker som bör nyttjas under utvecklingen av DIMT och är framtaget av Andreas Sjöberg på Saab ATM.

Utifrån dessa rekomendationer diskuterades och bestämdes vilka program och tekniker som skulle komma att användas. Diskussionerna för val av tekniker grundades mycket på hur applikationen skulle komma att bli så effektiv som möjligt. En av dessa

tekniker var XHTML5 för att applikationen skulle ha korta svarstider och på bättre sätt skulle kunna köras på mobila enheter.

Att ta reda på vad som intressenterna främst ville ha ut av systemet var något som också lades ned mycket tid på, både under planeringsfasen, men även under utvecklingens gång. Detta genom ett flertal möten, både internt inom projektgruppen på Saab AB, men även med Swedavia. Med så många parametrar i beräkning blev det av stor vikt att selektera ut vilken information och funktionalitet i de grafiska gränssnitten som var viktigast att fokusera på.

För att försöka göra de grafiska gränssnitten till DIMT till det bättre gentemot hur

avisningsbolagens system tidigare fungerat gjordes undersökningar av detta. Genom

Swedavia kunde skärmdumpar från de tidigare systemens gränssnitt erhållas för analys, se

Bilaga 1. Då DIMT skulle komma att innehålla mycket av ny information jämfört med de

tidigare systemen gjordes ingen större analys av olika parametrar, utan främst strukturen i

helhet. Här insågs att strukturen över informationen var svåröverskådlig. Olika flygningar

listades upp på en helt egen sida med flertalet attribut per flygning direkt synliga i en tabell,

vilket gjorde att helheten såg rörig ut. Övrig information om avisningstruckar visades i en

14

liten ruta på en egen sida. Genom denna undersökning ansågs det att det bästa vore att ha information om flygningar och avisning mer samlat på en och samma sida, men utan att det för den sakens skull bli för svåröverskådligt.

För att ha något att utgå ifrån gjordes en skiss över det grafiska gränssnittet för koordinatorn där så många parametrar som möjligt försöktes tas med utifrån de dokument som lästs

igenom. Det grafiska gränssnittet till operatören valdes att väntas med att planeras tills dess att en tydligare bild över koordinatorns gränssnitt erhållits. Fokus lades på att försöka få ett så användarvänligt och enkelt gränssnitt som möjligt för koordinatorn, men ändå att så mycket information som möjligt skulle finnas tillgängligt.

Flight no EOBT EDIT

Update Resourses

Unit 1 Unit 2 Unit 3 Unit 4 Unit 5

UNITS STANDS General info Info Update

General settings

Unit 6 Unit 7 Unit 8

Unit Flight no Stand ERTZ ARTZ

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

De-Icing Management Tool

Weather Stand Apron A/P size Flight no

light F 1b AF abc123

DI-meth DI-comp

c14 Ice ab

TTOT DIWT STOT

ERZT Apron ARZT SOBT

EEZD ECZT ACZT

Stand ADIT A/P size

AEZD

HOT MET A/P size

AIBT Apron EXOT AHOT

Deviation

+ Add

Första skissen som skickades till Swedavia

Tanken var att dela in gränssnittet i tre olika moduler på sidan.

 Flight list:

Lista till vänster där alla flygningar inom ett 24 timmars intervall skulle listas upp, där enbart den mest väsentliga informationen per flygning skulle visas, så som

flygnummer, EDIT (Estimated De-Icing time) och EOBT (Estimated Off Block Time). Listan skulle vara skrollbar för att få plats med alla flygningar, och varje flygning i listan skulle ges möjlighet att klicka på.

 Flight information:

Mer ingående information per flygning skulle visas uppe i högra hörnan genom att klicka på en flygning i listan till vänster. Här skulle information om flygningen och flygplanet visas samt avisningsparametrar och olika hålltider för den specifika

flygningen. Korrigeringar av avisnings-parametrar för en specifik flygning skulle även

vara möjligt för koordinatorn att göra genom denna modul, varför den delen valdes att

läggas under en egen flik för att förebygga att oavsiktliga ändringar.

15

 General settings:

Här igenom skulle mer allmänna inställningar av avisningsparametrar och

mappningstabeller kunna göras, som skulle kunna komma att påverka avisning för flera flygningar och inte enbart för en specifik flygning. Även annan generell information som till exempel information om truckar och väder skulle finnas tillgänglig här.

Skissen presenterades först för övriga inom projektgruppen på Saab ATM, där det inte fanns några större invändningar mot förslaget. Efter detta skickades skissen ut till Swedavia för att kunna undersöka om detta var något som skulle kunna ses som användbart för en koordinator.

Överlag ansåg de att strukturen var bra som utgångspunkt, med enbart några mindre synpunkter angående olika parametrar. Att ha TOBT (Target Off Block Time), istället för EOBT som en parameter i listan över flygningar var något som ändrades.

Efter detta fanns en grund att utgå ifrån och utvecklingen av applikationen kunde påbörjas.

Planeringsfasen fortlöpte dock under hela utvecklingsprocessen med kontinuerliga möten och diskussioner inom projektgruppen och med Swedavia, varav planeringen för utformningen av applikationen successivt ändrades.

4.2 UTVECKLINGSFASEN

Till en början gällde det att sätta sig in i de olika teknikerna samt hur interaktionen dem emellan fungerade. Något som insågs var att stor del av XHTML5-koden skulle behöva att genereras via Jquery. Detta eftersom många kopplingar mot servern skulle göras men även på grund av att en webbsida kan göras mer dynamisk om XHTML5-kod genereras genom skript istället för att ha den hårdkodad. Då funktionaliteten över teknikerna blev tydligare kunde sedan utvecklingen av applikationen påbörjas.

Här nedan beskrivs utvecklingsfasen för var och en av modulerna som skapades och hur teknikerna har använts.

4.2.1 Flight list

Listan för avgående flygningar började byggas upp av en tabell med ett antal rader med hårdkodad data för att se hur det såg ut grafiskt. I ett tidigt skede listades attributen flight- nummer, TOBT (Target Off Block Time) och EDIT (Estimated De-Icing Time) enligt skissen.

Flightlistan i tidigt stadium

Tabellens uppbyggnad gjordes i JavaScript för att det skulle gå att lägga till fler avgångar

dynamiskt. För att listan ska kunna innehålla flera rader med avgående flygningar lades en

skroll-funktion till. CSS-koden: ” overflow: auto; ” gör att skroll-funktionen enbart visas då

antalet rader som läggs till inte får plats i den synliga delen av tabellen.

16

Då det bestämts att varje flygning i listan skulle vara klickbar, för att på så sätt kunna expandera ytterligare information om flygningen, hittades en lösning för detta genom att använda Jquerys .live()-metod.

Denna metod kan kopplas till olika element och hantera vissa händelser som en användare utför på elementet, så som ett klick i detta exempel. .live()-metoden fungerar både för element som skapas när en internetsida laddas, och även på nya element som skapas dynamiskt med hjälp av skript under körning. Vid ett klick på en avgång i listan hämtas information från denna rad i tabellen. Sedan görs en sökning på flygnumret och TOBT i databasen och därefter presenteras mer detaljerad information, till exempel flygplansstorlek och flygbolag.

Informationen visas i modulen med mer ingående information för den specifika flygningen.

I ett tidigt skede mottogs en testfil med exempeldata i XML-format från utvecklaren av serversidan, med information om ett fåtal avgående flygningar. För att kunna hämta XML- filen och plocka ut information från denna skickades, via Jquery, en AJAX-begäran till servern.

$.ajax({

url: "test.xml", type: "post", data: data,

// callback handler that will be called on success success: function(xml){

// call method to add flight to the list updateList(xml);

},

// callback handler that will be called on error error: function(){

} });

AJAX-metod som hämtar information från testfilen med flygningar

Generellt fungerar metoden på så sätt att man kan skicka data mellan server och klient genom denna. I detta fall skickas filen från servern till klientsidan, och då mottagningen lyckats (”success:”) anropas metoden updateList() där XML-stukturen som mottagits skickas med.

Iteration görs på de olika flygningarna och den väsentliga informationen plockas ut med hjälp av Jquery. Ett exempel för att hämta ett flygplansnummer är

som ger ”145” enligt XML-strukturen nedan.

XML-struktur av en flight

Efter att Swedavia hade fått ta del av bilder på listan av avgående flygningar blev deras kommentarer att man borde kunna se ytterligare information på raden för varje avgående flyg i listan. Därför valdes att lägga till kolumner för ”Place”, ”Typecode”, ”Regnr”,

”ERZT”(Estimated Ready for de-icing Time) och ”Weather”. ”Place” beskriver vart

17

flygplanet står parkerat. ”Typecode” är en kod på tre tecken som beskriver flygplanets modell.

”Regnr” anger registreringsnumret för respektive flyplan. ”Weather” presenterar en bild som beskriver vilket väder som råder då planet ska avisas, ”Light”, ”Moderate” eller ”Severe”.

Raderna för varje avgående flygning gjordes även smalare för att koordinatorn ska kunna se så många flygningar som möjligt utan att behöva bläddra neråt i listan.

För att utveckla DIMT V2 på ett trovärdigt sätt behövde Swedavia leverera historisk data över avgående flygningar på Arlanda och väderförhållanden för ett par dagar samt en del övrig information från avisningsbolagen. När väl data om avgående flygningar tillhandahållts, skapade utvecklaren av serversidan en PHP-fil som hämtar dessa från databasen och genererar informationen som ett XML-svar. I det grafiska gränssnittet hämtas flygningarna på samma sätt som tidigare med hjälp av att en AJAX – begäran, via Jquery, skickas till serversidan. I och med att det nu handlade om att ett hundratal flygningar skulle hämtas gentemot de tre flygningarna som fanns i den tidigare test-filen, blev laddningstiden cirka fem sekunder lång.

Även vid ett klick på en specifik flygning tog det uppemot fem sekunder för att söka upp samma flygning i XML-svaret från servern och söka upp den flygspecifika information som skulle visas. Problemet löstes genom att spara en lokal kopia av XML-filen när data

returnerades genom en AJAX -begäran till servern. Detta för att reducera dataflöde mellan server och klient och effektivisera fördröjningar i gränssnittet. Den lokala filen användes sedan för att undvika att interagera med servern varje gång man tryckte på en flygning i listan.

Det förbättrade laddningstiden på sidan betydligt och bidrog till ett mer användarvänligt gränssnitt.

Ett programmeringsmässigt fel som visade sig då hämtning av en stor mängd flygningar började göras, var att vid ett klick på en flygning i listan söktes inte rätt information upp i XML-strukturen så fel flygspecifik information visades i gränssnittet. För att lösa det här gjordes en räknare som räknar antal noder med flyg i XML-strukturen. När en rad läggs till med ett flyg i listan läggs ett ID till raden, som får ett värde innehållande ett indexnummer för identifiering. Indexnumret är då beroende på det antal räknaren har kommit upp till då raden läggs till. Numret anger vilken nod flygningen ligger på i XML- strukturen. Vid tryck på en specifik flygning tas därför indexnumret och hämtar den noden från XML- strukturen och plockar ut den informationen som ska presenteras.

$(xml).find('flight').eq(index);

Kod för att plocka ut noden på position “index”.

Listan med avgående flygningar ska uppdateras en gång per minut så att inte flygningar som redan avgått ligger kvar i listan. Därför gjordes en skript-funktion som gör ett AJAX-anrop och hämtar XML-strukturen över avgående flygningar från servern var 60:e sekund och därefter uppdaterar listan med de nya flygningarna.

var updateFlightList = setInterval(function() {

loadXML(1, min, max, 'update', "");

}, 60000);

Exempel på funktion som görs var 60:e sekund

I XML-strukturen, som fås från servern med avgående flyg, hämtas även DIMT:s simulerade klockslag som sedan används i gränssnittet. Flyg vars SOBT (Scheduled Off Block Time) har passerats av den simulerade tiden presenteras inte i listan. SOBT är den schemalagda tiden för när ett flyg ska lyfta, och tillsammans med flygnumret är detta det som identifierar en

avgående flygning.

18

Listan hade bestämts att visa avgångar för de närmsta 24 timmar efter den simulerade tiden.

Utifrån den historiska data som erhållits över avgående flyg på Arlanda insågs att uppemot 200 flygningar skulle kunna komma att förekomma inom ett 24 timmars intervall. För att göra gränssnittet mer användarvänligt utvecklades en sorteringsmetod där ett tidsintervall väljs som till exempel visar från nu och fem timmar framåt. Det görs med hjälp av en ”slider” som sätter ett minimum och ett maximum värde och därefter hämtas flygningarna som ligger mellan det angivna intervallet från XML-strukturen. addTableRow() lägger till en flygning i listan med de attribut som är bestämda för listan. För att veta vilka flygningar som ligger i intervallet jämförs respektive flygnings SOBT med den simulerade tiden.

”Slider” för val av intervall som ska visas och sökfunktionen.

Efter undersökning mot Swedavia beslutades att en sökfunktion för flygningarna borde finnas.

Detta för att koordinatorn lätt ska kunna ändra någon parameter för ett specifikt flyg utan att behöva leta igenom hela listan efter flyget. Sökfunktionen byggdes upp på så sätt att då koordinatorn skriver något i fältet så söks XML-stukturen över flygningar direkt igenom och letar upp den eller de noder som innehåller den inskrivna texten i namnet på flygningen. Den eller de noder som hittas plockas ut och listas upp i listan över flygningarna. En anpassning gjordes även så att sökfunktionen skulle fungera i kombination med valt tidsintervall i

”slidern”.

Om en nods flygnummer innehåller det inmatade i sökfunktionen, så listas flygningen till ”Flight List”

Funktionaliteten för ”flight list” blev klar i ett relativt tidigt stadium av utvecklingsfasen och efter detta lades en del tid ned på designen där bland annat skuggeffekter och andra

färgkombinationer lades till. Sedan övergick mer fokus till de övriga modulerna.

4.2.2 Flight Information

Denna modul började utvecklas utifrån den mall som skissats upp i det första stadiet i planeringsfasen. Här var tanken att mer ingående information för en specifik flygning skulle visas, då en flygning väljs ur listan till vänster.

Ingen data från serversidan fanns tillgänglig i skedet vid början av skapandet av denna modul.

19

Istället listades hårdkodad data för en flygning i en enklare tabell, utan någon speciell struktur över parametrarna.

En testfil med exempeldata i XML-struktur över några få avgående flygningar blev så småningom tillgänglig från serversidan.

XML-fil med exempeldata för en specifik flygning

På grund av att relativt många parametrar med information skulle listas upp i denna modul så valdes att göra en ändring i strukturen för att göra informationen överskådlig. Tre tabeller skapades, där information relaterat till flygplanet valdes att läggas i en tabell under rubriken

”Airplane”. Avisningsinformation i en tabell med rubriken ”Deicing”, samt information om olika hålltider för en flygning i en tabell med rubriken ”Timeline”.

Utökad information för en specifik flygning

Två knappar lades högst upp i modulen, ”Information” och ”Update”, med möjlighet att kunna skifta mellan två vyer. Ena vyn med ”Information”, för att enbart visa data för

flygningen utan möjlighet att kunna göra ändringar, samt en vy under knappen ”Update” där koordinatorn skulle ges möjlighet att göra ändringar för den valda flygningen. Då det från början var oklart vilka parametrar som skulle kunna ändras av en koordinator för en flygning, lades det till editerbara fält för alla parametrar. Även det faktum att ingen PHP-fil för

möjlighet att göra uppdateringar till databasen fanns färdig, hade dessa fält ingen koppling till

databasen vid detta skede.

20

Klick på ”Update” visar en vy med möjlighet att editera parametrar

Jquery valdes att användas i koden för att smidigt kunna ladda om innehållet i modulen vid klick på knapparna ”Information” och ”Update”, utan att påverka något annat på webbsidan.

Metoderna loadFlightInfoXML(index) samt updateFlightInfoXML(index), anropas vid klick på ”Information” respektive ”Update”. Var och en av dessa metoder tömmer innehållet i modulen för att sedan generera den förbestämda koden som finns för respektive knapp.

Attributet index anger den nod som ska hämtas i XML-strukturen över alla flygningar, och detta index kommer ifrån den flygning som är klickad på i listan över avgående flygningar till vänster på webbsidan.

Jquery-anrop vid klick på ”Information” eller ”Update

Eftersom mycket av informationen skulle komma att innehålla förkortningar så valdes att skapa ”popup”-rutor som visar förklaring av dessa. En ”popup”-ruta visas då musen förs över en förkortning. Vid tidpunkten för skapandet av detta fanns det i databasen enbart en

tabellstruktur för att lagra förkortningar. Då ingen data över förkortningar fanns tillgänglig så gjordes enbart förberedelse av ”popup”-rutan, för att sedan kunna koppla samman denna med databasen.

Popup-ruta som visas då musen förs över en förkortning

Under utvecklingens gång bibehölls strukturen för modulen relativt likt till den ursprungliga, förutom några ytterligare detaljer i tabellen som visar olika hålltider. Där lades ett attribut till,

”Place”, med information om vart planet befinner sig vid de olika hålltiderna. Varje tid har

även ett datum relaterat till sig som inte visas i det grafiska gränssnittet. En informationsikon

21

lades till som visar då det är en avvikelse i datumet för tiden jämfört med den simulerade tiden. Då man håller på ikonen visas en ”popup”-ruta med det datum som är av avvikelse.

Ändringar i designen, så som användning av flikar istället för knappar för ”Information” och

”Update” lades också till, samt ändringar i färger och skuggeffekter. Något som dock fick planeras om var förklaringarna för förkortningarna som skulle komma att visas i ”popup”- rutor. Tidsbegränsningar från serversidans håll gjorde att metoder istället gjordes på klientsidan för att förklara förkortningarna.

Flightinformation efter uppdatering

Relativt sent under utvecklingens gång blev en PHP-fil klar från serversidan med möjlighet att kunna göra uppdateringar i databasen för parametrar relaterat till en specifik flygning.

Flertalet av de fält med information som tidigare under utvecklingen tillfälligt lagts som editerbara fick tas bort eller ändras på grund av systemets begränsningar för uppdateringar.

För att göra dessa uppdateringar i databasen sker, vid klick på ”Save”, en AJAX-begäran till PHP-filen på servern som hanterar avgående flygningar

Ajax-anrop för uppdatering till databasen

Alla de fält där värdet ska uppdateras i databasen måste ligga inom HTML:s ”<input>”- taggar, där dessa ”<input>”-taggar i sin tur ligger inom ett formulär (”<form>”). Den data om ligger inom ”<input>”-taggar i formuläret serialiseras och skickas via AJAX-begäran till servern som i sin tur bearbetar informationen. Varje fält har ett unikt namn för att rätt uppdateringar i databasen ska kunna göras. Identifierande parametrar för flygningen så som

”Flight number” och ”SOBT” skickas även med för att serversidan ska kunna uppdatera flygningen korrekt.

Ett krav som finns för projektet är att historik ska kunna presenteras, vilket inkluderar alla

ändringar som gjorts. För att det ska vara möjligt skrivs aldrig information i databasen över,

utan det läggs alltid till ny information. När webbapplikationen körs hämtas enbart den

senaste sparade informationen från databasen.

22 4.2.3 General information

Den tredje modulen var från början oklart vad den skulle innehålla, men det var tänkt att den skulle samla alla allmänna inställningar för DIMT och annan generell information. Ett exempel på det är de olika truckarnas körschema. Något annat som planerades finnas under allmänna inställningar var tabeller för mappning av uppskattade tider för avisning (EDIT), väder och för tiden det tar för en truck att köra mellan plattformarna.

Modulen ”General information” som visar ”Other information” i tidigt stadium

Då data från serversidan saknades från start, byggdes en stomme upp för de olika delarna. I modulen skapades knappar för de olika områdena, ”Other information” och ”Units”, där innehållet i modulen byts beroende på vilken knapp som klickas på. ”Other information” var tänkt att innehålla de olika mappningstabellerna och där gjordes en struktur med tre enkla tabeller. På liknande sätt gjordes även ”Units”, med enbart en tabell med tanken att lista upp truckarnas körschema för de kommande 24 timmarna i en tabell när väl data för detta skulle komma att bli tillgänglig. För att bygga upp en tabell används HTML-taggen ”<table>” som en yttre ram till tabellen. Innuti varje tabell läggs sedan ”<tr>”-taggar där varje sådan tagg representerar en rad i tabellen. För att lägga till kolumner i en rad läggs ett antal ”<td>”- taggar, beroende på hur många kolumner man vill ha, innuti varje ”<tr>”-tagg.

Något som ansågs skulle vara bra att kunna göra för en koordinator var möjligheten att kunna

ändra vissa parametrar för flera flygningar. Därför lades ytterligare en knapp till högst upp i

modulen vid namn ”Multiple Changes” med en vy för hantering av detta. En tabell gjordes

där samtliga flygningar laddas till denna via en AJAX-begäran, på liknande sätt som i ”Flight

list”. Varje rad innehåller en ”checkbox” där koordinatorn ska kunna välja ett antal flygningar

och sedan ges möjlighet att ändra vissa parametrar på samtliga valda flyg. En tabell skapades

med de parametrar som ansågs vara rimliga att kunna ändra. Eftersom en PHP-fil saknades på

serversidan för möjlighet att göra uppdateringar, så kunde ingen koppling göras i det här

skedet.

23

”Multiple changes”

För att kunna se aktuell simulerad väderprognos och även kunna påverka inställningar av detta så skapades knappen ”Weather settings”. En ruta för att manuellt kunna ställa in vädertyp, ”Light”, ”Moderate” och ”Severe”, för de kommande timmarna lades till. Det byggdes även en enkel tabell med en hårdkodad väderprognos timme för timme. Till en början listades enbart tidpunkt och vädertyp.

Väderprognos med möjlighet till ändring

Allt eftersom utvecklingen fortlöpte valdes att läggas till ytterligare detaljerad information så som vindhastighet, nederbördsmängd och nederbördstyp. Även en tydligare och större ruta för vädret den nuvarande simulerade timmen lades till.

Designen ändrades till att ha ett liknande fliksystem och skuggeffekter som används i ”Flight information” för att få ett enhetligt utseende.

Flikar istället för knappar

För att göra animerade flikar används CSS-kod, där utseendet på dessa baseras på gif-bilder.

Olika stilattribut sätts i CSS-koden beroende på om fliken är klickad på eller ej.

24

Del av CSS-kod för utseendet av flikar.

Under utvecklingsprocessen gjordes flertalet ändringar i modulen ”General information”.

Efter undersökande arbete mot Swedavia och diskussion inom gruppen togs beslut att informationen skulle delas upp. Då skapades en ny vy, ”General settings”, som kom att innehålla de tre mappningstabellerna. I samband med detta drogs även slutsatsen att ”Units”

skulle att komma behöva ändras. Detta eftersom det skulle bli svåröverskådligt om ett stort antal truckars körschema skulle synas samtidigt i en tabell. För att göra något mer nytänkande gjordes då en helt ny vy, ”Units view”, med ett slags grafiskt rutnät som presenterar varje trucks körschema på ett mer överskådligt sätt. Denna beskrivs senare i rapporten.

”Units” valdes ändå att behållas. Detta för att om operatörens enhet har gått sönder så ska istället koordinatorn kunna mata in start- och sluttid för en avisningsprocess i DIMT. I ett sent stadium gjordes metoder för att hämta alla truckars körschema från servern via en AJAX- begäran och sedan presentera dessa i en lista i den vy. Vid tryck på ett objekt i listan ges möjligheten att sätta antingen en ACZT (Actual Commence of De-Icing Time) eller en AEZT (Actual End of De-Icing Time). Det lades även till två sökfunktioner där den ena med

funktionalitet liknande den för ”Flight list” som filtrerar listan efter flygnummer, medan den andra filtrerar avisningar baserat på truckarnas namn.

4.2.4 General settings

En bit in i utvecklingen av applikationen så insågs att modulen för ”General information”

skulle komma att innehålla stor del av information och funktioner. Efter diskussioner bestämdes att lägga mer allmänna inställningar, som påverkar DIMT, på en helt egen sida.

Högst upp på sidan lades två knappar, ”Flight Events” och ”General Settings”. Den förstnämnda knappen skulle vid klick på denna, visa hela den hittills skapade vyn för

koordinatorn. Vid klick på knappen för ”General Settings” skulle hela sidan under knapparna laddas om, och istället visa en vy där koordinatorn skulle ges möjlighet att påverka allmänna inställningar.

25

Knapparna ”Flight Events” och ”General Settings” högst upp på sidan för skiftning mellan vyerna

Det som en koordinator skulle kunna påverka var de tre olika mappningstabellerna till

systemet: ”Weather settings”, ”EDIT Look-Up Table” samt ”Drive-Up Times”. Strukturen för dessa mappningstabeller hade tidigare under utvecklingens gång påbörjats skapas i ”General information”. Eftersom det nu istället fanns betydligt större yta att utnyttja för tabellerna valdes att ändra upplägget för dessa. I ”General Settings” skapades tre flikar, en för varje tabell.

Strukturen för de tre olika tabellerna utvecklades på liknande sätt. Informationen som listas upp i tabellerna sker genom att en AJAX-begäran görs för den fil med information som ska hämtas från servern. Varje mappningstabell har en tillhörande PHP-fil. Ett XML-svar genereras där informationen, via Jquery, plockas ut och listas upp i den aktuella tabellen.

Vy för ”EDIT Look-Up Table” i ”General Settings” då de tre mappningstabellerna flyttats hit

Vy för ”Weather Settings” i “General Settings”