Problembeskrivning 2. Förutsättningar och antaganden 2. Systemstruktur 3. Identifiering 3. Kartläggning 4. Sökstrategi 5

Transkript

1 Design dokument Realtids- & Distribuerade System Grupp 10 Per Hamrin Mikael Wiberg Christobal Wetzig Martin Persson Innehåll: Problembeskrivning 2 Förutsättningar och antaganden 2 Systemstruktur 3 Identifiering 3 Kartläggning 4 Sökstrategi 5 Beslutssystem och felkontroll 5 Realtidsaspekter & Lastbalansering 6 Kommunikationskomplexitet 7 Slutsatser & kommentarer 7 1

2 Problembeskrivning Vi skall designa ett distribuerat system av trådlösa agenter som genomsöker ett område efter en skatt. Varje agent kallar vi för en nod framöver. Noderna skall självständigt kunna genomsöka området och när en nod finner skatten så skall alla noder samlas på den platsen. Kommunikation mellan noderna får sker över en delad trådlös kanal. Förutsättningar och antaganden För att kunna diskutera designförslag och presentera ett sådant i det här dokumentet så har vi gjort ett antal antaganden. Antaganden vi gjort listas nedan tillsammans med de förutsättningar som är givna av uppgiften. N antal noder Antalet verksamma noder i nätverket är godtyckligt. Oändliga resurser Vi antar att minne och beräkningskapacitet i noderna kommer täcka våra behov och kommer alltså inte diskutera optimering eller begränsningar i enheterna. Trådlöst broadcast-medium Kommunikation sker över en delad trådlös kanal och vi utgår ifrån att mediet hanterar meddelanden som skickas samtidigt och kommer såldes inte diskutera begränsningar i kommunikationsmediet eller hur CAN-bussen är implementerad. Ingen central server Vi har ambitionen att göra hela systemet decentraliserat. Varje nod har ett unikt ID Endast väggar är hinder Vi har alltså inga hål eller andra faror i området som vi behöver hantera. Systemet ska vara skalbart Givet en övre gräns för områdets storlek så ska vi kunna lösa problemet inom en viss tid förutsatt att vi har ett visst antal noder till förfogande. Kartan är tom vid starten Vi vet ingenting om området när vi börjar utforskningen. Synkad klocka Vi vill kunna spara information om när en ändring gjorts i kartan, så därför behöver noderna ha en klocka som går rätt. Grind till området Vi har en grind till området som när en nod passerar denna, utlöser en id-förfrågan hos den nod som passerar denna. Vad gäller feltolerans så gör vi följande antaganden: Oärlig nod = trasig nog Vi har inga möjligheter att skilja på noder som är felaktiga och på dem som skickar vilseledande information. Om noden har tilldelats ett korrekt ID-nummer och skickar giltiga meddelanden så kommer den behandlas som en korrekt nod (även om den har oärliga avsikter). Wait and see Vi förväntar oss inte data från enskilda noder inom visst tidsintervall, utan en nod som slutar fungera kommer först bli klassad som trasig när hela området är genomsökt och data från den noden saknas. Loggbok Vi har en historik gällande vilka bidrag enskilda noder gör till kartan över området. 2

3 Kommer vi dra slutsatsen att en nod är felaktig så kan vi alltså spåra vilka ändringar som denna har gjort i kartan. Detta för att kunna sända dit fungerande noder för att utforska området Systemstruktur Översikt Systemet är ett decentraliserat, trådlöst system där varje nod har en varsin bild av kartan lagrad som uppdateras då något meddelande tas emot om förändring/utbyggnad. De tekniker vi har tänkt använda oss av för att åstadkomma detta är följande: ID Vi har ett självlärande system. Enheten har från tillverkaren ett hårdkodat id som är unikt. Lagring Våra noder har oändligt med utrymme att lagra data om kartor/koordinater/loggbok. Information om vilket ID som har genomsökt vilken ruta är sparas tillsammans med status om rutorna i kartan i den utbyggbara kartan. Sensorer Vi har 2 typer av sensorer på våran nod, en för att känna av näraliggande omgivning för att detektera och undvika kollisioner med väggar/andra noder/annat t.ex. IR eller ultraljud. Den andra sensorn är för specifik för att avgöra om skatten är hittad, då en nod måste köra över skatten för att hitta den, ex på detta är en kanske en kamera med bildigenkänning om skatten är ett kors målat på underlaget, eller kanske en geigermätare om skatten är radioaktiv och nedgrävd. Motorer Vi förflyttar oss med hjälp av någon form av stegmotorer så att vi kan beräkna hur långt vi har förflyttat oss och i vilken riktning. Vi antar att detta systemet fungerar optimalt utan några problem t.ex att däcken slirar eller liknande. Kommunikation Vi använder oss av en CAN-bus liknande trådlös anslutning med oändlig bandbredd så vi har inga problem med konflikter i mediet. Kommunikationen garanterar även att alla meddelandena kommer fram i korrekt tid. Identifiering Vi tänker oss ett självlärande system där noderna skickas in sekventiellt och sen skickar någon form av ID request till de noder som redan finns inne på arenan som beslutar sig om något vettigt ID att tilldela nykomlingen, detta nummer skickas till den senast inkomna noden tillsammans med en lista av de ID n som redan finns. När den första noden kommer in i området så kommer den inte att få något svar på sina id-förfrågningar och den kan därför dra slutsatsen att den är den första noden och tilldelar alltså sig själv id nummer 1. För att detta ska fungera så måste varje nod ha information om sitt eget id samt antalet noder som är verksamma i området. Identifieringsprocessen sker i ett antal steg: 3

4 1. En nod passerar grinden till området. Detta utlöser ett id_request som skickas ut i nätverket. 2. Noder redan i området tar emot id_request och beräknar vilket nytt id den nya noden skall ha. Nytt id är antalet noder + 1. Noderna lägger också till 1 till antalet noder. 3. Noderna svara med ett id_reply innehållandes id-numret för den nya noden samt antalet noder i nätverket. 4. Den nya noden lagrar sitt nya id samt antalet noder som finns i nätverket. I och med detta så är den nya noden klar att börja arbeta. Kartläggning Kartläggning och sökstrategier är kopplade till varandra, men när vi diskuterar kartläggning så tänker vi oss själva uppgiften att åstadkomma en representation av området. Denna skall sedan kunna uttryckas grafiskt för att ge en bild av området. För att rita upp en karta över området så utgår vi från en nollkännedom om området. Kartan ritas alltså upp vartefter området utforskas. Karta = Distribuerad databas Varje nod har en egen kopia av kartan över området. Denna kan liknas vid en distribuerad databas som är synkroniserad över noderna. Kartan har ett versionsnummer som ökas med 1 varje gång en ändring införs i kartan. Associerat med kartan finns även loggboken som innehåller varje versionsnummer och vilken enhet som begärde ändringen samt vad som ändrades. Även tidpunkten för ändringen lagras. Med hjälp av denna kommer vi kunna spåra och återhämta ändringar som gjorts av felaktiga noder. Denna skulle kunna fungera enligt följande: 1. En nod upptäcker en vägg och behöver föra in detta i kartan. 2. Ändringen tilldelas ett versionsnummer som är kartans nuvarande versionsnummer Ändringen placeras on hold i den aktuella noden (om felsäkerhet önskas) 4. Ändringen skickas ut i nätverket och alla noder genomför ändringen Önskas en mer felsäker hantering så kan man tänka sig två ytterligare steg 5. Alla noder som mottagit och genomfört ändringen skickar ett svarsmeddelande till ursprungsnoden innehållandes det nya versionsnumret. 6. När alla noder svarat med det nya versionsnumret så fastställs ändringen i den initierande noden. Ytterligare felsäkerhet kan åstadkommas genom att sända dit en ytterligare nod för att dubbelkolla vad som föreslås. Databasen (kartan) skall för varje kartruta innehålla information om rutans status, d.v.s om den är outforskad, utforskad, reserverad eller bearbetas. Annan information som den skall innehålla är vilken nod som finns där för tillfället, om den innehåller en vägg, om skatten finns där o.s.v. Informationen om vilken nod som finns i rutan används för att undvika att två noder genomsöker samma ruta samtidigt. 4

5 Sökstrategi Vi kommer att använda oss av en variant på frontier-algoritmen. Våran version kommer att innehålla ett reserveringssystem för rutor, detta kommer att hjälpa i nodernas planering för att veta vilken nästa ruta är som skall genomsökas. Själva frontier-algoritmen bygger på att alla noderna kommer att arbeta gemensamt mot en gräns som skär det redan kända området mot det outforskade. Genom att flytta gränsen framåt så utforskar noderna nya delar av området. De kommer att välja nästa ruta genom att prioritera den närmsta gränsen till den nuvarande rutan. Då den valt ruta kommer den att reserveras tills noden har tagit sig till rutan och sökt igenom den, efter den sökt igenom rutan kommer den att rapportera in den som klar med eventuella hinder. Detta kommer att stoppa noder från att ta samma ruta som någon annan, vilket medför att endast tomma rutor i våran gräns kommer att genomsökas. Fördelarna med frontier är att den är väldigt effektiv och kan söka sig fram på en karta i ett stadigt tempo. Eftersom vi har trådlös kommunikation över hela kartan kommer vi alltid få information från alla noderna, vart vi än befinner oss på kartan, detta kommer leda till en exakt bild för varje nod utan någon dödtid. Nackdelarna är avancerad uträkning och att många paket kommer att sändas över nätverket. När skatten har allokerats och verifierats så kommer alla noder att avbryta sin sökning och ta the least-cost path till noden som hittat skatten och samlas där. Den sträckan kommer att räknas ut med hjälp av Dijkstras algoritm som är en algoritm byggd för att räkna ut den kortaste vägen. Beslutssystem och felkontroll För att komma fram till gemensamma beslut i ett helt decentraliserat system, så som: En nod har hittat skatten. Ska gruppen godkänna detta från en nod? En ny nod förfrågar en identifiering Är alla medvetna om denna nya nod? Godkänner vi en ny medlem? Om felaktiga data upptäcks Ska en felsökning ske? Är tillräckligt många överens om att data är felaktigt överhuvudtaget? I ett helt decentraliserat system anser vi att någon eller några former av beslutssystem är behövliga. Vi föreslår användning av en av de algoritmer vi studerat tidigare. Förslagsvis en konsensusalgoritm med bysantinsk felkontroll, tillhörande Paxos-familjen. En nackdel med det tillvägagångssättet är som vi tidigare har sett, är att både Paxos och bysantinska algoritmer är meddelandeintensiva och sårbara om ID-hanteringen inte skulle vara tillförlitlig. Vi påminner att med stöd av begränsningarna, förutsätter vi att man-in-themiddle attacker inte förekommer. Samt friheter med kommunikationstekniken CANbus LAN. Därmed förenklas problemställningen med Identifikation och meddelandehantering 5

6 något. Däremot begränsar vi användning av konsensus till de fall då vi håller för sannolikt att det kan spara mycket tid eller resurser. En nod har hittat skatten Då en nod rapporterar att den hittat skatten finns det anledning, särkilt om noderna har långa avstånd ifrån varandra, att först besluta om den informationen är sanningsenlig med en mindre grupp. Det kan då vara lämpligt att finna konsensus med en bysantinsk felmarginal enligt n>3f+1. Med andra ord skicka tillräckligt många noder initialt för att nå samstämmighet då vi har n noder. Vinsten blir att vi har en bevisad felkontroll trots att vi inte behöver skicka samtliga noder. Samt att om noden rapporterar fel vinsten att precis nödvändigt många måste ta sig till skatt koordinaten. Om felaktiga data upptäcks Om felaktiga data upptäcks finns det stora skäl att först undersöka om det verkligen är data som inte stämmer. Det kan vara noden som rapporterar en konflikt som själv är trasig och bidrar med en konflikt som inte finns. Vi tror att den vanligaste orsaken till oklarheter kan uppstå då kartor inte är synkroniserade med varandra och man får en konflikt av data. Att besluta vem som är rätt synkroniserad kan då vara svårt att bestämma. (vems kopia av helheten är egentligen rätt). Regelbundna Felkontroller För att tidigare upptäcka synkroniseringsfel tänker vi oss regelbundna kontroller av checksumma eller motsvarande. Tanken är att när en nod har samlat på sig tillräckligt mycket data, förfrågar den gruppen om det kan vara lämpligt att göra en checksumma på samtliga kartors data. Tanken är att upptäcka stora fel i ett tidigare stadium och kanske utesluta trasiga noder. Eftersom en checksumma är en krävande körning tänker vi oss en trestegs plan. Första steget skulle vara att jämföra data med övriga noder på t.ex: Storlek på databas i bytes Antal utforskade rutor Eller en kombination av andra tänkbara data som inte ska skilja sig nämnvärt. Om data skiljer sig nämnvärt så kan det vara värt att göra en mer CPU-intensiv checksumma för alla noders databas. Man kan då utesluta felkällor. För att det ska fungera måste samtliga noder komma till konsensus att inte skriva till databaser. Allt arbete med skrivning till databas måste upphöra samtidigt. Vi måste kunna garantera mutual exclusion på access till databasen. En deadline för när det ska ske måste även garanteras. Realtidsaspekter & Lastbalansering Vi använder oss av deadlines när vi låser databasen för att undersöka att denna är identisk hos alla noder. Eftersom systemet inte har några delade resurser så har vi inga moment där vi behöver balansera arbetsbördan. 6

7 Kommunikationskomplexitet Systemet nyttjar en hög grad av utbyte av meddelanden. När databasen uppdateras så gör vi en broadcast, när vi använder oss av byzantine algorithm så sker ett intensivt utbyte av meddelanden. Slutsatser & kommentarer Vi har dragit upp riktlinjerna för ett system som är helt decentraliserat. Noder fattar beslut i grupp och alla har en identisk bild av området. Centrala algoritmer är Paxos-Byzantine (för konsensus), Dijkstra (för att hitta optimal väg till målet) och frontier-algoritmen för sökstrategin. 7