Вы задаёте требования и принимаете решения. Расчёты, документация и задания смежникам получаются из модели и обновляются сами при каждом изменении.
R2O — способ вести проект от технического задания до эксплуатации в одной модели. Инженер задаёт требования и принимает решения, а расчёты, документация и задания смежникам получаются из модели. Когда что-то меняется, система сама пересчитывает всё, что от этого зависит, и показывает, что устарело.
Изменили в одном месте — поправилось везде.
Проект начинается не с чертежа, а с того, что должно получиться: назначение помещений, нагрузки, нормы, бюджет. Нормы — часть модели: правило само находит, к чему применяться, и у каждого правила есть ссылка на пункт нормы.
Результат — не комплект документации, а работающий объект. Из модели получаются задания на производство и закупку, данные для монтажа и наладки, а после сдачи — паспорт объекта для службы эксплуатации.
Все разделы и все этапы работают с одними данными. Ничего не переносится вручную из программы в программу и не перепечатывается из таблицы в таблицу.
Модель знает, что от чего зависит. Поправили исходные данные — пересчиталось всё зависимое, а то, что нельзя пересчитать без инженера, помечено как устаревшее.
В CAD человек рисует линии. В BIM — объекты, а виды и спецификации система выводит сама. В R2O человек задаёт требования и решения, а всё остальное выводится из них.
Сегодня путь от ТЗ до объекта проходит через разные программы и разных людей. Данные между ними переносят вручную, и на каждом стыке что-то теряется или устаревает.
Модель знает, что от чего зависит. Ниже три цепочки для примера — подход не привязан к одному разделу или процессу.
Одно изменение проходит по всей цепочке. Что можно пересчитать — пересчитано, остальное помечено.
Из модели получается не только чертёж: у оборудования появляются сигналы, по ним — схема управления, программа и состав изделия для производства. Программу можно проверить на модели ещё до выезда на объект.
Замеры и решения с монтажа и наладки возвращаются в модель. Служба эксплуатации получает объект таким, какой он есть, а не таким, каким его нарисовали.
Система не проектирует вместо инженера. Она берёт на себя расчёты, оформление и сверку, а решения и подпись остаются за человеком.
Система собирает то, что делается по типовым решениям и проверенным правилам.
Генераторы и ИИ предлагают вариант. Он проходит проверки, а принимает его инженер — по маршруту, как документ.
Функции, от которых зависит безопасность людей, собираются только из испытанных шаблонов.
Ответственность за проект остаётся за инженером. У каждого значения записано, кто и почему его задал.
Каждая часть подхода давно работает в машиностроении, авиации, промышленной автоматике и ИТ. Новое — собрать их в одну модель для всех разделов стройки.
правила проектирования записаны так, что их исполняет система
требования — элементы модели, а не текст рядом с ней
одна связанная цепочка данных от замысла до эксплуатации
программа управления проверяется на модели до выезда на объект
изменение исходных данных пересобирает всё зависимое, как программа после правки
Подход заложен в ProMatrix Engineering — объектную систему проектирования для всех разделов: архитектура, отопление и вентиляция, автоматика, водоснабжение, электрика, слаботочные системы, а дальше конструкции, генплан и геодезия. Модуль в разработке, мы показываем его честно — по стадиям.
Идёт первая веха — «Черчу АР и ОВиК объектами»: архитектура, вентиляция и отопление уже работают в модели. Следующий шаг — пилот на реальном объекте параллельно с AutoCAD. Приглашаем проектные организации стать пилотными заказчиками.
ProMatrix Engineering — часть экосистемы ProMatrix: документооборот, задачи, замечания, сметы, снабжение и монтаж работают на тех же данных. Поэтому модель не обрывается на выпуске проекта.
Расскажите, где у вас сейчас рвётся цепочка — между разделами, при изменениях или после выпуска проекта. Разберём на вашем примере.
Ответим в рабочие часы. Если вопрос срочный — быстрее всего в Telegram.
