Tre nye regelverk (JV) innen informasjonsteknologi er godkjent og trer i kraft 1. mars. Dette ble kunngjort av Alexander Stepanov, nestleder for avdelingen for byplanlegging og arkitektur i departementet for bygg og bolig og kommunale tjenester i Den russiske føderasjonen, innenfor rammen av seminaret "Informasjonsmodellering. Digitalt miljø som grunnlag for samhandling ”, organisert av Federal Center for rasjonering, standardisering og teknisk samsvarsvurdering i konstruksjon, underlagt det russiske byggedepartementet, sammen med RSPP-komiteen for teknisk regulering, standardisering og samsvarsvurdering. Arrangementet ble holdt 21. februar med deltagelse av et representativt team av eksperter.

JV “Informasjonsmodellering i konstruksjon. Regler for å beskrive komponentene i informasjonsmodellen "," Informasjonsmodellering i konstruksjon. Reglene for dannelse av en informasjonsmodell av objekter i ulike stadier av livssyklusen "og" Informasjonsmodellering i konstruksjon. Reglene for utveksling mellom informasjonsmodeller av objekter og modeller brukt i programvaresystemer "trer i kraft 1. mars, 2018.

I følge Alexander Stepanov inkluderer systemet med nasjonale dokumenter som opprettes innen ii konstruksjon grunnleggende standarder og praksiskoder som gir digital infrastruktur, inkludert de som definerer de grunnleggende bestemmelsene, prinsippene og terminologien til BIM, samt standarder og retningslinjer for praksis som definerer det konseptuelle rammeverket og en metodikk for å introdusere informasjonsmodellering i praksis på visse stadier av livssyklusen – fra rettferdiggjøring av investeringer til utnyttelse og riving av bygninger og konstruksjoner.

I 2018 startet utviklingen av grunnleggende standarder som definerer de grunnleggende prinsippene, konseptene og terminologien til BIM: GOST R “Organisering av informasjon om byggearbeid. Informasjonshåndtering ved hjelp av informasjonsmodellering. Del 1. Grunnleggende prinsipper og konsepter "og GOST R" Organisering av informasjon om byggearbeid. Informasjonshåndtering ved hjelp av informasjonsmodellering. Del 2. Stadiet for etablering av eiendeler ”. Lignende ISO-standarder (ISO 19650-1 og ISO 19650-2) er for tiden i sluttfasen av utviklingen. Eksperter på PC 13 "Behandling, lagring og utveksling av informasjon knyttet til byggearbeid" TC 465 "Bygg" har deltatt i disse arbeidene siden 2017.

Gjennomgår nå registreringsprosedyren GOST R “Informasjonsmodellering i konstruksjon. Industry Base Classes (IFC) for informasjonsutveksling på tvers av alle stadier av livssyklusen. Grunnleggende bestemmelser ". "Hvis statskunden får muligheten til å be om å gi informasjon for kontroll i IFC-formatet, vil det ikke være behov for å bruke budsjettmidler på kjøp av et stort antall forskjellige programvareprodukter og på vedlikehold av en overdreven stab av spesialister som er i stand til å jobbe i disse programmene," sa Alexander Stepanov.

Systemet med normative og tekniske dokumenter totalt vil inkludere 15 nasjonale standarder (GOST R), 10 sett med regler, inkludert: 13 GOST R og 4 SP - dokumenter utviklet i grunnleggende (grunnleggende) retninger; 2 GOST R og 6 sett med regler - for individuelle stadier av livssyklusen.

For øyeblikket, innen BIM, er 7 GOST-er og 4 sett med regler tilgjengelige for praktisk bruk.

Arrangementet ble deltatt av spesialister fra TC 465 "Construction", KazNIISA (Kasakhstan), Center for Digital Economy ved Moscow State University, JSC SRC "Construction", NIIPromzdaniy, FAU FTSS, etc.

Konfidensialitetspolicy for selskapet "Koncurator"

Dette dokumentet "Personvernregler" (heretter referert til som "Retningslinjer") ble utviklet i samsvar med den russiske føderasjonens føderale lov datert 27. juli 2006 nr. 152-FZ "Om personopplysninger" og definerer prosedyren for behandlingen , bruk og beskyttelse av personopplysninger av OOO Konkurator "(Heretter -" Selskapet "), lokalisert på adressen: 117036, Russland, Moskva, st. Profsoyuznaya, hus 3, kontor 817.

For formålene med denne policyen betyr "personopplysninger" all informasjon som direkte eller indirekte er relatert til en identifisert eller identifiserbar person. "Behandling av personopplysninger" betyr enhver handling (operasjon) eller et sett med handlinger (operasjoner) utført ved bruk av automatiseringsverktøy eller uten bruk av slike verktøy med personopplysninger, inkludert innsamling, registrering, systematisering, akkumulering, lagring, avklaring (oppdatering, endring) , utvinning, bruk, overføring (distribusjon, levering, tilgang), depersonalisering, blokkering, sletting, ødeleggelse av personopplysninger.

Ved å bruke nettstedet vårt og gi oss dine personopplysninger, fylle ut skjemaene på nettstedet vårt, samtykker du til behandlingen av dine personopplysninger i samsvar med denne policyen.

Selskapet samler inn, behandler, bruker og beskytter følgende personopplysninger som du oppgir til oss når du fyller ut skjemafeltene på nettstedet vårt (heretter referert til som "nettstedet"), når du kommuniserer med oss ​​i noen form, når du abonnerer på en nyhetsbrev, ved påmelding til arrangementer: , kontakt telefonnummer, e-postadresse (e-post), stilling, firma og annen informasjon som finnes i meldingene du sender oss.

Selskapet behandler dine personopplysninger utelukkende med det formål å gi deg informasjon om selskapet, våre tjenester og arrangementer; kommunisere med deg når du kontakter oss; organisere din deltakelse i våre arrangementer og undersøkelser; sender deg våre nyhetsbrev; til andre formål med ditt samtykke.

Tekniske data som overføres automatisk av enheten du bruker nettstedet med, inkludert de tekniske egenskapene til enheten, IP-adresse, informasjon fra informasjonskapsler, informasjon om nettleseren, dato og klokkeslett for tilgang til nettstedet, adressene til de forespurte sidene og annen slik informasjon, i motsetning til personopplysninger, er slik informasjon upersonlig, og tilhører derfor ikke sammensetningen av personopplysninger.

Selskapet kan behandle tekniske data for å: sikre funksjonen og sikkerheten til nettstedet og forbedre kvaliteten på nettstedet.

Selskapet legger ikke ut personopplysningene dine i offentlig tilgjengelige kilder.

For å beskytte rettighetene dine, vil selskapet, på din forespørsel, gi deg informasjon om behandlingen av dine personopplysninger, i samsvar med del 7 av artikkel 14 i den føderale loven "Om personopplysninger". Du kan kontakte oss med en forespørsel om behandling av dine personopplysninger ved å sende oss et brev med emnelinjen "Forespørsel om personopplysninger" (eller "Tilbakekallelse av samtykke til behandling av personopplysninger" i tilfelle tilbakekall av samtykke til behandling av personopplysninger) til e-postadressen: [e-postbeskyttet] nettstedet

Selskapet sørger for at nødvendige juridiske, organisatoriske og tekniske tiltak iverksettes for å beskytte personopplysninger mot uautorisert eller utilsiktet tilgang til dem, ødeleggelse, endring, blokkering, kopiering, tilveiebringelse, spredning av personopplysninger, samt fra andre ulovlige handlinger i forhold til dem. til personopplysninger, og påtar seg også forpliktelsen til å opprettholde konfidensialiteten til dine personopplysninger.

Behandlingen av personopplysninger utføres uten noen tidsbegrensning, på noen lovlig måte. Selskapet stopper behandlingen av personopplysningene dine på din forespørsel dersom de behandlede personopplysningene er ulovlig innhentet eller ikke er nødvendige for det angitte formålet med behandlingen og hvis du tilbakekaller ditt samtykke til behandling.

Selskapet har rett til å gjøre endringer i denne policyen. Den nye personvernerklæringen trer i kraft fra det øyeblikket den er lagt ut på nettstedet.

Den 23. august startet en offentlig diskusjon om fire joint ventures utviklet etter ordre fra departementet for bygg og bolig og verktøy i Den russiske føderasjonen. Liste med direkte lenker nedenfor. Termin for diskusjon er 60 kalenderdager.

Noen av lenkene kan fortsatt laste ned tekstene til dokumentutkastene. En annen og garantert måte å få tekstmeldinger på er å sende en forespørsel til adressen: [e-postbeskyttet]

Det anbefales å skrive kommentarer og forslag i det foreskrevne skjemaet. Alle kommentarer vil bli vurdert og besvart og/eller tilsvarende endringer vil bli gjort i den andre utgaven. Du kan sende kommentarer til samme adresse, eller gjennom skjemaet på FAA FTSS-nettstedet.

Den 8. september ble det mottatt kommentarer fra medlemmer av PK-5 TK-465 og medlemmer av Byggedepartementet WG, hvor dokumentene i utgangspunktet ble publisert.

Dokumenter er utviklet av forskjellige team, så prosedyren for håndtering av kommentarer kan være litt annerledes. I oktober avsluttes diskusjonen av dokumentene på PP-5-møtet, som mest sannsynlig også vil bli invitert til forfattere av viktige kommentarer.

Del 2. Uformell

1. Teamet vårt er involvert i utviklingen av to av de fire dokumentene. Vi er veldig glade for å ha muligheten til å delta i dannelsen av det regulatoriske og tekniske feltet for informasjonsmodellering i den russiske føderasjonen. Vi garanterer at kvaliteten på den endelige utgaven vil være av høyeste internasjonale standard. Vi er veldig interessert i dette, og derfor inviterer vi alle spesialister med kunnskap og erfaring innen et spesifikt fagområde, tilsvarende emnet for joint venture, til å snakke om fordelene og i en dialog komme til det beste (i det nåværende historiske øyeblikket ) formuleringer.

2. I Den russiske føderasjonen har arbeidet med Planen (program, veikart) for en trinnvis overgang til BIM pågått siden slutten av 2012. Flere titalls mennesker deltok i utviklingen og diskusjonen. Derfor er det i dette dokumentet for øyeblikket mer enn FEM åpenbare punkter. Og selve veikartet er nå under vurdering av regjeringen i den russiske føderasjonen. (Jeg har ingen informasjon om det er akseptert eller ikke ennå).

3. Som medlem av arbeidsgruppen og ekspertrådet om emnet, erklærer jeg at i nasjonale standardiseringsdokumenter er og vil ingen spesifikke programvareprodukter foretrekkes. (Programvareutviklere har rett, etter eget skjønn, til å utvikle standarder som sørger for arbeid i programvaren deres). I denne forbindelse foreslår jeg at forfattere som påstander om brudd på antimonopollovgivningen og den føderale loven om beskyttelse av konkurransen, illustrerer dette med tekster fra relevante lover og fellesforetaket.

Jeg vil gjerne trekke oppmerksomheten din til navnet på joint venture-selskapet, på grunn av hvilket denne opphetede diskusjonen begynte - "Reglene for utveksling mellom informasjonsmodeller av objekter og modeller brukt i programvaresystemer." Utviklerne av dette fellesforetaket ble faktisk fanget i en skrustikke. Noen anmeldere krever spesifisitet fra dem, detaljerte regler og ikke generelle hensyn. (Hvem vil fortelle deg hvordan dette kan gjøres hvis det nedlegges veto mot noen omtale av produkter?) Andre krever tvert imot at eventuelle omtaler slettes. Veien ut ligger åpenbart i utviklingen av ytterligere metodiske anbefalinger, hvor det vil være tillatt å nevne produktene.

I en nylig oppsiktsvekkende publikasjon var det en omtale av BIM-lykke på bekostning av en bestemt leverandør, jeg ber forfatteren om å "bevæpne" øynene og gi meg konkrete eksempler fra teksten. På grunn av mine roller (se første setning i punkt 3), må jeg virkelig sørge for nøytraliteten til regelverket angående BIM-plattformer.

4. I Storbritannia er andelen statlige ordrer i bygg og anlegg ca 40 %. RF har BETYDLIG LENGRE. Jeg kunne ikke finne det nøyaktige tallet, men NOPRIZ insisterer på at det ikke er mer enn 5 % (!). Fra andre kilder hørte jeg et tall på opptil 15 %. (Og hvorfor knekke et spyd – eller en rive?) Det vil si at en privatkunde dominerer i konstruksjonen. Og han står fritt til å bestille som han vil, uten å bryte loven. Og inkludert å bestemme formatene han ønsker å motta produktet i. Hva krangler vi da om? Hvis en statlig kunde begynner å be om 20 % av et lite volum i BIM, hvor mye forretning vil en individuell designer tape som ikke vil høre noe om BIM? Ingenting. Vil ikke gå på statens anbud og vil fortsette å male for en privat næringsdrivende til han spør BIM.

5. Nå om de "tildekkede restriksjonene for å skjule svakhetene til det promoterte produktet." Om "produktet" se punkt 3. Når det gjelder restriksjonene, antyder setningen ovenfor at forfatteren ikke er kjent med lignende dokumenter utviklet i andre land foran oss på dette området. Slike dokumenter er fulle av formuleringer som "på grunn av begrenset programvarestøtte" eller "ettersom BIM-ferdigheter og programvareverktøy for dette formålet fortsatt er umodne", osv. Ja, vi må innrømme at programvareproduktene vi har til rådighet ikke er perfekte ennå og vi må ta hensyn til dette... Derfor tar vi tilsvarende forbehold i teksten og vil fortsette å gjøre det.

6. Og avslutningsvis vil jeg appellere til de som var virkelig skuffet over det de så - tekstene til dokumenter og kaller dem rå, osv. Hva forventet du å finne der og ikke fant? Kanskje vi burde ordne opp i det og være mer spesifikke? Hvis vi samler alle temaene som dekkes av lignende nasjonale dokumenter om BIM i forskjellige land, vil vi finne at de reflekterer modelleringsteknikker, tilnærminger for å bestemme utviklingsnivåene for informasjonsmodellelementer (LOD, LOI), nye roller og ansvar for deltakere i prosessen, BIM-implementeringsplaner -prosjekter, regler for utvikling av bibliotekelementer, spørsmål om interoperabilitet og organisering av teamarbeid. Det er praktisk talt alle temaene. Først da er de fortsatt dekomponert i forskjellige deltakere og stadier av livssyklusen. Poster fra denne listen dekkes delvis av innsendte fellesforetak, og resten inngår av departementet i planen for videre utvikling.

Jeg inviterer alle som er skuffet til en konstruktiv dialog. Hvis du ikke ønsker å skrive en offisiell anke, og samtidig er vi kjent med deg, skriv i en personlig. La oss finne ut av det.

Godkjent. Etter ordre fra departementet for bygg og bolig og kommunale tjenester i Den russiske føderasjonen av 15. desember 2017 N 1674 / pr.

Retningslinjer SP-328.1325800.2017

"INFORMASJONSMODELLER I KONSTRUKSJON. REGLER FOR BESKRIVELSE AV INFORMASJONSMODELLKOMPONENTER"

Byggeinformasjonsmodellering. Komponenter. Retningslinjer og krav

Introdusert for første gang

Introduksjon

Dette settet med regler ble utviklet i samsvar med den føderale loven av 30. desember 2009 N 384-FZ "Tekniske forskrifter om sikkerheten til bygninger og konstruksjoner" for å utvikle enhetlige krav, regler og anbefalinger for å lage komponenter som brukes til å danne informasjonsmodeller av et byggeobjekt.

Regelsettet ble utarbeidet av teamet av forfattere av JSC "Research Center" Construction "- TsNIISK oppkalt etter V.A.Kucherenko (leder for arbeidet - Dr. Ananiev) og LLC "KONKURATOR" (M.G. Korol, S.E. Benklyan).

1 bruksområde

1.1 Dette regelverket gjelder prosessene for informasjonsmodellering av bygninger og konstruksjoner og fastsetter krav til komponentene i informasjonsmodellene deres.

1.2 Dette regelverket stiller ikke krav til metodene for plassering, vedlikehold, struktur, form og innhold til digitale biblioteker (kataloger/baser) av komponenter.

2 Normative referanser

Dette settet med regler bruker normative referanser til følgende dokumenter:

GOST 2.303-68 Samlet system for designdokumentasjon. Linjer

GOST 2.306-68 Unified system for design documentation. Betegnelser for grafisk materiale og regler for deres anvendelse i tegninger

Merk - Når du bruker dette settet med regler, er det tilrådelig å sjekke gyldigheten av referansedokumenter i det offentlige informasjonssystemet - på den offisielle nettsiden til det føderale utøvende organet innen standardisering på Internett eller i henhold til den årlige informasjonsindeksen " National Standards", som ble publisert fra 1. januar inneværende år , og om utgavene av den månedlige informasjonsindeksen "National Standards" for inneværende år. Hvis det refererte dokumentet som den udaterte lenken er gitt til erstattes, anbefales det at gjeldende versjon av dette dokumentet brukes, med tanke på alle endringer som er gjort i denne versjonen. Hvis det refererte dokumentet som den daterte referansen er gitt til, erstattes, anbefales det å bruke versjonen av dette dokumentet med ovennevnte godkjenningsår (godkjenning). Dersom det etter godkjenning av dette regelverket gjøres en endring i det refererte dokumentet som den daterte referansen er gitt til, som påvirker bestemmelsen som det refereres til, anbefales det at denne bestemmelsen anvendes uten å ta hensyn til dette. endring. Hvis det refererte dokumentet kanselleres uten erstatning, anbefales det at bestemmelsen der lenken til det er gitt, brukes i den delen som ikke påvirker denne lenken. Det anbefales å sjekke informasjonen om gyldigheten av regelsettene i Federal Information Fund of Standards.

3 Begreper og definisjoner

Følgende termer og definisjoner brukes i dette dokumentet:

3.1 komponentattributter: Essensielle egenskaper til en komponent som er nødvendige for å definere dens geometri eller egenskaper og har et navn og en betydning.

3.2 komponent geometriske parametere: Attributter som definerer størrelse, form og romlig posisjon til en komponent.

3.3 grafiske egenskaper for en komponent: Egenskaper som sikrer gjenkjennelighet av en komponent i en tredimensjonal projeksjon, samt i ulike projeksjoner og skalaer med visning av karakteristiske todimensjonale symboler, linjer, skraveringer, tekst.

3.4 informasjonsmodellering av byggeobjekter: Prosessen med å opprette og bruke informasjon om under bygging, samt ferdigstilte byggeobjekter for å koordinere inndata, organisere felles produksjon og lagring av data, samt deres bruk til ulike formål i alle ledd av livssyklusen.

3.5 komponent: En digital representasjon av de fysiske og funksjonelle egenskapene til et enkeltelement på en byggeplass, beregnet på gjentatt bruk.

Merk - En komponent brukt i en modell blir et modellelement.

3.6 komponentmetadata: Strukturerte data som representerer egenskapene til en beskrevet komponent for identifikasjon, gjenfinning, evaluering og styring.

3.7 åpne datautvekslingsformater: Dataformater med åpen spesifikasjon.

MERK - IFC-formatet (Industry Base Classes) er et åpent spesifikasjonsdataformat og -skjema. Det er en internasjonal standard for datautveksling innen informasjonsmodellering innen anleggsteknikk og drift.

3.8 monteringEt navngitt sett med komponenter som kan gjenbrukes.

3.9 nivå av utdypning; LOD: Et sett med krav som definerer fullstendigheten av utarbeidelsen av et digitalt informasjonsmodellelement. Utviklingsnivået spesifiserer minimumsmengden av geometriske, romlige, kvantitative, samt eventuelle attributtdata som kreves for å løse ipå et bestemt stadium av objektets livssyklus.

3.10 funksjonell oppførsel av en komponent: Endring av en komponent i samsvar med reglene for interaksjon med miljøforhold fastsatt i den.

3.11 digital informasjonsmodell: En objektorientert parametrisk tredimensjonal modell som digitalt representerer de fysiske, funksjonelle og andre egenskapene til et objekt (eller dets individuelle deler) i form av et sett med informasjonsrike elementer.

3.12 modellelement: Del av en digital informasjonsmodell som representerer et element, system eller sammenstilling innenfor en byggeplass eller byggeplass.

4 Generelt

4.1 Komponenter er preget av geometriske parametere, grafiske egenskaper, attributter og funksjonell oppførsel.

4.2 Komponenter bør skilles:

Etter typer:

Punkt - komponenter med spesifiserte geometriske former som legges til modellen med referanse til deres innsettingspunkt.

MERK Komponenter som vindu, dør, bjelke, søyle, pumpe, møbler osv.;

Lineær - oppnås ved å koble en rettet lukket profil og en referanselinje som en generator.

MERK Komponenter som vegger, rør, kanaler, kanaler osv.;

Areal - volumetriske komponenter med betydelig lavere høyde, skapt ved å tegne en kontur av et begrenset område.

MERK Komponenter som gulv, tak, tak osv.;

Med henvisning til produsenten:

Generalisert - komponenten er en digital representasjon av et produkt, hvis spesifikke produsent er ukjent;

Produkt – En komponent er en digital representasjon av en bestemt produsents produkt.

Etter parameteriseringsnivå:

Parametriske komponenter - komponenter, plasserte forekomster av som kan konfigureres ved å endre attributtverdiene i programvaregrensesnittet (uten å måtte redigere komponenten direkte);

Ikke-parametriske komponenter er komponenter som er opprettet uten mulighet for konfigurasjon.

Etter omfang:

Arkitektur;

Urban planlegging;

Bygningskonstruksjon;

Ingeniørsystemer og nettverk;

Interiør og eksteriør design;

Andre bruksområder.

5 Generelle krav til komponenter

5.1 Komponentutvikling bør utføres ved å bruke passende programvareverktøy som implementereralitet.

5.2 Når du utvikler komponenter, bør du:

Vurder målene med å bruke den digitale informasjonsmodellen;

Ta hensyn til kravene til nivåene for utarbeidelse av modellelementer;

Bestem sammensetningen og antall geometriske parametere;

Bestem sammensetningen og antall attributter.

6 Krav til geometriske parametere, nivåer av geometrisk utforming og grafisk visning av komponenter

6.1 Krav til geometriske parametere og grafisk representasjon av en komponent inkluderer krav til:

Geometriske parametere;

Visning av grafiske symboler;

Nivået av geometrisk utdyping;

Reservasjon av plass okkupert av en komponent;

Grafisk visning av materialer.

6.2 Krav til geometriske parametere

6.2.1 Når du utvikler en komponent, bør du:

Simuler geometri i en skala på 1:1;

Definer innsettingspunktet (grunnpunktet) for en punktkomponent;

Bruk minimum antall konstruksjonselementer (for eksempel konstruksjonsplaner og linjer);

Bruk geometriske parametere uttrykt i metriske enheter.

6.2.2 Generiske komponenter skal inkludere parameterverdier som definerer nominelle dimensjoner dersom de faktiske dimensjonene ikke er kjent.

6.2.3 Komponenter av typen "produkt" skal inkludere parameterverdier som definerer de nøyaktige dimensjonene.

6.2.4 Krav til visning av grafiske symboler:

komponenten må inneholde grafiske elementer for å formidle informasjon som ikke kan vises i en tredimensjonal projeksjon (for eksempel retningsvisere, åpningsretning av dører, måter å åpne vinduer på).

6.3 Krav til nivå for geometrisk utdyping

6.3.1 Innsettingspunktene (basispunkter) til en komponent bør være konsistente på tvers av alle utviklingsnivåer.

6.4 Krav til grafisk visning av materialer

6.4.1 Hvis et bilde skal fylle overflaten til en komponent, må det være kvadratisk eller rektangulært for å gi sømløs repetisjon av bildet (flising).

6.4.2 Krav til filen med bildet av materialet:

Størrelsen på kvadratiske bilder er minst 512 x 512 piksler;

Størrelse på rektangulære bilder - minst 512 piksler langs den lengste siden;

Bildeoppløsning - ikke mindre enn 150 punkter per tomme.

7 Krav til nivå på attribusjon og attributtverdier

7.1 Ved utvikling av komponenter bør antallet, sammensetningen av attributter og nivået av attributiv utdyping bestemmes under hensyntagen til:

Mål og mål for bruk av digitale informasjonsmodeller;

LOD krav;

Krav til sammensetning og innhold av teknisk dokumentasjon.

7.2 Alle opprettede komponentattributter skal fylles ut.

7.3 Komponentattributter bør deles inn i obligatoriske og valgfrie.

7.3.1 De obligatoriske attributtene til en komponent bør inkludere slike egenskaper eller tekniske egenskaper som gjør at komponenten kan identifiseres unikt, og også inneholde data på grunnlag av hvilke det er mulig å utvikle teknisk dokumentasjon, bestille, kjøpe og installere en spesifikk komponent under byggeprosessen.

7.3.2 Ytterligere attributter bør inkludere egenskaper eller tekniske egenskaper som kreves for tekniske beregninger, informasjon av teknisk og økonomisk art, tekniske og operasjonelle og andre egenskaper.

7.4 Hvis parameterverdier skal kontrollere den geometriske størrelsen eller formen til en komponent, bør endring av dem endre størrelsen og/eller formen til komponenten i modellen.

7.5 Hvis verdien av attributtet ikke er begrenset og gir mulighet for å legge inn både tall og bokstaver, skal verdien til attributtet tildeles en alfanumerisk datatype.

7.6 Verdien av et tekstattributt til en komponent må ikke slutte med et punktum.

8 Funksjonskrav til komponenter

8.1 En komponent skal "oppføre seg" på en måte som gjenspeiler dens funksjonalitet og forhold til andre komponenter.

8.2 I et programvaremiljø er det som regel mulig å designe en komponent med et eller annet antall forhåndsdefinerte faste parametere tilgjengelig i et reelt fysisk bygningselement. Hvis det er forhåndskonfigurerte varianter av en komponent, bør ytelsesdegraderingen eller vanskeligheten med å bruke den være minimal.

8.3 En komponent bør modelleres slik at den kan kobles til og fungere sammen med andre komponenter dersom interoperabilitet er støttet og i samsvar med målene for modellen som utvikles.

9 Regler for navngivning av komponenter og deres attributter

9.1 Navnekonvensjonene for komponenter i denne delen er for filbasert programvare.

9.2 Navnesystemet bør bestå av:

Generelle navneregler;

Navneordninger.

MERK - Et eksempel på et komponentfilnavnsystem er gitt i A.15-A.16 (vedlegg A).

9.3 En komponent må ha et unikt navn og beskrivelse.

9.4 Navneregler for attributter

9.4.1 Måleenheter er ikke angitt i attributtnavnet.

9.4.2 Attributter med verdier som antyder boolske datatyper (Ja / Nei) bør navngis slik at verdien nødvendigvis tildeles (for eksempel "Sill Presence" - Ja / Nei).

MERK - Et eksempel på reglene for navngiving av attributter er gitt i A.17 (vedlegg A).

9.5 Navnekonvensjoner for materialer

9.5.1 Navnet på et materiale må begynne med en stor bokstav etterfulgt av en liten bokstav. Hvis navnet består av to eller flere ord, begynner hvert ord med stor bokstav og alle ordene skrives sammen.

9.5.2 Filen med bildet av materialet navngis på samme måte som for materialet, med utvidelsen tilsvarer formatet til den brukte grafikkfilen.

MERK - Et eksempel på reglene for navngivning av materialer er gitt i A.18 (vedlegg A).

10 Krav til komponentformater

10.1 Ved filformater kan komponenter representeres:

I åpent IFC-format (versjoner 2x3 og høyere);

I kildeformater (filformater for komponenter og prosjektfiler for programvaren som brukes).

11 Krav til komponentmetadata

11.1 Når du organiserer databaser / kataloger / biblioteker av komponenter, for eksempel i form av Internett-lagring, er det nødvendig å gi et praktisk søk ​​etter nødvendig innhold. Vanligvis utføres dette søket ved hjelp av metadata. Søk etter metadata – søk etter attributter til en komponent som støttes av en bestemt søkemotor.

Vedlegg A

A.1 Komponenter kan kombineres til sammenstillinger (for eksempel "rørleggerarbeid", "varmeenhet", "transformatorstasjon"), som anbefales brukt til å danne tematiske kataloger / databaser / gjenbruksbiblioteker.

A.2 Komponenten må være unikt identifisert. For dette anbefales det å bruke:

Unikt navn;

Globalt unik identifikator som brukes til å identifisere ressurser;

Klassifiseringskode (hvis noen).

A.3 For å minimere antallet komponenter som utvikles og forene dem, anbefales det å lage parametriske komponenter.

For å overholde kravene i ESKD- og SPDS-standarder (for eksempel GOST 2.303 og GOST 2.306) for design- og arbeidsdokumentasjon, anbefales det å inkludere konvensjonelle grafiske symboler i sammensetningen ved utvikling av en komponent.

Merk - Komponenter på LOD 100-utviklingsnivået er konseptuelle formative elementer og trenger som sådan ikke foreløpig forberedelse av de tilsvarende komponentene, og på LOD 500-nivået er de fullt definerte komponenter som skiller seg fra LOD 400-nivået bare i dimensjoner som samsvarer med den faktiske gjennomføringen av designbeslutningene. Av disse grunner anbefales LOD-utviklingsnivåer på 200, 300 og 400 for utvikling av databaser / biblioteker / kataloger over komponenter.

MERK I mangel av passende lavnivåkomponenter, kan høyerenivåkomponenter brukes.

A.8 Det anbefales at ingeniør-/prosessutstyrskomponentene utformes med hensyn til reservert vedlikeholdsplass, som anbefales inkludert som en del av komponenten.

A.9 Hvis det er nødvendig å utvikle en komponent med et spesifikt materiale, anbefales det å inkludere farger, skraverings-/fyllmønstre og filer med teksturbilde i passende skala.

A.12 Verdien av et komponentattributt kan uttrykkes som en formel hvis verdien avhenger av andre attributter.

A.13 Hvis en komponent kan representere forskjellige varianter av et element i et konstruksjonsobjekt, anbefales det å representere dem ved å bruke et attributt med en verdi uttrykt på en av følgende måter:

Den eneste verdien er hvis det bare er ett valg for verdien;

Listeverdi - hvis den bestilte listen inneholder flere unike verdier av samme type, hvis rekkefølge er viktig (for eksempel 200, 400, 600, 800);

Områdeverdi - hvis det er øvre og nedre grenser for denne verdien (grense). Den nedre grensen er indikert først, og deretter den øvre grensen (for eksempel 175-200 kW). Hvis verdiområdet inkluderer positive og negative verdier, skilles de med ordene "fra" og "til" (for eksempel fra minus 10 ° C til pluss 20 ° C). Hvis ingen verdi er spesifisert, betyr det en ubegrenset grense (for eksempel 175 kW -<ноль>, dvs. alle verdier er større enn eller lik den nedre grenseverdien på 175 kW);

Nummerert verdi - hvis verdien gir mulighet for valg av faste verdier fra den etablerte listen. Individuelle elementer må skilles fra hverandre med et komma og et mellomrom (for eksempel a, b, c, d).

Merk - Disse metodene for å uttrykke forskjellige varianter av elementer i et konstruksjonsobjekt brukes som regel i komponenter av den "generaliserte" typen.

A.14 En komponent anbefales modellert på en slik måte at den kan kobles til andre komponenter og fungere sammen med disse, dersom fellesfunksjonen er støttet og samsvarer med målene for den utviklede modellen.

Filnavnet består av felter;

Det anbefales å bruke understreken "_" som skilletegn mellom feltene;

Alle felt i et filnavn starter med en stor bokstav etterfulgt av en liten bokstav. Hvis feltet består av to eller flere ord, begynner hvert ord med stor bokstav og alle ordene skrives sammen;

Forkortelser og koder skal skrives med store bokstaver;

A.16 Komponentfilnavnstruktur

<Поле1>_<Поле2>_<Поле3>_<Поле4>_<Поле5>_<Поле6>

hvor feltene har betydningen gitt i Tabell A.1.

Tabell A.1

Hvis komponenten ikke inneholder 3D-geometri, legger du til "-2D" på slutten av "Fields2" (funksjonell type).

Notater (rediger)

1 Antall felt i filnavnet kan variere fra fire til seks, avhengig av type komponent (type "generisk" eller "produkt"), samt tilstedeværelsen av ytterligere identifiserende egenskaper.

2 Et eksempel på navngivning av komponenter av den "generiske" typen:

ABV_Dør_Double_Aluminium_GOST23747-2015

3 Et eksempel på navngivning av komponenter av typen "produkt":

ABC_Washbasin_Ceramic_Factory1_VersionA

Hvis du trenger å legge inn flere felt, anbefales det å legge dem til på slutten av navnet.

A.17 Navneregler for attributter

<Поле1>_<Поле2>

hvor feltene har følgende betydninger gitt i tabell A.2

Tabell A.2

MERK - Eksempler på navngivingsattributter:

Profilbredde

ABC_AreaApartments

<Поле1>_<Поле2>_<Поле3>_<Поле4>_<Поле5>

hvor feltene har følgende betydninger gitt i tabell A.3

Tabell A.3

MERK - Eksempel på navngivingsmateriale:

ABC_Tiles_Bituminous_Continent_Manufacturer