• No results found

Implementation av binary messages i AIS och användargränssnitt för egendefinierade meddelanden

N/A
N/A
Protected

Academic year: 2021

Share "Implementation av binary messages i AIS och användargränssnitt för egendefinierade meddelanden"

Copied!
49
0
0

Loading.... (view fulltext now)

Full text

(1)

 

 

  

  

  

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 

(2)

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 45   

(3)

Sammanfattning 

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 AIS­informationen 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.       

(4)

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öm                                                     

(5)

Inledning 

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  AIS­protokollet  (Automatic Identification System).     Fordon som väger mer än 300 ton måste vara ha utrustning installerad avsedd för att skicka ut  AIS­information [11]. Utskicket av AIS­information har som huvudsyfte att informera medtrafikanter  om ett fordons aktuella position (se Fig. 1). När AIS­utrustningen är rättkonfiguerad så är det ett  helautomatiserat system, det krävs ingenting av användaren. Vi kallar det “AIS­information” 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. 

(6)

  I AIS­informationen å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 B­transponder  är dels att klass A­transpondern är dyrare och att den dels har lite extra funktioner. Klass  A­transpondern skickar ut AIS­informationen 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 A­transponder 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 A­transponder kan därför  skicka ut en annan meddelandetyp där riktningen står angiven. En klass B­transponder är inte  tillståndsberoende och utskicket av data sker med konstant periodicitet. B­transpondern har också  lägre prioritet till skillnad mot A­transpondern. Det vill säga, B­transpondern 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  AIS­information. 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 text­display (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  AIS­data så att alla enheter som opererar på samma frekvens kan ritas ut på en karta, programvaran  kallas chartplotter.  Figur 1. Hur GPS­data kan utbytas mellan fordon. 

(7)

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å AIS­protokollet samt GPSMAP­utrustningen 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 AIS­protokollet 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 samt 

(8)

framtagning 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 icke­uppkopplad  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 AIS­protokollet samt GPSMAP­utrustningen.  ● Definiera funktioner för mottagning samt sändning av meddelanden via AIS.  ● Skapa ett användargränssnitt för chatt­funktion 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 

(9)

○ psmapNedbrytning av det existerande avläsningsprogrammet till  transpondern   ● Implementation av  ○ textomvandlingar från text till hexadecimalt  ○ textomvandlingar från tect till 6­bit 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 

(10)

○ 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.     

(11)

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, GPS­mottagare och kraftaggregat  ● Net Framework version 4.0   

 

 

(12)

Fö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 i 

(13)

planet 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  master­slave 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 IP­nä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. 

(14)

  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 mmorpg­spel 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 ur 

(15)

flera 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. NMEA­protokollet har som kärnuppgift att se till att varje,  inkommande och utgående meddelande, vilket huvudsakligen är GPS­information, eller så kallade  “Position reports”, är strukturerad på ett visst sätt. NMEA­meddelanden ö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 AIS­meddelanden [12].    NMEA­protokollet 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 NMEA­strängar. 

(16)

  Detta är exempel på GPS­meddelanden som tas emot/skickas som NMEA­strängar. Alla ovanstående  meddelanden börjar med GP (som syftar till GPS). Det finns också så kallade AIS­meddelanden, 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 Safety­Related Message  13  Safety­Related Acknowledgement  14  Safety­Related 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  Aid­to­Navigation 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 messag​e  Tabell 5. AIS­meddelanden definierade i AIS­protokollet.    Vi är mest inriktade på meddelandetyp 6 och 8. Typ 6, Binary Addressed Message ser ut som  beskrivning i Tab. 6.               

(17)

Field  Len  Description  Member  T  Units  0­5  6  Message Type  type  u  Constant: 6 

6­7  2  Repeat Indicator  repeat  u  As in Common Navigation Block  8­37  30  Source MMSI  mmsi  u  9 decimal digits 

38­39  2  Sequence Number  seqno  u  Unsigned integer 0­3  40­69  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 

72­81  10  Designated Area Code  dac  u  Unsigned integer  82­87  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 “re­broadcasta” 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 NMEA­strängar och överförs med en  bithastighet på 4800 bit/s. Vi kommer att fokusera på AIS­meddelanden 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. NMEA­strängar är skrivna som ASCII medans övriga  AIS­meddelanden är kodade som 6­bitars binärkodning [15].    

(18)

  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). AIS­standarden  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 AIS­meddelanden tar upp olika många slots beroende på storleken av  meddelandet. AIS­standarden 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örst­till­kvarn”­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.     

(19)

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 usb­minnen som innehåller en tomt eller icke­tomt 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  A­Z (versaler) samt siffror 1­9, 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. 

(20)

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  AIS­manualer 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 

Transmitter­responder“). Den mest signifikanta skillnaden är hur ofta transpondern skickar ut data.  En klass B­transponder skickar endast ut data var trettionde sekund oberoende av fordonets  orientering. En klass A­transponder innehåller information om bland annat orientering, destination  och beräknad ankomsttid. Klass A­transpondern 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 safety­related 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  GPS­mottagare. 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 COM­port i datorn. Transpondern i sin tur hade en GPS­mottagare inkopplad som  hämtade GPS­information 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 AIS­informationen 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 AIS­meddelanden 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 

(21)

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 COM­porten 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 7­bitars ASCII­tecken, 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, NMEA­strä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 GPS­mottagaren 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  GPS­meddelande 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 “AI­meddelanden” 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 AIS­meddelanden, som  innefattar den “vanliga ais­informationen” 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 XOR­operationer.    

(22)

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 AI­meddelanden 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 AIS­protokollet. 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 AIS­protokollet 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 0­99). 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 GPAAM­meddelande 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, NMEA­strä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.       

(23)

  $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 AIS­meddelande.    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.       

(24)

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 station­mode och den senare  flyg­mode.     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.     

(25)

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 SMS­konversationer 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 “swipe­spacen” (swipe­utrymmet) 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 “station­mode” där egendefinierade meddelanden är i  fokus, här ska även finnas inställningsmöjligheter till programmet. Ett annat läge som vi kallar  “flight­mode” 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 swipe­funktion 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 IP­nätet eller via en  RS422­port. 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.   

(26)

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. EC­meddelande, en NMEA­sträng med meddelandefält “HELLO” i 6­bit 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 mottagar­id vilket i exemplet ovan är  793420871 och meddelandeinnehållet, kodat i 6­bitar 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.   

(27)

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 windows­applikation 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. Facebook­chatt.      Figur 20. Enhetslista, visar alla enheter man har en dialog med. 

(28)

  Figur 19. Multiplayer­chatt.    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 Saab­ikon 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 

(29)

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 station­mode och flight­mode 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   flight­mode 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 station­mode 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. 

(30)

I detta läge kan denna panel bläddras via scrollen på musen men denna kan behöva en  “push­and­drag”­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 station­mode från flight­mode (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.   

References

Related documents

[r]

[r]

[r]

[r]

 Delegationsbeslut FC Niklas Roos af Hjelmsäter, enligt kultur- och fritidsnämndens delegationsordning § 3.8 – 2018/0103 KFN-2 Besvarande av detaljplaneremisser som ej

Kommunfullmäktige § 42/2016 – Svar på motion väckt av Peter Godlund (MP) och Josefin Utas (MP) om införande av cykelbokslut i kommunen5. Kommunstyrelsen 2016-04-27 –

Kommunfullmäktige § 7/2015 – Svar på motion väckt av Anna Myrhed (C) om att se över förutsättningarna för att

från en i Norrortsleden ingående vägtrafiktunnel, Törnskogstunneln i Sollentuna kommun; nu fråga om prövotidsredovisning avseende inverkan på brunnar