Строительная фирма: BIM-модели по 6 ГБ и общий доступ для подрядчиков

MAATRIX

Сводная BIM-модель среднего жилого корпуса легко весит 5-6 ГБ, а на объекте с ней одновременно работают архитекторы, конструкторы, инженеры ОВиК и электрики, генподрядчик и пара субподрядчиков помельче. Отправить такой файл по почте нельзя технически, через мессенджер — можно, но через час уже непонятно, у кого какая версия на диске. Разберём, почему для стройки общий доступ к модели — не удобство, а вопрос того, не забьёт ли монтажник вентиляции стену, которую конструктор в последний момент подвинул на полметра.

Почему BIM-модель не проходит через обычную пересылку

Файл сводной модели — это не один чертёж, а слепок всего проекта: геометрия, атрибуты элементов, связи между дисциплинами, иногда история изменений внутри самого файла. Даже когда экспортируется частичный срез — только конструктив, только инженерные сети — вес легко переваливает за несколько гигабайт, потому что в модели хранятся не линии на плоскости, а объёмные объекты с параметрами.

Почта режет вложения на уровне 20-25 МБ у большинства провайдеров, так что 6-гигабайтный файл в письмо просто не помещается — приходится либо дробить архивом на части, либо лезть за внешней ссылкой. Мессенджеры вроде WhatsApp или Telegram технически способны передать файл такого размера, но это лотерея: пережатие на стороне сервиса, обрыв на слабом канале у прораба на объекте, отсутствие истории — если сообщение с файлом потерялось в ленте из трёхсот других сообщений, найти его снова та ещё задача.

Второй момент — надёжность самой передачи. При загрузке файла в 5-6 ГБ через нестабильное мобильное соединение (а прораб на площадке чаще сидит на 4G, чем на оптике) велика вероятность оборвать передачу на середине. Часть облачных сервисов и мессенджеров в таком случае либо откатывают загрузку целиком, либо — что хуже — сохраняют повреждённый файл без предупреждения, и подрядчик открывает модель, которая на первый взгляд цела, а на деле обрублена.

Что ломается, когда версии расходятся между подрядчиками

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

Дальше — классический сценарий коллизии: воздуховод проложен по координатам старой модели и упирается в колонну, которой там уже не должно быть по новой версии, но никто заранее это не увидел, потому что каждый смотрел в свою копию. На бумаге такие расхождения всплывают на площадке — там, где переделка стоит уже не часы работы за компьютером, а простой бригады и порезанный металл.

Второй симптом того же рассинхрона — бесконечные файлы вида model_final_v3_ispravlennaya_ot_ivanova.ifc. Когда версии расходятся по десяткам локальных копий у разных организаций, невозможно однозначно сказать, какая из них актуальна прямо сейчас, и приходится каждый раз уточнять созвоном или перепиской — вместо того чтобы просто открыть файл и увидеть дату последнего изменения.

Централизованное хранилище: одна модель, один источник правды

Решение звучит не как откровение, но именно оно закрывает обе проблемы разом: собственный сервер, на котором лежит текущая версия сводной модели и на который у всех подрядчиков объекта есть доступ по сети. Не копия у каждого в почте, а одна папка, к которой подключаются все участники — с правами, соответствующими их роли в проекте.

Смысл в том, что «актуальная версия» перестаёт быть вопросом переписки. Конструктор сохранил изменения — файл на сервере обновился, и у всех остальных участников синхронизация подтянула новую версию (или как минимум они увидели свежую дату при следующем открытии). Никто не спрашивает в чате «а у тебя какая версия», потому что версия ровно одна, и она физически лежит в одном месте.

Отдельный практический плюс — сервер снимает зависимость от чужой инфраструктуры. Публичные облачные сервисы синхронизации периодически меняют тарифные лимиты, режут скорость для больших файлов на бесплатных и даже платных планах, ограничивают число участников общей папки. Собственный сервер с фиксированной конфигурацией такими сюрпризами не грозит — сколько подрядчиков подключить и сколько места выделить под архив моделей, решает проектная команда, а не тарифная политика стороннего сервиса.

Похожий подход применим и на соседнем участке той же стройки — при работе с версиями чертежей у конструктора та же логика: версии чертежей конструктора на своём сервере разбирают, как выстроить историю изменений для 2D-документации, которая сопровождает BIM-модель.

Как это устроено технически: файловый сервер с синхронизацией

На практике для такой задачи не нужна экзотика — достаточно поднять на арендованном сервере файловое хранилище с синхронизацией, вроде Nextcloud или Seafile, и организовать структуру папок по дисциплинам и подрядчикам:

/bim-project/
  01-svodnaya-model/        # актуальная сводная модель
  02-arhitektura/           # рабочие файлы архитектора
  03-konstruktiv/           # рабочие файлы конструктора
  04-ovik/                  # инженерные сети — вентиляция
  05-elektrika/             # инженерные сети — электрика
  06-arhiv/                 # снятые с работы версии, по датам
  07-obschie-dokumenty/     # регламенты, графики, ТЗ на координацию

Каждый подрядчик подключается через клиент синхронизации (десктопное приложение или веб-интерфейс) и работает со своей рабочей папкой напрямую, а в 01-svodnaya-model попадают только согласованные, сведённые версии — их туда выкладывает ответственный BIM-координатор, а не каждый участник по своему усмотрению.

Между Nextcloud и Seafile для такой задачи есть разница в поведении с крупными файлами: Seafile изначально проектировался под блочную синхронизацию и при повторной загрузке пересылает только изменённые блоки файла, а не весь файл целиком — для модели в 6 ГБ, где правки затрагивают небольшую часть геометрии, это ощутимо экономит трафик и время на каждой синхронизации. У Nextcloud базовая синхронизация в большинстве конфигураций работает по файлу целиком. Разбор конкретных плюсов и минусов обеих систем — в отдельной статье: Seafile или Nextcloud — что выбрать для сервера.

Для самой установки Nextcloud есть готовый Docker Compose файл — поднимается за один проход без ручной настройки веб-сервера и базы отдельно.

Права доступа и блокировки, чтобы никто не перезаписал чужую работу

Общий сервер решает проблему разрозненных копий, но открывает новую — что если два человека одновременно правят один и тот же файл и сохраняют изменения почти одновременно? Здесь важны два механизма.

Первый — разграничение прав по ролям. Субподрядчик по электрике не должен иметь возможность редактировать файлы конструктива, даже если ему нужен к ним доступ для просмотра. В Nextcloud и Seafile это делается через группы пользователей и права на конкретные папки:

Второй механизм — блокировка файла на время редактирования (file locking). Когда конструктор открывает файл сводной модели для правки, система помечает его как занятый, и второй пользователь либо видит предупреждение, либо получает файл в режиме только для чтения, пока блокировка не снята. Это стандартное поведение большинства платформ для совместной работы с файлами, и его стоит включать явно — без него рано или поздно кто-то перезапишет чужие правки последним сохранением, и они просто исчезнут без предупреждения.

Отдельно стоит продумать доступ для подрядчиков, которые появляются на проекте временно — субподрядчик закончил монтаж вентиляции и покинул объект, но учётная запись с доступом к серверу у него осталась. Порядок выдачи и, что важнее, своевременного отзыва доступа для внешних участников подробно разобран в чек-листе: передача сервера подрядчику: чек-лист по доступам и рискам — логика та же, даже если сервер не передаётся целиком, а выдаётся доступ только к разделу с моделями.

Сеть, скорость передачи и резервные копии

Модель в 6 ГБ — это заметная нагрузка на канал, и её стоит спланировать заранее, а не выяснять постфактум, почему у прораба на площадке синхронизация идёт двадцать минут. Ориентировочно: при канале порядка 100 Мбит/с (это около 10-12 МБ/с реальной пропускной способности с учётом накладных расходов протокола) полная загрузка файла в 6 ГБ займёт примерно 8-10 минут — терпимо, если это происходит несколько раз в день, а не при каждом мелком изменении. Цифры сильно зависят от канала конкретного подрядчика, поэтому воспринимайте их как порядок величины, а не гарантию.

Именно поэтому важно выбирать инструмент синхронизации, который передаёт не весь файл при каждом изменении, а только разницу — это кратно снижает объём трафика на каждой правке и делает работу с большими моделями терпимой даже для подрядчиков на слабом канале где-нибудь на удалённой площадке.

Второй практический момент — резервные копии. Централизованное хранилище удобно ровно до момента, пока с ним ничего не случилось: сбой диска, ошибочное удаление, случайная перезапись сводной модели старой версией. Раздел 06-arhiv внутри самого хранилища — это не бэкап, а просто снятые с работы версии; настоящая резервная копия должна лежать отдельно от рабочего сервера, по расписанию, с ротацией хотя бы за пару недель, чтобы можно было откатиться не только к «вчера», но и к состоянию до конкретной ошибки, обнаруженной не сразу.

Для проекта, который тянется месяцами и накапливает архив моделей, чертежей и фотофиксации по этапам, стоит сразу закладывать сервер с запасом по диску — расширять хранилище на живом проекте с десятком подключённых подрядчиков менее удобно, чем выбрать конфигурацию заранее. Подборка конфигураций под такую задачу собрана здесь: выделенный сервер в Великобритании для файлового хранилища на терабайты.

Частые вопросы