Все началось в далеком уже 2016 году, когда Президент России поручил в срок до 1 декабря разработать и утвердить план мероприятий по внедрению технологий информационного моделирования в сфере строительства (BIM).
С тех пор утекло много воды, о BIM-проектировании стали говорить даже те, кто к строительству имел весьма опосредованное отношение. Умы и мысли регулярно будоражились новыми поручениями и новыми сроками. Затем стали появляться новости одна другой фантастичнее: о полном внедрении BIM, о первых прохождениях экспертизы с BIM-моделью, о переходе к BIM на отечественном ПО… Сотни публикаций, отчетов, споры до хрипоты о терминологии, которые привели к тому, что звучное BIM (англ. Building Information Model) было заменено не менее звучным ТИМ (Технология информационного моделирования). Теоретически страна в едином порыве готовилась покорять космические пространства, и это не могло не пугать вдохновлять разработчиков ПО.
Но что же на практике? А на практике оказалось, что даже спустя годы внедрений и после километров публикаций об успехе подавляющее большинство проектных компаний испытывает сомнения в практической целесообразности применения технологии информационного моделирования. И в этом нет ничего странного, если учесть, что создание цифровой информационной модели (ЦИМ) требует:
И все ради чего? Ради красивой трехмерной картинки, которую можно так эффектно покрутить перед заказчиком?
О пользе применения технологии информационного моделирования много говорили на самых высоких уровнях. Это и удобное управление графиком строительства, и организация процесса строительного надзора, и учет расхода средств и материалов, и, наконец, наглядность контроля на этапе эксплуатации. Но ведь пока сам не пощупаешь, невозможно в полной мере осознать всю пользу?
Вот и вышло, что на этапе проектирования весь смысл цифровой информационной модели сводился к поиску геометрических пересечений между моделями разных дисциплин. И это, конечно, было полезно. Но душа требовала большего, особенно если учесть, что мы живем в эпоху победивших информационных технологий. Поэтому вскоре все заговорили об автоматическом поиске нормативных нарушений, а затем и об автоматическом проектировании в соответствии со стандартами.
Грандиозные планы разбивались о многолетние наслоения норм и стандартов, применявшихся в проектировании. Часть из них действовала еще с советских времен и, конечно же, устарела, часть только вступила в силу, но уже противоречила существующим требованиям, а порой и здравому смыслу. Одно было очевидно — с такой базой чуда не произойдет.
Решение было подсказано нашими западными тогда еще партнерами, и называлось это решение SMART-стандартами.
Согласно схеме развития стандартизации по классификации ИСО/МЭК (рис. 1), нормативные документы должны пройти несколько стадий эволюции.
Если совсем в двух словах, то бумажные стандарты развиваются в электронные версии — PDF, далее текст распознаётся и в структуре выделяются требования. Тут уже документ становится машиночитаемым, а когда множество машиночитаемых документов складывают свои классифицированные требования в единую базу — можно говорить о машиночитаемом контенте. Затем начинается настоящий космос: создание машиноинтерпретируемого контента путем изложения требований в виде логических выражений (выделение объекта, субъекта, предиката). У нас такие требования чаще называются машинопонимаемыми. И, наконец, появляется стандарт как сервис, то есть некий инструмент, автоматизирующий производственные процессы в соответствии с требованиями стандартов.
Эта схема всем очень понравилась, особенно она впечатлила поклонников всяких инноваций. Оставался открытым один вопрос: как же сказку сделать былью.
Решено было начать с разработки стандарта на SMART-стандарт, чтобы наши славные нормотворцы смогли сразу разрабатывать документы в машиночитаемом или машинопонимаемом (какая, в конце концов, разница?) виде. Собственно, с новой терминологией вышло много путаницы, поэтому как-то само собой заговорили о стандартах в формате XML, которые должны были решить почти все проблемы.
Оставалась самая малость — добиться того, чтобы в цифровой информационной модели присутствовала вся информация, которую можно проверять на соответствие нормам и стандартам. Сперва панацеей считался формат IFC, который магическим образом должен был отображать даже те связи между объектами, которые не были заложены при проектировании. Затем прагматичные экспертизы (СПб ГАУ «Центр государственной экспертизы» и ГАУ г. Москвы «Московская государственная экспертиза») стали выпускать свои требования к цифровым информационным моделям. В конце концов появился стандарт на информационное моделирование в строительстве. И вроде бы всё делалось правильно… но как-то в разные стороны и в отрыве от реальности.
Последний вопрос — вопрос обеспечения единства описания объектов ЦИМ в соответствии с нормами и стандартами — предполагалось решить созданием и применением Классификатора строительной информации (КСИ) для кодирования объектов. Эти же коды должны были использоваться при написании новых SMART-стандартов. Для надежности исполнения задуманного даже выпустили правительственное постановление, обязывавшее применять при проектировании Классификатор строительной информации. Методикой, правда, сперва не снабдили и примеров использования не показали. Но это всё мелочи по сравнению с величием задумки.
Долгое время компания «Нанософт» держалась в стороне от вопроса цифровизации стандартов и их применения при проверке информационных моделей, сконцентрировавшись на решении более прикладных задач автоматизации проектирования. Но однажды наступил момент, когда разговоры об инновационных технологиях, сулящих скорейшее наступление светлого будущего, перешли критическую черту, а мы уже не могли сдерживать любопытство. Пришлось приниматься за дело, открыв целое направление, имя которому NSR Specification.
И прямо с порога мы окунулись в суровую реальность:
Фактически никто не знал, что проверять в ЦИМ, как проверять и какой должна быть ЦИМ. Слишком много неизвестных для одного уравнения, но отступать было поздно.
Мы начали с того, что наметили для себя ряд основных вопросов, решение которых должно было способствовать достижению конкретной цели — автоматическому поиску нормативных нарушений в ЦИМ. Итак:
После чего решили разбираться с проблемами по мере их поступления.
Вопрос обработки нормативных текстов можно было решить двумя способами:
Мы как IT-компания предсказуемо взялись за автоматизацию. Нам нужен был инструмент, способный прочитать текст стандарта, подсказать границы требований и коды классификации для создания машиночитаемого контента. На полную автоматизацию рассчитывать не приходилось, особенно если учесть опечатки, противоречия и неточность терминологии, которой часто грешат нормативы. Но даже для того чтобы получить автоматические подсказки по обработке текста стандарта, нужно было научить компьютерную программу понимать этот текст. А значит не обойтись без алгоритмов машинного обучения, для создания которых были разработаны онтологические модели предметной области, основанной на Классификаторе строительной информации (рис. 2), нормативного документа и нормативного требования.
В итоге мы получили инструмент, автоматизирующий обработку нормативного текста, который используется командой экспертов при создании базы машиночитаемых требований для подсистемы требований NSR Specification.
Данный продукт является веб-ресурсом, доступ пользователей осуществляется в режиме онлайн. Главная задача подсистемы требований — упростить поиск и анализ информации из нормативных источников и предоставить справку о кодах КСИ, подходящих к тексту требования.
При создании базы нормативных требований в первую очередь обрабатываются документы, обеспечивающие соблюдение положений основных технических регламентов: «О безопасности зданий и сооружений» и «О требованиях пожарной безопасности». Процесс создания машиночитаемого контента является непрерывным и, естественно, учитывает изменения, вносимые в нормативные документы и Классификатор строительной информации.
Более подробная информация о продукте и способах получения тестового доступа найдется на странице www.nanocad.ru/products/nsr_specification.
Модуль семантической обработки NSR Specification, кончено же, не является волшебной палочкой. До сих пор нерешенными остаются вопросы обработки табличных данных и изображений. Но с учетом уже освоенных технологий хочется надеяться, что у нас есть все шансы на успех.
Как вы уже поняли, для автоматизации проверки ЦИМ одного машиночитаемого контента будет маловато, нужны машиноинтерпретируемые (машинопонимаемые) требования. Стремиться к которым мы решили путем семантического анализа. В идеале хотелось решить сразу две задачи: получить образцы для апробации проверки ЦИМ и наработать базу примеров для создания алгоритмов машинного обучения.
В ходе работ использовались два варианта семантической разметки.
В первом случае предварительно выделенные требования, полученные из базы данных, передавались в модуль обработки текста, реализующий его аннотацию. Аннотация текста заключалась в генерации дополнительных данных о тексте требования, необходимых для автоматической идентификации токенов, соответствующих размеченным классам, а также для последующей аннотации элементарных требований и семантических элементов в тексте. Использованный алгоритм аннотации текста требований состоял из трех этапов:
Результаты использовались при формировании шаблонов, предназначенных для автоматизации данного процесса разметки.
Для второго варианта был выбран формат разметки семантических ролей элементов требований на основе языка OWL. Использовался парсинг разметки семантических ролей элементов требований и ее конвертация в доработанный частично машиноинтерпретируемый формат: на вход подавался TSV-файл, на выходе получался файл в OWL-формате, содержащий машиноинтерпретируемое требование.
Ну, а если попытаться перевести с формально-программистского на общедоступный русский, то семантический анализ до боли в сердце напоминает выделение частей речи в предложении, из школьной практики. Дополняемый указанием связей слов и сопоставлением смысловых единиц требования с кодами КСИ (рис. 3).
И что же со всем этим делать, спросите вы. Именно в этот момент на сцену выходит потребность в программном продукте, где физически будут осуществляться проверки.
В качестве плацдарма для наших экспериментов был выбран программный комплекс CADLib Модель и Архив, разработка компании «СиСофт Девелопмент». Причин тому несколько:
Помимо этого, поддерживается импорт цифровых информационных моделей из различных форматов, включая всеми любимый IFC, и прямая публикация из нативных форматов BIM-решений на Платформе nanoCAD.
Обрадованные таким удачным решением, мы принялись за разработку конвертера текста требования, подвергнутого семантическому анализу, в XML-формат профиля проверки на коллизии, который можно импортировать в CADLib Модель и Архив.
Дело оставалось за малым — найти ЦИМ, закодированную по КСИ, чтобы проверить работоспособность создаваемых проверок. Но, как уже сказано, с применением Классификатора строительной информации при проектировании все оказалось не так просто…
В силу описанных трудностей все опытные ЦИМ, созданные различными проектными компаниями, были не похожи друг на друга и ко всем бедам очень отличались от нашего представления об идеале.
Отступать мы и не думали. Поэтому было принято решение поработать над проверкой ЦИМ без учета кодов КСИ. Мы взяли модели, предоставленные нашими заказчиками, и модели, созданные в рамках внутренних пилотных проектов. И, наконец, смогли систематизировать список проблем:
В CADLib Модель и Архив также есть поддержка нужной нам структуры (рис. 4), но на практике проектировщики чаще всего ограничиваются связью объекта с этажом.
Вот пример хорошего описания — см. рис. 5. Тут указано наименование (Свая железобетонная) и даже есть раздел классификации с указанием принадлежности к глобальной группе Строительных конструкций, и конкретизация, свидетельствующая, что объект является частью Фундамента.
А вот другой пример из той же ЦИМ (рис. 6). Здесь уже довольно сложно разобраться, с каким объектом мы имеем дело, потому что вместо наименования указан размер, а параметры классификации приписывают объект к таинственной группе Составных профилей. Забегая вперед, скажу, что объект является колонной каркаса здания.
Иногда попадаются объекты, об имени которых можно догадаться только по типу IFC, который, как известно, может быть довольно общим.
Откуда такая пестрота описаний?
Во-первых, дело в разнообразии инженерного ПО, используемого для информационного моделирования.
Во-вторых, базы элементов в САПР чаще всего создавались не одномоментно, а в течение длительного времени и разными разработчиками. Основной упор при создании объектов делался на их трехмерном представлении и параметрических свойствах, а не на единообразном описании.
В-третьих, человеческий фактор, по причине которого при проектировании могут быть допущены ошибки в заполнении значений параметров объекта.
А теперь давайте посмотрим, как нормативные документы описывают объекты требований — на примере Таблицы 21 из Технического регламента о требованиях пожарной безопасности (123-ФЗ) — (рис. 7).
Получается, если мы хотим, чтобы проверка ЦИМ действительно соответствовала тексту нормативного требования, то у конструктивных элементов должны быть указаны следующие параметры:
После всех сделанных открытий оставалось только сложить кубики пазла:
Начнем с хороших новостей: всё заработало (рис. 13).
Используя инструмент проверки на коллизии в CADLib Модель и Архив, действительно можно воссоздать поиск нормативных нарушений и очень наглядно оценить результаты.
Мы не поленились и создали к каждой проверке выноски с текстом нарушения и ссылкой на нормативное требование. Получилось здорово и вдохновляюще!
А теперь к сложностям.
Тем не менее, эксперимент мы посчитали удачным, решение было одобрено к тиражированию.
Так как же соотнести объекты ЦИМ с текстом нормативных требований — с учетом всего многообразия художественных оборотов и вольной терминологии, используемой нормотворцами? На самом деле Классификатор строительной информации и сейчас остается главной надеждой борцов за автоматизацию экспертизы ЦИМ. Но в силу причин, озвученных выше, возможности применять его на практике прямо сейчас — нет.
Поэтому мы решили выработать свой порядок описания объектов ЦИМ, сделав основной упор на группировке объектов (рис. 14). Иными словами, если нормативный документ требует особых характеристик у объектов, являющихся частью каркаса здания, то каждая балка должна знать, что является частью каркаса. В силу того что необходимо было предусмотреть все возможные варианты группировки, от глобальной до частной, выработана иерархия структуры по принципу «матрешки»:
Техническая система → Функциональная группа → Функциональная подгруппа → Сборка → Объект → Деталь объекта.
Пример:
Конструктивная система → Каркас → Бесчердачное покрытие → Ферма → Балка → Крепеж.
Это первая группа характеристик.
Далее мы предусмотрели наличие параметров, которые могут содержать сведения о типе системы, группы, подгруппы, в которую входит объект. Например, Группа «Фундамент» с типом «Свайный». Это вторая часть.
Третья группа характеристик содержит информацию о вхождении объекта в особые зоны, выделяемые в нормативных документах. Это лестничные клетки, пути эвакуации, тамбур-шлюзы. Когда проектировщики освоят создание зон и помещений в структуре здания и привязку к ним, от объектов этой группы характеристик можно будет отказаться. Но пока — так.
И, наконец, четвертая группа — это собственные характеристики объекта. Им мы уделяли меньше всего внимания, потому что большая часть этих сведений уже содержится в описании объектов.
И, самое главное, в центре — собственное имя объекта, которое принципиально необходимо отличать от имени изделия, из которого объект выполнен. В большинстве ЦИМ на этом моменте возникает путаница и колонна начинает называться трубой квадратной.
Кроме этого, был разработан набор параметров для описания зданий и помещений.
Используя разработанную схему описания объектов, команда NSR стала успешно наводить порядок в пользовательских ЦИМ и создавать профили проверок, претендующие на универсальность.
Процесс применения новых параметров получился, конечно, весьма трудоемким. Поэтому параллельно мы стали разрабатывать приложение для CADLib Модель и Архив, автоматизирующее описание объектов по шаблонам. Но, если смотреть правде в глаза, то правильнее закладывать необходимые данные сразу при проектировании. Решить эту задачу мы надеемся через обновление баз стандартных объектов в BIM-приложениях, закрепив эффект BIM-стандартом.
Но и Классификатор строительной информации мы бросать не предполагаем. Подвергая требования семантическому анализу, продолжаем создавать слой разметки с кодами КСИ и разрабатываем схему синхронизации с разработанными параметрами NSR. И у нас даже получилось реализовать успешный пилотный проект с проверкой ЦИМ по кодам КСИ. Но это отдельная история, достойная рассказа в следующей серии J.
Только увидев свет в конце тоннеля в виде практически применимых решений для проверки ЦИМ, мы смогли в полной мере осознать, какого объема задачу взяли в работу, и что шансы на успех были не слишком велики.
Сейчас у нас большие планы на будущее:
Но есть и узкое место, вызывающее особенные опасения: отнюдь не все требования нормативных документов поддаются легкой и безболезненной конвертации в правила проверки не только автоматически, но и вручную.
Хорошо работать с требованиями, которые говорят четко: «Ширина путей движения (в коридорах, галереях
Но чаще всего нормативные документы на этом не останавливаются, продолжая: «…допускается ширина коридора 1,5−1,2 м с организацией разъездов (карманов) для кресел-колясок длиной не менее 2 м при общей с коридором ширине не менее 1,8 м в пределах прямой видимости следующего кармана».
Разумеется, такие конструкции надо упрощать, сохраняя смысл и последовательность проверки. И это тоже можно попробовать решить применением семантического анализа и алгоритмов машинного обучения. Так что впереди у нас много захватывающих исследований, о результатах которых мы обязательно будем рассказывать!
