RESPONS PÅ HØRINGSKOMMENTARER TIL CUNECOS KODESTRUKTUR-PROJEKT

Transkript

1 RESPONS PÅ HØRINGSKOMMENTARER TIL CUNECOS KODESTRUKTUR-PROJEKT cuneco har behandlet høringskommentarerne til cunecos oplæg til en CCS-kodestruktur for bygningsdele og rum, der blev fremlagt på en høringsworkshop den 15. marts Her kan du se alle høringskommentarer og cunecos svar på dem. cuneco en del af bips Dato 22. juni 2012 Projektnr Læsenøgle til kommentarskabelon Felt i kommentarskabelon Nr. Udfyldt af Evt. henvisning til slide eller dokument Paragraf / figur eller tabel i slide eller dokument Kommentar Foreslået ændring Respons og svarkategorier Kommentar fra cuneco Betydning cuneco står for fællesskab. Vi udvikler det fælles grundlag for digitaliseret samarbejde i byggeri, anlæg og drift. Målet er øget effektivitet og produktivitet gennem bedre udveksling af informationer. Høringskommentarens nummer, tildelt af cuneco Henvisning til kommentarstiller Henvisninger til slides, refererer til præsentationer af rapporten ved høring den 15. marts Henvisninger til dokument refererer til høringsrapport CCS kodningsregler af 5. marts Henvisning i relation til hhv. præsentationen eller høringsrapporten Kommentar fra kommentarstiller Foreslået ændring fra kommentarstiller Definition af svarkategorier: Svarene Accepteret, Delvist, Ikke og er anført ud fra anvendelse i tilretning af rapporten CCS kodningsregler. De i høringssvarene anførte foreslåede ændringer er opgaver eller kommentarer, der ligger uden for kodeprojektet, og hvor kommentaren er noteret til brug i processen eller til brug i øvrige arbejdsgrupper. Accepteret De i høringssvarene anførte foreslåede ændringer indarbejdes direkte i revisionen af rapporten. Delvist De i høringssvarene anførte foreslåede ændringer har givet anledning til indirekte eller delvise ændringer, der indarbejdes i revisionen af rapporten. Ikke De i høringssvarene anførte foreslåede ændringer indarbejdes ikke i revisionen af rapporten. Der er anført en begrundelse herfor. cunecos svar på kommentaren

2 Nr. Udfyldt af 1 Byggeskadefonden Slide eller dokument Paragraf / figur eller tabel i slide eller dokument Type af kommentar Kommentar Foreslået ændring Respons Kommentarer fra cuneco De systemer, som beskrives i rapporten, er efter Byggeskadefondens opfattelse den samme uheldige sammenblanding af metoder, som var en væsentlig svaghed ved DBK. Da kommentaren er identisk med kommentaren fra Landsbyggefonden (høringskommentar nr. 8), henvises til svar til denne. 2 Byggeskadefonden Rapporten vurderes derfor at være uegnet som grundlag for det videre arbejde, og det vurderes dermed også, at der på det foreliggende grundlag ikke er basis for at gå ind i en detaljeret vurdering og diskussion af elementer i rapporten. Der er i den danske byggesektor efter Byggeskadefondens opfattelse primært behov for en egentlig klassifikation af bygningsobjekter herunder af hovedklassen bygningsdele. Da kommentaren er identisk med kommentaren fra Landsbyggefonden (høringskommentar nr. 9), henvises til svar til denne. Det vurderes som positivt, at der tales om en egentlig klassifikation.

3 3 Byggeskadefonden 4 Byggeskadefonden 5 Byggeskadefonden 6 Byggeskadefonden 7 Byggeskadefonden Når klassifikationen udvikles / foreligger, vil der være behov for at beskrive hvilke egenskabsdata, der er relevante i de enkelte klasser. De i rapporten beskrevne aspekter er simpelthen egenskaber knyttet til objekterne på lige fod med øvrige egenskaber. Byggeskadefonden tager her forbehold for aspekttanke-gangen, og det må forudsættes at de beskrevne aspekter ikke influerer på den senere udredning af egenskaber. Der må her endvidere tages forbehold for at den skitserede kodning ikke bliver bestemmende for udviklingen af en kommende klassifikation. Det anbefales således, at processen omkring klassifikation starter helt forfra i et åbent og fordomsfrit udviklingsmiljø. I en sådan proces kan de nødvendige eksperter på området inddrages med skyldig hensyntagen til brugernes egentlige behov samt til, at klassifikationen skal være værdiskabende for branchen i bred forstand. Ikke Da kommentaren er identisk med kommentaren fra Landsbyggefonden (høringskommentar nr. 10), henvises til svar til denne. Da kommentaren er identisk med kommentaren fra Landsbyggefonden (høringskommentar nr. 11), henvises til svar til denne. Accepteret Da kommentaren er identisk med kommentaren fra Landsbyggefonden (høringskommentar nr. 12), henvises til svar til denne. Delvist Da kommentaren er identisk med kommentaren fra Landsbyggefonden (høringskommentar nr. 13), henvises til svar til denne. Da kommentaren er identisk med kommentaren fra Landsbyggefonden (høringskommentar nr. 14), henvises til svar til denne.

4 8 Landsbyggefonden 9 Landsbyggefonden De systemer, som beskrives i rapporten, er efter Byggeskadefondens opfattelse den samme uheldige sammenblanding af metoder, som var en væsentlig svaghed ved DBK. Rapporten vurderes derfor at være uegnet som grundlag for det videre arbejde, og det vurderes dermed også, at der på det foreliggende grundlag ikke er basis for at gå ind i en detaljeret vurdering og diskussion af elementer i rapporten. Der er i den danske byggesektor efter Byggeskadefondens opfattelse primært behov for en egentlig klassifikation af bygningsobjekter herunder af hovedklassen bygningsdele. Da CCS-forslaget netop imødekommer den tidligere rejste kritik og nu giver mulighed for både at kunne foretage en simpel klassifikation og en mere avanceret identifikation, er det svært at forstå kommentaren. Der savnes derfor en mere detaljeret problembeskrivelse af samme uheldige sammenblanding af metoder..: 10 Landsbyggefonden 11 Landsbyggefonden Det vurderes som positivt, at der tales om en egentlig klassifikation. Når klassifikationen udvikles / foreligger, vil der være behov for at beskrive hvilke egenskabsdata, der er relevante i de enkelte klasser. De i rapporten beskrevne aspekter er simpelthen egenskaber knyttet til objekterne på lige fod med øvrige egenskaber. Ikke Kommentaren overføres til egenskabsgruppen (der arbejder med disse emner). Aspekterne er forskellige måder at se samme objekt på, og herunder de egenskaber der er knyttet til objekterne.

5 12 Landsbyggefonden 13 Landsbyggefonden 14 Landsbyggefonden Byggeskadefonden tager her forbehold for aspekttanke-gangen, og det må forudsættes at de beskrevne aspekter ikke influerer på den senere udredning af egenskaber. Der må her endvidere tages forbehold for at den skitserede kodning ikke bliver bestemmende for udviklingen af en kommende klassifikation. Det anbefales således, at processen omkring klassifikation starter helt forfra i et åbent og fordomsfrit udviklingsmiljø. I en sådan proces kan de nødvendige eksperter på området inddrages med skyldig hensyntagen til brugernes egentlige behov samt til, at klassifikationen skal være værdiskabende for branchen i bred forstand. Accepteret Aspekterne har ikke indflydelse på egenskaberne der knyttes til et objekt. Delvist Kodningen dikterer ikke direkte indholdet af klassifikationen, men der er en del bindinger til kodeprincipperne som vil have indflydelse på inddelingskriterierne for klasserne på de øverste niveauer. Det er nødvendigt for at koden kan være konsistent og stabil gennem livscyklus for et objekt. Det foreliggende projekt har haft til formål at beskrive principperne for hvordan kodestrukturen skal være opbygget. Sideløbende har cuneco gennemført en behovsanalyse, der har haft til formål at beskrive hvor anvendelse af klassifikationen vil give værdi og dermed også, hvad der skal klassificeres. Da behovsanalysen har haft en bred deltagelse af repræsentanter fra branchen ser cuneco ikke noget behov for at starte forfra, da vi forudsætter at brugerne kender deres egne behov.

6 15 Kåre Nilsson Teknisk Er bokstavskodningen i CCS afstemt med ISO tabel der blandt andet anvendes i pibs C203 del 5 og 7? De foreslåede bogstavkoder i CCS og ditto fra ISO (og bips C203) er ikke i konflikt med hinanden. 16 Kåre Nilsson Teknisk I forbindelse med nummerering af IT netværk med tilhørende udstyr, anvendes i dag typisk kravene i TIA 606, se bilag hvor disse krav er anvendt til nummerering. Vil der blive taget højde for kravene i TIA 606 i CCS? Ikke Bogstavkoderne fra ISO er indarbejdet i ISO/IEC tabel 2 som underklasser til hovedklasse B. TIA 606 har ikke været taget i betragtning, og vil ikke være direkte foreneligt med den foreslåede CCS kodning. I praksis er det dog muligt at dobbeltkode et objekt med fx CCS og TIA 606 såfremt det er påkrævet. Ved hurtig gennemgang af det fremsendte bilag, ser det ud til at mange af informationerne fra TIA 606 vil være egenskaber i CCS. Der savnes en reference på den fremsendte danske version af TIA 606, da koder m.v. er justeret i forhold til den amerikanske udgave af do.

7 17 Kåre Nilsson 18 Kåre Nilsson krav Krav 16 Teknisk Teknisk I bygger CCS på blandt andet ISO/IEC Jeg håber I bruger denne standard, fordi I finder at den er den bedst egnede og ikke fordi I tror at der et direktiv eller en bekendtgørelse kræver, at det skal man. For modsat det I skriver under Krav 16, er der ingen direktiver eller bekendtgørelser der stiller sådanne krav. Der er en norm(en60204) der anbefaler at ISO/IEC kan anvendes, hvis man ikke kan finde på noget andet. Hvordan nummereres en rumføler der indeholder de 3 målinger: temperatur, CO 2 og fugt. Accepteret Teksten præciseres i rapporten. Den tilhører klasse BZ i ISO/IEC (kombinerede opgaver). Eventuelle underklasser til BZ kan introduceres i CCS såfremt det er nødvendigt (BZA, BZB, BZC etc.). Alternativt kan de tre målinger betragtes som egenskaber for objektet.

8 19 Kåre Nilsson 20 MBBL (Karsten Gullach) Teknisk I jeres rapport er det ikke helt klart hvilken begrundelse der for ikke at vælge at oversætte Uniclass / OmniClass til dansk, i stedet for at udvikle et nyt system. Der er muligt at Uniclass / OmniClass ikke er så avanceret som CCS, men når det kan anvendes I UK, USA og Canada så virker det lidt mærkeligt, at det ikke kan anvendes I Danmark. 4.2 Det anføres, at kodesyntaksen skal understøtte mapping mellem den nye struktur og DBK I forlængelse heraf forudsættes det, at kodesyntaksen ligeledes skal understøtte mapping mellem den nye kodestruktur og (No Suggestions), jf. den forståelse om mapping mellem DBK 2006 og FK, der blev opnået mellem bips og Landsbyggefonden i regi af den daværende Erhvervs- og Byggestyrelse i Delvist Begrundelse tydeliggøres i rapporten. Baggrunden for ikke at basere CCSklassifikationen på et af de nævnte klassifikationssystemer er, at klassifikationsinddelingen involverer en uhensigtsmæssig grad af detaljering i forhold til objekternes egenskaber. cuneco har fundet det mere relevant, at lave en mere robust klassifikation og i større grad basrere sig på specifikation af egenskabsdata for de enkelte objekter i forhold til specifikke formål. Mapping mellem CCS-klassifikationen og Forvaltningsklassifikation vil være et projekt, der helt naturligt vil komme i forlængelse af udviklingen af CCStabellerne. Hvem der kommer til at forestå dette arbejde er ikke fastlagt for indeværende men cuneco vil bidrage i relevant omfang. Derudover bevirker den systematik, der anvendes i disse klassifikationer, at omfanget af klassifikation bliver meget stort, da alle mulige kombinationer skal klassificeres. Dette vurderes ikke at være brugervenligt, og det ses som mere hensigtsmæssigt at håndtere dette via egenskaber/egenskabsdata.

9 21 Grontmi j, Christia n Hansen 22 Grontmi j, Christia n Hansen 23 Grontmi j, Christia n Hansen Teknisk Vedr. IEC : Placeringsaspekt (+), funktionsaspekt (=) og produktaspekt (-) har været anvendt i ca. 10 år på mange CTSanlæg, og det fungerer fint. Det har endda kunnet lade sig gøre at overtale en række bygherrer til at indarbejde dette i deres eksisterende ældre referencestruktur, da bygherren kan se en praktisk fordel. Teknisk Vedr. IEC : Denne del 2 er til gengæld håbløs brugerfjendsk, f.eks. hedder en frosttermostat, en brandtermostat, en kanaltemperaturføler, en rumtemperaturføler, m.v. alle sammen BT efterfulgt af et løbenr.. Det kan bygherren ikke bruge til noget, når han f.eks. får en SMS-alarm en nat med - BT03 (er det en frost- eller en brandalarm?) Teknisk Vedr. sammenbyggede komponenter: En kanalføler der måler både fugt og temperatur, hvilken referencebetegnelsen får den? Der er mange andre eksempler Vedr. IEC : Såfremt udvalgte dele af denne overhovedet skal bruges, skal produktbetegnelserne omarbejdes, så bygherren umiddelbart let og simpelt kan skelne mellem forskellige produkter f.eks. kanaltemperaturføler, indblæsning, kanaltemperaturføler, udsugning, m.v. (Alternativet er en massiv boykot fra bygherrerne) Der laves oversigter over f.eks.: 1 komponent med flere signaler Flere komponenter, der deler samme signal M.v. Delvist Kommentaren overføres til klassifikationsgruppen. Der arbejdes med en underklassifikation til gruppe BT (fx BTA, BTB, BTC etc.). Det bemærkes at enkelte informationer (fx indsugning / udsugning) måske overføres som egenskaber til objektet eller fremgår af den overliggende systemklassifikation. Den tilhører klasse BZ i ISO/IEC (kombinerede opgaver). Eventuelle underklasser til BZ kan introduceres i CCS såfremt det er nødvendigt (BZA, BZB, BZC etc.). Udarbejdelse af oversigter håndteres af klassifikationsgruppen. Kommentaren overføres til klassifikationsgruppen.

10 24 Grontmi j, Christia n Hansen 25 Grontmi j, Christia n Hansen 26 Grontmi j, Christia n Hansen 27 Grontmi j, Christia n Hansen Teknisk Vedr. IEC : Er der modstrid med DS/ISO 14617? Teknisk Teknisk Teknisk F.eks.: DS/ISO 14617: Temperaturmåling = T IEC : Temperaturmåling = BT Vedr.anlægstyper: En bygherre har brug for simpelt at kunne skelne mellem en lang række forskellige anlægstyper. F.eks. varmeanlæg: Her skelnes mellem varmevekslere, radiatorblandesløjfer, varmlufttæpper, varmeanlæg kørerampe, varmeanlæg kalorifere, m.v. Jeg er i tvivl om, der er en standardiseret detaljeret liste over anlægstyper i CCS s forslag Nummerering af etager er ofte et problem, da der anvendes mange forskellige måder f.eks. overkælder, underkælder, etage -1, etage 0, m.v. Nummerering af rum, kan ofte give problemer. Hvad sker der, når rum opdeles, sammenlægges, m.v.? DS/ISO er allerede indarbejdet i bips tegningsstandard C203 del 5 og 7 i Det er derfor vigtigt, at CCS ikke er modstrid med DS/ISO Der udføres en standardiseret detaljeret liste over anlægstyper. (50 eksempler fremsendes gerne) At der udarbejdes et entydigt standardsystem for nummerering af samtlige etager At der udarbejdes nogle vejledninger for god skik for rumnummerering samt, hvordan ændringer bør udføres De foreslåede bogstavkoder i CCS og ditto fra ISO (og bips C203) er ikke i konflikt med hinanden. Bogstavkoderne fra ISO er indarbejdet i ISO/IEC tabel 2 som underklasser til hovedklasse B. Accepteret Klassifikationsgruppen arbejder med emnet, og en evt. oversigt modtages gerne. Accepteret Det anføres i rapporten, at CCS følger ISO 4157 standardserien på dette område. Accepteret Kommentaren overføres til den gruppe der skal arbejde med vejledninger / eksempelmateriale.

11 28 Grontmi j, Christia n Hansen 29 Grontmi j, Christia n Hansen 30 Grontmi j, Christia n Hansen Teknisk Teknisk Vedr.anlægsopdeling: I DBK er der massive klager over, at et ventilationsaggregats blandesløjfer ikke har samme anlægsnr. som selve ventilationsaggregatet. Eksempel: Der står 4 ventilationsaggregater på taget og 12 tilhørende varme- og køleblandesløjfer på etagen nedenunder. Når brugeren står ved de 12 blandesløjfer, kan han ikke se, hvilke blandesløjfer, der hører til hvilket ventilationsaggregat Vedr. eltavler: Det er meget ofte et brugerkrav at et nr. på en eltavle indeholder oplysninger om de forsynende tavler og transformere. Eksempel: T1 T1-HT2 T1-HT2-ET4 T1-HT2-ET4-GT13 Vedr. kommunikation og forståelse: Uanset hvilke referencebetegnelser CCS ender med, er der en meget omfattende opgave med at forklare dem. Via nogle praktiske eksempeltegninger vises, at blandesløjfer til ventilationsaggregater har samme anlægsnr. som selve ventilationsaggregatet Dette brugerkrav muliggøres og vises via praktiske eksempler Der tilføjes rigeligt med praktiske eksempler og tegninger Accepteret Kommentaren overføres til den gruppe der skal arbejde med vejledninger / eksempelmateriale. Delvist El-tavlers indbyrdes sammenhæng er en del af CCS kodeprincippet, men kan udtrykkes ved supplerende mærkning. Det viste eksempel overholder ikke delaf reglen for inddeling af systemer. Kommentaren overføres til den gruppe der skal arbejde med vejledninger / eksempelmateriale. Accepteret Kommentaren overføres til den gruppe der skal arbejde med vejledninger / eksempelmateriale.

12 31 Grontmi j, Christia n Hansen 32 Grontmi j, Christia n Hansen 33 Ulla Michael, DANSKE ARK Der findes mange bygherrer med m2 eksisterende bygninger med eksisterende referencebetegnelser. Der mangler nogle forklaringer på, hvad der skal ske ved ændringer, udvidelser, nygbygninger, m.v. Der findes en længere række eksisterende bygherre-/rådgiver- /entreprenør-lister med anvendte referencebetegnelser. Det er oftest lister der er opstået via praktiske behov. Hvis CCS skal erstatte disse, skal CCS være temmelig dækkende DANSKE ARK ser det som meget positivt at der lægges op til en adskillelse af klassifikation og referencestruktur. Dette vil være en væsentlig forenkling af rådgivernes arbejde med at håndtere CCS i den daglige projektering. Der tilføjes rigeligt med praktiske eksempler Der indsamles f.eks eksisterende bygherre-/rådgiver-/entreprenør-lister med anvendte referencebetegnelser, og det kontrolleres, at CCS rent faktisk kan erstatte disse i praksis Accepteret Kommentaren overføres til den gruppe der skal arbejde med vejledninger / eksempelmateriale. Delvist CCS Strukturelt Produktaspekt skal opbygges og struktureres af personer med faglig kompetence. Eksisterende referencebetegnelser mappes derefter til denne struktur. Da hele brugbarheden og funktionaliteten af CCS står og falder med de grundlag, der indarbejdes i rådgivernes projektering, er det set fra DANSKE ARKs side meget væsentligt at det i den fortsatte udvikling er stort fokus på at klassifikationen er enkel, forståeligt og brugbar. Dette mener vi fortsat skal prioriteres meget højt.

13 34 Digital Konverg ens v/ Jørgen Storm Emborg 35 Digital Konverg ens v/ Jørgen Storm Emborg 36 Digital Konverg ens v/ Jørgen Storm Emborg Vi kan både i det udsendte skriftlige materiale og specielt på workshoppen se at der er lyttet til de kommentarer, der i tidens løb er givet til DBK og CCS imødekommer mange af disse. Vi glæder os til at kunne kommentere på detaljerne i systemet - på de konkrete tabelværdier. Det er relativt komplekst for byggefolk at kommentere alene på strukturen. Processen omkring høring af strukturen har ikke været optimal - det har ikke været muligt at gennemføre en grundig høringsproces med den begrænsede høringsperiode. Offentliggør tabellerne under vejs og involver den brede branche i udarbejdelsen (workshops og lignende). Længere høringsfrister generelt for fremtidige arbejder. cunecos udviklingsmodel består i, at projekter gennemføres af en række nøglepersoner, der kan inddrage eksterne personer til review i relevant omfang undervejs i udviklingsprocessen. Udviklingen følges løbende af cunecos styregruppe, der repræsenterer de forskellige dele af branchen og styregruppens medlemmer har ligeledes mulighed for at inddrage deres bagland undervejs. Endelig er alle projekter genstand for offentlige høringer, når der foreligger et resultat, der har en kvalitet, som det er rimeligt at lægge frem. Dette er noteret. I forbindelse med fremtidige projekter, vil vi sikre os, at høringsperioden er længere.

14 37 Digital Konverg ens v/ Jørgen Storm Emborg 38 Digital Konverg ens v/ Jørgen Storm Emborg 39 Digital Konverg ens v/ Jørgen Storm Emborg 40 Digital Konverg ens v/ Jørgen Storm Emborg 41 Digital Konverg ens v/ Jørgen Storm Emborg Teknisk Teknisk Teknisk Teknisk Teknisk Kan "løbenumre" være informationsbærende - kan en bygherre definere en bestemt syntaks for løbenumre, som vil komplicere anvendelsen unødigt? Kan "løbenumre" være informationsbærende - kan en bygherre definere en bestemt syntaks for løbenumre, som vil komplicere anvendelsen unødigt? Valgfriheden i strukturen omkring nummerering og lignende stiller store krav til projektspecifikke aftaler omkring "understandardiseringer" for at muliggøre anvendelse af data på tværs af parter. Der er usikkerhed omkring hvilke dele af systemet der skal anvendes og hvilke der kan anvendes. Skal den simple klassifikation være til stede, eller kan en part beslutte udelukkende at anvende et af de andre aspekter? Vi er nervøse omkring grænsen mellem klassifikation og egenskaber og om den placeres for højt, så problemer udskydes til diskussion i forbindelse med egenskaber. Vi ønsker en specifikation af at løbenumre, underklassifikation etc. ikke kan være informationsbærende, men udelukkende er projektspecifikke løbenumre. Indarbejd forslag til at etablere mapning mellem projektspecifikke løbenumre og informationsbærende systemer hos bygherrer. Der ønskes vejledninger i hvordan dette håndteres. Det skal klart beskrives hvilke dele af systemet der er obligatorisk skal være til stede - vores opfattelse er at den simple klassifikation skal anvendes i alle tilfælde. Grænsen mellem klassifikation og egenskaber skal overvejes og defineres nøje og beskrives detaljeret - dette skal ske snarest muligt og inden arbejdet med tabeller kommer for langt. Accepteret Det forstås således, at løbenumre anvendes som del af identifikation af objektet. Delvist Princippet er, men det kan være vanskeligt at dække 100%. Kommentaren overføres til den gruppe der skal arbejde med vejledninger / eksempelmateriale. Accepteret Princippet er, men det kan være vanskeligt at dække 100%. Delvist Kommentaren overføres til den gruppe der skal arbejde med vejledninger / eksempelmateriale. Der stilles ikke krav om anvendelse af den simple klassifikation i alle tilfælde. Hvad der obligatorisk eller valgfrit beskrives i rapporten. Kommentaren overføres til grupperne for klassifikation hhv. egenskabsdata. Det er et centralt krav, at klassifikationen er stabil for et objekt set i den samlede livscyklus.

15 42 Digital Konverg ens v/ Jørgen Storm Emborg 43 Digital Konverg ens v/ Jørgen Storm Emborg Teknisk Der har været arbejdet med it egnethed i processen, men fokus har i for høj grad været på professionelle udviklere - der er i byggebranchen en lang række af egenudviklede "Excel-systemer" og lignende som kan have svært ved at håndtere kodestrukturen (ikke positionsfast). It egnetheden er ikke håndteret konsekvent gennem et teoretisk fundament, men er håndteret gennem involvering af udvalgte SW udviklere - f.eks. ingen it teoretikere og praktikere. Eksempler på konkrete problemer savnes. Inddragelse af andre kompetencer. Sikringen af IT-egnetheden er tilstræbt sikret ad flere veje. Dels - som det rigtigt påpeges - gennem involvering af en repræsentant fra en IT-leverandør i selve udviklingen og dels igennem en høring i bips' IT-forum undervejs i udviklingsforløbet. Derudover er selve den offentlige høring, som høringsworkshoppen er en del af, men som også omfatter en løbende dialog med de IT-leverandører, der vil deltage i cunecos afprøvningsprojekter, også et væsentlig element i sikringen af ITegnetheden.

16 44 Digital Konverg ens v/ Jørgen Storm Emborg Hvilke tiltag er der gjort for at gennemføre høringen mod et internationalt høringspanel? Høringsdokument oversættes til engelsk og en international høring gennemføres. Undervejs i udviklingsforløbet har der været ført en dialog med flere internationale kompetencer som fx Håvard Bell (Norge), Eirik Selvik (Norge) og Anders Ekholm (Sverige). Derudover holder bips - inkl. repræsentanter fra CCS kodestrukturgruppen - løbende møder med klassifikationsrepræsentanter fra de øvrige nordiske lande. bips og cuneco deltager i arbejdet omkring revision af klassifikationsstandarden ISO og koordinerer i den forbindelse løbende udviklingen med en række internationale aktører. cuneco har indgået aftale med Anders Ekholm (Lunds Universitetet) om et tværgående review af cunecos projekter, med henblik på at sikre indbyrdes koordinering og sammenhæng til international udvikling.

17 45 Digital Konverg ens v/ Jørgen Storm Emborg 46 Digital Konverg ens v/ Jørgen Storm Emborg 47 Digital Konverg ens v/ Jørgen Storm Emborg Teknisk Teknisk Vi mangler en konsekvent beskrivelse af hvordan systemet forholder sig til de mest udbredte nationale klassifikationsstandarder - herunder overvejelser omkring en mere direkte kobling mellem CCS og disse. Dette er specielt relevant i forbindelse med det fremadrettede arbejde med de konkrete tabeller, hvor kompetencer med direkte relation til de nationale standarder bør involveres. Der mangler en gennemgang af hvordan CCS forholder sig til det hidtil anvendte klassifikationssystem i Danmark - SfB systemet. Et objekt kan have to forskellige numre i to forskellige aspekter - døren er nummer 3, men dør nummer 7 i vægsystem 1. Dette giver forvirring i praksis og giver risiko for misforståelser i praksis. Involver ressourcer fra OmniClass og Uniclass direkte i arbejdet med udarbejdelse af tabeller. Praktisk mapning udarbejdes på linje med mapningen til DBK Problemstillingen skal beskrives og operationaliseres. Det væsentligste bidrag til at sikre koblingen til de øvrige nationale klassifikationssystemer vil bestå i, at klassifikationsstandarden ISO opdateres, således at denne vil afspejle principperne i CCS uden at dette dog vil påvirke opbygningen og indholdet af de øvrige nationale systemer. Accepteret Kommentaren overføres til den gruppe der skal arbejde med vejledninger / eksempelmateriale. Delvist Det er et unødigt stærlt krav at kræve at nummereringen samordnes på tværs af aspekterne. Aspekterne mulliggør håndtering af objekterne fra forskellige synsvinkler, hvorfor objekterne ikke vil have de samme kompositoriske relationer. Dette detaljeres yderligere i rapporten.

18 48 Digital Konverg ens v/ Jørgen Storm Emborg 49 DTU, Risø, Allan Murphy Teknisk Det er et problem for branchen at der er to helt separate klassifikationssystemer til hhv. byggeperioden og driftperioden (Forvaltnings Klassifikation) Dette er en fælles kommentar fra DTU, Lyngby og DTU Risø (Campus service = driftsafdelinger): Det er et for abstrakt grundlag for DTU til at kunne vurdere konsekvenserne De to systemer bør behandles til et samlet system. Fornyet høring med langt mere vægt på eksempler og praktiske konsekvenser cuneco vil bidrage til, at der udarbejdes et system til mapning mellem CCS og FK, således at man vil overgangen til drift vil have mulighed for at få genereret FK-koder for objekterne ud fra den CCS-klassifikation og egenskabsdata, der er påført objekterne i projekterings- og udførelsesperioden. Ønsket om at høringsmaterialet i højere grad skal bestå af praktiske eksempler er noteret, og vil blive taget i betragtning i forhold til kommende projekter. M.h.t. ønsket om en ny høring vil vi afvise dette med den begrundelse af høringen har genereret så mange konstruktive og relevante kommentarer, at vi vil mene at den har opfyldt sit formål.

19 50 Henrik Schleder mann Teknisk Når man laver et så omfattende klassifikations og identifikationssystem så synes jeg det er problematisk at man ikke forholder sig til en ensartet måde at identificerer komponent placering i forhold til bygningsgeometrien. Rumnumre er ikke entydige. Rum opsplittes, nedlægges og nye rum etableres. Rumnumre ændres løbende af brugere. For de tekniske installationer er der i relation til drift og overvågningssystemer et stort behov for kunne angive entydig placering af komponenter som ikke ændres i løbet af bygningens levetid. Det er også et meget vigtigt aspekt i hele driftforløbet. At der udarbejdes et entydigt system for hvordan placering af komponent / anlæg identificeres og som skal anvendes på alle nye bygninger. Dette kunne være via: - GPS koordinater. - Ved anvendes af et hensigtsmæssigt og standardiseret bygningsgrid hvor der er regler for hvordan dette anvendes og hvordan akser nummereres. - Ved at lave en standardiseret måde at tildele rumnumre afhængigt af et bygningsgrid. Delvist De foreslåede CCS aspekter for rum (funktionsaspektet og strukturelt produktaspekt) anvendes til identifikation af rum, og er (samlet set) stabile set over livscyklus for et rum, men omfatter ikke fx når to rum sammenlægges, og det ene dermed nedlægges/udgår. De foreslåede ændringer (fx GPSkoordinater) kan tilføjes som egenskaber for de pågældende rum. De ønskede ( historiske ) informationer, fx om tidligere rumnummer kan evt. bevares som en del af egenskabsdata knyttet til et objekt og ses som en særskilt aktivitet der omhandler vedligehold af informationer. Hvis rumnumre ændres hvad de ofte gør af brugere eller arkitekter er det meget kostbart at oprette den bagved liggende dokumentation. Der indarbejdes en beskrivelse i rapporten, der viser hvorledes CCS koderne kan anvendes til dette formål, fx at et tidligere rum efter en renovering skal findes som en del af et nyt rum. Kommentaren overføres til egenskabsdatagruppen

20 51 Flemmin g Grangaa rd, Dansk Byggeri 52 Flemmin g Grangaa rd, Dansk Byggeri Det er en rigtig god ide, at optage hele præsentationen, og efterfølgende give muligeh for, at se de fire film. Rigtig stor ros! Der er tilgengæld ikke ros for høringsfristen. Det er et svært emne, som bliver beskrevet meget abstakt og komplekst. Det kræver tid, at sætte sig ind i stoffet. Fremlæggelserne den 15. marts var til gengæld mere spiselige. Vi har noteret os, at høringsfristen har været for kort, hvilket vi vil tage i betragtning i forbindelse med fremtidige projekter. M.h.t. det tekniske indhold af rapporten mener vi ikke at det kan undgås, at man kommer op på et vist teknisk niveau i beskrivelsen af systemet. Til gengæld har vi prioriteret at følge dette til dørs af en præsentation, der er mere pædagogisk og umiddelbart forståelig.

21 53 Flemmin g Grangaa rd, Dansk Byggeri 54 Flemmin g Grangaa rd, Dansk Byggeri 1. Resume side 3 I princippet giver det ikke mening, at man kun skal kommentere kodestruktur, uden at kende omfanget og indhold af tabeller, klasser, domæner, fag, ressourcer mv. Det er nærmest en form for en accept på et ufuldstændigt grundlag, som senere kan give bagslag, når man er kommet i dybden med indholdet af tabellerne. Fordi man kan frygte, at der på nuværende tidspunkt er taget beslutninger, som det ikke er muligt, at gennemskue. Desværre har det mest karakter af, at rapporten skulle ud nu. Det vil kræve flere høringer, dette kan ikke være den endelige høring. Arbejdet bør koordineres med de øvrige projekter som har indflydelse i en eller anden udstrækning. Her vises eksempler fra cunecos egen projektliste: Afklaring af klassifikationsniveau Afklaring af struktur og metode for egenskabsdata Klassifikation af bebyggelser, bygninger og rum Begrebsmodel for ressourcedomæne Metode-struktur for egenskabsdata Egenskabsdata for ressourcer, processer, produktions-planlægning, driftsregistrering, beregninger, rumprogrammer, opsamling af driftsdata, Krav til informationer for drift Tabeller for bygningsdele, tabeller for drift Sammenhæng mellem egenskabsdata og IFD Sammenhæng mellem bygningsmodel og bygningsbeskrivelse Det virker stadig unødigt komplekst. Udover forenkling bør der arbejdes med formidlingen af stoffet, med mere sigende og oplysende eksempler. Delvist Alle de nævnte projekter koordineres løbende med hinanden ligesom de hver især vil være genstand for selvstændige høringer. Der vil således blive tale om mange høringer undervejs i cunecos projektperiode. Kommentaren overføres til den gruppe der skal arbejde med vejledninger / eksempelmateriale.

22 55 Flemmin g Grangaa rd, Dansk Byggeri 56 Flemmin g Grangaa rd, Dansk Byggeri Indlæg 2, slide 6 Ved vurderingen af DBK tilbage i oktober 2010, blev der fra mange sider efterlyst en værdianalyse. Den har branchen stadig tilgode. Dicon-rapporten fra 2008 peger flere steder på belysning af værdien. De afholdte behovsanalyser kan ikke gøre det ud for en gennemarbejdet og afsluttet værdianalyse fordi de netop ikke har beskæftiget sig ed klassifiaktion, som oplyst af Torben Klitgaard på høringen om brugerseminarere. Der blev i præsentationen nævnt, at man skulle have kigget på Holland i stedet for de andre lande, hvor man tidligere har kigget i deres systemer. Der er muligt; men vi mangler dokumentationen herfor. Derfor ved vi ikke, om det ville være bedre at fordanske et af de andre systemer. Ikke Det er cunecos holdning, at man ikke kan tale om værdien af klassifikation i sig selv. da klassifikation først giver værdi, når det bliver anvendt i forbindelse med konkrete processer. Fokus for indeværende projekt har været at definere en kodestruktur, der gør det muligt at referere til et specifikt objekt samt at sige noget om, hvilken klasse objektet tilhører. Når dette formål er opfyldt mener vi, at det er muligt at anvende objektet i forhold til de processer, der skaber værdien. Analyserne af værdiskabelsen i disse processer foretages i forbindelse med afprøvningsprojekterne med opstart i efteråret Kommentaren på fremlæggelsen havde til formål at tydeliggøre, at der er andre lande der arbejder efter de samme principper som CCS nu lægger op til. Det er ikke en del af opgavebeskrivelsen, at et dansk klassifikationssystem skal være en fordanskning af andre landes systemer.

23 57 Flemmin g Grangaa rd, Dansk Byggeri 58 Flemmin g Grangaa rd, Dansk Byggeri Inden lancering af den nye CCS. Det skal sikres, at man ikke får de samme vanskeligheder med CCS, som man har haft med DBK. Derfor bør test og afprøvning foregå på et mere kvalificeret grundlag end det skete med DBK. t om syntaksen Det vil være en fordel, at betragte de forskellige oplysninger som enkeltstående oplysninger i hvert sit felt. Det forhindrer ikke en samlet visning af hele strengen. Det er ganske almindelig databaseteknik. Det vil ydermere give store fordele ved sortering og anvendelse i andre programmer f. eks. Excel. Dermed vil aspekt præfix ikke ødelægge sorteringen. Delvist Dette er helt i overensstemmelse med cunecos holdninger og arbejdsmetoder. cuneco har allerede på nuværende tidspunkt indgået aftaler med en lang række IT-leverandører, der vil implementere CCS og der arbejdes i øjeblikket på at de tabeller, der bliver udviklet, vil blive stillet til rådighed for IT-leverandørerne via webservices. Det præciceres i rapporten, at de enkelte aspekter er seperate egenskaber for et objekt, der evt. kan samles til én kodestreng (adskilt med / ) såfremt det er påkrævet. De enkelte aspekters præfiks muliggør dette, da koden for hvert aspekt er helt entydig, og ikke kan forveksles med andre koder for andre aspekter pga. deres forskellige præfiks. Kommentaren overføres til gruppen der arbejder med egenskabsdata, således at koden for de enkelte aspekter evt. kan udveksles som flere enkelte egenskaber.

24 59 Flemmin g Grangaa rd, Dansk Byggeri Når kompleksiteten og omfanget af kommentarer tages i betragtning, bør der i værksættes en ny høring, når alle problemstillinger er indarbejdet. Opfølgeren til kodestrukturprojektet er et projekt vedr. afklaring af klassifikationsniveau. Formålet med dette projekt er at udarbejde retningslinjer for klassifikation af bygningsdele samt grænsefladen til egenskabsdata. Indholdet af dette projekt vil inddrage de ting, der er kommet frem i den indeværende høringsproces og projektet vil være genstand for en særskilt høring.

25 60 Flemmin g Grangaa rd, Dansk Byggeri 1. Resume side 3 Afsnit 4 Der er taget udgangspunkt i ISO og ISO/IEC standarderne. Men hele systematikken der er beskrevet hælder sig hovedsagligt op af sidstnævnte, som er en elektrisk og mekanisk standard, hvilket giver en uheldig udformning af det vi har brug for i byggeriet. Det er helt uforståeligt, at man ikke har vist den samme interesse for ISO og IFC, som man har for IEC Disse standarder har dog en langt større udbredelse bredt blandt byggefolk end 81346, som kun benyttes af en mindre del af el- og mekanikfolket. Det foreslås, at der udarbejdes eksempler og scenarier der analyserer og demonstrerer hvordan de identificerede brugerbehov kunne løses gennem anvendelse af elementer fra og IFC evt. i kombination med Ikke ISO er en rammestandard, der i sin udformning danner en fælles platform for definition af byggeriet. ISO er ikke i modstrid med ISO/IEC (og omvendt). ISO er derfor helt central for CCS. IFC er et udvekslingsformat og ikke et kodesystem. IFC kan indeholde CCS koderne, hvorved CCS koder kan overføres mellem forskellige IT systemer. Det er valgt at anvende principperne fra ISO/IEC 81346, da denne standard stiller nogle værktøjer til rådighed, der er nyttige i forbindelse med cunecos ønsker om at kunne identificere objekter entidgt ud fra forskellige aspekter. Der savnes eksempler på, hvad der menes med uheldig udforming af det vi har brug for i byggeriet.

26 61 Flemmin g Grangaa rd, Dansk Byggeri 3. introduktion side 7 Afsnit 2 og 3 Her er beskrevet at det er en revideret version af DBK. Skemaet på side 70 med aspektkoder viser tydeligt, at bygningsdelene er klassificeret anderledes i det nye CCS. Visningen af de 4 øvrige aspekter og forslag til indhold, viser desværre tydeligt, at tankesættet bagved er det samme som DBK, og dermed kan man have en begrundet frygt for den megen fokus på referencesystemet, som umiddelbart ser ud til unødigt at komplicere koderne og vanskeliggøre anvendelsen for mange af byggeriets brugere. Her henvises til ovenstående punkt om beslægtede projekter i Cuneco. Ikke Med CCS er det nu muligt kun at klassificere bygningsdele og rum (med % hhv. %%)., og derfor er der tale om en anderledes tilgang end DBK, hvord dette ikke var muligt. Referencesystemet fra DBK er revideret, og indgår fortsat i CCS, da dette tankesæt er centralt i bestemte sammenhænge. Der er i CCS ikke krav om anvendelse af refrencesystemer. Vi vil undersøge fordele og ulemper ved at gøre fx den simple klassifikation obligatorisk for at skabe et fælls grundlag for den simple anvendelse, som efterlyses. Se endvidere svar på høringskommentar 60.

27 62 Flemmin g Grangaa rd, Dansk Byggeri 63 Flemmin g Grangaa rd, Dansk Byggeri 64 Flemmin g Grangaa rd, Dansk Byggeri 3. introduktion side 7 3. introduktion side 8 3. introduktion side 8 Afsnit 6 Rapporten præsenterer forslag til klassifikationstemaer, men indeholder ikke det specifikke tabelarbejde, herunder de klassifikationstabeller der skal udarbejdes, på baggrund af denne rapport. Dette er særdeles uhensigtsmæssigt, når man tænker på, at opmålingsreglerne fra 2008, stort set ikke er blevet anvendt, pga. af den kobling man lavede til DBK, som begrænsede muligheden for entydighed, som et af mange væsetligste ankepunkter. Afsnit 2 I grundlag for rapporten omtales Ekholm-rapporten Afsnit 3 Redaktio nel Det er svært at se hvor præcis denne rapport har inspireret i revideringsarbejdet. I rapporten: Behovsanalyse hvad er byggebranchens behov for standarder for udveksling af digital information? (Foreløbige hovedkonklusioner) Kommenteres under 16 Bilag D side 72 Her henvises til ovenstående punkt om beslægtede projekter i Cuneco. Lad Anders Ekholm og Lars Häggström gennemgå rapporten sammen med resultaterne af denne høring. De uhensigtsmæssigheder, der er blevet afdækket i forhold til DBK2006, har cuneco valgt at håndtere gennem opstilling af succeskriterier for sine udviklingsprojekter. Den beskrevne vanskelige kobling til DBK i forhold til Opmålingsreglerne bundede ifølge cunecos opfattelse i at man ikke kunne klassificere uafhængigt af referencestrukturen eller referere til projektspecifikke typer. Begge disse forhold har været med i kodestrukturprojektets succeskriterier og cuneco anser at projektet har opfyldt disse kriterier med den nye kodestruktur som CCS repræsenterer. cuneco har bedt Anders Ekholm lave review på høringsmaterialet, og han vil således selv kunne give udtryk for om hans kommentarer til DBK er tilgodeset i CCS kodestrukturen. Accepteret Der indsættes en reference fra afsnit 3 til bilag D i rapporten.

28 65 Flemmin g Grangaa rd, Dansk Byggeri 3. introduktion side 8 Afsnit Redaktio nel Rapporten: Indsamling af basisinput til projektarbejdet med deltagelse af udvalgte eksperter med afsæt i de vedtagne forudsætninger for opgaven. Det vil klæde rapporten, at oplyse om disse. Delvist Der indsættes en reference til forudsætningen for projektarbejdet (indsættes som bilag).

29 66 Flemmin g Grangaa rd, Dansk Byggeri Afsnit Side Det vil ikke give mening, at kommentere på et detaljeret niveau, som f.eks.: Er bygningsdele dækkende? Om alle bygningsdele kan beskrives med 2 eller 3 bogstaver? Om der er underklasser mv.? Hvordan skal de relevante egenskaber klassificeres? Hvordan behandles øvrige egenskaber, som er relevante f. eks. for opmåling og produktion mv., hvilken form for struktur? Vi mener grundlæggende, som beskrevet ovenfor, at der skal tages hensyn til de øvrige cuneco-projekter, som har indflydelse struktur, terminologi, opbygning mv. Når dette ikke er belyst, er det foreslåede blevet unødigt komplekst, fordi alle nuancer ikke er tænkt ind. Så fremt alt skulle være løst, ville det det formentlig tage 3 5 år, at lave den samlede klassifiaktion; men det vi har set i dette oplæg, er til gengæld for lille del af isbjerget. Der er alt for mange afhængigheder som vil afstedkomme revisioner, og på den måde kræve nye høringer. Udover denne kommentar, efterlyses flere gennemarbejde praktiske eksempler, det vil give en bedre mulighed for, at gennemskue kompleksitete, og se konsekvenserne i sin helhed. Kompleksiteten er i forvejen unødig høj. Det er cunecos holdning, at man med det foreliggende resultat har lagt sigt fast på nogle principper, som der ikke skal laves om på i forbindelse med de forhold, der er nævnt i kommentaren. Det er korrekt, at der er tale om en række faktorer, der ikke for indeværende er afdækket, hvilket vil ske i forbindelse med cunecos kommende projekter. cuneco mener at man med det foreliggende resultat fra kodestruktur projektet, vil kunne håndtere den relevante datamængde uden at koderne bliver unødigt lange og komplicerede.

30 67 Flemmin g Grangaa rd, Dansk Byggeri 68 Flemmin g Grangaa rd, Dansk Byggeri Afsnit 4.2 Afsnit 12 side 66 Afsnit 1 pkt. 6 Kodesyntaksen skal understøtte mapning mellem den nye struktur og DBK2006, blev der nævnt under debatten på mødet den 15. marts, at man ville kunne dette en til en. Det er nok love for meget, det er tale om en enklere struktur i det nye CCS. Hvis det endeligt er tilfældet, kan man konkludere, at adskillelsen og nytænkningen ikke har været omfattende nok i revisonen af DBK. I øvrigt bør man prioritere denne indsats med mapning, og koncentrere sig om det fremadrettede, under respekt af de få som har anvendt DBK2006 med udbytte. Herudover er mapning til SfB og Forvaltningsklassifikationen formentlig mere påkrævet. 1. Afsnit I rapporten står: CCS er designet til at være et fælles kodesystem, som er fælles for alle domæner: Der kan derfor udarbejdes en fælles formidling og eksempelsamling. Endvidere er der lagt vægt på at de forskellige domæner vil kunne arbejde bedre sammen og reducere antallet af fejl og misforståelser mellem parterne, idet koderne er ensartet og entydigt opbygget for alle domæner. Det er stadig uhensigstmæssigt med både CCS og forvaltningsklassifikationen. De burde smelte sammen. Her mangler praktisk eksempler som belyser dette, da de nævnte domæner ikke er omtalt i rapporten Delvist Det er korrekt at man ikke vil kunne lave 100% en-til-en mapning mellem DBK2006 og CCS. Dette skyldes dels at CCS ikke klassificerer varianter af typer og dels at CCS eliminerer muligheden for at klassificere objekter med forskellige klasser, som det er tilfældet med DBK2006. cuneco er enige i, at det er uhensigtsmæssigt for branchen med to klassifikationssystemer, hvilket adresseres ad 2 veje. Den ene er, at CCS vil definere de klassifikationskoder og egenskabsdata, der er nødvendige for at matche funktionaliteten i FK, og den anden er at cuneco vil bidrage til at udvikle en mapning mellem CCS og FK. Det præciseres i rapporten hvad der forstås ved "domæner" (der tænkes på faglige domæner).

31 69 Flemmin g Grangaa rd, Dansk Byggeri 70 Flemmin g Grangaa rd, Dansk Byggeri Side 66 På samme side nævnes at softwareleverandørerne har været konsulteret og CCS kan understøttes af IT-værktøjerne. Afsnit 15 Side Det vil klæde rapporten at omtale hvilke leverndører og værktøjer der er tale om. Bilag C Fin visualisering. Accepteret Omtale af leverandørene og værktøjerne vil indgå i rapporten.

32 71 Flemmi ng Grangaa rd, Dansk Byggeri Afsnit 16 Side 72 Bilag D Der er flere citater fra behovsanalysen, som lige så godt kunne have været valgt som repræsentative om behov for bruger-venlighed og enkelhed osv. F. eks.: Der er ikke sammenhæng mellem klassificeringen/bygningsmodellen og bygningsdelsbeskrivelserne. Anvendelsesbehovet for klassifikation skal afklares gennem konkrete eksempler for forskellige fagområder. Det svenske klassifikationssystem, hvor der er kobling til beskrivelsesværktøjet fungerer godt. Hvorfor ikke benytte os af de navne, som vi giver dem alligevel? DBK er ikke velegnet i udførelsesfasen. cuneco skal starte med kernen, dvs. beskrive et system, som branchen over tid kan forbedre. Klassifikation og niveauer de forskellige aktører har forskellige detaljeringsbehov. DBK-kodningen er tung og hænger ikke sammen med mængdeudbud. Deltagerne på disse workskops og bølger har ikke prioriteret DBk højest. Det skal man ikke lade sig mærke af, der er ikke tvivl om at bygningsdelsklassifikationen er vigtig for flere ting end man umiddelbart er klar over eksempelvis opmåling og produktion.

33 72 Flemmin g Grangaa rd, Dansk Byggeri 73 Flemmin g Grangaa rd, Dansk Byggeri 74 Bygning sstyrelse n 75 Bygning sstyrelse n Afsnit 17 Side 80 Bilag E I henhold til ovenstående generel bemærkning om tabeller mv. Er det vigtigt at understrege, at der skal arbejdes meget mere med klasser og underklasser, og hvordan de skal navngives. IT- egnethed: Der var oprindeligt planlagt en seance om IT-egnethed af DBK2006, den blev pludselig aflyst i efteråret Vi må anbefale at man tager dette op igen, og får belyst IT-egnetheden i en bredere sammenhæng med erfarne brugere i forhold til alle typer relevant software, som anvendes i virksomhederne. Bygningsstyrelsen er interesseret i en udrulningsplan og leveringstidspunkter for: - bygningsdel- og rumtabeller. - mappingtabel/vejledning for konvertering af DBK til CCS. - mappingtabel/vejledning for konvertering af SfB til CCS. Hvordan tænkes CCS at håndtere mere abstrakte aspekter som fag/rolle og arbejde (jf. bips 1000)? Dette spørgsmål af hensyn til fx økonomisk opfølgning og omkostningsanalyser. Det er cunecos holdning at den bedste metode til at verificere IT-egnetheden er ved at afprøve det i praksis. Dette har cuneco mulighed for fx i forbindelse med afprøvningsprojektet DNV- Gødstrup, hvor der er indgået aftaler med IT-leverandører og brugere om implementering og afprøvning af CCS. cuneco vil i løbet af juni måned 2012 komme med udmeldinger omkring konkrete planer for udrulning af klassifikations- og mapningstabeller. CCS anvendes til kodning i resultatdomænet. De nævnte aspekter vil blive håndteret i form af egenskabsdata, der jævnfør ISO , vil omfatte både ressourcer, processer og resultater.

34 76 Bygning sstyrelse n 77 Bygning sstyrelse n 78 Kjeld Svidt og Maria Thygese n, Bygning sinform atik, Aalborg Universi tet Rapporten bør give brugerne relevante kriterier for en beslutning om anvendelse af CCS kontra anvendelse af egenskabsdata. Bygningsstyrelsen efterlyser, at fordelene ved anvendelse af CCS belyses yderligere ift. små byggeprojekter, inden aflevering til drift. Dette tiltag skal være med til at sælge brugen af systemet yderligere overfor brugerne. 3 Det konstateres, at rapporten omhandler kodningsprincipper til anvendes ved klassifikation og identifikation af bygningsdele og rum. Det blev ved høringsworkshoppen pointeret, at det ikke handler om klassifikation, men om kodestuktur. Kommer der en tilsvarende rapport og proces for hhv. klassifikations- og identifikationsprincipperne? Umiddelbart skulle man tro, at kodestrukturen skulle afhænge af et forventet antal varianter, identificeret i klassifikations- og referencestrukturen. Kommentaren overføres til de grupper der skal arbejde med vejledninger / eksempelmateriale samt egenskabsdata. Denne opfordring er også modtaget gennem behovsanalysen og ønsket vil blive efterkommet gennem de scenarier cuneco anvender i sit arbejde. Scenarierne vil delvist udgøre beskrivelsen af den værdiskabelse, der skal verificeres i forbindelse med afprøvningsprojekterne. Det er cunecos opfattelse, at den foreslåede kodestruktur er fleksibel og uafhængig nok til at man kan håndtere det antal varianter, der vil blive afdækket i de kommende klassifikationsprojekter. Denne antagelse er gjort med udgangspunkt i det meget omfattende arbejde med hensyn til afdækning af antallet af bygningsdele, der blev gjort i DBK 2006.

35 79 Kjeld Svidt og Maria Thygese n, Bygning sinform atik, Aalborg Universi tet 80 Kjeld Svidt og Maria Thygese n, Bygning sinform atik, Aalborg Universi tet S. 3 i rapport + slide 4 i tk_intro Slide 17 i tk_intro CCS skal afløse DBK. Førend CCS udskiftes med DBK i lovgivningen, skal det sikres, at CCS er afprøvet og testet på flere scenarier. Systemet skal kunne skabe produktivitet, og de anvendelsesvanskeligheder DBK medførte, må ikke gentages. Mappingtabeller der migrerer fra SfB til CCS Ved migrering af SfB til CCS, hvordan er dette tiltænkt i forhold til f.eks. driftsherrens driftssystemer. Det bør testes, om de anvendte systemer også kan behandle CCS. Dette er en hel central forudsætning i cunecos arbejde. Det er cunecos opfattelse, at mappingen fra SfB til CCS er blevet gjort væsentligt enklere end fra SfB til DBK2006, da klassifikationen nu er uafhængig af referencestrukturen. cuneco planlægger at gøre denne mapping til genstand for en selvstændig afprøvning.

36 81 Kjeld Svidt og Maria Thygese n, Bygning sinform atik, Aalborg Universi tet 82 Kjeld Svidt og Maria Thygese n, Bygning sinform atik, Aalborg Universi tet S. 7 + slide 10 i tk_intro. I rapporten på side 7, beskrives CCS som en revidering af DBK, mens slide 10 indikerer, at tavlen er visket ren. s Krav Som udgangspunkt for projektet er der jævnfør opgavedefinitionen pkt. 3.3 stillet følgende minimumskrav som succeskriterie for projektet Gør det klart hvorvidt tavlen er visket ren eller om det er en mindre revision af et tidligere system. Grundlaget for de 31 krav er uklart. Der refereres til pkt. 3.3, som ikke findes i rapporten. Accepteret Teksten præciceres i rapporten. Accepteret Grundlaget beskrives bedre og referencer opdateres.

37 83 Kjeld Svidt og Maria Thygese n, Bygning sinform atik, Aalborg Universi tet 84 Kjeld Svidt og Maria Thygese n, Bygning sinform atik, Aalborg Universi tet 63 IFC beskrives som et udvekslingsformat mellem forskellige IT systemer. 14 Den nye CCS-kode er derfor udformet således at CCS-koden kan anvendes analogt uden understøttelse af ITsystemer. I praksis vil IT understøttelse dog være en væsentlig effektivisering i anvendelsen af CCS. IFC er en omfattende datamodel, som har været under udvikling i mere end 15 år, og som også indeholder aspekter af klassifikationer og referencesystemer. Hvorvidt forsøger man med CCS at løse samme problemer, som IFC skal løse? I hvilke situationer er CCS anvendelig uden brug af IT? Hvilke processer skal CCS understøtte hvem, hvad og hvornår? Der bør udarbejdes anvendelsesscenarier og brugergrænseflader, som illustrerer brugeren i den enkelte anvendelsessituation. Accepteret IFC er et udvekslingsformat og ikke et kodesystem. IFC kan indeholde CCS koderne, hvorved CCS koder kan overføres mellem forskellige IT systemer. Emnet præciceres yderligere i rapporten. Accepteret Kommentaren overføres til den gruppe der skal arbejde med vejledninger / eksempelmateriale.

38 85 White arkitekt er A/S Høringsr apport Side 17 Figur 2 med tilhøren de definitio n ISO :2001 Teknisk Rapport definition: Brugsrum: Et rumligt sammenhængende og afgrænset område i en bygning, der har et primært menneskeligt anvendelsesformål. Figur er vist med vægge rundt rummet. ISO :2001 Afsnit 2.10 Note 1 A space may be bounded physically or notionally se derudover Annex A punkt A.4 i ISO for 4 deling af Space begreb. Der findes ligeledes rum uden for bygninger gårdrum, torve, parkeringspladser mv. Forslag til ny definition: Brugsrum: Et rumligt sammenhængende og afgrænset fysisk eller teoretisk område i en bygning eller bebyggelse Delvist Definitionen opdateres i samråd med de øvrige arbejdsgrupper.

39 86 White arkitekt er A/S Høringsr apport side 24, 25 & 26, samt Bilag C Regel 12 Bilag C Redaktio nel Rapport s. 24 Strukturelt produktaspekt: Koder i dette aspekt identificerer objektforekomster i en strukturel dekomponering (systemer og deres bestanddele) af byggeriet. Denne dekomponering kan enten være foruddefineret i CCS eller være bestemt af projektet. Tabel 2 Foruddefinerede CCS aspektkoder inden for hvert aspekt Rapport s 25 (-) Identifikation af bygningsdele, baseret på en CCS defineret dekomponering af bygningsstruktur i systemer og deres bestanddele. Regel 12: Projektspecifikke aspektkoder anvender 3 ens præfikstegn (f.eks. --- ). Definition af sådanne projektspecifikke aspekt-koder skal beskrives i projektets dokumentation inkl. den anvendte klassifikation. Forslag til ny regel 12: Regel 12: Ved projektspecifikke aspektkoder indsættes 2 ekstra præfikstegn af samme karakter som aspekt foran aspektkode. f.eks. "---" angiver projektspecifik Strukturelt Bygnings ID, "----" angiver projektspecifik Strukturelt Brugsrums ID. Bilag C. bør udbygges med kodesyntaks for projektspecifikke systemer og hierarkier. Delvist Regel 12 bearbejdes. Bilag C udvides tilsvarende. Spørgsmål: Hvad eller hvordan adskilles et projektspecifik Bygningsdels ID fra et projektspecifik Brugsrum ID hvis begge har 3 ens præfikstegn.

40 87 White arkitekt er A/S 88 Markus Lampe, DTU CAS Forudgå ende komme ntar Bilag C Regel 12 Teknisk Begge sider Teknisk Såfremt et projekt ønsker flere forskellige projektspecifikke Strukturelt aspekt for Bygnings ID f.eks en for beskrivelser, en for anlægsbudget, en for finansiering og en for drift & vedligehold, hvilke muligheder er der for dette i kodesyntaksen? Hvorfor skal der defineres præcise disse 4 delaspekter og hvordan sikres det, at det er de aspekter som er de nødvendige for byggebranchen? Det vil først vise sig med anvendelsen af CCS. Bred anvendelse og stor fleksibilitet af CCS skal sikres, så at systemet kan bruges også med de ukendte krav, som kommer i fremtiden. Derfor burde der være en mulighed for at sener hende tilføje aspekter eller slette nogen, når de ikke bliver brugt. Alternativ: Kun klassifikationsaspekt & egenskaber (herunder de resterende aspekter). Delvist Delvist Formålet med CCS koderne er at klassificere og identificere bygningsdele og rum. Rapporten opdateres, så det præciceres hvad aspekterne gør, og hvordan man kan lave projecktspecifikke aspekter, og hvilke regler disse skal følge. Der er ikke krav om at anvende alle aspekter. Dette er styret af behov. De foreslåede aspekter er hentet fra defineret anvendelse (=,+.- og #) i ISO/IEC og klassifikationsaspektet (%) er tilføjet så klassifikationen kan anvendes seperat. Aspekterne er ikke begrænset til dette, og kan evt. udvides såfremt der viser sig et behov for dette senere. 89 Markus Lampe, DTU CAS Bilag C Begge sider Teknisk Rigtig godt tiltag, at anvende en simplet stabil klassifikation sammen med et identificerende aspekt / egenskab. For sikre en hurtig og bred integrering i byggebranchen og største fleksibilitet skulle man forenkle CCS, så at forklaring ikke behøver at fylde 80 sider, men kan forklares på få sider. CCS til klassifikationsaspekt (på grundlag af en enklere klassifikation end f.eks. SFB med synonymer) og egenskaber. De 4 resterende aspekter kunne fremhæves som nøgle egenskaber. Klassifikationen og identifikation kan dermed også ske igennem egenskaber (aspekt) sammen med klassifikationsaspektet som stabilt omdrejningspunkt fra vugge til grav". Fremtidig fleksibilitet er sikret. Ikke Dette tydeliggøres i rapporten. Den foreslåede ændring anses ikke for tilstrækkelig fleksibel til at tilfredsstille samtlige behov i livscyklus for et objekt.

41 90 Markus Lampe, DTU CAS 91 Markus Lampe, DTU CAS Saml. Præsent ation Slide 27 til 29 Teknisk Softwaren skal automatisk klassificere. Men sikkerhed af enkelt integration i software er ikke tilstrækkelig dokumenteret. Bestræbelser (Letter og intet, afprøvningsprojekt) grunder ikke på den til høring fremlagt materiale. Softwareudbyder har ikke set helheden af CCS. Dybden af forpligtelse af integration er ikke defineret (f.eks. komponentniveau). Mere inddragelse af en breder vifte af softwareleverandør. Når CCS er defineret, bred undersøgelse af integrationsmuligheder med svar ad softwareleverandør i ca. programmeringstid for integrationen af f.eks. kalssifikationssaspekter og egenskaber. Side 8 Teknisk d. løbende test af IT-egnetheden Dokumentation offentliggøres Har man bed Bips / Cunecos ITleverandør udvalg at bekræfte dette? Delvist cuneco har en dialog med et bredt udsnit af de leverandører, der leverer IT-systemer til den danske byggebranche, og er for indeværende ikke blevet gjort opmærksom på, at der er ting i CCS der ikke vil kunne implementeres i software. cuneco er opmærksomme på, at enkel softwareunderstøttelse samt tydeliggørelse af værdiskabelse er to helt centrale forudsætninger, for at tingene bliver implementeret. Procedure og deltagere tilføjes i rapporeten. 92 Markus Lampe, DTU CAS 93 Markus Lampe, DTU CAS Side 8 Side 63 Figur 10 - CCS og relation til IFC/IFD Side 9 Teknisk Redaktio nel e. CCS kode og relation/samspil med IFC og IFD ( ) Undervejs i projektet er afholdt koordinerende workshops og møder med( ). Blev CCS forlagt IT-leverandørgruppen i Bips? Dokumentation, redegørelse offentliggøres Har man bed Bips / Cunecos Building Smart udvalg at bekræfte dette? Forlægges IT-leverandørgruppen i Bips. bips buildingsmart udvalg er ikke blevet bedt om at bekræfte de udtalelser, som rapporten indeholder om IFC og IFD. Projektgruppen har haft møde med Håvard Bell (Norge), der er en af bagmændende bag IFD for bedst muligt at beskrive, hvordan der kan drages fordel af denne teknologi i forhold til CCS. Accepteret Er gennemført som en del af projektarbejdet. Det præciceres, at gruppen er ITleverandørgruppen i bips i stedet for interessenter fra ITleverandørbranchen.

42 94 Markus Lampe, DTU CAS Side 12 Side 59 Teknisk ( ) Klassifikationsdelen i CCS skal muliggøre en statisk klassifikation af en bygningsdel eller et rum, således at tilskrivningen af egenskabsdata ikke ændrer klassifikationen af objektet.( ) Er man sikkert på, at egenskaber aldrig må være klassificerende? ( ) Egenskabsdata såsom materialer eller form indgår ikke som klassifikationstema.( ) Det kan være meget vigtig, f.eks. for entreprenør. Alternativ: Kun klassifikationsaspekt & egenskaber (herunder f.eks. de resterende aspekter). Hermed sikres en fremtidig fleksibilitet og gøre det muligt at anvende egenskaber til identifikation og typisering. Det vil kunne dække alle behov af alle aktør i byggebranchen. Delvist CCS indeholder en forenklet klassifikation, der kan indgå i en entydig identifikation af et objekt. Når objektet er identificeret, kan man finde de øvrige egenskaber der er knyttet til objektet. Det er muligt projektspecifikt at inddele objekter i klasser på baggrund af objekternes egenskaber men hvad CCSklassifikationen angår, forudsættes det at objekterne ikke ændrer klasse, når egenskaber ændres i projektforløbet. 95 Markus Lampe, DTU CAS 96 Markus Lampe, DTU CAS Side 14 Teknisk ( ) Herved udelukkes bl.a. GUID( ) farlig, da den bruges i dagens dato i mange sammenhæng som kobling mellem forskellige programmer. F.eks. arealstyring i Dalux. Side 18 Teknisk ( ) De enkelte aspektkoder kan anvendes individuelt eller i kombination med hinanden. ( ). GUID kan anvendes som link. Det er rigtig vigtigt, at man ikke bliver påkrævet hvilke aspekter eller kombinationer man SKAL anvende. Dette er forskelligt fra fase til fase og behov til behov og fra bygherre til bygherre. Ikke Egenskaber kan inddeles i klasser hvor det giver mening/værdi. GUID kan evt. anvendes som link, men anses som ustabil som identifikation set over livscyklus. Accepteret CCS stiller ikke krav om hvilke aspekter der anvendes af de forskellige parter, da dette er afhængigt af deres individuelle behov. Kommentaren overføres til den gruppe der skal arbejde med vejledninger / eksempelmateriale.

43 97 Markus Lampe, DTU CAS Side 67 Redaktio nel Definition af aspekt mangler Vigtig grundlægende del af CCS Definition tilføjes Accepteret Definitionen tilføjes. 98 Markus Lampe, DTU CAS 99 Markus Lampe, DTU CAS Side 73 Side 74 / 75 Redaktio nel Teknisk Der savnes en enklere klassifikation af bygningsdelene. Man kan ikke sige at CCS er enklere en DBK med aspekterne Kommentar: Skillefladen mellem egenskabsdata og klassifikation af objekter bør defineres således at kodningen af byggematerialer og produkter ikke bliver påvirket af ændringer i deres egenskabsdata ( ) af egenskabsdata ikke ændrer klassifikationen af objektet. Der anvendes en funktionel enkelt klassifikation af bygningsdele og rum & egenskaber Der bruges filter for egenskaber og eller bygningsdele/rum klassifikationen for at finde de ønskede dele. Hvorfor skal Skillefladen mellem egenskabsdata og klassifikation defineres? Hvis man kun bruger klassifikationsaspektet & egenskaber er det også løst. Hvorfor er det nødvendig? Brug af klassifikationsaspektet & egenskaber gør bygningsdel og rum stabil. Man kan udpege den egenskab, som ikke skal ændre sig fra vugge til grav og det kunne også være en brandklasse lige så meget som f.eks. funktionsaspektet. Ikke Kodeprincipperne i CCS lægger op til at klassifikationsdelen forenkles i forhold til DBK2006. Identifikation af objekter i CCS foretages ved brug af referencestrukturer eller simpel fortløbende nummerering. Dette betyder at objekter idenficeres ved brug af CCS, og det er derfor ikke nødvendigt at finde objekter ved brug af diverse former for filtre. Kommentaren videregives til projektgruppen der arbejder med klassifikation.

44 100 Christia n Lundstr øm ISO standarden foreskriver anvendelse af symboler som præfiks for angivelse af domæne. Dette giver anledning til misforståelse idet +, -, = har entydig betydning i samfundet som regnetegn og vil blive læst som sådan. I forhold til oplistning af bygningsdele m.v. i regneark vil anvendelse af de gængse regnetegn give anledning til problemer og store fejlmuligheder. Eks. =JB2 vil returnere indholdet af celle JB2, som almindeligvis er =0. ==, ++ o.l. har tilsvarende andre betydninger ved programkodning, hvorfor de også ved implementering i IT programmer kan give anledning til misforståelser hos programmører og fejl. At præfiks f.eks. anføres i parentes (=), (+) etc. Dette giver større læsevenlighed, færre misforståelser og kan anvendes i regneark. Ikke Da cuneco finder at tilføjelse af fx parenteser i forbindelse med præfiks vil besværliggøre arbejdet med koderne vælger vi at fastholde, den foreslåede notation. Det er i fx Microsoft Excel muligt at ændre formateringen af celler for at sikre, at CCS-koder ikke opfattes som regneudtryk, formler eller referencer.

45 101 Kristian Birch Pederse n 3.1 Projektgrundlag Teknisk Det er lidt trist, at cuneco alene forsøger at løse morgensdagens udfordringer med gårsdagens metoder. I andre brancher udvikles ontologier, der redegør for objekter og sammenhænge mellem objekterne. Herved kan man opbygge intelligente videnhåndteringssystmer, der automatisk kan analysere viden i systemer. I CCS ses kun på objekter, men ikke deres relationer, dermed er CCS alene anvendeligt til strukturering og ikke umiddelbart klart til at blive anvendt f.eks. i forbindelse med Semantic Web teknologier o.lign. I forbindelse med cunecos projekt vedr. metode og struktur for egenskabsdata beskrives det, hvordan relationer til andre objekter er en egenskab for et objekt. Om dette er fuldt tilstrækkeligt i forhold til at opfylde de formål, der efterlyses, kan være genstand for en nærmere analyse, men i forhold til nærværende projekt har vi begrænset os til at identificere det enkelte objekt med henblik på at kunne referere til alle egenskaber for objektet. Jeg har beskrevet en ontologiudviklingsmetode i denne rapport på side 251, som cuneco med fordel kunne lade sig inspirere af: al_models_linked_with_physical_com ponents_in_construction.pdf

46 102 Kristian Birch Pederse n 103 Kristian Birch Pederse n 104 Kristian Birch Pederse n 4.2 Krav Teknisk Det undrer, at kravene er så detaljerede tekniske, og at der ikke er formuleret nogle mere overordnede krav om hvad klassifikationssystemet som minmum skal kunne bruges til. Derved er der en betydelig risiko for at CCS opfylder de formaliserede tekniske krav uden f.eks. at være egnet til at strukturere bygningsdele, så de kan anvendes til entydig og automatisk prissætning i forbindelse med udbud baseret på mængder og lignende prakiske use-cases. 4.2 Krav Teknisk Det undrer, at det ikke er noget krav, at der udvikles en klassifikationsstruktur som er konsistent, korrekt og uden redundans. Afsnit 5 Redaktio nel Formuleringen CCS omhandler klasser og identifikation af objekter i den rigtige verden, dvs. uden om (IT) modelverdenen. Dermed sikres, at CCS ikke er i konflikt med eventuelle 3D modeller, IFC m.v., men er et fælles referencepunkt for disse. virker noget talesprogsaktig og indekreret, at der formodes at være en konklikt ift. IFC. Det foreslås at lade afsnittet udgå og i stedet udføre en saglig vurdering og eksemplificering af hvorledes CCS og IFC kan anvendes sammen. Delvist Den valgte fremgangsmåde er en konsekvens af, at cunecos behovsanalyser (der netop skal belyse anvendelsen) har pågået samtidig med gennemførelsen af kodestrukturprojektet. Samtidig er det cunecos holdning, at man med den definerede struktur vil kunne opfylde de beskrevne behov. cuneco er indstillet på, at foretage korrektioner, hvis det fortsatte arbejde indikerer, at dette er nødvendigt. Afsnittet udgår ikke, men forholdet mellem IFC og CCS beskrives bedre.

47 105 Kristian Birch Pederse n 106 Kristian Birch Pederse n 107 Kristian Birch Pederse n 108 Kristian Birch Pederse n Afsnit 5 Teknisk Beskrivelsen af forskellen på objekttype, objektforekomst og objektindivid er ikke helt klar. Er det nødvendigt at tale om både objektforekomster og objektindivider? Er begge ikke blot en instans af en objekttype med forskelligt detaljeringsniveua af egenskabsdata? Afsnit 5 Teknisk Formuleringen Objektindivider kan udskiftes, mens objektforekomsterne består. er ikke korrekt, afhænger det ikke af størrelsen af renoveringen? Teknisk Ville det ikke være hensigtsmæssigt, at sætte referencekoderne til sidst? Med undtagelse af efter ibrugtagning af el og mekaniske anlæg underlagt stærkstrømsbekendtgørelsen og maskindirektivet er disse af mindre betydning end klassifikationskoden Identifik ationskr av Teknisk Hvorfor bruges ressourcer på at integrere kodningsprincipperne med identificationsprincipper? Kan dette ikke blot gøres med en unik genereret kode, som det kendes fra f.eks. IFCmodeller, stregkoder, RFID-tags, objekter bygningsmodelleringssoftware m.v.? Det foreslås at lade betegnelsen objektindivid udgå, ligesom det er valgt for rum i afsnit 6. Se ovenfor. (red. Kommentar 105: "Kristian Birch Pedersen, Exigo-5") Delvist Delvist Ikke Definitionerne af de forskellige objekter er central og bevares, men suppleres med en figur der tydeliggør forskellen. Formuleringen rettes og skal præcicere, at objektforekomster også kan udgå, såfremt objektet helt udgår. Det er uklart hvad der menes med referencekoderne. Rækkefølgen af de forskellige aspektkoder er uden betydning. I flere sammenhænge vil de automatisk genererede koder, der stammer fra fx bygningsmodelleringssystemer, ikke være anvendelige. Dette gælder fx hvis man ønsker at slette et objekt og genindsætte uden at ændre identifikationen af objektet. Derudover vil denne type koder ikke være læselige for mennesker, og det vil ikke give mening at sortere efter dem.

48 109 Kristian Birch Pederse n 110 Kristian Birch Pederse n t Det er lidt trist, at der bruges så meget fokus på referencestrukturer sammenligt med den beskedne fokus på klassifikation. Afsnit Teknisk Det er uklart hvor dybt cuneco vil klassificere bygningsdele. Hvis dette gøres alt for overordnet, vil CCS blive uanvendeligt til f.eks. brug i forbindelse med f.eks. automatisering af tilbudsprocessen. En stålsøjle bør f.eks. kunne skelnes fra en betonsøjle via klassifikationskoden, selvom den eneste forskel på dem er egenskabsdata for materialer. Alternativt bør egenskabsdataene systematiseres så meget, at der automatisk kan filtreres eller sorteres efter dem i stedet for klassifikationskoden. Lad teksten om referencestruktur udgå og tilføj følgende: For anvendelse af referestrukturer i forbindelse med f.eks. driften af mekaniske og elektriske anlæg se: ISO/IEC 81346, og kom nu i gang med at definere de klassifikationstabeller. Den danske byggebranche har behov for et klassifikationssytem hurtigst muligt. Præciser den planlagte dybde af klassifikationstabellerne. Ikke Klassifikationen har fået en central rolle i CCS. Det er vigtigt at få et fælles kodningsprincip på tværs af fagene / domæner. Kommentaren vidergives til arbejdsgrupperne for klassifikation og egenskabsdata. Kommentaren Alternativt bør egenskabsdataene systematiseres så meget, at der automatisk kan filtreres eller sorteres efter dem i stedet for klassifikationskoden er den løsning der er valgt i CCS.

49 111 Kristian Birch Pederse n 112 Kristian Birch Pederse n Afsnit 3.1 Afsnit Teknisk Teknisk ISO nævnes i projekgrundlaget, men dens fundamentale pincip med at klassifikationstabeller skabes ud fra en overordnet systematik om at en construction process skaber et construction result og bruger construction ressource ser ud til at være helt negliceret i CCS. På den baggrund vurderes det meget tvilvsomt om CCS i praksis vil kunne mappes til andre klassifikationssystemer baseret på ISO Det er uklart hvad der sker med koden hvis der viser sig behov for at have mere end 29 objekttyper på hvert niveau. Delvist Delvist De foreslåede CCS koder anvendes udelukkende i construction result, hvilket præciceres i rapporten. Mapning til andre landes klassifikationssystemer foregår via IFD, hvilket præciseres i rapporten. Der er rettelig plads til 23 objektklasser pr. niveau, og ikke 29. Klassifikationen i CCS fastlægges så der ikke er behov for mere end 23 objektklsser pr. niveau i klassifikationen. 113 Kristian Birch Pederse n Afsnit 8 Teknisk Det giver ikke mening at omtale et klassfikationsaspektet. Klassifikationen anvendes til at strukture og gruppere de øvrige aspekter. Lad klassifikationsaspektet udgå. Delvist Det præciceres i rapporten, at der anvendes underklassifikation såfremt de 23 typer overskrides. Fuktionaliteten af "klassifikationsaspektet" i CCS bibeholdes. En endelig afklaring af anvendelsen af begrebet aspekt pågår i cuneco i øjeblikket, og denne afklaring vil afgøre, om begrebet 'klassifikationsaspekt' bibeholdes eller omdøbes, fx til "typeaspekt".

50 114 Kristian Birch Pederse n 115 Kristian Birch Pederse n 116 Kristian Birch Pederse n Afsnit 8 Teknisk Der er ikke taget stilling til hvorledes hovedparten af tabellerne i ISO skal kodes. Afsnit 8 Teknisk Det er unødvendigt at anvende %- tegnet foran klassifikationskoden, det vil sikkert forvirre mere end det vil gavne. Afsnit 8 Teknisk Er et rum ikke en slags placeringsaspekt i sig selv? De dobbelte koder for rum bør udgå. Det forvirrer mere end det gavner. Ikke Ikke Nærværende projekt omhandler kun resultatdomænet i ISO Ressource- og procesdomænet håndteres separat hvilket dog ikke betyder, at man ikke vil kunne komme til at anvende lignende principper i disse domæner. Det konkrete antal tabeller, der skal udvikles er ikke fastlagt og vil afhænge af de identificerede behov samt de igangværende afklaringsprojekter. Tegnet er medtaget for at kunne skelne de forskellige aspektkoder entydigt fra hinanden. Dette understøtter bl.a. IT anvendeligheden af CCS. Det er uklart hvad der menes med dobbelte koder.

51 117 Kristian Birch Pederse n Afsnit 8 Teknisk Rum har fået sin egen præfiks med dobbelt-koder. Det virker lidt underligt. Hvad sker der med alle de objekter i byggeriet som endnu ikke er klassificeret såsom materiel, arbejdsprocesser, bebyggelser, personer/roller osv. Er tanken så for hver klassifikationstabel, at fortsætte med at sætte tegn efter hinanden? Var det ikke mere hensigtsmæssigt blot at bruge et tal eller bogstav til klassifikationstabellens nummer? Delvist De fremlagte kodeprincipper anvendes i resultatdomænet. De nævnte klasser ligger jævnfør ISO i andre domæner end resultatdomænet og tænkes ikke kodet i henhold til en aspekttankegang. Dette præciseres i rapporten.

52 118 Kristian Birch Pederse n Afsnit 10. Teknisk De fire foreslåede tabeller for bygningsdele har ikke nogen umiddelbart relation til ISO Der foreslås at lave en 100 % 1-til-1 sammenhæng mellem de 16 overordnede klasser (tabeller) i ISO og de overordnede tabeller i CCS. Ikke De 4 foreslåede tabeller (systemtabel, bygningsdelstabel 1, bygningsdelstabel 2, ISO/IEC tabel 1) er alle deltabeller af ISO tabel A7 (elements). Argumentationen er et citat fra ISO , side 9: There are other possible ways of specializing the object classes, but the recommended tables are considered to represent the most important ways. Provided that each country uses this framework of tables and follows the definitions given in this part of ISO 12006, it will be possible for standardization to develop table by table in a flexible way; e.g. country A and country B could have a common classification table of elements, for example, but different classification tables for work results without experiencing difficulties of fit at the joints. Det bemærkes, at ISO er under revision, og at dette bl.a. omfatter nye tabeller som ikke eksistere I ISO I dag, herunder del-af tabeller som fx. CCS strukturelle produktaspekter.

53 119 Kristian Birch Pederse n 120 Kristian Birch Pederse n Afsnit Afsnit Teknisk Teknisk Det virker højest besyndeligt at starte kodningen med K for terræn. Hvor blev KISS princippet af? Alfabetet starter med A. Det er højest besyndeligt, at der i forslaget til klassifikationstabellen er gjort rigtig meget for at undgå konflikt med kodning af elektriske og mekaniske bygningsdele efter ISO/IEC , men det virker ikke som om, at der er brugt energi på at udvikle et system baseret på ISO Det virker somom, at CCS forsøges indpasset i ISO uden rigtigt at passe særlig godt ind. Referencesystematikken bør kun anvendes der hvor den giver mening og ikke gennemsyre og komplicere klassifikationskoderne unødigt. De tre grundlæggende aspekter produkt, placering og funktion der anvendes i ISO giver god mening, men at gennemtvinge referencemetodikken i alle andre klassifikationstabeller virker ikke gennemtænkt, og vil med stor sandsynlighed resultere i, at CCS vil lide samme triste skæbne som DBK Ikke Klasserne for hovedsystemer skal følge reglerne for klassifikation beskrevet i ISO/IEC tabel 3. De anførte klasser er kun ment som eksempler. Klasserne af hovedsystemer skal kun anvendes i del-af strukturene, og ikke i %-klassifikationen, der alene klassificerer bygningsdele (uden at være en del af en referencestruktur). ISO/IEC og ISO er ikke i konflikt med hinanden.

54 121 Kristian Birch Pederse n 122 Kristian Birch Pederse n Afsnit 11.3 Teknisk Teknisk Definitionerne af Konstruktioner, Delkonstruktioner og Komponenter virker ikke særligt teoretisk velfunderet. Er der ikke blot tale om bygningsdele, som kan nedbrydes i bygningsdele ind til et atomart niveua nås? I teksten står: At arbejdet funderes på ISO dette er ikke udmøntet i den i høringsmaterialet beskrevne udgave af CCS, der alene er baseret på ISO Der foreslås opbygget én simpel klassifikationsstruktur med 5-8 niveauer og bygningsdele. Arbejdet foreslås grebet successivt an, så detaljereingsniveauet fastlægges ud fra behovet svarende til praktisk anvendelse. CCS bør grundlæggende baseres på ISO og ISO bør så indpasses heri, og ikke omvendt. Alternativt kan ISO anvendes som supplement i forbindelse elektriske og mekaniske systemer i drift. Delvist Kommentaren vidergives til arbejdsgruppen for klassifikation, hvor indelingskriteriet for de enkelte klasser skal defineres. Teknisk note: Der vil i praksis være få hundrede objekter der skal klassificeres jf. det nye princip om stabilitet, og ikke som anført. Klassifikationsstruktur med 5-8 niveauer vil ikke overholde kravet om stabilitet i klassifikationen, og der vil i praksis sandsynligvis blive tale om 2-3 niveauer for at skabe en stabilitet der er tilstrækkelig. CCS er baseret på ISO , der er en rammestandard for klassifikation af byggeriet (dvs. uden at være særlig specifik). ISO omhandler ikke kodningsprincipper for bygningsdele eller rum. ISO/IEC indeholder principper for kodning og identifikation, som cuneco har valgt at inddrage i arbejdet i det omfang det kan supplere ISO Dette tydeliggøres i rapporten.

55 123 Kristian Birch Pederse n 124 Kristian Birch Pederse n 125 Kristian Birch Pederse n 126 Jan Karlshøj 127 Jan Karlshøj 128 Jan Karlshøj 129 Jan Karlshøj Afsnit 11.3 Teknisk Det er uklart hvorledes cuneco tænker ISO og ISO anvendt i sammenhæng. Kan produktaspektet f.eks. sidestilles med work result i ISO ? t Ideen om at have en stabil kode gennem hele projektet er fin. t Anvendelsen af bogstaver i koderne i stedet for tal er fin, det giver kortere koder end ved anvendelse af tal. Positivt Man arbejder med en mere stringent syntaks i kodningen. Positivt Man fjerner krav om klassifikationen per undertype skal danne en kontinuer liste af tal. Dvs. en ventil har samme underkode uanset om den tilhører det ene eller andet system. Positivt Der er en klarere adskillelse af klassifikation og løbenr. Positivt Der forventes en mere overordnet klassifikation, som ikke overlapper så meget med objekternes egenskaber. Arbejde med adskilte variable og kun bruge sammensatte strenge, hvor det giver værdi. Arbejde med adskilte variable og kun bruge sammensatte strenge, hvor det giver værdi. Arbejde med adskilte variable og kun bruge sammensatte strenge, hvor det giver værdi. Delvist Tydeliggøres i rapporten. Aspektkoderne kan i det fremsatte forslag allerede nu anvendes separat og sammensættes til en samlet kodestreng efter behov. Aspektkoderne kan i det fremsatte forslag allerede nu anvendes separat og sammensættes til en samlet kodestreng efter behov. Aspektkoderne kan i det fremsatte forslag allerede nu anvendes separat og sammensættes til en samlet kodestreng efter behov.

56 130 Jan Karlshøj 131 Jan Karlshøj Negative Strukturen ser fortsat ud til at være kompliceret og kræve bruge af computere, men på den anden side ikke it-egnet. Negativt Ser ikke specielt it-egnet ud fx svært at lave en sortering i Excel. Man blander fire aspekter sammen i en kode. Arbejde med adskilte variable og kun bruge sammensatte strenge, hvor det giver værdi. Jeg ville foretrække, hvis der skal være 4 koder/variable, at de var adskilte og kun blev samlet i forbindelse med udskrifter. Jeg mener ikke at strengen egner sig til behandling i it-systemer. Brugen af specielle karakterer gør ikke implementeringen lettere. Delvist Aspektkoderne kan i det fremsatte forslag allerede nu anvendes separat og sammensættes til en samlet kodestreng efter behov. Aspektkoderne kan anvendes separat og sammensættes til en samlet kodestreng efter behov. Egenskabsprojektet vil varetage dette således at de enkelte aspektkoder er separate egenskaber på objekterne (datamæssigt set). 132 Jan Karlshøj 133 Jan Karlshøj Negativt Systemet giver anledning til dobbelt registrering såfremt at fx BIMprogrammer benyttes. CCS kan angive relationen fra en bygningsdel til et rum, men denne relation kender softwaren allerede eller kan beregne den. Negativt Koblingen til IFD er kun mulig for en del af CCS-koden. Bruges hele koden kan den ikke kobles til IFD. Skal kun bruges når det er relevant fx i forbindelse med udskrifter. Adskil strengen i flere variable. Delvist Delvist Brugen af præfiks og skråstreger til seperering af aspektkoderne muliggør adskillelse af aspektkoderne. CCS er designet til brug i alle sammenhænge, herunder også BIM (men ikke begrænset hertil). Det kan ikke forudsættes, at alle parter har BIM til rådighed, og derfor skal CCS også kunne håndteres uden BIM-modeller. Systemerne vil kunne generere den strukturelle kode ud fra deres kendskab til sammenhængen. Det er ikke nødvendigt at vedligeholde den strukturelle kode mens man arbejder internt i systemet. Se svar til høringskommentar nr. 58

57 134 Jan Karlshøj 135 Jan Karlshøj 136 Jan Karlshøj Negativt Det er mere eller mindre basalt set DBK i en forbedret udgave, men med mange af de samme svagheder som DBK havde. Side 51 %JB / #JB7 / -MB3.JB2 / =MB1 / +MB3.DF3 / ++A1.AAA1 Er/bliver materialet kommenteret af Anders Ekholm og Lars Haggstöm? Hold tingene adskilt. Lav et it-egnet system og fasthold de eksisterende systemer/lav det er nødvendigt af hensyn menneskelig tolkning. Det må forventes at regler og lovgivning i stigende grad tillader brug af it, og dermed vil behovet for systemer til menneskelig tolkning blive mindre. Ikke Det er uklart hvad der menes med mange af de samme svagheder som DBK havde, Hold tingene adskilt og Lav et IT-egnet system. Ifølge cunecos opfattelse beror mange af de uhensigtsmæssigheder, der er blevet påpeget i forhold til DBK på, at man i forbindelse med udviklingen og impelementering ikke i tilstrækkelig grad har belyst, hvordan og til hvad systemet skulle anvendes. cuneco vil gennem en beskrivelse af hvordan CCS anvendes i interaktionen mellem mennesker-mennesker, menneskermaskiner og maskiner-maskiner sikre, at systemet vil kunne anvendes nu uden at blive konserverende i forhold til den fremtidige udvikling. Adskil strengen i flere variable. Aspektkoderne kan i det fremsatte forslag allerede nu anvendes separat og sammensættes til en samlet kodestreng efter behov. Få både Anders Ekholm og Lars Haggstöm til at kommentere konceptet. cuneco har indgået aftale med Anders Ekholm om at han kommenterer materialet.

58 137 Jan Karlshøj 138 Michael Porskær, Søren Jensen A/S 139 Michael Porskær, Søren Jensen A/S 140 Michael Porskær, Søren Jensen A/S Er konceptet reelt baseret på input behovsanalysen? Og er der lavet en mapping mellem elementerne i konceptet og behovsanalysen? Teknisk Aspektkoder bør komme i bestemt rækkefølge, der bør som minimum anbefales en rækkefølge. I forhold til IT systemer er det naturligvis underordnet hvilken orden de kommer i, men i praktisk daglig brug ville det for genkendelsen, når man arbejder på forskellige projekter være rart at ikke at skulle huske på hvad der nu gælder for det ene og det andet. Side 23 Teknisk Antallet af cifre i løbenummeret bør være fast ellers skal det aftales fra gang til gang Side 38 Teknisk Hvornår er det godt at vide at en stikkontakt sidder i en bestemt væg? Referencen til væggen kan naturligvis undlades, men der savnes konkrete eksempler på hvornår det giver mening at have denne reference og hvem der kan have gælde af den Lav en mapning så er det klart for alle hvor behovet kommer fra. Der vedtages en række følge for aspektkoder Antalet af cifre vedtages at være 3 Ikke Ikke Behovsanalysen siger ikke særlig meget om klassifikation - men siger rigtig meget om behov der forudsætter, at der foreligger en fælles klassifikation. cuneco arbejder på at beskrive løsningen af disse behov i form af scenarier, som anvendes i forbindelse med udvikling og afprøvning. Aspektets præfiks er entydigt og er tilstrækkelig til at genkende koden, både for mennesker og IT-systemer. En fast rækkefølge er derfor ikke påkrævet. Kommentaren overføres envidere til de grupper der skal arbejde med vejledninger / eksempelmateriale. Koderne vil blive unødigt lange, og kan endvidere vedtages separat for de enkelte projekter. Specificer med konkrete eksempler Kommentaren overføres til de grupper der skal arbejde med vejledninger / eksempelmateriale.

59 141 Michael Porskær, Søren Jensen A/S 142 Michael Porskær, Søren Jensen A/S Side Teknisk Hvorfor er systemnumre ændret til bogstaver? Er det fordi angiver disse, ville det ikke være godt at kunne skælle systemer fra bygningsdele der også er 2-cifre bogstaver Side 55 Teknisk Der savnes en definitation af hvornår mar eksempelvis et vægsystem. Det kan være det løser sig når tabellerne bliver udarbejdet, men system tanke gangen er ikke så umiddelbar ved arkitekt og konstruktuion, som den er ved installation Det definderes klare hvornår man har et system. CCS benytter konsekvent bogstaver som klassifikation. Kommentaren overføres til de grupper der skal arbejde med vejledninger / eksempelmateriale.

60 143 Claus Johanne ssen t t Kære Cuneco. Jeg deltog i jeres høringsmøde i går på DTU. Selve grundlaget for kodningsprincipperne ser ud til at kunne bære igennem fsa. Kodning Jeg vil dog stille spørgsmål til anvendeligheden i det daglige arbejde. Hvorfor kalder man ikke en spade for en spade og en dør for en dør? Når vi skal beskrive en bygningsdel har vi brug for en klar beskrivelse. Dvs. at vi altid og også fremover vil bruge en betegnelse der angiver dørnummer, brandklassifikation, materialer, farve, beslåning mv. og det er det samme for alle bygningsdele. Hvad skal så egentligt bruge koden til hvis ikke den er i stand til at beskrive dette? Så er det jo bare det samme som et ethvert andet nummer. HVORFOR kan man ikke bruge betegnelser i klassifikationen som: DOOR, WALL, CEILING, FLOOR, ROOF, BUILDING, ROOM, etc. etc. Det giver umiddelbart mening og vil være en information vi vil skulle levere under alle omstændigheder. Det virker som om kodningsprincipperne er bygget op omkring en tankegang der fokuserer på små EL og VVS dimser som nok er svære at holde styr på men i bund og grund ikke bør diktere klassifikationen på det der er det væsentlige: Nemlig BYGNINGEN! Nu har en dør heddet en dør i mange tusinde år. Brug IFC navngivningen! Ikke Koderne vil blive for lange (Door3, Wall34) og princippet kan ikke håndtere underklassificering af objekter i typer.

61 144 NCC NCC har gennem flere år anvendt dele af DBK2006 (bygningsdele og entrepriser). Vi er overbevist om værdien af et klassifikationssystem. For os er værdien skabt gennem vores egen interne anvendelse af DBK, ikke gennem kommunikation af DBK-koder med andre virksomheder. Ikke fordi, vi ikke gerne vil kommunikere DBK-koder med andre, men fordi der har været få at kommunikere med. Værdien af et klassifikationssystem fremhæves ofte som kommende fra at virksomhederne kan kommunikere effektivt med hinanden, at vi taler samme sprog. Den værdi er der naturligvis, men den første, og i lang tid den største værdi er den, virksomheden skaber internt gennem veldefinerede begreber, en ensartet terminologi, en nyttig struktur, et anvendeligt kodesystem osv. Der er ikke behov for ændringer til standarden på dette punkt. Men fortæl meget gerne om begge former for værdiskabelse: Den værdi, virksomheden kan skabe internt, også selvom den i lang tid er ret alene om at bruge klassifikationssystemet. Den værdi, der skabes, når virksomheden kan kommunikere mere effektivt med andre virksomheder. Kommentaren overføres til de grupper der skal arbejde med vejledninger / eksempelmateriale.

62 145 NCC Det er ikke muligt fuldt ud at vurdere CCS kodningsregler på nuværende tidspunkt. Af to årsager: Standarden er kompleks og svær at forstå. Der er tale om meget mere end kodningsregler, nemlig en hel filosofi for, hvordan klassifikation skal håndteres i den danske byggebranche. Man kan ikke afslutte formidling og høring af noget så komplekst på 18 dage. Det bliver ikke nemmere af, at rapporten kunne være mere pædagogisk. Vi er bange for, at mange i branchen ikke har kunnet sætte sig fyldestgørende ind i standarden på den korte tid selvom de gerne ville. Det gælder i hvert fald os selv. Rapporten beskæftiger sig kun med en del af CCS samlede klassifikationskoncept. Rapporten udpeger (gennem eksempler) kun de objekttyper, der skal klassificeres (de forskellige bygningsdele, f.eks. vægkonstruktion, dør, samling ). Det har bestemt værdi, men begrænset i forhold til en mere detaljeret klassifikation. Der er behov for underklassifikation af f.eks. bygningsdele (forskellige vægkonstruktionstyper, dørtyper, ). Rapporten mener, at yderligere klassifikation af objekttyperne skal håndteres vha. egenskabsdata. Det betyder, at cunecos samlede klassifikationskoncept bliver en Vi synes, det en fordel med delhøringer, som den der er i gang for CCS kodningsregler. Den samlede opgave både med udvikling og høring af CCS må nødvendigvis brydes ned. Af de to årsager, nævnt i kommentarkolonnen foreslår vi, at høringen af CCS kodningsregler afsluttes med status Vi er klogere men ikke færdige med CCS kodningsregler og klassifikation. Cuneco bør støtte yderligere formidling og debat om CCS kodningsregler. Det er desuden nødvendigt med en samlet diskussion og vurdering af hele cunecos klassifikationskoncept. Det samlede koncept vil være beskrevet i: En ny udgave af CCS kodningsregler, der tager høringsresultatet i marts 2012 i betragtning. Resultatet af cuneco-projektet Afklaring af klassifikationsniveau. Dette projekts opgave er bl.a. at afklare hvor grænsen skal gå mellem klassifikation i CCS og klassifikation vha. egenskabsdata. Denne afklaringsopgave ligger ret beset ikke i CCS kodningsregler. De konkrete klassifikationstabeller, der skal udvikles. Resultatet af cuneco-projektet Afklaring af struktur og metode for egenskabsdata. cuneco anvender helt generelt en iterativ tilgang til udviklingen. Dette betyder at der afholdes en lang række høringer undervejs i udviklingsprocessen, og at tilbagemeldingen fra en høring kan have konsekvenser for andre projekter end lige præcis det, der var i høring i den pågældende sammenhæng. cuneco er derfor enige i den fremgangsmåde, der foreslås i denne kommentar, og opfatter det som værende i overensstemmelse med den anvendte arbejdsgang i cunecos projekter.

63 146 NCC Afsn side 22 Vi mener, at grænsen mellem hvilke klassifikationsbehov, der dækkes vha. klassifikationskoden, og hvilke klassifikationsbehov, der dækkes vha. (yderligere) egenskabsdata er helt fundamental for alle klassifikationssystemer, også for CCS. Alle klassifikationssystemer har denne grænse. På et eller andet tidspunkt slipper mulighederne for klassifikation vha. klassifikationskoden op, og man må ty til (andre) egenskabsdata. Forskellige klassifikationssystemer placerer grænsen forskelligt. DBK2006 har mulighed for en ret detaljeret klassifikation af bygningsdele, og hvis ellers bygningsdelsklasserne er nyttige må man relativt sjældent ty til de øvrige bygningsdelsegenskaber for at klassificere. OmniClass har en endnu mere detaljeret klassifikation af bygningsdele vha. klassifikationskoden. Vi mener ikke, der er nogen naturlov, der siger, hvilket klassifikationsniveau (vha. klassifikationskoden), der er det rigtige. Der er fordele og ulemper ved både høje og lave niveauer. Vi har i næste kolonne søgt at skitsere nogle fordele og ulemper ved det meget høje niveau, som CCS kodningsregler anbefaler. Vi vil pege på et muligt designproblem i CCS kodningsregler. Fordi Lav en god analyse af fordele og ulemper ved en klassifikationskode på meget højt niveau og tilsvarende omfattende brug af egenskabsdata til klassifikationsformål. Her er, hvad vi kan komme i tanke om: Fordele: Klassifikationskoden vil med relativt høj sandsynlighed forblive konstant. Betyder f.eks., at objektforekomstens identifikator sjældent ændres, da klassifikationskoden indgår i identifikatoren (hvilket vi ikke er helt overbeviste om, er en god ide, se andet punkt). Klassifikationskoden kan gøres relativt enkel indenfor det enkelte aspekt. Koden kan indgå i dækningen af mange klassifikationsbehov (men ulempen er, at koden ofte ikke er nok). Mange varierede klassifikationsbehov kan dækkes vha. egenskabsdata. I princippet kan alle objektets egenskaber, bortset fra identifikatorer, bruges i klassifikation. Man får fleksibilitet og dynamik i klassifikationen. Relativt lille risiko for konflikt mellem konkrete egenskabsdata og klassifikationskode for det enkelte objekt. Ulemper: Det samlede klassifikationskoncept[1] skal inddrage i Delvist CCS kodningsregler og CCS klasser og CCS egenskaber skal fungere sammen som beskrevet, og derfor afsluttes kodningsregler ikke før end klassifikationen er på plads. Kommentaren overføres til klassifikations- og egenskabsdatagruppen.

64 NCC Vi værdsætter, at der er lyttet til kritikken af DBK2006 og tidligere arbejdsversioner af CCS, og at CCS gennem sin større fleksibilitet imødekommer en række af de behov, der har været nævnt. NCC De formulerede krav til CCS er omfattende, og løsningen er ambitiøs måske for ambitiøs. Der er reelt tale om flere delstandarder indenfor samme standard. NCC DBK2006 er også kompleks, når man tager flere/alle aspekter i anvendelse, men her har produktaspektet en dominerende stilling. Alle skal anvende dette, mens de øvrige aspekter er frivillige. Sådan er det ikke i CCS, så vidt vi har forstået: Her er alle aspekter frivillige, men man skal selvfølgelig anvende mindst ét aspekt. Bliv ved med at lytte. Pas på med ambitiøsiteten. Er der en regel, der siger, at alle aspekter er frivillige, men at mindst ét aspekt skal anvendes? Hvis ikke (og hvis dette i øvrigt er korrekt), bør man tilføje sådan en regel. Måske er det ikke så simpelt. Kan man f.eks. anvende placeringsaspektet uden at anvende det strukturelle produktaspekt (eller måske det simple produktaspekt)? Accepteret Dette præciseres i rapporten.

65 150 NCC Prisen er en standard, der samlet set er mere kompleks. Det er rigtigt, at man gennem anvendelse af et/få aspekter kan forsimple sin anvendelse af standarden væsentligt i forhold til DB2006. Men virksomheden/byggeprojektet skal igennem en ikke helt enkel proces for at forstå standarden og for at udvælge de dele, der skal tages i anvendelse. Tilsvarende har den IT-producent, der i sit standardsystem vil implementere hele eller store dele af CCS, en stor opgave. Der er en reel risiko for, at standardens udbredelse og IT-implementering hæmmes pga. kompleksiteten. Vi peger på nogle få forenklinger i de følgende kommentarer. Men grundlæggende følger kompleksiteten og omfanget af krav, ambitionsniveau og overordnet filosofi for CCS. Hvis man holder fast i dette, er indsatsen primært af pædagogisk og hjælpende art: Let forståelig dokumentation CCS for Dummies afprøv både standarden og dokumentationen Vejledninger f.eks. i hvordan man udvælger de dele af CCS, man vil anvende. Kurser, støtte Gennemskuelig og pålidelig understøttelse i standard IT-systemer cuneco finder de foreslåede løsninger til, hvordan forståelsen af systemet kan understøttes meget konstruktive og anvendelige, og det er givetvis noget der vil tages i anvendelse. cuneco finder det centralt at beskrive koblingen mellem formålet med at klassificere og de dele, der anvendes i forhold til det konkrete formål, da det kan hjælpe brugeren (og IT-leverandøren) med at fokusere på den del af systemet, der er relevant for ham.

66 151 NCC Med den store fleksibilitet i anvendelsen af CCS følger, at to parter, virksomheder, projekter, der begge anvender CCS, ikke nødvendigvis kan kommunikere effektivt med hinanden. Eks.1: En installationsingeniør, der kun anvender det strukturelle produktaspekt, kan f.eks. ikke kommunikere sine identifikatorer for bygningsdele til en entreprenør, der kun anvender det simple produktaspekt. Vi har ikke nogen gode løsningsforslag. En mulig, men skræmmende, løsning er, at man for det enkelte byggeprojekt beslutter, hvordan CCS skal anvendes. At der indgås en projektspecifik CCSaftale (analog med en IKT-aftale). Det stiller store krav til den enkelte parts omstillingsevne, og kan føre til at han stort set skal mestre hele standarden. Vi hører meget gerne om bedre løsninger. Delvist Anvendelsen af CCS koder afhænger til dels af de projektspecifikke aftaler fx i en IDM manual (informationsniveauer) aftales. Ad eks. 2.) Ikke. En dør kan ikke placeres i (være en del af) en vægkonstruktion. Eks. 2: En arkitekt placerer døren direkte i vægsystemet, men konstruktionsingeniøren placer den i vægkonstruktionen, der er placeret i vægsystemet. En udfordring, hvis de samarbejder i samme byggeprojekt. Parterne kommunikerer heller ikke nødvendigvis deres bygningsdelsklasser og rumklasser særlig effektivt med hinanden.

67 152 NCC Afsn. 6 side 17 Redaktio nel Der står CCS koder to grundlæggende objekter: bygningsdele og rum. Bør der ikke stå: CCS koder tre grundlæggende objekter: systemer, bygningsdele og rum., og lade afsnittet dække de tre objekter? Ikke Bygningsdele kan håndteres i overordnede systemer af bygningsdele. System(er) er ikke et objekt i sig selv. 153 NCC Afsn side 23. Der står: NOTE: Det skal bemærkes at der i klassifikationsaspektet er mulighed for at lave en projektspecifik underklassifikation af CCSklassifikationen, og at disse underklasser fx kan opbygges af tal. Skal underklassen ikke opbygges af tal? Hvis det er forstået rigtigt, er der vist mange steder, hvor systemer skulle være nævnt sammen med bygningsdele og rum. Hvis svaret på spørgsmålet er ja, rettes til og at disse underklasser skal opbygges af tal. Der er et (måske mindre betydningsfuldt) brud på logikken her. I de andre aspekter anvendes tal til at angive løbenumre. Delvist Anvendelsen af tal præciseres således at anvendelsen af tal i det nævnte aspekt fremgår mere tydeligt.

68 NCC Afsn side NCC Afsn side 38 /39 Teknisk Teknisk Vedr. funktionsaspektet: Man skal tilsyneladende bruge det strukturelle produktaspekt både for den objektforekomst (system eller bygningsdel), man vil tildele funktionel klassifikation, og den objektforekomst i bygningens funktionsstruktur, man vil tilknytte. Det virker ulogisk og begrænsende. Hvis det er vigtigt at kunne angive funktion for systemer/bygningsdele, er det vel lige vigtigt, uanset om man anvender simpel identifikation eller kompositionel identifikation. Man kan tilsyneladende ikke skrive: #JB52 / =JB7 : Dør nr. 52 har funktionskrav som specificeret for funktionel dør nr. 7. Vedr. placeringsaspektet: Man skal tilsyneladende bruge det strukturelle produktaspekt både for den objektforekomst (system eller bygningsdel), man vil placere, og den objektforekomst, man vil placere i. Det virker ulogisk og begrænsende. Hvis det er vigtigt at kunne angive placering, er det vel lige vigtigt, uanset om man anvender simpel identifikation eller kompositionel identifikation. Man kan tilsyneladende ikke skrive: #SFA47 / +LUD65 : Afbryder nr. 47 placeret i plade nr. 65 Vi er med på, at den foreslåede syntaks i rapporten ikke kan klare dette, fordi aspekttegnet = hermed får to betydninger. Men hvis det er vigtigt, må man udvikle syntaksregler, der dækker behovet. Vi er med på, at den foreslåede syntaks i rapporten ikke kan klare dette, fordi aspekttegnet + hermed får to betydninger. Men hvis det er vigtigt, må man udvikle syntaksregler, der dækker behovet. Delvist Delvist Anvendelse af funktionsaspektet for bygningsdele (=) tydeliggøres. Anvendelse af placeringsaspektet for bygningsdele (+) tydeliggøres yderligere i rapporten.

69 NCC Afsn side 45 NCC Afsn side 45 Redaktio nel Her introduceres objekttyperne Bebyggelse, Bygning og Etage uden videre. Læseren er ikke velforberedt. Det virker som nogle sidste-øjeblikstanker. Skal det angivne aspekttegn efter sætningen Syntaksen for aspektkoden ser derfor således ud ikke være - (i stedet for = ). Forbered, beskriv, definer disse objekttyper på lige fod med de øvrige, der behandles i rapporten Accepteret Henvisning til ISO 4157 indsættes. <- Se Accepteret (=) rettes til (--). Man bemærker, at identifikation af bygninger sker uden brug klassekode sammenstillet med løbenr.

70 158 NCC Teknisk Hvordan bør man vurdere CCS ITegnethed? Det er glædeligt, at en række kompetente IT-leverandører har været involveret i udviklingen og kommenteringen af CCS, og at de siger CCS kan implementeres i vores ITsystemer. Det er en nødvendig, men langt fra tilstrækkelig forudsætning, at kompetente og ressourcestærke ITproducenter siger god for standarden. IT-egnetheden må ikke kun vurderes af en begrænset skare af ressourcestærke, kompetente producenter af standard IT-systemer. Repræsentanter fra de øvrige grupper af IT-folk, og fra IT-brugerne, skal også komme med deres vurdering og denne skal indgå i den samlede bedømmelse af CCS IT-egnethed. De scenarier, der beskriver anvendelsen af CCS vil beskrive hvilke dele af CCS, der skal anvendes i konkrete sammenhænge og dermed hvilken delmængde af CCS, de enkelte ITleverandører skal implementere i deres systemer. Dette vil gøre opgaven mere overskuelig. Langt størstedelen af de IT-folk, der kommer til at arbejde med CCS, kommer imidlertid fra interne ITafdelinger i byggebranchens virksomheder. IT-afdelingerne kan være store, men ofte består afdelingen af nogle få medarbejdere måske kun en enkelt som har få ressourcer til at lære og til at implementere CCS i virksomhedens IT-systemer. Dertil kommer, at størstedelen af ITunderstøttelsen af CCS kommer til at ske i andre systemtyper end de store standard-cad/bim-systemer med god udbredelse på det danske marked. Det drejer sig om: Kalkulationssystemer, sagsstyringssystemer, økonomisystemer/kontoplaner, data warehouse-systemer, rumprogramdatabaser, planlægningssystemer osv.

71 159 NCC Teknisk CCS skal være særdeles IT-egnet, hvis standarden skal udbredes i branchens IT-systemer, jf. foregående punkt. Efter vores mening er det ikke let at bruge CCS i IT-systemerne. CCS-koden er meget fleksibelt opbygget. Det fører til en høj grad af positionsløshed. Antallet af bogstaver på hvert niveau kan variere. Antallet af cifre i underklasser og løbenumre kan variere. Foranstillede nuller er ikke et krav. Antallet af niveauer i referencestrukturen kan variere (fordi man ikke behøver at medtage mellemliggende niveauer). Det fører til banale, men store praktiske problemer med at sortere, filtrere, søge Desuden bliver fortolkningen af CCSkoden i applikationssystemerne vanskeligere. Dertil kommer, at inddragelse af egenskaber i det samlede klassifikationskoncept kan føre til omfattende systemændringer, jf. tidligere. En løsning kan være, at den enkelte virksomhed definerer sin egen husstandard for, hvordan CCS-koden skal bygges op. Men det holder sandsynligvis kun til det øjeblik, man er nødt til at kommunikere sine CCS-koder med andre virksomheder (med andre husstandarder for CCS). Her er et eksempel på en mere håndfast løsning: Der skal altid være det samme antal bogstaver på et givet niveau (inklusiv typer). Nedenfor forudsættes tre tegn. Eksempel: Vægsystem klassificeres som MB_ MB for vægsystem og _ (underscore) for ingen speciel type vægsystem, og MBA MB for vægsystem og for ydervæg osv. Dette i stedet for MB for vægsystem uden nogen speciel type. Hvis man har tænkt at opretholde to niveauer af typer gælder det naturligvis, at der også skal afsættes fast plads til dette og dermed være fire tegn på hvert niveau Ikke Kodens opbygning med præfiks, bogstaver, tal og skilletegn er entydig, og kan tolkes af IT-systemer efter en veldefineret regel.

72 NCC CCS skal være særdeles IT-egnet, hvis standarden skal udbredes i branchens IT-systemer, jf. foregående punkt. NCC Implementering af CCS i et standard ITsystemer kan ske på mange måder. Man kan ikke, når man hører, at et bestemt IT-system understøtter CCS, vide, hvordan CCS er understøttet. Der er behov for, at forskellige typer af IT-systemer implementerer CCS med fornøden og gennemskuelig kvalitet og ensartethed. Der er desuden behov for, at der for et konkret IT-system præcist, ensartet og enkelt beskrives, hvilke dele af CSS, der er implementeret i systemet. (Dette behov findes også for DBK2006, men det er større med CCS pga. den større fleksibilitet i standarden.) Man kan forestille sig, at IT-opgaven forenkles ved at IT-producenter (og cuneco/bips) udvikler forskellige tekniske hjælpemidler, som stilles til rådighed for branchen. F.eks. en generel fortolker af CCS-kodestrengen. Denne kunne leveres som plug-in til forskellige, udbredte programmer, f.eks. office-programmer. Det kan hjælpe, men vil ikke fjerne problemet. Der bør udvikles et sæt entydige retningslinjer for, hvordan CCS skal implementeres i IT-systemer, herunder hvilke dele, der skal implementeres og hvilke dele, der er frivillige. Herudover er der behov for, at en kompetent og uvildig instans overvåger og kontrollerer CCS-implementeringen i branchens standard IT-systemer. Der skal efter godkendelse udstedes et certifikat for den konkrete version af ITsystemet, der dokumenterer, at CCS er implementeret korrekt, samt hvilke dele af CCS, der er implementeret. Ved nye versioner af IT-systemet skal certifikatet fornyes. Denne instans kan desuden yde bistand til virksomheder med egenudviklede ITsystemer. Dette ønske er noteret og cuneco vil bestræbe sig på, at der bliver etableret en tjeneste som beskrevet på BDS. Det er cunecos holdning at de enkelte dele af CCS skal kobles til de praktiske formål, som klassifikationen skal anvendes til - og dermed også til funktionaliteten i IT-systemerne. Dette vil igen hænge sammen med en kravstillelse, der er formålsorienteret. En godkendelsesinstans er en god idé, men der er ansvarsmæssige implikationer, der skal overvejs nøje.

73 162 NCC Teknisk Identifikatorer for objektforekomster skal ubetinget kunne holdes uforanderlige. Identifikatorerne i både det simple (#) og det strukturelle (-) produktaspekt er afhængig af objektforekomstens klassekode. I det strukturelle produktaspekt er identifikatoren desuden afhængig af identifikatoren (klasse + løbenr.) for de overliggende objektforekomster i kompositionsstrukturen. Det fører uvægerligt til at identifikatoren ikke med sikkerhed kan holdes konstant. Udform et identifikatorbegreb, der er uafhængigt af andre egenskaber for objektforekomsten eller for andre objektforekomster. Man behøver ikke kaste sig ud i GUIDidentifiers for at opnå dette. Det simple produktaspekt kunne f.eks. blot tildeles en 6-tegns kode. Det giver et antal mulige identifikatorværdier på mindst 346. Eller 1 mio, hvis man kun vil anvende cifre. Ikke Den foreslåede CCS opfylder de krav som der er stillet til løsningen for kodeprincipperne. Dette er beskrevet i rapporten, og er måden som CCS koderne virker på. CCS forholder sig ikke til antallet af cifre i hver kodedel og vil /bør ikke standardiseres, da antallet af cifre også afhænger af størrelsen på den enkelte projekter (store projekter = større antal løbenumre, små projekter = lille antal løbenumre). Det fører også til krav om klassen ikke må ændres for en objektforekomst, og det heraf afledte krav, at CCS skal klassificere på et relativt højt niveau. Begge dele uheldige, som nævnt ovf.

74 163 NCC Teknisk Vi forstår godt baggrunden, men det virker ikke logisk og hensigtsmæssigt, at en objektforekomst kan have to identifikatorer (i det simple og det strukturelle). Hvorfor er der flere identifikatorer i standarden? Kan standarden nøjes identifikation i #- aspektet? Vi kan godt se, dette vil føre til et tab, hvis man vil have CCS-koden til at angive bygningsdelsforekomstens (rumforekomstens) kompositionelle placering indenfor overliggende forekomst(er). Delvist De to muligheder for identifikation dækker forskellige behov, og det er frivilligt hvilken man benytter (evt. begge). Man kan derfor nøjes med én identifikation. Der udarbejdes et skema i rapporten der viser de forskellige kombinationsmuligheder ved anvendelse af de forskellige aspekter samt begrænsningerne ved udeladelse af bestemte aspekter.

75 164 NCC Afsn. 10, s. 54 og frem Teknisk Vi er meget skeptiske overfor rapportens input til selve kodningsarbejdet. Her anbefales, at man benytter bogstaverne og klassifikationen fra ISO/IEC 81346, og at man så lægger de dele som denne standard ikke dækker (dvs. de konstruktive bygningsdele) ind på de ledige bogstaber (vist kun 3 bogstaver). Dette mener vi er uacceptabelt: Vi kan ikke styre hvad der sker med ISO/IEC standarden. Den kan på et senere tidspunkt vælge at lave væsentlige ændringer eller at tage de ledige bogstaver i brug til noget andet end det CCS på eget initiativ bruger dem til. Vi mener at det vil give en meget skæv klassifikation hvor man på det øverste niveau bruger mange bogstaver på at dække installationer og kun ganske få til de øvrige områder. Der er ikke noget logisk/teknisk i vejen for det, men det kan være forkert behovsmæssigt og vil i hvert fald være uheldigt formidlingsmæssigt. Ikke dermed sagt at man ikke kan bruge hele eller dele af ISO/IEC klassifikationen i CCS, men det skal i givet fald være i en indkapslet del, hvor CCS har kontrollen og sætter rammerne, ikke omvendt. Se Foreslåede ændring. Der bør udvikles en generel mekanisme, der tillader andre standarder at blive adopteret i værtsstandarden CCS. Den fremmede standard skal på en eller anden generel måde indkapsles (måske med et præfix?), så dens koder ikke clasher med eller begrænser kodeanvendelse i værtsstandarden, CCS, eller i andre standarder, som værtsstandarden har adopteret. IEC skal have lov til at anvende sine koder. Men det skal klassifikationen af konstruktive og andre ikke-mekaniske/elektriske systemer/bygningsdele også. Denne adoptionsmekanisme skal være generel. Dvs. den skal ikke kun gælde systemer, bygningsdele og rum, men alle objekttyper, som CCS i fremtiden kommer til at dække, f.eks. også objekttyper indenfor ressourcedomænet. Det bliver måske ikke (forhåbentlig ikke) sidste gang, CCS bliver vært for andre standarder. Hvad med f.eks. Standard(er) for anlæg Standard(er) for byggevarer (ressourcedomænet). Vi har tidligere anbefalet, at man her kigger på de etablerede standarder, frem for at udvikle selv (stort arbejde, stor risiko for at byggevareproducenterne ikke vil følge). I forbindelse med cunecos projekt vedr. afklaring af klassifikationsniveau for bygningsdele pågår der i øjeblikket et arbejde, hvor inddelingen og kodning af klasser laves med udgangspunkt i klassifikationsbehovene for de relevante områder. I den forbindelse vil de relevante standarder blive inddraget.

76 165 NCC Ovenstående fører til det generelle krav -> Klassifikationsstandardens grunddesign skal være af en sådan karakter, at der i fremtiden ikke lægges væsentlige begrænsninger på udvidelsesmuligheder. Standarden skal være langtidsholdbar, og vi kender ikke fremtidens behov. Kommentaren videregives til arbejdsgruppen der bearbejder klassifikationen for bygningsdele og rum. 166 NCC Teknisk Vi har behov for mapning fra DBKbygningsdelskoder (i produktaspektet) til CCS-koder (i det strukturelle produktaspekt). Der skal være mulighed for at udvide klassifikationen både i bredden (nye objekttyper, nye klasser indenfor kendte objekttyper) og i dybden (underklasser til underklasser til ). Vi har behov for, at information ikke går tabt i denne mapning. I det omfang, CCS-koderne er mere generelle end DBK-koderne skal overskudsinformation i DBK-koden tydeliggøres i et passende sæt egenskabsdata. Vi har behov for at mappingtabeller er klar samtidig med frigivelse af denne del af CCS.

77 NCC Vi er bekymrede for, at al størstedelen af udviklingskraft endnu en gang går i klassifikation af bygningsdele. Hvad med objekter/begreber i ressourcedomænet som først lige er ved at blive analyseret. NCC NCC, og andre virksomheder indenfor anlæg, har et behov for en veludviklet klassifikation indenfor anlægsområdet. Det gælder både Objekttyper indenfor resultatdomænet. DBK2006 har nogle ganske få anlægstyper indenfor bygningsdele og rum, men de er langt fra dækkende. Objekttyper indenfor ressourcedomænet, specielt entrepriser rettet mod anlæg. Opprioriter det cuneco-projekt, der skal afdække behov indenfor ressourcedomænet. Der er en reel risiko for, at der endnu en gang hverken bliver tid eller ressourcer nok til at gøre noget særligt indenfor dette område. Cunecos deadline ligger kun godt 2 år ude i fremtiden. I første omgang skal kodningsreglerne for systemer, bygningsdele og rum (egentlig de tilsvarende hovedobjekttyper indenfor anlæg) udformes, så de tilgodeser behovene indenfor anlægsområdet. Herudover vil vi opfordre til, at der igangsættes projekter til udvikling af objekttyper, klassifikationsdybde, klassetabeller, egenskabsdefinitioner osv. indenfor anlæg. Som nævnt både i resultat- og ressourcedomænet. Ressourcedomænet er genstand for et selvstændigt projekt, og den pågældende projektgruppe er p.t. i færd med at beskrive behovet for en indsats på dette område. Styregruppen vil inddrage denne kommentar i forbindelse med behandlingen af gruppens oplæg. cuneco har fået til opdrag at udvikle standarder, der dækker hele det byggede miljø i forhold til alle faser. Gruppen der p.t. kigger på Klassifikation af bebyggelser, bygninger og rum skal også inddrage anlæg, veje, parker, broer etc.

78 NCC Afsn. 9, side 48 NCC 13 Bilag A side 67 Teknisk Teknisk I trin 5 står Da det er relevant at vide hvilken vægkonstruktion i vægsystemet døren skal monteres i, tildeles dørens objektforekomst en reference for placeringen i konstruktionsrummet: -JB2:MB3 / +DF3:MB3 Koden læses: Dør nr. 2 i Vægsystem nr. 3 placeret i Vægkonstruktion nr. 3 i Vægsystem nr. 3 Hvorfor er der behov for denne kodning i placeringsaspektet? Citat: Objekt (byggeobjekt) En fysisk bestanddel eller tænkt fysisk bestanddel - af en bygning med alle dens iboende egenskaber, relationer til omkringliggende byggeobjekter samt øvrig relateret information. Kan man ikke bare sige, at døren indgår i vægkonstruktion nr. 3, dvs. nøjes med -MB3.DF3.JB2? Når den kompositionelle struktur er den samme som den placeringsmæssige, er den placeringsmæssige vel overflødig? Det er forhåbentlig ikke korrekt. CCS skal også beskæftige sig med ikke fysiske objekter. Eksempler: Faser/processer/aktiviteter Roller Entrepriser (der nok rummer fysiske objekter, men ikke selv kan karakteriseres som et sådant) NCC Afprøvning er vigtig. I Gødstrup bør man sikre sig, at alle aspekter bliver afprøvet, både indenfor bygningsdele og rum. Man bør ligeledes afprøve et stort udvalg af klasser både i bredden og dybden. Ikke Ikke 1.) Reglen er, at produktaspektet (-) identificere selve objektet (her: dør), mens placeringsreferencen er en kryds-reference til et andet objekt, dvs. hvilket andet objekt som selve objektet er placeret i. Dette muliggør referencer på tværs af systemer (fx fra et el-system til et vægsystem). 2.) Eksemplet døre indgår i vægkonstruktion nr. 3 dvs. nøjes med - MB3.DF3.JB2 er forkert, da en dør ikke er en del af en vægkonstruktion, men en del af et vægsystem, på lige fod med en vægkonstruktion. Kodningsprojektet omhandler objekter i ISO s resultatdomæne, hvor objekterne bygningsdele og rum henføres til, og som den anførte definition omhandler. De nævnte begreber faser, roller, entrepriser m.v. er ikke objekter i resultatdomænet. Kommentaren overføres til afprøvningsprojektet.

79 NCC De dele af CCS, der kommer fra IEC/ISO (mekaniske og elektriske systemer/bygningsdele) skal være af nogenlunde samme natur som de dele der er udviklet for konstruktive bygningsdele, f.eks. mht. aspekter, klassifikationsniveau, detaljeringsgrad i bygningsdele, NCC Teknisk Bilag B: Vi værdsætter beskrivelsen af CCS i metasprog. Vi har ikke forstand på EBNF, men det ser ud som om beskrivelsen ikke er færdigudviklet. Beskrivelsen af kodesyntaksen (ikke kun for bygningsdels- og rumkoder) skal være en fuldgyldig del af standarden. NCC Hvad er strategien med forvaltningsklassifikation. Skal der udvikles mapping mellem CCS og den udviklede Forvaltningsklassifikationsstandard? Skal den udviklede Forvaltningsklassifikationsstandard adopteres i CCS (analogt med IEC/ISO , hvis det kan lade sig gøre)? Eller skal der udvikles ny forvaltningsklassifikation i CCS? Vi kender ikke IEC-standarden. Er det tilfældet? Få en metasprog-ekspert til at udarbejde specifikationen, hvis cuneco ikke råder over en sådan. Lyt til eksperten, hvis han påpeger manglende logik, tvetydigheder osv. så er det formentlig fordi der er problemer, med strukturen, som bør løses. Svar: ja, de er af samme natur. cuneco har noteret, at relevante eksterne kompetencer skal inddrages i denne sammenhæng. Strategien mht. til FK er beskrevet ovenfor i svaret på kommentar nr. 67.

80 NCC Teknisk Lokale udvidelsesmuligheder Man bør kunne tilføje virksomhedsspecifikke eller projektspecifikke klasser for bygningsdele (og måske også rum), ikke kun underklasser til eksisterende CCSklasser. Der bør udvikles en generel mekanisme for tilpasning af CCS til virksomheden eller projektet? NCC Teknisk Vi har problemer med at forstå begrebet klassifikationstema. NCC Teknisk Vi forstår ikke begrebet funktionsstruktur og dermed heller ikke funktionsaspektet. NCC Teknisk De IT-producenter, der har deltaget i vurdering af IT-egnetheden, er primært producenter, der ETABLERER klassifikationskoder. Der er tilsyneladende ikke nogen, der læser og fortolker CCS-koder, som er etableret af fremmede systemer Kunne man definere begrebet, og eksplicit angive de klassifikationstemaer, der konkret anvendes rundt omkring? I det omfang, det ikke allerede er sådan. Kunne man definere funktionsstruktur og gerne uddybe med forklaring og eksempel på en sådan struktur. Inddrag også IT-producenter, der kan vurdere om CSS koden kan fortolkes. Fortolkning kan være en mere kompleks opgave end etablering af koden. Særlig i et system, der er så fleksibelt i sin kodeopbygning som CCS. Ved kode generering (afsender), kan man lave sin egen standard inden for standarden. Det kan man ikke, når man fortolker (modtager). Her skal man kunne håndtere alle de mulige kombinationer, som standarden tillader. Dette er en del af rapporten, se afs Se også NCC-10. Accepteret Klassifikationstema defineres i rapporten. Accepteret Begrebet og dets anvendelse præciseres og eksemplificeres.

81 179 NCC Redaktio nel Vi synes generelt, at terminologien omkring klassifikationsaspektet og det simple produktaspekt antyder, at de to aspekter er lidt inferiøre. Brug en ligeværdig terminologi. Delvist En alternativ terminologi overvejes ved revision af rapporten. Se også svar til høringskommentar 166. (Tilsvarende de to punkter ovf. Der omhandler, at det simple produktaspekt vist ikke kan anvende i placeringsaspektet og funktionsaspektet.)

82 180 Simon Friberg Jeg vil på forhånd beklage at jeg ikke kan være mere præcis, da det ville tage for meget tid og ekstra research for mig da jeg ikke forsker i Videnso rganisat oriske brudflad er til daglig. Det er meget vel og godt at tænke i stabilitet og globalisering men hvis det er et klassifikationssystem der skal have en kvalitet med verdensklasse er der, udfra min synsvinkel, nødt til at være nogle biblioteks/vidensorganisatorisk faglighed ind over kodereglerne i særdeleshed og systemet i almindelighed. Ved gennemgang af høringsrapporten for CCS kodningsregler, forekommer det mig tydeligt at CCS vil kunne blive mere smidigt og stabilt uden at gøre køb på kravet om internationalisering. To krav der lader til at begrænse målet når de begge burde/kunne være innovationsmotorer i udformningen af koderegler/principper til CCS. Jeg anbefaler en gennemgang af systemets dele/mål/opbygning/regler foretaget af en informationsvidenskabelig forsker der arbejder med klassifikationsteoretiske analyser. Dem findes der et mere end par stykker af på Informations Videnskabeligt Akademi, Birger Hjørland eller Pia Borlund ville være et fint sted at starte. Jeg er da også villig til at lede videre for jer efter eksperter der kan gennemse og kommentere mere præcist og fagligt end jeg måske ville kunne. Det er jo ikke utænkeligt at andre fagligheder, forskere i Informationsarkitektur eller videnorganisation i bredere forstand fx, kunne sættes ind på opgaven for at stille de gode og for dem indlysende spørgsmål, der i sidste ende skaber skaber det holdbare og prøvede regelsæt til systemet. cunecos styregrupe vil medtage forslaget i det videre arbejde.

83 181 Henrik Bang, Bygherr eforenin gen Overordnede kommentarer Overordnet finder Bygherreforeningen det kursskifte, der er sket fra DBK, meget positivt herunder det fokus på tre mekanismer klassifikation, specifikation og ID-systematik som præger CCS. Det virker rigtigt at starte med håndtering og klassifikation af rum og bygningsdele for herefter at overveje andre objekter (såsom mandskab, materialer, materiel, metoder, processer og organisation). Endvidere finder vi det meget positivt med udmeldingen om mapping mellem CCS og Forvaltningsklassifikation. Udover håndtering og klassifikation af rum og bygningsdele overveje andre objekter (såsom mandskab, materialer, materiel, metoder, processer og organisation). Behov for en bredere anlagt beskrivelse af formålet med og værdiskabelsen i klassifikation set i lyset af det paradigmeskift som byggeriets samarbejdsformer, metoder og værktøjer undergår i disse år. Formålet med den fremlagte kodestruktur er at kunne klassificere og identificere bygningsdele og rum, som findes i ISO resultatdomæne. De øvrige objekter der nævnes (mandskab, materialer, metoder etc.) ligger i ressourcedomænet og procesdomænet i ISO , og er ikke en del af kodeprojektet for bygningsdele og rum. Vi finder at der med det foreliggende høringsforslag er åbnet for en frugtbar diskussion om formålet med at klassificere rum og bygningsdele, men også at der stadig savnes en bredere anlagt beskrivelse af formålet med og værdiskabelsen i klassifikation set i lyset af det paradigmeskift som byggeriets samarbejdsformer, metoder og værktøjer undergår i disse år.

84 182 Henrik Bang, Bygherr eforenin gen International standardisering Hvad angår international standardisering kan vi konstatere, at man vælger et spor (EN 81346) ud af tre mulige og skal pege på den mulige fare for isolation i den danske byggesektor, hvis man i udlandet går andre veje. Det bør undersøges nøje, om det foreliggende forslag er kompatibelt med ISO hhv. IFC, IFD og IDM (de to andre spor). Undersøgelse af, om det foreliggende forslag er kompatibelt med ISO hhv. IFC, IFD og IDM (de to andre spor). Delvist Det fremlagte forslag er ikke i konflikt med de nævnte standarder, og understøtter disse. Dette tydeliggøres i rapporten.

85 183 Henrik Bang, Bygherr eforenin gen Princip og metode for klassifikation Til at belyse klassifikation kan det være en god ide at benytte views som princip, som forslaget bygger på. Men som generelt princip har den valgte løsning en række uheldige konsekvenser, idet kun et stærkt begrænset antal views tillægges en særlig betydning (uden at det er dokumenteret, at der er særligt brug for dem), mens det ikke nævnes, hvordan andre lige så relevante views kan indarbejdes (fx fag og arbejder views for byg- og driftsherrer). Som alternativ til at pege på tre views bør det overvejes at udvikle en metode til håndtering af anvendelsen af views ikke kun i forbindelse med klassifikation, men mere generelt til støtte for informationshåndteringen. Det bør overvejes at udvikle en metode til håndtering af anvendelsen af views ikke kun i forbindelse med klassifikation, men mere generelt til støtte for informationshåndteringen. Det bør overvejes at opgive referencesystematikken som et fælles grundlag for bygningsklassifikationen og i stedet satse på at udarbejde en vejledning i konkret anvendelse af EN cunecos strategi om at anvende en overordnet klassifikation og supplere dette med en struktureret anvendelse af egenskabsdata er bl.a. lavet ud fra et ønske om kunne håndtere objekter i forhold til en lang række forskellige formål, der ikke alle kan dækkes af den samme klassifikation. Dette mener cuneco er helt konsistent med det beskrevne ønske og en del af formålet med egenskabsdataarbejdet vil være at beskrive, hvordan sæt af egenskaber defineres i forhold til specifikke formål. De øvrige objekter der nævnes inden for fag, arbejder m.v ligger i ressourcedomænet og procesdomænet i ISO , og er ikke en del af kodeprojektet for bygningsdele og rum. Referencesystematikken (del-af) er ikke grundlag for klassifikation af bygningsdele i CCS, hvorfor bemærkningen om at "opgive referencesystematikken som fælles grundal for bygningsklassifikation" i princippet er imødekommet. Det fremlagte forslag for kodestruktur tillader en fleksibel anvendelse, herunder "ren" klassifikation uden nogen form for referencestruktur. Dette beskrives mere klart i revisionen af rapporten.

86 184 Henrik Bang, Bygherr eforenin gen 185 Henrik Bang, Bygherr eforenin gen Princip og metode for klassifikation Desuden savner vi en beskrivelse af, hvordan arbejdet med modelbaserede værktøjer og IKT-baseret informationshåndtering skal understøttes af enten klassifikationstabeller eller af specifikation med udfoldede egenskabsdatasæt eller begge dele. Med rigdommen af egenskaber for selv de enkleste byggeobjekter, er det vanskeligt at forestille sig en klassifikationssystematik med lige så mange klassifikationstabeller eller facetter, som der kan etableres relevante views. Princip og metode for klassifikation Det bør overvejes at opgive referencesystematikken som et fælles grundlag for bygningsklassifikationen man kunne i stedet satse på at udarbejde en vejledning i konkret anvendelse af EN som alternativ. Behov for en beskrivelse af, hvordan arbejdet med modelbaserede værktøjer og IKT-baseret informationshåndtering skal understøttes af enten klassifikationstabeller eller af specifikation med udfoldede egenskabsdatasæt eller begge dele. Delvist Beskrivelsen vil løbende blive udviklet i forbindelse med cunecos arbejde med egenskabsdata og informationsniveuaer samt afdækningen af behov og værdiskabelse i branchen. Kravet om at kodestrukturen skal indeholde en referencedel er en del af forudsætningerne for løsningen af opgaven. Dette er begrundet med, at man ønsker at have en entydig reference til objekterne gennem hele projektets livscyklus. Referencesystematikken er ikke et grundlag for bygningsklassifikationen. Med det fremlagte forslag kan klassifikationen anvendes uafhængigt af referencesystematikken. Dette tydeliggøres i rapporten.

87 186 Henrik Bang, Bygherr eforenin gen Fokusområder for klassifikationsarbejdet Bygherreforeningen ser tre oplagte fokusområder i det fremtidige arbejde for at kunne skabe værdi: Grænsefladen mellem drift og programmering samt konceptuelt design grænsefladen mellem udførelse /drift med fokus på dokumentation og driftsdata samt grænsefladen projektering/udførelse med fokus på tilbudsberegning og produktions-forberedelse. Lad det fremtidige arbejde være rettet mod de mest oplagte fokusområder mht. værdiskabelse Det er disse tre områder, der explicit er beskrevet i cunecos behovsanalyse og alle tre områder vil være centrale i den fremtidige udvikling.

88 187 Henrik Bang, Bygherr eforenin gen Rum og Bygningsdele - og meget andet Bygherreforeningen tilslutter sig forslaget om til en start at fokusere på håndtering og klassifikation af Rum og Bygningsdele. Vi er af den klare opfattelse at det netop er på disse områder (overgangen mellem projekt og produktion, hvor bygningningsdelene jo spiller en central rolle, samt håndteringen af bygniningerne hos byg- og driftsherren, hvor rum, funktion og organisering spiller en helt central rolle) at gode, sunde løsninger på datahåndtering kan skabe størst værdi. Vi vil foreslå, at der samtidig med at der arbejdes videre med disse objektkategorier - og før der træffes endelige beslutninger om klassifikationskonceptet og om syntax mv. - fokuseres på at beskrive, hvordan man påtænker at håndtere de mange andre objektkategorier, der er beskrevet i grundlaget for DBK, og som jo også nødvendigvis må inddrages i et samlet klassifikationskoncept. Der tænkes her især på: De fire M er - mandskab, materialer, materiel og metoder; Byggeriets processer; Byggeriets organisation - herunder agenter og roller. cuneco har noteret sig opfordringen til at lave en samlet oversigt over sammenhængen mellem de fire domæner i ISO P.t. foretages dette i separate projekter, men det overvejes at lave en samlet redegørelse for disse domæner, som supplement til begrebsmodellen fra ISO Af disse tre områder finder vi, at det især er påkrævet med udviklingen af et klart billede af den fremtidige sammenhæng mellem det nu foreliggende og de fire M er samt agenter og roller. Vi kan f.eks. ikke forestille os produktionsplanlægningsog produktionsløsninger (f.eks. tilbudsberegninger) eller programmerings- og driftsløsninger eller rumklassifikation, som ikke inddrager disse elementer.

89 188 Henrik Bang, Bygherr eforenin gen CCS og Forvaltningsklassifikation (FK) Bygherreforeningen finder det meget positivt, at det på høringsmødet blev bekendtgjort, at der bliver gennemført en mapping mellem CCS og Forvaltnings-klassifikation. Vi vil foreslå, at det i den forbindelse overvejes, hvordan det kan sikres, at FK bliver et ægte subsæt af CCS - eller omvendt, at CCS bliver et supersæt for FK. M.h.t. mapningen til FK henvises til svaret på kommentar nummer 67. Hvad angår muligheden for at lade FK være et subset til CCS vil muligheden for dette bero på en nærmere analyse af systemernes kompatibilitet som vil kunne gennemføres når cunecos arbejde med klassifikationstabellerne er mere fremskredet.

90 189 Henrik Bang, Bygherr eforenin gen CCS i forhold til ekspertvurderingens anbefalinger Bygherreforeningen savner en nærmere redegørelse for det foreliggende forslags forhold til Anders Ekholms og Lars Häggströms ekspertvurderinger (den oprindelige udtalelse og sammenfatningen af januar 2011) og de mange høringssvar, som fremkom i forbindelse med Symposiet i oktober M.h.t. relationen til Anders Ekholms vurdering af DBK henvises til svaret på høringskommentar nr. 44. Derudover opfatter cuneco nærværende høring inkl. høringskommentarer som et validt grundlag for det videre arbejde. Vi vil foreslå, at der udarbejdes et kort notat herom til støtte for prioriteringen af indsatsen af det videre arbejde.

91 190 Henrik Bang, Bygherr eforenin gen Hvor skaber klassifikationstabeller værdi? Vi finder at med det foreliggende høringsforslag, er der åbnet for en frugtbar diskussion om formålet med at klassificere rum og bygningsdele, men at der stadig savnes en bredere anlagt beskrivelse af formålet med klassifikation set i lyset af det paradigmeskift som byggeriets samarbejde, metoder og værktøjer undergår i disse år. Dette især på IKTområdet, hvor den successive konkretisering under projekteringen og udførelsen i stigende grad bliver understøttet af værktøjer, som håndterer stadig rigere egenskabsdatasæt gennem processen. Der bør tages stilling til, hvordan klassifikation og modellering samvirker i vore dages projektering og med vore dages avancerede, objektorienterede applikationer og modelleringsværktøjer, samt hvor (i hvilke domæner og funktioner) der kan skabes værdi ved at støtte funktioner og arbejdsprocesser med klassifikationstabeller. Område har været fokus for cunecos behovsanalyse, hvor der er beskrevet en række scenarier, hvor klassifikation i samspil med egenskabsdata og informationsniveauer skaber værdi i forbindelse med konkrete projekter. cuneco finder det ikke formålstjenstligt, at forsøge at beskrive værdiskabelsen af klassifikation isoleret set, da værdiskabelsen er knyttet til en proces, der indehoder mange elementer. Klassifikationstabeller må jo nødvendigvis udvikles inden for rammerne af et specificeret domæne og mhp. at understøtte bestemte formål og/eller funktioner. Vi savner følgelig en nærmere beskrivelse af: Hvor kan der skabes værdi (mest værdi) ved at udvikle klassifikationstabeller - inden for hvilke domæner, funktioner og delfunktioner?; Hvem skal bruge tabellerne - og til hvad?; Hvordan kan tabellerne konkret støtte arbejdsprocesser og modellering?; Hvordan kan tabellerne skabe værdi (direkte, indirekte og afledt) i mange forskellige domæner og funktioner? Den foreliggende behovsanalyse har

92 191 Henrik Bang, Bygherr eforenin gen Bredde og involvering i arbejdet Bygherreforeningen er enig i, at det er vigtigt at arbejdet gennemføres med tilstrækkelig ekspertise inden for områderne klassifikation, udvikling af ID-systemer, informationshåndtering samt anvendelse af egenskabsdata i modellering. For at opnå det bedst mulige resultat er det nødvendigt, at projektet-gruppen i tilstrækkelig grad er bemandet med klassifikationsekspertise og involverer personer med praktisk erfaring og viden om modellering og om praktisk anvendelse af egenskabsdata i forskellige design-, produktions- og driftsprocesser. Man kunne med fordel have involveret den kreds af kritikere, som deltog aktivt og konstruktivt i symposiet i Vi vil foreslå, at man i det videre arbejde involverer folk i projektarbejdet med ovennævnte kvalifikationer, og at man finder en arbejdsform, som involverer folk med praktisk erfaring med modellering mv. - herunder fra BVU-Net og fra kredsen af kritikere af DBK. Sammensætningen af cunecos projektgrupper foretages af cunecos styregruppe, der omfatter repræsentanter fra en række af de forskellige parter i branchen - og også repræsentanter for de organisationer, som de personer med de nævnte kvalifikationer, er tilknyttet. Styregruppen bestræber sig på at alle synspunkter bliver inddraget i arbejdet.

93 192 Henrik Bang, Bygherr eforenin gen Internationalisering og standarder Bygherreforeningen finder det overordentlig vigtigt, at den indsats som vi i Danmark gør på klassifikationsområdet forholder sig bevidst til, og lægger sig så tæt op ad internationale standarder vedr. klassifikation, ID-systemer, egenskabsdatastrategier og informationshåndtering som muligt, og at vi gør det i overens-stemmelse med den internationale udvikling på modelleringsområdet og i BuildingSmart miljøet. Vi er derfor bekymrede over, at det foreliggende forslag alene forholder sig til - og er baseret på - en standard, hvis primære emne er informationshåndtering gennem anvendelse af en referencesystematik på det elektriske og mekaniske område, og kun i ringe grad omhandler klassifikation i byggeriet generelt, og som ikke forholder sig til emner som modelleringspraksis i byggebranchen og håndtering af byggeriets successive konkretisering i modelbaserede værktøjer via egenskabsdata. Vi ser det sådan, at kun en ud af tre forskellige muligheder dvs. kun et enkelt bud ud af tre mulige på udfordringen er blevet undersøgt. Vi vil følgelig foreslå, at man - inden man går videre i arbejdet - gennemfører grundige vurderinger af IFC-konceptet/IFC-standarden og af ISO , og undersøger disse standarders muligheder for at understøtte byggeriets informations- og datahåndtering inden for forskellige domæner og funktioner. Vi savner en mere udfoldet dokumentation af inden for hvilke andre områder denne mekanik kan være relevant at benytte. Umiddelbart vil vi pege på to områder, hvor metodikken ville kunne finde anvendelse, men der kan ved en nærmere undersøgelse sikkert identificeres flere, bl.a. på FM-området. Vi peger på tilbudsgivnings-processen hos entreprenører, hvor der allerede er foretaget eksperimenter, som det kunne være gavnligt for resten af branchen at høre nærmere om samt udviklingen af metoder til at sammenknytte bips beskrivelser til bygnings- og procesobjekter under modelleringsprocesser - netop den type af behov, som EN er udviklet til at dække. Vi er således ikke bekendt med, at andre fremherskende, internationale klassifikationssystemer i byggeriet benytter den foreslåede metodik og syntax. Vi føler os ikke overbevist om, at det foreliggende forslag er I den palette af internationale standarder, som cuneco baserer sit arbejde på, har de buildingsmartrelaterede standarder en meget central rolle. Derudover har buildingsmartrelaterede projekter været nævnt som grundlag for samtlige de cunecoprojekter, der indtil nu er startet op. Endelig har cuneco indgået aftale om, at projektchefen for cuneco indtræder i bips buildingsmart-udvalg samt den nordiske bestyrelse for buildingsmart for yderligere at sikre denne koordinering.

94 193 Henrik Bang, Bygherr eforenin gen Aspekt, View og Egenskaber Overalt hvor der arbejdes med objektorienterede og strukturerede data i databasebaserede værktøjer benyttes views som en udbredt metode til at filtrere og analysere data mhp. at understøtte en eller flere specifikke funktioner. Denne filtrering af data benyttes i det foreliggende forslag. Mekanismen foreslås anvendt som en generel metodik, der skal benyttes som styrende for klassifikation af bygningsdele og rum, og den vil danne grundlag for fastholdelse af aspekttankegangen og referencesystematikken fra DBK, som et generelt klassificerende element for hele CCS. Delvist Kodestrukturen har to primære formål: 1) At identificere objektforekomster både individuelt og ud fra den sammenhæng som de indgår i forhold til systemer og funktioner. 2) At tilknytte objektforekomsten til en objektklasse.. Det præciceres i rapporten, at kodestruktuern (views) ikke er styrende for klassifikationen, men at klassifikationen skal følge anvisningerne i ISO , hvilket der i øvrigt også er lagt op i det videre arbejde. Forslaget er derfor, at lave én simpel klassifikation (fx af bygningsdele), der kan anvendes uafhængigt, og på tværs i de forskellige aspekter. Vi finder det ikke overbevisende påvist, at det er hensigtsmæssigt generelt at indføre dette princip. På denne måde udpeges på forhånd - og helt generelt - simple ID er, funktion, struktur og placering som særligt vigtige views, hvis aftryk på klassifikations-tabellerne skal benyttes, hvis man ønsker en underopdeling af de foreslåede, grundlæggende hovedklasser. Dette synes umiddelbart at have følgende konsekvenser: - Klassifikation efter funktion indgår på to niveauer - dels som ren klassifikation (hvad det så end måtte være) med præfixet (%) dels i en mere Anvendelsen af aspekter (views) præciceres yderligere. Anvendelse af objektetforekomsten i konkrete sammenhænge i forbindelse med byggeriets processer vil blive foretaget med udgangspunkt i disse to formål kombineret med en struktureret anvendelse af egenskabsdata for objektforekomsten. Det er cunecos opfattelse at de fremlagte kodeprincipper opfylder de to nævnte formål.

95 194 Henrik Bang, Bygherr eforenin gen Praktisk udvikling og afprøvning af klassifikation og ID-systemer for RUM I Bygherreforeningens medlemskreds er der gennem længere tid arbejdet på at identificere behovene for klassifikation af rum. Arbejdet er ikke afsluttet, men der foreligger på en række områder bud på behovene for klassifikation af rum, lige som en gruppe bestående af erfarne virksomheder for tiden arbejder på at finde en praktisk løsning på dette område. Samtidig ser vi en række udfordringer i den foreslåede skitse til klassifikation af rum. Vi vil foreslå, at der som første fase i en kombineret udvikling og afprøvning af behov og udformning af klassifikationstabeller på området rumklassifikation gennemføres et hurtigt workshopforløb med delta-gelse af fagfolk, som har praktiske erfaringer inden for området suppleret med folk med viden om klassifikation. Workshopforløbet skal fokusere på brugsrummet og kunne i grove træk struktureres på følgende måde: - Præsentation for hinanden af eksisterende behovsformuleringer og tabelværker - herunder præsenteres rumklassifikationssystemer og tabeller fra kendte nordiske forslag samt Omniclass mfl. - Oplistning af basale klassifikationsparametre/kriterier baseret på erfaringer og på egenskabsdatasystematikker kendt fra f.eks. Drufus og NS og FM-systemer. - Identifikation af brugerbehov i forhold til områderne ydeevne, ejerskab, institutionstype, anvendelse, beliggenhed, omkostninger etc. og eksempler på ID- og rumnummereringssystemer set i hele rummets levetid (i alle domæner). - Fastlæggelse af klassifikationstabeller og klassifikationsparametre for hver tabeltype. - Beskrivelse af evt. sammenhænge og principper for syntaks, herunder sammenstilling med CCS. cuneco har noteret forslaget. I forbindelse med cunecos igangværende projekt vedr. klassifikation af bebyggelser, bygninger og rum, er der allerede gennemført en workshop efter disse retningslinjer, men cuneco er indstillede på at kigge denne proces efter i sømmene en ekstra gang for at sikre, at alle perspektiver er dækket af.

96 195 Henrik Bang, Bygherr eforenin gen Praktisk udvikling og afprøvning af klassifikation, ID-systemer og egenskabsdata- og informationshåndtering for andre, udvalgte domæner og funktioner På samme måde som ovenfor beskrevet vedr. rum, vil vi foreslå at der tilsvarende gennemføres afprøvning/alternativ udvikling på en række andre områder, hvor man vedr. bygningsdele har en begrundet formodning om, at der ville kunne skabes værdi ved implementering af en simplere model end den foreslåede, og hvor man samtidig kan afprøve, hvilke udfordringer det vil give at gennemføre en fuld udskillelse af referencesystematikken fra klassifikationen. Man kunne her fokusere på overgangen mellem projekt og produktionsplanlægning (incl tilbudsprocessen) samt belyse mulighederne for at støtte modellerings-processen med anvendelse af bips beskrivelser. De nævnte elementer er taget med i cunecos beskrivelse af strategien for afprøvningsområdet, som netop har til formål at beskrive alle de perspektiver, der skal afdækkes i forbindelse med afprøvningen.

97 196 Henrik Bang, Bygherr eforenin gen 197 Henrik Bang, Bygherr eforenin gen Trykprøvning af CCS ved udenlandske eksperter Bygherreforeningen vil foreslå, at der - når de foreslåede aktiviteter er færdige, og der foreligger en revideret version - gennemføres en yderligere trykprøvning af CCS i form af et review af forslaget gennemført af kompetente eksperter fra udlandet, som har viden og erfaringer inden for alle tre hovedemner samt repræsentanter fra BuildingSmart med kendskab til IFC, IFD og IDM. Ekspertgruppen bør endvidere omfatte personer med et særligt kendskab til klassifikation af egenskabsdatatyper, som kan medvirke til at vurdere den foreslåede løsnings evne til at understøtte specifikationsfunktioner for objektegenskaber i tidssvarende modelleringsværktøjer. BVU-net kan evt. bidrage med at identificere sådanne personer. Fra tal til bogstaver Bygherreforeningen finder det positivt at inddrage bogstaver i kodningen af objekt-typerne.

98 198 Henrik Bang, Bygherr eforenin gen Den stabile kode Bygherreforeningen kan tilslutte sig tanken om "den stabile kode" som går gennem alle snitflader og transformationer fra vugge til grav og som kan ses som bærer af et minimums egenskabsdatasæt. Men det er efter vores mening nødvendigt at gå dybere i undersøgelsen af, om det er muligt i praksis at realisere - og i givet fald hvor og hvordan. Der er to grunde til det: - Byggeriets virkelighed. Den samlede proces er karrakteriseret ved successiv konkreti-sering og den medfører netop et behov for at man kan ændre i objekterne og dermed i klassifikationskoden undervejs i processen efterhånden som objekterne samles, opdeles eller beriges med yderligere egenskaber. Det er et generelt vilkår i byggeriet, som man må respektere, og som klassifikationskonceptet skal kunne håndtere. - Værktøjernes forskellighed. Om - og især hvordan - man i praksis kan holde styr på sine objekter på deres vej i byggeriets samlede flow - og ind og ud af manuelle og automatiserede processer og objekt-orienterede værktøjer - er i høj grad et dataudvekslings- og et formatproblem. En nærmere belysning af vilkårene for dette flow må gennemføres før man kan se, om der er én mulig løsning, der kan holde fra vugge til grav, om der evt. er flere fælles for eet eller flere domæner, og om man evt. kan definere en standardbeskrivelse af minimumsobjektet, som holder hele vejen igennem. Findes der entydige cuneco er enige i, at princippet om 'den stabile kode' ikke er noget man kan vedtage uden at sikre sig, at det kan implementeres i den virkelige verden. På den baggrund vil dette princip have meget stor fokus i forbindelse med udarbejdelsen af scenarier og gennemførelsen af afprøvningsprojekterne.

99 199 Henrik Bang, Bygherr eforenin gen 200 Henrik Bang, Bygherr eforenin gen Teknisk Fag og Arbejder Der efterlyses konkret forslag til to ekstra facetter for håndtering af hhv. fag og arbejder til støtte for byg- og driftsherrens håndtering af bygningsdele i forbindelse med beskrivelser og gennemførelse af udbud samt tilbudsvurdering. Simple ID er, GUID og ID- Nummererings-systemer Der findes to typer af ID er: - Simple maskingenererede ID er etableret i/af IKT-værktøjerne i forbindelse med oprettelsen af objekter i systemer - GUID. - ID er der repræsenterer et funktionelt defineret view på objekterne etableret gennem deres egenskabsdata (eks. historien om dørnummerering) og som skal bruges til et bestemt formål. Vi foreslår, at det beskrives, hvordan informationshåndteringen kan understøttes af IKT-værktøjernes maskingenerede kode. Vi foreslår endvidere, at der igangsættes et arbejde med at identificere og beskrive forskellige IDsystemer ud fra deres domænetilhør og specifikke formål, samt udarbejde forslag til fælles principper for udarbejdelse/implementering af sådanne systemer - med eksempler, guidelines for implementering mv. Fag og arbejde er ikke en del af resultatdomænet i ISO , som kodeprojektet omfatter. Der er ingen kobling mellem CCS og de maskingenerede koder. De maskingenerede koder anses for ustabile (da de er afhængige af den IT platform de er udarbejdet på, og endvidere kan ændre sig for samme objekt, fx ved at en "væg" slettes i en model, og genindsættes på ny). Maskingenerede koder er endvidere uegnet til menneskelig genkendelse. De foreslåede nye projekter medtages i puljen af mulige opgaver.

100 201 Henrik Bang, Bygherr eforenin gen Teknisk Den foreslåede syntax og samspil med andre værktøjer som fx Excel Det nævnes flere steder i forslaget, at koder skal kunne håndteres manuelt, og let skal kunne indlæses i enkle værktøjer som fx Excel - for gennemførelse af sortering, optælling og analyser mv. Den foreslåede syntax udviser udfordringer på to områder i denne forbindelse: - Programmer som Excel (som er det eneste vi har forsøgt os i) opfatter umiddelbart en CCS-streng som en blanding af celle-referencer og funktioner/operatorer, og vil ikke uden en for- eller efterbehandling af strengen kunne bruge den meningsfyldt. - Dette kræver udvikling af specialiserede udlæsnings- og indlæsningsværktøjer evt. baseret på xml (xml-convertere), som dels kan generere en generelt forståelig eller specifik maskinlæsbar kode, som kan indlæses automatisk i relevante systemer, og som - hvor det måtte være relevant - samtidig fra det modtagende system kan tilbagelevere en CCS-streng med de nød-vendige koder i den nødvendige syntax. Dette er ikke noget den gennemsnitlige Excel bruger kan lave efter behov. Hvordan problemet skal løses ligger ikke lige for, men for at lette en manuel eller halv-automatisk overførsel kunne man overveje at indføre en fast rækkefølge af facetter og faste opdelinger af den enkelte facet evt. suppleret med tab eller mellemrum som skilletegn. Dette vil så til gengæld formentlig gå ud over brugervenligheden og ønsket om en kort kodestreng. Delvist Kodestrengen kan dekodes i den form den er nu, og skal ikke være i et fast format. Kodestrengen kan deles op i de forskellige aspektkoder. Se svar til kommentar 131. Teknisk note: Når fx Excel regner på kodestrengen, er det fordi cellen i regnearket skal formateres anderledes. Kodestrengen kan desuden håndteres med standard funktionaliteten i Excel. Håndteringen af kodeprincipper i Excel belyses nærmere.

101 202 Henrik Bang, Bygherr eforenin gen Fokus i det videre arbejde Bygherreforeningen er helt enig i, at det er nødvendigt at gennemføre en hård prioritering i det videre arbejde for at sikre, at man kommer til vejs ende med en klassifikation der skaber værdi på udvalgte områder. Vi vil derfor foreslå, at arbejdet fremover fokuseres på at opnå nyttige og værdi-skabende resultater på de områder, hvor COWI-rapporten (og mange andre udsagn) har peget på, at værdiskabelsen ved udviklingen af støtteværktøjer til den videre udvikling på IKT-området skønnes at ville have størst effekt i branchen. Disse tre områder er alle blevet fremhævet i cunecos behosvanalyse og cuneco har enten oprettet eller er i færd med at definere projekter, der har fokus på disse områder. Vi vil i den forbindelse pege på især tre områder, hvor indsatsen skønnes at ville skabe mest værdi. Det drejer især sig om følgende tre områder: - Grænsefladen mellem projekteringsdomænet og produktionsdomænet med et særligt fokus på grænsefladen mellem projekt og udførelse - inkl. tilbudsberegning og produktionsplanlægning. - Grænsefladen mellem driftsdomænet og de tidlige funktioner i projekteringsdomænet med et særligt fokus på grænsefladen mellem driftserfaringer, programmering og konceptuelt design. - Grænsefladerne mellem produktionen og driftsdomænet med et særligt fokus på den løbende overdragelse af data mhp. dokumentation af produkt og proces samt overdragelse af data til drift.

102 203 Kaj A. Jørgense n En af Cunecos projektgrupper vedrørende klassifikation har nu udsendt et første rapport-udkast og indbudt til høring. Der vil tilsyneladende ske to væsentlige ændringer som hilses velkommen: 1) 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. 2) 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 Fremgår indirekte af kommentaren. Det pointeres at et af formålene med CCS bl.a. er entydig identifikation af objekter uafhængigt af IT-platforme. CCS skal desuden kunne anvendes både digitalt og analogt (dvs. egnet til menneskelig genkendelse), hvilket har været en forudsætning for projektgruppens arbejde. kommentar til Fremgår indirekte af kommentaren. Det er teknisk svært at udlede en konstruktiv kommentar af de betragtninger der fremføres, da det rummer risiko for misfortolkning.

103 204 Kaj A. Jørgense n Teknisk 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 Fremgår indirekte af kommentaren. 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 1). 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. Delvist CCS er ikke kun begrænset til dataobjekter. Tekst vedrørende modeller "i den virkelige verden" præciseres i rapporten. kommentar til Fremgår indirekte af kommentaren. Det er teknisk svært at udlede en konstruktiv kommentar af de betragtninger der fremføres, da det rummer risiko for misfortolkning.

104 205 Kaj A. Jørgense n Teknisk 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 1). 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 applika-tioner som regel systemgenereret (se ID attributten i figur 1). Men mere bruger-venlige ID er eller navne kan sagtens tilføjes, hvis det er hensigtsmæssigt (se Name attributten i figur 1). En navngivning skal i sagens natur være brugerrettet og Fremgår indirekte af kommentaren. 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. Ikke Det pointeres at et af formålene med CCS bl.a. er entydig identifikation af objekter uafhængigt af IT-platforme. I henhold til gældende internationale standarder, er de CCS kodeprincipper der er foreslået defineret som entydig identifikation af et objekt. CCS er designet til at kunne fungere uden datamodeller til rådighed, men i samspil med disse. kommentar til Fremgår indirekte af kommentaren. Det er teknisk svært at udlede en konstruktiv kommentar af de betragtninger der fremføres, da det rummer risiko for misfortolkning.

105 206 Kaj A. Jørgense n 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 Fremgår indirekte af kommentaren. kommentar til Fremgår indirekte af kommentaren. Det er teknisk svært at udlede en konstruktiv kommentar af de betragtninger der fremføres, da det rummer risiko for misfortolkning.

106 207 Kaj A. Jørgense n Teknisk 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ærkelsesvæ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. Aspekt-begrebet 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 udgangspunkt i bygningsmodeller, 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. Fremgår indirekte af kommentaren. kommentar til Fremgår indirekte af kommentaren. Det er teknisk svært at udlede en konstruktiv kommentar af de betragtninger der fremføres, da det rummer risiko for misfortolkning. Teknisk kommentar til Aspektbegrebet har mest karakter af at være en akademisk foreteelse, som ikke har nogen særlig praktisk betydning. cuneco mener, at der her er tale om en misforståelse af konceptet, og er ikke enige i, at det er en akademisk forteelse, men at den tværtimod har en særdeles praktisk betydning. Teknisk kommentar til 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. cuneco er ikke enige i, at dette er tilfældet i praksis. Teknisk kommentar til 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.. Det fremlagte forslag til kodeprincipper i CCS giver mulighed for dette.

107 208 Kaj A. Jørgense n 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. Fremgår indirekte af kommentaren. Der er ikke krav om, at standarder skal opbygges på et videnskabeligt grundlag. Til gengæld er der andre mekanismer der bevirker, at standarder anvendes, hvilket bl.a. er valgt i CCS. cuneco er enige i, at anvendelsen af enhver standard skal ses i sammenhæng med en vurdering af kvaliteten af den pågældende standard i sammenhæng med egnetheden i forhold til den opgave, der skal løses.

108 209 Kaj A. Jørgense n Teknisk Under gennemgangen af aspektbegrebet 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 Fremgår indirekte af kommentaren. Delvist kommentar til Fremgår indirekte af kommentaren. Det er teknisk svært at udlede en konstruktiv kommentar af de betragtninger der fremføres, da det rummer risiko for misfortolkning. Det tydeliggøres i rapporten hvordan klassifikationen virker i de aspekter hvor den anvendes, og hvordan den kan anvendes separat. Det overvejes evt. at ændre betegnelsen klassifikationsaspekt.

109 210 Kaj A. Jørgense n 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 attributter/egenskaber og dels ved underopdeling 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/aktiviteter, monteringsinstrukser og vedligeholdelsesanvisninger. En klassifikationstabel over bygningsdelstyper giver altså grundlag for inddragelse af data udefra (branchedata) til projekterne. Dette betyder omvendt, at dette behov giver Fremgår indirekte af kommentaren. kommentar til Fremgår indirekte af kommentaren. Det er teknisk svært at udlede en konstruktiv kommentar af de betragtninger der fremføres, da det rummer risiko for misfortolkning.

110 211 Kaj A. Jørgense n 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. t 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. Teknisk kommentar til Dataobjekter til repræsentation af bygningsdele vil som oftest blive født ud fra deres former. cuneco er ikke enige i betragtningen, da det kun omfatter enkelte bygningsdele og ikke kan anvendes som en generel metodik (gælder fx ikke ventiler, rør, kabler, sikringer mv.