Construir: um guia para construção e design. Discussão pública de códigos de prática (SP) sobre modelagem de informação BIM Sp na construção

Antes de enviar uma inscrição eletrônica ao Ministério da Construção da Rússia, leia as regras de funcionamento deste serviço interativo descritas abaixo.

1. As inscrições eletrônicas na área de competência do Ministério da Construção da Rússia, preenchidas de acordo com o formulário anexo, são aceitas para consideração.

2. O recurso eletrónico pode conter declaração, reclamação, proposta ou pedido.

3. Os recursos eletrónicos enviados através do portal oficial da Internet do Ministério da Construção da Rússia são submetidos à apreciação do departamento de tratamento dos recursos dos cidadãos. O Ministério fornece uma análise objetiva, abrangente e oportuna das candidaturas. A consideração de recursos eletrônicos é gratuita.

4. De acordo com a Lei Federal de 2 de maio de 2006 N 59-FZ "Sobre o procedimento para considerar solicitações de cidadãos da Federação Russa", as solicitações eletrônicas são registradas no prazo de três dias e enviadas, dependendo do conteúdo, para o estrutural divisões do Ministério. O recurso é considerado no prazo de 30 dias a partir da data do registro. Um recurso eletrônico contendo questões cuja solução não é da competência do Ministério da Construção da Rússia é enviado no prazo de sete dias a partir da data de registro ao órgão apropriado ou ao funcionário apropriado, cuja competência inclui a resolução das questões levantadas em o recurso, com notificação do mesmo ao cidadão que enviou o recurso.

5. O recurso eletrónico não é apreciado quando:
- a ausência do nome e apelido do requerente;
- indicação de endereço postal incompleto ou impreciso;
- a presença de expressões obscenas ou ofensivas no texto;
- a presença no texto de ameaça à vida, à saúde e ao patrimônio de um funcionário, bem como de seus familiares;
- usar um layout de teclado não cirílico ou apenas letras maiúsculas ao digitar;
- ausência de sinais de pontuação no texto, presença de abreviaturas incompreensíveis;
- a presença no texto de questão para a qual o requerente já tenha recebido resposta escrita sobre o mérito em relação a recursos anteriormente enviados.

6. A resposta ao requerente do recurso é enviada para o endereço postal indicado no preenchimento do formulário.

7. Na apreciação do recurso não é permitida a divulgação das informações constantes do recurso, bem como das informações relativas à vida privada do cidadão, sem o seu consentimento. As informações sobre os dados pessoais dos candidatos são armazenadas e processadas em conformidade com os requisitos da legislação russa sobre dados pessoais.

8. Os recursos recebidos através do site são resumidos e submetidos à chefia do Ministério para informação. As respostas às perguntas mais frequentes são publicadas periodicamente nas secções “para residentes” e “para especialistas”

Aprovado Ordem do Ministério da Construção e Habitação e Serviços Comunais da Federação Russa de 15 de dezembro de 2017 N 1674/pr

Código de Prática SP-328.1325800.2017

“MODELAGEM DE INFORMAÇÃO NA CONSTRUÇÃO. REGRAS PARA DESCRIÇÃO DOS COMPONENTES DO MODELO DE INFORMAÇÃO”

modelagem de informações de construção. componentes. Diretrizes e requisitos

Apresentado pela primeira vez

Introdução

Este conjunto de normas foi desenvolvido de acordo com a Lei Federal de 30 de dezembro de 2009 N 384-FZ “Regulamento Técnico de Segurança de Edifícios e Estruturas” com o objetivo de desenvolver requisitos, regras e recomendações uniformes para a criação de componentes utilizados para formar modelos de informação de um objeto de construção.

O conjunto de regras foi elaborado pela equipe de autores do JSC "Centro de Pesquisa "Construção" - TsNIISK em homenagem a V.A. Kucherenko (orientador - Doutor em Ciências Técnicas I.I. Vedyakov; Candidato em Ciências Técnicas Yu.N. Zhuk, A.V. Ananiev) e OOO "KONKURATOR" (M.G. Korol, S.E. Benklyan).

1 área de uso

1.1 Este conjunto de regras aplica-se aos processos de modelação de informação de edifícios e estruturas e estabelece requisitos para os componentes dos seus modelos de informação.

1.2 Este conjunto de regras não estabelece requisitos para os métodos de colocação, manutenção, estrutura, forma e conteúdo de bibliotecas digitais (catálogos/bancos de dados) de componentes.

2 Referências normativas

Este conjunto de regras utiliza referências normativas aos seguintes documentos:

GOST 2.303-68 Sistema unificado para documentação de projeto. linhas

GOST 2.306-68 Sistema unificado para documentação de projeto. Designações de materiais gráficos e regras para sua aplicação em desenhos

Nota - Ao utilizar este conjunto de regras, é aconselhável verificar a validade dos documentos de referência no sistema de informações públicas - no site oficial do órgão executivo federal na área de normalização na Internet ou de acordo com o índice anual de informações " Normas Nacionais”, que foi publicada a partir de 1º de janeiro do corrente ano, e de acordo com as edições do índice de informação mensal “Normas Nacionais” do ano em curso. Se um documento referenciado sem data tiver sido substituído, recomenda-se que seja utilizada a versão atual desse documento, tendo em conta quaisquer alterações efetuadas nessa versão. Caso o documento referenciado seja substituído por uma referência datada, recomenda-se que seja utilizada a versão deste documento com o ano de aprovação (aceitação) indicado acima. Se, após a aprovação deste conjunto de regras, for feita uma alteração ao documento referenciado ao qual é dada referência datada, afetando a disposição a que é dada a referência, recomenda-se que esta disposição seja aplicada sem ter em conta este mudar. Se o documento de referência for cancelado sem substituição, recomenda-se que a disposição que contém o link para ele seja aplicada na parte que não afeta esse link. É aconselhável verificar as informações sobre o funcionamento dos conjuntos de normas no Federal Information Fund of Standards.

3 Termos e definições

Neste documento são utilizados os seguintes termos com suas respectivas definições:

3.1 atributos do componente: Propriedades essenciais de um componente que são necessárias para definir sua geometria ou características e possuem um nome e um valor.

3.2 geometria do componente: Atributos que definem o tamanho, forma e posição espacial de um componente.

3.3 propriedades gráficas de um componente: Propriedades que garantem o reconhecimento de um componente em uma projeção tridimensional, bem como em diversas projeções e escalas com exibição de símbolos bidimensionais característicos, linhas, hachuras, texto.

3.4 modelagem de informações de construção: O processo de criação e uso de informações sobre projetos de construção em construção e concluídos, a fim de coordenar dados de entrada, organizar a produção conjunta e armazenamento de dados, bem como seu uso para diversos fins em todas as fases da vida. ciclo.

3.5 componente: Representação digital das características físicas e funcionais de um único elemento de um objeto de construção, destinado a uso repetido.

Nota – Um componente aplicado a um modelo torna-se um elemento do modelo.

3.6 metadados do componente: Dados estruturados que representam as características do componente descrito para identificação, busca, avaliação e gerenciamento do mesmo.

3.7 formatos abertos de intercâmbio de dados: Formatos de dados com especificação aberta.

NOTA Formato IFC (Industry Base Classes) e esquema de dados com especificação aberta. É um padrão internacional para troca de dados em modelagem de informações na área de engenharia civil e operações.

3.8 montagem: Um conjunto nomeado de componentes destinados a serem reutilizados.

3,9 nível de desenvolvimento; LOD: Um conjunto de requisitos que determina a integralidade do desenvolvimento de um elemento de um modelo de informação digital. O nível de desenvolvimento define a quantidade mínima de dados geométricos, espaciais, quantitativos, bem como quaisquer dados atributivos necessários para resolver problemas de modelagem de informação em um estágio específico do ciclo de vida do objeto.

3.10 comportamento funcional de um componente: Modificação de um componente de acordo com suas regras de interação com o ambiente.

3.11 modelo de informação digital: Um modelo tridimensional paramétrico orientado a objetos que representa digitalmente as características físicas, funcionais e outras de um objeto (ou de suas partes individuais) na forma de um conjunto de elementos ricos em informações.

3.12 elemento do modelo: Parte de um modelo de informação digital que representa um elemento, sistema ou montagem dentro de um canteiro de obras ou local.

4 Disposições gerais

4.1 Os componentes são caracterizados por parâmetros geométricos, propriedades gráficas, atributos e comportamento funcional.

4.2 Os componentes devem ser separados:

Por tipos:

Ponto - componentes com formas geométricas especificadas, adicionados ao modelo com referência ao seu ponto de inserção.

NOTA Componentes como janela, porta, viga, coluna, bomba, móveis, etc.;

Linear - obtido conectando um perfil direcional fechado e uma linha de referência como geratriz.

NOTA Componentes como paredes, tubulações, dutos, dutos de cabos, etc.;

Areal - componentes tridimensionais, muito menores em altura, criados desenhando o contorno de uma área limitada.

NOTA Componentes como pisos, telhados, tetos, etc.;

De acordo com o fabricante:

Generalizado - um componente é uma representação digital de um produto cujo fabricante específico é desconhecido;

Um produto componente é uma representação digital do produto de um fabricante específico.

Por nível de parametrização:

Componentes paramétricos - componentes cujas instâncias colocadas podem ser configuradas alterando os valores dos atributos na interface do software (sem a necessidade de edição direta do componente);

Componentes não paramétricos são componentes criados sem possibilidade de configuração.

Por escopo:

Arquitetura;

Planejamento urbano;

Construção civil;

Sistemas e redes de engenharia;

Design de interiores e exteriores;

Outras áreas de aplicação.

5 Requisitos gerais para componentes

5.1 O desenvolvimento de componentes deve ser realizado utilizando ferramentas de software adequadas que implementem a funcionalidade de modelagem de informação.

5.2 Ao desenvolver componentes, você deve:

Considerar a finalidade da utilização do modelo de informação digital;

Ter em conta os requisitos para os níveis de elaboração dos elementos do modelo;

Determinar a composição e número de parâmetros geométricos;

Determine a composição e o número de atributos.

6 Requisitos para parâmetros geométricos, níveis de detalhe geométrico e exibição gráfica de componentes

6.1 Os requisitos para os parâmetros geométricos e exibição gráfica do componente incluem requisitos para:

Parâmetros geométricos;

Exibição de símbolos gráficos;

O nível de elaboração geométrica;

Reservando o espaço ocupado pelo componente;

Exibição gráfica de materiais.

6.2 Requisitos geométricos

6.2.1 Ao desenvolver um componente, você deve:

Geometria do modelo em escala 1:1;

Definir o ponto de inserção (ponto base) para um componente do tipo “ponto”;

Utilize o número mínimo de elementos auxiliares (por exemplo, planos e linhas auxiliares);

Use parâmetros geométricos expressos em unidades métricas.

6.2.2 Os componentes do tipo “genérico” devem incluir valores de parâmetros que definam as dimensões nominais caso as dimensões reais não sejam conhecidas.

6.2.3 Os componentes do tipo “produto” devem incluir valores de parâmetros especificando dimensões precisas.

6.2.4 Requisito para exibição de símbolos gráficos:

o componente deve incluir elementos gráficos para transmitir informações que não podem ser exibidas em uma projeção tridimensional (por exemplo, indicadores de direção, lado de abertura de porta, métodos de abertura de janela).

6.3 Requisitos para o nível de desenvolvimento geométrico

6.3.1 Os pontos de inserção (pontos base) do componente devem ser iguais em todos os níveis de desenvolvimento.

6.4 Requisitos para exibição gráfica de materiais

6.4.1 Se uma imagem precisar preencher a superfície de um componente, ela deverá ter formato quadrado ou retangular para garantir uma repetição contínua da imagem (na forma de mosaico).

6.4.2 Requisitos para um arquivo de imagem de material:

O tamanho das imagens quadradas é de pelo menos 512x512 pixels;

O tamanho das imagens retangulares é de pelo menos 512 pixels no lado mais longo;

Resolução da imagem - pelo menos 150 dpi.

7 Requisitos para o nível de elaboração atributiva e valores dos atributos

7.1 No desenvolvimento de componentes, o número, a composição dos atributos e o nível de elaboração atributiva devem ser determinados levando em consideração:

Metas e objetivos da aplicação de modelos de informação digital;

Requisitos de LOD;

Requisitos para a composição e conteúdo da documentação técnica.

7.2 Todos os atributos dos componentes gerados deverão ser preenchidos.

7.3 Os atributos dos componentes devem ser divididos em obrigatórios e opcionais.

7.3.1 Os atributos obrigatórios de um componente devem incluir propriedades ou características técnicas que permitam que o componente seja identificado de forma única, e também conter dados com base nos quais seja possível desenvolver documentação técnica, solicitar, comprar e instalar um componente específico durante construção.

7.3.2 Atributos adicionais deverão incluir propriedades ou características técnicas necessárias para cálculos de engenharia, informações técnicas e econômicas, características técnicas e operacionais e outras.

7.4 Se os valores dos parâmetros devem controlar o tamanho ou forma geométrica de um componente, alterá-los deve alterar o tamanho e/ou forma do componente no modelo.

7.5 Se um valor de atributo for irrestrito e permitir a inserção de dígitos e letras, então ao valor do atributo será atribuído um tipo de dados alfanumérico.

7.6 O valor de um atributo de texto de um componente não deve terminar com ponto.

8 Requisitos funcionais para componentes

8.1 Um componente deve “comportar-se” de uma forma que reflita sua funcionalidade e seu relacionamento com outros componentes.

8.2 Em um ambiente de software, geralmente é possível desenvolver um componente com tantos parâmetros fixos predefinidos quanto o próprio elemento físico da construção. Com variantes pré-configuradas de um componente, a degradação do desempenho ou a dificuldade de uso devem ser mínimas.

8.3 Um componente deve ser modelado de tal forma que possa ser conectado e operar em conjunto com outros componentes, se a coexistência for apoiada e consistente com os objetivos do modelo que está sendo desenvolvido.

9 Convenções de nomenclatura para componentes e seus atributos

9.1 As regras de nomenclatura de componentes fornecidas nesta seção destinam-se a software baseado em um sistema de armazenamento de arquivos.

9.2 O sistema de nomenclatura deve consistir em:

Regras gerais de nomenclatura;

Esquemas de nomenclatura.

NOTA Um exemplo de sistema de nomenclatura de arquivos de componentes é fornecido em A.15-A.16 (Anexo A).

9.3 O componente deve ter nome e descrição exclusivos.

9.4 Regras de nomenclatura de atributos

9.4.1 As unidades de medida não são especificadas no nome do atributo.

9.4.2 Atributos com valores que assumem tipos de dados booleanos (Sim/Não) devem ser nomeados de forma que necessariamente seja atribuído um valor (ex. “Presença Windowsill” – Sim/Não).

NOTA Um exemplo de convenções de nomenclatura de atributos é dado em A.17 (Anexo A).

9.5 Convenções de nomenclatura de materiais

9.5.1 O nome do material deve começar com letra maiúscula seguida de letra minúscula. Se o nome consistir em duas ou mais palavras, cada palavra começará com uma letra maiúscula e todas as palavras serão escritas juntas.

9.5.2 O arquivo com a imagem do material recebe o mesmo nome do material, com extensão correspondente ao formato do arquivo gráfico aplicado.

NOTA Um exemplo de regras de nomenclatura de materiais é dado em A.18 (Apêndice A).

10 Requisitos de formato de componente

10.1 Em termos de formatos de arquivo, os componentes podem ser representados por:

Em formato IFC aberto (versão 2x3 e superior);

Em formatos originais (formatos de arquivos de componentes e formatos de arquivos de projetos de software).

11 Requisitos de metadados de componentes

11.1 Ao organizar bancos de dados/catálogos/bibliotecas de componentes, por exemplo, na forma de armazenamentos online, é necessário fornecer uma busca conveniente pelo conteúdo necessário. Via de regra, essa pesquisa é realizada por meio de metadados. Pesquisa por metadados - pesquisa por atributos de componentes suportados por um mecanismo de pesquisa específico.

Anexo A

A.1 Os componentes podem ser combinados em conjuntos (por exemplo, “cabine sanitária”, “unidade de calor”, “subestação transformadora”), que são recomendados para serem utilizados para formar catálogos/bancos de dados/bibliotecas de reaproveitamento temáticos.

A.2 O componente deve ser identificado de forma única. Para isso é recomendado usar:

Nome único;

Um identificador globalmente exclusivo usado para identificar recursos;

Código do classificador (se houver).

A.3 Para minimizar o número de componentes desenvolvidos e sua unificação, recomenda-se a criação de componentes paramétricos.

Para cumprir os requisitos dos padrões ESKD e SPDS (por exemplo, GOST 2.303 e GOST 2.306) para a preparação de projeto e documentação de trabalho, é recomendado incluir símbolos gráficos convencionais em sua composição ao desenvolver um componente.

Nota - Os componentes no nível de projeto LOD 100 são elementos de construção conceituais e como tal não requerem preparação prévia dos componentes correspondentes, e no nível LOD 500 são componentes totalmente definidos que diferem do nível LOD 400 apenas nas dimensões que correspondem ao execução real das decisões de projeto. Por essas razões, os níveis de LOD 200, 300 e 400 são recomendados para desenvolvimento de banco de dados/biblioteca/catálogo de componentes.

Nota - Na ausência de componentes correspondentes de nível de desenvolvimento inferior, é permitida a utilização de componentes de nível superior.

A.8 Recomenda-se que componentes de equipamentos de engenharia/processo sejam projetados levando em consideração a reserva de espaço para manutenção, que é recomendado ser incluído como parte do componente.

A.9 Se você precisar projetar um componente com um material específico, é recomendado incluir cores, padrões de hachura/preenchimento e arquivos de imagem de textura na escala apropriada.

A.12 O valor de um atributo de um componente pode ser expresso como uma fórmula, caso seu valor dependa de outros atributos.

A.13 Se um componente puder representar diferentes instâncias de um item de construção, recomenda-se que sejam representados por um atributo com um valor expresso de uma das seguintes formas:

Valor único – se houver uma única escolha para o valor;

Valor da lista - se a lista ordenada contém vários valores únicos do mesmo tipo, cuja ordem é importante (por exemplo, 200, 400, 600, 800);

Valor do intervalo - se existem limites superior e inferior para este valor (limite). Primeiro é indicado o limite inferior e depois o superior (por exemplo, 175-200 kW). Se a faixa de valores incluir valores positivos e negativos, eles serão separados usando as palavras "de" e "para" (por exemplo, de menos 10°C a mais 20°C). Se o valor não for especificado, significa um limite ilimitado (por exemplo, 175 kW -<ноль>, ou seja todos os valores maiores ou iguais ao valor limite inferior de 175 kW);

Valor numerado - se o valor prevê a escolha de valores fixos da lista estabelecida. Os elementos individuais devem ser separados uns dos outros por uma vírgula e um espaço (por exemplo, a, b, c, d).

Nota - Estas formas de expressar as diversas opções dos elementos do objeto de construção, via de regra, são utilizadas em componentes do tipo “generalizado”.

A.14 Recomenda-se que um componente seja modelado de tal forma que possa ser conectado e cooperar com outros componentes, se a coexistência for apoiada e consistente com os objetivos do modelo que está sendo desenvolvido.

O nome do arquivo consiste em campos;

Recomenda-se utilizar o sublinhado “_” como caractere separador entre os campos;

Todos os campos em um nome de arquivo começam com uma letra maiúscula seguida por uma letra minúscula. Se o campo consistir em duas ou mais palavras, cada palavra começará com uma letra maiúscula e todas as palavras serão escritas juntas;

As abreviaturas e códigos devem ser escritos em letras maiúsculas;

A.16 Estrutura de nomes de arquivos de componentes

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

onde os campos têm os significados dados na Tabela A.1.

Tabela A.1

Se o componente não contiver geometria 3D, "Campo2" (tipo funcional) deverá ser anexado com "-2D" no final.

Notas

1 O número de campos no nome do arquivo pode variar de quatro a seis, dependendo do tipo de componente (genérico ou tipo de produto), bem como da presença de recursos adicionais de identificação.

2 Um exemplo de nomenclatura de componentes do tipo "genérico":

ABV_Porta_Folha Dupla_Alumínio_GOST 23747-2015

3 Um exemplo de nomenclatura de componentes do tipo "produto":

ABV_Washbasin_Ceramic_Factory1_VersionA

Se precisar inserir campos adicionais, é recomendável adicioná-los no final do nome.

A.17 Regras de nomenclatura de atributos

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

onde os campos têm os seguintes significados dados na Tabela A.2

Tabela A.2

Nota - Exemplos de nomenclatura de atributos:

Largura do perfil

ABC_SquareApartamentos

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

onde os campos têm os seguintes significados dados na Tabela A.3

Tabela A.3

Nota - Um exemplo de nomenclatura de materiais:

ABC_Tile_Bitumen_Continent_Manufacturer

Antes de enviar uma inscrição eletrônica ao Ministério da Construção da Rússia, leia as regras de funcionamento deste serviço interativo descritas abaixo.

1. As inscrições eletrônicas na área de competência do Ministério da Construção da Rússia, preenchidas de acordo com o formulário anexo, são aceitas para consideração.

2. O recurso eletrónico pode conter declaração, reclamação, proposta ou pedido.

3. Os recursos eletrónicos enviados através do portal oficial da Internet do Ministério da Construção da Rússia são submetidos à apreciação do departamento de tratamento dos recursos dos cidadãos. O Ministério fornece uma análise objetiva, abrangente e oportuna das candidaturas. A consideração de recursos eletrônicos é gratuita.

4. De acordo com a Lei Federal de 2 de maio de 2006 N 59-FZ "Sobre o procedimento para considerar solicitações de cidadãos da Federação Russa", as solicitações eletrônicas são registradas no prazo de três dias e enviadas, dependendo do conteúdo, para o estrutural divisões do Ministério. O recurso é considerado no prazo de 30 dias a partir da data do registro. Um recurso eletrônico contendo questões cuja solução não é da competência do Ministério da Construção da Rússia é enviado no prazo de sete dias a partir da data de registro ao órgão apropriado ou ao funcionário apropriado, cuja competência inclui a resolução das questões levantadas em o recurso, com notificação do mesmo ao cidadão que enviou o recurso.

5. O recurso eletrónico não é apreciado quando:
- a ausência do nome e apelido do requerente;
- indicação de endereço postal incompleto ou impreciso;
- a presença de expressões obscenas ou ofensivas no texto;
- a presença no texto de ameaça à vida, à saúde e ao patrimônio de um funcionário, bem como de seus familiares;
- usar um layout de teclado não cirílico ou apenas letras maiúsculas ao digitar;
- ausência de sinais de pontuação no texto, presença de abreviaturas incompreensíveis;
- a presença no texto de questão para a qual o requerente já tenha recebido resposta escrita sobre o mérito em relação a recursos anteriormente enviados.

6. A resposta ao requerente do recurso é enviada para o endereço postal indicado no preenchimento do formulário.

7. Na apreciação do recurso não é permitida a divulgação das informações constantes do recurso, bem como das informações relativas à vida privada do cidadão, sem o seu consentimento. As informações sobre os dados pessoais dos candidatos são armazenadas e processadas em conformidade com os requisitos da legislação russa sobre dados pessoais.

8. Os recursos recebidos através do site são resumidos e submetidos à chefia do Ministério para informação. As respostas às perguntas mais frequentes são publicadas periodicamente nas secções “para residentes” e “para especialistas”

28 de maio de 2018 Tatyana Bekh

GOST e SP em BIM

Decidimos coletar uma lista de documentos normativos que regulamentam os rumos da tecnologia da informação na construção. Aqui está o que foi encontrado em dias de hoje!

Lista de documentos normativos sobre BIM:

• GOST R 57310 -2016 (ISO 29481 -1:2010) Modelagem de informações na construção. Guia de entrega de informações. Metodologia e formato. Data de introdução 2017 —07 —01
• GOST R 57311-2016 Modelagem de informações na construção. Requisitos para operacional documentação de objetos de construção concluída . Data de introdução 2017 —07 —01
• GOST R 57309-2016 (ISO 16354:2013) Diretrizes para bibliotecas de conhecimento e bibliotecas de objetos. Data de introdução 01/07/2017 .
• GOST R 57563 -2017 / ISO / TS 12911: 2012 Modelagem de informações na construção. Diretrizes para o desenvolvimento de padrões informativo modelagem de edifícios e estruturas (conforme alterada). Data de introdução 2017 -10 -01 .
• GOST R ISO 12006-2-2017 Construção. Um modelo para organização de dados de obras. Parte 2 . Fundamentos da Classificação da Informação. Data de introdução 2017 -10 -01 .
• GOST R ISO 12006-3-2017 Construção. Um modelo para organização de dados de obras. Parte 3 . Fundamentos da troca de objetos - orientado Informação . Data de introdução 2017 —10 —01
• GOST R ISO 22263-2017 Modelo de organização de dados de construção. Estrutura de gerenciamento de informações de projeto. Data de introdução 2017 -10 -01 .
• GOST R 57295-2016 Sistemas de gerenciamento de projeto. Guia para gerenciamento de projetos na construção. Data de introdução 2018 -01 -01 .
• SP 301 .1325800 .2017 Modelagem de informações na construção. Regras de organização do trabalho Produção- departamentos técnicos. Data de introdução 2018 -03 -02 .

Atualizado em 23/03/2018. COM Em março de 2018, três conjuntos de regras (SP) para BIM entram em vigor:

• SP 328.1325800.2017 “Modelagem de informação na construção. Normas de descrição dos componentes do modelo de informação” (Despacho n.º 1674/pr de 15 de dezembro de 2017). Este conjunto de regras aplica-se aos processos de modelação de informação de edifícios e estruturas e estabelece requisitos para os componentes dos seus modelos de informação, mas não estabelece requisitos para os métodos de colocação, manutenção, estrutura, forma e conteúdo das bibliotecas digitais (catálogos/ bancos de dados) de componentes. O documento entrará em vigor em 16 de junho de 2018.
• SP 331.1325800.2017 “Modelagem de informação na construção. Regras para a troca entre modelos de informação de objetos e modelos utilizados em sistemas de software” (Despacho n.º 1230/pr de 18 de setembro de 2017). A SP 331.1325800.2017 baseia-se nos requisitos básicos para a criação e operação de sistemas de informação que interagem entre si ao longo de todo o ciclo de vida de um edifício ou estrutura e implementam a tecnologia de modelagem de informação de um objeto de construção. O conjunto de regras entrou em vigor em 19 de março de 2018.
• SP 333.1325800.2017 “Modelagem de informação na construção. Regras para a formação de um modelo de informação de objetos nas diversas fases do ciclo de vida” (Despacho n.º 1227/pr de 18 de setembro de 2017). O documento contém requisitos para modelos de informação de instalações de construção em massa e seu desenvolvimento nas diversas fases do ciclo de vida, visando melhorar a validade e qualidade das soluções de projeto, aumentando o nível de segurança durante a construção e operação. Abordagens gerais para a formação de modelos de informação garantirão sua facilidade de uso e aumentarão a eficiência do processo de modelagem de informação. O conjunto de regras entrou em vigor em 19 de março de 2018.

Num futuro próximo, temos a promessa de expandir a documentação regulamentar e técnica do BIM em duas direções:

Documentos Básicos:

• 3 GOST R.
• 4 joint ventures

Documentos para diferentes fases do ciclo de vida de um objeto

• 2 GOST R.
• 6 joint ventures

Não se esqueça que hoje existem duas categorias de documentos normativos.

De acordo com alguns links, ainda é possível fazer download dos textos das minutas dos documentos. Outra forma garantida de obter os textos é enviar uma solicitação para o endereço: [e-mail protegido].

Recomenda-se escrever comentários e sugestões na forma prescrita. Todos os comentários serão considerados e respondidos e/ou alterados de acordo na segunda edição. Você pode enviar comentários para o mesmo endereço, ou através do formulário no site da FAA FCS.

A partir do dia 8 de setembro, foram recebidos comentários de membros do SC-5 TC-465 e de membros do GT do Ministério da Construção, no site onde os documentos foram publicados pela primeira vez.

Os documentos são desenvolvidos por equipes diferentes, portanto o processo de feedback pode variar um pouco. Em outubro, a discussão dos artigos será concluída na PP-5, que provavelmente também incluirá comentaristas substanciais.

Parte 2. Informal

2. Na Federação Russa, o trabalho no Plano (programa, roteiro) para uma transição faseada para o BIM está em andamento desde o final de 2012. Dezenas de pessoas participaram do desenvolvimento e discussão. Portanto, existem agora mais de CINCO pontos óbvios neste documento. E o próprio roteiro está agora sob consideração do Governo da Federação Russa. (Não tenho informações se foi adotado ou ainda não).

3. Como membro do Grupo de Trabalho e do Conselho de Especialistas no tema, declaro que nos documentos nacionais de padronização não é dada preferência a quaisquer produtos de software específicos e não será dada. (Os desenvolvedores de software têm o poder de desenvolver padrões para trabalhar em seu software). A este respeito, sugiro que os autores que alegam infundadamente violações da lei antimonopólio e da lei federal sobre a protecção da concorrência ilustrem isto com textos das leis e joint ventures relevantes.

Chamo a atenção para o nome da joint venture que deu início a esta acalorada discussão - “Regras para troca entre modelos de informação de objetos e modelos utilizados em sistemas de software”. Os desenvolvedores desta joint venture, na verdade, foram espremidos em um torno. Alguns revisores exigem deles regras específicas e detalhadas, e não considerações gerais. (Quem pode dizer como isso pode ser feito se alguma menção a produtos for vetada?) E outros, ao contrário, exigem que qualquer menção seja apagada. A saída, obviamente, é desenvolver recomendações metodológicas adicionais, onde será permitida a menção de produtos.

Em uma recente publicação sensacional, houve uma menção à felicidade do BIM às custas de um determinado fornecedor, peço ao autor que “arme” sua mente e me dê exemplos específicos do texto. Em relação às minhas funções (ver a primeira frase do parágrafo 3), preciso realmente garantir a neutralidade dos documentos regulamentares relativos às plataformas BIM.

4. No Reino Unido, a percentagem de encomendas governamentais na construção é de cerca de 40%. Na Federação Russa - SIGNIFICATIVAMENTE MAIS BAIXO. Não consegui encontrar o valor exato, mas NOPRIZ insiste que não passa de 5% (!). De outras fontes, ouvi um número de até 15%. (E por que quebrar lanças - ou ancinhos?) Ou seja, em nossa construção o cliente particular domina. E ele é livre para ordenar como quiser, sem infringir a lei. E inclusive determinar os formatos em que deseja receber o produto. Sobre o que então estamos discutindo? Se um cliente governamental começar a pedir 20% de um pequeno volume em BIM, quanto negócio perderá um projetista individual, que não quer ouvir nada sobre BIM? Nada. Não irá a concurso público e continuará sorteando um comerciante privado até que ele peça BIM.

5. Agora, sobre “restrições veladas que permitem ocultar os pontos fracos do produto promovido”. Sobre o “produto” ver item 3. Quanto às restrições, a frase acima indica que o seu autor não está familiarizado com documentos semelhantes desenvolvidos em outros países que estão à nossa frente nesta área. Tais documentos estão cheios de afirmações como “devido ao suporte de software limitado” ou “já que as competências BIM e as ferramentas de software para este fim ainda são imaturas”, etc. Sim, temos que admitir que os produtos de software à nossa disposição ainda não são perfeitos e temos que levar isso em conta. Por conseguinte, aplicamos reservas semelhantes no texto e continuaremos a fazê-lo.

6. E para terminar, quero dirigir-me a quem está realmente decepcionado com o que viu - os textos dos documentos e chamá-los de brutos, etc. Talvez devêssemos detalhar as coisas e ser mais específicos? Se reunirmos todos os tópicos abordados por documentos nacionais semelhantes sobre BIM em diferentes países, descobriremos que eles refletem técnicas de modelagem, abordagens para determinar os níveis de elaboração dos elementos do modelo de informação (LOD, LOI), novos papéis e responsabilidades de processo participantes, planos de implementação BIM -projetos, regras para o desenvolvimento de elementos de biblioteca, questões de interoperabilidade e organização do trabalho em equipe. Esses são quase todos os tópicos. Só então eles são decompostos em diferentes participantes e estágios do ciclo de vida. Os itens desta lista são parcialmente fechados pelas joint ventures apresentadas, e os demais são incluídos pelo Ministério no plano de desenvolvimento futuro.

Convido todos os desiludidos a um diálogo construtivo. Se você não deseja escrever um apelo oficial e ao mesmo tempo já nos conhecemos, escreva de forma pessoal. Vamos descobrir.