CCS kodningsregler. Kodningsregler for klassifikation og identifikation af objekter

Transkript

1 3. december 2012 CCS kodningsregler Kodningsregler for klassifikation og identifikation af objekter cuneco projektnummer: Afklaring af kode og struktur for bygningsdele FORELØBIG UDGAVE TIL OFFENTLIG HØRING 2. UDGAVE

2 cuneco.dk center for produktivitet i byggeriet CCS kodningsregler Redaktion Henrik Balslev, Balslev & Jacobsen ApS Allan Dam Jepsen, CPC - Center for Product Customization ApS Nicolai Karved, Betech Data A/S Søren Spile, cuneco cuneco en del af bips bips Lautrupvang 1 B 2750 Ballerup Telefon Fax bips@bips.dk Grafisk tilrettelæggelse Fænø Design 2

3 1 Resumé Forudsætninger og nuværende resultat. Denne rapport beskriver forudsætningerne, forløbet og resultatet med cuneco projektet Kodningsprincipper for klassifikation og identifikation. Kodeprincipperne afløser det eksisterende DBK og bliver samtidig omdøbt til CCS (cuneco classification system). CCS er et nationalt system der kan anvendes til klassifikation og identifikation af bygningsdele og rum, samt til at beskrive relationerne mellem bygningsdele og rum. Første udgave af denne rapport er fra 5. marts 2012 og den dannede grundlag for den offentlige høring. cuneco modtog i alt 211 kommentarer til rapporten, hvoraf nogle var direkte rettet mod det samlede cuneco arbejde, mens andre var rettet mod kodeprincipperne, som denne rapport omhandler. Denne 2. udgave af rapporten har indarbejdet de relevante kommentarer fra høringen samt opdateret indholdet med hensyn til den fremdrift der er sket i de øvrige cuneco projekter. Udgangspunktet for CCS er ISO (2001) standarden: Framework for classification of information. Standarden er p.t. under revision hvilket bl.a. cuneco bidrager til. Hertil kommer en række andre ISO/IEC standarder der er anvendt efter relevans og behov. CCS anvender en kombination af præfiks (specialtegn), klassifikationskoder (bogstaver) og tal (løbenumre) til at skabe forskellige typer af identificerende koder, der umiddelbart kan tolkes af mennesker, og endvidere kan understøttes af forskellige IT systemer til at bære information mellem disse. Denne rapport beskriver reglerne for kodemekanismerne, samt krav til klassifikationsdelen af koden, der udvikles en andre projektgrupper. I Bilag C Oversigt over supplerende aspektkoder findes en oversigt over de samlede kodeprincipper i CCS. Det anbefales at have disse oversigter ved siden af rapporten for at opnå en hurtigere fortrolighed med principperne. 3

4 2 Indholdsfortegnelse 1 Resumé Indholdsfortegnelse Introduktion Projektgrundlag Projektforløb Formål Objekter og aspekter Bygningsdele og brugsrum Typer, forekomster og individer Strukturelle aspekter og views Kravspecifikation Minimumskrav Uddybet kravspecifikation Grundlæggende kodningsregler Klassifikation og identifikation i CCS Klassifikation Generelt Kort om stabilitetsprincippet Regler for klassifikationsbogstaver Anbefalinger til klassifikationstabeller Identifikation Strukturelle aspekter Regler for identifikations løbenumre Strukturelle aspektkoder Syntaks for Gruppe 1 aspektkoder

5 8.1.1 [%] Typeaspekt for bygningsdele [#] Produktaspekt for bygningsdele [-] Sammensat produktaspekt for bygningsdele [+] Placeringsaspekt for bygningsdele [=] Funktionsaspekt for bygningsdele Syntaks for Gruppe 2 aspektkoder [%%] Typeaspekt for brugsrum [##] Produktaspekt for brugsrum [--] Sammensat produktaspekt for brugsrum [++] Placeringsaspekt for brugsrum [==] Funktionsaspekt for brugsrum Syntaks for Gruppe 3 aspektkoder Supplerende strukturel aspektkoder Eksempler for anvendelse % Typeaspekt for bygningsdele # Produktaspekt for bygningsdele Sammensat produktaspekt for bygningsdele Placeringsaspekt for bygningsdele = Funktionsaspekt for bygningsdele %% Typeaspekt for brugsrum ## Produktaspekt for brugsrum Sammensat produktaspekt for brugsrum Placeringsaspekt for brugsrum == Funktionsaspekt for brugsrum Kodning igennem livscyklus for en bygningsdel Kodning igennem livscyklus for et brugsrum IT implementering Tidlig afklaring af It-egnethed Forløbet

6 10.3 Konklusion på introduktionsmøde Eksempler på CCS i EBNF-format Relation til andre standarder ISO (2001 / 2013) ISO/IEC (2009) DIN (2010) ISO 4157 (1999) SFB (1950+) DBK (2006) Forvaltnings Klassifikation (2009) IFC/IFD OmniClass, BSAB, Uniformat m.fl Sammenfatning Bilag A - Termer og definitioner Bilag B Oversigt over aspektkoder Bilag C Oversigt over supplerende aspektkoder Bilag D Eksempler for kodning af bygningsdele Bilag E Eksempler for kodning af brugsrum Bilag F - Kommentarer til behovsanalysens foreløbige hovedkonklusioner Bilag G Forudsætningsnotat Bilag H Udvidet kravspecifikation Klassifikationskrav Identifikationskrav Normative krav Anvendelseskrav Implementeringskrav Bilag I Spørgeskema til IT-leverandørgruppen i bips

7 3 Introduktion Denne rapport i 2. udgave beskriver resultatet af Cuneco projekt Afklaring af struktur og kode for bygningsdele. Projektet har til formål at udarbejde et klart og entydigt grundlag for en revideret version af struktur og kodesyntaks for bygningsdele og brugsrum i Dansk Bygge Klassifikation (DBK). Den reviderede version vil herefter kendes under navnet cuneco classification system (CCS). Resultatet af projektet er en beskrivelse af en struktur for kodning af typer og forekomster af bygningsdele og brugsrum i resultatdomænet. Projektet har fokus på afhjælpning af de problemstillinger og mangler, der er blevet påpeget siden DBK blev frigivet i 2006 og skal skabe grundlag for det efterfølgende arbejde i cuneco, der omfatter frembringelse af reviderede klassifikationstabeller. Projektet er udført af en arbejdsgruppe nedsat af Cuneco, som består af: Søren Spile, cuneco (projektleder) Henrik Balslev, Balslev & Jacobsen ApS Nicolai Karved, Betech Data A/S Allan Dam Jepsen, CPC - Center for Product Customization ApS Ulf Harlou, CPC - Center for Product Customization ApS Rapporten beskriver regler for, hvorledes CCS koder skal udarbejdes, samt retningslinier og krav for det efterfølgende klassifikationsarbejde. Rapporten beskriver hvorledes klassifikation anvendes i kodningen, men omhandler ikke det specifikke klassifikationsarbejde, dvs. udarbejdelse af de klassifikationstabeller der skal udarbejdes på baggrund af denne rapport i projekterne Klassifikation af bygningsdele og Klassifikation af bygværker og rum. Eksemplerne i rapporten der bruges til illustration af kodningsreglerne benytter derfor en foreløbig klassifikation, baseret på de foreløbige resultater fra projekterne og (december 2012) for at illustrere sammenhængen mellem klassifikationen og kodningsreglerne. Ændringer i klassifikationskoder vil forekomme på baggrund af granskning og den offentlige høring

8 3.1 Projektgrundlag De detaljerede forudsætningerne for gruppens arbejde, herunder de grundlæggende tekniske krav som nye kodningsprincipper skal opfylde, er nærmere beskrevet i: Projektbeskrivelse: Afklaring af struktur og kode for bygningsdele. 9. udgave dateret Beskrivelse af aktivitet 2 - forudsætning for opgaveløsning. Version Følgende materiale danner grundlag for projektet jf. Projektbeskrivelsens pkt. 6: DBK 2006 ISO Ekholm-rapporten, 2011 DIKON-rapporten, 2010 Notat om DBK i forbindelse med IT-systemer, bips Notat om DBK i BIM software, Betech Data A/S, 2009 DBK Kodningsprincipper, Balslev & Jacobsen Aps, 2010 Forvaltnings Klassifikation, Landsbyggefonden og KL, August 2009 IFD, IFC (ISO/PAS IFC 2x platform) ISO/IEC og Hertil er under projektets forløb tilføjet: Udviklingsplan for Dansk Bygge Klassifikation Behovsanalyse hvad er byggebranchens behov for standarder for udveksling af digital information? (Foreløbige hovedkonklusioner) (se bilag Bilag F - Kommentarer til behovsanalysens foreløbige hovedkonklusioner) Høringskommentarer fra offentlig høring (cuneco_hoeringssvar_ccs_kodestruktur.pdf) 3.2 Projektforløb Projektgruppen har gennemført projektet ved gennemløb af korte udviklingscyklus med løbende review og feedback af foreslåede løsninger fra cuneco s styregruppe samt den gennemførte offentlige høring i Hovedforløbet for projektet mht. udformning af den tekniske løsning har været følgende rækkefølge: 1. Afklaring af forudsætninger og grundlag for opgavens løsning a. Studie af DBK2006 samt supplerende baggrundsmateriale (se afsnit 3.1) b. Afdækning af relationer til IFC og IFD, samt cuneco projektet vedr. egenskabsdata 8

9 2. Indsamling af basisinput til projektarbejdet med deltagelse af udvalgte eksperter (Anders Ekholm & Eirik Selvik) med afsæt i de vedtagne forudsætninger for opgaven. 3. Udformning af syntaks og struktur for ny kodeteknik med fokus på nedenstående områder: a. Studie af nødvendige / lovgivningsmæssige / direktivmæssige kodningsbehov b. Studie af kodens udvikling over tid (projektforløb) c. Studie af informationsniveauer og deres indvirkning på koden d. Løbende tests af IT-egnetheden e. CCS kode og relation/samspil med IFC og IFD. f. Håndtering af ny kode ved udveksling i IT-systemer g. Mapning til eksisterende DBK koder h. Mapning til danske og internationale standarder i. Udarbejdelse af grafiske eksempler 4. Intern høringsworkshop i Cuneco d Revision af syntaks og struktur for ny kodeteknik samt udarbejdelse af inddelingskriterier for bygningsdele og rum. 6. Offentlig høring d med efterfølgende indsamling af kommentarer. 7. Revision af struktur for ny kodeteknik samt forslag til inddelingskriterier for bygningsdele og brugsrum baseret på høringssvar 8. Udarbejdelse af rapport i 2. udgave, med indarbejdede høringssvar m.v. Undervejs i projektet er afholdt koordinerende workshops og møder med cuneco s styregruppe, projektgruppen for Cuneco projekt Afklaring af struktur og metode for egenskabsdata, og interessenter fra ITleverandør branchen (se afsnit 10). 9

10 4 Formål Formålet med CCS kodningstandarden er at levere en grundlæggende informationsstruktur, der sikrer en entydig og ensartet forståelse for information i branchen og som understøtter udveksling af disse informationer mellem parterne. Arbejdet med udarbejdelse af en standard for kodning af byggeriets objekter udspringer af branchens behov og ønsker i forhold til en bedre og ensartet forståelse og udveksling af de mange forskellige typer information, der indgår i et bygværks samlede livscyklus. Helt grundlæggende baseres arbejdet med CCS på ISO , der er en overordnet rammestandard for klassifikation af information i byggeriet. ISO er pt. (år 2012) under revision, og cuneco deltager aktivt i revisionsarbejdet. Et første udkast (Committee Draft) af den nye udgave kan forventes primo Se afsnit ISO indeholder ikke specifikke tabeller for bygningsdele, men kun anbefalinger om principperne for udarbejdelse af disse tabeller, fx at en tabel over bygningsdele kan baseres på funktion. ISO indeholder ikke regler eller retningslinjer for udarbejdelse af koder af klasser eller identifikation, da dette er uden for emneområdet for standarden. Såfremt andre lande har fulgt anbefalingerne i ISO , i lighed med CCS, vil klassifikationen fra CCS derfor kunne mappes til andre systemer, fx via IFD. Se afsnit CCS har, i modsætning til andre lande, bevidst lagt et stabilitetsprincip til grund for udarbejdelse af identificerende koder og koder for klassifikation. Dvs. at det er et krav i CCS, at koder og klasser skal være så stabile som overhovedet muligt, således de ikke ændrer sig set over den samlede livscyklus, for derved at gøre CCS stabil, nem og brugervenlig. Hermes sikres også sporbarheden af de forskellige bygningsdele og rum igennem livscyklus. For at sikre en entydig udveksling og genbrug af data gennem alle byggeriets processer fra idéfase og projektering over udførelse til drift og vedligehold, er det nødvendigt at identificere bygningsdele og brugsrum entydigt, så de er nemme at genfinde og genkende for alle parter på tværs af platforme. Reglerne for identifikation af bygningsdele og brugsrum er i CCS udformet således, at de dels kan genkendes og bruges manuelt / analogt, dvs. af mennesker uden support fra et IT system, og dels så de kan bruges automatisk / digitalt, dvs. anvendes i forskellige IT systemer. Dette sker i er- 10

11 kendelse af, at meget arbejde med information fortsat håndteres manuelt i projekterne, og at den stigende anvendelse af fx BIM fortsat vil tage tid at implementere, inden det bliver allemandseje. Samtidigt er det et krav at enhver kode også skal kunne håndteres i IT systemer (2D, 3D, diagrammering, beregninger, beskrivelser etc.) hvilket kan understøttes mere eller mindre automatisk. Der er lagt vægt på en menneskelig genkendelse af såvel betydning af kode samt den tilhørende klassifikation. Dog undgås mnemotekniske (mundrette) forkortelser helt, da disse ikke kan anvendes i internationalt regi. CCS er udviklet som et meget fleksibelt system, der har mange og forskellige anvendelsesmuligheder alt efter behov og alt efter kompleksitet. I praksis vil alle ikke skulle bruge alt fra CCS, men kun de udvalgte elementer der er relevante for deres behov. Anvendelsen af CCS koder vil kunne aftales fra projekt til projekt, og kan indgå som én af de aftaler der omfattes af en IDM manual (dvs. en aftale om informationsniveauer). CCS kodereglerne er udviklet til at kunne anvendes for alle parter (alle fag og interesser) igennem hele livscyklus for bygningsdele og brugsrum. 11

12 5 Objekter og aspekter 5.1 Bygningsdele og brugsrum CCS koder to typer af objekter i resultatdomænet af ISO : bygningsdele og brugsrum Denne rapport omhandler de CCS koder, der anvendes til kodning af to grundlæggende objekter: bygningsdele og brugsrum, der findes i resultatdomænet af ISO Objektet bygningsdel forefindes som: objekttype, objektforekomst og objektindivid. Objektet brugsrum forefindes som: objekttype, objektforekomst og objektindivid. Bygningsdele og brugsrum illustreres i denne rapport med følger definitioner og symboliseres ved de viste symboler. Bygningsdel: en afgrænset bestanddel af en bygning, som i sig selv eller i kombination med andre bygningsdele har en karakteristisk funktion i bygningen Brugsrum: rum defineret af det byggede miljø og som giver plads til brugeraktivitet eller udstyr Se endvidere definitioner i Bilag A - Termer og definitioner. 12

13 5.2 Typer, forekomster og individer CCS klassificerer objekttyper og identificerer objektforekomster. I samråd med projektgruppen der arbejder med objektegenskaber, er der defineret følgende adskillelse mellem de forskellige typer af objekter der håndteres med CCS: En objekttype er en klasse af objekter der har de samme karakteristiske egenskaber, dvs. at det er på baggrund af objekttyperne at klassen af fx bygningsdele oprettes. En objekttype bliver medlem af en CCS klasse, og tildeles kendebogstaver for klassen. En objektforekomst er anvendelsen af en bestemt objekttype inden for en specifik sammenhæng. Objektforekomsten er stabil og repræsenterer objektet af interesse, så længe objektet findes. En objektforekomst får tildelt en identificerende CCS kode, der identificerer objektforekomsten entydigt. Et objektindivid er et eksemplar af en objekttype uafhængigt af hvor den er benyttet. Det vil fx være det konkrete produkt som vælges til at instantiere objektforekomsten. Et objektindivid vil typisk have et serienummer, et ordrenummer eller tilsvarende, der identificerer hvert enkelt individ. Et objektindivid refererer altid til en objektforekomst. Et objektindivid kan udskiftes med et andet individ, uden at dette har indflydelse på objektforekomsten. Figur 1 - Objekt forekomst og objekt individer. Individerne passer til forekomsten. CCS klassificerer objekttyper og identificerer objektforekomster. Formålet med at skelne mellem de tre typer af objekter er dels at kunne håndtere information om objekterne (type - forekomst - individ) individuelt og dermed mere klart, dels at sikre en stabilitet i CCS koderne for bygningsdele og brugsrum. 13

14 Objektindivider kan udskiftes, mens objektforekomsterne som de passer til forbliver uændrede. Såfremt et objekt udgår, slettes objektforekomsten. Objektforekomsterne er stabile at klassificere og identificere i den samlede livscyklus for et objekt. Objektforekomster og objektindivider er illustreret i Figur 2. Forekomster Forekomster Inderdør Swedoor Selection Allegro Individer Inderdør Swedoor Selection Allegro GW11 Inderdør Swedoor Selection Allegro GW1 Kroneafbryder HVID Fuga Ean nr.: Individer Lysdæmper Dreje MEK-D 300CR HVID Fuga Ean nr.: Lysdæmper skyde MEK-S 300LR HVID Fuga Ean nr.: Figur 2 - Illustration af objekt forekomster og objekt individer 5.3 Strukturelle aspekter og views CCS anvender to forskellige måder at betragte objektforekomster på. I forbindelse med udvikling af CCS koder, har der tidligere i forløbet været anvendt begrebet aspekt, hvilket var defineret som en bestemt måde at se et objekt på. Termen aspekt er efterfølgende fundet for upræcis, da man kan se objekter på mange andre måder, end den måde den blev anvendt på. 14

15 Efterfølgende har arbejdet resulteret i, at der nu skelnes mellem aspekter der anvendes til at strukturere information (fx i del-af hierarkier) og andre måder at se objekter på. Aspekter til strukturering benævnes i CCS for strukturelle aspekter, mens andre måder at betragte objekter på benævnes views. Som input til CCS begrebskataloget foreslår denne rapport definitioner og anvendelse for hhv. views og strukturelle aspekter som anført i Bilag A - Termer og definitioner. Views behandles ikke yderligere i denne rapport. Bemærk, at en struktur i et strukturelt aspekt kan være flad, dvs. uden en successiv underinddeling, eller i et vilkårligt antal underinddelinger efter behov. Såfremt der er behov for flere niveauer, kan disse skabes i en trælignende struktur, dvs. at der ikke er krav om et fast antal niveauer i hver gren. Kodestrukturen, der altid baseres på et eller flere strukturelle aspekter, har to primære formål: 1) At identificere objektforekomster enten individuelt og/eller ud fra den sammenhæng som de indgår i set i forhold til systemer som de er bestanddele af. 2) At tilknytte objektforekomsten til en objektklasse. Kravet er, at CCS klassifikationen skal være stabil set over livscyklus, så koden ikke ændre sig. Status ved dette projekts afslutning er, at stabilitetsprincippet i klassifikationen opnås ved at anvende bygningsdelenes tekniske egenfunktion (dvs. hvad en bygningsdel gør i sig selv ), frem for den funktion bygningsdelen anvendes til, som inddelingskriterie for klassifikationen. 15

16 6 Kravspecifikation Krav til udformning af koder for bygningsdele og brugsrum. Strukturen og syntaksen for kodning i CCS er designet til at understøtte både processer i byggeprojekter og uden for byggeprojekter, herunder hele bygge- og driftsprocessen, og kan anvendes til et varieret kodningsbehov i de forskellige faser. Målgruppen er derfor alle byggeriets aktører, fx: Byg- og driftsherrer Arkitekter Rådgivere Ingeniører Entreprenører Udførende Byggematerialeleverandører Projektgruppen har været særligt opmærksom på de faglige forskelle mellem aktørerne og deres forskellige informationsbehov, samt hvorledes disse forventes at være differentieret efter bl.a. branche, virksomhedsrolle, opgaveportefølje, it-niveau etc. 6.1 Minimumskrav Som udgangspunkt for projektet er der af cuneco's styregruppe, jævnfør pkt. 3.3 i Projektbeskrivelsen, stillet følgende minimumskrav som succeskriterier for projektet Kodesyntaksen skal være it-egnet. Det skal tilstræbes, at de tabeller der omhandler klassifikationsdelen og som efterfølgende vil blive udarbejdet, skal kunne anvendes sammen med IFD. Koden skal indeholde en klassifikationsdel, der er uafhængig af hvilken sammenhæng bygningsdelen indgår i. Koden skal omfatte en referencedel, der gør brug af klassifikationsdelen. Kodesyntaksen skal indeholde en løbenummerdel, der kan bruges til at identificere bygningsdele unikt indenfor projektet. Kodesyntaksen skal understøtte mapning mellem den nye struktur og DBK Kodesyntaksen skal tilstræbes at kunne mappes til andre nationale klassifikationssystemer. 16

17 Klassifikationsdelen skal kunne anvendes under hele byggeprocessen fra program til og med forvaltning. 6.2 Uddybet kravspecifikation Projektgruppen har fundet det nødvendigt at uddybe og udvide minimumskravene stillet af cuneco bl.a. som følge af behov og resulterende krav til CCS-koden der er identificeret undervejs i projektet efter input fra følgende kilder: Projektets baggrundsmateriale Interne workshops i projektgruppen Review med cuneco s styregruppe og IT-leverandører (se afsnit 10) Intern høringsworkshop i cuneco Studie af behovsanalysen fra Cuneco projekt Behovsanalysen (foreløbige hovedkonklusioner) (kommenteret i Bilag F - Kommentarer til behovsanalysens foreløbige hovedkonklusioner) Offentlig høring på DTU Den udvidede kravspecifikation dækker nedenstående temaer og kan læses i Bilag H Udvidet kravspecifikation: Klassifikationskrav Identifikationskrav Normative krav Anvendelseskrav Implementeringskrav Disse krav samt minimumskravene fra Projektbeskrivelsen udgør den grundlæggende kravspecifikation for projektgruppens udvikling af CCS. 17

18 7 Grundlæggende kodningsregler BEMÆRK: De i denne rapport anvendte klassifikationskoder (1, 2 eller 3 bogstaver) stammer fra cuneco's klassifikationsprojekter, der ikke er en del af dette projekt. Klassifikationskoderne er medtaget af hensyn til illustration og sammenhæng mellem kodeprincipper og klassifikationskoder. Klassifikationstabellerne for bygningsdele og rum sendes i offentlig høring i januar Ændringer i den færdige koder kan derfor forekomme. 7.1 Klassifikation og identifikation i CCS I resultatdomænet af ISO anvendes CCS til klassifikation og identifikation af bygningsdele og brugsrum. Hertil kommer klassifikation af bygværker. Klassifikationsdelen har til formål at samordne klasser af objekter, som har det samme sæt af egenskaber (type-af), og identifikationsdelen skal benyttes som robust identifikation af enhver relevant objektforekomst såfremt det er nødvendigt at kunne skelne ens forekomster fra hinanden, fx skelne døre, vinduer, ventiler og stikkontakter individuelt fra hinanden. I forhold til DBK2006 ændres der på måden hvorpå klassifikationsdelen og identifikationsdelen beskrives i CCS, idet der i CCS gælder følgende: A 1 A1 1.) I DBK2006 blev klassifikation beskrevet både ved tal og bogstaver. I CCS beskrives klassifikation udelukkende ved brug af latinske bogstaver. 2.) CCS identifikationsdelen er opbygget af løbenumre der qua kodens opbygning gør det muligt at skelne enhver objektforekomst fra andre objektforekomster. 3.) Klassifikationsdelen og identifikationsdelen bruges i dele af CCS til samtidigt at identificere et objekt og give en oplysning om typen af objekt. 7.2 Klassifikation Generelt I DBK2006 blev adskillige bygningsdele organiseret forskelligt afhængigt af hvilken strukturel sammenhæng de indgik i. Branchens erfaringer med DBK2006 samt evalueringer af DBK2006 (fx Ekholm-rapporten samt Notat om DBK i forbindelse med IT-systemer) har påpeget flere uhensigtsmæssigheder, heriblandt: 18

19 Ændringer i objekters egenskabsdata eller konstruktive relationer fører i mange tilfælde til ændringer i klassifikationen af objektet, med dertil hørende behov for ændringer i den berørte dokumentation, advisering af forskellige aktører mm. En kompositionelt afhængig klassifikation understøtter ikke branchens ønsker om at kunne anvende den klassificerende del af CCS separat til forskellige formål, fx til samordning af objekter i tilbudsfasen eller driftsfasen. Når et objekt kan klassificeres forskelligt alt efter den pågældende kompositoriske sammenhæng, gøres både manuel og ITunderstøttet klassifikation mere besværlig. I byggeriets IT-værktøjer ønskes ét ensartet inddelingskriterie der anvendes til klassifikationsdelen, således at man får ens klassifikationsbogstaver, der betegner de samme objekter uanset anvendelsen. I CCS anlægges der derfor et nyt centralt princip for klassifikation af bygningsdele og brugsrum: Stabilitetsprincippet: Klassifikationen af bygningsdele og brugsrum i CCS skal være stabil igennem livscyklussen for et kodet objekt. Dette inkluderer at inddelingskriterierne for bygningsdele og brugsrum i CCS skal være 100% uafhængige af den strukturelle komposition af bygværket dvs. i hvilken strukturel kontekst en bygningsdel eller et brugsrum objekt indgår i. Det forudsættes stadig at klassifikationen baseres på type-af strukturer, dvs. følger de gængse regler for udarbejdelse af klassifikationstabeller Kort om stabilitetsprincippet Stabilitetsprincippet for klassifikation i CCS inebærer, at inddelingskriterierne i CCS er uafhængige af projektspecifikke egenskabsdata, dvs. egenskabsdata der ændres gennem objektets livscyklus. Dette inkluderer den strukturelle komposition af bygværket. Formålet med at anlægge dette princip er at gøre kodningen af objekter stabil ved ændring af bygværkets komposition, hvilket vil resultere i færre ændringer af dokumentation mm. Det vil blive muligt at prækode objekter i IT systemernes objektbiblioteker, og generelt set vil det være nemmere at huske klassifikationen for mennesker (dvs. til analog brug). Ydermere vil det være muligt at klassificere objekterne før den kompositoriske sammenhæng for objektet er kendt, hvilket ikke var tilfældet med DBK2006. Ved traditionel klassifikation ændres klassifikationen af et objekt henover tid, efterhånden som objektet tildeles flere egenskabsdata (se Figur 3), hvilket resulterer i ændringer i klassifikationskoden. Dette skyldes enten at klassifikationen detaljeres ved tildeling af en underklasse, eller at objektet tildeles en anden klasse af samme detaljeringsniveau. 19

20 Information om et objekt Traditionel klassifikation Egenskaber Egenskabsdata Objektklasse (klassifikation) Programmering Projektering Udførsel Drift Tid Figur 3 - Traditionel klassifikation: Ændring henover tid I CCS anlægges stabilitetsprincippet, idet der ønskes en stabil (uændret) klassifikation, set over livscyklus for et objekt. Kriteriet for dybden af klassifikation bliver således, at der skal klassificeres ud fra de egenskabsdata der ikke vil bevirke en ændring af objektets klassifikation gennem objektets livscyklus (se Figur 4). Information om et objekt CCS Egenskaber Egenskabsdata Objektklasse (klassifikation) Programmering Projektering Udførsel Drift Tid Figur 4 - CCS klassifikation: Statisk klassifikation henover tid Egenskabsdata, der potentielt kunne resultere i en ændring af klassifikationskoden hen over tid, tilskrives i stedet udelukkende som egenskabsdata for objektet og indgår ikke længere i koden for klassifikationen. De enkelte egenskabsdata kan efterfølgende klassificeres separat (fx brandklasser, materialeklasser etc.). 20

21 7.2.3 Regler for klassifikationsbogstaver I de dele af CCS hvor klassifikation indgår skal klassifikationsbogstaver anvendes efter følgende regler: Regel 1: Regel 2: Bogstaverkoder skal bestå af kapitaliserede latinske bogstaver A til Z med udelukkelse af bogstaverne I og O, da disse kan forveksles med tallene 1 (ét) og 0 (nul). Danske bogstaver Æ, Ø og Å anvendes ikke. I bogstavkoder bestående af mere end ét bogstav udgør et efterfølgende bogstav altid en underklasse af det foregående bogstav. Princippet illustreres herunder: B B etc. (1) (2) (3) B Klassifikationsbogstav (1) Hovedklasse (2) Underklasse af foranstående klasse (3) Efterfølgende bogstaver udgør underklasser af foranstående underklasse Regel 3: Anvendelse af klassifikation der ikke er foruddefineret i CCS klassifikationstabeller tillades kun i koder for strukturelle aspekter hvor CCS udtrykkeligt tillader det. Denne klassifikation er kun gældende inden for konteksten af ét bestemt projekt. Der er ingen begrænsning for dybden af en sådan klassifikation, der altid skal forklares i den medfølgende dokumentation. Kodningsprincipperne i CCS definerer de grundlæggende regler for brug af klassifikationsbogstaver og fastlægger ét princip for udarbejdelsen af klassifikationstabellerne. Udarbejdelsen af klassifikationstabellerne i CCS falder uden for rammer af dette projekt og varetages af projekterne Klassifikation af bygværker og rum og Klassifikation af bygningsdele. De relevante forudsætninger for klassifikationsarbejdet der er affødt af kodningsprincipperne overføres til projektgrupperne for de to klassifikationsprojekter Anbefalinger til klassifikationstabeller I henhold til de beskrevne regler for kodning af bygningsdele og brugsrum, skal klassifikation af disse foregå med bogstaver. Baseret på rådata fra DBK, har udviklingen af CCS klassifikation for bygningsdele vist, at det vil være hensigtsmæssigt at opdele bygningsdele i tre grupper: 21

22 Hovedsystemer Del-systemer Komponenter Det anbefales, at der anvendes 1 bogstav for hovedsystemer, 2 bogstaver for del-systemer og 3 bogstaver for komponenter, således at man kan skelne mellem de tre grupper på antallet af bogstaver. Inddelingskriteriet for bygningsdelene skal sikre den stabilitet i klassen, som er beskrevet i afs Stabiliteten for klassifikation af bygningsdele kan etableres for hele livscyklussen. Klassifikation af brugsrum skal på tilsvarende vis udvikles, således at klassifikation af et brugsrum gøres så stabil som muligt. Anvendelse af klassifikation af brugsrum, set gennem hele livscyklus, er dog ikke lige så stabil som klassifikation af bygningsdele. Et vilkårligt brugsrum kan skifte anvendelsesfunktion (fx fra kontor til lager), hvilket vil have indflydelse på klassifikation af brugsrummet. Da det ikke e muligt at skabe en 100% stabil klassifikation set over den samlede livscyklus for et brugsrum, medtages koden for klassen i de strukturelle aspekter %% og == (hvor en ændring af klassekoden ikke har samme effekt), men ikke i ##, -- og ++ (der anvendes som forskellige former for identifikation af brugsrum). Projektgruppen anbefaler at der udarbejdes to tabeller til klassifikation af brugsrum med hver deres inddelingskriterie: 1. Brugsrum 1 o Inddelingskriteriet skal være relateret til brugsrummenes fysiske gruppering i bygværk. Tabellen skal således fx indeholde klasser såsom Bygning, Afsnit, Etage og Brugsrum 2. Brugsrum 2 o Inddelingskriteriet skal være relateret til brugsrummets primære funktion eller tiltænkte brug Den endelige beslutning om definition af nødvendige klassifikationstabeller træffes ikke i dette projekt. 7.3 Identifikation Da den information der udveksles om objektforekomster i byggeriet er så forskelligartet i et bygværk, er det ikke er teknisk muligt at udarbejde én kode der alene kan opfylde alle de krav, som stilles til en CCS kode. Identifikation i CCS sker derfor ved brug af strukturelle aspekter (se afsnit 5.3), der beskriver kompositionen af et bygværk. Anvendelsen af de strukturelle aspekter gør det både muligt at identificere bygningsdele og brugsrum, samt at udtrykke supplerende information omkring deres skiftende relationer gennem hele bygværkets livscyklus. Inden for hvert strukturelle aspekt defineres der flere strukturelle aspektkoder til brug ved kodning af objekter i CCS. Hvert strukturelle aspekt har 22

23 tilknyttet et bestemt tegn (præfiks) til brug i de strukturelle aspektkoder. Den tekniske løsning på kodemekanismen i CCS er altså designet som en sammensætning af disse strukturelle aspektkoder, der følger de samme generelle syntaksregler, men som hver især tilgodeser forskellige informationsbehov om en bygningsdel hhv. et brugsrum. Klassifikationsdelen af CCS anvendes i koderne for de strukturelle aspekter, bl.a. for at kunne: Sikre genkendelse for mennesker (dvs. analog brug). Mindske risikoen for at brugerne udtager de samme løbenumre, når de forskellige fag koder deres del af bygværket. Muliggøre afkodning af hvilken struktur eller hvilke relationer koden beskriver Strukturelle aspekter Et strukturelt aspekt i CCS angiver en bestemt måde at anskue bygværkets objekter og deres relationer. Ved at anlægge forskellige anskuelser af bygværkets objekter er det muligt at lave en mangesidig beskrivelse af et bygværk, alt efter formål og tidspunkt i bygværkets livscyklus. Hovedformålet med dette er at understøtte de forskellige informationsbehov i byggeriet, der ikke kan beskrives ud fra blot én bestemt anskuelse af et givent bygværk. De strukturelle aspekter kan således siges at agere som filtre hvorigennem et bygværk anskues, og hvor hvert strukturelt aspekt gør det muligt enten at betragte et objekt (bygningsdel eller brugsrum) isoleret eller i en sammenhæng til bygværkets øvrige objekter. De fleste af de strukturelle aspekter i CCS anskuer objekterne i strukturer med sammenhæng til bygværkets øvrige objekter. Disse strukturelle aspekter defineres ud fra objektrelationer, der beskriver enten konstruktion, funktion, placering eller typefællesskab for bygværkets objekter. I CCS defineres der fem forskellige typer af strukturelle aspekter hvorigennem byggeriets objekter anskues: Typeaspekt o I typeaspektet anskues objekter ud fra deres typefællesskab med andre objekter, dvs. ud fra hvilke objekter inden for den samme CCS klasse som de har et typemæssigt fællesskab med fx forskellige designvarianter. o Strukturelle aspektkoder i dette strukturelle aspekt benytter et eller flere % (Procenttegn) som præfiks. 23

24 Produktaspekt o I produktaspektet anskues objekter som isolerede objekter uden relation til andre objekter, dvs. at objekternes indbyrdes relationer mht. konstruktion, funktion eller placering betragtes ikke. Uagtet at der er tale om en flad struktur, er der tale om en struktur i teknisk forstand (her: at tingene er ordnet efter en overordnet systematik). o Strukturelle aspektkoder i dette strukturelle aspekt benytter et eller flere # (Nummertegn) som præfiks. Sammensat produktaspekt o I det sammensatte produktaspekt anskues objekter ud fra deres konstruktionsmæssige relationer til andre objekter, dvs. ud fra deres fysiske relationer. o Strukturelle aspektkoder i dette strukturelle aspekt benytter et eller flere - (Minustegn) som præfiks. Placeringsaspekt o I placeringsaspektet anskues objekter ud fra deres placeringsmæssige relationer til andre objekter, dvs. ud fra hvordan de er placeret i forhold til andre objekter. o Strukturelle aspektkoder i dette strukturelle aspekt benytter et eller flere + (Plustegn) som præfiks. Funktionsaspekt o I funktionsaspektet anskues objekter ud fra deres funktion og deres funktionsmæssige relationer til andre objekter, dvs. ud fra hvilken funktion de opfylder i et bygværk eller system og hvordan de funktionelt hænger sammen med andre objekter. o Strukturelle aspektkoder i dette strukturelle aspekt benytter et eller flere = (Lighedstegn) som præfiks. Note: Da de strukturelle aspektkoder benytter præfikstegn der også bruges som operatorer i computerprogrammer fx programmer fra Microsoft Office, skal brugerne af CCS være opmærksom på at koderne behandles korrekt. Som eksempel kan nævnes Microsoft Excel, hvor koderne bl.a. kan håndteres ved brug af en bestemt celleformatering eller brug af apostrof foran koden. Det skal generelt bemærkes at CCS koderne kan håndteres med basisfunktionaliteten i Excel og ikke kræver udvikling af makroer eller lignende. Tilsvarende kan præfikstegnene anvendes til filnavngivning såfremt det er hensigtsmæssigt. Anvendelsen af strukturelle aspektkoder i sker efter følgende regler: Regel 4: Regel 5: Kodede objekter i CCS tilskrives et varierende antal delkoder (minimum én) kaldet strukturelle aspektkoder. Samlingen af strukturelle aspektkoder der tilskrives et objekt kaldes objektets CCC kode. Alle strukturelle aspektkoder er forsynet med et præfikstegn (fortegn) for det pågældende strukturelle aspekt hvori aspektkoden er defineret. 24

25 Regel 6: Regel 7: Såfremt der defineres mere end én strukturel aspektkode inden for et strukturelt aspekt benyttes flere af det samme præfiks f.eks. +, ++, +++ osv. Strukturelle aspektkoder kan sammensættes til én enkelt CCS-kodestreng, hvor hver strukturelle aspektkode er adskilt med et skråtegn: /. Princippet illustreres herunder: D / D / D etc. (1) (2) (3) (4) (5) D Strukturel aspektkode i den samlede kodestreng (1) Strukturel aspektkode (2) Separator / adskiller de enkelte aspektkoder i kodestrengen (3) Strukturel aspektkode (4) Separator / adskiller de enkelte aspektkoder i kodestrengen (5) Strukturel aspektkode Regel 8: Der er ingen regel for rækkefølgen af de strukturelle aspektkoder i CCS-kodestrengen. Rækkefølgen er uden betydning, da man kan skelne de forskellige strukturelle aspektkoder fra hinanden på deres forskellige præfiks (fortegn) Regler for identifikations løbenumre Løbenumre i de strukturelle aspektkoder bruges til identifikation af ensartede typer af individuelle objekter eller grupper af objekter. Der gælder følgende regler for brugen af løbenumre: Regel 9: Regel 10: Regel 11: Regel 12: Regel 13: Der er intet krav om fast antal af karakterer i et løbenummer. Foranstillede nuller kan benyttes efter behov, f.eks. hvis dette er nødvendigt af hensyn til sortering i IT-systemer. Ved kodning af kompositionelle del-af strukturer i CCS, adskilles hvert strukturniveau i koden ved brug af punktum.. Løbenumre kan enten være gældende inden for én bestemt klasse eller på tværs af klasser. Nummerering kan enten ske fortløbende på tværs af alle niveauer og under-dele i en del-af struktur eller fortløbende inden for ét niveau eller en under-del af en del-af struktur. Såfremt der benyttes en global nummerering der er gældende i aspektkoderne for mere end ét strukturelt aspekt, skal det i projektets dokumentation angives i hvilke strukturelle aspektkoder den globale nummerering anvendes. 25

26 Regel 14: Løbenumre kan efter behov tillægges specifik betydning, der er gældende inden for et projekt. Betydningen af løbenumrene skal altid forklares i projektets dokumentation. 26

27 8 Strukturelle aspektkoder Udarbejdelse af CCS koder efter veldefinerede aspekter. I CCS prædefineres strukturelle aspektkoder med op til to præfikstegn inden for hvert strukturelle aspekt. Brugere af CCS kan frit oprette supplerende strukturelle aspektkoder med tre eller flere præfikstegn inden for hvert strukturelle aspekt, forudsat at definitionerne og syntaksreglerne for de strukturelle aspekter følges. Aspektkoderne for de strukturelle aspekter inddeles i tre grupper: Gruppe 1 CCS strukturelle aspektkoder der udtrykker information relateret til bygningsdele. Gruppe 2 CCS strukturelle aspektkoder der udtrykker information relateret til brugsrum. Gruppe 3 Brugerdefinerede supplerende strukturelle aspektkoder der udtrykker information relateret til enten bygningsdele eller brugsrum. I de efterfølgende afsnit beskrives de prædefinerede strukturelle aspektkoder. En oversigt over alle aspektkoderne kan ses i Bilag B Oversigt over aspektkoder og Bilag C Oversigt over supplerende aspektkoder. 8.1 Syntaks for Gruppe 1 aspektkoder CCS prædefinere fem aspektkoder (én for hvert strukturelt aspekt), der udtrykker information relateret til bygningsdele. Definitionerne for hver aspektkode ses i Tabel 1. Præfiks Definition % Projektspecifik gruppe af bygningsdele med samme klassifikation. # Identificerer en bygningsdel betragtet som et selvstændigt objekt. - Identificerer en bygningsdel som en del af en anden bygningsdel. + Identificerer et sted udtrykt ved en bygningsdel. = Identificerer en bygningsdel som en del af en anden bygningsdel i en funktionel sammenhæng. Tabel 1 - Strukturelle aspektkoder i Gruppe 1 Eksempler for anvendelsen af de strukturelle aspektkoder vises i afsnit 9. 27

28 8.1.1 [%] Typeaspekt for bygningsdele Symbol Præfiks Definition Beskrivelse % (procenttegn) Projektspecifik gruppe af bygningsdele med samme klassifikation. Det er muligt inden for rammerne af ét projekt, at definere typer af bygningsdele inden for hver klasse, til brug ved gruppering af bygningsdele i designvarianter f.eks. til udbud og specifikation. Denne aspektkode bruges til identifikation af sådanne grupper. Såfremt der defineres bestemte typer af bygningsdele i et projekt, er denne definition kun gyldig inden for rammerne af det specifikke bygværket og skal beskrives i bygværkets dokumentation. Klassifikation Aspektkoden gør brug af følgende klassifikationstabeller: Hovedsystemer Delsystemer Komponenter Afhængigt af om der kodes et Hovedsystem, Delsystem eller en Komponent anvendes den relevante klassifikation. Syntaks Strukturniveau 1 Syntaks % B N (1) (2) (3) B N Klassifikationsbogstav(er) Løbenummer (1) Aspekt præfiks (2) Bygningsdelsklassifikation (iht. tabellerne Hovedsystemer, Delsystemer eller Komponenter) (3) Løbenummer for gruppe af bygningsdele med samme klassifikation Eksempel %QQA1 Vinduesgruppe 1 (sidehængte vinduer) %QQA2 Vinduesgruppe 2 (tophængte vinduer) 28

29 8.1.2 [#] Produktaspekt for bygningsdele Symbol Præfiks Definition Beskrivelse # (nummertegn) Identificerer en bygningsdel betragtet som et selvstændigt objekt. Aspektkoden bruges til entydigt at identificere en bygningsdel (Hovedsystem, Delsystem eller Komponent) uafhængigt af den strukturelle komposition af bygværket. Koden udgør således en enkeltniveaus struktur, med en simpel fortløbende nummerering inden for hver klasse af bygningsdele. Da aspektkoden er uafhængig af relationer til andre objekter i et bygværk, kan aspektkoden udgøre en stabil identifikator igennem hele livscyklus for en bygningsdel. Klassifikation Aspektkoden gør brug af følgende tabeller: Hovedsystemer Delsystemer Komponenter Syntaks Strukturniveau 1 Syntaks # B N (1) (2) (3) B N Klassifikationsbogstav(er) Løbenummer (1) Aspekt præfiks (2) Bygningsdelsklassifikation (iht. tabellerne Hovedsystemer, Delsystemer eller Komponenter) (3) Bygningsdelsløbenummer Eksempel #QQA1 Vindue 1 #QQA34 Vindue 34 #QQC1 Dør 1 #QQC34 Dør 34 29

30 8.1.3 [-] Sammensat produktaspekt for bygningsdele Symbol Præfiks Definition Beskrivelse: - (minustegn) Identificerer en bygningsdel som en del af en anden bygningsdel. Aspektkoden benyttes til entydig identifikation af bygningsdele. Systemer og delsystemer anvendes til at håndtere og beskrive sammenhængende bygningsdele frem for bygningsdele som enkelte objekter. Koden benytter en produktmæssig (fysisk konstruktiv) synsvinkel og kan baseres på en generisk model for dekomponering af bygningsdele, der er prædefineret i CCS s hovedsystemer. Bygværkets systemstruktur kan aflæses af koden, og gør det bl.a. muligt at afkode del-af relationer mellem bygningsdele. Koden kan således bruges til at finde bestanddelene i bygværkets systemer. Hermed supporteres bl.a. designgenbrug ved inddeling af bygværket i isolerede designstrukturer samt håndtering af overordnede systemer i bygværket. Det anbefales af projektgruppen, at der til gavn for byggebranchen defineres en række generiske systemstrukturer for hver klasse af hovedsystem. Klassifikation Aspektkoden gør brug af følgende tabeller: Hovedsystemer Delsystemer Komponenter Syntaks Aspektkoden beskriver en del-af struktur der overholder følgende hierarki for hvor i strukturen objekterne kan indgå: Hovedsystem > Delsystem > Komponent Der er ikke krav om at der skal defineres Hovedsystemer eller Delsystemer i bygværket, og det er samtidigt muligt at definere flere niveauer af Delsystemer i strukturen. Man kan således have forskellige strukturer, med forskelligt antal strukturniveauer, alt efter kompleksitet. Man kan fx have en struktur uden Hovedsystemer, der kun består af Delsystemer, som igen består af Komponenter. 30

31 Dette kaldes i praksis for en træstruktur, da der ikke er sat regler for antallet af underinddelinger. De seks eksempler nedenfor illustrerer princippet for opbygning af sådanne strukturer illustreret nedenfor: -Komponent. Komponent -Delsystem. Komponent -Hovedsystem. Delsystem. Komponent -Hovedsystem.Delsystem.Komponent.Komponent -Hovedsystem. Delsystem. Delsystem. Komponent.Komponent -Hovedsystem.Hovedsystem.Delsystem.Delsystem. Komponent.Komponent etc. Syntaksen for aspektkoden ser således ud: Strukturniveau 1 n Syntaks - B N. B N (1) (2) (3) (4) (5) (6) B N Klassifikationsbogstav(er) Løbenummer (1) Aspekt præfiks (2) Bygningsdelsklassifikation (iht. tabellerne Hovedsystemer, Delsystemer eller Komponenter) (3) Løbenummer for Hovedsystem, Delsystem eller Komponent (4) Separator. adskiller strukturniveauer (5) Bygningsdelsklassifikation (iht. enten Hovedsystemer, Delsystemer eller Komponenter) (6) Løbenummer for Hovedsystem, Delsystem eller Komponent. For at lette kodning af objekter og gøre det nemmere at undgå konflikter i nummereringen af de kodede objekter, kan man anvende de samme løbenumre som et objekt kodes med i [#] Produktaspekt for bygningsdele. Eksempel på sammensætning i [-] Sammensat Produktaspekt for bygningsdele : 31

32 Hovedsystem Delsystem Komponent Produktaspekt: #B1 #UC4 #QQA36 Sammensat Produktaspekt: -B1.QA4.QQA36 (Vægsystem 1.Vinduesparti 4.Vindue 36) Eksempel Et vindue kan kodes med eller uden brug af samme løbenummer som anvendes i [#] Produktaspekt for bygningsdele. Kodning uden brug af samme løbenummer som anvendes i [#] Produktaspekt for bygningsdele: # aspektkode: #QQA87 Vindue nr. 87 løbenummer genbruges ikke - aspektkode: -B1.QA1.QQA1 Vægsystem 1.Vinduesparti 1. Vindue 1 Samlet CCS-kode: #QQA87 / -B1.QA1.QQA1 Kodning med brug af samme løbenumre som anvendes i [#] Produktaspekt for bygningsdele: # aspektkode: #QQA87 Vindue nr. 87 løbenummer genbruges - aspektkode: -B1.QA4.QQA87 Vægsystem 1.Vinduesparti 4. Vindue 87 Samlet CCS-kode: #QQA87 / -B1.QA4.QQA87 32

33 8.1.4 [+] Placeringsaspekt for bygningsdele Symbol Præfiks Definition Beskrivelse + (plustegn) Identificerer et sted udtrykt ved en bygningsdel. Aspektkoden beskriver en lokation i bygværket udtrykt ved en bygningsdel, dvs. at bygningsdelen i sig selv udgør et sted. Bygningsdele kan dermed udgøre steder hvor andre objekter i bygværket er placeret (fx monteret). Aspektkoden kan dermed bruges til at udtrykke f.eks. montage information som ikke fremgår af del-af strukturen fra [-] Sammensat Produktaspekt for bygningsdele. Dette kan bl.a. være tilfældet for montagerelationer mellem elektriske/mekaniske bygningsdele og konstruktive bygningsdele, eller mellem bygningsdele i det samme system. Klassifikation Aspektkoden gør brug af følgende tabeller: Hovedsystemer Delsystemer Komponenter Syntaks Da aspektkoden beskriver et sted udtrykt ved bygningsdelene i bygværket kan man vælge at basere aspektkoden på enten [#] Produktaspekt for bygningsdele eller [-] Sammensat Produktaspekt for bygningsdele. Syntaksen for [+] Placeringsaspekt for bygningsdele vil således beskrive den samme struktur som et af disse aspekter, men i stedet udtrykt som et sted der kan bruges som placeringsreference. Hvorvidt syntaksen for aspektkoden baseres på [#] Produktaspekt for bygningsdele eller [-] Sammensat Produktaspekt for bygningsdele skal angives i bygværkets dokumentation. Syntaks baseret på [#] Produktaspekt for bygningsdele : Strukturniveau 1 Syntaks + B N (1) (2) (3) B N Klassifikationsbogstav(er) Løbenummer 33

34 (1) Aspekt præfiks (2) Bygningsdelsklassifikation (iht. tabellerne Hovedsystemer, Delsystemer eller Komponenter) (3) Bygningsdelsløbenummer Syntaks med vilkårligtantal strukturniveauer baseret på [-] Sammensat produktaspekt for bygningsdele : Strukturniveau 1 n Syntaks + B N. B N (1) (2) (3) (4) (5) (6) B N Klassifikationsbogstav(er) Løbenummer (1) Aspekt præfiks (2) Bygningsdelsklassifikation (iht. tabellerne Hovedsystemer, Delsystemer eller Komponenter) (3) Løbenummer for Hovedsystem (4) Separator. adskiller strukturniveauer (5) Bygningsdelsklassifikation (iht. tabellerne Hovedsystemer, Delsystemer eller Komponenter) (6) Løbenummer for Delsystem Eksempel +B2.UC4.ULL1 Vægsystem 2.Vægkonstruktion 4.Vægplade 1 Placeringen anvendes som reference for en bygningsdels placering således: -K1.ED1.SFA1 / +B1.DF4.LUD1 Læses: Elsystem 1.Belysningsanlæg 1.Afbryder 1 (placeret i) Vægsystem 1.Vægkonstruktion 4.Vægplade 1 34

35 8.1.5 [=] Funktionsaspekt for bygningsdele Symbol Præfiks Definition Beskrivelse = (lighedstegn) Identificerer en bygningsdel som en del af en anden bygningsdel i en funktionel sammenhæng. Aspektkoden identificerer bygningsdele ud fra en funktionel betragtning hvilket muliggør at bygningsdele identificeres uafhængigt af den strukturelle komposition af bygværket. Der kan således identificeres bygningsdele før/uden den strukturelle komposition af bygværket er kendt, dvs. uden hensyntagen til den faktiske implementering af en specificeret funktionalitet. Aspektkoden gør det muligt at designe funktionalitet i bygværket, og kan bl.a. anvendes til prædesign og/eller systemdesign af hovedsystemer og delsystemer, fx i form af procesdiagrammer og konstruktive systemer uden hensyn til den efterfølgende fysiske udformning. Klassifikation Aspektkoden gør brug af følgende tabeller: Hovedsystemer Delsystemer Bygningsdele Syntaks Syntaksen i aspektkoden skal beskrive en funktionel systemstruktur bestående af bygningsdele. Der anvendes en syntaks for systemnedbrydning lig den der anlægges i [-] Sammensat Produktaspekt for bygningsdele. Aspektkoden beskriver derfor en del-af struktur der overholder følgende hierarki for hvor i strukturen objekterne kan indgå: Hovedsystem > Delsystem > Komponent Der er ikke krav om at der skal defineres Hovedsystemer eller Delsystemer i et projekt, og det er samtidigt muligt at definere flere niveauer af Delsystemer i strukturen. Man kan således have forskellige strukturer, med forskelligt antal strukturniveauer, alt efter kompleksitet. Man kan fx have en struktur uden Hovedsystemer, der kun består af Delsystemer, som igen består af Komponenter. Dette kaldes i praksis for en træstruktur, da der ikke er sat regler for antallet af underinddelinger. De seks ek- 35

36 sempler nedenfor illustrerer princippet for opbygning af sådanne strukturer illustreret nedenfor: =Komponent. Komponent =Delsystem. Komponent =Hovedsystem. Delsystem. Komponent =Hovedsystem.Delsystem.Komponent.Komponent =Hovedsystem. Delsystem. Delsystem. Komponent.Komponent =Hovedsystem.Hovedsystem.Delsystem.Delsystem. Komponent.Komponent etc. Syntaksen for aspektkoden ser således ud: Strukturniveau 1 n Syntaks = B N. B N (1) (2) (3) (4) (5) (6) B N Klassifikationsbogstav(er) Løbenummer (1) Aspekt præfiks (2) Bygningsdelsklassifikation (iht. tabellerne Hovedsystemer, Delsystemer eller Komponenter) (3) Løbenummer for Hovedsystem, Delsystem eller Komponent (4) Separator. adskiller strukturniveauer (5) Bygningsdelsklassifikation (iht. tabellerne Hovedsystemer, Delsystemer eller Komponenter) (6) Løbenummer for Hovedsystem, Delsystem eller Komponent. Eksempel =J1.HA2.RMA7 Ventilationssystem 1.Blandeanlæg 2.Kontraventil 7 36

37 8.2 Syntaks for Gruppe 2 aspektkoder CCS prædefinere fem aspektkoder (én for hvert strukturelt aspekt), der udtrykker information relateret til brugsrum. Definitionerne for hver aspektkode ses i Tabel 2. Præfiks Definition %% Projektspecifik gruppe af brugsrum med samme klassifikation. ## Identificerer et brugsrum betragtet som et selvstændigt objekt. -- Identificerer et brugsrum som en del af et bygværk, afsnit (option) og en etage. ++ Identificerer et sted udtrykt ved et brugsrum, en etage, et afsnit eller et bygværk. == Identificerer et brugsrum i en projektspecifik funktionel sammenhæng. Tabel 2 - Strukturelle aspektkoder i Gruppe 2 Eksempler for anvendelsen af de strukturelle aspektkoder vises i afsnit 9. 37

38 8.2.1 [%%] Typeaspekt for brugsrum Symbol Præfiks Definition Beskrivelse %% (procenttegn procenttegn) Projektspecifik gruppe af brugsrum med samme klassifikation. Det er tilladt inden for rammerne af et bygværk at definere typer af brugsrum inden for hver klasse, til brug ved gruppering af brugsrum fx til konfigurering og beskrivelse af brugsrum. Denne aspektkode bruges til identifikation af sådanne grupper. Såfremt der defineres bestemte typer af brugsrum i et projekt, er denne definition kun gyldig inden for rammerne af det specifikke bygværkets og skal beskrives i bygværkets dokumentation. Klassifikation Aspektkoden gør brug af følgende klassifikationstabeller: Brugsrum 2 Syntaks Strukturniveau 1 Syntaks %% B N (1) (2) (3) B N Klassifikationsbogstav(er) Løbenummer (1) Aspekt præfiks (2) Brugsrumsklassifikation (iht. tabel Brugsrum 2) (3) Løbenummer for gruppe af brugsrum med samme klassifikation Eksempel %%BA1 Baderumsgruppe 1 (Baderum med brusekabine) %%BA2 Baderumsgruppe 2 (Baderum med badekar) 38

39 8.2.2 [##] Produktaspekt for brugsrum Symbol Præfiks Definition Beskrivelse Klassifikation Syntaks ## (nummertegn nummertegn) Projektspecifik nummerering af brugsrum. Aspektkoden bruges til entydigt at identificere brugsrum uden hensyn til den struktur brugsrummet indgår i. Koden afspejler derfor ikke den fysiske placering af brugsrummene og ej heller den funktionelle opdeling af byggeriets brugsrum. Aspektkoden udgør en enkeltniveaus struktur, med en fortløbende nummerering af brugsrum. Der indgår ingen klassifikation af brugsrum i denne aspektkode, da typen af brugsrum meget nemt kan ændres fuldstændigt igennem livscyklus for et bygværk. Inklusion af klassifikation vil derfor gøre koden ustabil. Strukturniveau 1 Syntaks ## N (1) (2) N Løbenummer (1) Aspekt præfiks (2) Brugsrums løbenummer Eksempel ##1 Brugsrum nr. 1 ##34 Brugsrum nr

40 8.2.3 [--] Sammensat produktaspekt for brugsrum Symbol Præfiks Definition -- (minustegn minustegn) Identificerer et brugsrum som en del af en bygning, afsnit (option) og en etage. Beskrivelse Aspektkoden benyttes til entydig identifikation af brugsrum. Bygninger, afsnit og etager anvendes til at håndtere og beskrive sammenhængende brugsrum frem for udelukkende brugsrum som enkelte objekter. Aspektkoden beskriver en fysisk strukturel dekomponering af bygningen, der altid vil være projektspecifik. Kodens struktur afspejler den fysiske placering af brugsrummene i konstruktionen og kan således bruges til orientering i det færdige byggeri. Følger ISO 4157 (se afsnit 11.4). Klassifikation Aspektkoden gør brug af følgende tabeller: Brugsrum 1 Syntaks Aspektkoden beskriver en del-af struktur der følger følgende hierarki for hvor i strukturen bestemte objekter kan indgå: Bygning -> Afsnit (option) -> Etage -> Brugsrum Topniveauet i koden udgøres altid af bygning. Afsnit kan udelades fra strukturen såfremt der ikke er nogen definerede afsnit i bygværket. Der samtidigt ingen begrænsninger i hvor mange niveauer af Afsnit, Etage eller Brugsrum der kan inkluderes i strukturen, så længe strukturhierarkiet overholdes. Der kan således fx identificeres underafsnit ved at inkludere afsnit på to niveauer fx Bygning 1. Afsnit 1. Afsnit 1. Etage 2. Brugsrum 1 Eller brugsrum kan beskrives som inddeling af overligende brugsrum efter behov fx ved brug af flytbare vægkonstruktioner. Bygning 1. Etage 1. Brugsrum 1. Brugsrum 1 Bygning 1. Etage 1. Brugsrum 1. Brugsrum 2 40

41 Syntaksen for aspektkoden ser derfor således ud: Strukturniveau 1 n n n Syntaks -- B N. B N. B N. B N (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) B N Klassifikationsbogstav(er) Løbenummer (1) Aspekt præfiks (2) Klassifikation for Bygning (iht. tabel Brugsrum 1) (3) Løbenummer for Bygning (4) Separator. adskiller strukturniveauer (5) Klassifikation for Afsnit (iht. tabel Brugsrum 1) (6) Løbenummer for Afsnit (7) Separator. adskiller strukturniveauer (8) Klassifikation for Etage (iht. tabel Brugsrum 1) (9) Løbenummer for Etage (10) Separator. adskiller strukturniveauer (11) Klassifikation for Brugsrum (iht. tabel Brugsrum 1) (12) Løbenummer for Brugsrum Eksempel --B12.S3.E2.R22 Bygning 12. Afsnit 3. Etage 2. Brugsrum 22 NOTE: De anvendte bogstavkoder i ovenstående eksempel refererer til klassifikationstabel indeholdende klasserne Bygning, Afsnit, Etage, Brugsrum der udsendes i offentlig høring januar Bogstaverne anses for klasser. Ændringer kan forekomme. 41

42 8.2.4 [++] Placeringsaspekt for brugsrum Symbol Præfiks Definition Beskrivelse Klassifikation ++ (plustegn plustegn) Identificerer et sted udtrykt ved et brugsrum, en etage, et afsnit eller en bygning. Aspektkoden beskriver en lokation i bygværket udtrykt ved et brugsrum (Bygning, Afsnit, Etage eller Brugsrum). Brugsrum kan således udgøre steder hvor andre objekter i bygværket er placeret. Aspektkoden gør brug af følgende tabeller: Brugsrum 1 Syntaks Da aspektkoden beskriver et steder udtrykt ved brugsrum i bygværket baseres strukturen af aspektkoden strukturen af [--] Sammensat produktaspekt for brugsrum. Syntaksen for aspektkoden ser derfor således ud: Strukturniveau 1 n n n Syntaks ++ B N. B N. B N. B N (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) B N Klassifikationsbogstav(er) Løbenummer (1) Aspekt præfiks (2) Klassifikation for Bygning (iht. tabel Brugsrum 1) (3) Løbenummer for Bygning (4) Separator. adskiller strukturniveauer (5) Klassifikation for Afsnit (iht. tabel Brugsrum 1) (6) Løbenummer for Afsnit (7) Separator. adskiller strukturniveauer (8) Klassifikation for Etage (iht. tabel Brugsrum 1) (9) Løbenummer for Etage (10) Separator. adskiller strukturniveauer (11) Klassifikation for Brugsrum (iht. tabel Brugsrum 1) (12) Løbenummer for Brugsrum 42

43 Eksempel Kodning af en placering ++B1.S1.E3.R25 Bygning 1.Afsnit 1. Etage 3.Brugsrum 25 Placeringen kan anvendes som reference for en bygningsdels placering f.eks.: -K1.ED1.SFA1 / ++B1.S1.E3.R25 Elsystem 1. Belysningsanlæg 1. Afbryder 1 (placeret i) Bygning 1. Afsnit 1. Etage 3. Brugsrum 25 43

44 8.2.5 [==] Funktionsaspekt for brugsrum Symbol Præfiks Definition Beskrivelse Klassifikation == (lighedstegn lighedstegn) Identificerer et brugsrum i en projektspecifik funktionel sammenhæng. Aspektkoden bruges til entydigt at identificere brugsrum baseret på en funktionel projektspecifik gruppering af rummene. Den funktionelle gruppering afspejler derfor ikke den fysiske placering af brugsrummene og kan i stedet bruges til at designe et byggeri på et funktionelt plan, uden at have fastlagt det endelige (fysiske) bygningsdesign. Aspektkoden gør brug af følgende klassifikation: Projektspecifik klassifikation efter projektspecifikt inddelingskriterie fx Organisationsniveau Brugsrum 2 Syntaks Syntaksen i denne aspektkode tillader kodning af en del-af struktur med et vilkårligt antal niveauer, hvor det er muligt at definere projektspecifikke grupper af brugsrum. Aspektkoden overholder følgende hierarki for hvor i strukturen objekterne kan indgå: Brugsrumsgruppe > Brugsrum Der er ingen begrænsninger for antallet af niveauer for brugsrumsgrupper eller brugsrum, men hierarkiet skal overholdes. De projektspecifikke grupper af brugsrum kan enten klassificeres efter et projektbestemt inddelingskriterie eller efter Brugsrum 2, og det skal angives i projektets dokumentation hvilken af de to muligheder der anvendes. Individuelle Brugsrum klassificeres efter Brugsrum 2. Syntaksen for aspektkoden ser derfor således ud: Strukturniveau 1 n Syntaks - B N. B N (1) (2) (3) (4) (5) (6) B N Klassifikationsbogstav(er) Løbenummer 44

45 (1) Aspekt præfiks (2) Klassifikation for funktionel gruppe af brugsrum a. Projektspecifikt inddelingskriterie eller tabel Brugsrum 2 anvendes. (3) Løbenummer for funktionel gruppe af brugsrum (4) Separator. adskiller strukturniveauer (5) Klassifikation for Brugsrum (iht. tabel Brugsrum 2) (6) Løbenummer for Brugsrum Eksempel Med klassifikation af brugsrumgrupper efter projektspecifikt inddelingskriterie: Projektspecifikt inddelingskriterie for grupper af brugsrum: Organisatorisk opdeling Projektspecifik klassifikation af grupper af brugsrum: Bogstav Klasse Objekt K Hovedorganisation Klynge A Underorganisation Afdeling CCS klassifikation for brugsrum: Bogstav Klasse Objekt NA Kontor Cellekontor Koden for et kontor bliver da fx: ==K1.A2.NA3 Klynge 1. Afdeling 2.Kontor 3 Uden klassifikation af brugsrumgrupper efter projektspecifikt inddelingskriterie: CCS indelingskriterie for grupper af brugsrum: Overordnet funktion CCS klassifikation af grupper af brugsrum (Brugsrumstabel 1): Bogstav Klasse Objekt H Sygdomsbehandlingsrum Kirurgisk afdeling CCS klassifikation for brugsrum (Brugsrumstabel 2): Bogstav Klasse Objekt HC Vådt behandlingsrum Operationsstue Koden for en operationsstue bliver da fx: ==H2.HC4 Sygdomsbehandlingsrum 2.Vådt behandlingsrum 4 45

46 8.3 Syntaks for Gruppe 3 aspektkoder CCS tillader definition af supplerende strukturelle aspektkoder inden for de fem strukturelle aspekter. Disse aspektkoder er udelukkende gyldige inden for rammerne af et bygværk, men ikke generelt i byggebranchen. De supplerende aspektkoder kan bruges til formål der ikke er dækket af de prædefinerede CCS aspektkoder, f.eks. identifikation af objekter der ikke kan klassificeres ud fra CCS-klassifikationstabellerne og identificeres i de foruddefinerede aspektkoder fx leverancer i moduler til et byggeri der indeholder objekter på tværs af eksisterende CCS koder. Definitionen af supplerende strukturelle aspektkoder skal beskrives i projektets dokumentation. Aspektkoderne er underlagt definitionerne for de strukturelle aspekter i CCS samt kodningsreglerne i CCS, men beskriver andre supplerende strukturer. Aspektkoder gør brug af præfikstypen for det pågældende strukturelle aspekt der suppleres og tilføjer blot en eller flere karakterer til præfikset f.eks. [---] (minustegn minustegn minustegn). Regel 14: Supplerende strukturelle aspektkoder anvender altid flere end 2 ens præfikstegn (f.eks. --- ). Definition af sådanne aspektkoder skal beskrives i projektets dokumentation Supplerende strukturel aspektkoder Præfiks Definition Beskrivelse Syntaks Klassifikation Tre eller flere præfikstegn for det strukturelle aspekt der suppleres. Der gælder samme definition, som for det strukturelle aspekt der suppleres. Aspektkoden kan bruges til etablering af supplerende strukturer efter projektspecifik behov. Strukturerne der beskrives ved brug af supplerende strukturelle aspektkoder er således forskellig fra de strukturer der beskrives i de foruddefinerede CCS aspektkoder. De opstillede regler for kodning i CCS er gældende. Der anvendes samme klassifikation for bygningsdele og brugsrum som for de foruddefinerede aspektkoder i det strukturelle aspekt der suppleres. 46

47 9 Eksempler for anvendelse Eksempler på anvendelse af strukturelle aspekter. Med kodningsprincipperne i CCS adresseres de forskellige kodningsbehov brugerne af CCS kan stå over for igennem et bygværks livscyklus. Dette inkluderer både identifikation af objekter samt kommunikation af deres indbyrdes relationer såsom placering, komposition og typefællesskab. De forskellige aspektkoder vil derfor typisk anvendes på forskellige tidspunkter i et bygværks livscyklus og til forskellige formål. I de efterfølgende afsnit vises eksempler for de primære anvendelser af de strukturelle aspektkoder og anvendelsen igennem livscyklus for et objekt demonstreres. Oversigter med eksempler for anvendelse af de strukturelle aspekter kan desuden ses i Bilag D Eksempler for kodning af bygningsdele og Bilag E Eksempler for kodning af brugsrum 47

48 9.1 % Typeaspekt for bygningsdele Primær anvendelse Gruppering af bygningsdele for projektspecifikt formål vha. CCS klassifikation. Relevant ved beskrivelse af bygningsdele der har sammenfaldende egenskaber. Eksempel a) Gruppering af bygningsdele inden for objektklasser i. Bygningsdele i bygværket der er af samme type (designvariant) grupperes Vinduestype 1 (sidehængt) %QQA1 Vinduer i projektet tilhørende gruppen Vinduestype 1 %QQA1 Vinduestype 2 (tophængt) %QQA2 Vinduer i projektet tilhørende gruppen Vinduestype 2 %QQA2 Figur 5 Grupper af bygningsdele inden for klassen QQA Vindue 48

49 9.2 # Produktaspekt for bygningsdele Primær anvendelse Eksempel Identifikation af bygningsdele vha. CCS klassifikation og nummerering. Anvendes til nummerering uden kendskab til eller behov for strukturering. a) Identifikation af bygningsdele (Delsystemer og Komponenter) i et bygværk. Nummereringen er fortløbende inden for hver objektklasse.... Vindue 201 #QQA201 Vindue 202 #QQA Vindue 316 #QQA316 Vinduesparti 32 #QA32... Figur 6 - Identificering af bygningsdele 49

50 9.3 - Sammensat produktaspekt for bygningsdele Primær anvendelse Eksempel Identifikation af bygningsdele ved deres indbyrdes sammenhæng vha. CCS klassifikation og nummerering. Anvendes til sammensætning af bygningsdele ved brug af hovedsystemer, delsystemer og komponenter. Der kan for de enkelte bygningsdele anvendes samme nummerering som anvendt i produktaspektet (#). a) Kodning af bygningsdele i to Vægsystemer. Der tildeles løbenumre for objekterne inden for hver klasse og hvert struktur niveau i systemerne dvs. en relativ nummerering i forhold til tilhørsforholdet. Vægsystem 1 -B1 Vægsystem 1.Vægkonstruktion 1 -B1.UC1 Vægsystem 1. Vinduesparti 1 -B1.QA1 Vægsystem 1. Vinduesparti 1. Vindue 1 -B1.QA1.QQA1 Vægsystem 1. Vinduesparti 1. Vindue 2 -B1.QA1.QQA2 Vægsystem 12 -B12 Vægsystem 12.Vægkonstruktion 1 -B12.UC1 Vægsystem 12. Vindue 1 -B12.QQA1 Figur 7 - Kodning af bygningsdele med fortløbende nummerering inden for klasser og strukturniveauer 50

51 b) Kodning af bygningsdele i to Vægsystemer. Nummereringen af objekterne gentages fra [#] Produktaspekt for bygningsdele. Der er derfor tale om en statisk global nummerering af bygningsdelene, som er upåvirket af eventuelle ændringer i systemstrukturen. Vægsystem 1 -B1 Vægsystem 1.Vægkonstruktion 1 -B1.UC1 Vægsystem 1. Vinduesparti 32 -B1.QA32 Vægsystem 1. Vinduesparti 1. Vindue 201 -B1.QA32.QQA201 Vægsystem 1. Vinduesparti 1. Vindue 202 -B1.QA32.QQA202 Vægsystem 12 -B12 Vægsystem 12.Vægkonstruktion 6 -B12.UC6 Vægsystem 12. Vindue 316 -B12.QQA316 Figur 8 - Kodning af bygningsdele med brug af "global" statisk nummerering fra # Produktaspekt for bygningsdele 51

52 c) Kodning af bygningsdele i et Vægsystem. Der tildeles løbenumre for objekterne inden for hver klasse og hvert struktur niveau dvs. en relativ nummerering i forhold til tilhørsforholdet. Vægsystem 1 -B1 Vægsystem 1.Vægkonstruktion 1 -B1.UC1 Vægsystem 1.Vægkonstruktion 2.Beklædningsplade 1 -B1.UC2.QTL1 Vægsystem 1.Vægkonstruktion 2.Beklædningsplade 2 -B1.UC2.QTL2 Vægsystem 1.Vægkonstruktion 2.Beklædningsplade 3 -B1.UC2.QTL3 Vægsystem 1.Vægkonstruktion 2.Beklædningsplade 4 -B1.UC2.QTL4 Vægsystem 1. Vinduesparti 1 -B1.QA1 Vægsystem 1. Vinduesparti 1. Rude 1 -B1.QA1.QQB1 Vægsystem 1. Vinduesparti 1. Vindue 1 -B1.QA1.QQA1 Vægsystem 1. Vinduesparti 1. Vindue 2 -B1.QA1.QQA2 Vægsystem 1. Vinduesparti 1. Karm 1 -B1.QA1.UNA1 Vægsystem 1. Vinduesparti 1. Karm 2 -B1.QA1.UNA2 Vægsystem 1. Vinduesparti 1. Vinduesplade 1 -B1.QA1.QTC1 Figur 9 - Eksempel på opbygning koder i et hovedsystem 52

53 9.4 + Placeringsaspekt for bygningsdele Primær anvendelse Reference for placering af en bygningsdel på eller i en anden bygningsdel. Eksempel a) En afbryders placering ift. den plade (bygningsdel) den er monteret i medtages som reference i kodningen af afbryderen. El-system 1. Belysningsanlæg 1. Afbryder 1 (Placeret på/i) Vægsystem 1.Vægkonstruktion 1. Beklædningsplade 3 -K1.ED1.SFA1 /+B1.UC1.QTL3 Vægsystem 1. Vægkonstruktion 1. Beklædningsplade 1 -B1.UC1.QTL1 Figur 10 - Kodning af en afbryder, med reference for placering ift. anden bygningsdel. 53

54 9.5 = Funktionsaspekt for bygningsdele Primær anvendelse Identifikation af bygningsdele ved deres funktionelle sammenhæng, uafhængig af fysisk implementering, vha. CCS klassifikation og nummerering. Anvendes til prædesign og/eller systemdesign af hovedsystemer og delsystemer, fx i form af procesdiagrammer og konstruktive systemer. Eksempel a) Prædesign: I et bygværk skal der indgå en række pumpeanlæg af samme design. Der laves i projektet ét design for alle disse anlæg og de indgående bygningsdele identificeres vha. [=] Funktionsaspekt for bygningsdele. Designet implementeres senere rent fysisk i forskellige af bygværkets Hovedsystemer. Pumpeanlæggene i disse systemer identificeres vha. [#] og [-], og de har alle [=]-koden for det prædesignede pumpeanlæg som reference. =GA1 =BPB1 =PGD1 =PGD2 =QMA3 =QMA4 =QMA1 =HQA1 =RMA1 =QMA2 =MAA1 =GPA1 Pumpeanlæg 1 =GA1 Pumpeanlæg 1.Pumpe 1 =GA1.GPA1 Pumpeanlæg 1.Elektromotor 1 =GA1.MAA1 Pumpeanlæg 1.Afspærringsventil 1 =GA1.QMA1 Pumpeanlæg 1.Afspærringsventil 2 =GA1.QMA2 Pumpeanlæg 1.Afspærringsventil 3 =GA1.QMA3 Pumpeanlæg 1.Afspærringsventil 4 =GA1.QMA4 Pumpeanlæg 1.Kontraventil 1 =GA1.RMA1 Pumpeanlæg 1.Filter 1 =GA1.HQA1 Pumpeanlæg 1.Trykswitch 1 =GA1.BPB1 Pumpeanlæg 1.Trykviser 1 =GA1.PGD1 Pumpeanlæg 1.Trykviser 2 =GA1.PGD2 Figur 11 - Eksempel på funktionel kodning af prædesigns. 54

55 b) Funktionelle systemer vs. Fysiske systemer: Et prædefineret pumpeanlæg =GA1 (se Figur 11) skal forsyne et bygværk med brugsvand og får derfor betegnelsen =F1.GA1. Det funktionelle pumpeanlæg er fysisk opdelt. De fleste af Komponenterne sidder samlet i et fysisk Pumpeanlæg -F3.GA1, men Afspærringsventilen =F1.GA1.QMA2 sidder i et tilstødende Blandeanlæg -F3.HA1 hvor den er den tolvte ventil i blandeanlægget. I Figur 12 ses kodningen for to af ventilerne. Bemærk at de funktionelt set er en del af det samme funktionelle pumpeanlæg, men at de fysisk er en del af to forskellige systemer. =H1.GA1.QMA1/-H3.HA1.QMA1 =H1.GA1.QMA2/-H3.GA1.QMA12 Figur 12 - Eksempel på bygningsdele der tilhører det samme funktionelle system, men forskellige fysiske konstruktioner. 55

56 9.6 %% Typeaspekt for brugsrum Primær anvendelse Gruppering af brugsrum for projektspecifikt formål vha. CCS klassifikation. Relevant ved konfigurering og beskrivelse af brugsrum. Eksempel a) Brugsrum i bygværket der er af samme type (designvariant) grupperes dvs. brugsrum i bygværket tildeles altså en reference for hvilken gruppe af Brugsrum de tilhører. Baderumstype 1 (Basis) %%BA1 Baderum i projektet tilhørende gruppen Baderumstype 1 %%BA1 Baderumstype 2 (Luksus) %%BA2 Baderum i projektet tilhørende gruppen Baderumstype 2 %%BA2 Figur 13 - Grupper af brugsrum inden for klassen BA - Baderum 56

57 9.7 ## Produktaspekt for brugsrum Primær anvendelse Identifikation af brugsrum vha. nummerering. Anvendes til nummerering uafhængig af brugsrummets placering. NB! Må ikke forveksles med egenskaben rumnummer. Eksempel a) Identifikation af brugsrum i et bygværk. Nummereringen er fortløbende og rummene klassificeres ikke. Figur 14 - Identifikation af brugsrum uafhængigt af bygværkets kompositoriske sammenhæng. 57

58 Sammensat produktaspekt for brugsrum Primær anvendelse Eksempel Identifikation af et brugsrum vha. nummerering i forhold til den bygning, afsnit (option) og etage som det indgår i. Anvendes når placering af et brugsrum i en bygning er kendt. a) Brugsrum i en bygning identificeres ift. hvilken etage og bygning de er en del af. Figur 15 - Identifikation baserest på bygværkets kompositoriske sammenhæng. 58

59 Placeringsaspekt for brugsrum Primær anvendelse Placering af en bygningsdel i et brugsrum. Placering af en bygningsdel på en etage. Placering af en bygningsdel i et afsnit. Placering af en bygningsdel på eller i en bygning. Placering af et brugsrum i et brugsrum. Eksempel a) En afbryders placering ift. det rum (brugsrum) den er monteret i medtages som reference i kodningen af afbryderen. El-system 1. Belysningsanlæg 1. Afbryder 1 (Placeret i) Bygning 1.Etage 1. Rum 1 -K1.ED1.SFA1 /++B4.E1.R1 ++B4.E1.R3 ++B4.E1.R2 ++B4.E1.R1 Figur 16 - Brugsrum brugt som stedreference. I de tilfælde hvor brugsrum lægges sammen, opdateres ++ koden så bygningsdelenes placering bliver ift. det nyligt skabte brugsrum. 59

60 b) Et brugsrum (--B1.E1.R1) opdeles, så der opstår to nye brugsrum (--B1.E1.R2 og --B1.E1.R3). De to nye brugsrum får begge en placeringsreference (++B1.E1.R1), der viser at de er placeret i det tidligere brugsrum. På denne vis kan linket til det tidligere brugsrum bibeholdes i bygværkets dokumentation. --B1.E1.R1 Figur 17 - Ikke opdelt brugsrum --B1.E1.R2 ++B1.E1.R1 --B1.E1.R3 ++B1.E1.R1 Figur 18 - Brugsrum efter opdeling 60

61 c) Et brugsrum (--B1.E1.R12) nedlægges, og bliver en del af et andet eksisterende brugsrum (--B1.E1.R11). I dokumentationen på det nedlagte brugsrum (--B1.E1.R12) noteres en placeringsreference (++B1.E1.R11). På denne vis kan linket til det tidligere brugsrum bibeholdes i bygværkets dokumentation. Dette er specielt med tanke for de driftsystemer der ikke har mulighed for at opdatere kodningen på bygningsdele. --B1.E1.R11 --B1.E1.R12 Figur 19 - Brugsrum før sammenlægning --B1.E1.R11 Beskrivelse Udgået -- Sammensat produktaspekt ++ Placeringsaspekt Kontor 1 --B1.E1.R11 Kontor 2 --B1.E1.R12 ++B1.E1.R11 Figur 20 - Brugsrum efter sammenlægning 61

62 9.10 == Funktionsaspekt for brugsrum Primær anvendelse Eksempel Identifikation af brugsrum ved deres funktionelle sammenhæng vha. projektspecifik klassifikation samt CCS brugsrumsklassifikation og nummerering. Anvendes til funktionelt at sammensætte brugsrum ved deres tilhørsforhold til grupper af rum. 1.) I et projekt specificeres tre funktionelle brugsrum (Kontorer) før det vides hvordan den fysiske udformning af bygværket skal være. Klynge 1. Afdeling 1. Kontor 1 ==K1.A1.NA1 Klynge 1. Afdeling 1. Kontor 2 ==K1.A1.NA2 Klynge 1. Afdeling 2. Kontor 1 ==K1.A2.NA1 Senere i projektet konstrueres de funktionelle brugsrum og fordeles i bygværket som vist i Figur 21. Klynge 1.Afdeling 1 ==K1.A1 Klynge 1.Afdeling 2 ==K1.A2 Klynge 1.Afdeling 1. Kontor 1 ==K1.A1.NA1 Klynge 1.Afdeling 1. Kontor 2 ==K1.A1.NA1 Klynge 1.Afdeling 2. Kontor 1 ==K1.A2.NA1 Figur 21 - Brugsrums funktionelle kodning. 62

63 9.11 Kodning igennem livscyklus for en bygningsdel Der er flere forskellige måder at anvende de strukturelle aspektkoder på, afhængigt af behov. Figur 22 illustrerer kodegruppens opfattelse af hvornår de forskellige Strukturelle Aspekter oftest vil være relevante for kodning af bygningsdele, men anvendelsen er ikke begrænset hertil. Drift og vedligeholdelse Idé/program Byggeproduktion Dispositionsforslag Produktionsforberedelse Projektering Udførelseskalkulation % # = Figur 22 - Eksempel på anvendelse af strukturelle aspektkoder for bygningsdele I det efterfølgende gives et eksempel på kodning af en bygningsdel igennem et tænkt livscyklusforløb. Eksemplet illustrerer princippet og er viser én af flere mulige anvendelser. Idé/program Der defineres en projektspecifik vinduestype (sidehængte vinduer) Strukturelt Aspektkode Betydning aspekt % %QQA1 Vinduestype 1 (sidehængt) # == Tabel 3 - Der defineres en projektspecifik type af vinduer Dispositionsforslag Ingen ændring 63

64 Projektering Et vindue indsættes i projektet. Det tilhører gruppen af vinduer af typen Vinduestype 1 (%QQA1). Vinduet er nr. 201 i bygværket (#QQA201) og indsættes som en del af et vinduesparti i et vægsystem (-B1.QA32.QQA201). Vinduet er fysisk placeret i brugsrum 1 på første etage i bygning 4 (++B4.E1.R1). Strukturelt Aspektkode Betydning aspekt % %QQA1 Vinduestype 1 (sidehængt) # #QQA201 Vindue nr B1.QA32.QQA201 Vægsystem 1.Vinduesparti 32.Vindue B4.E1.R1 Bygning 4. Etage 1. Brugsrum 1 == Tabel 4 - Koderne for et vindue i bygværket Udførelseskalkulation Ingen ændring Produktionsforberedelse Ingen ændring Byggeproduktion Ingen ændring Drift og vedligeholdelse Bygværket renoveres og det besluttes at udskifte alle vinduer. Det kodede vindue ændres til et vindue af typen %QQA4 (lavenergi, ekstra lydisolering). Strukturelt Aspektkode Betydning aspekt % %QQA4 Vinduestype 4 (lavenergi, ekstra lydisolering) # #QQA201 Vindue nr B1.QA32.QQA201 Vægsystem 1.Vinduesparti 32.Vindue B4.E1.R1 Bygning 4. Etage 1. Brugsrum 1 == Tabel 5 - Det kodede vindue skifter type 64

65 9.12 Kodning igennem livscyklus for et brugsrum Da der er adskillige forskellige måder at anvende de Strukturelle Aspektkoder på afhængigt af behov, vil det være omsonst at forsøge at beskrive dem alle. Figur 23 viser kodegruppens opfattelse af hvornår de forskellige strukturelle aspekter oftest vil være relevante for kodning af brugsrum. Drift og vedligeholdelse Idé/program Byggeproduktion Dispositionsforslag Produktionsforberedelse Projektering Udførelseskalkulation %% ## == Figur 23 - Eksempel på anvendelse af strukturelle aspektkoder for brugsrum. I det efterfølgende gives et eksempel på kodning af en bygningsdel igennem et tænkt livscyklus forløb. Idé/program Der laves et funktionelt design af bygværket. En af afdelingerne i organisationen, der skal bruge bygværket, har brug for et møderum. Inddelingskriteriet i det funktionelle design er organisatorisk. Strukturelt Aspektkode Betydning aspekt %% %%GA1 Møderum type 1 ## == ==K1.A1.GA1 Klynge 1.Afdeling 1.Møderum 1 Tabel 6 - Brugsrummets koder i Idé/program fasen Dispositionsforslag Der disponeres over de fysiske brugsrum i bygværket. Møderummet tildeles en # kode for at kunne identificere rummet selv om der laves hyppige ændringer i bygværkets layout. 65

66 Strukturelt Aspektkode Betydning aspekt %% %%GA1 Møderumstype 1 ## ##17 Rum nr == ==K1.A1.GA1 Klynge 1.Afdeling 1.Møderum 1 Tabel 7 - Brugsrummets koder i Dispositionsforslag fasen Projektering Møderummet placeres endeligt på anden etage i bygning 1. Møderummet er det tolvte brugsrum på denne etage. Strukturelt Aspektkode Betydning aspekt %% %%GA1 Møderumstype 1 ## ##17 Rum nr B1.E1.R12 Bygning 1.Etage 1.Brugsrum == ==K1.A1.GA1 Klynge 1.Afdeling 1.Møderum 1 Tabel 8 - Brugsrummets koder i Projektering fasen (1) Udførelseskalkulation Ingen ændring af objektets kode Produktionsforberedelse Ingen ændring af objektets kode Byggeproduktion Ingen ændring af objektets kode Drift og vedligeholdelse I forbindelse med en reorganisering af organisationen der bruger bygværket er møderummet blevet overflødigt. Brugsrummet omdannes derfor til et kontor tilhørende gruppen af kontorer Kontortype 3 (%%NA3), så det kan bruges som kontor for den nye chef Referencen til det oprindelige funktionelle Møderum (==K1.A1.GA1) kan noteres i kontorets dokumentation. Strukturelt Aspektkode Betydning aspekt %% %%NA3 Kontortype 3 ## ##17 Rum nr B1.E1.R12 Bygning 1.Etage 1.Brugsrum == Tabel 9 - Brugsrummets koder i drift og vedligeholdelse fasen 66

67 Kontoret opdeles senere så der opstår to nye brugsrums (##41 og ##42). De to nye kontorer er også af typen Kontortype 3 og de bliver hhv. det 13. og 14. brugsrum på etagen. De to nye brugsrum får samtidigt en placeringsreference ++ der indikerer at de er placerede i det tidligere kontor. Således kan linket til det tidligere kontor bibeholdes. Strukturelt Aspektkode Betydning aspekt %% %%GA1 Møderumstype 1 ## ##17 Rum nr B1.E1.R12 Bygning 1.Etage 1.Brugsrum == Tabel 10 Koderne for det gamle kontor Strukturelt Aspektkode Betydning aspekt %% %%NA3 Kontortype 3 ## ##41 Rum nr B1.E1.R13 Bygning 1.Etage 1.Brugsrum B1.E1.R12 Bygning 1.Etage 1.Brugsrum 12 == Tabel 11 Koderne for det første kontor opstået ved opdeling af det gamle kontor Strukturelt Aspektkode Betydning aspekt %% %%NA1 Kontortype 3 ## ##42 Rum nr B1.E1.R14 Bygning 1.Etage 1.Brugsrum B1.E1.R12 Bygning 1.Etage 1.Brugsrum 12 == Tabel 12 Koderne for det første kontor opstået ved opdeling af det gamle kontor 67

68 10 IT implementering 10.1 Tidlig afklaring af It-egnethed. For at sikre kodesyntaksens It-egnethed var en tidlig afklaring med et udvalg af branchens It-leverandører vigtig for kodegruppens fremadrettede arbejde. Dette møde blev koordineret gennem IT-leverandørgruppen i bips Forløbet Følgende It-leverandører var indbudt til introduktionsmøde d. 6/9-2011: PM El-beregning, Kalkia IGE+XAO Danmark, CADdy++ CodeGroup, Sigma Tekla Danmark, Tekla Byggecentrum, V&S Prisdata NTI CADcenter, Solibri MagiCAD Danmark, MagiCAD 3dbyggeri Danmark, Digitalt Produktkatalog Betech Data, Autodesk Revit På mødet blev deltagerene introduceret til kodegruppens forudsætninger og mål samt ændringer til kodens struktur i forhold til DBK Følgende emner blev diskuteret på mødet: Type-af klassifikation med entydig brug af bogstaver Mekanismen Klassifikation i del-af og type-af RDS ID koder Kodens opbygning Skilletegn Præfiks Kode eksempler It-implementering Efterfølgende blev alle deltagerene opfordret til at returnere et spørgeskema (se skemaet i Bilag I Spørgeskema til IT-leverandørgruppen i bips) samt eventuelt kommentarer til kodegruppen for at sikre en entydig afdækning af de tekniske overvejelser i kode strukturen. Kodegruppen modtog input fra 7 It-leverandørerne Konklusion på introduktionsmøde It-Leverandørenes samlede reaktion var overvejende positiv og specielt den selvstændige Type-af klassifikation blev fremhævet som en klar forbedring i forhold til de udfordringer der er ved It-implementeringen af DBK Det blev udtrykt at Typeaspektet suppleret med veldefinerede egenskaber vil 68

69 kunne yde den information der er nødvendig for at kunne prissætte en bygningsmodel. Ingen af de returnerede svar gav anledning til ændringer i den fremlagte kodestruktur. Generelt udtrykte It-leverandørerne at de ønsker at indgå aktivt i udviklingen og afprøvningen af cuneco s standarder. It-leverandørerne kom med følgende opfordringer til at forbedre forudsætningerne for den efterfølgende It-implementering. Muligheden for at kode del-af strukturen uden tvungen brug af systemer Konkrete eksempler på anvendelsen af CCS En fælles platform (evt. web service) udviklet og drevet af cuneco Afprøvningsprojekter Tidsplan for de færdige standarder De tekniske dele af rapporten oversat til Engelsk Kode strukturen beskrevet som kode notationer, følgende mulige standarder blev nævnt o Extended Backus-Naur Form, EBNF o Regulære udtryk, Regexp 10.4 Eksempler på CCS i EBNF-format CCS kodens syntaks kan IT teknisk f.eks. beskrives i Extended Backus-Naur Form (EBNF - ISO 14977) eller lignende relevante metasyntakser. Nedenstående eksempel i EBNF format illustrerer kun princippet og skal detaljeres inden det udleveres som brugbart eksempel. DBK kode = RDS id kode, { /, RDS placerings kode}, /, Project type kode, /, Øvrige koder ; RDS id kode = -, DBK system klasse, DBK sub system klasse, løbenummer,., objektklasse, løbenummer ; RDS placerings kode = ++, DBK system klasse, DBK sub system klasse, løbenummer,., objektklasse, løbenummer ; Project type kode = #, Projekt klassificering, løbenummer ; Projekt klassificering = bogstaver ; DBK system klasse = heltal ; DBK sub system klasse = bogstaver ; Løbenummer = heltal; heltal = ciffer, {ciffer} ; bogstaver = bogstav {, bogstav} ; nul = 0 ; ciffer = positivt ciffer nul ; positivt ciffer = ; bogstav = a b c d e f g h i j k l m n o p q r s t u v x y z ; 69

70 11 Relation til andre standarder 11.1 ISO (2001 / 2013) CCS relation til ISO (2001) (under revision ) ISO : Building constructions - Organisation of information about construction works. Part 2 - Framework for classification of information. ISO er under revision, og cuneco deltager via Dansk Standard i udviklingen af den nye version, der udsendes i en officiel Committee Draft (CD) version i begyndelsen af At arbejdet funderes på ISO betyder, at der er en international anerkendt ramme for klassifikation, som CCS kan placeres inden for. ISO er den grundlæggende standard inden for klassifikation af information i byggeriet. Standarden definerer, at ressourcer (construction ressource) anvendes i en proces (construction process) til at skabe resultater (construction result) og at ressourcer, processer og resultater alle har egenskaber (construction property) Som det fremgår af titlen på standarden, omhandler ISO klassifikation. Der kan oprettes klassifikationstabeller inden for ressourcer, processer, resultater og egenskaber. Standarden beskriver hvilke forskellige kriterier der kan anvendes til at skabe klassifikationstabellerne i de forskellige områder. Figur 24 herunder viser sammenhængen mellem de 4 domæner. Figuren er et uddrag af den nye udgave af ISO figur 1 (ændringer kan forekomme). 70

71 Construction result results in Construction process uses Construction resource has Construction property Figur 24 - De 4 grundlæggende domæner i ISO [Uddrag af ny ISO , figur 1. Ændringer kan forekomme i den endelige udgave.] Standarden anvendes således, at man i de enkelte lande kan udvikle egne klassifikationstabeller, dvs. at der er metodefrihed for hvordan man eksakt vil implementere standarden. Hensigten er derfor ikke at hvert land har identiske klassifikationstabeller, men at man inden for hvert område kan mappe til andre landes respektive tabeller, såfremt de følger rammerne fra ISO Standarden omhandler ikke kodeprincipper for hvorledes klassifikationstabeller eller deraf afledte koder for klasser skal udformes. Dette er ligeledes op til de enkelte lande at udforme. CCS arbejdet med at udforme koder for bygningsdele er derfor kun delvist omfattet af ISO i form af principperne for klassifikationstabellerne, men ikke i form af selve koderne eller måden som de udformes og sammensættes på, fx til en identificerende kode. Helt konkret vil enhver CCS kode skulle anvendes inden for ét af de fire domæner: ressourcer, processer, resultater og egenskaber. Denne koderapport omhandler kun de koder der skal anvendes inden for resultatdomænet til at kode bygningsdele og brugsrum. Klassifikationstabeller til bygningsdele baseres på anbefalingerne i ISO , og udformes efter de retningslinjer der er anført heri. 71

72 11.2 ISO/IEC (2009) CCS relation til ISO/IEC standardserien. ISO/IEC 81346: Industrielle systemer, installationer og udstyr samt industriprodukter - Struktureringsprincipper og referencebetegnelser. Del 1: Generelle krav. Del 2: Klassifikation af objekter og koder for klasser NOTE: En referencebetegnelse er en identificerende kode for et objekts forekomst i et givent system. ISO/IEC beskriver regler for udarbejdelse af identificerende koder (del 1) samt definerer en grundlæggende tabel for klassificering af objekter (del 2). Som nævnt i afs er ISO den grundlæggende rammestandard for CCS med hensyn til klassifikation af information. ISO/IEC standardserien er en forudsætning for udvikling af CCS, da man dermed sikrer at CCS koder er baseret på internationalt anerkendte teknikker for udformning af koder. I lighed med Danmark, har Tyskland valgt at anvende kodeprincipperne fra i deres nationale kodesystem for bygningsdele, se afs ISO/IEC standardserien beskriver reglerne for hvordan information struktureres så det kan anvendes til kodning af objekter, hvilket ikke er omfattet af ISO , samt giver en konkret anvisning på klassifikationstabeller efter funktion, hvor ISO blot beskriver at man bør lave tabeller af bygningsdele, baseret på funktion. Samspillet mellem ISO , ISO/IEC og CCS illustreres med Figur 25 på næste side. 72

73 CCS brugsrum klassifikation CCS tillæg Kodeprincipper ISO/IEC Klassifikation og identifikation af brugsrum vha. strukturelle aspekter ( m. lille CCS tillæg) & CCS klassifikation defined by Construction space part of aggregate of Construction complex CCS tillæg Kodeprincipper ISO/IEC Construction result Construction entity results in part of CCS bygningsdele Construction process Construction element part of Klassifikation ISO/IEC uses Construction resource Klassifikation og identifikation af bygningsdele vha. strukturelle aspekter ( m. CCS tillæg) & klassifikation ( med CCS tillæg) has Construction property [Uddrag af foreløbig udgave af ISO figur 1.] Figur 25 - Sammenhæng mellem ISO , ISO/IEC og CCS NOTE: Figuren i den sorte indramning er et uddrag af den kommende version af ISO , figur 1. Ændringer kan forekomme. ISO/IEC del 1 og 2 er anvendt i CCS i det omfang det har været teknisk muligt, mens andre ønsker og tekniske krav har været nødvendige at tilføje. Fx definerer blot hvad præfiks =, +, - og # anvendes til, mens der i CCS var et særbehov for at introducere % som et ekstra præfiks til håndtering af typer. Tilsvarende er klassifikationstabellerne i baseret på funktion, men stopper ved et todelt klassifikationstrin, mens der i CCS er behov for et tredje trin. Endvidere er der betegnelser og termer i klasserne fra der mest er rettet mod elektroteknik og mekanik, men som med en modifikation nu også kan omfatte de konstruktive bygningsdele (vægkonstruktion, dør, vindue etc.). Det skal bemærkes, at klassifikationsprincippet fra ISO/IEC følger anbefalingerne i ISO DIN (2010) CCS relation til DIN DIN : Kennzeichnungssystematik für technische Produkte und technische Produktdokumentation Teil 12: Bauwerke und Technische Gebäudeausrüstung I lighed med CCS, har Tyskland for nyligt ( ) introduceret kodeprincipper baseret på ISO/IEC standardserien i deres byggesektor. 73

74 Langt de fleste kodeprincipper er ens med CCS, herunder anvendelse af præfikstegn. CCS er dog mere fleksibelt og udbygget end den tilsvarende DIN: Fx omhandler CCS også brugsrum på same niveau som bygningsdele, hvilket DIN standarden ikke gør. Endvidere har CCS en mere omfattende og gennemarbejdet tabel med bygningsdele, herunder især bygningsdele der er vigtige for konstruktionsingeniører og arkitekter, end den tilsvarende DIN. De grundlæggende klassifikationsbogstaver der anvendes af CCS hhv. DIN er ens, da de begge er baseret på ISO/IEC cuneco er opmærksomme på, at der er planer om at udgive DIN som en international ISO/IEC standard ISO 4157 (1999) CCS relation til ISO ISO 4157: Teknisk tegning. Bygningstegninger. Del 1: Betegnelsessystemer. Bygninger og dele af bygninger. Del 2: Rumnavne og -numre. Del 3: Rumidentifikatorer. ISO 4157 standardserien giver anvisninger på hvordan en bygning og dens etager / rum kan nummereres med henblik på anvendelse i bygningstegninger. Anvendelsesområdet er dermed begrænset i forhold til fx de behov som BIM stiller i dag, og standarden er kandidat til en opdatering på flere punkter, hvilket der dog p.t. ikke er planer om. De grundlæggende principper fra ISO 4157, fx at man anskuer bygning - etage - rum håndteres af CCS vha. -- aspektet. Se afs ISO 4157 indeholder ikke anvisninger på klassifikation af rum. Der henvises endvidere til CCS rapporten om klassifikation af brugsrum, der er uden for emneområdet af denne rapport SFB (1950+) CCS relation til SfB. SfB-systemet (SfB = Samarbetskomitén för Byggnadsfrågor) blev oprindeligt udviklet for klassificering og kodning af den svenske standardbeskrivelse Bygg-AMA, og anvendtes her første gang i [Kilde: 74

75 SfB anvendes i stor grad i Danmark. Anvendelsesgranden er meget overordnet og ikke homogen, fx har de enkelte aktører forskellige fortolkninger af hvordan systemet anvendes og til hvad, dvs. at SfB findes i et utal af varianter i Danmark. CCS bliver den fælles afløser for de mange forskellige anvendelser der findes af SfB. Denne rapport anbefaler, at der i det omfang det er muligt udarbejdes overordnede mappingtabeller mellem SfB og CCS. Dette er kun muligt i et vist omfang, idet CCS er mere omfattende end SfB, og endvidere er de to systemer udarbejdet til forskellige formål: SfB er udarbejdet med det formål at kode og klassificere en beskrivelse mens CCS er udarbejdet til at understøtte både digitale og analoge processer i arbejdet med bygningsmodeller (2D, 3D, diagrammer, beregninger, beskrivelser etc.). I lighed med at der kan udarbejdes mappingtabeller fra SfB til CCS, vil det også være muligt at mappe andre kodestrukturer fra forskellige bygherrer / aktører til CCS efter behov DBK (2006) CCS relation til DBK. DBK er udarbejdet af bips i DBK er en forkortelse for Dansk Bygge Klassifikation og blev udgivet i Hensigten med DBK var at danne et fælles grundlag for organisering og udveksling af informationer i byggeriet. DBK blev udviklet i samarbejde med en lang række aktører i byggebranchen, hvor de fleste fag var repræsenteret. DBK introducerede som det første system en del-helhed tankegang, der adskilte sig fra andre landes traditionelle klassifikationstabeller ved at organisere alle bygningsdele i et hierarki, hvor forskellige bygningsdele pr. definition var en del af en større helhed. DBK s kodeprincipper blev baseret på tal, og bevirkede bl.a. at ens bygningsdele (fx isolering) skiftede kode, alt efter hvilken overordnet bygningsdel den var en del af, hvilket rent IT teknisk var uhensigtsmæssigt. Det bemærkes, at del-helhed relationer ikke er et klassifikationssystem i traditionel forstand, idet traditionel klassifikation er baseret på type-af relationer. Del-helhed anvendes som udgangspunkt til at håndtere helheder (fx anlæg eller større systemer) frem for enkeltdele. DBK blev gjort obligatorisk via IKT bekendtgørelsen, og er derfor blevet anvendt på større offentlige projekter. Del-af strukturen fra DBK er med til at skabe overblik over de bygningsdele der indgår, og dermed et samlet overblik over antallet og typerne af bygningsdele. Dermed er der også hø- 75

76 stet de første erfaringer med DBK og ikke mindst styrker og svagheder ved DBK. DBK indeholder i sine nuværende tabeller en meget stor mængde af anvendte betegnelser for bygningsdele. CCS genanvender samtlige disse betegnelser som grundlag til udvikling af de nye CCS klassifikationstabeller, hvoraf de afledte koder indgår i de i denne rapport nævnte kodeprincipper, og kan genkendes via anvendelsen af bogstaver. Der henvises i øvrigt til projektgruppen der udarbejder klassifikationstabeller for bygningsdele, og som ikke er en del af denne rapport. De i DBK anvendte præfikstegn (fx - og + ) genanvendes i CCS, men er blevet ændret, videreudviklet og veldefineret, således at anvendelsesformen for alle aspekter nu er konsistente og endvidere kan opfylde både krav til analog anvendelse og krav til digital anvendelse i fx IT systemer. CCS er derfor et nyt system, hvor tavlen er visket ren fra DBK, men på den anden side genanvender de principper der har vist sig effektive ved afprøvning i DBK, fx del-helheds relationerne. CCS er udvidet og ændret i forhold til DBK, og er derfor et langt mere fleksibelt system, der tillader forskellige former for anvendelse set i forhold til DBK. Det har været centralt for arbejdet med CCS, at forskellige eksisterende kodesystemer, herunder DBK, skal kunne mappes til CCS i så stort omfang som muligt Forvaltnings Klassifikation (2009) CCS relation til Forvaltnings Klassifikation. FK er udarbejdet af Landsbyggefonden. Ministeriet for By, Bolig og Landdistrikter har (medvirkning fra 1. februar 2012) ændret bekendtgørelsen om drift af almene boliger mv. Dette indebærer, at Forvaltnings Klassifikation med tilhørende kontoplaner for konto 115 og 116 nu skal indarbejdes. [Kilde: Klassifikationstabellerne i forvaltningsklassifikation er udarbejdet efter et andet princip end CCS og til et andet formål end CCS. Hvor CCS er designet til at dække hele livscyklussen for bygningsdele og brugsrum, er Forvaltningsklassifikation (som navnet indikerer) designet til forvaltningsdelen af almene boliger. Denne rapport anbefaler, at der i det omfang det er muligt, udarbejdes mappingtabeller mellem Forvaltningsklassifikation og CCS, idet CCS sikrer at medtage alle bygningsdele fra Forvaltningsklassifikationstabellerne i CCS tabellerne. 76

77 11.8 IFC/IFD CCS relation til IFC og IFD. IFC er et IT-neutralt udvekslingsformat (og ikke et kodesystem), der bl.a. anvendes til udveksling af informationer mellem forskellige IT-platforme, og som fordrer at information skabes digitalt (dvs. at manuelle informationer ikke understøttes). IFD er et internationalt bibliotek over de forskellige termer som forskellige lande anvender om forskellige objekter. Såfremt man er enig i fx den engelske term for en bygningsdel, kan man lægge en tilsvarende dansk term ind i IFD, og dermed mappe til andre landes tilsvarende betegnelser. Det bemærkes, at de enkelte lande ikke ser ens på samme bygningsdele og derfor er en direkte mapping ikke altid mulig. Kodemekanisme i CCS virker sammen med både IFC og IFD på følgende måde: CCS-koden indeholder en lang række delkoder som har forskellig betydning, og som entydigt kan genkendes på et præfiks (fx %, #, =, +, -). Ét af formålene med koden er at identificere forekomsten af et givent objekt i et byggeris livscyklus. CCS koden kan bæres af IFC, som én af mange oplysninger (egenskaber) om et objekt. IFC behøver ikke kende betydningen af koden (dvs.at kunne de-kode den), men skal blot overfører CCS koden mellem to parter. IFC er designet til at blive anvendt 100% digitalt, mens CCS både kan anvendes manuelt ( analogt ) og digitalt. IFD er et internationalt bibliotek med termer for bygningsdele. CCS vil kunne bidrage med flere termer og danske betegnelser til IFD, inklusive definitioner til det eksisterende bibliotek. IFD er ikke et kodesystem, og dermed ikke i konflikt med CCS koder. Når et objekt kodes med den nye CCS klassifikations kode (Type-af) vil objektet også kunne kodes med begrebets IFD-GUID. Ved en efterfølgende eksport fx via IFC vil denne IFD-GUID blive båret med til andre systemer som kan de-kode CCS typen i forhold til begrebet og derved oversætte det til et andet lands klassifikationstabeller. De terminologier som CCS udvikler og benytter om bygningsdele kan indarbejdes i IFD, lige som der kan laves præcise specifikationer på hvilken parameter CCS-koden benytter i IFC ved udveksling mellem forskellige IT systemer. 77

78 Figur 26 herunder illustrerer samspillet mellem CCS, IFC og IFD ved udveksling af data mellem brugere Bygningsdel Bygningsdel Bygningsdel Vægsystem 1. Vægkonstruktion 1. Dør 1 -B1.UG1.QQC1 Egenskaber: IFC Værdi: B1.UG1.QQC vHRQ8oT0Hsm051Mm008 IFD Building Smart Dictionary 3vHRQ8oT0Hsm051Mm008 Figur 26 - CCS og relationer til IFC/IFD 11.9 OmniClass, BSAB, Uniformat m.fl. CCS relation til andre landes klassifikationsstandarder. Under arbejdet med udvikling af CCS har det været en forudsætning at studere andre landes tilsvarende klassifikationssystemer. Fælles for fx OmniClass (USA), BSAB (Sverige) og Uniformat (Storbritannien) er, at deres systemer er udviklet ud fra et andet princip end CCS og til et andet formål. Typisk medtager disse systemer forskellige egenskaber for de forskellige objekttyper, der inddrages som successivt inddelingskriterie for objekterne. Konsekvensen er, at klassifikationssystemerne bliver endog særdeles omfattende når de sammenlignes med CCS. Se også Figur 2 i denne rapport, der illustrerer princippet. De nævnte klassifikationssystemer har til formål at klassificere objekter (bygningsdele og brugsrum), og ikke som CCS både at identificere og klassificere bygningsdele og brugsrum. Derfor er der også tale om to forskellige tilgange til håndtering af kompleks information og deres sammenhænge. CCS har valgt et stabilitetsprincip, der bevirker at klassen og koden for denne er helt stabil set i livscyklus Dette gøres bl.a. ved at anvende et særligt inddelingskriterie i klassifikationstabellerne, således at CCS koden er meget enkel og forbliver intakt uanset om egenskaberne ændres (fx ved valg materialevalg). I modsætning til de her nævnte systemer, knyttes egenskaber i CCS separat til et objekt, der er identificeret ved en sammensætning af præfiks, bogstavkode for klasse og et løbenummer. 78

79 Som eksempel på forskellen kan nævnes en væg, der i Uniformat kan klassificeres på 72 forskellige måder (inklusive kendte egenskaber, herunder materialevalg), mens samme væg kun kan klassificeres på 1 måde i CCS, og øvrige informationer behandles som egenskaber. CCS sikre bl.a. dermed at objekter kan forkodes i fx objektbiblioteker, og at der kan anvendes en kode der er velegnet til menneskelig genkendelse. Såfremt de øvrige landes klassifikationssystem i lighed med CCS følger anvisningerne i ISO , kan der mappes mellem CCS og andre klassifikationer, evt. med mellemkomst af IFD. Se afsnit Det skal bemærkes, at de her nævnte klassifikationssystemer ikke opfylder stabilitetsprincippet, som CCS anser for væsentligt. 79

80 12 Sammenfatning Sammenfatning af rapporten og de væsentligste konklusioner. Denne revision af rapporten er 2. udgave, der har medtaget og indarbejdet de relevante høringskommentarer fra den offentlige høring i Rapporten og dermed kodeprincipperne fremstår derefter mere homogene og veldefinerede til brug for en fornyet offentlig høring, der afvikles i CCS er designet til at være ét fælles kodesystem, som er fælles for alle faggrupper gennem hele livscyklus. CCS relationer til øvrige internationale og nationale standarder er beskrevet i relevant omfang. Kodesystemet anvender en kombination af præfiks (tegn for et specifikt strukturelt aspekt), klassifikation (bogstaver) og løbenummer (tal) til at skabe en identificerende kode for bygningsdele og brugsrum Koden er designet så den umiddelbart kan genkendes af mennesker, og endvidere kan tolkes af IT systemer til brug for udveksling af informationer. cuneco har truffet aftale med et parterne i DNV Gødstrup projektet om test af CCS kodeprincipper og deraf afledte navngivning af bygningsdele og rum. De i Gødstrup projektet anvendte IT systemer har forpligtet sig til at implementere og understøtte CCS kodeprincipper, herunder klassifikation og anvendelse af præfikstegn. 80

81 13 Bilag A - Termer og definitioner Definitioner af anvendte termer - input til CCS begrebskatalog. Følgende centrale termer anvendes i denne rapport. [Reference til kilde er indsat i firkantet parentes]. 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. [DBK2006] / [ISO :2001, 2.2 modificeret] strukturelt aspekt en bestemt måde at se et objekt på i en struktur NOTE 1: Formålet med et strukturelt aspekt er at strukturere information efter ensartede retningslinjer og at anvende dette til at identificere et objekt (bygningsdel eller brugsrum) entydigt. NOTE 2: Ved entydig identifikation af et objekt forstås, at alle objekter (også af samme type) kan identificeres hver for sig, og dermed klart adskilles fra hinanden. I daglig tale vil man kalde dette for nummerering af bygningsdele eller nummerering af brugsrum. NOTE 3: Ét strukturelt aspekt er én af flere egenskabsværdier. Et strukturelt aspekt har ikke indflydelse på egenskaberne der knyttes til et objekt. [CCS definition] view et defineret udvalg af informationer om ét eller flere objekter til et bestemt formål NOTE 1: Et view anvendes til at se specifikke informationer om ét eller flere objekter til et bestemt formål fx en energisimulering eller priskalkulation. NOTE 2: Resultatet af et view er et øjebliksbillede af specifikke informationer fx i form af egenskabsdata. [CCS definition] 81

82 objekttype klasse af objekter der har de samme karakteristiske egenskaber [IEC :2010, 3.16] objektforekomst anvendelsen af en objekttype inden for en specifik sammenhæng (fx i et (andet objekt eller system) uafhængigt af hvilket objekt individ der anvendes [IEC :2010, 3.15] objektindivid et eksemplar af en objekttype uafhængigt af hvor den er benyttet [IEC :2010, 3.14] GUID Globally unique identifier. et unikt referencenummer der anvendes som identifikation i computer software: [Wikipedia] IFC Industry Foundation Classes. datamodel som har til formål at beskrive bygninger og bygningskonstruktionsdata. [Wikipedia] IFD International Framework for Dictionaries en (international) standard for terminologi biblioteker eller ontologier. [ bygningsdel (fra engelsk: Construction element) en afgrænset bestanddel af en bygning, som i sig selv eller i kombination med andre bygningsdele har en karakteristisk funktion i bygningen. [DBK2006] / [ISO , 2.6 modificeret] NOTE: Definitionerne i ISO er under revision og udkommer i første nye udgave i Der anvendes her den eksisterende definition fra brugsrum rum defineret af det byggede miljø og som giver plads til brugeraktivitet eller udstyr [CCS 2012] Note 1: Et brugsrum kan bestå af flere zoner. En zone kan også betragtes som et brugsrum, defineret ud fra dets karakteristika. Eksempelvis en gangzone, et arbejdsområde, et opholdsområde osv. Note 2: Med til det byggede miljø hører også det naturskabte miljø som kan være med til at definere et brugsrum. Eksempelvis afgrænser en skovgrænse, et vandløb eller en skrænt f.eks. en have, en park eller en plads. Note 3: Udstyr kan f.eks. være inventar, teknisk udstyr og anlæg. 82

83 [CCS definition] system konstruktionssystem samvirkende konstruktionsobjekter organiseret til at opnå et eller flere specificerede formål [Dansk oversættelse af construction system fra ny ISO (2013)] [ISO/IEC 15288:2008, modificeret] 83

84 14 Bilag B Oversigt over aspektkoder CCS strukturelle aspekter Generelle regler Definition Strukturelt aspekt: En bestemt måde at se et objekt på i en struktur. Anvendelse af bogstaver og tal I en kode for et strukturelt aspekt anvendes bogstaver til angivelse af klassifikation. I en kode for et strukturelt aspekt anvendes tal som projektspecifikt løbenummer. Anvendelse af skilletegn. I det sammensatte produktaspekt, i placeringsaspektet samt i funktionsaspektet anvendes punktum. som skilletegn mellem de forskellige niveauer i strukturen. Adskillelse af koder / Såfremt flere koder for strukturelle aspekter skrives samlet på én linie, skal koderne adskilles med et skråtegn /, fx: -B1.UA1.QQA1 / ++B4.E2.R1 Regler for supplerende strukturelle aspekter For hvert strukturelt aspekt kan der etableres yderligere strukturelle aspekter, der identificeres ved 3 eller flere præfikstegn, fx: ===, +++, ====. For supplerende strukturelle aspekter gælder samme syntaksregler, som for det strukturelle aspekt der suppleres. Hvorvidt der benyttes regler for bygningsdele eller brugsrum i det supplerende strukturelle aspekt angives projektspecifikt. Version:

85 CCS strukturelle aspekter Typeaspekt Symbol Præfiks % %% Definition Projektspecifik gruppe af bygningsdele med samme klassifikation. Projektspecifik gruppe af brugsrum med samme klassifikation. Anvendelse Gruppering af bygningsdele for projektspecifikt formål vha. CCS klassifikation. Relevant ved beskrivelse af bygningsdele der har sammenfaldende egenskaber. Gruppering af brugsrum for projektspecifikt formål vha. CCS klassifikation. Relevant ved konfigurering og beskrivelse af brugsrum. Eksempel Vinduestype 1 (sidehængt) %QQA1 Vinduestype 2 (tophængt) %QQA2 Kontor type 1 (enkeltrum) %%NA01 Kontor type 2 (storrum) %%NA02 CCS - klassifikation Bygningsdele Brugsrum Version:

86 CCS strukturelle aspekter Produktaspekt Symbol Præfiks # ## Definition Identificerer en bygningsdel betragtet som et selvstændigt objekt. Identificerer et brugsrum betragtet som et selvstændigt objekt. Anvendelse Identifikation af bygningsdele vha. CCS klassifikation og nummerering. Anvendes til nummerering uden kendskab til eller behov for strukturering. Identifikation af brugsrum vha. nummerering. Anvendes til nummerering uafhængig af brugsrummets placering. NB! Må ikke forveksles med egenskaben rumnummer. Eksempel Vindue nr. 1 #QQA1 Vindue nr. 316 #QQA316 Brugsrum nr. 1 ##1 Brugsrum nr. 235 ##235 CCS - klassifikation Bygningsdele Version:

87 CCS strukturelle aspekter Sammensat produktaspekt Symbol Præfiks - -- Definition Identificerer en bygningsdel som en del af en anden bygningsdel. Identificerer et brugsrum som en del af en bygning, afsnit (option) og en etage. Anvendelse Identifikation af bygningsdele ved deres indbyrdes sammenhæng vha. CCS klassifikation og nummerering. Anvendes til sammensætning af bygningsdele ved brug af hovedsystemer, delsystemer og komponenter. Der kan for de enkelte bygningsdele anvendes samme nummerering som anvendt i produktaspektet (#). Identifikation af et brugsrum vha. nummerering i forhold til den bygning, afsnit (option) og etage som det indgår i. Anvendes når placering af et brugsrum i en bygning er kendt. Eksempel Vægsystem 1. Vinduesparti 1. Vindue 1 -B1.QA1.QQA1 Vægsystem 12. Vindue 316 -B12.QQA316 Bygning 4. Etage 2. Brugsrum 1 --B4.E2.R1 Bygning 12. Afsnit 3. Etage 2. Brugsrum 22 --B12.S3.E2.R22 CCS - klassifikation Bygningsdele Brugsrum Version:

88 CCS strukturelle aspekter Placeringsaspekt Symbol Præfiks + ++ Definition Identificerer et sted udtrykt ved en bygningsdel. Identificerer et sted udtrykt ved et brugsrum, en etage, et afsnit eller en bygning. Anvendelse Placering af en bygningsdel på eller i en anden bygningsdel. Placering af en bygningsdel i et brugsrum. Placering af en bygningsdel på en etage. Placering af en bygningsdel i et afsnit. Placering af en bygningsdel på eller i en bygning. Placering af et brugsrum i et brugsrum. Eksempel Vægsystem 1. Vægkonstruktion 2. Beklædningsplade 3 +B1.UC2.QTL3 Bygning 4. Etage 2. Brugsrum 1 ++B4.E2.R1 CCS - klassifikation Bygningsdele Brugsrum Version:

89 CCS strukturelle aspekter Funktionsaspekt Symbol Præfiks = == Definition Identificerer en bygningsdel som en del af en anden bygningsdel i en funktionel sammenhæng. Identificerer et brugsrum i en projektspecifik funktionel sammenhæng. Anvendelse Identifikation af bygningsdele ved deres funktionelle sammenhæng, uafhængig af fysisk implementering, vha. CCS klassifikation og nummerering. Anvendes til prædesign og/eller systemdesign af hovedsystemer og delsystemer, fx i form af procesdiagrammer og konstruktive systemer. Identifikation af brugsrum ved deres funktionelle sammenhæng vha. projektspecifik klassifikation samt CCS brugsrumsklassifikation og nummerering. Anvendes til funktionelt at sammensætte brugsrum ved deres tilhørsforhold til grupper af rum. Eksempel Ventilationssystem 1. Blandeanlæg 2. Kontraventil 3 =J1.HA2.RMA3 Klynge 1. Afdeling 2. Kontor 3 ==K1.A2.MA3 CCS - klassifikation Bygningsdele Projektspecifik Brugsrum Version:

90 15 Bilag C Oversigt over supplerende aspektkoder CCS strukturelle aspekter Supplerende strukturelle aspekter Symbol Præfiks %%% ### === %%%% #### ==== Definition Der gælder samme definition, som for det strukturelle aspekt der suppleres. Anvendelse Anvendes til etablering af supplerende strukturer efter projektspecifikt behov. CCS klassifikation og projektspecifik klassifikation anvendes i det supplerende strukturelle aspekt efter samme regler, som det strukturelle aspekt der suppleres. Eksempel Badekabinemodul 4. Vægkonstruktion 1 ---AA4.UC1 Skole 1. Administration 1. Kontor 3 ===S1.A1.NA3 CCS - klassifikation Identisk med klassifikationen i det strukturelle aspekt der suppleres Version:

91 16 Bilag D Eksempler for kodning af bygningsdele CCS strukturelle aspekter Eksempler på kodning af bygningsdele Symbol Præfiks Eksempel % Vinduestype 1 (sidehængt) Vinduestype 2 (tophængt) %QQA1 %QQA # Vindue nr. 1 Vindue nr. 316 #QQA1 #QQA316 - Vægsystem 1. Vinduesparti 1. Vindue 1 Vægsystem 12. Vinduesparti 18. Vindue 316 -B1.QA1.QQA1 -B12.QA18.QQA316 + Vægsystem 1. Vægkonstruktion 2. Plade 3 +B1.UC2.QTL3 ++ Bygning 4. Etage 2. Brugsrum 1 ++B4.E2.R1 = Ventilationssystem 1. Blandeanlæg 2. Kontraventil 3 =J1.HA2.RMA3 Version:

92 17 Bilag E Eksempler for kodning af brugsrum CCS strukturelle aspekter Eksempler på kodning af brugsrum Symbol Præfiks Eksempel %% Kontor type 1 (enkeltrum) Kontor type 2 (storrum) %%NA01 %%NA ## Brugsrum nr. 1 Brugsrum nr. 235 ##1 ##235 Bygning 4. Etage 2. Brugsrum 1 -- Bygning 4. Afsnit 3. Etage 2. Brugsrum 2 --B4.E2.R1 --B4.S3.E2.R2 Bygning 4. Etage Brugsrum 1 ++B4.E2.R1 Klynge 1. Afdeling 2. == Kontor 3 ==K1.A2.NA3 Version:

93 18 Bilag F - Kommentarer til behovsanalysens foreløbige hovedkonklusioner Følgende er uddraget fra behovsanalysens foreløbige hovedkonklusioner. Behovsanalysens konklusioner er citeret direkte i kursiv og projektgruppens kommentarer og de afledte krav følger efter. Behovsanalysen indikerer, at digitaliseringen er godt i gang. Der tegner sig dog et heterogent billede, hvor forskellige aktørgrupper arbejder på meget forskellige niveauer. Anvendelsen af bygningsmodeller bliver mere og mere udbredt især på større byggerier og ikke i form af fulde modeller mens mindre byggeprojekter, ombygning og renovering stadig typisk foregår vha. 2D. Kommentar: Projektgruppen er bevidst om de forskellige grader af digitalisering i byggeriet; aktørernes tilgængelige ressourcer for anvendelse af CCS-koden; samt projekternes forskellige omfang. Krav: CCS-koden skal kunne anvendes i branchemiljøer af vidt forskelligt omfang og med forskellige grader af IT-implementering. Udvekslingen med samarbejdspartnerne opleves således ofte som problematisk både pga. samarbejdskulturen, aftalegrundlaget og inkompatible itsystemer, og fordi der mangler standarder, der understøtter og ensarter udvekslingen. På tværs af aktørerne i værdikæden er der således en klar efterspørgsel på mere struktur, større ensartethed, samt flere og mere brugbare standarder. Kommentar: Understøttelse af datastrukturering ved udveksling anses for ét af CCS-kodens hovedkrav. Der lægges desuden vægt på kodens mulige anvendelse i forskellige IT-systemer, Krav: CCS-koden skal understøtte forskellige grader af datastrukturering i 93

94 overensstemmelse med det differentierede billede af digitalisering i branchen, omfanget af projekterne hvori koden skal anvendes og aktørernes tilgængelige ressourcer. Krav: Udtagelsen af CCS-koder skal ikke være afhængigt af at aktørerne anvender et bestemt IT-system eller at koderne udtages i en bestemt fase af byggeriet. Herved udelukkes bl.a. GUID (Global Unique Identifier) som grundlag for kodning, da disse fordrer ens og statisk kodegenerering i alle IT-systemer. Det er tungt at lave DBKkodningen. Der savnes en enklere klassifikation af bygningsdelene. Kommentar: Projektgruppen er bevidst om den hidtidige DBK-kodes manglende understøtning af simpel kodning. Dette er udbedret i den nye CCSkode. Krav: Det kræves af CCS-koden at den kan udtages manuelt; at koden benytter simple klassifikationstabeller; samt at koden understøtter minimal kodning for brugere med simple kodningsbehov. DBK burde kunne bruges uafhængigt af referencesystemet. Kommentar: Projektgruppen tolker dette, som at der skal kunne foretages en klassifikation af objekter der er uafhængig af objektrelationer i et bygværk. Krav: Objekter skal kunne klassificeres uafhængigt af referencekodning, dvs. uafhængigt af den kompositoriske struktur af bygværk. Grundlaget for tidligt i processen at lave beregninger på fx arealer, energi og totaløkonomi, er uklart. Der mangler grundlag for struktureret arbejde med rumprogrammer. Kommentar: Der er brug for i højere grad at kunne kode rum og relationer mellem rum og bygningsdele. I tilgift til behovsanalysens konklusion kan projektgruppen oplyse at dette inkluderer både en fysisk og funktionel kodning. Krav: CCS-koden skal inkludere struktureret kodning af rum. Dette inklude- 94

95 rer klassifikation og reference for rum baseret på både en fysisk og funktionel tilgang samt reference for relationer mellem bygningsdele og rum. Der er uensartede opfattelser af funktionsudbud og de mængder, der knytter sig til dette. Kommentar: Der er behov for at anskue byggeriet fra et funktionelt synspunkt. CCS-koden bør understøtte denne tilgang både for bygningsdele og rum. Mængdeudbud er svært at gennemføre i praksis. Det er uklart, hvad det operationelle niveau for mængdeudbud skal være. De bydende bruger meget tid på manuel opmåling og optælling af mængder. Kommentar: Summering af mængder bør lettes i forbindelse med udbud. Dette vil formentlig inkludere både typer defineret i bips regi og undertyper der er specifikke for individuelle bygværker. Krav: CCS-koden skal muliggøre nem søgning, filtrering og sortering af objekttyper defineret i CCS. Krav: CCS-koden skal muliggøre nem søgning, filtrering og sortering af projektspecifikke grupper af objekter af samme klasse defineret i CCS. De udførende kan som regel ikke genbruge data fra udbudsmaterialet til produktionsplanlægningen, da data er uredigerbare, og bygningsmodellen ikke udleveres. Kommentar: Datagenbrug inkluderer ikke blot muligheden for redigering af digitale modeller. Datagenbrug inkluderer desuden: direkte genbrug af datamodeller og dokumentation uden omkodning, identifikation af relaterede objekter samt vigtigst af alt entydig identifikation af objekter. Krav: CCS skal understøtte genbrug af datastrukturer og muliggøre minimal omkodning i datamodeller og dokumentation ved genbrug. Rådgiverne og de udførende vil gerne modtage mere struktureret produktinformation, som kan indgå 95

96 direkte i bygningsmodellen, produktionskort, afleveringsmateriale osv. Byggematerialer er ikke entydigt defineret. Der mangler unikke specifikationer (egenskabsdata). Der mangler en metode til at beskrive unika produkter. 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. Krav: 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. Dette gøres for at sikre en stabil kodning af objektet igennem dets levetid. Ændring af et objekts klassifikation skal således svare til oprettelsen af et nyt objekt frem for ændring af et eksisterende. Driftsherrerne kan ofte ikke bruge de afleverede data, da de ikke er redigerbare eller ikke er tilstrækkeligt strukturerede. Kommentar: Behovet understreger igen nødvendigheden at kunne understøtte en struktureret dataudveksling. CCS-koden skal således understøtte strukturering af data. Vigtige ønsker til klassifikations standard fra Behovsanalysen Projekt Behovsanalysen har identificeret følgende elementer der bør medgå i overvejelserne i forbindelse med udvikling af en standard for klassifikation. Projektgruppen kommenterer her de overvejelser gruppen har haft i forhold til de elementer der er relevante for udviklingen af CCS. Det vurderes, om det er nemmere at arbejde med det bygningsdelene hedder og er (som giver mening) end at få vist en kode bestående af tegn (tal og bogstaver), som ingen kan huske. Kommentar: Klassifikationen og dermed CCS skal nødvendigvis bestå af tegn (tal og bogstaver) og ikke navne på bygningsdele. Dette gøres af flere hensyn bl.a. skal længden af koden være så kort som mulig, stavefejl vil opstå hvis navne bruges, og så skal klassifikationen desuden benyttes i referencedelen. Det pointeres desuden at der til enhver tid i dokumentation og IT-systemer kan vises et navn tilknyttet bygningsdelen, men at dette navn ikke udgør klassifikationen. 96

97 Konklusion: Klassifikationen skal bestå af tegn. Navne for bygningsdele udgør data der kan anvendes efter behov, dog ikke til klassifikation og reference. Klassifikation skal skilles fra referencesystemet. Arkitekterne har alene behov for overblik over hvilke komponenter, der anvendes i et byggeri enten via eget klassifikationssystem eller et fælles. Kommentar: Behovet for klassifikation uafhængigt af referencedelen anerkendes. Behovet for aktørbestemt klassifikation anerkendes i begrænset omfang, idet aktørbestemt klassifikation i CCS-koden kun kan tillades efter forskrifter bestemt af CCS. Konklusion: CCS skal muliggøre brug af klassifikation uafhængigt af referencedelen. Brugen af eget klassifikationssystem muliggøres kun i de aspektkoder hvor CCS tillader det. Denne klassifikation er kun gyldig inden for ét bestemt byggeprojekt, men kan genbruges i andre byggeprojekter efter aftale blandt projekternes parter. Producenterne opererer med deres egne klassifikationer (koder og produktnavne), som arkitekten først sent/aldrig sætter ind i modellen. Kommentar: Projektgruppen ser dette som en bekræftelse af hvorledes CCS bør håndtere aktørbestemt klassifikation. Kodningsspørgsmålet skal afklares: Koden må ikke være en fortolkningskode. Den skal overholde matematiske regler for kodning, så den i sig selv er maskinaflæselig. Kommentar: Projektgruppen ser dette som en bekræftelse af at CCS skal baseres på tegn og ikke navne for bygningsdele. At koden skal være maskinaflæselig tolkes desuden som at koden så vidt muligt også bør understøtte automatisk kodning foretaget af IT-systemer. Koden må ikke være for lang. Tit vil man hellere bare give objektet et nummer. Det kan være nemmere at anvende værktøjets egen nedbryd- 97

98 ningslogik det kan være svært, hvis man har en prædefineret tilgang. Kommentar: Projektgruppen er opmærksom på problematikken omkring længden af koder. Det skal dog pointeres at den lange liste af ønsker for CCS trækker i den modsatte retning. Projektgruppen har søgt at gøre koden så kort som muligt, og vil desuden pointere at CCS koden består af delkoder der stykkes sammen efter det konkrete behov. CCS-koden kan således ved minimale kodningsbehov f.eks. ren klassifikation, være så kort som kun tre karakterer lang. DBK skal lægge sig op af det internationale ISO-arbejde mht. at finde/udvikle tabeller. Kommentar: Projektgruppen er enig i nødvendigheden af at lægge sig op af ISO-arbejdet. Dette inkluderer bl.a. ISO og ISO/IEC Konklusion: CCS skal muliggøre mapping til ISO og ISO/IEC Det vil desuden søges at undgå konflikter med objektklassifikationen i ISO/IEC , da denne klassifikation ifølge maskindirektivet er påkrævet for elektriske og mekaniske installationer. Minimal konflikt med ISO/IEC vil derfor støtte introduktionen af CCS i det elektriske og mekaniske domæne. Det skal afklares, hvad der er det rigtige typiseringsniveau i forhold til at kunne skabe objektbiblioteker og families for at kunne navngive objekttyper eller have et system til at sortere typerne i. Hvor er de vigtigste adskillende egenskaber på fx døre, og hvilke egenskaber er mindre vigtige fx i forhold til prissætning? Kommentar: Projektgruppen præsenterer forslag til inddelingskriterier Det skal afklares, om det er hensigtsmæssigt at starte med et objekt med få egenskaber og successivt putte flere på, eller om det er bedre at skifte objektet ud undervejs med et med flere egenskaber. Og hvad 98

99 betyder dette for klassifikation og anvendelse. Kommentar: Projektgruppen har søgt at undgå omkodning af objekter og udskiftning af objekter. Resultatet fremgår af de foreslåede delkoder og inddelingskriterier. Det skal afklares, hvordan sammenhængen er mellem bygningsdele i bygningsmodeller, bygningsdelsbeskrivelser og kalkulationer i forhold til entydighed og klassifikation. Der er ikke enighed eller standard på dette område. For rum skal afklares: Bruges der én type koder for at kunne lave og dokumentere projektet, og laver man bare den endelige (en anden) rumnummerering bagefter og udelukker/supplerer de hinanden? Kommentar: Projektgruppen tolker dette som et behov for tidlig kodning af rum i projekter til identifikation, hvor den endelige placering af rummene ikke er kendt. Konklusion: CCS understøtter tidlig kodning af rum der kan afvige fra den endelige placering. Bygningsdriftsklassifikation: En fremtidig klassifikation skal både være relevant for de store, professionelle bygherrer og for de mindre bygherrer, som kører på et lavere teknisk niveau. Evt. via forskellige niveauer et overordnet niveau, hvor tingene beskrives på et overordnet niveau for dem, der alligevel selv går ud og måler med tommelstok og et mere detaljeret niveau for dem, der magter at gå dybere ned. Det må ikke blive for voldsomt, så almindelige mennesker ikke kan se, hvor de er henne. Kommentar: Projektgruppen er enig i betragtningen. 99

100 Konklusion: CCS udvikles så simpel kodning med klassifikation og identifikation kan foretages i projekter med begrænset behov for kodning. 10 0

101 19 Bilag G Forudsætningsnotat Beskrivelse af aktivitet 2 forudsætninger for opgaveløsning. I dette notat beskrives grundlaget for opgavens løsning jævnfør projektbeskrivelse af 15. marts 2011, 9. udgave. Grundlaget for projektet er i øvrigt beskrevet i listeform i projektbeskrivelsen afs. 6. Forudsætninger for nuværende DBK:2006: Forudsætninger fra nuværende DBK er beskrevet i DBK 2006 vejledning, Begrebsmodel, klassifikations- og referencesystem version samt uddybet på møde med Gunnar Friborg (bips) den Følgende var grundlaget for udvikling af DBK: At der findes en teoretisk model for forholdet mellem objekter, tegn og begreber (A. Ekholm, side 13) 2. At DBK:2006 er forankret i en overordnet begrebsmodel (afsnit 5) fra ISO standardserien 3. At der er afveget fra ISO (afsnit 5.1) i form af en uddybning af modellen fra ISO At DBK:2006 så vidt muligt er internationalt kompatibelt (afsnit 1.3). Dette betyder i praksis at der kan mappes til andre landes klassifikationssystemer. 5. At modellen (DBK), skal dække hele byggeriets livscyklus (afsnit 1.2) 6. At begrebsdefinitioner i prioriteret rækkefølge er taget fra (A) Internationale ISO/IEC Standarder, (B) Oxford Dicitionary of English, (C) Nudansk Ordbog og (D) egne definitioner. 7. DBK:2006 er bygget således at alle typer kan sammensættes efter behov. Præ-definerede sammensætninger er ikke en del af DBK:2006, da mængden heraf bliver uoverskuelig (fra Gunnar Friborgs gennemgang af DBK:2006). 8. DBK:2006 er objektorienteret (fra Gunnar Friborgs gennemgang af DBK:2006). Forudsætninger for ny udgave af DBK:2012 (nu: CCS ) Arbejdsgruppen ser følgende som teknisk forudsætning for udvikling af kodestrukturen til en ny udgave af DBK. Almene forudsætninger 1. Forudsætningerne fra DBK:2006 bibeholdes. 10 1

102 2. Projektbeskrivelse Afklaring af Struktur og kode for bygningsdele af 25. maj 2011 pkt. 3.3 Succeskriterier, der beskriver succeskriterierne for en ny kodestruktur. 3. Det er centralt at kodesyntaksen bliver IT-egnet. Arbejdsgruppen definere dette således, at de enkelte dele af en kode skal være ITeget, og ser dette som en grænseflade til projektet om egenskaber. 4. Projektet omfatter beskrivelse af en kodesyntaks for tabeller om produkter (jævnfør ISO/IEC 81346) der anvendes i resultatdomænet (jævnfør ISO ). Øvrige domæner er ikke omfattet af dette projekt. 5. Det præciseres, at DBK-koden er en referencebetegnelse, baseret på ISO/IEC og reglerne heri, samt at DBK-kodens formål er at identificere forekomster af objekter. Se særskilt afsnit herom. 6. Jævnfør afklarende møde med Håvard Bell hos cuneco/bips den tages der hensyn til IFC & IFD i det omfang DBK:2012 kan berige IFC & IFD og drage nytte af den mekanisme som de repræsentere, dels som udvekslingsformat, dels som bibliotek for terminologi. 7. Øvrige IT-standarder medtages ikke og er således ikke en forudsætning for projektet. Andre tillægsforudsætninger I det omfang det er teknisk muligt og relevant, indarbejdes følgende tillæg til forudsætningerne, som er baseret på de indledende diskussioner som arbejdsgruppen har haft om projektet: 1. DBK-koden skal beskrives således at den kan medtages i QR-code og RFID-chipset som ren tekst. 2. Anvendelsen af DBK-koden analogt henholdsvis digitalt skal præciseres. 3. Relationen mellem IFC/IFD og DBK forklares bedre og det synliggøres hvordan IFC, IFD og DBK:2012 virker sammen. Det forudsættes bl.a. at DBK-referencekoden er én af flere egenskaber de kan overføres via IFC, dvs. at IFC ikke skal kode/dekode DBK-koden, men indeholde et felt til dette. 4. Formålet med DBK:2012 koden er at skabe et link mellem den digitale verden og den analoge verden. Dvs. at DBK koden kan håndteres i bidder internt i et IT-system alt efter behov / tekniske begrænsninger etc. mens den sammensættes til et analogt formål, fx at skabe et link mellem et byggeobjekt og den tilhørende analoge mærkning og dokumentation. 5. Der kan evt. udarbejdes et analogt spor og et digitalt spor der viser hvad der sker med informationerne i IT systemerne, og hvad der udlæses til en analog DBK-kode. 6. DBK-koder skal kunne genereres automatisk eller evt. semiautomatisk. 10 2

103 7. Begrebsdefinitionerne fra DBK:2006 udvides til at omfatte (E) IFD begreber, (F) Wikipedia m.fl. og at prioritetsrækkefølgen heraf evt. kan ændres. 8. Der indarbejdes en versioneringsdel af DBK, således at ITsystemerne kan kende forskel på eventuelle forskelle i udgaverne af DBK. 9. Det er måske en begrænsning, at der kun findes én identificerende DBK-kode. Det skal præciseres hvad en identificerende DBK-kode i så fald identificere, set i det samlede livscyklus for et objekt i byggeriet. 10. Der skal skelnes mellem unikke numre og entydige numre, og forskellen heri skal tydeliggøres. Dette er bl.a. relevant for at skelne mellem forekomster, typer og individer. Se særskilt afsnit herom. 11. DBK-koden anvendes bl.a. til at identificere det samme objekt entydigt, uanset hvor det befinder sig i livscyklus, hvilket er et særkende for DBK i forhold til andre landes klassifikationssystemer. 12. Afgrænsning af udsagnet DBK skal kunne anvendes i hele byggeriets livscyklus, da fx Forvaltningsklassifikation har en anden opfattelse. Udsagnet afgrænses derfor til at DBK-koden pr. definition kan anvendes i alle faser, men at koden ikke i sig selv tilfredsstiller alle behov i alle faser. Det vil være nødvendigt at anvende flere egenskaber m.v. 13. Forudsætning til objekter der medtages i DBK-kodens fremtidige form: Kodeord: Sporbarhed og Der medtages det i strukturen, der giver mening (i sporbarheden). 14. Det præciseres, at DBK-koden ikke kun anvendes i 2D / 3D CADmodeller, men også i ikke-cad som fx beskrivelser, beregninger, diagrammer etc. 15. I det omfang det er relevant og muligt, kan relationen mellem DBKkoden og IDM (Information Delivery Manual) synligøres. 16. Én DBK-kode kan sandsynligvis ikke rumme alt der skal sandsynligvis bruges mellem 1-3 koder for at tilfredsstille alle informationer i alle faser. Det fastholdes at der udvælges én DBK kode som den primære entydige ID, og som er robust set over det samlede tidsperspektiv. Tekniske forudsætninger I dette afsnit beskrives diverse tekniske forudsætninger, der danner grundlag for udarbejdelse af en revision af DBK-koden. Muligheder for tilstande af objekter ( arbejdsgang ) Følgende tilstande for et objekt er indledningsvis identificeret: 1. Objekter der ikke kræver entydig ID (dvs.et løbenummer), men alene en type: Fx ens vinduer, gulvbrædder. 10 3

104 2. Objekter der skal have et entydigt ID (med løbenummer) når objektet er installeret: Fx en stikkontakt, belysningsarmatur, vinduer (af hensyn til drift). 3. Objekter der skal have et entydigt ID (med løbenummer) inden det installeres: Fx et specifikt ventilationsanlæg (ventilationsanlægget laves specifikt til hvert byggeri) eller individuelle vinduer. Det betyder i praksis at: 1. Alle DBK-koder er udtaget inden installation på pladsen. 2. Nogle koder påsættes hos leverandøren (præ-definerede koder til fx ventilationsanlæg). 3. Nogle koder påsættes på byggepladsen (fx stikkontakter). 4. Andre koder påsættes aldrig i praksis (fx skruer, søm) selv om koden findes (fx koder på vinduer, isolering, lysarmaturer). Ændringer i ISO Ændringer i DBK i forhold til ISO 12006: (Se slide The ISO standard fra Gunnar Friborg møde den ). ISO defines a framework for classification: DBK:2006 er gået 100% ind for den grundlæggende model, men i den model i ISO der står op er i DBK:2006 lagt ned, og endvidere er der i den originale model et låst view fra nogle aktører, hvilket giver en låst metode at se data på, hvor DBK:2006 pr. definition har delt alt op i separate tabeller, der kan kombineres efter behov. ISO har termen space, hvilket er lidt for upræcist, så dette er udspecificeret til et mere detaljeret niveau. Det overordnede scope for ISO matcher fint scopet af ISO/IEC standarden. Generelt om forskellige koder fra ISO/IEC Følgende tabel 1 fra ISO/IEC anses for meget central i det videre arbejde med udarbejdelse af en revideret DBK-kode: 10 4