Как многие из вас знают, главной нашей целью является перевод человекопонимаемых требований в машиноинтерпритируемый вид, из которого можно будет создать машинопонимаемое (правильнее даже машиноприменяемое) правило. Проще говоря, мы хотим сделать переводчик с русского языка на язык, понятный машине.
С машиноинтерпретируемым видом мы более-менее научились справляться с помощью уникальной разметки текста, основанной на не менее уникальной методике. Из нашей разметки можно понять: с помощью каких фильтров будут отобраны объекты проверки; как эти объекты относятся друг к другу по местоположению.
В работе – автоматизация анализа структурных связей, но речь сейчас не об этом, а о создании машинопонимаемого формата. Главный вопрос, который сейчас остается нерешенным - как должен выглядеть этот самый универсальный xml, какой синтаксис надо использовать? А может это и не xml должен быть, а скажем, json? Программ, обладающих функционалом для проверки ЦИМ – много, и «машинопонимаемость» у всех своя. Единый стандарт «универсального xml» должен быть спущен «сверху» и стать общепринятой нормой. Мы же таких полномочий не имеем, а показывать работающее решение хочется уже сейчас. Поэтому, мы занимаемся созданием «кадлибопонимаемого» формата для конкретного ПО CADLib Модель и Архив (СиСофт Девелопмент). В данном решении уже есть инструмент проверки на коллизии, в котором можно создавать свои правила, сочетающие анализ информационных свойств и местоположения объектов.
Фильтры для отбора объектов переводятся в «кадлибопонимаемый» вид довольно легко. А вот для воспроизведения условий, относящихся к местоположению, приходится фантазировать, выбирая оптимальный вариант из стандартного набора.
А теперь давайте поговорим о типах проверки и как мы их используем.
1️⃣ Условие. Самый базовый тип проверки значения атрибута объекта. Где здесь взаимодействие объектов, спросите Вы? В данную проверку можно добавить несколько объектов и сценарий будет выполняться при условии их наличия. А еще, допустимые значения одного объекта можно рассчитывать из характеристик другого объекта. Но местоположение тут действительно не учитывается.
2️⃣ Минимальное расстояние, минимальное расстояние в плане и минимальное расстояние по вертикали. Обычно данный тип проверок используется просто через ввод числа того самого значения минимального расстояния, которое надо проверить. Мы же не ищем легких путей и строим формулы с IF, которые на русском звучат примерно следующим образом: если в границах (на расстоянии) от объекта1 есть объект2, у которого атрибут1 имеет значение> допустимого – то ошибка.
Возможностей для усложнения – море. Но в итоге, можно получить сценарий для проверки расстояния воздуховода, исключающие детали, относящиеся к одной осевой.
3️⃣ Пересечение. Данный тип проверки предсказуемо выдает ошибку при пересечении двух объектов. Мы и его используем тоже с условием IF для воспроизведения требований вида «Выходные двери из помещения котельной должны открываться наружу». Должно Проверяться направление открывания двери, а также ее отношение к помещению котельной. if([object2.NSR_DOORS_OPENING] ="Внутрь",false,0) – через такую формулу проверяем все двери на направление открывания, если оно равно «внутрь», то сразу выдается ошибка, а если не равно «Внутрь», то проверяется пересечение с помещением Котельной. Таким образом, получается проверить два необходимых условия.
4️⃣ Наличие соседних объектов. Только данный тип проверки выдает коллизию, если на заданном расстоянии от первого объекта нет второго объекта (все остальные не найдут объекты и скажут, что коллизии нет). Отлично помогает, если необходимо поискать в определенных помещениях наличие вентиляции или системы пожаротушения.
Приятный бонус: сочетание проверок минимальное расстояние + наличие соседних объектов позволяют проверять требование с диапазоном допустимого расстояния.
С машиноинтерпретируемым видом мы более-менее научились справляться с помощью уникальной разметки текста, основанной на не менее уникальной методике. Из нашей разметки можно понять: с помощью каких фильтров будут отобраны объекты проверки; как эти объекты относятся друг к другу по местоположению.
В работе – автоматизация анализа структурных связей, но речь сейчас не об этом, а о создании машинопонимаемого формата. Главный вопрос, который сейчас остается нерешенным - как должен выглядеть этот самый универсальный xml, какой синтаксис надо использовать? А может это и не xml должен быть, а скажем, json? Программ, обладающих функционалом для проверки ЦИМ – много, и «машинопонимаемость» у всех своя. Единый стандарт «универсального xml» должен быть спущен «сверху» и стать общепринятой нормой. Мы же таких полномочий не имеем, а показывать работающее решение хочется уже сейчас. Поэтому, мы занимаемся созданием «кадлибопонимаемого» формата для конкретного ПО CADLib Модель и Архив (СиСофт Девелопмент). В данном решении уже есть инструмент проверки на коллизии, в котором можно создавать свои правила, сочетающие анализ информационных свойств и местоположения объектов.
Фильтры для отбора объектов переводятся в «кадлибопонимаемый» вид довольно легко. А вот для воспроизведения условий, относящихся к местоположению, приходится фантазировать, выбирая оптимальный вариант из стандартного набора.
А теперь давайте поговорим о типах проверки и как мы их используем.
1️⃣ Условие. Самый базовый тип проверки значения атрибута объекта. Где здесь взаимодействие объектов, спросите Вы? В данную проверку можно добавить несколько объектов и сценарий будет выполняться при условии их наличия. А еще, допустимые значения одного объекта можно рассчитывать из характеристик другого объекта. Но местоположение тут действительно не учитывается.
2️⃣ Минимальное расстояние, минимальное расстояние в плане и минимальное расстояние по вертикали. Обычно данный тип проверок используется просто через ввод числа того самого значения минимального расстояния, которое надо проверить. Мы же не ищем легких путей и строим формулы с IF, которые на русском звучат примерно следующим образом: если в границах (на расстоянии) от объекта1 есть объект2, у которого атрибут1 имеет значение> допустимого – то ошибка.
Возможностей для усложнения – море. Но в итоге, можно получить сценарий для проверки расстояния воздуховода, исключающие детали, относящиеся к одной осевой.
3️⃣ Пересечение. Данный тип проверки предсказуемо выдает ошибку при пересечении двух объектов. Мы и его используем тоже с условием IF для воспроизведения требований вида «Выходные двери из помещения котельной должны открываться наружу». Должно Проверяться направление открывания двери, а также ее отношение к помещению котельной. if([object2.NSR_DOORS_OPENING] ="Внутрь",false,0) – через такую формулу проверяем все двери на направление открывания, если оно равно «внутрь», то сразу выдается ошибка, а если не равно «Внутрь», то проверяется пересечение с помещением Котельной. Таким образом, получается проверить два необходимых условия.
4️⃣ Наличие соседних объектов. Только данный тип проверки выдает коллизию, если на заданном расстоянии от первого объекта нет второго объекта (все остальные не найдут объекты и скажут, что коллизии нет). Отлично помогает, если необходимо поискать в определенных помещениях наличие вентиляции или системы пожаротушения.
Приятный бонус: сочетание проверок минимальное расстояние + наличие соседних объектов позволяют проверять требование с диапазоном допустимого расстояния.