I projektet flaggskeppet har RISE och Haparanda kommun tillsammans med projektets övriga partners utforkskat hur vi använder digitala tvillingar i framtidens äldrebodende (SÄBO). Projektet har utgått från ett äldreboendet Hemstranden i Haparanda. Projektet är ett IOT sverige projekt.
I arbetet har vi tillämpat en prototypdriven designprocess där vi parallellt jobbar med att inventera tillgänglig data och behov och definiera innehållet i den digitala tvillingen enligt en modell med sex steg. Läs mer om den här.
Resultaten som redovisas under de olika stegen nedan är en sammanfattning av de resultat som framkommit under flera iterationer mellan de olika stegen.
En demo video över prototypen kan ses här
Steg 1: Problemdefinition / behovsinventering
Äldreboendet Hemstranden i Haparanda är ett alldeles nybyggt vård- och omsorgsboende som invigdes i februari 2023. Boendet består av 80 lägenheter på omkring 35 kvadratmeter. 10% av lägenheterna är byggda för parboende. Boendet har 3 våningar med två avdelningar på plan 1 och tre avdelningar på resterande våningar. Dessa är namngivna med 1A, 1B, 2A, 2B,2C osv. På första våningen finns i stället för den tredje avdelningen i stället kontor, café och omklädningsrum.
Aktörer
Själva byggnaden ägs och förvaltas av Riksbyggen medan Haparanda kommun står för själva verksamheten. Lösningen med larm osv står 9solutions för ett Finskt it-bolag som specialiserar sig på vårdlösningar.
Kommunens mål är naturligtvis att kunna ge en kostnadseffektiv och bra omsorg till de boende. En av de större problemen men tampas med är personalförsörjningen. Ett annat är kommunikation då många av de som jobbar inom personal styrkan har utländsk bakgrund. Som resten av västvärlden så brottas man ju också med en ökad andel äldre i samhället. Man vill gärna bygga en förståelse för hur de ska kunna vara framsynta när man bygger nytt och strukturerar verksamheten.
Riksbyggen mål är att bli en attraktiv partner för kommunerna genom så kallade kooperativa hyresrätter. Det beskriver det själva som: "Med kooperativ hyresrätt kan kommuner säkerställa kvaliteten och långsiktigheten i sin vårdverksamhet och boenden för äldre utan att kostnaderna för fastighetsinvesteringar skenar. Konceptet är bra för de kommuner som vill ha ett alternativ till traditionellt, kommunalt fastighetsförvaltande, men samtidigt möta ett ökande vård- och omsorgsbehov – allt detta utan att använda kommunala medel."
Riksbyggens har i rollen som både byggaktör och fastighetsförvaltaren målet att vara en aktörer som är med lite längre. Som förvaltare har man naturligtvis olika miljö och effektivitetsmål.
9solutions affärside är att med etablerad standardteknik (tex bluetooth) skapa kostnadseffektiva vårdlösningar. Men vill naturligtvis skapa så mycket värde som det går med den data som man samlar in. Som många bolag i deras situation så brottas man med att skapa värden själv genom nya tjänster och att öppna upp för kunderna i det här fallet kommunen att kunna få ta del av sin data.
Roller
Det finns flera olika roller hos de olika aktörerna. Hos Haparanda finns verksamhetsplanerare, vårdbiträden, undersköterskor, sjuksköterskor osv. Vi har också de boende och deras anhöriga. Hos riksbyggen har vi fastighetsförvaltare som sköter om byggnaden och kundtjänst personal som tar emot de olika anmälningarna ifrån verksamheten.
Behov
Utformning av boendet: Ett tydligt behov gällande en digital tvilling är att kunna förstå hur boendets utformning kommer att påverka verksamheten. Här inkluderas saker som möblering av lokalerna samt simulering av flöden och tekniska system.
Samordning i vardagen eller under en kris: De behov som finns inom Hemstrandens personal kan man säga faller inom två kategorier. Den ena av dessa är dagliga behov som finns mer eller hela tiden dvs överlämning mellan personal i olika pass och kommunikation mellan olika roller så som vårdbidräden och undersköterskor och verksamhetsplannerare, mellan de olika avdelningarna eller vid felanmälan av någon del av fastigheten till tex Riksbyggen. Den andra kategorien är behov som uppstår under extremsituationer tex brand, pandemi, vinterkräksjuka, akut personalbrist eller liknande.
Verktyg för planering eller för någon på språng: En annan kategoriindelning är planering och utbildning då man använder verktyget mera fokuserat för att simulera olika händelser eller bara för att få en översikt över verksamheten och daglig användning där man löpande skulle använda verktyget. Vi kan benämna dessa två fall fokuserad interaktion respektive flyktig/"på språng" interaktion. I det flyktiga interaktionen är det väldigt viktigt att verktyget inte hindrar personalen i sitt jobb. Idag används ofta lappar eller kalendrar på en central plats på avdelningen. Detta sätt att notera ner saker som man behöver komma ihåg går snabbt och är enkelt men har nackdelen att det ibland försvinner lappar som råkar hänga med hem i fickan eller att informationen bara är åtkomlig lokalt. I planerings/utbildnings sammanhang kan man tänka ett något mera komplicerat verktyg med fler funktioner för att visualisera olika scenarion osv. det är då en person som designar dessa scenarion i verktygen och visar för de övriga för att bättre förstå vad man tex ska ta göra vid en brandutrymning, vinterkräksjuka osv.
Steg 2: Data inventering
Data finns både hos kommunen i form av personal och boende planering, 9 solutions i form av larm och positioner på de olika blåtandsenheterna, nattkameror och talboxar samt hos Riksbyggen i form av byggnadsinformation så som BIM ritningar, data gällande värme och ventilationssystem och felanmälningar. I det aktuella projektet fanns ingen individuell mätning och styrning av värmen i lägenheterna. Vi kompletterade därför med ytterligare sensorer som mätte temperatur och fuktighet i ett utvalt antal lägenheter.
Integrerade system: I från vårdpersonalen finns en tydlig önskan om att inte få ytterligare ett system som man ska lära sig och i värsta fall ett parallellt system där man ska fylla in information som man redan fyller i, i ett annat system. Man tar också upp att det ofta finns språkförbistringar. Många som jobbar på äldreboendet har utlänskbakgrund och även om de kanske tala bra svenska är de inte alltid bra på att skriva på svenska. Alternativa medium som möjlighet att spela in ett röstmeddelande eller bara ta en bild för att komma igång någonting skulle därför kunna göra verktyget mera användbart. Man kan också tänka sig lösningar där man för samman digitala och analoga ytor tex kameror som fångar en whiteboard tavla eller liknade. Det finns idag flera olika system för att styra behörighet till olika lås i fastigheten den digitala tvillingen skulle här kunna utgöra ett gemensamt gränssnitt för att komma åt alla dessa lås för den som har behörighet. Idag var man tvungen att endera fysiskt gå till en viss dator eller använda fjärråtkomst till den datorn för att lägga in nya användare. Felanmälan till Riksbyggen görs också via en webbsida hos Riksbyggen där man måste har inloggningsuppgifter. Även denna dels skulle kunna integreras i den digitala tvillingen. Både 9 solutions och Riksbyggen har olika APIer för att komma åt data. Hos 9 solutions verkar det dock behövas olika API:er för larmen respektive för talboxar och videokameror. Hos Riksbyggen finns åtminstone 5 olika API:er som skulle behövas integreras mot.
Beslutshjälp: Det kom fram flera exempel på situationer där olika nyckeltal skulle kunna vara användbart ett sådant var temperaturvariationen i rummet. En vanlig händelse är att de boende säger att de fryser. Personalen tar då på dem ylle sockar eller ger dem en filt samtidigt som de försöker avgöra om personen kanske är sjuk eller om rummet är kallt och behöver felanmälas. Ett exempel togs därför fram där lägenheten hade ett nyckeltal som visade temperaturen i lägenheten över olika perioder (Se bild nedan).
Kvalitetssäkring: Ett annat nyckeltal som presenterades som exempel var hur många gånger som en boende larmat eller hur ofta vårdpersonalen vistas i en viss lägenhet. I den boendes vy presenterades också nyckeltal som hur mycket tid ute som en person vistas, när personen senast duschat osv. Denna data skulle kunna fås eftersom både personal och boende har en blåtandsenhet som kan positioneras grovt. Informations om duschar kan fås från temperatur- och fuktsensorer som placeras i dusch utrymmet. Personalen såg här särskild en användning av denna data när man pratade med anhöriga som utryckte oro över om den boende fick sina behov tillgodosedda. Det återstår att i faktiska användartester utvärdera i vilka situationer man faktiskt skulle komma ihåg att använda liknande information. Man så gärna att personens omorgsplan fanns kopplat till den boendes vy. Nedan finns ett förslag på hur detta skulle kunna se ut. Genom att kombinera en rubrik med ikoner ökas förståelsen även för de som har begränsad läsförståelse på svenska.
Steg 3: Entitets inventering
Inom mjukvarudesgin jobbar man inte sällan efter en objekt orienterad modell där man utgår ifrån objekten snarare än logik och funktioner. Ett objekt är beskrivs av en samplig egenskaper dvs ett egenskaps namn kopplat till ett värde. För en person kan det tex vara:
| Namn | Sigrid Larsson |
|---|---|
| Ålder | 83 |
Eftersom vi ofta inte benämner en person för ett objekt och desutom också gärna inkluderar aktiviteter i digitala tvillingar så är ordet entitet ofta bättre att använda utanför data området. En del av jobbet med den digitala tvillingen är att identifiera alla entiteter som ska vara representerade i systemet.
Följande entiteter identifierades som viktiga i projektet.
- Hemstranden dvs hela byggnaden och dess verksamheter för att visualisera aggregerad information om verksamheten, mål, vision osv.
- Alla tre våningar för att bland annat kunna släcka överliggande våningar så att man bättre kan se de olika objekten i den aktuella våningen,
- avdelningarna för att kunna visualisera resurser och aktuell arbetsbelastning på dem,
- de boendes lägenheter för att kunna visualisera inomhus komforten osv.
- teknisk utrustning så som larmknappar, lyftar, nattkameror, hotelllås osv. för att komma åt konfigurering av dessa av behörig personal samt guider för hur de används.
- Vitvaror så som tvätt- och diskmaskiner för att se status få instruktioner osv.
- Brandceller och rökavgränsningar, sprinklers och branddetektorer för att kunna visualisera pågående larm, skapa situations anpassade evakueringsplaner eller visualisera scenarion under utbildning.
- Tekniska system i byggnaden för att tex hitta vilken säkring som är kopplad till vilket rum eller vart vattenavstängningen till finns för en viss ledning vid läckage.
- Hjälpmedel och medicinsk utrustning så som liggsårsmadrasser som ofta flyttas runt för att man ska kunna hitta dem när de behövs.
- Områden med begränsad åtkomst så som medicinskåp osv. för att visualisera loggar för behöriga eller för att visa om medicin administrerats.
- De boende själva för att kunna visualisera omsorgsplaner kalendrar, utförda aktiviteter så som dusch osv påminnelser mm.
- Personalen för att visualisera saker som vart personen befinner sig, om personalen fått sin rast osv. För att kunna skicka medelanden eller tagga varandra.
- Påminnelser/meddelanden dvs. felanmälningar, kom i håg anteckningar, notiser från teknisk utrustning eller larm.
Steg 4: Entitets/objekts definitioner
Följande egenskaper hos de olika entiteterna eller objekten diskuterades.
Påminnelser/meddelanden: Ett förslag var att alla objekt i tvillingen skulle ha ett meddelandeflöde dvs en kanal (se lägenhetsvy ovan). Varje meddelande skulle kunna innehålla en blandning av text, bild eller röst memon eller bara någon av dem. Ett meddelande skulle kunna vara synligt på en eller flera kanaler. En tvättmaskin skulle på så sätt kunna meddela att den är klar på sin egen kanal, men även på rums kanalen eller avdelningskanalen om man vill det. Som användare kan man välja vilka kanaler man vill vara med i eller inte. Alla meddelanden behandlas på samma sätt men meddelande vyn skulle kunna ha underflikar där man tex bara ser.
Egenskaper: Varje entitet eller objekt definieras av ett antal egenskaper. För en person kan en egenskap tex vara namn eller ålder. Vilka egenskaper som ska definieras för varje objekt kan dels fastställas utifrån behoven som finns men också tillgången på existerande data hos de olika organisationerna i projektet. I vissa fall vill man också anpassa sig efter olika standarder som finns för tex byggnader där det finns fastställt vilka egenskaper, namn och definitioner på dessa och format på datat som olika typer av objekt bör ha. I exemplen för tex lägenheten så har vi inte lagt så mycket energi i projektet exakt vilka egenskaper som ska finnas med men redan existerande data som finns är tex kvadratmeterytan på varje lägenhet och om lägenheten är avsedd för singel eller parboende osv.
Länkningar
Rent hierarkiskt så kommer de ovan angivna objekten har följande länkning.
Men i en kunskapsgraf finns alltid flera olika hierarkier då entiteter kan ha flera olika relationer till varandra. En våning kan vara nått som entiteten innehåller. I nuläget så är avdelningarna endast kopplade till en våning i byggnaden men detta kan naturligtvis komma att ändras med tiden. Man kan säga att Hemstranden innehåller våningarna, avdelningarna och lägenheterna. Än så länge innehåller även våningarna avdelningarna och lägenheterna. Avdelningarna innehåller även lägenheterna och några andra objekt. I det här fallet är relationen innehåller. Skulle en avdelning spänna delar av flera våningar i framtiden så skulle man kanske behöva definiera ett delområde av en avdelning som utgör listas i både våningens och avdelningens innehållsförteckning. Av denna anledning behöver vi skilja på grundhierarkier som avser hur objekten är namngivna och sparade på disk samt interaktions hierarkier som är de som är smidiga att använda i det visuella gränssnittet. Ett rum är ju fysiskt kopplat till en våning så i vår databas är varje rum indelat efter byggnad/våning/rums id. Men eftersom organisationen är centerad kring indelningen av avdelningar så kommer vi i det här fallet att använda byggnad/avdelning/rums id för att beskriva vart vi är i tvillingen visuellt. Ett rum som byter avdelning kommer med andra ord att få ett annat namn när man drar tidslinjen fram och tillbaka i gränssnittet.
Då även meddelanden ska kunna vara synliga i flera olika kanaler så blir varje meddelande ett fristående objekt som sedan kan länkas i från flera olika kanaler. Meddelanden lagars under användare eller objekt som genererade det/meddelande id tex Hemstranden/användare/Jeanette/meddelande 1. Varje entitet har en egenskap som heter kanaler där kanaler listade kopplade till objektet återfinns. Varje kanal är i sig ett objekt. En kanal innehåller förutom namn och beskrivning en lista med länkar till meddelanden som finns med i kanalen. Varje meddelande han ha en typ-egenskap som beskriver om den är ett larm, en händelse, en komihåg anteckning, "att göra" notis eller en felanmälan. Varje meddelande innhåller även namn, icon, tidsstämpel, tidslängd (om det tex rörde ett larm) och bild, ljud eller bild som meddelandet innehåller.
Nyckeltalen
Ett nyckeltal är ett egenskap hos ett objekt eller en entitet som matematiskt har anpassats för att kunna vara jämförbar med andra objekt eller entiteter. Man använder tex ofta energi per kvadratmeter och år för att jämföra byggnaders prestanda med varandra. I exemplen nedan finns nyckeltal och egenskaper blandade. Den översta raden är ifrån lägenhetsexemplet, den mellersta från den bodendes vy och den nedersta från personalvyn. Ingen av dessa nyckeltal är testade i verksamheten utan har i nuläget används som diskussionsunderlag för att komma fram till vad som skulle kunna vara användbart som beslutsunderlag.
Man kan endera skapa nyckeltalen utifrån förutbestämda tidsintervaller rad 2 och 3 nedan eller låta användaren välja utifrån ett antal tidsperioder se rad 1. I vissa fall kan nyckeltalet också vara tiden sen senaste gången aktiviteten utfördes tex senaste dusch exemplet nedan. I fallet med hur stor andel av sin rast som personalen fått utgår vi ifrån ett normalläge. Utformningen av nyckeltalen är starkt kopplat till dess syfte. Just nyckeltalet Rast syftade till att göra det synligt för andra medarbetare eller chefer när arbetsbelastingen för en enskild anställd var ohälsosamt hög men man skulle ju även kunna använda samma data till att övervaka personalen eller få den att känna sig övervakade. Skulle vi tex visa hur många larm som en enskild person i personalen svarat på skulle det i stället skapa en ökad stress för de anställda och till och med kunna leda till ineffektiva suboptimeringar dvs att man blir fokuserad på att få talen att se bra ut snarare än att lösa problemen på ett bra sätt något som ofta sker inom överoptimiserade hemtjänstsorganisationer. Ett inneboende problem hos vissa av dessa nyckeltal är också hur vi tex tekniskt definierar olika tillstånd så som tex rast. Att bara definiera rast som tid man spenderar i personalrummet kan vara trubbigt då man också kan få sin återhämtning i andra sammanhang.
Steg 5: Visualisering
Unity: Utvecklingen av visualisering och interaktion i den digitala tvillingen skedde i Unity. Unity är en plattformsoberoende spelmotor utvecklad av Unity Technologies som när den introducerades främst användes just för spelutveckling men som med tiden har anammats av industrier utanför videospel med behov av visualisering. Unity klienten är i sin tur kopplat till en server programvara som är byggd runt publish/subscribe systemet MQTT. Ett publish/subscribe system skiljer sig ifrån tex ett Web API genom att man inte behöver fråga efter ny data utan att man istället upprättar prenumerationer på en vis och då får pushade uppdateringar vid förändringar.
Från data till visualisering: I en visualisering så har man ofta ett grafiskt objekt som representerar entiteten. Denna är sedan kopplat till olika data.
Genom att klicka på enheten så får man tex få upp en sidovy där man kan se utvalda data kopplat det valda objektet. En annan variant är att man använder ett nyckeltal för att tex färga upp alla entiteter eller objekt av en viss typ för att förstå skillnader. Det skulle tex kunna vara rummens temperatur som används för att sätta färgen på det objekt som representerar varje rum och på så sätt skapa en så kallad heatmap (ibland på svenska färgdiagram). Genom att tex dra tidslinjen fram och tillkapa kan man se hur temperaturerna fluktuerar i de olika rummen baserat på solens position och utomhusväder.
Gränssnittet utgår from RISE digitala tvilling plattform som är utformat för att snabbt kunna skapa prototyper och visualisera data på ett lättförståeligt sätt genom berättelser som förklarar situationen. Alla delar är därför andra ord inte specifikt framtaget för just den här projektet utan ska mera ses som en första iteration. Nedan beskrivs de generella delarna av gränssnittet.
Scen och lagerväljare: . I menyn längst nere till vänster väljer man scener i rullgardinsmenyn (1). I listan under kan man klicka i och ur de olika lagren som finns tillgängliga i scenen.
Genvägar: Längst uppe till vänster finns genvägar (2) som kan ställas in för att komma till en viss scen och med ett visst antal lager aktiverade.
Dataväljare: I mitten i överkant finns Dataväljaren (3) där man kan välja vilket data-set man vill visualisera, i detta exempel "antalet besök av personal per dag".
Tidsväljare: I mitten i nederkant kan man dra i tidsväljaren (4) för att ställa in önskat datum och tid.
Inställningar: Längst upp till höger finner man inställningar (5) för att aktivera eller deaktivera dag och natt visualisering, växla mellan fullskärm eller fönster vy, hemknapp som för användaren tillbaka till en start vy med dagens tid, kugghjuls ikonen har inställningar för hur man vill visualisera olika områdesbegränsningar i kartvyer och plustecknet aktiverar eller deaktiverar mittmarkören som används för hoover funktioner.
Bokmärkesmeny: I bokmärkesmenyn (6) kan man skapa bokmärken som sparar ner vy, tid, data för den specifika tillfället och på så sätt kan man skapa en berättelse.
Perspektivväljare: I nedre högra hörnet finns en perspektivväljare (7) där man kan välja att se den digitala tvillingen i förstapersons-vy eller översikts-vy.
Slutsatser
Syftet med en digital tvilling är att skapa förståelse och göra det enklare att samarbeta kring denna förståelse. Vi vill alltså gärna att data ska kunna flöda fritt mellan olika aktörer. I vissa fall är det dock nödvändigt att begränsa tillgången till data för olika aktörer. En lösning på detta är att de olika aktörerna bara lägger upp information som de är ok med att dela. Detta är dock ingen bra lösning eftersom det då ofta slutar med att man har flera olika gränssnitt där tvillingen skulle utgöra något man endast använder i speciella situationer. Det finns en stor fördel med att ha en lösning som används dagligen i verksamheten men som också kan stödja samarbete mellan aktörerna. Vi vill i stället att tvillingen ska vara mer som en webbläsare dvs att vi med samma program kan komma åt data ifrån flera olika serverar. Skillnaden här är dock att de olika sidorna inte ska visas som separata websidor utan att data ska smälta ihop till en enda tvilling.
Vi kan tex tänka oss att data så som definition av rum och våningsplan finns på en server hos Riksbyggen medan data om avdelningar och verksamheten finns på en server hos kommunen.
Riksbyggen tillåter kommunens anställda att ta del av grundinformation så som byggnadens rum och våningar medan kommunen tillåter Riksbyggen att ta del av information så som avdelningar och kontaktpersoner för olika rum. Kommunen delar dock inte med sig av information så som personlig data om de boende.
I exemplet ovan så har kommunen fyra egenskaper hos ett rum (typ av objekt, kontaktperson, boende och en lista med länkar till andra ställen där man kan hitta information om rummet). Fastighetsägaren har på sin sida fem egenskaper (typ av objekt, yta, geometri, besiktningsdatum och en även de en lista med länkar). Med länkarna kan de olika definitionerna av rummen kopplas ihop. Kommunen ger fastighetsägaren tillgång till kontaktperson för alla objekt av typ rum. Fastighetsägaren ger kommunen tillgång till yta, geometri osv. Längst ner i server ser vi vilka egenskaper som de olika aktörerna kan se hos rums objektet. Man kan naturligtvis göra mera komplicerad tillgångs styrning än detta men
Sammanfattning
En digital tvilling har två huvudsakliga mål.
- Att sätta data i ett sammanhang och på så sätt omvandla det till kunskaper och insikter.
- Skapa en plattform för att bättre samarbete mellan olika personer, kompetenser, avdelningar och organisationer.
Grunden i en digital tvilling är en kunskapsgraf där olika data kopplas samman och som sedan visualiseras. Tvillingen kan sägas vara 5-dimensionell eftersom vi ofta har de 3 rumsliga dimensionerna, tid och olika framtidsscenarion. Det är viktigt att vi ser till att hantera tid och alternativa data i alla dataset som vi sammanfogar. Om byggnaden förändras så måste vi ha information både innan och efter förändringen för det ska stämma med tex sensordata.
För att implementera en digital tvilling behöver vi identifiera vilka typer av problem verksamheten har och vid vilka tillfällen som samarbete mellan olika aktörer kan vara utmanande. Vi behöver därefter identifiera vilka entiteter som är kopplade till dessa problem och utmaningar samt vilka egenskaper som dessa entiteter har och vart vi kan hitta data om dem i de olika aktörernas system.
Genom att tillämpa en prototypbaserad ansats där alla problemägare kan ge återkoppling under utvecklingen på så kan vi bygga mera relevanta lösningar då vi kan fånga upp fler perspektiv och inkludera även de som jobbar i första linjen på en verksamhet.
Verktyg och mallar
Följande verktyg användes för att skapa prototypen.
Unity
Unity är en plattformsoberoendespelmotor utvecklad av Unity Technologies. Motorn kan användas för att skapa tredimensionella (3D) och tvådimensionella (2D) spel, såväl som interaktiva simuleringar och andra upplevelser. Motorn har anammats av industrier utanför videospel, såsom film, bilindustri, arkitektur, ingenjörskonst. (wikipedia)
Blender
Blender är en fri programvara (open-source) för skapande av 3D-grafik. Den används inom animation, 3D-modellering och 3D-printing, UV-kartläggning, konst, virtual reality och spelutveckling. Blender finns till ett stort antal operativsystem, bland annat GNU/Linux, Windows, Mac OS, Solaris och FreeBSD. (wikipedia)
Nextcloud
Nextcloud är en klient-serverprogramvara för att skapa och använda fillagringstjänster. Nextcloud erbjuder liknande funktioner som Dropbox, Office 365 eller Google Drive när den används tillsammans med paketlösningarna Collabora Online eller OnlyOffice. Det kan driftas som molntjänst eller på egen server och är skalbart från hemmakontorslösningar baserade på Raspberry Pi till fullstora datacenterlösningar som stöder miljontals användare. (wikipedia)
Mosquitto MQTT
MQTT kan beskrivas som ett chattverktyg för sensorer. En sensor publiserar sin data i ett chattrum och alla klienter som är intresserade av att ta del av datat ansluter sig till rummet och får kontimuerligt uppdateringar.
Länkar till fördjupning
