Inledning För att koordinera enheter mot ett gemensamt mål krävs ett effektivt system för att förmedla information. Man strävar ofta efter att varje enhet ska ha den information som krävs för att enheten ska utföra de handlingar som leder till att hela systemet löser problemet så effektivt som möjligt. Det finns ett antal system som bygger på olika teorier om på vilket sätt informationen i systemet ska hanteras för att lösa problem. Vanligtvis delar man in koordinerande modeller i två typer, Centraliserade eller Distribuerade, som jag kommer att återkomma till. Den modell som jag har valt att presentera här heter PIM (Process Integrated Mecanism) och kan ses som ett tredje och relativt nytt sätt att se på hur man kan koordinera enheter. Modellen blir intressant eftersom den utgår från teori från både centraliserade och distribuerade system och har karaktär från dem båda. Genom att kombinerar och utnyttja det bästa från båda systemen har man försökt kapa en modell som har en mindre komplex och mer stabil arkitektur. PIM är alltså varken en centraliserad eller distribuerad arkitektur. Det beror på det inte finns någon central enhet som har övergripande och fullständig kontroll vilket centraliserade modeller har. Det sker inte heller någon individuell förhandling mellan enheterna på det sätt som teorier om distribuerade modeller bygger på. PIM har istället en koordinerande process (Coordinating process, CP) som förflyttar sig mellan enheterna och bidrar till att skapa ett system av självständiga noder med individuella processer som utgör delarna av en helhet, trots att alla noder är separerade från varandra. Jag kommer att ge en övergripande redogörelse om Centraliserade och distribuerade modeller för att visa på vad som skiljer PIM från dem. Jag kommer att fokusera mer på att beskriva teorin bakom PIM och hur arkitekturen som bygger på teorin är konstruerad. I PIM har den koordinerande processen (CP) en central och betydande i många av de övriga processerna och kommer att återkomma i hela beskrivning av PIM. Hur man i PIM har löst probelmet med att minska komplexiteten och öka stabilitet framkommer i styckena om Flyttbara och Residenta och där är CP, PIM Objekt, PIM Runtime och Node Monitor viktiga processer. 1/16
Varför finns det ett behov av PIM? Centraliserade och Distribuerade modeller Centraliserade modeller har en hierarkisk struktur med en enhet som har övergripande kontroll på all information för alla agenter, den styr och fördelar handlingar och information till de övriga enheterna. I ett Distribuerat system finns ingen hierarki och kommunikation sker istället individuellt mellan agenterna. Agenterna förhandlar om handlingar om vad som ska göras och av vem. Båda dessa modeller bygger på teorier med problem som det finns anledning att försöka lösa För de Centraliserade arkitekturerna är det framförallt instabiliteten som försvagar och som direkt medför problem. Det uppstår då enheten som har övergripande kontroll begår misstag eller slutar fungera. Distribuerade arkitekturerna har problemet att de snabbt blir en hög komplexitet i algoritmen för förhandlingarna, vilket gör dem svåra att programmera och hantera. Teorin bakom PIM modellen Målet med PIM är att skapa en koordineringsmodell för Komponenter/Noder som ska samarbeta med syftet att uppnå en modell vars arkitektur har en låg komplexitet och hög flexibilitet. Den koordinerande processen I PIM har man behållit tanken med ett centraliserat system med en central process som koordinerande enhet men man har valt att inte placerat processen i en specifik nod i systemet. Teorin för PIM bygger på att man går ifrån tanken om att den koordinerande processen ska väntar på att få information skickad till sig från dom understående enheterna. Istället är tanken att den koordinerande processen besöker enheterna och utför processen under besöket. Man kommer att slippa skicka stora mängder data till processen om man istället har en liten process som man flyttar till data. CP har rollen som den intelligenta delen som bearbetar och fattar beslut om vilka handlingar som ska utföras och noderna utför handlingarna som beordras av CP 2/16
Tanken i ett PIM är en kontinuerlig förflyttning av CP som ska cirkulera kontinuerligt och besöka noderna och urföra sin process. Varje besök hos en komponent tar en viss tid, Residency Time, som är tiden det tar då den koordinerande processen ska ge order om vad komponenten ska utföra för handlingar. Längden på Residency Time blir avgörande för huruvida systemet kan koordinera alla komponenters handlingar så att de sker på ett tillfredställande sätt för systemet. I en dynamisk värld med snabba förändringar skulle en för lång Residency Time medföra att CP inte hinner ge order om handlingar till komponenter och systemet inte hinner med att utför de handlingar i takt med vad som krävs. Figur 1:CPs cykel över noderna i ett PIM En nod är ingen agent Som nämts tidigare kan PIM till viss del ses som en modell av distribuerad karaktär. Det är dock viktigt att tydliggöra att en komponent i PIM inte är någon form av autonom agent med som har möjlighet att handla utifrån ett High-level perspektiv. Det sker alltså ingen individuell förhandling mellan komponenterna i PIM på det sätt som agenter i mer traditionella distribuerade modeller gör. En komponent har inte något övergripande perspektiv över samarbetet dem emellan, vilket medför att processer som kräver ett sådant inte kommer att kunna utföras av komponenten på egen hand. 3/16
En komponent i PIM har ändå möjligheten att utföra s.k. Lokala processer och kan ha en mängd olika lokal processer på olika komplexitetsnivåer. Men de lokala processer sker lokalt och kräver inte någon koordinering med processer för andra komponenter. Pianoexemplet Exemplet har som syfte att tydliggöra iden bakom ett PIM och hur CP koordinerar noder utan att noderna i sig är agenter som kan förhandla med varandra. Det går ut på att man har ett PIM beståendes av två robotar, R1 och R2, som ska lyfta ett piano. Varje robot är försedd med en sensor, H, som ger information om den absoluta höjden, som den lyft pianot, och handlingen, Adjust arm, som justerar höjden genom att höja eller sänka inom ett visst intervall. Det finns en viss osäkerhet i hur mycket robotarna lyfter, så höjden måste hela tiden kontrolleras. Målet är att de två robotarna ska lyfta pianot balanserat. Figur 2: Två robotar som lyfter ett piano Ett visst värde e för hur stor skillnaden i höjd får vara begränsar hur högt en robot kan lyfta pianot utan att det kompenseras. Om värdet överskrids kan den robot som ligger högre sänka lite, annars så höjer den robot som befinner sig lägre. if R1:H R2H >e Then R2:Adjust-Arm(R1:H R2:H) Else R1:Adjust-Arm(R2) Eftersom de endast finns två robotar kommer exemplet bestå av ett PIM med två noder där CP utför en process på robotarna växelvis. Utan någon ytterligare information än den som ges 4/16
från sensorn i på roboten kommer CP växelvis justera höjden genom att förflytta sig mellan och koordinera robotarna. En koordination kommer att styra robotarna när de lyfter pianot så att det framstår som att det finns en kommunikation mellan dem trots att så inte är fallet. Det finns inget individuellt mål eller behov för någon av robotarna som de behöver förhandla med den andra om. Robotarna kommer alltså att agera som delarna av en enhet. PIMs arkitektur För att på ett bra sätt beskriva PIMs arkitektur är det lämpligt att återgå till behovet av en modell som är stabil och mindre komplex. PIM består av två delar PIMs arkitektur kan beskrivas som två delar som består av en flyttbar del Movable part och en mer stationära del som kallas Resident part. Tillsammans bidrar de till PIMs förmåga att både vara stabil och mindre komplex. Figur 3: PIMs övergripande arkitektur 5/16
Den flyttbara delen utgörs av CP och en Global översikt och ger PIM karaktären av ett centraliserat system med en styrande enhet som har fullständig överblick och kontroll över samtliga komponenterna. Fördelen blir att man kan programmera den koordinerande algoritmen utifrån ett centraliserat perspektiv och att man på så vis undviker komplexitetsnivåerna som ett distribuerat perspektiv ofta leder till. Det är på så sätt som man reducerar komplexitetsnivån hos PIM och samtidigt skapar en illusion av att PIM är en centraliserad modell. I den flyttbara delen i PIMs arkitektur hittar man alltså lösningen som gör att modellen får en relativt låg komplexitetsnivå. Utmaningen med att lösa problemet med instabilitet som centraliserade modeller har svårt att hantera återstår dock. Lösningen ligger i att PIM endast skapar en illusion av att vara ett centraliserat system och problem med instabilitet kommer därför inte nödvändigtvis behöva uppstå på samma sätt. PIM har ju som sagt även tagit karaktär av distribuerade modeller och eftersom CP är distribuerat över alla noderna i ett PIM kommer en kopia av CP vara sparade på alla noderna som går att återuppta om en nod går sönder. Hur man hanterar trasiga noder kommer jag att återkomma till. I ett PIM kommer Movable part att vara dynamiskt förflyttad under särskilda intervall medan Resident part alltid är tillgänglig och aktiv på varje nod. Movable part är aktiv på en nod när CP befinner sig där i sin cykel. Resident part har processer som kräver att den är aktiv konstant. Resident part är ansvarig för processerena Runtime system och Node Monitor samt alla lokala processer för varje enskild nod. Generellt kan man säga att Runtime System sköter värkställningen av CP på en nod och Node Monitor upptäcker och reparerar fel som uppstår. Ramverket Mobile JikesRVM I försök att testa PIM i praktiken har man valt att använda sig av en Java baserad plattform som heter Mobile JikesRVM. Jag kommer inte att redogöra för hur Mobile JikesRVM fungerar på djupare nivå men jag tror att det kan vara bra att nämna det viktigaste i relation till CP. Mobile JikesRVM utnyttjar något som kallas Strong mobility som innebär att det blir möjligt för en process att behålla och ta med sig föregående komponents state under 6/16
förflyttningen av CP till nästa komponent. Det är precis vad som krävs för att CP ska kunna skapa ett globalt perspektiv utifrån de övriga noderna och därför blir det lämpligt att använda Mobile JikesRVM som ramverk. För den programmerare som ska skapa ett PIM är det också praktiskt när det går att använda Java threading modellen, som bygger på samma teori som Strong mobility för att skriva den koordinerande algoritmen. Flyttbara Delen CP och PIM-objekt CP ingår i Movable part tillsammans med det man kallar en Golobal översikt, där CP är ett objekt i Mobile JikesRVM. Under CPs cykel över noderna i ett PIM följer alltid ett objekt med som kallas PIM object. Det är via PIM object som CP interagerar med en nod och PIM object har övergripande perspektivet för koordineringen i ett PIM. PIM object och skapas inledningsvis under uppstarten av ett PIM och är den del som ger PIM karaktären av ett centraliserat system med en styrande enhet. Den globala översikten Det är PIM objects övergripande perspektiv som gör det möjligt för komponenterna i ett PIM att koordineras så att de uppfyller iden om att utgöra delarna av en helhet. För skapa ett övergirpande perspektiv tilldelas CP en unified logical view av PIM object i form av egenskaper om nodernas nummer och typer, fullständig tillgång till tillståndet för varje nod och High-level control över förflyttningsprocessen. Med ett sådant perspektiv blir det möjligt att koordinera logiska noderna på ett mer abstrakt plan för att därefter placeras dynamiskt på fysiska noder. Fysiska noder är objekt i form av robotar och liknade fysiska maskiner som ska koordineras. Man skapar alltså en dynamisk bindning mellan en logisk nod och en fysisk nod. Bindningen sparas i form av ett individuellt ID-nummer numeric unique identifier (UUID) som används för att kunna byta ut fysiska noder mot noder med samma egenskaper. 7/16
Fördelen dynamisk lösning är att det blir möjligt att definiera vilka fysiska noder som en logisk nod ska kunna upprätta en bindning med. Resultatet blir att systemet har en flexibilitet där de egenskaper som fysiska noder har blir det avgörande för bindningen och inte den fysiska noden i sig. Beroende på vilka behov som finns kommer det att bli möjligt att ta bort och lägga till fysiska noder efter behov och på ett smidigt sätt. Koordineringen av noder Koordineringen av noderna görs för att lösa ett problem på bästa möjliga sätt, utifrån de tillgångar som finns. I vissa fall kan det finnas flera noder av samma typ som kan utföra samma typ av uppgifter och det kan finnas anledning att kunna välja mellan dessa. Tex. om de befinner sig på olika platser kan det vara fördelaktigare att bryta en bindning med en nod och binda den till en annan som befinner sig på lämpligare plats. En nods egenskaper och förmågor är möjliga för CP att se på grund av att alla noder presenterar och gör sina förmågor synliga utåt. Det är utnyttjas av CP för att avgöra vilken nod som är lämplig för ett visst ändamål och på så sätt kan noderna väljas. Med information om en nodernas typ och den översiktliga informationen som ges av PIM objekt, kan CP välja ut och skapa en Logical Topology, som består av de noder som finns tillgängliga. Här har Dynamiken i bindningen en viktig roll då det blir möjligt för den koordinerande algoritmen i CP att styra topologin genom att ta bort och lägga till noder efter behov. Det blir alltså möjligt att koordinera noderna utifrån en policy för de egenskaper och förmågor som finns eftersom det endast är möjligt att binda samma typ av logisk nod till motsvarande fysiska nod. Figur 4 visar hur logiska noder binder till motsvarande fysiska nod och att varje bindning har ett UUID som lagras i den fysiska noden. 8/16
Figur 4: Logiska noder binder till Fysiska noder av samma typ. Utvecklarna av PIM ger följande exempel: Andra policys kan skapa ytterligare kriterier för fysiska noder, tex. kvalitén på informationslänken för att nå roboten. Det medför att man kan uppnå en optimal styrning av alla tillgängliga resurser genom att skapa ett schema för vilka policys som ska gälla under en körning av PIM runtime. Det behöver alltså inte bara vara en nods egenskaper som värderas utan möjligheten att välja nod efter andra kriterier finns också. Man skulle kunna tänka sig att det finns ett antal noder med samma egenskaper men som är utspridda. En simpel heuristik skulle kunna innebära att det ska upprättas en bindning mellan en logisk nod och den fysiska nod som har högst kvalitet på informationslänken. Då en hög kvalitet skulle kunna innebära att den fysiska noden har lägst sannolikhet att förlora kontakten. Den koordinerande algoritmen kan även resonera och gör bedömningar av den senaste globala överblicken som ges. Det blir möjligt på grund av en särskild caching mechanism som lagrar och tillåter att en fördröjd process utföras transparent mot CP. När CP förflyttar sig snabbt mellan noderna får den information om den fysiska nodens tillstånd från en kopia som 9/16
är lagras av den motsvarande logiska noden. Kopian kan då jämföras med den nya och ett resonemang av själva överblicken kan göras. Residenta delen Den resistenta delen av PIM är ansvarig för att: Underlätta den snabba och kontinuerliga förflyttningen av CP över noderna. Upptäcka fel i noder och återställa CP för att behålla koordineringsalgoritmen hel och stabil. I PIM har man valt att tilldela dessa två ansvarsområden på två olika processer PIM Runtime och PIM monitor. Uppdelningen görs för att man vill kunna utföra den snabba förflyttningen av CP utan att den ska bli påverkad av om det finns noder i systemet som är trasiga eller okontaktbara. Parallellt med PIM Runtime körs PIM monitor vars uppgift att upptäcka och reparera trasiga noder. PIM Runtime PIM Runtime ansvara alltså för den grundläggande livscykel för en nod vilket består av följande steg. 1.Öppna och lyssnar efter inkommande sändningar från CP från andra lagmedlemmar i PIM. 2. När det upprättats en koppling med den sändande noden läses hela tillståndet från CP 3. Avserialiser tillståndet som ges av CP så att den kan fortsätta från den senaste instruktionen som utfördes på den tidigare noden. 4. Updatera det lagrade tillståndet på Node objekt i PIM 5. Låt CP köra under ett tidsintervall som är bestämd av residencytime för noden. 6.Sätt en kontrollpunkt för CP och spara en kopia av den, om ett fel skulle uppstå. 7. Skicka tillståndet för CP till nästa nod i den Logiska topologin. Efter en lyckad överföring, kommer PIM runtime stänga och återigen börja lyssna efter inkommande sändningar och därmed sker en omstart av förflyttningscykeln. Lite mer förklaring till några av de viktigare stegen i PIM Runtime: 10/16
[1] Noden väntar på att CP ska komma och utföra sin process på den genom att lyssna efter signaler från andra noder. Någon form av tidsintervall går att sätta för hur länge en nos ska lyssna, på så sätt kan den upptäcka om noden där CP befinner sig har gått sönder. [3] Avserialiseringen görs för att Mobile JikesRVM ska kunna utnytjas [4] Beroende på vilka lokala processer som en nod har sätts olika tidsintervall för Residencytime. Node Monitor Ansvaret för att upptäcka och reparera trasiga noder ligger på processen Node monitor. Node monitor sköter den dynamiska bindningen mellan logiska och fysiska noder och har en egen överblick över alla noder i systemet. Överblicken gör det möjligt att upptäcka noder som inte utför de handlingar som är tänkt. Varje nod har en distribuerad funktion så att nya noder kan upptäckas och kommunicera med varandra, men som sagt ingen förhandling. Noder av samma typ kan gruppera sig och hanteras av en särskild Group Manager som ger varje nod sitt UUID. När en ny fysisk nod upptäcks av de andra noderna kommer noden i systemet som för tillfället utför CP att försöka binda den fysiska noden till en logisk nod. Trasiga noder Problemet med noder som dör eller försvinner och som redan har en etablerad bindning i systemet ska NodeMonitor försöka lösa. Genom att söka i en grupp som består av noder av den önskade typen ska NodeMonitor återupprätta bindningen mellan den logiska noden och en fysisk nod av den typen. Finns det ingen så återupptas samma process när det uppstår ett behov av noden. När en trasig nod upptäcks kommer Node Monitor att upphäva bindningen till den noden vilket PIM Runtime kommer att märka när CPs cykel når den trasiga noden. Node Monitor kommer att försöka binda den logiska noden till en annan fysisk nod med samma egenskaper. Den trasiga noden lämnas utanför och ett PIM kan på sås sätt hantera problemet med trasiga noder på ett relativt smidigt sätt och undvika större avbrott i processerna. 11/16
Figur 5: Fel på en nod där CP inte befinner sig Om CPs cykel blir störd på grund av att noden där CP befinner sig går sönder, kommer de andra noderna märka att det inte sker någon förflyttning då CP inte kommer till dem. Problemet har man löst genom att en kopia av CP sparas på noden varje gång CP har varit på besökt. Node Monitor startar en process på varje nod för att jämför de olika nodernas kopior av CP. Den senast Kopian av CP väljs ut och placeras på en nod så att cykeln över noderna kan fortsätta. Figur 6: Fel på en nod som CP befinner sig på De Centraliserade modellerna får problem när det uppstår fel i den nod som har ansvarar för koordineringen av de andra. Men ett PIM kan alltså behålla karaktären av ett centraliserat system fast med en ökad stabilitet eftersom CP inte är beroende av en specifik nod. Den viktiga skillnaden är alltså att CP kan fortsätta sin cykel utan störning och fungera som en central process trots att fel uppstår i noden där processen befinner sig. 12/16
Valla får- Exempel på koordinering Exemplet nedan från (PIM [Ford 2010]) visar på hur ett PIM kan koordinera noder från sensordata med hjälp av CP. Det visar att komplexiteten för den koordinerande algoritmen i CP inte behöver bli så komplex trots relativt höga krav på koordinering. Det finns tre fysiska noder som likt Pianoexemplet inte utför någon individuell förhandlig för att uppnå målet. All koordinering sker utifrån den algoritm som anges i CP. Exemplet går ut på att tre fordon med olika egenskaper sak smala ihop ett antal får. Förutom fåren består världen endast av de tre fordonen samt två föremål, stenar och katter. Fordonen kan vara av typen Utkik, Spårare och Herde. Utkiken rör sig på marken och har sensorer som kan se former på 30m avstånd. En Utkik kan inte skilja mellan djur och stenar, men kan skilja på om det är ett stort föremål (sten eller får) eller ett litet föremål (sten eller katt). Spåren är ett flygande fordon som kan sensorer som kan skilja mellan djur eller stenar, men kan inte skilja mellan katter och får. Herden är ett markfordon och har både Utkikens och Spårarens sensorer men de har en begränsad räckvidd. Figur 7: (A) Objektens placeringg i världen initialt. (B) Objektens placering närmålet uppnåts. Utkik Spårare Herde Symbol U S H Typ Markfordon Flyg Markfordon Form & Sensor Former Värme Värme 13/16
Sensor avstånd 40m 60m 20m Hastighet 4 m/s 230 m/s 10 m/s Figur 8: Fordonens egenskaper Får Katt Sten Symbol F K S Temperatur Markfordon Flyg Markfordon Strolek Former Värme Form & Värme Figur 9: Föremål i världen Världen är konstruerad så fordonen har tillgång till positionen för föremålen är kända och målet för fordonen är att samla och behålla fåren i mitten. Utkiken och spårarna följer en fördefinierad väg i sitt sökande som har angetts i koordinerings processens kod. Med den informationen skapas en värld med objekt och där närvaron av ett får kan ges av (Får, Får-form, varmt objekt, inget). En ny observation består av kännetecken, dess koordinat och tiden för observationen. Varje ny observation kan användas för att uppdatera den globala översikten genom att utnyttja informationen från Figur 9. Ny observation på (x, y) Gammalt värde Uppdaterat världe Inget Något Inget Varm Får-form Får Varm Får Får Varm Varm eller inget Varm Får-form Varm Får Får-form Får Får Får-form Får-form eller inget Får-form Får Något Får Figur 10: Uppdatering av världens tillstånd 14/16
Algoritmen för CP skulle därför kunna vara: Loop När observation (f, x, y) levereras, Uppdatera global översikts värde för Position (x, y) utifrån Figur 9 Exemplet visar på hur den globala översikten uppstår genom att CP rör sig över noderna i ett PIM och bär med sig information om tillståndet som ges av sensorerna. Algoritmen i CP kan uppdatera det globala perspektivet utifrån att den vet vilken information som ges och koordinera noderna därefter. Diskussion Jag tycker att PIM blir intressant just på grund av hur man använder sig av teorierna för Centraliserade och Distribuerade system för att lösa varandras problem. Enkelheten i arkitekturen är också tilltalande och känns genomtänkt på ett sätt som göra att jag tror att det finns möjligheter att utveckla den vidare. Just dom enkla lösningarna känns som ett av PIMs styrkor för att kunna konkurrera med andra modeller. Sättet att skapa Illusionen, som får PIM att inte bara framstår som ett Centraliserat system utan också kunna tillgodose sig fördelarna med det, samtidigt som man samtidigt undviker nackdelarna, är riktigt smart. Även sättet att lösa trasiga noder känns genomtänkt och som en lösning som verkligen fungerar i längden. Det är svårt att riktigt veta hur pass väl PIM står sig mot andra typer av system då jag inte kunde hitta så många exempel där man jämfört. Jag tycker att det ska bli intressant att se vad PIM får för inverkan på utvecklingen av koordinerande modeller generellt för till viss del framstår PIM som en syntes av teser. 15/16
Referenser Kennet M. Ford, James Allen, Niranjan Suri, Patric J hayes och Robert A. Morris PIM: A Novel Architecture for Coordinating Behavior of Distributed Systems 2010 Raffaele Quitadamo, Giacomo Cabri, Letizia Leonardi Mobile JikesRVM: A framework to support transparent Java thread migration 2007 Raffaele Quitadamo, Danilo Ansaloni, Niranjan Suri, Kenneth M. Ford, James Allen, Giacomo Cabri The PIM: an Innovative Robot Coordination Model based on Java Thread Migration 16/16