Самарский портал "Технологии, компьютеры"

« « Я помню это чудное мгновенье » »

В.С.Высоцкий

20 ноября в самарском Доме актёра компания Аскон проводила VIII-ой традиционный Поволжский Форум «Современные технологии автоматизации производства 2003».

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

Программистам (автоматизаторам) всегда представлялось, что конструктор в основном чертит, да ещё производит расчёты. И пока автоматизация конструкторского труда была полностью в руках программистов (ну, все эти отделы САПР), автоматизировался лишь процесс черчения. Чертежи распечатывались и сдавались в обычный бумажный архив. Примерно как в той байке начала ХХ века, про то, что в Америке детей делают при помощи пара и электричества (1). Это было победное шествие «Компас-график». Главное: начальнички, никогда за компьютером не работавшие, были убеждены, что теперь их контора находится на острие прогресса.

Фактически сколько-нибудь серьёзной автоматизации так и не случилось. И всё же польза от двумерной графики была: после того, как было автоматизировано движение рук, программисты поняли, что конструктор работает ещё и головой. Но поскольку (по мнению программистов) работа конструктора заключается в вычерчивании проекций, то, видимо, в голове у него как раз и формируются трёхмерные модели этих деталей. А тут как раз подоспело компьютерное 3D (dimension): видеокарты, игры, средства разработки. Было создано трёхмерное моделирование с отображением проекций модели – «Компас-3D». Жить стало лучше, жить стало веселее. Если пакеты плоской графике «понимали» только разрозненные линии, то и связей между проекциями чертежа для них не существовало. Можно было начертить на виде сверху чайник, а на главном виде – кастрюлю, и система всё это послушно воспринимала. С 3D графикой всё иначе. Любая проекция теперь – это именно проекция, и у неё есть хозяин: трёхмерная модель. Значит, и изменения этой модели сразу же отображаются на всех её проекциях (видах, разрезах, сечениях). Если уж конструктор приделал кастрюле носик, то теперь на всех проекциях будет чайник – и никаких компромиссов.

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

В это же время другие программисты автоматизировали труд технологов. Ход автоматизации был примерно таким же «лобовым», как и для конструкторов. Что там технолог ваяет? Карты техпроцесса? Ну, вот вам автоматизация разработки карт техпроцесса в лице системы «Автопроект».

Автоматизированные системы управления производством тоже как-то жили и развивались. Но не столь интенсивно, а главное – не так зрелищно, как авточерчение.

И постепенно все эти фрагменты автоматизации в своём развитии дошли до своих тупиков.

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

Есть вечные книги, например, Библия. Много веков люди читают её и черпают истину. Для конструктора таким же откровением является ЕСКД – единая система конструкторской документации. Так вот, похоже на то, что программисты, наконец, дочитали ЕСКД до того места, где написано, что основным конструкторским документом для сборочной единицы (3) является спецификация (4). Спецификация в системе «Компас» формировалась, но там она была лишь иллюстрацией (довеском) к сборочному чертежу, а никак не основные.

Тут как чёрт из коробочки появляется курганская разработка, именуемая сначала скромно «Компас-менеджер», а затем уже гордо и независимо «Лоцман».

И становится флагманским продуктом, а разработки Аскона позиционируются как «Решения для создания и управления инженерными данными». Пропагандируется «Построение интегрированных систем на базе ЛОЦМАН:PLM и КОМПАС V6».

Всё встало с головы на ноги: конструктор теперь не просто чертит. Теоретически он может совсем не чертить (5). Он делает главное: спецификациями изделий (6) формирует основную часть базы данных предприятия. Образно говоря, спецификации — это скелет, на который потом нарастает мясо, кожа и всякий другой жир в виде технологий, планов выпуска, заказов собственным цехам и сторонним поставщикам. И вся эта расчленёнка чудесным образом превращается в единый живой организм.

Решается главная проблема АСУПа: теперь за ввод данных в базу отвечает сам автор - конструктор. Он же распечатывает эти данные (спецификации) и расписывается на них (7).

Проблемы взаимоотношений конструкторов и технологов переходят в ту плоскость, где их, наконец, можно решить. Поясню: технологи традиционно не обращали внимания на то, как конструктор структурировал изделие и разрабатывали для него свою иерархию. Например, в конструкторскую спецификацию автомобиля КамАЗ на равных входят три его оси. А технология производства требует промежуточной сборочной единицы в виде тележки из задней и средней оси. И вот уже тридцать лет эта тележка, никоим образом не отражённая в конструкторской документации (и, соответственно, никак не обозначенная), изготавливается и поставляется на главный конвейер. Этакое изделие-призрак. При внедрении единой базы технологи запросто выломают конструкторам руки и заставят их привести иерархию спецификаций к реальному положению вещей на предприятии. Другими словами, по конструкторской документации теперь можно будет изготавливать изделие (8).

И автоматизация проектирования станет частью (первой, или главной, как хотите) автоматизации предприятия.

Здорово? Почти. Отдельное изделие действительно имеет иерархическую древовидную структуру, похожую на файловую систему диска, отображаемую проводником Windows. А вот совокупность выпускаемых предприятием изделий уже не описывается списком логических дисков с их папками, поскольку одни и те же узлы могут входить в разные изделия. Упомянутая камазовская тележка может быть частью как тягача, так и самосвала. И от любой промежуточной сборочной единицы можно построить как «дерево вниз» (классические спецификации), так и «дерево вверх» - её «входимости». И хотя с самим этим фактом никто спорить не будет, увидеть конструкторский архив не как набор иерархий, а как реляционную базу – задача нетривиальная. И требующая, как минимум, отказа от многих стереотипов, включая систему конструкторских обозначений. Ведь классическое конструкторское обозначение строится именно по иерархической схеме ФИРМА. АВТОМОБИЛЬ. 000. 000. 000. Нули в обозначении введены для единства формата, при этом количество уровней определяется стандартами предприятия или отрасли. На более низких уровнях нули заменяются значениями: ФИРМА. АВТОМОБИЛЬ. ДВИГАТЕЛЬ. ПОРШЕНЬ. КОЛЬЦО. То есть система обозначений подразумевает, что поршень разрабатывается для конкретного двигателя конкретного автомобиля (9). И упомянутая камазовская тележка отсутствовала в документации не по лени или глупости конструкторов, а только потому, что для неё не хватило уровня и конструктор просто не смог её обозначить. Так же, как в приведённом примере нет места для сборочной единицы ПОРШНЕВАЯ ГРУППА.

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

Ведь Лоцман + Компас хорош или плох не сам по себе. Важнее другое: насколько удовлетворяет он требованиям заказчика?

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

======

(1) Берётся пара, выключается электричество, а дальше всё по-старому.

(2) На самом деле формирование образа модели и её отображение – процесс итерационный, поскольку сложную модель (деталь) сформировать исключительно в голове не сможет ни один конструктор. Ситуация примерно такая же, как и в работе со многими числами.

(3) А также комплекса и комплекта.

(4) ГОСТ 2.102-68 (1995) пункт 2.2.

(5) В 1985 году на Куйбышевском станкостроительном производственном объединении была внедрена система проектирования гидроблоков с выводом документации на АЦПУ (это вроде пишущей машинки). Несмотря на практическое отсутствие чертежей, система выполняла свои функции и передавала данные интегрированной системе.

(6) И атрибутами самих изделий: масса, вид поставки, материал – это тоже конструкторские данные.

(7) До безбумажной технологии и электронных подписей дело дойдёт естественным путём.

(8) Один из руководителей Курганского автобусного завода на совещании по внедрению интегрированной системы в 1993 году высказался так: мне не нужна конструкторская документация, по которой невозможно изготовить изделие. А потом добавил: и конструктора, которые делают такую документацию.

(9) Конструкторская практика допускает заимствование изделий, но сами конструктора этого очень не любят. Представьте себе, что разработчик поршня увеличил на 1мм его диаметр, не забыв, разумеется, и про свой цилиндр. А конструктор, позаимствовавший поршень, узнал об этом изменении только на ковре у начальника, куда его вызвали по случаю остановки конвейера – поршни не лезут в цилиндры.