A Åpen. Rapport. Fartsmodell for næringslivets transporter. Systemering. Forfattere Ola Rennemo og Trude Tørset

Transkript

1 A Åpen Rapport Fartsmodell for næringslivets transporter. Systemering Forfattere Ola Rennemo og Trude Tørset SINTEF Teknologi og samfunn Transportforskning 1. september 2011

2

3

4

5

6

7

8 VI

9 Sammendrag Behovsanalysen i prosjektet Fartsmodell for næringslivets transporter er gjennomgått med tanke på systemering. Generelle krav til Fartsmodellen som en fungerende beregningsmodell er avledet ut fra behovsanalysen, og dokumentert i denne rapporten. Brukerkrav i denne sammenhengen er altså brukerkrav fra andre systemer. Ut fra disse er en systemarkitektur avledet, i form av nødvendig funksjonalitet, overordnet datastruktur og en mulig komponentinndeling. Dette oppsummeres i et sett av systemkrav som må oppfylles for at Fartsmodellen skal kunne fungere i en større sammenheng. VII

10 VIII

11 Innholdsfortegnelse 1 Innledning Om Fartsmodellen og informasjonsflyten knyttet til denne Systemeringsarbeidet i Fartsmodellprosjektet Tilgrensende prosjekt Metodikk Perspektiver som beskriver systemet Systemkrav Noen definisjoner fra ARKTRANS Brukstilfeller og krav fra behovsanalysen Flåtestyring Reiseplanlegging og bilnavigasjon i kjøretøyet Drivstofforbruk og utslippsberegninger Trafikksikkerhet Drift, vedlikehold, trafikkavvikling Overordnet planlegging Oppsummering av krav fra brukstilfellene Funksjonsperspektiv Roller Brukerkrav Brukstilfelle Beregning av kjørefart Prosessperspektiv Informasjonsperspektiv Komponentperspektiv ROSATTE Om deling av grunnlagsdata mellom Fartsmodell og FmBruker Bruk av separate datasett Bruk av felles datasett Systemkrav Konklusjoner Referanser IX

12 X

13 1 Innledning Dette dokumentet er resultatet av arbeidspakke 2 i Fartsmodellprosjektet, systemering. Det skal fungere som en overordnet spesifikasjon for konkrete implementeringer. Fartsmodellen kan inngå i mange sammenhenger, og implementeres på mange måter. Det er derfor ikke snakk om å spesifisere ett bestemt system, men å definere et sett av felles retningslinjer. Denne arbeidspakken var ment å bygge på resultatene fra et EU-prosjekt som både SINTEF og Statens vegvesen har deltatt aktivt i: Road Safety Attributes med akronymet ROSATTE, men ROSATTE-prosjektet har ikke nådd langt nok hverken når det gjelder datamodell eller funksjonalitet til at det ble 1 direkte nyttig her. ROSATTE kan, hvis det realiseres som planlagt, fungere som en universell datakilde for Fartsmodellen. Men som dette dokumentet viser, er kanskje de største utfordringene knyttet til sammenkoblingen mellom Fartsmodellen og de systemene hvor den er ment å inngå. Fartsmodellprosjektet har hatt begrenset tid til rådighet, samtidig som de omkringliggende systemene er mange og omfattende. Figuren på forsiden av denne rapporten illustrerer dette. Det har derfor vært nødvendig å holde gjennomgangen av disse på et overordnet nivå, uten å gå inn på hvordan de enkelte grensesnittete bør se ut. Figuren på forsiden skisserer sammenhengen mellom brukere, dataflyt og beregningsmodellen. Tilgjengelig datagrunnlag og behovsanalyse er beskrevet av Børnes og Tørset, (2011), mens anvendte data og modelleringen er dokumentert i Tørset m. fl. (2011). 1.1 Om Fartsmodellen og informasjonsflyten knyttet til denne Fartsmodellen er en beregningsrutine som beregner forventet fart for tunge kjøretøy på veger utenom bystrøk. Fartsmodellen sine beregninger tar utgangspunkt i vegnettsbeskrivelser hentet fra den Norske Vegdatabanken (NVDB). For enkelte bruksområder er det også aktuelt å oppgi andre brukerbestemte inngangsdata. Dette gjelder for eksempel ved beregning av forventet fart for et bestemt kjøretøy med kjent motoreffekt og totalvekt. Når disse dataene ikke er kjent benyttes gjennomsnittstall i beregningene. Fartsmodellen har flere ulike bruksområder, med grunnlag for friflytfart (gjennomsnittsfart uten påvirkning fra annen trafikk) til modellberegninger, navigasjonssystemer og flåtestyring som eksempler. Beregnet fart på enkeltlenker eller vegstrekninger kan være inngangsdata til andre programsystem. Samtidig vil datagrunnlaget også inneholde informasjon som har en egenverdi å videreformidle, for eksempel fartsgrensen. Det kan derfor også lages systemer for å videreformidle informasjon fra datagrunnlaget som fartsmodellen bygger på. De ulike bruksområdene som vi har bygget på i prosjektet, er diskutert i Børnes og Tørset (2011). Fartsmodellen som er utviklet i prosjektet er ikke tilrettelagt eller tilpasset de ulike bruksområdene, men kan tas i bruk som et utgangspunkt og videreutvikles til flere typer bruksområder. Fartsmodellen beregner forventet fart på enkeltlenker. Før vi kan gjøre beregninger med fartsmodellen, må vi derfor definere hvilke lenker som skal inngå i ruten fra startpunkt til målpunkt. Rekkefølgen på lenkene som inngår i ruten er også viktig, siden deler av beregningen benytter starthastigheten på lenken som inngangsdata til fartsberegningen for gjeldende lenke. Utvikling av rutevalgsalgoritmer har ikke vært en del av prosjektet, men fartsmodellen er egnet til å inngå i kostnadsfunksjoner som ligger til grunn for rutevalgsalgoritmer

14 I Figur 1 er det vist hvordan informasjonsflyten går inn og ut av fartsmodellen. Rutevalget må først være bestemt og det (OD info) gis inn til NVDB for å dele opp vegnettet langs ruten i homogene lenker. Oppdelingen av vegnettet kalles for segmentering. Rutinene for segmenteringen er beskrevet i Tørset m. fl. (2011). Deretter knyttes vegstandarddata fra NVDB til de aktuelle lenkene. Lenker med vegstandarddata og eventuelt turspesifikke data (vekt, motoreffekt) kobles til dersom det skal beregnes for en spesiell tur. Ellers brukes gjennomsnittsverdier. Fartsmodellen (FM) beregner reisetid for hver enkelt lenke basert på vegstandarddata og eventuelt turspesifikke data. Reisetid på ruten kan brukes for de enkelte bruksområdene sammen med annet informasjonsgrunnlag, enten fra NVDB eller fra andre steder. Reisetiden fra start til målpunkt vil også kunne være påvirket av andre forhold enn reisetiden på de enkelte veglenkene. For eksempel vil kjøre- og hviletidsreglementet, som regulerer hvor lenge sjåførene kan kjøre uten pause, ha betydning for leveransetidspunktet for godstransport. Andre forhold kan være knyttet til driftsforholdene i vegnettet, for eksempel midlertidige vegstengninger eller vegarbeid som for en periode hindrer alminnelig framkommelighet på vegnettet. For enkelte bruksområder vil denne typen informasjon også kunne inngå i informasjonsstrømmene. Rute eller ruter OD info Barrierer, hindringer Semi-dynamiske /dynamiske data NVDB Vegstandarddata for enkeltlenker Biltype og vekt Firmainfo Loven FM Reisetid på enkeltlenker eller rute BRUKSOMRÅDER Figur 1: Datakilder og dataflyt ved bruk av Fartsmodellen 1.2 Systemeringsarbeidet i Fartsmodellprosjektet I fartsmodellprosjektet er det gjennomført en behovsanalyse med utgangspunkt i sluttbrukersituasjoner (Børnes og Tørset, 2011). Analysen er gjort ut fra behovene til deltakerne i prosjektet, primært Statens vegvesen, Tollpost Globe og MapSolutions. Behovsanalysen har vært førende for utvikling av beregningsmodellen, men hvilke variabler som er tatt i bruk har vært styrt av datatilgjengelighet og kvaliteten på tilgjengelige data. For å dekke brukerbehovene som ble identifisert i behovsanalysen, må det gjøres en videreutvikling eller tilrettelegging for hvert bruksområde. Det er heller ikke laget et 2

15 brukergrensesnitt som er tilpasset ulike bruksområder. Det er også noe som må produseres i forbindelse med at fartsmodellen implementeres i ulike system. Systemering er den første fasen i en systemutvikling. I systemeringsfasen oversettes og bearbeides krav fra behovsanalysen til funksjoner og informasjonsmodeller som siden blir spesifikasjoner på programenheter og datastrukturer, samt grensesnitt mellom bruker og program og mellom programmoduler. Systemeringen i fartsmodellprosjektet bygger på behovsanalysen som er gjennomført i prosjektet og tolker og detaljerer krav til dataflyt og beregningsgangen for hver av de viktigste bruksområdene. Dette vil være et utgangspunkt for arbeidet med å videreutvikle fartsmodellen og implementere den i de ulike systemene hvor den er tenkt å inngå. Selve regnemetoden er dokumentert i rapporten Datagrunnlag og beregningsrutiner for Fartsmodellen (Tørset m. fl., 2011). I sin nåværende form tar den ikke hensyn til alle faktorer som ble vurdert i starten av prosjektet, som vær, føre, trafikktetthet, hendelser mm. Siden disse faktorene er med i behovsanalysen, og opplagt har praktisk betydning, bør tilgang til disse dataene (som altså ikke er i bruk i dag) likevel bli med i vurderingen av hva slags system som dekker behovene som er identifisert. 1.3 Tilgrensende prosjekt ROSATTE 2 er et EU-prosjekt som beskriver og demonstrerer hvordan vegrelatert informasjon kan formidles automatisk fra lokale vedtaksmyndigheter og ut til de enkelte bilførernes navigasjonsenheter. Det gjøres ved hjelp av universelle vegreferanser, felles grensesnitt og felles datastrukturer, og kan dermed formidles likt til forskjellige brukere på tvers av lendegrenser. Denne infrastrukturen kan med andre ord være en universell leverandør av grunnlagsdata til en fartsmodell. Infrastrukturen kan også brukes til å formidle resultatene fra en fartsmodell til andre systemer som trenger dem

16 2 Metodikk Dette er en kort generell beskrivelse av metodikken som er brukt i dette systemeringsarbeidet. Det vil sannsynligvis ikke programmeres bare ett programsystem som dekker alle bruksområder for Fartsmodellen. Det er mer sannsynlig at Fartsmodellen implementeres i ulike programsystem tilpasset hvert enkelt bruksområde. I dette kapitelet har man imidlertid tatt utgangspunkt i at systemet er et felles produkt som vil dekke alle bruksområdene. På denne måten ser man sammenhengen mellom de ulike bruksområdene med tanke på krav til datagrunnlag og resultat. 2.1 Perspektiver som beskriver systemet Vi bruker et sett av perspektiver for å beskrive systemet. Disse er inspirert av retningslinjene i rammeverket ARKTRANS 3. Innefor disse beskrives de ulike elementene med begreper og symboler hentet fra Unified Modeling Language (UML) 4. Hvert av perspektivene beskriver ulike sider av det vi kaller systemarkitekturen. Det blir altså ikke laget ett altomfattende kart, noe som ville blitt veldig uoversiktig, men heller spesialiserte presentasjoner for å beskrive viktige egenskaper langs de forskjellige dimensjonene. Det brukes forskjellige metoder og figurer i de forskjellige perspektivene, men de er likevel logisk bundet sammen. Denne rapporten gir en beskrivelse av følgende perspektiv, som beskriver datasystemet med økende detaljeringsgrad: Funksjonsperspektivet er en overordnet beskrivelse av hva systemet gjør, sett fra et brukerståsted. Det fokuserer på de elementene som leverer systemets funksjonalitet, dvs. interne og eksterne aktører, deres roller, og brukerkravene. Prosessperspektivet detaljerer brukstilfellene ved å identifisere kombinasjoner av roller, funksjonalitet og tilhørende informasjon/dataoverføring. Prosessperspektivet brukes for å avklare sekvenser, ansvarsforhold og informasjonsflyten mellom rollene. Informasjonsperspektivet beskriver informasjonselementene som brukes av systemet, og spesifiserer innholdet i dataene som overføres mellom delsystemene. Informasjonselementene blir ofte identifisert i prosessperspektivet, når forholdet mellom funksjonaliteter og roller blir vist. Informasjonsperspektivet sier ingenting om hvordan implementeringen gjøres, men det definerer de viktigste informasjonselementene, og sammenhengen mellom dem. Komponentperspektivet gir forslag til hvordan et fungerende system kan struktureres. Dette er en konkretisering av de tre første punktene, og resulterer i en fysisk inndeling av systemet, og dataflyten mellom delene. I prosjektplanen er målet med prosjektet skissert. Det gir rammer for en overordnet beskrivelse av hva fartsmodellen skal gjøre og hvilke behov den skal fylle. Behovsanalysen er med på å avdekke de mer konkrete behovene for ulike bruksområder og i kapittel 3 side 6 er disse brutt ned til type funksjonalitet som er etterspurt, hvilke operasjoner som må gjøres og i hvilken rekkefølge. I fartsmodellprosjektet er det laget ferdig en modell som dekker noen av bruksområdene gitt ut fra et funksjonsperspektiv slik den framstår nå, men fartsmodellen må eventuelt utvikles videre for å dekke alle

17 I denne rapporten er det tenkt videre på hva som må til for å ta i bruk den produserte fartsmodellen, og i den forbindelse er det identifisert hvordan systemet må bygges opp ut fra et prosessperspektiv. Dette er illustrert i Figur 4 side 18. I kapittel 6 side 20 er de praktiske utfordringene med å sikre datagrunnlag sett i sammenheng med et EUprosjekt som involverer flere av partnerne i fartsmodellprosjektet: ROSATTE. Målsettingen i ROSATTE er å bygge opp et system for å kunne bidra med datagrunnlag til bruk i sikkerhetsapplikasjoner på tvers av landegrensene i Europa. Det er naturlig at data til og fra fartsmodellen ses i sammenheng med de rutiner som utvikles i ROSATTE. 2.2 Systemkrav Systemkravene avledes fra de nevnte 4 perspektivene, og beskriver hva som skal til for at systemet skal kunne oppfylle brukerkravene. Systemkravene, som presenteres nærmere i kapittel 8 på side 26, deles ofte inn i funksjonelle krav, ikke-funksjonelle krav, og omgivelseskrav: Funksjonelle krav spesifiserer funksjonaliteten som forventes av et fungerende system. Ikke-funksjonelle krav spesifiserer krav til ytelser og kvaliteter. Omgivelseskrav spesifiserer både krav som følger av kjente begrensningene fra omgivelsene, og krav til omgivelsene for at systemet skal fungere. 2.3 Noen definisjoner fra ARKTRANS Definisjonene under er hentet fra ARKTRANS. ARKTRANS er basert på UML, og gir retningslinjer for bruk av begreper knyttet til transportsystemer. En aktør er en person, organisasjon, system eller delsystem som bruker eller brukes av systemet. En bruker (FmBruker) er en aktør som er ekstern i forhold til systemet. Alle aktører har en eller flere roller. En rolle representerer et ansvarsområde, som kan være felles for flere aktører. Brukerkrav kommer fra brukerne, og er fullstendig brukerorienterte. De kan formidles både gjennom figurer, formelle spesifikasjoner og prosatekst, og uttrykker det som forventes av systemet, og hvilke forutsetninger og begrensninger som gjelder. Et brukstilfelle kan defineres som en serie interaksjoner med systemet, for å utføre en oppgave. Et brukstilfelle utgjør en delmengde av systemets funksjonalitet, uten at man tar hensyn til indre strukturer. Sum av brukstilfellene representerer hele systemets funksjonalitet. 5

18 3 Brukstilfeller og krav fra behovsanalysen I dette kapitlet presenteres en gjennomgang av brukstilfellene som ble identifisert i Behovsanalysen for Fartsmodellprosjektet (Børnes og Tørset, 2011). Brukstilfellene ble der gruppert innenfor seks hovedanvendelsesområder: 1. Flåtestyring 2. Reiseplanlegging og bilnavigasjon 3. Drivstofforbruk og utslippsberegning 4. Trafikksikkerhet 5. Drift, vedlikehold, trafikkavvikling 6. Overordnet planlegging Figur 2: Primære brukstilfeller fra behovsanalysen 6

19 Figur 2 viser den overordnede sammenhengen mellom Fartsmodellen og de primære eksterne brukstilfellene (hovedanvendelsesområdene). Fartsmodellen er her representert ved boblen Beregn kjørefart, som inkluderer selve Fartsmodellen, dens datakilder og beregningene som utføres. De eksterne brukstilfellene dreier seg om å administrere og igangsette beregninger og tilleggsberegninger, og å formidle resultatene slik at de passer inn i anvendelsesområdene. Selv om disse anvendelsesområdene ligger utenfor Fartsmodellprosjektet, vil de likevel påvirke det, siden Fartsmodellen skal kunne kommunisere med de ulike eksterne anvendelsesområdene, med utveksling av data og beregningsresultater. Figuren visen også hvilke typer brukere/aktører/roller som etterspør de ulike anvendelsesområdene (fyrstikkfigurene). Merk at disse fyrstikk-figurene kan representere både personer og systemer, og at linjene mellom disse og brukstilfelle-boblene kan illustrere avhengighet begge veier. Aktørene ISA og Reiseplanlegger bruker Fartsmodellen (Beregn kjørefart) direkte. I dette ligger en antagelse om at de kan tilpasse seg Fartsmodellen direkte. Det er hele tiden en forutsetning at kjøretiden beregnes på en sekvens av lenker. Rutevalgsalgoritmen er ikke en del av Fartsmodellen, men Fartsmodellen kan være et grunnlag for en rutevalgsalgoritme. I de følgende delkapitlene er hvert av de seks hovedanvendelsesområdene eller primære brukstilfellene presentert litt nærmere. Det ligger ikke innenfor prosjektet å beskrive dataflyten mellom Fartsmodellen og de ulike anvendelsesområdene i detalj. Gjennomgangen er derfor kortfattet, og bør leses sammen med behovsanalysen. Der hvor punktene er merket BTxx, refereres det direkte til brukstilfellene i behovsanalysen. Beskrivelsen begrenser seg til et mulig forløp for deloppgaver og kommunikasjon mellom Fartsmodellen og de eksterne systemene, og identifisering av hvilke krav dette stiller til Fartsmodellen. De forutsetninger og krav som kommer frem her, utgjør grunnlaget for beskrivelsen av brukerkrav til datasystem som presenteres i kapittel 4.2 Brukerkrav side 15. I prinsippet kan kravene omfatte funksjonelle, ikke-funksjonelle og omgivelseskrav slik disse er definert i kapittel 5, men på dette detaljeringsnivået er det fokusert på funksjonskravene. 7

20 3.1 Flåtestyring Flåtestyringsverktøy benytter informasjon om fartsnivå og reisetid i det norske vegnettet. Fartsmodellen skal gjøre denne informasjonen riktigere, ved at det tas hensyn til faktorer som vegstandard, trafikk, føreforhold osv. Tabell 1: Detaljering av anvendelsesområdet Flåtestyring Type funksjonalitet / operasjon og forløp Konfigurér bruk Beskrivelse Bruker definerer kjøretøydata og beregningsmåte: type kjøretøy, mål, vekt, effekt reisetid med eller uten hviletid generelt tidspunkt eller spesifikt tidspunkt Kan eventuelt inkludere faktorer som: timetrafikk vær, føre Det skal være mulig å angi direkte at en veglenke er stengt/ ikke skal brukes. (I tilfelle dette ikke ligger i datagrunnlaget) Hvis starttidspunkt med dato er kjent, kan kortvarige stegninger og førevarsler inkluderes i reisetidsberegningen. Finn korteste veg Flåtestyringssystemet finner korteste veg på vanlig måte, eventuelt med via-punkter, basert på antatt reisetid. Startverdier på reisetid er oftest avledet fra skiltet hastighet. Veglenker langs korteste veg etterberegnes av fartsmodellen, og nye lenkevise reisetider lagres tilbake i datasettet. Hvis noen av lenkene langs korteste veg får økt reisetid i forhold til utgangspunktet, må flåtestyringssystemet beregne korteste vei på nytt. Dette fortsetter inntil ingen av lenkene langs korteste vei har fått økt reisetid. Lag kjøreplan (BT11) En serie korteste veg-beregninger, som beskrevet over, med kjøretøydata, hviletidsbestemmelser, via-punkter, starttidspunkt, laste-/losse-steder og tilhørende tidspunkter. Bruk av klokkeslett gjør at trafikkdata, føremeldinger og fergeruter kan inkluderes etter ønske. Dokumentér kjøreplan Kjøreplaner kan gis navn og dokumenteres, slik at det er mulig å sammenligne alternativer. Brukstilfellene BT12, BT13 og BT14 synes å være varianter over samme funksjon. Reiseplanlegging som foregår i forkant av selve reisen inngår her. Avledede funksjonelle systemkrav: Forløpet forutsetter at Fartsmodellen må være integrert mot flåtestyringssystemet. Det vil i praksis si at enten må fartsmodellen tilpasses dette og etterbehandle datasettet, eller så må bruk av fartsmodellen inngå direkte i flåtestyringssystemet. Det siste er å foretrekke, siden det eller ellers blir vanskelig å lage gode beregningsrutiner og oppdateringsrutiner. Fartsmodellen må kunne konfigureres av bruker før start, og resultatene må være knyttet til denne konfigurasjonen. Fartsmodellen må kunne ta imot en vilkårlig lang sekvens av lenkereferanser, beregne kjørefart på disse, og formidle resultatene. Etter kjøring skal det fremgå hvilke av lenkene som eventuelt har fått lengre kjøretid. 8

21 3.2 Reiseplanlegging og bilnavigasjon i kjøretøyet Reiseplanlegging og bilnavigasjon som foregår i hvert enkelt kjøretøy, styres av den enkelte sjåfør. Tabell 2: Detaljering av anvendelsesområdet "Reiseplanlegging og bilnavigasjon" Type funksjonalitet / operasjon og forløp Konfigurér bruk Beskrivelse Bruker definerer kjøretøydata og beregningsmåte: type kjøretøy, mål, vekt, effekt reisetid med eller uten hviletid generelt tidspunkt (tidsangivelse som gjentas: for eksempel hver mandag klokken 15 ) eller spesifikt tidspunkt (klokkeslett på en bestemt dato: for eksempel mandag 7. mars 2011 klokken 15) Kan eventuelt inkludere faktorer som: timetrafikk vær, føre Det skal være mulig å angi direkte at en veglenke er stengt/ ikke skal brukes, i tilfelle bruker har opplysninger som ennå ikke ligger i datagrunnlaget. Hvis starttidspunkt er kjent, d.v.s. spesifikt tidspunkt gitt, kan kortvarige stegninger og førevarsler inkluderes i reisetidsberegningen, d.v.s. bruk av dynamiske data. Dynamiske data må leses direkte fra webtjenester. Datagrunnlag Finn raskeste veg (BT21, BT22) Navigasjonsenheter bruker stort sett telenettet for oppdatering underveis. Siden datasettene kan være store, vil inkrementell oppdatering være nødvendig. Oppdatering av dynamiske data bør skje så direkte som mulig, men likevel avgrenset i omfag p.g.a. kostnader og båndbredde. Navigasjonssystemet finner raskeste veg på vanlig måte, eventuelt med viapunkter, basert på antatt reisetid.(startverdiene er avledet fra skiltet hastighet.) Veglenker langs korteste veg etterberegnes av fartsmodellen, og nye lenkevise reisetider lagres tilbake i datasettet. Hvis noen av lenkene langs korteste veg får økt reisetid i forhold til utgangspunktet, må flåtestyringssystemet beregne korteste vei på nytt. Dette fortsetter inntil ingen av lenkene langs korteste vei har fått økt reisetid. Fartsmodellen skal gi realistisk tidsstraff på lenker som er uegnede for det gitte kjøretøyet, eller sperre dem helt for bruk. Reisetid som økes på denne måten bør forklares for bruker. Det ligger i dette at Fartsmodellen beregninger oppdaterer de samme lenkevise reisetidene som navigasjonsenhetens rutevalgsalgoritme benytter. Raskeste veg for utenlandsk tungbil (BT23) I prinsippet som beskrevet ovenfor, men oppdateringer og meldinger direkte fra norske myndigheter må formidles med universelle vegreferanser. Det vil si vegreferanser som kan tolkes direkte av ulike navigasjonsenheter, eller av navigasjonsenhetens kartleverandør. (Med direkte oppdatering menes en raskere oppdatering enn det som er mulig med kartleverandørens egne datainnsamlingsrutiner.) Avledede funksjonelle systemkrav: Fartsmodellen må konfigureres for det aktuelle kjøretøyet, men bare én gang. Bruk av Fartsmodellen må være integrert i navigasjonssystemets rutevalgsfunksjon, slik at økte reisetider påvirker rutevalget direkte, uten inngrep fra bruker eller lange ventetider. 9

22 Etter kjøring skal det fremgå hvilke av lenkene som eventuelt har fått vesentlig kjøretid. Navigasjonsenheten trenger inkrementell oppdatering underveis. Bruk av dynamiske data kan bli nødvendig, men må i så fall begrenses i omfang, og være knyttet til lenkene. Data som endres ofte må formidles til kartleverandør eller trafikant med universelle vegreferanser. 3.3 Drivstofforbruk og utslippsberegninger Dette brukstilfellet handler om et planlagt verktøy for beregning av drivstofforbruk og utslipp. Inndata for dette verktøyet ligger tett opptil fartsmodellens inndata. Tabell 3: Detaljering av anvendelsesområdet Drivstofforbruk og utslippsberegninger Type funksjonalitet / operasjon og forløp Konfigurér bruk Beskrivelse Bruker definerer kjøretøydata og beregningsmåte: type kjøretøy, mål, vekt, effekt, virkningsgrad Generelt tidspunkt benyttes, d.v.s. bruker sesong / gjennomsnittstall / statistikk som inngangsdata. Kan eventuelt inkludere faktorer som timetrafikk vær, føre Beregn drivstofforbruk (BT31) Beregningsverktøyet finner raskeste veg på vanlig måte, eventuelt med via-punkter, basert på antatt reisetid.(startverdiene kan være avledet fra skiltet hastighet.) Veglenker langs raskeste veg etterberegnes av fartsmodellen, og nye lenkevise reisetider lagres. Hvis noen av lenkene langs korteste veg får økt reisetid, må beregningsverktøyet beregne korteste vei på nytt. Lenker langs ny korteste veg får reisetid beregnet på nytt, o.s.v., inntil alle ingen av lenker langs korteste vei har fått økt reisetid. Lenkedataene oppdateres med forbrukstall avledet fra fartsmodellens fartsprofil og en kjøretøymodell. Beregnede ruter henger sammen logisk, og tids- og forbrukstall kan summeres langs strekningene. Transportkostnader (BT32, BT33) Flere alternative ruter kan beregnes som over, og resultatene eksporteres til andre beregningsverktøy. Avledede funksjonelle systemkrav: Fartsmodellen må være integrert i beregningsverktøyets rutevalgsfunksjon. Fartsmodellen og beregningsverktøyet deler flere grunnlagsdata. Det er generelt en kilde til feil å håndtere flere kopier av de samme informasjonsbitene i et system. Isteden for å ha egne kopier av kjøretøy- og lenkedata, bør Fartsmodellen kunne konfigureres til å gjenbruke tilsvarende data fra beregningsverkøyet den inngår i. Etter kjøring skal det fremgå hvem av lenkene som eventuelt har fått vesentlig lengre kjøretid enn det som basisfarten gir. 10

23 3.4 Trafikksikkerhet Tabell 4: Detaljering av anvendelsesområdet Trafikksikkerhet Type funksjonalitet / operasjon og forløp Konfigurér bruk Beskrivelse Bruker definerer kjøretøydata og beregningsmåte: type kjøretøy, mål, vekt, effekt Generelt tidspunkt benyttes, d.v.s. bruker sesong / gjennomsnittstall / statistikk som inngangsdata. Kan eventuelt inkludere faktorer som timetrafikk vær, føre Det skal være mulig å angi direkte at en veglenke er stengt/ ikke skal brukes. (I tilfelle dette ennå ikke ligger i datagrunnlaget) Sikker fart og risiko (BT41, BT42) Transportkostnader (BT32, BT33) I et evalueringsverktøy, helst kartbasert, definerer bruker en rute interaktivt, og bruker fartsmodellen til å beregne denne. Samme rute kan gjenbrukes i flere scenarier, hvor ulike føre- og kjøretøyskombinasjoner brukes. En kjøretøymodell beregner resulterende sidekrefter og parallellkrefter, samt tilgjengelige friksjonskrefter fra underlaget, og lagrer resultatene lenkevis. Sikkerhetsmarginen, d.v.s. forskjell mellom beregnet fart og kritisk fart, kan i illustreres i kart, og brukes som grunnlag for ny skilting. Flere alternative ruter kan beregnes som over, og resultatene eksporteres til andre beregningsverktøy. Avledede funksjonelle systemkrav: Fartsmodellen må være integrert i evalueringsverktøyet, slik at riktige ruter blir beregnet. Fartsmodellen og beregningsverktøyet deler flere grunnlagsdata. Det er generelt en kilde til feil å håndtere flere kopier av de samme informasjonsbitene i et system. Isteden for å ha egne kopier av kjøretøy- og lenkedata, bør Fartsmodellen kunne konfigureres til å gjenbruke tilsvarende data fra beregningsverkøyet den inngår i. 11

24 3.5 Drift, vedlikehold, trafikkavvikling I forbindelse med drift og vedlikehold skal fremkommelighet vurderes med ulike forutsetninger. Tabell 5: Detaljering av anvendelsesområdet Drift og vedlikehold Type funksjonalitet / operasjon og forløp Spesifisér veglenker Konfigurér bruk Beskrivelse I et kart definerer bruker hvilke veglenker som skal vurderes. Bruker definerer forutsetninger: type kjøretøy, mål, vekt sikt/vær, friksjon restriksjoner, stengninger m.m. Generell tidsangivelse, og da kan variasjonskurver for trafikkmengder inngå Det skal være mulig å angi direkte at en veglenke er stengt/ ikke skal brukes. (I tilfelle dette ennå ikke ligger i datagrunnlaget) Forsinkelser ved vegarbeid (BT-51) Vedlikeholdsstandard vinter (BT-52) Trafikkstyring (BT-53) Evalueringsverktøy finner korteste veg, eventuelt med via-punkter, basert på antatt reisetid.(startverdiene er avledet fra skiltet hastighet.) Hvis noen av lenkene langs korteste veg får økt reisetid, må verktøyet beregne korteste vei på nytt. Lenker langs ny korteste veg får reisetid beregnet på nytt, o.s.v., inntil alle ingen av lenker langs korteste vei har fått økt reisetid. Alternativer kan sammenlignes. Ved å definere alternative føreforhold på lenker, kan sammenligninger gjøres og tidskostnader vurderes. Som foregående tilfeller, ved å kjøre flere alternativer basert på ulike forutsetninger. Avledede funksjonelle systemkrav: Fartsmodellen må være integrert i evalueringsverktøyet, slik at riktige ruter blir beregnet. Fartsmodellen og beregningsverktøyet deler flere grunnlagsdata. Det er generelt en kilde til feil å håndtere flere kopier av de samme informasjonsbitene i et system. Isteden for å ha egne kopier av kjøretøy- og lenkedata, bør Fartsmodellen kunne konfigureres til å gjenbruke tilsvarende data fra beregningsverkøyet den inngår i. 3.6 Overordnet planlegging Det er flere aktuelle verktøy for overordnet planlegging, som alle deler opp vegnettet på sin egen måte. Komponent for kjørefart må derfor kunne ta imot og behandle lenker definert som fra- til vegreferanse. I tillegg trenger den en del opplysninger som ofte ikke er tilgjengelige i planleggingsverktøyets datasett. Etterfølgende beskriver et iterativt forløp, hvor fartsmodellberegningen kan føre til nye beregninger i planverktøyet. 12

25 Tabell 6: Detaljering av anvendelsesområdet Overordnet planlegging Type funksjonalitet / operasjon og forløp Konfigurér fartsmodellkomponent Beskrivelse Bruker angir: gyldighetsperiode (år / sesong / døgn / time) stoppkriterier modellverktøy prosjektdatasett med lenkedefinisjoner, m.m. (Kan være tekstfiler, databasekobling, webservice eller annet) Brukeren kan velge mellom å få beregnet friflytfart eller forventet fart. Oppdatér prosjektdata Beregn Rapportér Modellverktøy startes og kjører sine beregninger på datasettet. Deretter kalles brukstilfelle Beregn. Inndata leses fra prosjektfil og konfigurasjon. Alle nødvendige data skrives til beregningskomponent. Fartsmodellen beregner reisetider på valgte ruter. Etter beregning skrives nye lenkehastigheter tilbake til datasettet. Hvis stoppkriterium er oppfylt, kalles brukstilfelle Rapporter. Hvis ikke, kalles brukstilfelle Oppdater prosjektdata på nytt. Systemet lager og viser en rapport for den ferdige beregningen. I rapporten inngår de aktuelle konfigurasjonsdata, slik at beregningene kan gjentas på et senere tidspunkt, med sammenlignbare resultat. Avledede funksjonelle systemkrav: Fartsmodellen og modellverktøyet deler flere grunnlagsdata. Det er generelt en kilde til feil å håndtere flere kopier av de samme informasjonsbitene i et system. I stedet for å ha egne kopier av kjøretøy- og lenkedata, bør Fartsmodellen kunne konfigureres til å gjenbruke tilsvarende data fra beregningsverkøyet den inngår i. Fartsmodellen må kunne tilpasses forskjellige datasett, enten ved omprogrammering, eller med bruk av egne tilpasningsmoduler. 13

26 3.7 Oppsummering av krav fra brukstilfellene De systemene som representerer FmBruker er omtalt, og de har gjennomgående et helt annet faglig fokus enn de ulike datakildene for vegnettet. Vegnettsdata hentes fra NVDB, som er utviklet som en fagdatabase for drift og vedlikehold av vegnettet i Norge. Datastruktur og definisjoner i NVDB er spesialtilpasset til dette bruksområdet, og har derfor bl.a. en lenkedatadefinisjon som ikke sammenfaller med det som er naturlig for andre bruksområder. For eksempel er det ikke lagt inn klotoideparametre, men kun radius for svinger, og av den grunn kan lenkeinndelingen bli en utfordring når vi skal lage homogene lenkeelementer. Skal Fartsmodellen ha praktisk verdi for disse, må datasettene, d.v.s. veglenkene og tilhørende data, være tilrettelagt på forhånd. Erfaringene fra arbeidet med modellering og metodeutvikling (Tørset m. fl., 2011) underbygger dette. Dermed ender vi opp med samme konklusjon som for separate datasett, d.v.s. at datasettet bør være bearbeidet på forhånd. Når det gjelder dynamiske data for en fremtidig utvidet Fartsmodell, kan de best formidles direkte fra eksterne tjenester. Men for mobile varianter av FmBruker må datatrafikken begrenses til et minimum. Dette av hensyn til både trafikkostnader og nødvendig etterbehandling av data. Kravene fra de gjennomgåtte brukstilfellene kan oppsummeres slik: Fartsmodellen bør inngå som en del av FmBrukers rutevalgsalgoritme, og oppdatere dennes datasett direkte. Grunnlagsdata bør tilrettelegges før de leses av FmBruker, med en oppdateringsfrekvens som er passer endringstakten i innholdet. Grunnlagsdataene må ha en lenkeinndeling som ikke glatter ut kurveradier og stigninger som inngår i Fartsmodellen beregninger. Det er nødvendig med inkrementelle oppdateringer av grunnlagsdataene. Data med kort levetid og/eller stor viktighet bør formidles raskere utenom lenkeoppdateringene, og innholdet må samtidig være knyttet direkte til lenkene for å være nyttig i en kjøretidsberegning. Oppdateringer og meldinger fra Norske myndigheter må kunne knyttes til universelt forståtte vegreferanser. Disse kravene kan gjenfinnes som brukerkrav i funksjonsperspektivet. 14

27 4 Funksjonsperspektiv Funksjonsperspektivet gir en overordnet beskrivelse av hva modellen gjør, sett fra et brukerståsted. 4.1 Roller Som nevnt i forrige kapittel, representerer en rolle et ansvarsområde som kan være felles for flere aktører. Hvilke slike roller som kan identifiserer i forbindelse med Fartsmodellen, og eksempler på brukere som etterspør tjenester fra disse rollene, er vist i Tabell 7. Tabell 7: Roller i Fartsmodellen Rolle Definisjon Eksempel på bruker Informasjonstjeneste Tjeneste for levering av veglenker og tilhørende informasjon. TeleAtlas og NavTeq oppdateringstjenester. TRIONA informasjonsplattform (TRIP) Meldingstjeneste Tjeneste for levering av dynamiske data i mindre porsjoner. Fartsmodell Rutiner for beregning av faktisk reisetid langs en rute. FmBruker Fartsmodellens vertssystem som initierer og bruker Fartsmodellens funksjonalitet. Reiseplanlegger, navigasjonsenhet, planleggingsverktøy 4.2 Brukerkrav Behovsanalysen (Børnes og Tørset, 2011) gir en rekke overordnede brukstilfeller hvor Fartsmodellen inngår. I kapittel 3 er hver av disse brukssituasjonene kort beskrevet, sammen med avledede generelle krav fra FmBruker til Fartsmodellen og dens omgivelser. Disse avledede kravene er oppsummert i Tabell 8. Tabell 8: Brukerkrav Nr Navn Beskrivelse 1 Integrasjon FmBruker trenger at Fartsmodellen inngår som en del av dens rutevalgsalgoritme. 2 Datagrunnlag innhold FmBruker trenger ferdige grunnlagsdata fra Informasjonstjensten, d.v.s. passende lenkedefinisjoner med relevante attributter påført. Data som endres ofte må kunne leveres med universelle vegreferanser. 3 Datagrunnlag inndeling Lenkene i datagrunnlaget må være tilpasset bruken, slik at informasjon om geometrien som Fartsmodellen trenger, ikke blir flatet ut. 4 Inkrementell oppdatering FmBruker trenger inkrementelle oppdateringer fra Informasjonstjenesten. 5 Dynamiske data tilgang Hvis dynamiske data inngår, trenger FmBruker å lese disse utenom ordinære oppdateringer. Meldingene er knyttet til lenkene i datagrunnlaget. 6 Dynamiske data begrensning En del FmBrukere er mobile. Derfor må det finnes mekanismer for å avgrense datatrafikken til det som har betydning for den enkelte FmBruker. 15

28 4.3 Brukstilfelle Beregning av kjørefart Her følger en detaljering av brukstilfellet for beregning av kjørefart fra vedlegget. Dette er det overordnede brukstilfellet for Fartsmodellen. Figur 3 viser de fire rollene, (ansvarsområdene) som inngår i Fartsmodellen; Informasjonstjeneste, Meldingstjeneste, Fartsmodell og FmBruker, kfr. Tabell 7: Roller i Fartsmodellen, og hvordan de forholder seg til brukstilfellene som inngår i modellen. Figur 3: Brukstilfelle Beregning av kjørefart i Fartsmodellen; roller 16

29 Tabell 9: Brukstilfeller for "Beregn kjørefart" Navn Datafangst Konfigurasjon Bestilling Beregn basisfart Beregn friflyt fart Resultater Beskrivelse Nødvendige informasjon om veg og tilhørende data hentes fra Informasjonstjenesten etter behov. Lenkene er allerede oppdelt på en passende måte, og påført all nødvendig informasjon. Inkrementelle oppdateringer er mulig basert på f.eks dato for siste oppdatering. Eventuelle dynamiske data kan når som helst leses fra Meldingstjeneste. I praksis starter dette ved at tjenesten først sender en melding til FmBruker når nye relevante data er tilgjengelige. Beregninger må konfigureres av det aktuelle verktøyet, og overføres til Fartsmodellen i forkant av beregningen. Foreløpig er det vekt, effekt og luftmotstand på aktuelt kjøretøy, men på sikt kan den utvides med tidspunkt og nye typer data for trafikk, vær, føre m.m. Referanse til konfigurasjonsdata og rute med lenkeliste overføres. Hvis det ikke er gjort allerede, beregnbasisfart. Siden denne kun er basert på fartsgrensen, kan den beregnes alle lenkene en gang for alle. Med utgangspunkt i basisfart, beregnes reisetid på lenkene i den rekkefølge de er tenkt kjørt. Resultater lagres pr lenke, og reisetid summeres pr rute. Der hvor Fartsmodellen øker reisetiden vesentlig i forhold til basis hastighet, legges en tekstlig forklaring på den aktuelle lenken, som siden kan presenteres for bruker. Lenke- og rutevis kjøretid leses av FmBruker. Der hvor spesielle årsaker gir lengre kjøretid, finnes tekstlige forklaringer knyttet til de aktuelle lenkene. 17

30 5 Prosessperspektiv Prosessperspektivet detaljerer funksjonene og dataoverføringen mellom dem. Prosessperspektivet brukes for å avklare sekvenser, ansvarsforhold og informasjonsflyten mellom rollene. Måten man implementerer fartsmodellen på vil varierer mye avhengig av bruksområdet, derfor er det ikke nødvendigvis kostnadseffektivt å lage en felles tjeneste for alle varianter av beregninger. I sin enkleste form er det kun snakk om å lese fra tabeller, beregne verdier, og å sette inn eller oppdatere rader i en lenkeberegningstabell. Følgende figur fra Tørset m. fl. (2011) illustrerer beregningsforløpet hvor beregningsgangen er sekvensiell og at resultatet av rekken av beregninger blir friflytfarten, dvs fartsnivået upåvirket av annen trafikk. I denne er det også lagt inn henvisninger til foreslått datamodell. FmLenke.fartsgrense Modell: Variabler: Basisfart Fartsgrense FmBeregningResultat.uthastighet(Forrige lenke) FmLenke.vegbredde Vegbreddemodell Basisfart eller fartsnivå fra lenka beregnet av forrige modell Vegbredde FmLenke.hradius FmLenke.vhelning Kjøretøy.EFFEKT Kjøretøy.vekt FmBeregningResultat.reisetid FmBeregningResultat.uthastighet Horisontalkurvemodellen Stigningsmodell Basisfart eller fartsnivå fra lenka beregnet av forrige modell Horisontalkurveradius Basisfart fra fartsgrensen og/eller Startfart fra forrige lenke Stigningsforhold på lenka og lengde Vekt og motoreffekt eller gjennomsnittsverdier Figur 4: Oppbygging av Fartsmodellen og kobling til datamodellen 18

31 Det kan være ønskelig å få tilgang til dynamiske data i fremtiden. I så tilfelle kan det være interessant å lese kapittel 5.2 i ROSATTE - Requirements and Overall Architecture 5. Her beskrives en mulig bruk av abonnementstjeneste for databrukere. Den samme mekanismen er også kommentert i komponentperspektivet i dette dokumentet

32 6 Informasjonsperspektiv Informasjonsperspektivet beskriver informasjonselementene som brukes av systemet og mellom delsystemene, og benyttes for å utarbeide en overordnet spesifikasjon på innholdet og struktur i datasettet. Tabell 10 viser hvilke typer inngangsdata som kreves i Fartsmodellen for å kunne beregne kjøretøyhastighet. Tabell 10: Inngangsdata for beregning av hastighet Navn Spesifikasjon kommentar Horisontalkurvatur Minste horisontalradius i meter. Vertikalkurvatur Helning i % Vegbredde Dekkebredde i meter Kjøretøy Vekt, motoreffekt, høyde, bredde, cw-verdi (konstant for beregning av luftmotstand, se dokumentasjon av stigningsmodellen i Tørset m. fl. 2011) Figur 5 viser et forslag til datamodell for Fartsmodellen som gjør det mulig å realisere brukstilfellene. Også grunnlagsdata som i dag ikke er med i dataflyten er tatt med her (grå bokser), fordi disse faktorene har betydning, og kan senere bli inkludert i en utvidet regnemodell. Lesing av figuren Hver boks i diagrammet tilsvarer en typedefinisjon i et tenkt system. Vanligvis blir disse oversatt mer eller mindre direkte til databasetabeller under implementasjonen. I et kjørende system kan det ligge et vilkårlig antall elementer i hver boks. Linjene mellom boksene angir logiske sammenhenger mellom elementene i de sammenknyttede boksene. Tallet 1 på linjen nært en boks, angir at for hvert element fra motsatt ende, finnen ett og bare ett element av denne typen. Symbolet 0..1 betyr tilsvarende ett eller ingen elementer. Symbolet 0..* betyr 0 eller flere. I en database blir disse sammenhengene realiserte ved å etablere tilsvarende koblingsfelter i tabellene, og definere regler for hvordan relasjonene mellom dem skal være (m.a.o. en relasjonsdatabase) Om datamodellen En rute defineres som en rekke av FmNoder fra start til slutt. En rute brukes i 0 eller flere beregninger. En FmLenke går alltid fra en FmNode til en annen. For hver FmLenke finnes det 0 eller flere lenkevise resultater. Hvert av disse er knyttet til en ruteberegning. Knyttet til samme lenke og ruteberegning kan det være 0 eller 1 forklarende tekster. Kjøretøyets luftmotstand beregnes fra faktisk hastighet, frontareal og cw-verdi. 20

33 Figur 5: Overordnet datamodell i Fartsmodell Datamodellen for Fartsmodellen vil være overlappende med FmBrukers datamodell når det gjelder faktisk innhold. Men å beskrive videre hvordan denne modellen ser ut for hver enkelt FmBruker, er det imidlertid ikke rom for å gå inn på i dette prosjektet. 21

34 7 Komponentperspektiv Komponentperspektivet skal gi et forslag til en fysisk inndeling av et system. Men en fungerende fartsmodell kan involvere mange systemer og inndelinger, avhengig av bruksområdet. Innenfor dette prosjektet er det umulig å komme med konkrete forslag for alle, men det er mulig å trekke frem noen forhold ved grunnlagsdataene som kan være nyttige å ha med seg ved en implementering. Alle data som i dag inngår i Fartsmodellen kan leses direkte fra NVDB via klient-api et, eller via TNE. Det vil sannsynligvis komme flere grensesnitt etter hvert, men den grunnleggende datamodellen forblir uendret. Vegreferansene på data fra disse kildene er særegne for Norge, og kan ikke uten videre brukes på vegnett fra andre datakilder. Som med alle andre beregningsverktøy basert på vegdata, er det for Fartsmodellen et spørsmål om hvordan man kan sikre seg at grunnlagsdata er oppdaterte. En av de viktigste inngangsparametrene til Fartsmodellen er fartsgrensene. De endrer seg jevnlig, særlig i tettbygde strøk. I tillegg kommer andre faktorer som omkjøringer, telerestriksjoner, kjørerestriksjoner m.m., som alle bør inngå i et rutevalg. Vedtak om slike endringer kan fattes på flere nivåer, og rutevalg med treffsikre reisetider kan ikke gjøres uten at følgene av slike vedtak er kjente. 7.1 ROSATTE Nettopp denne situasjonen er utgangspunktet for ROSATTE-prosjektet omtalt i innledningen. Her gir bl.a. D1.2 og D2.1 anbefalinger om hvordan en infrastruktur for oppdatering av slike data kan realiseres. Et tilleggskrav i ROSATTE er at informasjon om vedtak skal ha universelle vegreferanser, som kan tolkes inn i ulike kartgrunnlag. Dette er også et krav i Fartsmodellen. Dette gjør ROSATTE til en interessant datakilde for Fartsmodellen, men detaljer i datamodell og funksjonalitet er ennå ikke på plass. Figur 6 viser Fartsmodellen i et ROSATTE-perspektiv. Figuren er hentet fra ROSATTE D1.2, Kapittel 7, Component Viewpoint. Her vil FmBruker tilsvare ADAS applications, og Informasjonstjeneste vil tilsvare Information Provider Service. 22

35 Figur 6: Fartsmodellen i ROSATTE Component viewpoint I denne sammenhengen er dagens NVDB det samme som DataStore, og med TNE i rollen som DataService. Det som ikke er like godt definert i ROSATTE pr. dato, er hvordan den samme infrastrukturen kan støtte formidling av dynamiske data. Tjenesten DataService bruker universelle vegreferanser. Men hvis FmBruker kan tolke slike, er det ikke noe i veien for å registrerer hver enkelt FmBruker i Subscription Service, og slik få meldinger om, og laste ned, interessante data fra direkte fra denne. Det enkleste er om Information Provider Service implementerer tilsvarende abonnementstjeneste for sine brukere, knyttet til sin interne lenkeinndeling (som FmBruker baserers på. Se vedlegg 1). Da vil tolkning av universelle vegreferanser hos FmBruker falle bort, noe som betyr en feilkilde mindre. Men som sagt kan det bety at det tar lengre tid å få dynamiske data frem til FmBruker. 7.2 Om deling av grunnlagsdata mellom Fartsmodell og FmBruker Enten data kommer fra ROSATTE, NVDB eller andre kilder, må de lagres med et innhold og en inndeling som er tilpasset formålet. Fartsmodell og FmBruker har mye overlappende innhold i sine datasett, men i utgangspunktet avvikende inndeling og referanser. Det kan være ganske store datamengder involvert i beregninger knyttet til en fartsmodell, så en god struktur på dataflyt og datalagring mellom disse er derfor viktige punkter i realiseringen av en slik modell. To aktuelle muligheter er vurdert her: 23

36 1. Separate datasett for hhv. Fartsmodellen og FmBruker, d.v.s fysisk adskilte datalagere uten direkte forbindelser seg imellom.. 2. Felles datasett for Fartsmodellen og FmBruker, hvor Fartsmodell og FmBruker leser og skriver til de samme dataelementene. De to prinsipielt ulike løsningene er illustrert i Error! Reference source not found., og i de følgende delkapitlene er det gjort en vurdering av fordeler og ulemper ved de to løsningene. Figur 7: Separate eller felles datasett Bruk av separate datasett Fordeler: Det er flere fordeler ved å la Fartsmodellen arbeide med egne data: En får en klar inndeling og en ryddig dataflyt for Fartsmodellen, i og med at den selv kan definere nødvendige grunnlagsdata. En oppnår frihet i forhold til videreutvikling: Senere utvidelser av Fartsmodellen (d.v.s. utvidede algoritmer og flere grunnlagsdata, også av mere dynamisk karakter) vil ikke påvirke FmBruker. En oppnår frihet i forhold til realisering: Fartsmodellen kan være en del av FmBruker i form av et bibliotek, den kan være en selvstendig prosess på samme maskin, eller Fartsmodellen kan være en webservice. Alt dette uten å endre annet på FmBruker enn konfigurasjonsparametre. Ulemper: Det er likevel noen ulemper med dette: Responstid: Med to forskjellige datasett følger to forskjellige lenkeinndelinger. Fartsmodellen må derfor ta imot rutedefinisjoner som lister med vegreferanser, og knytte disse til egne lenker, før beregninger gjøres. Deretter må resultatene fra den interne lenkestrukturen overføres til lenkelisten fra FmBruker. Dette er spesielt en ulempe i langsomme nettverk eller enheter med liten prosessorkraft. 24

37 Redundans: Flere av brukstilfellene beskriver situasjoner hvor det er overlapp i datagrunnlaget mellom FmBruker og Fartsmodell. I tilfelle bruk av avvikende oppdateringsperioder og datakilder, kan samme vegstrekning ha forskjellige egenskaper i de to datasettene. Det kan gi uønskede resultater. Konklusjon: Ved bruk av separate datasett bør disse ha den samme lenkeinndelingen, de samme datakildene og oppdateringstidene, iallefall for den overlappende delen av datasettet Bruk av felles datasett Fordeler: Ved å la Fartsmodellen være fullt integrert i FmBruker, kan overføring av lenkelister og formidling av resultater rett og slett bestå av å oppfriske forhåndsdefinerte datasett fra lokal database, og sluttbruker trenger ikke merke mye til det. Ulemper: Det er ett mulig problem med dette: I Fartsmodellen ligger en antagelse om at lenkens egenskaper ikke endrer seg fra start til slutt. Er lenkeinndelingen uheldig, kan f.eks. endringer i vegbredde og kurvatur bli glattet ut, og Fartsmodellen vil korrigere for lite for disse faktorene. Konklusjon: Ved bruk av felles datasett må lenkeinndelingen vurderes nøye for å unngå at mulige fartsreduserende forhold blir midlet bort, for eksempel av høyresving som følger en venstresving blir oppfattet som rettlinje. Det virker likevel mest praktisk å bruke felles datasett. 25

38 8 Systemkrav Systemkrav er krav avledet fra brukerkrav og den påfølgende gjennomgangen. Systemkravene deles ofte inn i følgende typer krav: Funksjonelle krav(fk) spesifiserer funksjonaliteten som forventes av et fungerende system. Ikke-funksjonelle krav (IFK) spesifiserer krav til ytelser og kvaliteter. Omgivelseskrav (OK)spesifiserer både krav som følger av kjente begrensningene fra omgivelsene, og krav til omgivelsene for at systemet skal fungere. Tabell 11: Generelle krav til Fartsmodellen og dens omgivelser Nr Navn Beskrivelse Type krav 1 Fartsmodell integrasjon Fartsmodellen er en integrert del av FmBruker, og helst deler IFK datasett med denne. D.v.s at regnemodellen er en separat modul tilpasset den enkelte FmBruker, eller den inngår direkte i koden for FmBruker. 2 Fartsmodell ytelse Fartsmodellen må implementeres på en effektiv måte, fordi den IFK inngår som et tillegg i en tidskritisk rutevalgsalgoritme 3 Fartsmodell struktur Fartsmodellen bør implementeres med tanke på fremtidige IFK utvidelser i datagrunnlaget. Det er flere datatyper som påvirker reisetid som kan bli lagt til i fremtiden. 4 Datagrunnlag innhold Fartsmodellen trenger tilgang til lenkedefinisjoner med lengde, FK fartsgrense, vegbredde, kjørefeltantall, horisontalradius og stigning. 5 Datagrunnlag struktur Fartsmodellen trenger en lenkeinndeling som ikke kamuflerer FK endringer i fartsgrenser, kurvatur eller andre faktorer langs valgt rute. 6 Datagrunnlag dekning Der hvor grunnlagsdata ikke dekker området, må det overføres FK statuser eller spesialverdier som gjør at Fartsmodellen ikke bruker disse i beregningene. 7 Inkrementell oppdatering FmBruker trenger inkrementell oppdatering fra FK Informasjonstjenesten, se Tabell 7 og Figur 3. 8 Oppdateringsperiode Periodelengde mellom oppdateringer bør tilpasses forventet FK endringstakt i datagrunnlaget. 9 Datagrunnlag referanser Informasjonstjenesten må bruke kjente vegreferanser for å formidle FK data. Hyppige oppdateringer forutsetter at Informasjonstjenesten bruker universelle vegreferanser. 10 Dynamiske data tilgang Hvis dynamiske data inngår, trenger FmBruker å lese disse direkte, FK utenom ordinære oppdateringer av datagrunnlaget. For effektiv behandling er meldingene entydig knyttet til lenkene i datagrunnlaget. 11 Dynamiske data begrensning En del FmBrukere er mobile. Derfor må det finnes mekanismer for å avgrense meldingstrafikken til det som har betydning for den enkelte FmBruker. I praksis vil det si at FmBruker abonnerer på endringsmeldinger fra Informasjonstjenesten eller andre. FK 26