Industrielle styresystemer - Wiki
DDS benytter seg av en publish/subscribe-metode. Tenk deg at en "publisher", for eksempel et kamera, sender ut data. Dette dataet er ment for "subscribers, som kan være mottakende enheter som en skjerm som viser videoen fra kameraet dette kalles for machine to machine eller peer to peer. Mellom disse enhetene finner vi et viktig konsept kalt "topic". Hvert "topic" har et unikt navn og en bestemt data-type, her defineres informasjonen som skal populeres i det globale datasystemet kalt for GDS. Navnet gir en indikasjon på hva slags informasjon "topic"-et inneholder, mens data-typen definerer strukturen på denne informasjonen. Hvis vi for eksempel har flere kameraer, kan de alle sende sin video til et "topic" kalt "KameraFeed". Dette gjør det enkelt for en subscriber å motta video fra alle kameraene ved kun å abonnere på "KameraFeed"-topicen. QoS, som står for Quality of Service, er en viktig mekanisme innenfor DDS. QoS sørger for at data blir behandlet og dirigert basert på spesifiserte krav og prioriteringer. For eksempel, ved hjelp av QoS kan man prioritere "kritisk" data over "ikke-kritisk" data. Dette betyr at hvis en temperatursensor registrerer en temperatur som overstiger en gitt grense, noe som kan betraktes som kritisk informasjon så vil denne dataen få høy prioritet og dermed bli sendt raskere til mottakeren. Dette sikrer at systemer kan reagere raskt på viktig informasjon. QoS har også innstillinger som setter påliteligheten for data overføringen i fokus. Det er 2 hovedmoduser, “best effort” og “Realible”. Best effort innstilling vil sende data, men vil ikke kunne garantere om dataen kommer suksessfullt fram. Derfor kan man for mer kritisk data bruke innstillingen “Realible”, Realibel vil sørge for at dataen kommer fram ved bruk av “heartbeats” fra publisher sin ende og “acknowledgment” fra subscriber sin ende. Om dataen går tapt så vil DDS sørge for at dataen vil bli sendt på nytt fra lagring.
Overview
Content Tools