Bygherres kravstillelse, denne gang med udgangspunkt i BIM?
Submitted by ibkaa on Wed, 25/08/2010 - 21:48
Status på ”Vejledning for aflevering af digital arealinformation ”også kaldet ”Information Delivery Manual(IDM)”,udarbejdet på initiativ af Slots- og Ejendomsstyrelsen med deltagelse fra Universitets og Bygningsstyrelsen og Forsvarets Etablissementstjeneste.
Siden den sidste status har IDMén været et par gange frem og tilbage for kommentering hos de statslige bygherrer. Dette kombineret med sommeren som bød på spredt ferie for projekt deltagerene resulterede i en aflevering af en 90% færdig skitse den 11. August. Dette møde var jeg så heldig at få lov til at deltage i på trods af at min praktik periode hos Slots og Ejendomsstyrelsen udløb den 30. juni.
Derudover har alle 3 statslige bygherrer tilsluttet sig Slots- og Ejendomstyrelsens initiativ. SÅ IDMén skal betragtes som en samlet kravstillelse fra Slots og ejendomsstyrelsen, Universitets og bygning styrelsen og Forsvarets Etablissementstjeneste.
På mødet deltog Clars Danvold, Slots og Ejendomsstyrelsen, Jonas Lindhart, Universitets og Bygningsstyrelsen, Jan Karlshøj, Karlshoej, Stig Brinck, Niras, Bent Dalgaard, Dalux og undertegnede.
På mødet blev IDMén gennemgået af Jan Karlshøj og Stig Brinck som blev modtaget positivt. Der var dog nogle mindre kommentarer til selve opsætningen så som placering af bokse og lign.
Selve IDM er bygget op efter ISO/DIS 29481-1. Denne standard leverer metode og format til etablering af IDM. Vil du selv lege med det kan den købes her for den nette sum af kr. 750,- +forsendelse.
Først vil jeg forklare lidt om opbygningen og efterfølgende komme lidt ind på om IDM er det rigtige valg.
Som nævnt i det tidligere blog indlæg så drejer denne IDM om at stille entydige krav til en BIM leverance omhandlende arealer.
IDM opbygning:
Introen består af stamoplysninger og forklaring af IDM´s formål og mål generelt. Der formuleres også hvorfor arbejdet den beskriver skal udføres. Dette gøres for at skabe mening for slutbrugeren af IDM. Kort sagt ber beskrives hvilken værdi det stykke arbejde har som slutbrugeren af IDM skal udføre. Denne del er rettet mod beslutningstagere.
Leverance og aflevering
Nu bliver IDM´en mere specifik. Nu fokuseres der på selve udvekslingen af de oplysninger, som i dette tilfælde bygherre ønsker. Altså hvordan transaktionerne er projekt deltagerene imellem. Først senere bliver de enkelte data sæt specificeret.
.png)
Procesbeskrivelse
Nu går vi fra den overordnede beskrivelse af transaktionerne til beskrivelse af selve processen i detaljer. Her kan det virke til at blive kombliseret. Og man skal da også lige granske processen en gang eller to.
Men kort beskrevet så er række følgen:
1. Bygherre informerer rådgiver omkring hvilke data han ønsker at modtage
2. Denne kravstillelse formuleres og formidles til den rådgiver der er ansvarlig for modelleringen af bygning eller lignende
3. Rådgiver leverer en IFC space model med de korrekte data
4. Data tjekkes hos Driftsherre, er alt i orden modtages en kvittering og opgaven er færdig.
5. Er der fejl i modellen kører den en omgang til indtil at alle fejl er rettet.
Specifikation af aflevering
Her bliver det så meget nørdet og for den nørdede mere konkret. Her beskrives i hvilken fase vi er i projektet og så kommer listen med properties fordelt i relation til bygning/etage/rum (Markeret med rødt). Der vil sige de ting der skal tastes ind i modelleringsprogrammet.
Forretningsregler
Her lister man de ting som skal indgå for at IDMen opfylder kravene. Eksempelvis at data skal komme fra et bestemt sted.
.png)
Guide med screen shots fra DDS IFC viewer, Revit og Archicad
I forbindelse med udarbejdelse af IDMén har der også foregået en afprøvning for at sikre at de programmer som skal levere data rent faktisk også kan dette. Man har afprøvet to programmer Revit og Archicad og en viewer, DDS IFC viewer. I forbindelse med dette havde Revit problemer med at placere et af datasættene. Dette er givet videre til Autodesk og er ikke vurderet til at være kritisk for data leverancen. Ovenstående resulterede også i en kort vejledning med eksempler fra de forskellige programmer.
Hvad mangler?
Noget af det der mangler er for at komme helt i mål er en komplet rumliste fra de de statslige bygherrer og derefter en konkret afprøvning af IDM. SES forventer dette vil ske i efteråret og UBST har også flere byggerier i pipelinine som vil være oplagte til afprøvning. Derudover forventer Clars Danvold fra SES at koordinere den udarbejdede IDM med de øvrige nordiske lande via hans deltagelse i det nordiske bygherre netværk NKS og derigennem at skabe bedre vejledninger og klarerer skabeloner så de bedre kan stille krav og udveksle erfaringer/viden gennem IDM
Men er IDM overhovedet en god IDE?
Og er det den rigtige vej at gå?
Nogen siger at IDM og IFC ikke er udviklet tilstrækkeligt. Og jeg kan kun sige at det har ikke været let for mig i de indledende faser at finde vejledninger og formidlingsmateriale. Dernæst har det været svært at navigere i de forskellige initiativer i de enkelte buildigSMART chapters. Her kunne man med fordel se på hvordan andre open source projekter som Linux og Drupal opererer.
Tilbage til IDM. Den har som sådan baggrund i en ISO standard og er derfor til at arbejde med. IDM og IFC tager også afsæt i BIM og fokuserer på data i stedet for dokumenter og streger. Hvilket er et godt grundlag for en fremadrettet satsning på området.
Set fra et statsligt synspunkt må det være den eneste rigtige vej at gå. Bekendtgørelsen om Det Digitale Byggeri stiller krav til IFC. Dette gør de antageligt fordi de mener at åbne standarder er det rigtige for staten at satse på. Dette afspejler sig i BIM umbrella statement som er underskrevet af Danmark, Norge, Findland, Holland, USA og Canada. I denne forpligtiger de sig til at: ”understøtte BIM med åbne standarder. Herunder at deltage i open BIM relateret forskning , udvikling og samarbejde med udgangspunkt i statens egne bygninger” som der står i hensigtserklæringen.”(frit oversat)
Så hvis de skal følge deres egen hensigts erklæring så vil det give mest mening at benytte IDM som er det tilhørende værktøj til formidling af IFC kravene.
Et andet argument kunne være at, det faktum at Danmarks krav bygger på internationale åbne standarder vil gøre at software udviklere tør satse på at udvikle software til danske forhold, da de let kan tilpasse dem til det globaliserede marked efterfølgende. Enhver software udvikler med bare en lille smule ambition ville aldrig turde satse på det danske marked med 5 millioner indbyggere konta EU på over 400 millioner, kontra kloden på +6 milliader....
Til sidst mange tak til Clars Danvold, SES, Jonas Lindhart, UBST, Moten Klitgaard Pedersen FBE, Jan karlshøj, karlshoej og Stig Brinck, Niras for at jeg har fået lov til at kigge med over skulderen på projektet. Det har været spændende og yderst lærerigt.
- ibkaa's blog
- Login or register to post comments
- 1284 reads
Comments
"I forbindelse med dette havde Revit problemer med at placere et af datasættene. Dette er givet videre til Autodesk og er ikke vurderet til at være kritisk for data leverancen."
Er det muligt at vi kan få af vide hvilket datasæt der er tale om. Måske er der nogen herinde der kan løse det:-)
Det drejer sig om alle eksisterende Revit datasæt og alle dem som brugeren selv laver. Undtagen egenskaber som er findes i IFC2x3 specifikationerne som properties. Hvis man indlæser en IFC fil fra Revit vil man fx i Solibri Model Checker/Viewer se at Revit indgår i navnet på de fleste property sæt. Hvis der er nogle som har et bud på hvordan man kan oprette et egenskabssæt i Revit uden at Revit indgår i navnet - så er jeg interesseret at vide hvordan det er gjort.
Det er mig bekendt ikke muligt i Revit 2011 eller tidligere udgaver, at tilføje ikke standard IFC egenskaber til objekter i Revit uden at de kommer til at optræde i egenskabssæt, hvor "Revit" indgår i navnet af egenskabssættet. Betech har samme opfattelse, men tilbyder at få tilføjet danske egenskabssæt på lige fod med egenskabssæt fra GSA i USA. Jeg mener at dog at den rigtige løsning er at man selv skal kunne navngive egenskaber som man har lyst. I ArchiCAD kan man selv bestemme hvad egenskabssættet skal hedde. Hvis alle programmer tilføjer deres eget navn i egenskabssættene bliver unødvendigt besværligt at indlæse data i andre programmer.
Jan Karlshøj
Da SES gik i gang med IDM, er der da blevet kigget på det arbejder der alterreder er lavet med Forvaltnings Klassifikation?
I denne "rapport"(kapitel 6) er listet alle de egenskaber en bygherre bør stille krav om for arealer, rum og bygningsdel. De har tilmed beskrevet hvordan de skal afleveres i IFC og hvordan mapping mellem DBK og SFB kan gøres. Faktisk lavet en IDM om man vil...
Synes det er en skam at hvis SES laver deres eget system.
Her er link til den endelige version af den omtalte IDM som nu er tilgængelig via SES.dk
http://ses.dk/da/Vaerktoejer/~/media/Files/Vaerktoejer/Raadgiveraftaler/IDM%20-%20DK-GOV-Area.ashx
Som Jan nævner er problemet med Revit omgået ved at de 3 statslige bygherrer i første omgang tillader at navnet "revit" indgår i egenskabssættet.
Hey
IDM virker helt rigtig, da det kan udvikles i takt med at vi bliver klogere og bedre. DBK forudsætter at vi kender alle de mulige resultater, for at kunne oprette de tilhørende tabeller, hvilket ikke sker i en verden i bevægelse.
Jeg har måske misforstået noget, men jeg troet egenskaberne i høj grad var givet ud af DBK koden.
På DDB står (http://www.detdigitalebyggeri.dk/tech-article/egenskaber-og-egenskabsdata) står der:
I DBK indgår egenskabsdata med sit eget domæne, således at egenskaber pr definition er en parameter i klassifikationen. Her defineres egenskab som ”karakteristisk særpræg” (DS/EN ISO 9000:2000). Egenskabsdomænet i DBK opererer med følgende underbegreber:
•Grundlæggende egenskab: Egenskab som fastlægger identifikationen af et (bygge)objekt (DBK)
•Materiel egenskab: Fysisk opfattelig egenskab ved et (bygge)objekt (DBK)
•Kulturel egenskab: Subjektiv opfattelig egenskab ved et (bygge)objekt (DBK)
Hvordan hænger det så sammen med IDM?
Hvorfor stille krav om både DBK og IDM?
Jeg er synes det virker som dobbelt arbejde.
Lad os sige at IDM skal udarbejdes for at vide hvilke "karakteristiske særpræg" der skal bruger og hvordan de skal bruges/beskriver, sådan at de kan indgå i DBK-koden. Hvad skal vi så med DBK-koden, som jo så bare lister egenskaber som allerede findes, som en slags maskinkode.
Jeg kan ikke se hvorfor denne "maskinkode" er så vigtig, kun at den kan bruge af IT-systemer, men har vi lavet en IDM kan egenskaberne i sig selv vel lige så godt brugs. Det virker for mig som den simple løsning.
Som jeg ser det, så ligger den stor udfordring i at lave en fælles liste over rumtype, enheder og andre værdier (hvordan staves de, hvad betyder de osv.). En opgave som den enkelte sagtens kan gå i gang med for at komme i gang, men som vi skal have en standart for uanset om vi vælger DBK eller IDK. Fordelen ved IDM er bare at vi kan gå i gang nu, hvor vi med DBK må vente til alle er enige.
Hej
IDM handler om hvad man har brug for. Om det så kan håndteres via en DBK-kode eller ej er op til parterne, der laver en IDM at afgøre. DBK er under revision og jeg ved ikke hvor det ender.
Jeg ved derimod at IDM i kombination med IFC giver mulighed for at udveksle data mellem it-systemer. I meget om materialet omkring DBK har det været fremhævet, at DBK "gav it-systemløsning" på kommunikationen i branchen. Det mente jeg ikke var korrekt. Det er blevet fjernet i de seneste rapporter fra EBST. DBK er system - ikke et traditionelt klassifikationssystem - som kan opbygge informationer i en tekststreng, men mig bekendt giver det ikke svaret på en it-mæssig implementering. Det er for mig ikke klart hvordan DBK-koder skal overføres mellem systemer og hvordan alle andre informationer skal overføres, hvis man alene benytter sig DBK.
Jeg ser IDM, som en metode til at specificere informationsindhold. Man kan så bruge IFC indbyggede variabel til klassifikation eller oprette en særlig variable til DBK-koden. Håndtering af tekniske parametre, materialer, geometri, relationer med mere kan så håndteres via IFC.
DBK kan ikke erstatte IDM. IDM fjerner ikke et evt. behov for klassifikation. At DBK i dets nuværende form ikke er et klassifikationssystem er så en anden snak.
Jan
Hej Jan
Tak for et rigtig fint svar. Det var faktisk er meget klart og ærligt svar. Hatten af for det.
Jeg havde faktisk ikke forventet et svar på mit spørgsmål, da det ofte er et politisk varmt emne.
Jeg har et andet spørgsmål i forbindelse med DBK og IDM. Hvordan sikre man at der altid er overensstemmelse mellem de to?
Et eksempel kunne være et rum hvor DBK siger at det er et kontor, men room name (IDM) siger at det er et arbejdsværelse. Det er et tænkt eksempel, og måske ikke et særligt godt et. Hvilken af de to ”egenskaber” har ret?
Jeg tænker at det ikke er så stor et problem ved rum navne, men hvis en egenskab fra IDM’en skal bruges i DBK koden, er det vel vigtigt at opmålingsreglerne er de samme. Eller er jeg gal på den?