ccs kodnings- regler - bips · pdf fileiso/iec 81346-1 og 81346-2 hertil er under projektets...

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

2. UDGAVE

3. december 2012

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 - Center for Product Customization ApS Nicolai Karved, Betech Data A/S Søren Spile, cuneco cuneco – en del af bips bips Lautrupvang 1 B 2750 Ballerup Telefon 70 23 22 37 Fax 70 23 42 37 E-mail [email protected] www.bips.dk Grafisk tilrettelæggelse Fænø Design


1 Resumé

Forudsætninger og nuværende resultat.

Denne rapport beskriver forudsætningerne, forløbet og resultatet med

cuneco projektet ”Kodningsprincipper for klassifikation og identifikation”.

Kodeprincipperne afløser det eksisterende DBK og bliver samtidig omdøbt

til CCS (cuneco classification system).

CCS er et nationalt system der kan anvendes til klassifikation og identifika-

tion af bygningsdele og rum, samt til at beskrive relationerne mellem byg-

ningsdele og rum.

Første udgave af denne rapport er fra 5. marts 2012 og den dannede grund-

lag for den offentlige høring. cuneco modtog i alt 211 kommentarer til rap-

porten, hvoraf nogle var direkte rettet mod det samlede cuneco arbejde,

mens andre var rettet mod kodeprincipperne, som denne rapport omhand-

ler.

Denne 2. udgave af rapporten har indarbejdet de relevante kommentarer

fra høringen samt opdateret indholdet med hensyn til den fremdrift der er

sket i de øvrige cuneco projekter.

Udgangspunktet for CCS er ISO 12006-2 (2001) standarden: Framework for

classification of information. Standarden er p.t. under revision hvilket bl.a.

cuneco bidrager til. Hertil kommer en række andre ISO/IEC standarder der

er anvendt efter relevans og behov.

CCS anvender en kombination af præfiks (specialtegn), klassifikationskoder

(bogstaver) og tal (løbenumre) til at skabe forskellige typer af identificeren-

de koder, der umiddelbart kan tolkes af mennesker, og endvidere kan un-

derstøttes af forskellige IT systemer til at bære information mellem disse.

Denne rapport beskriver reglerne for kodemekanismerne, samt krav til

klassifikationsdelen af koden, der udvikles en andre projektgrupper.

I Bilag C – Oversigt over supplerende aspektkoder findes en oversigt over de

samlede kodeprincipper i CCS. Det anbefales at have disse oversigter ved

siden af rapporten for at opnå en hurtigere fortrolighed med principperne.


2 Indholdsfortegnelse

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

2 Indholdsfortegnelse ........................................................................................................................... 4

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

3.1 Projektgrundlag ...................................................................................................................... 8

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

4 Formål................................................................................................................................................... 10

5 Objekter og aspekter ...................................................................................................................... 12

5.1 Bygningsdele og brugsrum ............................................................................................. 12

5.2 Typer, forekomster og individer .................................................................................. 13

5.3 Strukturelle aspekter og views ..................................................................................... 14

6 Kravspecifikation ............................................................................................................................. 16

6.1 Minimumskrav ..................................................................................................................... 16

6.2 Uddybet kravspecifikation .............................................................................................. 17

7 Grundlæggende kodningsregler ................................................................................................ 18

7.1 Klassifikation og identifikation i CCS .......................................................................... 18

7.2 Klassifikation ........................................................................................................................ 18

7.2.1 Generelt ......................................................................................................................... 18

7.2.2 Kort om stabilitetsprincippet ............................................................................... 19

7.2.3 Regler for klassifikationsbogstaver ................................................................... 21

7.2.4 Anbefalinger til klassifikationstabeller ............................................................ 21

7.3 Identifikation ........................................................................................................................ 22

7.3.1 Strukturelle aspekter ............................................................................................... 23

7.3.2 Regler for identifikations løbenumre ............................................................... 25

8 Strukturelle aspektkoder .............................................................................................................. 27

8.1 Syntaks for Gruppe 1 aspektkoder .............................................................................. 27


8.1.1 [%] Typeaspekt for bygningsdele ...................................................................... 28

8.1.2 [#] Produktaspekt for bygningsdele ................................................................. 29

8.1.3 [-] Sammensat produktaspekt for bygningsdele .......................................... 30

8.1.4 [+] Placeringsaspekt for bygningsdele ............................................................. 33

8.1.5 [=] Funktionsaspekt for bygningsdele .............................................................. 35


8.2.1 [%%] Typeaspekt for brugsrum ......................................................................... 38

8.2.2 [##] Produktaspekt for brugsrum ..................................................................... 39

8.2.3 [--] Sammensat produktaspekt for brugsrum ............................................... 40

8.2.4 [++] Placeringsaspekt for brugsrum ................................................................. 42

8.2.5 [==] Funktionsaspekt for brugsrum .................................................................. 44


8.3.1 Supplerende strukturel aspektkoder ................................................................ 46

9 Eksempler for anvendelse ............................................................................................................ 47

9.1 % Typeaspekt for bygningsdele ................................................................................... 48

9.2 # Produktaspekt for bygningsdele .............................................................................. 49

9.3 - Sammensat produktaspekt for bygningsdele ....................................................... 50

9.4 + Placeringsaspekt for bygningsdele .......................................................................... 53

9.5 = Funktionsaspekt for bygningsdele ........................................................................... 54

9.6 %% Typeaspekt for brugsrum ...................................................................................... 56

9.7 ## Produktaspekt for brugsrum .................................................................................. 57

9.8 -- Sammensat produktaspekt for brugsrum ............................................................ 58

9.9 ++ Placeringsaspekt for brugsrum .............................................................................. 59

9.10 == Funktionsaspekt for brugsrum ............................................................................... 62

9.11 Kodning igennem livscyklus for en bygningsdel ................................................... 63

9.12 Kodning igennem livscyklus for et brugsrum ......................................................... 65

10 IT implementering ........................................................................................................................... 68

10.1 Tidlig afklaring af It-egnethed. ...................................................................................... 68

10.2 Forløbet ................................................................................................................................... 68


10.3 Konklusion på introduktionsmøde .............................................................................. 68

10.4 Eksempler på CCS i EBNF-format................................................................................. 69

11 Relation til andre standarder ...................................................................................................... 70

11.1 ISO 12006-2 (2001 / 2013) ............................................................................................ 70

11.2 ISO/IEC 81346 (2009) ...................................................................................................... 72

11.3 DIN 6779-12 (2010) .......................................................................................................... 73

11.4 ISO 4157 (1999) .................................................................................................................. 74

11.5 SFB (1950+) .......................................................................................................................... 74

11.6 DBK (2006) ............................................................................................................................ 75

11.7 Forvaltnings Klassifikation (2009) .............................................................................. 76

11.8 IFC/IFD .................................................................................................................................... 77

11.9 OmniClass, BSAB, Uniformat m.fl. ................................................................................ 78

12 Sammenfatning ................................................................................................................................. 80

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

14 Bilag B – Oversigt over aspektkoder ........................................................................................ 84

15 Bilag C – Oversigt over supplerende aspektkoder ............................................................. 90

16 Bilag D – Eksempler for kodning af bygningsdele .............................................................. 91

17 Bilag E – Eksempler for kodning af brugsrum ..................................................................... 92

18 Bilag F - Kommentarer til behovsanalysens foreløbige

hovedkonklusioner ................................................................................................................................ 93

19 Bilag G – Forudsætningsnotat ...................................................................................................101

20 Bilag H – Udvidet kravspecifikation .......................................................................................106

20.1 Klassifikationskrav ...........................................................................................................106

20.2 Identifikationskrav ...........................................................................................................107

20.3 Normative krav ..................................................................................................................108

20.4 Anvendelseskrav ...............................................................................................................108

20.5 Implementeringskrav .....................................................................................................109

21 Bilag I – Spørgeskema til IT-leverandørgruppen i bips .................................................110


3 Introduktion

Denne rapport i 2. udgave 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 brugsrum 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 brugsrum i resultatdomænet.

Projektet har fokus på afhjælpning af de problemstillinger og mangler, der

er blevet påpeget siden DBK blev frigivet i 2006 og skal skabe grundlag for

det efterfølgende arbejde i cuneco, der omfatter frembringelse af revidere-

de klassifikationstabeller.

Projektet er udført af en arbejdsgruppe nedsat af Cuneco, som består af:

• Søren Spile, cuneco (projektleder)

• Henrik Balslev, Balslev & Jacobsen ApS

• Nicolai Karved, Betech Data A/S

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

• Ulf Harlou, CPC - Center for Product Customization ApS

Rapporten beskriver regler for, hvorledes CCS koder skal udarbejdes, samt

retningslinier og krav for det efterfølgende klassifikationsarbejde.

Rapporten beskriver hvorledes klassifikation anvendes i kodningen, men

omhandler ikke det specifikke klassifikationsarbejde, dvs. udarbejdelse af

de klassifikationstabeller der skal udarbejdes på baggrund af denne rapport

i projekterne ”11101 Klassifikation af bygningsdele” og ”11091 Klassifikati-

on af bygværker og rum”.

Eksemplerne i rapporten der bruges til illustration af kodningsreglerne be-

nytter derfor en foreløbig klassifikation, baseret på de foreløbige resultater

fra projekterne 11101 og 11091 (december 2012) for at illustrere sammen-

hængen mellem klassifikationen og kodningsreglerne. Ændringer i klassifi-

kationskoder vil forekomme på baggrund af granskning og den offentlige

høring 2013.


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

Ekholm-rapporten, 2011

DIKON-rapporten, 2010

Notat om DBK i forbindelse med IT-systemer, bips

Notat om DBK i BIM software, Betech Data A/S, 2009

DBK Kodningsprincipper, Balslev & Jacobsen Aps, 2010

Forvaltnings Klassifikation, Landsbyggefonden og KL, August 2009

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

IFC (ISO/PAS 16739 IFC 2x platform)

ISO/IEC 81346-1 og 81346-2 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)

(se bilag Bilag F - Kommentarer til behovsanalysens foreløbige ho-

vedkonklusioner)

Høringskommentarer fra offentlig høring 2012-03-05

(cuneco_hoeringssvar_ccs_kodestruktur.pdf)

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

cuneco´s styregruppe samt den gennemførte offentlige høring i 2012.

Hovedforløbet for projektet mht. udformning af den tekniske løsning har

været følgende rækkefølge:

1. Afklaring af forudsætninger og grundlag for opgavens løsning

a. Studie af DBK2006 samt supplerende baggrundsmateriale

(se afsnit 3.1)

b. Afdækning af relationer til IFC og IFD, samt cuneco projek-

tet vedr. egenskabsdata

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


2. Indsamling af basisinput til projektarbejdet med deltagelse af ud-

valgte eksperter (Anders Ekholm & Eirik Selvik) med afsæt i de ved-

tagne forudsætninger for opgaven.

3. Udformning af syntaks og struktur for ny kodeteknik med fokus på

nedenstående områder:

a. Studie af nødvendige / lovgivningsmæssige / direktivmæ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

h. Mapning til danske og internationale standarder

i. Udarbejdelse af grafiske eksempler

4. Intern høringsworkshop i Cuneco d.2011-11-09

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

af inddelingskriterier for bygningsdele og rum.

6. Offentlig høring d. 2012-03-15 med efterfølgende indsamling af

kommentarer.

7. Revision af struktur for ny kodeteknik samt forslag til inddelingskri-

terier for bygningsdele og brugsrum baseret på høringssvar

8. Udarbejdelse af rapport i 2. udgave, med indarbejdede høringssvar

m.v.

Undervejs i projektet er afholdt koordinerende workshops og møder med

cuneco´s styregruppe, projektgruppen for Cuneco projekt ”12011 – Afkla-

ring af struktur og metode for egenskabsdata”, og interessenter fra IT-

leverandør branchen (se afsnit 10).


4 Formål

Formålet med CCS kodningstandarden er at levere en grundlæggende

informationsstruktur, der sikrer en entydig og ensartet forståelse for in-

formation i branchen og som understøtter udveksling af disse informatio-

ner mellem parterne.

Arbejdet med udarbejdelse af en standard for kodning af byggeriets objek-

ter udspringer af branchens behov og ønsker i forhold til en bedre og ensar-

tet forståelse og udveksling af de mange forskellige typer information, der

indgår i et bygværks samlede livscyklus.

Helt grundlæggende baseres arbejdet med CCS på ISO 12006-2, der er en

overordnet rammestandard for klassifikation af information i byggeriet. ISO

12006-2 er pt. (år 2012) under revision, og cuneco deltager aktivt i revisi-

onsarbejdet. Et første udkast (Committee Draft) af den nye udgave kan

forventes primo 2013. Se afsnit 11.1.

ISO 12006-2 indeholder ikke specifikke tabeller for bygningsdele, men kun

anbefalinger om principperne for udarbejdelse af disse tabeller, fx at en

tabel over bygningsdele kan baseres på funktion. ISO 12006-2 indeholder

ikke regler eller retningslinjer for udarbejdelse af koder af klasser eller iden-

tifikation, da dette er uden for emneområdet for standarden.

Såfremt andre lande har fulgt anbefalingerne i ISO 12006-2, i lighed med

CCS, vil klassifikationen fra CCS derfor kunne mappes til andre systemer, fx

via IFD. Se afsnit 11.8.

CCS har, i modsætning til andre lande, bevidst lagt et stabilitetsprincip til

grund for udarbejdelse af identificerende koder og koder for klassifikation.

Dvs. at det er et krav i CCS, at koder og klasser skal være så stabile som

overhovedet muligt, således de ikke ændrer sig set over den samlede livs-

cyklus, for derved at gøre CCS stabil, nem og brugervenlig. Hermes sikres

også sporbarheden af de forskellige bygningsdele og rum igennem livscy-

klus.

For at sikre en entydig udveksling og genbrug af data gennem alle byggeri-

ets processer fra idéfase og projektering over udførelse til drift og vedlige-

hold, er det nødvendigt at identificere bygningsdele og brugsrum entydigt,

så de er nemme at genfinde og genkende for alle parter på tværs af plat-

forme.

Reglerne for identifikation af bygningsdele og brugsrum er i CCS udformet

således, at de dels kan genkendes og bruges ”manuelt / analogt”, dvs. af

mennesker uden support fra et IT system, og dels så de kan bruges ”auto-

matisk / digitalt”, dvs. anvendes i forskellige IT systemer. Dette sker i er-


kendelse af, at meget arbejde med information fortsat håndteres manuelt i

projekterne, og at den stigende anvendelse af fx BIM fortsat vil tage tid at

implementere, inden det bliver allemandseje.

Samtidigt er det et krav at enhver kode også skal kunne håndteres i IT sy-

stemer (2D, 3D, diagrammering, beregninger, beskrivelser etc.) hvilket kan

understøttes mere eller mindre automatisk.

Der er lagt vægt på en menneskelig genkendelse af såvel betydning af kode

samt den tilhørende klassifikation. Dog undgås mnemotekniske (mundret-

te) forkortelser helt, da disse ikke kan anvendes i internationalt regi.

CCS er udviklet som et meget fleksibelt system, der har mange og forskelli-

ge anvendelsesmuligheder alt efter behov og alt efter kompleksitet. I prak-

sis vil alle ikke skulle bruge alt fra CCS, men kun de udvalgte elementer der

er relevante for deres behov.

Anvendelsen af CCS koder vil kunne aftales fra projekt til projekt, og kan

indgå som én af de aftaler der omfattes af en IDM manual (dvs. en aftale

om informationsniveauer).

CCS kodereglerne er udviklet til at kunne anvendes for alle parter (alle fag

og interesser) igennem hele livscyklus for bygningsdele og brugsrum.


5 Objekter og aspekter

5.1 Bygningsdele og brugsrum

CCS koder to typer af objekter i resultatdomænet af ISO 12006-2:

bygningsdele og brugsrum

Denne rapport omhandler de CCS koder, der anvendes til kodning af to

grundlæggende objekter: bygningsdele og brugsrum, der findes i resultat-

domænet af ISO 12006-2.

Objektet bygningsdel forefindes som: objekttype, objektfore-

komst og objektindivid.

Objektet brugsrum forefindes som: objekttype, objektfore-

komst og objektindivid.

Bygningsdele og brugsrum illustreres i denne rapport med følger definitio-

ner og symboliseres ved de viste symboler.

Bygningsdel:

en afgrænset bestanddel af en bygning, som

i sig selv eller i kombination med andre byg-

ningsdele har en karakteristisk funktion i

bygningen

Brugsrum:

rum defineret af det byggede miljø og som

giver plads til brugeraktivitet eller udstyr

Se endvidere definitioner i Bilag A - Termer og definitioner.


5.2 Typer, forekomster og individer

CCS klassificerer objekttyper og identificerer objektforekomster.

I samråd med projektgruppen der arbejder med objektegenskaber, er der

defineret følgende adskillelse mellem de forskellige typer af objekter der

håndteres med CCS:

En objekttype er en klasse af objekter der har de samme karakte-

ristiske egenskaber, dvs. at det er på baggrund af objekttyperne at

klassen af fx bygningsdele oprettes. En objekttype bliver medlem

af en CCS klasse, og tildeles kendebogstaver for klassen.

En objektforekomst er anvendelsen af en bestemt objekttype inden

for en specifik sammenhæng. Objektforekomsten er stabil og repræ-

senterer objektet af interesse, så længe objektet findes. En objektfo-

rekomst får tildelt en identificerende CCS kode, der identificerer ob-

jektforekomsten entydigt.

Et objektindivid er et eksemplar af en objekttype uafhængigt af hvor

den er benyttet. Det vil fx være det konkrete produkt som vælges til

at instantiere objektforekomsten. Et objektindivid vil typisk have et

serienummer, et ordrenummer eller tilsvarende, der identificerer

hvert enkelt individ. Et objektindivid refererer altid til en objektfore-

komst. Et objektindivid kan udskiftes med et andet individ, uden at

dette har indflydelse på objektforekomsten.

Figur 1 - Objekt forekomst og objekt individer. Individerne passer til forekomsten.

CCS klassificerer objekttyper og identificerer objektforekomster.

Formålet med at skelne mellem de tre typer af objekter er dels at kunne

håndtere information om objekterne (type - forekomst - individ) individuelt

og dermed mere klart, dels at sikre en stabilitet i CCS koderne for bygnings-

dele og brugsrum.


Objektindivider kan udskiftes, mens objektforekomsterne som de passer til

forbliver uændrede. Såfremt et objekt udgår, slettes objektforekomsten.

Objektforekomsterne er stabile at klassificere og identificere i den samlede

livscyklus for et objekt. Objektforekomster og objektindivider er illustreret i

Figur 2.

Figur 2 - Illustration af objekt forekomster og objekt individer

5.3 Strukturelle aspekter og views

CCS anvender to forskellige måder at betragte objektforekomster på.

I forbindelse med udvikling af CCS koder, har der tidligere i forløbet været

anvendt begrebet ”aspekt”, hvilket var defineret som ”en bestemt måde at

se et objekt på”. Termen ”aspekt” er efterfølgende fundet for upræcis, da

man kan ”se” objekter på mange andre måder, end den måde den blev

anvendt på.

Individer Individer

ForekomsterForekomster

Inderdør Swedoor

Selection Allegro

Inderdør Swedoor

Selection Allegro

GW1

Inderdør Swedoor

Selection Allegro

GW11

Kroneafbryder

HVID Fuga

Ean nr.:

5703302094375

Lysdæmper skyde

MEK-S 300LR

HVID Fuga

Ean nr.:

5703302109932

Lysdæmper Dreje

MEK-D 300CR

HVID Fuga

Ean nr.:

5703302109918


Efterfølgende har arbejdet resulteret i, at der nu skelnes mellem aspekter

der anvendes til at strukturere information (fx i del-af hierarkier) og andre

måder at ”se” objekter på.

Aspekter til strukturering benævnes i CCS for ”strukturelle aspekter”, mens

andre måder at betragte objekter på benævnes ”views”.

Som input til CCS begrebskataloget foreslår denne rapport definitioner og

anvendelse for hhv. views og strukturelle aspekter som anført i Bilag A -

Termer og definitioner.

Views behandles ikke yderligere i denne rapport.

Bemærk, at en struktur i et strukturelt aspekt kan være ”flad”, dvs. uden en

successiv underinddeling, eller i et vilkårligt antal underinddelinger efter

behov. Såfremt der er behov for flere niveauer, kan disse skabes i en træ-

lignende struktur, dvs. at der ikke er krav om et fast antal niveauer i hver

gren.

Kodestrukturen, der altid baseres på et eller flere strukturelle aspekter, har

to primære formål:

1) At identificere objektforekomster enten individuelt og/eller ud fra den

sammenhæng som de indgår i set i forhold til systemer som de er be-

standdele af.

2) At tilknytte objektforekomsten til en objektklasse. Kravet er, at CCS klas-

sifikationen skal være stabil set over livscyklus, så koden ikke ændre sig.

Status ved dette projekts afslutning er, at stabilitetsprincippet i klassifikati-

onen opnås ved at anvende bygningsdelenes tekniske egenfunktion (dvs.

hvad en bygningsdel ”gør i sig selv”), frem for den funktion bygningsdelen

anvendes til, som inddelingskriterie for klassifikationen.


6 Kravspecifikation

Krav til udformning af koder for bygningsdele og brugsrum.

Strukturen og syntaksen for kodning i CCS er designet til at understøtte

både processer i byggeprojekter og uden for byggeprojekter, herunder hele

bygge- og driftsprocessen, og kan anvendes til et varieret kodningsbehov i

de forskellige faser. Målgruppen er derfor alle byggeriets aktører, fx:

Byg- og driftsherrer

Arkitekter

Rådgivere

Ingeniører

Entreprenører

Udførende

Byggematerialeleverandører

Projektgruppen har været særligt opmærksom på de faglige forskelle 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.

6.1 Minimumskrav

Som udgangspunkt for projektet er der af cuneco's styregruppe, jævnfør

pkt. 3.3 i Projektbeskrivelsen, stillet følgende minimumskrav som succeskri-

terier 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.

6.2 Uddybet kravspecifikation

Projektgruppen har fundet det nødvendigt at uddybe og udvide minimums-

kravene stillet af cuneco bl.a. som følge af behov og resulterende krav til

CCS-koden der er identificeret undervejs i projektet efter input fra følgende

kilder:

Projektets baggrundsmateriale

Interne workshops i projektgruppen

Review med cuneco´s styregruppe og IT-leverandører (se afsnit 10)

Intern høringsworkshop i cuneco 2011-11-09

Studie af behovsanalysen fra Cuneco projekt 10011 - Behovsanaly-

sen (foreløbige hovedkonklusioner) (kommenteret i Bilag F - Kom-

mentarer til behovsanalysens foreløbige hovedkonklusioner)

Offentlig høring på DTU 2012-03-15

Den udvidede kravspecifikation dækker nedenstående temaer og kan læses

i Bilag H – Udvidet kravspecifikation:

Klassifikationskrav

Identifikationskrav

Normative krav

Anvendelseskrav

Implementeringskrav

Disse krav samt minimumskravene fra Projektbeskrivelsen udgør den

grundlæggende kravspecifikation for projektgruppens udvikling af CCS.


7 Grundlæggende kodningsregler

BEMÆRK:

De i denne rapport anvendte klassifikationskoder (1, 2 eller 3 bogstaver)

stammer fra cuneco's klassifikationsprojekter, der ikke er en del af dette

projekt. Klassifikationskoderne er medtaget af hensyn til illustration og

sammenhæng mellem kodeprincipper og klassifikationskoder. Klassifika-

tionstabellerne for bygningsdele og rum sendes i offentlig høring i januar

2013. Ændringer i den færdige koder kan derfor forekomme.

7.1 Klassifikation og identifikation i CCS

I resultatdomænet af ISO 12006-2 anvendes CCS til klassifikation og identi-

fikation af bygningsdele og brugsrum. Hertil kommer klassifikation af byg-

værker.

Klassifikationsdelen har til formål at samordne klasser af objekter, som har

det samme sæt af egenskaber (type-af), og identifikationsdelen skal benyt-

tes som robust identifikation af enhver relevant objektforekomst såfremt

det er nødvendigt at kunne skelne ens forekomster fra hinanden, fx skelne

døre, vinduer, ventiler og stikkontakter individuelt fra hinanden.

I forhold til DBK2006 ændres der på måden hvorpå klassifikationsdelen og

identifikationsdelen beskrives i CCS, idet der i CCS gælder følgende:

A 1.) I DBK2006 blev klassifikation beskrevet både ved tal og

bogstaver. I CCS beskrives klassifikation udelukkende ved brug af latinske bogstaver.

1 2.) CCS identifikationsdelen er opbygget af løbenumre

der qua kodens opbygning gør det muligt at skelne enhver objektforekomst fra andre objektforekomster.

A1 3.) Klassifikationsdelen og identifikationsdelen bruges i

dele af CCS til samtidigt at identificere et objekt og gi-ve en oplysning om typen af objekt.

7.2 Klassifikation

7.2.1 Generelt

I DBK2006 blev adskillige bygningsdele organiseret forskelligt afhængigt af

hvilken strukturel sammenhæng de indgik i. Branchens erfaringer med

DBK2006 samt evalueringer af DBK2006 (fx Ekholm-rapporten samt Notat

om DBK i forbindelse med IT-systemer) har påpeget flere uhensigtsmæssig-

heder, heriblandt:


Ændringer i objekters egenskabsdata eller konstruktive relationer

fører i mange tilfælde til ændringer i klassifikationen af objektet,

med dertil hørende behov for ændringer i den berørte dokumenta-

tion, advisering af forskellige aktører mm.

En kompositionelt afhængig klassifikation understøtter ikke bran-

chens ønsker om at kunne anvende den klassificerende del af CCS

separat til forskellige formål, fx til samordning af objekter i tilbuds-

fasen eller driftsfasen.

Når et objekt kan klassificeres forskelligt alt efter den pågældende

kompositoriske sammenhæng, gøres både manuel og IT-

understøttet klassifikation mere besværlig. I byggeriets IT-værktøjer

ønskes ét ensartet inddelingskriterie der anvendes til klassifikati-

onsdelen, således at man får ens klassifikationsbogstaver, der be-

tegner de samme objekter uanset anvendelsen.

I CCS anlægges der derfor et nyt centralt princip for klassifikation af byg-

ningsdele og brugsrum:

Stabilitetsprincippet: Klassifikationen af bygningsdele og

brugsrum i CCS skal være stabil igennem livscyklussen

for et kodet objekt. Dette inkluderer at inddelingskriteri-

erne for bygningsdele og brugsrum i CCS skal være 100%

uafhængige af den strukturelle komposition af bygvær-

ket dvs. i hvilken strukturel kontekst en bygningsdel eller

et brugsrum objekt indgår i.

Det forudsættes stadig at klassifikationen baseres på ’type-af’ strukturer,

dvs. følger de gængse regler for udarbejdelse af klassifikationstabeller.

7.2.2 Kort om stabilitetsprincippet

Stabilitetsprincippet for klassifikation i CCS inebærer, at inddelingskriterier-

ne i CCS er uafhængige af projektspecifikke egenskabsdata, dvs. egenskabs-

data der ændres gennem objektets livscyklus. Dette inkluderer den struktu-

relle komposition af bygværket. Formålet med at anlægge dette princip er

at gøre kodningen af objekter stabil ved ændring af bygværkets kompositi-

on, hvilket vil resultere i færre ændringer af dokumentation mm.

Det vil blive muligt at prækode objekter i IT systemernes objektbiblioteker,

og generelt set vil det være nemmere at ”huske” klassifikationen for men-

nesker (dvs. til analog brug). Ydermere vil det være muligt at klassificere

objekterne før den kompositoriske sammenhæng for objektet er kendt,

hvilket ikke var tilfældet med DBK2006.

Ved traditionel klassifikation ændres klassifikationen af et objekt henover

tid, efterhånden som objektet tildeles flere egenskabsdata (se Figur 3), hvil-

ket resulterer i ændringer i klassifikationskoden. Dette skyldes enten at

klassifikationen detaljeres ved tildeling af en underklasse, eller at objektet

tildeles en anden klasse af samme detaljeringsniveau.


Tid

Traditionel klassifikationInformation om et

objekt

Programmering Projektering Udførsel Drift

Objektklasse(klassifikation)

Egenskabsdata

Egenskaber

Figur 3 - Traditionel klassifikation: Ændring henover tid

I CCS anlægges stabilitetsprincippet, idet der ønskes en stabil (uændret)

klassifikation, set over livscyklus for et objekt. Kriteriet for dybden af klassi-

fikation bliver således, at der skal klassificeres ud fra de egenskabsdata der

ikke vil bevirke en ændring af objektets klassifikation gennem objektets

livscyklus (se Figur 4).

Tid

CCSInformation om et

objekt

Programmering Projektering Udførsel Drift

Objektklasse(klassifikation)

Egenskabsdata

Egenskaber

Figur 4 - CCS klassifikation: Statisk klassifikation henover tid

Egenskabsdata, der potentielt kunne resultere i en ændring af klassifikati-

onskoden hen over tid, tilskrives i stedet udelukkende som egenskabsdata

for objektet og indgår ikke længere i koden for klassifikationen. De enkelte

egenskabsdata kan efterfølgende klassificeres separat (fx brandklasser,

materialeklasser etc.).


7.2.3 Regler for klassifikationsbogstaver

I de dele af CCS hvor klassifikation indgår skal klassifikationsbogstaver an-

vendes efter følgende regler:

Regel 1: 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). Danske bogstaver

Æ, Ø og Å anvendes ikke.

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

efterfølgende bogstav altid en underklasse af det foregående

bogstav. Princippet illustreres herunder:

B B etc.

(1) (2) (3)

B Klassifikationsbogstav

(1) Hovedklasse

(2) Underklasse af foranstående klasse

(3) Efterfølgende bogstaver udgør underklasser af foran-

stående underklasse

Regel 3: Anvendelse af klassifikation der ikke er foruddefineret i CCS

klassifikationstabeller tillades kun i koder for strukturelle

aspekter hvor CCS udtrykkeligt tillader det. Denne klassifika-

tion er kun gældende inden for konteksten af ét bestemt pro-

jekt. Der er ingen begrænsning for dybden af en sådan klassi-

fikation, der altid skal forklares i den medfølgende dokumen-

tation.

Kodningsprincipperne i CCS definerer de grundlæggende regler for brug af

klassifikationsbogstaver og fastlægger ét princip for udarbejdelsen af klassi-

fikationstabellerne. Udarbejdelsen af klassifikationstabellerne i CCS falder

uden for rammer af dette projekt og varetages af projekterne ”11091 Klas-

sifikation af bygværker og rum” og ”11101 Klassifikation af bygningsdele”.

De relevante forudsætninger for klassifikationsarbejdet der er affødt af

kodningsprincipperne overføres til projektgrupperne for de to klassifikati-

onsprojekter.

7.2.4 Anbefalinger til klassifikationstabeller

I henhold til de beskrevne regler for kodning af bygningsdele og brugsrum,

skal klassifikation af disse foregå med bogstaver.

Baseret på rådata fra DBK, har udviklingen af CCS klassifikation for byg-

ningsdele vist, at det vil være hensigtsmæssigt at opdele bygningsdele i tre

grupper:


Hovedsystemer

Del-systemer

Komponenter

Det anbefales, at der anvendes 1 bogstav for hovedsystemer, 2 bogstaver

for del-systemer og 3 bogstaver for komponenter, således at man kan skel-

ne mellem de tre grupper på antallet af bogstaver.

Inddelingskriteriet for bygningsdelene skal sikre den stabilitet i klassen, som

er beskrevet i afs. 7.2.2. Stabiliteten for klassifikation af bygningsdele kan

etableres for hele livscyklussen.

Klassifikation af brugsrum skal på tilsvarende vis udvikles, således at klassi-

fikation af et brugsrum gøres så stabil som muligt. Anvendelse af klassifika-

tion af brugsrum, set gennem hele livscyklus, er dog ikke lige så stabil som

klassifikation af bygningsdele. Et vilkårligt brugsrum kan skifte anvendelses-

funktion (fx fra kontor til lager), hvilket vil have indflydelse på klassifikation

af brugsrummet. Da det ikke e muligt at skabe en 100% stabil klassifikation

set over den samlede livscyklus for et brugsrum, medtages koden for klas-

sen i de strukturelle aspekter %% og == (hvor en ændring af klassekoden

ikke har samme effekt), men ikke i ##, -- og ++ (der anvendes som forskelli-

ge former for identifikation af brugsrum).

Projektgruppen anbefaler at der udarbejdes to tabeller til klassifikation af

brugsrum med hver deres inddelingskriterie:

1. Brugsrum 1

o Inddelingskriteriet skal være relateret til brugsrummenes

fysiske gruppering i bygværk. Tabellen skal således fx inde-

holde klasser såsom Bygning, Afsnit, Etage og Brugsrum

2. Brugsrum 2

o Inddelingskriteriet skal være relateret til brugsrummets

primære funktion eller tiltænkte brug

Den endelige beslutning om definition af nødvendige klassifikationstabeller

træffes ikke i dette projekt.

7.3 Identifikation

Da den information der udveksles om objektforekomster i byggeriet er så

forskelligartet i et bygværk, er det ikke er teknisk muligt at udarbejde én

kode der alene kan opfylde alle de krav, som stilles til en CCS kode.

Identifikation i CCS sker derfor ved brug af strukturelle aspekter (se afsnit

5.3), der beskriver kompositionen af et bygværk. Anvendelsen af de struk-

turelle aspekter gør det både muligt at identificere bygningsdele og brugs-

rum, samt at udtrykke supplerende information omkring deres skiftende

relationer gennem hele bygværkets livscyklus.

Inden for hvert strukturelle aspekt defineres der flere strukturelle aspekt-

koder til brug ved kodning af objekter i CCS. Hvert strukturelle aspekt har


tilknyttet et bestemt tegn (præfiks) til brug i de strukturelle aspektkoder.

Den tekniske løsning på kodemekanismen i CCS er altså designet som en

sammensætning af disse strukturelle aspektkoder, der følger de samme

generelle syntaksregler, men som hver især tilgodeser forskellige informa-

tionsbehov om en bygningsdel hhv. et brugsrum.

Klassifikationsdelen af CCS anvendes i koderne for de strukturelle aspekter,

bl.a. for at kunne:

Sikre genkendelse for mennesker (dvs. ”analog” brug).

Mindske risikoen for at brugerne udtager de samme løbenumre,

når de forskellige fag koder deres del af bygværket.

Muliggøre afkodning af hvilken struktur eller hvilke relationer ko-

den beskriver.

7.3.1 Strukturelle aspekter

Et strukturelt aspekt i CCS angiver en bestemt måde at anskue bygværkets

objekter og deres relationer. Ved at anlægge forskellige anskuelser af byg-

værkets objekter er det muligt at lave en mangesidig beskrivelse af et byg-

værk, alt efter formål og tidspunkt i bygværkets livscyklus. Hovedformålet

med dette er at understøtte de forskellige informationsbehov i byggeriet,

der ikke kan beskrives ud fra blot én bestemt anskuelse af et givent byg-

værk.

De strukturelle aspekter kan således siges at agere som ”filtre” hvorigen-

nem et bygværk anskues, og hvor hvert strukturelt aspekt gør det muligt

enten at betragte et objekt (byg-

ningsdel eller brugsrum) isoleret

eller i en sammenhæng til bygvær-

kets øvrige objekter.

De fleste af de strukturelle aspekter i

CCS anskuer objekterne i strukturer

med sammenhæng til bygværkets

øvrige objekter. Disse strukturelle

aspekter defineres ud fra objektrela-

tioner, der beskriver enten konstruk-

tion, funktion, placering eller type-

fællesskab for bygværkets objekter.

I CCS defineres der fem forskellige typer af strukturelle aspekter hvorigen-

nem byggeriets objekter anskues:

Typeaspekt

o I typeaspektet anskues objekter ud fra deres typefælles-

skab med andre objekter, dvs. ud fra hvilke objekter inden

for den samme CCS klasse som de har et typemæssigt fæl-

lesskab med fx forskellige designvarianter.

o Strukturelle aspektkoder i dette strukturelle aspekt benyt-

ter et eller flere % (Procenttegn) som præfiks.


Produktaspekt

o I produktaspektet anskues objekter som isolerede objekter

uden relation til andre objekter, dvs. at objekternes indbyr-

des relationer mht. konstruktion, funktion eller placering

betragtes ikke. Uagtet at der er tale om en ”flad” struktur,

er der tale om en struktur i teknisk forstand (her: at tingene

er ordnet efter en overordnet systematik).


ter et eller flere # (Nummertegn) som præfiks.

Sammensat produktaspekt

o I det sammensatte produktaspekt anskues objekter ud fra

deres konstruktionsmæssige relationer til andre objekter,

dvs. ud fra deres fysiske relationer.


ter et eller flere - (Minustegn) som præfiks.

Placeringsaspekt

o I placeringsaspektet anskues objekter ud fra deres place-

ringsmæssige relationer til andre objekter, dvs. ud fra

hvordan de er placeret i forhold til andre objekter.


ter et eller flere + (Plustegn) som præfiks.

Funktionsaspekt

o I funktionsaspektet anskues objekter ud fra deres funktion

og deres funktionsmæssige relationer til andre objekter,

dvs. ud fra hvilken funktion de opfylder i et bygværk eller

system og hvordan de funktionelt hænger sammen med

andre objekter.


ter et eller flere = (Lighedstegn) som præfiks.

Note: Da de strukturelle aspektkoder benytter præfikstegn der også bruges som operato-

rer i computerprogrammer fx programmer fra Microsoft Office, skal brugerne af CCS

være opmærksom på at koderne behandles korrekt. Som eksempel kan nævnes Mi-

crosoft Excel, hvor koderne bl.a. kan håndteres ved brug af en bestemt celle-

formatering eller brug af apostrof foran koden. Det skal generelt bemærkes at CCS

koderne kan håndteres med basisfunktionaliteten i Excel og ikke kræver udvikling af

makroer eller lignende. Tilsvarende kan præfikstegnene anvendes til filnavngivning

såfremt det er hensigtsmæssigt.

Anvendelsen af strukturelle aspektkoder i sker efter følgende regler:

Regel 4: Kodede objekter i CCS tilskrives et varierende antal delkoder

(minimum én) kaldet strukturelle aspektkoder. Samlingen af

strukturelle aspektkoder der tilskrives et objekt kaldes objek-

tets CCC kode.

Regel 5: Alle strukturelle aspektkoder er forsynet med et præfikstegn

(fortegn) for det pågældende strukturelle aspekt hvori

aspektkoden er defineret.


Regel 6: Såfremt der defineres mere end én strukturel aspektkode

inden for et strukturelt aspekt benyttes flere af det samme

præfiks f.eks. +, ++, +++ osv.

Regel 7: Strukturelle aspektkoder kan sammensættes til én enkelt

CCS-kodestreng, hvor hver strukturelle aspektkode er adskilt

med et skråtegn: ”/”. Princippet illustreres herunder:

D / D / D etc.

(1) (2) (3) (4) (5)

D Strukturel aspektkode i den samlede kodestreng

(1) Strukturel aspektkode

(2) Separator ”/” adskiller de enkelte aspektkoder i kodestrengen


(4) Separator ”/” adskiller de enkelte aspektkoder i kodestrengen


Regel 8: Der er ingen regel for rækkefølgen af de strukturelle aspekt-

koder i CCS-kodestrengen. Rækkefølgen er uden betydning,

da man kan skelne de forskellige strukturelle aspektkoder fra

hinanden på deres forskellige præfiks (fortegn).

7.3.2 Regler for identifikations løbenumre

Løbenumre i de strukturelle aspektkoder bruges til identifikation af ensar-

tede typer af individuelle objekter eller grupper af objekter. Der gælder

følgende regler for brugen af løbenumre:

Regel 9: Der er intet krav om fast antal af karakterer i et løbenummer.

Foranstillede nuller kan benyttes efter behov, f.eks. hvis det-

te er nødvendigt af hensyn til sortering i IT-systemer.

Regel 10: Ved kodning af kompositionelle del-af strukturer i CCS, adskil-

les hvert strukturniveau i koden ved brug af punktum ”.”.

Regel 11: Løbenumre kan enten være gældende inden for én bestemt

klasse eller på tværs af klasser.

Regel 12: Nummerering kan enten ske fortløbende på tværs af alle

niveauer og under-dele i en del-af struktur eller fortløbende

inden for ét niveau eller en under-del af en del-af struktur.

Regel 13: Såfremt der benyttes en global nummerering der er gælden-

de i aspektkoderne for mere end ét strukturelt aspekt, skal

det i projektets dokumentation angives i hvilke strukturelle

aspektkoder den globale nummerering anvendes.


Regel 14: Løbenumre kan efter behov tillægges specifik betydning, der

er gældende inden for et projekt. Betydningen af løbenum-

rene skal altid forklares i projektets dokumentation.


8 Strukturelle aspektkoder

Udarbejdelse af CCS koder efter veldefinerede aspekter.

I CCS prædefineres strukturelle aspektkoder med op til to præfikstegn in-

den for hvert strukturelle aspekt. Brugere af CCS kan frit oprette supple-

rende strukturelle aspektkoder med tre eller flere præfikstegn inden for

hvert strukturelle aspekt, forudsat at definitionerne og syntaksreglerne for

de strukturelle aspekter følges.

Aspektkoderne for de strukturelle aspekter inddeles i tre grupper:

Gruppe 1

CCS strukturelle aspektkoder der udtrykker information relateret til

bygningsdele.

Gruppe 2

CCS strukturelle aspektkoder der udtrykker information relateret til

brugsrum.

Gruppe 3

Brugerdefinerede supplerende strukturelle aspektkoder der ud-

trykker information relateret til enten bygningsdele eller brugsrum.

I de efterfølgende afsnit beskrives de prædefinerede strukturelle aspektko-

der. En oversigt over alle aspektkoderne kan ses i Bilag B – Oversigt over

aspektkoder og Bilag C – Oversigt over supplerende aspektkoder.

8.1 Syntaks for Gruppe 1 aspektkoder

CCS prædefinere fem aspektkoder (én for hvert strukturelt aspekt), der

udtrykker information relateret til bygningsdele. Definitionerne for hver

aspektkode ses i Tabel 1.

Præfiks Definition

% Projektspecifik gruppe af bygningsdele med samme klassifikation.

# Identificerer en bygningsdel betragtet som et selvstændigt objekt.

- Identificerer en bygningsdel som en del af en anden bygningsdel.

+ Identificerer et sted udtrykt ved en bygningsdel.

= Identificerer en bygningsdel som en del af en anden bygningsdel i en funktionel sammenhæng.

Tabel 1 - Strukturelle aspektkoder i Gruppe 1

Eksempler for anvendelsen af de strukturelle aspektkoder vises i afsnit 9.


8.1.1 [%] Typeaspekt for bygningsdele

Symbol

Præfiks % (procenttegn)

Definition Projektspecifik gruppe af bygningsdele med samme klassifi-

kation.

Beskrivelse Det er muligt inden for rammerne af ét projekt, at definere

typer af bygningsdele inden for hver klasse, til brug ved

gruppering af bygningsdele i designvarianter f.eks. til udbud

og specifikation. Denne aspektkode bruges til identifikation

af sådanne grupper.

Såfremt der defineres bestemte typer af bygningsdele i et

projekt, er denne definition kun gyldig inden for rammerne

af det specifikke bygværket og skal beskrives i bygværkets

dokumentation.

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

Hovedsystemer

Delsystemer

Komponenter

Afhængigt af om der kodes et Hovedsystem, Delsystem el-

ler en Komponent anvendes den relevante klassifikation.

Syntaks

Strukturniveau 1

Syntaks % B N

(1) (2) (3)

B Klassifikationsbogstav(er)

N Løbenummer

(1) Aspekt præfiks

(2) Bygningsdelsklassifikation (iht. tabellerne Hovedsy-

stemer, Delsystemer eller Komponenter)

(3) Løbenummer for gruppe af bygningsdele med samme

klassifikation

Eksempel %QQA1 Vinduesgruppe 1 (sidehængte vinduer)

%QQA2 Vinduesgruppe 2 (tophængte vinduer)


8.1.2 [#] Produktaspekt for bygningsdele

Symbol

Præfiks # (nummertegn)

Definition Identificerer en bygningsdel betragtet som et selvstændigt

objekt.

Beskrivelse Aspektkoden bruges til entydigt at identificere en bygnings-

del (Hovedsystem, Delsystem eller Komponent) uafhængigt

af den strukturelle komposition af bygværket. Koden udgør

således en enkeltniveaus struktur, med en simpel fortlø-

bende nummerering inden for hver klasse af bygningsdele.

Da aspektkoden er uafhængig af relationer til andre objek-

ter i et bygværk, kan aspektkoden udgøre en stabil identifi-

kator igennem hele livscyklus for en bygningsdel.

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

Hovedsystemer

Delsystemer

Komponenter

Syntaks

Strukturniveau 1

Syntaks # B N

(1) (2) (3)


N Løbenummer

(1) Aspekt præfiks



(3) Bygningsdelsløbenummer

Eksempel #QQA1 Vindue 1

#QQA34 Vindue 34

#QQC1 Dør 1

#QQC34 Dør 34

1 2 3


8.1.3 [-] Sammensat produktaspekt for bygningsdele

Symbol

Præfiks - (minustegn)

Definition Identificerer en bygningsdel som en del af en anden byg-

ningsdel.

Beskrivelse: Aspektkoden benyttes til entydig identifikation af bygnings-

dele. Systemer og delsystemer anvendes til at håndtere og

beskrive sammenhængende bygningsdele frem for byg-

ningsdele som enkelte objekter.

Koden benytter en produktmæssig (fysisk konstruktiv) syns-

vinkel og kan baseres på en generisk model for dekompone-

ring af bygningsdele, der er prædefineret i CCS´s hovedsy-

stemer. Bygværkets systemstruktur kan aflæses af koden,

og gør det bl.a. muligt at afkode del-af relationer mellem

bygningsdele. Koden kan således bruges til at finde be-

standdelene i bygværkets systemer. Hermed supporteres

bl.a. designgenbrug ved inddeling af bygværket i isolerede

designstrukturer samt håndtering af overordnede systemer

i bygværket.

Det anbefales af projektgruppen, at der til gavn for bygge-

branchen defineres en række generiske systemstrukturer

for hver klasse af hovedsystem.


Hovedsystemer

Delsystemer

Komponenter

Syntaks Aspektkoden beskriver en del-af struktur der overholder

følgende hierarki for hvor i strukturen objekterne kan ind-

gå:

Hovedsystem > Delsystem > Komponent

Der er ikke krav om at der skal defineres Hovedsystemer

eller Delsystemer i bygværket, og det er samtidigt muligt at

definere flere niveauer af Delsystemer i strukturen. Man

kan således have forskellige strukturer, med forskelligt antal

strukturniveauer, alt efter kompleksitet.

Man kan fx have en struktur uden Hovedsystemer, der kun

består af Delsystemer, som igen består af Komponenter.


Dette kaldes i praksis for en ”træstruktur”, da der ikke er

sat regler for antallet af underinddelinger. De seks eksem-

pler nedenfor illustrerer princippet for opbygning af sådan-

ne strukturer illustreret nedenfor:

-Komponent. Komponent

-Delsystem. Komponent

-Hovedsystem. Delsystem. Komponent

-Hovedsystem.Delsystem.Komponent.Komponent

-Hovedsystem. Delsystem. Delsystem. Kompo-

nent.Komponent

-Hovedsystem.Hovedsystem.Delsystem.Delsystem. Kom-

ponent.Komponent

etc.

Syntaksen for aspektkoden ser således ud:

Strukturniveau 1 n

Syntaks - B N … . B N

(1) (2) (3) (4) (5) (6)


N Løbenummer

(1) Aspekt præfiks



(3) Løbenummer for Hovedsystem, Delsystem eller

Komponent

(4) Separator ”.” adskiller strukturniveauer

(5) Bygningsdelsklassifikation (iht. enten Hovedsystemer,

Delsystemer eller Komponenter)


Komponent.

For at lette kodning af objekter og gøre det nemmere at

undgå konflikter i nummereringen af de kodede objekter,

kan man anvende de samme løbenumre som et objekt ko-

des med i ”[#] Produktaspekt for bygningsdele”.

Eksempel på sammensætning i ”[-] Sammensat Produkt-

aspekt for bygningsdele”:


Hovedsystem Delsystem Komponent

Produktaspekt: #B1 #UC4 #QQA36

↓ ↓ ↓

Sammensat

Produktaspekt:

-B1.QA4.QQA36

(Vægsystem 1.Vinduesparti 4.Vindue 36)

Eksempel Et vindue kan kodes med eller uden brug af samme løbe-

nummer som anvendes i [#] Produktaspekt for bygningsde-

le.

Kodning uden brug af samme løbenummer som anvendes i

[#] Produktaspekt for bygningsdele:

# aspektkode: #QQA87

Vindue nr. 87

↓ løbenummer genbruges ikke

- aspektkode: -B1.QA1.QQA1

Vægsystem 1.Vinduesparti 1. Vindue 1

Samlet CCS-kode: #QQA87 / -B1.QA1.QQA1

Kodning med brug af samme løbenumre som anvendes i [#]

Produktaspekt for bygningsdele:

# aspektkode: #QQA87

Vindue nr. 87

↓ løbenummer genbruges

- aspektkode: -B1.QA4.QQA87

Vægsystem 1.Vinduesparti 4. Vindue 87

Samlet CCS-kode: #QQA87 / -B1.QA4.QQA87


8.1.4 [+] Placeringsaspekt for bygningsdele

Symbol

Præfiks + (plustegn)

Definition Identificerer et sted udtrykt ved en bygningsdel.

Beskrivelse Aspektkoden beskriver en lokation i bygværket udtrykt ved

en bygningsdel, dvs. at bygningsdelen i sig selv udgør et

sted. Bygningsdele kan dermed udgøre steder hvor andre

objekter i bygværket er placeret (fx monteret).

Aspektkoden kan dermed bruges til at udtrykke f.eks. mon-

tage information som ikke fremgår af del-af strukturen fra

”[-] Sammensat Produktaspekt for bygningsdele”. Dette kan

bl.a. være tilfældet for montagerelationer mellem elektri-

ske/mekaniske bygningsdele og konstruktive bygningsdele,

eller mellem bygningsdele i det samme system.


Hovedsystemer

Delsystemer

Komponenter

Syntaks Da aspektkoden beskriver et sted udtrykt ved bygningsde-

lene i bygværket kan man vælge at basere aspektkoden på

enten ”[#] Produktaspekt for bygningsdele” eller ”[-] Sam-

mensat Produktaspekt for bygningsdele”.

Syntaksen for ”[+] Placeringsaspekt for bygningsdele” vil

således beskrive den samme struktur som et af disse aspek-

ter, men i stedet udtrykt som et sted der kan bruges som

placeringsreference.

Hvorvidt syntaksen for aspektkoden baseres på ”[#] Pro-

duktaspekt for bygningsdele” eller ”[-] Sammensat Produkt-

aspekt for bygningsdele” skal angives i bygværkets doku-

mentation.

Syntaks baseret på ”[#] Produktaspekt for bygningsdele”:

Strukturniveau 1

Syntaks + B N

(1) (2) (3)


N Løbenummer


(1) Aspekt præfiks



(3) Bygningsdelsløbenummer

Syntaks med vilkårligtantal strukturniveauer baseret på ”[-]

Sammensat produktaspekt for bygningsdele”:

Strukturniveau 1 n

Syntaks + B N … . B N

(1) (2) (3) (4) (5) (6)


N Løbenummer

(1) Aspekt præfiks



(3) Løbenummer for Hovedsystem




(6) Løbenummer for Delsystem

Eksempel +B2.UC4.ULL1

Vægsystem 2.Vægkonstruktion 4.Vægplade 1

Placeringen anvendes som reference for en bygningsdels

placering således:

-K1.ED1.SFA1 / +B1.DF4.LUD1

Læses: Elsystem 1.Belysningsanlæg 1.Afbryder 1

(placeret i)

Vægsystem 1.Vægkonstruktion 4.Vægplade 1


8.1.5 [=] Funktionsaspekt for bygningsdele

Symbol

Præfiks = (lighedstegn)

Definition Identificerer en bygningsdel som en del af en anden byg-

ningsdel i en funktionel sammenhæng.

Beskrivelse Aspektkoden identificerer bygningsdele ud fra en funktionel

betragtning hvilket muliggør at bygningsdele identificeres

uafhængigt af den strukturelle komposition af bygværket.

Der kan således identificeres bygningsdele før/uden den

strukturelle komposition af bygværket er kendt, dvs. uden

hensyntagen til den faktiske implementering af en specifi-

ceret funktionalitet.

Aspektkoden gør det muligt at designe funktionalitet i byg-

værket, og kan bl.a. anvendes til prædesign og/eller sy-

stemdesign af hovedsystemer og delsystemer, fx i form af

procesdiagrammer og konstruktive systemer uden hensyn

til den efterfølgende fysiske udformning.


Hovedsystemer

Delsystemer

Bygningsdele

Syntaks Syntaksen i aspektkoden skal beskrive en funktionel sy-

stemstruktur bestående af bygningsdele. Der anvendes en

syntaks for systemnedbrydning lig den der anlægges i ”[-]

Sammensat Produktaspekt for bygningsdele”. Aspektkoden

beskriver derfor en del-af struktur der overholder følgende

hierarki for hvor i strukturen objekterne kan indgå:

Hovedsystem > Delsystem > Komponent

Der er ikke krav om at der skal defineres Hovedsystemer

eller Delsystemer i et projekt, og det er samtidigt muligt at

definere flere niveauer af Delsystemer i strukturen. Man

kan således have forskellige strukturer, med forskelligt antal

strukturniveauer, alt efter kompleksitet.

Man kan fx have en struktur uden Hovedsystemer, der kun

består af Delsystemer, som igen består af Komponenter.

Dette kaldes i praksis for en ”træstruktur”, da der ikke er

sat regler for antallet af underinddelinger. De seks ek-

≈≈


sempler nedenfor illustrerer princippet for opbygning af så-

danne strukturer illustreret nedenfor:

=Komponent. Komponent

=Delsystem. Komponent

=Hovedsystem. Delsystem. Komponent

=Hovedsystem.Delsystem.Komponent.Komponent

=Hovedsystem. Delsystem. Delsystem. Kompo-

nent.Komponent

=Hovedsystem.Hovedsystem.Delsystem.Delsystem. Kom-

ponent.Komponent

etc.

Syntaksen for aspektkoden ser således ud:

Strukturniveau 1 n

Syntaks = B N … . B N

(1) (2) (3) (4) (5) (6)


N Løbenummer

(1) Aspekt præfiks




Komponent





Komponent.

Eksempel =J1.HA2.RMA7

Ventilationssystem 1.Blandeanlæg 2.Kontraventil 7



CCS prædefinere fem aspektkoder (én for hvert strukturelt aspekt), der

udtrykker information relateret til brugsrum. Definitionerne for hver

aspektkode ses i Tabel 2.

Præfiks Definition

%% Projektspecifik gruppe af brugsrum med samme klassifikation.

## Identificerer et brugsrum betragtet som et selvstændigt objekt.

-- Identificerer et brugsrum som en del af et bygværk, afsnit (option) og en etage.

++ Identificerer et sted udtrykt ved et brugsrum, en etage, et afsnit eller et bygværk.

== Identificerer et brugsrum i en projektspecifik funktionel sammen-hæng.

Tabel 2 - Strukturelle aspektkoder i Gruppe 2

Eksempler for anvendelsen af de strukturelle aspektkoder vises i afsnit 9.


8.2.1 [%%] Typeaspekt for brugsrum

Symbol

Præfiks %% (procenttegn procenttegn)

Definition Projektspecifik gruppe af brugsrum med samme klassifika-

tion.

Beskrivelse Det er tilladt inden for rammerne af et bygværk at definere

typer af brugsrum inden for hver klasse, til brug ved grup-

pering af brugsrum fx til konfigurering og beskrivelse af

brugsrum. Denne aspektkode bruges til identifikation af så-

danne grupper.

Såfremt der defineres bestemte typer af brugsrum i et pro-

jekt, er denne definition kun gyldig inden for rammerne af

det specifikke bygværkets og skal beskrives i bygværkets

dokumentation.

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

Brugsrum 2

Syntaks

Strukturniveau 1

Syntaks %% B N

(1) (2) (3)


N Løbenummer

(1) Aspekt præfiks

(2) Brugsrumsklassifikation (iht. tabel Brugsrum 2)

(3) Løbenummer for gruppe af brugsrum med samme

klassifikation

Eksempel %%BA1 Baderumsgruppe 1 (Baderum med brusekabine)

%%BA2 Baderumsgruppe 2 (Baderum med badekar)


8.2.2 [##] Produktaspekt for brugsrum

Symbol

Præfiks ## (nummertegn nummertegn)

Definition Projektspecifik nummerering af brugsrum.

Beskrivelse Aspektkoden bruges til entydigt at identificere brugsrum

uden hensyn til den struktur brugsrummet indgår i. Koden

afspejler derfor ikke den fysiske placering af brugsrummene

og ej heller den funktionelle opdeling af byggeriets brugs-

rum. Aspektkoden udgør en enkeltniveaus struktur, med en

fortløbende nummerering af brugsrum.

Klassifikation Der indgår ingen klassifikation af brugsrum i denne aspekt-

kode, da typen af brugsrum meget nemt kan ændres fuld-

stændigt igennem livscyklus for et bygværk. Inklusion af

klassifikation vil derfor gøre koden ustabil.

Syntaks

Strukturniveau 1

Syntaks ## N

(1) (2)

N Løbenummer

(1) Aspekt præfiks

(2) Brugsrums løbenummer

Eksempel ##1 Brugsrum nr. 1

##34 Brugsrum nr. 34

1 2 3


8.2.3 [--] Sammensat produktaspekt for brugsrum

Symbol

Præfiks -- (minustegn minustegn)

Definition Identificerer et brugsrum som en del af en bygning,

afsnit (option) og en etage.

Beskrivelse Aspektkoden benyttes til entydig identifikation af brugs-

rum. Bygninger, afsnit og etager anvendes til at håndtere og

beskrive sammenhængende brugsrum frem for udelukken-

de brugsrum som enkelte objekter.

Aspektkoden beskriver en fysisk strukturel dekomponering

af bygningen, der altid vil være projektspecifik. Kodens

struktur afspejler den fysiske placering af brugsrummene i

konstruktionen og kan således bruges til orientering i det

færdige byggeri.

Følger ISO 4157 (se afsnit 11.4).


Brugsrum 1

Syntaks Aspektkoden beskriver en del-af struktur der følger følgen-

de hierarki for hvor i strukturen bestemte objekter kan ind-

gå:

Bygning -> Afsnit (option) -> Etage -> Brugsrum

Topniveauet i koden udgøres altid af bygning. Afsnit kan

udelades fra strukturen såfremt der ikke er nogen definere-

de afsnit i bygværket. Der samtidigt ingen begrænsninger i

hvor mange niveauer af Afsnit, Etage eller Brugsrum der

kan inkluderes i strukturen, så længe strukturhierarkiet

overholdes. Der kan således fx identificeres underafsnit ved

at inkludere afsnit på to niveauer fx

Bygning 1. Afsnit 1. Afsnit 1. Etage 2. Brugsrum 1

Eller brugsrum kan beskrives som inddeling af overligende

brugsrum efter behov fx ved brug af flytbare vægkonstruk-

tioner.

Bygning 1. Etage 1. Brugsrum 1. Brugsrum 1

Bygning 1. Etage 1. Brugsrum 1. Brugsrum 2


Syntaksen for aspektkoden ser derfor således ud:

Strukturniveau 1 n n n

Syntaks -- B N … . B N … . B N … . B N

(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)


N Løbenummer

(1) Aspekt præfiks

(2) Klassifikation for Bygning (iht. tabel Brugsrum 1)

(3) Løbenummer for Bygning


(5) Klassifikation for Afsnit (iht. tabel Brugsrum 1)

(6) Løbenummer for Afsnit


(8) Klassifikation for Etage (iht. tabel Brugsrum 1)

(9) Løbenummer for Etage


(11) Klassifikation for Brugsrum (iht. tabel Brugsrum 1)

(12) Løbenummer for Brugsrum

Eksempel

--B12.S3.E2.R22

Bygning 12. Afsnit 3. Etage 2. Brugsrum 22

NOTE: De anvendte bogstavkoder i ovenstående eksempel refererer til

klassifikationstabel indeholdende klasserne Bygning, Afsnit, Etage, Brugs-

rum der udsendes i offentlig høring januar 2013. Bogstaverne anses for

klasser. Ændringer kan forekomme.


8.2.4 [++] Placeringsaspekt for brugsrum

Symbol

Præfiks ++ (plustegn plustegn)

Definition Identificerer et sted udtrykt ved et brugsrum, en etage, et

afsnit eller en bygning.

Beskrivelse Aspektkoden beskriver en lokation i bygværket udtrykt ved

et brugsrum (Bygning, Afsnit, Etage eller Brugsrum). Brugs-

rum kan således udgøre steder hvor andre objekter i byg-

værket er placeret.


Brugsrum 1

Syntaks Da aspektkoden beskriver et steder udtrykt ved brugsrum i

bygværket baseres strukturen af aspektkoden strukturen af

”[--] Sammensat produktaspekt for brugsrum”.


Strukturniveau 1 n n n

Syntaks ++ B N … . B N … . B N … . B N

(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)


N Løbenummer

(1) Aspekt præfiks

(2) Klassifikation for Bygning (iht. tabel Brugsrum 1)

(3) Løbenummer for Bygning


(5) Klassifikation for Afsnit (iht. tabel Brugsrum 1)

(6) Løbenummer for Afsnit


(8) Klassifikation for Etage (iht. tabel Brugsrum 1)

(9) Løbenummer for Etage





Eksempel Kodning af en placering

++B1.S1.E3.R25

Bygning 1.Afsnit 1. Etage 3.Brugsrum 25

Placeringen kan anvendes som reference for en bygnings-

dels placering f.eks.:

-K1.ED1.SFA1 / ++B1.S1.E3.R25

Elsystem 1. Belysningsanlæg 1. Afbryder 1

(placeret i)

Bygning 1. Afsnit 1. Etage 3. Brugsrum 25


8.2.5 [==] Funktionsaspekt for brugsrum

Symbol

Præfiks == (lighedstegn lighedstegn)

Definition Identificerer et brugsrum i en projektspecifik funktionel

sammenhæng.

Beskrivelse Aspektkoden bruges til entydigt at identificere brugsrum

baseret på en funktionel projektspecifik gruppering af

rummene. Den funktionelle gruppering afspejler derfor ikke

den fysiske placering af brugsrummene og kan i stedet bru-

ges til at designe et byggeri på et funktionelt plan, uden at

have fastlagt det endelige (fysiske) bygningsdesign.

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

Projektspecifik klassifikation efter projektspecifikt

inddelingskriterie fx Organisationsniveau

Brugsrum 2

Syntaks Syntaksen i denne aspektkode tillader kodning af en del-af

struktur med et vilkårligt antal niveauer, hvor det er muligt

at definere projektspecifikke grupper af brugsrum. Aspekt-

koden overholder følgende hierarki for hvor i strukturen ob-

jekterne kan indgå:

Brugsrumsgruppe > Brugsrum

Der er ingen begrænsninger for antallet af niveauer for

brugsrumsgrupper eller brugsrum, men hierarkiet skal

overholdes.

De projektspecifikke grupper af brugsrum kan enten klassi-

ficeres efter et projektbestemt inddelingskriterie eller efter

Brugsrum 2, og det skal angives i projektets dokumentation

hvilken af de to muligheder der anvendes. Individuelle

Brugsrum klassificeres efter Brugsrum 2.


Strukturniveau 1 n

Syntaks - B N … . B N

(1) (2) (3) (4) (5) (6)


N Løbenummer


(1) Aspekt præfiks

(2) Klassifikation for funktionel gruppe af brugsrum

a. Projektspecifikt inddelingskriterie eller ta-

bel Brugsrum 2 anvendes.

(3) Løbenummer for funktionel gruppe af brugsrum




Eksempel Med klassifikation af brugsrumgrupper efter projektspeci-

fikt inddelingskriterie:

Projektspecifikt inddelingskriterie for grupper af brugsrum:

Organisatorisk opdeling

Projektspecifik klassifikation af grupper af brugsrum:

Bogstav Klasse Objekt

K Hovedorganisation Klynge

A Underorganisation Afdeling

CCS klassifikation for brugsrum:


NA Kontor Cellekontor

Koden for et kontor bliver da fx:

==K1.A2.NA3 Klynge 1. Afdeling 2.Kontor 3

Uden klassifikation af brugsrumgrupper efter projektspeci-

fikt inddelingskriterie:

CCS indelingskriterie for grupper af brugsrum:

Overordnet funktion

CCS klassifikation af grupper af brugsrum (Brugsrumstabel

1):


H Sygdomsbehandlingsrum Kirurgisk afdeling

CCS klassifikation for brugsrum (Brugsrumstabel 2):


HC Vådt behandlingsrum Operationsstue

Koden for en operationsstue bliver da fx:

==H2.HC4

Sygdomsbehandlingsrum 2.Vådt behandlingsrum 4



CCS tillader definition af supplerende strukturelle aspektkoder inden for de

fem strukturelle aspekter. Disse aspektkoder er udelukkende gyldige inden

for rammerne af et bygværk, men ikke generelt i byggebranchen. De sup-

plerende aspektkoder kan bruges til formål der ikke er dækket af de præde-

finerede CCS aspektkoder, f.eks. identifikation af objekter der ikke kan klas-

sificeres ud fra CCS-klassifikationstabellerne og identificeres i de foruddefi-

nerede aspektkoder fx leverancer i moduler til et byggeri der indeholder

objekter på tværs af eksisterende CCS koder.

Definitionen af supplerende strukturelle aspektkoder skal beskrives i pro-

jektets dokumentation. Aspektkoderne er underlagt definitionerne for de

strukturelle aspekter i CCS samt kodningsreglerne i CCS, men beskriver an-

dre supplerende strukturer.

Aspektkoder gør brug af præfikstypen for det pågældende strukturelle

aspekt der suppleres og tilføjer blot en eller flere karakterer til præfikset

f.eks. [---] (minustegn minustegn minustegn).

Regel 14: Supplerende strukturelle aspektkoder anvender altid flere

end 2 ens præfikstegn (f.eks. ”---”). Definition af sådanne

aspektkoder skal beskrives i projektets dokumentation.

8.3.1 Supplerende strukturel aspektkoder

Præfiks Tre eller flere præfikstegn for det strukturelle aspekt der

suppleres.

Definition Der gælder samme definition, som for det strukturelle

aspekt der suppleres.

Beskrivelse Aspektkoden kan bruges til etablering af supplerende struk-

turer efter projektspecifik behov. Strukturerne der beskri-

ves ved brug af supplerende strukturelle aspektkoder er så-

ledes forskellig fra de strukturer der beskrives i de forudde-

finerede CCS aspektkoder.

Syntaks De opstillede regler for kodning i CCS er gældende.

Klassifikation Der anvendes samme klassifikation for bygningsdele og

brugsrum som for de foruddefinerede aspektkoder i det

strukturelle aspekt der suppleres.


9 Eksempler for anvendelse

Eksempler på anvendelse af strukturelle aspekter.

Med kodningsprincipperne i CCS adresseres de forskellige kodningsbehov

brugerne af CCS kan stå over for igennem et bygværks livscyklus. Dette

inkluderer både identifikation af objekter samt kommunikation af deres

indbyrdes relationer såsom placering, komposition og typefællesskab. De

forskellige aspektkoder vil derfor typisk anvendes på forskellige tidspunkter

i et bygværks livscyklus og til forskellige formål.

I de efterfølgende afsnit vises eksempler for de primære anvendelser af de

strukturelle aspektkoder og anvendelsen igennem livscyklus for et objekt

demonstreres. Oversigter med eksempler for anvendelse af de strukturelle

aspekter kan desuden ses i Bilag D – Eksempler for kodning af bygningsdele

og Bilag E – Eksempler for kodning af brugsrum


9.1 % Typeaspekt for bygningsdele

Primær anvendelse

Gruppering af bygningsdele for projektspecifikt formål vha. CCS

klassifikation.

Relevant ved beskrivelse af bygningsdele der har sammenfaldende

egenskaber.

Eksempel

a) Gruppering af bygningsdele inden for objektklasser i. Bygningsdele i bygværket der er af samme type (designva-

riant) grupperes

Vinduestype 1 (sidehængt)

%QQA1

Vinduestype 2 (tophængt)

%QQA2

Vinduer i projektet tilhørende gruppen Vinduestype 1

%QQA1

Vinduer i projektet tilhørende gruppen Vinduestype 2

%QQA2

Figur 5 – Grupper af bygningsdele inden for klassen QQA Vindue


9.2 # Produktaspekt for bygningsdele

Primær anvendelse

Identifikation af bygningsdele vha. CCS klassifikation og nummere-

ring.

Anvendes til nummerering uden kendskab til eller behov for struk-

turering.

Eksempel

a) Identifikation af bygningsdele (Delsystemer og Komponenter) i et

bygværk. Nummereringen er fortløbende inden for hver objektklas-

se.

Vindue 202

#QQA202

Vindue 201

#QQA201

Vinduesparti 32

#QA32

...

...

Vindue 316

#QQA316

...

Figur 6 - Identificering af bygningsdele


9.3 - Sammensat produktaspekt for bygningsdele

Primær anvendelse

Identifikation af bygningsdele ved deres indbyrdes sammenhæng

vha. CCS klassifikation og nummerering.

Anvendes til sammensætning af bygningsdele ved brug af hovedsy-

stemer, delsystemer og komponenter.

Der kan for de enkelte bygningsdele anvendes samme nummere-

ring som anvendt i produktaspektet (#).

Eksempel

a) Kodning af bygningsdele i to Vægsystemer. Der tildeles løbenumre

for objekterne inden for hver klasse og hvert struktur niveau i

systemerne dvs. en relativ nummerering i forhold til tilhørsforhol-

det.

Vægsystem 12. Vindue 1

-B12.QQA1

Vægsystem 12.Vægkonstruktion 1

-B12.UC1

Vægsystem 12

-B12

Vægsystem 1. Vinduesparti 1. Vindue 2

-B1.QA1.QQA2


-B1.QA1.QQA1

Vægsystem 1. Vinduesparti 1

-B1.QA1


-B1.UC1

Vægsystem 1

-B1

Figur 7 - Kodning af bygningsdele med fortløbende nummerering inden for klasser og struk-

turniveauer


b) Kodning af bygningsdele i to Vægsystemer. Nummereringen af ob-

jekterne gentages fra [#] Produktaspekt for bygningsdele. Der er

derfor tale om en statisk ”global” nummerering af bygningsdelene,

som er upåvirket af eventuelle ændringer i systemstrukturen.


-B12.QQA316


-B12.UC6

Vægsystem 12

-B12


-B1.QA32.QQA202


-B1.QA32.QQA201


-B1.QA32


-B1.UC1

Vægsystem 1

-B1

Figur 8 - Kodning af bygningsdele med brug af "global" statisk nummerering fra # Produkt-

aspekt for bygningsdele


c) Kodning af bygningsdele i et Vægsystem. Der tildeles løbenumre for

objekterne inden for hver klasse og hvert struktur niveau dvs. en re-

lativ nummerering i forhold til tilhørsforholdet.

Vægsystem 1

-B1


-B1.QA1.QQA1


-B1.QA1.QQA2

Vægsystem 1. Vinduesparti 1. Rude 1

-B1.QA1.QQB1

Vægsystem 1. Vinduesparti 1. Karm 2

-B1.QA1.UNA2

Vægsystem 1. Vinduesparti 1. Vinduesplade 1

-B1.QA1.QTC1

Vægsystem 1. Vinduesparti 1. Karm 1

-B1.QA1.UNA1


-B1.QA1


-B1.UC1

Vægsystem 1.Vægkonstruktion 2.Beklædningsplade 1

-B1.UC2.QTL1


-B1.UC2.QTL4


-B1.UC2.QTL2


-B1.UC2.QTL3

Figur 9 - Eksempel på opbygning koder i et hovedsystem


9.4 + Placeringsaspekt for bygningsdele

Primær anvendelse Reference for placering af en bygningsdel på eller i en

anden bygningsdel.

Eksempel

a) En afbryders placering ift. den plade (bygningsdel) den er monteret

i medtages som reference i kodningen af afbryderen.

El-system 1. Belysningsanlæg 1. Afbryder 1

(Placeret på/i)

Vægsystem 1.Vægkonstruktion 1. Beklædningsplade 3

-K1.ED1.SFA1 /+B1.UC1.QTL3

Vægsystem 1. Vægkonstruktion 1. Beklædningsplade 1

-B1.UC1.QTL1

Figur 10 - Kodning af en afbryder, med reference for placering ift. anden bygningsdel.


9.5 = Funktionsaspekt for bygningsdele

Primær anvendelse

Identifikation af bygningsdele ved deres funktionelle sammenhæng,

uafhængig af fysisk implementering, vha. CCS klassifikation og

nummerering.

Anvendes til prædesign og/eller systemdesign af hovedsystemer og

delsystemer, fx i form af procesdiagrammer og konstruktive syste-

mer.

Eksempel

a) Prædesign:

I et bygværk skal der indgå en række pumpeanlæg af samme design.

Der laves i projektet ét design for alle disse anlæg og de indgående

bygningsdele identificeres vha. [=] Funktionsaspekt for bygningsdele.

Designet implementeres senere rent fysisk i forskellige af bygværkets

Hovedsystemer. Pumpeanlæggene i disse systemer identificeres vha.

[#] og [-], og de har alle [=]-koden for det prædesignede pumpeanlæg

som reference.

=QMA1 =QMA2=HQA1

=PGD1

=PGD2

=BPB1

=RMA1

=MAA1

=GPA1

=QMA3 =QMA4

=GA1

Pumpeanlæg 1.Afspærringsventil 1

=GA1.QMA1

Pumpeanlæg 1

=GA1


=GA1.QMA2


=GA1.QMA3


=GA1.QMA4

Pumpeanlæg 1.Filter 1

=GA1.HQA1

Pumpeanlæg 1.Kontraventil 1

=GA1.RMA1

Pumpeanlæg 1.Trykswitch 1

=GA1.BPB1

Pumpeanlæg 1.Trykviser 1

=GA1.PGD1

Pumpeanlæg 1.Trykviser 2

=GA1.PGD2

Pumpeanlæg 1.Pumpe 1

=GA1.GPA1

Pumpeanlæg 1.Elektromotor 1

=GA1.MAA1

Figur 11 - Eksempel på funktionel kodning af prædesigns.


b) Funktionelle systemer vs. Fysiske systemer:

Et prædefineret pumpeanlæg =GA1 (se Figur 11) skal forsyne et byg-

værk med brugsvand og får derfor betegnelsen =F1.GA1. Det funktio-

nelle pumpeanlæg er fysisk opdelt. De fleste af Komponenterne sidder

samlet i et fysisk Pumpeanlæg -F3.GA1, men Afspærringsventilen

=F1.GA1.QMA2 sidder i et tilstødende Blandeanlæg -F3.HA1 hvor den

er den tolvte ventil i blandeanlægget.

I Figur 12 ses kodningen for to af ventilerne. Bemærk at de funktionelt

set er en del af det samme funktionelle pumpeanlæg, men at de fysisk

er en del af to forskellige systemer.

=H1.GA1.QMA1/-H3.HA1.QMA1 =H1.GA1.QMA2/-H3.GA1.QMA12

Figur 12 - Eksempel på bygningsdele der tilhører det samme funktionelle system, men for-

skellige fysiske konstruktioner.


9.6 %% Typeaspekt for brugsrum

Primær anvendelse

Gruppering af brugsrum for projektspecifikt formål vha. CCS klassi-

fikation.

Relevant ved konfigurering og beskrivelse af brugsrum.

Eksempel

a) Brugsrum i bygværket der er af samme type (designvariant) grup-

peres dvs. brugsrum i bygværket tildeles altså en reference for hvil-

ken gruppe af Brugsrum de tilhører.

Baderumstype 2 (Luksus)

%%BA2Baderum i projektet tilhørende gruppen Baderumstype 2

%%BA2

Baderumstype 1 (Basis)

%%BA1

Baderum i projektet tilhørende gruppen Baderumstype 1

%%BA1

Figur 13 - Grupper af brugsrum inden for klassen BA - Baderum


9.7 ## Produktaspekt for brugsrum

Primær anvendelse

Identifikation af brugsrum vha. nummerering.

Anvendes til nummerering uafhængig af brugsrummets placering.

NB! Må ikke forveksles med egenskaben ”rumnummer”.

Eksempel

a) Identifikation af brugsrum i et bygværk. Nummereringen er fortlø-

bende og rummene klassificeres ikke.

Figur 14 - Identifikation af brugsrum uafhængigt af bygværkets kompositoriske sammen-

hæng.


9.8 -- Sammensat produktaspekt for brugsrum

Primær anvendelse

Identifikation af et brugsrum vha. nummerering i forhold til den

bygning, afsnit (option) og etage som det indgår i.

Anvendes når placering af et brugsrum i en bygning er kendt.

Eksempel

a) Brugsrum i en bygning identificeres ift. hvilken etage og bygning de er en del af.

Figur 15 - Identifikation baserest på bygværkets kompositoriske sammenhæng.


9.9 ++ Placeringsaspekt for brugsrum

Primær anvendelse

Placering af en bygningsdel i et brugsrum.

Placering af en bygningsdel på en etage.

Placering af en bygningsdel i et afsnit.

Placering af en bygningsdel på eller i en bygning.

Placering af et brugsrum i et brugsrum.

Eksempel

a) En afbryders placering ift. det rum (brugsrum) den er monteret i

medtages som reference i kodningen af afbryderen.

++B4.E1.R1

++B4.E1.R2++B4.E1.R3

El-system 1. Belysningsanlæg 1. Afbryder 1

(Placeret i)

Bygning 1.Etage 1. Rum 1

-K1.ED1.SFA1 /++B4.E1.R1

Figur 16 - Brugsrum brugt som stedreference.

I de tilfælde hvor brugsrum lægges sammen, opdateres ++ koden så byg-ningsdelenes placering bliver ift. det nyligt skabte brugsrum.


b) Et brugsrum (--B1.E1.R1) opdeles, så der opstår to nye brugsrum

(--B1.E1.R2 og --B1.E1.R3). De to nye brugsrum får begge en place-

ringsreference (++B1.E1.R1), der viser at de er placeret i det tidlige-

re brugsrum. På denne vis kan linket til det tidligere brugsrum bi-

beholdes i bygværkets dokumentation.

--B1.E1.R1

Figur 17 - Ikke opdelt brugsrum

--B1.E1.R2

++B1.E1.R1

--B1.E1.R3

++B1.E1.R1

Figur 18 - Brugsrum efter opdeling


c) Et brugsrum (--B1.E1.R12) nedlægges, og bliver en del af et andet

eksisterende brugsrum (--B1.E1.R11). I dokumentationen på det

nedlagte brugsrum (--B1.E1.R12) noteres en placeringsreference

(++B1.E1.R11). På denne vis kan linket til det tidligere brugsrum bi-

beholdes i bygværkets dokumentation. Dette er specielt med tanke

for de driftsystemer der ikke har mulighed for at opdatere kodnin-

gen på bygningsdele.

--B1.E1.R11 --B1.E1.R12

Figur 19 - Brugsrum før sammenlægning

--B1.E1.R11

Beskrivelse Udgået -- Sammensat produktaspekt ++ Placeringsaspekt

Kontor 1 --B1.E1.R11

Kontor 2 --B1.E1.R12 ++B1.E1.R11

Figur 20 - Brugsrum efter sammenlægning


9.10 == Funktionsaspekt for brugsrum

Primær anvendelse

Identifikation af brugsrum ved deres funktionelle sammenhæng

vha. projektspecifik klassifikation samt CCS brugsrumsklassifikation

og nummerering.

Anvendes til funktionelt at sammensætte brugsrum ved deres til-

hørsforhold til grupper af rum.

Eksempel

1.) I et projekt specificeres tre funktionelle brugsrum (Kontorer) før det

vides hvordan den fysiske udformning af bygværket skal være.

Klynge 1. Afdeling 1. Kontor 1

==K1.A1.NA1


==K1.A1.NA2


==K1.A2.NA1

Senere i projektet konstrueres de funktionelle brugsrum og forde-

les i bygværket som vist i Figur 21.

Klynge 1.Afdeling 1

==K1.A1

Klynge 1.Afdeling 2

==K1.A2

Klynge 1.Afdeling 2. Kontor 1

==K1.A2.NA1


==K1.A1.NA1


==K1.A1.NA1

Figur 21 - Brugsrums funktionelle kodning.


9.11 Kodning igennem livscyklus for en bygningsdel

Der er flere forskellige måder at anvende de strukturelle aspektkoder på,

afhængigt af behov. Figur 22 illustrerer kodegruppens opfattelse af hvornår

de forskellige Strukturelle Aspekter oftest vil være relevante for kodning af

bygningsdele, men anvendelsen er ikke begrænset hertil.

Figur 22 - Eksempel på anvendelse af strukturelle aspektkoder for bygningsdele

I det efterfølgende gives et eksempel på kodning af en bygningsdel igennem

et tænkt livscyklusforløb. Eksemplet illustrerer princippet og er viser én af

flere mulige anvendelser.

Idé/program

Der defineres en projektspecifik vinduestype (sidehængte vinduer)

Strukturelt aspekt

Aspektkode Betydning

% %QQA1 Vinduestype 1 (sidehængt)

#

-

+

++

==

Tabel 3 - Der defineres en projektspecifik type af vinduer

Dispositionsforslag

Ingen ændring

Idé/program

Dispositionsforslag

Projektering

Udførelseskalkulation

Produktions-forberedelse

Byggeproduktion

Drift og vedligeholdelse

% # - + ++ =


Projektering

Et vindue indsættes i projektet. Det tilhører gruppen af vinduer af

typen Vinduestype 1 (%QQA1).

Vinduet er nr. 201 i bygværket (#QQA201) og indsættes som en del

af et vinduesparti i et vægsystem (-B1.QA32.QQA201).

Vinduet er fysisk placeret i brugsrum 1 på første etage i bygning 4

(++B4.E1.R1).

Strukturelt aspekt


% %QQA1 Vinduestype 1 (sidehængt)

# #QQA201 Vindue nr. 201

- -B1.QA32.QQA201 Vægsystem 1.Vinduesparti 32.Vindue 201

+

++ ++B4.E1.R1 Bygning 4. Etage 1. Brugsrum 1

==

Tabel 4 - Koderne for et vindue i bygværket


Ingen ændring

Produktionsforberedelse

Ingen ændring

Byggeproduktion

Ingen ændring


Bygværket renoveres og det besluttes at udskifte alle vinduer. Det

kodede vindue ændres til et vindue af typen %QQA4 (lavenergi,

ekstra lydisolering).

Strukturelt aspekt


% %QQA4 Vinduestype 4 (lavenergi, ekstra lydisole-ring)

# #QQA201 Vindue nr. 201

- -B1.QA32.QQA201 Vægsystem 1.Vinduesparti 32.Vindue 201

+

++ ++B4.E1.R1 Bygning 4. Etage 1. Brugsrum 1

==

Tabel 5 - Det kodede vindue skifter type


9.12 Kodning igennem livscyklus for et brugsrum

Da der er adskillige forskellige måder at anvende de Strukturelle Aspektko-

der på afhængigt af behov, vil det være omsonst at forsøge at beskrive dem

alle. Figur 23 viser kodegruppens opfattelse af hvornår de forskellige struk-

turelle aspekter oftest vil være relevante for kodning af brugsrum.

Figur 23 - Eksempel på anvendelse af strukturelle aspektkoder for brugsrum.

I det efterfølgende gives et eksempel på kodning af en bygningsdel igennem

et tænkt livscyklus forløb.

Idé/program

Der laves et funktionelt design af bygværket. En af afdelingerne i

organisationen, der skal bruge bygværket, har brug for et møde-

rum. Inddelingskriteriet i det funktionelle design er organisatorisk.

Strukturelt aspekt


%% %%GA1 Møderum type 1

##

--

++

== ==K1.A1.GA1 Klynge 1.Afdeling 1.Møderum 1

Tabel 6 - Brugsrummets koder i Idé/program fasen

Dispositionsforslag

Der disponeres over de fysiske brugsrum i bygværket. Møderum-

met tildeles en # kode for at kunne identificere rummet selv om der

laves hyppige ændringer i bygværkets layout.

Idé/program

Dispositionsforslag

Projektering


Produktions-forberedelse

Byggeproduktion


%% ## -- ++ ==


Strukturelt aspekt


%% %%GA1 Møderumstype 1

## ##17 Rum nr. 17

--

++


Tabel 7 - Brugsrummets koder i Dispositionsforslag fasen

Projektering

Møderummet placeres endeligt på anden etage i bygning 1. Møde-

rummet er det tolvte brugsrum på denne etage.

Strukturelt aspekt



## ##17 Rum nr. 17

-- --B1.E1.R12 Bygning 1.Etage 1.Brugsrum 12

++


Tabel 8 - Brugsrummets koder i Projektering fasen (1)


Ingen ændring af objektets kode

Produktionsforberedelse


Byggeproduktion



I forbindelse med en reorganisering af organisationen der bruger

bygværket er møderummet blevet overflødigt. Brugsrummet om-

dannes derfor til et kontor tilhørende gruppen af kontorer Kontor-

type 3 (%%NA3), så det kan bruges som kontor for den nye chef

Referencen til det oprindelige funktionelle Møderum

(==K1.A1.GA1) kan noteres i kontorets dokumentation.

Strukturelt aspekt


%% %%NA3 Kontortype 3

## ##17 Rum nr. 17


++

==

Tabel 9 - Brugsrummets koder i drift og vedligeholdelse fasen


Kontoret opdeles senere så der opstår to nye brugsrums (##41 og

##42). De to nye kontorer er også af typen Kontortype 3 og de bli-

ver hhv. det 13. og 14. brugsrum på etagen.

De to nye brugsrum får samtidigt en placeringsreference ++ der in-

dikerer at de er placerede i det tidligere kontor. Således kan linket

til det tidligere kontor bibeholdes.

Strukturelt aspekt



## ##17 Rum nr. 17


++

==

Tabel 10 – Koderne for det ”gamle” kontor

Strukturelt aspekt



## ##41 Rum nr. 41


++ ++B1.E1.R12 Bygning 1.Etage 1.Brugsrum 12

==

Tabel 11 – Koderne for det første kontor opstået ved opdeling af det gamle kontor

Strukturelt aspekt



## ##42 Rum nr. 42


++ ++B1.E1.R12 Bygning 1.Etage 1.Brugsrum 12

==

Tabel 12 – Koderne for det første kontor opstået ved opdeling af det gamle kontor


10 IT implementering

10.1 Tidlig afklaring af It-egnethed.

For at sikre kodesyntaksens It-egnethed var en tidlig afklaring med et ud-

valg af branchens It-leverandører vigtig for kodegruppens fremadrettede

arbejde. Dette møde blev koordineret gennem IT-leverandørgruppen i bips.

10.2 Forløbet

Følgende It-leverandører var indbudt til introduktionsmøde d. 6/9-2011:

PM El-beregning, Kalkia

IGE+XAO Danmark, CADdy++

CodeGroup, Sigma

Tekla Danmark, Tekla

Byggecentrum, V&S Prisdata

NTI CADcenter, Solibri

MagiCAD Danmark, MagiCAD

3dbyggeri Danmark, Digitalt Produktkatalog

Betech Data, Autodesk Revit

På mødet blev deltagerene introduceret til kodegruppens forudsætninger

og mål samt ændringer til kodens struktur i forhold til DBK 2006.

Følgende emner blev diskuteret på mødet:

Type-af klassifikation med entydig brug af bogstaver

Mekanismen Klassifikation i del-af og type-af

RDS ID koder

Kodens opbygning

Skilletegn

Præfiks

Kode eksempler

It-implementering

Efterfølgende blev alle deltagerene opfordret til at returnere et spørgeske-

ma (se skemaet i Bilag I – Spørgeskema til IT-leverandørgruppen i bips)

samt eventuelt kommentarer til kodegruppen for at sikre en entydig af-

dækning af de tekniske overvejelser i kode strukturen.

Kodegruppen modtog input fra 7 It-leverandørerne.

10.3 Konklusion på introduktionsmøde

It-Leverandørenes samlede reaktion var overvejende positiv og specielt den

selvstændige Type-af klassifikation blev fremhævet som en klar forbedring i

forhold til de udfordringer der er ved It-implementeringen af DBK 2006. Det

blev udtrykt at Typeaspektet suppleret med veldefinerede egenskaber vil


kunne yde den information der er nødvendig for at kunne prissætte en

bygningsmodel.

Ingen af de returnerede svar gav anledning til ændringer i den fremlagte

kodestruktur.

Generelt udtrykte It-leverandørerne at de ønsker at indgå aktivt i udviklin-

gen og afprøvningen af cuneco’s standarder.

It-leverandørerne kom med følgende opfordringer til at forbedre forudsæt-

ningerne for den efterfølgende It-implementering.

Muligheden for at kode del-af strukturen uden tvungen brug af

systemer

Konkrete eksempler på anvendelsen af CCS

En fælles platform (evt. web service) udviklet og drevet af cuneco

Afprøvningsprojekter

Tidsplan for de færdige standarder

De tekniske dele af rapporten oversat til Engelsk

Kode strukturen beskrevet som kode notationer, følgende mulige

standarder blev nævnt

o Extended Backus-Naur Form, EBNF

o Regulære udtryk, Regexp

10.4 Eksempler på CCS i EBNF-format

CCS kodens syntaks kan IT teknisk f.eks. beskrives i Extended Backus-Naur

Form (EBNF - ISO 14977) eller lignende relevante metasyntakser.

Nedenstående eksempel i EBNF format illustrerer kun princippet og skal

detaljeres inden det udleveres som brugbart eksempel. DBK kode = RDS id kode, {”/”, RDS placerings kode}, ”/”, 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 ;


11 Relation til andre standarder

11.1 ISO 12006-2 (2001 / 2013)

CCS relation til ISO 12006-2 (2001) (under revision 2012-2013)

ISO 12006-2: Building constructions - Organisation of information about

construction works. Part 2 - Framework for classification of information.

ISO 12006-2 er under revision, og cuneco deltager via Dansk Standard i

udviklingen af den nye version, der udsendes i en officiel ”Committee

Draft” (CD) version i begyndelsen af 2013.

At arbejdet funderes på ISO12006-2 betyder, at der er en international

anerkendt ramme for klassifikation, som CCS kan placeres inden for.

ISO 12006-2 er den grundlæggende standard inden for klassifikation af in-

formation i byggeriet. Standarden definerer, at

ressourcer (construction ressource) anvendes

i en proces (construction process)

til at skabe resultater (construction result)

og at ressourcer, processer og resultater alle har egenskaber

(construction property)

Som det fremgår af titlen på standarden, omhandler ISO 12006-2 klassifika-

tion. Der kan oprettes klassifikationstabeller inden for ressourcer, proces-

ser, resultater og egenskaber. Standarden beskriver hvilke forskellige krite-

rier der kan anvendes til at skabe klassifikationstabellerne i de forskellige

områder.

Figur 24 herunder viser sammenhængen mellem de 4 domæner. Figuren er

et uddrag af den nye udgave af ISO 12006-2 figur 1 (ændringer kan fore-

komme).


Construction

resource

Construction result

Construction

process

uses

results in

Construction

property

has

Figur 24 - De 4 grundlæggende domæner i ISO 12006-2

[Uddrag af ny ISO 12006-2, figur 1. Ændringer kan forekomme i den endelige udgave.]

Standarden anvendes således, at man i de enkelte lande kan udvikle egne

klassifikationstabeller, dvs. at der er metodefrihed for hvordan man eksakt

vil implementere standarden. Hensigten er derfor ikke at hvert land har

identiske klassifikationstabeller, men at man inden for hvert område kan

mappe til andre landes respektive tabeller, såfremt de følger rammerne fra

ISO 12006-2.

Standarden omhandler ikke kodeprincipper for hvorledes klassifikationsta-

beller eller deraf afledte koder for klasser skal udformes. Dette er ligeledes

op til de enkelte lande at udforme.

CCS arbejdet med at udforme koder for bygningsdele er derfor kun delvist

omfattet af ISO 12006-2 i form af principperne for klassifikationstabellerne,

men ikke i form af selve koderne eller måden som de udformes og sam-

mensættes på, fx til en identificerende kode.

Helt konkret vil enhver CCS kode skulle anvendes inden for ét af de fire

domæner: ressourcer, processer, resultater og egenskaber.

Denne koderapport omhandler kun de koder der skal anvendes inden for

resultatdomænet til at kode bygningsdele og brugsrum. Klassifikationsta-

beller til bygningsdele baseres på anbefalingerne i ISO 12006-2, og udfor-

mes efter de retningslinjer der er anført heri.


11.2 ISO/IEC 81346 (2009)

CCS relation til ISO/IEC 81346 standardserien.

ISO/IEC 81346: Industrielle systemer, installationer og udstyr samt industri-

produkter - Struktureringsprincipper og referencebetegnelser.

Del 1: Generelle krav.

Del 2: Klassifikation af objekter og koder for klasser

NOTE: En referencebetegnelse er en identificerende kode for et objekts forekomst i et givent

system.

ISO/IEC 81346 beskriver regler for udarbejdelse af identificerende koder

(del 1) samt definerer en grundlæggende tabel for klassificering af objekter

(del 2).

Som nævnt i afs. 11.1 er ISO 12006-2 den grundlæggende rammestandard

for CCS med hensyn til klassifikation af information.

ISO/IEC 81346 standardserien er en forudsætning for udvikling af CCS, da

man dermed sikrer at CCS koder er baseret på internationalt anerkendte

teknikker for udformning af koder. I lighed med Danmark, har Tyskland

valgt at anvende kodeprincipperne fra 81346 i deres nationale kodesystem

for bygningsdele, se afs. 11.3.

ISO/IEC 81346 standardserien beskriver reglerne for hvordan information

struktureres så det kan anvendes til kodning af objekter, hvilket ikke er

omfattet af ISO 12006-2, samt giver en konkret anvisning på klassifikations-

tabeller efter funktion, hvor ISO 12006-2 blot beskriver at man bør lave

tabeller af bygningsdele, baseret på funktion.

Samspillet mellem ISO 12006-2, ISO/IEC 81346 og CCS illustreres med Figur

25 på næste side.


CCS

brugsrum

klassifikationKodeprincipper

ISO/IEC 81346-1

CCS tillægKlassifikation og identifikation

af brugsrum vha. strukturelle

aspekter (81346-1 m. lille CCS

tillæg) & CCS klassifikation

[Uddrag af foreløbig udgave

af ISO 12006-2 figur 1.]

Construction

resource

Construction result

Construction

process

Construction space

uses

results in

Construction

complex

Construction entity

Construction

element

aggregate of

part of

defined by

Construction

property

has

part of

part of

Kodeprincipper

ISO/IEC 81346-1

CCS tillæg

Klassifikation

ISO/IEC 81346-2

CCS

bygningsdele

Klassifikation og identifikation af

bygningsdele vha.

strukturelle aspekter

(81346-1 m. CCS tillæg)

& klassifikation

(81346-2 med CCS tillæg)

Figur 25 - Sammenhæng mellem ISO 12006-2, ISO/IEC 81346 og CCS

NOTE: Figuren i den sorte indramning er et uddrag af den kommende version af ISO 12006-2, figur 1. Ændringer kan forekomme.

ISO/IEC 81346 del 1 og 2 er anvendt i CCS i det omfang det har været tek-nisk muligt, mens andre ønsker og tekniske krav har været nødvendige at tilføje. Fx definerer 81346 blot hvad præfiks ”=”, ”+”, ”-” og ”#” anvendes til, mens der i CCS var et særbehov for at introducere ”%” som et ekstra præfiks til håndtering af typer. Tilsvarende er klassifikationstabellerne i 81346-2 baseret på funktion, men stopper ved et todelt klassifikationstrin, mens der i CCS er behov for et tredje trin. Endvidere er der betegnelser og termer i klasserne fra 81346-2 der mest er rettet mod elektroteknik og mekanik, men som med en modifi-kation nu også kan omfatte de konstruktive bygningsdele (vægkonstruktion, dør, vindue etc.).

Det skal bemærkes, at klassifikationsprincippet fra ISO/IEC 81346-2 følger

anbefalingerne i ISO 12006-2.

11.3 DIN 6779-12 (2010)

CCS relation til DIN 6779-12.

DIN 6779-12: Kennzeichnungssystematik für technische Produkte und

technische Produktdokumentation – Teil 12: Bauwerke und Technische

Gebäudeausrüstung

I lighed med CCS, har Tyskland for nyligt (2011-2012) introduceret kode-

principper baseret på ISO/IEC 81346 standardserien i deres byggesektor.


Langt de fleste kodeprincipper er ens med CCS, herunder anvendelse af

præfikstegn.

CCS er dog mere fleksibelt og udbygget end den tilsvarende DIN: Fx om-

handler CCS også brugsrum på same niveau som bygningsdele, hvilket DIN

standarden ikke gør. Endvidere har CCS en mere omfattende og gennemar-

bejdet tabel med bygningsdele, herunder især bygningsdele der er vigtige

for konstruktionsingeniører og arkitekter, end den tilsvarende DIN.

De grundlæggende klassifikationsbogstaver der anvendes af CCS hhv. DIN

er ens, da de begge er baseret på ISO/IEC 81346-2.

cuneco er opmærksomme på, at der er planer om at udgive DIN 6779-12

som en international ISO/IEC standard.

11.4 ISO 4157 (1999)

CCS relation til ISO 4157.

ISO 4157: Teknisk tegning. Bygningstegninger.

Del 1: Betegnelsessystemer. Bygninger og dele af bygninger.

Del 2: Rumnavne og -numre.

Del 3: Rumidentifikatorer.

ISO 4157 standardserien giver anvisninger på hvordan en bygning og dens

etager / rum kan nummereres med henblik på anvendelse i bygningsteg-

ninger.

Anvendelsesområdet er dermed begrænset i forhold til fx de behov som

BIM stiller i dag, og standarden er kandidat til en opdatering på flere punk-

ter, hvilket der dog p.t. ikke er planer om.

De grundlæggende principper fra ISO 4157, fx at man anskuer ”bygning -

etage - rum” håndteres af CCS vha. ”--” aspektet . Se afs. 8.2.3.

ISO 4157 indeholder ikke anvisninger på klassifikation af rum.

Der henvises endvidere til CCS rapporten om klassifikation af brugsrum, der

er uden for emneområdet af denne rapport.

11.5 SFB (1950+)

CCS relation til SfB.

SfB-systemet (SfB = Samarbetskomitén för Byggnadsfrågor) blev oprindeligt

udviklet for klassificering og kodning af den svenske standardbeskrivelse

Bygg-AMA, og anvendtes her første gang i 1950.

[Kilde: www.hfb.dk]

http://www.hfb.dk/


SfB anvendes i stor grad i Danmark. Anvendelsesgranden er meget over-

ordnet og ikke homogen, fx har de enkelte aktører forskellige fortolkninger

af hvordan systemet anvendes og til hvad, dvs. at SfB findes i et utal af vari-

anter i Danmark.

CCS bliver den fælles afløser for de mange forskellige anvendelser der fin-

des af SfB.

Denne rapport anbefaler, at der i det omfang det er muligt udarbejdes

overordnede mappingtabeller mellem SfB og CCS. Dette er kun muligt i et

vist omfang, idet CCS er mere omfattende end SfB, og endvidere er de to

systemer udarbejdet til forskellige formål: SfB er udarbejdet med det for-

mål at kode og klassificere en beskrivelse mens CCS er udarbejdet til at

understøtte både digitale og analoge processer i arbejdet med bygnings-

modeller (2D, 3D, diagrammer, beregninger, beskrivelser etc.).

I lighed med at der kan udarbejdes mappingtabeller fra SfB til CCS, vil det

også være muligt at mappe andre kodestrukturer fra forskellige bygherrer /

aktører til CCS efter behov.

11.6 DBK (2006)

CCS relation til DBK.

DBK er udarbejdet af bips i 2004-2005.

DBK er en forkortelse for Dansk Bygge Klassifikation og blev udgivet i 2006.

Hensigten med DBK var at danne et fælles grundlag for organisering og

udveksling af informationer i byggeriet. DBK blev udviklet i samarbejde med

en lang række aktører i byggebranchen, hvor de fleste fag var repræsente-

ret.

DBK introducerede som det første system en del-helhed tankegang, der

adskilte sig fra andre landes traditionelle klassifikationstabeller ved at orga-

nisere alle bygningsdele i et hierarki, hvor forskellige bygningsdele pr. defi-

nition var en del af en større helhed.

DBK’s kodeprincipper blev baseret på tal, og bevirkede bl.a. at ens byg-

ningsdele (fx isolering) skiftede kode, alt efter hvilken overordnet bygnings-

del den var en del af, hvilket rent IT teknisk var uhensigtsmæssigt.

Det bemærkes, at del-helhed relationer ikke er et klassifikationssystem i

traditionel forstand, idet traditionel klassifikation er baseret på type-af rela-

tioner. Del-helhed anvendes som udgangspunkt til at håndtere helheder (fx

anlæg eller større systemer) frem for enkeltdele.

DBK blev gjort obligatorisk via IKT bekendtgørelsen, og er derfor blevet

anvendt på større offentlige projekter. Del-af strukturen fra DBK er med til

at skabe overblik over de bygningsdele der indgår, og dermed et samlet

overblik over antallet og typerne af bygningsdele. Dermed er der også hø-


stet de første erfaringer med DBK og ikke mindst styrker og svagheder ved

DBK.

DBK indeholder i sine nuværende tabeller en meget stor mængde af an-

vendte betegnelser for bygningsdele. CCS genanvender samtlige disse be-

tegnelser som grundlag til udvikling af de nye CCS klassifikationstabeller,

hvoraf de afledte koder indgår i de i denne rapport nævnte kodeprincipper,

og kan genkendes via anvendelsen af bogstaver. Der henvises i øvrigt til

projektgruppen der udarbejder klassifikationstabeller for bygningsdele, og

som ikke er en del af denne rapport.

De i DBK anvendte præfikstegn (fx ”-” og ”+”) genanvendes i CCS, men er

blevet ændret, videreudviklet og veldefineret, således at anvendelsesfor-

men for alle aspekter nu er konsistente og endvidere kan opfylde både krav

til analog anvendelse og krav til digital anvendelse i fx IT systemer.

CCS er derfor et nyt system, hvor ”tavlen er visket ren” fra DBK, men på den

anden side genanvender de principper der har vist sig effektive ved afprøv-

ning i DBK, fx del-helheds relationerne. CCS er udvidet og ændret i forhold

til DBK, og er derfor et langt mere fleksibelt system, der tillader forskellige

former for anvendelse set i forhold til DBK.

Det har været centralt for arbejdet med CCS, at forskellige eksisterende

kodesystemer, herunder DBK, skal kunne mappes til CCS i så stort omfang

som muligt.

11.7 Forvaltnings Klassifikation (2009)

CCS relation til Forvaltnings Klassifikation.

FK er udarbejdet af Landsbyggefonden.

Ministeriet for By, Bolig og Landdistrikter har (medvirkning fra 1. februar

2012) ændret bekendtgørelsen om drift af almene boliger mv. Dette inde-

bærer, at Forvaltnings Klassifikation med tilhørende kontoplaner for konto

115 og 116 nu skal indarbejdes.

[Kilde: www.lbf.dk]

Klassifikationstabellerne i forvaltningsklassifikation er udarbejdet efter et

andet princip end CCS og til et andet formål end CCS. Hvor CCS er designet

til at dække hele livscyklussen for bygningsdele og brugsrum, er Forvalt-

ningsklassifikation (som navnet indikerer) designet til forvaltningsdelen af

almene boliger.

Denne rapport anbefaler, at der i det omfang det er muligt, udarbejdes

mappingtabeller mellem Forvaltningsklassifikation og CCS, idet CCS sikrer at

medtage alle bygningsdele fra Forvaltningsklassifikationstabellerne i CCS

tabellerne.


11.8 IFC/IFD

CCS relation til IFC og IFD.

IFC er et IT-neutralt udvekslingsformat (og ikke et kodesystem), der bl.a.

anvendes til udveksling af informationer mellem forskellige IT-platforme, og

som fordrer at information skabes digitalt (dvs. at ”manuelle” informatio-

ner ikke understøttes).

IFD er et internationalt bibliotek over de forskellige termer som forskellige

lande anvender om forskellige objekter. Såfremt man er enig i fx den engel-

ske term for en bygningsdel, kan man lægge en tilsvarende dansk term ind i

IFD, og dermed mappe til andre landes tilsvarende betegnelser. Det be-

mærkes, at de enkelte lande ikke ser ens på samme bygningsdele og derfor

er en direkte mapping ikke altid mulig.

Kodemekanisme i CCS virker sammen med både IFC og IFD på følgende

måde:

CCS-koden indeholder en lang række delkoder som har forskellig

betydning, og som entydigt kan genkendes på et præfiks

(fx %, #, =, +, -).

Ét af formålene med koden er at identificere forekomsten af et gi-

vent objekt i et byggeris livscyklus.

CCS koden kan ”bæres” af IFC, som én af mange oplysninger (egen-

skaber) om et objekt. IFC behøver ikke kende betydningen af koden

(dvs.at kunne de-kode den), men skal blot overfører CCS koden

mellem to parter.

IFC er designet til at blive anvendt 100% digitalt, mens CCS både

kan anvendes manuelt (”analogt”) og digitalt.

IFD er et internationalt bibliotek med termer for bygningsdele.

CCS vil kunne bidrage med flere termer og danske betegnelser til

IFD, inklusive definitioner til det eksisterende bibliotek.

IFD er ikke et kodesystem, og dermed ikke i konflikt med CCS koder.

Når et objekt kodes med den nye CCS klassifikations kode (Type-af)

vil objektet også kunne kodes med begrebets IFD-GUID. Ved en ef-

terfølgende eksport fx via IFC vil denne IFD-GUID blive båret med til

andre systemer som kan de-kode CCS typen i forhold til begrebet

og derved oversætte det til et andet lands klassifikationstabeller.

De terminologier som CCS udvikler og benytter om bygningsdele kan 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.


Figur 26 herunder illustrerer samspillet mellem CCS, IFC og IFD ved udveks-

ling af data mellem brugere.

Figur 26 - CCS og relationer til IFC/IFD

11.9 OmniClass, BSAB, Uniformat m.fl.

CCS relation til andre landes klassifikationsstandarder.

Under arbejdet med udvikling af CCS har det været en forudsætning at stu-

dere andre landes tilsvarende klassifikationssystemer.

Fælles for fx OmniClass (USA), BSAB (Sverige) og Uniformat (Storbritannien)

er, at deres systemer er udviklet ud fra et andet princip end CCS og til et

andet formål. Typisk medtager disse systemer forskellige egenskaber for de

forskellige objekttyper, der inddrages som successivt inddelingskriterie for

objekterne. Konsekvensen er, at klassifikationssystemerne bliver endog

særdeles omfattende når de sammenlignes med CCS. Se også Figur 2 i den-

ne rapport, der illustrerer princippet.

De nævnte klassifikationssystemer har til formål at klassificere objekter

(bygningsdele og brugsrum), og ikke som CCS både at identificere og klassi-

ficere bygningsdele og brugsrum.

Derfor er der også tale om to forskellige tilgange til håndtering af kompleks

information og deres sammenhænge. CCS har valgt et stabilitetsprincip, der

bevirker at klassen og koden for denne er helt stabil set i livscyklus Dette

gøres bl.a. ved at anvende et særligt inddelingskriterie i klassifikationstabel-

lerne, således at CCS koden er meget enkel og forbliver intakt uanset om

egenskaberne ændres (fx ved valg materialevalg).

I modsætning til de her nævnte systemer, knyttes egenskaber i CCS separat

til et objekt, der er identificeret ved en sammensætning af præfiks, bog-

stavkode for klasse og et løbenummer.

BygningsdelBygningsdel

IFCIFCEgenskaber:------------ ------- --- --- --- --- ---- -------

Værdi:------ ------- -----B1.UG1.QQC1-------- ---- ----- --3vHRQ8oT0Hsm051Mm008

Bygningsdel

Vægsystem 1. Vægkonstruktion 1. Dør 1 -B1.UG1.QQC1

Vægsystem 1. Vægkonstruktion 1. Dør 1 -B1.UG1.QQC1

------------- ------- -- --------

--- -- -----

-- ----------------------- -----

----- ---------- -----

IFDBuilding Smart Dictionary

3vHRQ8oT0Hsm051Mm008


Som eksempel på forskellen kan nævnes en væg, der i Uniformat kan klassi-

ficeres på 72 forskellige måder (inklusive kendte egenskaber, herunder

materialevalg), mens samme væg kun kan klassificeres på 1 måde i CCS, og

øvrige informationer behandles som egenskaber. CCS sikre bl.a. dermed at

objekter kan forkodes i fx objektbiblioteker, og at der kan anvendes en ko-

de der er velegnet til menneskelig genkendelse.

Såfremt de øvrige landes klassifikationssystem i lighed med CCS følger an-

visningerne i ISO 12006-2, kan der mappes mellem CCS og andre klassifika-

tioner, evt. med mellemkomst af IFD. Se afsnit 11.8.

Det skal bemærkes, at de her nævnte klassifikationssystemer ikke opfylder

stabilitetsprincippet, som CCS anser for væsentligt

.


12 Sammenfatning

Sammenfatning af rapporten og de væsentligste konklusioner.

Denne revision af rapporten er 2. udgave, der har medtaget og indarbejdet

de relevante høringskommentarer fra den offentlige høring i 2012. Rappor-

ten og dermed kodeprincipperne fremstår derefter mere homogene og

veldefinerede til brug for en fornyet offentlig høring, der afvikles i 2013.

CCS er designet til at være ét fælles kodesystem, som er fælles for alle fag-

grupper gennem hele livscyklus.

CCS relationer til øvrige internationale og nationale standarder er beskrevet

i relevant omfang.

Kodesystemet anvender en kombination af præfiks (tegn for et specifikt

strukturelt aspekt), klassifikation (bogstaver) og løbenummer (tal) til at

skabe en identificerende kode for bygningsdele og brugsrum Koden er de-

signet så den umiddelbart kan genkendes af mennesker, og endvidere kan

tolkes af IT systemer til brug for udveksling af informationer.

cuneco har truffet aftale med et parterne i DNV Gødstrup projektet om test

af CCS kodeprincipper og deraf afledte navngivning af bygningsdele og rum.

De i Gødstrup projektet anvendte IT systemer har forpligtet sig til at imple-

mentere og understøtte CCS kodeprincipper, herunder klassifikation og

anvendelse af præfikstegn.


13 Bilag A - Termer og definitio-ner

Definitioner af anvendte termer - input til CCS begrebskatalog.

Følgende centrale termer anvendes i denne rapport.

[Reference til kilde er indsat i firkantet parentes].

objekt (byggeobjekt)

en fysisk bestanddel – eller tænkt fysisk bestanddel - af en bygning med alle

dens iboende egenskaber, relationer til omkringliggende byggeobjekter

samt øvrig relateret information.

[DBK2006] / [ISO 12006-2:2001, 2.2 modificeret]

strukturelt aspekt en bestemt måde at se et objekt på i en struktur

NOTE 1: Formålet med et strukturelt aspekt er at strukturere information efter ensartede

retningslinjer og at anvende dette til at identificere et objekt (bygningsdel eller brugsrum)

entydigt.

NOTE 2: Ved entydig identifikation af et objekt forstås, at alle objekter (også af samme type)

kan identificeres hver for sig, og dermed klart adskilles fra hinanden. I daglig tale vil man

kalde dette for ”nummerering af bygningsdele” eller ”nummerering af brugsrum”.

NOTE 3: Ét strukturelt aspekt er én af flere egenskabsværdier. Et strukturelt aspekt har ikke

indflydelse på egenskaberne der knyttes til et objekt.

[CCS definition] view et defineret udvalg af informationer om ét eller flere objekter til et bestemt

formål

NOTE 1: Et view anvendes til at se specifikke informationer om ét eller flere objekter til et

bestemt formål fx en energisimulering eller priskalkulation.

NOTE 2: Resultatet af et view er et øjebliksbillede af specifikke informationer fx i form af

egenskabsdata.

[CCS definition]


objekttype klasse af objekter der har de samme karakteristiske egenskaber

[IEC 62507-1:2010, 3.16]

objektforekomst anvendelsen af en objekttype inden for en specifik sammenhæng (fx i et

(andet objekt eller system) uafhængigt af hvilket objekt individ der

anvendes

[IEC 62507-1:2010, 3.15]

objektindivid et eksemplar af en objekttype uafhængigt af hvor den er benyttet

[IEC 62507-1:2010, 3.14]

GUID

Globally unique identifier.

et unikt referencenummer der anvendes som identifikation i computer

software:

[Wikipedia]

IFC

Industry Foundation Classes.

datamodel som har til formål at beskrive bygninger og bygningskonstrukti-

onsdata.

[Wikipedia]

IFD

International Framework for Dictionaries

en (international) standard for terminologi biblioteker eller ontologier.

[www.ifd-library.org]

bygningsdel (fra engelsk: Construction element)

en afgrænset bestanddel af en bygning, som i sig selv eller i kombination

med andre bygningsdele har en karakteristisk funktion i bygningen.

[DBK2006] / [ISO 12006-2, 2.6 modificeret]

NOTE: Definitionerne i ISO 12006-2 er under revision og udkommer i første nye udgave i

2013. Der anvendes her den eksisterende definition fra 2001.

brugsrum rum defineret af det byggede miljø og som giver plads til brugeraktivitet

eller udstyr

[CCS 2012]

Note 1: Et brugsrum kan bestå af flere zoner. En zone kan også betragtes som et brugsrum,

defineret ud fra dets karakteristika. Eksempelvis en gangzone, et arbejdsområde, et op-

holdsområde osv.

Note 2: Med til det byggede miljø hører også det naturskabte miljø som kan være med til at

definere et brugsrum. Eksempelvis afgrænser en skovgrænse, et vandløb eller en skrænt

f.eks. en have, en park eller en plads.

Note 3: Udstyr kan f.eks. være inventar, teknisk udstyr og anlæg.


[CCS definition]

system konstruktionssystem samvirkende konstruktionsobjekter organiseret til at opnå et eller flere specificerede formål

[Dansk oversættelse af ”construction system” fra ny ISO 12006-2 (2013)] [ISO/IEC 15288:2008, modificeret]


14 Bilag B – Oversigt over aspekt-koder

CCS – strukturelle aspekter

DefinitionStrukturelt aspekt:

En bestemt måde at se et objekt på i en struktur.

Generelle regler

Version: 2012-11-29

Adskillelse

af koder

”/”

Såfremt flere koder for strukturelle aspekter skrives samlet

på én linie, skal koderne adskilles med et skråtegn ”/”, fx:

-B1.UA1.QQA1 / ++B4.E2.R1

Regler for

supplerende

strukturelle

aspekter

For hvert strukturelt aspekt kan der etableres yderligere

strukturelle aspekter, der identificeres ved 3 eller flere

præfikstegn, fx: ===, +++, ====.

For supplerende strukturelle aspekter gælder samme

syntaksregler, som for det strukturelle aspekt der suppleres.

Hvorvidt der benyttes regler for bygningsdele eller brugsrum i

det supplerende strukturelle aspekt angives projektspecifikt.

Anvendelse

af skilletegn

”.”

I det sammensatte produktaspekt, i placeringsaspektet samt

i funktionsaspektet anvendes punktum ”.” som skilletegn

mellem de forskellige niveauer i strukturen.

Anvendelse

af bogstaver

og tal

I en kode for et strukturelt aspekt anvendes bogstaver til

angivelse af klassifikation.

I en kode for et strukturelt aspekt anvendes tal som

projektspecifikt løbenummer.



Præfiks

Eksempel

Anvendelse

CCS -

klassifikation

Definition

% %%

Typeaspekt

Symbol

Gruppering af bygningsdele for

projektspecifikt formål vha. CCS

klassifikation.

Relevant ved beskrivelse af

bygningsdele der har

sammenfaldende egenskaber.

Vinduestype 1 (sidehængt)

%QQA1

Vinduestype 2 (tophængt)

%QQA2

Bygningsdele

Projektspecifik gruppe af

bygningsdele med samme

klassifikation.

Gruppering af brugsrum for

projektspecifikt formål vha. CCS

klassifikation.

Relevant ved konfigurering og

beskrivelse af brugsrum.

Brugsrum

Projektspecifik gruppe af

brugsrum med samme

klassifikation.

Kontor type 1 (enkeltrum)

%%NA01

Kontor type 2 (storrum)

%%NA02

Version: 2012-11-29



Præfiks

Eksempel

Anvendelse

CCS -

klassifikation

Definition

# ##

Produktaspekt

Symbol

Identifikation af bygningsdele

vha. CCS klassifikation og

nummerering.

Anvendes til nummerering uden

kendskab til eller behov for

strukturering.

Vindue nr. 1

#QQA1

Vindue nr. 316

#QQA316

Bygningsdele

Identificerer en bygningsdel

betragtet som et selvstændigt

objekt.

Identifikation af brugsrum vha.

nummerering.

Anvendes til nummerering

uafhængig af brugsrummets

placering.

NB! Må ikke forveksles med

egenskaben ”rumnummer”.

Identificerer et brugsrum

betragtet som et selvstændigt

objekt.

Brugsrum nr. 1

##1

Brugsrum nr. 235

##235

1 2 3 1 2 3

Version: 2012-11-29



Præfiks

Eksempel

Anvendelse

CCS -

klassifikation

Definition

- --

Sammensat produktaspekt

Symbol


ved deres indbyrdes

sammenhæng vha. CCS

klassifikation og nummerering.

Anvendes til sammensætning af

bygningsdele ved brug af

hovedsystemer, delsystemer og

komponenter.

Der kan for de enkelte

bygningsdele anvendes samme

nummerering som anvendt i

produktaspektet (#).

Vægsystem 1. Vinduesparti 1.

Vindue 1

-B1.QA1.QQA1


-B12.QQA316

Bygningsdele

Identificerer en bygningsdel som

en del af en anden bygningsdel.

Identifikation af et brugsrum vha.

nummerering i forhold til den

bygning, afsnit (option) og etage

som det indgår i.

Anvendes når placering af et

brugsrum i en bygning er kendt.

Identificerer et brugsrum som en

del af en bygning, afsnit (option)

og en etage.

Bygning 4. Etage 2. Brugsrum 1

--B4.E2.R1

Bygning 12. Afsnit 3. Etage 2.

Brugsrum 22

--B12.S3.E2.R22

Version: 2012-11-29

Brugsrum



Præfiks

Eksempel

Anvendelse

CCS -

klassifikation

Definition

+ ++

Placeringsaspekt

Symbol

Placering af en bygningsdel på

eller i en anden bygningsdel.

Vægsystem 1.

Vægkonstruktion 2.

Beklædningsplade 3

+B1.UC2.QTL3

Bygningsdele

Identificerer et sted udtrykt ved

en bygningsdel.

Placering af en bygningsdel i et

brugsrum.


en etage.

Placering af en bygningsdel i et

afsnit.


eller i en bygning.

Placering af et brugsrum i et

brugsrum.

Brugsrum

Bygning 4.

Etage 2.

Brugsrum 1

++B4.E2.R1

Version: 2012-11-29

Identificerer et sted udtrykt ved

et brugsrum, en etage, et afsnit

eller en bygning.



Præfiks

Eksempel

Anvendelse

CCS -

klassifikation

Definition

= ==

Funktionsaspekt

Symbol


ved deres funktionelle

sammenhæng, uafhængig af

fysisk implementering, vha. CCS


Anvendes til prædesign og/eller

systemdesign af hovedsystemer

og delsystemer, fx i form af

procesdiagrammer og

konstruktive systemer.

Ventilationssystem 1.

Blandeanlæg 2.

Kontraventil 3

=J1.HA2.RMA3

Bygningsdele

Identificerer en bygningsdel som

en del af en anden bygningsdel i

en funktionel sammenhæng.

Identifikation af brugsrum ved

deres funktionelle sammenhæng

vha. projektspecifik klassifikation

samt CCS brugsrums-


Anvendes til funktionelt at

sammensætte brugsrum ved

deres tilhørsforhold til grupper af

rum.

Identificerer et brugsrum i en

projektspecifik funktionel

sammenhæng.


==K1.A2.MA3

Projektspecifik Brugsrum

Version: 2012-11-29


15 Bilag C – Oversigt over supple-rende aspektkoder


Præfiks

Eksempel

Anvendelse

CCS -

klassifikation

Definition

Supplerende strukturelle aspekter

Symbol

Anvendes til etablering af supplerende strukturer efter

projektspecifikt behov.

CCS klassifikation og projektspecifik klassifikation

anvendes i det supplerende strukturelle aspekt efter

samme regler, som det strukturelle aspekt der

suppleres.

Badekabinemodul 4.

Vægkonstruktion 1

---AA4.UC1

Identisk med klassifikationen

i det strukturelle aspekt der suppleres

Der gælder samme definition, som for det strukturelle

aspekt der suppleres.

Version: 2012-11-29

%%%%

####

----

++++

====

%%%

###

---

+++

===

…

…

…

…

…

Skole 1. Administration 1.

Kontor 3

===S1.A1.NA3


16 Bilag D – Eksempler for kod-ning af bygningsdele


Præfiks EksempelSymbol

%Vinduestype 1

(sidehængt)

Vinduestype 2

(tophængt)

#Vindue nr. 1

Vindue nr. 3161 2 3

-

Vægsystem 1.

Vinduesparti 1.

Vindue 1

+Vægsystem 1.

Vægkonstruktion 2.

Plade 3

=Ventilationssystem 1.

Blandeanlæg 2.

Kontraventil 3

%QQA1

%QQA2

#QQA1

#QQA316

-B1.QA1.QQA1

+B1.UC2.QTL3

=J1.HA2.RMA3

Eksempler på kodning af bygningsdele

++Bygning 4.

Etage 2.

Brugsrum 1

++B4.E2.R1

Version: 2012-11-29

Vægsystem 12.

Vinduesparti 18.

Vindue 316

-B12.QA18.QQA316


17 Bilag E – Eksempler for kod-ning af brugsrum


Præfiks EksempelSymbol

%%Kontor type 1

(enkeltrum)

Kontor type 2

(storrum)

##Brugsrum nr. 1

Brugsrum nr. 235

--Bygning 4. Afsnit 3.

Etage 2. Brugsrum 2

== Klynge 1. Afdeling 2.

Kontor 3

%%NA01

%%NA02

##1

##235

--B4.E2.R1

==K1.A2.NA3

Eksempler på kodning af brugsrum

++ Bygning 4. Etage 2.

Brugsrum 1++B4.E2.R1

1 2 3

Version: 2012-11-29

Bygning 4. Etage 2.

Brugsrum 1

--B4.S3.E2.R2


18 Bilag F - Kommentarer til be-hovsanalysens foreløbige ho-vedkonklusioner

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 klassifikation af objekter der er uafhængig af objektrelationer i et byg-værk. Krav: Objekter skal kunne klassificeres uafhængigt af referencekodning, dvs. uafhængigt af den kompositoriske struktur af bygværk.

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

”Der mangler grundlag for 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 bygværker. 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 grupper af objekter af samme klasse 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 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 i de aspektkoder hvor CCS tillader det. Denne klassifikation er kun gyldig inden for ét bestemt byggeprojekt, men kan genbruges i andre byggeprojekter efter aftale blandt projekternes parter.

Producenterne opererer med deres egne klassifikationer (koder og 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 inddelingskriterier

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

Det skal afklares, hvordan sammen-hængen er mellem bygningsdele i bygningsmodeller, bygningsdelsbe-skrivelser og kalkulationer i forhold til entydighed og klassifikation. Der er ikke enighed eller standard på dette område.

For rum skal afklares: Bruges der én type koder for at kunne lave og 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.

100

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

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

101


19 Bilag G – Forudsætningsnotat

Beskrivelse af aktivitet 2 – forudsætninger for opgaveløs-ning. I dette notat beskrives grundlaget for opgavens løsning jævnfør projektbe-

skrivelse af 15. marts 2011, 9. udgave. Grundlaget for projektet er i øvrigt

beskrevet i listeform i projektbeskrivelsen afs. 6.

Forudsætninger for nuværende DBK:2006: Forudsætninger fra nuværende DBK er beskrevet i ”DBK 2006 vejledning,

Begrebsmodel, klassifikations- og referencesystem” version 2006-08-01

samt uddybet på møde med Gunnar Friborg (bips) den 2011-06-23.

Følgende var grundlaget for udvikling af DBK:2006

1. At der findes en teoretisk model for forholdet mellem objekter,

tegn og begreber

(A. Ekholm, side 13)

2. At DBK:2006 er forankret i en overordnet begrebsmodel (afsnit 5)

fra ISO 12006 standardserien

3. At der er afveget fra ISO 12006 (afsnit 5.1) i form af en uddybning af

modellen fra ISO 12006.

4. At DBK:2006 så vidt muligt er internationalt kompatibelt (afsnit

1.3). Dette betyder i praksis at der kan ”mappes” til andre landes

klassifikationssystemer.

5. At modellen (DBK), skal dække hele byggeriets livscyklus (afsnit 1.2)

6. At begrebsdefinitioner i prioriteret rækkefølge er taget fra (A) In-

ternationale ISO/IEC Standarder, (B) Oxford Dicitionary of English,

(C) Nudansk Ordbog og (D) egne definitioner.

7. DBK:2006 er bygget således at alle typer kan sammensættes efter

behov. Præ-definerede sammensætninger er ikke en del af

DBK:2006, da mængden heraf bliver uoverskuelig (fra Gunnar Fri-

borgs gennemgang af DBK:2006).

8. DBK:2006 er objektorienteret (fra Gunnar Friborgs gennemgang af

DBK:2006).

Forudsætninger for ny udgave af DBK:2012 (nu: ”CCS”) Arbejdsgruppen ser følgende som teknisk forudsætning for udvikling af

kodestrukturen til en ny udgave af DBK.

Almene forudsætninger 1. Forudsætningerne fra DBK:2006 bibeholdes.

102


2. Projektbeskrivelse ”Afklaring af Struktur og kode for bygningsdele”

af 25. maj 2011 pkt. 3.3 ”Succeskriterier”, der beskriver succeskrite-

rierne for en ny kodestruktur.

3. Det er centralt at kodesyntaksen bliver IT-egnet. Arbejdsgruppen

definere dette således, at de enkelte dele af en kode skal være IT-

eget, og ser dette som en grænseflade til projektet om egenskaber.

4. Projektet omfatter beskrivelse af en kodesyntaks for tabeller om

produkter (jævnfør ISO/IEC 81346) der anvendes i resultatdomæ-

net (jævnfør ISO 12006-2). Øvrige domæner er ikke omfattet af det-

te projekt.

5. Det præciseres, at DBK-koden er en referencebetegnelse, baseret

på ISO/IEC 81346 og reglerne heri, samt at DBK-kodens formål er at

identificere forekomster af objekter. Se særskilt afsnit herom.

6. Jævnfør afklarende møde med Håvard Bell hos cuneco/bips den

2011-07-01 tages der hensyn til IFC & IFD i det omfang DBK:2012

kan berige IFC & IFD og drage nytte af den mekanisme som de re-

præsentere, dels som udvekslingsformat, dels som bibliotek for

terminologi.

7. Øvrige IT-standarder medtages ikke og er således ikke en forudsæt-

ning for projektet.

Andre tillægsforudsætninger

I det omfang det er teknisk muligt og relevant, indarbejdes følgende tillæg

til forudsætningerne, som er baseret på de indledende diskussioner som

arbejdsgruppen har haft om projektet:

1. DBK-koden skal beskrives således at den kan medtages i QR-code

og RFID-chipset som ”ren tekst”.

2. Anvendelsen af DBK-koden analogt henholdsvis digitalt skal præci-

seres.

3. Relationen mellem IFC/IFD og DBK forklares bedre og det synliggø-

res hvordan IFC, IFD og DBK:2012 virker sammen. Det forudsættes

bl.a. at DBK-referencekoden er én af flere egenskaber de kan over-

føres via IFC, dvs. at IFC ikke skal kode/dekode DBK-koden, men in-

deholde et felt til dette.

4. Formålet med DBK:2012 koden er at skabe et ”link” mellem den di-

gitale verden og den analoge verden. Dvs. at DBK koden kan hånd-

teres ”i bidder” internt i et IT-system alt efter behov / tekniske be-

grænsninger etc. mens den sammensættes til et analogt formål, fx

at skabe et link mellem et byggeobjekt og den tilhørende analoge

mærkning og dokumentation.

5. Der kan evt. udarbejdes et ”analogt” spor og et ”digitalt” spor der

viser hvad der sker med informationerne i IT systemerne, og hvad

der udlæses til en analog DBK-kode.

6. DBK-koder skal kunne genereres automatisk eller evt. semi-

automatisk.

103


7. Begrebsdefinitionerne fra DBK:2006 udvides til at omfatte (E) IFD

begreber, (F) Wikipedia m.fl. og at prioritetsrækkefølgen heraf evt.

kan ændres.

8. Der indarbejdes en versioneringsdel af DBK, således at IT-

systemerne kan kende forskel på eventuelle forskelle i udgaverne af

DBK.

9. Det er måske en begrænsning, at der kun findes én identificerende

DBK-kode. Det skal præciseres hvad en identificerende DBK-kode i

så fald identificere, set i det samlede livscyklus for et objekt i bygge-

riet.

10. Der skal skelnes mellem ”unikke numre” og ”entydige numre”, og

forskellen heri skal tydeliggøres. Dette er bl.a. relevant for at skelne

mellem forekomster, typer og individer. Se særskilt afsnit herom.

11. DBK-koden anvendes bl.a. til at identificere det samme objekt en-

tydigt, uanset hvor det befinder sig i livscyklus, hvilket er et sær-

kende for DBK i forhold til andre landes klassifikationssystemer.

12. Afgrænsning af udsagnet ”DBK skal kunne anvendes i hele byggeri-

ets livscyklus”, da fx Forvaltningsklassifikation har ”en anden opfat-

telse”. Udsagnet afgrænses derfor til at DBK-koden pr. definition

kan anvendes i alle faser, men at koden ikke i sig selv ”tilfredsstiller

alle behov” i alle faser. Det vil være nødvendigt at anvende flere

egenskaber m.v.

13. Forudsætning til objekter der medtages i DBK-kodens fremtidige

form: Kodeord: ”Sporbarhed” og ”Der medtages det i strukturen,

der giver mening (i sporbarheden)”.

14. Det præciseres, at DBK-koden ikke kun anvendes i 2D / 3D CAD-

modeller, men også i ”ikke-CAD” som fx beskrivelser, beregninger,

diagrammer etc.

15. I det omfang det er relevant og muligt, kan relationen mellem DBK-

koden og IDM (Information Delivery Manual) synligøres.

16. Én DBK-kode kan sandsynligvis ikke rumme ”alt” – der skal sandsyn-

ligvis bruges mellem 1-3 koder for at tilfredsstille alle informationer

i alle faser. Det fastholdes at der udvælges én DBK kode som den

primære entydige ID, og som er robust set over det samlede tids-

perspektiv.

Tekniske forudsætninger I dette afsnit beskrives diverse tekniske forudsætninger, der danner grund-

lag for udarbejdelse af en revision af DBK-koden.

Muligheder for tilstande af objekter (”arbejdsgang”)

Følgende tilstande for et objekt er indledningsvis identificeret:

1. Objekter der ikke kræver entydig ID (dvs.et løbenummer), men ale-

ne en type: Fx ens vinduer, gulvbrædder.

104


2. Objekter der skal have et entydigt ID (med løbenummer) når objek-

tet er installeret: Fx en stikkontakt, belysningsarmatur, vinduer (af

hensyn til drift).

3. Objekter der skal have et entydigt ID (med løbenummer) inden det

installeres: Fx et specifikt ventilationsanlæg (ventilationsanlægget

laves specifikt til hvert byggeri) eller individuelle vinduer.

Det betyder i praksis at:

1. Alle DBK-koder er udtaget inden installation på pladsen.

2. Nogle koder påsættes hos leverandøren (præ-definerede koder til

fx ventilationsanlæg).

3. Nogle koder påsættes på byggepladsen (fx stikkontakter).

4. Andre koder påsættes aldrig i praksis (fx skruer, søm) selv om ko-

den findes (fx koder på vinduer, isolering, lysarmaturer).

Ændringer i ISO 12006-2

Ændringer i DBK i forhold til ISO 12006: (Se slide ”The ISO 12006-2 stan-

dard” fra Gunnar Friborg møde den 2011-06-23).

ISO 12006 defines a framework for classification: DBK:2006 er gået

100% ind for den grundlæggende model, men i den model i ISO

12006 der ”står op” er i DBK:2006 ”lagt ned”, og endvidere er der i

den originale model et ”låst view” fra nogle aktører, hvilket giver en

”låst metode” at se data på, hvor DBK:2006 – pr. definition – har

delt alt op i separate tabeller, der kan kombineres efter behov.

ISO 12006-2 har termen ”space”, hvilket er lidt for upræcist, så det-

te er udspecificeret til et mere detaljeret niveau. Det overordnede

scope for ISO 12006 matcher fint scopet af ISO/IEC 81346 standar-

den.

Generelt om forskellige koder fra ISO/IEC 81346

Følgende tabel 1 fra ISO/IEC 81346 anses for meget central i det videre

arbejde med udarbejdelse af en revideret DBK-kode:

105


Figuren viser, at et der skelnes mellem Typer, Forekomster og Individer

(som er identisk med Instanser).

Figuren antages at kunne præcisere hvad en DBK-kode primært anvendes

til (kaldet ”referencedelen” i projektbeskrivelsen), og hvad en typekode

anvendes til (kaldet ”klassifikationsdelen” i projektbeskrivelsen).

106


20 Bilag H – Udvidet kravspecifi-kation

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.

Projektgruppens kommentarer til behovene identificeret i de foreløbige

hovedkonklusioner fra projekt 10011 – Behovsanalysen, kan læses i Bilag F -

Kommentarer til behovsanalysens foreløbige hovedkonklusioner.

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 F.

I de følgende afsnit gennemgås de af projektgruppen udvidede krav der

ligger til grund for den udarbejde struktur og syntaks for kodning i CCS.

Kravene er opdelt således:

Klassifikationskrav

Identifikationskrav

Normative krav

Anvendelseskrav

Implementeringskrav

20.1 Klassifikationskrav

Krav 1: Bygningsdele og brugsrum skal kunne tildeles en klassifikati-

on der er uafhængig af objekternes relation til andre objekter i et bygværk, dvs. en klassifikation der er uafhængig af den strukturelle komposition for bygværket.

Krav 2: Aktørers brug af eget klassifikationssystem skal kun være

muligt i følgende tilfælde: Aktøren ønsker at lave en underklassifikation af CCS klassifi-kationen f.eks. for at kende forskel på forskellige designs af objekter i sit byggeri.

107


a. En sådan underklassifikation skal i CCS betragtes som en identifikation af bestemte grupper af ob-jekter med samme CCS klassifikation;

b. Identifikation er kun gyldig inden for ét bestemt byggeprojekt, men kan genbruges i andre bygge-projekter efter aftale blandt projekternes parter;

c. Underklassifikationen kan kun anvendes i en vel-defineret CCS aspektkode.

Krav 3: Klassifikationen skal bestå af bogstaver. Navne for bygnings-

dele udgør data der kan anvendes efter behov, dog ikke til klassifikation 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.

20.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 og defineret af projektets aktører. Den projektspeci-

fikke dekomponering kan bl.a. baseres på leverancer, modu-

ler eller lignende, og kan f.eks. benyttes 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 andre bygningsdele.

108


Krav 12: CCS skal understøtte tidlig identifikationskodning af brugs-

rum i projekter før den endelige placering af brugsrummene

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å brugsrummenes endelige placering.

20.3 Normative krav

Med henvisning til grundlaget for projektet og de stillede krav, fastholdes

rammerne fra ISO 12006-2 standarden. ISO 12006-2 er en rammestandard

for klassifikation af byggeriet, men omhandler imidlertid ikke kodningsprin-

cipper for bygningsdele eller rum, og ISO/IEC 81346, der indeholder prin-

cipper for kodning og identifikation, inddrages derfor i arbejdet i det om-

fang det kan supplere ISO 12006-2.

Dette gælder særligt anvendelsen af aspekter til kodning af objekter i CCS,

samt syntaksregler til opbygning af koden. Kodeprincipperne i CCS revideres

væsentligt i forhold til DBK2006 udgaven på en sådan måde, at de stillede

krav til projektet opfyldes.

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

dele til ISO12006-2

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

efterfølgende vil blive udarbejdet, skal kunne anvendes

sammen med IFD.

20.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.

109


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

af projektspecifikke grupper 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.

20.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.

110


21 Bilag I – Spørgeskema til IT-leverandørgruppen i bips

Firma:

Software:

Nr. Spørgsmål: Svar:

1 Den ”nye” DBK kode består af flere dele. Er det mu-

ligt at de-kode ved:

a.) at skille koden ad i fx 3 dele og

b.) de-kode hver del-kode i forskellige dele (fx at

behandle RDS ID koden på én måde, type-koden på

en anden måde og en ”projektspecifik” kode på en

tredje måde)?

2. Såfremt der skal løbenumre på de enkelte objekter,

fx vinduer og konstruktioner - hvilke regler skal der

så bruges, for at et IT system kan kode dette auto-

matisk uden brugerindblanding?

NB! Der påtænkes indledningsvis samme metode

som M&E generelt benytter i ”systemtankegang”,

dvs. at der tildeles løbenumre inden for hver objekt-

klasse som del-systemet består af (Fx A01, A02, B01,

C01, C02, C03 etc.)

3. Er det muligt at lave en løbenummerserie som be-

gynder på en bestemt værdi (fx 101, 102 etc.)? Kan

fx være en option for at tildele forskellige faggrupper

forskellige nummerserier (arkitekt = 100, konstrukti-

on = 200 etc.)

4. En DBK kode anses for én egenskab (af mange) til et

objekt. Har I et forslag til hvordan denne DBK-kode

(dvs. en specifik egenskab) kan importeres / ekspor-

teres entydigt mellem forskellige IT systemer?

5. Med den DBK kode 2012 som vi arbejder med, er det

så muligt at pre-kode et objekt internt i jeres system,

således at brugere ikke skal tænke nærmere over

hvilken kode der skal tildeles? Hvis ”nej” - eftersøger

vi en forklaring på hvorfor, og hvad der i givet fald

111


skal ændres for at det kan lade sig gøre.

6. Ny DBK kode har et behov for at være ikke-låst for-

mat, dvs. at der ikke kan garanteres bestemte plad-

ser betyder noget bestemt. I det udleverede eksem-

pel på DBK kode, består RDS ID af 2 niveauer, men

det er ikke en fast regel - der kan være fra 1-5 ni-

veauer i hver RDS kode.

Til gengæld kan der sættes helt klare regler op for

hvornår der kommer bogstaver og tal, hvornår der

kommer løbenumre og hvornår der kommer et skifte

til et nyt niveau (fx ved brug af ”.” og ”/” i DBK-

koden.

7. Er det ok at der er ”mellemrum” i koderne for ma-

nuel læsbarheds skyld, fx [”RDS-kode” ”mellemrum”

”/” ”mellemrum” ”type-kode”] etc.?

8. DBK koden består af forskellige dele, hvoraf den

første RDS ID er obligatorisk. Såfremt de andre plad-

ser er ”tomme”, skal der så alligevel afsættes plads

til dette (”dummies”)?

9. Præfikstegn ”-”, ”+”, ”++”, ”=”, ”/” og ”#” anses for

centrale i DBK koden til at adskille betydningen af de

forskellige del-koder. Er der tekniske forhindringer i

IT-systemerne der bevirker, at disse præfikser ikke

kan anvendes.

NB! Her tænkes ikke på at præfikstegnene fx får MS

Excel til at ”regne” (da man så kan definere cellen

som tekst), men om der er specifikke negative kon-

sekvenser. Hvis ja, ønskes disse beskrevet som en

del af svaret.

10. I det viste eksempel på DBK-koden 2012 er der for-

udsat en fast rækkefølge i opbygningen af koden (se

bilag). Der er imidlertid et ønske om ikke at låse

denne rækkefølge, bortset fra et krav om at RDS ID

kode altid står forrest for at identificere objektet,

mens de øvrige del-koder kan variere alt efter be-

hov. De enkelte del-koder kan helt sikkert identifice-

res vha. deres respektive præfiks (+, ++, # etc.) såle-

des at der ikke er tvivl om hvad koden betyder, uan-

set dens plads i den samlede DBK-kode. Er det OK at

identificere den enkelte del-koder vha. deres respek-

tive (og unikke) præfikses?

ccs kodnings- regler - bips · pdf fileiso/iec 81346-1 og 81346-2 hertil er under projektets...

Documents