Datateknik C, Examensarbete, 15 högskolepoäng
Implementation av binary messages i AIS och
användargränssnitt för egendefinierade
meddelanden
Jimmy Makkonen och Matthias Segelström Dataingenjörsprogrammet, 180 högskolepoäng Örebro vårterminen 2016 Examinator: Dag Stranneby Örebro universitet Orebro University Institutionen för School of Science and Technology
Innehållsförteckning
Sammanfattning 2 Förord 3 Inledning 4 Bakgrund 4 Projekt 6 Del 1 6 Del 2 6 Del 3 7 Del Extra 7 Syfte 7 Krav 7 Arbetsfördelning 7 Metoder och verktyg 10 Metoder 10 Del 1 10 Del 2 10 Del 3 10 Del Extra 10 Verktyg 10 Förberedelser 11 Första steget 11 Förstå problemet 11 Idéer för programmet 12 Inläsning på NMEA och AIS protokollen 13 Genomförande 19 Resultat 31 Del 1 31 Del 2 31 Del extra 34 Diskussion 35 Uppfyllande av projektets krav 35 Speciella resultat och slutsatser 36 Projektets utvecklingspotential 38 Reflektion kring eget lärande 38 Kunskap och förståelse 38 Färdighet och förmåga 41 Värderingsförmåga och förhållningssätt 42 Referenser 43 Informationssökning 43 Bilagor och figurer 45Sammanfattning
I Nyköping utövar försvaret telekrigsövning för målflyg vilket Saab i Arboga är en del av. Telekrig är ett “digitalt krig” där syftet är att störa ut elektrisk utrustning, exempelvis störa ut radarfunktionen så att en eventuell fiende inte ska dyka upp på densamma. Syftet med uppgiften var att tillförse målflygen med ett kommunikationssätt som underlättade kommunikationen vid en övning. Detta kommunikationssätt måste vara hemligt då man aldrig kan veta vem som lyssnar på informationen som skickas. Komradion behövde en ersättare som både var snabb, säker och enkel att använda. Kommunikationen skulle komma att ske via transpondrar som är installerade i samtliga övningsflygplan Nyköping tillhandahåller. Dessa transpondrar skickar och tar emot den vanliga AISinformationen vilket bland annat beskriver riktning och bäring för planet. Del ett av uppgiften gick ut på att undersöka dessa transpondrar för att se om det fanns möjlighet att skicka egendefinierade meddelanden. Denna uppgift löstes genom att koppla upp två datorer till transpondrarna och pratade med dem via IP. I del två av uppgiften ingick det att ta fram funktioner, ramverk och stödprogram för meddelandekommunikation. Genom att ta fram en programvara som grundades på lösningen i del ett så kan vi ta emot och sända ut meddelanden på radionätet vilket effektiviserar kommunikationen vid telekrigsövningar där flertalet enheter deltagar. Vi tog fram ett programvara som agerade hjälpprocess till programvaran i del ett. Programvaran genererar hemliga kodord till varje textkommando så att endast ett kodord behöver transmitteras över nätet, där kodordet matchas mot en textstäng på mottagande sida. I sista delen av uppgiften, som vi skulle göra om tid fanns, skulle vi göra en applikation som gjorde detsamma som programvaran i del två gjorde fast på en surfplatta. Detta löste vi genom att innan vi började på del två använda ett tillägg som tillät oss att köra programvaran på både dator och surfplatta.Förord
Denna rapport är resultatet av tio veckors arbete på Saab i Arboga som ett avslutande moment på Dataingenjörsprogrammet vid Örebro universitet. Målet med arbetet är att självständigt utvärdera och i vårt fall lösa ett reellt problem och analysera densamma samt komma fram till rimliga slutsatser. Vi vill tacka vår handledare Andrey Kiselev samt vår kontaktperson på Saab, Jörgen Ekstedt som båda stöttat oss i processen. Ett särskilt tack riktas också till Peter Bergljung på Transpondertech som blev en nyckelperson vad gäller vår arbetsframgång. Örebro universitet, 2016 Jimmy Makkonen och Matthias SegelströmInledning
Bakgrund
Saab tillgodoser den globala marknaden med världsledande produkter, servicerelaterade tjänster och militärdefensiva lösningar. Saab är verksamma över hela världen, de anpassar och utvecklar ny teknologi för att möta allmänhetens varierande behov. De viktigaste marknaderna är Europa, Sydafrika, Australien och USA. De har 14000 anställda med en årlig försäljning för omkring 24 miljarder kronor, av vilka forskning och utveckling utgör cirka 20% [1]. Saab grundades som flygplanstillverkare den andra april år 1937 som ett samarbete mellan NOHAB i Trollhättan och ASJA i Linköping. Redan året därpå färdigställde de deras första fabrik i Trollhättan och i samband med det vann de en licens för att bygga flygplansmodellen Junkers Ju86K, designerad B3. Året efter, 1939, konkurrerade Saab och ASJA med varandra om vilka som skulle få förtroendet att bygga ett nytt spaningsflygplan, uppdraget gick till ASJA’s favör, dock så övertogs ASJA’s verksamhet av Saab senare samma år [2]. I slutet av femtiotalet gick Saab in datormarknaden genom att gå med i något som kallas Datasaab (som senare blev ett eget företag) vilket var en division vars syfte var att integrera små datorer i flygplan som skulle fungera som ett navigeringsverktyg. Datorn kom att kallas CK37 och användes bland annat i flygplanet Viggen så sent som år 1971 [3]. Saab i Arboga inriktar sig mot reparationer och underhåll av flygplan tillhörande flygvapnet. Här sker samarbete med flygvapen över hela världen. I Nyköping utför försvaret träning av telekrig vilket Saab i Arboga är en del av. Telekrig är ett “digitalt krig” vars huvudsyfte är att exploatera känslig eller hemlig information från sin motpart/fiende. Träningen innefattar simulering av diverse elektronikstörningar i kritiska situationer. Övningens syfte är att träna/förbereda soldater att utföra uppgifter med utslagen eller manipulerad utrustning. Eftersom att liknande risker föreligger är det viktigt att piloterna har ett flertal sätt att kommunicera. Enheten för målflyg använder idag en särskild maskinvara, och tillsammans med utvecklad radioteknik och en programvara som kallas GPSMAP kan de se var alla olika enheter (flygplan) befinner sig i luften under olika typer av övningar. Utgående data från maskinvaran (transpondern) är information som definieras i AISprotokollet (Automatic Identification System). Fordon som väger mer än 300 ton måste vara ha utrustning installerad avsedd för att skicka ut AISinformation [11]. Utskicket av AISinformation har som huvudsyfte att informera medtrafikanter om ett fordons aktuella position (se Fig. 1). När AISutrustningen är rättkonfiguerad så är det ett helautomatiserat system, det krävs ingenting av användaren. Vi kallar det “AISinformation” eftersom att denna information skickas över protokollet “Automatic Identification System”, förkortat AIS. Protokollet i fråga har stöd för många olika meddelandetyper som kan användas vid olika situationer.I AISinformationen återfinns data som beskriver fordonets bäring och avstånd. Denna data skickas via en maskinvara som kallas transponder. En transponder som är kapabel till att både skicka och ta emot data finns i två olika klasser, A och B. Skillnaden mellan en Klass A och en klass Btransponder är dels att klass Atranspondern är dyrare och att den dels har lite extra funktioner. Klass Atranspondern skickar ut AISinformationen periodvis beroende på planets tillstånd. Transpondern skickar data med tätare intervaller och funktioner finns för att skicka ut data som beror på fordonets bäring. Om fordonet som är installerat med en Klass Atransponder svänger kraftigt så kommer transpondern att under det ögonblicket skicka ut data med tätare intervaller jämfört med om den inte skulle befunnit sig i svängning. Transpondern är därför tillståndsberoende. Eftersom att fordonet genomfört en sväng så är fordonets nya riktning av intresse och en klass Atransponder kan därför skicka ut en annan meddelandetyp där riktningen står angiven. En klass Btransponder är inte tillståndsberoende och utskicket av data sker med konstant periodicitet. Btranspondern har också lägre prioritet till skillnad mot Atranspondern. Det vill säga, Btranspondern kommer kanske inte alltid att få sända ut sin data beroende på hur pass belastat nätet är, alltså hur många fordon som är i närheten [21]. Transpondern har anslutningar som måste vara inkopplade för att kunna skicka och ta emot AISinformation. En av anslutningarna är kopplad till en GPS som hela tiden skickar positionsdata till transpondern, som i sin tur vidarebefordrar data till en antenn som sänder ut positionsdata om fordonet på radionätet. Andra enheter som opererar på samma frekvens kommer att ta emot data via antennen. Transpondern har ytterligare en anslutning i form av en parallell sådan. Den parallella anslutningen kan med fördel kopplas till en dator så att data från transpondern kan skickas till en dator för exempelvis utritning av position, det är det programmet GPSMAP gör som Saab använder idag. Faktum är att en textdisplay (GPSMAP i det aktuella fallet) är ett minimikrav och måste alltså finnas ombord på fordonet [11]. Många flygplan har någon typ dator med tillhörande programvara som kan ta emot inkommande AISdata så att alla enheter som opererar på samma frekvens kan ritas ut på en karta, programvaran kallas chartplotter. Figur 1. Hur GPSdata kan utbytas mellan fordon.
Projekt
Projektet går ut på att förbättra det system målflygen använder idag. Idag så finns inget stöd datoriserad kommunikation, allt sker över antingen mobilnätet eller över radionätet. När man utför olika typer av flyg eller telekrigsövningar vill man ha radiotystnad vilket innebär att inga kommandon eller annan känslig information får kommuniceras över radionätet. Faktum är att ingenting alls ska kommuniceras så att tredjepart kan stjäla eller dra nytta av den informationen. För det krävs att kommunikationen är hemlig och inte på något sätt kan dekrypteras vilket innebär att en krypteringsalgoritm inte är tillräcklig, alla krypteringar kan och kommer att knäckas, tids nog. Målet med projektet är att implementera funktioner för att skicka egendefinierade meddelanden via AIS (Automatic Identification System) och GPSMAP eller annan, egenutvecklad programvara. Denna lösning ska säkerställa ett fullständigt hemligt informationsutbyte.Del 1
Uppgiften är att läsa in sig på AISprotokollet samt GPSMAPutrustningen för att kunna ta fram programvara för att skicka och ta emot meddelanden via AIS samt programvara för integrering med GPSMAP. Vi vet inte riktigt vilka funktioner GPSMAP har i dagsläget. Vi vet att programmet ritar ut alla enheters position på en karta samt att det går att planera enklare rutter i kartsystemet. Vi vill i synnerhet kunna skicka egendefinierade och fördefinierade meddelanden och vi tror inte att det nuvarande system har stöd för det. Vi ska ta reda på vilka funktioner som finns i programmet men vad vi har hört från Saab så pekar det mot att vi kommer behöva skriva en egen kommunikationsprogramvara vilket också är önskvärt från vår sida dels på grund av att vi på så sätt kommer att lära oss hur AISprotokollet fungerar och samverkar med andra, överliggande protokoll, och dels för att det är roligare att komma upp med något eget, nytt och fräscht. Arbetet redovisas på Saab genom en demonstration där information kan utbytas mellan två enheter.Del 2
Om den första delen lyckas ska den andra genomföras. I denna del är målet att ta fram funktioner, ramverk och stödprogram för att hantera egendefinierade meddelanden som ska skickas via protokollet. I det här skedet så är det viktigt att ställa sig frågan om vi måste eller bör skriva egen programvara för systemet. Som tidigare nämnts är det från alla perspektiv bättre att skriva egen programvara men eventuellt så kanske det inte är genomförbart vad gäller certifieringar. Vi vet att hård och programvara som används inom flygvapnet måste ha olika typer av certifieringar beroende på vad det är och hur det ska användas. Är det ett lokalt system och inte kommersiellt så kanske det inte behövs några vidare kontroller eller godkännanden. Det är en frågeställning vi får ha i baktanken, huruvida det måste godkännas av högre instanser eller om det är tillräckligt och utefter det utvärdera våra alternativ. Vid egenskriven programvara så kommer vi i den här delen fram programvara för definition av meddelanden och innehåll. Vi kommer att skapa ett användargränssnitt för meddelandeutbyte samtframtagning av arbetssätt för hantering av meddelanden i en övning. Som tidigare nämnt måste meddelanden hanteras på ett särskilt sätt, det räcker inte med att kryptera dem. Arbetet sammanställs i rapportform samt en muntlig redovisning på Örebro universitet.
Del 3
Om den andra delen lyckas så ska den tredje och sista delen genomföras. Del 3 går ut på att implementera del 2 på en läsplatta. Det vill säga att porta programmet till en läsplatta varifrån man kan skicka fördefinierade och egendefinierade meddelanden.Del Extra
Del extra går ut på att skapa ett “hemligt program” som endast ska finnas på en ickeuppkopplad dator. En representant från varje flygplan använder godtycklig lagringsmedia inkopplad i den hemliga datorn och laddar över den data som krävs (textkommando:kommando) som ska användas till övningen. När sedan huvudprogrammet tar emot ett kommando ska kommandot kontrolleras mot den “hemliga filen” och skriva ut textmeddelandet till motsvarande kommando.Syfte
Syftet med uppgiften är att tillförse målflygen med ett kommunikationssätt som underlättar kommunikationen vid en övning. Detta kommunikationssätt, eller snarare den information som utbyts, måste vara hemligt då man aldrig kan veta vem som lyssnar på informationen som skickas. Komradion är idag en väldigt utdaterad kommunikationsmetod som ej lämpar sig för information som är hemligstämplad. Därför behöver komradion en ersättare.Krav
De krav som ska vara uppfyllda vid projektets slut: ● Ha övergripande förståelse för AISprotokollet samt GPSMAPutrustningen. ● Definiera funktioner för mottagning samt sändning av meddelanden via AIS. ● Skapa ett användargränssnitt för chattfunktion mellan enheter. ● Sätta oss in i Saabs verksamhet.Arbetsfördelning
Del 1: Matthias: ● Informationssökning om ○ Meddelandetyper ○ Textomvandlingar ○ Vdo och vdm meddelanden ○ Transponderns egenskaper ○ GPSMAP○ psmapNedbrytning av det existerande avläsningsprogrammet till transpondern ● Implementation av ○ textomvandlingar från text till hexadecimalt ○ textomvandlingar från tect till 6bit ascii ○ logiken för checksumma ● Kontaktperson till telekrigsavdelningen i Nyköping Jimmy: ● Informationssökning om ○ inkapslade meddelanden ○ kryptering ○ indikator till meddelanden ○ positionsrapporter och sändningshastighet ○ checksummor ● Implementation av ○ strukturen på testprogrammet ○ textomvandlingar från text till binärt ○ textomvandlingar från text till decimalt ○ logisken vid läsning från transponder Del 2: Matthias: ● Informationssöking om ○ plattformar för applikationsskapande ○ designförslag ■ tema ○ designkrav ■ storlek på objekt ○ kodstruktur i en applikation ■ eventhandlers ■ delegat ○ windows forms ■ exporteringsmöjligheter till platta ● Implementation av funktioner som ○ meddelandeutskick ○ transparenta knappar ○ enhetshanteraren ● Implementation av design ○ Färger ○ Enhetlistan ■ online eller offline ■ Storlek och placering på enhet ■ meddelandeindikator för läst eller oläst meddelande ○ statusmeddelanden
○ chattområdet med scrollfunktion ● Kontaktperson till transpondertech i Linköping Jimmy: ● Informationssöking om ○ designförslag ■ färg ■ storlek på objekt ○ designkrav ■ inuitiv design ○ kodstruktur i en applikation ■ trådar ○ windows forms ■ möjligheter och begränsningar designmässigt ■ möjligheter och begränsningar funktionsmässigt ○ applikationer i flygplan ● Implementation av funktioner som ○ chattområde och dess funktioner ○ enhetslistan ○ kommandolistan ○ meddelandemottagning ● Implementation av design ○ placering av knappar och paneler ○ kommandolistan ■ stationmode ■ flightmode med tillhörande logik bakom placering och storlek ○ enhetshanteraren Del extra: Matthias: ● Programtestare i sökning efter programfel. Jimmy: ● Implementation av grundstommen av gränssnittet. ● Logik bakom de automatiskt genererade koderna.
Metoder och verktyg
Metoder
Del 1
För att lösa problemet i del ett som är att skicka ett meddelande över transpondrarna ska vi först och främst titta om det är möjligt. Detta kommer vi att göra genom att läsa företagets manualer samt testa oss fram genom att skriva kod som skriver till transpondrarna i Visual Studio. Visar det sig att transpondrarna inte klarar av att skicka egna meddelanden måste vi börja titta på andra alternativ.Del 2
För att skapa en så bra programvara som möjligt i del två kommer vi att informationssöka efter riktlinjer och tips till en lyckad applikation. Vi kommer även åka på besök till Nyköping för att höra vad som behövs i applikationen. Därefter kommer vi att använda önskat tillägg till Visual Studio för att konstruera programmet.Del 3
För att hinna skapa en applikation till en läsplatta kommer vi att i del två välja ett tillägg till Visual Studio som ger oss möjligheten att exportera den färdiga applikationen till önskad läsplatta.Del extra
I denna del kommer vi att lyssna på önskemål från Nyköping för att förstå vad det är som applikationen ska göra och konstruera den i det inbyggda tillägget i Visual Studio, windows forms.Verktyg
Vi kommer använda oss av: ● Dator från företaget ● 2 st transpondrar med tillhörande antenn, GPSmottagare och kraftaggregat ● Net Framework version 4.0Förberedelser
Första steget
Innan vi börjar med uppgiften är det viktigt för oss att förstå vad problemet är samt hur miljön ser ut som slutprodukten kommer att användas i för att den ska få alla de egenskaper som företaget önskar. Det är även viktigt för oss att veta vilka verktyg som får användas i ett flygplan så att vi inte har en slutprodukt som ej kan användas på grund utav säkerhetsrisk eller liknande. Att veta vilken målgrupp som produkten riktar sig till när man skapar ett program är väldigt viktigt eftersom programmet både ska tilltala användarna utséendemässigt och ha funktioner som är intuitiva för användaren. Exempelvis, om vi ser till ett användargränssnitt så kan det vara rimligt att ha funktionsmässigt nära besläktade knappar inom rimligt avstånd från varandra, särskilt om det är en tidspressad situation. Vi vet inte riktigt hur pass tidskritiska olika situationer kan vara, kommer operatören ha mycket tid att skicka ett meddelande eller är snabbhet är en viktig aspekt hos programmet och i så fall, hur kan det lösas? Vi bör även diskutera hur programmet kan användas och vilka alternativ vi har. Vilka begränsningar som finns hos teknologin och utrustningen samt personens förmåga att använda programmet. Företaget har gett oss ett alternativ på lösning till problemet med dessa binary messages men om vi får idéer om andra lösningar bör dessa också förmedlas och diskuteras. Angående del extra så vet vi att att ingen känslig data ska skickas över något nät samt att man vill åstadkomma radiotystnad så krävs ett säkert sätt att generera och överföra textkommandon med tillhörande “hotkeys” (snabbknappar) så kommer denna generering utföras på en “hemlig dator” som inte är uppkopplad på något sätt.Förstå problemet
För att förstå problemet på det tekniska såväl praktiska planet utifrån den information vi delgivits så har vi dels läst manualer och dels gjort många antaganden. Problemdefinitionen idag är att det är problematiskt för såväl operatörer och piloter att föra en säker och tydlig kommunikation eftersom att de kommunikationsmedium som används är mobil och radionät. Våra radiofrekvenser är publika och är därmed inte ett alternativ eftersom att kommunikationen ska vara hemlig, samtidigt kan röstkommunikation via radionätet i cockpiten lätt bli otydlig på grund av brus och andra störfaktorer. För att piloten och operatören ska kunna kommunicera på ett, för passagerare riskfritt sätt, så krävs ett bra och enkelt verktyg samt ett gränssnitt till densamma som är primitivt och användarvänligt. För att förbättra den nuvarande kommunikationen ska vi använda transpondern som sitter monterad i alla övningsflygplan. Idag sitter en GPSMAP i cockpiten som både piloten och handhavande operatör använder, GPSMAPen visar i dagsläget endast positioner av andra enheter på en karta. Längre bak iplanet sitter vanligtvis två operatörer till som i dagsläget sköter andra praktiska detaljer, till exempel olika mätningar från det aktuella övningstillfället. Önskvärt är att piloten och handhavande operatör ska ta del av inkommande meddelanden från dels den stationära stationen på marken och dels andra aktiva enheter, i luften. De operatörer som vanligtvis sköter mätningar ska kunna ta del av samma meddelanden som cockpiten men också skicka egendefinierade meddelanden till den stationära stationen såväl som andra flygande enheter. I dagsläget sitter det också en GPSMAP i bakre delen av planet (och i cockpiten som nämnts) som är masterslave kopplade vilket innebär att meddelanden som ska skickas (eller gränssnittet för konstruerande av ett meddelande) kan inte operera på samma kanal eftersom att en eventuell meddelanderuta i kartan skulle störa piloten. Vi ska se över möjligheten att koppla in en ytterligare dator till transpondern, alternativt att sköta den kommunikationen via IPnät (WiFi) eller bluetooth. Produkten som vi ska skapa kommer att synas på samma skärm som programmet GPSMAP gör i dagsläget. Piloten och en eventuell operatör är de som har tillgång till denna skärm som även speglas till en annan skärm i flygplanet. Användarna av programmet är därför piloten samt operatören som tydligt ska kunna se och skicka meddelanden, det är dock inte önskvärt att pilotens skärm ska störas av meddelandekonstruering och annat dylikt, om det inte är piloten själv som ska skicka ett meddelande så klart. Utöver dessa kommer programmet även att användas från marken där en övning styrs ifrån. Detta gör att programmet behöver se annorlunda ut beroende på vem som använder det. Från marken krävs inga funktioner som skiljer sig från en vanlig meddelandefunktion men i planet är det viktigt att programmet är tydligt och snabbt att använda eftersom tiden som användarna har för att använda programmet är begränsad. Eftersom programmet ska användas av försvaret krävs även en form av kryptering som kan klassas som hemlig. Programmet måste därför vara anpassat för att kunna hantera viktig information och kanske innehålla ett uppslagverk för dessa hemliga koder.
Idéer för programmet
Vid första anblick så kommer många idéer om hur programmet skulle kunna fungera. För att piloten ska kunna skicka meddelanden snabbt och med händerna fortfarande på instrumenten i planet skulle ett röststyrt program vara en bra lösning. Figur 2. Tecken som skulle kunna användas vid meddelandesändning.Figur 3. Två flygplan som kommunicerar med varandra. För att spinna vidare på att piloten ska ha maximalt fokus på sin instrumentbräda och omgivning och inte behöva hantera programmet skulle även ett program som kan se kommandon gjorda med händerna och utefter dom utforma meddelanden vara ett alternativ (se Fig. 2). En annan bra lösning skulle vara en pekskärm med förutbestämda knappar med meddelanden som piloten redan kan innan flygning startar. Dessa alternativ är utformade för att ge piloten en möjlighet att skicka egna meddelanden. Kan inte piloten sköta detta har vi operatören samt eventuella medpassagerare längre bak i planet. Några alternativ för att göra programmet enkelt för dem att använda kan vara att låta dem skriva egendefinierade meddelanden på ett tangentbord eller en pekplatta. Ska programmet bara presentera en chatt eller ska även en karta synas på skärmen? GPSMAP programmet visar idag en karta men att kunna byta ut denna mot ungefär samma program fast med en inbyggd chattfunktion som påminner om dagens mmorpgspel där en spelares senaste meddelande syns intill spelaren precis som att denne ropade ut det. Detta skulle göra att programmet känns väldigt dynamiskt och enkelt att sortera ut vilka meddelanden som är intressanta för en själv (se Fig. 3). Lösningar till att meddelanden behöver vara krypterade kan vara en krypteringsfunktion som finns i programmet som omvandlar textsträngar till något oläsbart och tillbaka till vanlig text. Även så skulle en lokal lista över kommandon kunna finnas i datorn som översätter meddelanden i programmet som i efterhand kan slås mot det lokala listan. Om operatören eller piloten får in kortkommandot “H4” så ska en lokal lista finnas nära till hand, där “HH” kanske betyder “Avbryt övning”.
Inläsning på NMEA och AIS protokollen
AIS använder som standard två frekvenser, 161.975 MHz samt 162.025 MHz, vilka är de “marina frekvenserna” [14] där datapaket periodvis sänder ut speciellt utformade datapaket, mer om strukturen på datapaketen längre ned. Saab har dock blivit tilldelade egna frekvenser att sända på till deras övningar så vi kommer att använda frekvenserna 151.2 MHz samt 142.2 MHz, vilket kan vara bra urflera perspektiv, dels så slipper vi ta in data från helt oberoende enheter och dels slipper de oberoende enheterna ta hänsyn till övningsflygen. Övningsflygen utgör inget direkt hot för de kommersiella planen. Transpondern kommunicerar via två underliggande protokoll, kallat NMEA 0183 (där 0183 anger vilken standard det är) och AIS. NMEAprotokollet har som kärnuppgift att se till att varje, inkommande och utgående meddelande, vilket huvudsakligen är GPSinformation, eller så kallade “Position reports”, är strukturerad på ett visst sätt. NMEAmeddelanden överförs som standard med en bithastighet på 4800bit/s men det verkar råda delade meningar om huruvida man kan använda samma bithastighet som används för att skicka så kallade AISmeddelanden [12]. NMEAprotokollet stödjer en mängd olika meddelanden [13], ett urval kan ses i Tab. 4. Prefix Meddelandetyp AAM Waypoint Arrival Alarm ALM Almanac data APA Auto Pilot A sentence APB Auto Pilot B sentence BOD Bearing Origin to Destination BWC Bearing using Great Circle route DTM Datum being used. GGA Fix information GLL Lat/Lon data GRS GPS Range Residuals GSA Overall Satellite data GST GPS Pseudorange Noise Statistics GSV Detailed Satellite data MSK send control for a beacon receiver MSS Beacon receiver status information. RMA recommended Loran data RMB recommended navigation datafor gps RMC recommended minimum data for gps RTE route message TRF Transit Fix Data STN Multiple Data ID VBW dual Ground / Water Spped VTG Vector track an Speed over the Ground WCV Waypoint closure velocity (Velocity Made Good) WPL Waypoint Location information XTC cross track error XTE measured cross track error ZTG Zulu (UTC) time and time to go (to destination) ZDA Date and Time Tabell 4. Olika typer av NMEAsträngar.
Detta är exempel på GPSmeddelanden som tas emot/skickas som NMEAsträngar. Alla ovanstående meddelanden börjar med GP (som syftar till GPS). Det finns också så kallade AISmeddelanden, vilka vi ska försöka utnyttja. Det finns 27 olika meddelandetyper som stöds i AIS protokollet [4], vilka kan ses i Tab. 5. Number Type 1, 2 and 3 Position Report Class A 4 Base Station Report 5 Static and Voyage Related Data 6 Binary Addressed Message 7 Binary Acknowledge 8 Binary Broadcast Message 9 Standard SAR Aircraft Position Report 10 UTC/Date Inquiry 11 UTC/Date Response 12 Addressed SafetyRelated Message 13 SafetyRelated Acknowledgement 14 SafetyRelated Broadcast Message 15 Interrogation 16 Assignment Mode Command 17 DGNSS Broadcast Binary Message 18 Standard Class B CS Position Report 19 Extended Class B CS Position Report 20 Data Link Management Message 21 AidtoNavigation Report 22 Channel Management 23 Group Assignment Command 24 Static Data Report 25 Single Slot Binary Message 26 Multiple Slot Binary Message 27 Long Range AIS Broadcast message Tabell 5. AISmeddelanden definierade i AISprotokollet. Vi är mest inriktade på meddelandetyp 6 och 8. Typ 6, Binary Addressed Message ser ut som beskrivning i Tab. 6.
Field Len Description Member T Units 05 6 Message Type type u Constant: 6
67 2 Repeat Indicator repeat u As in Common Navigation Block 837 30 Source MMSI mmsi u 9 decimal digits
3839 2 Sequence Number seqno u Unsigned integer 03 4069 30 Destination MMSI dest_mmsi u 9 decimal digits
70 1 Retransmit flag retransmit b 0 = no retransmit (default) 1 = retransmitted
71 1 Spare x Not used
7281 10 Designated Area Code dac u Unsigned integer 8287 6 Functional ID fid u Unsigned integer
88 920 Data data d Binary data May be shorter than 920 bits. Tabell 6. Binary Addressed Message ● Där Message Type är meddelandetypen, i detta fall 6. ● Repeat indicator indikerar om något hindrade data från att nå fram, exempelvis ett berg. Då kan man repetera eller “rebroadcasta” de bitarna som inte nådde fram till slutdestinationen. ● MMSI är den enskilda enhetens ID nummer som vanligtvis sätts av sjöfartverket. Eftersom att Saab fått egna frekvenser att operera på så har Saab själva satt id nummer på deras transpondrar. På vår arbetsplats har våra transpondrar id, 14 och 15. ● Sequence number är vilket ordning i paketserien ett visst paket har. Om ett paket skulle behöva skickas om och efterföljande paket når fram korrekt så måste mottagaren veta att det paketet som inte nådde fram egentligen skulle nåt fram innan det sista paketet. ● Destination MMSI är mottagarens id. ● Retransmit flag flaggar för om meddelandet av någon känd eller okänd anledning behöver omsändas. ● Designated Area Code är ingenting vi kommer att använda. Olika geografiska placeringar har olika dac men vi kommer bara skicka meddelanden lokalt. ● Functional id är ett id som bestäms av den auktoritet som är ansvarig för den geografiska placeringen som ges av DAC:en, punkten ovan, inget vi kommer använda. ● Data är det fält som intresserar vårt ändamål. Datafältet beskriver den binära fält där vårt meddelande ska placeras, som mest får längden vara 920 bitar [14]. De automatiska meddelanden kommer att skickas som NMEAsträngar och överförs med en bithastighet på 4800 bit/s. Vi kommer att fokusera på AISmeddelanden av typ 6 och 8. Dessa kommer att skickas men en högre bithastighet (38400 bit/s) och därmed överföras snabbare. I Fig.7 kan vi på multiplexerns vänstra sida följa meddelandets väg. Den kommer inte att tas emot som NMEA, ty startsymbolen kommer inte vara ett dollartecken och därmed inte tolkas som en sådan sträng. Signalen kommer inte heller att nedgraderas på andra sidan av multiplexern utan kommer också tas emot med den högre bitraten. NMEAsträngar är skrivna som ASCII medans övriga AISmeddelanden är kodade som 6bitars binärkodning [15].
Figur 7. Protokollstruktur, hur och med vilka hastigheter olika data översförs med. Vi har haft tankar att kommunicera med röstmeddelanden vilket vore extremt användbart eftersom detta inte behöver ta för mycket koncentration och tid från en pilot eller operatör. Men eftersom programmet ska användas i en bullrig miljö och att ytterligare utrustning då måste flygcertifieras för att lösa detta så ryms det ej i vår tidsplan. Detta får bli en eventuell lösning som kan undersökas mer noggrant i framtiden. För varje frekvens så måste utrymme allokeras och delas på ett rimligt sätt och det görs med hjälp av något som kallas timeslots. AIS använder TDMAb (Time Division Multiple Access). AISstandarden anger att det finns ett begränat antal platser eller “time slots” för var och en av de två (marina) frekvenserna. Olika typer av AISmeddelanden tar upp olika många slots beroende på storleken av meddelandet. AISstandarden tydliggör att 2,250 slots finns att tillgå varje minut, på en frekvens, och totalt 4500 över de båda frekvenserna. Frekvenserna delas in i kanaler som som man kan lyssna och broadcasta på. Det finns möjlighet att operera på de båda frekvenserna (kanalerna). Om slotsen skulle bli fulla så fungerar de lite utefter “försttillkvarn”principen. De fordon som allokerar utrymme först (vanligtvis de som är närmast) får avsätta tidsutrymme [16]. En illustration i Fig. 8. Figur 8. Hur fordon allokerar tidsutrymme i timeslots.
Det här är ingen begränsning för oss eftersom att vi har egna frekvenser att sända på. Initialt hade vi tankar om att skicka videomeddelanden men av samma anledning som med ljudmeddelanden (för låg överföringshastighet och för mycket data) så fungerar inte det heller. En annan idé som var att piloten skulle använda pekskärmen (som vi trodde satt i planet) för att skicka fördefinierade meddelanden. Vi hade diskuterat olika typer av layouter i det eventuella gränssnittet, exempelvis stora tydliga knappar som minskar risken för feltryckning. Väl på plats fick vi veta att skärmarna som ritar ut kartorna (likt de GPSMAPAR vi har fått lånat) inte stödjer touchscreenfunktion, vilket de vi lånat gör. Angående det hemliga programmet vi beskrivit ovan så har vi har tagit fram ett program, skrivet i C# (en binärfil som kommer att ligga på den hemliga datorn) som läser från ett externt minne, förslagsminne usbminnen som innehåller en tomt eller icketomt textmeddelande som manipuleras av binärfilen. Programmet skapar alltså unika kortkommandon för varje textkommando som återfinns på textdokumentet. Textdokumentet kan komma på lite olika former och programmet hanterar dokumentet efter den aktuella strukturen, exempel följer nedan. Om ett helt tomt textmeddelande (lagrat på ett extern minne) kopplas in i den hemliga datorn så kommer vårt egenskrivna program att lägga till följande rad, “Exempelmeddelande:EM (editera denna)”. Där användaren kan välja att: ● Modifiera texten med ett godkänt kommando, ex. “Starta ovning ett:FF” Där FF är ett egenvalt kortkommando. ● Välja att lämna kortkommandodelen tom, ex. “Starta ovning ett:”. Då kommer programmet att generera ett kortkommando som kan innefattas av bokstäver från AZ (versaler) samt siffror 19, på godtycklig form. Ex. 99, RR, F8, 9K och så vidare. Textkommando:kortkommando lagras i en hashtabell som ej tillåter redundanta textkommandon. Kontroll av redundanta kortkommandon (värden i en hashtabell) sker manuellt. Om textmeddelandet initialt har textkommandon sparade så kan användaren välja att lägga till fler och ta bort tidigare kommandon. Textdokumentet går inte att spara om inmatningen på filen inte överensstämmer med ett särskilt format, det vill säga formatet “Meddelande:KK”. Inmatningen kontrolleras av en rekursiv funktion som jämför inmatningen med ett reuljärt uttryck. Funktionen returnerar sant om det är en godkänd inmatning. Om meddelandet av någon okänd anledning skulle stå på fel format (om den blivit redigerad utanför programmet) så kommer dokumentet att tömmas och ett tomt dokument kommer att visas för användaren. När användaren är nöjd med textfilen och de kommandon som kommer att användas till kommande övning så får de andra operatörerna ta deras externlagringsenhet (eller om ett minne överlåtes mellan dem) ladda in dokumentet från den hemliga datorn och därefter ansluta till deras datororer, inne i flygplanen, och ladda in data till huvudprogrammet. Huvudprogrammet kommer då att läsa från textfilen och lägga in alla textkommandon och snabbknappar.
Genomförande
Vid projektets början fick vi veta att deras nuvarande kommunikationssätt var bristfälligt och hur resultatet av vårt arbete skulle kunna effektivisera deras kommunikation i olika sammanhang. Vid kommunikation i dagsläget så används i första hand radion, i andra hand mobiltelefonen och i värsta fall ingenting. Ibland så kan man av diverse anledningar inte använda radion eller mobiltelefonen, då kan det hända att man får avbryta övningen. Vår första arbetsdag kom att innefatta en hel del informationssökning. Vi hade blivit försedda med AISmanualer som vi bläddrade igenom. I manualerna så fann vi bland annat information på vilka typer av meddelande som protokollet accepterade, som i sin tur var beroende på vilken typ av transponder som sände ut data, via protokollet, ut på radionätet. I detta skede så visste vi inte alls vilken typ av maskinvara som vi skulle arbeta med. Transpondrar kan vara av olika klasser, klass A eller B. De båda klasserna kan både sända och svara (transponder kommer ifrån engelskans“Transmitterresponder“). Den mest signifikanta skillnaden är hur ofta transpondern skickar ut data. En klass Btransponder skickar endast ut data var trettionde sekund oberoende av fordonets orientering. En klass Atransponder innehåller information om bland annat orientering, destination och beräknad ankomsttid. Klass Atranspondern kommer att skicka ut information i olika tidsintervaller beroende på dess orientering [17]. Vidare diskuterade vi hur vi skulle sända ut data på nätet, uppgiften kom att kallas “implementation av binary messages i AIS…) just på grund av att vi hade fått tips av vår handledare att
meddelandetypen “Binary Broadcast Message”, “eventuellt kunde utnyttjas”. Protokollet tillåter en hel del andra typer av meddelanden, bland annat något som kallas “Safety Related Broadcast Message” som ska användas för, “text messaging, nominally safetyrelated but also for traffic control and occasionally chatter” [4]. Spontant så kände vi att den här meddelandetypen lät vettig men samtidigt så, beroende på vilken klassificering av transponder man har, finns olika möjligheter att sända ut/ta emot olika typer av meddelanden. Vi mottog transponderutrustningen kallad R3 med tillhörande programvara (GPSMAP) och GPSmottagare. Vi fick två uppsättningar av transponderutrustning så att vi kunde testa transpondrarna mot varandra, det vill säga att både skicka och ta emot information. Utrustningen kopplades in via en COMport i datorn. Transpondern i sin tur hade en GPSmottagare inkopplad som hämtade GPSinformation som sedan skickades vidare till alla andra enheter på radionätet via en antenn. GPSMAP påminde om en radar där en karta över Europa visades tillsammans med alla transpondrar som var i drift (visades som flygplan). I programmet kunde man följa flygplanens position och hastighet i realtid. Programmet visade även en lista som innehöll AISinformationen samt information om flygplanets id. Alla transpondrar som finns i flygplanen har ett id, kallat Maritime Mobile Service Identity (MMSI) så att alla flygplan unikt kan identifieras. Saab hade tidigare arbetat med ett program för inläsning av AISmeddelanden och källkoden till det programmet fanns kvar vilket underlättade en hel del för oss. Vi bestämde oss för lösa problemet med
ramverket .Net i Visual Studio. Det kändes nu rimligt att skriva ett program som kunde avläsa och skicka data med via transpondrarna. Det var lättare att ta emot meddelanden än att skicka så programmet omvandlades till ett testprogram för utsändning av meddelanden. Vi visste inte hur transpondern ville ha indatan eller hur vi skulle skriva till COMporten som transpondern var inkopplad via. I testprogrammet kunde vi skriva ett meddelande och därefter välja på vilket format meddelandet skulle skickas. Programmet klarade av att skicka ut strängen som den var (som text), eller som 7bitars ASCIItecken, på hexadecimal, decimal och binär form. Detta pågrund av manualernas tvetydighet hur meddelanden skulle se ut. GPBWC,220516,5130.02,N,00046.34,W,213.8,T,218.0,M,0004.6,N,EGLM*1 1 Kod 9. Meddelandeexempel, NMEAsträng. Informationen som skickas mellan olika typer av marinutrustning kommunicerar också som nämnts över ytterligare ett protokoll, förkortat NMEA (The National Marine Electronics Association). Informationen som skickas från exempelvis GPSmottagaren till datorn, tas emot på ett särskilt format. Den skickas som en kommaseparerad mening, ett meddelandeexempel kan se ut enligt Fig. 9. Varje meddelande börjar med ett dollartecken och slutar med ett såkallat “carriage return” vilket betyder, “gå till meningens början”, alternativt slutar meningen med ett radslut. Efter dollartecknet kommer två stycken bokstäver som betecknar meddelandetypen. Om transpondern tar emot ett GPSmeddelande så kommer meddelandetypen att vara GP ($GP), om istället meddelandetypens beteckning är AL så betyder det att det inkommande meddelandet är ett alarmmeddelande. I testprogrammet som läste från transpondern fick vi in “AImeddelanden” som löd: “Tx malfunction”, “Rx malfunction” och “Antenna VSWR fault”, varpå det står i en dokumentation [10] att det första och andra felet beror på att kontakterna inte är rätt ansluta till transpondern, men det har vi försäkrat oss om att de är. Det sistnämnda felet beror sannolikt på att mottagning är dålig. Vi valde att inte fördjupa oss i felen eftersom att kommunikationen mellan våra transpondrar verkar fungera. De “AI” meddelanden som skickades ut, där meddelandetypen “AI” syftar till AISmeddelanden, som innefattar den “vanliga aisinformationen” nådde fram, det till säga, den data som skickades ut av vår första transponder togs emot av den andra transpondern och vice versa. Vidare i meddelandet, efter meddelandetypen så följer tre stycken ytterligare bokstäver som beskriver meddelandeinnehållet. Exempel på innehållet kan vara AAM (Waypoint Arrival Time), GSA (Overall Satellite Data) eller ZDA(Date And Time). I själva verket finns det många många fler typer. Fortsättningsvis så följer alltså en kommaseparerad lista med otydlig information följt av en stjärna (*) och checksumman. Checksumman återfinns på hexadecimal form som det sista elementet i listan och den räknas ut på innehållet mellan dollartecknet och multiplikationsoperatorn. Denna data används för att kontrollera att meddelandet har skickats korrekt samt att meddelandet inte har modifierats på vägen, checksumman beräknas via flertalet XORoperationer.
Det ramlade också in meddelanden som hade typen AI vilket innebär att efterföljande information var direkt skickad från en annan transponder. Vi kunde inte hitta inte någon bokstavskombination som var tydligt inriktad mot att en dator eller annan enhet (transponder) kunde skicka informationen. Detta ledde oss till att försöka få transpondern att tro att vi är en annan enhet. Till exempel att vi skulle anta en GPS som skickar meddelanden, försöket misslyckades. Dessa AImeddelanden har ett utropstecken (!) som startsymbol (följt av meddelandeinnehållet) istället för ett dollartecken. De vanligaste meddelandena som transpondern mottog var VDO och VDM som är en standard för inkapslade meddelanden i AISprotokollet. VDO indikerar vilka meddelanden som skickas ut och VDM är de meddelanden som tas emot från andra enheter. VDO och VDM är de mest komplicerade meddelandena i AISprotokollet eftersom det finns 27 olika typer [4]. Typ 8 och 14 var särskilda meddelanden där valfri data kunde inkluderas vilket var intressant för oss men tack vare den uteblivna informationen i manualerna om transponderns förmåga att ta in strängar från datorn var alla försök misslyckade. Utöver VDO och VDM fanns TXT som även det var intressant. TXT meddelanden hade en sådan struktur att man först berättade hur många meddelanden som utgjorde ett meddelande (mellan 099). Därefter vilket id i denna ordning som detta meddelande var följt av avsändaren. Till exempel “TXT,12,5,1,Detta är ett meddelande”, där ettan indikerar att vi är enhet ett. Efter meddelandeindikatorn kommer dess GPAAMmeddelande vilket betyder att detta är av meddelandetypen GP (som står för GPS) följt av meddelandeinnehållet AAM vilket står för “Waypoint Arrival Alarm” vilket är ett alarm som skickas när enheten nått sitt mål (se Fig.10) [7]. $GPAAM,A,A,0.10,N,WPTNME*32 Kod 10. Meddelandeexempel 2, NMEAsträng. Med informationen ovan tillsammans med informationen i manualerna skulle vi försöka skicka meddelanden. I Tab. 11 kommer många exempel på försök, samtliga skickade som vanliga ASCII tecken, binärkodade, decimal samt hexadecimalkodning.
$AITXT,01,01,14,Hejsan*23 $AITXT,01,01,14,Hejsan $AITXT,01,01,14,Hejsan $GPTXT,01,01,14,Hejsan*23 $TXT,01,01,14,Hejsan*23 !AIVDM,1,1,,B,177KQJ5000G?tO`K>RA1wUbN0TKH,0*5C !AIVDO,1,1,,B,177KQJ5000G?tO`K>RA1wUbN0TKH,0*5C !AIVDO,1,1,,A,80003PEQEnfieFIE 177KQJ5000G?tO`K>RA1wUbN0TKH !AIBBM,1,1,,,56,9000inWdsOO,1 Tabell 11. Några försök att sända ut ett meddelande. Efter mycket testande och läsning så började vi misstänka att det inte gick att skicka manuella meddelanden via transpondern. Vid skrivning till transpondern så ska man få någon typ av respons vilket vi inte fått och det var ingenting i manualerna vi läst som pekade mot att transpondern hade funktioner för att omvandla de meddelanden som kom från datorn till ett AISmeddelande. Efter diskussion med vår handledare på Saab så drog vi slutsatsen att det inte var möjligt att skicka egendefinierade meddelanden via transpondrarna vi hade. Dessa transpondrar, som kallas R3, tillverkades i början på nittiotalet. Vi kom också överens med vår handledare om att vi skulle bli ansvariga för att bestämma inköp av ny transponder till företaget som klarade av att skicka egendefinierat meddelanden. Figur 12 och 13. Design från Windows 10 och Spotify.
I väntan på svar från skaparna av transpondern (Transpondertech i Linköping) om ytterligare information så bestämde vi oss för att ta händelserna i förväg och skissa på del två vilket innebar att börja fundera på hur denna applikation skulle se ut. Vi ville att applikationen skulle vara modern och enkel att jobba och eftersom datorerna som används tillsammans med transpondrarna hade en fungerande touchscreen tänkte vi utnyttja detta när piloten skulle skriva sina meddelanden från planet. Efter inspiration från dagens mobilapplikationer kom vi fram till att vi ville ha ett program som hade två lägen. Ett läge som är mer avancerat där man sköter mycket inställningar samt ett läge där snabbhet och enkelhet är viktigast. Det tidigare valde vi att kalla stationmode och den senare flygmode. Vi valde att följa dagens trend med stilren design med sköna färger att ha på en skärm. Den största inspirationkällan vad gäller designen kom från Windows 10 som är uppbyggd av rektangulära ikoner för applikationer bland annat. Färgtemat är inspirerat av Spotifys gränssnitt. Skärmdumpar från dessa program finns i Fig. 12 och Fig. 13. Windows forms var en miljö som vi var bekväma med och därför skapade vi gränssnittet med detta verktyg. Hur Windows Forms olika funktioner och verktyg kan användas nås från Microsofts egen hemsida [8]. Där kan vi läsa hur vanliga knappar och andra delar av programmet kan modifieras för att få det utseende vi söker. Figur 14 och 15. Skisser på hur applikationen kan komma att se ut. Vi valde vi att följa en guide som används för att se till att “allt som ett interface ska ha” finns med. När programmet är klart så kommer vi att i resultatet stämma av mot denna guide [20]. Vi hade fått ett telefonnummer till Transpondertech i Linköping och vi kände att det var läge att ringa till dem och höra om de hade tips hur vi kunde gå vidare och huvudfrågan var om det gick att skicka egendefinierade meddelanden med R3:orna. Av samtalet framgick att det var “arkeologi” att jobba med de transpondrar vi hade och ett framtida möte bokades där vår handledare på Saab också skulle medverka, tillsammans med oss, där vi skulle diskutera möjligheten att låna en nyare generation transpondrar av Transpondertech. Figur 14 och 15. Station mode och Flight mode.
Mötet med alla inblandade slutade bra och Transpondertech skickade 2 uppsättningar av transpondrar generation 5, kallad R5. Samtidigt skickade de manualer till dessa transpondrar och vi såg med detsamma i manualerna att det fanns ett avsnitt som var avsett för skrivning till transpondern. När vi designade applikationen ville vi att den skulle vara intuitiv vilket innebär att programmet ska ha förmågan att ge användaren förståelse av programmet på direkten utan att behöva lära sig eller fundera [18]. Om något är intuitivt är något som är tämligen subjektivt beroende på vilka tidigare erfarenheter man har men i detta läge handlar det bara om att göra något som är okomplicerat och “rimligt”. Eftersom vi ska göra ett chattprogram är det viktigt att vi tittar på kommersiella chattprogram. Dessa kan vara Skype, Facebook eller de SMSkonversationer som används i dagens mobiltelefoner. Det gäller även att titta på dessa och avgöra vad som behöver vara med och vad som kan exkluderas. Det är viktigt att följa standarder som finns för att göra ett program lätt att använda så att olika enheter och i synnerhet skärmstorlekar kan anpassas till programmet. enligt [9] så ska en knapp inom Apples standarder vara minst 44*44 pixlar för att vara klickbar. Detta är en standard som följs även utanför Apple. Enligt författaren till inlägget [9] så är “swipespacen” (swipeutrymmet) det viktigaste för en bra touchscreenupplevelse. Med detta avses det område som användaren kan dra sitt finger för att bläddra på sidan. Detta kommer vi att ha i åtanke när vi gör applikationen. Vi ville att applikationen skulle ha två lägen. Ett “stationmode” där egendefinierade meddelanden är i fokus, här ska även finnas inställningsmöjligheter till programmet. Ett annat läge som vi kallar “flightmode” där snabbhet och intuivitet eftersträvas. Därför kom frågan upp hur bytet mellan dessa lägen skulle se ut. Eftersom programmet skulle vara körbart på en platta (enligt del 3) så tänkte vi först att en swipefunktion skulle vara det mest intuitiva men eftersom programmet ska användas i en skakig miljö så kan ett vanligt klick på skärmen oavsiktligt bli en “swipe”, därför har vi valt att inte ha “swipe”funktion vid funktioner som på något sätt är kritiska för användaren. Enligt Fig. 16 såg menyn för programmet ut i tidigt skede. Stora knappar som är enkla att klicka på och en röd knapp som stänger ner programmet. Vi hade ej bestämt oss om vi ville ha några ikoner på respektive knapp för att göra det mer intuitivt men det återstod att se och efter lite test skulle vi förhoppningsvis veta vad som blir bäst. Dagen därpå dök transpondranra upp. en kunde antingen kopplas upp via IPnätet eller via en RS422port. Eftersom att stöd finns för IP samt att en önskan från Saab’s sida är att dessa ska fungera med läsplattor så valde vi IP. Vi hade fått IP och port i förväg av transpondertech och att koppla upp sig mot dessa var enkelt genom att sätta upp en socket och anslutna via rätt adress. De här transpondrarna var helt nya, ingen förkonfiguration hade gjorts på dem, då de tagits direkt från deras lager. I Visual Studio gick det nämligen problemfritt att läsa all inkommande data från andra enheter som var uppkopplade via transpondrar men vi kunde fortfarande inte skriva till den. Figur 16. Meny.
Vi tog återigen kontakt med Transpondertech och vi frågade hur vi skulle skriva till transpondrarna. Vi berättade var vi befann oss i processen och vi fick till svar att de skulle maila oss med information. I mailet så fick vi berättat för oss hur vi kontrollerar att transpondern är satt till sändingsläge och hur vi ändrar transponderns id (mmsi). Detta enligt Fig. 30 och Fig. 31. $PSTT,101,122*02 Kod 30. Sändningstext till transponder. $AISPW,EPV,,1,user*3F $AIEPV,C,AI,,106,266000237*2 F Kod 31. Id ändring till transponder. Mailet introducerade oss också till en ny typ av sträng, som börjar med $PSTT, $AISPW samt $AIEPV. Vi kom snabbt underfund med att det var inga typer som nämndes i R3:ans dokumentation utan det var kommandon som endast R5:an kunde hantera. Vidare så framgår det ganska tydligt att det är meddelandetyper för att konfigurera transpondrarna. Vi skickar in sw.WriteLine(“$PSTT,101,122*02”) och får vi direkt ett svar från transpondern med svarsmeddelanden som indikerar att transpondern är satt till “sändning” enligt mailet. För vardera satte vi också id som tydligen kunde sättas godtyckligt vilket förvånade oss. Som tidigare nämnt så är det något som tilldelas av sjöfartsverket, trodde vi. Vi provade att skicka ett meddelande av typen 6 (som är ett adresserat binärmeddelande, kan ses på sidan 16. I informationen från mailet så står det att ett binärmeddelande ska börja med bokstäverna “EC” följt av “ABM” (ABM = Addressed Binary Message) så att strängen kom att se ut enligt Fig. 17. !ECABM,1,1,2,793420871,1,6,040N<PDhht0,2*6C Kod 17. ECmeddelande, en NMEAsträng med meddelandefält “HELLO” i 6bit ASCII. Där strukturen för meddelandeinnehållet, det vill säga, mellan kommatecknen följer den standard vi tidigare beskrivit. Eftersom det är adresserat så behövs mottagarid vilket i exemplet ovan är 793420871 och meddelandeinnehållet, kodat i 6bitar ASCII fortlöper mellan de kommatecken där datadelen därimellan börjar med 040N vilket enligt exemplet som text, översätts till “HELLO”. Typen “EC” har vi inte stött på tidigare och i nuläget fördjupar vi oss inte i det. Vi skicka samma meddelande som i exemplet (“HELLO”) borde vara ett godtagbart format eftersom att det återfinns i ett exempel. Vi räknade om checksumman för meddelandet eftersom att mmsi:t skiljer sig och provar att sända ut det på nätet.
Vi hade tidigare noterat att inkomna meddelanden, på vardera transponder, kom väldigt oregelbundet och vi fick intrycket av att det var dålig mottagning vad gäller våra antenner. Med R3orna hade vi inte det problemet över huvud taget men vi antog (eller avfärdade) problemet tills vidare genom att anta att impedansen till antennerna ändrats på grund av annan utrustning eller liknande. Det adresserade binärmeddelandet som var adresserat till vår andra transponder skickades iväg men togs tyvärr inte emot. Vi kunde dock notera att vi fick tillbaka ett ACK eller acknowledgement från avsändaren så meddelandet måste gått iväg korrekt, bara att vi inte kunde ta emot det, kanske var det impedansproblemet (som nödvändigvis inte behöver bero på det men eftersom vi inte omplacerat antennerna så var det lite märkligt). När vi höll ut antennerna så långt vi kunde, från vårt kontor (genom fönstret) så insåg vi att inkommande meddelanden generellt kom mer ofta och snart märkte vi att meddelanden ramlade in efter ordning om vi höll ett stadigt grepp om antennen vilket borde tyda på impedansproblem eller bristfälligt jordplan. Ett nytt försök gjordes och meddelandet dök upp till den adresserade parten, vi hade lyckats. Vi provade samtidigt att skicka ett vanligt “BBM” (binary broadcast message), som alltså inte är adresserat och därmed når (i teorin) alla på den aktuella frekvensen och det fungerade likaså. Eftersom nu del 1 av uppgiften var klar var det bara att fokusera på del 2 som i detta läge var att göra en windowsapplikation som både kan köras på en dator och en läsplatta samt en applikation som körs på en “hemlig dator” som genererar koder till chattprogrammet. Vi ville att detta chattprogram skulle vara likt dagens chattapplikationer som återfinns på exemeplvis Skype, Facebook och i mobiltelefoner för att ge användaren så lite arbete som möjligt för att förstå vad som ska göras när hen öppnar programmet. Därför, när vi designade menyn där du väljer enhet att skicka meddelanden till så har inspiration hämtas från Facebooks layout blandat med de chattrutor som återfinns i dagens multiplayerspel. Den delen som är hämtad från Facebook är en större ruta som blinkar om du har ett oläst meddelande (se Fig. 18) och från multiplayerspelet att meddelande rutan ej ändras för olika chattrutor utan meddelanderutan uppdateras endast (se Fig. 19). Detta för att göra texten mer lättläst på en läsplatta. Figur 18. Facebookchatt. Figur 20. Enhetslista, visar alla enheter man har en dialog med.
Figur 19. Multiplayerchatt. Menyn för detta såg i detta läge ut så här, med knappen till vänster som skickar meddelanden till alla enheter i en övning samt knappar till höger om denna som skickar adresserade meddelanden. Hur stora dessa knappar blir beror på antalet enheter som har kopplat upp sig under programmets levande tid. Knapparna har även fått en indikator som visar om enheter är online eller offline (har uppdaterat sin position de senaste 5 sekundrarna)(se Fig. 20). När denna var klar var det dags att börja skissa på hur denna meddelanderuta skulle se ut i stations läget tillsammans med hur ett meddelande skulle se ut. Denna meddelanderuta skulle klara av att visa så många meddelanden som möjligt samtidigt som meddelandena ska vara lätta att se även på avstånd om det är en pilot som skulle titta på skärmen. Meddelanderutan skulle därför designas för att ge ett bra fokus på det senaste meddelandet som har anlänt främst, och därefter rymma cirka 8 medelstora meddelanden för att därefter ha funktioner för att scrolla eller “swipea” för att kunna se tidigare meddelanden. Vi behövde också bestämma hur ett specifikt meddelande skulle se ut. Dagens chattprogram använder lite olika sätt för att visa ett meddelande. Mobiler använder sig av klassiska pratbubblor på olika sidor av skärmen i olika färger för att visa vem som skickar ett meddelande till skillnad från mailfunktionen som enbart skickar den relevanta texten. Dessa applikationer skiljer sig så att i mobiltelefonerna ska konversationerna uttryckas i realtid medans mail är ett mer informationrikt sätt att skriva där innehållet är viktigare. Den har inte heller samma tidspress. Vårt chattprogram behövde lite av båda eftersom meddelandena behöver skickas ganska snabbt samt att informationen som skickas är viktigare än ett vanligt chattmeddelande. Detta gjorde att vi valde att ge varje meddelande en tidstämpel med en enklare version av denna “pratbubbla” för att fortfarande ge meddelanderutan en känsla av konversation och inte typiskt mail. Till en början hade vi en Saabikon i bakgrunden av chatten men i windows form så skapade detta otroliga fördröjningar vilket gjorde att denna inte var värd att ha med i programmet trots att den gav
meddelanderutan en proffsigare känsla. Vi valde att göra de egna meddelandena blåa för att många användare känner igen sig i det eftersom Apple använder en liknande färg för sina egna meddelanden samt att det är Saabs blå färg. Meddelanden som kommer från andra får färgen grå för att inte göra meddelanderutan för färggrann vilket kan ge programmet fel intryck. Enligt Fig. 21 såg meddelanderutan ut preliminärt. Vi kom i detta läge på att vi var tvungna att vara konsekventa i vårt val av typsnitt och typsnittsstorlek i programmet och kollade därför runt på olika applikationer för att få inspiration av ett tydligt men snyggt typsnitt tillsammans med vår Windows/spotifyliknande design. Denna sida [19] gav några tips på hur man kan tänka när man väljer typsnitt och efter att ha kollat runt lite så kom vi överens om att “Microsoft sans” gav programmet rätt känsla. Storleken på typsnitten ändrar sig beroende på vart i programmet vi är samt efter skärmstorleken. Tillsammans med skapandet av meddelanderutan behövdes en ruta där meddelanden kunde matas in tillsammans med en “skicka”knapp som skickar iväg det skrivna meddelandet. Windows forms har ett “textbox”verktyg som kan användas för detta. Denna textbox hade dock ingen snygg lösning på att bokstäver som gick under “kanten” på textrutan och därför gjordes textrutan i “fel storlek” tillsammans med en panel i samma färg för att lura användaren att rutan är större än vad den är både uppe och nere. Detta gjorde att textrutan var lättare att läsa av och gjorde att skicka knappen fick en större yta som den passade i, med tanke på tidigare gjorda objekt i gränssnittet. Vi ville att skillnaden mellan stationmode och flightmode skulle främst vara användningen av de kortkommandon som skulle läggas in, i stationsmode skulle dessa kunna användas begränsat men i flightmode skulle denna del vara den viktigaste delen för att med få klick kunna skicka ett fördefinierat meddelande. Därför valde vi att i stationmode ha en liten panel av kommandon som gick att bläddra i för att kunna se vilka kommandon som fanns tillgängliga samt klicka på en för att förflytta dennes text till textrutan för att kunna skicka (se Fig. 22). Ett kommando i denna lista är därför en knapp precis som i enhetlistan för att göra att detta program skulle fungera bra på en läsplatta. I denna knapp kan man se tre saker. Knappens text, knappens motsvarande kortkommando samt knappens snabbhetsknapp på tangentbordet som ges utav knapparnas ordning med starten QWERTY och så vidare. Figur 21. Meddelanderuta, där meddelanden visas.
I detta läge kan denna panel bläddras via scrollen på musen men denna kan behöva en “pushanddrag”funktion för att fungera på en platta eftersom ingen scrollfunktion kan användas på en sådan. Vid första skissen av designen så lämnade vi ett område i station mode där vi ville slänga in diverse knappar som ska skilja stationmode från flightmode (se Fig. 23). I detta område placerade vi en “hjälp”knapp som skulle användas av användare som ej använt programmet innan för att lättare kunna förstå vad som kan göras i programmet. Förhoppningsvis är programmet intuitivt nog men en hjälpknapp är ändå aldrig fel eftersom saker vi skapare av programmet ser som självklart kanske inte alls är självklart när programmet är klart. Vi har även en knapp som byter läge på vilken text som skickas när ett kommando används. Alltså om den ordinarie texten skickas eller om det hemliga kortkommandot skickas. Vi har även lagt till en knapp som skymmer textpanelen med ett område där du kan lägga in enheter i en vänlista eller blockera en viss enhet samt en till knapp som gör att ditt program enbart hanterar enheter som du har i din vänlista (se Fig. 24). Detta ifall R5:orna kommer att köras på det marina frekvensera så behöver programmet att kunna sålla ut vilka enheter som faktiskt är med i övningen. Blockeringslistan är till för om man vill köra på en viss frekvens men det finns en enhet som stör mer än vad den ger kan man därför blockera denna. Figur 22. Kommandolistan, alla inlagda kommandon. Figur 23. Undermeny.