САПР и контент: задача понимания себя
АрхивЗнание, образ, информация... Мы привычно обобщаем эти понятия, хотя сущности, ими обозначаемые, принципиально зависят от предметной области - они определяются относительно нее и вне ее не существуют: нет информации "вообще", нет "знания вообще". А вот "логическую геометрию" знания, процессуальную динамику его создания и эволюции можно, в принципе, представить самостоятельными сущностями, достаточно инвариантными относительно породившей их среды. И заниматься ими будет не информатика, а, скорее, "знаниеведение", "образологика" или "технология понимания"...
Человечество накопило столько конкретной информации, что дальнейшее ее производство становится бессмысленным: она остается невостребованной даже в рамках родной предметной области. Категорический императив сегодняшнего дня в области техники и технологии звучит так: или создание саморазвивающихся технических "биот", или совершенствование форм, методов и технологий работы с информацией: переход от анализа к синтезу и образному ее обобщению.
Второй путь дает человечеству шанс избежать интеллектуальной деградации. Поэтому задача, поставленная перед людьми на рубеже веков, - это задача понимания себя. Но с чего начать? Как подступиться к этой проблеме?
В технике до сих пор не существует языка, адекватного сложности решаемых задач. Трудно сказать, что такое "технический образ". Язык современной техники берет начало не от технического образа (суммы идей, как например в математике), а от технологического цикла проектирования и производства изделия, от конкретного воплощения идеи. А собственно идея изделия размазана по многим документам и представлена во многих формах, преимущественно - литературных, и образ технического объекта оживает только в воображении человека, прочитавшего нужные материалы.
Тем не менее, процесс создания адекватного языка для работы с техническими образами неуклонно развивается.
Первой итерацией было, по-видимому, внедрение 2D-САПР, когда стали возможны логические операции с "точным контуром" как таковым, без обязательного стопроцентного образмеривания: адекватным техническим образом в некоторых случаях оказывался сам контур. Вторая итерация - это работа с реалистичными геометрическими формами объектов в 3D-САПР. Третьей будет, по всей видимости, работа с техническими образами, объединяющими геометрическую форму, проектную логику (в том числе и эвристический ее компонент) со средой контента предметной области. В дальнейшем эти локальные среды сольются в единую среду и...
Но начинать решение названных проблем нужно было "еще вчера". Первым этапом в этой работе должна быть "работа Карла Линнея" - осмысление, классификация и систематизация. Необходимо понять, каковы де-факто механизмы обработки людьми технических образов, и как они эволюционируют в процессе внедрения новых технологий и САПР. Необходимо фиксировать, накапливать эту информацию о движении информации. А уже на этой базе - делать выводы и строить теории.
...Тема выделения и накопления контента близка мне в силу многолетнего практического "прикладного контент-анализа", сопутствующего проектированию. В процессе внедрения новой техники и "тяжелых" САПР мы подошли к этому мероприятию системно: пытались обеспечить "заведение" в машину не только моделей агрегатов или узлов, но и проектной логики.
Задача возникла совершенно естественно: нас поразил тот факт, что несмотря на десятки шкафов (!) бумажной документации, описаний, пояснительных записок, для того чтобы ответить на простенький вопрос (почему тут диаметр 10, а не 15?) - непременно бегут куда-то и вызывают пенсионера дядю Ваню, который сошлется на прецедент, случившийся в 19... далеком году. Оказалось (и это далеко не очевидно даже для имеющих отношение к технике людей), что в технической документации содержится только информация о "мгновенном" состоянии изделия и всех его параметров. Но это все равно, что описывать поток воды, бьющей из сопла, точным указанием координат всех молекул на какой-то момент времени - много ли это дает для понимания сути процесса?
Беда усугубляется еще и тем, что производство и техническое проектирование вынуждены ориентироваться на стандарты и ГОСТы. Стандартная документация крайне консервативна и практически не может - в ее нынешнем виде - эволюционировать.
Итак, огромные описания, обоснования, отчеты - это опять-таки не то, не знание. В лучшем случае, бледная его тень. За рубежом это поняли и активно внедряют так называемые CALS-технологии (система информационной поддержки "жизни" любых изделий на основе открытых международных стандартов). С 1985 года суть концепции CALS неоднократно расширялась. Но CALS - это не контент, назначение у нее несколько другое.
Базы знаний тоже создаются, и весьма успешно. В эти работы вкладываются огромные средства, но пока никому не ясно, в какой же форме эти знания, этот контент хранить. Пока себя оправдала лишь одна форма - древнейшая, литературная. В "их" фирмах старейшим специалистам регулярно выдаются соответствующие вопросники, а ответы фиксируются и систематизируются.
Мы в своей работе сконцентрировались на анализе конструкции и компоновки высокой сложности. В этой области не существовало ничего подобного, например, записанному цепочкой формул алгоритму для теплогидравлических расчетов. А отсутствие протоколирования "годографа" проекта в пространстве возможных вариантов приводит к тому, что даже пресловутый дядя Ваня пенсионер уже начинает путаться в компоновке.
К примеру, группа арматуры на стенке защитной оболочки предельно компактирована, чтобы освободить место для группы трубопроводов. По арматуре изменена геометрия смежных систем (чтобы не было интерференции). А потом вдруг (спустя год, когда каскад таких изменений разросся и запутался многократной рекурсией) группа трубопроводов переносится на другую стенку. Но вряд ли кто помнит, что она-то и была причиной, отправной точкой всей логики данной компоновки! Налицо появление "артефакта" в ходе проектирования.
Но артефакт может появиться и в силу чисто человеческих причин (примерно половина всех случаев по моему опыту!). Проектируют люди. Они живые, устают иногда. И когда (за неделю до сдачи проекта) схемщики выдают очередное требование, согласно которому нужно принципиально менять компоновку... нет, не будет ее никто менять! В этом случае схема идет сама по себе, чертеж - сам по себе (а потом, Бог даст, его корректируют - отзывают и заменяют).
Что уж говорить о тех случаях, когда проектировщик системы, понимающий в ней больше всех остальных вместе взятых, может, не советуясь ни с кем, заложить пару-тройку таких вот артефактов от себя лично.
А если в этот момент (особенно по второму и третьему сценариям появления артефакта) с проектировщиком, не дай Бог, что случится (а ведь, как мы уже упоминали, дядя Ваня-то пенсионер!), то этот документ ("инвентарный номер" - понятие в любом "ящике" священное) становится этакой вещью в себе, единым и неделимым монолитом в фундаменте строимого над ним проекта.
Помочь могла бы модель. Но математика тут сложная, да и как прикажете параметризовать такие характеристики, как "удобство обслуживания" или "технологичность"? Кроме того, раз формализовав задачу, нужно замыкать на нее весь трафик проектных транзакций, иначе актуальность имеющейся формальной модели (то есть геометрическая модель + логическая модель) падает катастрофически, и через неделю придется начинать все сначала. Но даже проделав эту неимоверную работу по математической формализации, вы мало что получите в итоге, ибо проектирование идет от образа к модели, а не наоборот.
Основные усилия исследователей в области ИИ направлены сейчас на реализацию "образного мышления" или хотя бы просто работы с образами, а не с параметрическими моделями. Последнее весьма объяснимо на бытовом уровне: человек стремится преобразовать большое, но слабо связанное множество в маленькое, но сильно связанное, к работе с которым оптимально приспособлен наш мозг. Нам важнее знать "почему", видеть образ (а он содержит в описательном виде всю динамику), логику, чем иметь гигантский набор описывающих параметров, которые затем нужно еще и интерпретировать.
Единственным светом в окошке (то есть подходом, применимым в нашей технической области) здесь является использование набора метафор из области 3D-САПР. Когда вращаешь на экране "силикона", разглядывая на просвет, хрустальный кубик компоновки реакторной установки (РУ), переплетающийся сотнями трубопроводов, конструкций, агрегатов, элементов, то меньше всего думаешь о цифрах, размерах и параметрах - просто красоту ищешь, пропорциональность, симметрию, логику. И любой ляп или артефакт при таком рассмотрении черным пятном бросается в глаза - не заметить невозможно!
Итак, задача контент-анализа, накопления и фиксации знания ("почему это так, а не вот так") макетно решалась на базе концептуального аппарата 3D-САПР с использованием его метафор. Вначале была разработана специальная система обозначений (позиционная, содержащая в имени набор полей, описывающих структурную принадлежность данного элемента, его "личный жизненный этап", а также "воплощение" - он может одновременно являться и записью БД, и файлом обмена, и ссылкой).
Затем на базе введенной (и реализованной на обширном объеме проектного архива - целый проект РУ, до уровня болтов и прокладок) Единственным светом в окошке (то есть подходом, применимым в нашей технической области) здесь является использование набора метафор из области 3D-САПР. Когда вращаешь на экране "силикона", разглядывая на просвет, хрустальный кубик компоновки реакторной установки (РУ), переплетающийся сотнями трубопроводов, конструкций, агрегатов, элементов, то меньше всего думаешь о цифрах, размерах и параметрах - просто красоту ищешь, пропорциональность, симметрию, логику. И любой ляп или артефакт при таком рассмотрении черным пятном бросается в глаза - не заметить невозможно!
Итак, задача контент-анализа, накопления и фиксации знания ("почему это так, а не вот так") макетно решалась на базе концептуального аппарата 3D-САПР с использованием его метафор. Вначале была разработана специальная система обозначений (позиционная, содержащая в имени набор полей, описывающих структурную принадлежность данного элемента, его "личный жизненный этап", а также "воплощение" - он может одновременно являться и записью БД, и файлом обмена, и ссылкой).
Затем на базе введенной (и реализованной на обширном объеме проектного архива - целый проект РУ, до уровня болтов и прокладок) системы обозначений был разработан формальный язык описания проектных транзакций. Получилось на удивление красиво - мы обрели возможность без единого слова, формально-символьно описывать очень многие операции над образами, не используя ни единого параметра (в традиционной трактовке этого термина): все методы в лучших объектных традициях были инкапсулированы внутри этих образов-моделей, обеспечиваясь ядром САПР, структурой БД проекта и введенными обозначениями, которые прошивали сквозным образом все уровни проекта от болта до общих компоновок.
Далее началось собственно накопление контента. Протоколы транзакций трехлетней работы можно читать, как "17 мгновений весны". Можно и задать машине вопрос "а почему тут так, а не вот так?" или "а откуда это вот взялось и чем обусловлено?" - простое прослеживание трека объекта в протоколе дает ответ. Может, конечно, найтись злоумышленник, пожелавший уничтожить следы какого-то проектного трека. Но тогда вся логическая система (а она ведь жестко сцеплена) распадется, что будет обнаружено при первом же просмотре или поиске.
Вот простой пример записи транзакции:
( Cut/sect XOZ+Y [ _1YBZ1_12] ) (r)
( S1YSBT__12 ( ! ) + (C1_SBT___2)
Обозначения (поля позиционного кода) зависят от базиса, в котором данный элемент реализован. Базис фиксируется для каждого элемента (объема, зоны... ) исходя из степеней свободы проектной вариантности - нет смысла предусматривать изменения, которые никогда не будут востребованы: реактор никогда на потолок защитной оболочки не поставят. Набор базисов хранится в специальном глоссарии.
Словесное описание приведенного примера займет не менее нескольких страниц текста (с учетом ссылок на все затронутые в транзакции разделы и меняемые связи). В нашей транскрипции эти сущности привлекаются за счет среды контента. Эта запись читается много легче, чем листинг на Си. И наша следующая задача - применить машинный анализ для выявления проектной логики и построения логических и процессуальных моделей.
Эта проблематика резонирует с содержанием темы номера "Задача понимания" ("КТ", #305-306): возможность представить наши "логические и процессуальные деревья" примерно в такой форме, как там были представлены политические тексты, позволила бы извлечь "логический трек" из протоколов проектных транзакций. И слова автора о возможности выделения логики процесса из контекста и ее дальнейшего тиражирования (в той или иной ситуации выбора) не оставили нас равнодушными. В технике это уже пытались делать (вспомните хотя бы АРИЗ - развивавшуюся Альтшуллером с соавторами методику решения творческих задач). Но автор проиллюстрировал принципиально иной подход: не навязывать жизни искусственные схемы, а изучать реальность, классифицируя и сознательно применяя это знание всякий раз в новом контексте.
|
Можно пойти по этому пути и дальше, создав некий процессор логического выбора. В достаточно узкой постановке (отслеживание, фиксация и интерпретация логики эволюции проектных решений) эта задача технически реализуемая. Пока нами реализовано декодирование (интерпретация) текста протокола, написанного "вручную" в процессе работы на САПР. Автоматическая запись протокола в процессе работы тоже (теоретически) не является проблемой - нужна лишь лицензия от производителя САПР и соответствующий SDK, чтобы встроить набор функций. Но реализовать подобную базу образов, в перспективе сцепленную с накопленным контентом, можно только на базе "тяжелых" 3D-САПР (типа EUCLID) или систем виртуальной реальности.
Я далек от идеи предлагать в качестве суперхайвея для всех нашу любительскую зарисовку, сделанную под потребности конкретного большого проекта. Суть в том, что мы, отказавшись от формализации путем параметризации, сумели реализовать преимущества формальной работы с образами и создали логическую модель установки в реальном проекте.
Что же дальше? Как, на какой базе развивать работы по накоплению знания, созданию хранилищ опыта? Какими средствами создавать логические модели конструкций? Как представлять и обрабатывать технические образы, способные играть роль знания? Какие технологии нужны для этого? Какие современные работы и проекты можно принять в качестве эмбрионов будущих технологий, какой задел развивать? И наконец, что же такое технический образ и эвристическая стратегия в среде контента и вне его? Ответы на эти вопросы на рубеже веков придется искать всем, кто имеет отношение к созданию современной техники.
Автор благодарит сотрудников ОКБМ А. В. Васяева и М. К. Владимирского, предоставивших рисунки.
Сергей Макаров - инженер-физик, начальник группы САПР ОКБ Машиностроения, Нижний Новгород.