CCS kodningsregler. Kodningsregler for klassifikation og identifikation af objekter

Transkript

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

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

3 1 Resumé Denne rapport beskriver forudsætningerne, forløbet og resultatet med cuneco projeketet Kodningsprncipper for klassifikation og identifikation. Rapporten beskriver den tekniske løsning, dels i overordnede principper, dels i detaljer således at det kan anvendes til fx implementering i IT software. Kodeprincipperne afløser det eksisterende DBK og bliver samtidig omdøbt til CCS (cuneco classification system). CCS er et nationalt system der kan anvendes til klassifikation og identifikation af bygningsdele og rum, samt til at beskrive relationerne mellem bygningsdele og rum. Der er taget udgangspunkt i ISO og ISO/IEC standarderne, hvor ISO er en rammestandard for konteksten af klassifikation og ISO/IEC definere reglerne for strukturer, syntaks og til dels klassifikation inden for bestemte områder. Grundlæggende adskiller CCS sig fra DBK ved at hvor de forskellige aspekter i DBK definerede forskellige klasser for et objekt, så fortæller aspekterne i CCS en sammenhæng mellem objekter af samme klasse og en måde at adressere dem på. I Bilag C - Oversigt over aspektkoder findes en oversigt over de samlede kodeprincipper i CCS. Det anbefales at have disse oversigter ved siden af rapporten for at opnå en hurtigere fortrolighed med princippet. 3

4 2 Indholdsfortegnelse 1 Resumé Introduktion Projektgrundlag Projektforløb Kravspecifikation Målgruppe Krav Klassifikationkrav Identifikationskrav Normative krav Anvendelseskrav Implementeringskrav Objekthåndtering i CCS: Typer, forekomster og individer Kodede objekter: Bygningsdele og rum CCS KodningsREGLER Klassifikation og identifikation CCS-kodens overordnede struktur Aspekter Klasser Løbenumre Aspektkoderne Anvendelse af aspektkoder Gruppe 1 aspektkoder [%] Bygningsdelsklasse [#] Simpelt bygningsdels ID

5 8.2.3 [=] Bygningsdels funktions ID [-] CCS bygningsdels ID [+] Konstruktionsrums placerings ID Gruppe 2 aspektkoder [%%] Rumklasse [##] Simpelt rum ID [==] Rum funktions ID [ ] CCS brugsrums ID [++] Brugsrums placerings ID Gruppe 3 aspektkoder [---] Projektspecifk aspektkode Kodningseksempler Dør Afbryder Forslag til klassifikation Bygningsdele Hovedsystemer Bygningsdele Konstruktive Bygningsdele elektriske og mekaniske Bebyggelser Bygninger Brugsrum Relation til internationale standarder m.v IFC/IFD ISO/IEC ISO Sammenfatning Bilag A - Termer og definitioner Bilag B - Eksempler på CCS i EBNF-format

6 15 Bilag C - Oversigt over aspektkoder Bilag D - Kommentarer til behovsanalysens hovedkonklusioner Bilag E Bygningsdelstabel

7 3 Introduktion Denne rapport beskriver resultatet af Cuneco projekt Afklaring af struktur og kode for bygningsdele. Projektet har til formål at udarbejde et klart og entydigt grundlag for en revideret version af struktur og kodesyntaks for bygningsdele og rum i Dansk Bygge Klassifikation (DBK). Den reviderede version vil herefter kendes under navnet cuneco classification system (CCS). Resultatet af projektet er en beskrivelse af en struktur for kodning af typer og forekomster af bygningsdele og rum i resultatdomænet. Projektet har fokus på afhjælpning af de problemstillinger og mangler, der er blevet påpeget siden DBK blev frigivet i 2006 og skal skabe grundlag for det efterfølgende arbejde i cuneco, der har til formål at frembringe reviderede reference- og klassifikationstabeller. Projektet er udført af en arbejdsgruppe nedsat af Cuneco, som består af: Søren Spile, Projektleder, cuneco Ulf Harlou, CPC - Center for Product Customization ApS Allan Dam Jepsen, CPC - Center for Product Customization ApS Nicolai Karved, Betech Data A/S Henrik Balslev, Balslev & Jacobsen ApS Rapporten beskriver regler for, hvorledes CCS koder skal udarbejdes, og retningslinier for det efterfølgende klassifikationsarbejde. Rapporten præsenterer forslag til klassifikationstemaer, men omhandler ikke det specifikke tabelarbejde, herunder de klassifikationstabeller der skal udarbejdes på baggrund af denne rapport, dvs. udarbejdelse af tabeller. 3.1 Projektgrundlag De detaljerede forudsætningerne for gruppens arbejde, herunder de grundlæggende tekniske krav som nye kodningsprincipper skal opfylde, er nærmere beskrevet i: Projektbeskrivelse: Afklaring af struktur og kode for bygningsdele. 9. udgave dateret

8 Beskrivelse af aktivitet 2 - forudsætning for opgaveløsning. Version Følgende materiale danner grundlag for projektet jf. Projektbeskrivelsens pkt. 6: DBK 2006 ISO ISO/IEC og Ekholm-rapporten, 2011 DIKON-rapporten, 2010 Notat om DBK i forbindelse med IT-systemer, bips Notat om DBK i BIM software, Betech Data A/S, 2009 DBK Kodningsprincipper, Henrik Balslev, 2010 (vedlagt) Forvaltnings Klassifikation, Landsbyggefonden og KL, August 2009 IFD, Hertil er under projektets forløb tilføjet: Udviklingsplan for Dansk Bygge Klassifikation Behovsanalyse hvad er byggebranchens behov for standarder for udveksling af digital information? (Foreløbige hovedkonklusioner) 3.2 Projektforløb Projektgruppen har gennemført projektet ved gennemløb af korte udviklingscyklus med løbende review og feedback af foreslåede løsninger fra udvalgte eksperter. Hovedforløbet for projektet mht. udformning af den tekniske løsning har været følgende rækkefølge: 1. Afklaring af forudsætninger og grundlag for opgavens løsning a. Studie af DBK2006 samt supplerende baggrundsmateriale (se afsnit 2.2) b. Afdækning af relationer til IFC og IFD, samt cuneco projektet vedr. egenskabsdata 2. Indsamling af basisinput til projektarbejdet med deltagelse af udvalgte eksperter med afsæt i de vedtagne forudsætninger for opgaven 3. Udformning af syntaks og struktur for ny kodeteknik med fokus på nedenstående områder: a. Studie af nødvendige / lovgivningsmæssige / direktivmæssige kodningsbehov b. Studie af kodens udvikling over tid (projektforløb) c. Studie af informationsniveauer og deres indvirkning på koden d. Løbende tests af IT-egnetheden e. CCS kode og relation/samspil med IFC og IFD. f. Håndtering af ny kode ved udveksling i IT-systemer g. Mapning til eksisterende DBK koder 8

9 h. Mapning til ISO , Forvaltnings Klassifikation og ISO/IEC i. Udarbejdelse af grafiske eksempler 4. Intern høringsworkshop i Cuneco med deltagelse af udvalgte interessenter 5. Revision af syntaks og struktur for ny kodeteknik samt udarbejdelse af klassifikationstemaer for bygningsdele, systemer og brugsrum. 6. Offentlig høring (fremtidigt arbejde) 7. Udarbejdelse af endelig rapport med indarbejdede høringssvar (fremtidigt arbejde) Undervejs i projektet er afholdt koordinerende workshops og møder med Cuneco s styregruppe, projektgruppen for Cuneco projekt Afklaring af struktur og metode for egenskabsdata, og interessenter fra ITleverandør branchen. 9

10 4 Kravspecifikation CCS-koden er designet til at understøtte hele bygge- og driftsprocessen, og CCS kan derfor anvendes til et varieret kodningsbehov i de forskellige faser. Da Cuneco projekt Behovsanalysen først sent i projektets forløb har kunne præsentere sine hovedkonklusioner, har projektgruppen som grundlag for sit arbejde fundet det nødvendigt at præcisere hvilke behov der adresseres med den nye CCS-kode og hvilken anvendelse koden er tiltænkt. Behovene og de resulterende krav til CCS-koden er undervejs i projektet udbygget og tilpasset efter input fra følgende kilder: Projektets baggrundsmateriale Interne workshops i projektgruppen Review af projektgruppens arbejde med Cuneco s styregruppe og IT-leverandører Studie af behovsanalysen fra Cuneco projekt Behovsanalysen Projektgruppens kommentarer til behovene identificeret i de foreløbige hovedkonklusioner fra projekt Behovsanalysen kan læses i bilag D. Projekt har desuden påpeget en række elementer der bør indgå i overvejelserne ved udvikling af en klassifikationsstandard i Cuneco. De af elementerne der har været af direkte relevans for udviklingsarbejdet er ligeledes kommenteret i bilag D. I det efterfølgende gennemgås målgruppen for CCS og de primære krav der ligger til grund for det endelige resultat. 4.1 Målgruppe CCS-koden er tiltænkt brug både i byggeprojekter og uden for byggeprojekter. Målgruppen inkluderer derfor alle byggeriets aktører, fx: Byg- og driftsherrer Arkitekter Rådgivere Ingeniører Entreprenører Udførende Byggematerialeleverandører Projektgruppen har været særligt opmærksom på de faglige forskelle mellem aktørerne og deres forskellige informationsbehov, samt hvorledes disse forventes at være differentieret efter bl.a. branche, virksomhedsrolle, opgaveportefølje, it-niveau etc. 10

11 4.2 Krav Som udgangspunkt for projektet er der jævnfør opgavedefinitionen pkt. 3.3 stillet følgende minimumskrav som succeskriterie for projektet Kodesyntaksen skal være it-egnet. Det skal tilstræbes, at de tabeller der omhandler klassifikationsdelen og som efterfølgende vil blive udarbejdet, skal kunne anvendes sammen med IFD. Koden skal indeholde en klassifikationsdel, der er uafhængig af hvilken sammenhæng bygningsdelen indgår i. Koden skal omfatte en referencedel, der gør brug af klassifikationsdelen. Kodesyntaksen skal indeholde en løbenummerdel, der kan bruges til at identificere bygningsdele unikt indenfor projektet. Kodesyntaksen skal understøtte mapning mellem den nye struktur og DBK Kodesyntaksen skal tilstræbes at kunne mappes til andre nationale klassifikationssystemer. Klassifikationsdelen skal kunne anvendes under hele byggeprocessen fra program til og med forvaltning. Projektgruppens analyse af behov for den nye CCS-kode har resulteret i en udbyggelse af ovenstående i forhold til nedenstående temaer, der gennemgås i de efterfølgende afsnit. Kravene er opdelt således: Klassifikationskrav Identifikationskrav Normative krav Anvendelseskrav Implementeringskrav Disse krav udgør den grundlæggende kravspecifikation for udviklingen af CCS. Det bør overordnet set bemærkes at udviklingen af CCS sker med hensyn til en række lovmæssige og normative krav især til mekaniske og elektriske bygningsdele, fx Stærkstrømsbekendtgørelsen og Maskindirektivet, der bl.a. bevirker, at en kode skal være designet i overensstemmelse med relevante harmoniserede standarder, og at disse koder skal være egnet til menneskelig genkendelse. Med henvisning til grundlaget for projektet og de stillede krav, fastholdes rammerne fra ISO standarden og de grundlæggende kodningsprincipper baseret på ISO/IEC standarden. Kodeprincipperne i CCS revideres dog væsentligt i forhold til DBK2006 udgaven. Revisionen af koden sker fortsat med ISO/IEC som grundlag, men på en sådan måde, at de stillede krav til projektet opfyldes. Udover reglerne for syntaks fra ISO/IEC medtages de relevante klassifikationstabeller fra for 11

12 så vidt angår mekaniske og elektriske anlæg, da disse er normative for disse systemer Klassifikationskrav Krav 1: Krav 2: Krav 3: Krav 4: Krav 5: Bygningsdele og rum skal kunne tildeles en kode for typeklassifikation uafhængigt af referencekodning. Aktørers brug af eget klassifikationssystem skal kun være muligt under følgende forudsætninger: klassifikationen udgør en underklassifikation af klassifikationen i CCS; denne underklassifikation er kun gyldig inden for ét bestemt byggeprojekt, men kan genbruges i andre byggeprojekter efter aftale blandt projekternes parter; underklassifikationen kan kun anvendes i en veldefineret CCS kode. Klassifikationen skal bestå af tegn. Navne for bygningsdele udgør data der kan anvendes efter behov, dog ikke til klassifikation og reference. Klassifikationsdelen i CCS skal muliggøre en statisk klassifikation af en bygningsdel eller et rum, således at tilskrivningen af egenskabsdata ikke ændrer klassifikationen af objektet. Dette gøres for at sikre en stabil kodning (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. Klassifikation i CCS skal være entydig dvs. et objekt skal ikke kunne klassificeres som mere end én type Identifikationskrav Krav 6: Krav 7: Krav 8: Krav 9: Krav 10: CCS skal understøtte stabil og entydig identifikation af objekter 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. CCS skal inkludere identifikation af objekter i forhold til en dekomponering for byggeri defineret af CCS. CCS skal muliggøre identifikation af objekter i forhold til en dekomponering for byggeri gældende inden for ét bestemt projekt. Den projektspecifikke dekomponering kan bl.a. baseres på leverancer, moduler eller lignende, og kan f.eks. benyttes til omkostnings- eller vægtberegninger. CCS skal understøtte identifikation af bygningsdele uden hensyntagen til den strukturelle komposition af byggeriet. CCS skal understøtte identifikation af bygningsdele baseret på den strukturelle komposition af byggeriet. 12

13 Krav 11: Krav 12: Krav 13: Krav 14: CCS skal understøtte reference af bygningsdeles fysiske placering i forhold til brugsrum og konstruktionsrum. CCS skal understøtte tidlig identifikationskodning af rum i projekter før den endelige placering af rummene er kendt. CCS skal understøtte struktureret identifikationskodning af brugsrum baseret på deres funktion i byggeriet. CCS skal understøtte struktureret identifikationskodning af rum baseret på rummenes endelige placering Normative krav Krav 15: Krav 16: Krav 17: CCS skal muliggøre mapping af klassifikationer for bygningsdele til ISO CCS skal muliggøre mapping af klassifikationer for bygningsdele til ISO/IEC Det skal undgås, at objektklassifikationen fra CCS konflikter med ISO/IEC , da denne klassifikation ifølge maskindirektivet er påkrævet for elektriske og mekaniske installationer. De tabeller i CCS der omhandler klassifikationsdelen og som efterfølgende vil blive udarbejdet, skal kunne anvendes sammen med IFD Anvendelseskrav Krav 18: Krav 19: Krav 20: Krav 21: Krav 22: Krav 23: Det kræves af CCS-koden, at den kan udtages manuelt; at koden benytter simple klassifikationstabeller; samt at koden understøtter minimal kodning for brugere med simple kodningsbehov. CCS skal søge at minimere eller helt undgå nødvendigheden af omkodning af objekter og udskiftning af objekter i projekter. CCS skal understøtte genbrug af datastrukturer og dokumentation. Dette inkluderer minimal omkodning i datamodeller og dokumentation samt identifikation af designbestanddele og associeret data og dokumentation. CCS-koden skal muliggøre nem søgning, filtrering og sortering af objekttyper defineret i CCS. CCS-koden skal muliggøre nem søgning, filtrering og sortering af projektspecifikke varianter af objekttyper defineret i CCS. CCS-koden skal understøtte forskellige grader af datastrukturering i overensstemmelse med det differentierede billede af digitalisering i branchen, omfanget af projekterne hvori koden skal anvendes og aktørernes tilgængelige ressourcer. 13

14 Krav 24: Krav 25: Krav 26: Krav 27: CCS skal muliggøre analog navigering i byggeriers strukturer. Dvs. CCS skal understøtte beskrivelse af byggeriers komposition og et objekts strukturelle kontekst. Det skal være muligt at benytte CCS-koden som den identificerende kode ved dataudveksling i alle IT-systemer og domæner. CCS skal understøtte relatering af funktionskrav til rum og bygningsdele. CCS skal søge at minimere potentielle konflikter ved udtagning af koder for objekter f.eks. gennem definition af kodestrukturer Implementeringskrav Krav 28: Krav 29: Krav 30: Krav 31 Generering 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. CCS-koden skal kunne anvendes i branchemiljøer af vidt forskelligt omfang og med forskellige grader af ITimplementering. CCS skal kunne benyttes i de mest gængse kontorsoftware bl.a. programmerne i Microsoft Office. 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. 14

15 5 Objekthåndtering i CCS: Typer, forekomster og individer cuneco classification cystem (CCS) anvendes til klassifikation og identifikation af objekter. Klassifikation af objekter i CCS beskriver tilskrivningen af en type til et objekt. CCS omhandler klasser og identifikation af objekter i den rigtige verden, dvs. uden om (IT) modelverdenen. Dermed sikres, at CCS ikke er i konflikt med eventuelle 3D modeller, IFC m.v., men er et fælles referencepunkt for disse. I samråd med projektgruppen der arbejder med objekt egenskaber, er der defineret følgende adskillelse mellem de forskellige typer af objekter der behandles: Objekttype Klasse af objekter der har de samme karakteristiske egenskaber [FDIS for IEC , Requirements for identification systems enabling unambiguous information interchange Part 1: Principles and methods] Objektforekomst Anvendelsen af en objetktype inden for en specifik sammenhæng (fx i et andet objekt (anlæg) eller et system (bygning)) uafhængigt af hvilket objekt individ der anvendes [FDIS for IEC ] Objektindivid Et eksemplar af en objekttype uafhængigt af hvor den er benyttet [FDIS for IEC ] NOTE: Objekterne og definitionerne er objekter betragtet i den virkelige verden, og omfatter derfor ikke en model repræsentation af samme objekt. Formålet med at skelne mellem de tre typer af objekter er at kunne håndtere information om objekterne (type - forekomst - individ) på mere klart. Objekttypen vil anvende en klassifikation, der er ens for både objektforekomst og objektindivid, dvs. at både objektforekomst og objektindivid benytter samme klassifikation. 15

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

17 6 Kodede objekter: Bygningsdele og rum CCS koder to grundlæggende objekter: bygningsdele og rum. Objektet bygningsdel forefindes som: objekttype, objektforekomst og objektindivid. Objektet rum forefindes som: objekttype og objektforekomst. Objektet rum kan ses som brugsrum og konstruktionsrum. Bygningsdele, brugsrum og konstruktionsrum illustreres i denne rapport med følger definitioner og symboliseres ved de viste symboler. Bygningsdel: En afgrænset bestanddel af en bygning, som i sig selv eller i kombination med andre bygningsdele har en karakteristisk funktion i bygningen. Brugsrum: Et rumligt sammenhængende og afgrænset område i en bygning, der har et primært menneskeligt anvendelsesformål. Konstruktionsrum: det rum der opstår ved opbygning af bygningstekniske systemer og som er indlejret heri. Se endvidere definitioner i Bilag A - Termer og definitioner. 17

18 7 CCS Kodningsregler Klassifikation og identifikation CCS anvendes til klassifikation og identifikation af systemer, bygningsdele og rum. I forhold til DBK2006 ændres der på måden hvorpå klassifikationsdelen og identifikationsdelen beskrives i CCS. I DBK2006 blev klassifikation beskrevet både ved tal og bogstaver. I CCS beskrives klassifikation udelukkende ved brug af latinske bogstaver. Klassifikation og identifikation anvender følgende regler: A A1 1.) CCS klassifikationsdelen kan anvendes separat efter behov, og kan indgå i alle de øvrige koder i CCS. Klassifikationsdelen har til formål at samordne klasser af objekter, som har det samme sæt af egenskaber (type-af). Koden for en given klassifikation foretages alene vha. bogstaver. 2.) CCS identifikationsdelen er opbygget af bogstaver fra klassifikationsdelen plus et løbenummer der qua kodens opbygning tilsammen giver en oplysning om typen af objekt + et løbenummer og/eller hvilken strukturel komposition et objekt indgår i (del-af), således at enhver objektforekomst kan skelnes fra andre objektforekomster. Identifikationsdelen skal benyttes som robust identifikation af enhver objektforekomst i et byggeri, såfremt det er nødvendigt at kunne skelne ens forekomster fra hinanden, fx skelne døre, vinduer, ventiler og stikkontakter individuelt fra hinanden CCS-kodens overordnede struktur Den information der udveksles om objektforekomster er så forskelligartet i et byggeri, at det ikke er teknisk muligt at udarbejde én kode der alene kan opfylder alle de krav, som stilles til en CCS kode. Den tekniske løsning på kodemekanismen i CCS er derfor designet som en sammensætning af flere delkoder kaldet aspektkoder, der følger de samme syntaksregler, men som hver især tilgodeser forskellige informationsbehov om en objektforekomst. De enkelte aspektkoder kan anvendes individuelt eller i kombination med hinanden. Regel 1: Den samlede CCS-kode der tilskrives et objekt består af et varierende antal delkoder kaldet aspektkoder, der sammensættes til en samlet kodestreng kaldet CCS-kode. 18

19 Regel 2: Regel 3: De enkelte aspektkoder adskilles i CCS-koden med et skråtegn: /. Der er ingen regel for rækkefølgen af aspektkoderne i CCSkoden. Rækkefølgen er uden betydning, da man kan genkende de forskellige aspektkoder fra hinanden på deres forskellige præfiks (fortegn). Brugen af præfiks medvirker til, at CCS-koden kan genkendes af mennesker og kan adskilles rent IT-teknisk. CCS-koden følger syntaksreglerne i ISO/IEC 81346, der definerer aspektkoderne som referencebetegnelser i det der kaldes et referencesystem, forkortet RDS (Reference Designation System). En RDS kode muliggør identifikation af et objekts forekomst, hvor mindst én RDS kode identificerer objektets forekomst entydigt. Det er tillagt stor værdi, at syntaksreglerne er baseret på denne international standard, dels for at kunne opfylde allerede eksisterende krav der er funderet på ISO/IEC 81346, dels for at fremme IT understøttelse af kodereglerne i CCS. Med entydig identifikation menes, at kun én specifik objektforekomst identificeres ved den givne RDS kode, og dermed ikke kan forveksles med andre objekter. RDS koderne er i sig selv egnet til menneskelig genkendelse, og består af en kombination af bogstaver og tal sat i en bestemt rækkefølge, der fx viser en kompositionel sammensætning af givne bygningsdele. Et objekt kan foruden en RDS kode have alle former for andre koder tilknyttet, uden at dette er i konflikt med hinanden. CCS-koden reglerne om RDS koder, idet én eller flere af aspektkoderne kan udgøre en entydig identifikation af en bygningsdel eller et rum, mens øvrige aspektkoder og andre koder (serienummer, ordrenummer, produkt-id, GUID etc.) kan inkluderes som supplerende information efter behov på forskellige tidspunkter i byggeriets livscyklus. Den grundlæggende struktur for CCS-koden udformes grundlæggende som: D / D (1) (2) (3) / (4) D (5) etc. D Kode i den samlede kodestreng (1) Aspektkode se afs. 8). (2) Separator / adskiller de enkelte koder i kodestrengen (3) Aspektkode (4) Separator / adskiller de enkelte koder i kodestrengen (5) Aspektkode 19

20 7.1.3 Aspekter Aspekter i CCS koder baseres på reglerne i ISO/IEC Hovedformålet med aspekter er at kunne beskrive information om givne objekter helt præcist i form af en CCS kode. Dette understøtter det faktum at de forskellige informationsbehov i byggeriet ikke kan beskrives ud fra én bestemt anskuelse af et givent byggeri. Aspekterne agerer derfor ligesom filtre hvorigennem et byggeri anskues f.eks. strukturelt, funktionelt, placeringsmæssigt m.v. Der er i CCS defineret følgende aspekter til definition af aspektkoder: Aspekt Klassifikationsaspekt 1.) Funktionsaspekt Simpelt produktaspekt Strukturelt produktaspekt Placeringsaspekt Forklaring Anskuer byggeriet fra en klassifikationsmæssig synsvinkel, dvs. en ikke-identificerende synsvinkel (enkeltniveau). Anskuer byggeriets bestanddele ud fra deres funktionsmæssige sammenhæng (flerniveau). Anskuer byggeriet fra en simpel strukturel nedbrydning af byggeriet uden hensyntagen til den kompositoriske sammenhæng mellem objekterne (enkeltniveau). Anskuer byggeriet fra en strukturel nedbrydning med hensyn til den kompositoriske sammenhæng mellem objekterne, hvor øverste niveau defineres som systemer (flerniveau). Anskuer byggeriet ud fra en placeringsmæssig nedbrydning (flerniveau). Placeringsaspektet bruges som link mellem bygningsdele og rum (konstruktionsrum og brugsrum). Tabel 1 - Kodningsaspekter i CCS 1.) NOTE: Klassifikationsaspektet er ikke omtalt i ISO/IEC , da det er uden for emneområdet af denne standard. Klassifikationsaspektet er indført i forbindelse med CCS og er ikke i konflikt med standarden. De øvrige aspekter i CCS er velkendte og veldefinerede aspekter fra ISO/IEC

21 CCS definerer flere forskellige aspektkoder inden for hvert aspekt og tildeler hver aspekt kode et bestemt præfiks. De enkelte aspektkoder beskrives i afsnit 8. Regel 4: Regel 5: Alle aspektkoder er forsynet med et præfikstegn (fortegn), hvis betydning er defineret i afsnit 8. Såfremt der defineres mere end én aspektkode inden for et aspekt benyttes flere af det samme aspekt-tegn som præfiks f.eks. +, ++, +++ osv. jævnfør ISO/IEC Klasser Det har været en forudsætning for arbejdet med den nye CCS-kode, at den klassificerende del af CCS skal kunne anvendes separat til forskellige formål, fx til samordning af objekter i tilbudsfasen eller i en driftsfase. Af hensyn til IT egnetheden m.v. skal der dog kun findes ét ensartet klassifikationstema, der anvendes til klassifikationsdelen og identifikationsdelen, således at man får ens klassifikationsbogstaver, der betegner de samme objekter uanset anvendelsen. Klassifikationen baseres på type-af strukturer, dvs. følger de gængse regler for udarbejdelse af klassifikationstabeller. For så vidt angår identifikationsdelen for bygningsdele, er det desuden et krav at klassifikationen for bygningsdele er stabil igennem objektets livscyklus bl.a. for at undgå ændringer i den identificerende del af koden. Ved traditionel klassifikation underdeles klasserne hen over tid, efterhånden som objektet tildeles flere egenskaber (se Figur 2). Klassifikationen bliver på denne måde stadig mere detaljeret hvilket resulterer i ændringer i klassifikationskoden. 21

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

23 Klassifikationen i CCS er derfor underlagt følgende regler: Regel 6: Regel 7: Bogstaverkoder skal bestå af kapitaliserede latinske bogstaver A til Z med udelukkelse af bogstaverne I og O, da disse kan forveksles med tallene 1 (ét) og 0 (nul). I bogstavkoder bestående af mere end ét bogstav udgør et efterfølgende bogstav altid en underklasse af det foregående bogstav. NOTE: Det skal bemærkes at der i klassifikationsaspektet er mulighed for at lave en projektspecifik underklassifikation af CCS-klassifikationen, og at disse underklasser fx kan opbygges af tal. Regel 8: Inddeling af CCS-klassifikationen i underklasser, der ikke er defineret i CCS-tabellerne, tillades kun i aspektkoder inden for klassifikationsaspektet. Denne underklassifikation kan ikke benyttes i de andre aspektkoder og er kun gældende inden for konteksten af ét bestemt projekt. Der er ingen begrænsning for dybden af en sådan underklassifikation. Sammensætningen af koden følger denne regel: B B B etc. B (1) (2) (3) Klassifikationsbogstav (1) Hovedklasse (2) Underklasse af foranstående klasse (3) Underklasse af foranstående klasse Løbenumre Løbenumre i CCS benyttes inden for hver aspektkode til identifikation eller alternativt som projektspecifik underklasse. Antallet af karakterer i ethvert løbenummer er ikke fast. For eksempel har det foranstillede 0 i et løbenummer ingen praktisk betydning, og kan evt. udelades. Udeladelse af 0 kan dog have indvirkning på sortering mv. i IT systemer hvorfor man kan bestemme i et projekt at inkludere foranstillede nuller. Regel 9: Regel 10: Regel 11: Identifikation i CCS sker ved brug af løbenumre. Der er intet krav om fast antal af karakterer i et løbenummer. Foranstillede nuller kan udelades. Niveauerne i en del-af struktur til identifikation adskilles ved brug af punktum. imellem hvert niveau i strukturen. Nummerering er fortløbende inden for hvert specifikke niveau i en kodningsstruktur. F.eks. AB1.CD1.EF1, -AB1.CD2.EF1, -AB2.CD1.EF1. Nummerering går ikke på tværs af niveauer. 23

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

25 Aspekt aspekt Aspektkode - præfiks Aspektkode - navn -- Brugsrums ID Funktionsaspekt = Bygningsdels funktions ID == Rum funktions ID Placeringsaspekt + Konstruktionsrums placerings ID ++ Brugsrums placerings ID Tabel 2 Foruddefinerede CCS aspektkoder inden for hvert aspekt Aspektkoderne inddeles i tre grupper Gruppe 1: Aspektkoder der udtrykker information i forhold til bygningsdele Gruppe 2: Aspektkoder der udtrykker information i forhold til brugsrum Gruppe 3: Supplererende aspektkoder defineret i byggeprojekt En oversigt over alle aspektkoderne kan ses i Bilag C - Oversigt over aspektkoder. Aspektkoder i gruppe 1 beskriver information i relation til bygningsdele. Dette omfatter: (%) Klassifikation af bygningsdele. + % # (#) Identifikation af bygningsdele, simpel fortløbende nummerering. - = (-) Identifikation af bygningsdele, baseret på en CCS defineret dekomponering af bygningsstruktur i systemer og deres bestanddele. (+) Placeringsreference i forhold til konstruktionsrum. Placeringsinformation anvendes i CCS som x-reference til bygningsdele og brugsrum. (=) Funktionsreference for bygningsdele Aspektkoder i gruppe 2 beskriver information i relation til brugsrum. Dette inkluderer: ++ %% ## (%%) Klassifikation af brugsrum. -- == 25

26 (##) Identifikation af brugsrum, simpel fortløbende nummerering. (- -) Identifikation af brugsrum, baseret på en CCS defineret dekomponering af bygningsstrukturering. (==) Identifikation af brugsrum, baseret på en funktionel strukturering, dvs. kodning af funktionsrum. (++) Placeringsreference i forhold til brugsrum. Anvendes som x-reference til bygningsdele og konstruktionsrum. Aspektkoder i gruppe 3 beskriver supplerende information, der ikke kan udtrykkes ved brug af de foruddefinerede aspektkoder i CCS f.eks. identifikation af objekter der ikke kan klassificeres ud fra CCS og identificeres i de foruddefinerede aspektkoder, fx leverancer i moduler til et byggeri der indeholder objekter på tværs af eksisterende CCS koder. Gruppe 3 er underlagt de samme regler for kodningsprincipper som de andre aspektkoder og er gyldige inden for rammerne af et projekt, men ikke generelt i byggebranchen Regel 12: Projektspecifikke aspektkoder anvender 3 ens præfikstegn (f.eks. --- ). Definition af sådanne projektspecifikke aspektkoder skal beskrives i projektets dokumentation inkl. den anvendte klassifikation. 26

27 8.1 Anvendelse af aspektkoder Hver aspektkode har en anvendelse for enten bygningsdele eller brugsrum der kan ses i Tabel 3 og Tabel 4 herunder. Kodning af bygningsdele (og systemer) Aspektkode Anvendelse % Klassifikationskode for bygningsdele (objekttyper). # Simpel identifikation hvor alle bygningsdele af en bestemt type nummereres fortløbende i takt med at objekterne genereres - Identifikation af bygningsdele og systemer baseret på byggeriets systemstruktur = Relatering af funktioner til bygningsdele eller systemer + X-reference for placeringen af en bygningsdel i forhold til konstruktionsrum dvs. typisk krydsreference for bygningsdeles montagested. ++ X-reference for placeringen af bygningsdel i forhold til brugsrum, dvs. typisk krydsreference for bygningsdeles placering i brugsrum. Tabel 3 - Aspektkoder til kodning af bygningsdele Kodning af rum Aspektkode Anvendelse %% Klassifikationskode for rum (objekttyper) ## Simpel identifikation hvor alle brugsrum af en bestemt type nummereres fortløbende i takt med at objekterne genereres - - Identifikation af brugsrum baseret på byggeriets fysiske rumstruktur, som altid vil være projektspecifik. == Identifikation af brugsrum ud fra et funktionelt design af byggeriet. Man kan således identificere et brugsrum før dets placering er fastlagt, således at man kan designe et byggeri baseret på de nødvendige rumfunktioner. Tabel 4 - Aspektkoder til kodning af rum Se endvidere Bilag C - Oversigt over aspektkoder. 27

28 8.2 Gruppe 1 aspektkoder [%] Bygningsdelsklasse Symbol Præfiks Hovedformål Beskrivelse % (procenttegn) Ren klassifikation af bygningsdele samt projektspecifik underklassifikation såfremt det er påkrævet. Aspektkoden bruges til ren klassifikation af bygningsdele. Koden er baseret på en type-af klassifikation defineret i CCS-klassifikationstabellerne. Det er tilladt inden for rammerne af et byggeprojekt at lave en projektspecifik underklassifikation af CCSklassifikationen til brug ved gruppering af CCS-typer i projektspecifikke designvarianter f.eks. til udbud og specifikation. Klassifikationstemaet der bruges til at underklassificere CCS-typerne bestemmes af projektets deltagere. Såfremt der foretages en sådan underklassifikation er denne kun gyldig inden for rammerne af det specifikke projekt og udgør derfor ikke en underklassifikation der kan bruges generelt i byggebranchen. En evt. underklassifikation af CCS-typerne skal beskrives i projektets dokumentation, og der gælder desuden at det kun er CCS-klassifikationen der benyttes i de andre aspektkoder. Projektspecifik underklassifikation kan derfor kun findes i denne aspektkode. Klassifikation Aspektkoden gør brug af følgende tabeller: Bygningsdelstabel 1 (konstruktive bygningsdele) Bygningsdelstabel 2 (elektriske og mekaniske bygningsdele) For en eventuel projektspecifik underklassifikation gælder de samme syntaksregler for sammensætning af klassifikationsbogstaver som for den øvrige klassifikation. 28

29 Syntaks Syntaks uden brug af projektbestemt underklassifikation: % (1) B Klassifikationsbogstav(er) (1) Aspekt præfiks (2) CCS bygningsdelsklassifikation B (2) Syntaks med brug af projektbestemt underklassifikation: B T % B T (1) (2) (3) Klassifikationsbogstav(er) Underklassifikation i form af tal (1) Aspekt præfiks (2) Bygningsdelsklassifikation (Bygningsdelstabel1 & 2) (3) Projektbestemt underklassifikation vha. tal. Eksempel Eksempel uden brug af projektbestemt underklassifikation: %JA %JB Bygningsdel af typen Vindue Bygningsdel af typen Dør Eksempel med brug af projektbestemt underklassifikation: %JB1 Bygningsdel af typen Dør, projektspecifik undertype 1 %JB2 Bygningsdel af typen Dør, projektspecifik undertype 2 NOTE: De viste klasser JA, JB m.fl. er kun illustrative eksempler til brug i denne rapport, da klassifikationskoder ikke er omfattet af projektet og endnu ikke er fastlagt i fuldt omfang (marts 2012). Kodegruppen har dog udarbejdet et forslag klassifikationsprincip - se Bilag E Bygningsdelstabel [#] Simpelt bygningsdels ID Symbol

30 Præfiks Hovedformål Beskrivelse # (nummertegn) Entydig identifikation af bygningsdele, simpel nummerering Aspektkoden bruges til entydigt at identificere en bygningsdel uden hensyn til den struktur bygningsdelen indgår i. Identifikationen er derfor ikke baseret på kompositionen af byggeriet og udgør således en enkeltniveaus reference. Aspektkoden udgør således en enkeltniveaus struktur, med en simpel nummerering af bygningsdele. Klassifikation Aspektkoden gør brug af følgende tabeller: Bygningsdelstabel 1 (konstruktive bygningsdele) Bygningsdelstabel 2 (elektriske og mekaniske bygningsdele) Syntaks # (1) B (2) N (3) B N Klassifikationsbogstav(er) Løbenummer (1) Aspekt præfiks (2) Bygningsdelsklassifikation (Bygningsdelstabel 1 & 2) (3) Bygningsdels løbenummer Eksempel #JA1 Bygningsdel af typen Vindue, nummer 1 #JA34 Bygningsdel af typen Vindue, nummer 34 30

31 8.2.3 [=] Bygningsdels funktions ID Symbol Præfiks Hovedformål Beskrivelse Klassifikation = (lighedstegn) Reference for bygningsdels funktion Aspektkoden bruges som reference for funktioner for systemer og bygningsdele i en del-af struktur, og muliggør at der kan tilknyttes fælles funktionskrav til forskellige systemer og bygningsdele. Aspektkoden beskriver en del-af struktur baseret på en funktionel dekomponering af byggeriet. De refererede funktionelle objekter i strukturen er de samme objekter der kan findes i den strukturelle dekomponering af byggeriet i det strukturelle produktaspekt dvs. bygningssystemer og bygningsdele, men uden en 1:1 relation. Aspektkoden kan således ikke entydigt identificere systemer og bygningsdele, men udgør en fælles reference til den samme funktion for flere systemer eller bygningsdele. Aspektkoden gør brug af følgende tabeller: Systemtabel Bygningsdelstabel 1 (konstruktive bygningsdele) Bygningsdelstabel 2 (elektriske og mekaniske bygningsdele) Syntaks Syntaksen i aspektkoden skal kunne afspejle en del-af struktur for funktionelle systemer bestående af bygningsdele, hvor bygningsdele i CCS klassificeres enten som underklasser af Konstruktioner, Del-konstruktioner eller Komponenter. Del-af strukturen skal overholde følgende hierarki for hvor i strukturen objekterne kan indgå. System -> Konstruktion -> Del-konstruktion -> Komponenter Systemer udgør altid topniveauet i strukturen og er obligatorisk. De øvrige underliggende objekter indgår kun i strukturen såfremt de skal identificeres. Man kan således godt have dele af en struktur hvor der ikke indgår delkonstruktioner, så f.eks. konstruktionerne kun består af komponenter (og ikke del-konstruktioner). 31

32 = (1) B (2) N (3). (4) B (5) N (6). (7) B (8) N (9). (10) B (11) N (12) B Klassifikationsbogstav(er) N Løbenummer (1) Aspekt præfiks (2) Systemklassifikation (Systemtabel) (3) Systemløbenummer (4) Separator. viser det næste niveau i strukturen (5) Bygningsdelsklassifikation (Bygningsdelstabel 1: Konstruktioner, Del-konstruktioner eller Komponenter ) (6) Bygningsdelsløbenummer (7) Separator. viser det næste niveau i strukturen (8) Bygningsdelsklassifikation (Bygningsdelstabel 1: Delkonstruktioner eller Komponenter ) (9) Bygningsdelsløbenummer (10) Separator. viser det næste niveau i strukturen (11) Bygningsdelsklassifikation (Bygningsdelstabel:1 Komponenter ) (12) Bygningsdelsløbenummer Eksempel Kodning af systemer: Et byggeri består af fire vægsystemer, hvor to systemer indeholder bygningens ydre vægsystemer og to vægsystemer indeholder de indre vægkonstruktioner. De forskellige funktionskrav til hhv. indre og ydre vægsystemer specificeres ved at knytte dem til forskellige funktionelle systemer i bygningens funktionsstruktur. Vægsystemer i bygningen: -MB1 Vægsystem nummer 1 (indeholdende ydre vægkonstruktioner) -MB2 Vægsystem nummer 2 (indeholdende ydre vægkonstruktioner) -MB3 Vægsystem nummer 3 (indeholdende indre vægkonstruktioner) -MB4 Vægsystem nummer 4 (indeholdende indre vægkonstruktioner) Bygningens funktionsstruktur er defineret så den indeholder to tænkte funktionelle systemer: =MB1 Funktionelt vægsystem nummer 1 =MB2 Funktionelt vægsystem nummer 2 32

33 =MB1 bruges til at specificere funktionskrav for vægsystemer der indeholder ydre vægkonstruktioner hvor man f.eks. ønsker at specificere det samlede lysindfald. = MB2 bruges til at kunne specificere funktionskrav for vægsystemer der indeholder indre vægkonstruktioner hvor man ønsker at specificere grænser for lydtransmission. Bygningens fire vægsystemer CCS-kodes derfor således: -MB1 / =MB1 -MB2 / =MB1 -MB3 / =MB2 -MB4 / =MB2 Vægsystem nummer 1 af typen MB, funktionelt vægsystem MB1. Vægsystem nummer 2 af typen MB, funktionelt vægsystem MB1. Vægsystem nummer 3 af typen MB, funktionelt vægsystem MB2. Vægsystem nummer 4 af typen MB, funktionelt vægsystem MB2. 33

34 8.2.4 [-] CCS bygningsdels ID Symbol Præfiks Hovedformål Beskrivelse: Klassifikation - (minustegn) Entydig identifikation af bygningsdele og systemer, baseret på del-af struktur Aspektkoden benyttes til entydig identifikation af systemer og bygningsdele. Systemer anvendes til at håndtere og beskrive sammenhængende bygningsdele frem for bygningsdele som enkelte objekter. Koden benytter en produktmæssig synsvinkel og kan baseres på en generisk model for dekomponering af bygningsdele, der er prædefineret i CCS. Byggeriets systemstruktur kan aflæses af koden, og gør det bl.a. muligt at afkode del-af relationer mellem bygningsdele. Koden kan således bruges til at finde bestanddelene i byggeriets systemer. Hermed supporteres bl.a. designgenbrug ved inddeling af byggeriet i isolerede designstrukturer samt håndtering af overordnede systemer i byggeriet. Aspektkoden gør brug af følgende tabeller: Systemtabel Bygningsdelstabel 1 (konstruktive bygningsdele) Bygningsdelstabel 2 (elektriske og mekaniske bygningsdele, baseret på ISO/IEC tabel 2). ISO/IEC Tabel 1 for elektriske og mekaniske delsystemer. Syntaks Ved kodning af systemer med konstruktive bygningsdele f.eks. Vægsystemer Anvendt klassifikation: Systemtabel Bygningsdelstabel 1 (konstruktive bygningsdele) I systemer med konstruktive bygningsdele klassificeres bygningsdelene som underklasser af Konstruktioner, Delkonstruktioner eller Komponenter jævnfør Bilag E Bygningsdelstabel 1 Aspektkoden skal i disse systemer beskrive en del-af struktur der overholder følgende hierarki for hvor i strukturen objekterne kan indgå: 34

35 Systemer -> Konstruktioner -> Del-konstruktioner -> Komponenter Systemer udgør altid topniveauet i strukturen og er obligatorisk. De øvrige underliggende objekter indgår kun i strukturen såfremt de skal identificeres. Man kan således have forskellige strukturer alt efter hvad der ønskes identificeres. Syntaksen for konstruktive systemer ser således ud - (1) B (2) N (3). (4) B (5) N (6). (7) B (8) N (9). (10) B (11) N (12) B Klassifikationsbogstav(er) N Løbenummer (4) Aspekt præfiks (5) Systemklassifikation (Systemtabel) (6) Systemløbenummer (7) Separator. viser det næste niveau i strukturen (8) Bygningsdelsklassifikation (Bygningsdelstabel 1: Konstruktioner, Del-konstruktioner eller Komponenter ) (9) Bygningsdelsløbenummer (10) Separator. viser det næste niveau i strukturen (11) Bygningsdelsklassifikation (Bygningsdelstabel 1: Delkonstruktioner eller Komponenter ) (12) Bygningsdelsløbenummer (13) Separator. viser det næste niveau i strukturen (14) Bygningsdelsklassifikation (Bygningsdelstabel:1 Komponenter ) (15) Bygningsdelsløbenummer Ved kodning af elektriske og mekaniske systemer f.eks. Belysningssystem Anvendt klassifikation Systemtabel Bygningsdelstabel 2 (elektriske og mekaniske bygningsdele) ISO/IEC Tabel 1 I modsætning til de konstruktive systemer har aspektkoden i de elektriske og mekaniske systemer i teorien ikke noget maksimalt antal niveauer. Den del-af struktur aspektkoden beskriver, har kun defineret et øverste og nederste niveau, 35

36 hvorimod der kan defineres et vilkårligt antal mellemliggende systemniveauer. Topniveau: CCS system (obligatorisk) o Klassifikation i forhold til CCS systemtabel Mellemniveauer (vilkårligt antal): Undersystemer defineret i projektet (valgfri) o Klassifikation i henhold til ISO/IEC Tabel 1 Nederste niveau: CCS bygningsdele o Klassifikation i henhold til CCS bygningsdelstabel 2 Det anbefales, at der i klassifikationsprojektet defineres en række generiske systemstrukturer for hvert hovedsystem, som det anbefales at anvende i branchen. Syntaksen for elektriske og mekaniske systemer ser således ud - (1) B (2) N (3). (4) B (5) N (6). (7) B (8) N (9) B Klassifikationsbogstav(er) N Løbenummer (1) Aspekt præfiks (2) Systemklassifikation (Systemtabel) (3) Systemløbenummer (4) Separator. viser det næste niveau i strukturen (5) Undersystem; vilkårligt antal undersystemer/niveauer (ISO/IEC Tabel 1) (6) Undersystems løbenummer (7) Separator. viser det næste niveau i strukturen (8) Bygningsdelsklassifikation (Bygningsdelstabel 2) (9) Bygningsdelsløbenummer Eksempel Ved kodning af systemer med konstruktive bygningsdele f.eks. Vægsystem -MB2.DF4.LUD2 Koden dekodes til: Vægsystem nr. 2 > Vægkonstruktion nr. 4 > Plade nr. 2. Koden beskriver: Plade nr. 2 i Vægkonstruktion nr. 4 i Vægsystem nr. 2. -MB3.LUD2 Koden dekodes til: Vægsystem nr. 3 > Plade nr. 2 Koden beskriver: Plade nr. 2 i Vægsystem nr. 3 Ved kodning af elektriske og mekaniske systemer f.eks. Belysningssystem 36

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

38 8.2.5 [+] Konstruktionsrums placerings ID Symbol Præfiks Hovedformål Beskrivelse Syntaks Klassifikation + (plustegn) Reference for objekter placering i forhold konstruktionsrum Aspektkoden bruges til reference for objekters placering i forhold til konstruktionsrum, defineret som det rum der udgøres af byggeriets bygningsdele. Koden beskriver således placeringen af bygningsdele i forhold til andre bygningsdele, og kan bruges til at beskrive placeringsinformation som ikke fremgår af [-]-koden. Det kan f.eks. være tilfældet når bygningsdele er monteret i andre bygningsdele i et andet system. Dette er bl.a. tilfældet for bygningsdele i de elektriske systemer, der er monteret i bygningsdele i de konstruktive systemer såsom vægsystemer. Da konstruktionsrummet er defineret som det konstruktive rum der udgøres af bygningsdele, skal aspektkoden beskrive en del-af struktur der er en kopi af del-af strukturen i [-] koden. Syntaksen for denne aspektkode er derfor den samme som for [-] koden på den bygningsdel der refereres til. Der benyttes den samme klassifikation som i [-] og aspektkoden gør derfor brug af følgende tabeller: Systemtabel Bygningsdelstabel A (konstruktive bygningsdele) Bygningsdelstabel B (elektriske og mekaniske bygningsdele) Eksempel Kodning af en placering +MB2.DF4.LUD1 Koden dekodes til: Placering; Vægsystem nr. 2 > Vægkonstruktion nr. 4 > Plade Nr. 1 Koden beskriver: Placering; Plade Nr. 1 i Vægkonstruktion nr. 4 i Vægsystem nr. 2 Placeringen anvendes som link af en bygningsdels placering til konstruktionsrummet: -XC1.SFA1 / +MB2.DF4.LUD1 Koden dekodes til: Belysningssystem 1 > Afbryder nr. 1 placeret i Vægsystem nr. 2 > 38