Undersøker flyvende lys, fant jordnært problem med sensorer

Det begynte med observasjoner av lavatmosfæriske lys nær terrenget i et skjermet område utenfor Oslo.

Det vi observerer, har klare likhetstrekk med lysfenomenene som har gjort Hessdalen kjent.

Området holdes foreløpig tilbake for å unngå at ferdsel, kunstig lys og oppmerksomhet påvirker arbeidet.

Fenomenet kan observeres og måles, men årsaken er fortsatt noe ukjent. Derfor begynner vi ikke med en konklusjon – vi begynner med dataene. 

Før vi forsøker å forklare observasjonene, må tidspunkt, sted, miljøforhold og sensorstatus dokumenteres godt nok til at mulige forklaringer kan testes fremfor å antas.

Jeg trodde først at den vanskelige delen ville være å velge de riktige sensorene.

Jeg tok feil.

Den virkelige utfordringen oppsto da kameraer, LoRa-loggere, miljøsensorer og manuelle observasjoner skulle brukes sammen.

Integrasjonen blir alltid noen andres problem

Sensorene kunne fungere utmerket hver for seg. Likevel brukte vi uforholdsmessig mye tid på arbeidet mellom dem.

Én kilde rapporterte hvert sekund, en annen hvert femte minutt. Noen sendte data kontinuerlig, mens andre lagret målingene lokalt og leverte dem senere. Tidssoner, enheter, formater og måten sensorene rapporterte feil på, varierte. 

Alt kunne i prinsippet lagres i samme database. Det betydde ikke at dataene kunne forstås sammen.

Dette er ikke et særtrekk ved vårt prosjekt. Det er en grunnleggende svakhet i måten mange sensorsystemer utvikles på.

Hver gang en ny sensortype, produsent eller protokoll kommer inn, bygger vi enda en adapter, enda en databehandler og enda en spesialløsning. Deretter gjør vi det samme på nytt i neste prosjekt.

Det fungerer, men prisen er teknisk gjeld. Systemet blir vanskeligere å vedlikeholde, og kunnskapen om hvordan integrasjonen egentlig virker, blir gjerne sittende hos noen få utviklere.

Dette er en dårlig måte å bygge sensorinfrastruktur på.

En måleverdi er ikke nok

En sensorverdi har begrenset betydning uten kontekst.

Tallet 42 forteller lite dersom vi ikke vet hvilken sensor det kom fra, hva som ble målt, hvilken enhet som ble brukt, hvor sensoren befant seg, om klokken gikk riktig, og om utstyret fungerte som forventet.

Likevel behandles denne informasjonen ofte som noe som kan legges til senere.

Det bør være motsatt.

Kilde, tidspunkt, sted, sensorstatus og datakvalitet bør følge observasjonen fra det øyeblikket den registreres. Dette må være en del av selve datastrukturen, ikke informasjon som operatøren må lete etter i et annet system når noe uvanlig skjer.

Det samme gjelder varsler.

At én sensor reagerer, betyr ikke nødvendigvis at en hendelse har funnet sted. Det betyr bare at én kilde har registrert et avvik.

Skal vi forstå hva som skjedde, trenger vi kanskje kamerabilder, værdata, målinger fra nærliggende sensorer og informasjon om utstyrets tilstand i samme tidsrom. Også sensorene som ikke reagerte, kan være viktige. De forteller hva som forble normalt.

Et sensorvarsel er derfor ikke en hendelse. Det er starten på en undersøkelse.

Har lytta i fire millioner timer

- Til nå har vi samlet nærmere 4 millioner timer med data fra hundretalls systemer, forteller utviklerne bak Soundsensing.

Vi må bygge for gjenbruk

Jeg mener vi må slutte å akseptere at hver ny sensorintegrasjon utvikles som et eget spesialprosjekt.

Målet bør være at nye sensorer kan kobles til gjennom en kjent struktur, der de gjentakende delene av arbeidet allerede er håndtert. En ny kilde vil fortsatt kreve dokumentasjon, testing og noe tilpasning. Den fysiske verden kommer aldri til å bli fullstendig standardisert.

Men det bør ikke være nødvendig å bygge hele forståelsen på nytt.

Et slikt system må minimum kunne:

1. Ta imot data fra ulike typer kilder

2. Bevare informasjon om kilde, tid, sted, status og kvalitet

3. Samle relevante observasjoner rundt samme situasjon

4. Gjøre resultatet tilgjengelig for både mennesker og eksisterende systemer

Det er dette som gradvis kan gjøre sensorintegrasjon mer likt å legge til en ny kapasitet enn å starte et nytt utviklingsprosjekt.

Utviklere på norsk UFO-jakt: - Det er et stigma rundt dette

Sensorer, kameraer, kunstig intelligens og engasjerte utviklere skal undersøke mystiske lysfenomener i Hessdalen.

Fra lysfenomener til Heimdall

Erfaringene fra feltarbeidet ble utgangspunktet for programvarelaget Heimdall, som vi utvikler gjennom VEIL.

Heimdall er fortsatt under utvikling. Vi har ikke laget en universell løsning som automatisk forstår enhver sensor enda. Det vi har bygget, er en fungerende teknisk retning for å ta imot ulike observasjoner, bevare sammenhengen mellom dem og presentere dem som et geografisk og tidsmessig situasjonsbilde.

Ambisjonen er at operatøren først skal kunne se hva som krever oppmerksomhet, og deretter undersøke den samme situasjonen grundigere uten å måtte rekonstruere den manuelt fra flere separate systemer.

Kunstig intelligens kan etter hvert hjelpe til med å oppdage mønstre og peke ut hva som bør undersøkes. Men analysen må være sporbar, og mennesket må fortsatt eie vurderingen.

For oss startet dette med noen merkelige lys.

Men problemet vi oppdaget, har svært lite med mystiske fenomener å gjøre. Det finnes overalt hvor kameraer, miljøsensorer, industrielle målesystemer og menneskelige observasjoner skal brukes sammen.

Vi trenger ikke bare flere sensorer. Vi trenger en bedre måte å få dem til å fortelle den samme historien.

Ny fase: Nå trenger de din hjelp i UFO-jakta

Det har blitt fart på UFO-jakten i Hessdalen etter at profesjonelle utviklere begynte å involvere seg i prosjektet. Nå starter neste fase.