BIM-замечания: модель, ответственное задание и статус

Связь начинается с одного замечания

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

Мы предлагаем начинать разработку системы BIM-замечаний с такого сквозного сценария. На одном замечании проверяем форматы, идентификаторы и права, затем согласуем правила переноса. Результат для BIM-менеджера: матрица обмена и сценарий приёмки, по которым можно оценить первую версию системы. Ниже разберём, какие данные нужны и как проверить потерю объекта после обновления модели.

BCF, BIM Collaboration Format, описывает обмен темами замечаний между BIM-продуктами. Геометрию модели и её версии ведём отдельно: тема с текстом и сохранённым видом сама по себе не подтверждает, что в портале открыта нужная выгрузка. В BCF-XML 3.0 buildingSMART прямо предусмотрено сопоставление файлов с моделями принимающего приложения.

Матрица одного обмена BCF

Тема замечания, объект модели и задача портала имеют разные идентификаторы. GUID темы позволяет узнать прежнее замечание при повторном импорте. Идентификатор элемента помогает найти геометрию в конкретной модели. ID задачи нужен, чтобы обновить уже созданное поручение. В договорённости об обмене сохраняем все три связи.

Например, тема «Пересечение воздуховода и балки» может ссылаться на несколько элементов и содержать несколько видов. Для первой проверки выбираем один вид и нужные элементы. Остальные данные сохраняем или явно фиксируем предел переноса, чтобы команда знала, какой контекст увидит инженер.

Поля TopicStatus, AssignedTo и состав сохранённого вида описаны в спецификации BCF-XML 3.0. Собственную версию выпуска модели и связь с задачей мы добавляем в контракт интеграции. Наличие поля в стандарте ещё требует проверки его чтения и записи в выбранных продуктах.

Увеличить

Кто разрешает закрыть замечание

Статус задачи «Выполнено» может означать, что инженер закончил работу. Статус темы «Закрыто» может требовать проверки координатором. Если сопоставить их только по названию, система закроет замечание до проверки исправленной модели.

Для такого процесса мы предлагаем правило: завершение задачи переводит тему в «Ожидает проверки». Координатор сверяет новую модель и подтверждает закрытие. Это пример проектного маршрута; окончательные значения берём из правил вашей команды и возможностей продуктов. Для каждого перехода записываем, кто инициирует изменение, кто разрешает его и где хранится итог.

В BCF API 3.0 предусмотрены права на действия и доступные значения статуса, в том числе для отдельной темы. Эти права проверяем вместе с правилами портала. Если переход запрещён или значение неизвестно, сохраняем прежний подтверждённый статус и показываем причину ответственному за сверку.

После отправки изменения читаем результат принимающей системы. Пока подтверждения нет, в портале показываем «Изменение ожидает передачи» или понятную ошибку. Так BIM-менеджер различает запрос инженера и статус, который другая сторона действительно приняла.

Проверка новой модели и потерянного объекта

Допустим, воздуховод пересоздали при исправлении модели. В новой выгрузке прежний GUID отсутствует. Геометрия рядом может быть похожей, но автоматическая привязка по близости способна увести замечание к другому элементу. Мы предлагаем вынести такую тему на сверку координатору.

Система сохраняет исходную версию, вид и историю задачи. Для новой версии показывает «Объект не найден» и список связей, которые требуют проверки. Координатор может подтвердить замену элемента или закрыть замечание по результату проверки. Удаление объекта само по себе не доказывает устранение коллизии.

Даже если GUID сохранился, проверяем, что элемент принадлежит нужному файлу и выпуску. Для сборной модели фиксируем версии участвующих файлов. Если сопоставление невозможно, оставляем исторический контекст доступным и явно отмечаем, что привязка к текущей модели ещё не подтверждена.

Увеличить

BCF-файл, API и связка с Navisworks

Файловый обмен удобен для контролируемой загрузки пакета замечаний. BCF API рассматриваем, когда доступные интерфейсы продуктов позволяют читать и изменять темы через сервис. В обоих вариантах проверяем состав данных и обратное направление: импорт темы не доказывает возможность вернуть её статус.

Для интеграции Navisworks с корпоративным порталом сначала уточняем версию и редакцию продукта, установленное расширение, формат выгрузки и разрешённый способ доступа. Документация Navisworks 2026 описывает экспорт сохранённых видов в XML. Этот файл требует отдельного разбора; перенос темы BCF, ответственного и статуса проверяем на конкретной связке продуктов.

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

Сам поиск коллизий, редактирование модели и разработка плагина для авторского продукта оцениваются отдельно. Для системы замечаний сначала достаточно связать уже найденную тему с поручением и проверкой результата. Разработка API-интеграции строится вокруг этого согласованного обмена.

Что принять до расширения системы

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

1. Обычный импорт. В портале появляется одна задача с темой, ответственным, ссылкой на согласованную модель и сохранённым видом.
2. Повтор без полученного ответа. Повторно передаём ту же тему, когда не получили ответ о создании задачи. Система сверяет связь проекта, GUID темы и ID задачи; второе поручение не появляется в этом сценарии.
3. Неизвестный статус. Передаём значение без соответствия. Оно попадает на сверку и не закрывает замечание автоматически.
4. Недостаточно прав. Пытаемся изменить статус пользователем без разрешения. Подтверждённый статус сохраняется, причина отказа видна в журнале.
5. Обновление модели. Сверяем прежние ссылки с новым выпуском. Удалённый объект получает признак потери связи; система не выбирает другую геометрию автоматически.
6. Обратное изменение. Выполняем разрешённый переход, читаем итог на стороне владельца статуса и сравниваем с порталом.

Для каждого теста сохраняем входные данные, ожидаемый результат и фактическое состояние обеих систем. Если обмен остановился, BIM-менеджер видит тему, причину и действие для восстановления. Протокол этих проверок задаёт основание для расширения на другие проекты и роли.

Как мы подходим к обмену между системами

В мобильном магазине «Бакаев» мы связали приложение, админ-панель и 1С через сервер синхронизации. Сотрудник меняет фотографию в админ-панели, и она отражается в 1С. Заказ из приложения меняет остатки в админ-панели и учётной системе; изменения из 1С доходят обратно до приложения.

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

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

Вопросы перед заказом

Проверим один обмен BIM-замечанием

Пришлите один BCF issue, версии продуктов и правила статусов. Проверим контракт обмена и предложим карту соответствий, ограничений и приемочный сценарий.

Проверить реализуемость обмена