Vedlegg A2.6 FDV dokumentasjon

Transkript

1 Vedlegg A2.6 FDV dokumentasjon Dokumentasjon fra IDÈ til DRIFT: Designdokumentasjon + Som bygget dokumentasjon + Drift og vedlikeholdsdokumentasjon = FDV Dokumentasjon Sykehuset i Vestfold HF Versjon: Side 1

2 Dokumentasjonskontroll: Versjon Dato Forfatter Årsak Kapittel berørt Godkjent av / Dato Inge Aarseth, Etablering av dokumentet Alle Brynjulf Skjulsvik, Lars C. Christensen Inge Aarseth Justering av tekst Alle Brynjulf Skjulsvik, Lars C. Christiansen, Etablering av eksempler på FDVdokumentasjon 1, 5 11, samt vedlegg 7 og 8. Inge Aarseth A.Arnesen/ Sykehuset i Vestfold HF Versjon: Side 2

3 Innhold 1. Sammendrag Innledning Definisjoner Overordnede prosjektdokumenter FDV dokumentasjon i prosjektets faser Prosjektets faser sett i forhold til Livssyklus og FDV Integrert Design Prosess med delprosesser Produksjonsprosess med delprosesser Modeller i prosjekteringsarbeidet Overlevering av modellinformasjon Leveranseomfang FDV dokumentasjon Designinformasjon Supplerende Attributter produkt/komponent/artikkel: Supplerende Attributter system: RFID merking av komponenter System og produktinformasjon. Leverandørinformasjon Igangkjøring, ferdigstillelsesinformasjon Driftsfasen Avhending Overordnet informasjonsmatrise Hvordan skal informasjonen kunne aksesseres: Innsamling og utvekslingsformat Revisjonsutgaver Organisering Vesentlig del av leveransen Eierskap og rettigheter Vedlegg 1 Definisjoner Vedlegg 2 Overordnet informasjonsmatrise Vedlegg 3 Egenskapsinformasjon til systemer og produkter som skal inkluderes i FDV dokumentasjonen.. 32 Vedlegg 4 SiVs system for nummerering av tegninger Vedlegg 5 Bakgrunnsinformasjon: BIM og FDV informasjon Vedlegg 6 Bakgrunnsinformasjon: COBie beskrivelse Sykehuset i Vestfold HF Versjon: Side 3

4 Vedlegg 7 Eksempel på BIM FDV informasjon Vedlegg 8 Minimum detaljeringsnivå for leveranse av FDV dokumentasjon (digital PDF og papirversjon). 58 Sykehuset i Vestfold HF Versjon: Side 4

5 1. Sammendrag Med FDV dokumentasjon menes i dette dokumentet følgende dokumentasjon: o Designdokumentasjon o Som bygget dokumentasjon o Drift og Vedlikeholdsdokumentasjon Overlevering av FDV dokumentasjon skal være basert på og tilpasset bruk av 3D BIM. FDV dokumentasjonen skal også overleveres på tradisjonell måte (digitalversjon og papirversjon). I dette dokumentet menes åpenbim ( definisjon) når BIM beskrives, basert på IFC formatet. Byggherren forutsetter at informasjonsstrukturen (Pset og egenskapsfelt) defineres i de prosjekterendes BIM programmer og at så mye objektinformasjon som mulig legges inn i 3D BIMen fra starten av. Det blir derved kun supplering av utfyllende informasjon som må legges inn i produksjonsprosessen. Minimumsnivået på informasjon som skal legges inn er angitt i Vedlegg 3 COBIE sammen med kapittel 5 FDV dokumentasjon. Byggherren legger opp til at den informasjonsmengden som ikke kan håndteres direkte i modellen overføres inn i BIMen og FDV programmet via COBIE regnearket (excel format). Byggets målsettinger klargjøres før forprosjektet (tilsv.) ferdigstilles, og skal formuleres på en slik måte at dette skal kunne måles etter 2 års full drift. Det er 5 hovedfaser i et systems og objekts livsløp som skal gjenspeiles i 3D BIMen. Dette medfører at nøkkelinformasjon vil ha flere verdier avhengig av hvilken fase informasjonen genereres: o som kravsatt ( As required ) dokumentasjon. o som designet og prosjektert ( As designed ) dokumentasjon. o som bygd ( As built ) dokumentasjon. o som innmålt ( As tested ) dokumentasjon o som driftet ( As operated ) dokumentasjon Aktørene skal legge inn oppdaterte modeller regelmessig (minimum en gang pr uke i startfasen), på det stedet byggherren anviser eks. webhotel. Det er definert to nivå på leveranseomfanget av FDV dokumentasjon: o Grunnleggende digital FDV dokumentasjon (Gjelder for PiV prosjektene) o Komplett modellbasert FDV dokumentasjon Det er definert en rekke Pset (PropertySet=Egenskapssett) som viser hvilken type informasjon som skal etableres på hvert objekt avhengig av type objekt. Overordnet informasjonsmatrise angir eksempelvis når dokumentene skal etableres, ajourføres og sluttføres. Det forutsettes at dette gjøres tilgjengelig løpende på webhotellet. Komponentenes identifikasjonsinformasjon skal inneholde informasjon om Sann Leverandør (Produsent) og Sann Leverandørs komponentinformasjon. Leveranse av FDV dokumentasjon er å anse som en vesentlig del av kontrakten og fremsendelse av sluttfaktura kan først gjøres etter at komplett FDV dokumentasjon er overlevert og godkjent av byggherren. Byggherren har eierskap og alle rettigheter knyttet til alt arbeidet og resultat som omfattes av dette oppdraget. Sykehuset i Vestfold HF Versjon: Side 5

6 2. Innledning Denne anvisningen angir hvordan byggeprosjektets Design, Forvaltning, Drifts, Vedlikehold og Utviklingsdokumentasjon (heretter benevnt FDV dokumentasjon) skal utarbeides og overleveres Byggherren. Fokus i dette dokumentet er Design, Drift og Vedlikeholdsdokumentasjon. Dokumentasjonen vil inneholde informasjon og dokumenter av ulikt slag. Denne anvisningen angir rekkefølgen og hva som er minimumsinformasjon eller nøkkelinformasjon som skal leveres for de ulike systemer og objekter i de ulike fasene. Prosjektet skal gjennomføres som et BIM prosjekt (BIM = Bygnings Informasjons Modell). All nødvendig informasjon som trengs for å forvalte, drifte, vedlikeholde og utvikle bygget skal samles inn og tilpasses BIM. BIM er blant annet en 3D modell som er oppbygd av 3D objekter med tilhørende egenskapsinformasjon. Bruk av BIM gir bedre mulighet for strukturering av informasjon og kan gi enklere tilgang til nøkkelinformasjon og dokumentasjon fra de ulike aktørene involvert i byggets levetid. Presisering: 1) Når det beskrives BIM i dette dokumentet så menes det åpenbim, basert på det åpne internasjonale filformatet IFC eller tilsvarende, såfremt ikke noe annet er angitt spesifikt. 2) Når det beskrives COBie 1 i dette dokumentet henviser det til innsamlingsregnearket som er utviklet av USACE og buildingsmart International for å lage et entydig grensesnitt mellom design og drift. Informasjon i dette regnearket kan høstes fra ulike BIM systemer eller kan brukes som ett tradisjonelt input regneark hvor informasjonen legges inn manuelt. Det kan gi betydelig fordeler for prosjektet, ved at viktig egenskapsinformasjon for systemer eller produkter kun registreres en gang i BIM modellen. Først lages en krav BIM som definerer byggherrens krav som kravsatt. Systemer og objekter med generisk og produktuavhengig informasjon vil så bli definert av prosjekterende som prosjektert. Etter at utførende har valgt leverandører vil så systemer og objekter oppdateres med leverandørspesifikk informasjon som bygd. I igangskjøringsfasen vil systemer og objekter oppdateres med innmålte verdier som innmålt. Når anlegget er i drift er det viktig at modellen vedlikeholdes og er oppdatert med hensyn på egenskapsinformasjon. Med andre ord er det 5 hovedfaser i system og objekt informasjonslivsløpet: som kravsatt ( As required ) dokumentasjon. som designet og prosjektert ( As designed ) dokumentasjon. som bygd ( As built ) dokumentasjon. som innmålt ( As tested ) dokumentasjon som driftet ( As operated ) dokumentasjon Tradisjonell FDV informasjonsinnsamling har skjedd via innsamlingsark som Tian DV s regneark, Statsbygg sitt innsamlingsark eller de enkelte FDV leverandørers spesial regneark eller direkte i databaser som TIDA. Byggherrens forutsetter at informasjonsstrukturen defineres i BIM programmene under prosjekteringen og at mest mulig av informasjonen legges direkte inn i modellen. For den informasjonen som ikke kan legges direkte inn i modellen, skal aktørene benytte andre åpne internasjonale standarder for utveksling av informasjonen. Byggherren har funnet bruk av COBie regnearket som formålstjenlig i denne informasjonsutvekslingen. Målsettingen med bruk av COBie er at de ovennevnte regnearkene delvis skal erstattes av COBie regnearket. 1 COBIE = Construction Operations Building Information Exchange Sykehuset i Vestfold HF Versjon: Side 6

7 Det er viktig å legge merke til at COBie regnearkfilen (Vedlegg 3) definerer minimumsnivået på FDV informasjon i prosjektet, sammen med kapitel 5 FDV dokumentasjon. Aktører som ikke har tilrettelagt informasjonen digitalt i f.eks BIM eller databaser kan også benytte COBie(regneark) som input regneark eller utvekslingsformat av digital informasjon. 3. Definisjoner Definisjoner som er benyttet i dette dokumentet er angitt i vedlegg Overordnede prosjektdokumenter Helsedirektoratet har utgitt en veileder for tidligfase planlegging 2, som skal brukes på større prosjekter innenfor sykehusutbygging. Følgende figur, som er hentet fra veilederen, angir faser og beslutningspunkter i prosjektets start og gjennomføringsfase. Byggherrens krav til FDV dokumentasjon tar hensyn til denne faseinndelingen. 2 Sykehuset i Vestfold HF Versjon: Side 7

8 5. FDV dokumentasjon i prosjektets faser 5.1 Prosjektets faser sett i forhold til Livssyklus og FDV Følgende figur viser prosjektets livssyklusprosess sett i forhold til de normale fasene hvor FDVdokumentasjonen skapes og brukes. FDV informasjonen skapes allerede i programmeringsfasen og suppleres/utvikles kontinuerlig frem til bruksfasen. TEK 10 stiller også eksplisitte krav til at prosjekterende skal fremskaffe FDV informasjon under prosjektering. Dokumentasjon som etableres i de respektive fasene: Programmeringsfase: Klargjøre forutsetninger for prosjektet Definere funksjonelle brukerkrav Formulere FDV tekniske krav Integrert Design Prosess (IDP): Utvikle målsettinger for bygget Utvikle løsninger for funksjonskrav (bruker sentrisk) Dokumentere alle hovedfunksjonskrav til systemer og produkter beskrives (design forutsetninger) Utvikle løsninger for integrerte funksjonskrav (design og teknikk) Etablere alle systemer og tilhørende objekter o Systematisk gjennomgang av krav o Definere systemer og egenskaper til systemer for å tilfredsstille krav o Definere produkttyper og egenskapskrav for produktene i de definerte systemene Byggefasen: Bestillingsfase oppdatere produkter og egenskapsinformasjon med leverandørspesifikk informasjon ned på komponent og artikkel nivå også inneholdende avhendingsinformasjon Leveransefase dokumentere endringer i endelig produkt leveranse Monteringsfase dokumentere hvordan det er montert og sammensatt Igangkjøringsfasen: Sykehuset i Vestfold HF Versjon: Side 8

9 Levere innregulering og ytelsesbekreftelse på systemer og produkter Levere nødvendig dokumentasjon for å få brukstillatelse (inkl samsvarserklæringer og uavhengig kontroll) Bruksfase Videreutvikle FDV forutsetninger i prosjektet til det aktuelle bygget Gjennomføre IDP for ombygging og utvikling av bygget Oppdatere FDV dokumentasjon både på modell og dokument jevnlig Avhending Dokumentasjon på hvordan produktene skal avhendes 5.2 Integrert Design Prosess med delprosesser Skissen viser prosessen fra tidlig programmering, design, produksjonen av det ferdige bygg (fra start til slutt, gjennom anskaffelse og montasje av delprodukter, produkter, systemer og integrerte systemer) til bygget rives. BIM skal benyttes aktivt i dette arbeidet, BIM defineres i denne sammenheng som bygningsinformasjonsmodellering og dekker modellering fra system til detaljert geometrisk utforming av ulike systemer. Sykehuset i Vestfold HF Versjon: Side 9

10 5.3 Produksjonsprosess med delprosesser Skissen viser prosessen ved produksjonen av det ferdige bygg med alle systemer. Prosessen dekker fra start til slutt, gjennom anskaffelse og montasje av delprodukter, produkter, systemer og integrerte systemer, og frem til bygget rives. 5.4 Modeller i prosjekteringsarbeidet De 5 hovedfaser i system og objekt informasjonslivsløpet er 1) som kravsatt ( As required ) dokumentasjon. 2) som designet og prosjektert ( As designed ) dokumentasjon. 3) som bygd ( As built ) dokumentasjon. 4) som innmålt ( As tested ) dokumentasjon 5) som driftet ( As operated ) dokumentasjon Dette vil også speile seg i modell revisjonene av BIMen. De fleste prosjekterende bruker i dag BIM systemer i prosjekteringsarbeidet. For å forenkle arbeidet med informasjon i modellen er det også viktig at objektbibliotekene, som benyttes i de ulike fag BIM programmene, er definert med riktige egenskapsfelt og mest mulig riktig informasjon på objektene. Som kravsatt er informasjon som ligger på objektene i BIM en som referanse og i prinsippet ikke skal endres. Som designet, bygd, innmålt og driftet innebærer at objektene oppdateres med leverandørspesifikk informasjon og så gjennomgår 3 hovedrevisjonssykler (bygd, innmålt og driftet). Sykehuset i Vestfold HF Versjon: Side 10

11 Dette medfører at nøkkelinformasjon på objektene vil ha flere verdifelt i modellen avhengig av hvilken fase informasjonen legges inn. BIMen vil ikke bare inneholde nøkkelinformasjon på objektene, men BIM en vil også kunne være et enkelt grensesnitt for gjenfinning av ulik FDV informasjon. Objekter kan også inneholde URLer (Universal Resource Locator er) som kan peke på ytterligere informasjonsressurser relatert til objektene. BIMen vil gi enklere informasjonstilgang til nøkkelinformasjon og linking til objektrelatert informasjon, og vil supplere tradisjonelle papirutskrift av FDV dokumentasjon. Ved riktig koding av BIMen vil den også bidra til å strukturere prosjekteringsarbeidet og tilhørende dokumentasjon på en måte som vil bidra til å forenkle tilgang til mer detaljert prosjekteringsdokumentasjon ved senere ombygginger, påbygginger eller utvikling av eiendommen. 5.5 Overlevering av modellinformasjon BIM skal brukes aktivt i prosjektet. Ved informasjonsoverlevering til drift er det er en forutsetning i prosjektet at all egenskapsinformasjon på BIM objektene skal være kvalitetssikret. Annen vedlikeholdsinformasjon knyttes til BIM objektene gjennom TFM koden og NS 3420 koden som da er nøkler for informasjonskoblingen. Det Tverrfaglige Merke Systemet (TFM) inneholder systematikk for å tagge/merke objekter med lokasjon, system angivelse og produkt/komponent angivelse og er uttrykt som: +P2= JV001 Som betyr bygg P2, system 360 løpenummer 001 og produkt JV001 Informasjonen kan suppleres til BIMen på flere måter. Byggherren forutsetter at informasjonsstrukturen (inkl Pset) blir etablert i de aktuelle BIM programmene i prosjekteringsfasen, og at det er kun supplering av informasjon som må importeres inn i BIMen. Dette medfører at det er den første av de to etterfølgende angitte måtene som er basis i dette kravdokumentet: 1. Direkte i BIM objektet med Pset 3 data. Utvekslingsformatet for BIMen skal være åpenbim/ifc. Det defineres ulike informasjons sett for å strukturere egenskapsinformasjonen på objektene. Følgende eksempler på informasjon skal være som tillegg til produktets egenskaper (ref. pkt 5.7): Pset om krav Pset om objektet Pset om designinformasjon Pset om drift og skjøtsel 3 Pset= PropertySet = EgenskapsSett Sykehuset i Vestfold HF Versjon: Side 11

12 Pset om vedlikehold og utskifting Informasjonsmengden vil måtte tilpasses de enkelte produkter/objekter. 2. Etablering i COBie regneark for import i BIM basen. Det vil prioriteres at de ulike aktører, leverandører, produsenter etablerer en programmatisk kobling mellom de ulike programsystemene for å automatisere overføring av informasjon. Ved bruk av CoBie som importark, vil en gjennom prosjektet få ulike versjoner som representerer informasjonsstatus i de ulike fasene av prosjektet. Sykehuset i Vestfold HF Versjon: Side 12

13 5.6 Leveranseomfang FDV dokumentasjon Både innsamling og overføring av DDV 4 dokumentasjon skal overføres i faser. I de ulike faser av prosjektet vil informasjonsmengden være noe forskjellig (Jfr. Vedlegg 2). Byggherren har definert to nivå på leveranseomfanget av FDV dokumentasjon: Nivå 1: Grunnleggende digital FDV dokumentasjon Nivå 2: Komplett modellbasert FDV dokumentasjon (utvidede krav i tillegg til nivå 1) Dersom krav til leveranseomfang ikke er angitt i forespørselsdokumentet, gjelder krav til nivå 2. Leveranseomfanget for PiV prosjektene skal være i henhold til Nivå 1. Detaljert beskrivelse på de to nivåene: 1. Grunnleggende digital FDV dokumentasjon 1.1 Det skal leveres en 3D BIM som er komplett (ARK, RIB, RIV, RIE, etc) basert på IFC formatet. 1.2 All informasjon skal leveres i digitalt format, både på åpne internasjonale standard formater (eks: IFC, PDF) og de opprinnelige filformatene (eks: RVT, DWG, XLS, DOC) med all opprinnelig informasjon inkludert. Tegninger skal leveres på PDF formatet. 1.3 Alle felt som er angitt med Nivå 1 i FDV regnearket (COBie) fylles ut. De informasjonsfelt som er angitt i COBIE regnearket skal som minimum defineres i prosjekteringsverktøyenes (eks: ArchiCAD og MagiCAD) EgenskapSett (PropertySet), og kunne eksporteres til OpenBIM IFC formatet og COBIE formatet. 1.4 De EgenskapsSett (Pset) som er definert i kapittelet 5 Designinformasjon skal etableres i prosjekteringsverktøyene. 1.5 Linker til datablad, vedlikeholdsbeskrivelser, etc skal fremgå i regnearket. 1.6 Intet datablad og/eller beskrivelser skal inneholde mer enn ett produkt på norsk (alternativt et annet skandinavisk språk), (såfremt ikke Byggherren skriftelig har gitt tillatelse til noe annet). 1.7 FDV dokumentasjon skal også leveres digitalt i PDF format, Word, Excel, DWG. For eksempel på detaljeringsnivå henvises til vedlegg All informasjon skal leveres i 2 eksemplarer på papirformat, hvor PDF tegninger etc skal leveres i originalstørrelsen (målestokk som er definert i tittelfeltet). For eksempel på detaljeringsnivå henvises til vedlegg Informasjonen om byggsystemer skal struktureres etter følgende struktur: Bygg System Delsystem Undersystem/modul Produkt Komponent Ar kkel 2. : Komplett modellbasert FDV dokumentasjon (All informasjon som er angitt på nivå 1, med følgende tillegg): 2.1 Alle felt som er angitt med Nivå 2 i COBIE regnearket fylles ut 2.2 All informasjon skal være strukturert og tilpasset innleggelse på Byggherrens Modellserver. Det er de prosjekterende og entreprenørene (og evt. leverandørene) som har ansvaret for at denne informasjonen blir lagt inn på modellserveren. 2.3 Dokumentasjon skal i størst mulig grad være basert på 3D modeller av produkter. Overlevering til byggherren kan skje på flere måter, hvor byggherren har fokus på to måter i prioritert rekkefølge: 1) Integrert åpenbim/ifc modell hvor nøkkel informasjon er tilgjengelig på objektnivå og hvor tilhørende pdf filer (tegninger, produktdatablader ) kan være linket til objektene. 4 DDV= Design, Drift og Vedlikehold Sykehuset i Vestfold HF Versjon: Side 13

14 2) Utfylt COBie FDV innsamlings regneark med tilhørende pdf filer (tegninger, produktdatablader, etc.). Det er byggherrens målsetting at metode 1 skal benyttes i størst mulig grad. Dersom byggherren (/Helse Sør Øst) underveis i prosjektet etablerer egen modellserver, kan byggherren kreve at oppdateringene skal skje mot denne uten ekstra kostnader fra de prosjekterende/entreprenøren. Følgende prinsippskisse viser hvordan FDV informasjonen genereres og aggregeres over tid, samt hvordan grensesnittet mellom de ulike programmene og BIM en er. Som vist i figuren henter de prosjekterende inn objekter i modellen som inneholder noe generisk informasjon, dette suppleres med prosjektspesifikke krav. Entreprenøren ajourfører modellen med as built informasjon, inklusiv 3D modeller av de objekter som leveres. Til sammen vil dette utgjøre FDVdokumentasjonen som importeres i FDV BIM programmet. 5.7 Designinformasjon Prosjekterende har ansvar for etablering av designinformasjon i BIM. Mengde informasjon vil variere fra produkt til produkt. Sykehuset i Vestfold HF Versjon: Side 14

15 Som et minimum skal det etableres informasjon i ulike faser av prosjektet mht krav, design, leveranse, idriftsettelse, drift og skjøtsel, vedlikehold/utskifting og avhending. Informasjonsmengden vil også variere for ulike faser. Prosjekterende er ansvarlig for å etablere de felt som andre aktører i prosjektet skal komplettere. Som et eksempel på informasjonen som er etablert i OpenBIM er i vedlegg 3 angitt som kolonneoverskrifter i CoBie. (Hvordan COBie er oppbygd er angitt i Vedlegg 6). For feltet system, komponent og attributt har man angitt i det etterfølgende hvilke informasjoner som kan være aktuelle for det enkelte produkt og system. Følgende presiseres: I utgangspunktet skal den etterspurte FDV informasjonen være på objekt/produktnivå, men for tekniske/andre komponenter hvor det er naturlig å skifte ut deler av produktet skal FDVinformasjonen speile dette og legges på respektivt komponent og artikkelnivå. I punkt og angis eksempler på Pset for ulike produkter. Et produkt er en funksjonell enhet i henhold til TFM. Ett produkt kan bestå av mange komponenter og artikler. I tillegg til produktets egenskapsdata skal følgende Pset felt etableres for produkter i prosjekteringsfasen: Supplerende Attributter produkt/komponent/artikkel: Pset krav: Egenskaper knyttet til kapasitet, funksjon, max temp, min temp, lyd, lys, hastighet, demping, akustikk, renhet, statisk elektrisitet, strømtilførsel, vanntilkobling etc Pset design: Egenskaper knyttet til design Dette er tilsvarende informasjon som i Pset krav, men basert på prosjektert løsning. Pset NS 3420: Egenskaper knyttet til NS 3420 koden så fremt denne finnes. NS kode, ytelse, kapasitet, merknad, antall, max lux, max dempning, max lyd,etc. Pset fysisk: Egenskaper knyttet til fysiske mål. lengde, høyde, bredde, vekt, volum Pset termisk: Egenskaper knyttet til termiske egenskaper Max trykk, Trykk klasse, min trykk, driftstrykk, max temp, min.temp, driftstemp. etc Pset akustisk: Egenskaper knyttet til akustikk, lyd, støy etc Pset atmosfærisk: Egenskaper knyttet til luftkvalitet, renhet etc Pset aktinisk: Egenskaper knyttet til, lys, stråling, magnetisme, etc Pset mekanisk: Egenskaper knyttet til mekanisk bruk etc Pset psykososialt: Egenskaper knyttet til psykososiale forhold etc. Pset estetisk: Egenskaper knyttet til form farge etc Pset knyttet til elektrisk tilkobling: spenning, fase, effekt, Cos pi, max effekt, max amp, etc Pset knyttet til automatisering: Type I/O, spenning, NC/NO, regulator ID, alarmnivå, Pset knyttet til igangkjøring: Innregulering, målinger, KS (sjekkliste) Pset knyttet til drift: Driftstid, frekvens for inspeksjon, funksjon, ytelse, begrensninger, MTTF, MTBF, Daglige/ukentlige rutiner for Sykehuset i Vestfold HF Versjon: Side 15

16 Skjøtsel, etc. Pset knyttet til betjeningstilgang: Betjeningsavstand fra produktets 0 pkt, avstand, bredde, høyde, lengde (for blant annet virtuell kollisjonskontroll av betjeningsvennlighet). Pset knyttet til vedlikeholdstilgang: Betjeningsavstand fra produktets 0 pkt, avstand, bredde, høyde, lengde (for blant annet virtuell kollisjonskontroll av vedlikeholdsvennlighet). Pset miljø: Egenskaper knyttet til stoffnavn, Cas nr etc Pset knyttet til vedlikehold: Periodiske rutiner for vedlikehold. type personell, fagområde, timer, verktøy, hjelpemateriell Pset knyttet til utskifting: Produktets levetid, rutiner for utskiftning, kostnader. Pset knyttet til avhending: Rutiner for avhending, kostnader, frekvens, metode deponering Pset Levetidskostnader (LCC): Driftstimer, Bruksbelastning, Renholdsnivå, etc Supplerende Attributter system: Pset krav: Egenskaper knyttet til kapasitet, funksjon, max temp, min temp, lyd, lys, hastighet, demping, akustikk, renhet, statisk elektrisitet, strømtilførsel, vanntilkobling etc Pset design: Egenskaper knyttet til design Dette er tilsvarende informasjon som i Pset krav, men basert på prosjektert løsning. I tillegg kommer linker til sprengskisser (exploded view) og delelister. Sann leverandør (produsent) og sann Leverandørs Partnummer skal oppgis. Pset fysisk: Egenskaper knyttet til fysiske mål. lengde, høyde, bredde, vekt, volum Pset termisk: Egenskaper knyttet til termiske egenskaper Max trykk, Trykk klasse, min trykk, driftstrykk, max temp, min.temp, driftstemp. etc Pset akustisk: Egenskaper knyttet til akustikk, lyd, støy etc Pset atmosfærisk: Egenskaper knyttet til luftkvalitet, renhet etc Pset aktinisk: Egenskaper knyttet til, lys, stråling, magnetisme, etc Pset mekanisk: Egenskaper knyttet til mekanisk bruk etc Pset psykososialt: Egenskaper knyttet til psykososiale forhold etc. Pset estetisk: Egenskaper knyttet til form, farge etc Pset knyttet til elektrisk tilkobling: spenning, fase, effekt, Cos pi, max effekt, max amp, etc Pset knyttet til automatisering: Type I/O, spenning, NC/NO, regulator ID, alarmnivå, Pset knyttet til igangkjøring: Innregulering, målinger, KS (sjekkliste) Sykehuset i Vestfold HF Versjon: Side 16

17 Pset knyttet til drift: Driftstid, frekvens for inspeksjon, funksjon, ytelse, begrensninger, MTTF, MTBF. Daglige/ukentlige rutiner for skjøtsel. Pset miljø: Egenskaper knyttet til stoffnavn, Cas nr etc Pset knyttet til vedlikehold: Periodiske rutiner for vedlikehold, type personell, fagområde, timer, verktøy, hjelpemateriell, Pset knyttet til betjeningstilgang: Betjeningsavstand fra produktets 0 pkt, avstand, bredde, høyde, lengde (for blant annet virtuell kollisjonskontroll av betjeningsvennlighet). Pset knyttet til vedlikeholdstilgang: Betjeningsavstand fra produktets 0 pkt, avstand, bredde, høyde, lengde (for blant annet virtuell kollisjonskontroll av vedlikeholdsvennlighet). Pset knyttet til utskifting: Produktets levetid, rutiner for utskiftning, kostnader. Pset knyttet til avhending: Rutiner for avhending, kostnader, frekvens, metode deponering 5.8 RFID merking av komponenter I utgangspunktet ønsker byggherren RFID merking av alle komponenter i bygget. Følgende utgjør minimumsnivået for det som skal RFID merkes: Alle moduler (basert på industrialisert produksjon) skal RFID merkes. Alle tekniske produkt og komponenter som vil være gjenstand for normalt vedlikehold og utskiftning. Byggtekniske komponenter som svært sjelden er gjenstand for vedlikehold/utskiftning trenger ikke RFID merking. Byggutstyr/innredning og inventar/møbler Brukerutstyrskomponenter Dersom de prosjekterende/entreprenøren er usikker på om et objekt skal RFID merkes fremmes det for byggherren for avgjørelse. RFID brikkene skal: Være av typen passiv RFID: ISO C Tilfredsstille standarden GS1 EPC Global Tag Data Standard ( standard pdf) Tåle det miljøet de utsettes for med god margin. Skal fungere i miljø med mye metall og vann. Brikken skal plasseres i/på objektet slik at retningen er tilpasset servicepersonellets lesing av brikken. Primært skal brikken være plassert inne i objektet. Dersom dette ikke er mulig eller hensiktsmessig skal den enkelt kunne festes til produktet/komponenten på både plane og krummede flater RFID brikken (tag en) for produkter(/komponenter/artikler) skal inneholde EAN strekkoden som produktet normalt får fra produsenten, sammen med den unike RFID identifikasjonen. Sykehuset i Vestfold HF Versjon: Side 17

18 5.9 System og produktinformasjon. Leverandørinformasjon Entreprenører og leverandører skal komplettere informasjonen. Dette gjelder spesielt egenskapsfeltene som er etablert. All informasjon skal registreres digitalt i BIM modellen, alternativ kan man benytte eksport til COBie regnearket (Excel) for innfylling og import i databasen. Ved bruk av COBie må innfylling påregnes flere ganger. Informasjonsmengden vil variere for de ulike produkter, men alle egenskaper, informasjon, montasje og bruk av produktet skal registreres i de enkelte felt Igangkjøring, ferdigstillelsesinformasjon I forbindelse med igangkjøring, ferdigstillelse skal informasjonen angitt i forskrifter og byggherrens krav, som eksempelvis målinger, innreguleringer, beregninger, kontroller, etc registreres i 3D BIMen, alternativt kan her også benyttes COBie formatet. Her må det påregnes flere registreringer. Jfr. Kap Driftsfasen For driftsfasen skal all informasjon som er nødvendig for å bruke, drifte, vedlikeholde samt foreta utskiftinger av produkter og systemer. Det er viktig at alle jobbrutiner for drift og skjøtsel og vedlikehold er komplette uten at det er nødvendig å slå opp i andre dokumenter. Jfr. Kap Avhending. For avhendingsfasen skal all informasjon om produktet knyttet til miljø etableres. Det er nødvendig at denne informasjonen kan oppdateres i byggets levetid, da krav og kunnskap om produkters avhengig vil kunne ende endre seg i byggets levetid. Jfr. Kap Overordnet informasjonsmatrise Vedlegg 2 viser overordnede informasjonsmatriser, hvor det fremgår hvilket nivå av informasjon som skal frembringes til hvilken fase prosjektet er i, samt hvor beskrivelsene og spesifikasjonene skal etableres, ajourføres og ferdigstilles. Antall nivå er avhengig av kompleksiteten til systemet, og må justeres tilsvarende. Når det er fylt ut i et felt i matrisen skal den aktuelle informasjonen gjøres tilgjengelig for Byggherren i den aktuelle fasen/perioden. Informasjonen skal ajourføres løpende (i startfasen med maximum 7 kalenderdagers intervall og i slutten av byggefasen ved hver endring evt. daglig) i byggherrens system (webhotel, modelserver, tilsv.). Byggherren har mulighet til å kreve daglig oppdatering av informasjon, dersom det anses nødvendig fra Byggherrens side. 6.1 Hvordan skal informasjonen kunne aksesseres: Informasjonen bør minst være tilgjengelig via følgende metoder i et FDV system: Systemet (eksempelvis velge Ventilasjonssystem i en overordnet meny, for deretter å kunne gå til riktig nivå i en hierarkisk struktur) Sykehuset i Vestfold HF Versjon: Side 18

19 Byggets hierarkiske struktur: Lokasjon, sone, bygg, etasje, rom, modul/komponent (Eksempelvis gå via rommet og velge de elementer som inngår i det aktuelle rommet for eksempel via inntasting, 3D modell, strekkode og/eller RFID merking av komponent) Funksjon (eksempelvis velge Temperaturregulering og få opp de systemer som er knyttet til den funksjonen i det aktuelle området) Dette medfører at all informasjon skal lagres slik at den har både hierarkisk og relasjonell tilknytning. 7. Innsamling og utvekslingsformat Etterfølgende figur viser hvordan informasjonen skal etableres og kommuniseres. Aktørenes ansvarsområde: Rådgiverne (inkl Arkitekt) benytter sine BIM baserte fagprogrammer til å etablere 3D modeller basert på objekter som har definerte riktige informasjonsfelt (EgenskapSett/PSet) ihht det som er definert i vedlagte COBIE regneark. Dette eksporteres i IFC format til den felles 3D BIM en, samt til COBIE regnearket. Entreprenør/Leverandør høster informasjon fra BIM en og fra COBIE regnearket, og fyller ut med produktspesifikke data fra underleverandørenes databaser. Komplette og utfylte COBIE regneark skal så eksporteres inn i 3D modellen og direkte til FDV programmet som velges. Aktørene er også ansvarlig for å ajourføre 3D modellen, blant annet ved å fremskaffe eksakte 3D modeller av de leverte objekter og erstatte de generiske produktene med det som leveres. Entreprenøren/Leverandøren har ansvar for at all FDV dokumentasjon er implementert i BIM en og legge til rette for implementering i Byggherrens FDV program. Sykehuset i Vestfold HF Versjon: Side 19

20 8. Revisjonsutgaver All informasjon i prosjektet skal knyttes til BIM en og vedlikeholdes jevnlig. All informasjon i prosjektet skal lagres med status. FDV dokumentasjonen skal inneholde komplette utgaver av: som kravsatt ( As required ) dokumentasjon. o Ansvar: Prosjekteringsgruppeleder o Tidsfrist: Før Detaljprosjektfasen er sluttført som designet og prosjektert ( As designed ) dokumentasjon. o o Ansvar: Prosjekteringsgruppeleder Tidsfrist: Før Detaljprosjektfasen er sluttført. Dersom endringer: Før utførelse på byggeplass påbegynnes. som bygd ( As built ) dokumentasjon. o Ansvar: Total /Hovedentreprenørs Oppdragsansvarlig o Tidsfrist: Før Igangkjøringsfasen starter opp som innmålt ( As tested ) dokumentasjon o Ansvar: Total/Hovedentreprenørs Prosjekteringsleder o Tidsfrist: Før Driftsfasen starter som driftet ( As operated ) dokumentasjon o Ansvar: Driftsorganisasjonen o Tidsfrist: Løpende De prosjekterende ved Prosjekteringsleder er ansvarlig for at dette gjennomføres i prosjekteringsfasen sammen med Entreprenørenes oppdragsansvarlige. 9. Organisering Entreprenøren skal oppnevne en FDV ansvarlig for seg og sine underentreprenører og dokumentere at disse personene har nødvendig kompetanse og erfaring innen fagområdet. Ved større entrepriser kan det være behov for at entreprenøren etablerer del FDV ansvarlige for hovedfagområdene. FDV skal være et fast punkt på prosjekteringsmøter, byggemøter, fremdriftsmøter evt i egne særmøter. Entreprenøren skal delta på FDV møter med Byggherren og dens driftsorganisasjon. Entreprenøren skal innarbeide rutiner for planlegging, produksjon og kvalitetssikring av FDV dokumentasjon og sluttdokumentasjon i egen organisasjon. FDV dokumentasjon skal synliggjøres i prosjektets dokumentplan. Sykehuset i Vestfold HF Versjon: Side 20

21 10. Vesentlig del av leveransen FDV dokumentasjonen anses som en vesentlig del av leveransen og skal være helt komplett og godkjent av byggherren for at sluttfaktura skal kunne sendes fra entreprenørene. Opplasting av informasjon til web hotel/modellserver underveis i prosjektet er viktig. Dialog med byggherren vedrørende FDV dokumentasjonens form og innhold anbefales i hele prosjektets gjennomføringstid, for å unngå forsinkelse i gjennomgangen hos byggherren på slutten av prosjektet. 11. Eierskap og rettigheter Byggherren skal ha eierskap og alle rettigheter (inklusiv men ikke begrenset til opphavsrett) til alt arbeidet som er gjort i forbindelse med oppdraget, også med hensyn til alle data som ligger i BIM og FDVdokumentasjon og andre leveranser utviklet og fremskaffet av de prosjekterende og entreprenørene/leverandørene. Byggherren får full bruksrett til fabrikatspesifikke opplysninger for gjenbruk innen statens helseforetak og forvaltning, men overtar ikke opphavsrettighetene. Entreprenøren er ansvarlig for at byggherrens rettigheter knyttet til dette oppdraget, videreføres og sikres i avtaler med underentreprenører, leverandører, etc. Sykehuset i Vestfold HF Versjon: Side 21

22 Vedlegg 1 Definisjoner Begrep Merkesystem Id merking, FDVU dokumentasjon Design informasjon Kravspesifikasjon Programmeringsfase Integrert prosjektering Bygging Igangkjøring, ferdigstillelse Drift Avhending Tidligfase Gjennomføringsfasen Driftsfasen BIM OpenBIM COBIE Beskrivelse Tverrfaglig merkesystem for identifikasjon av alle bygningsmessige og tekniske installasjoner. Merkesystemet bygger på Statsbygg sitt Tverrfaglige merkesystem, men er modifisert for SIV Dokumentasjon av alle leveranser som forklarer Design, forutsetninger, oppbygging, installasjon, drift, vedlikehold og utskifting av et system/produkt. For prosjektet skal det leveres digital versjon, modellversjon og papirversjon. All informasjon som danner grunnlag for valg av produkter og systemer. Dette er beregninger, min maks data, etc Inngår i FDVU dokumentasjon Byggherrens funksjonelle krav (/ytelseskrav) Utarbeidelse av løsninger basert på krav spesifikasjon prosjekteringsfasen Bygg og installasjonsfasen Kontroll og igangkjøring av bygg og tekniske installasjoner Bruksfasen hvor bygg og teknikk benyttes i dets levetid Riving, deponering etter endt levetid for de enkelte produkt Idé, konsept og forprosjektfasen Detaljprosjekt, bygging og ibrukstaking Bruksfasen hvor bygg og teknikk benyttes i dets levetid BIM = BygningsInformasjonsModell BIM basert på den åpne internasjonale standarden IFC (tilsv.), og som administreres av med norsk avdeling: Excel regneark som har eksportert informasjon som andre aktører skal komplettere/revidere for import tilbake til BIM basen og til FDV programmet. Siste gyldige versjon skal benyttes (Pr 03/2011 er det COBie2). Construction Operations Building Information Exchange (COBie) er et standardisert grensesnitt mellom utbygging og drift. I Norge har vi innsamlingsregneark for ulike FDV systemer, og COBie regnearket definerer et regneark grensesnitt som alle BIM og FDV systemene kan forholde seg til. Initiativet bak COBie kommer fra US Army Corps of Engineers (USACE) men buildingsmart North America har overtatt utviklingsansvaret. 3E KU 3D modell Etableres Krav Utvikles Sykehuset i Vestfold HF Versjon: Side 22

23 KF 3A BE BA SE SA SF Byggeweb/Web hotell Aktør. FDVU instruks Produkt. Krav Fastsettes 3D modell Ajourføres Beskrivelse Etableres Beskrivelse Ajourføres Spesifikasjon Etableres Spesifikasjon Ajourføres Spesifikasjon Ferdigstilt Prosjektet benytter et Web hotell system. Internettbasert arkivsystem hvor aktørene overfører til og henter informasjon Aktør er rådgiver, entreprenør, leverandør eller andre som bidrar til leveranser til Oppdragsgiver. Generell informasjon om et system/produkt. Dette er et ekstrakt av den viktigste informasjon fra FDVU dokumentasjon. Et produkt består av delprodukter som er satt sammen til en funksjonell enhet basert på prosjektets merkesystem. Et funksjonelt produkt kan bestå av flere koder for NS Et funksjonelt produkt kan bestå av flere komponenter (delprodukter) Komponent Artikkel System Produkt fysisk ferdig (PFF) System fysisk ferdig (SFF) Funksjonstest pr. System. (FTS) Integrert funksjonstest flere systemer. (IFT) En komponent inngår i et produkt og kan bestå av en og flere artikler Artikkel inngår som delkomponent i en komponent. Den minste komponenten som et produkt/komponent kan bestå av. Et system består av to eller flere produkter sammenbygget til et statisk eller dynamisk enhet for å dekke en funksjon i henhold til merkesystemet. Systemet er avgrenset innenfor samme systemnummer i hht prosjektets merkesystem. Milepel når et produkt er ferdigmontert på byggeplassen og kontrollert og FDV dokumentasjon er supplert Milepel når alle produkter i et system er fysisk ferdig og koblet sammen i et system (ferdigmontert) og kontrollert og FDV dokumentasjon er supplert Milepel når systemet er igangkjørt, innregulert og ferdig testet og dokumentert av entreprenør/leverandør. Det omfatter også systemets grensesnitt mot øvrige systemer og entrepriser for at systemets funksjon blir ivaretatt. Testprotokoller, innregulering/måleprotokoller og annen FDV dokumentasjon er oppdatert. Systemet er da klart for å inngå i Integrerte funksjonstester. Integrert funksjonstest består av flere systemer som er sammenbygget for å oppfylle tverrfaglige funksjoner (scenarier). Denne fasen ledes av byggherren med deltakelse av totalentreprenøren. Dette gir grunnlag for start prøveperiode. Befaring for prøvedrift Befaring for kontroll av/om vilkårene for oppstart prøvedrift er tilstede. Sykehuset i Vestfold HF Versjon: Side 23

24 Prøveperiode Totaltest 1 Totaltest 2 As built / Som bygget DAK manual Prøveperioden starter etter at Integrerte funksjonstester(scenarietester) er utført og godkjent samt at befaring for prøvedrift er utført og godkjent. Totaltest 1 utføres med brukerutstyr innenfor prøveperioden. Totaltesten foretas med ulike scenarier med simulert virksomhetsdrift for enkelte viktige områder. Denne aktiviteten ledes av byggherren. Totaltest 2 utføres med brukerutstyr etter innflytting. Totaltesten foretas med ulike scenarier og ledes av driftsorganisasjonen. Som bygget; tegninger, dokumentasjon, måleprotokoller etc. DAK retningslinjer som benyttes for etablering av AutoCad tegninger. De ulike aktørers DAK manual må samstemme med prosjektets DAK manual. DAK manualen skal primært være en del av BIM manualen. BIM manual Pset TFM Autorisert personell Bruksanvisning Brukerveiledning FDVU system Produktets 0 punkt MTTF MTBF GUID MVD Kontroll BIM retningslinjer som benyttes for etablering av lukket fag BIM og åpen team BIM. Statsbygg sbim manual angir også hvilke egenskaper som skal defineres på de ulike objektene i de ulike faser av prosjektet. Property Set eller på norsk Egenskaps Sett. Definerer et sett med sammenhørende egenskaper på et gitt objekt type med et gitt navn. Statsbygg s tverrfaglige merkesystem. Informasjon tilgjengelig på Statsbygg s hjemmeside. Teknisk medisinsk personell som har gjennomgått opplæring i bruk av systemer og utstyr. Bruksanvisningen er for teknisk/medisinsk personell (autorisert personell) og er et ekstrakt av FDVU informasjonen som er nødvendig for å betjene og forstå de ulike systemer. Bruksanvisningen skrives ut i hendig format, f.eks. A5. Dette vil i hovedsak være kortversjoner av beskrivelser og informasjon inklusiv tegningsutsnitt/skisser som finnes i FDV dokumentasjonen. Brukerveiledningen er for uautorisert personell som informasjon til brukere i bygget om f.eks. hensikt, hvordan betjenes etc. Dette skal eventuelt samkjøres med annen brukerveiledning og etableres i et hendig format som legges ut til brukeren på samme måte som informasjon om telefon, PC, persienner, temperatur, etc. For spesielt utstyr skal brukerveiledning henges opp i plastramme ved utstyret. Edb system som benyttes til oppfølging og lagring av informasjon om bygningen og oppgaver innenfor forvaltning, drift, vedlikehold og utvikling. Referansepunkt for angivelse av vedlikeholdsområdet på ulike sider av et produkt. Referansepunktet angis av prosjekterende/leverandør og skal angi området som er nødvendig for drift og vedlikehold av produktet/systemet. NB! Dersom det må være tilgang på andre sider enn betjeningssiden så må dette også angis. Mean Time To Failure Mean Time Between Failure Globally Unique Identifier (Globalt unik identifikasjonskode) Model View Definition Utprøving, kontroll, registrering og dokumentasjon av om det produserte (del ) resultat oppfyller tekniske og funksjonelle egenskaper i.h.t. funksjoner, tegninger og beskrivelser. Sykehuset i Vestfold HF Versjon: Side 24

25 Kontrollområde Fysisk avgrenset produksjonsområde som del av byggeobjektet. Kontrollområder fastsettes i forbindelse med utarbeidelse av produksjonsplanene. For Vedlegg 8 Minimum detaljeringsnivå for leveranse av FDV dokumentasjon på PDFformat og papirformat, gjelder disse definisjonene: DV innsamling/ Digital FDVU dokumentasjon Excel importark FDVU dokumentasjon hvor produkt og systeminformasjon skal skrives inn i Excel regneark for overføring til byggherren sitt digitale FDVU system Lydia eller tilsvarende. Instrukser, produktdatablad, beregninger, innreguleringer etc overføres i digitalform til Web hotellet. Excel ark som er laget av Lydia eller tilsvarende. Fortløpende innfylling av informasjon og senest oppdatert nå produktet kommer på byggeplassen. Sykehuset i Vestfold HF Versjon: Side 25

26 Vedlegg 2 Overordnet informasjonsmatrise Forklaringer til forkortelsene som er benyttet i informasjonsmatrisene nedenfor inklusiv hvem som er ansvarlig for fremskaffelse: Informasjon Hovedansvarlig Delansvarlig 3E= 3Dmodell Etableres Prosjekterende KU= Krav Utvikles Byggherre Prosjekterende KF= Krav Fastsettes Prosjekterende Byggherre 3A= 3Dmodell Ajourføres Prosjekterende BE= Beskrivelse Etableres Prosjekterende Byggherre BA= Beskrivelse Ajourføres Prosjekterende SE= Spesifikasjon Etableres Entreprenør Prosjekterende SA= Spesifikasjon Ajourføres Entreprenør Prosjekterende SF= Spesifikasjon Ferdigstilt Entreprenør Prosjekterende System Konseptfase Forprosjekt Byggets Ytelesmål defineres Detaljprosjektfase Kontraheringfase Byggefase Igangkjøringsfase Driftsfase Design fase Benevnelse/Egenskaper: Navn/Type/etc. KE BE KF BA SE SA SF Egenskaper (inkl kapasitet/ytelse, etc) KE BE KF BA SE SA SF Systembeskrivelse/funksjon BE BA BA SE SA SF 3D modell av Systemet 3E 3A 3A 3A 3A 3A 3A Dimensjoner/vekt/etc BE BA SE SA SF Bygge og Driftsfase Beskrivelser: Installasjon BE SE SF Igangkjøring SE SF Bruk SE SF Vedlikehold SE SF Utskiftning SE SF Sanering SE SF Sykehuset i Vestfold HF Versjon: Side 26

27 Delsystem Konseptfase Forprosjekt Byggets Ytelesmål defineres Detaljprosjektfase Kontraheringfase Byggefase Igangkjøringsfase Bruksfase Designfase Benevnelse/Egenskaper: Navn/Type/etc. KE BE KF BA SE SA SF Egenskaper (inkl kapasitet/ytelse, etc) KE BE KF BA SE SA SF Systembeskrivelse/funksjon KE BE BA SE SA SF 3D modell av Systemet 3E 3A 3A 3A 3A 3A 3A Dimensjoner/vekt/etc BE BA SE SA SF Bygge og Bruksfase Beskrivelser: Installasjon BE SE SF Igangkjøring SE SF Bruk SE SF Vedlikehold SE SF Utskiftning SE SF Sanering SE SF Sykehuset i Vestfold HF Versjon: Side 27

28 Undersystem/Modul Konseptfase Forprosjekt Byggets Ytelesmål defineres Detaljprosjektfase Kontraheringfase Byggefase Igangkjøringsfase Bruksfase Designfase Benevnelse/Egenskaper: Navn/Type/etc. KE BE KF BA SE SA SF Egenskaper (inkl kapasitet/ytelse, etc) KE BE KF BA SE SA SF Systembeskrivelse/funksjon KE BE BA SE SA SF 3D modell av Systemet 3E 3A 3A 3A 3A 3A 3A Dimensjoner/vekt/etc BE BA SE SA SF Bygge og Bruksfase Beskrivelser: Installasjon BE SE SF Igangkjøring SE SF Bruk SE SF Vedlikehold SE SF Utskiftning SE SF Sanering SE SF Det presiseres at generiske 3D objekter skal byttes ut med valgte 3D objekter i byggefasen, slik at sombygget blir likt med det fysisk bygde miljø. Produkt Sykehuset i Vestfold HF Versjon: Side 28

29 Konseptfase Forprosjekt Byggets Ytelesmål defineres Detaljprosjektfase Kontraheringfase Byggefase Igangkjøringsfase Bruksfase Designfase Benevnelse/Egenskaper: Navn/Type/etc. BE BA SE SA SF Egenskaper (inkl kapasitet/ytelse, etc) BE BA SE SA SF Systembeskrivelse/funksjon BE BA SE SA SF 3D modell av Systemet 3E 3A 3A 3A 3A 3A 3A Dimensjoner/vekt/etc BE BA SE SA SF Bygge og Bruksfase Beskrivelser: Installasjon BE SE SF Igangkjøring SE SF Bruk SE SF Vedlikehold SE SF Utskiftning SE SF Sanering * SF *Med enkelte produkt skjer det også noe i denne fasen Det presiseres at generiske 3D objekter skal byttes ut med valgte 3D objekter i byggefasen, slik at sombygget blir likt med det fysisk bygde miljø. Sykehuset i Vestfold HF Versjon: Side 29

30 Komponent Konseptfase Forprosjekt Byggets Ytelesmål defineres Detaljprosjektfase Kontraheringfase Byggefase Igangkjøringsfase Bruksfase Designfase Benevnelse/Egenskaper: Navn/Type/etc. BE SE SA SF Egenskaper (inkl kapasitet/ytelse, etc) BE SE SA SF Systembeskrivelse/funksjon BE SE SA SF 3D modell av Systemet 3E 3A 3A 3A 3A Dimensjoner/vekt/etc BE SE SA SF Bygge og Bruksfase Beskrivelser: Installasjon SF Igangkjøring SE SF Bruk SE SF Vedlikehold SE SF Utskiftning SE SF Sanering SE SF *Med enkelte komponenter skjer det også noe i denne fasen Det presiseres at generiske 3D objekter skal byttes ut med valgte 3D objekter i byggefasen, slik at sombygget blir likt med det fysisk bygde miljø. Sykehuset i Vestfold HF Versjon: Side 30

31 Artikkel Konseptfase Forprosjekt Byggets Ytelesmål defineres Detaljprosjektfase Kontraheringfase Byggefase Igangkjøringsfase Bruksfase Designfase Benevnelse/Egenskaper: Navn/Type/etc. SF Egenskaper (inkl kapasitet/ytelse, etc) SF Systembeskrivelse/funksjon 3D modell av Systemet 3A 3A 3A Dimensjoner/vekt/etc SF SF Bygge og Bruksfase Beskrivelser: Installasjon Igangkjøring Bruk Vedlikehold SE SF Utskiftning SE SF Sanering SF Sykehuset i Vestfold HF Versjon: Side 31

32 Vedlegg 3 Egenskapsinformasjon til systemer og produkter som skal inkluderes i FDV dokumentasjonen. Navnet på tabellen (øverste rad) angir navnet på arkfanen i COBIE regnearket. Felt som er angitt med rød tekst/kursiv er felt som byggherren etterspør og som kommer i tillegg til COBIEregnearkets standardfelt, og skal fylles inn. Norsk oversettelse av COBIE regnearket er vist sammen med engelsk original tekst: Kontakt Contact Nivå (ref. pkt 5.7) Epost 1 OpprettetAv CreatedBy 1 OpprettetTid CreatedOn 1 Kategori Category 1 Firma Company 1 Telefon Phone 1 EksternSystem ExtSystem 1 EksternObjekt ExtObject 1 EksternIdentifikator ExtIdentifier 1 Avdeling Department 1 OrganisasjonsKode OrganizationCode 1 Fornavn GivenName 1 Etternavn FamilyName 1 Adresse Street 1 Postboks PostalBox 1 Poststed Town 1 Region/ Fylke StateRegion 1 Postnummer PostalCode 1 Land Country 1 URL/Webadresse 1 Bygg Facility Nivå (ref. pkt 5.7) Navn Name 1 OpprettetAv CreatedBy 1 OpprettetTid CreatedOn 1 Kategori Category 1 ProsjektNavn ProjectName 1 LokasjonsNavn SiteName 1 Sykehuset i Vestfold HF Versjon: Side 32

33 LengdeMål LinearUnits 1 ArealMål AreaUnits 1 VolumMål VolumeUnits 1 ValutaEnheter CurrencyUnits 1 ArealMålinger AreaMeasurement 1 EksternSystem ExtSystem 1 EksternObjekt ExtObject 1 EksternIdentifikator ExtIdentifier 1 EksternLokasjonObjekt ExtSiteObject 1 EksternLokasjonIdentifikator ExtSiteIdentifier 1 EksternByggObjekt ExtFacilityObject 1 EksternByggIdentifikator ExtFacilityIdentifier 1 Beskrivelse Description 1 ProsjektBeskrivelse ProjectDescription 1 LokasjonBeskrivelse SiteDescription 1 Fase Phase 1 Gab nummer 1 Bygg ID 1 Kontraktsnavn 1 Kontraktsnummer 1 Kontraktsdato 1 Overtakelsesdato 1 BYA, bebygd areal 1 Etasje Floor Nivå (ref. pkt 5.7) Navn Name 1 OpprettetAv CreatedBy 1 OpprettetTid CreatedOn 1 Kategori Category 1 EksternSystem ExtSystem 1 EksternObjekt ExtObject 1 EksternIdentifikator ExtIdentifier 1 Beskrivelse Description 1 KoteHøyde Elevation 1 Høyde Height 1 Sykehuset i Vestfold HF Versjon: Side 33

34 Rom Space Nivå (ref. pkt 5.7) Navn Name 1 OpprettetAv CreatedBy 1 OpprettetTid CreatedOn 1 Kategori Category 1 EtasjeNavn FloorName 1 Beskrivelse Description 1 EksternSystem ExtSystem 1 EksternObjekt ExtObject 1 EksternIdentifikator ExtIdentifier 1 RomMerke RoomTag 1 BruksHøyde UsableHeight 1 BruttoAreal GrossArea 1 NettoAreal NetArea 1 RFIDtagNr 1 Romfunksjonsnummer 1 Geografisk nummer 1 Romnummer 1 RomType 1 Kallenavn 1 BRA 1 OBRA 1 REA 1 VEA, Vektet areal 1 Volum 1 OBS! Alle romfunksjonsopplysningene (felt og verdi, inkl felt hvor verdi ikke er fylt ut) som er registrert i Planleggingsprogrammet (for eksempel drofus) skal eksporteres til modellen (3D BIM) ved bruk av IFCformatet, knyttet til de respektive Space/Rom. FDV systemet vil således ha tilgang til programmeringsdata via BIM. Dette medfører at antall felt som skal inkluderes under fanen Rom/Space blir vesentlig større enn det som er angitt ovenfor. Dersom Planleggingsprogrammet ikke kan eksportere dette til modellen, skal dette gjøres via COBIEregnearket under fanen Space/Rom. Utstyrslisten pr rom skal også eksporteres til modellen, enten fra Planleggingsprogrammet til modellen eller via COBIE regnearket, koblet opp mot Space/Rom. Sykehuset i Vestfold HF Versjon: Side 34