Bruk av digitale samhandlingsverktøy i KO basert på geografiske informasjonssystemer Norges Røde Kors Hjelpekorps

Transkript

1 Bruk av digitale samhandlingsverktøy i KO basert på geografiske informasjonssystemer Norges Røde Kors Hjelpekorps - Prosjektgruppe Digitale Kart - Oslo 21. april 2005

2 Sammendrag Utgangspunktet for denne rapporten var evaluering av ulike støtteverktøy for kartpresentasjon i KO. Disse evalueringene er nå skilt ut som egne rapporter. Kun deler fra evalueringen av produkter som Locus, Maria, MapSource og OziExplorer er vedlagt denne rapporten. Det resterende materialet vil bli gjort tilgjengelig fortløpende. Det ble tidlig klart at det måtte skilles mellom en enkel og rimelig løsning for umiddelbar implementering, og en mer avansert løsning som ivaretar behov tilknyttet større operasjoner. OziExplorer har blitt anbefalt og vedtatt som den enkle løsningen, men siden kartdata N50 for dette formatet er blitt trukket fra markedet i etterkant av vedtaket må denne løsningen revurderes. Hovedfokuset i prosjektet har underveis blitt endret fra test og evaluering av eksisterende systemer for en avansert løsning, til utvikling av et spesialtilpasset samhandlingsverktøy i KO. Dette innebærer identifisering av behov knyttet til støtte for samhandling, roller og oppgaver i KO. Begrunnelsen for fokusskiftet og foreløpige resultater av dette arbeidet presenteres i denne rapporten. Et gjennomgående problem forblir tilgang til geodata under aksjoner, hjemme og ute. For innlands aksjoner må det inngås et samarbeid med det offentlige som sikrer oss tilgang til geodata direkte fra kildene, slik at vi selv kan velge oppløsning, presentasjon og bruk. Gruppen har ikke funnet ferdige løsninger i dagens marked som dekker en rimelig del av de funksjoner vi har behov for i en mer avansert løsning. Imidlertid eksisterer det systemkomponenter som løser de fleste av problemstillingene. Utfordringen blir å sammenstille disse til et helhetlig system med et optimalisert brukergrensesnitt. Denne rapporten legger et godt grunnlag for utvikling av et slikt system spesialtilpasset våre behov. Side 2 av 31

3 Innholdsfortegnelse 1 INNLEDNING FOKUS HISTORIKK PROSJEKTGRUPPENS MEDLEMMER SØK OG REDNING (SAR) OPPDRAGETS FORLØP KOMPLEKSITET AVGRENSING AV PROBLEMSTILLINGEN ROLLER OG OPPGAVER I KO AKSJONSLEDER NESTLEDER (NK) SAMBANDSLEDER INFORMASJONSFLYT, INTERAKSJON OG SAMHANDLING BEHOV FUNKSJONALITET OVERORDNET Brukergrensesnitt Roller og oppgaver Kontekst og sesjonslagring Rapportering Kommunikasjon Installasjon og konfigurasjon av forskjellige oppsett OPERATIV FUNKSJONALITET Aksjonsleder NESTLEDER SAMBANDSLEDER SAMMENSATTE FUNKSJONER KONSEPTUEL FUNKSJONALITET Database Systemmodell Programvarestandard og dataformat Utveksling av geodata Tilgang på grunnlagsdata Integrering av egne tilleggsdata Bruk av fremmede data ved internasjonale operasjoner Utnyttelse av andre typer data SCENARIER SCENARIO 1 - TILGANG TIL DATA SCENARIO 2 - BRUK AV LOKALE GEODATAKILDER SCENARIO 3 - INNSAMLING OG DELING AV TILLEGGSDATA FRA FELT SCENARIO 4 - DOKUMENTASJON OVERFOR SAMARBEIDSPARTNERE OG TIL SENERE BRUK EVALUERING AV EKSISTERENDE SYSTEMER MARIA FRA TELEPLAN OZIEXPLORER MED RESCUE TRACKER MULIGE LØSNINGER SAMARBEID UNDER PLANLEGGING KONKLUSJON VEDLEGG Side 3 av 31

4 1 Innledning Denne rapporten er blant annet utarbeidet i forbindelse med sluttevalueringen av GIS verktøyet Maria utviklet og levert av Teleplan. Produktet har vært til uttesting med tanke på bruk i operative situasjoner i Hjelpekorpset. Vi mener at en dyp forståelse av roller, oppgaver og arbeidsprosesser i KO er nødvendig før vi kan gjøre et valg av systemløsning. Ved hjelp av forståelse av problemstillingen og kunnskap om de faktiske behov, kan vi identifisere den funksjonaliteten et fremtidig digitalt samhandlingsverktøy i KO skal ha. Vi mener at vårt mål må være å lage et system som har minimalt med funksjonalitet samtidig som det er svært godt tilpasset de behovene vi har. Systemet grunnfunksjoner bør kunne brukes med minimal øving. Vi trenger derfor ikke et ekspertsystem med mye funksjonalitet, men et støtteverktøy som naturlig integreres i arbeidsprosessen i KO. Det er viktig for oss at systemet oppleves som enkelt å bruke og at det vil kreve begrenset med opplæring for mannskap med lang operativ erfaring. I denne rapporten har vi fulgt opp dette standpunktet ved å skissere behov, funksjonalitet, mulige løsninger og videre fremdrift 1.1 Fokus Det opprinnelige hovedprosjektet har tittelen Digitale Kart. Dette beskriver den underliggende problemstillingen for snevert. Vi har derfor valgt å gi denne prosjektrapporten en annen tittel enn hovedprosjektet. Målet med tittelen er å gjenspeile hovedutfordringen i prosjektet: samhandling. Vi mener nå at samhandling, roller, oppgaver og arbeidsprosesser må gis betraktelig mer fokus i det videre arbeidet. For å få optimal nytte av digitale hjelpemidler må disse kommunisere på en slik måte at oversikt maksimaliseres og repetisjonsarbeid minimaliseres. Dette kan man oppnå ved å dele informasjon digitalt. 1.2 Historikk Digitale kart har lenge vært et tema i Røde Kors. Mange forskjellige initiativer rundt om i Norge har sett på problemstillingen og forsøkt diverse løsninger (Locus, Maria, MapSource, OziExplorer, etc.). På bakgrunn av dette ble det etter hvert tydelig at det fra sentralt hold burde komme noen retningslinjer for hvilke systemer som bør benyttes for å unngå for mange forskjellige løsninger. Et samarbeidsprosjekt mellom ressursgruppe ettersøkning (RGE) og ressursgruppe samband (RGS) ble derfor opprettet av landsrådet for Norges Røde Kors Hjelpekorps (LR NRKH). RGS skulle styre prosjektet og ha ansvar for den tekniske delen og RGE skulle være problemeier. Dette er naturlig siden det er RGE som sitter på fagkompetansen innen ettersøkning og ettersøkingsledelse og dermed som representanter for brukerne av et eventuelt system. Side 4 av 31

5 Behovet som verktøyet skal dekke er sammensatt og sterkt knyttet til de ulike roller og oppgaver som søks- og redningsledelsen (KO) har. Det er rimelig å anta at digitale verktøy som GIS vil kunne effektivisere arbeidet i KO betraktelig. Mange av oppgavene er preget av repetisjon og masseproduksjon av data. Her kan digitale verktøy være med på å redusere arbeidsmengden og dermed frigjøre tid til det som er viktigst for søks- og redningsledelsen; sikkerheten til egne mannskaper og en effektiv gjennomføring av oppdraget. For å få til dette betinger det at verktøyet er tilpasset de behov som finnes i KO. Et dårlig tilpasset verktøy vil lett kunne ta fokus vekk fra de viktige oppgavene i arbeidet og over på forskning på hvordan en oppgave skal løses med verktøyet. Det ultimate digitale verktøyet skal ikke ses og ikke høres. Det skal være en integrert del av de arbeidsprosesser og oppgaver som må gjennomføres for å nå målet for oppdraget - dette krever kunnskap om oppgaver og roller i en søks- og redningsledelse. En annen aktivitet som er sterkt knyttet til digitale kartsystemer (GIS) er sanntids sporing av søksenheter ved hjelp av posisjonsdata og bruk av posisjonslogg fra enhetene i etterkant. Flere grupperinger i RKH har jobbet med dette de siste årene. Buskerud RKH hadde et prosjekt sammen med Locus der TransMed flåtestyring og kombiproduktet Benefon ble benyttet som sender av posisjonsdata og GSM som bærer. Dette systemet egner seg greit for sanntids sporing. GSM SMS er en dyr kommunikasjonsbærer, og man er totalt avhengig av dekning på GSM. Systemet er fortsatt i bruk, men i meget begrenset volum. Et alternativt system er APRS. Dette er en protokoll som muliggjør overføring av posisjoneringsdata over radiosamband som VHF. RKH kan dermed benytte sitt ordinære radiosamband som bærer av posisjonsinformasjonen. APRS benyttes i dag av Hordaland RKH og Drammen RKH. Andre systemer for posisjonsdataoverføring og sporing er under vurdering, blant annet via GSM/GPRS og ICOM internprotokoll. Ressursgruppene har hele tiden ønsket å begrense og flytte fokuset fra teknologi over på de faktiske behov som finnes i KO. Dette vil vi forsette å gjøre, siden den eneste veien til suksess er at verktøyet oppleves som nyttig, ikke som en begrensning eller et irritasjonsmoment. Med dette følger en del problemer. Blant annet at det ikke finnes noen ferdige produkter som kan tas direkte i bruk. En viss tilpassning vil bli nødvendig uansett og dette koster penger. Det andre er at vi trenger løsninger nå. Mange medlemmer landet rundt sitter og venter på at det sentrale ledd skal levere noe brukbart innenfor digitale kartverk. I tillegg skal det helst være kostnadsfritt for det lokale hjelpekorps. For å møte disse forventningene vedtok LR NRKH at problemet skulle angripes på to nivåer. Et grunnivå der verktøyet skulle være så enkelt og billig som mulig til bruk i små korps og aksjoner der digitale hjelpemidler ikke har den store nytteverdien. Enkel funksjonalitet som nedlasting og opplasting av ruter og spor fra GPS, utskrift av kart og kanskje sanntids sporing hvis dette var ønskelig. Gjennom ulike lokale initiativ og utprøving ble OziExplorer et naturlig verktøy å vurdere. Da OziExplorer innfridde mange av kravene vedtok LR NRKH derfor at dette skulle være verktøyet på grunnivået. I ettertid har tilgangen til N50 kartdata blitt begrenset, da Ugland IT har besluttet å stoppe salget av N50 kartet i et format som OziExplorer kan lese. Valget av OziExplorer bør derfor revurderes. Side 5 av 31

6 Det avanserte nivået beveger seg inn på et helt annet område. Vi snakker her om digitale samhandlingsverktøy som skal støtte rollene og oppgavene til ledelsen for en søks- og redningsaksjon. Det ble bestemt at man skulle prøve ut flere forskjellige systemer, parallelt med identifisering av behov. Både Locus og Maria ble vurdert som mulige pilotsystemer. Valget falt på Maria levert av Teleplan. Før jul 2004 ble det inngått avtale om test av Maria frem til 1. april 2005, med en påfølgende frist for sluttrapporten den 1. mai Fire grupperinger rundt om i Norge (Hordaland, Oslo og Buskerud, Akershus og Sør- Trøndelag) fikk hver sin lisens av Maria slik at programmet kunne testes ut. Hordaland og Buskerud har jobbet mye med de tekniske løsningene, Sør-Trøndelag hovedsakelig har jobbet med behovene og de konseptuelle problemstillingene mens Oslo og Akershus har primært sett på brukervennlighet og kobling mot GPS. Maria er evaluert opp mot disse hovedområdene. Side 6 av 31

7 1.3 Prosjektgruppens medlemmer Oslo og Akershus Lars Otto Laukvik Leder for prosjektet Digitale Kart Problem Manager / Leder avvikshåndtering i ErgoGroup AS. Har 31 års erfaring fra IT bransjen. Er D-rådsleder i Oslo RKH og leder av Ressursgruppe Samband i NRKH. Thorbørn W. Pedersen Teknisk leder i Morgenstierne Teknisk as og d-rådsleder i Akershus. Kompetanse innen elektronikk, data og telekommunikasjon. Sør-Trøndelag Frode Rougnø Leder Digitale samhandlingsverktøy i KO Aksjonsleder i mange år. Mange års bakgrunn som aktiv i RKH og lang operativ erfaring. Kenneth Gulbrandsøy Initiativtaker og oppdragsgiver for Digitale samhandlingsverktøy i KO. Leder for Ressursgruppe Ettersøkning i NRKH. Har ettersøkning og operativ ledelse som fagkompetanse. Jobbet med utdanning av aksjonsledere på barmark og vinter de siste seks årene. Lang operativ erfaring. Pål Husum Mastergradsstudent i GIS. Skriver masteroppgave om bruk av GIS i redningstjenesten. Tidligere arbeidserfaring med GIS. Mange års bakgrunn som aktiv i RKH og lang operativ erfaring. Jan-Rune Sørheim Tele-kom.ingeniør. Arbeider med nettverksdrift i Netcom. Radioamatør og Sambandsleder i Trondheim RHK. Lang erfaring fra RKH. Side 7 av 31

8 Nina Elisabeth Nerbø Storvik Administrator. Har tilrettelagt møter og rapportskriving. Arkivansvarlig ved SVT-fakultetet, NTNU. John Bjørndal Arbeider med GIS i privat sektor. Har lang arbeidserfaring og utdanning innen GIS fra ulike miljø. Mange års bakgrunn som aktiv i RKH og lang operativ erfaring. Tom Fagerhaug Svært dyktig analytiker. Doktorgrad innen produksjonsteknikk. Mange års bakgrunn som aktiv i RKH og lang operativ erfaring. Hordaland og Buskerud (2 grupperinger) Roar Elde Leder for prosjektgruppen. Senior Instruktør Teleteknikk i forsvaret. Bruker av Maria i jobbsammenheng, jobbet med sambandsproblematikken i Røde Kors i en årrekke. Radioamatør og Distriktssambandsleder (Hordaland). Chris Låstad Askeland Grafiker. Lang erfaring med kart- og sambandsproblematikk i KO Magnus Øvrebø Radioamatør med interessefelt APRS og nødsamband. Leder NRRL`s nødsambandstjeneste i Drammen. Fagbrev Serviceelektroniker i telematikk og kommunikasjonselektronikk. Petter A. Skatvedt Ambulanse koordinator, AMK-Buskerud. Daglig bruker av digitalt dataverktøy, flåtestyring (LOCUS). Distrikts sambandsleder Buskerud RKH. Mange års operativ erfaring i RKH. Side 8 av 31

9 2 Søk og redning (SAR) I dette kapittelet har vi et overordnet blikk på roller og oppgaver i ledelsen av en søks- og redningsaksjon med hovedfokus på det som skjer i kommandoområde (KO). Denne korte innføringen er på ingen måte fullstendig. Likevel har vi valgt å kort presentere roller og oppgaver på et generelt grunnlag. Vi har også valgt å fremstille problemstillingen fra RKH sitt ståsted. Det er prosjektgruppens intensjon at denne fremstillingen skal samkjøres med Politiet som er oppdragsgiver ved aksjoner. Det er viktig for oss og for prosjektet at man ikke havner i en diskusjon om hvem som skal inneha de ulike rollene. Dette kan variere fra sted til sted. Noen oppdragsgivere er tilfreds med å la RKH gjøre mesteparten av jobben, mens andre ønsker å detaljstyre. Rollene og oppgaven finnes der uansett og designet av GIS verktøyet skal ikke være påvirket av hvem som innehar den enkelte rolle og oppgave, men designet og tilrettelagt slik at rollene kan ivaretas og oppgavene kan gjennomføres. 2.1 Oppdragets forløp Det er viktig å anerkjenne det faktum at aksjoner gjennomføres på mange forskjellige måter. Situasjonene er varierte og dette medfører et mangfold av forskjellige løsninger. I tillegg til dette kommer forskjellige tradisjoner og slik har vi alltid gjort det mekanismer. Alt dette vil virke inn på hvordan et oppdrag løses. Vi gjør likevel et forsøk på å presentere en generalisert modell av et søksoppdrag fra det mottas til det er gjennomført. Denne modellen vil hjelpe oss med å bryte ned et søksoppdrag i dets enkelte bestanddeler, så vel roller som oppgaver. Modellen vi har benyttet er gjengitt i figur Kompleksitet Det er mange faktorer som påvirker kompleksiteten i oppdraget. De faktorene som er enklest å påvirke har med produksjon og håndtering av informasjon å gjøre. Hver enkelt søksenhet skal ha et oppdrag, helst skriftlig dersom dette er mulig. Å produsere ett skriftlige oppdrag er kanskje ikke spesielt tidkrevende i seg selv, men når det skal produseres til mange søksenheter vil dette ta lang tid. Et digitalt hjelpemiddel som et GIS verktøy vil være til stor hjelp i en slik situasjon. 2.3 Avgrensing av problemstillingen Den videre presentasjonen vil fokusere på arbeidet i KO, det vil si den nederste firkanten i figur 1. Videre har vi begrenset oss til å se på aksjoner som når en viss størrelse. Dette valget er understøttet av den tidligere vurderingen rundt behovsforskjellene som det nødvendigvis vil være mellom små søksoppdrag med få søksenheter og store søksoppdrag med mange søksenheter. I tettbebygde området er det ikke uvanlig at man kan ende opp med mer enn 20 enheter i søk. Dette stiller store krav til ledelsen i KO med tanke på planlegging og logistikk. Det er i slike situasjoner at digitale samhandlingsverktøy virkelig kan komme til nytte. Side 9 av 31

10 Oppdrag mottas Hjemme Kort vurdering Varsling Innhente info Tiltak Underveis Analysere Endring? Planlegge I KO Gjennomføre Figur 1: Overordnet modell av et oppdrag 2.4 Roller og oppgaver i KO RKH bruker ofte en rollefordeling i KO med aksjonsleder, nestleder og sambandsleder. Hvis disse er godt trente og samkjørte kan de håndtere oppdrag med stor kompleksitet og mange mannskaper. Det kan bli nødvendig å tilknytte seg ytterligere flere personer/roller for å ivareta oppgaver som logging, problemløsning, bindeledd mellom KO og mannskaper som venter på oppdrag eller som hviler. Situasjonen alene bestemmer dette. Man vil (og bør) til en hver tid forsøke å minimalisere antall personer i KO slik at flest mulig kan komme seg ut i søk. I fortsettelsen vil vi kort oppsummere hva de ulike rollene innebærer av ansvar, oppgaver, kompetanse og kunnskap. Side 10 av 31

11 2.5 Aksjonsleder Dette er lederen i KO og den som har det overordnede ansvaret for den praktiske gjennomføringen av oppdraget. Prinsipielt og formelt er det alltid Politiet som har denne rollen, men i praksis vil ofte lederen fra den frivillige redningsorganisasjonen bekle denne rollen ved å være den som faktisk gjennomfører oppgavene til aksjonslederen. Vi har tidligere nevnt problemene med å definere hvem som bekler den enkelte rolle. Dette er et eksempel hvor vi tydelig ser at flere personer kan bekle samme rolle. Aksjonsleders oppgaver er Tydelig definere mål og hensikt for oppdraget (plan). Identifisere behov i god tid før de oppstår og iverksette tiltak Holde oversikt Oppfølging av informasjon, pårørende, media Være kritisk og granskende til sine egne avgjørelser Evaluere og vurdere om nåværende plan er hensiktsmessig Endelig instans ved avgjørelser Støtte opp og legge til rette for sine medarbeidere Hvis aksjonsleder i praksis er en frivillig må politiet holdes løpende orientert Delta i analyse og planleggingsarbeidet når dette er nødvendig Dokumentasjon av viktige hendelser og overordnet fremdrift. Oversikten viser at aksjonsleder ikke har mange praktiske oppgaver. Det er aksjonsleders plikt og oppgave å forsøke til en hver tid å holde hodet over vannet og ivareta det store bildet. Dette blir vanskelig hvis man graver seg ned i detaljer. En god aksjonsleder klarer å balansere mellom detaljer og det store bildet uten å miste oversikten. Stikkord: OVERSIKT og KOORDINASJON 2.6 Nestleder (NK) Nestleder vil som regel være aksjonsleders nærmeste støttespiller og høyre hånd. Disse to vil samarbeide tett i løpet av hele oppdraget. Nestleders fokus er taktikk. NK vil sammen med aksjonsleder og sambandslederen gjennomføre en analyse av den tilgjengelige informasjonen man har (den savnede, lendet, vær, føre og lysforhold, og egne ressurser). Ut i fra dette lager man seg en hypotese, formening om hva som har skjedd, og planlegger et søk ut i fra dette. En stor del av informasjonen som produseres under den taktiske vurderingen og planlegging er knyttet til lendet. Spørsmål som Hvor er den savnedes hytte? Normalruter? Skredfare? Sist sett? Er det ulendt? Er den savnede kjent i området? vil sammen med hypotesen være med på å bestemme utformingen av hvert søksoppdrag. Nestleders oppgaver er Taktisk vurdering og planlegging Utarbeidelse av søksoppdrag Oppfølging av fremdrift og resultater Justere planer i henhold til aksjonsleders mål og hensikt Dokumentasjon av beslutningsgrunnlag Side 11 av 31

12 Kort oppsummet er nestleders hovedoppgave å produsere søksoppdrag som til en hver tid er tilpasset situasjonen. Stikkord: TAKTIKK og PRODUKSJON 2.7 Sambandsleder Sambandslederens rolle har mange fasetter. Kommunikasjon med søksenheter, loggføring av all vesentlig kommunikasjon i tillegg til bidrag til planleggingen. Sambandslederen må ha god kunnskap om lendet som aksjonen foregår i slik at radiosambandet kan konfigureres optimalt. Videre må sambandslederen være god til å koordinere mannskapene, fordele søksoppdrag og holde orden på alle forespørsler og den videre oppfølging av disse. Det er spesielt viktig at sambandslederen evner å videreformidle viktig informasjon til aksjonsleder og nestleder og filtrere vekk informasjon av mindre viktighet. Dette er en vanskelig balansegang som innebærer erfaring og god innsikt i hele prosessen. Sambandslederens oppgaver er Sørge for god kommunikasjon mellom aksjonsledelsen og alle søksenheter Koordinasjon og problemløsning Bidra til planleggingen Dokumentasjon av all kommunikasjon Stikkord: KOMMUNIKASJON og IVERKSETTING Side 12 av 31

13 2.8 Informasjonsflyt, interaksjon og samhandling For i grove trekk å visualisere hvordan informasjonen flyter i KO har vi valgt å lage en modell. Denne vil være med på å gi et bedre bilde på hva som faktisk skjer i KO. Informasjonshåndtering og flyt i et fremtidig system må eksplisitt støtte de generelle egenskapene til modellen i figur 2. Kommunikasjon Informasjon Oppdragsgiver Pårørende Media Publikum Koordinasjon Status? Ordrer Nestleder Aksjonsleder Resultater Spørsmål Meldinger Status KO Koordinasjon Status? Ordrer Sambandsleder Aksjonsleder Aksjonsleder Søksenheter Oppdrag Meldinger Oppgaver Ordrer Oppdrag Meldinger Oppgaver Ordrer Figur 2 Modell for informasjonsflyt, interaksjon og samhandling Side 13 av 31

14 3 Behov Vi er på langt nær ferdig med å kartlegge alle behov man har for støtte i KO. Det er heller ikke foretatt en sortering etter viktighet, noe som vil være viktig når man skal prioritere mellom funksjonalitet for å oppnå en fornuftig kost-nytte effekt. Vi har imidlertid identifisert noen hovedtrekk. Produksjon og fremstilling av informasjon med mulighet for å lagre, skrive ut og flytte rundt mellom de enkelte rollene i KO Rike funksjoner for kartanalyse, planlegging av søksoppdrag, føring av resultater og sammenkobling av disse med annen informasjon Systemet må tilpasses den enkeltes rolle og oppgaver (hver rolle krever forskjellige funksjoner, ergo forskjellige grensesnitt) Brukervennligheten må være svært god. Systemet må være enkelt å lære der det meste av funksjonalitet ligger på et ettklikks nivå. Ofte brukte funksjoner må være mulig å automatisere (batch) for å korte med tiden det tar å gjennomføre oppgaven Lett tilgang til data. Mulighet til å shoppe nye data til en hver tid på døgnet (portal). Dette betyr at systemet må være basert på åpen kildekode (mulig å endre uten at leverandør må inn i bildet). Kommunisere med andre datasystemer som UMS (varslingssystem) og medlemsdatabaser (ressursdatabaser) Åpne internasjonale datastandarder. Gir mulighet til å hente inn data fra alle tenkelige datakilder. Vil være konkurransedrivende og kostnadsreduserende. Systemet må kunne støtte plug-in-moduler. Opptak av sambandstrafikk, gjenkjenning av samtalestruktur for automatisk innsetting av linjer i sambandslogg Flere personer må kunne jobbe mot de samme dataene samtidig i sanntid. Uvikling av system vil kreve mer ressurser enn det prosjektgruppen i sin helhet har tilgang til. Eksterne ressurser må dermed hentes inn. Samkjøring av våre aktiviteter med resten av redningstjenesten (HRS, DSB, Justis, FORF) Side 14 av 31

15 4 Funksjonalitet I dette kapitlet er vi litt mer konkret på hvilken funksjonalitet som bør var tilstede i systemet. Det vi nå snakker om er et system som blander samhandlingsverktøy, databaseteknologi og geografiske informasjonssystemer (GIS). Det finnes modulære systemer på markedet i dag som hver for seg dekker ulike deler av våre behov. Det vil likevel være nødvendig med en del utvikling for å få disse til å kommunisere på en sømløs og enhetlig måte. Grovt sett kan våre behov oppsummeres som: Innsamling av data og analyse Etterretning, kartanalyse, sambandsdekning, varsling, ressursoversikt Gjennomføring Ordre, informasjonshåndtering, sanntids sporing, logistikk, planverk og prosedyrer Dokumentasjon og rapportering Aksjonslogg, sporlogg, sambands- / audiologg, live video. Problemstillingen med å utvikle et helhetlig system for å håndtere disse oppgavene er på ingen måte unik for RKH. HRS, Politiet og andre offentlige etater har utviklet egne systemer som delvis gir svar på problemstillingene vi har. Det finnes også enkeltkomponenter utviklet blant annet for redningstjeneste i utlandet som er kommersielt tilgjengelig. Utfordringen blir å finne en hensiktsmessig måte å integrere og implementere funksjonaliteten på. Vi har valgt å dele funksjonalitet inn i tre hovedområder: overordnet, operativ og konseptuel. Overordnet funksjonalitet ser på hvordan roller skal implementeres, hvordan informasjonsflyt og håndtering skal foregå og så videre. Operativ funksjonalitet knyttes til de konkrete oppgavene man har identifisert og konseptuel funksjonalitet er funksjonalitet knyttet til systemtekniske løsninger. Vi trekker her frem mange nyvinninger inne GIS som er i ferd med å bli kommersielt tilgjengelig. Mulighetene innen GIS er svært store. Det er ikke teknologien som setter grensene, men evnen til å utnytte denne. Norge Digitalt og andre offentlige initiativer innen beredskap og GIS gir enorme mulighet for oss i redningstjenesten. Det svært viktig at Norges Røde Kors og resten av redningstjenesten blir partnere i for eksempel Norge Digitalt. 4.1 Overordnet Her beskrives den overordnede funksjonaliteten til systemet. Vi deler funksjonaliteten opp i to deler. Brukergrensesnitt (klient) og levering av data (server/database). Den siste delen vil bli dekket mer omfattende under konseptuel funksjonalitet. Overordnet funksjonalitet retter seg hovedsakelig mot brukergrensesnittet, med andre ord den delen av systemet som brukeren direkte arbeider på. Alt bak er egentlig av mindre interesse så lenge den oppfyller de overordnede behov som er spesifisert tidligere. Side 15 av 31

16 4.1.1 Brukergrensesnitt Hovedvisjonen for brukergrensesnittet kaller vi ett-klikks-visjonen. Som det ligger i ordet betyr dette at flest mulig av funksjonene skal kunne nås på ett klikk. Det vil si en knapp, tabulator eller andre skjermobjekter. Dette reduserer tiden man benytter på å gjennomføre en oppgave til et minimum. Eksempler kan være tegning av en teig, legge til en ny enhet, legge til en ny hendelse og så videre. Dette stiller store krav til oss og utviklerne med tanke på begrensing i antall funksjonalitet på ett-klikks-nivå. Vi må gjennomføre en grundig analyse av all nødvendig og ønsket funksjonalitet og finne en prioritert rekkefølge på disse. Videre må oppgaver som krever serier med handlinger kunne gjennomføres som batcher. Det vil si at systemet guider brukeren gjennom handlingene med å utføre gjentatte handlinger. Handlinger som ikke krever brukerinteraksjon utfører systemet automatisk, som for eksempel ta frem dialogbokser, velge verktøy, presentere inndata felt, vise valglister og så videre. Under avsnittet operativ funksjonalitet er dette beskrevet som veiledere eller wizards Roller og oppgaver Systemet må støtte de tre hovedrollene i KO. Det vil si at systemet/applikasjon(er) må støtte tre forskjellige oppsett; ett for aksjonsleder, ett for nestleder og ett for sambandsmannen. Dette vil være med på å fordele funksjonaliteten på flere skjermbilder. Resultatet blir da et mer oversiktelig brukergrensesnitt der det blir enklere å plassere flest mulig av de mest brukte funksjonene synlig til en hver tid. Dette kan realiseres på mange måter. En vanlig metode er å la en og samme applikasjon innta forskjellige tilstander, for eksempel tilstandene Aksjonsleder, Nestleder og Sambandsmann, se Figur 3. Aksjonsleder Sambandsleder Applikasjonene må være tilpasset den enkelte rolle og oppgave Nestleder Figur 3 Systemtilstander Fordelen med at alt ligger i samme applikasjon er at man kan bytte roller underveis uten å skifte arbeidsstasjon se de samme dataene og dermed enklere samarbeide variere sammensetningen i KO (1, 2, 3 eller flere som jobber samtidig på de samme dataene) og blande sammen roller uten at systemet trenger særlig stor konfigurasjon Videre må det være mulig å for hver enkelt bruker å kommunisere med de andre brukerne. Typisk type kommunikasjon er felles informasjonsbuffere (søketeiger med forskjellig tilstander, aksjonslogger, sambandslogger, fremmøtelister og så videre). Side 16 av 31

17 4.1.3 Kontekst og sesjonslagring Systemet må kunne settes inn i en situasjons- og lokasjonskontekst. For eksempel Søk etter 12 år gammel jente den , Gråkallen, Trondheim Kommune. All aktivitet og informasjon som håndteres (teiger, funn, logger, fremmøtelister) plasseres inn i denne konteksten. Dermed kan man på et senere tidspunkt hente frem igjen de lagrede dataene for rapportering og evaluering ut fra en dato eller lokasjon. Et annet navn for dette er sesjonslagring. Med en slik funksjonalitet er det mulig å spille av hendelsesforløpet i etterkant for å skaffe seg en dypere forståelse av hva som skjedde og hva som ble gjort. En typisk nytteeffekt vil være ved overlevering av oppdraget til en ny søksledelse. Da kan den nye ledelsen spille av hva som er gjort og på grunnlag av dette få en god forståelse av hva som er gjort så langt Rapportering En annen nytteeffekt av sesjonslagring er utarbeidelse av rapport i etterkant. Systemet kan selv automatisk generere en rapport/oppsummering av hypotesene, plan, hendelsesforløpet (aksjonslogg og sambandslogg), resultater (dekningsgrad, hvor er det avsøkt og hvordan), antall ressurser involvert (timer, type ressurs) og så videre. Når dataene først er der er det en smal sak å generere en utskrift av dette Kommunikasjon Systemet må være mulig å distribuere med kommunikasjon over Internet/Ethernet Installasjon og konfigurasjon av forskjellige oppsett Konfigurasjon av systemet må være så enkelt som mulig. Det vil si at installasjonen må utføre det meste av konfigureringen. Det skal ikke være nødvendig å være kyndig i operativsystem konfigurasjon eller annen avanserte ferdigheter. Installasjonsrutinene må dermed være dynamiske slik at man kan velge forskjellige oppsett av systemet (alt på en PC, nettverksløsning, tilkobling til ekstern dataportal og så videre). 4.2 Operativ funksjonalitet Den operative delen av funksjonaliteten har vi valgt å gruppere etter roller. Dette gjør det enklere å sortere funksjonalitet for senere prioritering Aksjonsleder Stikkordene for aksjonsleder var oversikt og koordinasjon. Med andre ord må denne delen av systemet presentere informasjon som er med på å gi oversikt over: sjekklister plan fremdrift (oppdragets tilstand) ressurser Side 17 av 31

18 Mest sannsynlig bør denne delen være bygget opp rundt aksjonsloggen. Aksjonsleder er ansvarlig for at aksjonsloggen blir ført. Noen hendelser legger aksjonsleder til selv (for eksempel viktige avgjørelser eller konkrete tiltak), andre hendelser legges til av systemet selv. For eksempel fra sambandsloggen (prioriterte meldinger) eller resultatkartet (når oppdrag er ferdig). Videre er det viktig at aksjonsleder har mulighet til å gå dypere ned i dataene som de andre arbeider med. Dette kan løses ved at aksjonsleder kan gå inn i deler av, eller den samme visning som for eksempel nestleder, men uten rettigheter til å endre eller påvirke. Annen informasjon som bør være tilgjengelig er ressurslister, fremmøtelister, kontaktinformasjon og så videre. 4.3 Nestleder Stikkordene for nestleder var taktikk og produksjon. I dette ligger det mange oppgaver. Fellestrekket for disse oppgavene er at oppgavene resulterer i oppdrag til enheter av en eller annen art. Hvis vi ser tilbake på den overordnede modellen av oppdraget (figur 1) vil man se at det er tre hovedfaser i det operative arbeidet; nemlig analyse, planlegging og gjennomføring. Analyse og planlegging er oppgaver som nestleder utfører med støtte fra aksjonsleder. Under analysen vurderes de faktorer som påvirker oppdraget fra det mottas til det er gjennomført. NRKH har definert fire hovedkategorier av informasjon som må analyseres; den savnede, lendet, vær-, føre- og lysforhold og egne mannskaper (ressurser). Basert på denne informasjonen gjør aksjonsledelsen vurdering og kommer frem til en eller flere hypoteser (hva har mest sannsynlig skjedd). Den videre planleggingen vil være basert på disse hypotesene. Under analysen og planleggingen er det kategorien lendet som krever mest av tiden. Først må en kartanalyse gjennomføres: hvor er den savnede sist sett kanaliserende lende transport inn og ut av området veier, stier, parkeringsplasser hvor kan man plassere fremskutt KO skredfarevurderinger størrelse på operasjonsområdet Når hypoteser er valgt, er det tid for planlegging. Under planleggingen tar nestleder ut søketeiger (der søket skal gjennomføres) med hensiktsmessige krav til gjennomføring (søkemetode, nøyaktighet i forhold til effektivitet). Dette gjentas inntil den savnede er funnet eller hele operasjonsområdet er gjennomsøkt på en tilfredsstillende måte (dekningsgrad og nøyaktighet). Typisk funksjonalitet i et GIS system vil i denne sammenhengen være: Utarbeidelse av en lendeorientering Når mannskap skal orienteres er det fordelaktig at en kort lendeorientering er laget der den mest relevante informasjonen er tatt med. Dette reduserer sannsynligheten for misforståelser nå oppdrag gis over samband (man har på forhånd sett hvor den savnedes hytte er eller hvor møtepunkt for inntransport er). Her må systemet støtte uttak av lendeorientering ved for eksempel et rektangel verktøy med en påfølgende wizard som informasjon kan legges til: klikk på et element i kartet og en dialogboks med mulighet for å legge inn informasjon dukker opp Side 18 av 31

19 Gjenta dette inntil man er ferdig med å velge ut relevant informasjon Deretter kan man skrive ute en rapport med den valgte informasjonen (kartutsnitt med sterkt redusert innhold). Dette er en typisk veiledningsfunksjonalitet eller wizard. Uttak av ny teig Uttak av ny teig gjøres svært mange ganger i løpet av en leteaksjon. Dette er kanskje den oppgaven som tar mest tid i løpet av hele aksjonen. Systemet må derfor være optimalisert for å støtte denne oppgaven. Oppgaven innebærer å: Tegne teig på kart og gi den et unikt navn. Teigen bør kunne snappes til relevante lendegjenstander (kanten av et vann, en sti eller vei) og skraveres. Her kan en dialogboks automatisk dukke opp der søkemetode kan tilordnes og eventuell annen kravspesifikasjon samt hvilket lag som skal utføre oppdraget (gjøres i samråd eller av sambandsleder). Hvis man dobbeltklikker på teigen vil dialogboksen dukke opp på nytt. Teigen må kunne gjøres om til waypoint, eventuelt en rute som kan lastes ned i en GPS. Dette er en typisk veiledningsfunksjonalitet eller wizard. Utskrift av søksoppdrag Utskrift av søksoppdrag er en viktig funksjonalitet. Når oppdraget er ferdig og lag er tilordnet skal man kunne skrive ut oppdraget. Utskriften skal inneholde et relevant kartutsnitt med rutetilvisning og rutenett. I utgangspunktet skal forholdet være 1:50000, 1:25000 eller én av de vanlige forholdstallene til orienteringskart. Dette er en typisk veiledningsfunksjonalitet eller wizard. Annen relevant informasjon som kan komme med automatisk er værvarsling for det aktuelle området. Hvis systemet er koblet opp mot metrologisk institutt vil det være mulig å hente ned værhistorikk og værvarsel for det aktuelle området automatisk. Skredfarevurdering Dette er et stor fagfelt. Systemet må kunne hente inn grunnlagsdata for skredfarevurdering. 4.4 Sambandsleder Stikkordene for sambandslederen var kommunikasjon og iverksetting. Sambandslederen må til enhver tid kunne iverksette det mest optimale oppdraget og løse logistikk utfordringer på en hensiktmessig måte. Dette vil si at Sambandslederen må ha en god oversikt over oppdragets tilstand (plassering av enheter, type ressurs og oppgaver med tilhørende prioriteringer). Videre må Sambandslederen ha et godt radiosamband for å sende og motta informasjon. Sambandslederen oppgaver er: Lede sambandstjenesten i KO Dekningsanalyse og radionett-planlegging Side 19 av 31

20 Skaffe god radiodekning i søkeområdene og tilførselsveier. Resultatkart Sambandslogg (audio og data-logg) Sanntids sporing av enheter (arkivering av sporlogger) Nedlasting og opplasting av GPS data direkte fra/til GPS Sette opp datanettverk og annen infrastruktur i KO, inkludert ekstern kommunikasjon Systemet må støtte disse oppgavene på en hensiktsmessig måte. 4.5 Sammensatte funksjoner Siden data er lagret sentralt og delt med andre kan man se for seg følgende scenario. Nestleder produserer søksoppdrag og legger disse i en felles buffer. Søksoppdraget har nå status som klar for tildeling. Sambandslederen tilordner søksoppdrag etter prioritet og logistikkvurderinger. Søksoppdraget endrer status til i søk. Etter hvert som søksoppdragene er utført registrer Sambandslederen dette. Søksoppdraget endrer status til utført. Slik kommuniserer nestleder og sambandslederen via systemet på en effektiv og enkel måte. Systemet må på en enkel måte kunne vise søksteiger som er klar for tildeling, i søk og utførte. Figur 4 presenterer et forslag på hvordan dette kan gjøres. Har kan man velge å vise en eller flere lag samtidig ved hjelp av ett klikk. Samtidig er denne funksjonaliteten samlet på ett sted og tett knyttet til informasjon den skal vise. Kartdata Klar I søk Utført Figur 4 forslag til layout for teig administrasjon Det finnes flere andre lignende sammensatte oppgaver, men vi venter med å definere disse til senere i prosessen. 4.6 Konseptuel funksjonalitet Database Samhandling og drift fordrer en database i bunnen som knytter sammen tidsrelaterte data med geografiske data og ressursoversikter. Oppdatering, rapportering og statusvising må kunne gå fortløpende og i et flerbruker-miljø. Data skal være tilgjengelig både lokalt på KO og til eksterne kunder og leverandører av typen HRS, LRS, NRKH og andre ressurser og samarbeidspartnere. Side 20 av 31