Рассмотрена организация совместной работы над информационной моделью здания в распределённой проектной команде. Показано, что централизованная схема с общим файлом и блокировками элементов плохо применима при удалённой работе внешних исполнителей, и обоснована федеративная схема «один файл — один автор». Определена единица обмена между разделами: не полная модель смежника, а задание-выжимка — именованный неизменяемый срез, содержащий только значимые для получателя величины. Показан предел применимости обмена геометрией для раздела инженерных систем и сформулированы условия работоспособности федеративной схемы.
Введение
Проектная документация создаётся несколькими специалистами, решения которых взаимно зависимы. Архитектор задаёт габариты помещений и высоты, конструктор — несущий каркас, инженер размещает в оставшемся объёме сети отопления, вентиляции, водоснабжения и электроснабжения. Каждое изменение у одного участника способно обесценить работу остальных.
Цена рассогласования измерима. Классическое исследование Национального института стандартов и технологий США оценило годовые издержки недостаточной совместимости данных в отрасли капитального строительства в 15,8 млрд долларов, причём основная их часть приходится на повторный ввод данных, проверку и устранение последствий рассогласования [9]. Отечественные данные подтверждают масштаб: из выборки пятидесяти проектов лишь 10 % не имели замечаний государственной экспертизы, а ошибки проекта и неудачные проектные решения являются причиной от 10 до 35 % аварий [1, с. 710].
Технология информационного моделирования предлагает решение: пространственная модель делает пересечения видимыми и позволяет выявить их до выхода на площадку [3]. Однако сама по себе трёхмерная модель координации не обеспечивает — она лишь переносит задачу согласования из плоскости чертежа в пространство модели. Остаётся организационный вопрос: как несколько авторов работают над одним объектом, не блокируя друг друга и не теряя изменений смежника.
Вопрос обостряется для распределённых команд. Практика привлечения внешних исполнителей, работающих удалённо и на собственных рабочих местах, распространена в проектировании инженерных разделов; при этом единая корпоративная сеть, общий сервер и администрируемые рабочие места отсутствуют.
Цель работы — обосновать схему организации совместной работы, применимую в таких условиях, и определить единицу обмена между разделами.
1. Две схемы организации совместной работы
1.1. Централизованная схема
Распространённый способ совместной работы над моделью в среде Revit — общий файл с механизмом рабочих наборов: каждый участник заимствует элементы, изменяет их и возвращает. Схема обеспечивает единый источник данных и не требует согласования форматов.
Её предпосылки, однако, существенны: устойчивый канал к общему хранилищу, единая версия программного обеспечения, администрируемые рабочие места, доверенная сеть. При работе внешних исполнителей эти предпосылки не выполняются. Попытка заменить общее хранилище синхронизируемой облачной папкой приводит к известным последствиям: подгрузке файла по требованию, конфликтным копиям и повреждению модели, — и не рекомендуется разработчиком среды.
Отдельно следует отметить отсутствие автоматической блокировки для файлов модели в средствах совместной работы общего назначения: системы управления документами реализуют явное взятие файла на редактирование, но не удерживают его автоматически при открытии в среде проектирования. Это означает, что при распределённой работе техническая гарантия непересечения авторов отсутствует, и её приходится заменять организационной.
1.2. Федеративная схема
Альтернатива — федеративная схема, в которой модель объекта разделена на файлы по принципу «один файл — один автор». Раздел делится на части по естественным границам: секция здания, блок систем, этап. Каждая часть имеет единственного ответственного, и только он вносит в неё изменения.
Блокировки при такой схеме не нужны: конфликт редактирования исключён не механизмом, а разделением ответственности. Сводная модель объекта существует не как файл, а как результат сборки — совокупность частей, объединяемых для проверки пересечений и анализа.
Схема имеет два следствия, существенных для организации работы.
Во-первых, границы файлов становятся границами ответственности. Вопрос «кто отвечает за этот участок» получает ответ из состава модели, а не из переписки.
Во-вторых, состав объекта становится наблюдаемым: наличие или отсутствие части, дата её последнего изменения и версия видны без обращения к автору.
1.3. Применимость
Федеративная схема не является универсально лучшей. При работе одной команды в одном офисе централизованная схема проще: она не требует регламента обмена и даёт мгновенную видимость чужих изменений.
Однако при распределённой работе выбор сводится к федеративной схеме, поскольку предпосылки централизованной не выполняются, а их имитация средствами файловой синхронизации создаёт риск потери данных, превышающий выигрыш.
2. Единица обмена между разделами
2.1. Полная модель как единица обмена
Естественным решением представляется передача смежнику полной модели раздела в виде подгружаемой связи. Практика показывает недостатки такого обмена.
Полная модель содержит избыточные для получателя данные: инженеру, размещающему воздуховоды, не нужны сведения об отделке и заполнении проёмов, но нужны отметки перекрытий, габариты помещений и положение несущих элементов. Избыточность увеличивает вес файла, замедляет работу и, что существеннее, скрывает изменения: при получении новой версии модели смежника отличить значимое изменение от несущественного визуально невозможно.
Кроме того, полная модель не фиксирует предмет согласования. Факт передачи модели не означает, что стороны договорились о конкретной величине, и при расхождении на стадии выпуска документации восстановить, что именно было согласовано, затруднительно.
2.2. Задание-выжимка
Предлагается иная единица обмена — задание-выжимка: именованный набор величин, значимых для получателя, передаваемый вместо полной модели. Для взаимодействия архитектурного и инженерного разделов состав задания включает:
- отметки и габариты — высоты этажей, отметки перекрытий, чистые высоты помещений;
- зоны размещения — коридоры, шахты, технические помещения, подвесные потолки с указанием свободной высоты;
- проёмы и отверстия — положение, размеры, требования к обрамлению;
- закладные детали и нагрузки, передаваемые на конструкции;
- табличные данные — экспликации помещений, категории, требования по кратностям воздухообмена.
Задание отличается от модели тремя свойствами. Оно адресно — составлено для конкретного получателя. Оно сопоставимо — две версии задания различаются по перечню изменённых величин, а не визуально. Оно фиксирует договорённость — согласованное задание является документом, к которому можно вернуться.
2.3. Задание как неизменяемый срез
Для того чтобы задание выполняло последнюю функцию, оно должно быть неизменяемым после выдачи. Изменение условий порождает новую версию задания, а не правку прежней. Прежние версии сохраняются.
Такое требование соответствует принятой в среде общих данных схеме движения материалов между зонами рабочих данных, общих данных, опубликованной документации и архива, где переход сопровождается процедурами проверки и согласования, а опубликованное не изменяется [7]. Единообразное именование и статусы, отражающие уровень готовности, названы в той же работе необходимыми условиями работоспособности среды.
3. Формат слепка и предел применимости обмена
3.1. Нативный формат и открытый формат
Файл модели в нативном формате среды проектирования остаётся рабочим документом автора. Для сборки сводной модели, проверки пересечений и передачи данным потребителям целесообразно использовать открытый формат, а нативный файл рассматривать как архивный.
Основанием служит разграничение задач: нативный формат оптимизирован для редактирования в конкретной среде и конкретной её версии, тогда как для анализа, длительного хранения и передачи требуются независимость от версии среды и машиночитаемая структура. Направления развития открытого формата IFC — расширение охвата, многоуровневая архитектура обмена, организационные изменения в практике управления проектами — были определены ещё в начале его распространения [8] и сохраняют актуальность.
3.2. Что теряется при обмене
Существенное ограничение, о котором следует говорить прямо: не всякий обмен сохраняет свойства, необходимые инженерному разделу.
Элемент инженерной сети характеризуется не только геометрией, но и принадлежностью к системе, наличием соединительных портов и связностью с соседними элементами. Именно эти свойства позволяют получить из модели спецификацию, проверить гидравлическую увязку и проследить систему от источника до потребителя.
Механизмы обмена, ориентированные на геометрическое представление, передают элемент сети как поверхность с набором свойств. Такой обмен пригоден для визуального контроля и поиска пересечений, но недостаточен для анализа систем: принадлежность к системе и топология соединений при нём утрачиваются. Открытый формат IFC содержит средства описания этих свойств — распределительные порты, отношения соединения портов и распределительные системы, — и выбор механизма обмена следует делать по признаку их сохранения.
Практическое следствие: требование к слепку модели инженерного раздела строже, чем к слепку архитектурного. Для архитектуры достаточно геометрии и свойств элементов; для инженерных систем требуется сохранение топологии, иначе слепок пригоден лишь для проверки пересечений.
3.3. Свод объекта
Собранная из частей сводная модель служит основанием для проверки пересечений — задачи, ради которой информационное моделирование чаще всего и внедряется [3]. Пересечение воздуховода с несущей балкой, выявленное в модели, устраняется правкой, тогда как обнаруженное на площадке требует переделки.
Однако сводная модель полезна не только проверкой пересечений. Она даёт состав объекта на дату, перечень изменений между датами и основание для проверки комплектности — сведения, которые при работе по чертежам восстанавливаются только вручную.
4. Координация архитектора и инженера
4.1. Асимметрия зависимости
Взаимная зависимость разделов не симметрична. Инженер не может начать компоновку до получения планировок и отметок, тогда как архитектор способен вести работу, зная лишь ориентировочные требования к техническим помещениям. Из этого следует, что основной поток заданий направлен от архитектора к инженеру, а основной поток требований — в обратную сторону.
Практическое следствие: задержка выдачи архитектурных решений сдвигает работу инженерных разделов целиком, тогда как задержка инженерных требований приводит к локальным переделкам. Это обстоятельство должно учитываться при планировании: резерв времени требуется не там, где работа объёмнее, а там, где она зависима.
4.2. Предмет согласования
Наиболее конфликтные предметы согласования между архитектурным и инженерным разделами — отверстия в ограждающих и несущих конструкциях, свободная высота под перекрытием и размеры технических помещений. Сложность возникает не в момент первичной выдачи, а при изменениях: перенос перегородки архитектором обесценивает трассировку сетей, а увеличение сечения воздуховода инженером может потребовать изменения высоты подвесного потолка.
Для раздела вентиляции характерна дополнительная трудность: при плотной прокладке воздуховодов пересечения многочисленны, а их чтение на планах затруднено, вследствие чего приходится выполнять планы на нескольких отметках [3]. Это делает трёхмерную проверку не удобством, а необходимостью.
4.3. Событие вместо опроса
При обмене файлами участник узнаёт об изменении смежника, когда открывает его модель. Между внесением изменения и его обнаружением проходит время, в течение которого работа ведётся по устаревшим данным.
Организационное решение — уведомление о событии: изменение публикуется, и заинтересованные участники извещаются о нём, а не опрашивают хранилище. Требование выглядит техническим, но определяет достижимую скорость согласования: при опросе задержка равна периоду опроса, при уведомлении — времени реакции.
4.4. Прослеживаемость обмена
Отдельного внимания заслуживает реестр переданных и полученных материалов. Практика показывает, что значительная доля срывов сроков вызвана задержкой исходных данных, а ответственность при этом возлагается на проектировщика, поскольку доказательства своевременного запроса отсутствуют.
Реестр обмена, в котором фиксируются дата передачи, состав и получатель, закрывает спор до его возникновения. Апробация схемы приёма-передачи документации с использованием технологий информационного моделирования показала сокращение времени согласования на 57 % и снижение числа ошибок на 69 % [2], причём в числе факторов успешности названы корпоративные стандарты моделирования, среда общих данных и юридически значимый документооборот.
5. Условия работоспособности федеративной схемы
Федеративная схема не сводится к разделению файлов. Ниже перечислены условия, без которых разделение даёт не выигрыш, а дополнительные издержки.
5.1. Граница файла совпадает с границей ответственности. Если часть модели правят двое, преимущество схемы утрачивается, а механизма разрешения конфликта нет. Деление на части выполняется по зонам ответственности, а не по удобству построения.
5.2. Именование и статус обязательны. Часть модели без обозначения стадии готовности не может быть включена в свод: неизвестно, является ли она решением или заготовкой. Единообразное именование и статусы — условие работоспособности среды общих данных [7], а не формальность.
5.3. Сводная модель собирается автоматически. Если сборка выполняется вручную, она выполняется редко, и проверка пересечений превращается в разовое мероприятие перед выдачей. Ценность сводной модели пропорциональна частоте её пересборки.
5.4. Единицей обмена является задание, а не модель. Передача полной модели переносит на получателя работу по выявлению значимых изменений; при числе разделов более трёх эта работа становится основной.
5.5. Выданное задание не изменяется. Правка ранее выданного задания лишает стороны возможности установить, что было согласовано, и обесценивает саму процедуру выдачи.
5.6. Выбор механизма обмена определяется требованиями наиболее сложного раздела. Механизм, достаточный для архитектуры, может оказаться непригодным для инженерных систем (п. 3.2). Проверять пригодность следует по разделу с наибольшими требованиями к передаваемым свойствам.
6. Ограничения
Федеративная схема не устраняет необходимости согласования — она делает его наблюдаемым. Число согласований остаётся прежним, изменяется лишь то, что они фиксируются и поддаются проверке.
Схема предъявляет требования к дисциплине: именование, статусы, регламент выдачи заданий. В организации, где эти требования не соблюдаются, разделение модели на части приведёт к потере целостности вместо выигрыша. Уровень цифровой зрелости организации и квалификация персонала названы в числе ключевых факторов внедрения [2], и это ограничение следует признавать до начала перестройки процессов.
Выбор среды общих данных не является нейтральным: критерии выбора включают не только функциональные возможности, но и прозрачность ценообразования, простоту эксплуатации и независимость от иностранных компонентов [6]. Схема, описанная в настоящей работе, предъявляет к среде минимальные требования — хранение версий, статусы, уведомления, — что расширяет выбор.
Наконец, применение средств автоматизации, включая методы искусственного интеллекта, к анализу собранной модели остаётся отдельной задачей. Исследования показывают, что такие технологии входят в проектную практику [4], однако их применение опирается на качество исходных данных: модель, собранная из несогласованных частей, непригодна для автоматического анализа независимо от применяемых методов. Контроль качества выпускаемой документации при этом остаётся необходимым: в ряде организаций нормоконтроль отсутствует, а внутренняя проверка ограничивается самопроверкой исполнителя [5].
Заключение
1. Централизованная схема совместной работы над информационной моделью предполагает условия, не выполняющиеся при распределённой работе внешних исполнителей; её имитация средствами файловой синхронизации создаёт риск потери данных.
2. Федеративная схема «один файл — один автор» исключает конфликт редактирования разделением ответственности, а не блокировкой, и делает состав объекта и границы ответственности наблюдаемыми.
3. Единицей обмена между разделами целесообразно считать не полную модель смежника, а задание-выжимку — адресный, сопоставимый по версиям и неизменяемый после выдачи набор значимых величин.
4. Требования к механизму обмена определяются разделом инженерных систем: сохранения геометрии недостаточно, необходима передача принадлежности к системе и топологии соединений, иначе слепок пригоден лишь для проверки пересечений.
5. Координация архитектора и инженера несимметрична: основной поток заданий направлен от архитектора, и резерв времени требуется в зависимых, а не в наиболее трудоёмких работах.
6. Сформулированы шесть условий работоспособности федеративной схемы. Их несоблюдение обращает разделение модели в дополнительные издержки, вследствие чего они подлежат проверке до перестройки процессов.
---
Список литературы
1. Байбурин А.Х., Самарин А.Ю. Оценка рисков ошибок проектирования // Известия вузов. Инвестиции. Строительство. Недвижимость. 2024. Т. 14, № 4. С. 708–718. DOI: 10.21285/2227-2917-2024-4-708-718. URL: https://cyberleninka.ru/article/n/otsenka-riskov-oshibok-proektirovaniya (дата обращения: 14.09.2026).
2. Берденников Ф.Р., Синенко С.А. О приёме-передаче проектной и рабочей документации в подрядной строительной организации с использованием технологий информационного моделирования для организации строительного производства // Инженерный вестник Дона. 2025. № 5. URL: https://cyberleninka.ru/article/n/o-priyome-peredache-proektnoy-i-rabochey-dokumentatsii-v-podryadnoy-stroitelnoy-organizatsii-s-ispolzovaniem-tehnologiy (дата обращения: 14.09.2026).
3. Ермакова В.А., Саламатина А.С. BIM-моделирование в системах вентиляции // Инженерный вестник Дона. 2022. № 1. URL: https://cyberleninka.ru/article/n/bim-modelirovanie-v-sistemah-ventilyatsii (дата обращения: 14.09.2026).
4. Есаулов Г.В., Барчугова Е.В., Карелин Д.А., Моисеев Ю.М. Технологии искусственного интеллекта в архитектурной и градостроительной практике, науке и образовании // Architecture and Modern Information Technologies. 2026. Т. 1, № 74. С. 229–247. DOI: 10.24412/1998-4839-2026-1-229-247. URL: https://cyberleninka.ru/article/n/tehnologii-iskusstvennogo-intellekta-v-arhitekturnoy-i-gradostroitelnoy-praktike-nauke-i-obrazovanii (дата обращения: 14.09.2026).
5. Мальцев А.Б. Контроль качества проектной деятельности в строительстве // Вестник науки. 2023. Т. 3, № 11 (68). С. 956–967. URL: https://cyberleninka.ru/article/n/kontrol-kachestva-proektnoy-deyatelnosti-v-stroitelstve (дата обращения: 14.09.2026).
6. Мухаррямов И.Р. Основные критерии выбора среды общих данных для работы проектных организаций // Инженерный вестник Дона. 2024. № 3. URL: https://cyberleninka.ru/article/n/osnovnye-kriterii-vybora-sredy-obschih-dannyh-dlya-raboty-proektnyh-organizatsiy (дата обращения: 14.09.2026).
7. Савенко А.И., Черенков П.В. Среда общих данных при реализации строительных объектов с применением BIM // САПР и ГИС автомобильных дорог. 2019. № 2. DOI: 10.17273/CADGIS.2019.2.1. URL: https://cyberleninka.ru/article/n/sreda-obschih-dannyh-pri-realizatsii-stroitelnyh-obektov-s-primeneniem-bim (дата обращения: 14.09.2026).
8. Froese T. Future directions for IFC-based interoperability // Journal of Information Technology in Construction (ITcon). 2003. Vol. 8. P. 231–246. URL: https://www.itcon.org/paper/2003/17 (дата обращения: 14.09.2026).
9. Gallaher M.P., O'Connor A.C., Dettbarn J.L., Gilday L.T. Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry. NIST GCR 04-867. Gaithersburg, MD: National Institute of Standards and Technology, 2004. 210 p. URL: https://nvlpubs.nist.gov/nistpubs/gcr/2004/nist.gcr.04-867.pdf (дата обращения: 14.09.2026).
© Габидуллин Р.З., 2026