ccs kodnings- regler - cunecocuneco.dk/files/ccs_kodningsregler_hoeringsrapport_-_2012-03-05.pdf ·...

CCS kodnings-regler Kodningsregler for klassifikation og identifikation af objekter cuneco projektnummer: 11011 Afklaring af kode og struktur for bygningsdele FORELØBIG UDGAVE TIL OFFENTLIG HØRING

5. marts2012

2 CCS kodningsregler - foreløbig udgave til offentlig høring · cuneco · 2012-03-05

cuneco.dk center for produktivitet i byggeriet CCS kodningsregler Redaktion Henrik Balslev, Balslev & Jacobsen ApS Allan Dam Jepsen, CPC Nicolai Karved, Betech Data A/S Søren Spile, cuneco cuneco – en del af bips bips Lautrupvang 1 B 2750 Ballerup Telefon 70 23 22 37 Fax 70 23 42 37 E-mail [email protected] www.bips.dk Grafisk tilrettelæggelse Fænø Design


1 Resumé

Denne rapport beskriver forudsætningerne, forløbet og resultatet med cuneco projeketet ”Kodningsprncipper for klassifikation og identifikation”. Rapporten beskriver den tekniske løsning, dels i overordnede principper, dels i detaljer således at det kan anvendes til fx implementering i IT soft-ware. 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 identifika-tion af bygningsdele og rum, samt til at beskrive relationerne mellem byg-ningsdele og rum. Der er taget udgangspunkt i ISO 12006-2 og ISO/IEC 81346 standarderne, hvor ISO 12006-2 er en rammestandard for konteksten af klassifikation og ISO/IEC definere reglerne for strukturer, syntaks og til dels klassifikation inden for bestemte områder. Grundlæggende adskiller CCS sig fra DBK ved at hvor de forskellige aspekter i DBK definerede forskellige klasser for et objekt, så fortæller aspekterne i CCS en sammenhæng mellem objekter af samme klasse og en måde at adressere dem på. I Bilag C - Oversigt over 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 princippet.


2 Indholdsfortegnelse

1 Resumé ........................................................................................................................3

3 Introduktion .................................................................................................................7

3.1 Projektgrundlag ...........................................................................................................7

3.2 Projektforløb ................................................................................................................8

4 Kravspecifikation .........................................................................................................10

4.1 Målgruppe ...................................................................................................................10

4.2 Krav ..............................................................................................................................11

4.2.1 Klassifikationkrav .........................................................................................................12

4.2.2 Identifikationskrav .......................................................................................................12

4.2.3 Normative krav ............................................................................................................13

4.2.4 Anvendelseskrav ..........................................................................................................13

4.2.5 Implementeringskrav...................................................................................................14

5 Objekthåndtering i CCS: Typer, forekomster og individer ..........................................15

6 Kodede objekter: Bygningsdele og rum ......................................................................17

7 CCS KodningsREGLER ...................................................................................................18

7.1.1 Klassifikation og identifikation ....................................................................................18

7.1.2 CCS-kodens overordnede struktur ..............................................................................18

7.1.3 Aspekter .......................................................................................................................20

7.1.4 Klasser ..........................................................................................................................21

7.1.5 Løbenumre ..................................................................................................................23

8 Aspektkoderne ............................................................................................................24

8.1 Anvendelse af aspektkoder .........................................................................................27

8.2 Gruppe 1 aspektkoder .................................................................................................28

8.2.1 [%] Bygningsdelsklasse ................................................................................................28

8.2.2 [#] Simpelt bygningsdels ID .........................................................................................29


8.2.3 [=] Bygningsdels funktions ID ......................................................................................31

8.2.4 [-] CCS bygningsdels ID ................................................................................................34

8.2.5 [+] Konstruktionsrums placerings ID ...........................................................................38


8.3.1 [%%] Rumklasse ...........................................................................................................40

8.3.2 [##] Simpelt rum ID ......................................................................................................42

8.3.3 [==] Rum funktions ID ..................................................................................................43

8.3.4 [––] CCS brugsrums ID .................................................................................................45

8.3.5 [++] Brugsrums placerings ID .......................................................................................46


8.4.1 [---] Projektspecifk aspektkode ....................................................................................47

9 Kodningseksempler .....................................................................................................48

9.1 Dør ...............................................................................................................................48

9.2 Afbryder .......................................................................................................................52

10 Forslag til klassifikation................................................................................................54

10.1 Bygningsdele ................................................................................................................54

10.1.1 Hovedsystemer ............................................................................................................55

10.1.2 Bygningsdele – Konstruktive .......................................................................................57

10.1.3 Bygningsdele – elektriske og mekaniske .....................................................................61

10.2 Bebyggelser .................................................................................................................62

10.3 Bygninger .....................................................................................................................62

10.4 Brugsrum .....................................................................................................................62

11 Relation til internationale standarder m.v. .................................................................63

11.1 IFC/IFD .........................................................................................................................63

11.2 ISO/IEC 81346 ..............................................................................................................64

11.3 ISO 12006-2 .................................................................................................................65

12 Sammenfatning ...........................................................................................................66

13 Bilag A - Termer og definitioner ..................................................................................67

14 Bilag B - Eksempler på CCS i EBNF-format ...................................................................69


15 Bilag C - Oversigt over aspektkoder .............................................................................70

16 Bilag D - Kommentarer til behovsanalysens hovedkonklusioner ................................72

17 Bilag E – Bygningsdelstabel 1 .......................................................................................80


3 Introduktion

Denne rapport beskriver resultatet af Cuneco projekt ”11011 - 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 rum i Dansk Bygge Klassifikation (DBK). Den reviderede version vil herefter ken-des under navnet cuneco classification system (CCS). Resultatet af projektet er en beskrivelse af en struktur for kodning af typer og forekomster af byg-ningsdele og rum 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 har til formål at frembringe revide-rede reference- og klassifikationstabeller. Projektet er udført af en arbejdsgruppe nedsat af Cuneco, som består af:

• Søren Spile, Projektleder, cuneco

• Ulf Harlou, CPC - Center for Product Customization ApS

• Allan Dam Jepsen, CPC - Center for Product Customization ApS

• Nicolai Karved, Betech Data A/S

• Henrik Balslev, Balslev & Jacobsen ApS

Rapporten beskriver regler for, hvorledes CCS koder skal udarbejdes, og retningslinier for det efterfølgende klassifikationsarbejde. Rapporten præsenterer forslag til klassifikationstemaer, men omhandler ikke det specifikke tabelarbejde, herunder de klassifikationstabeller der skal udarbejdes på baggrund af denne rapport, dvs. udarbejdelse af tabeller.

3.1 Projektgrundlag

De detaljerede forudsætningerne for gruppens arbejde, herunder de grund-læggende tekniske krav som nye kodningsprincipper skal opfylde, er nær-mere beskrevet i:

• Projektbeskrivelse: Afklaring af struktur og kode for bygningsdele. 9. udgave dateret 1.6.2011.


• Beskrivelse af aktivitet 2 - forudsætning for opgaveløsning. Version 2011-07-06.

Følgende materiale danner grundlag for projektet jf. Projektbeskrivelsens pkt. 6:

• DBK 2006 • ISO 12006-2 • ISO/IEC 81346-1 og 81346-2 • 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, Henrik Balslev, 2010 (vedlagt) • Forvaltnings Klassifikation, Landsbyggefonden og KL, August 2009 • IFD, http://www.ifd-library.org/

Hertil er under projektets forløb tilføjet:

• Udviklingsplan for Dansk Bygge Klassifikation 2010-2012 • Behovsanalyse – hvad er byggebranchens behov for standarder for

udveksling af digital information? (Foreløbige hovedkonklusioner)

3.2 Projektforløb

Projektgruppen har gennemført projektet ved gennemløb af korte udvik-lingscyklus med løbende review og feedback af foreslåede løsninger fra udvalgte eksperter. 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 2.2) b. Afdækning af relationer til IFC og IFD, samt cuneco projek-

tet vedr. egenskabsdata 2. Indsamling af basisinput til projektarbejdet med deltagelse af ud-

valgte eksperter med afsæt i de vedtagne forudsætninger for opga-ven

3. Udformning af syntaks og struktur for ny kodeteknik med fokus på nedenstående områder:

a. Studie af nødvendige / lovgivningsmæssige / direktivmæs-sige kodningsbehov

b. Studie af kodens udvikling over tid (projektforløb) c. Studie af informationsniveauer og deres indvirkning på ko-

den 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

http://www.ifd-library.org/


h. Mapning til ISO 12006-2, Forvaltnings Klassifikation og ISO/IEC 81346

i. Udarbejdelse af grafiske eksempler 4. Intern høringsworkshop i Cuneco med deltagelse af udvalgte inte-

ressenter 5. Revision af syntaks og struktur for ny kodeteknik samt udarbejdelse

af klassifikationstemaer for bygningsdele, systemer og brugsrum. 6. Offentlig høring (fremtidigt arbejde) 7. Udarbejdelse af endelig rapport med indarbejdede høringssvar

(fremtidigt arbejde)

Undervejs i projektet er afholdt koordinerende workshops og møder med Cuneco´s styregruppe, projektgruppen for Cuneco projekt ”12011 – Afkla-ring af struktur og metode for egenskabsdata”, og interessenter fra IT-leverandør branchen.


4 Kravspecifikation

CCS-koden er designet til at understøtte hele bygge- og driftsprocessen, og CCS kan derfor anvendes til et varieret kodningsbehov i de forskellige faser. Da Cuneco projekt 10011 – Behovsanalysen først sent i projektets forløb har kunne præsentere sine hovedkonklusioner, har projektgruppen som grundlag for sit arbejde fundet det nødvendigt at præcisere hvilke behov der adresseres med den nye CCS-kode og hvilken anvendelse koden er til-tænkt. Behovene og de resulterende krav til CCS-koden er undervejs i pro-jektet udbygget og tilpasset efter input fra følgende kilder:

• Projektets baggrundsmateriale • Interne workshops i projektgruppen • Review af projektgruppens arbejde med Cuneco´s styregruppe og

IT-leverandører • Studie af behovsanalysen fra Cuneco projekt 10011 - Behovsanaly-

sen

Projektgruppens kommentarer til behovene identificeret i de foreløbige hovedkonklusioner fra projekt 10011 – Behovsanalysen kan læses i bilag D. Projekt 10011 har desuden påpeget en række elementer der bør indgå i overvejelserne ved udvikling af en klassifikationsstandard i Cuneco. De af elementerne der har været af direkte relevans for udviklingsarbejdet er ligeledes kommenteret i bilag D. I det efterfølgende gennemgås målgruppen for CCS og de primære krav der ligger til grund for det endelige resultat.

4.1 Målgruppe

CCS-koden er tiltænkt brug både i byggeprojekter og uden for byggeprojek-ter. Målgruppen inkluderer 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 mel-lem aktørerne og deres forskellige informationsbehov, samt hvorledes disse forventes at være differentieret efter bl.a. branche, virksomhedsrolle, op-gaveportefølje, it-niveau etc.


4.2 Krav

Som udgangspunkt for projektet er der jævnfør opgavedefinitionen pkt. 3.3 stillet følgende minimumskrav som succeskriterie for projektet

• Kodesyntaksen skal være it-egnet. • Det skal tilstræbes, at de tabeller der omhandler klassifikationsde-

len 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 klassifikations-delen.

• 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 2006.

• Kodesyntaksen skal tilstræbes at kunne mappes til andre nationale klassifikationssystemer.

• Klassifikationsdelen skal kunne anvendes under hele byggeproces-sen fra program til og med forvaltning.

Projektgruppens analyse af behov for den nye CCS-kode har resulteret i en udbyggelse af ovenstående i forhold til nedenstående temaer, der gennem-gås i de efterfølgende afsnit. Kravene er opdelt således:

• Klassifikationskrav • Identifikationskrav • Normative krav • Anvendelseskrav • Implementeringskrav

Disse krav udgør den grundlæggende kravspecifikation for udviklingen af CCS. Det bør overordnet set bemærkes at udviklingen af CCS sker med hensyn til en række lovmæssige og normative krav især til mekaniske og elektriske bygningsdele, fx Stærkstrømsbekendtgørelsen og Maskindirektivet, der bl.a. bevirker, at en kode skal være designet i overensstemmelse med rele-vante harmoniserede standarder, og at disse koder skal være egnet til menneskelig genkendelse. Med henvisning til grundlaget for projektet og de stillede krav, fastholdes rammerne fra ISO 12006-2 standarden og de grundlæggende kodningsprin-cipper baseret på ISO/IEC 81346 standarden. Kodeprincipperne i CCS revi-deres dog væsentligt i forhold til DBK2006 udgaven. Revisionen af koden sker fortsat med ISO/IEC 81346 som grundlag, men på en sådan måde, at de stillede krav til projektet opfyldes. Udover reglerne for syntaks fra ISO/IEC 81346 medtages de relevante klassifikationstabeller fra 81346-2 for


så vidt angår mekaniske og elektriske anlæg, da disse er normative for disse systemer.

4.2.1 Klassifikationskrav Krav 1: Bygningsdele og rum skal kunne tildeles en kode for typeklas-

sifikation uafhængigt af referencekodning. Krav 2: Aktørers brug af eget klassifikationssystem skal kun være

muligt under følgende forudsætninger: klassifikationen udgør en underklassifikation af klassifikationen i CCS; denne under-klassifikation er kun gyldig inden for ét bestemt byggeprojekt, men kan genbruges i andre byggeprojekter efter aftale blandt projekternes parter; underklassifikationen kan kun anvendes i en veldefineret CCS kode.

Krav 3: Klassifikationen skal bestå af tegn. Navne for bygningsdele

udgør data der kan anvendes efter behov, dog ikke til klassifi-kation og reference.

Krav 4: Klassifikationsdelen i CCS skal muliggøre en statisk klassifika-

tion 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 (både klassifikation og identifikation) 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.

Krav 5: Klassifikation i CCS skal være entydig dvs. et objekt skal ikke

kunne klassificeres som mere end én type.

4.2.2 Identifikationskrav Krav 6: CCS skal understøtte stabil og entydig identifikation af objek-

ter gennem hele byggeriets livscyklus. Entydighed vil sige at en del af CCS-koden skal referere til ét specifikt objekt. Denne del af koden skal bibeholdes hen over objektets livscyklus.

Krav 7: CCS skal inkludere identifikation af objekter i forhold til en

dekomponering for byggeri defineret af CCS. Krav 8: CCS skal muliggøre identifikation af objekter i forhold til en

dekomponering for byggeri gældende inden for ét bestemt projekt. Den projektspecifikke dekomponering kan bl.a. base-res på leverancer, moduler eller lignende, og kan f.eks. be-nyttes til omkostnings- eller vægtberegninger.

Krav 9: CCS skal understøtte identifikation af bygningsdele uden hen-

syntagen til den strukturelle komposition af byggeriet. Krav 10: CCS skal understøtte identifikation af bygningsdele baseret

på den strukturelle komposition af byggeriet.


Krav 11: CCS skal understøtte reference af bygningsdeles fysiske pla-cering i forhold til brugsrum og konstruktionsrum.

Krav 12: CCS skal understøtte tidlig identifikationskodning af rum i

projekter før den endelige placering af rummene er kendt. Krav 13: CCS skal understøtte struktureret identifikationskodning af

brugsrum baseret på deres funktion i byggeriet. Krav 14: CCS skal understøtte struktureret identifikationskodning af

rum baseret på rummenes endelige placering.

4.2.3 Normative krav Krav 15: CCS skal muliggøre mapping af klassifikationer for bygnings-

dele til ISO12006-2 Krav 16: CCS skal muliggøre mapping af klassifikationer for bygnings-

dele til ISO/IEC 81346-2. Det skal undgås, at objektklassifika-tionen fra CCS konflikter med ISO/IEC81346-2, da denne klas-sifikation ifølge maskindirektivet er påkrævet for elektriske og mekaniske installationer.

Krav 17: De tabeller i CCS der omhandler klassifikationsdelen og som

efterfølgende vil blive udarbejdet, skal kunne anvendes sammen med IFD.

4.2.4 Anvendelseskrav Krav 18: 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 kod-ningsbehov.

Krav 19: CCS skal søge at minimere eller helt undgå nødvendigheden

af omkodning af objekter og udskiftning af objekter i projek-ter.

Krav 20: CCS skal understøtte genbrug af datastrukturer og dokumen-

tation. Dette inkluderer minimal omkodning i datamodeller og dokumentation samt identifikation af designbestanddele og associeret data og dokumentation.

Krav 21: CCS-koden skal muliggøre nem søgning, filtrering og sortering

af objekttyper defineret i CCS. Krav 22: CCS-koden skal muliggøre nem søgning, filtrering og sortering

af projektspecifikke varianter af objekttyper defineret i CCS. Krav 23: CCS-koden skal understøtte forskellige grader af datastruktu-

rering i overensstemmelse med det differentierede billede af digitalisering i branchen, omfanget af projekterne hvori ko-den skal anvendes og aktørernes tilgængelige ressourcer.


Krav 24: CCS skal muliggøre analog navigering i byggeriers strukturer. Dvs. CCS skal understøtte beskrivelse af byggeriers komposi-tion og et objekts strukturelle kontekst.

Krav 25: Det skal være muligt at benytte CCS-koden som den identifi-

cerende kode ved dataudveksling i alle IT-systemer og do-mæner.

Krav 26: CCS skal understøtte relatering af funktionskrav til rum og

bygningsdele. Krav 27: CCS skal søge at minimere potentielle konflikter ved udtag-

ning af koder for objekter f.eks. gennem definition af kode-strukturer.

4.2.5 Implementeringskrav Krav 28: Generering af CCS-koder skal ikke være afhængigt af at aktø-

rerne anvender et bestemt IT-system eller at koderne udta-ges 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.

Krav 29: CCS-koden skal kunne anvendes i branchemiljøer af vidt for-

skelligt omfang og med forskellige grader af IT-implementering.

Krav 30: CCS skal kunne benyttes i de mest gængse kontorsoftware

bl.a. programmerne i Microsoft Office. Krav 31 CCS klassifikationen må ikke være i konflikt med eksisterende

normative og lovgivningsmæssige krav. Da CCS-koden skal implementeres blandt aktører med væsentlig forskellige forudsætninger og behov, har det været nødvendigt for projektgruppen ikke at antage en ideel implementeringssituation for CCS. Den nye CCS-kode er derfor udformet således at CCS-koden kan anvendes analogt uden understøttelse af IT-systemer. I praksis vil IT understøttelse dog være en væsentlig effektivisering i anvendelsen af CCS.


5 Objekthåndtering i CCS: Typer, forekomster og individer

cuneco classification cystem (CCS) anvendes til klassifikation og identifikati-on af objekter. Klassifikation af objekter i CCS beskriver tilskrivningen af en type til et objekt. CCS omhandler klasser og identifikation af objekter i ”den rigtige verden”, dvs. uden om (IT) modelverdenen. Dermed sikres, at CCS ikke er i konflikt med eventuelle 3D modeller, IFC m.v., men er et fælles referencepunkt for disse. I samråd med projektgruppen der arbejder med objekt egenskaber, er der defineret følgende adskillelse mellem de forskellige typer af objekter der behandles:

Objekttype Klasse af objekter der har de samme karakteristiske egen-skaber [FDIS for IEC 62507-1, Requirements for identification sy-stems enabling unambiguous information interchange – Part 1: Principles and methods] Objektforekomst Anvendelsen af en objetktype inden for en specifik sammen-hæng (fx i et andet objekt (anlæg) eller et system (bygning)) uafhængigt af hvilket objekt individ der anvendes [FDIS for IEC 62507-1] Objektindivid Et eksemplar af en objekttype uafhængigt af hvor den er be-nyttet [FDIS for IEC 62507-1] NOTE: Objekterne og definitionerne er objekter be-

tragtet i ”den virkelige verden”, og omfatter derfor ikke en model repræsentation af samme objekt.

Formålet med at skelne mellem de tre typer af objekter er at kunne hånd-tere information om objekterne (type - forekomst - individ) på mere klart. Objekttypen vil anvende en klassifikation, der er ens for både objektfore-komst og objektindivid, dvs. at både objektforekomst og objektindivid be-nytter samme klassifikation.


Objektforekomst er det objekt der opstår først i en projektspecifik sam-menhæng, og senere kan implementeres som et objektindivid. Objektfore-komst er derfor stabil, set over et byggeris livscyklus. Objektindivid er det specifikke produkt der indkøbes og installeres som en løsning på et designet objektforekomst. Objektindivider er den færdige tekniske løsning i ethvert byggeri, og er således også genstand for Drift og Vedligehold. Et objektindivid referere altid til en objektforekomst. Objektindivider kan udskiftes, mens objektforekomsterne består. Som kon-sekvens, er objektforekomsterne stabile at klassificere og identificere over den samlede livscyklus for et objekt. Objektforekomster og objektindivider er illustreret i Figur 1.

Figur 1 - Illustration af objekt forekomster og objekt individer


6 Kodede objekter: Bygningsdele og rum

CCS koder to grundlæggende objekter: bygningsdele og rum.

• Objektet bygningsdel forefindes som: objekttype, objektfore-komst og objektindivid.

• Objektet rum forefindes som: objekttype og objektforekomst. • Objektet rum kan ses som ”brugsrum” og ”konstruktionsrum”.

Bygningsdele, brugsrum og konstruktionsrum 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 karak-teristisk funktion i bygningen.

• Brugsrum: Et rumligt sammenhængende og afgrænset område i en bygning, der har et primært menneskeligt anvendelsesfor-mål.

• Konstruktionsrum: det rum der opstår ved opbygning af byg-ningstekniske systemer og som er indlejret heri.

Se endvidere definitioner i Bilag A - Termer og definitioner.


7 CCS Kodningsregler

7.1.1 Klassifikation og identifikation CCS anvendes til klassifikation og identifikation af systemer, bygningsdele og rum. I forhold til DBK2006 ændres der på måden hvorpå klassifikationsdelen og identifikationsdelen beskrives i CCS. I DBK2006 blev klassifikation beskrevet både ved tal og bogstaver. I CCS beskrives klassifikation udelukkende ved brug af latinske bogstaver. Klassifikation og identifikation anvender følgende regler:

A 1.) CCS klassifikationsdelen kan anvendes separat efter

behov, og kan indgå i alle de øvrige koder i CCS. Klas-sifikationsdelen har til formål at samordne klasser af objekter, som har det samme sæt af egenskaber (ty-pe-af). Koden for en given klassifikation foretages alene vha. bogstaver.

A1

2.) CCS identifikationsdelen er opbygget af bogstaver fra klassifikationsdelen plus et løbenummer der qua ko-dens opbygning tilsammen giver en oplysning om ty-pen af objekt + et løbenummer og/eller hvilken struk-turel komposition et objekt indgår i (del-af), således at enhver objektforekomst kan skelnes fra andre ob-jektforekomster.

Identifikationsdelen skal benyttes som robust identifikation af enhver ob-jektforekomst i et byggeri, såfremt det er nødvendigt at kunne skelne ens forekomster fra hinanden, fx skelne døre, vinduer, ventiler og stikkontakter individuelt fra hinanden.

7.1.2 CCS-kodens overordnede struktur Den information der udveksles om objektforekomster er så forskelligartet i et byggeri, at det ikke er teknisk muligt at udarbejde én kode der alene kan opfylder alle de krav, som stilles til en CCS kode. Den tekniske løsning på kodemekanismen i CCS er derfor designet som en sammensætning af flere delkoder kaldet aspektkoder, der følger de samme syntaksregler, men som hver især tilgodeser forskellige informationsbehov om en objektforekomst. De enkelte aspektkoder kan anvendes individuelt eller i kombination med hinanden. Regel 1: Den samlede CCS-kode der tilskrives et objekt består af et

varierende antal delkoder kaldet aspektkoder, der sammen-sættes til en samlet kodestreng kaldet CCS-kode.


Regel 2: De enkelte aspektkoder adskilles i CCS-koden med et skrå-tegn: ”/”.

Regel 3: Der er ingen regel for rækkefølgen af aspektkoderne i CCS-

koden. Rækkefølgen er uden betydning, da man kan genken-de de forskellige aspektkoder fra hinanden på deres forskelli-ge præfiks (fortegn).

Brugen af præfiks medvirker til, at CCS-koden kan genkendes af mennesker og kan adskilles rent IT-teknisk. CCS-koden følger syntaksreglerne i ISO/IEC 81346, der definerer aspektko-derne som referencebetegnelser i det der kaldes et referencesystem, for-kortet RDS (Reference Designation System). En RDS kode muliggør identifi-kation af et objekts forekomst, hvor mindst én RDS kode identificerer ob-jektets forekomst entydigt. Det er tillagt stor værdi, at syntaksreglerne er baseret på denne international standard, dels for at kunne opfylde allerede eksisterende krav der er funderet på ISO/IEC 81346, dels for at fremme IT understøttelse af kodereglerne i CCS. Med entydig identifikation menes, at kun én specifik objektforekomst iden-tificeres ved den givne RDS kode, og dermed ikke kan forveksles med andre objekter. RDS koderne er i sig selv egnet til menneskelig genkendelse, og består af en kombination af bogstaver og tal sat i en bestemt rækkefølge, der fx viser en kompositionel sammensætning af givne bygningsdele. Et objekt kan foruden en RDS kode have alle former for andre koder tilknyt-tet, uden at dette er i konflikt med hinanden. CCS-koden reglerne om RDS koder, idet én eller flere af aspektkoderne kan udgøre en entydig identifika-tion af en bygningsdel eller et rum, mens øvrige aspektkoder og andre ko-der (serienummer, ordrenummer, produkt-ID, GUID etc.) kan inkluderes som supplerende information efter behov på forskellige tidspunkter i byg-geriets livscyklus. Den grundlæggende struktur for CCS-koden udformes grundlæggende som:

etc.

D Kode i den samlede kodestreng

(1) Aspektkode se afs. 8). (2) Separator ”/” adskiller de enkelte koder i kodestrengen (3) Aspektkode (4) Separator ”/” adskiller de enkelte koder i kodestrengen (5) Aspektkode

(5) (4) (3) (2) (1) D / D / D


7.1.3 Aspekter Aspekter i CCS koder baseres på reglerne i ISO/IEC 81346-1. Hovedformålet med aspek-ter er at kunne beskrive information om givne objekter helt præcist i form af en CCS kode. Dette understøtter det faktum at de forskellige informationsbehov i byggeriet ikke kan beskrives ud fra én bestemt ansku-else af et givent byggeri. Aspekterne agerer derfor ligesom ”filtre” hvorigennem et byg-geri anskues f.eks. strukturelt, funktionelt, placeringsmæssigt m.v. Der er i CCS defineret følgende aspekter til definition af aspektkoder:

Aspekt Forklaring

Klassifikationsaspekt1.) Anskuer byggeriet fra en klassifikationsmæs-sig synsvinkel, dvs. en ikke-identificerende synsvinkel (enkeltniveau).

Funktionsaspekt Anskuer byggeriets bestanddele ud fra deres funktionsmæssige sammenhæng (flerni-veau).

Simpelt produktaspekt

Anskuer byggeriet fra en simpel strukturel nedbrydning af byggeriet uden hensyntagen til den kompositoriske sammenhæng mellem objekterne (enkeltniveau).

Strukturelt produkt-aspekt

Anskuer byggeriet fra en strukturel nedbryd-ning med hensyn til den kompositoriske sammenhæng mellem objekterne, hvor øverste niveau defineres som systemer (fler-niveau).

Placeringsaspekt

Anskuer byggeriet ud fra en placeringsmæs-sig nedbrydning (flerniveau). Placeringsaspektet bruges som link mellem bygningsdele og rum (konstruktionsrum og brugsrum).

Tabel 1 - Kodningsaspekter i CCS

1.) NOTE: Klassifikationsaspektet er ikke omtalt i ISO/IEC 81346-1, da det er uden for emneområdet af denne standard. Klassifikationsaspektet er indført i for-bindelse med CCS og er ikke i konflikt med standarden. De øvrige aspekter i CCS er velkendte og veldefinerede aspekter fra ISO/IEC 81346-1.


CCS definerer flere forskellige aspektkoder inden for hvert aspekt og tildeler hver aspekt kode et bestemt præfiks. De enkelte aspektkoder beskrives i afsnit 8. Regel 4: Alle aspektkoder er forsynet med et præfikstegn (fortegn),

hvis betydning er defineret i afsnit 8.

Regel 5: Såfremt der defineres mere end én aspektkode inden for et

aspekt benyttes flere af det samme aspekt-tegn som præfiks f.eks. +, ++, +++ osv. jævnfør ISO/IEC 81346.

7.1.4 Klasser Det har været en forudsætning for arbejdet med den nye CCS-kode, at den klassificerende del af CCS skal kunne anvendes separat til forskellige formål, fx til samordning af objekter i tilbudsfasen eller i en driftsfase. Af hensyn til IT egnetheden m.v. skal der dog kun findes ét ensartet klassifikationstema, der anvendes til klassifikationsdelen og identifikationsdelen, således at man får ens klassifikationsbogstaver, der betegner de samme objekter uanset anvendelsen. Klassifikationen baseres på ’type-af’ strukturer, dvs. følger de gængse regler for udarbejdelse af klassifikationstabeller. For så vidt angår identifikationsdelen for bygningsdele, er det desuden et krav at klassifikationen for bygningsdele er stabil igennem objektets livscy-klus bl.a. for at undgå ændringer i den identificerende del af koden. Ved traditionel klassifikation underdeles klasserne hen over tid, efterhån-den som objektet tildeles flere egenskaber (se Figur 2). Klassifikationen bliver på denne måde stadig mere detaljeret hvilket resulterer i ændringer i klassifikationskoden.


Figur 2 - Traditionel klassifikation: Ændring henover tid

I CCS ønskes der en stabil 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 klassi-fikation gennem objektets livscyklus (se Figur 3). Egenskabsdata, der kunne indgå i klassifikationen af objektet, og potentielt resultere i en ændring af klassifikationskoden hen over tid, tilskrives i stedet som egenskabsdata for objektet og indgår ikke længere i klassifikationen. De enkelte egenskabsda-ta kan efterfølgende klassificeres separat (fx brandklasser, materialeklasser etc.).

Figur 3 - CCS klassifikation: Statisk klassifikation henover tid

Tid

Traditionel klassifikation

Klassifikation

Information om et objekt

Egenskabsdata

Programmering Projektering Udførsel Drift

Tid

Information om et objekt

Klassifikation

CCS

Egenskabsdata

Programmering Projektering Udførsel Drift


Klassifikationen i CCS er derfor underlagt følgende regler: Regel 6: Bogstaverkoder skal bestå af kapitaliserede latinske bogsta-

ver A til Z med udelukkelse af bogstaverne I og O, da disse kan forveksles med tallene 1 (ét) og 0 (nul).

Regel 7: I bogstavkoder bestående af mere end ét bogstav udgør et

efterfølgende bogstav altid en underklasse af det foregående bogstav. NOTE: Det skal bemærkes at der i klassifikationsaspektet er mulighed for at lave en projektspecifik underklassifikation af CCS-klassifikationen, og at disse underklasser fx kan opbygges af tal.

Regel 8: Inddeling af CCS-klassifikationen i underklasser, der ikke er

defineret i CCS-tabellerne, tillades kun i aspektkoder inden for klassifikationsaspektet. Denne underklassifikation kan ik-ke benyttes i de andre aspektkoder og er kun gældende in-den for konteksten af ét bestemt projekt. Der er ingen be-grænsning for dybden af en sådan underklassifikation.

Sammensætningen af koden følger denne regel:

etc.

B Klassifikationsbogstav

(1) Hovedklasse (2) Underklasse af foranstående klasse (3) Underklasse af foranstående klasse

7.1.5 Løbenumre Løbenumre i CCS benyttes inden for hver aspektkode til identifikation eller alternativt som projektspecifik underklasse. Antallet af karakterer i ethvert løbenummer er ikke fast. For eksempel har det foranstillede ”0” i et løbenummer ingen praktisk betydning, og kan evt. udelades. Udeladelse af ”0” kan dog have indvirkning på sortering mv. i IT systemer hvorfor man kan bestemme i et projekt at inkludere foranstillede nuller. Regel 9: Identifikation i CCS sker ved brug af løbenumre. Der er intet

krav om fast antal af karakterer i et løbenummer. Foranstille-de nuller kan udelades.

Regel 10: Niveauerne i en del-af struktur til identifikation adskilles ved

brug af punktum ”.” imellem hvert niveau i strukturen. Regel 11: Nummerering er fortløbende inden for hvert specifikke ni-

veau i en kodningsstruktur. F.eks. –AB1.CD1.EF1, -AB1.CD2.EF1, -AB2.CD1.EF1. Nummerering går ikke på tværs af niveauer.

(3) (2) (1) B B B


8 Aspektkoderne

Aspektkoderne i de fem aspekter opfylder følgende: Klassifikationsaspekt: Koder i dette aspekt har udelukkende klassificerende formål. Koderne kan ikke benyttes til identifikation. NOTE: Klassifikationsaspektet ligger uden for emneområdet af ISO/IEC 81346, der omhand-ler identifikation af objektforekomster. Klassifikationsaspektet er medtaget i CCS for at kunne anvendes klassifikation separat fra de andre aspekter Simpelt produktaspekt: Koder i dette aspekt identificerer objektforekom-ster. Koderne kan benytte en simpel nummerering (1,2,3 etc.) og er derfor ikke baseret på en strukturel nedbrydning af byggeriet. Aspektet beskriver byggeriet fra en produktsynsvinkel. Strukturelt produktaspekt: Koder i dette aspekt identificerer objektfore-komster i en strukturel dekomponering (systemer og deres bestanddele) af byggeriet. Denne dekomponering kan enten være foruddefineret i CCS eller være bestemt af projektet. Aspektet beskriver byggeriet fra en produkt-synsvinkel. Funktionsaspekt: Koder i dette aspekt kan have forskellige formål enten entydig identificering af brugsrum eller reference for funktioner (og dermed funktionskrav) for bygningsdele. Fælles for koder i dette aspekt er, at de beskriver byggeriet fra en funktionel synsvinkel. Placeringsaspekt: Koder i dette aspekt beskriver fysiske placeringer og bru-ges som x-reference mellem bygningsdele og rum (brugsrum / konstrukti-onsrum). Fælles for koder i dette aspekt er at de beskriver byggeriet fra en fysisk placeringssynsvinkel. Der er i CCS foruddefineret følgende aspektkoder i de fem aspekter:

Aspekt Aspektkode - præfiks Aspektkode - navn

Klassifikationsaspekt % Bygningsdelsklasse

%% Rumklasse

Simpelt produktaspekt # Simpelt bygningsdels ID

## Simpelt rum ID

Strukturelt produkt- - Bygningsdels ID


Aspekt Aspektkode - præfiks Aspektkode - navn

aspekt -- Brugsrums ID

Funktionsaspekt =

Bygningsdels funktions ID

== Rum funktions ID

Placeringsaspekt + Konstruktionsrums pla-

cerings ID

++ Brugsrums placerings ID

Tabel 2 – Foruddefinerede CCS aspektkoder inden for hvert aspekt

Aspektkoderne inddeles i tre grupper

• Gruppe 1: Aspektkoder der udtrykker information i forhold til byg-ningsdele

• Gruppe 2: Aspektkoder der udtrykker information i forhold til brugsrum

• Gruppe 3: Supplererende aspektkoder defineret i byggeprojekt

En oversigt over alle aspektkoderne kan ses i Bilag C - Oversigt over aspekt-koder. Aspektkoder i gruppe 1 beskriver information i relation til bygningsdele. Dette omfatter:

(%) Klassifikation af bygningsdele. (#) Identifikation af bygningsdele, simpel fortlø-

bende nummerering. (-) Identifikation af bygningsdele, baseret på en

CCS defineret dekomponering af bygnings-struktur i systemer og deres bestanddele.

(+) Placeringsreference i forhold til konstruktions-

rum. Placeringsinformation anvendes i CCS som x-reference til bygningsdele og brugsrum.

(=) Funktionsreference for bygningsdele

Aspektkoder i gruppe 2 beskriver information i relation til brugsrum. Dette inkluderer:

(%%) Klassifikation af brugsrum.

#

=-

+ %

##

==--

++ %%


(##) Identifikation af brugsrum, simpel fortløbende nummerering.

(- -) Identifikation af brugsrum, baseret på en CCS

defineret dekomponering af bygningsstruktu-rering.

(==) Identifikation af brugsrum, baseret på en funk-

tionel strukturering, dvs. kodning af funktions-rum.

(++) Placeringsreference i forhold til brugsrum. An-

vendes som x-reference til bygningsdele og konstruktionsrum.

Aspektkoder i gruppe 3 beskriver supplerende information, der ikke kan udtrykkes ved brug af de foruddefinerede aspektkoder i CCS f.eks. identifikation af objekter der ikke kan klassificeres ud fra CCS og identificeres i de foruddefinerede aspektkoder, fx leverancer i moduler til et byggeri der inde-holder objekter på tværs af eksisterende CCS koder. Gruppe 3 er underlagt de samme regler for kodningsprincip-per som de andre aspektkoder og er gyldige inden for ram-merne af et projekt, men ikke generelt i byggebranchen Regel 12: Projektspecifikke aspektkoder anvender 3 ens præfikstegn

(f.eks. ”---”). Definition af sådanne projektspecifikke aspekt-koder skal beskrives i projektets dokumentation inkl. den an-vendte klassifikation.


8.1 Anvendelse af aspektkoder

Hver aspektkode har en anvendelse for enten bygningsdele eller brugsrum der kan ses i Tabel 3 og Tabel 4 herunder.

Kodning af bygningsdele (og systemer)

Aspektkode Anvendelse

% Klassifikationskode for bygningsdele (objekttyper).

# Simpel identifikation hvor alle bygningsdele af en bestemt type nummereres fortløbende i takt med at objekterne genereres

- Identifikation af bygningsdele og systemer baseret på byg-geriets systemstruktur

= Relatering af funktioner til bygningsdele eller systemer

+ X-reference for placeringen af en bygningsdel i forhold til konstruktionsrum dvs. typisk krydsreference for bygningsdeles montagested.

++ X-reference for placeringen af bygningsdel i forhold til brugsrum, dvs. typisk krydsreference for bygningsdeles placering i brugsrum.

Tabel 3 - Aspektkoder til kodning af bygningsdele

Kodning af rum

Aspektkode Anvendelse

%% Klassifikationskode for rum (objekttyper)

## Simpel identifikation hvor alle brugsrum af en bestemt type nummereres fortløbende i takt med at objekterne genereres

- - Identifikation af brugsrum baseret på byggeriets fysiske rumstruktur, som altid vil være projektspecifik.

== Identifikation af brugsrum ud fra et funktionelt design af byggeriet. Man kan således identificere et brugsrum før dets placering er fastlagt, således at man kan designe et byggeri baseret på de nødvendige rumfunktioner.

Tabel 4 - Aspektkoder til kodning af rum

Se endvidere Bilag C - Oversigt over aspektkoder.


8.2 Gruppe 1 aspektkoder

8.2.1 [%] Bygningsdelsklasse Symbol Præfiks % (procenttegn) Hovedformål Ren klassifikation af bygningsdele samt projektspecifik un-

derklassifikation såfremt det er påkrævet. Beskrivelse Aspektkoden bruges til ren klassifikation af bygningsdele.

Koden er baseret på en type-af klassifikation defineret i CCS-klassifikationstabellerne. Det er tilladt inden for rammerne af et byggeprojekt at lave en projektspecifik underklassifikation af CCS-klassifikationen til brug ved gruppering af CCS-typer i pro-jektspecifikke designvarianter f.eks. til udbud og specifikati-on. Klassifikationstemaet der bruges til at underklassificere CCS-typerne bestemmes af projektets deltagere. Såfremt der foretages en sådan underklassifikation er den-ne kun gyldig inden for rammerne af det specifikke projekt og udgør derfor ikke en underklassifikation der kan bruges generelt i byggebranchen. En evt. underklassifikation af CCS-typerne skal beskrives i projektets dokumentation, og der gælder desuden at det kun er CCS-klassifikationen der benyttes i de andre aspekt-koder. Projektspecifik underklassifikation kan derfor kun findes i denne aspektkode.

Klassifikation Aspektkoden gør brug af følgende tabeller:

Bygningsdelstabel 1 (konstruktive bygningsdele) Bygningsdelstabel 2 (elektriske og mekaniske byg-

ningsdele)

For en eventuel projektspecifik underklassifikation gælder de samme syntaksregler for sammensætning af klassifikati-onsbogstaver som for den øvrige klassifikation.


Syntaks Syntaks uden brug af projektbestemt underklassifikation:

B Klassifikationsbogstav(er) (1) Aspekt præfiks (2) CCS bygningsdelsklassifikation

Syntaks med brug af projektbestemt underklassifikation:

B Klassifikationsbogstav(er) T Underklassifikation i form af tal

(1) Aspekt præfiks (2) Bygningsdelsklassifikation (Bygningsdelstabel1 & 2) (3) Projektbestemt underklassifikation vha. tal.

Eksempel Eksempel uden brug af projektbestemt underklassifikation:

%JA Bygningsdel af typen ”Vindue” %JB Bygningsdel af typen ”Dør” Eksempel med brug af projektbestemt underklassifikation: %JB1 Bygningsdel af typen ”Dør”, projektspecifik underty-

pe ”1” %JB2 Bygningsdel af typen ”Dør”, projektspecifik underty-

pe ”2”

NOTE: De viste klasser ”JA”, ”JB” m.fl. er kun illustrative eksempler til brug i denne rapport, da klassifi-kationskoder ikke er omfattet af projektet og endnu ikke er fastlagt i fuldt omfang (marts 2012).

Kodegruppen har dog udarbejdet et forslag klassifikationsprincip - se Bilag E – Bygningsdelstabel 1.

8.2.2 [#] Simpelt bygningsdels ID Symbol

(3) (2) (1) T B %

(2) (1) B %

1 2 3


Præfiks # (nummertegn) Hovedformål Entydig identifikation af bygningsdele, simpel nummerering Beskrivelse Aspektkoden bruges til entydigt at identificere en bygnings-

del uden hensyn til den struktur bygningsdelen indgår i. Identifikationen er derfor ikke baseret på kompositionen af byggeriet og udgør således en enkeltniveaus reference.

Aspektkoden udgør således en enkeltniveaus struktur, med

en simpel nummerering af bygningsdele. Klassifikation Aspektkoden gør brug af følgende tabeller:

Bygningsdelstabel 1 (konstruktive bygningsdele) Bygningsdelstabel 2 (elektriske og mekaniske byg-

ningsdele)

Syntaks

B Klassifikationsbogstav(er) N Løbenummer

(1) Aspekt præfiks (2) Bygningsdelsklassifikation (Bygningsdelstabel 1 & 2) (3) Bygningsdels løbenummer

Eksempel #JA1 Bygningsdel af typen ”Vindue”, nummer 1

#JA34 Bygningsdel af typen ”Vindue”, nummer 34

(3) (2) (1) N B #


8.2.3 [=] Bygningsdels funktions ID Symbol Præfiks = (lighedstegn) Hovedformål Reference for bygningsdels funktion Beskrivelse Aspektkoden bruges som reference for funktioner for sy-

stemer og bygningsdele i en del-af struktur, og muliggør at der kan tilknyttes fælles funktionskrav til forskellige syste-mer og bygningsdele. Aspektkoden beskriver en del-af struktur baseret på en funktionel dekomponering af bygge-riet. De refererede funktionelle objekter i strukturen er de samme objekter der kan findes i den strukturelle dekompo-nering af byggeriet i det strukturelle produktaspekt dvs. bygningssystemer og bygningsdele, men uden en 1:1 relati-on. Aspektkoden kan således ikke entydigt identificere sy-stemer og bygningsdele, men udgør en fælles reference til den samme funktion for flere systemer eller bygningsdele.


Systemtabel Bygningsdelstabel 1 (konstruktive bygningsdele) Bygningsdelstabel 2 (elektriske og mekaniske byg-

ningsdele)

Syntaks Syntaksen i aspektkoden skal kunne afspejle en del-af struk-tur for funktionelle systemer bestående af bygningsdele, hvor bygningsdele i CCS klassificeres enten som underklas-ser af ”Konstruktioner”, ”Del-konstruktioner” eller ”Kom-ponenter”. Del-af strukturen skal overholde følgende hie-rarki for hvor i strukturen objekterne kan indgå.

System -> Konstruktion -> Del-konstruktion -> Komponenter

Systemer udgør altid topniveauet i strukturen og er obliga-torisk. De øvrige underliggende objekter indgår kun i struk-turen såfremt de skal identificeres. Man kan således godt have dele af en struktur hvor der ikke indgår del-konstruktioner, så f.eks. konstruktionerne kun består af komponenter (og ikke del-konstruktioner).

≈≈



(1) Aspekt præfiks (2) Systemklassifikation (Systemtabel) (3) Systemløbenummer (4) Separator ”.” viser det næste niveau i strukturen (5) Bygningsdelsklassifikation (Bygningsdelstabel 1:

”Konstruktioner”, ”Del-konstruktioner” eller ”Kom-ponenter”)

(6) Bygningsdelsløbenummer (7) Separator ”.” viser det næste niveau i strukturen (8) Bygningsdelsklassifikation (Bygningsdelstabel 1: ”Del-

konstruktioner” eller ”Komponenter”) (9) Bygningsdelsløbenummer (10) Separator ”.” viser det næste niveau i strukturen (11) Bygningsdelsklassifikation (Bygningsdelsta-

bel:1”Komponenter”) (12) Bygningsdelsløbenummer

Eksempel Kodning af systemer:

Et byggeri består af fire vægsystemer, hvor to systemer in-deholder bygningens ydre vægsystemer og to vægsystemer indeholder de indre vægkonstruktioner. De forskellige funk-tionskrav til hhv. indre og ydre vægsystemer specificeres ved at knytte dem til forskellige funktionelle systemer i bygningens funktionsstruktur. Vægsystemer i bygningen: -MB1 Vægsystem nummer 1 (indeholdende ydre væg-

konstruktioner) -MB2 Vægsystem nummer 2 (indeholdende ydre væg-

konstruktioner) -MB3 Vægsystem nummer 3 (indeholdende indre væg-

konstruktioner) -MB4 Vægsystem nummer 4 (indeholdende indre væg-

konstruktioner) Bygningens funktionsstruktur er defineret så den indehol-der to tænkte funktionelle systemer: =MB1 Funktionelt vægsystem nummer 1 =MB2 Funktionelt vægsystem nummer 2

(12) (11) (10) (9) (8) (7) (6) (5) (4) (3) (2) (1) N B . N B . N B . N B =


”=MB1” bruges til at specificere funktionskrav for vægsy-stemer der indeholder ydre vægkonstruktioner hvor man f.eks. ønsker at specificere det samlede lysindfald. ”= MB2” bruges til at kunne specificere funktionskrav for vægsystemer der indeholder indre vægkonstruktioner hvor man ønsker at specificere grænser for lydtransmission.

Bygningens fire vægsystemer CCS-kodes derfor således: -MB1 / =MB1 Vægsystem nummer 1 af typen MB, funk-

tionelt vægsystem MB1. -MB2 / =MB1 Vægsystem nummer 2 af typen MB, funk-



tionelt vægsystem MB2.


8.2.4 [-] CCS bygningsdels ID Symbol Præfiks - (minustegn) Hovedformål Entydig identifikation af bygningsdele og systemer, baseret

på del-af struktur Beskrivelse: Aspektkoden benyttes til entydig identifikation af systemer

og bygningsdele. Systemer anvendes til at håndtere og be-skrive sammenhængende bygningsdele frem for bygnings-dele som enkelte objekter. Koden benytter en produkt-mæssig synsvinkel og kan baseres på en generisk model for dekomponering af bygningsdele, der er prædefineret i CCS. Byggeriets systemstruktur kan aflæses af koden, og gør det bl.a. muligt at afkode del-af relationer mellem bygningsde-le. Koden kan således bruges til at finde bestanddelene i byggeriets systemer. Hermed supporteres bl.a. designgen-brug ved inddeling af byggeriet i isolerede designstrukturer samt håndtering af overordnede systemer i byggeriet.


Systemtabel Bygningsdelstabel 1 (konstruktive bygningsdele) Bygningsdelstabel 2 (elektriske og mekaniske byg-

ningsdele, baseret på ISO/IEC 81346-1 tabel 2).

ISO/IEC 81346-2 Tabel 1 for elektriske og mekani-ske delsystemer.

Syntaks Ved kodning af systemer med konstruktive bygningsdele

f.eks. Vægsystemer Anvendt klassifikation:

Systemtabel Bygningsdelstabel 1 (konstruktive bygningsdele)

I systemer med konstruktive bygningsdele klassificeres byg-ningsdelene som underklasser af ”Konstruktioner”, ”Del-konstruktioner” eller ”Komponenter” jævnfør Bilag E – Byg-ningsdelstabel 1 Aspektkoden skal i disse systemer beskrive en del-af struk-tur der overholder følgende hierarki for hvor i strukturen objekterne kan indgå:


Systemer -> Konstruktioner -> Del-konstruktioner -> Kom-ponenter Systemer udgør altid topniveauet i strukturen og er obliga-torisk. De øvrige underliggende objekter indgår kun i struk-turen såfremt de skal identificeres. Man kan således have forskellige strukturer alt efter hvad der ønskes identificeres.

Syntaksen for konstruktive systemer ser således ud


(4) Aspekt præfiks (5) Systemklassifikation (Systemtabel) (6) Systemløbenummer (7) Separator ”.” viser det næste niveau i strukturen (8) Bygningsdelsklassifikation (Bygningsdelstabel 1:

”Konstruktioner”, ”Del-konstruktioner” eller ”Kom-ponenter”)

(9) Bygningsdelsløbenummer (10) Separator ”.” viser det næste niveau i strukturen (11) Bygningsdelsklassifikation (Bygningsdelstabel 1: ”Del-

konstruktioner” eller ”Komponenter”) (12) Bygningsdelsløbenummer (13) Separator ”.” viser det næste niveau i strukturen (14) Bygningsdelsklassifikation (Bygningsdelsta-

bel:1”Komponenter”) (15) Bygningsdelsløbenummer

Ved kodning af elektriske og mekaniske systemer f.eks. ”Be-lysningssystem” Anvendt klassifikation

Systemtabel Bygningsdelstabel 2 (elektriske og mekaniske byg-

ningsdele) ISO/IEC 81346-2 Tabel 1

I modsætning til de konstruktive systemer har aspektkoden i de elektriske og mekaniske systemer i teorien ikke noget maksimalt antal niveauer. Den del-af struktur aspektkoden beskriver, har kun defineret et øverste og nederste niveau,

(12) (11) (10) (9) (8) (7) (6) (5) (4) (3) (2) (1) N B . N B . N B . N B -


hvorimod der kan defineres et vilkårligt antal mellemlig-gende systemniveauer.

• Topniveau: CCS system (obligatorisk) o Klassifikation i forhold til CCS systemtabel

• Mellemniveauer (vilkårligt antal): Undersystemer defineret i projektet (valgfri)

o Klassifikation i henhold til ISO/IEC 81346-2 Tabel 1

• Nederste niveau: CCS bygningsdele o Klassifikation i henhold til CCS bygnings-

delstabel 2

Det anbefales, at der i klassifikationsprojektet defineres en række generiske systemstrukturer for hvert hovedsystem, som det anbefales at anvende i branchen.

Syntaksen for elektriske og mekaniske systemer ser således

ud


(1) Aspekt præfiks (2) Systemklassifikation (Systemtabel) (3) Systemløbenummer (4) Separator ”.” viser det næste niveau i strukturen (5) Undersystem; vilkårligt antal undersyste-

mer/niveauer (ISO/IEC 81346-2 Tabel 1) (6) Undersystems løbenummer (7) Separator ”.” viser det næste niveau i strukturen (8) Bygningsdelsklassifikation (Bygningsdelstabel 2) (9) Bygningsdelsløbenummer

Eksempel Ved kodning af systemer med konstruktive bygningsdele f.eks. ”Vægsystem” -MB2.DF4.LUD2 Koden dekodes til: Vægsystem nr. 2 > Vægkonstruktion nr.

4 > Plade nr. 2. Koden beskriver: Plade nr. 2 i Vægkonstruktion nr. 4 i

Vægsystem nr. 2. -MB3.LUD2 Koden dekodes til: Vægsystem nr. 3 > Plade nr. 2 Koden beskriver: Plade nr. 2 i Vægsystem nr. 3 Ved kodning af elektriske og mekaniske systemer f.eks. Be-lysningssystem

(9) (8) (7) (6) (5) (4) (3) (2) (1) N B . N B . N B -


-XC1.SFA1 Koden dekodes til: Belysningssystem 1 > Afbryder nr. 1 Koden beskriver: Afbryder nr. 1 i Belysningssystem 1 -XC2.Q1.SFA2 Koden dekodes til: Belysningssystem 2 > Afbrydersystem

1 > Afbryder nr. 2 Koden beskriver: Afbryder nr. 2 i Afbrydersystem 1 i

Belysningssystem 2


8.2.5 [+] Konstruktionsrums placerings ID Symbol Præfiks + (plustegn) Hovedformål Reference for objekter placering i forhold konstruktionsrum Beskrivelse Aspektkoden bruges til reference for objekters placering i

forhold til konstruktionsrum, defineret som det rum der udgøres af byggeriets bygningsdele. Koden beskriver såle-des placeringen af bygningsdele i forhold til andre byg-ningsdele, og kan bruges til at beskrive placeringsinformati-on som ikke fremgår af [-]-koden. Det kan f.eks. være til-fældet når bygningsdele er monteret i andre bygningsdele i et andet system. Dette er bl.a. tilfældet for bygningsdele i de elektriske systemer, der er monteret i bygningsdele i de konstruktive systemer såsom vægsystemer.

Syntaks Da konstruktionsrummet er defineret som det konstruktive

rum der udgøres af bygningsdele, skal aspektkoden beskri-ve en del-af struktur der er en kopi af del-af strukturen i [-] koden. Syntaksen for denne aspektkode er derfor den samme som for [-] koden på den bygningsdel der refereres til.

Klassifikation Der benyttes den samme klassifikation som i [-] og aspekt-

koden gør derfor brug af følgende tabeller:

Systemtabel Bygningsdelstabel A (konstruktive bygningsdele) Bygningsdelstabel B (elektriske og mekaniske byg-

ningsdele)

Eksempel Kodning af en placering

+MB2.DF4.LUD1 Koden dekodes til: Placering; Vægsystem nr. 2 >

Vægkonstruktion nr. 4 > Plade Nr. 1

Koden beskriver: Placering; Plade Nr. 1 i Vægkon-struktion nr. 4 i Vægsystem nr. 2

Placeringen anvendes som link af en bygningsdels placering

til konstruktionsrummet: -XC1.SFA1 / +MB2.DF4.LUD1 Koden dekodes til: Belysningssystem 1 > Afbryder nr.

1 placeret i Vægsystem nr. 2 >


Vægkonstruktion nr. 4. > Plade nr. 1

Koden beskriver: Afbryder nr. 1 i Belysningssystem

1 placeret i Plade nr. 1 i Vægkon-struktion nr. 4 i Vægsystem nr. 2”



8.3.1 [%%] Rumklasse Symbol Præfiks %% (procenttegn procenttegn) Hovedformål Ren klassifikation af brugsrum samt projektspecifik under-

klassifikation Beskrivelse Denne aspektkode bruges til ren klassifikation af brugsrum.

Koden er baseret på en type-af klassifikation defineret i CCS-klassifikationstabellerne. Det er tilladt inden for rammerne af et byggeprojekt at lave en projektspecifik underklassifikation af CCS-klassifikationen til brug ved grupperes af CCS-typer i pro-jektspecifikke designvarianter f.eks. til udbud og specifikati-on. Klassifikationstemaet der bruges til at underklassificere CCS-typerne bestemmes af projektets deltagere. Såfremt der foretages en underklassifikation er denne kun gyldig inden for rammerne af det specifikke projekt og ud-gør derfor ikke en underklassifikation der kan bruges gene-relt i byggebranchen. En evt. underklassifikation af CCS-typerne skal beskrives i projektets dokumentation, og der gælder desuden at det kun er CCS-klassifikationen der benyttes i de andre aspekt-koder. Projektspecifik underklassifikation kan derfor kun findes i denne aspektkode.


Brugsrumstabel 1 • Tabellen indeholder underklasserne for

brugsrum med en karakteristisk funktion f.eks. typen ”Møderum”

Syntaks Syntaks uden brug af projektbestemt underklassifikation:

B Klassifikationsbogstav(er)

(1) Aspekt præfiks

(2) (1) B %


(2) CCS brugsrumsklassifikation

Syntaks med brug af projektbestemt underklassifikation:

B Klassifikationsbogstav(er) T Typenummer

(1) Aspekt præfiks (2) Brugsrumsklassifikation (Brugsrumstabel 1) (3) Projektbestemt underklassifikation af CCS type vha.

tal.

Eksempel Eksempel uden brug af projektbestemt underklassifikation:

%%CA Brugsrum af typen ”Baderum” %%LA Brugsrum af typen ”Møderum”

Eksempel med brug af projektbestemt underklassifikation: %%CA1 Brugsrum af typen ”Baderum”, projektspecifik un-

dertype ”1” %%CA2 Brugsrum af typen ”Baderum”, projektspecifik un-

dertype ”2”

NOTE: Eksempel på projektspecifik undertype 1 af et baderum kan fx være ”Baderum med brusekabine” og projektspecifik un-dertype 2 kan fx være ”Baderum med badekar”.

(3) (2) (1) T B %


8.3.2 [##] Simpelt rum ID Symbol Præfiks ## (nummertegn nummertegn) Hovedformål Entydig identifikation af brugsrum uden hensyn til fysisk

placering Beskrivelse Aspektkoden bruges til entydigt at identificere t 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 brugs-rum. Aspektkoden udgør en enkeltniveaus struktur, med en simpel nummerering af brugsrum.


Brugsrumstabel 2

Syntaks


(1) Aspekt præfiks (2) Brugsrumsklassifikation (Brugsrumstabel 2) (3) Brugsrums løbenummer

Eksempel ##LA1 Brugsrum af typen ”Møderum”, nummer 1

##LA34 Brugsrum af typen ”Møderum”, nummer 34

(3) (2) (1) N B #

1 2 3


8.3.3 [==] Rum funktions ID Symbol Præfiks == (lighedstegn lighedstegn) Hovedformål Entydig identifikation af brugsrum baseret på en funktionel

gruppering af byggeri Beskrivelse Aspektkoden bruges til entydigt at identificere brugsrum

baseret på en funktionel gruppering af rummene. Den funk-tionelle gruppering afspejler derfor ikke den fysiske place-ring af brugsrummene og kan i stedet bruges til at designe et byggeri på et funktionelt plan, uden at have fastlagt det endelige (fysiske) bygningsdesign. Brugsrum i denne aspektkode kaldes derfor funktionsrum.


Brugsrumstabel 1 • Tabellen indeholder de overordnede klas-

ser for brugsrum med en karakteristisk funktion f.eks. klassen ”Beboelse”

• Tabellen indeholder underklasserne for brugsrum med en karakteristisk funktion f.eks. ”Møderum”

Syntaks Syntaksen i denne aspektkode tillader kodning af en del-af struktur med et vilkårligt antal niveauer, hvor det er muligt i byggeprojektet at definere projektspecifikke funktionsrum der kan bruges til samling af brugsrumsobjekter der er for-uddefineret i CCS. Den del-af struktur aspektkoden kan ko-de er derfor kendetegnet ved følgende:

• Øvre niveauer (vilkårligt antal): Funktionsrum defi-neret i projektet

• Mellemniveauer (projektspecifik) • Nederste niveau: Funktionsrum defineret i CCS

o Klassifikation i henhold til Brugsrumstabel 1


(1) Aspekt præfiks

(11) (10) (9) (8) (7) (6) (5) (4) (3) (2) (1) N B . N . N B . N B =


(2) Projektspecifik funktionsrum; vilkårligt antal niveauer (3) Funktionsrumsløbenummer (4) Separator ”.” viser det næste niveau i strukturen (5) Funktionsrumsklassifikation (projektspecifik) (6) Funktionsrumsløbenummer

Eksempel Brugsrummene i et hospital skal kodes ud fra et samlet

funktionelt brugsrum (funktionsrum) kaldet ”Kirurgisk af-snit”, hvori der skal være et antal operationsstuer med til-hørende faciliteter. Operationsstuerne i det kirurgiske afsnit skal klassificeres efter Brugsrumstabel 1, da dette brugsrum er defineret i CCS. Det specificerede funktionelle brugsrums ”Kirurgisk afsnit” skal som et af de øvre niveauer i den funktionelle del-af struktur være projektspecifikt, da det samler en række af funktionsrum defineret i CCS Brugsrumstabel 1. Aspektkoden for en operationsstue kan derfor f.eks. være: ==M1.MC2 Koden dekodes til: Funktionsgruppe 1 > Behandlingsrum

nr. 2 Koden beskriver: Behandlingsrum nr. 2 i Funktionsgrup-

pe 1 (fx operationsafsnit)


8.3.4 [––] CCS brugsrums ID Symbol Præfiks -- (minustegn minustegn) Hovedformål Entydig identifikation af brugsrum samt bebyggelser og

bygninger. Beskrivelse Aspektkoden identificerer entydigt bebyggelser, bygninger

etager og brugsrum ud fra en strukturel dekomponering af bygningen, der altid vil være projektspecifik. Kodens struk-tur afspejler den fysiske placering af brugsrummene i kon-struktionen og kan således bruges til orientering i det fær-dige byggeri.

Klassifikation Aspektkoden gør ikke brug af CCS klassifikationstabeller,

men vil være projektspecifik. Syntaks Aspektkoden beskriver en del-af struktur der følger følgen-

de hierarki: (Bebyggelse) -> (Bygning) -> Etage -> Brugsrum Niveauerne for bebyggelse og bygning kan udelades fra

strukturen i tråd med projektets behov, men hierarkiet skal følges og der må ikke fjernes niveauet for bygning uden og-så at fjerne niveauet for bebyggelse. Såfremt bebyggelse og bygning udelades fra strukturen skal dette fremgå af pro-jektets dokumentation. Syntaksen for aspektkoden ser derfor således ud

N Beskrivelse og/eller løbenummer

(1) Aspekt præfiks (2) Bygningsløbenummer (3) Separator ”.” viser det næste niveau i strukturen (4) Etagenummer (5) Separator ”.” viser det næste niveau i strukturen (6) Brugsrumsløbenummer (7)

Eksempel --BYG1.K1.25 Koden dekodes til: Bygning 1 > Kælderniveau 1 > Rum nr. 25 Koden beskriver: Rum nr. 25 i Kælderniveau 1 i Bygning 1

(6) (5) (4) (3) (2) (1) N . N . N =


8.3.5 [++] Brugsrums placerings ID Symbol Præfiks ++ (plustegn plustegn) Hovedformål Reference for placering i forhold til brugsrum Beskrivelse Denne aspektkode udgør en reference for placeringen af et

bygningsdel i forhold til brugsrum f.eks. en bygningsdels placering i forhold til et brugsrum. Strukturen af koden er en kopi af strukturen i [--](minustegn minustegn) koden, men hvor [--] koden bruges som entydig identifikator for brugsrummet, så bruges [++] koden som link til bygningsdeles placering i brugsrummet. De to koder er adskilt så der ikke er nogen tvivl om hvilket objekt der identificeres.

Klassifikation Aspektkoden gør ikke brug af CCS klassifikationstabeller. Syntaks Da aspektkoden skal beskrive en del-af struktur der er en

kopi af [--] strukturen er syntaksen for denne aspektkode den samme som for [--] koden med undtagelse af præfiks.

Eksempel Kodning af en placering

++BYG1.K1.25 Koden dekodes til: Placering: Bygning 1 > Kælderniveau 1

> Rum nr. 25 Koden beskriver: Rum nr. 25 i Kælderniveau 1 i Bygning

1

Placeringen anvendes som link af en bygningsdels placering til brugsrummet, f.eks.: -XC1.SFA1 / ++BYG1.K1.25 Koden dekodes til: Belysningssystem 1 > Afbryder nr.

1 placeret i Bygning 1 > Kælder-niveau 1 > Rum nr. 25

Koden beskriver: Afbryder nr. 1 i Belysningssystem

1 placeret i Rum nr. 25 i Kælderni-veau 1 i Bygning 1”



CCS tillader definition af projektspecifikke aspektkoder, der er gyldige inden for rammerne af et projekt, men ikke generelt i byggebranchen. Projekt-specifikke aspektkoder kan bruges til formål der ikke er dækket af de for-uddefinerede CCS aspektkoder, f.eks. identifikation af objekter der ikke kan klassificeres ud fra CS-klassifikationstabellerne og identificeres i de forudde-finerede aspektkoder. Definition af sådanne projektspecifikke aspektkoder skal beskrives i projek-tets dokumentation inkl. den anvendte klassifikation. Aspektkoderne er underlagt syntaksreglerne for kodning i CCS. Projektspecifikke aspektkoder gør brug af præfikstypen for det pågældende aspekt og tilføjer blot en karakter til præfikset f.eks. [---] (minustegn minus-tegn minustegn).

8.4.1 [---] Projektspecifk aspektkode Præfiks --- (minustegn minustegn minustegn) Hovedformål Entydig identifikation, supplerende information. Beskrivelse Aspektkoden kan bruges til at identificere bygningsdele ud

fra en strukturel dekomponering af byggeriet i det struktu-relle produktaspekt. Denne dekomponering følger således ikke dekomponeringen i den i CCS definerede aspektkode [-]. Aspektkoden koder en del-af struktur baseret på moduler hvori der indgår bygningsdele der normalt ville kodes som en del af forskellige systemer i [-] koden. Et eksempel på dette kunne f.eks. være et badeværelses-modul, der ville indeholde både strukturelle, elektriske og mekaniske bygningsdele, hvor selve modulet ikke ville kun-ne klassificeres efter CCS.

Syntaks De generelle syntaksregler for opbygning af del-af baserede

koder skal følges i dette aspekt. Klassifikation Bygningsdele er de eneste objekter i denne aspektkode der

klassificeres, hvorimod alle andre objekter i del-af struktu-ren kun får tildelt et løbenummer. Der benyttes klassifikati-onstabellerne for bygningsdele.


9 Kodningseksempler

9.1 Dør

Nedenstående eksempel viser design og anvendelse af en dør i en bygning. Listenumrene referer til numrene i Figur 4, og projektet udelader reference for bebyggelse og bygning da projektet kun omfatter designet af én enkelt bygning. CCS klassifikation:

1. Designeren vælger først en dør fra symbolbiblioteket, der har in-kluderet CCS klassifikationskoden for en dør:

Bygningsdelsklasse (ren klassifikation): %JB CCS-klassifikation: ”Dør”

2. Objektet har eventuelt egenskabsdata, der fx beskriver at det valg-te objekt er en ”Træ-inderdør”.

Klassifikationen JB følger herefter objektet, og kan enten anvendes separat (%JB), eller indgå i en eller flere andre aspektkoder: CCS identifikation:

3. Designeren har designet et vægsystem, hvoraf der herunder ses et udsnit:

-MB3 Vægsystem nr. 3 -MB3.DF3 Vægkonstruktion nr. 3 -MB3.DF3.JD1 Søjle nr. 1 -MB3.DF3.JD1.LPA1 Armering nr. 1

4. Den valgte dør placeres i vægsystem 3 dvs. en objektforekomst op-står i vægsystemet hvorved døren får tildelt løbenummer.

-MB3.JB2 Dør nr. 2 i Vægsystem nr. 3

5. Da det er relevant at vide hvilken vægkonstruktion i vægsystemet døren skal monteres i, tildeles dørens objektforekomst en referen-ce for placeringen i konstruktionsrummet:

-MB3.JB2 / +MB3.DF3 Koden læses: Dør nr. 2 i Vægsystem nr. 3 placeret i Vægkonstrukti-on nr. 3 i Vægsystem nr. 3


Figur 4 - CCS eksempel med dør

Alternativt kunne designeren først havde tegnet en dør i vægsystemet og dernæst valgt en specifik variant ved at ændre egenskabsdata for objektfo-rekomsten. I så fald havde forløbet været således (se Figur 5):

1. Designeren har designet et vægsystem ”-MB3”. 2. Designeren vælger et dør-objekt fra sit symbol bibliotek. 3. Objektet indsættes i vægsystemet og der opstår en objektfore-

komst med en placeringsreference

-MB3.JB1 / +MB3.DF3 Dør nr. 1 i Vægsystem nr. 3

4. Der vælges egenskabsdata for objektforekomsten som tilskrives egenskabsdata f.eks. ”Træ-inderdør”.


Figur 5 - CCS eksempel med dør

Udover at give døren en reference for placeringen i forhold til konstrukti-onsrummet, kan der tildeles yderligere koder f.eks. Brugsrums placerings ID (placeringsreference): ++E1.11 Placeringen ”Rum 11 på Etage nr. 1 Bygningsdels funktions ID (funktionsreference): =MB1 Reference for en nedarvet funktion for vægsystemer.

Funktionen kunne bl.a. bruges til specifikation af krav til lydtransmissions for vægsystemer og deres be-standdele.

Designeren kunne ønske en simpel forløbende nummerering af alle døre i bygningen således: Bygningsdelsklasse: #JB7 Dør nr. 7 i bygningen


Den samlede CCS-kodestreng for døren i eksemplet kunne derfor maksimalt komme til at se således ud, såfremt alle aspektkoder blev anvendt:

%JB / #JB7 / -MB3.JB2 / =MB1 / +MB3.DF3 / ++A1.AAA1 Hvis der kun er brug for klassifikation og identifikation kan en kort kode-streng bruges i stedet f.eks.:

%JB / #JB7 eller %JB / -MB3.JB2


9.2 Afbryder

Nedenstående eksempel viser design og anvendelse af en elektrisk afbryder i en bygning. Listenumrene referer til numrene i Figur 6, og projektet ude-lader reference for bebyggelse og bygning da projektet kun involverer de-signet af én enkelt bygning. CCS klassifikation:

1. Designeren vælger “Afbryder” fra sit symbol bibliotek. • Afbryderen er en elektrisk bygningsdel og klassificeres efter

Bygningsdelstabel 2 som ”SFA” (Afbryder) • Hovedklasse ”Omforme en manuel operation” (S) • Underklasse ”Give et elektrisk signal” (F) • Underklasse ”Afbryder” (A)

2. Objektet har egenskabsdata der beskriver at det valgte objekt er en ”Kroneafbryder”

CCS identifikation:

3. Designeren har designet et vægsystem, hvoraf der herunder ses et udsnit:

-MB3 Vægsystem nr. 3 -MB3.DF3 Vægkonstruktion nr. 3 -MB3.DF3.JD1 Søjle nr. 1 -MB3.DF3.JD1.LPA1 Armering nr. 1

4. Den valgte afbryder indsættes i konstruktionen som en del af et Be-lysningssystem hvorved afbryderen får tildelt løbenummer.

-XC1.SFA1 Afbryder nr. 1 i Belysningssystem 1

5. Da det er relevant at vide hvilken vægkonstruktion i vægsystemet afbryderen skal monteres i, tildeles afbryderens objektforekomst en reference for placeringen i konstruktionsrummet

-XC1.SFA1 / +MB3.DF1 Koden læses: Afbryder nr. 1 i Belysningssystem nr. 1 placeret i Vægkonstruktion nr. 1 i Vægsystem nr. 3.


Figur 6 - CCS eksempel med afbryder


10 Forslag til klassifikation

CCS klassifikationstabeller er ikke omfattet af projektgruppens arbejde. I forbindelse med udviklingen af syntaks og kodningsprincipper har det været nødvendigt at studere klassifikationsmekanismer, da disse indgår som en del af kodningsprincippet. Der er i dette projekt udarbejdet derfor udarbejdet forslag til klassifikati-onstemaer og klassifikationsgrundlag for følgende objekter.

• Bygningsdele o Systemtabel o Bygningsdelstabel 1 o Bygningsdelstabel 2 o ISO/IEC 81346-2 Tabel 1

• Bebyggelser o Bebyggelsestabel

• Bygninger o Bygningstabel

• Brugsrum o Brugsrumstabel 1 o Brugsrumstabel 2

Disse forslag er grundlag for det videre klassifikationsarbejde. Der er derfor ikke tale om de endelige klassifikationstabeller, og klassifikationstemaerne kan endnu ændres i forbindelse med klassifikationsarbejdet der foregår i andet regi.

10.1 Bygningsdele

I forslaget til klassifikation af bygningsdele i CCS foreslås det at definere klassifikationstemaer der gør det enkelt at klassificere en bygningsdel. Det betyder at klassifikationen er:

• Uafhængig af aspektet dvs. en bygningsdel klassificeres ensartet i alle aspekter.

• Stabil klassifikation uanset hvilken kompositorisk sammenhæng den klassificerede bygningsdel indgår i.

• Baseret på få egenskaber, hvormed flere egenskaber skal angives som egenskabsdata og ikke kodes som klassifikation.

Der foreslås forskelligt klassifikationstema for hhv. konstruktive bygnings-dele såsom vægkonstruktioner, søjler, armering etc. og til elektriske og mekaniske bygningsdele såsom afbrydere, ledninger og ventiler dvs. typisk installationer.


Nødvendigheden af forskellige klassifikationstemaer skyldes hovedsageligt de forskelle der er i de faglige domæners tilgang til strukturering samt at mekaniske og elektriske bygningsdele allerede er underlagt normmæssige krav om identifikation iht. ISO/IEC 81346. I de følgende afsnit beskrives forslag til klassifikationen for bygningsdele. Klassifikationen er opdelt i følgende tabeller

Tabel Klassificerede bygningsdele

Systemtabel Hovedsystemer for byggeri

Bygningsdelstabel 1 Konstruktive bygningsdele

Bygningsdelstabel 2 Elektriske og mekaniske bygningsdele

(baseret på ISO/IEC 81346-2 tabel 2).

ISO/IEC 81346-2 Tabel 1 Undersystemer i de elektriske og mekaniske hovedsystemer

Tabel 5- Klassifikationstabeller for bygningsdele

10.1.1 Hovedsystemer Den nuværende udgave af DBK2006 indeholder en lang række byggetekni-ske systemer, der anvendes til at samle bygningsdele efter ’del-af’ princip-pet. De bygningstekniske systemer fra DBK2006 skal tildeles en ny klassificeren-de bogstavkode, fx som vist i eksemplet herunder:

Nuværende DBK2006 kode

Forslag til ny CCS kode iht. ISO/IEC 81346-2

tabel 3

System

A_ (Reserveret)

100 KA Terræn

200 MA Fundamentsystem

205 MB Vægsystem

210 MC Dæksystem

215 MD Tagsystem

300 PA Vandsystem

305 PB Afløbssystem

310 PC Gas-og luftsystem

315 PD Kølesystem

320 PE Varmesystem


Nuværende DBK2006 kode

Forslag til ny CCS kode iht. ISO/IEC 81346-2

tabel 3

System

325 PF Ventilationssystem

355 QA Transportsystem

400 SA Inventar

340 XA El-forsyningssytem

345 XB Automationssystem

330 XC Belysningssystem

335 XD Adgangssystem

350 XE Beskyttelsessystem

360 YA Kommunikationssystem

365 YB Brand- og alarmsystem

Tabel 6 - CCS klasser af hovedsystemer

NOTE: De viste kodebogstaver i omstående tabel er erstatning for de tidligere DBK2006 talkoder 200, 205, 210,… da der rettelig er tale om en klassifikation af systemer, og forslaget i CCS er at benytte bogstaver til klassifikation. Hvert system kan endvidere tildeles et løbe-nummer, fx MB1 (vægsystem 1), MB2 (vægsystem 2) etc. Såfremt et system har forbindelse til andre systemer (ex. varmeflade i et ventilationssystem har forbindelse til et varmesystem) håndteres dette vha. relationer, der betragtes som/gemmes som en egenskab til de relevante objekter. Objektet kodes dermed ikke som en del af begge systemer gen-nem CCS koden, men identificeres udelukkende som værende en del af ét system. Relationen kan udtrykkes ved hjælp af [+] og [++] aspektkoderne.


10.1.2 Bygningsdele – Konstruktive Eksempler for Bygningsdelstabel 1 kan ses i Bilag E – Bygningsdelstabel 1. Der foreslås en simpel klassificering baseret på tre hovedklasser af byg-ningsdele:

Konstruktioner, Del-konstruktioner og Komponenter. De tre klasser relateres til hovedsystemerne således:

Systemer ABSOLUT DEFINITION: Kompositionsniveau 1


KONSTRUKTIONER (D) ABSOLUT DEFINITION: Kompositionsniveau 2

RELATIV DEFINITION: Sammensætning af DEL-KONSTRUKTIONER og/eller KOMPONENTER, der kan indgå i SYSTE-MER. ABSTRAKT DEFINITION: Bygningsdel bestående af andre bygningsdele, der kan indgå i systemer.

DEL-KONSTRUKTIONER (J) ABSOLUT DEFINITION: Kompositionsniveau 3 RELATIV DEFINITION: Sammensætning af KOM-PONENTER, der kan indgå i KONSTRUKTIONER eller SYSTEMER. ABSTRAKT DEFINITION: Bygningsdel der kan under-inddeles i andre bygnings-dele, og kan indgå i syste-mer eller andre bygnings-dele.

Figur 7 - Eksempel på Konstruktion

Figur 8 - Eksempel på del-konstruktioner


Figur 9 - Eksempel på Komponenter

KOMPONENTER (L) ABSOLUT DEFINITION: Kompositionsniveau 4

RELATIV DEFINITION: Bygningsdel der kan indgå i KONSTRUKTIONER eller DEL-KONSTRUKTIONER.

ABSTRAKT DEFINITION: Bygningsdel der ikke yderligere underinddeles og kan indgå i andre bygningsdele.

Det er i forslaget til klassifikationstabellen søgt at undgå konflikt med kod-ning af elektriske og mekaniske bygningsdele efter ISO/IEC 81346-2, men projektgruppen er opmærksom på at det funktionelle klassifikationstema i ISO/IEC 81346-2 ikke kan accepteres af de konstruktive domæner. Tabellen til klassifikation af konstruktive bygningsdele foreslås derfor opbygget såle-des:

• De tre nødvendige hovedklasser (Konstruktioner, Del-konstruktioner og Komponenter) tideles hver et bogstav, der ikke er i konflikt med brugen af bogstaver i ISO/IEC 81346-2 tabel 1.

• Der vælges et passende underklassifikationstema for hver hoved-klasse såfremt det er nødvendigt med en underklassifikation

• Egenskabsdata såsom materialer eller form indgår ikke som klassifi-kationstema.


Bygningsdelstabel 1 vil kan f.eks. opbygges således:

Konstruktioner

Klassifikationsniveau 1 2

Klassifikationstema Konstruktionsdefinition (tema ikke fast-lagt)

Klassifikationsbogstaver D A-Z undtagen I & O

Tabel 7 - Klassen "Konstruktioner"

Produkter

Klassifikationsniveau 1 2

Klassifikationstema Produktdefinition (tema ikke fastlagt)

Klassifikationsbogstaver J A-Z undtagen I & O

Tabel 8 - Klassen "Produkter"

Komponenter

Klassifikationsniveau 1 2 3

Klassifikationstema Komponentdefinition Primær tiltænkt funktion

(tema ikke fast-

lagt)

Klassifikationsbogstaver L A-Z und-tagen I &

O

A-Z und-tagen I &

O

Tabel 9 - Klassen "Komponenter"

Underklassifikationstema for Konstruktioner og Del-konstruktioner er ikke fastlagt i forbindelse med dette projekt. Underklassifikationen i niveau to af komponentklassifikationen bruger et klassifikationstema om en primær tiltænkt anvendelse. Dette kan f.eks. være: Forstærkning, Afdækning, Afskærmning etc. Dette er begreber der allerede optræder i de nuværende DBK2006 tabeller, men som ting og ikke funktioner. I CCS foreslås det at anvende disse begreber som funktioner og tildele komponenter en tilknytning til en bestemt funktion. Såfremt projektgruppens anbefaling følges, vil der dels sikres en forholdsvis simpel klassifikation af konstruktive bygningsdele, dels vil der være en del typer i den nuværende DBK2006 der kan overflyttes som egenskaber til objekter. Da inddelingskriteriet vil være veldefineret, vil det ligeledes være klart hvad der kan overføres til egenskabsdomænet.


Gruppen anbefaler, at udgangspunktet for den nye klassifikation skal være den eksisterende DBK2006 tabel 25a .

10.1.3 Bygningsdele – elektriske og mekaniske Nuværende tabeller i ISO/IEC 81346-2 omfatter allerede de mekaniske og elektriske bygningsdele og benytter primær funktion som klassifikationste-ma. Dette betyder, at hovedklassifikationen for mekaniske og elektriske bygningsdele allerede er defineret og kan anvendes direkte i CCS. Projektgruppen foreslår at bibeholde dette klassifikationstema og dermed udarbejde en tabel for elektriske og mekaniske bygningsdele efter dette klassifikationstema kaldet Bygningsdelstabel 2 i denne rapport. I praksis vil der være tale om underklasser til tabel 2 i ISO/IEC 81346-2 dvs. klasserne B, C, E, F, G, H, K, M, N, P, Q, R, S, T, U, V, X, Y og Z. Klasse I og O anvendes ikke, da bogstaverne kan forveksles med tallene 1 og 0. Klasse D, J og L anvendes ikke for at undgå konflikt med klassifikationen af de kon-struktive bygningsdele, Konstruktioner (D), Del-konstruktioner (J) og Kom-ponenter (L). Det er nødvendigt at lave en underinddeling af klasserne i ISO/IEC 81346-2 Tabel 2 for at IT systemerne kan skelne mellem objekterne i systemer. Der er behov for minimum en tre karakterer bogstavskode på objektet for at sikre entydighed, i forhold til de kun to karakterer som ISO/IEC 81346-2 Tabel 2 definerer. Denne udbygning er i overensstemmelse med reglerne for klassifikation i ISO/IEC 81346-2. Såfremt der udvikles nye tabeller på baggrund af ISO/IEC 81346-2, vil den aktive danske deltagelse i standardiseringsarbejdet kunne medføre, at de danske tilføjelser eventuelt kan indarbejdes ved en senere revision af ISO/IEC 81346 standardserien. Bygningsdelstabel 2 foreslås derfor at have en opbygning således: Elektriske og mekaniske bygningsdele

Klassifikationsniveau 1 2 3

Klassifikationstema Bestemt af ISO/IEC

81346-2 Tabel 2

Bestemt af ISO/IEC

81346-2 Ta-bel 2

(tema ikke fastlagt)

Klassifikationsbogstaver A-Z undtagen D,I, J, L, O

A-Z undtagen I & O

A-Z undtagen I & O

Tabel 10 - Klassifikation i tabellen Bygningsdelstabel 2

Der vil i aspektkoderne yderligere være brug for at klassificere en række undersystemer til de elektriske og mekaniske hovedsystemer der defineres i CCS. Projektgruppen anbefaler at der til disse undersystemer anvendes klassifikations tabellen ISO/IEC 81346-2 Tabel 1. Det anbefales yderligere at der udarbejdes foreslåede systemnedbrydninger for de forskellige elektri-


ske og mekaniske hovedsystemer, således at der defineres en generisk an-vendelig systemnedbrydning for de elektriske og mekaniske systemer.

10.2 Bebyggelser

Projektgruppen anbefaler at klassifikationen af bebyggelser baseres på Ta-bel 10/10a ”Bebyggelsestyper i produktaspektet” fra DBK2006, med den ændring at der udelukkende benyttes bogstaver og ikke tal.

10.3 Bygninger

Projektgruppen anbefaler at klassifikationen af bebyggelser baseres på DBK2006 Tabel 15/16a ”Bygning eller anlæg med den karakteristiske funk-tion”, med den ændring at der udelukkende benyttes bogstaver og ikke tal.

10.4 Brugsrum

Projektgruppen anbefaler at klassifikationen af bebyggelser baseres på DBK2006 Tabel 20/20a ”Brugsrum med den karakteristiske funktion”, med den ændring at der udelukkende benyttes bogstaver og ikke tal. Der foreslås udarbejdet to tabeller

• Brugsrumstabel 1 o Tabellen indeholder de overordnede klasser for brugsrum

med en karakteristisk funktion f.eks. klassen ”Beboelse” og klassen ”Ophold”

• Brugsrumstabel 2 o Tabellen indeholder underklasserne for brugsrum med en

karakteristisk funktion f.eks. ”Møderum”


11 Relation til internationale standarder m.v.

11.1 IFC/IFD

Det er et grundlag for revisionen af DBK2006, at principperne skal virke sammen med Building Smart Directory, også benævnt IFD. Kodemekanisme i CCS vil virke direkte sammen med både IFC og IFD, da CCS tjener et andet formål end IFC/IFD.

• CCS-koden indeholder en lang række delkoder. Heraf er et af for-målene med koden at identificere forekomsten af et givent objekt i et byggeris livscyklus. CCS koden indeholder bogstavkoder, der klassificerer objektet.

• IFC er et udvekslingsformat mellem forskellige IT systemer. • IFD er et internationalt bibliotek med termer for bygningsdele.

DBK2012 vil kunne bidrage med flere termer til IFD samt danske termer til det eksisterende bibliotek.

Når et objekt kodes med den nye CCS klassifikations kode (Type-af) vil ob-jektet 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 DBK typen i forhold til begrebet og derved oversætte det til et andet lands klassifikationstabeller. RDS ID koden identificerer. De terminologier som CCS udvikler og benytter om bygningsdele kan indar-bejdes i IFD, lige som der kan laves præcise specifikationer på hvilken pa-rameter CCS-koden benytter i IFC ved udveksling mellem forskellige IT sy-stemer. I eksemplet i Figur 10 vises hvordan CCS koden virker i samspil med IFC og IFD.


Figur 10 - CCS og relation til IFC/IFD

11.2 ISO/IEC 81346

ISO/IEC 81346-1 (2009) og ISO/IEC 81346-2 (2009): Industrial systems, installations and equipment and industrial products - Structuring principles and reference designations.

• Part 1: Basic rules. • Part 2: Classification of objects and codes for classes.

Disse valg af internationale standarder har følgende praktiske betydninger for CCS:

1.) At DBK2012 koden opbygges i henhold til ISO/IEC 81346 betyder, at der anvendes internationalt anerkendte principper for opbygning af CCS koden, herunder veldefinerede anvendelser af præfikstegn (fortegn), syntaks og til kombination af klassifikation og strukturel nedbrydning i de forskellige dele af CCS koden. Endvidere anvendes klassifikationstabellerne fra ISO/IEC 81346-2 tabel 1 og tabel 2 som klassifikation for mekaniske og elektrotekniske bygningsdele.


11.3 ISO 12006-2

ISO 12006-2 (2001) Building constructions - Organisation of information about construction works. Part 2 - Framework for classification of information. At arbejdet funderes på ISO12006-2 betyder, at der er en international ramme som CCS kan placeres i, på samme måde som DBK2006 blev det. NOTE: Revisionsarbejdet med ISO12006-2 standarden er igangsat

(december 2011) og varetages af Dansk Standard som sekre-tariat for denne opgave. Der er aktiv dansk ekspertdeltagelse i revisionsarbejdet af standarden.


12 Sammenfatning

CCS er designet til at være ét fælles kodesystem, som er fælles for alle do-mæner. Der kan derfor udarbejdes en fælles formidling og eksempelsam-ling. Endvidere er der lagt vægt på at de forskellige domæner vil kunne ar-bejde bedre sammen og reducere antallet af fejl og misforståelser mellem parterne, idet koderne er ensartet og entydigt opbygget for alle domæner. Principperne for den nye CCS kode har i forbindelse med projektet været fremlagt for en række softwareleverandører til kommentering med positive tilbagemeldinger, for at sikre at implementering af CCS vil kunne understøt-tes i de forskellige software. På baggrund af spørgeskemaer til leverandørerne, er det konklusionen, at CCS hurtigt vil kunne understøttes af IT værktøjerne, og at brugerne derfor kun i begrænset omfang behøver at bekymre sig om kodningsprincipper i detaljer.


13 Bilag A - Termer og definitio-ner

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 12006-2:2001, 2.2 modificeret] Objekttype Klasse af objekter der har de samme karakteristiske egenskaber [FDIS for IEC 62507-1, Requirements for identification systems enabling unambiguous information interchange – Part 1: Principles and methods] Objektforekomst Anvendelsen af en objetktype inden for en specifik sammenhæng (fx i et andet objekt (anlæg) eller et system (bygning)) uafhængigt af hvilket objekt individ der anvendes [FDIS for IEC 62507-1 samt ISO/IEC 81346-1, 4.8 modificeret] Objektindivid Et eksemplar af en objekttype uafhængigt af hvor den er benyttet Objekt individer er identificeret ved fx hjælp af et serienummer, der er rela-teret til den aktuelle sammenhæng for produktionen af individerne eller ved hjælp af tilsvarende unikke numre. [FDIS for IEC 62507-1] GUID Globally unique identifier. Et unikt referencenummer der anvendes som identifikation i computer software: [Wikipedia] IFC Industry Foundation Classes. Datamodel som har til formal at beskrive bygninger og bygningskonstrukti-onsdata. [Wikipedia]


IFD International Framework for Dictionaries En (international) standard for terminologi biblioteker eller ontologier. [www.ifd-library.org] Bygningsdel (fra engelsk: Construction entity part) 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 12006-2, 2.6 modificeret] Rum Et rumligt sammenhængende og afgrænset område i en bygning, der har et primært menneskeligt anvendelsesformål. Synonym: Brugsrum [DBK2006, modificeret] / [BBR/KMS] Konstruktionsrum Det rum der opstår ved opbygning af bygningstekniske systemer og som er indlejret heri. System Sæt af indbyrdes forbundne objekter, betragtet som en enhed i en define-ret sammenhæng og separeret fra deres omgivelser. [ISO/IEC 81346-1, 3.2] Referencebetegnelse (RDS) Kendemærke til et specifikt objekt udformet med hensyn til det system som objektet er en bestanddel af, baseret på et eller flere aspekter af det sy-stem [ISO/IEC 81346-1, 3.11]


14 Bilag B - 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}, ”/”, Pro-ject 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 = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ; 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 ;


15 Bilag C - Oversigt over aspekt-koder


Refe

renc

e fo

r by

gnin

gsde

les p

lace

ring

ift. b

rugs

rum

.

Rela

tion

mel

lem

rum

og

kons

truk

tions

rum

.

Aspe

ktko

den

angi

ver

hvilk

et b

rugs

rum

en

bygn

ings

del e

r kny

ttet

til.

Besk

river

f.ek

s. h

vilk

et

kont

or e

n af

bryd

er e

r pl

acer

et i.

Aspe

ktko

den

angi

ver

CCS-

klas

sifik

atio

n af

br

ugsr

um, f

x ko

ntor

, sk

akt,

gang

etc

.

Kode

n ka

n su

pple

res m

ed

en p

roje

ktsp

ecifi

k un

derk

lass

ifika

tion,

f.ek

s.

Kont

orty

pe 1

,Ko

ntor

type

2,

Kont

orty

pe 3

, etc

.

//

[++]

Bru

gsru

ms

plac

erin

gs ID

[%%

] Rum

klas

se[=

=] F

unkt

ions

rum

ID

Iden

tifik

atio

n af

br

ugsr

ums t

iltæ

nkte

fu

nktio

n og

tilk

nytn

ing

af

funk

tions

krav

til

brug

srum

.

Sort

erin

g af

bru

gsru

m v

ha.

funk

tione

lle g

rupp

erin

ger

af ru

m.

/

Aspe

ktko

den

iden

tific

ere

de e

nkel

te b

rugs

rum

i et

fu

nktio

nelt

hier

arki

, ude

n at

anv

ende

den

fakt

iske

fysis

ke p

lace

ring

af d

e gi

vne

brug

srum

f.ek

s.

Dom

icil

1.Af

delin

g 6.

Lage

r 8Ho

spita

l 3.O

mrå

de 1

.Kon

tor 3

Klas

sifik

atio

n af

bru

gsru

m.

Sort

erin

g og

filtr

erin

g.

Grup

perin

g af

bru

gsru

m

vha.

pro

jekt

spec

ifik

unde

rkla

ssifi

katio

n.

Iden

tifik

atio

n af

bru

gsru

m

f.eks

. kon

tore

r, te

knik

rum

et

c. n

år d

en e

ndel

ige

fysis

ke p

lace

ring

af

rum

met

er k

endt

i by

gnin

gen.

Aspe

ktko

den

iden

tific

erer

br

ugsr

um i

forh

old

til d

en

sam

men

hæng

de

indg

år i

dvs.

i fo

rhol

d til

byg

gerie

ts

fysis

ke st

rukt

ur f.

eks.

Bygn

ing

1.Et

age0

.Rum

5By

gnin

g 2.

Etag

e4.R

um3

[--] C

CS B

rugs

rum

ID

CC

S - c

unec

o cl

assi

ficat

ion

syst

em |

Asp

ektk

oder

for r

um

Bru

gsru

m

[##]

Sim

pelt

rum

ID

Enty

dig

iden

tifik

atio

n af

br

ugsr

um v

ha. e

nkel

nu

mm

erer

ing.

Aspe

ktko

den

iden

tific

erer

de

enk

elte

bru

gsru

m u

den

hens

ynta

gen

til st

rukt

uren

de

indg

år i.

Kode

n be

nytt

ers s

om e

n sim

pel l

øben

de

num

mer

erin

g i h

ele

bygg

erie

t f.e

ks.

Kont

or n

r. 1,

Ko

ntor

nr.

2, e

tc.

Del

kode

navn

Bes

kriv

else

Hov

edfo

rmål

Kla

ssifi

katio

ns-

tabe

ller

/

Sim

pelt

prod

ukta

spek

tSt

rukt

urel

t pro

dukt

aspe

ktPl

acer

ings

aspe

ktFu

nktio

nsas

pekt

Klas

sifik

atio

nsas

pekt

12

3

## ==--++

%%

Bru

gsru

mB

ygni

nger

Bru

gsru

m

2012

-03-

05


16 Bilag D - Kommentarer til be-hovsanalysens hovedkonklusi-oner

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 digitalise-ringen er godt i gang. Der tegner sig dog et heterogent billede, hvor forskellige aktørgrupper arbejder på meget forskel-lige niveauer. Anvendelsen af byg-ningsmodeller bliver mere og mere ud-bredt – især på større byggerier og ikke i form af fulde modeller – mens mindre byggeprojekter, ombygning og renove-ring stadig typisk foregår vha. 2D. ”

Kommentar: Projektgruppen er bevidst om de forskellige grader af digitali-sering 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 samarbejdspartner-ne opleves således ofte som problema-tisk – både pga. samarbejdskulturen, af-talegrundlaget og inkompatible it-systemer, og fordi der mangler standar-der, der understøtter og ensarter ud-vekslingen. På tværs af aktørerne i værdikæden er der således en klar efterspørgsel på me-re struktur, større ensartethed, samt fle-re 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


overensstemmelse med det differentierede billede af digitalisering i bran-chen, 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 DBK-kodningen.

• “Der savnes en enklere klassifikation af bygningsdelene.”

Kommentar: Projektgruppen er bevidst om den hidtidige DBK-kodes mang-lende understøtning af simpel kodning. Dette er udbedret i den nye CCS-kode. Krav: Det kræves af CCS-koden at den kan udtages manuelt; at koden be-nytter simple klassifikationstabeller; samt at koden understøtter minimal kodning for brugere med simple kodningsbehov.

• ”DBK burde kunne bruges uaf-hængigt af referencesystemet.”

Kommentar: Projektgruppen tolker dette, som at der skal kunne foretages en uafhængig typeklassifikation af objekter. Krav: Objekter skal kunne tildeles en kode for typeklassifikation uafhængigt af referencekodning.

• ”Grundlaget for tidligt i processen at lave beregninger på fx arealer, energi og totaløkonomi, er uklart. ”

• ”Der mangler grundlag for struktu-reret arbejde med rumprogram-mer.”

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 kod-ning. Krav: CCS-koden skal inkludere struktureret kodning af rum. Dette inklude-rer klassifikation og reference for rum baseret på både en fysisk og funktio-nel 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 syns-punkt. CCS-koden bør understøtte denne tilgang både for bygningsdele og rum.

• Mængdeudbud er svært at gennem-føre i praksis. Det er uklart, hvad det operationelle niveau for mængde-udbud 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 byggerier. Krav: CCS-koden skal muliggøre nem søgning, filtrering og sortering af ob-jekttyper defineret i CCS. Krav: CCS-koden skal muliggøre nem søgning, filtrering og sortering af pro-jektspecifikke varianter af objekttyper defineret i CCS.

• ”De udførende kan som regel ikke genbruge data fra udbudsmateria-let til produktionsplanlægningen, da data er uredigerbare, og bygnings-modellen ikke udleveres. ”

Kommentar: Datagenbrug inkluderer ikke blot muligheden for redigering af digitale modeller. Datagenbrug inkluderer desuden: direkte genbrug af da-tamodeller 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å direkte i bygningsmodellen, produk-tionskort, afleveringsmateriale osv.”


• ”Byggematerialer er ikke entydigt defineret. Der mangler unikke speci-fikationer (egenskabsdata).”

• ”Der mangler en metode til at be-skrive unika produkter.”

Kommentar: Skillefladen mellem egenskabsdata og klassifikation af objek-ter 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 kod-ning 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 re-digerbare eller ikke er tilstrækkeligt strukturerede.”

Kommentar: Behovet understreger igen nødvendighe-den at at kunne understøtte en struktureret dataudveks-ling. CCS-koden skal således understøtte strukturering af data.


Vigtige ønsker til klassifikations standard fra Behovsanalysen Projekt 10011-Behovsanalysen har identificeret følgende elementer der bør medgå i overvejelserne i forbindelse med udvikling af en standard for klassi-fikation. 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 refe-rencedelen. 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. Konklusion: Klassifikationen skal bestå af tegn. Navne for bygningsdele udgør data der kan anvendes efter behov, dog ikke til klassifikation og refe-rence.

• Klassifikation skal skilles fra referen-cesystemet. Arkitekterne har alene behov for overblik over hvilke kom-ponenter, der anvendes i et byggeri enten via eget klassifikationssystem eller et fælles.

Kommentar: Behovet for klassifikation uafhængigt af referencedelen aner-kendes. 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 referen-cedelen. Brugen af eget klassifikationssystem muliggøres kun under forudsætning af at klassifikationen udgør en underklassifikation af klassifikationen i CCS; at denne underklassifikation kun er gyldig inden for ét bestemt byggeprojekt, men kan genbruges i andre byggeprojekter efter aftale blandt projekternes parter; at underklassifikationen kun kan anvendes i en af CCS bestemt del-kode.

• Producenterne opererer med deres egne klassifikationer (koder og pro-


duktnavne), 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 fortolk-ningskode. Den skal overholde ma-tematiske 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 ma-skinaflæselig tolkes desuden som at koden så vidt muligt også bør under-stø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-ningslogik – det kan være svært, hvis man har en prædefineret til-gang.

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 inter-nationale ISO-arbejde mht. at fin-de/udvikle tabeller.

Kommentar: Projektgruppen er enig i nødvendigheden af at lægge sig op af ISO-arbejdet. Dette inkluderer bl.a. ISO12006-2 og ISO/IEC 81346-2. Konklusion: CCS skal muliggøre mapping til ISO12006-2 og ISO/IEC81346-2. Det vil desuden søges at undgå konflikter med objektklassifikationen i ISO/IEC81346-2, da denne klassifikation ifølge maskindirektivet er påkrævet for elektriske og mekaniske installationer. Minimal konflikt med ISO/IEC81346-2 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 ob-jekttyper eller have et system til at sortere typerne i. Hvor er de vigtig-ste adskillende egenskaber på fx dø-re, og hvilke egenskaber er mindre vigtige fx i forhold til prissætning?

Kommentar: Projektgruppen præsenterer forslag til klassifikationstemaer

• • Det skal afklares, om det er hen-sigtsmæ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 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 klassifikationstemaer.

• • Det skal afklares, hvordan sam-menhængen er mellem bygningsde-le i bygningsmodeller, bygnings-delsbeskrivelser og kalkulationer i forhold til entydighed og klassifika-tion. Der er ikke enighed eller stan-dard på dette område.

• For rum skal afklares: Bruges der én type koder for at kunne lave og do-kumentere projektet, og laver man bare den endelige (en anden) rum-nummerering bagefter – og udeluk-ker/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, profes-sionelle 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 over-ordnet niveau ”for dem, der allige-vel selv går ud og måler med tom-melstok” og et mere detaljeret ni-veau for dem, der magter at gå dy-bere ned. Det må ikke blive for voldsomt, så almindelige menne-sker ikke kan se, hvor de er henne.

Kommentar: Projektgruppen er enig i betragtningen. Konklusion: CCS udvikles så simpel kodning med klassifikation og identifika-tion kan foretages i projekter med begrænset behov for kodning.


17 Bilag E – Bygningsdelstabel 1

Klasser for bygningsdele til mekanik og elektroteknik er dækket af ISO/IEC 81346-2:2009 tabel 1 & tabel 2. Tabellen herunder viser forslag til mulige klasser af bygningsdele for de øvrige områder: Bogstavkode Hovedklasse Underklasse Underklasse D Konstruktioner

DA Bærelag DB Fundamentkonstruktion DC Dækkonstruktion DD Gulvkonstruktion DE Loftkonstruktion DF Vægkonstruktion

etc. J Del-konstruktioner

JA Vindue JB Dør JC Port JD Søjle

etc. L Komponenter

LA Forstærkning LB Afdækning LC Afskærmning LD Afslutning LE Inddækning LF Samling LG Stopning LH Beklædning LI <Anvendes ikke> LJ Belægning LK Isolering LL Udsmykning LM Lukning

LMA Sprodse LMB Rude LMC Ramme LMD Beslåning

LN Åbning

etc.

ccs kodnings- regler - cunecocuneco.dk/files/ccs_kodningsregler_hoeringsrapport_-_2012-03-05.pdf ·...

Documents