Presentasjon av sensorinformasjon o.l

(Edit this document) (Create subordinate document)

CMS legger til rette for at automatiske prosesser kan opprette og endre dokumenter. Dokumentlageret er en SQL-database, og dokumentinnholdet er kun tekst (i Markdown-syntaks).

En prosess som leser sensorinformasjon, eller mottar data fra andre prosesser i nettverket kan med fordel benytte CMS til å fremvise denne informasjonen. Fremvisningen vil da skje på det samme systemet som betjener annen informasjonsutveksling, noe som forenkler opplæring og bedrer integrasjonen av informasjonskildene. Vi vil heretter kaller en slik prosess for en sensorprosess.

En sensorprosess vil motta informasjon fra omverdenen, avgjøre hvordan den skal presenteres, evt. stille den sammen med tidligere informasjon som er mottatt, og deretter lagre en egnet tekst i Markdown-syntaks i databasen. To detaljer kan være nyttig å påpeke:

• Dokumentet lagres i databasen med tabellkolonnen Protected satt til 1. I dette tilfellet vil det ikke være mulig for brukere av weblesere å redigere dette dokumentet. Det kan kun endres gjennom direkte operasjoner på SQL databasen.

• Dokumentet lagres med en gitt “Refresh”-rate, se dokumentet om deling av sanntidsinformasjon her. På den måten vil alle klientene som holder øye med dette dokumentet bli automatisk oppdatert om det legges inn ny informasjon.

Programmering av en sensorprosess

Det synes å være to alternative måter å sette opp en sensorprosess:

1. Gjennom skreddersydd programmering i hvert enkelt tilfelle. Det vil være en fleksibel modell som kan tilfredsstille alle spesialtilfeller av informasjonsbehandling, inkludert loggføring, statistikk, filtrering osv. Modellen er kunnskaps- og tidkrevende, og forutsetter administratorrettigheter hos dem som tester og installerer programvaren.

2. Gjennom et generisk program som er parameterstyrt av et dokumentinnhold. Et dokument kan inneholde nødvendige parametre for en sensorprosess som skal velge informasjonskilde, filtrere og sammenstille data, påføre nødvendig layout og lagre i dokumentdatabasen. En slik løsning vil være mindre egnet for spesialtilfeller, men kunne tilby en rask deployering av et sensorprosess utført av brukere uten administratorrettigheter. Man oppretter eller endrer et parameterdokument og tjenesten kommer straks i drift. Den initielle kostnaden knyttet til designet av parameterdokumentet og en generisk sensorprosess vil derimot være stor.

Kilde for datamottak

Sammen med webtjener-programmet er det installert en PubSub-broker, som kan motta såkalte publikasjoner og videresende dem til klienter som abonnerer på publikasjoner med et gitt tema. I motsetning til en web-applikasjon, hvor klienten aktivt henter informasjon ved behov (kalt pull-distribusjon) vil PubSub sende data til klientene asynkront (kalt push-distribusjon).

Det er mange fordeler ved å bruke en PubSub-broker for å formidle sensorinformasjon: Det skaper en løsere kopling mellom partene, og man unngår noen sikkerhetsproblemer knyttet til NAT-enheter og brannvegger. To modeller for å bygge systemet kan være:

1. En sensorprosess står mellom PubSub-brokeren og dokumentdatabasen. Den mottar sensorinformasjon på en vilkårlig form som PubSub-publikasjoner, og omgjør denne informasjon til Markdown, slik skissert ovenfor. Her kreves det at sensorprosessen utføres i selve tjenermaskinen. Det kreves også at sensorene har de nødvendige programbibliotekene for å bruke PubSub-protokollen.

2. Sensorprosessene kommuniserer “direkte” med sensorene på en dertil valgt protokoll og sender det resulterende Markdown-dokumentet til PubSub-brokeren, som videresender denne til en prosess i webtjeneren som oppdaterer dokumentdatabasen. En fordel med denne modellen er at sensorprosessene kan bruke pull-protokoller for å skaffe informasjon. En annen mulig fordel er at flere mottagere kan abonnere på Markdown-dokumentene som passerer gjennom PubSub-brokeren, om det er ønskelig å behandle og vise dataene på flere steder.

Forhindre kaos

Disse prosessene kan komme til å ødelegge eksisterende dokumenter dersom de angir en ukorrekt dokument id. Som et forsøksvis skill mellom de ordinære dokumentene og disse som blir automatisk generert kan vi benytte protected-kolonnen. Dersom protected==0så kan dokumentet redigeres, men ikke skrives til av en sensorprosess. Motsatt om protected==1.

Dette innebærer at sensorprosessen må hente et eksisterende dokument før det kan skrives til. Dersom dokumentet med denne id ikke eksisterer kan et nytt dokument opprettes (id til far-dokumentet bør være riktig). Nye dokumenter tildeles en dokumentid fra databasen, så man kan f.eks. bneytte verdien 9999999 om et nytt dokument skal lages.

Prototyp-kode

To enkle Python-moduler er skrevet for å studere mekanismene foreslått i alternativ 2 ovenfor. Kodemodulene benytter MQTT-tema “cms/sensors” for å kommunisere gjennom MQTT-brokeren. Syntaksen som overføres som payload i en publikasjon er basert på JSON.

PubSubAdapter.py ligger på området /var/www/html/CMS og har følgende virkemåte: Den abonnerer på publikasjoner fra MQTT-brokeren med overnevnte tema. Når en publikasjon ankommer, blir den analysert som et JSON-object, og de enkelte delene av meldingen gjøres om til en SQL setning for å legge til eller endre en rad i CMS dokumentdatabasen. Programmet startes ved boot fra /etc/rc.local.

SendMessage.py ligger på området /var/www/html/CMS og inneholder nødvendig kode for å opprette et dokumentobject med JSON-syntaks og sende den til MQTT-brokeren. Hver gang man ønsker andre dokumentopplysninger må kildekoden endres. Programmet er rudimentært og brukes kun til å teste PubSubAdapter.

---

Last update (UTC): 2024-01-02 23:35:29 by 192.168.2.160 - Docid: 13 - Parent docid: 14 Download docx