NSR Specification

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

Я все время говорю, что мы работаем в условиях множественных неизвестных.
У нас есть текстовое требование, с помощью которого надо проверять ЦИМ. Но, мы не знаем:
1⃣ по каким правилам разметить схему требования;
2⃣ как интерпретировать схему, уложив её в этапы проверки;
3⃣ как, в конце концов, должен выглядеть результат, который сможет исполнить стороннее программное обеспечение.
Причем, каждое из этих X зависит друг от друга. Такая вот петрушка.
Сперва хотели плясать от структуры профилей проверки на коллизии CADLib Модель и Архив.
Т.е. взять текст требования, вручную, создать на его основе проверку (благо в CADLib есть вполне себе человеческий интерфейс для этого) и, затем, разработать механизм превращения одного в другое с помощью ИИ и прочей магии.
Но, вот в чем шутка, широкие возможности CADLib, открывают множество вариантов по отработке одной и той же проверки. И, нельзя забывать, что кроме CADLib есть и другие решения, в которых свои правила.
А для того, чтобы создать Большую Красную Кнопку для конвертации нужна не другая Большая Красная Кнопка с функцией "Сделай красиво". Нужны алгоритмы, учитывающие все возможные варианты конвертации, зависящие от текста требования и от возможностей ПО для проверки, способные выбрать наиболее эффективные и, главное, более-менее универсальные способы преобразования. Я не говорю "Невозможно ", я говорю "Может есть путь проще"?
Так что, снова возвратились к истокам и стали рассуждать, из каких звеньев будет состоять проверка. И это были:
✅ Выбор объектов в проверку по информационным свойствам.
Тут, внимание, многие программы позволяют даже использовать расчётные значения при выборе. Можно учитывать структурные связи, подчинённость объектов. Но нельзя брать в расчёт расстояния между объектами. Это можно сделать в другом звене:
✅ Условие проверки.
Тут мы уже оперируем исключительно тем, что выбрали на предыдущем этапе. Но можно принять решение на основании проверки информационных значений атрибутов объектов и их положения относительно друг друга. Есть даже программы, которые умеют делать измерения габаритов.
Из всего вышесказанного можно сделать вывод о том, какие типы операций нам надо разглядеть в тексте:
✅ пара "атрибут+значение" для выбора объектов;
✅ информацию о положении объектов для этапа проверки;
✅ пара "атрибут+значение", для принятия решения о нарушении.

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

И это конечно все хорошо, но как же хочется спокойно поработать)

Однажды наступает момент, когда уже невозможно противиться современным тенденциям. У всех уважаемых IT-направлений есть ТГ-каналы) А мы, вроде бы и делаем потрясающие вещи, но, как-то скромно, шепотом.
В общем, хочу попробовать пошуметь тут. Рассказывать буду все подряд:
1⃣ О текущей работе
2⃣ О проблемах
3⃣ О маленьких и больших победах
Ну, и немного буду хвастаться проведенными мероприятиями.

Меня зовут Кутузова Ольга, я продакт-менеджер направления NSR Specification, компания Нанософт разработка. Целыми днями наша команда ломает голову, как автоматизировать прочтение нормативного документа машиной, чтобы результаты можно было использовать для поиска нарушений в Цифровой Информационной Модели (ЦИМ). Ну и для создания в САПР умных, интеллектуальных инструментов, которые будут знать положения нормативных документов. Да что там, днями, нас и по ночам не отпускает работа😊

В общем, добро пожаловать!