Danva Wiki - Brugerbidrag [da]

Danvand 1.1 ZONER

2012-11-26T11:57:52Z

Jkj:

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=ZONER Begrebsmodel Zoner]

== '''ZONER''' ==

TBD

== '''ZONEKATEGORI''' ==

TBD

== '''ZONETYPE''' ==

TBD

Danvand 1.1 ZONER

2012-11-26T11:57:33Z

Jkj:

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=ZONER Begrebsmodel Zoner]

== '''ZONER''' ==

== '''ZONEKATEGORI''' ==

TBD

== '''ZONETYPE''' ==

TBD

Danvand 1.1 VENTIL

2012-11-26T11:56:36Z

Jkj: 1. forslag til registreringsvejledning

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=VENTIL Begrebsmodel Ventil]

== '''VENTIL''' ==

Obligatoriske felter:
# Funktion
# Ventilkode
# Ventiltype (hentes fra ventilkataloget, herunder bl.a. dimension)
# Dato for etablering
# Status
# Åbningsgrad – der kan registreres både normal og aktuel åbningsgrad i %
# Sagsnummer – på alle nye komponenter (lagt fra 1/1-2010)
# Ejerforhold

Anbefalede oplysninger:
# Er ventil tilgængelig (J/N)? Default (J)

== '''Ventilkatalog''' ==

Der bør være en ventiltype i kataloget for hver ventilkode (administrator).

[[Fil:Eksempel.jpg]]
[[Fil:Eksempel.jpg]]
[[Fil:Eksempel.jpg]]

Danvand 1.1 VENTIL

2012-11-26T11:54:08Z

Jkj: 1. forslag til registreringsvejledning

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=VENTIL Begrebsmodel Ventil]

Obligatoriske felter:
# Funktion
# Ventilkode
# Ventiltype (hentes fra ventilkataloget, herunder bl.a. dimension)
# Dato for etablering
# Status
# Åbningsgrad – der kan registreres både normal og aktuel åbningsgrad i %
# Sagsnummer – på alle nye komponenter (lagt fra 1/1-2010)
# Ejerforhold

Anbefalede oplysninger:
# Er ventil tilgængelig (J/N)? Default (J)

== '''Ventilkatalog''' ==

Der bør være en ventiltype i kataloget for hver ventilkode (administrator).

[[Fil:Eksempel.jpg]]
[[Fil:Eksempel.jpg]]
[[Fil:Eksempel.jpg]]

Danvand 1.1 TAPSTED

2012-11-26T11:52:25Z

Jkj: 1. forslag til registreringsvejledning

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=TAPSTED Begrebsmodel Tapsted]

== '''TAPSTED''' ==

Sprinkleranlæg er en særlig "komponent", som ikke er vandforsyningens ejendom, men ikke desto mindre meget væsentlig for at kunne vurdere specifikke krav til forsyningsevnen (enkelt- eller dobbeltsidig forsyning, krav til flow, krav til tryk).

Oplysninger om sprinkleranlæg kan som udgangspunkt hentes fra godkendelsesrapporter fra hhv. DBI eller RMG. De skal dog indhentes ved direkte kontakt til ejeren af det enkelte sprinkleranlæg.

De øvrige kategorier af tapsteder bør være enklere at registrere, da oplysningerne relateres til type af komponent etc.

Obligatoriske felter:
# Kategori
# Tapsted type (hentes fra tapsted kataloget – ikke relevant for sprinkleranlæg)
# Dato for etablering
# Status
# Sagsnummer – på alle nye komponenter (lagt fra 1/1-2010)
# Ejerforhold

Anbefalede oplysninger:
# Position (overjordisk eller underjordisk) og frostsikret (ja/nej) for alle andre end sprinkleranlæg.
# En lang række oplysninger for sprinkleranlæg, som fremgår af sprinkler godkendelsesrapporterne. Sprinkleranlæg er ikke vandforsyningens ejendom og det kan være vanskeligt at indhente oplysningerne, som i givet fald skal hentes fra ejeren af sprinkleranlægget. Der er forskel på krav til vandforsyning af sprinkleranlægget og de deraf afledede krav til vandforsyningen. Det bliver for vidtgående at gå i detaljer med de enkelte oplysninger om sprinkleranlæg i denne vejledning.

== '''Tapstedkatalog''' ==

TBD

Danvand 1.1 MAALERENHED

2012-11-26T11:44:26Z

Jkj:

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=MAALERENHED Begrebsmodel Målerenhed]

== '''MÅLERENHED''' ==

TBD

== '''Målerenhedskatalog''' ==

TBD

Danvand 1.1 NOTE

2012-11-26T11:43:57Z

Jkj:

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=NOTE Begrebsmodel Note]

== '''NOTE''' ==

TBD

Danvand 1.1 MAALERENHED

2012-11-26T11:43:21Z

Jkj:

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=MAALERENHED Begrebsmodel Målerenhed]

== '''MÅLERENHED''' ==

TBD

Danvand 1.1 LEDNING

2012-11-26T11:42:22Z

Jkj: 1. forslag til registreringsvejledning

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=LEDNING Begrebsmodel Ledning]

== '''LEDNING''' ==

Obligatoriske felter for alle ledningskategorier er:
# Kategori
# Dato for etablering af ledning (for ledninger, som ikke kun er ”Planlagt”)
# Status
# Rørtype (dimension, materiale, trykklasse)
# Sagsnummer – på alle nye ledninger (lagt fra 1/1-2010)
# Ejerforhold

Anbefalede oplysninger
# Oprindelse, X- og Y-koordinater
# Oprindelse, koter
# Lægningsmetode

== '''Opmåling''' ==

Ved opmåling af ledninger bør angives koten til top af ledning i knækpunkterne. Der skal registreres et tilstrækkeligt antal knækpunkter til at ledningen kan genfindes.

== '''Rørkatalog''' ==

Obligatoriske felter for alle ledningskategorier er:
# Dimension
# Materiale
# trykklasse

Særlige forhold for Stikledninger og Jordledninger er:
# Eksisterende primærledninger (transmission-, distributions- og forsyningsledninger) har stort set altid kendt rørtype. Men det er ikke altid tilfældet for stik- og jordledninger. Hvis rørtypen ikke er kendt, kan den anføres som f.eks. dimension: 0 materiale: ukendt

Derfor skal der oprettes en ”Dummy” rørtype i kataloget

----

--Bent Guldager, Aarhusvand A/S 15. nov 2012, 09:32 (UTC) test af link til begrebsmodel

Link [http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=LEDNING Begrebsmodel Ledning]

Link [http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=MAALERENHED Begrebsmodel Målerenhed]

Danvand 1.1 KOMBIKOMPONENT

2012-11-26T11:39:39Z

Jkj: 1. forslag til registreringsvejledning

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=KOMBIKOMPONENT Begrebsmodel Kombi-komponent]

== '''KOMBIKOMPONENT''' ==

Kombikomponenter er samlinger med indbyggede ventiler. Der kan vælges mellem flere forskellige kategorier:
a. Kombikryds: En samling med 4 forbindelser med hver sin ventil
b. Kombitee: En samling med 3 forbindelser med 2 eller 3 ventiler
c. Kombiventil: En samling med én ventil og 2 forskellige dimensioner

Obligatoriske felter for alle kombikomponenter er:
# Kategori (f.eks. kombi-T eller Kombi-kryds)
# Type – dvs. reference til kataloget, hvor der er en liste med mulige fabrikater og dimensioner etc.)
# Dato for etablering af komponent (for komponenter, som ikke kun er ”Planlagt”)
# Status
# Reference til den eller de ledninger, der er koblet til de enkelte forgreninger
# Ventilåbningsgrad (i %) på de ventiler, som kombikomponenten indeholder
# Sagsnummer – på alle nye komponenter (lagt fra 1/1-2010)
# Ejerforhold

Anbefalede oplysninger:
Ingen yderligere opl.

== '''Kombikomponet Katalog''' ==

Obligatoriske felter for kombikomponenter er:
# Kategori (f.eks. kombi-T eller Kombi-kryds)
# Dimension for alle forgreninger (kan være 2, 3 eller 4)
# Entydigt navn – typisk en fabrikantbetegnelse

Anbefalede oplysninger:
# Firmanavn på fabrikanten
# Varenummer fra fabrikantens katalog

[[Fil:Kombi-T med ventiler1.png|200px|thumb|left|Kombi-T med ventiler]]

Danvand 1.1 FORBRUGSSTED

2012-11-26T11:35:22Z

Jkj:

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=FORBRUGSSTED Begrebsmodel Forbrugssted]

== '''FORBRUGSSTED''' ==

TBD

'''Forbrugstypekatalog'''

TBD

Danvand 1.1 FORBRUGSSTED

2012-11-26T11:35:08Z

Jkj:

Danvand 1.1 ENKELSAMLING

2012-11-26T11:33:31Z

Jkj: 1. forslag til registreringsvejledning

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=ENKELSAMLING Begrebsmodel Enkelsamling]

== '''ENKELSAMLING

Enkelsamlinger er komponenter, der ikke er tilgængelig uden opgravning. Enkelsamlinger registreres typisk kun, hvor man har behov for at kende placeringen på en ledningsstrækning eller hvor man ønsker at markere samling mellem ledningstyper med forskellige karakteristika. Enkelsamlinger kan ikke hindre fri vandstrøm. Slutmuffe er dog et særtilfælde.

Der kan vælges mellem flere forskellige kategorier:
a. Uoplyst Bør ikke anvendes på nye enkeltsamlinger
b. Anboring Det sted, hvor stikledningen er koblet til forsyningsnettet
c. Bøjning Svejste samlinger eller glat bøjning
d. Dimensionsskift Samling af to forskellige dimensioner
e. Kryds Samling af 4 ledninger.
f. Samling Herunder fitting, svejsning, limning, muffe, gummiring etc.
g. Slutmuffe Boltet eller svejst
h. Tee Samling af 3 ledninger. Ens dimensioner eller reduktionstee
i. Snavssamler
j. Andet

Bemærk, at en anboring med indbygget anboringsventil bør registreres som en ventil med ventilfunktion skydeventil og ventilkode stophane.

Obligatoriske felter for alle enkeltsamlinger er:
# Kategori (se ovenfor)
# Type – dvs. reference til kataloget, hvor der er en liste med mulige fabrikater og dimensioner etc.)
# Dato for etablering af komponent (for komponenter, som ikke kun er ”Planlagt”)
# Status
# Sagsnummer – på alle nye komponenter (lagt fra 1/1-2010)
# Ejerforhold
# For anboringer er det obligatorisk at tage stilling til anboringsstedet (top, side eller bund). Hvis det ikke kendes, vælges koden uoplyst.

Anbefalede oplysninger:
# Overgangstype

== '''Enkelsamlings-katalog''' ==

Obligatoriske felter for enkelsamlinger er:
# Kategori (f.eks. Anboring eller bøjning)
# Dimension for alle forgreninger (kan være 1, 2, 3 eller 4)
# Entydigt navn – typisk en fabrikantbetegnelse
# For bøjninger skal bøjningsvinklen angives
# For anboringer skal anboringstypen angives (bøjle, saddel). Hvis det ikke kendes, vælges koden uoplyst.

Anbefalede oplysninger:
# Firmanavn på fabrikanten
# Materiale på enkelsamlingen
# Varenummer fra fabrikantens katalog

[[Fil:Anboring1.png|200px|thumb|left|Anboring]]

[[Fil:T-stykke1.png|200px|thumb|left|T-stykke]]

[[Fil:Anboring ventil1.png|200px|thumb|left|Anboring ventil]]

[[Fil:Boejning1.png|200px|thumb|left|Bøjning]]

[[Fil:Samling multijoint1.png|200px|thumb|left|Samling,Multijoint]]

[[Fil:Slutmuffe1.png|200px|thumb|left|Slutmuffe]]

[[Fil:Samling elektrosvejsning1.png|200px|thumb|left|Samling, elektrosvejsning]]

[[Fil:Samling-lige kobling1.png|200px|thumb|left|Samling, Lige kobling]]

[[Fil:Samling-samlemuffe1.png|200px|thumb|left|Samling, Samlemuffe]]

[[Fil:reduktion1.png|200px|thumb|left|Reduktion]]

Danvand 1.1 DOKUMENT

2012-11-26T11:29:18Z

Jkj:

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=DOKUMENT Begrebsmodel Dokument]

== '''DOKUMENT''' ==

TBD

Danvand 1.1 BYGVAERK

2012-11-26T10:36:10Z

Jkj: 1. forslag til registreringsvejledning

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=BYGVAERK Begrebsmodel Bygværk]

== '''BYGVÆRK''' ==

Bygværker registreres som et objekt med en udstrækning (et areal). Bygværker vil typisk være aktiver, hvori der vil være en række komponenter og ledninger. Der kan dermed registreres en reference fra mange komponenter og ledninger til det samme bygværk – f.eks. et vandværk.

Et mere simpelt bygværk kan være en målerbrønd, som vist på nedenstående figur. Man kan vælge at registre alle komponenter knyttet til samme knude, som repræsenterer bygværket Sektionsmålerbrønd med en ledning i hver retning eller man kan vælge at registrere alle delstrækninger som hver sin ledning med den enkelte komponent i endepunkterne.

Bygværket kan og bør knyttes til en knude, så man har en reference til et punkt og også lettere kan vælge at visualisere bygværket som et punktobjekt i den pågældende knude, når man viser et oversigtsbillede fra ledningsregistreringen.

[[Fil:Sektionsbrond.PNG]]

Fil:Sektionsbrond.PNG

2012-11-26T10:34:43Z

Jkj: Tegning af sektionsmålerbrønd til vand

Tegning af sektionsmålerbrønd til vand

Danvand 1.1 BORING

2012-11-26T10:21:17Z

Jkj:

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=BORING Begrebsmodel Boring]

== BORING ==

TBD

Danvand 1.1 BEHOLDER

2012-11-26T10:20:41Z

Jkj:

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=BEHOLDER Begrebsmodel Beholder]

== BEHOLDER ==

TBD

Danvand 1.1 Vaerdiansaettelse

2012-11-26T10:19:08Z

Jkj: /* Værdiansættelse - nyt afsnit om kataloger og tabeller */

== Værdiansættelse ==

Se foregående afsnit om projekt, hvor værdiansættelse også er behandlet...

== Sammenhæng mellem kataloger og komponent/ledningstabeller ==

Hvor den samme oplysning kan registreres under både komponent og i kataloget, er det registreringen på komponenten, der er gældende. Oplysningen i kataloget bruges i denne sammenhæng som en mulighed for at filtrere mellem katalogets værdier ud fra f.eks. funktionskoden.

Danvand 1.1 Livscyklus + Historik

2012-11-26T10:17:34Z

Jkj: /* Objekt-historik i DANDAS/DANVAND databasen: */

== '''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.

[[Fil:Livscyklus1.JPG|200px|thumb|left|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:
# Ikke i brug, hvis der er planer om at tage det i drift igen på et senere tidspunkt.
# 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
# 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 :
# Driften har brug for at vide, hvilket anlæg de skal drive og hvilke de ikke skal drive.
# Der må ikke kunne tilknyttes drifttiltag i et driftsprogram til anlæg, der ikke er i drift.
# 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.
# 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.
# 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.
# Af hensyn regnskaber skal vi vide, hvis et anlæg skal straksafskrives, når det enten ikke længere skal anvendes eller bliver fjernet.
# 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:
# 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.
# Ændring af status til død, sløjfet eller ikke i brug (systemafhængigt) for den delstrækning, der er blevet renoveret
# 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'''
# 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'''
# 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.'''
# 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.
# 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.

Danvand 1.1 Livscyklus + Historik

2012-11-26T10:16:31Z

Jkj: Tilføjet vejledning ved del-renovering samt kort beskrivelse af databasehistorik

== '''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.

[[Fil:Livscyklus1.JPG|200px|thumb|left|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:
# Ikke i brug, hvis der er planer om at tage det i drift igen på et senere tidspunkt.
# 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
# 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 :
# Driften har brug for at vide, hvilket anlæg de skal drive og hvilke de ikke skal drive.
# Der må ikke kunne tilknyttes drifttiltag i et driftsprogram til anlæg, der ikke er i drift.
# 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.
# 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.
# 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.
# Af hensyn regnskaber skal vi vide, hvis et anlæg skal straksafskrives, når det enten ikke længere skal anvendes eller bliver fjernet.
# 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:
# 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.
# Ændring af status til død, sløjfet eller ikke i brug (systemafhængigt) for den delstrækning, der er blevet renoveret
# 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'''
# 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'''
# 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.'''
# 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.
# 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.

Danvand 1.1 Livscyklus + Historik

2012-11-26T10:10:52Z

Jkj: /* Renovering og del-renovering: */

Danvand 1.1 Livscyklus + Historik

2012-11-26T10:08:11Z

Jkj: /* Livscyklus og procedure ved (del-)renovering */

Danvand 1.1 Livscyklus + Historik

2012-11-26T10:07:25Z

Jkj: /* Livscyklus og procedure ved ledningsrenovering */

Danvand 1.1 Generelt

2012-11-26T10:00:08Z

Jkj: Tilføjet en læsevejledning

== '''GENERELT''' ==

Scope og målgruppe:
Registreringsmedarbejdere i forsyningerne. Dvs. det forudsættes at der er administratorer, som sørger for vedligeholdelse af kataloger samt at registreringssystemet sørger for automatisk at udfylde oplysninger om f.eks. DatoOpdateret, DatoOprettet, Initialer etc.

Dette er ikke at forveksle med et systemkrav, som håndteres af DANVAND/DANDAS datamodellen

== Læsevejledning ==

TBD = To Be Defined – dvs. der foreligger ikke en registreringsvejledning endnu.

== Link til begrebsmodel ==

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1 Begrebsmodel Danvand 1.1]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=BEHOLDER Begrebsmodel Beholder]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=BORING Begrebsmodel Boring]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=BYGVAERK Begrebsmodel Bygværk]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=DOKUMENT Begrebsmodel Dokument]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=ENKELSAMLING Begrebsmodel Enkelsamling]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=FORBRUGSSTED Begrebsmodel Forbrugssted]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=KOMBIKOMPONENT Begrebsmodel Kombi-komponent]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=LEDNING Begrebsmodel Ledning]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=MAALERENHED Begrebsmodel Målerenhed]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=NOTE Begrebsmodel Note]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=PUMPE Begrebsmodel Pumpe]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=RESERVOIR Begrebsmodel Reservoir]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=TAPSTED Begrebsmodel Tapsted]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=VENTIL Begrebsmodel Ventil]

[http://www.detdigitalevandselskab.dk/Default.aspx?ID=3408&TokenExist=no&omraade=Vand&model=DanVand&version=1.1&begreb=ZONER Begrebsmodel Zoner]

Danvand 1.1 Oprindelse

2012-11-26T09:58:12Z

Jkj: 1. forslag til registreringsvejledning

== '''OPRINDELSE''' ==

Obligatoriske oplysninger for alle komponenter og ledninger:
# Oprindelse for registrering, herunder en nøjagtighed på opmålingen

Anbefalede oplysninger:
# Oprindelse, X- og Y-koordinater
# Oprindelse Z-koordinat

Danvand 1.1 Vaerdiansaettelse

2012-11-26T09:56:31Z

Jkj: 1. forslag til registreringsvejledning

== Værdiansættelse ==

Se foregående afsnit om projekt, hvor værdiansættelse også er behandlet...

Danvand 1.1 Projekt

2012-11-26T09:55:40Z

Jkj: 1. forslag til registreringsvejledning

== LEDNINGSPROJEKTER OG VÆRDIANSÆTTELSE ==

For at lette arbejdet med værdiansættelse, til brug for indberetninger til Forsyningssekretariatet, DANVA og til udarbejdelse af årsregnskab, anbefales at alle ledningsprojekter registreres med et tilhørende sagsnummer. Det bør være det sagsnummer, hvortil der knyttes en samlet økonomi fra Forsyningens økonomifunktion. Det kan registreres på alle komponenter (via reference til knuderne) og på ledninger. Der bør registreres et sagsnummer ved både etablering, levetidsforlængelse og renovering (når et aktiv tages ud af drift).

Hvis der er flere komponenter knyttet til samme knude, er det ikke muligt at registrere forskellige sagsnumre herpå med den gældende standard. Hvis der er knyttet mere end et sagsnummer til et aktiv (ved enten etablering, levetidsforlængelse og/eller renovering) er det ikke muligt at foretage en fuldstændig registrering heraf med den gældende standard. Det anbefales i så fald indtil videre at det er det sidste sagsnummer, der knyttes til aktivet.

Danvand 1.1 Projekt

2012-11-26T09:51:42Z

Jkj: 1. forslag til registreringsvejledning

== LEDNINGSPROJEKTER OG VÆRDIANSÆTTELSE ==