12 010 Egenskabsdata Opsamling på læsning af baggrundsmateriale
Indhold Egenskaber ISO 12006-3 eclass IDM COBie Egenskabers placering - overvejelser Læseliste kommentar Whole Building Design Guide 3D arbejdsmetode 2006 (egenskaber & informationsniveauer) F103 objektstruktur 2008 Forvaltningsklassifikation 2009 (egenskaber) Norsk Statsbygg BIM-MANUAL 1.1 & 1.2 beta 1 (egenskaber/informationsniveauer/lod) SPie CIB Master List IFC 2x3 Property Sets
Noter - egenskabsprojekt Bent Dalgaard Larsen Dalux
Agenda Egenskaber ISO 12006-3 eclass IDM COBie Egenskabers placering - overvejelser Læseliste - kommentar
Egenskaber Bruges i: Maskiner: Standard udveksling mellem programmer gbxml, Be10, IFC property sets som benyttes af programmer Mennesker: Søgning på produkter Beskrivelser
ISO 12006-3 Fra 2004! En standard for hvordan egenskabsdata defineres Ret lille standard. Beskrevet i EXPRESS formatet (Dvs. det samme som f.eks. IFC formatet er beskrevet i) Hvis man har forstået IFD har man også forstået ISO 12006-3. Det er bare en formaliseret måde at beskrive det hele på Dog indeholder ISO 12006-3 noget ekstra om interaktion (xtdrelactsupon) Jeg har forsøgt at få fat i mere om IFD men det er ikke gået så godt. En del mails men ingen svar?
IFD (ISO 12006-3) i applikationer I IFD benyttes en GUID + et navn mv. Hvordan passer dette ind i dagens programmer? Risiko for for denne morale: Fint koncept men vi skal lige have Autodesk og mange andre til at ændre fundamentalt i deres systemer?
IFD ISO12006-3 formål En stor del er søgning i egenskaber (når man skal finde produkter) En konkurrent til SPie? (SPie nævner ikke IFD og IFD nævner ikke SPie) IFD ser ikke ud til at relatere sig til Programmer: F.eks. gbxml, Be10 IDM/MVD er: Har ikke set noget der forbinder disse Dvs. formål må være find et produkt?
IFD ISO12006-3 - konklussion IFD virker ikke til at være interessant når det handler om dataudveksling mellem programmer Ihvert fald ikke på kort eller mellemlangt sigt Siden der ikke eksisterer offentligt tilgængelige programmer som benytter denne ISO standard fra 2004 kan man sætte spørgsmål ved om tankerne er rigtige
IDM BuildingSMART process En beskrivelse af hvordan man udveksler informationer En IDM definerer: HVEM kræver informationenen HVORFOR HVORNÅR HVILKE informationer HVEM modtager informationer Der findes en ISO der definerer hvordan man skriver disse ting MVD (Model view definition) bruges til at beskrive hvilke egenskaber BIM modellen skal indeholde
IDM - definitioner Process map (PM) + Exchange requirement (ER)
IDM Det ser ud til at der hovedsageligt findes IDM er som ikke er implementeret i praksis Det er nemt at finde definitioner på IDM er Det er meget svært at finde eksempler på IDM er der faktisk har været brugt og case stories (COBie er undtagelsen)
COBie Construction Operations Building Information Exchange (COBie) Udveksling af IFC baseret data til FM Defineret som et udtræk til et XLS dokument Dvs. al information er defineret i IFC og trækkes ud derfra Defineret som en IDM http://idm.buildingsmart.no/confluence/display/i DM/COBIE+Project
COBie data Vedligehold Garantier Reservedele Forbyggende vedligehold Resourcer Drift Startup/nedluknings procedure Fejlhåndtering Produkt Størrelse/pladskrav Flytbarhed Funktioner Lokation Produktdata
0
COBie for/imod For: Åbent format, læseligt af alle (Excel) Mange relevante informationer Imod: De data der er defineret i COBie svarer ikke nødvendigvis til den måde FM systemer vil have dem på. Detaljeringer er ikke god nok F.eks. Stort eller lille eftersyn eller en bil skal til service efter 30.000 km eller 1 år kan ikke beskrives Den er ikke forberedt for at der kan komme opdateringer til informationerne (ID er er f.eks. rene tekster der skal være unikke) Systemet burde også i det mindste teoretisk kunne håndtere at vedligeholdelsesvejledninger bliver opdateret
Min holdning til COBie Nogle rigtige tanker Er dog umiddelbart simplificeret for meget Detaljeringen er dog gået lidt op og ned mellem COBie til COBie2 Man får lyst til at lave en COBie3 som er mere avanceret, men kan konverteres til COBie2 (dog med tab af informationer). Men retningen og tilgangen til digital aflevering virker rigtig
eclass eksempel på en anden klassifikation med egenskaber Tal.tal.tal.tal Egenskabsdata altid på niveau 4 Hvilke egenskaber der benyttes er defineret ud fra klassifikationen Bliver brugt i Gea koncernen 4600 ansatte, 40 lande og 500 i Danmark Nu indført på Gea-Niro i den danske underafdeling Bliver brugt til at holde styr på deres forbrug og klasificering af nye ting de laver De har mange af de traditionelle problemer: Objekter kan ligge flere steder det kan diskuteres hvor der er rigtigt En kultur af få klasificeret alle nye ting korrekt http://www.eclasscontent.com/
IFC hvad kan det indeholde Alt Spørgsmålet er dog hvor meget det bør indeholde? - og hvornår det bør indeholde hvad? Det hele afgøres af dataflowet F.eks. Revit->IFC->COBie Her giver det ikke mening af tilføje informationer direkte til IFC, da enhver opdatering i Revit vil overskrive alt indhold Alle BIM værktøjer understøtte kan en subdel af IFC Konklussion Så selvom IFC i princippet kan indeholde alt giver det ikke mening at lægge alle data i IFC
Hvor skal egenskaber tilknyttes? På klassifikationsstrukturen? Dette gøres f.eks. i eclass. Dette er nok fornuftigt hvis det kun er formålet at bruge egenskaber til at finde objekter Uafhængigt af klassifikationen? Mere hensigtsmæssigt hvis objekter skal opfylde forskellige behov IT mæssigt F.eks. kan en pumpe indeholde egenskaber til brug for dimensionering, energi eller drift og vedligehold. Det er vel fint at pumpen kan indeholde 1 eller flere af disse MVD s (Hedder det det når det er på objekter? IFC mangler for øvrigt objekt fil formatet)
Egenskaber versus klassifikation Objekt Klassifikation Egenskab1 Egenskab2 Egenskab3 MVD1 MVD2 MVD 1: Energi MVD 2: Drift & Vedligehold
Overvejelser om materialet til litteratur studiet Litteraturlisten består hovedsageligt af teoretisk materiale F.eks. ISO 12006-3, IFD, IDM Materialet burde suppleres med: Revit, AutoCAD, Vico, Tekla, IES VE, Rambyg, Rockwool Energy Design, ArchiCAD, Bentley Architecture, drofus, MagiCAD, gbxml etc. Produktblade: Velux, Velfac, Isover, Danfoss, Grundfos Det er problematisk hvis vi opbygger noget ud fra ikke anvendt teoretisk materiale som ikke passer sammen med det som folk faktisk anvender
Resume 12010-02: SPie
12010-02: SPie SPie (Specifiers Properties) udvikles til leverandører, sådan at de kan erstatte datablade med en IFC/IfcXML fil, hvori alle relevante produktdata er defineret. Specifiers Properties gør brug af IFC Property Sets til at definere egenskaber, samt OmniClass til at klassificere den omhandlende bygningsdel. SPie definere egne Property Sets til formålet, men føler IFC strukturen.
Ekspempel på product template: 12010-02: SPie
Resume 12010-04: CIB Master list of Headings for the arrangement and presentation of information in technical documents for design and construction from 1993
12010-04: CIB Master list Cim Master List er en række definitioner af terminologier for gruppering af egenskaber. Terminologierne er: Dokument Krav Teknisk beskrivelse Funktionalitet Design krav Udførelse Drift og brug Vedligehold
Ekspempel på product template: 12010-02: SPie
Resume 12010-06: IFC 2x3 Property set definition reference, 2005 http://buildingsmart-tech.org/ifc/ifc2x3/tc1/html/index.htm
12010-06: IFC 2x3 Property set definition reference, 2005 Property Sets (PSets) er grupperinger af egenskaber, som kan tilknyttes IFC objekter (IfcEntities). Med IFC 2x3 findes 317 PSets til beskrivelser af bl.a. funktionskrav, materialeegenskaber, driftshistorik, ressourcer mv. Egenskaber ligger dog ikke entydigt defineret i PSets I IFC. Bl.a. navn, type, klassifikationskode, system, zoneinddeling, placering og geometri defineres via andre IfcEntiteter. PSet definitioner kan udføres via STEEP eller XML. buildingsmart har planer om at skabe online adgang til Pset definitioner via XML Web Service funktionen i IFD. buildingsmart lægger op til at der nationalt/i organisationer udvikles egne PSets, med ønsket indhold. Der ser ikke ud til at være en international udvikling inden for PSet definitioner pt.
12010-06: IFC 2x3 Property set definition reference, 2005 Eksempel på Property Set som kan tilknyttes et IfcSpace: I PSet definitionen angives hvilke entities det enkelte PSet kan tilknyttes
12010-06: IFC 2x3 Property set definition reference, 2005 Mangel på entydighed, samme information kan genfindes flere steder: Egenskaber har ikke en entydig enhed. Egenskaber defineres via f.eks. IfcAreaMeasure, IfcVolumetricFlowRateMeasure osv. Enheder defineres derpå generelt for hele IFC modellen via IfcUnits
Whole Building Design Guide Et program under National Institute of Building Sciences i USA The goal of 'Whole Building' Design is to create a successful high-performance building by applying an integrated design and team approach to the project during the planning and programming phases. Fokus er planlægning og programmering - og altså ikke udførsel og drift Hjemmesiden indeholder en sektion om Operation and maintenance men ikke noget om udførsel Hjemmesidens afsnit er gennemgået i det følgende
Design Guidance Denne indeholder anbefalinger vedr. nedenstående facetter i designprocessen Design objectives Denne sektion indeholder vejledning i forbindelse med design med henblik på at opfylde specifikke mål m.h.t. tilgængelighed, æstetik, pris, drift, bygningsbevarelse, arbejdsklima, sikkerhed og bæredygtighed. Building types Vejledning i design af forskellige bygningstyper. Dette kan være relevant i forbindelse med egenskaber for bygninger. Space types Vejledning i design af forskellige rumtyper. Dette kan være relevant i forbindelse med egenskaber for rum. Design disciplines Gennemgang af roller i forbindelse med designprocessen. Dette kan være relevant i forbindelse med definition af roller og aktører i ressourcedomænet. Products & systems Vejledning i design i forbindelse med produkter og byggesystemer opdelt efter bl.a. CSI Masterformat. Kan være relevant i forbindelse med egenskaber for materialer i ressourcedomænet.
Project Management Denne sektion indeholder vejledning i projektplanlægning i forbindelse med designprocessen.
Operations & Maintenance Gennemgang af processer i forbindelse med drift og vedligehold. Fokuserer bl.a. på hvilke data man skal have styr på at udføre drift og vedligehold samt på hvordan dette kan håndteres i IT-systemer.
Documents & References Henvisninger til ekstern dokumentation. Indeholder bl.a. et værktøj til at søge i egenskaber i Masterformat og Uniformat.
Tools Gennemgang af IT-værktøjer, der anvendes i byggebranchen. Listen virker ikke superrelevant - indeholder f.eks. ikke Revit, Vico, Solibri eller andre for os velkendte produkter.
Continuing Education Oversigt over videreuddannelsestilbud i regi af WBDG.
BIM Redegørelse for BIM samt BIM-initiativer fra NIBS og branchen samt en oversigt over dokumenter om BIM organiseret efter indgangene Design, Procure, Assemble og Operate.
Applied Research Oversigt over relevante forskningsprojekter
Vurdering Da WBDG er procesorienteret er den ikke særlig relevant i forhold til arbejdet i egenskabsdataprojektet. Koblingen til egenskaber skal findes igennem SPIE, som der henvises til i WBDG. I forhold til cuneco kan WBDG inddrages i forhold til arbejdet med Informationsniveauer, da det er i denne sammenhæng man vil kigge på de processer, der vil anvende egenskabsdata.
Indhold 3D arbejdsmetode 2006 (egenskaber & informationsniveauer) F103 objektstruktur 2008 Forvaltningsklassifikation 2009 (egenskaber) Norsk Statsbygg BIM-MANUAL 1.1 & 1.2 beta 1 (egenskaber/informationsniveauer/lod)
3D arbejdsmetode 2006 (egenskaber & informationsniveauer) Egenskaber Løst beskrevet med mange henvisninger til objektstruktur Der er funktionsbestemte egenskaber, geometriske egenskaber og ellers bare objektegenskaber!? Egenskaber/objektegenskaber beskrives mest i relation til de forskellige informationsniveauer som udtryk for konkretiseringsgrad Ordet egenskaber fremgår i ordlisten kun under objektdata (Data om objektets egenskaber fx type, klasse, funktion, materiale mm.)
3D arbejdsmetode 2006 (egenskaber & informationsniveauer) Informationsniveauer De 7 informationsniveauer svarer nogenlunde til den traditionelle faseopdeling i byggeri!? Informationsniveauer er uafhængige af konstellationer Informationsniveauerne adskiller sig ved, hvor konkret de anvendte byggeobjekter og byggeobjektegenskaber er specificeret Et givent informationsniveau er generelt ens for alle bygningsdele (objekter) indenfor den enkelte fagdisciplin og på tværs af fagdisciplinerne Egenskaber i et givent informationsniveau specificeres jf. objektstruktur
Min holdning til 3D arbejdsmetode 2006 Nogle rigtige, men tidlige tanker Egenskaber er løst beskrevet og ikke entydigt defineret Informationsniveauer er rigtigt tænkt, men er brugt for generelt ift. de enkelte bygningsdele som indgår i bygningsmodellen på givent tidspunkt Informationsniveauer skal IKKE sættes lig med fasemodel Informationsniveauer bør i et eller andet omfang kunne beskrive detaljeringen pr. bygningsdel og kan måske derfor ikke bruges som en generel betegnelse for en hel bygningsmodel!?
F103 objektstruktur 2008 Definerer regler for navngivning og indehold for de mest anvendte objekter og sætter sammenhæng mellem byggeobjekt, egenskabsdata og informationsniveau Objektstrukturen kan bruges som afsæt for kvalitetskontrol af bygningsmodeller Objekttyper: Rumlige objekter Fysiske objekter Sammensatte / administrative objekter Navngivning af egenskaber bygger på DBK og listerne indeholder også tilsvarende IFC navngivning
F103 objektstruktur 2008 Hvis der anvendes detaljerede objekter tidligt i projektet er det informationsniveauet som beskriver hvilke egenskaber der er taget stilling til og dermed valide Brug af objekter og objektstruktur tager afsæt i de projektspecifikke IKT-specifikationer
Min holdning til objektstruktur 2000 Nogle rigtige, men tidlige tanker Sammenhæng til informationsniveauer er svær at få øje på. (Objektstruktur henviser til 3D arbejdsmetode, og 3D arbejdsmetode henviser til objektstruktur) Vi skal vælge rigtigt mht. navngivningsprincipper for egenskaber Kongstanken med en objektstruktur fungerer ikke i en papirversion, vi skal have et digitalt værktøj
Forvaltningsklassifikation 2009 (egenskaber) Klassifikation som er udviklet til anvendelse i ejendomsforvaltningen med fokus på digital kommunikation Definition af egenskaber: Ved et byggeobjekts egenskaber forstås dets iboende og funktionelle karakteristika samt relationer objekter. FI2XML er tænkt som et fælles udvekslingssprog (format) IFC er også tænkt som et fælles udvekslingssprog eller hvad!?
Forvaltningsklassifikation 2009 (egenskaber) De udarbejdede tavler med egenskabsdata er et første forsøg på at tilvejebringe en anvendelig struktur Dette er en udbygning af tabellen for bygningsdele og dermed en skitse til en samlet struktur for egenskabsdata for objektklassen bygningsdele.
Min holdning til forvaltningsklassifikation Fokus er kun på drift Det virker ikke som om arbejdet er gjort færdigt Er det her overhovedet en standard? Jeg er ikke helt sikker på at jeg forstår det der er skrevet, men måske er det bare mig der ikke er klog nok!?
Statsbygg BIM-MANUAL 1.1 & 1.2 beta 1 Generelt BIM-manualen indeholder generelle retningslinjer for bygningsinformationsmodellering (BIM) med brug af IFC for informationsudveksling BIM-manualen har fokus på nytteværdi af BIM, men beskriver som sådan ikke BIM-processer og er ikke en CAD-manual Alligevel lugter det også lidt af en CAD-manual
Statsbygg BIM-MANUAL 1.1 & 1.2 beta 1 Version 1.1 Indeholder skema med fasebeskrivelse / informationsniveauer pr. fagdisciplin pr. fase
Statsbygg BIM-MANUAL 1.1 & 1.2 beta 1 Version 1.1 (fortsat) Indeholder skema med egenskaber, hvem der er ansvarlig og hvilke informationer i hvilken fase Navngivning af egenskaber er på engelsk og skal jf. manualen være IFD navngivning Navngivning af egenskaber er ikke unik pr. bygningsdel IFC property type og data type er angivet i skemaet
Statsbygg BIM-MANUAL 1.1 & 1.2 beta 1 Version 1.2 beta 1 Faser henviser nu til Processprotocol.com Fagdiscipliner henviser til OmniClass tabel 33 Klassifikation i øverste niveau er indarbejdet Informationsniveauer er døde og erstattet af LOD Manualen indeholder krav til opbygning og navngivning af objekter i BIM-model samt indhold i en given fase
Statsbygg BIM-MANUAL 1.1 & 1.2 beta 1 Version 1.2 beta 1 (fortsat) Krav til egenskaber er indbygget i samme tabel Konceptet for Level of Development (LOD) er inspireret af IAI og citygml
Statsbygg BIM-MANUAL 1.1 & 1.2 beta 1 Version 1.2 beta 1 (fortsat) Konceptet Model Element Author (MEA) er fra AIA dokument E202
Min holdning til BIM-MANUAL 1.1 & 1.2 beta 1 Det er også en CAD-manual Men hvor er oversigten over egenskaber i version 1.2? Hvis de er fjernet med vilje er verdenen så klar til IFD og er IFD klar til verdenen?? LOD tankegangen er interessant - Statsbygg har tilpasset dette til egne behov! Helt sikkert det bedste og nyeste jeg har læst, og der er mange gode ting som cuneco og bips kan bruge, men det er ikke for lægmand!