KOMMENTARSKABELON. Alle kommentarer:

Transkript

1 KOMMENTARSKABELON Dato Dokument Høring CCS kodestruktur Udfyldt af: NCC Navn på person Alle : NCC Generel NCC har gennem flere år anvendt dele af DBK2006 (bygningsdele og entrepriser). Vi er overbevist om værdien af et klassifikationssystem. For os er værdien skabt gennem vores egen interne anvendelse af DBK, ikke gennem kommunikation af DBK-koder andre virksomheder. Ikke fordi, vi ikke gerne vil kommunikere DBK-koder andre, men fordi der har været få at kommunikere. Værdien af et klassifikationssystem fremhæves ofte som kommende fra at virksomhederne kan kommunikere effektivt hinanden, at vi taler samme sprog. Den værdi er der naturligvis, men den første, og i lang tid den største værdi er den, virksomheden skaber internt gennem veldefinerede begreber, en ensartet terminologi, en nyttig struktur, et anvendeligt kodesystem osv. Der er ikke behov for ændringer til standarden på dette punkt. Men fortæl meget gerne om begge former for værdiskabelse: Den værdi, virksomheden kan skabe internt, også selvom den i lang tid er ret alene om at bruge klassifikationssystemet. Den værdi, der skabes, når virksomheden kan kommunikere mere effektivt andre virksomheder. Generel Det er ikke muligt fuldt ud at vurdere CCS kodningsregler på nuværende tidspunkt. Af to årsager: Standarden er kompleks og svær at forstå. Der er tale om meget mere end kodningsregler, nemlig en hel filosofi for, hvordan klassifikation skal håndteres i den danske byggebranche. Man kan ikke afslutte formidling og høring af noget så komplekst på 18 dage. Det bliver ikke nemmere af, at rapporten kunne være mere pædagogisk. Vi er Vi synes, det en fordel del-høringer, som den der er i gang for CCS kodningsregler. Den samlede opgave både udvikling og høring af CCS må nødvendigvis brydes ned. Af de to årsager, nævnt i kommentarkolonnen foreslår vi, at høringen af CCS kodningsregler afsluttes status Vi er klogere men ikke færdige CCS kodningsregler og klassifikation. Cuneco bør støtte yderligere formidling og debat om CCS kodningsregler.

2 bange for, at mange i branchen ikke har kunnet sætte sig fyldestgørende ind i standarden på den korte tid selvom de gerne ville. Det gælder i hvert fald os selv. Rapporten beskæftiger sig kun en del af CCS samlede klassifikationskoncept. Rapporten udpeger (gennem eksempler) kun de objekttyper, der skal klassificeres (de forskellige bygningsdele, f.eks. vægkonstruktion, dør, samling ). Det har bestemt værdi, men begrænset i forhold til en mere detaljeret klassifikation. Der er behov for underklassifikation af f.eks. bygningsdele (forskellige vægkonstruktionstyper, dørtyper, ). Rapporten mener, at yderligere klassifikation af objekttyperne skal håndteres vha. egenskabsdata. Det betyder, at cunecos samlede klassifikationskoncept bliver en blanding af CCSklassifikation og CCS-egenskabshåndtering. Det er desuden nødvendigt en samlet diskussion og vurdering af hele cunecos klassifikationskoncept. Det samlede koncept vil være beskrevet i: En ny udgave af CCS kodningsregler, der tager høringsresultatet i marts 2012 i betragtning. Resultatet af cuneco-projektet Afklaring af klassifikationsniveau. Dette projekts opgave er bl.a. at afklare hvor grænsen skal gå mellem klassifikation i CCS og klassifikation vha. egenskabsdata. Denne afklaringsopgave ligger ret beset ikke i CCS kodningsregler. De konkrete klassifikationstabeller, der skal udvikles. Resultatet af cuneco-projektet Afklaring af struktur og metode for egenskabsdata. Den samlede vurdering af CCS skal naturligvis inddrage resultatet af yderligere cunecoprojekter, bl.a. Klassifikation af bebyggelser, bygninger og rum. Begrebsmodel for ressourcedomæne, samt heraf følgende projekt(er). Afsn side 22 Generel Vi mener, at grænsen mellem hvilke klassifikationsbehov, der dækkes vha. klassifikationskoden, og hvilke klassifikationsbehov, der dækkes vha. (yderligere) egenskabsdata er Vurdering af de enkelte dele af klassifikationskonceptet, og af det samlede koncept, bør omfatte Formidling Høring Afprøvning Debat i branchen Lav en god analyse af fordele og ulemper ved en klassifikationskode på meget højt niveau og tilsvarende omfattende brug af egenskabsdata til klassifikationsformål. Her er, 2

3 helt fundamental for alle klassifikationssystemer, også for CCS. Alle klassifikationssystemer har denne grænse. På et eller andet tidspunkt slipper mulighederne for klassifikation vha. klassifikationskoden op, og man må ty til (andre) egenskabsdata. Forskellige klassifikationssystemer placerer grænsen forskelligt. DBK2006 har mulighed for en ret detaljeret klassifikation af bygningsdele, og hvis ellers bygningsdelsklasserne er nyttige må man relativt sjældent ty til de øvrige bygningsdelsegenskaber for at klassificere. OmniClass har en endnu mere detaljeret klassifikation af bygningsdele vha. klassifikationskoden. Vi mener ikke, der er nogen naturlov, der siger, hvilket klassifikationsniveau (vha. klassifikationskoden), der er det rigtige. Der er fordele og ulemper ved både høje og lave niveauer. Vi har i næste kolonne søgt at skitsere nogle fordele og ulemper ved det meget høje niveau, som CCS kodningsregler anbefaler. Vi vil pege på et muligt designproblem i CCS kodningsregler. Fordi klassifikationskoden indgår i identifikatoren både i det simple produktaspekt (#) og det strukturelle produktaspekt (-), er CCS afhængig af, at klassifikationskoden er stabil. Ellers ændrer identifikatorerne sig, og det er i høj grad uønskeligt. HVIS nu det viser sig i cuneco-projektet Afklaring af klassifikationsniveau, at der er behov for en mere detaljeret klassifikation af hvad vi kan komme i tanke om: Fordele: Klassifikationskoden vil relativt høj sandsynlighed forblive konstant. Betyder f.eks., at objektforekomstens identifikator sjældent ændres, da klassifikationskoden indgår i identifikatoren (hvilket vi ikke er helt overbeviste om, er en god ide, se andet punkt). Klassifikationskoden kan gøres relativt enkel indenfor det enkelte aspekt. Koden kan indgå i dækningen af mange klassifikationsbehov (men ulempen er, at koden ofte ikke er nok). Mange varierede klassifikationsbehov kan dækkes vha. egenskabsdata. I princippet kan alle objektets egenskaber, bortset fra identifikatorer, bruges i klassifikation. Man får fleksibilitet og dynamik i klassifikationen. Relativt lille risiko for konflikt mellem konkrete egenskabsdata og klassifikationskode for det enkelte objekt. Ulemper: Det samlede klassifikationskoncept 1 skal inddrage i hvert fald de egenskaber, der hyppigst anvendes til klassifikation. Disse egenskaber skal standardiseres (egenskabsnavn, -definition, tilladte værdier, ). Den samlede klassifikation bliver mere komplekst at overskue, da man ofte vil skulle kombinere de to metoder, klassifikation og egenskaber. De IT-systemer, der skal oprette og vedligeholde de standardiserede egenskabsdata, skal have disse egenskaber ( felter ) tilføjet i database og på bru- 1 Her menes ikke at egenskaberne skal indgå i klassifikationskoden, men at man i dækningen af klassifikationsbehovet skal indtænke en række egenskabsdata. 3

4 bygningsdele, bliver koden (og der identifikatorerne) mere ustabil. Der kan blive behov for at gentænke dele af designet. gergrænseflade. Kan være et stort arbejde og kan kollidere egenskaber, der allerede findes for objektet (fordi der findes egenskaber, der allerede ligner, men ikke er helt som defineret i CCS). Kan være meget mere krævende, end at etablere en klassifikationskode (der måske allerede har et felt i systemet). Risiko for, at det kan afholde mange virksomheder fra at implementere andet end klassifikationskoden. Brugerne skal indtaste og opdatere de ekstra egenskabsdata (i heldigste fald, kan et tilsvarende antal eksisterende egenskaber fjernes). De IT-systemer, der skal anvende klassifikationskode og tilhørende klassifikationsegenskaber, skal tilpasse/udvikles. CCS følger en anden klassifikationsfilosofi end visse andre klassifikationsstandarder. OmniClass (og DBK2006) anvender generelt en mere detaljeret klassifikation. Uanset om dette klassifikationsniveau er hensigtsmæssigt eller ej, er det besværligt at mappe mellem to klassifikationssystemer så forskellige klassifikationsniveauer. (Retfærdigvis skal det nævnes, at det også kan være besværligt at mappe mellem to klassifikationssystemer meget detaljeret klassifikation nemlig hvis de detaljerede klasser er meget forskellige mellem de to standarder.) Det anbefales, at designet af CCS kodningsregler ikke lukkes, før klassifikation vha. egenskaber er designet og opgavens omfang for cuneco og branchens virksomheder er vurderet. 4

5 Generel Generel Generel Vi værdsætter, at der er lyttet til kritikken af DBK2006 og tidligere arbejdsversioner af CCS, og at CCS gennem sin større fleksibilitet imødekommer en række af de behov, der har været nævnt. De formulerede krav til CCS er omfattende, og løsningen er ambitiøs måske for ambitiøs. Der er reelt tale om flere delstandarder indenfor samme standard. DBK2006 er også kompleks, når man tager flere/alle aspekter i anvendelse, men her har produktaspektet en dominerende stilling. Alle skal anvende dette, mens de øvrige aspekter er frivillige. Sådan er det ikke i CCS, så vidt vi har forstået: Her er alle aspekter frivillige, men man skal selvfølgelig anvende mindst ét aspekt. Prisen er en standard, der samlet set er mere kompleks. Det er rigtigt, at man gennem anvendelse af et/få aspekter kan forsimple sin anvendelse af standarden væsentligt i forhold til DB2006. Men virksomheden/byggeprojektet skal igennem en ikke helt enkel proces for at forstå standarden og for at udvælge de dele, der skal tages i anvendelse. Tilsvarende har den IT-producent, der i sit standardsystem vil implementere hele eller store dele af CCS, en stor opgave. Der er en reel risiko for, at standardens udbredelse og IT-implementering hæmmes pga. kompleksiteten. Med den store fleksibilitet i anvendelsen af CCS følger, at to parter, virksomheder, projekter, der begge anvender CCS, ikke nødvendigvis kan kommunikere effektivt hinanden. Bliv ved at lytte. Pas på ambitiøsiteten. Er der en regel, der siger, at alle aspekter er frivillige, men at mindst ét aspekt skal anvendes? Hvis ikke (og hvis dette i øvrigt er korrekt), bør man tilføje sådan en regel. Måske er det ikke så simpelt. Kan man f.eks. anvende placeringsaspektet uden at anvende det strukturelle produktaspekt (eller måske det simple produktaspekt)? Vi peger på nogle få forenklinger i de følgende. Men grundlæggende følger kompleksiteten og omfanget af krav, ambitionsniveau og overordnet filosofi for CCS. Hvis man holder fast i dette, er indsatsen primært af pædagogisk og hjælpende art: Let forståelig dokumentation CCS for Dummies afprøv både standarden og dokumentationen Vejledninger f.eks. i hvordan man udvælger de dele af CCS, man vil anvende. Kurser, støtte Gennemskuelig og pålidelig understøttelse i standard IT-systemer Vi har ikke nogen gode løsningsforslag. En mulig, men skræmmende, løsning er, at man for det enkelte byggeprojekt beslutter, hvordan CCS skal anvendes. At der indgås en 5

6 Eks.1: En installationsingeniør, der kun anvender det strukturelle produktaspekt, kan f.eks. ikke kommunikere sine identifikatorer for bygningsdele til en entreprenør, der kun anvender det simple produktaspekt. projektspecifik CCS-aftale (analog en IKT-aftale). Det stiller store krav til den enkelte parts omstillingsevne, og kan føre til at han stort set skal mestre hele standarden. Vi hører meget gerne om bedre løsninger. Eks. 2: En arkitekt placerer døren direkte i vægsystemet, men konstruktionsingeniøren placer den i vægkonstruktionen, der er placeret i vægsystemet. En udfordring, hvis de samarbejder i samme byggeprojekt. Afsn. 6 side 17 Parterne kommunikerer heller ikke nødvendigvis deres bygningsdelsklasser og rumklasser særlig effektivt hinanden. Generelt/teknisk Der står CCS koder to grundlæggende objekter: bygningsdele og rum. Bør der ikke stå: CCS koder tre grundlæggende objekter: systemer, bygningsdele og rum., og lade afsnittet dække de tre objekter? Afsn side 23. Afsn side Generelt Der står: NOTE: Det skal bemærkes at der i klassifikationsaspektet er mulighed for at lave en projektspecifik underklassifikation af CCSklassifikationen, og at disse underklasser fx kan opbygges af tal. Skal underklassen ikke opbygges af tal? Vedr. funktionsaspektet: Man skal tilsyneladende bruge det strukturelle produktaspekt både for den objektforekomst (system eller bygningsdel), man vil tildele funktionel klassifikation, og den objektforekomst i bygningens funktionsstruktur, man vil tilknytte. Det virker ulogisk og begrænsende. Hvis det er vigtigt at kunne Hvis det er forstået rigtigt, er der vist mange steder, hvor systemer skulle være nævnt sammen bygningsdele og rum. Hvis svaret på spørgsmålet er ja, rettes til og at disse underklasser skal opbygges af tal. Der er et (måske mindre betydningsfuldt) brud på logikken her. I de andre aspekter anvendes tal til at angive løbenumre. Vi er på, at den foreslåede syntaks i rapporten ikke kan klare dette, fordi aspekttegnet = her får to betydninger. Men hvis det er vigtigt, må man udvikle syntaksregler, der dækker behovet. 6

7 Afsn side 38 /39 Afsn side 45 Afsn side 45 angive funktion for systemer/bygningsdele, er det vel lige vigtigt, uanset om man anvender simpel identifikation eller kompositionel identifikation. Man kan tilsyneladende ikke skrive: #JB52 / =JB7 : Dør nr. 52 har funktionskrav som specificeret for funktionel dør nr. 7. Generelt/teknisk Vedr. placeringsaspektet: Man skal tilsyneladende bruge det strukturelle produktaspekt både for den objektforekomst (system eller bygningsdel), man vil placere, og den objektforekomst, man vil placere i. Det virker ulogisk og begrænsende. Hvis det er vigtigt at kunne angive placering, er det vel lige vigtigt, uanset om man anvender simpel identifikation eller kompositionel identifikation. Man kan tilsyneladende ikke skrive: #SFA47 / +LUD65 : Afbryder nr. 47 placeret i plade nr. 65 Generel Her introduceres objekttyperne Bebyggelse, Bygning og Etage uden videre. Læseren er ikke velforberedt. Det virker som nogle sidste-øjebliks-tanker. Redaktionel Skal det angivne aspekttegn efter sætningen Syntaksen for aspektkoden ser derfor således ud ikke være - (i stedet for = ). Man bemærker, at identifikation af bygninger sker uden brug klassekode sammenstillet løbenr. Vi er på, at den foreslåede syntaks i rapporten ikke kan klare dette, fordi aspekttegnet + her får to betydninger. Men hvis det er vigtigt, må man udvikle syntaksregler, der dækker behovet. Forbered, beskriv, definer disse objekttyper på lige fod de øvrige, der behandles i rapporten <- Se Generel/teknisk Hvordan bør man vurdere CCS IT-egnethed? Det er glædeligt, at en række kompetente ITleverandører har været involveret i udviklingen og kommenteringen af CCS, og at de siger CCS kan implementeres i vores ITsystemer. IT-egnetheden må ikke kun vurderes af en begrænset skare af ressourcestærke, kompetente producenter af standard IT-systemer. Repræsentanter fra de øvrige grupper af ITfolk, og fra IT-brugerne, skal også komme deres vurdering og denne skal indgå i 7

8 Det er en nødvendig, men langt fra tilstrækkelig forudsætning, at kompetente og ressourcestærke IT-producenter siger god for standarden. den samlede bedømmelse af CCS ITegnethed. Langt størstedelen af de IT-folk, til at arbejde CCS, kommer imidlertid fra interne IT-afdelinger i byggebranchens virksomheder. IT-afdelingerne kan være store, men ofte består afdelingen af nogle få arbejdere måske kun en enkelt som har få ressourcer til at lære og til at implementere CCS i virksomhedens IT-systemer. Dertil kommer, at størstedelen af ITunderstøttelsen af CCS kommer til at ske i andre systemtyper end de store standard- CAD/BIM-systemer god udbredelse på det danske marked. Det drejer sig om: Kalkulationssystemer, sagsstyringssystemer, økonomisystemer/kontoplaner, data warehouse-systemer, rumprogram-databaser, planlægningssystemer osv. En stor del af systemerne vil være standardsystemer ringe udbredelse på det danske marked (dvs. producentens indtægtsgrundlag til at dække omkostninger til CCSunderstøttelse er meget begrænset). Endnu en stor del af systemerne vil være systemer, udviklet af virksomhedernes interne IT-afdelinger, deres ofte begrænsede ressourcer og typisk store backlog af (ndre) ændringskrav fra brugerne. Endelig kommer CCS-koder til at optræde i office-programmer som Excel og Word. Brugerne af office-programmerne er os selv, 8

9 Generel/teknisk den begrænsede indsigt i teknisk IT, som de fleste af os har. CCS skal være særdeles IT-egnet, hvis standarden skal udbredes i branchens ITsystemer, jf. foregående punkt. Efter vores mening er det ikke let at bruge CCS i IT-systemerne. CCS-koden er meget fleksibelt opbygget. Det fører til en høj grad af positionsløshed. Antallet af bogstaver på hvert niveau kan variere. Antallet af cifre i underklasser og løbenumre kan variere. Foranstillede nuller er ikke et krav. Antallet af niveauer i referencestrukturen kan variere (fordi man ikke behøver at tage mellemliggende niveauer). Det fører til banale, men store praktiske problemer at sortere, filtrere, søge Desuden bliver fortolkningen af CCS-koden i applikationssystemerne vanskeligere. Dertil kommer, at inddragelse af egenskaber i det samlede klassifikationskoncept kan føre til omfattende systemændringer, jf. tidligere. En løsning kan være, at den enkelte virksomhed definerer sin egen husstandard for, hvordan CCS-koden skal bygges op. Men det holder sandsynligvis kun til det øjeblik, man er nødt til at kommunikere sine CCS-koder andre virksomheder ( andre husstandarder for CCS). Her er et eksempel på en mere håndfast løsning: Der skal altid være det samme antal bogstaver på et givet niveau (inklusiv typer). Nedenfor forudsættes tre tegn. Eksempel: Vægsystem klassificeres som MB_ MB for vægsystem og _ (underscore) for ingen speciel type vægsystem, og MBA MB for vægsystem og for ydervæg osv. Dette i stedet for MB for vægsystem uden nogen speciel type. Hvis man har tænkt at opretholde to niveauer af typer gælder det naturligvis, at der også skal afsættes fast plads til dette og der være fire tegn på hvert niveau Man kan forestille sig, at IT-opgaven forenkles ved at IT-producenter (og cuneco/bips) udvikler forskellige tekniske hjælpemidler, som stilles til rådighed for branchen. F.eks. en generel fortolker af CCS-kodestrengen. Denne kunne leveres som plug-in til forskellige, udbredte programmer, f.eks. officeprogrammer. Det kan hjælpe, men vil ikke fjerne problemet. 9

10 Generel/teknisk Implementering af CCS i et standard ITsystemer kan ske på mange måder. Man kan ikke, når man hører, at et bestemt IT-system understøtter CCS, vide, hvordan CCS er understøttet. Der er behov for, at forskellige typer af ITsystemer implementerer CCS fornøden og gennemskuelig kvalitet og ensartethed. Der er desuden behov for, at der for et konkret IT-system præcist, ensartet og enkelt beskrives, hvilke dele af CSS, der er implementeret i systemet. Der bør udvikles et sæt entydige retningslinjer for, hvordan CCS skal implementeres i ITsystemer, herunder hvilke dele, der skal implementeres og hvilke dele, der er frivillige. Herudover er der behov for, at en kompetent og uvildig instans overvåger og kontrollerer CCS-implementeringen i branchens standard IT-systemer. Der skal efter godkendelse udstedes et certifikat for den konkrete version af IT-systemet, der dokumenterer, at CCS er implementeret korrekt, samt hvilke dele af CCS, der er implementeret. Ved nye versioner af IT-systemet skal certifikatet fornyes. (Dette behov findes også for DBK2006, men det er større CCS pga. den større fleksibilitet i standarden.) Identifikatorer for objektforekomster skal ubetinget kunne holdes uforanderlige. Identifikatorerne i både det simple (#) og det strukturelle (-) produktaspekt er afhængig af objektforekomstens klassekode. I det strukturelle produktaspekt er identifikatoren desuden afhængig af identifikatoren (klasse + løbenr.) for de overliggende objektforekomster i kompositionsstrukturen. Denne instans kan desuden yde bistand til virksomheder egenudviklede ITsystemer. Udform et identifikatorbegreb, der er uafhængigt af andre egenskaber for objektforekomsten eller for andre objektforekomster. Man behøver ikke kaste sig ud i GUIDidentifiers for at opnå dette. Det simple produktaspekt kunne f.eks. blot tildeles en 6- tegns kode. Det giver et antal mulige identifikatorværdier på mindst Eller 1 mio, hvis man kun vil anvende cifre. Det fører uvægerligt til at identifikatoren ikke sikkerhed kan holdes konstant. Det fører også til krav om klassen ikke må ændres for en objektforekomst, og det heraf afledte krav, at CCS skal klassificere på et relativt højt niveau. Begge dele uheldige, som nævnt ovf. 10

11 Afsn. 10, s. 54 og frem Vi forstår godt baggrunden, men det virker ikke logisk og hensigtsmæssigt, at en objektforekomst kan have to identifikatorer (i det simple og det strukturelle). Hvorfor er der flere identifikatorer i standarden? Vi er meget skeptiske overfor rapportens input til selve kodningsarbejdet. Her anbefales, at man benytter bogstaverne og klassifikationen fra ISO/IEC 81346, og at man så lægger de dele som denne standard ikke dækker (dvs. de konstruktive bygningsdele) ind på de ledige bogstaber (vist kun 3 bogstaver). Dette mener vi er uacceptabelt: Vi kan ikke styre hvad der sker ISO/IEC standarden. Den kan på et senere tidspunkt vælge at lave væsentlige ændringer eller at tage de ledige bogstaver i brug til noget andet end det CCS på eget initiativ bruger dem til. Vi mener at det vil give en meget skæv klassifikation hvor man på det øverste niveau bruger mange bogstaver på at dække installationer og kun ganske få til de øvrige områder. Der er ikke noget logisk/teknisk i vejen for det, men det kan være forkert behovsmæssigt og vil i hvert fald være uheldigt formidlingsmæssigt. Ikke der sagt at man ikke kan bruge hele eller dele af ISO/IEC klassifikationen i CCS, men det skal i givet fald være i en indkapslet del, hvor CCS har kontrollen og sætter rammerne, ikke omvendt. Se Foreslåede ændring. Kan standarden nøjes identifikation i #- aspektet? Vi kan godt se, dette vil føre til et tab, hvis man vil have CCS-koden til at angive bygningsdelsforekomstens (rumforekomstens) kompositionelle placering indenfor overliggende forekomst(er). Der bør udvikles en generel mekanisme, der tillader andre standarder at blive adopteret i værtsstandarden CCS. Den freme standard skal på en eller anden generel måde indkapsles (måske et præfix?), så dens koder ikke clasher eller begrænser kodeanvendelse i værtsstandarden, CCS, eller i andre standarder, som værtsstandarden har adopteret. IEC skal have lov til at anvende sine koder. Men det skal klassifikationen af konstruktive og andre ikkemekaniske/elektriske systemer/bygningsdele også. Denne adoptionsmekanisme skal være generel. Dvs. den skal ikke kun gælde systemer, bygningsdele og rum, men alle objekttyper, som CCS i fremtiden kommer til at dække, f.eks. også objekttyper indenfor ressourcedomænet. Det bliver måske ikke (forhåbentlig ikke) sidste gang, CCS bliver vært for andre standarder. Hvad f.eks. Standard(er) for anlæg Standard(er) for byggevarer (ressourcedomænet). Vi har tidligere anbefalet, at man her kigger på de etablerede standarder, frem for at udvikle selv (stort arbejde, stor risiko for at byggevareproducenterne ikke vil følge). 11

12 Generel Ovenstående fører til det generelle krav -> Klassifikationsstandardens grunddesign skal være af en sådan karakter, at der i fremtiden ikke lægges væsentlige begrænsninger på udvidelsesmuligheder. Standarden skal være langtidsholdbar, og vi kender ikke fremtidens behov. Generel/teknisk Generel Generelt Vi har behov for mapning fra DBKbygningsdelskoder (i produktaspektet) til CCS-koder (i det strukturelle produktaspekt). Vi har behov for, at information ikke går tabt i denne mapning. I det omfang, CCS-koderne er mere generelle end DBK-koderne skal overskudsinformation i DBK-koden tydeliggøres i et passende sæt egenskabsdata. Vi har behov for at mappingtabeller er klar samtidig frigivelse af denne del af CCS. Vi er bekymrede for, at al størstedelen af udviklingskraft endnu en gang går i klassifikation af bygningsdele. Hvad objekter/begreber i ressourcedomænet som først lige er ved at blive analyseret. NCC, og andre virksomheder indenfor anlæg, har et behov for en veludviklet klassifikation indenfor anlægsområdet. Det gælder både Objekttyper indenfor resultatdomæne DBK2006 har nogle ganske få anlægstyper indenfor bygningsdele og rum, men de er langt fra dækkende. Objekttyper indenfor ressourcedomænet, specielt entrepriser rettet mod an- Der skal være mulighed for at udvide klassifikationen både i bredden (nye objekttyper, nye klasser indenfor kendte objekttyper) og i dybden (underklasser til underklasser til ). Opprioriter det cuneco-projekt, der skal afdække behov indenfor ressourcedomænet. Der er en reel risiko for, at der endnu en gang hverken bliver tid eller ressourcer nok til at gøre noget særligt indenfor dette område. Cunecos deadline ligger kun godt 2 år ude i fremtiden. I første omgang skal kodningsreglerne for systemer, bygningsdele og rum (egentlig de tilsvarende hovedobjekttyper indenfor anlæg) udformes, så de tilgodeser behovene indenfor anlægsområdet. Herudover vil vi opfordre til, at der igangsættes projekter til udvikling af objekttyper, klassifikationsdybde, klassetabeller, egenskabsdefinitioner osv. indenfor anlæg. Som nævnt både i resultat- og ressourcedomænet. 12

13 Afsn. 9, side 48 Teknisk læg. I trin 5 står Da det er relevant at vide hvilken vægkonstruktion i vægsystemet døren skal monteres i, tildeles dørens objektforekomst en reference for placeringen i konstruktionsrummet: -MB3.JB2 / +MB3.DF3 Koden læses: Dør nr. 2 i Vægsystem nr. 3 placeret i Vægkonstrukti-on nr. 3 i Vægsystem nr. 3 Kan man ikke bare sige, at døren indgår i vægkonstruktion nr. 3, dvs. nøjes -MB3.DF3.JB2? Når den kompositionelle struktur er den samme som den placeringsmæssige, er den placeringsmæssige vel overflødig? 13 Bilag A side 67 Hvorfor er der behov for denne kodning i placeringsaspektet? Teknisk Citat: Det er forhåbentlig ikke korrekt. Objekt (byggeobjekt) En fysisk bestanddel eller tænkt fysisk bestanddel CCS skal også beskæftige sig ikke fysiske - af en bygning alle dens ibo- objekter. Eksempler: ende egenskaber, relationer til omkringliggende Faser/processer/aktiviteter byggeobjekter samt øvrig relateret Roller information. Entrepriser (der nok rummer fysiske objekter, men ikke selv kan karakteriseres som et sådant) Generel Afprøvning er vigtig. I Gødstrup bør man sikre sig, at alle aspekter bliver afprøvet, både indenfor bygningsdele og rum. Man bør ligeledes afprøve et stort udvalg af klasser både i bredden og dybden. Generelt De dele af CCS, fra IEC/ISO Vi kender ikke IEC-standarden (mekaniske og elektriske systemer/bygningsdele) skal være af nogenlunde Er det tilfældet? samme natur som de dele der er udviklet for konstruktive bygningsdele, f.eks. mht. aspekter, klassifikationsniveau, detaljeringsgrad i bygningsdele, Teknisk Bilag B: Vi værdsætter beskrivelsen af CCS i metasprog. Vi har ikke forstand på EBNF, men det ser ud som om beskrivelsen ikke er færdigudviklet. Beskrivelsen af kodesyntaksen (ikke kun for bygningsdels- og rumkoder) skal være en fuldgyldig del af standarden. Få en metasprog-ekspert til at udarbejde specifikationen, hvis cuneco ikke råder over en sådan. Lyt til eksperten, hvis han påpeger manglende logik, tvetydigheder osv. så er det formentlig fordi der er problemer, strukturen, som bør løses. 13

14 Generel Hvad er strategien forvaltningsklassifikation. Skal der udvikles mapping mellem CCS og den udviklede Forvaltningsklassifikationsstandard? Skal den udviklede Forvaltningsklassifikationsstandard adopteres i CCS (analogt IEC/ISO , hvis det kan lade sig gøre)? Eller skal der udvikles ny forvaltningsklassifikation i CCS? Generel/Teknisk Lokale udvidelsesmuligheder Teknisk Teknisk Teknisk Vi har problemer at forstå begrebet klassifikationstema. Vi forstår ikke begrebet funktionsstruktur og der heller ikke funktionsaspektet. De IT-producenter, der har deltaget i vurdering af IT-egnetheden, er primært producenter, der ETABLERER klassifikationskoder. Der er tilsyneladende ikke nogen, der læser og fortolker CCS-koder, som er etableret af freme systemer Man bør kunne tilføje virksomhedsspecifikke eller projektspecifikke klasser for bygningsdele (og måske også rum), ikke kun underklasser til eksisterende CCS-klasser. Der bør udvikles en generel mekanisme for tilpasning af CCS til virksomheden eller projektet? Kunne man definere begrebet, og eksplicit angive de klassifikationstemaer, der konkret anvendes rundt omkring? I det omfang, det ikke allerede er sådan. Kunne man definere funktionsstruktur og gerne uddybe forklaring og eksempel på en sådan struktur. Inddrag også IT-producenter, der kan vurdere om CSS koden kan fortolkes. Fortolkning kan være en mere kompleks opgave end etablering af koden. Særlig i et system, der er så fleksibelt i sin kodeopbygning som CCS. Ved kode generering (afsender), kan man lave sin egen standard inden for standarden. Det kan man ikke, når man fortolker (modtager). Her skal man kunne håndtere alle de mulige kombinationer, som standarden tillader. 14

15 Generel/Redaktionel Vi synes generelt, at terminologien omkring klassifikationsaspektet og det simple produktaspekt antyder, at de to aspekter er lidt inferiøre. Brug en ligeværdig terminologi. (Tilsvarende de to punkter ovf. Der omhandler, at det simple produktaspekt vist ikke kan anvende i placeringsaspektet og funktionsaspektet.) 15