Cn informatiemodellering. Openbare discussie over BIM-praktijkcodes (SP). Functionele vereisten voor componenten

laat een reactie achter 6,950

Drie nieuwe regels (JV) op het gebied van informatietechnologie zijn goedgekeurd en zullen op 1 maart van kracht worden. Dit werd aangekondigd door Alexander Stepanov, plaatsvervangend hoofd van de afdeling Stedelijke Ontwikkeling en Architectuur van het Ministerie van Bouw en Huisvesting en Gemeentelijke Diensten van de Russische Federatie, in het kader van het seminar "Informatiemodellering. Digitale omgeving als basis voor interactie ", georganiseerd door het Federale Centrum voor rantsoenering, standaardisatie en technische conformiteitsbeoordeling in de bouw, ondergeschikt aan het ministerie van bouw van Rusland, samen met de RSPP-commissie voor technische regelgeving, standaardisatie en conformiteitsbeoordeling. Het evenement vond plaats op 21 februari met de deelname van een representatief team van experts.

JV “Informatiemodellering in de bouw. Regels voor het beschrijven van de componenten van het informatiemodel ”,“ Informatiemodellering in de bouw. De regels voor het vormen van een informatiemodel van objecten in verschillende stadia van de levenscyclus "en" Informatiemodellering in de bouw. De regels voor uitwisseling tussen informatiemodellen van objecten en modellen die worden gebruikt in softwaresystemen "worden op 1 maart van kracht. 2018.

Volgens Alexander Stepanov omvat het systeem van nationale documenten dat wordt gecreëerd op het gebied vaneën in de bouw, basisnormen en praktijkcodes die zorgen voor digitale infrastructuur, inclusief die welke de basisbepalingen, principes en terminologie van BIM definiëren, evenals normen en praktijkcodes die het conceptuele kader en een methodologie definiëren om informatiemodellering in bepaalde stadia van de levenscyclus in de praktijk te brengen - van het rechtvaardigen van investeringen tot het gebruik en de sloop van gebouwen en constructies.

In 2018 begon de ontwikkeling van basisnormen die de basisprincipes, concepten en terminologie van BIM definiëren: GOST R “Organisatie van informatie over bouwwerkzaamheden. Informatiemanagement met behulp van informatiemodellering. Deel 1. Basisprincipes en concepten "en GOST R" Organisatie van informatie over bouwwerkzaamheden. Informatiemanagement met behulp van informatiemodellering. Deel 2. De fase van het creëren van activa ”. Vergelijkbare ISO-normen (ISO 19650-1 en ISO 19650-2) bevinden zich momenteel in de laatste ontwikkelingsfase. Experts van PC 13 "Verwerking, opslag en uitwisseling van informatie met betrekking tot bouwwerkzaamheden" TC 465 "Bouw" nemen sinds 2017 deel aan deze werken.

Ondergaat nu de registratieprocedure GOST R “Informatiemodellering in de bouw. Industry Base Classes (IFC's) voor informatie-uitwisseling gedurende de levenscyclus. Basisbepalingen". “Als de staatsklant de mogelijkheid wordt geboden om de verstrekking van informatie voor controle in het IFC-formaat te eisen, dan is het niet nodig om budgetfondsen te besteden aan de aankoop van een groot aantal verschillende softwareproducten en aan het onderhoud van een overmatig personeel van specialisten die in staat zijn om in deze programma's te werken, "zei Alexander Stepanov.

Het systeem van normatieve en technische documenten omvat in totaal 15 nationale normen (GOST R), 10 sets regels, waaronder: 13 GOST R en 4 SP - documenten ontwikkeld in fundamentele (basis)richtingen; 2 GOST R en 6 sets regels - voor individuele fasen van de levenscyclus.

Momenteel zijn er op het gebied van BIM 7 GOST's en 4 sets regels beschikbaar voor praktisch gebruik.

Het evenement werd bijgewoond door specialisten van TC 465 "Construction", KazNIISA (Kazachstan), het Center for Digital Economy van de Moscow State University, JSC Research Center "Construction", NIIPromzdaniy, FAU FTSS, enz.

Vertrouwelijkheidsbeleid van het bedrijf "Konkurator"

Dit document "Privacybeleid" (hierna het "Beleid" genoemd) is ontwikkeld in overeenstemming met de federale wet van de Russische Federatie van 27 juli 2006 nr. 152-FZ "Over persoonsgegevens" en definieert de procedure voor de verwerking , gebruik en bescherming van persoonlijke gegevens door OOO Konkurator "(Hierna - het" Bedrijf "), gevestigd op: 117036, Rusland, Moskou, st. Profsoyuznaya, huis 3, kantoor 817.

Voor de doeleinden van dit Beleid betekent "persoonsgegevens" alle informatie die direct of indirect betrekking heeft op een geïdentificeerde of identificeerbare persoon. Onder "verwerking van persoonsgegevens" wordt verstaan elke actie (bewerking) of een reeks acties (bewerkingen) die worden uitgevoerd met behulp van automatiseringstools of zonder gebruik van dergelijke tools met persoonlijke gegevens, met inbegrip van verzameling, registratie, systematisering, accumulatie, opslag, verduidelijking (bijwerken, wijzigen) , extractie, gebruik, overdracht (distributie, verstrekking, toegang), depersonalisatie, blokkering, verwijdering, vernietiging van persoonlijke gegevens.

Door onze website te gebruiken en ons uw persoonlijke gegevens te verstrekken, door de formulieren op onze website in te vullen, stemt u in met de verwerking van uw persoonlijke gegevens in overeenstemming met dit beleid.

Het bedrijf verzamelt, verwerkt, gebruikt en beschermt de volgende persoonlijke gegevens die u ons verstrekt bij het invullen van de formuliervelden op onze website (hierna de "Site" genoemd), wanneer u in welke vorm dan ook met ons communiceert, wanneer u zich abonneert op een nieuwsbrief, bij inschrijving voor evenementen: , telefoonnummer, e-mailadres (e-mail), functie, bedrijf en andere informatie in de berichten die u ons stuurt.

Het Bedrijf verwerkt uw persoonsgegevens uitsluitend om u informatie te verstrekken over het Bedrijf, onze diensten en evenementen; met u communiceren wanneer u contact met ons opneemt; het organiseren van uw deelname aan onze evenementen en enquêtes; u onze nieuwsbrieven te sturen; voor andere doeleinden met uw toestemming.

Technische gegevens die automatisch worden verzonden door het apparaat waarmee u de site gebruikt, waaronder de technische kenmerken van het apparaat, IP-adres, informatie uit cookies, informatie over de browser, datum en tijd van toegang tot de site, adressen van de opgevraagde pagina's en andere dergelijke informatie, in tegenstelling tot persoonlijke gegevens, is dergelijke informatie onpersoonlijk en behoort daarom niet tot de samenstelling van persoonlijke gegevens.

Het bedrijf kan technische gegevens verwerken om: de werking en veiligheid van de site te verzekeren en de kwaliteit van de site te verbeteren.

Het bedrijf plaatst uw persoonlijke gegevens niet in openbare bronnen.

Om uw rechten te beschermen, zal het bedrijf u op uw verzoek informatie verstrekken over de verwerking van uw persoonlijke gegevens, in overeenstemming met deel 7 van artikel 14 van de federale wet "op persoonlijke gegevens". U kunt contact met ons opnemen met een verzoek met betrekking tot de verwerking van uw persoonsgegevens door ons een brief te sturen met als onderwerp "Verzoek om persoonsgegevens" (of "Intrekking van toestemming voor de verwerking van persoonsgegevens" in geval van intrekking van de toestemming voor de verwerking van persoonsgegevens) naar het e-mailadres: [e-mail beveiligd] site

Het bedrijf zorgt ervoor dat de nodige juridische, organisatorische en technische maatregelen worden genomen om persoonsgegevens te beschermen tegen ongeoorloofde of onopzettelijke toegang tot deze gegevens, vernietiging, wijziging, blokkering, kopiëren, verstrekken, verspreiding van persoonsgegevens, evenals tegen andere onwettige handelingen in verband met tot persoonsgegevens, en neemt tevens de verplichting op zich om de vertrouwelijkheid van uw persoonsgegevens te bewaren.

De verwerking van persoonsgegevens gebeurt zonder enige tijdslimiet, op een legale manier. Het bedrijf stopt op uw verzoek met de verwerking van uw persoonsgegevens als de verwerkte persoonsgegevens onrechtmatig zijn verkregen of niet nodig zijn voor het aangegeven doel van de verwerking en als u uw toestemming voor de verwerking intrekt.

Het bedrijf heeft het recht om wijzigingen aan te brengen in dit beleid. Het nieuwe privacybeleid treedt in werking vanaf het moment dat het op de site wordt geplaatst.

Op 23 augustus begon een openbare discussie over vier joint ventures die zijn ontwikkeld in opdracht van het Ministerie van Bouw en Huisvesting en Nutsvoorzieningen van de Russische Federatie. Lijst met directe links hieronder. De termijn voor bespreking is 60 kalenderdagen.

Een deel van de links kan de teksten van de conceptdocumenten nog downloaden. Een andere en gegarandeerde manier om sms'jes te ontvangen, is door een verzoek te sturen naar het adres: [e-mail beveiligd]

Het wordt aanbevolen om opmerkingen en suggesties in de voorgeschreven vorm te schrijven. Alle opmerkingen zullen in overweging worden genomen en beantwoord en/of overeenkomstige wijzigingen worden aangebracht in de tweede editie. U kunt opmerkingen naar hetzelfde adres sturen, of via het formulier op de FAU FTSS-website.

Op 8 september werden opmerkingen ontvangen van leden van PK-5 TK-465 en leden van het Ministerie van Bouw, op de site waarvan de documenten in de eerste plaats werden gepubliceerd.

Documenten worden door verschillende teams ontwikkeld, dus de procedure voor het verwerken van opmerkingen kan enigszins verschillen. In oktober zal de bespreking van de documenten eindigen op de PP-5-bijeenkomst, waarvoor hoogstwaarschijnlijk ook auteurs van belangrijke opmerkingen zullen worden uitgenodigd.

Deel 2. Informeel

1. Ons team is betrokken bij de ontwikkeling van twee van de vier documenten. We zijn erg blij dat we de kans hebben om deel te nemen aan de vorming van het regelgevende en technische veld voor informatiemodellering in de Russische Federatie. We garanderen dat de kwaliteit van de definitieve versie van de hoogste internationale standaard zal zijn. Wij zijn hierin zeer geïnteresseerd en nodigen daarom alle specialisten met kennis en ervaring op een specifiek vakgebied, overeenkomend met het onderwerp van de joint venture, uit om ten gronde te spreken en in een dialoog tot het beste te komen (op het huidige historische moment ) formuleringen.

2. In de Russische Federatie wordt sinds eind 2012 gewerkt aan het Plan (programma, roadmap) van een gefaseerde overgang naar BIM. Tientallen mensen namen deel aan de ontwikkeling en discussie. Daarom zijn er in dit document op dit moment meer dan VIJF voor de hand liggende punten. En de routekaart zelf wordt nu bestudeerd door de regering van de Russische Federatie. (Ik heb geen informatie of het is geaccepteerd of nog niet).

3. Als lid van de Werkgroep en Expert Council over het onderwerp verklaar ik dat in nationale normalisatiedocumenten geen specifieke softwareproducten de voorkeur krijgen en zullen krijgen. (Softwareontwikkelaars hebben het recht om naar eigen goeddunken standaarden te ontwikkelen die voorzien in werk in hun software). In dit verband stel ik voor dat auteurs die beschuldigingen van schendingen van de antimonopoliewetgeving en de federale wet op de bescherming van de concurrentie dit illustreren met teksten uit de relevante wetten en de joint venture.

Ik wil uw aandacht vestigen op de naam van de joint venture, waardoor deze verhitte discussie begon - "Regels voor uitwisseling tussen informatiemodellen van objecten en modellen die worden gebruikt in softwaresystemen." De ontwikkelaars van deze joint venture zaten in feite gevangen in een bankschroef. Sommige reviewers eisen specificiteit van hen, gedetailleerde regels en geen algemene overwegingen. (Wie zal u vertellen hoe dit kan als een vermelding van producten wordt afgewezen?) Anderen daarentegen eisen dat alle vermeldingen worden verwijderd. De uitweg ligt uiteraard in de ontwikkeling van aanvullende methodologische aanbevelingen, waarbij het toegestaan zal zijn om de producten te vermelden.

In een recente ophefmakende publicatie was er sprake van BIM-geluk ten koste van een bepaalde verkoper, ik vraag de auteur zijn ogen te "bewapenen" en mij concrete voorbeelden uit de tekst te geven. Vanwege mijn rollen (zie de eerste zin van punt 3), moet ik echt zorgen voor de neutraliteit van regelgeving met betrekking tot BIM-platforms.

4. In Groot-Brittannië bedraagt het aandeel van overheidsopdrachten in de bouw ongeveer 40%. De RF is AANZIENLIJK LAGER. Ik heb het exacte cijfer niet kunnen vinden, maar NOPRIZ houdt vol dat het niet meer dan 5% (!) is. Uit andere bronnen hoorde ik het cijfer tot 15%. (En waarom een speer - of een hark breken?) Dat wil zeggen, een particuliere klant domineert in de bouw. En hij is vrij om te bestellen wat hij wil, zonder de wet te overtreden. En inclusief het bepalen van de formaten waarin hij het product wil ontvangen. Waar hebben we het dan over? Als een staatsklant 20% van een klein volume in BIM begint te vragen, hoeveel omzet zal een individuele ontwerper dan verliezen die niets over BIM wil horen? Niks. Gaat niet naar de staatsaanbesteding en blijft schilderen voor een particuliere handelaar totdat hij BIM vraagt.

5. Nu over de "versluierde beperkingen om de zwakheden van het gepromote product te verbergen." Over het "product" zie punt 3. Wat de beperkingen betreft, suggereert de bovenstaande zin dat de auteur niet bekend is met soortgelijke documenten die in andere landen zijn ontwikkeld en die ons op dit gebied hebben overtroffen. Dergelijke documenten staan vol met formuleringen zoals "vanwege beperkte softwareondersteuning" of "omdat BIM-vaardigheden en softwaretools voor dit doel nog onvolwassen zijn", enz. Ja, we moeten toegeven dat de softwareproducten die we tot onze beschikking hebben nog niet perfect zijn en daar moeten we rekening mee houden... Daarom maken we soortgelijke voorbehouden in de tekst en zullen we dat blijven doen.

6. En tot slot zou ik een beroep willen doen op degenen die echt teleurgesteld waren in wat ze zagen - de teksten van documenten en ze rauw noemden, enz. Wat had je daar verwacht te vinden en niet gevonden? Misschien moeten we het uitzoeken en specifieker zijn? Als we alle onderwerpen samenbrengen die in vergelijkbare nationale documenten over BIM in verschillende landen worden behandeld, zullen we zien dat ze modelleringstechnieken, benaderingen voor het bepalen van de ontwikkelingsniveaus van informatiemodelelementen (LOD, LOI), nieuwe rollen en verantwoordelijkheden van deelnemers aan het proces, BIM-implementatieplannen -projecten, regels voor de ontwikkeling van bibliotheekelementen, kwesties van interoperabiliteit en organisatie van teamwerk. Dat zijn praktisch alle onderwerpen. Alleen dan worden ze nog steeds ontleed in verschillende deelnemers en stadia van de levenscyclus. Items uit deze lijst worden deels gedekt door de ingediende samenwerkingsverbanden, de rest wordt door het ministerie meegenomen in het plan voor verdere ontwikkeling.

Ik nodig iedereen die teleurgesteld is uit voor een constructieve dialoog. Als je geen officieel beroepschrift wilt schrijven, en tegelijkertijd zijn we al bekend met je, schrijf dan in een persoonlijk. Laten we het uitzoeken.

Goedgekeurd. In opdracht van het Ministerie van Bouw en Huisvesting en Gemeentelijke Diensten van de Russische Federatie van 15 december 2017 N 1674 / pr

Praktijkcode SP-328.1325800.2017

"INFORMATIEMODELLEN IN DE BOUW. REGELS VOOR BESCHRIJVING INFORMATIEMODELCOMPONENTEN"

Modellering van gebouwinformatie. Componenten. Richtlijnen en vereisten

Voor het eerst geïntroduceerd

Invoering

Deze reeks regels is ontwikkeld in overeenstemming met de federale wet van 30 december 2009 N 384-FZ "Technische voorschriften voor de veiligheid van gebouwen en constructies" om uniforme eisen, regels en aanbevelingen te ontwikkelen voor het maken van componenten die worden gebruikt om informatiemodellen van een bouwobject.

De set regels is opgesteld door het team van auteurs van JSC "Research Center" Construction "- TsNIISK genoemd naar V.A.Kucherenko (hoofd van het werk - Dr. Ananiev) en LLC "KONKURATOR" (M.G. Korol, S.E. Benklyan).

1 toepassingsgebied

1.1 Deze set regels is van toepassing op de processen van informatiemodellering van gebouwen en constructies en stelt de vereisten vast voor de componenten van hun informatiemodellen.

1.2 Dit reglement stelt geen eisen aan de wijze van plaatsing, onderhoud, opbouw, vorm en inhoud van digitale bibliotheken (catalogi/bases) van componenten.

2 normatieve referenties

Deze set van regels maakt gebruik van normatieve verwijzingen naar de volgende documenten:

GOST 2.303-68 Uniform systeem voor ontwerpdocumentatie. lijnen

GOST 2.306-68 Uniform systeem voor ontwerpdocumentatie. Benamingen van grafisch materiaal en regels voor hun toepassing in tekeningen

Opmerking - Bij het gebruik van deze set regels is het raadzaam om de geldigheid van referentiedocumenten in het openbare informatiesysteem te controleren - op de officiële website van het federale uitvoerende orgaan op het gebied van standaardisatie op internet of volgens de jaarlijkse informatie-index " National Standards", die op 1 januari van het lopende jaar werd gepubliceerd, en over de uitgiften van de maandelijkse informatie-index "National Standards" voor het lopende jaar. Als het document waarnaar wordt verwezen, waarnaar de ongedateerde link wordt gegeven, wordt vervangen, wordt aanbevolen de huidige versie van dit document te gebruiken, rekening houdend met alle wijzigingen die in deze versie zijn aangebracht. Als het document waarnaar wordt verwezen, waarnaar wordt verwezen, wordt vervangen, wordt aanbevolen de versie van dit document te gebruiken met het bovengenoemde goedkeuringsjaar (acceptatie). Indien, na de goedkeuring van dit reglement, een wijziging wordt aangebracht in het document waarnaar wordt verwezen waarnaar de gedateerde verwijzing wordt gegeven, die gevolgen heeft voor de bepaling waarnaar wordt verwezen, dan wordt aanbevolen deze bepaling toe te passen zonder hiermee rekening te houden verandering. Als het document waarnaar wordt verwezen wordt geannuleerd zonder vervanging, wordt aanbevolen de bepaling waarin de link ernaar wordt gegeven toe te passen in het deel dat geen invloed heeft op deze link. Het is raadzaam om de informatie over de geldigheid van de regels in het Federal Information Fund of Standards te controleren.

3 Termen en definities

In dit document worden de volgende termen en definities gebruikt:

3.1 componentattributen: Essentiële eigenschappen van een component die nodig zijn om de geometrie of kenmerken ervan te definiëren en die een naam en betekenis hebben.

3.2 geometrische componenten parameters: attributen die de grootte, vorm en ruimtelijke positie van een component bepalen.

3.3 grafische eigenschappen van een onderdeel: Eigenschappen die zorgen voor herkenbaarheid van een onderdeel in een driedimensionale projectie, maar ook in verschillende projecties en schalen met de weergave van kenmerkende tweedimensionale symbolen, lijnen, arceringen, tekst.

3.4 informatiemodellering van constructieobjecten: het proces van het creëren en gebruiken van informatie over in aanbouw zijnde, evenals voltooide constructieobjecten om invoergegevens te coördineren, gezamenlijke productie en opslag van gegevens te organiseren, evenals hun gebruik voor verschillende doeleinden in alle stadia van de levenscyclus.

3.5 onderdeel: Een digitale weergave van de fysieke en functionele kenmerken van een afzonderlijk onderdeel van een bouwplaats, bedoeld voor herhaald gebruik.

NB - Een component die in een model wordt toegepast, wordt een modelelement.

3.6 metadata van componenten: Gestructureerde gegevens die de kenmerken van een beschreven component vertegenwoordigen om deze te identificeren, op te halen, te evalueren en te beheren.

3.7 open data-uitwisselingsformaten: Dataformaten met een open specificatie.

OPMERKING - IFC-indeling (Industry Base Classes) is een gegevensindeling en schema met open specificatie. Het is een internationale standaard voor gegevensuitwisseling in informatiemodellering op het gebied van civiele techniek en operaties.

3.8 assemblage: een benoemde set componenten die opnieuw kan worden gebruikt.

3.9 niveau van uitwerking; LOD: een reeks eisen die de volledigheid van een digitaal informatiemodelelement definiëren. Het ontwikkelingsniveau specificeert de minimale hoeveelheid geometrische, ruimtelijke, kwantitatieve en alle attribuutgegevens die nodig zijn om informatiemodelleringsproblemen in een bepaalde fase van de levenscyclus van het object op te lossen.

3.10 Functioneel gedrag van een onderdeel: Het wijzigen van een onderdeel volgens de daarin vastgelegde regels van interactie met omgevingscondities.

3.11 digitaal informatiemodel: een objectgeoriënteerd parametrisch driedimensionaal model dat de fysieke, functionele en andere kenmerken van een object (of zijn afzonderlijke onderdelen) digitaal weergeeft in de vorm van een reeks informatierijke elementen.

3.12 modelelement: onderdeel van een digitaal informatiemodel dat een element, systeem of samenstel binnen een bouwplaats of bouwplaats voorstelt.

4 Algemeen

4.1 Componenten worden gekenmerkt door geometrische parameters, grafische eigenschappen, attributen en functioneel gedrag.

4.2 Componenten moeten worden gescheiden:

Per soort:

Punt - componenten met gespecificeerde geometrische vormen die aan het model worden toegevoegd met verwijzing naar hun invoegpunt.

OPMERKING Componenten zoals raam, deur, balk, kolom, pomp, meubels, enz.;

Lineair - verkregen door een gericht gesloten profiel en een referentielijn als generator te verbinden.

OPMERKING Componenten zoals wanden, buizen, kanalen, kanalen, enz.;

Areaal - volumetrische componenten van aanzienlijk lagere hoogte, gecreëerd door een contour van een beperkt gebied te tekenen.

OPMERKING Componenten zoals vloeren, daken, plafonds, enz.;

Met verwijzing naar de fabrikant:

Gegeneraliseerd - het onderdeel is een digitale weergave van een product waarvan de specifieke fabrikant onbekend is;

Product - Een component is een digitale weergave van het product van een specifieke fabrikant.

Per parametreerniveau:

Parametrische componenten - componenten waarvan de geplaatste instanties kunnen worden geconfigureerd door de attribuutwaarden in de software-interface te wijzigen (zonder de noodzaak om de component rechtstreeks te bewerken);

Niet-parametrische componenten zijn componenten die zijn gemaakt zonder de mogelijkheid van hun configuratie.

Per bereik:

Architectuur;

Stedelijke planning;

Bouwconstructie;

Technische systemen en netwerken;

Interieur en exterieur ontwerp;

Andere toepassingsgebieden.

5 Algemene vereisten voor componenten

5.1 De ontwikkeling van componenten moet worden uitgevoerd met behulp van geschikte softwaretools die functionaliteit voor informatiemodellering implementeren.

5.2 Bij het ontwikkelen van componenten moet u:

Overweeg de doelen van het gebruik van het digitale informatiemodel;

Houd rekening met de eisen voor de uitwerkingsniveaus van modelelementen;

Bepaal de samenstelling en het aantal geometrische parameters;

Bepaal de samenstelling en het aantal attributen.

6 Eisen aan geometrische parameters, niveaus van geometrische uitwerking en grafische weergave van componenten

6.1 Eisen aan geometrische parameters en grafische weergave van een component omvatten eisen voor:

Geometrische parameters;

Weergave van grafische symbolen;

Het niveau van geometrische uitwerking;

Ruimte reserveren die door een onderdeel wordt ingenomen;

Grafische weergave van materialen.

6.2 Vereisten voor geometrische parameters

6.2.1 Bij het ontwikkelen van een component moet u:

Simuleer geometrie op een schaal van 1: 1;

Definieer het invoegpunt (basispunt) voor een puntcomponent;

Gebruik het minimum aantal constructie-elementen (bijvoorbeeld constructievlakken en lijnen);

Gebruik geometrische parameters uitgedrukt in metrische eenheden.

6.2.2 Generieke componenten moeten parameterwaarden bevatten die de nominale afmetingen definiëren als de werkelijke afmetingen niet bekend zijn.

6.2.3 Componenten van het type "product" zullen parameterwaarden bevatten die de exacte afmetingen bepalen.

6.2.4 Voorwaarde voor de weergave van grafische symbolen:

het onderdeel moet grafische elementen bevatten om informatie over te brengen die niet in een driedimensionale projectie kan worden weergegeven (bijvoorbeeld richtingaanwijzers, de openingsrichting van deuren, manieren om ramen te openen).

6.3 Eisen aan het niveau van geometrische uitwerking

6.3.1 De invoegpunten (basispunten) van een component moeten consistent zijn op alle ontwikkelingsniveaus.

6.4 Vereisten voor grafische weergave van materialen

6.4.1 Als een afbeelding het oppervlak van een component moet vullen, moet deze vierkant of rechthoekig zijn om een naadloze herhaling van de afbeelding (tegels) mogelijk te maken.

6.4.2 Eisen aan het bestand met de afbeelding van het materiaal:

De grootte van vierkante afbeeldingen is minimaal 512x512 pixels;

Grootte van rechthoekige afbeeldingen - minimaal 512 pixels langs de langste zijde;

Beeldresolutie - niet minder dan 150 dots per inch.

7 Vereisten voor het niveau van attributie en attribuutwaarden

7.1 Bij het ontwikkelen van componenten dient het aantal, de samenstelling van attributen en het niveau van attributieve uitwerking te worden bepaald rekening houdend met:

Doelen en doelstellingen van het gebruik van digitale informatiemodellen;

LOD-vereisten;

Eisen aan de samenstelling en inhoud van technische documentatie.

7.2 Alle aangemaakte componentattributen moeten worden ingevuld.

7.3 Componentattributen moeten worden onderverdeeld in verplicht en optioneel.

7.3.1 De verplichte attributen van een component dienen die eigenschappen of technische kenmerken te omvatten die het mogelijk maken het component uniek te identificeren, en ook gegevens bevatten op basis waarvan het mogelijk is om technische documentatie te ontwikkelen, een specifiek component te bestellen, te kopen en te installeren tijdens het bouwproces.

7.3.2 Aanvullende attributen dienen eigenschappen of technische kenmerken te omvatten die vereist zijn voor technische berekeningen, informatie van technische en economische aard, technische en operationele en andere kenmerken.

7.4 Als parameterwaarden de geometrische grootte of vorm van een component moeten bepalen, zou het wijzigen ervan de grootte en/of vorm van de component in het model moeten veranderen.

7.5 Als de waarde van het attribuut niet beperkt is en de mogelijkheid biedt om zowel cijfers als letters in te voeren, dan zal aan de waarde van het attribuut een alfanumeriek gegevenstype worden toegewezen.

7.6 De waarde van een tekstattribuut van een component mag niet eindigen met een punt.

8 Functionele eisen aan componenten

8.1 Een component "draagt" zich op een manier die zijn functionaliteit en onderlinge relaties met andere componenten weerspiegelt.

8.2 In een software-omgeving is het in de regel mogelijk om een component te ontwerpen met een of ander aantal vooraf gedefinieerde vaste parameters die beschikbaar zijn in een echt fysiek bouwelement. Als er voorgeconfigureerde varianten van een component zijn, zou de prestatievermindering of de moeilijkheid om deze te gebruiken minimaal moeten zijn.

8.3 Een component moet zo worden gemodelleerd dat deze kan worden verbonden met en kan functioneren in combinatie met andere componenten als interoperabiliteit wordt ondersteund en in overeenstemming is met de doelstellingen van het model dat wordt ontwikkeld.

9 Regels voor het benoemen van componenten en hun attributen

9.1 De naamgevingsconventies voor componenten in deze sectie zijn bedoeld voor software op basis van een bestandsopslagsysteem.

9.2 Het naamgevingssysteem moet bestaan uit:

Algemene naamgevingsregels;

Naamgevingsschema's.

OPMERKING - Een voorbeeld van een bestandsnaamgevingssysteem voor componenten wordt gegeven in A.15-A.16 (bijlage A).

9.3 Een onderdeel moet een unieke naam en omschrijving hebben.

9.4 Regels voor het benoemen van attributen

9.4.1 Maateenheden worden niet aangegeven in de attribuutnaam.

9.4.2 Attributen met waarden die booleaanse gegevenstypen impliceren (Ja / Nee) moeten zo worden genoemd dat de waarde noodzakelijkerwijs wordt toegewezen (bijvoorbeeld "Sill Presence" - Ja / Nee).

OPMERKING - Een voorbeeld van regels voor het benoemen van attributen wordt gegeven in A.17 (Bijlage A).

9.5 Naamgevingsconventies voor materialen

9.5.1 De naam van een materiaal moet beginnen met een hoofdletter gevolgd door een kleine letter. Als de naam uit twee of meer woorden bestaat, begint elk woord met een hoofdletter en worden alle woorden samen geschreven.

9.5.2 Het bestand met de afbeelding van het materiaal wordt op dezelfde manier genoemd als voor het materiaal, met de extensie die overeenkomt met het formaat van het gebruikte grafische bestand.

OPMERKING - Een voorbeeld van regels voor het benoemen van materialen wordt gegeven in A.18 (bijlage A).

10 Vereisten voor componentformaten

10.1 Door bestandsindelingen kunnen componenten worden weergegeven:

In open IFC-formaat (versies 2x3 en hoger);

In originele formaten (bestandsformaten van componenten en projectbestanden van de gebruikte software).

11 Vereisten voor metagegevens van componenten

11.1 Bij het organiseren van databases / catalogi / bibliotheken van componenten, bijvoorbeeld in de vorm van internetopslag, is het noodzakelijk om de vereiste inhoud gemakkelijk te kunnen zoeken. Meestal wordt deze zoekopdracht uitgevoerd met behulp van metadata. Zoeken op metadata - zoeken op kenmerken van een component die wordt ondersteund door een specifieke zoekmachine.

Bijlage A

A.1 Componenten kunnen worden gecombineerd tot assemblages (bijvoorbeeld "sanitair", "verwarmingseenheid", "transformatorstation"), die worden aanbevolen om te worden gebruikt om thematische catalogi / databases / bibliotheken voor hergebruik te vormen.

A.2 Het onderdeel moet uniek worden geïdentificeerd. Hiervoor wordt aanbevolen om te gebruiken:

Unieke naam;

Wereldwijd unieke identificatie die wordt gebruikt om bronnen te identificeren;

Classificatiecode (indien aanwezig).

A.3 Om het aantal componenten dat wordt ontwikkeld te minimaliseren en te verenigen, wordt aanbevolen om parametrische componenten te creëren.

Om te voldoen aan de vereisten van ESKD- en SPDS-normen (bijvoorbeeld GOST 2.303 en GOST 2.306) voor de ontwerp- en werkdocumentatie, wordt bij het ontwikkelen van een component aanbevolen om conventionele grafische symbolen in de samenstelling op te nemen.

Opmerking - Componenten op het LOD 100-ontwikkelingsniveau zijn conceptuele massa-elementen en behoeven als zodanig geen voorafgaande voorbereiding van de corresponderende componenten, en op het LOD 500-niveau zijn het volledig gedefinieerde componenten die alleen qua afmetingen verschillen van het LOD 400-niveau die overeenkomen met de daadwerkelijke uitvoering van de ontwerpbeslissingen. Om deze redenen worden LOD-ontwikkelingsniveaus van 200, 300 en 400 aanbevolen voor de ontwikkeling van databases / bibliotheken / catalogi van componenten.

OPMERKING Als er geen geschikte componenten van een laag niveau zijn, mogen componenten van een hoger niveau worden gebruikt.

A.8 Het wordt aanbevolen om bij het ontwerp van de componenten van de engineering/procesapparatuur rekening te houden met de gereserveerde onderhoudsruimte, die wordt aanbevolen als onderdeel van de component.

A.9 Als het nodig is om een component met een specifiek materiaal te ontwikkelen, is het aan te raden om kleuren, arcering/opvulpatronen en bestanden met een textuurafbeelding in de juiste schaal op te nemen.

A.12 De waarde van een componentattribuut kan worden uitgedrukt als een formule als de waarde ervan afhangt van andere attributen.

A.13 Als een component verschillende varianten van een element van een constructieobject kan vertegenwoordigen, wordt aanbevolen om deze weer te geven met een attribuut met een waarde die op een van de volgende manieren wordt uitgedrukt:

De enige waarde is als er maar één keuze is voor de waarde;

Lijstwaarde - als de geordende lijst meerdere unieke waarden van hetzelfde type bevat, waarvan de volgorde belangrijk is (bijvoorbeeld 200, 400, 600, 800);

Bereikwaarde - als er boven- en ondergrenzen zijn van deze waarde (limiet). Eerst wordt de ondergrens aangegeven, gevolgd door de bovengrens (bijv. 175-200 kW). Als het waardenbereik positieve en negatieve waarden bevat, worden deze gescheiden met de woorden "van" en "tot" (bijvoorbeeld van min 10 ° C tot plus 20 ° C). Als er geen waarde is opgegeven, betekent dit een onbeperkte limiet (bijvoorbeeld 175 kW -<ноль>, d.w.z. alle waarden zijn groter dan of gelijk aan de onderste grenswaarde van 175 kW);

Genummerde waarde - als de waarde voorziet in de selectie van vaste waarden uit de vastgestelde lijst. Losse elementen moeten van elkaar worden gescheiden door een komma en een spatie (bijvoorbeeld a, b, c, d).

Opmerking - Deze methoden voor het uitdrukken van verschillende varianten van elementen van een constructieobject worden in de regel gebruikt in componenten van het "gegeneraliseerde" type.

A.14 Het verdient aanbeveling om een onderdeel zo te modelleren dat het met andere onderdelen kan worden verbonden en in samenhang daarmee kan functioneren, als de gezamenlijke werking wordt ondersteund en overeenkomt met de doelstellingen van het ontwikkelde model.

De bestandsnaam bestaat uit velden;

Het wordt aanbevolen om het onderstrepingsteken "_" te gebruiken als scheidingsteken tussen velden;

Alle velden in een bestandsnaam beginnen met een hoofdletter gevolgd door een kleine letter. Als het veld uit twee of meer woorden bestaat, begint elk woord met een hoofdletter en worden alle woorden samen geschreven;

Afkortingen en codes moeten in hoofdletters worden geschreven;

A.16 Component bestandsnaamstructuur

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

waarbij de velden de betekenis hebben die is gegeven in Tabel A.1.

Tabel A.1

Als het onderdeel geen 3D-geometrie bevat, voegt u aan het einde van "Velden2" (functioneel type) "-2D" toe.

Notities (bewerken)

1 Het aantal velden in de bestandsnaam kan variëren van vier tot zes, afhankelijk van het type component (type "generiek" of "product"), evenals de aanwezigheid van aanvullende identificerende kenmerken.

2 Een voorbeeld van het benoemen van componenten van het type "generieke":

ABV_Door_Double_Aluminium_GOST23747-2015

3 Een voorbeeld van het benoemen van componenten van het type "product":

ABC_Wasbasin_Ceramic_Factory1_VersionA

Als u extra velden moet invoeren, is het raadzaam deze aan het einde van de naam toe te voegen.

A.17 Naamgevingsregels voor attributen

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

waarbij de velden de volgende betekenissen hebben zoals gegeven in Tabel A.2

Tabel A.2

OPMERKING - Voorbeelden van het benoemen van attributen:

Profielbreedte

ABC_AreaApartments