Хроники инженера-разработчика. Глава 3. 5

Фото из интернета

Глава с абстракциями и научным флёром, а потому на любителя


1982 г.

"СПРУТ" - ТЕХНОЛОГИЧЕСКИЙ САПР ВТОРОГО ПОКОЛЕНИЯ

ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ СИСТЕМЫ

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

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

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

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

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

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

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

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

Но, даже возможность, теперь понятного нам диалогового режима проектирования, оказалась не последним сюрпризом.

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

Либо с полностью «ручным» проектированием и только одной автоматической печатью технологической документации, аналогично текстовым редакторам, либо, при большом "желании", даже и на 100% полностью автоматической!

Таким образом, благодаря появлению у нас собственного протофрейма, задача «машинного» проектирования технологических операций, из прежней для «пакетного» САПРа, трансформировалась в чисто технический «процесс означивания его слот».

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

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

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

«Смыслы», заложенные в эти фреймы, интерпретировались нами, как цели (чего физически необходимо достичь этим фрагментом) и их топологическими свойствами в «пространстве» технологической операции.
То есть, а как эти части-фрагменты, со расположены друг относительно друга – последовательно, параллельно или параллельно-последовательно.

"Значения" слотов первых двух фреймов определяли автоматически, как обычные идущие по порядку числа, а вот для третьего, самого нижнего из этих фреймов, специально разработали ограниченно-естественный язык диалогового режима автоматизированного проектирования.
Его основу составили известные любому из технологов обычные технические термины, типа слов «Собрать», «Установить», «Сверлить» или «Клепать», которые они должны были выбирать из "выпадающего" меню.

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

Стали искать, и на этот раз, снова нашли нужное нам.

Первыми оказались наши будущие «продукционные» модели» представления «процедурных знаний», о существовании которых узнали из прекрасной монографии «Основы кибернетики» издания 1973 года.
Её автором оказался Лев Тимофеевич Кузин – кибернетик, доктор технических наук, профессор, лауреат Государственной премии СССР, основатель отечественной кибернетической школы Московского инженерно-физического института (МИФИ).

В этой книге нашли описание формализованного подхода для генерации цепочек, известного как «системы продукций» или «подстановок», когда посылки (антеценденты) по определённым правилам заменяются на заключения (консеквенты).
Проще говоря, если имеем «Х», то, при выполнении «условия» и путем замены одного на другое, получим «У» или даже цепочку из «абвгд»дейки.

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

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

Именно таким способом, мы, разработав свою библиотеку «продукций», продолжили означивание слот нашего протофрейма, заменяя по "правилам" ключевые слова в Порядке сборки, на технологические цепочки из строк-переходов.

Второй находкой стали «таблицы соответствия», как и в первом случае, ставшими нам известными из книги - «Автоматизированные системы технологической подготовки производства в машиностроении» под ред. Г.К. Горанского, Москва, Машиностроение, 1976 года.

Их автор, Георгий Константинович Горанский - член-корреспондент Академии наук Беларуси, профессор, академик Международной академии наук информации, информационных процессов и технологий, учёный в области машиноведения, автоматизации, технической кибернетики и информатики.

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

Формально, именно такой механизм был нужен и нам, потому как для означивания слот фреймов «Способ» выполнения технологических работ и «Ресурсы», подходил по всем статьям.

Оказалось, что подобных «выборов решений» требуется превеликое множество, от средств технологического оснащения и до «назначения» исполнителей сборочных работ.
Да к тому же, эти «решения» можно было «накрыть» лишь одной специальной программой, каждый раз «подсовывая» ей каталоги «решений» с условиями их существования!

Для прояснения ряда вопросов по этим таблицам, механизмов работы которых, мы первоначально для себя до конца не смогли понять, специально съездили в Институт технической кибернетики (ИТКан АН БССР) из города Минска, альма-матери Г.К. Горанского.

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

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

А вопрос опять оказался вовсе и не тривиальным, ведь для «механизмов» в нашем случае требовались не просто информация и данные, а, как это уже было в прошлый раз с «пакетным» САПРом, технологические ЗНАНИЯ.

Причём, воспользоваться нашим же опытом, мы абсолютно не могли, в связи с принципиальным изменением процессов их применения для новых «механизмов» автоматизированного проектирования технологических операций.

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

Явно выраженную в том, что даже малейшие изменения в наших представлениях о «правильных» технологических структурах в этих моделях, не говоря о случаях их кардинального изменения или массового наращивания, однозначно требовали практически полного перепрограммирования, как управляющей программы, так и её отдельных подпрограмм.
Это было бы сродни, как гоняться за солнечным зайчиком, ведь всё равно его не поймаешь!

Именно по этой причине, нам и следовало ещё раз вернуться к решению этой задачи, а технически, наконец-то, – создать полноценную, структурированную под проектные задачи БАЗУ технологических ЗНАНИЙ.

Для нас самих, да и для других разработчиков из нашей отрасли – впервые, ведь тогда и самого этого понятия «Баз Знаний», не то что в широком обиходе, но даже и в публикациях на эту тему ещё не было.

Только-только пошли обсуждения таких новинок, как "Базы данных", что принципиально не одно и тоже.
Исключения составляли академические издания со статьями, в основном зарубежных ученых, касавшихся, как и у М. Минского проблем "Искусственного интеллекта", применительно к созданию первых «Экспертных систем».

Но и эту, принципиально новую задачу, мы тоже смогли решить.

Опять же, чуток теории.
На сегодня существует уже достаточно развитая классификация видов этих самых «знаний», но в 80-х годах, в основном, обсуждались только две их разновидности, как – декларативные или процедурные.

К первым, относили исключительно ту информацию, смыслы которой декларировали «знания» о том, «ЧТО, ЕСТЬ ЧТО», проще говоря, а это «ЧТО» представляет из себя. Часто этот вид, до сих пор, ещё называют знаниями фактографическими, так как отражают «факты», действительно имеющими быть в природе.
С процедурными знаниями ещё проще, это знания о каких-либо «ДЕЙСТВИЯХ», но одновременно и с условиями их возможной реализации.

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

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

Но кроме того, действительно, кое-что, дополнительно нам сделать всё-таки пришлось.
Это были, как мы их называли - «Словари», являвшиеся основным компонентом, созданного одновременно с "Базой", механизма «настройки» всего проектного функционала нашего САПРа и разом переводившего его, как сейчас говорят, в разряд программных «ПЛАТФОРМ».

И уже, в который для нас раз, этого понятия, так же ещё, не существовало.
А потому, позже окончательное название нашей разработки стало, как "СПРУТ - инструментальная система формирования символьных моделей технологических процессов сборки в составе ИСА ТПП".
Каюсь, а вот до "цифровых" моделей, вместо "символьных" мы, так и не доросли!

Но, что интересно, как правило в инженерном поиске, одновременно с появлением новых взглядов и технических решений, осознания уже и новых возможностей, приходит осознание и новых, ранее неведомых проблем.

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

Причём, эта «содержательность», однозначно, без вариантов, должна быть исключительно состоятельной, которую способны обеспечить только специалисты-машиностроители очень высокой квалификации, под стать тем из них, которые уже с опытом разработки отраслевых стандартов (ОСТов).

Но и это ещё не всё.
Для без болезненной «накачки» этих «Баз», необходима ещё и стандартизация структуры и формы представления самих «знаний».

В наше время ничего подобного мы не имели, всё приходилось создавать только самим.
Такой вариант, безусловно, самый не подходящий, потому как «всезнаек» в природе просто не существует, а сама работа в этом случае растягивается на многие годы.

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

Стало известно, что Николай Вежновец из нашего Головного Института, предложил подход, названный им, как БТМ – Базовые Технологические Модули.
Модули, слагающие все, не зависимо от вида производства, технологические процессы, со структурой принципиально подходящей и нам.

Фактически он предлагал ОСТы, но с достаточно скромным и локальным технологическим содержанием, которые, тем не менее были бы чрезвычайно ценными и необходимыми для автоматизации технологического проектирования, для «накачки» именно Баз Знаний.

Этот подход мы взяли за основу, понимая его перспективность, но правда, в структурном плане нам пришлось, и кое-что «причесать».
Не дожидаясь из Москвы известий о начале работ по БТМ, подключили в качестве соисполнителей по ЦТ-917 своих коллег из нашего смежного подразделения.

Их начальник сектора Борис Федорович Чиняков, поддержал наше предложение, работы по БТМ были начаты и у нас.
В течение нескольких лет этими разработками руководила очень квалифицированный, с опытом работы непосредственно на производстве, технолог Валентина Александровна Кузнецова.
Именно эти БТМы, предварительно размещенные в нашей Базы технологических Знаний, и использовались новым САПРом для автоматизированного проектирования сборки самолетов.

А вот о том, как же мы реализовали в "Техническом проекте" САПРа второго поколения новую парадигму "автоматизации технологического проектирования", пытаясь уже техническими решениями ответить на злополучный для нас вопрос "зачем, всё-таки, козе баян?", наши Хроники следующей главы.