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

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

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

«НЕТ НИЧЕГО ПРАКТИЧНЕЕ ХОРОШЕЙ ТЕОРИИ»

Для успеха любого инженерного поиска уже изначально, образно говоря, важно «ПРАВИЛЬНО ВЪЕХАТЬ», постараться избежать ошибок глобального, принципиального характера.
В противном случае, искоренить которые в дальнейшем будет чрезвычайно трудно – длительно и затратно, а подчас практически и невозможно.
В конце концов, может потребоваться опять все начать с начала.

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

Первоначально в нашей группе оказалось семь человек, но вскоре мы надолго остались лишь вчетвером.
Группой руководил старший инженер Александр Петрович Суворов, лишь немногим старше меня.

Нам повезло, что в тот момент во главе группы, из всех нас был именно Александр.
Ещё молодой специалист, но уже с явными задатками и способностями к теоретическим исследованиям.
На его рабочем столе всегда лежали книги из новых поступлений, в основном по вопросам системного подхода, системного анализа и общей теории систем.
Благо, что в начале 70-х эта научная тематика, уверенно, наравне с искусственным интеллектом и кибернетикой, вошла в ТОП научных публикаций.

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

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

Концепция (от латинского, conceptio) – как понимание, единый замысел, ведущая мысль.
Замысел, который по мнению «разработчиков» и способен привести к решению поставленной задачи.
 
Напротив, «парадигма» (от греческого слова) – это пример, модель, образец.
Считаю, что лучшее, или по крайней мере более понятное, определение «парадигме» дал Томас Кун - американский историк и философ науки, в нашумевшей в 70-х годах его работе "Структура научных революций".
Т. Кун: «Под парадигмами я подразумеваю признанные всеми научные достижения, которые в течение определенного времени дают модель постановки проблем и их решений».
Другими словами, парадигма – точка зрения, определенный способ видения проблемы и путей её решения.
Некий психологически предопределенный «коридор» мысленных усилий, главенствующий на какое-то время в умах большинства исследователей.

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

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

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

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

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

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

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

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

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

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

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

Хотя наши коллеги, как и мы, по-прежнему СЧИТАЛИ ПЕРЕВОД С РУЧНОГО "ИЗГОТОВЛЕНИЯ" ТЕХНОЛОГИЧЕСКОЙ ДОКУМЕНТАЦИИ НА МАШИННЫЙ СПОСОБ, СВОЕЙ ГЛАВНОЙ ЗАДАЧЕЙ, но её решение уже видели по-разному.

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

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

Павел Морозов, напротив, считал, что необходимо сохранять максимальную «автономность» строк-переходов, которая наверняка придаст САПРам и максимальную технологическую универсальность.

Как показала дальнейшая история развития САПРов, – автоматизированного проектирования как конструкций изделий, так и технологических процессов их изготовления, эти подходы самолетчиков из Куйбышева и Казани оказались вполне жизнеспособными, оправдавшие себя вплоть до наших дней.

Подход, к которому ещё в 70-х годах пришел Г. Моссоулин, в настоящее время в САПРах известен, как метод параметрического моделирования.
Мы его тоже использовали, но только гораздо позже, уже в версии нашего технологического САПРа на персоналках.

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

Оправдался и подход Павла Морозова, все известные мне современные редакторы технологического назначения, построены именно на этих принципах.

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

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

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

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

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

По этим основаниям, все наши разработки, с появлением стандартов Единой Системы, велись с обязательным условием выполнения их требований, а сами стандарты для нас оказались своевременным и очень основательным подспорьем.

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

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

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

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

А вот с разработкой алгоритма «проектирования» всё оказалось гораздо сложнее.
И тому было несколько серьезных причин.

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

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

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

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

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

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

К этим категориям мы отнесли "порядки сборки", "технологические последовательности" и отношения «следования и предшествования» в их структурах.

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

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

И вот тут, размышляя, а как же, всё-таки умудриться нашему алгоритму «уже самостоятельно детализировать …», мы впервые столкнулись с одной из ключевых, таковой являющейся и в наши дни, для науки «Искусственного интеллекта» проблемой - представления и обработки ЗНАНИЙ.
Её суть состоит "в несоответствии между сведениями о предметной области, имеющихся у специалистов, и возможностями формального представления и обработки такой информации в ЭВМ".

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

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

Однако, ещё в 1969 году, в одном из учебных пособий Московского авиационно-технологического института (МАТИ), впервые в отечественном самолетостроении, сотрудники кафедры "Технологии производства летательных аппаратов" во главе с Виктором Владимировичем Павловым для формализации структур технологических процессов уже предложили теорию графов.
На то время это был весьма продуктивный подход, сочетавший выразительность и простоту формализации технологических процессов, с визуализацией структурных особенностей их построения.
У нас это пособие тоже было и, естественно, мы с ним были знакомы.

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

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

Таким образом, уже в 1975 году мы и получили первые для себя модели представления технологических знаний в ЭВМ, выполненные в виде ориентированного графа, в котором строки-переходы были вершинами, а технологические последовательности (отношения) отражались его дугами.
Естественно, все наши законченные разработки документировались официальными техническими отчетами по НИОКР, правда, как правило, они носили "закрытый" характер.

В последствии, подобные модели получили название "семантических" (смысловых) сетей.
Это понятие появилось в журнале Scientific American в мае 2001 года, его ввёл Сэр Тимоти Джон Бернерс-Ли — британский учёный, создатель Всемирной паутины (World Wide Web).

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

В части собственно программирования по готовым алгоритмам, я не видел для нас каких-либо серьёзных проблем, потому как, еще учась в институте в одном из городских академических институтов, самому пришлось самостоятельно познакомиться и немного освоить и программирование на алгоритмическом языке, им был «Алгол-60» для ЭВМ БЭСМ-6.

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

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

Удручало отсутствие в институте собственной вычислительной машины, хотя бы и такой, как на базовом заводе ЭВМ «Минск-32» еще второго поколения.
По условиям хоздоговора с нашим заводом, в части его плана совместных работ, он обязывался предоставлять нам машинное время, но … только в объеме одного часа времени на период обеденного перерыва заводчан.
А это - лишь 5 часов в неделю при нашей-то потребности в пять часов в день!

С того времени и до завершения наших разработок по технологическим САПРам работы над их программными комплексами преимущественно вели лишь два инженера-разработчика: Л.С. Макавецкене и А.Е. Белоножко.

Лидия Семеновна Макавецкене, выпускница ХАИ, «самолетчица», инженер-плазовик, до нас уже успевшая поработать и на серийном заводе, в создание наших пионерских САПРов внесла свой огромный личный вклад.
В начале, самостоятельно освоив лишь «Фортран», а за последующие десятилетия выросла высококлассного программиста, одного из ведущих разработчиков нашей группы.

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

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

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

Каким может быть принципиальное построение программного комплекса технологического САПРа, мы поняли практически сразу.
Ведь его построение, что называется, было-то предопределено заранее: нашим собственным видением «машинного проектирования» и процессом обработки данных на ЭВМ, причем, конкретно на «Минск-32».

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

До написания уже программ на «Фортране», мы окончательно определились со структурой и формой представления данных, исходных для расчета на ЭВМ.
Так для технологов, вопреки сложившемуся у них порядку разработки технологической документации, появилась от нас «незаконнорожденная» - «Карта исходной информации» (КИИ).
Ею стала таблица с перечнем деталей узла, записанных «столбиком» в порядке сборки, и с кодами основных технологических "блоков-мазков".
Кроме того, по каждой детали задавался некоторый переменный набор данных, как «параметров» необходимых для работы подпрограмм комплекса.

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

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

После этого, безусловно знаменательного для нас события, буквально через две недели, моя история с технологическими САПРами прервалась.
Уже 6 сентября того же года, я оказался в Краснознаменном Восточном Округе, но не инженером-разработчиком, а на действительной службе двухгодичником, лейтенантом пограничных войск КГБ СССР в горах Восточного Памира.