Objekt-orienterte Produktmodeller i Byggenæringen Av Eirik Kalstveit

Oppgaveteksten Innledning Digital Produktmodellering Utvikling av konseptuell modell Forstå produktet Forstå produktutviklings-prosessen Forstå produksjonsprosessen

Oppgaveteksten Innledning Digital Produktmodellering Implementering i et datamaskinverktøy Velge et høvelig verktøy Omsette konseptuell modell til et ”kjørbart” program i en datamaskin

Oppgaveteksten Innledning Internasjonale prosjekter Standard for the Exchange of Product Model Data, ISO 10303 ISO/STEP (International Standardization Organisation) Felles informasjonsmodeller for petroleumsindustrien POSC/CAESAR (Petrotechnical Open Software Corporation)

Oppgavebesvarelsen Tilgjengelig på internett etter 15. desember http://www.selvaag.no/diplom97.htm Inneholder Presentasjon av litteratur/web-studium Modell av enebolig Produkt/prosess-modell (eventuelt)

Informasjonsutveksling Overføring av data er en tilnærming System A System B NURBS Circle Polyline Neutral format System A og B er bygget på forskjellig logikk, noe som gjør at dataoverføringen er lik, men logikken som tolker dataene avviker Ulike konsepter fører til uønskede avvik

Hva er et produkt Fysisk eller abstrakt objekt, med en kompleksitet som gjør det nødvendig med en eksakt definisjon, planlegging og koordinasjon for å realisere objektet Typisk produkt: Bygninger, skip, biler, industrianlegg Kan være enestående (Oljeplattform), eller masseprodusert (PC’er)

Hva er en modell? Et diagram er ikke en modell, men en representasjon av modellen. En modell kan brukes av en ”modellmaskin” (F eks en PC) En modell forenkler virkeligheten for å få frem ”kjernen” i det som skal produseres. ”A model is a structure that a system can use to simulate or anticipate the behavior of something else” -Marvin Minsky

Eksempel: Ventil PCV0321 Eksempel på gjenbruk (flerbruk) av data. Utstyrs data-ark Ventil PCV0321 3D DAK Hentet fra POSC/CAESAR prosjektet

Hvorfor produktmodell? Automatisere boligbygging Fokus flyttes til kunnskapstilegning Utveksling og deling av informasjon blir en viktig del av prosessen.

Hvorfor produktmodell? Effektiv bruk av IT forutsetter omorganisering av arbeidsprosesser Kommunisere på nye måter Informasjon blir delt mellom aktører Standardiseringer av konsepter for å unngå feiltolkinger og kommunikasjonssvikt i byggeprosessen.

Hensikt med en produktmodell Kommunikasjon mellom involverte parter. (Gjensidig forståelse og idéutveksling?) Informasjon utveksles og deles Redusere kompleksiteten til et produkt. ”Everything should be made as simple as possible, but not simpler” -Einstein

”Livshjulet” for et produkt Midtsirkelen og kanalene i figuren representerer produktmodellen og innfører en ny måte å organisere byggeprosessen på, der det ikke lenger er en bestemt rekkefølge på når ”ting” skjer Gjennom konseptuelt design blir hovedtrekk diskutert, og prinsipielle avgjørelser tatt. Detaljert design baseres på produktdefinisjonen, og innebærer spesifiseringer av løsninger. Her betraktes produktet som en enhet, de ulike valgte løsninger gir erfaringer og kunnskap Her blir produktet realisert, fra bunn til topp (bottom-up) fra detaljert til overordnet nivå

Objekt-orientert tilnærming ”Naturlig” å dele inn ”verden” i objekter Fokus på dataoppbygging (struktur) for funksjon Objekter har visse egenskaper og virkemåter ”Samarbeider” med andre objekter. Kommuniserer med andre objekter Stabil base for utviklingsprosessen Objekter er beskyttet mot uønskede forandringer Definerer problemorienterte objekter tidlig Utvider disse objektene gjennom prosessen Sømløs siden notasjonen er lik hele tiden Hver iterasjon klargjør egenskaper i stedet for å modifisere arbeid som allerede er gjort ”Sømløs” utviklingsprosess Utviklingsprosessen er iterativ (prøv og feil)

Nordre Nes Enebolig nr 7 Konseptuell beskrivelse med notasjon etter Rumbaugh’s Object Modeling Technique

Hva er en enebolig? Vegger, vinduer, dører og pipe etc etc En plass å oppholde seg Tegninger Mye arbeid!!!??? Kostnader

Hvordan modellere en enebolig KOSTNADSOVERSLAG

Hovedfaser i modellen DESIGN REALISERING (Beskrivelse) Design er en prosess som tilfører kunnskap fra et overordnet nivå, ned til en spesifikk forekomst DESIGN (Beskrivelse) REALISERING (Slik det blir gjort) Realiseringen gir erfaringer tilbake til generisk nivå På generisk nivå finnes ”generell” kunnskap, det kan være prinsipper, metoder og teorier... GENERISK SPESIFIKK FOREKOMST En KATEGORI av konstruksjoner, f. eks boliger En TYPE av konstruksjoner, f. eks enebolig type Nordre Nes En spesiell FOREKOMST av typen, f. eks Nordre Nes hus nr 7 ERFARING KUNNSKAP

Design vs Realisering Design-nivå beskriver løsninger Mest arbeid på realiseringsnivå Komponentbiblioteket Standard løsninger Varekataloger (Fra leverandører)

Økende detaljomfang Objekter må være i stand til å ta vare på økende detaljomfang etter hvert som designfasen skrider frem. Skisse Plan Detalj (Fra A Ekholm: ”A conceptual framework for classification of construction work”)

Klassifisering av objekter Objekter med en bestemt egenskap kan hentes fra en database, etter klassifisering Slik kan tradisjonelle bygningsklasser, men også f eks lyd-isolasjon og brann-motstand, organiseres Objekter må kunne ha varierende funksjons- og komponent-egenskaper. (Fra A Ekholm: ”A conceptual framework for classification of construction work”)

”Ting” kan være både objekt og relasjon Forbindelse er et objekt som realiseres ved en standard løsning, men er også en relasjon mellom Vegg1 og Vegg2

”Ting” kan være både objekt og relasjon Et rom er en relasjon mellom gulv, vegg og tak samtidig som det er et eget objekt med plassering og betegnelse TV-stue

Kommentar/beskrivelse av objekt Alle objekter bør referere til (eie) en kommentar som beskriver formål, funksjon og evt andre spesifikke ting. Kommentar er et eget objekt. Nyttig for å oppnå forståelse og entydighet Bør kunne tilordnes flere verdier

En attributt bør kunne ha flere verdier Verdi tilordnes/settes etter hvor man befinner seg i design-/prosjektfasen

Eksempel: Kostnad Kostnader er usikre i planleggingsfasen, da bruker man planlagt og forventet kostnad som verdi. Egentlig kostnad får man først når bygget er ferdig bygget og regnskapet er sluttført. Erfart kostnad gir da erfaringer tilbake til designfasen.

Informasjon på ulike nivåer 4 ”abstraheringsnivåer” Informasjon kan realiseres fra ulike nivåer (Hentes i strukturen) Alle subklasser kan ”arve” fra generisk ”superklasse”

Eksempel: Boareal Boareal kan hentes fra totalt boareal som kan være f. eks 170 m2. Design-nivå. Boareal kan også kalkuleres vha alle roms areal. Verdien blir da hentet nedenfra i strukturen og fastsatt etter valgte løsninger. Verdien kan da være f. eks 168 m2.

Relasjoner Antall relasjoner mellom objekter i et system er stort Oppstår som følge av: Fysisk sammenkobling Geometrisk oppbygging (rom) Hierarkisk posisjon

Ulike relasjoner består av er en slags forbinder dekomponering beskriver arv/slektskap forbinder relasjoner mellom objekter

Ulike relasjoner realiseres ved leveres av et designobjekt realiseres ved valgt løsning fra komponentbiblioteket leveres av relasjon mellom produkt og leverandør

Geometri/utforming Kan med fordel beskrives ved egen objekt-klasse, kalt f. eks RefGeometri Unngår problemer med kalkulasjoner fra f. eks transformasjonsmatriser som kan gi store numeriske operasjoner.* Mindre risiko for feil, mer effektiv konsistenskontroll.* (*Kilde: Dale, S I: Object-oriented Product Modeling for Structural Design)

Referansegeometri To måter å representere oppbygning på: Geometrisk Topologisk Geometri beskriver form og plassering i rommet til en figur. Topologi er ”limet” som binder sammen geometrisk informasjon om punkt, linjer, flater og skall.

Geometrisk Er lagret i modellen som figurer, linjer etc. En linje beskrives ved hjelp av en funksjon, f. eks: y = 1 + x Kan ta unødvendig mye plass, da geometriske data er permanent lagret.

Topologisk Beskriver sammenheng mellom punkt, linjer og flater. En linje, L1, beskrives som sammenkoblingen mellom 2 punkt p1 og p2 Fordelen med topologisk representasjon av geometri er at informasjonen kan genereres når man trenger det, og man unngår feiltolking av informasjon om tilstøtende objekter.

Hvordan behandle geometri? Man bør bestemme seg for en måte å representere ting på. Man bør bestemme hvilken geometri systemet kan behandle. Det vil i alle tilfeller ligge mye arbeid i å utarbeide og implementere en fornuftig og brukende geometri-beskrivelse.

Beskrivelse av hvordan ”ting” bør gjøres Design-nivå Beskrivelse av hvordan ”ting” bør gjøres

Felles attributter og beskrivelser Attributter for alle objekter: Symbol (F eks ikon) Kostnad (På forskjellig nivå) Byggetid (Erfaringsmessig)

Design-nivå Setter krav til og beskriver løsninger ”Top-down”-design Byggeforskrifter oppfylles Standarder Andre ”Top-down”-design Dekomponering av enebolig, man definerer hva en enebolig består av og grupperer de ulike delene etter ting som er felles

Design-nivå Objekter på design-nivå har attributter som avhenger av andre attributter: Et rom er ikke et fysisk objekt, attributter finnes vha relasjonene mellom gulv, vegg og tak Kostnad på design-nivå består av alle komponenters kostnader.

Enebolig + MANGE FLERE + MANGE FLERE FASADE ETASJE- SKILLER ALTAN BYGNINGS SKJELETT VEGG ETASJE VINDU DØR TAK + MANGE FLERE + MANGE FLERE VEGG PIPE FUNDAMENT

Enebolig Fasade Bygningsskjelett Som oftest sammenhengende over flere etasjer. ”Dekorativ” del av en enebolig Bygningsskjelett Beskriver oppbygning og tekniske løsninger ut fra forskrifter og standarder

Enebolig, dekomponering

Fasade Fasade er et ”dekke” som beskytter bygningsskjelettet mot vær og vind. Inneholder åpninger til vinduer, dører og ventiler. (Slf også til strøm, tlf o.a.) Oppbygd av kledning, utlekting og forhudningspapp

Bygningsskjelett Trapp Etasje Forbindelse Griper inn i 2 eller flere etasjer. Trappeåpning beskrives spesielt Etasje Oversikt over rom og plassering av vegger, vinduer og dører. Forbindelse Realiseringen av forbindelsen er et eget objekt, men forbindelsen er også en relasjon.

Bygningsskjelett Pipe Tak Altan Fundament Går gjennom alle etasjer og tak Tak Har en viss skråvinkel og kan være flere typer Altan ”Hektet” på en etasje Fundament Husets plassering i et boligfelt

Bygningsskjelett

Etasje Etasje har objekter som hentes fra komponent-biblioteket.

Trapp Muliggjør adkomst fra en etasje til en annen Har en relasjon til en etasjeskiller ved en forbindelse. Relasjonen beskriver bl a plassering i etasje. Kjøpes som regel fra leverandør som en del, eller i flere små deler som settes sammen på byggeplass

Forbindelse Beskriver alle forbindelser mellom objekter Har en standard utførelse og hentes fra komponentbibliotek. Realiseres som et objekt, men er også en relasjon mellom objekter

Rom Relasjon mellom vegg, gulv og tak Har plassering og betegnelse

Pipe Går gjennom etasjer og tak. Som regel spesialutførelse på fundament Kan kjøpes eller lages selv. Ved kjøp er det også relasjoner til leverandør og objektet hentes fra varekatalog

Tak Takdekke velges spesielt (Panne, skifer, shingel etc) (...og leveres av leverandør?) Kan være flere typer, men Nordre Nes nr 7 har skråtak. Kan ha et takark. (Nordre Nes nr 7 har)

Takark Spesiell utførelse: Består av knevegg, skråvegg, vindu og tak

Altan Forbindelse til etasje Består av søyle, drager, rekkverk og dekke

Fundament Forbinder boligen med boligfeltet Har standard utførelse og beskrivelse kan hentes fra komponentbibliotek

Hvordan ”ting” gjøres Utvikling av komponentbibliotek Realiserings-nivå Hvordan ”ting” gjøres Utvikling av komponentbibliotek

Realiserings-nivå 2 ”hovedgrupper” Komponenter som kjøpes Har en leverandør Hentes fra leverandørkatalog Komponenter som lages på byggeplass En stor innsats vil ligge i å utforme komponentbiblioteket...

Realiserings-nivå Komponentbibliotek Kjøp Selvaag Leveres fra leverandør Velges fra varekatalog Pris og leveringstid avhenger av leverandør Selvaag Lages selv Pris og leveringstid bygger på erfaringer. Detaljer, forbindelser Selvaag-prinsipper og standarder

Komponenter Komponenter fra biblioteket kan enten monteres på byggeplass, eller produseres. De som monteres har da en relasjon til en leverandør.

Detaljer og forbindelser De ulike verdier blir attributter til objektene Hentes fra bibliotek

Detaljer og forbindelser De ulike verdier blir attributter til objektene Hentes fra bibliotek

Attributter på realiserings-nivå Faktiske verdier på ”virkelige” objekter Pris fra leverandør Byggetid på byggeplass Leveringstid fra leverandør Antall m2 kledning på fasaden

Produkt-prosessmodell Arbeidsprosesser som utvikler modellen

Aktiviteter Hus- Tomtekjøp utvikling Hovedaktiviteter Produksjon Hovedgrep

THE END THE END