Kommentar Foreslået ændring Kommentarer fra arbejdsgruppen

Transkript

1 KOMMENTARSKABELON Dato Udfyldt af: Høring CCS kodestruktur Kaj A. Jørgensen Henvisning Type af kommentar (G/T/R) G Kommentar Foreslået ændring Kommentarer fra arbejdsgruppen En af Cunecos projektgrupper vedrørende klassifikation har nu udsendt et første rapportudkast og indbudt til høring. Der vil tilsyneladende ske to væsentlige ændringer som hilses velkommen: ) Efter vi er nogle, der nu i flere år har påpeget, at DBK på bygningsdelsområdet ikke er et klassifikationssystem i egentlig forstand, ser det ud til at der nu skal udvikles klassifikationstabeller for bygningsdelstyper og rumtyper. ) Der vil ligeledes blive udviklet klassifikationstabeller for rumfunktioner og bygningsdelsfunktioner. Disse nyskabelser bliver imidlertid ikke fremlagt i denne omgang, selv om det absolut er påkrævet at få skabt sikkerhed for, at denne udvikling vil være grundlagt på et sundt fundament. Der er således endnu ikke opsat en klar påpegning af formålet med udvikling af klassifikationssystemer i et tidssvarende perspektiv. Så efter flere måneders arbejde, er det relativt skuffende, at det udelukkende er såkaldt kodningsregler, der er fremlagt. Emner, der i denne sammenhæng er helt sekundære. Det er endvidere særdeles skuffende, at der tilsyneladende lades hånt om de mange høringssvar, der tidligere er udarbejdet til det danske "klassifikationsarbejde". I det fremsatte forslag er der stadig en stærk fokus på det emne, der vel mest betegnende kan kaldes opmærkning af bygningsdele via en sammensætning af koder. En sådan form for opmærkning og fokus på koder er uvæsentlig ved IT-baserede systemer eller bygningsmodeller, hvor koderne under alle omstændigheder vil være til internt brug og ikke noget brugere skal håndtere.

2 T Forekomst og Individ Omtalen af nogle helt grundlæggende begreber bliver forplumret, når begrebet 'forekomst', som ganske vist hidtil (i DBK) har været uklart defineret, nu skal udtrykkes som 'objektforekomst' og i øvrigt iklædes en ny betydning. I daglig tale er begrebet jo synonym med 'eksemplar af et eller andet' og dermed også synonym med 'individ'. I rapporten udtrykkes det som type af objekt, hvilket er det stik modsatte og dermed klart forvirrende. Det er svært at se begrundelsen for i den grad at skabe forvirring. Det medvirker yderligere til forvirringen, at begrebet 'objekt' også skal forstås i en fremmed betydning (i teksten benyttes flere betydninger). Nogle steder bliver det udtrykt som 'objektindivid', hvilket er dobbeltkonfekt. Andre steder forklares 'Objektindivid' som et 'specifikt produkt, der indkøbes', hvorved der sker en uholdbar indsnævring af betydningen. Det tyder mest på, at man med vold og magt ønsker at hænge sig fast i noget, som allerede er dømt ude, hvilket er i modstrid med erklæringen om at "tavlen er vasket ren". Helt galt bliver det, når der i en note præciseres, at definitionerne gælder (cit.) 'objekter betragtet i den virkelige verden, og omfatter derfor ikke en model repræsentation af samme objekt'. Hermed er forvirringen total, idet hele den fundamentale opfattelse af rapportindholdet smuldrer. Det er helt afgørende, at der skelnes skarpt mellem 'den virkelige eller fysiske verden' og forskellige former for beskrivelse af denne, altså modeller heraf. Med en beskrivelse er der jo altid tale om en mere eller mindre bevidst forenkling (model) af virkeligheden. (Med modeller menes her ikke nødvendigvis den gængse opfattelse af bygningsmodeller eller BIM modeller men mere generelt. Dokumentbaserede beskrivelser eller objekter i specialsoftware kan også betragtes som modeller.) Det forbistrede er ganske vist, at begrebet 'objekt' i bred forstand både kan benyttes om noget fysisk og om en 'data container', også præciseret som 'dataobjekt' (se figur ). Hvis ikke rapportindholdet (om kodning mv.) primært handler om håndtering af data om rum og bygningsdele (i 'den virkelige verden'), altså beskrivelse heraf (eller mere stringent 'repræsentation heraf'), så er sigtet med rapporten fuldstændig forfejlet. I det følgende vil begrebet 'objekt' blive opfattet som 'dataobjekt'/'data container', herunder som 'modelobjekt' som illustreret i figur. Desuden: Et objekts attributter/egenskaber kan være af forskellig art, herunder de almindelige: numerisk, tekst, osv. (inkl. koder) og kan desuden referere til andre objekter (illustreret med pile i figur ). Visse attributter kan eksempelvis beskrive eller referere til byggeprodukter (hvis man ikke i stedet indsætter en produktmodel). Begrebet 'objekttype' er en "skabelon" for objekter i overensstemmelse med almindelig opfattelse inden for informationsmodellering. Forudsætningen for ethvert objekt er altså, at der er defineret en objekttype. Objekter skabes altså som eksemplarer (forekomster) af en given type. Mere kompliceret behøver det ikke at være.

3 T Identifikation I rapporten forekommer emnet identifikation som en del af kodningen og det er en absolut uheldig sammenblanding, idet påsætning af koder ikke har noget med identifikation at gøre. Koder indsættes i objekter som led i beskrivelse af bygningsdele, altså specifikation og de er blot at betragte som helt almindelige egenskabs værdier, der kun er særlige værdier, fordi de refererer til positioner i f.eks. eksisterende tabeller (se eksempelvis attributten 'Classification' i figur ). En sådan kode er ganske vist en identificering af en tabelindgang men det er jo en helt anden sag og må ikke forveksles med identifikation af et objekt. Noget sekundært er, at man derved tilfører objektet identitet (altså noget andet end identifikation). Misforståelsen kan muligvis også hidrøre fra den sprogbrug, der anvendes i forbindelse med at søge efter et informationsobjekt ved at benytte en eller flere søgenøgler og dermed indsnævre søgningen indtil man har fundet eller identificeret det søgte. Éntydig identifikation af et objekt fødes altid med objektet og er derfor i software applikationer som regel systemgenereret (se ID attributten i figur ). Men mere bruger-venlige ID er eller navne kan sagtens tilføjes, hvis det er hensigtsmæssigt (se Name attributten i figur ). En navngivning skal i sagens natur være brugerrettet og bør derfor ikke gøres unødig besværlig ved at anvende koder men i stedet mere klar tekst eller entydige forkortelser. Identifikation har derfor ikke nødvendigvis noget med klassifikation at gøre (selv om en typebetegnelse eventuelt kan indgå som i det viste eksempel ' 738'). Desuden: identifikation er ikke et aspekt i den almindeligt definerede betydning, da identifikatorer ikke bør indeholde en betydning. Omkring identifikation bliver det hævdet, at der er behov for, at hver identifikator/navn er uændret hen igennem projektet men i praksis er der mange eksempler på, at det kun kan være tilfældet, når objektet ikke ændres strukturelt. En væsentlig del af detaljeringsarbejdet handler jo netop om, at objekter opdeles i flere objekter, hvorved der er behov for ændring af ID'er/navne. Tænk f.eks. på en facadevæg, der opdeles i sektioner enten fordi de tilgrænsende rum stiller forskellige krav eller fordi den skal indkøbes som præfabrikerede elementer. I dette tilfælde sker opdelingen måske endog først af leverandøren, altså relativt sent i processen. Noget tilsvarende vil kunne ske med forskellige installationsdele. Der er naturligvis behov for éntydig brugerdefineret identifikation af visse fysiske bygningsdele og indsætte værdier herfor i dataobjekter. At oprette sådanne identifikatorer/navne manuelt før det er nødvendigt og dermed være tvunget til at vedligeholde værdierne unødigt er imidlertid spild af ressourcer. Den til grund liggende påstand om stabil identifikation er dermed ikke påvist. Behovet kan løses meget enklere. Fysisk identifikation af en (fysisk) bygningsdel vil i fremtiden meget hensigtsmæssigt blive foretaget med RFID eller en tilsvarende teknisk løsning. En sådan ID vil da naturligt indgå som egenskabsværdi i det objekt, der repræsenterer bygningsdelen. Konklusionen må være, at emnet identifikation bør adskilles fra de øvrige emner og behandles helt separat mest fordelagtigt efter at de relevante klassifikationstabeller er udviklet. 3

4 T G Aspekt-begrebet Aspekt-begrebet bliver i rapporten stadig fremhævet som et hovedemne men det bliver desværre ikke behandlet på udtømmende måde. Emnet er ikke nyt, for der drejer sig ganske enkelt blot om en måde at kategorisere egenskaber på og teorien herom strækker sig helt tilbage til Aristoteles. Det er bemær kelsesværdigt, at der ikke fremføres en argumentation for, hvorfor netop de valgte egenskaber fremhæves og udråbes som aspekter, når der findes stribevis af andre kategorier af egenskaber, der også kan betragtes ud fra aspekttankegangen. Eksempelvis kan nævnes valg af brandklasse, energiklasse eller sikkerhedsklasse. Aspektbegrebet har mest karakter af at være en akademisk foreteelse, som ikke har nogen særlig praktisk betydning. Almindelig praksis er jo, at man bare påsætter egenskabsdata efter behov. Komposition og placering er også listet som aspekter og kan naturligvis foretages men kodning heraf er helt overflødig, hvis man tager udgangs punkt i bygnings mo deller, hvor det er muligt at trække data ud og strukturere på flere måder efter behov. Når bygningsdele vælges og bliver indsat i en konkrete model, oprettes der nemlig automatisk relationer dels mellem bygningsdelene indbyrdes og dels mellem rum og bygningsdele. Disse relationer er defineret i IFC og forventes brugt i modelleringssoftware. (Se figur som forenklet illustration af nogle af de relationer, der automatisk opbygges i bygningsmodeller og som kan anvendes til sådanne dataudtræk.) Ønsker man koder lagt ind i modeller, kunne det gøres ved f.eks. at definere nogle PropertySets i IFC. Kompo sition kan i øvrigt meget enkelt etableres på anden måde. Forslaget rummer tilsyneladende kun én kompositorisk struktur (jf. også referencesystemet i DBK) men det er vigtigt at understrege, at der sædvanligvis vil være behov for flere forskellige formålsbestemte kompositionsstrukturer, f.eks. også efter etager og rum. Anvendelse af standarder Ovenstående betragtninger er i høj grad også en kritik af de standarder, der refereres til. Disse standarder bliver altså tillagt uholdbar meget betydning. Standarder er ikke nødvendigvis opbygget på et korrekt videnskabeligt grundlag og skal under alle omstændigheder vurderes nøje i forhold til anvendelsesområdet. 4

5 T Klassifikation er ikke et aspekt Under gennemgangen af aspekt-begrebet figurerer også klassifikation og dette må siges at være meget problematisk, idet der teoretisk set er tale om et brud med traditioner. Helt principielt må der foretages et valg mellem to principper for informationsmodellering og det er der ikke redegjort klart for. Den ene mulighed er, at det traditionelle princip for modelleringssoftware anvendes (gælder også for IFC), hvor objekter skabes ud fra valg af objekttype, hvor alle mulige typer er defineret i et klassifikationssystem i form af biblioteker med objekttyper (taksonomi i flere niveauer). På denne måde fødes objekter med et varieret antal attributter afhængigt af typen og i tillæg vil der være en række metoder til rådighed, knyttet til attributterne. Dette princip indebærer, at klassifikation ikke kan karakteriseres som et aspekt på linje med de andre. En afgørende mulighed ved denne fremgangsmåde er, at henvisninger til nationale eller internationale klassifikationssystemer kan indbygges i objekttyperne på forhånd og dermed eliminere eller væsentligt reducere behovet for manuelt arbejde. Som led i detaljeringen kan der så ske en successiv specialisering, dvs. at eksisterende objekter udskiftes med mere specielle objekter, altså valg af undertyper. Vinduer og døre kan eksempelvis i første omgang vælges som generiske objekttyper uden nærmere specifikation og senere kan der foretages valg af en mere speciel type og det generiske objekt udskiftes da med et nyt objekt, eventuelt en model af et byggeprodukt. Ved den anden mulighed, som der tilsyneladende lægges op til her, skabes objekter ud fra ultimativt én objekttype eller ud fra meget få og meget generiske objekttyper med meget få attributter og metoder. Specialisering af undertyper håndteres derfor efterfølgende ved specifikation med successiv påsætning/opdatering af egenskaber. Som nævnt strider denne fremgangsmåde mod sædvanlig praksis, herunder IFC. Det vil således være en væsentlig mere primitiv tilgang, hvor struktur og semantik ved allerede udviklede informationsmodeller med klassifikation som IFC ikke kan bruges i forbindelse med softwareudvikling. En afgørende ulempe er også, at klassifikation dermed bliver en ren manuel opgave. Rapporten tyder desuden meget på, at der ikke skelnes skarpt mellem a) 'det at klassificere', altså 'at vælge en klasse' og b) 'det at opbygge et klassifikationssystem'. Det første forudsætter det andet. Så der er kun tale om 'at klassificere', hvis der vælges klasser fra et klassifikationssystem. Påsætning af andre koder er derfor ikke 'at klassificere'. 5

6 Formål med klassifikation Som anført i indledningen er der i det foreliggende rapportudkast ikke taget stilling til formål med klassifikationssystemer og hvilke principper, der skal ligge til grund for udvikling af tidssvarende klassifikationstabeller. Der er nemlig behov for at kikke på klassifikation på en helt anden måde set i relation til bygningsmodellering. En helt afgørende begrundelse er som nævnt, at et modelobjekt altid oprettes fra en defineret type/klasse (klassifikationssystem) tidligt i forløbet og fra det tidspunkt vil arbejdet med objektet være specificering dels i form af påsætning af flere attribut ter/egen ska ber og dels ved underopde ling i delobjekter. Det er derfor meget afgørende, at dette kan ske så automatisk/softwareunderstøttet som muligt. Når et modelobjekt er oprettet, bør dets derved fastlagte type anvendes til selektering af data i interne/eksterne databaser for nærmere specifikation af modelobjektet, f.eks. med omkostningsdata, tekniske løsninger, udførelsesanvisninger/aktivi teter, mon terings in strukser og vedligeholdelsesanvisninger. En klassifikationstabel over bygningsdelstyper giver altså grundlag for inddragelse af data udefra (branchedata) til projekterne. Dette betyder omvendt, at dette behov giver grundlag for videninstitutioner kan organisere (klassificere) og offentliggøre forskellige former for byggedata. Det er derfor også væsentligt at påpege, at der er brug for mange forskellige klassifikationstabeller til støtte for de forskellige trin i den samlede proces. I figur 3 er der vist en række eksempler på projektuafhængige data, der kan være nyttige til brug ved projekters specifikationsarbejde. Alle disse datamængder kan med fordel organiseres i klassifikationstabeller. Som det kan ses af diagrammet skelnes der vedrørende rum mellem aktiviteter og funktioner. Dette forhold er det vigtigt at få behandlet inden klassifikationstabeller kan udvikles. Vedrørende bygningsdele er der vist en adskillelse mellem funktioner, former, strukturer, tekniske kompositioner, produktmodeller og aktiviteter/recepter. Det er ligeledes vigtigt at få disse sondringer analyseret forud for udvikling af klassifikationstabeller. Dataobjekter til repræsentation af bygningsdele vil som oftest blive født ud fra deres former, hvilket netop er dækket af IFC og modelleringssoftware. Dermed er klassifikation på dette område i nogen grad overflødiggjort. Skulle man alligevel finde det hensigtsmæssigt at opbygge en national eller international klassifikationstabel over formtyper er det meget vigtig, at der kan ske en jævnførelse med objekttyperne i IFC. I modsat fald vil den ovenfor nævnte inddragelse af data ikke kunne ske effektivt og softwareunderstøttet. Generelt er det afgørende, at der er sammenhæng mellem klassifikationstabellerne indbyrdes. Eksempelvis vil det øge produktiviteten væsentligt, hvis man ud fra valgte former let kan blive vejledt til valg af strukturer (f.eks. vedrørende bærende dele) eller videre kan blive støttet til valg af tekniske kompositioner (f.eks. vinduer, trapper eller lagdele af vægge). Ligeledes vil det være ressourcebesparende, hvis man ud fra valgte tekniske kompositioner kan blive hjulpet til valg af produktmodeller eller aktiviteter og recepter som grundlag for estimering og udførelse. 6

7 Figur : 7

8 8 Figur : Project P Slab Storey S Building B Site X 4 3 Opening Opening Window Door Space V Window Opening 3 Pset Pset Building Model Representation in IFC Slab 3 4 Space V

9 Figur 3: Steps Pre Programming Programming Integral Design Detailed Design Construction Production Operations & Maintenance User Activities Project Independent Information Components / Parts Spaces Functions Functions Forms Properties Structures Technical Composites Product Models Processes / Receipes Properties Project Specication Functional Requirements Space Programs Space Layout / Architecture Composition Estimates Production Plans O & M Plans 9