История науки и техники

"Stay vertical" (Herb Voelcker).

В этому году мне выпала честь отрецензировать одну из рукописей в главном САПРовском журнале Computer-Aided Design. Увы, соглашение о неразглашении запрещает раскрывать содержание публикации и, тем более, детали самого процесса рецензирования. Скажу лишь, что процесс вполне нагляден, и рецензент не имеет никаких проблем с тем, чтобы, выделив время, комфортно сделать свою часть работы.

Планируемый к выпуску номер CAD посвящен памяти Герберта Велкера, чье имя уже упоминалось на страницах сего уютного бложика в далеком 2015-м году в связи с описанием булевых операций. Напомню, что Рекувич и Велкер, как наиболее яркие фигуранты «рочестерской школы» геометрического моделирования, удостоились премии им. Безье за работу над PAP (Production Automation Project) в 70-е и 80-е годы. Профессор Велкер умер в возрасте 90 лет, и всякому, интересующемуся историей CAD, можно рекомендовать ознакомиться с его биографией и библиографией. Не буду, впрочем, распинаться здесь по поводу вклада человека, которого я не имел возможности знать лично. Остается с нетерпением ждать специального выпуска журнала, из которого, уверен, можно почерпнуть множество интересных сведений о работе рочестерской школы в общем и Велкера в частности. Время продуктивной работы этих школ приходится на становление автоматизации проектирования как дисциплины. Можно говорить о различных коллективах, преследовавших более-менее одинаковую цель — компьютеризацию процесса производства. Их было много, этих коллективов. Некоторые не стесняются говорить даже о том, что-де именно они «изобрели» CAD/CAM, хотя это, разумеется, не так. Не знаю почему, но именно рочестерская школа мне как-то ближе. Звучит, конечно, абсурдно, но даже статьи именно этого коллектива как-то меньше корёжат мозг деланым наукообразием: все строго, но по существу. И, конечно, возникновение новой дисциплины не обошлось без философского бэкинга, исходящего, впрочем, из самой необходимости познакомить компьютер с интуитивно воспринимаемой любым человеческим существом геометрией формы.

Так, Велкер, рассуждая о роли геометрии в САПР [Shapiro, V., & Voelcker, H. (1989). On the role of geometry in mechanical design. Research in Engineering Design, 1(1), 69–73], использует метафору «энергетических портов», за которой наш брат немедленно заподозрит старый добрый фичер (feature, конструктивный элемент). Так уж вышло, что работа нашего коллектива тесно связана с распознаванием всяких фичеров на твердотельной геометрии, а потому данная статья кажется знаковой. В своей статье Велкер отмечает подчиненную роль геометрии по отношению к функции детали. Намерение установить отношение между формой и функцией становится поводом не только для оригинальной статьи из Рочестера, но и последующих работ других коллективов, в том числе из Англии (подробнее ниже).

Брусок и его «наряды» (см. статью McKay et al).

Попытка сопрячь геометрическую форму и функцию детали неминуемо приведет к понятию фичера и, что естественно, к вопросам синтеза и анализа модели. Анализ модели — это и есть распознавание конструктивных элементов, тогда как синтез — проектирование в терминах фичеров, исходя из некоторой спецификации. Если деталь уже создана как геометрическое представление, то распознавание ее конструктивных элементов должно привести к более глубокому пониманию назначения и, если угодно, «онтологии» детали. В процессе этого анализа мы можем по-разному трактовать определенный набор конструктивных элементов. Например, если мы исследуем саму возможность изготовить данную деталь, то нас может интересовать глубина пазов и диаметр фрезы. Если же мы изучаем прочность детали, то вместо пазов мы станем исследовать толщину стенок. Таким образом, существует пересекающийся набор всевозможных семантик, связываемых нами с геометрией формы. В зависимости от контекста, мы «переодеваем кирпич» (см. фотографию выше) в тот или иной наряд.

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

Брусок и решетка его граней в виде диаграммы Хассе.

В английской статье [McKay et al, 2019] предлагается использовать решетку (lattice) для «нанесения» на модель семантики, правда, там речь идет о сборках. Те же авторы предложат использовать решетки для фичеров (как раз в специальном выпуске CAD). При этом все многообразие «семантических покрытий» модели может быть визуализировано диаграммой Хассе (см. иллюстрацию выше).

Нельзя сказать, что идея построения решёток выглядит как-то свежо и перспективно. Признаться, первое впечатление от самого подхода у меня сложилось скорее настороженно негативное, поскольку, как и любой другой формализм, этот не избавлен от главной проблемы любого формализма — отсутствия внятных инструкций, а как вообще это все реализовывать. Ведь предлагается не просто новый инструмент, а новая, страшно сказать, парадигма, где вместо этих ваших MBD и STEP 242 на сцену выводится все многообразие представлений формы для данной детали со всей ее семантикой. В виде ужасающе сложного графа, между прочим, так что и элегантностью подход не блещет. С другой стороны, здесь явно что-то есть. Давайте разбираться.

А дело собственно вот в чем. Начиная с 2016 года, наш коллектив так или иначе работал с задачами распознавания фичеров, а в таких задачах следует начать с определения, что такое вообще этот самый фичер есть. Самое простое — определить конструктивный элемент как множество граней, а точнее, индексов граней модели. Далее строится сто-пятьсот алгоритмов распознавания фичеров, которые на выходе отдают те самые индексы граней, тип конструктивного элемента (отверстие, паз, скругление, фаска и т.п.) и какие-то его свойства, например, диаметр сверла. Все работает прекрасно, почти как оркестр, но ровно до тех пор, пока не возникает неоднозначность. Скажем, одна и та же грань может быть распознана как скругление или как элемент боковой фрезерной обработки. Аналогичным образом, мы можем найти в модели что-то похожее на результат токарной обработки, хотя модель, понятное дело, не может сказать, а есть ли у производителя токарный станок или там только фрезер. В общем, возникает неоднозначность, связанная с тем, как атрибутировать конкретную грань. Даже в случае, если тип грани строго детерминирован, могут возникнуть трудности с однозначным определением способа изготовления: боком фрезы или основанием? Впрочем, фотография с переодетым кирпичом еще нагляднее: одни и те же грани могут входить в различные подмножества (ribs, pockets) в зависимости от того, что мы исследуем в модели.

Универсальной архитектуры ПО, отвечающей на все названные вопросы, понятное дело, нет. Здесь возникает куча разнообразной специфики, не имеющей к геометрии вообще никакого отношения, например, а есть ли в производстве нужного типа фреза, чтобы обработать тот или иной фичер. Попытки как-то формализовать суровую многофакторную реальность проектных решений имеют все шансы стать бесплодными умствованиями. Но начинать с чего-то надо, и формализация понятия «фичер» на уровнях Модель-Алгоритм-Программа требует работы мысли, выходящей за рамки одноклеточного программисткого труда.

Да, кстати, спешу похвастаться. Теперь я не просто так. Мне дали вот такой сертификат:

"Recognised Reviewer Certificates" — лычка для ценителей.