Применение проектной парадигмы в управлении объектами САПР ТП ковки на прессах

С.В. Арзамасцев,
с.н.с., к.т.н., доц., sav@imach.uran.ru
ИМАШ УрО РАН, г.Екатеринбург

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

The proposed design method for storing and processing information in the computer-aided design of technological processes of forging on presses. The design paradigm allows to represent all information about the designed objects in compact, visual form and to increase the efficiency of management objects in the design process.

Опыт разработки системы автоматизированного проектирования технологических процессов ковки молотовых поковок, внедрённой на ОАО Уральский турбинный завод [1], высветил её достоинства и недостатки и позволил перейти на более высокий уровень организации системы. Таким образом, появилось понимание в необходимости проектной организации системы и многодокументного интерфейса по типу MDI (Multiple Document Interface).

Проектная парадигма заключается в информационном объединении трёх основных объектов проектирования: детали, поковки и описания технологического процесса – в одну сущность, рассматриваемую совместно, которая и названа проектом. Проект идентифицируется своим обозначением, которое переносится с чертежа детали, как базового объекта. Каждый экземпляр проекта может содержать множество различных вариантов деталей того же самого обозначения (наименования), на каждую из которых может быть спроектировано множество поковок, а на каждую поковку множество различных технологических процессов [2]. Таким образом проекты можно представить, как ветви на стволе дерева, состоящие из ветвей-побегов (детали), из которых произрастают более мелкие ветви (поковки) с листьями (технологические процессы). Все дочерние объекты наследуют свойства своих родительских объектов. Предлагаемый подход решает проблемы учёта и разработки технологической документации в единичном и мелкосерийном производстве, когда машиностроительные изделия изготавливаются мелкими партиями (комплектами) и постоянно подвергаются модернизации и улучшению своих эксплуатационных характеристик без кардинального изменения в технической документации, с сохранением присвоенных деталям обозначений для модернизируемых изделий. В конструкторской документации изменения в чертежах деталей и сборочных единиц оформляются в виде извещений, в которых указываются новые размеры и требования взамен предыдущих, но без замены обозначения (номера) самой детали в конструкторской документации (чертеже детали и спецификации на сборочную единицу). В извещениях об изменениях указывают, на какие комплекты изделий распространяются данные изменения. Несоблюдение требований извещений об изменении может приводить к непредсказуемым последствиям при эксплуатации изделий, например, к отмене запуска космического корабля или выходу из строя прокатного стана, что, в свою очередь, может повлечь за собой большие материальные затраты и катастрофические последствия. Каждое извещение об изменении в информационном плане связывается с определённым номером варианта детали. Если изменённые параметры детали требуют разработки новой поковки, то в системе сначала создаётся новый вариант детали, а на него уже конструируется своя поковка.

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

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

Таким образом, ясно, что система автоматизированного проектирования должна быть построена как система с проектной парадигмой, при которой пользователь системы имеет возможность видеть чёткую информацию по проектируемым объектам и их состояниям в комплексе и взаимосвязи. Для реализации данной идеи в интерфейс системы включено дерево проектов (рис.1), построенное на основе таблицы-представления, которая в свою очередь собрана из таблиц для объектов: деталь, поковка, техпроцесс. Как видим, дерево проектов даёт наглядную, исчерпывающую информацию о проектах и состояниях входящих в проекты объектов. Например, вал – тест с обозначением 00.11.27.04.2016 состоит из шести вариантов деталей, на первую деталь спроектированы две поковки с вариантами 1 и 5, на поковку с вариантом 1 в стадии проектирования существует техкарта тоже с вариантом 1, на поковку с вариантом 5 окончательно спроектирована техкарта с вариантом 4, имеющая регистрационный номер 20167. Все объекты первой детали, кроме неё самой, находятся в архивном состоянии, т.е. временно исключены из состояния производства и поэтому не отображаются на других формах, предусмотренных для работы с актуальными объектами. Деталь 1111 «Болт специальный М48 лев.» находится в состоянии «АНН», что означает «аннулирована». Аннулированные объекты, как правило, сняты с производства, но остаются в базе данных для просмотра при необходимости или для копирования при создании аналогичных объектов. Напомним, что каждому варианту объекта (детали, поковке, карте технологического процесса) сопоставлено конкретное извещение об изменении с указанием номеров комплектов, на которые распространяется данное извещение. Это позволяет осуществлять автоматический контроль выдачи соответствующей технологической документации непосредственно в цех предприятия и таким образом предотвращать ситуации изготовления продукции, не соответствующей извещениям об изменениях.

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

Рис.1 Дерево проектов (слева) и базовая таблица-представление (справа)

Одним из важнейших аспектов управления системы является возможность перевода объектов проектирования в различные состояния по фактору визуализации и доступа к ним [3]. Разработано 4 вида состояний объектов:

1. актуальное – объекты (детали, поковки, техкарты) в данный момент времени находятся в стадии изготовления;

2. архивное – объекты, которые в данный, конкретный момент времени не подлежат изготовлению на предприятии;

3. аннулированное – объекты окончательно сняты с производства, но документация на них сохраняется в базе данных;

4. удалённое - объекты, удалённые из базы данных.

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

Рис.2 Взаимодействие и коды перевода состояний объектов проектирования

Для управления объектами разработаны исчерпывающие методы, относящиеся к интерфейсу системы. Здесь и выделения по условиям, и сортировки, и поиск по различным атрибутам. Поскольку система сама является большим и сложным программным комплексом, то возникла необходимость выделить те типовые задачи управления, которые не зависели бы от конкретного плана работы пользователя. Ряд таких задач вынесен для решения средствами, предоставляемыми СУБД. Так, для многих задач разработаны триггеры, т.е. программы, инициируемые и выполняющиеся непосредственно в базе данных. В табл.1 представлен список триггеров и реализуемых с их помощью функций. В качестве примера приведён текст запроса для триггера автоматического присвоения номера технологической карте ковки после заполнения её технологом, специалистом по термообработке, нормировщиком и утверждения главным металлургом предприятия (или уполномоченным на то лицом). Данные специалисты работают с картой технологического процесса в клиент-серверной системе предприятия. Обмен информацией происходит через базу данных. Таким образом, вынесение управлением отдельных задач непосредственно в СУБД позволяет решать эти задачи независимо от пользователей, что является элементом защиты и повышает корректность и надёжность системы в целом.

Таблица 1

Перечень триггеров и выполняемых ими функций

Триггер	Функция
DT_CORRECT	Запоминание даты и времени последней корректировки
DT_CREATE	Запоминание даты и времени создания объекта
IZM_VAR	Изменение номера варианта объекта при вводе нового и совпадении обозначения с имеющимся в БД
IZM_KOD	Заполнение поля «Код родительского объекта» в таблице дочернего объекта при совпадении обозначений и номеров вариантов объектов в обеих таблицах: родительской и дочерней
IZM_AKT_TK	Перевод существующей техкарты из актуального в архивное состояние при создании новой для той же поковки
NTK_IN_UP_INTK	Автоматическое присваивание номера карте технологического процесса ковки при условии утверждения её главным металлургом. Текст триггера:

Одной из сложнейших задач при создании системы является концептуализация основных принципов взаимодействия объектов. Поскольку прессовая ковка в значительной степени отличается от молотовой ковки по степени детализации процесса и характеризуется наличием большого числа дополнительных параметров, которые приводят к разработке новых объектов, важно согласовать концепции и действия при разработке программного обеспечения. Не приняв концептуально основные идеи и методы интегрированной системы (проектной парадигмы), трудно, а зачастую невозможно обеспечить корректную интеграцию подсистемы проектирования технологии ковки на прессах в общую канву интерфейса САПР ТП ковки.

Приведём основные концептуальные положения, применённые к некоторым ключевым параметрам объектов:

1. при рождении (создании) нового экземпляра объекта (детали, поковки, карты технологического процесса) он должен быть идентифицирован постоянным признаком, который не должен изменяться вплоть до исчезновения (уничтожения) данного объекта. Иными словами, постоянный признак (параметр) должен быть неизменным на протяжении всего жизненного цикла объекта. В качестве такого постоянного признака принято сочетание обозначения объекта (совпадающего с обозначением проекта) и варианта объекта. Если говорить о таблицах базы данных, в которых хранятся объекты, то жизненный цикл объекта должен определяться одной и той же записью в таблице. Все корректировки в процессе проектирования должны записываться в ту же самую строку таблицы, которая была создана в первоначальный момент. Важность данного положения диктуется необходимостью обеспечивать ссылочную целостность и логическую последовательность в процессе проектирования;

2. создание нового объекта с тем же обозначением должно сопровождаться присвоением объекту варианта, ещё не содержащегося в данной таблице для данного обозначения. Присвоение вариантов новым объектам рационально выполнять непосредственно в базе данных средствами программирования СУБД (см. триггер NTK_IN_UP_INTK в табл.1);

3. при корректировке параметров объекта, изменяющих какие-либо параметры родительских и дочерних объектов, они должны быть согласованы (не противоречить) с родительским и дочерним объектами. В противном случае создаётся новый вариант объекта;

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

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

В заключение следует сказать, что проектная парадигма и возможность управления объектами при разработке САПР ТП ковки на прессах позволяет подготовить систему к интеграции с системами документооборота более высокого уровня, отвечающими в целом за технологическую подготовку производства в соответствии с планируемыми сроками и возможностью контроля и выдачи директивных указаний подразделениям предприятия. В частности, проектная парадигма используется в САПР нового поколения [4], позволяющих использовать ранее разработанные технологические процессы для автоматической настройки и адаптации к условиям реального производства.

Работа выполнена при поддержке гранта РФФИ №16-07-00597_а.

Литература

1. Коновалов А.В., Арзамасцев С.В., Шалягин С.Д., Муйземнек О.Ю., Гагарин П.Ю. Интеллектуальная САПР технологических процессов ковки валов на молотах // Заготовительные производства в машиностроении. 2010. № 1. С.20-23.

2. Арзамасцев С.В., Муйземнек О.Ю. Методы учёта многовариантности разрабатываемых документов в локальных САПР технологических процессов ковки // Заготовительные производства в машиностроении. 2009. № 6. С.19-22

3. Арзамасцев С.В., Муйземнек О.Ю. Актуализация и архивирование объектов проектирования в САПР технологических процессов ковки // Программные продукты и системы. 2008. № 3(83). С.69-72.

4. Арзамасцев С.В., Гагарин П.Ю., Коновалов А.В. Проектная парадигма и интерфейс в гибридной САПР технологического процесса кузнечного производства // Программные продукты и системы. 2013. № 2(102). С.215-220.