Утв. Наказом Міністерства будівництва та житлово-комунального господарства РФ від 15 грудня 2017 р. N 1674/пр

Зведення правил СП-328.1325800.2017

"ІНФОРМАЦІЙНЕ МОДЕЛЮВАННЯ У БУДІВНИЦТВІ. ПРАВИЛА ОПИСУ КОМПОНЕНТІВ ІНФОРМАЦІЙНОЇ МОДЕЛІ"

Building information modeling. Components. Guidelines and requirements

Введено вперше

Вступ

Дане зведення правил розроблено відповідно до Федерального закону від 30 грудня 2009 р. N 384-ФЗ "Технічний регламент про безпеку будівель та споруд" з метою вироблення єдиних вимог, правил та рекомендацій щодо створення компонентів, що використовуються для формування інформаційних моделей об'єкта будівництва.

Звід правил підготовлений авторським колективом АТ "НДЦ "Будівництво" - ЦНДІБК ім. В.А. Кучеренко (керівник роботи - д-р техн. наук І.І. Ведяков; канд. .Ананьєв) та ТОВ "КОНКУРАТОР" (М.Г. Король, С.Е. Бенклян).

1 Область застосування

1.1 Дане зведення правил поширюється на процеси інформаційного моделювання будівель та споруд та встановлює вимоги до компонентів їх інформаційних моделей.

1.2 Дане зведення правил не встановлює вимог до способів розміщення, ведення, структури, форми та змісту цифрових бібліотек (каталогів/баз) компонентів.

2 Нормативні посилання

У цьому зведенні правил використані нормативні посилання такі документи:

ГОСТ 2.303-68 Єдина система конструкторської документації. Лінії

ГОСТ 2.306-68 Єдина система конструкторської документації. Позначення графічних матеріалів та правила їх нанесення на кресленнях

Примітка - При користуванні цим зведенням правил доцільно перевірити дію документів в інформаційній системі загального користування - на офіційному сайті федерального органу виконавчої влади у сфері стандартизації в мережі Інтернет або за щорічним інформаційним покажчиком "Національні стандарти", який опублікований станом на 1 січня поточного року , та за випусками щомісячного інформаційного покажчика "Національні стандарти" за поточний рік. Якщо замінений посилальний документ, на який дано недатоване посилання, рекомендується використовувати чинну версію цього документа з урахуванням усіх внесених до цієї версії змін. Якщо замінений посилальний документ, на який дано датоване посилання, рекомендується використовувати версію цього документа із зазначеним вище роком затвердження (прийняття). Якщо після затвердження цього зводу правил у посилальний документ, на який дано датоване посилання, внесено зміну, що стосується положення, на яке дано посилання, то це положення рекомендується застосовувати без урахування цієї зміни. Якщо посилальний документ скасовано без заміни, положення, в якому дано посилання на нього, рекомендується застосовувати в частині, що не зачіпає це посилання. Відомості про дію склепінь правил доцільно перевірити у Федеральному інформаційному фонді стандартів.

3 Терміни та визначення

У цьому документі застосовані такі терміни з відповідними визначеннями:

3.1 атрибути компонента: Істотні властивості компонента, необхідні визначення його геометрії чи характеристик і мають ім'я і значення.

3.2 геометричні параметри компонента: Атрибути, які визначають розмір, форму та просторове положення компонента.

3.3 графічні властивості компонента: Властивості, що забезпечують впізнаваність компонента у тривимірній проекції, а також у різних проекціях та масштабах з відображенням характерних двовимірних символів, ліній, штрихування, тексту.

3.4 інформаційне моделювання об'єктів будівництва: Процес створення та використання інформації щодо споруджуваних, а також завершених об'єктів будівництва з метою координації вхідних даних, організації спільного виробництва та зберігання даних, а також їх використання для різних цілей на всіх стадіях життєвого циклу.

3.5 компонент: Цифрове представлення фізичних та функціональних характеристик окремого елемента об'єкта будівництва, призначене для багаторазового використання.

Примітка - Компонент, застосований у моделі, стає елементом моделі.

3.6 метадані компонента: Структуровані дані, що являють собою характеристики описуваного компонента для ідентифікації, пошуку, оцінки та управління ним.

3.7 відкриті формати обміну даними: Формати даних із відкритою специфікацією.

Примітка - Формат IFC (Галузеві базові класи) формат та схема даних з відкритою специфікацією. Є міжнародним стандартом обміну даними в інформаційному моделюванні в галузі цивільного будівництва та експлуатації.

3.8 Складання: Іменований набір компонентів, призначений для багаторазового використання.

3.9 рівень опрацювання; LOD: Набір вимог, що визначає повноту опрацювання елемента цифрової інформаційної моделі. Рівень опрацювання визначає мінімальний обсяг геометричних, просторових, кількісних, а також будь-яких атрибутивних даних, необхідних для вирішення завдань інформаційного моделювання на конкретній стадії життєвого циклу об'єкта.

3.10 функціональна поведінка компонента: Зміна компонента відповідно до закладених у нього правил взаємодії з навколишніми умовами.

3.11 цифрова інформаційна модель: Об'єктно-орієнтована параметрична тривимірна модель, що представляє в цифровому вигляді фізичні, функціональні та інші характеристики об'єкта (або окремих його частин) у вигляді сукупності інформаційно насичених елементів.

3.12 елемент моделі: Частина цифрової інформаційної моделі, яка представляє елемент, систему чи складання в межах об'єкта будівництва чи будівельного майданчика.

4 Загальні положення

4.1 Компоненти характеризуються геометричними параметрами, графічними властивостями, атрибутами та функціональною поведінкою.

4.2 Компоненти слід розділяти:

За типами:

Точкові - компоненти із заданими геометричними формами, що додаються в модель із прив'язкою до своєї точки вставки.

Примітка - такі компоненти як вікно, двері, балка, колона, насос, меблі тощо;

Лінійні - одержувані за допомогою з'єднання спрямованого замкнутого профілю та лінії прив'язки як твірної.

Примітка - такі компоненти як стіни, труби, димарі, кабельні короби тощо;

Площі - об'ємні компоненти, значно меншої висоти, що створюються шляхом малювання контуру обмеженої площі.

Примітка – такі компоненти як перекриття, дахи, стелі тощо;

За прив'язкою до виробника:

Узагальнений компонент є цифровим поданням продукції, конкретний виробник якої невідомий;

Продукт – компонент є цифровим уявленням продукції конкретного виробника.

За рівнем параметризації:

Параметричні компоненти - компоненти, розміщені екземпляри яких можна конфігурувати зміною значень атрибутів в інтерфейсі програмного забезпечення (без необхідності безпосереднього редагування компонента);

Непараметричні компоненти – компоненти, які створені без можливості їхньої конфігурації.

За сферою застосування:

Архітектура;

Містобудування;

Будівельні конструкції;

Інженерні системи та мережі;

Дизайн інтер'єрів та екстер'єрів;

Інші сфери застосування.

5 Загальні вимоги до компонентів

5.1 Розробка компонентів повинна виконуватись за допомогою відповідних інструментів програмного забезпечення, що реалізує функціонал інформаційного моделювання.

5.2 Під час розробки компонентів слід:

Враховувати цілі використання цифрової інформаційної моделі;

Враховувати вимоги до рівнів опрацювання елементів моделі;

Визначати склад та число геометричних параметрів;

Визначати склад та число атрибутів.

6 Вимоги до геометричних параметрів, рівнів геометричного опрацювання та графічного відображення компонентів

6.1 Вимоги до геометричних параметрів та графічного відображення компонента включають вимоги до:

геометричних параметрів;

відображення графічних позначень;

рівню геометричного опрацювання;

Резервування простору, займаного компонентом;

Графічний відображення матеріалів.

6.2 Вимоги до геометричних параметрів

6.2.1 Під час розробки компонента слідує:

Моделювати геометрію у масштабі 1:1;

Визначати точку вставки (базову точку) для компонента типу "точковий";

Використовувати мінімальну кількість допоміжних елементів (наприклад, допоміжних площин та ліній);

Використовувати геометричні параметри, виражені у метричній системі одиниць.

6.2.2 Компоненти типу "узагальнений" повинні включати значення параметрів, що визначають номінальні розміри, якщо фактичні розміри невідомі.

6.2.3 Компоненти типу "продукт" повинні включати значення параметрів, що визначають точні розміри.

6.2.4 Вимоги до відображення графічних позначень:

до складу компонента необхідно включати графічні елементи передачі інформації, яку неможливо відобразити в тривимірної проекції (наприклад, покажчики напрямку руху, бік відчинення дверей, способи відкриття вікон).

6.3 Вимоги до рівня геометричного опрацювання

6.3.1 Точки вставки (базові точки) компонента повинні бути єдиними на всіх рівнях опрацювання.

6.4 Вимоги до графічного відображення матеріалів

6.4.1 Якщо зображенням необхідно заповнити поверхню компонента, воно має бути квадратної або прямокутної форми, щоб забезпечити безшовне повторення зображення (у вигляді мозаїки).

6.4.2 Вимоги до файлу із зображенням матеріалу:

Розмір зображень квадратної форми – не менше 512x512 пікселів;

Розмір зображень прямокутної форми - не менше 512 пікселів по найдовшій стороні;

Роздільна здатність зображення - не менше 150 точок на дюйм.

7 Вимоги до рівня атрибутивного опрацювання та значень атрибутів

7.1 При розробці компонентів число, склад атрибутів та рівень атрибутивного опрацювання слід визначати з урахуванням:

Цілей та завдань застосування цифрових інформаційних моделей;

Вимог до LOD;

Вимог до складу та змісту технічної документації.

7.2 Усі створені атрибути компонента мають бути заповнені.

7.3 Атрибути компонента слід розділяти на обов'язкові та додаткові.

7.3.1 До обов'язкових атрибутів компонента слід відносити такі властивості або технічні характеристики, які дозволяють однозначно ідентифікувати компонент, а також містять дані, на підставі яких можна здійснити розробку технічної документації, замовлення, купівлю та монтаж конкретного компонента у процесі будівництва.

7.3.2 До додаткових атрибутів слід відносити властивості або технічні характеристики, необхідні для проведення інженерних розрахунків, інформацію техніко-економічного характеру, техніко-експлуатаційні та інші характеристики.

7.4 Якщо значення параметрів повинні керувати геометричним розміром або формою компонента, при їх зміні повинні змінюватися розмір та/або форма компонента моделі.

7.5 Якщо значення атрибута не має обмежень і допускає можливість введення як цифр, так і літер, то значення атрибуту має надаватися алфавітно-цифровий тип даних.

7.6 Значення текстового атрибута компонента не повинне закінчуватися точкою.

8 Функціональні вимоги до компонентів

8.1 Компонент повинен "поводитися" таким чином, щоб відображалися його функціональне призначення та взаємозв'язки з іншими компонентами.

8.2 У середовищі програмного забезпечення, як правило, існує можливість розробити компонент з тим чи іншим числом попередньо заданих фіксованих параметрів, які має реальний фізичний будівельний елемент. За наявності попередньо налаштованих варіантів компонента зниження його продуктивності або утруднення його використання повинні бути мінімальними.

8.3 Компонент слід моделювати таким чином, щоб він міг бути приєднаний до інших компонентів і функціонувати спільно з ними, якщо спільне функціонування підтримується та відповідає завданням моделі, що розробляється.

9 Правила іменування компонентів та його атрибутів

9.1 Правила іменування компонентів, наведені в цьому розділі, призначені для програмного забезпечення, що працює на основі файлової системи зберігання даних.

9.2 Система іменування повинна складатися з:

Загальних правил імен;

Схема іменувань.

Примітка - Приклад системи найменування файлів компонентів наведено в А.15-А.16 (додаток А).

9.3 У компонента має бути унікальне ім'я та опис.

9.4 Правила іменування атрибутів

9.4.1 Одиниці виміру в назві атрибута не вказуються.

9.4.2 Атрибути зі значеннями, що передбачають логічні типи даних (Так/Ні), повинні іменуватися так, щоб значення обов'язково було надано (наприклад, "Наявність Підвіконня" - Так/Ні).

Примітка Приклад правил іменування атрибутів наведено в А.17 (додаток А).

9.5 Правила іменування матеріалів

9.5.1 Ім'я матеріалу повинно починатися з великої літери, за якою слідують малі. Якщо назва складається з двох і більше слів, то кожне слово починається з великої літери і всі слова пишуться разом.

9.5.2 Файлу із зображенням матеріалу ім'я присвоюється так само, як і матеріалу, з розширенням, що відповідає формату застосованого графічного файлу.

Примітка Приклад правил іменування матеріалів наведено в А.18 (додаток А).

10 Вимоги до форматів компонентів

10.1 За форматами файлів компоненти можуть бути:

у відкритому форматі IFC (версії 2x3 і вище);

У вихідних форматах (формати файлів компонентів та файлів проекту програмного забезпечення, що застосовується).

11 Вимоги до метаданих компонентів

11.1 При організації баз/каталогів/бібліотек компонентів, наприклад у вигляді інтернет-сховищ, необхідно забезпечувати зручний пошук необхідного контенту. Як правило, такий пошук здійснюється за метаданими. Пошук метаданих - пошук атрибутів компонента, що підтримуються конкретною пошуковою системою.

Додаток А

А.1 Компоненти можуть об'єднуватися у збірки (наприклад, "сантехкабіна", "тепловий вузол", "трансформаторна підстанція"), які рекомендується застосовувати для формування тематичних каталогів/баз/бібліотек повторного застосування.

А.2 Компонент має бути однозначно ідентифікований. Для цього рекомендується використовувати:

Унікальне ім'я;

Глобальний унікальний ідентифікатор, який застосовується для визначення ресурсів;

Код класифікатора (за його наявності).

А.3 Для мінімізації числа компонентів, що розробляються, та їх уніфікації рекомендується створювати параметричні компоненти.

Для відповідності вимогам стандартів ЕСКД та СПДС (наприклад, ГОСТ 2.303 та ГОСТ 2.306), що висуваються до оформлення проектної та робочої документації, при розробці компонента рекомендується включати до його складу умовні графічні позначення.

Примітка - Компоненти на рівні опрацювання LOD 100 являють собою концептуальні формоутворюючі елементи і як такі не потребують попередньої підготовки відповідних компонентів, а на рівні LOD 500 - повністю певні компоненти, які відрізняються від рівня LOD 400 тільки розмірами, що відповідають фактичному виконанню проектів. З цих причин для розробки баз/бібліотек/каталогів компонентів рекомендуються рівні опрацювання LOD 200, 300 та 400.

Примітка - За відсутності відповідних компонентів низького рівня опрацювання допускається застосовувати компоненти вищого рівня.

А.8 Компоненти інженерного/технологічного обладнання рекомендується розробляти з урахуванням резервування простору для обслуговування, яке рекомендується включати як частину компонента.

А.9 За необхідності розробки компонента з певним матеріалом рекомендується включати до нього кольори, зразки штрихування/заливки та файли із зображенням текстури у відповідному масштабі.

А.12 Значення атрибуту компонента може бути виражене у вигляді формули, якщо його значення залежить від інших атрибутів.

А.13 Якщо компонент може представляти різні варіанти елемента об'єкта будівництва, рекомендується представляти їх за допомогою атрибуту зі значенням, вираженим одним із таких способів:

Єдине значення - якщо значення існує єдиний варіант вибору;

Облікове значення - якщо в упорядкованому списку є кілька унікальних значень одного типу, порядок яких важливий (наприклад, 200, 400, 600, 800);

Діапазонне значення – якщо існують верхня та нижня межі цього значення (межа). Спочатку вказується нижня межа, а потім верхня (наприклад, 175-200 кВт). У випадку, якщо в діапазон значень входять позитивні та негативні значення, вони поділяються за допомогою слів "від" і "до" (наприклад, мінус 10°C до плюс 20°C). Якщо значення не вказано, це означає необмежену межу (наприклад, 175 кВт -<ноль>, тобто. всі значення вищі або дорівнюють нижньому граничному значенню 175 кВт);

Нумероване значення – якщо для значення передбачено вибір фіксованих значень із встановленого переліку. Окремі елементи повинні відокремлюватися один від одного комою та пробілом (наприклад, a, b, c, d).

Примітка - Дані способи вираження різних варіантів елементів об'єкта будівництва зазвичай застосовуються в компонентах типу "узагальнений".

А.14 Компонент рекомендується моделювати таким чином, щоб він міг бути приєднаний до інших компонентів і функціонувати спільно з ними, якщо спільне функціонування підтримується та відповідає завданням моделі, що розробляється.

Ім'я файлу складається із полів;

Як знак-розділювач між полями рекомендується використовувати знак підкреслення "_";

Всі поля в імені файлу починаються з великої літери, за якою йдуть малі. Якщо поле складається з двох і більше слів, то кожне слово починається з великої літери і всі слова пишуться разом;

Абревіатури та коди слід писати великими літерами;

А.16 Структура імен файлів компонентів

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

де поля мають наведені у таблиці А.1 значення.

Таблиця А.1

Якщо компонент не містить тривимірної геометрії, в кінці "Поля2" (функціональний тип) слід додати "-2D".

Примітки

1 Кількість полів у імені файлу може змінюватись від чотирьох до шести залежно від типу компонента (тип "узагальнений" або "продукт"), а також наявності додаткових ідентифікаційних ознак.

2 Приклад іменування компонентів типу "узагальнений":

АБВ_Двері_Двупольні_Алюмінієві_ГОСТ23747-2015

3 Приклад іменування компонентів типу "продукт":

АБВ_Умивальник_Керамічний_Завод1_Виконання

Якщо потрібно ввести додаткові поля, їх рекомендується додавати наприкінці імені.

А.17 Правила іменування атрибутів

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

де поля мають такі значення, наведені у таблиці А.2

Таблиця А.2

Примітка - Приклади іменування атрибутів:

ПрофільШиріна

АБВ_Площа Квартири

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

де поля мають такі значення, наведені у таблиці А.3

Таблиця А.3

Примітка - Приклад іменування матеріалів:

ABC_Черепиця_Битумна_Континент_Виробник

Май 28th, 2018 Тетяна Бех

ГОСТ та СП по BIM

Вирішили зібрати перелік нормативних документів, які регламентують спрямування інформаційних технологій у будівництві. Ось що знайшлося насьогоднішній день!

Список нормативних документів з BIM:

• ГОСТ Р 57310-2016 (ІСО 29481-1:2010) Моделювання інформаційне в будівництві. Посібник з доставки інформації. Методологія та формат. Дата введення 2017 -07 -01
• ГОСТ Р 57311 -2016 Моделювання інформаційне в будівництві. Вимоги до експлуатаційноїдокументації об'єктів завершеного будівництва. Дата введення 2017 -07 -01
• ГОСТ Р 57309-2016 (ІСО 16354:2013) Керівні принципи з бібліотек знань та бібліотек об'єктів. Дата введення 2017-07-01.
• ГОСТ Р 57563 -2017 / ISO / TS 12911: 2012 Моделювання інформаційне в будівництві. Основні положення щодо розробки стандартів інформаційногомоделювання будівель та споруд (з Поправкою). Дата введення 2017 -10 -01.
• ГОСТ Р ИСО 12006-2-2017 Будівництво. Модель організації даних про будівельні роботи. Частина 2 . Основи класифікації інформації. Дата введення 2017 -10 -01.
• ГОСТ Р ИСО 12006 -3 -2017 Будівництво. Модель організації даних про будівельні роботи. Частина 3 Основи обміну об'єктно орієнтованоюінформацією. Дата введення 2017 -10 -01
• ГОСТ Р ИСО 22263 -2017 Модель організації даних про будівельні роботи. Структура управління проектною інформацією. Дата введення 2017 -10 -01.
• ГОСТ Р 57295 -2016 Системи дизайн-менеджменту. Посібник з дизайн-менеджменту в будівництві. Дата введення 2018-01-01.
• СП 301.1325800.2017 Інформаційне моделювання в будівництві. Правила організації робіт виробничо-Технічними відділами. Дата введення 2018-03-02.

Оновлено 23.03.2018. Зберезня 2018 року набирають чинності три зведення правил (СП ) по BIM:

• СП 328.1325800.2017 «Інформаційне моделювання у будівництві. Правила опису компонентів інформаційної моделі» (наказ від 15.12.2017 р. № 1674/пр).Дане зведення правил поширюється на процеси інформаційного моделювання будівель та споруд та встановлює вимоги до компонентів їх інформаційних моделей, але не встановлює вимоги до способів розміщення, ведення, структури, форми та змісту цифрових бібліотек (каталогів/баз) компонентів. Документ набуде чинності з 16 червня 2018 року.
• СП 331.1325800.2017 «Інформаційне моделювання у будівництві. Правила обміну між інформаційними моделями об'єктів та моделями, що використовуються у програмних комплексах» (наказ від 18.09.2017 р. № 1230/пр).В основу СП 331.1325800.2017 увійшли базові вимоги до створення та експлуатації інформаційних систем, що взаємодіють між собою протягом усього життєвого циклу будівлі або споруди та реалізують технологію інформаційного моделювання об'єкта будівництва. Звід правил набрав чинності з 19 березня 2018 року.
• СП 333.1325800.2017 «Інформаційне моделювання у будівництві. Правила формування інформаційної моделі об'єктів на різних стадіях життєвого циклу» (наказ від 18.09.2017 р. № 1227/пр).Документ містить вимоги до інформаційних моделей об'єктів масового будівництва та їх розробки на різних стадіях життєвого циклу, спрямовані на підвищення обґрунтованості та якості проектних рішень, підвищення рівня безпеки під час будівництва та експлуатації. Загальні підходи до формування інформаційних моделей забезпечать простоту їхнього використання та підвищать ефективність процесу інформаційного моделювання. Звід правил набрав чинності з 19 березня 2018 року.

У найближчому майбутньому нам з вами обіцяють розширити нормативно-технічну документацію з BIM у двох напрямках:

Базові документи:

• 3 ГОСТ Р
• 4 СП

Документи для різних стадій життєвого циклу об'єкту

• 2 ГОСТ Р
• 6 СП

Не слід забувати, що на сьогоднішній день існує дві категорії нормативних документів.

23 серпня почалося публічне обговорення чотирьох СП, розроблених на замовлення Міністерства будівництва та ЖКГ РФ. Список із прямими посиланнями нижче. Термін обговорення – 60 календарних днів.

За деякими посиланнями можна і зараз завантажити тексти проектів документів. Інший та гарантований спосіб отримати тексти – надіслати запит на адресу: [email protected]

Писати зауваження та пропозиції рекомендується за встановленою формою. Всі зауваження будуть розглянуті та по них будуть надані відповіді та/або будуть внесені відповідні зміни до другої редакції. Надсилати зауваження можна на ту саму адресу або через форму на сайті ФАУ ФЦС.

На 8 вересня надійшли зауваження від членів ПК-5 ТК-465 та членів РГ Мінбуду, на майданчику якого документи було опубліковано насамперед.

Документи розробляються різними командами, тому процедура відпрацювання зауважень може трохи відрізнятися. У жовтні обговорення документів завершиться на засіданні ПК-5, на яке, швидше за все, буде запрошено й авторів суттєвих зауважень.

Частина 2. Неформальна

1. Наша команда бере участь у розробці двох із чотирьох документів. Ми дуже раді можливості брати участь у формуванні нормативно-технічного поля інформаційного моделювання в РФ. Ми гарантуємо, що якість остаточної редакції буде відповідати найвищому світовому рівню. Ми дуже в цьому зацікавлені і тому запрошуємо всіх фахівців, які мають знання та досвід у конкретній предметній галузі, що відповідає темі СП, висловитися по суті та в діалозі дійти найкращих (на сьогодні історичний момент) формулювань.

2. У РФ робота над Планом (програмою, дорожньою картою) поетапного переходу на BIM ведеться з кінця 2012 року. Участь у розробці та обговоренні брали десятки людей. Тому в даному документі зараз є більше 5 очевидних пунктів. А сама дорожня карта зараз перебуває в Уряді РФ на розгляді. (Я не маю інформації, прийнята вона або поки немає).

3. Як член Робочої Групи та Експертної ради на тему я заявляю, що в національних документах зі стандартизації жодним конкретним програмним продуктам перевага не надається і не надаватиметься. (Розробники ПЗ мають право на власний розсуд розробляти стандарти, що передбачають роботу в їх ПЗ). У зв'язку з цим я пропоную авторам, які голослівно стверджують про факти порушення антимонопольного законодавства та федерального закону про захист конкуренції проілюструвати це текстами з відповідних законів та СП.

Звертаю увагу на назву СП, через яку розпочалася ця гаряча дискусія – «Правила обміну між інформаційними моделями об'єктів та моделями, що використовуються у програмних комплексах». Розробники цього СП за фактом виявилися затиснутими у лещата. Одні рецензенти вимагають від них конкретики, докладних правил, а чи не загальних міркувань. (Хто розповість, як це можна робити, якщо на будь-яку згадку про продукт накладено вето?) А інші, навпаки, вимагають виключити будь-які згадки. Вихід, очевидно, полягає у розробці додаткових методичних рекомендацій, де згадувати продукти буде дозволено.

У нещодавній гучній публікації була згадка про BIM-щастя за рахунок якогось вендора, прошу автора «озброїти» свій погляд і навести для мене конкретні приклади з тексту. У зв'язку з моїми ролями (див. першу пропозицію п.3) мені дійсно необхідно забезпечити нейтральність нормативних документів щодо BIM-платформ.

4. У Великій Британії частка держзамовлення у будівництві становить близько 40%. У РФ - ЗНАЧНО НИЖЧЕ. Мені не вдалося знайти точну цифру, але в НОПРИЗ наполягають, що це не більше ніж 5% (!). З інших джерел чула цифру до 15%. (І навіщо ламати списи – чи граблі?) Тобто у будівництві у нас домінує приватний замовник. І він може замовляти так, як йому подобається, не порушуючи закону. І навіть визначати формати, у яких хоче отримувати продукт. Про що тоді ми сперечаємося? Якщо держзамовник почне 20% із малого обсягу просити у BIM, скільки бізнесу втратить окремий проектувальник, який про BIM нічого чути не хоче? Нічого. Не піде на держтендер і продовжуватиме малювати для приватника, поки той не просить у ВIM.

5. Тепер про «завуальовані обмеження, що дозволяють приховати слабкі сторони продукту, що просувається». Для «продукт» див. п.3. Щодо обмежень, то наведена фраза говорить про те, що її автор не знайомий з аналогічними документами, розробленими в інших країнах, які випередили нас за цим напрямом. Такі документи рясніють формулюваннями типу «due to limited software support» або «as BIM skills and software tools for this purpose are still immature» тощо. . Тому аналогічні застереження за текстом ми застосовуємо і це робитимемо далі.

6. І на завершення хочу звернутися до тих, хто справді розчарувався у побаченому – текстах документів і називає їх сирими та ін. Ви що там очікували знайти та не знайшли? Можливо, нам слід усе розкласти по поличках і бути конкретнішими? Якщо звести всі теми, що охоплюються подібними національними документами по BIM у різних країнах, то виявимо, що в них відображаються методики моделювання, підходи до визначення рівнів опрацювання елементів інформаційної моделі (LOD, LOI), нові ролі та обов'язки учасників процесу, плани реалізації BIM -проектів, правила розробки бібліотечних елементів, питання інтероперабельності та організації колективної роботи Ось практично всі теми. Тільки потім вони ще розкладаються на різних учасників та стадії ЖЦ. Пункти з цього списку частково закриваються представленими СП, інші включені Міністерством у план подальших розробок.

Усіх розчарованих я запрошую до конструктивного діалогу. Якщо не хочете писати офіційне звернення, і при цьому ми з вами вже знайомі, пишіть у личку. Розберемося.

Три нові зведення правил (СП) за напрямом інформаційних технологій затверджено та набудуть чинності з 1 березня. Про це повідомив заступник голови Департаменту містобудівної діяльності та архітектури Міністерства будівництва та житлово-комунального господарства Російської Федерації Олександр Степанов у рамках семінару «Інформаційне моделювання. Цифрове середовище як основа взаємодії», організованого підвідомчим Мінбуду Росії Федеральним центром нормування, стандартизації та технічної оцінки відповідності у будівництві спільно з Комітетом РСПП з технічного регулювання, стандартизації та оцінки відповідності. Захід пройшов 21 лютого за участю представницького складу експертів.

СП «Інформаційне моделювання у будівництві. Правила опису компонентів інформаційної моделі», «Інформаційне моделювання у будівництві. Правила формування інформаційної моделі об'єктів на різних стадіях життєвого циклу» та «Інформаційне моделювання у будівництві. Правила обміну між інформаційними моделями об'єктів та моделями, що використовуються у програмних комплексах» набудуть чинності з 1 березня 2018 року.

За словами Олександра Степанова, створювана система національних документів у галузі технологій інформаційного моделювання у будівництві включає базові стандарти та склепіння правил, що забезпечують цифрову інфраструктуру, у тому числі визначальні основні положення, принципи та термінологію BIM, а також стандарти та склепіння правил, що визначають понятійну базу та методологію впровадження інформаційного моделювання в практику на окремих стадіях життєвого циклу – від обґрунтування інвестицій до утилізації та знесення будівель та споруд.

У 2018 році розпочато розробку базових стандартів, що визначають основні принципи, поняття та термінологію БІМ: ГОСТ Р «Організація інформації про будівельні роботи. Інформаційний менеджмент із застосуванням інформаційного моделювання. Частина 1. Основні принципи та поняття» та ГОСТ Р «Організація інформації про будівельні роботи. Інформаційний менеджмент із застосуванням інформаційного моделювання. Частина 2. Стадія створення активів». Аналогічні стандарти ISO (ISO 19650-1 та ISO 19650-2) знаходяться в даний час у завершальній стадії розробки. Експерти ПК 13 «Обробка, зберігання та обмін інформацією, що стосується будівельних робіт» ТК 465 «Будівництво», беруть участь у цих роботах з 2017 року.

Наразі проходить процедуру реєстрації ГОСТ Р «Моделювання інформаційне у будівництві. Галузеві базові класи (IFC) обмінюватись інформацією всіх етапах життєвого циклу. Основні положення". «Якщо державний замовник буде забезпечений можливістю вимагати надання інформації для контролю у форматі IFC, то не буде потреби витрачати бюджетні кошти на купівлю великої кількості різноманітних програмних продуктів та на утримання зайвого штату фахівців, здатних працювати у цих програмах», - зазначив Олександр Степанов.

Система нормативно-технічних документів загалом включатиме 15 національних стандартів (ГОСТ Р), 10 склепінь правил, у тому числі: 13 ГОСТ Р та 4 СП – документи, розроблені за основними (базовими) напрямками; 2 ГОСТ Р та 6 склепінь правил – для окремих стадій життєвого циклу.

В даний час в області БІМ доступні для практичного застосування 7 ГОСТів і 4 склепіння правил.

У заході взяли участь фахівці ТК 465 «Будівництво», КазНДІСА (Казахстан), Центру з цифрової економіки МДУ, АТ НДЦ «Будівництво», НДІПромбудівель, ФАУ ФЦС та ін.

Перед направленням електронного звернення до Мінбуду Росії, будь ласка, ознайомтеся з наведеними нижче правилами роботи даного інтерактивного сервісу.

1. До розгляду приймаються електронні звернення у сфері компетенції Мінбуду Росії, заповнені відповідно до форми, що додається.

2. В електронному зверненні може бути подана заява, скарга, пропозиція або запит.

3. Електронні звернення, направлені через офіційний Інтернет-портал Мінбуду Росії, надходять на розгляд до відділу роботи зі зверненнями громадян. Міністерство забезпечує об'єктивний, всебічний та своєчасний розгляд звернень. Розгляд електронних звернень здійснюється безкоштовно.

4. Відповідно до Федерального закону від 02.05.2006 р. N 59-ФЗ "Про порядок розгляду звернень громадян Російської Федерації" електронні звернення реєструються протягом трьох днів і направляються залежно від утримання до структурних підрозділів Міністерства. Звернення розглядається протягом 30 днів із дня реєстрації. Електронне звернення, що містить питання, вирішення яких не входить до компетенції Мінбуду Росії, направляється протягом семи днів з дня реєстрації до відповідного органу або відповідної посадової особи, до компетенції яких входить вирішення поставлених у зверненні питань, з повідомленням про це громадянина, який направив звернення.

5. Електронне звернення не розглядається за умови:
- відсутність прізвища та імені заявника;
- зазначення неповної або недостовірної поштової адреси;
- Наявність у тексті нецензурних або образливих виразів;
- наявності у тексті загрози життю, здоров'ю та майну посадової особи, а також членів її сім'ї;
- використання при наборі тексту некириличної розкладки клавіатури або лише великих букв;
- відсутності в тексті розділових знаків, наявності незрозумілих скорочень;
- Наявність у тексті питання, на яке заявнику вже надавалася письмова відповідь по суті у зв'язку з раніше спрямованими зверненнями.

6. Відповідь заявнику звернення надсилається на поштову адресу, вказану при заповненні форми.

7. При розгляді звернення не допускається розголошення відомостей, що містяться у зверненні, а також відомостей, що стосуються приватного життя громадянина без його згоди. Інформація про персональні дані заявників зберігається та обробляється з дотриманням вимог російського законодавства про персональні дані.

8. Звернення, що надійшли через сайт, узагальнюються та надаються керівництву Міністерства для інформації. На питання, що часто ставляться, періодично публікуються відповіді в розділах «для мешканців» і «для фахівців»