Loggning, distribution och behandling av data från radaranläggningar

Transkript

1 Examensarbete 20 poäng D-nivå Loggning, distribution och behandling av data från radaranläggningar Reg.kod: Oru-Te EXA037-Mag102/03 Matz Johansson Magisterprogrammet i elektroteknik 160 poäng Örebro vårterminen 2003 Examinator: Dag Stranneby Handledare: Kjell Mårdensjö LOGGING DISTRIBUTION AND TREATMENT OF DATA FROM RADAR UNIT

2 Sammanfattning Syftet med examensarbetet var att utvärdera metoder för att logga, lagra, distribuera och presentera data som passerar mellan radar och en yttre enhet vilket är ansluten till radarn. Behovet att logga data har uppkommit då det visat sig att statusinformationen inom denna typ av radarsystem är felaktig. För att hitta en lämplig maskinvara som på ett tillfredsställande sätt skulle kunna logga statusinformationen har bland annat olika typer av färdiga maskinvaror utvärderats. Efter att utvärderingen var klar har all utrustning och de programvaror som krävs för att få ett fungerande loggningssystem tagits fram. Resultatet av arbetet är en loggningsutrustning som kan logga statusdata under ca 6 månader innan lagringsmediet är fullt och samtidigt erbjuder en webbserver där användaren kan surfa in och söka efter data i en databas. För att söka data i databasen har en dynamisk webbsida konstruerats. Abstract The purpose with this degree project is to evaluate different methods to log, store, distribute and present the data transfered between a radar and an outer unit which is connected to the radar. The requirement to log data has been a pressing issue when it has come to be known that the status information in this type of radar system not is correct. To find a proper hardware which in a satisfactory way could log the status information has different types of hardware been evaluated. After the evaluation has all the necessary equipment been bought or developed and the necessary software which is needed for the system to work, been written. The result of the project is a log system that can log status data for 6 months before the storage media is full. The equipment also offers a web server where the user can search for data in a database. To make it possible to search data in the database a dynamic web site has been developed. 2 (34)

3 Innehållsförteckning 1. Förord Bakgrund Uppdragsbeskrivning Genomförande Teori Beskrivning av RS Beskrivning av HDLC Analyserande del Vad ska loggas Utvärdera olika möjligheter hur loggning ska ske Utvärdera alternativ för lokal lagring av loggade data Utvärdera alternativ för distribution av data Utvärdera alternativ för central lagring av data från flera radaranläggningar Definiera hur data ska behandlas och presenteras lokalt och centralt Vald lösning Implementering Bärarkort RCM Avläsning av portar i MSM586SEV Apache PHP MySQL Illustration av MSM586SEV Utvärdering/Diskussion Uppdraget Resultat Fortsatt utveckling Referenser I pappersform Webbsidor Figurförteckning Tabellförteckning Ordlista/förklaringar (34)

4 Förteckning över bilagor För ytterliggare information om AVR-processor och Siteplayer se...bilaga 1. För ytterliggare information om RCM3200 se...bilaga 2. För ytterliggare information om DSTni-LX se...bilaga 3. För ytterliggare information om TINI se...bilaga 4. För ytterliggare information om Infineon se...bilaga 5. För ytterliggare information om TDK se...bilaga 6. För ytterliggare information om MSM586SEV se...bilaga 7. För att se mer om AM26LS320C se...bilaga 8. Se mer om MAX202 i...bilaga 9. För närmare information om programmet till RCM3200 se...bilaga 10. För närmare information om programmen som avläser portar se...bilaga 11. För att läsa mer om filen termios.h se...bilaga 12. För närmare information om programkoden till search.php se...bilaga (34)

5 1. Förord Jag skulle vilja tack tacka min handledare på AerotechTelub, Fredrik Pettersson för att han hjälp mig och stöttat mig exemplariskt, tack Fredrik. Jag vill också tacka min handledare från Örebro universitet, Kjell Mårdensjö samt Dag Stranneby, Bo-Lennart Silfverdal och Lars- Göran Persson från universitetet. Till sist vill jag också tacka den övriga personalen på AerotechTelub Division Sensorsystem Affärsenhet Radar och VMS. 2. Bakgrund AerotechTelub arbetar med service och underhåll, på bland annat radaranläggningar, åt försvarets materielverk, FMV. Radaranläggning PS870 är en anläggning som AerotechTelub underhåller. Sedan en tid har det varit problem med PS870 då radarsystemets verkliga status inte stämmer med den information som skickats av MTS-enheten. Detta har medfört att frågan om loggning av systemet uppkommit. Idag upptäckts fel, bland annat i försvarets centraler som medför att servicepersonal åker ut till radaranläggningar för reparation och på plats upptäcker att felet inte var det fel som rapporterats av MTS-enheten. Givetvis är dessa fel dels kostsamma och dels resurskrävande och medför att arbete läggs ner där det inte behövs. Problemet har kommit till AerotechTelubs kännedom och med detta examensarbete görs ett försök att lokalisera var problemet uppstår. 3. Uppdragsbeskrivning Uppdraget uppdelat i sex punkter enligt specifikation: 1. Utvärdera olika möjligheter hur loggningen skulle kunna ske. 2. Utreda alternativ för lokal lagring av loggade data. 3. Utreda alternativ för distribution av loggade data. 4. Utreda alternativ för central lagring av loggade data från flera radaranläggningar. 5. Definiera hur informationen skulle kunna behandlas/presenteras lokalt och centralt. D.v.s. presentera olika alternativ för att behandla och presentera data lokalt och centralt. 6. Välja det lämpligaste alternativet och genomföra detta. Arbetet består av att ta fram lämplig utrustning som har möjlighet att logga det data som skickas mellan radar och MTS. Data som skickas mellan MTS och radar skickas med gränssnittet RS422 där protokollet HDLC används. Data ska kunna lagras lokalt vid radaranläggning för att, till exempel, servicepersonal ska kunna analysera data på plats vid radarstationen. Vidare ska data också kunna distribueras eller bli nådd över ett LAN men även möjligheten att använda telefonmodem för distribution av data är av intresse. Data ska också kunna presenteras på ett sammanställt sätt såsom i kolumner och rader både centralt och lokalt. Det finns också önskemål om att automatiskt kunna lagra och presentera sammanställt data från flera radarstationer utrustade med loggern i en central databas. När dessa ovanstående krav har tagits i betänkande och lämplig maskinvara hittats ska den införskaffas. Den programvara som behövs ska införskaffas eller tillverkas. Därefter ska loggern tillverkas och testas. 5 (34)

6 4. Genomförande I detta kapitel redovisas ett teoriavsnitt där RS422 och HDLC-protokollet beskrivs. Vidare redovisas hur den analyserande och den implementerande delen är genomförd. I kapitel 4 redovisas också generellt hur loggningen går till och hur data lagras och distribueras. Här redovisas också hur presentationen av data är implementerad. Radarstationer av denna typ innehåller materiel som är konfidentiell. På grund av detta är viss detaljinformation förändrad och borttagen. Detta innebär inte något problem för denna rapport eftersom det är den generella funktionen av en loggning som redovisas. Med uppdragsbeskrivningen som bakgrund har genomförandet grovt planerats efter nedanstående struktur. Arbetet har bestått av i huvudsak två delar, en analyserande del och en implementerande del. Den analyserande delen ligger till grund för den implementerande delen. Den analyserande delen är uppdelad i ett antal steg, bland annat dessa: Utvärdera olika möjligheter hur loggning ska ske Utvärdera alternativ för lokal lagring av loggade data Utvärdera alternativ för distribution av data Utvärdera alternativ för central lagring av data från flera radaranläggningar Definiera hur data ska behandlas och presenteras lokalt och centralt Den implementerande delen är också indelad i ett antal steg enligt nedan: Framtagning av maskinvara Implementering av programvara som läser från de seriella portarna Implementering av PHP och annan programvara Implementering av databas Implementering av webbserver 6 (34)

7 4.1. Teori Beskrivning av RS422 RS422 är en standardiserad metod att överföra data seriellt. Det finns flera olika versioner av RS422, den version som används i radarsystemet är RS422A/V.11. Ofta används RS422 då avståndet mellan DCE, Data Communication Equipment och DTE, Data Terminal Equipment är stort. RS422A/V.11 klarar 100 kbps då sträckan är kortare än 100 meter och 10 Mbps då sträckan är mindre än 10 meter, som i fallet mellan MTS och radar. Överföringen sker i en tvinnad parkabel där differentiella överföringskretsar producerar två signaler med olika polaritet som sänds i varsin ledare. Om ledningen störs så uppkommer störningen troligen på bägge ledarna. Då signalen nått den differentiella mottagningskretsen har bägge ledarna samma störning och störningen kan elimineras. För att motverka att signalen studsar tillbaka mot sändaren används ett motstånd med samma resistans som ledningens karakteristiska impedans. I figur 1 är det motståndet Rt som avses. RS422 blir därför en relativt säker dataöverföringsmetod. Figur 1 visar en figur på överföringsmetoden. Figur 1. Överföringsmetod RS422 7 (34)

8 Beskrivning av HDLC Tabell 1. HDLC-protokoll High Level Data Link Control är ett dataöverföringsprotokoll som är uppdelat i fyra ramar, dessa ramar är inneslutna av en startflagga och en stoppflagga. De fyra ramarna är adress-ram, kontroll-ram, data-ram (I-ram) och Frame Check Sequence -ram där varje ram innehåller ett eller flera ord om 8 bitar. Frame Check Sequence forkortas FCS, vilket ibland kallas Cyclic Redundance Control som förkortas CRC. Dataramen kan innehålla obegränsat många ord men i fallet mellan MTS och radar innehåller dataramen mellan 0 till 32 ord. Nedan redovisas den typ av HDLC-protokoll som gäller mellan MTS och radar. Startflagga/stoppflagga För att skydda startflaggan och stoppflaggan som är det 8-bitars ord som sitter först och sist i HDLC-ramen med bitmönstret , sätts en nolla in om det förekommer mer än 5 ettor i rad. Anledningen är för att undvika att data av misstag ska bli tolkat som en flagga, metoden kallas nollinsättning. Mottagaren skall alltid ta bort en nolla efter 5 ettor. Denna nolla ingår inte i CRC-beräkningen. Det enda undantaget är om en ram måste avbrytas. Då sätter sändaren in en sekvens på minst sju ettor i bitströmmen för att avsluta ramen. Adress-ram Adressen är alltid Anledningen till att adressen alltid är beror på att det är en punkt-till-punktförbindelse vilket innebär att det räcker med en adress eftersom det endast finns en mottagare, MTS eller radar. Kontroll-ram Bit nr fält MSB LSB I msb N ( R ) lsb P/F msb N (S) lsb 0 I RR msb N ( R ) lsb P/F S RNR msb N ( R ) lsb P/F S SNRM P U DISC P U UA F U DM F U FRMR F U Tabell 2. HDLC-protokollets kontrollram Kontroll-ramen är 8 bitar och identifierar vilken typ av ram som kommer, antingen en info eller kommando/respons-ram. Förkortningarna i tabell 2 står för: I = Information. RR = Receive Ready. Vilket är ett ord/ram som bekräftar och meddelar att fler I-ramar kan tas emot. RNR = Receive Not Ready. Ber att sändaren att sluta sända, fler I-ramar kan inte tas emot. Används för flödeskontroll men har även andra syften. SNRM = Set Normal Response Mode. Detta gäller då det är en obalanserad konfigurering. 8 (34)

9 DISC = Disconnect. Annonserar till exempel systemet stannar. UA = Unnumbered Acknowledge. DM = Disconnect Mode. FRMR = Frame Reject. Indikerar mottagandet av en godkänd men omöjlig ram. N (S) = Send sequence Number. En sekvensräknare som räknar mellan 0 till 7. N (R) = Receive sequence Number (next expected). En sekvensräknare som räknar mellan 0 till 7. P = Poll bit. Indikerar att det kommer flera ramar. F = Final bit. Indikerar att det var sista ramen. De olika fälten I, S och U står för Information, Supervisory och Unnumbered och delar in ramarna i olika format för att särskilja olika typer av kontroll-ramar. Data-ram (I-ram) Dataramen innehåller 0 till 32 ord, alltså 0 till 256 bitar och är ren binär info och är den information som skall loggas. FCS-ram (Frame Check Sequence) Är ett 16-bitars fält vars värde beräknas av en CRC-algoritm. Den cykliska redundanskontrollen används för kontroll av bitfel på hela HDLC-ramen och beräknas med modulo 2- metoden. Genom att dividera meddelandet som ska sändas med ett generatorpolynom, vilket beräknats på förbestämt sätt, beräknas en kvot och en rest. Den rest R(x) som beräknats betecknar FCS. Beräkningsmodellen är denna: M ( x) G( x) = Q( x) + R( x) 5 16 Där M(x) är meddelandet som ska sändas, G ( x) = 1+ x + x 12 + x är generatorpolynomet (CRC-CCITT), Q(x) är kvoten och R(x) är resten, vilken används som checksumma. 9 (34)

10 4.2. Analyserande del Den analyserande delen var en stor del av arbetet. Det var en hel del olika saker att sätta sig in i såsom RS422 och HDLC vilket beskrivits i teoriavsnittet samt även vad det fanns för olika maskinvaror som skulle passa just för detta ändamål. Att söka efter en lämplig maskinvara visade sig vara en intressant men också komplicerad del, eftersom det finnas många olika men ändå passande maskinvaror. Några av de mest intressanta maskinvarorna redovisas nedan i kapitel En annan viktig sak var att förstå var systemets funktion och vilken kringutrustning som var ansluten till radarsystemet eftersom de olika enheterna runt systemet ofta nämndes i dokumentationen. Vidare skulle det bestämmas vad som skulle loggas. Var det hela HDLCprotokollet från startflagga till stoppflagga som skulle loggas eller kanske bara I-ramen med information eller något där emellan? Eftersom det internt på AerotechTelub fanns stor kunskap om vilka data som skickas i dessa ledningar och vad som kunde vara intressant att logga togs det i beaktande då detta bestämdes. De olika stegen. Uppgiften kunde som sagt delas upp i ett antal olika steg där ett av de tidiga stegen var att utvärdera hur loggning ska genomföras. För att bestämma hur loggningen ska genomföras måste ett lämpligt maskinvarukoncept hittas. Att hitta rätt maskinvara var viktigt eftersom hela systemet skulle bli beroende av det. En väl vald maskinvara kunde till exempel underlätta möjligheterna för lokal lagring och distribution och presentationen av data. När de olika delarna tagits i beaktande och en ytlig bild skapats av hur systemet ska byggas upp gjordes en djupare analys över hur loggningssystemet skulle fungera och hur det ska genomföras. Bland annat hur data skulle överföras till ett användargränssnitt så att användaren på ett enkelt sätt skulle kunna analysera detta. Andra saker som krävde eftertanke var hur stor datamängd som ska lagras och vilken säkerhet som krävs för överföring av data till annan dator. Efter utvärderingen av hur loggningen ska genomföras gjordes en analys av hur data ska lagras. Den primära uppgiften i denna del var att klargöra vad som krävs för att lagra data och var detta ska göras. En beräkning av hur mycket utrymme som krävs för att lagra data ska göras utifrån analysen av hur mycket data som ska lagras. En intressant del här är även frågan om hur data ska lagras lokalt, om det bör lagras på hårddisk, flash-minne eller någon annan lagringsform. Då analysen av var och på vilket sätt data ska lagras var klar fortsatte arbetet med att utvärdera hur data skall distribueras. Detta har betydelse för hur konstruktionen ska se ut, det påverkar bland annat om det ska vara ett webbinterface eller inte. Här kommer frågan om möjligheten att kunna koppla upp sig via modem, Ethernet eller kanske Internet att behandlas samt om data skall distribueras kontinuerligt eller endast kunna nås då anslutning mot loggern sker. Vidare så utvärderades olika alternativ för hur central lagring av data skulle kunna genomföras. Även behandlingen av data, till exempel om rådata ska presenteras eller om data ska modifieras och tolkas, analyseras också. Till sist behandlas också presentationsdelen där det bland annat ska bestämmas om data ska presenteras i tabellform, strängform eller på något annat sätt. 10 (34)

11 Vad ska loggas Det visades sig att efter efterforskning och utfrågning av uppdragsgivaren, AerotechTelub, att det endast var ramen med bit-data, den så kallade I-ramen som var intressant att logga. I-ramen innehåller själva informationen som sänds i ledningen, den information som senare avläses och tolkas av bland annat försvaret. Dessa I-ramar innehåller olika typer av information, för att nämna några typer av information som skulle kunna sändas: radareffekt, omfång, temperaturer, radarstatus med mera. De andra ramarna som sänds innehåller endast adress, kontrolluppgifter och information om själva överföringen Utvärdera olika möjligheter hur loggning ska ske Utvärderingen hur data ska loggas är till stor del gjord med avseende på vilken maskinvara som skall användas. Maskinvaran är en viktig del med avseende på hur programvaran ska utvecklas, så att hitta en maskinvara som passar detta ändamål kändes viktig. Om lämplig maskinvara med bland annat möjlighet till LAN-anslutning och hårddiskanslutning skulle finnas tillgänglig finns möjligheten till ett lyckat koncept. Finns en maskinvara med många in- och ut-enheter så underlättar det implementationen. Är dessutom maskinvaran avsedd för inbyggnad med andra system finns ju också en utvecklingsmöjlighet av loggningssystemet, vilket kan vara bra i framtiden. Det finns alltså många aspekter att ta i beaktande då valet av maskinvara ska göras. Några önskemål om maskinvaran är: Enkel att utveckla programvara till LAN- och hårddiskanslutning Utvecklingsbar Enkel att administrera Genom efterforskning på Internet och i broschyrer har ett antal olika tänkbara alternativ visat sig vara intressanta. Några av de olika alternativen redovisas i korthet nedan. Datablad till de olika kretsarna finns som bilagor. AVR-processor och Siteplayer Ett alternativ var en konstruktion där några av komponenterna skulle vara AVR-processor, SitePlayer, hårddisk och kretsar för mottagning av RS422 och HDLC-kommunikation. Konstruktionen skulle anslutas till radarsystemet via kommunikationskretsarna och lyssna på dataledningen mellan radar och MTS. Kretsarna är av samma typ som redan används på anläggningen. Då data kommit in på en port förflyttar AVR-processorn data till hårddisken. Då man vill se på data ansluter man till kretsen SitePlayer, med en webbläsare, där till exempel en dynamisk webbsida hämtar upp det data som valts. SitePlayer är tänkt att anslutas seriellt till AVR-processorn, detta kan göra att data kommer att laddas sakta till SitePlayer. Denna konstruktion hade varit ganska tidskrävande och avslutades redan under idéstadiet. Den har alltså inte genomförts men borde vara en möjlig sammansättning. För ytterliggare information om AVR-processor och Siteplayer se bilaga 1. RCM 3200 RCM 3200 är en lämplig krets som innehåller de nödvändiga delar som behövs utom hårddiskanslutning. Den har stöd för både RS422 och synkron HDLC. Den utför också cyklisk redundanskontroll. Det finns också möjlighet att skicka data seriellt via RS232 till andra enheter. En LAN-anslutning möjliggör överföring via UDP och TCP/IP. För ytterliggare information om RCM3200 se bilaga (34)

12 DSTni-LX DSTni-LX är en version av Intels 16-bitars processor med 256 KB SRAM och flera kommunikationsportar. DSTni-LX har också den RS422 interface med möjlighet till webbserver. Tyvärr är de seriella portarna endast asynkrona. Den har även ett IDE-gränssnitt. För ytterliggare information om DSTni-LX se bilaga 3. Tini En populär krets har visat sig vara Tini från Dallas Semiconductor som är en inbäddad processor med ett eget Javabaserat operativsystem. Det finns mängder med information och kodexempel till Tini. Tini har möjlighet till webbserver, telnet, FTP-server, TCP/IP-stack samt externa kort med bland annat RS422 möjligheter. Modulen innehåller även en synkron tvåkanalig seriell anslutning. För ytterliggare information om TINI se bilaga 4. Infineon Infineon har ett kommunikationssystem baserat på en C165UTAH-kontroller som heter EASY Systemet har två stycken synkrona RS422-överföringskretsar som klarar fullduplex med både klocka och data. Det finns även en HDLC-kontroller kallad SEROCCO som hanteras av C165UTAH. För ytterliggare information om Infineon se bilaga 5. TDK TDK har en CMOS-baserad mikroprocessor (73M2910L) och den är baserad på 8-bitars industristandarden och jobbar med 44 MHz. Det finns också 24 programmerbara I/O-portar samt 3 externa avbrottskällor. Det ska även finnas en användarvänlig HDLC-paketerare som nås genom speciella funktionsregister och som tillhandahåller seriell I/O. HDLC-delen har även maskinvarusupport för 16-bitars CRC, nollinsättning och ett dedikerat avbrottsläge för paketeraren. Det finns också ett speciellt HDLC-avbrott med två register associerade till sig. Tyvärr verkar TDK:s 73M2910L inte vara så vanlig då inget forum hittades på Internet. Dessa forum brukar vara en bra informationskälla för att skaffa sig användares åsikter av en produkt. För ytterliggare information om TDK se bilaga 6. MSM586SEV MSM586SEV är en PC/104, vilket är en liten PC med bland annat fyra seriella portar och en parallell port, alltså gott om I/O. Den har också IDE-anslutning för hårddisk samt DiskOnChip vilket är en ny typ av lagringsmöjlighet. Det finns även tilläggskort, så kallade PC/104+, vilket är kort som ansluts till PC/104 via PC/104-bussen. Dessa tilläggskort finns i en uppsjö olika fabrikat och märken med lika många olika användningsområden. Eftersom ett vanligt operativsystem kan installeras underlättas hanterandet av systemet avsevärt och gör den också väldigt flexibel. Detta medför att en vanlig webbserver kan installeras enkelt. Eftersom MSM586SEV är en vanlig dator kan skärm, mus och tangentbord anslutas vilket medför enkel hantering av systemet. Det som skiljer den från en vanlig dator är storleken och priset. Tyvärr har inte MSM586SEV någon hantering av HDLC eller RS422. För ytterliggare information om MSM586SEV se bilaga (34)

13 Slutsats Med dessa olika ovanstående alternativ som bakgrund ser man att det finns möjlighet att logga data på plats och att användningen av inbyggnadssystem skulle kunna vara ett rimligt alternativ. Man ser också att det finns möjligheter med bland annat MSM586SEV att kunna generera ett dynamiskt användargranssnitt i en webbserver eftersom den kan hantera ett operativsystem. Det skulle då vara möjligt att med en HTML-sida och något dynamiskt språk exempelvis ASP eller PHP söka i en databas. MSM586SEV har också alternativ för att lagra den datamängd som kan komma att loggas. I detta läge uppfyller MSM586SEV många av de önskade kriterierna. För att se beräkning av datamängden som skulle loggas se avsnitt Eftersom data som loggats är konfidentiella skickas dessa enbart på det interna nätverket, det medför att frågan om säkerhet inte behöver tas upp angående dataöverföringen Utvärdera alternativ för lokal lagring av loggade data Data som loggas av en mikrocontroller eller liknande ska lagras. Ett sätt är att lagra data på hårddisk medan ett annat sätt är att lagra data i flash-minnen. För att undvika att batterier och annat ska orsaka databortfall eller att lagringsmediets lagringsutrymme inte räcker till bör lagringen ske på hårddisk. Det känns som ett naturligt alternativ då flera maskinvarualternativ också stödjer IDE. En annan aspekt vid valet av lagringsmedia är att hårddiskar är det vanligaste lagringsmediet och att IDE är standardiserat så ett utbyte av hårddisken ska inte vålla alltför stora problem. Ytterliggare en fördel är att lagringskapaciteten i en hårddisk kan vara relativt stor. En beräkning av hur mycket data som maximalt kan skickas mellan MTS:en och radaranläggningen på en av dataledningarna redovisas i tabell 3. Beräkningar görs i steg och redovisar olika alternativa datamängder beroende på vad som ska loggas. Eftersom loggning görs på både RX och TX så är den maximala datamängden dubbelt så stor som den beräknade datamängden i tabell 3. Detta alternativ i tabell 3 är inte aktuellt då endast I-ramen ska lagras men klargör vad som krävs om all data ska loggas. Om maximal datamängd överförs Antal bits/s 4800 Tot. antal bits/min Kbit Tot. antal bits/tim ,3 Mbit Tot. antal bits/dygn Mbit Tot. antal MB/dag MB Tot. antal MB/vecka MB Tot. antal MB/månad ,5 GB Tot. antal MB/år GB Tabell 3. Maximal datamängd i en riktning Maximal intressant datamängd som överförs Antal bits/s 4800 Antal intressanta bits/ram 256 Antal mindre intressanta bits/ram 48 Max antal bits/ram 304 Antal ramar/s 15.8 Antal intressanta bits/s Tabell 4. Intressant maximal datamängd i en riktning I tabell 4 redovisas en beräkning av den maximala intressanta datamängden endast i en riktning. Den intressanta datamängden kan variera från 0 bits till 256 bits per ram. 13 (34)

14 Den maximala intressanta datamängden som skickas mellan MTS och radaranläggningen är 4042 bit/s I tabell 5 redovisas en beräkning av den intressanta datamängd som ska loggas i en riktning. Den maximala intressanta datamängden som ska loggas i en riktning mellan MTS och radaranläggningen är 306 MB/vecka. Som information ska nämnas att då vi kopplade in ett oscilloskop på ledningen där data överförs visade det sig att den genomsnittliga ordmängden per överförd ram var 8-9 ord. Den verkliga datamängden är då troligtvis mindre än den beräknade eftersom beräkningen i tabell 5 baseras på en maximal ordmängd om 32 ord, alltså 256 bits. Det ska också tilläggas att utöver radardata lagras också en tidstämpel som anger när data kom in på porten i loggningssystemet. Tidstämpeln är minneskrävande. En beräkning på tidstämpeln som har följande utseende YYYYMMDDHHMMSS är gjord. Vilket innebär att det krävs 14 byte per ram. Då det loggas ca 15.8 ramar per sekund skulle tidstämpeln kräva 7 GB per år enligt beräkningen i tabell 6. Intressant datamängd som kan överföras Antal bit/s Tot. antal bitar/min Kbit Tot. antal bitar/tim Mbit Tot. antal bitar/dygn Mbit Tot. antal MB/dag MB Tot. antal MB/vecka MB Tot. antal MB/månad GB Tot. antal MB/år GB Tabell 5. Intressant maximal datamängd som ska loggas i en riktning Tabell 6. Tidstämpelns datamängd Datamängd som tid stämpeln kräver Antal ram/s 15.8 Antal byte/ram 14 Antal byte/tim vilket är 0.8 MB Antal byte/dygn vilket är 19.1 MB Antal byte/vecka vilket är MB Antal byte/mån (30 dygn) vilket är MB Antal byte/år vilket är 7.0 GB Summan av dessa två datamängder, tidstämpel + data, under ett år på en av ledningarna blir då 23 GB. Om man då beräknar att både sändning och mottagning ska loggas blir datamängden 23 GB + 23 GB = 46 GB under ett år. Resultatet innebär att en hårddisk på 50 GB bör kunna lagra ett års loggade data. 14 (34)

15 Utvärdera alternativ för distribution av data Distribution av data är viktigt då granskning av loggade data ska kunna ske centralt. Detta är också bra då man vill sammanställa data från flera radarstationer och en central databas ska understödjas av loggade data. Hur distributionen ska genomföras beror till stor del på den maskinvara som väljs. Det alternativ som är lämpligast ur framtidssynpunkt är att via Ethernet kunna ansluta till en webbserver som är inbyggd i dataloggern, för att sedan med en vanlig webbläsare ha möjlighet att söka och titta på lagrade data. Det ska även gå att ladda hem data från webbservern, kanske i form av en fil. Möjligheten att streama data är i detta läge inte granskad men kan komma att utvärderas i framtiden eller senare under arbetet när maskinvara är vald. Fördelen med att streama är att lättare kunna hitta fel i realtid. Ett tänkbart sätt för att streama data kan vara att använda RCM 3200 eftersom den har LAN-anslutning. Det skulle endast kräva en mindre förändring i det programmet som sköter RCM Som protokoll skall TCP/IP användas. Möjligheten att kunna koppla upp sig via modem mot loggern är intressant då det i försvaret idag är en vanlig typ av datakommunikation. Även frågan om modemanslutning får avgöras vid val av maskinvara Utvärdera alternativ för central lagring av data från flera radaranläggningar Fördelen med att centralt lagra data skulle kunna vara att man enkelt kan sammanställa och jämföra data från olika radarstationer och kanske även andra intressanta data, såsom temperatur och fukt för att kunna se om något samband finns med yttre omständligheter. Data kan dels hämtas manuellt genom att man hämtar hem en fil eller att en automatisk process överför data från de olika radarstationerna. Det senare är att föredra då det kan bli mödosamt att manuellt koppla upp sig mot de stationerna där data ska hämtas. Om man använder sig av automatisk dataöverföring bör data också lagras och bli sammanlänkade automatiskt av något program eller en databashanterare. Lagringen av data bör vara i en, eller kanske på flera hårddiskar eftersom datamängden kan bli relativt stor. Tanken är att sammanlänkningen ska medföra att alla data som ska jämföras ska kunna nås av användaren i en enda hanterare. I denna hanterare ska data sammanställas i tabell- eller diagramform. Denna centrala lagring och hantering bör ske i en central dator eftersom stora centraler ofta redan har bra kommunikation med omvärlden Definiera hur data ska behandlas och presenteras lokalt och centralt För att enkelt kunna läsa och förstå vad loggade data betyder vill man gärna presentera data i en grafisk bild i form av ett diagram eller liknande. Som första utgåva kommer data endast att presenteras i tabellform där olika data kan identifieras med vilken typ av data det är. En funktion som visar data i dess binära form ska också implementeras eftersom det kan vara intressant för uppdragsgivaren. En viss behandling av data kan vara intressant till exempel om man enkelt vill kunna särskilja korrekta data från felaktiga data eller extrema värden från normala. 15 (34)