LOD — широко используемая аббревиатура, но она не всегда понимается одинаково в разных частях мира. Более десяти лет это сокращение означало такие понятия, как «уровень детализации» (level of detail) и «уровень разработки» (level of development), при этом также получили распространение связанные с ними варианты — «уровень информации» (level of information), «уровень точности» (level of accuracy), «уровень геометрии» (level of geometry), «уровень разработки модели» (level of model development), имеющие разный смысл. Во многих корпоративных и государственных руководящих документах были приняты различные трактовки термина LOD, которые использовались во множестве планов реализации BIM (BIM execution plans, BEP) для строительных проектов. Но поскольку концепции различны и их реализация иногда неоднозначна, достаточно сложно сформулировать четкие требования к информации и обеспечить ее последовательное предоставление.

Более того, публикация стандарта ISO 19650-1:2018 привела к появлению новой концепции «уровня потребности в информации» (level of information need), которая, с одной стороны, призвана усовершенствовать подход к тому, как оптимально определить требования к информации на протяжении всего жизненного цикла проекта, а с другой — может внести путаницу в существующую практику отрасли.

В этой статье представлены упомянутые выше связанные концепции и дается актуальная информация о глобальном стандартизованном подходе, который вводит понятие «уровень потребности в информации» в контекст информационного моделирования зданий (BIM).

Концепция и история LOD

Хороший обзор истории и эволюции LOD можно найти в статье Марции Болпаньи (MACE) «Many Faces of LOD» [1]. В ней рассматриваются несколько примеров компаний и организаций из разных стран, которые разработали схожие концепции, и выполняется сравнение использующих их систем.

До внедрения BIM основным методом коммуникации в проектах были чертежи и спецификации. Чертежи абстрактно показывали компоновку, размеры и общую топологию проекта. Используя аннотации и ряд условных обозначений, чертежи могли передавать много информации о проекте. Особое значение в этом обсуждении имеет то, как масштаб чертежа влияет на передачу деталей: крупномасштабные чертежи не показывают деталей, но могут отображать глобальное позиционирование и контур проекта на строительной площадке. Чертежи среднего масштаба показывают структуру и основные размеры строительных объектов, дополненные аннотациями, такими как размеры и текстовые метки. В мелком масштабе показываются компоненты строительных объектов, их соприкосновение и связанность. Эта практика, существовавшая задолго до появления САПР, широко распространена и сегодня. Однако все больше и больше проектов разрабатывают такие типы документов с использованием программного обеспечения для BIM, например Archicad, Revit  или Vectorworks, и компонуют проект с использованием параметрических 3D-объектов, которые представляют объекты реального мира.

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

Одно из первых определений LOD трактуется как уровень детализации (level of detail), и оно до сих пор широко применяется в контексте географических информационных систем (ГИС), а также в разработке игр, где можно получить отображение бесчисленных цифровых объектов в реальном времени путем показа объектов с плавным изменением детализации в зависимости от их расстояния от зрителя. Объекты на расстоянии могут отображаться как упрощенные, но переключаются на варианты с высокой детализацией при просмотре вблизи.

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

Потребность в такой информации меняется на протяжении всего проекта, и какая-то информация необходима или известна только на определенной стадии проекта. Более того, информацию можно считать достоверной только после достижения определенных ключевых точек принятия решений — например, когда нужно приступить к строительству или извлечь объемы. Под так называемым уровнем разработки (level of development), или уровнем разработки модели (level of model development), подразумевается уровень достоверности.

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

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

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

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

Стандартизация “Level of D”

Поскольку этот процесс очень похож в разных странах и строительных проектах, имеет смысл стандартизовать подход, чтобы помочь людям оптимизировать методы моделирования. Вместо того чтобы использовать традиционные масштабы чертежей, были установлены такие понятия, как «уровень детализации» (level of detail), «спецификация прогрессии модели» (model progression specification) и «уровень разработки» (level of development). Выше мы привели ссылку на статью Болпаньи, в которой представлен подробный обзор и сравнение различных подходов.

Еще одной широко используемой спецификацией, связанной с LOD, является «Спецификация уровня разработки» (“Level of Development Specification”), которая ежегодно публикуется и обновляется на сайте BIMForum [2] и основана на спецификациях Американского института архитекторов (AIA). Эта спецификация содержит общий подход со ссылками и примерами в двух руководящих документах. Первая часть знакомит с концепциями и содержит обширную серию иллюстрированных объяснений для различных строительных объектов с акцентом на то, как объекты или элементы модели могут развиваться в ходе проекта. Во второй части представлен набор таблиц, описывающих свойства, и поясняется, как вы можете специфицировать требования на буквенно-цифровом уровне на разных этапах проекта.

Для лучшего понимания приведем здесь наиболее важные понятия из спецификации BIMForum:

• Уровень разработки (level of development) указывается на уровне объекта, а не модели, поскольку разные объекты могут находиться на разных уровнях разработки в рамках одной модели.
• Термин «детализация» (detail) заменен термином «разработка» (development) для обозначения степени, в которой вы можете полагаться на информацию, а не степени детализации информации.
• Первоначально было определено пять основных уровней с использованием числовой метки с шагом в 100, что теоретически позволяет при необходимости использовать промежуточные уровни. Ярлыки сами по себе довольно произвольны, но представляют постепенную эволюцию, которая обычно наблюдается в проекте.

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

Кроме того, LOD 500 больше не рассматривается, так как между ним и LOD 400 нет геометрической разницы. Кроме того, использование «уровней» для буквенно-цифровой информации в Части 2 было заменено списком требуемых свойств для различных стадий или вех проекта, что является более простым методом для понимания и интерпретации.

Поясним это на нескольких примерах.

Стальная колонна будет простой коробкой при LOD 100 и упрощенным однотавровым или двутавровым профилем при LOD 200. При LOD 300 у вас будет точный профиль и форма объекта. Начиная с LOD 350, вы получаете еще и соединительные пластины, болты и анкеры, а в конце, при LOD 400, в геометрию будут добавлены даже сварные швы, шайбы и гайки.

На уровне LOD 100 окна и двери будут только обозначены на модели. При LOD 200 у вас будет объект с указанием его размера и глубины, но ничего больше. При LOD 300 будет геометрически отображено различие между панелью остекления, стойками и компонентами. При LOD 350 — и особенно при LOD 400 — у вас будут точные профили, системы поддержки и даже герметики, накладки и мембраны. Этот последний уровень часто не требуется в модели, если только элемент модели не используется в качестве входных данных для генерации производственной информации.

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

Из вышеприведенных примеров понятно, что не всегда необходимо иметь все элементы на одном уровне: вполне достаточно иметь в проекте окна уровня LOD 300, тогда как для элементов структурной модели может потребоваться LOD 350 или даже LOD 400. И наоборот, некоторые элементы мебели или механические, электрические и сантехнические (MEP) элементы никогда не должны иметь LOD выше 200 или 300.

LOD в программном обеспечении BIM

Программное обеспечение для моделирования от разных вендоров реализует общий подход к созданию объектов: в зависимости от ваших целей вы можете сделать их очень детализированными или полностью абстрактными. Используя различные инструменты просмотра и конфигурацию фильтров и параметров отображения, вы разрабатываете модель, которая может быть представлена с различной степенью детализации по мере необходимости. Мы проиллюстрируем это с помощью двух распространенных программных систем: Autodesk Revit и Graphisoft Archicad.

Autodesk Revit широко используется в проектах любого масштаба. Но хотя программное обеспечение поставляется с набором контента (семействами) по умолчанию, большинство офисов взамен этого разрабатывают свои собственные библиотеки или используют коммерчески доступные. В настройках любого графического представления вы можете указать нужный уровень детализации: грубый, средний или подробный. Это может повлиять на представление вносимого вами контента, поскольку вы можете сделать видимость (под)компонентов зависимой от этого уровня детализации. Однако эти три фиксированных уровня не соответствуют непосредственно уровням детализации из BIMForum, поэтому вы должны задать правила отображения — например, использовать «грубый» для LOD 100 и 200, «средний» для LOD 300 и 350 и «подробный» для LOD 400. Однако это не является общим правилом, и практическая реализация может значительно отличаться от приведенного примера. Возможно, вы предпочтете «подробный» для уровней детализации от 300 до 400 и используете другие средства, чтобы различать общее и конкретное содержимое, например, заменяя одни семейства другими. Кто-то может сделать LOD пользовательским параметром, используя его в определении семейства для управления видимостью определенных компонентов для отражения уровня детализации, но это также не является общим правилом. На уровне вида (view) он устанавливается независимо от масштаба изображения.

В Graphisoft Archicad применяется другой подход. Объекты библиотеки Archicad создаются с использованием языка геометрического описания (Geometric Description Language, GDL), и разработчик объекта сам решает, нужно ли принимать во внимание такие аспекты, как Scale или Model View Options (MVO). Даже в этом случае нет прямого соответствия между масштабом чертежа и уровнем детализации, поэтому пользователь может интерпретировать это по-своему. Однако механизм MVO является более упорядоченным, поскольку он обеспечивает глобальный контроль над видимостью и уровнем детализации, при этом для большинства объектов используется набор уровней «схематический, упрощенный, полный», а для некоторых даже «низкий 1, низкий 2, средний, полный 1 и полный 2». MVO устанавливается для каждого вида, что позволяет адаптировать несколько объектов без дополнительных действий со стороны пользователя.

Главным отличием от подхода Revit является то, что объект в Archicad остается очень компактным, поскольку один скрипт может работать с целым рядом масштабов или уровней детализации, что делает объект чувствительным к масштабу. При работе с семействами на основе геометрии в Revit вам необходимо встраивать все различные уровни детализации в семейства, увеличивая размер их файлов и проекта, в котором они используются. Это также может повлиять на производительность программного обеспечения, особенно при работе с большими файлами моделей.

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

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

Для сравнения, в программном обеспечении для управления спецификациями и требованиями, таком как Plannerly [3] или BIMQ [4], стратегически принят более общий, открытый подход к LOD и связанным с ним спецификациям. Вместо того чтобы фиксировать уровни, эти платформы позволяют вам настраивать и маркировать различные уровни по своему усмотрению, например в соответствии с региональным стандартом. Они предоставляют шаблоны или предварительно сконфигурированные настройки со спецификацией LOD от BIMForum, используемой в качестве отправной точки из-за ее широкого распространения.

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

Ряд соображений, касающихся уровня разработки (Level of Development)

С момента своей первой публикации почти десять лет назад спецификация BIMForum получила широкое распространение не только в США, но и во всем мире. Технология уточнения изображений оказалось привлекательной для многих практиков BIM в разных странах.

Однако внедрение этого метода в отрасли также вызвало некоторые сложности и до сих пор является предметом обсуждения в проектах. Простая на первый взгляд концепция пяти уровней детализации становится крепким орешком в повседневной практике.

Достаточно ли пяти уровней?

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

Возможно, уровни — это просто фазы проекта?

Хотя такая концепция не подразумевается в LOD спецификациях, предложенных BIMForum, во многих других руководствах эта взаимосвязь довольно явная, с уровнями, определяемыми для каждой фазы проекта и увеличивающимися с каждой следующей фазой, например — 100 для краткого описания, 200 для предварительного проектирования, 300 для окончательного проекта, 350 для технического проектирования и согласования и 400 для строительства.

В таких случаях «метки» становятся набором вех, которым сопоставляются соответствующие объем и достоверность информации.

Как измерить LOD?

Хотя спецификация требований к информации предназначена для создания информации (например, насколько подробно следует моделировать колонну или балку?), оценка уровня LOD на стадии передачи готовой модели — совсем не тривиальная задача.

Немного громоздкое решение можно найти во второй части спецификации BIMForum, где предлагается использовать два вида LOD: целевой LOD и текущий LOD. Целевой LOD представляет предполагаемый уровень детализации, но текущий LOD оценить нелегко, не говоря уже о проверке. Задача чтения геометрического представления элемента и определения его уровня детализации не решена. Были предприняты попытки использовать методы, основанные на правилах, и даже модели машинного обучения, которые продемонстрировали некоторый прогресс, но сама формулировка уровней детализации не является достаточно полной.

Например, представьте себе простую прямоугольную стену или колонну без проемов или специального армирования из однородного материала. Она будет представлена в виде коробки почти на каждом уровне, за исключением, может быть, LOD 400 или, возможно, 350.

А как насчет уровня информации (Level of Information)?

Более ранние версии спецификации LOD предлагали определять профили LOD с помощью свойств, требующихся на каждом уровне. Мы сталкивались со многими проектами и рекомендациями, в которых говорилось, что

LOD = LOG + LOI (LOG — Level of Geometry, LOI — Level of Information).

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

Когда вы указываете LOD 300 для некоторого элемента, вам все равно необходимо свериться с таблицей требований, чтобы подтвердить завершение вехи проекта, поскольку в ней должно быть указано, какие реквизиты необходимы для каждого из обозначенных классов элементов.

Упрощенный фрагмент таблицы требований к свойствам:

Object: Column	Description	Data Type	Milestone 1	Milestone 2	Milestone 3
Identification
Name/Number	Assigned object number/code	Text		X	X
ID	Unique ID	GUID	X	X	X
Profile	Profile designation	Text		X	X
Steel grade	Code	Text		X	X
Fabrication Nr	Manufacturer ID	Text			X
Dimensions
Width	Nominal width of the profile	Length	X	X	X
Depth	Nominal depth of the profile	Length	X	X	X
Performance
Fire rating	Designation	Text		X	X
Load bearing	Intended to carry loads?	Boolean	X	X	X

Переход к Уровню потребности в информации (Level of information Need)

В 2018 году комитет ISO/TC 59/SC 13, отвечающий за разработку международных стандартов информационного моделирования зданий для строительных работ, опубликовал первые две части серии ISO 19650. Основанные на работе, проделанной Великобританией в серии BS/PAS 1192, эти стандарты, относящиеся к процессам, направлены на гармонизацию управления информацией на протяжении всего жизненного цикла проекта. Не являясь подробными техническими стандартами по технологии или форматам, связанным с BIM, они, скорее, определяют сам процесс, вводя новую серию концепций и принципов (ISO 19650-1), описывающих процесс передачии информации от оценки проекта до его сдачи (ISO 19650-2) и последующее использование информации об активах на этапе эксплуатации (ISO 19650-3), которая была опубликована несколько лет спустя.

В ISO 19650-1 было введено понятие «уровень потребности в информации» (level of information need), которое представляет собой «структуру, определяющую объем и степень детализации информации». Отмечается, что одной из его целей является предотвратить выдачу слишком большого количества информации.

В рамках ISO 19650-2 уровень потребности в информации связан с так называемым «информационным контейнером» — носителем пакетов информации, которые должны быть предоставлены. В большинстве случаев такими информационными контейнерами являются наши цифровые документы (3D-модели, 2D-чертежи CAD, графики…), которые необходимо предоставлять на различных вехах проекта. Частью плана реализации BIM (BIM Execution Plan, BEP) является требование разработать так называемый Основной план поставки информации (Master Information Delivery Plan, MIDP), который объединяет все различные графики предоставления информации от разных целевых групп.

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

Дальнейшая стандартизация концепции была проведена в CEN/TC 442, в Европейском комитете по стандартизации, рабочей группой под руководством Болпаньи, в результате чего был опубликован EN 17412-1:2020. Две дополнительные части серии находятся в стадии подготовки. Благодаря тесному сотрудничеству с комитетом ISO/TC 59/SC 13 было достигнуто соглашение о доведении этого стандарта до уровня ISO, поскольку он считается глобально актуальным для стандартизации. В настоящее время процесс продолжается, и в случае утверждения он будет опубликован как серия стандартов ISO 7817.

Концепции и принципы

Вместо того чтобы встраивать цели и вехи в определения, схема уровня потребности в информации устанавливает их в качестве предпосылок: что должно быть известно, прежде чем вы сможете сформулировать фактические требования? И это подход, сфокусированный на цели: вам нужно указать, зачем вам нужна информация (= цель), кем и для кого (= действующее лицо) и когда она требуется (= веха). И наконец, чтобы идентифицировать объект, вы должны определить его в некоторой специальной системе кодировки или классификации, такой как OmniClass или Uniclass.

Важно, чтобы предпосылки понимались как исходные данные, а не как часть определения. Геометрии «на уровне производства» не существует, но когда производство определяется как цель, будет выбрана подходящая геометрическая информация. Это довольно тонкий нюанс, но он обеспечивает более выразительный способ формулирования требований. Без указания цели или вехи нет смысла определять требование. Точно так же «уровень» не определяет фазу, но когда указывается фаза или веха, можно указать подходящий уровень.

Определение уровня потребности в информации

Чтобы указать уровень потребности в информации, мы различаем геометрическую информацию, буквенно-цифровую информацию и документацию. В контексте этой статьи мы в основном рассматриваем первые два вида, так как для них существует близкий эквивалент в LOD.

Как выразить требования к геометрической информации?

Здесь выделяются пять аспектов: детализация, размерность, местоположение, внешний вид и параметрическое поведение. Детализация относится к сложности представления объекта. Размерность может быть 3D, но также могут быть указаны 0D (точка), 1D (линия) и 2D (поверхность). Что касается местоположения, мы различаем абсолютное, или глобальное, и относительное — относительно другой точки отсчета. Внешний вид связан с визуальными и поверхностными качествами, независимыми от деталей, и наконец, параметрическое поведение может быть или не быть требованием, что влияет на тип геометрии и, возможно, формат файла, который будет использоваться для предоставления геометрической информации. В этой статье мы сосредоточимся на детализации, поскольку она наиболее тесно связана с LOD.

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

• Вам нужна простая геометрия-заполнитель?
• Достаточно ли внешней оболочки объекта или необходимо также включать внутренние компоненты и отверстия?
• Требуются ли подключения к другим объектам (как в случае с LOD 350)?
• Требуются ли более мелкие элементы, такие как фаски или скосы?

Если вернуться к примеру со стальной колонной, то его можно сформулировать следующим образом:

• Во время предварительного проектирования инженеру-строителю требуется только ввести аналитическую модель конструкции в программу расчета. Достаточно размерности 1D (оси колонны), позиционирующейся относительно уровня этажа. Нет требований к внешнему виду или параметрическому поведению. Детализация упрощена и на самом деле является лишь заполнителем, поскольку профиль будет определен позже во время анализа.
• На финальной стадии проектирования архитектор запрашивает у инженера-строителя более подробную геометрию стальной колонны после выполнения структурных расчетов. Целью на этом этапе является координация и документация. Для этого требуется внешняя оболочка элемента в 3D, расположенная относительно этажа здания и других элементов поблизости. Внешний вид балки должен отражать материал (сталь), но параметрическое поведение не требуется. Детали стальной колонны должны включать фактический профиль (в идеале из каталога) и возможные вырезы на торцах колонны.
• Для фазы строительства у подрядчика есть еще дополнительные требования, такие как соединительная пластина и болты, а также любые возможные отверстия или проемы, появившиеся в результате согласования конструкции и МЕР.

Хотя этот пример может быть описан с применением более ранней концепции LOD, здесь у нас появляется больше возможностей для спецификации геометрии.

Выражение требований к буквенно-цифровой информации

В то время как формулировка требований к геометрической информации все еще уточняется, требования к буквенно-цифровой информации уже практически устоялись, главным образом благодаря работе на уровне ISO/CEN.

Понятие требуемых «уровней» было заменено перечислением требуемых свойств на конкретной вехе. Во многих проектах владельцы и другие получатели информации используют электронные таблицы для перечисления всех необходимых свойств, которые затем используются для настройки соответствующих полей данных в моделях. Все современное программное обеспечение BIM умеет добавлять к объектам пользовательские свойства или записи.

Машинно-интерпретируемый или человекочитаемый?

Несмотря на то что многие проекты используют данные из электронных таблиц для выражения требований к информации, они считаются удобочитаемыми только для человека. Если вы хотите автоматизировать и проверять требования к информации, вам нужно преобразовать требования в серию правил проверки моделей для специального программного обеспечения (например Solibri или BIMcollab ZOOM). Продолжается работа над Частью 3 серии стандартов EN 17412/ISO 7817, направленной на утверждение формата обмена, интерпретируемого компьютером, который позволит использовать спецификацию уровня потребности в информации для автоматической проверки предоставленной информации.

В этом контексте мы также хотим явно упомянуть buildingSMART. Это глобальная организация по стандартизации информации о строительстве, и разработанный ими формат IFC поддерживается в каждом программном обеспечении для BIM. Несмотря на то что этап преобразования данных все еще нужен, экспорт информации о модели из вашего ПО в IFC реализован везде.

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

После публикации стандарта EN 17412 компания buildingSMART запустила проект стандартизированной Спецификации доставки информации (Information Delivery Specification, IDS) [5]. Рабочая группа опубликовала первые версии спецификации и в настоящее время работает с поставщиками программного обеспечения, чтобы проверить реализацию перед передачей ее пользователям.

В отличие от «уровня потребности в информации», IDS представляет собой формат обмена на основе XML, предназначенный только для выражения требований к буквенно-цифровой информации: Какие свойства необходимы в модели? Сознательно было принято решение не рассматривать геометрическую информацию. Кроме того, IDS предполагает, что используется схема IFC, поскольку фильтры и критерии выражаются с использованием объектов (классов) и свойств IFC.

Этот подход не заменяет «уровень потребности в информации», но может рассматриваться как дополнительная спецификация. После формулировки ваших информационных требований буквенно-цифровая часть может использоваться для их определения в машинно-интерпретируемом виде, что позволит автоматически проверять модели IFC на соответствие требованиям: Содержит ли ваш IFC-файл требуемые свойства, указанные в IDS?

Заключение

В этой статье мы представили обзор нескольких связанных друг с другом концепций, применяющихся для выражения детализированной, геометрической и буквенно-цифровой информации в проектах, где применяется BIM, и привели несколько способов, которые современное программное обеспечение использует для управления такой информацией в моделях. Мы также упомянули действующие международные стандарты, в которых эти концепции были переработаны и переопределены как «уровень потребности в информации», и рассказали о некоторых работах, ведущихся в комитетах по стандартизации и buildingSMART.

Предупреждение: автор участвует в работе комитета по стандартизации, разрабатывающего серию EN 17412 и будущие стандарты ISO 7817 для уровня потребности в информации.

Ссылки

1. https://www.bimthinkspace.com/2016/07/the-many-faces-of-lod.html
2. https://bimforum.org/lod
3. https://www.plannerly.com
4. https://www.bimq.de/en/
5. https://github.com/buildingSMART/IDS

Автор: Стефан Бойкенс
Источник: http://isicad.ru/

Понравилась статья? Тогда поддержите нас, поделитесь с друзьями и заглядывайте по рекламным ссылкам!