Forskel mellem versioner af "Danvand 1.1 Livscyklus + Historik"

Nuværende version fra 26. nov 2012, 11:17

Livscyklus og procedure ved (del-)renovering

Alle anlægsobjekter i DANDAS og DANVAND (komponenter, bygværker og ledninger) skal have angivet en status med tilhørende Datostatus. Datoetableret må ikke ændres ved skift af status med mindre et objekt skifter status fra planlagt til anlagt eller i brug.

Det er vigtigt at der IKKE MÅ SLETTES undtagen ved fejlregistreringer. Ved ændring af status i livscyklussen, skal der blot ændres statuskode.

I figuren nedenfor ses det livscyklus forløb, som er aftalt af DANVAND følgegruppen som den kommende standard. I den gældende DANVAND version 1.1 er der en fælles kode for død/sløjfet. Så hvis Forsyningen er afhængig af dataudveksling, skal det sikres at der benyttes et sæt af statuskoder, som understøttes af alle aktører.

Livscyklus

DANDAS har i den gældende version 2.5.2 en lidt anderledes livscyklus. Det er forventningen at DANVAND og DANDAS vil udarbejde et fælles sæt af statuskoder i en kommende version af begge standarder.

Et anlægs-objekt kan starte ”livet” med at være ” projekteret /planlagt” i DANDAS/DANVAND, gennemløbe alle ”livs-stadier” og ende som ”Sløjfet/Fjernet”. Objekterne skal dog ikke nødvendigvis gennemløbe alle stadier. Det kan f.eks starte som ”I brug” og derefter overgå til ”Død”. Et objekt kan dermed oprettes forskellige steder i livscyklus – som projekteret /planlagt, som anlagt eller som I Brug. Herefter kan det tages ud af drift igen enten som:

1. Ikke i brug, hvis der er planer om at tage det i drift igen på et senere tidspunkt.
2. Død, dvs at anlægget stadig findes i jorden med det vil ikke blive taget i brug igen på et senere tidspunkt som selvstændigt aktiv. Strakafskrivning iværksættes. I DANDAS er der p.t. 2 yderligere statuskoder, der skal betragtes som typer af Død. Det er Afproppet og Opfyldt
3. Fjernet (DANDAS)/Sløjfet (DANVAND), dvs anlægget er gravet op og findes ikke længere i jorden.

Et anlæg, som har status Død, kan senere reaktiveres som foringsrør for et andet medierør. Det oprindelige rør skifter så status fra Død til I brug og kategorien ændres til foringsrør.

Formål med at holde styr på status:

Det er vigtigt at holde styr på objekternes status (Statuskode) i livscyklus, og hvornår de skifter status (DatoStatus) af følgende årsager :

1. Driften har brug for at vide, hvilket anlæg de skal drive og hvilke de ikke skal drive.
2. Der må ikke kunne tilknyttes drifttiltag i et driftsprogram til anlæg, der ikke er i drift.
3. Ved tegningsudlevering har vi brug for at vide, hvilke anlæg der findes i jorden, og om det er i drift/ikke i drift (må ikke skades da det evt. skal tages i brug på et senere tidspunkt) eller dødt og dermed evt. kan fjernes ved lejlighed.
4. Af hensyn til regnskaber har vi brug for at vide, hvis der etableres anlæg, som ikke sættes i drift med det samme. Da må anlægget ikke aktiveres økonomisk.
5. Af hensyn til regnskaber har vi brug for at vide, hvornår et anlæg bliver sat i drift, for da må aktivering af anlægget ske, således at afskrivning kan påbegyndes.
6. Af hensyn regnskaber skal vi vide, hvis et anlæg skal straksafskrives, når det enten ikke længere skal anvendes eller bliver fjernet.
7. Både DANDAS og DANVAND kan indeholde anlæg, der enten kun er planlagt eller projekteret. Disse anlægsobjekter skal kunne adskilles i forhold til alle øvrige formål.

Renovering og del-renovering:

Ved del-renovering af en ledningsstrækning, skal der ske følgende principielle step:

1. Opdeling af eksisterende strækning i to strækninger, hvorved der bør sikres, at systemet automatisk skjuler den gl. strækning og kun viser de to nye strækninger med de samme attributter som den oprindeligt registrerede strækning.
2. Ændring af status til død, sløjfet eller ikke i brug (systemafhængigt) for den delstrækning, der er blevet renoveret
3. Oprettelse af den nylagte strækning med tilhørende komponenter. Den bør i enderne kobles til eksisterende knuder, så den hydrauliske sammenhæng (topologi) stadig er bibeholdt. Derved kan det forekomme at der er registreret flere komponenter (hhv. aktive og renoverede) i samme knudepunkt.

Ved renovering kan man vælge om gl. og nye komponenter registreres i samme punkt eller som nye punkter. I det punkt, hvor en eksisterende ledning forbindes til en ny ledning kan der dermed eksistere flere komponenter med forskellig status.

Objekt-historik i DANDAS/DANVAND databasen:

Når anlægsobjekterne bevarer deres oprindelige identitet (id) i DANDAS og DANVAND kan status og datostatus udelukkende håndtere deres tilstand i relation til planlægning/projektering, drift, økonomi, og tegningsudlevering. Database-historik er i den sammenhæng principielt ikke nødvendig.

Det er vigtigt at understrege, at håndteringen af objekthistorik bør varetages af DANVAND/DANDAS systemet og derfor ikke normalt er synligt for den almindelige bruger. Det er medtaget her for fuldstændighedens skyld og for at systemadministratorer har en forståelse af, hvorfor der oprettes ekstra objekter i databasen.

Alle objekter med en udfyldt DatoHistorisk skal normalt ikke vises for den almindelige bruger, da de kun eksisterer for at sikre referencer til øvrige IT-systemer som f.eks. værdiopgørelsesværktøjer.

Mange anlægstiltag medfører dog, at anlægsobjekter i DANDAS og DANVAND-baserede programmer IKKE bevarer deres oprindelige identitet af databaseteksniske årsager. Det sker f.eks. ved:

Deling af ledning

1. Eksempel: Tilslutning af en byggemodning, hvor der etableres et T-stykke på den eksisterende ledning. Databaseteknisk gøres den oprindelige ledning historisk med en angivelse af DatoHistorisk for hvornår den er ændret i databasen. Der oprettes samtidig 2 nye ledninger med samme egenskaber som den oprindelige. For begge de nye ledninger skal ErstatID udfyldes med den oprindelige ledningsID.

Samling af ledning

1. Hvis man ønsker at forenkle indholdet af databasen, kan flere ledninger med ens egenskaber blive lagt sammen i databasen. I et afløbssystem, kunne det også ske ved at en brønd mellem to ledninger sløjfes i marken. Databaseteknisk gøres de to (eller flere) eksisterende ledninger historiske, og der etableres én ny med samme egenskaber. DatoHistorisk udfyldes og SamletID udfyldes på de oprindelige ledninger med den nye ledningsID.

Udskiftning eller foring af en del af en ledning.

1. Eksempel med udskiftning: En ledning udskiftes delvist i marken (f.eks et midterstykke). Databaseteknisk gøres den oprindelige ledning historisk ved udfyldning af DatoHistorisk og der etableres 3 nye, som alle har samme egenskaber som den oprindelige ledning incl. datoetableret. Endvidere udfyldes ErstatID på alle 3 ledninger med den oprindelige ledningsID. Den midterste ledning skifter herefter status til Ikke i brug, Død eller Sløjfet, og der registreres en ny ledning med dennes egenskaber. Man kan vælge at udfylde ErstatID på den nye ledning med den midterste lednings ID for at angive at renoveringen erstatter den foregående ledning. Sidstnævnte er valgfrit.
2. Eksempel med foring: Et midterstykke af en ledning fores i marken.Der skal da ske det samme som ovenfor beskrevet, bort set fra at det midterste stykke skifter kategori til foringsrør og bibeholder sin status I Brug.

Disse tekniske håndteringer giver problemer, når øvrige IT-systemer har anvendt de tidligere anlægs identitet f.eks i værdihåndterings- og driftssystemer.

DANDAS og DANVAND har ikke pt. samme model for historik og desuden har de forskellige DANDAS-programmer forskellige implementering af historik. På sigt ønskes samme håndtering i de to modeller og der peges pt. på implementering af DANVAND´s historik model i DANDAS.