DGBuss:Kalenderfunksjoner

Kalenderfunksjonalitet i DGBuss 4.x

DGBuss er basert på et Versjon/Periode og Dagtype – prinsipp, hvilket betyr at hver eneste dato er tilordnet en kombinasjon av produksjonsversjon (‘V’) og dagtype (‘5’) , evt med en ekstra egenskap der man kan aktivere skolefridag (‘-‘). Dette prinsippet har ligget fast siden en eller annen gang på (19)90-tallet - tiden flyr!

Med det menes f.eks. at vinterruter 2019 kobles mot versjon V, (eller f.eks D). Via relativt fleksible definisjoner i periodekalender kan man da definere ulike perioder der V blir aktivert. Man kan også overstyre enkeltdatoer i unntakskalendere. Derved er det enkelt å overstyre en uke og sette den til f.eks. P, man kan aktivere søndagsruter på 1. mai ved å definere 1. mai som en dagtype 7 i unntakskalenderen. Man kan også for perioder eller enkeldatoer definere at det er skolefri (vises med ‘-‘) og derved vil turer i rutene som er merket «S» for skolekjøring, innstilles og turer som er merket «I» for skolefr«I» (evt-. «I»kke skolekjøring), aktiveres ekstra.

Sett at perioderegisteret er fyllt ut på følgende måte:

10 J Jul 24.12.13 02.01.14

20 P Påske 94 16.04.14 21.04.14

30 S Sommer 93 20.06.13 15.08.13

40 S Sommer 94 22.06.14 18.08.14

50 V Hele året 01.01.13 31.12.14

---

Alle data som skal behandles i systemet sjekkes fra toppen av perioderegisteret.

Resultatet kan illustreres på følgende vis:

caption

Totalkalenderen viser oversikt over kjøretypene for hver enkelt dato:

caption

Denne kjørekalenderen viser skolefri i perioden 1.-7. samt at 17. oktober kjøres som en søndag i periode ‘A’.

Andre muligheter for å begrense gyldigheten innenfor kalenderdefinisjonene man har i kalenderdefinisjonene: Ved å fra ruten gå via Tabell og Ruteinformasjon, kan man begrense gyldigheten, f.eks. i det tilfellet en sommerrute starter senere enn normal overgang mellom skolekjøring og sommerkjøring:

caption

Det finnes dessuten en mulighet til å begrense enkeltturers evt. modellers gyldighet ved å sette FOM og eller TOM dato:

caption

I all hovedsak har dette fungert etter hensikten og dekket de fleste behov.

Spesielt for kollektivselskaper som dekker et større område, kan det bli avvikende overgang mellom sommer og vinter, avvikende skoleferieavvikling etc og derved må man opprette og vedlikeholde ganske mange versjoner for å dekke alle avvikene. Derfor har brukerne både på samlinger og via enkelthenvendelser ønsket forbedringer på denne funksjonaliteten.

Eksempel på utfordring med standard kalenderfunksjonalitet i DGBuss 4.x

Et eksempel på utfordring med gjenldende kalenderfunksjonene, er om man har ulike kjørekalendere innenfor driftsområdet:

Sett at man har ruter innen ulike områder og rutetyper som kjøres i ulike varianter: Skoledagversjon, skolefridagsversjon og helårsversjon og styres av følgende plan (for de første 3 månedene av året):

1. Området Øst har vinterferie i uke 8. 2. Område Nord har vinterferie i uke 9 3. Distriktsrutene kjører samme plan hele året.

I dette tilfellet må man i versjon 4.x dele dette inn i følgende driftsperioder:

TOM uke 7: Produksjonsversjon A der alle 3 områdene kjører skoledags- evt helårsproduksjon.

I uke 8, kjører område Øst: Skolefriversjon, område Nord: Skoledagsversjon og Distriktsrutene kjører full produksjon. Disse rutene må kobles mot produksjonsversjon B.

I uke 9, kjører område Øst skoledagsproduksjon, område Nord kjører skolefriversjon og Distriktsrutene kjører fortsatt normal helårsversjon. Alle disse rutene må kobles mot produksjonsversjon C

I uke 10, kjører alle områdene igjen full skoledags- evt helårsversjon, altså er vi tilbake til produksjonsversjon A

Dette vil se slik ut i kalenderdefinisjonene:

caption

Dette betyr at skoledagsrutene i område Øst må kobles til A og en helt lik kopi til versjon C.

Skolefriversjonen av rutene i område Øst, må kobles til B.

Tilsvarende må skje med rutene i område Nord: Dvs Skoledagsversjonen må ligge som rute koblet til både A og B, mens skolefriversjonen må kobles til versjon C

Distriktsrutene må kopieres fra A til både B og C.

I utgangspunktet er det enkelt å kopier en rute fra en produksjonsversjon til en annen, men den største ulempen er når man i etterkant blir nødt til å endre en rute, f.eks. legge til en holdeplass eller legge til / endre noen avganger. På helårsruten må man altså gjenta prosessen 3 ganger: For A, B og C-versjonen av ruten.

Både vi og kundene har hatt en ønske om å finne en mer fleksibel løsning som reduserer dobbellagring av ruter.

FynBus-modellen

En mulighet kanskje ikke alle er klar over: I Fynbus (regionsselskapet på Fyn), har man lenge hatt et annet verktøy som har gitt mulighet for detaljstyring på turnivå. Innenfor hver kommune har de ulike koder som aktiverer en kjøring. Derved kan de dato for dato bestemme om en avgang skal gå eller ikke, dessuten har de valgt at man innenfor hver kommune skal kunne ha inntil 10 ulike kalendermønstre.

caption

Mandag 4.januar 2016 skal f.eks. turene i Assens som er merket AS1,AS2,AS3 og AS6 kjøre, mens andre turer er deaktivert. Dette har vist seg hensiktsmessig for Fyn og alle eksporter tar hensyn til denne kodingen. Kanskje kunne dette være nyttig også for øvrige kunder?

Sikre historikk

For å sikre at man har korrekt historikk for senere utskrift av produksjonsoppgaver, anbefales ved mindre endringer at man korrigerer i avgangskolonnene og evt setter en TOM-dato på gammel kolonne og FOM på ny og korrigert kolonne. Ved større endringer anbefales å kopiere hele produksjonsversjonen (rimelig kjapp rutine under vedlikehold og reorganiser - menyen) og aktivere den nye produksjonsversjonen fra endringsdatoen. Slik sikrer man at man alltid kan ta ut en rapport som viser korrekt produksjon over tid.

Planlagt utvidelse av kalenderfunksjonene i DGBuss 5.x

Sammendrag: Mulighet for å definere ulike kjørekalendre for ulike områder eller grupper av ruter, skaper større fleksibilitet.

Her er en illustrasjon på hvorledes kalendermønsteret kan variere fra område til område og rutegruppe til rutegruppe: Eksempelet er en utvidelse av "utfordringen" fra forrige kapittel:

caption

Ett område, som i figuren er kalt «Skolens ruteområde Øst» (sone 0) kan kjøre P om vinteren og S om sommeren med skolefri (Q) i uke 8.

Et annet område, «Skolens ruteområde Vest», (sone 1), kan kjøre D om vinteren med innstilling av skoleturene (D-) i uke 9.

Det betinger at vi må endre den opprinnelige forutsetningen om at hver dato kun har én versjon og dagtype til at det må være mulig å registrere og behandle flere versjoner / dagtyper pr dato.

Denne endringen må gjennomføres i både Periode- og Unntaks-kalenderen.

Derved resulterer dette i at man kan aktivere 1,2 eller flere dagtyper pr dato og dette må også komme fram av kjørekalenderen (som i prinsippet også styrer alle eksporter, rapporter osv. (Det er neppe hensiktsmessig å definere for mange pr dag).

Et komplett eksempel kan se slik ut:

caption

Figur: Eksempelet viser at man for sone 0 (altså det vi har kalt Skolens ruteområde ØSt) har definert P som vinterversjon, men bryter av med Q i uke 8. Parallelt har man innenfor definisjonen: Sone 1, definert en helårsversjon: D. I denne har man definert en ekskludering av skolerutene i uke 9.

Mandag – onsdag i Påsken har man aktivert en ekstra kjøring som er lagt inn i versjon Y.

Man kan også se at man har mulighet for å definere dagavvik for både sone 1 og sone 2 for f.eks. 1. mai.

Dette vil medføre at man bruker flere produksjonsversjoner, men samtidig vil det kunne bli færre ruter som er identiske i de ulike produksjonsversjonene. (I dag må man splitte opp en rute i f.eks. S og V – versjon selv om kjøringen er helt lik – fordi andre ruter har forskjell på sommer og vinter-ruter.) I stedet kan man ha kun en versjon av helårsrutene og eksempelvis kalle disse versjon ‘D’. På samme måte kan man da enklere definere inn at ulike områder har vinterferie i uke 8, andre i uke 9, tilsvarende for høstferier osv.

Det er ikke tenkt at de enkelte rutene skal kobles mot sone, kun at f.eks. 16. april, vil alle ruter i versjonene Q, D og Y og deres avganger som er merket dagtype 2 blir avviklet (i alle sammenhenger). Ut fra problemstillinger vi har blitt forelagt tidligere, har vi tro på at dette vil forenkle versjons-oppbyggingen vesentlig.

Status i utviklingen pr februar 19, er at (som man kan se: Definisjonene er på plass,) men man må gjennomgå rapporter, eksporter etc for å åpne for at man ikke lenger kun skal sjekke opp mot en versjon og dagtype pr dato, men alle de som er definert inn. Dvs et moderat arbeid å gjennomføre i det øyeblikk prinsippene bak utvidelsen er fastlagt.