Industrial Monitor
Sanntids overvåkningsdashbord for industriell utstyr — med anomalideteksjon og prediktivt vedlikehold.
→ Fanget en 18-dagers utstyrsdegradering i pilotfasen.
En overvåkingsplattform for en operatør med geografisk distribuerte industrielle ressurser — den typen flåte hvor hvert anlegg har sin egen PLS-vintage, sin foretrukne fieldbus, sin egen historian (eller ingen i det hele tatt), og et stort gap mellom det utstyrsleverandørens app viser og det operatøren faktisk vil se på tvers av hele flåten.
Problemets form
Arbeidet starter, som det ofte gjør i denne typen oppdrag, med en gjennomgang av eksisterende data. Noe ligger på Modbus TCP- og Modbus RTU-registre. Noe snakker OPC UA, eksponert av en nyere PLS. Noe sitter på en MQTT-megler som noen satte opp for to år siden og glemte. En håndfull sensorer er HTTP REST-endepunkter bak mobil-modemer, kun pollingvennlige. Ett subsystem snakker BACnet fordi det kommer fra en bygningsautomasjons-arv. To subsystemer er S7 over Profinet fordi Siemens. Et par andre busser på et par andre subsystemer, ingen av dem bærende for historien. Ingen av det deler enheter, ingen deler tidsstempler, og ingen er enig om hva «normalt» ser ut.
Oppdraget er enkelt å formulere og slett ikke enkelt å levere: ett dashbord, ett varslingsspor, én sannhetskilde for driftsteamet.
Tilnærmingen
Tre lag, holdt bevisst kjedelige i grensesnittene:
Edge. En liten Node-RED-gateway på hvert anlegg (Uplink på samme oppdrag) snakker hver protokoll innfødt, normaliserer enheter og signalnavn mot en kanonisk katalog, dedupliserer og videresender bare deltaer over en smalbåndslinje. Bufret lokalt til disk for de uunngåelige tilkoblingsbruddene. Samme gateway kjører en liten offline-regelpakke slik at de høyeste lokale feilene fortsatt lyser opp på anlegget når linken er nede.
Spine. En tidsserielagring på operatørens egen infrastruktur — TimescaleDB for de strukturerte industrielle signalene, med en MQTT-bro foran for streaming-strømmen og en Postgres-side komprimeringspolicy som beholder ett år med høyoppløst data og mange år med rollups. Per-ressurs-metadata i et relasjonsskjema slik at dashbordet kan gruppere etter anlegg, linje, leverandør, installasjonsdato, siste service-dato.
Surface. En FastAPI-backend, en statisk frontend (denne stacken — Astro, TypeScript, server-rendrede fliser der det hjelper) og en flåtevisning som oppdateres flere ganger per sekund over Server-Sent Events uten at klienten må polle. Anomalideteksjon kjører server-side: en blanding av enkle statistiske grenser for det som allerede er godt karakterisert, og lette lærte modeller — autoencodere, isolation forests, enkle LSTM-prognoser — for de halefenomenene der «dette er ikke riktig» er en frase ingen har tatt seg bryet med å skrive ned.
┌─[ 00 SIGNALER ]──────────────────────────────────────┐ │ > sensorer · ventiler · temperatur · vibrasjon │ └─────────────────────────┬────────────────────────────┘ ▼ ┌─[ 01 HENT ]──────────────────────────────────────────┐ │ │ │ tagger ──> normalisér ──> tidsserie-lager │ │ │ └─────────────────────────┬────────────────────────────┘ ▼ ┌─[ 02 OPPDAG ]────────────────────────────────────────┐ │ │ │ baseline ──> anomaliscore ──> alarmgrenser │ │ │ └─────────────────────────┬────────────────────────────┘ ▼ ┌─[ 03 TIDSLINJE ]─────────────────────────────────────┐ │ │ │ ▁▁▂▂▁▂▂▃▃▃▄▄▅▆▇█ drift fanget ved T-18d │ │ │ │ T-18d T-12d T-6d T-nå │ └──────────────────────────────────────────────────────┘
Integrasjonene er arbeidet
Mest av det reelle arbeidet er ikke modellering og ikke dashbordet. Det er å matche et register på en tretti år gammel PLS mot en måling fra en nyere sensor, få begge inn i samme tekniske enheter, få begge tidsstemplet mot samme NTP-kilde, og overtale begge til å fortsette å sende når mobil-modemet faller til to bjelker. Det er en seksjon av kodebasen som eksisterer utelukkende for å re-kode tidsstempler fra de fire eller fem subtilt-inkompatible representasjonene feltutstyret sender. Det er en ordliste over signalnavn operatørteamet kan redigere. Det er en per-anlegg klokke-skjevhets korreksjon. Ingenting av dette er glamorøst og alt det er det som avgjør om plattformen stoles på etter seks måneder.
Hva som ble levert
I pilotfasen — ett anlegg, tre uker med data — flagget plattformen en treg degradering på en enkelt ressurs atten dager før den ville ha produsert en hard feil under operatørens eksisterende alarmgrenser. Signalet var ikke uvanlig i seg selv; det ble uvanlig når det ble korrelert med to andre målinger som ingen andre på anlegget så på sammen. Løsningen var en planlagt service heller enn en nødanrop-utrykning.
Det er den riktige formen på utfall for prediktivt vedlikehold: ikke et mirakel, men nok varsel til å gjøre responsen om fra et telefonkall 22:00 til et punkt på neste ukes vedlikeholdsplan.
Stack, kort
- Edge: Node-RED, egne protokollnoder, SQLite ringbuffer, MQTT-bro med store-and-forward, signerte firmware-oppdateringer
- Protokoller sett i produksjon: Modbus TCP og RTU, OPC UA, MQTT, S7, BACnet, HTTP REST, samt et knippe mindre vanlige busser der utstyrsalderen krevde det
- Spine: PostgreSQL + TimescaleDB, EMQX som megler, Redis for hot-path-caching av avledet tilstand
- Surface: FastAPI, Astro, ren TypeScript, Server-Sent Events, Plotly for interaktive plot der de tjener sin JS
- ML: scikit-learn for de daglige detektorene, PyTorch for LSTM-prognosene, alle trent på operatørens egne historiske data og re-trent på fast kadens
- Hosting: operatørens egne Linux-servere, ingen tredjeparts-SaaS i datasporet
Status
Lever på flere anlegg; case-siden her holder seg generisk med vilje. Spesifikke ressurser, anlegg, leverandører og operatørens navn er dekket av NDA. Hvis du vurderer denne typen integrasjonsarbeid og vil snakke gjennom spesifikker, er drift@solheimsolutions.no korteste vei.