Программные продукты и системы

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

Внедрение PDM/PLM-систем, составляющих основу CALS-технологий, для многих предприятий является сложной задачей, связанной с организационной перестройкой всей инженерной структуры и с большими материальными затратами. Эти процессы осложняются из-за отсутствия на предприятиях достаточного количества подготовленных специалистов по CALS-технологиям. Локальные САПР ТП значительно дешевле и проще в освоении и использовании по сравнению с PDM/PLM-системами. Наделение их некоторыми возможностями PDM/PLM-систем позволило бы решить часть проблем, связанных с управлением процессом технологической подготовки производства.

Одной из главнейших задач CALS-технологии является управление документооборотом, учитывающим актуальность разрабатываемой конструкторской и технологической документации. Суть проблемы заключается в том, что для одной и той же конечной детали возможны различные варианты ее изготовления. Кроме того, деталь может иметь конструктивные различия без изменения атрибутов (ее наименования, обозначения и т.д.). Вопрос решается с помощью извещений об изменении, в которых конкретно указывается, какие происходят изменения в чертеже и на какие комплекты они распространяются. В этом случае зачастую приходится разрабатывать различные варианты технологических процессов.

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

1.   Рассмотрим постановку задачи актуализации и архивирования объектов проектирования и ее решение на примере разработки технологических процессов для ковки поковок типа ступенчатых валов (см.: Коновалов А.В., Арзамасцев С.В., Муйземнек О.Ю. и др. Новые принципы разработки САПР ТП ковки. // Кузнечно-штамповочное производство. – 2007. – № 1).

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

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

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

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

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

Для формализации алгоритмов перевода состояний классы объектов и состояний представлены в виде трехмерной модели (рис. 3). Разработанная модель реализует структуру данных и управление ходом вычислительного процесса с помощью данных. Условно модель показана в виде параллелепипеда, состоящего из горизонтальных и вертикальных слоев наподобие известной игрушки кубик Рубика. Фронтальные вертикальные слои представляют набор объектов проектирования всех трех классов (детали, поковки, техпроцессы) всех четырех состояний с одинаковым обозначением и номером варианта. Профильные вертикальные слои представляют собой множество объектов только одного класса, но для всех состояний и вариантов. Горизонтальные слои объединяют множество вариантов объектов всех классов по признаку нахождения в одном из четырех возможных состояний. Из-за того что число вариантов деталей не равно числу вариантов поковок, а число вариантов поковок не равно числу вариантов техпроцессов, в модели могут отсутствовать отдельные элементарные столбики (см. рис. 3). Таким образом, каждый параллелепипед можно считать экземпляром информационной модели объектов и состояний для самого старшего родительского объекта – детали, идентифицирующимся в пространстве всех деталей своим обозначением или номером чертежа. Все информационное пространство можно представить в виде комплекта сотен и тысяч параллелепипедов в зависимости от числа деталей, участвующих в информационном процессе.

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

Технология программной реализации основывалась на методе программирования таблиц решений. Наличие кружка в слое параллелепипеда «объект–состояние» соответствует ситуации истинности условия «Объект < деталь | поковка | техпроцесс > находится в состоянии < актуальном | архивном | аннулированном | удаленном>». Попытка перевода объекта в другое состояние является событием, которое инициирует обработчик проверки условий таблицы решений. При выполнении определенного условия вызывается метод, переводящий другие объекты того же наименования и обозначения в состояния, соответствующие новому состоянию исходного объекта. Например, при попытке перевести деталь из актуального состояния в архив (см. рис. 3) проверяется состояние дочернего объекта – поковки. Так как поковка находится в более высоком состоянии (актуальном), она переводится в архив. Перевод поковки в архив инициирует метод проверки состояния техпроцесса. Поскольку техпроцесс является актуальным, он также переходит в архив. В результате все объекты переведутся в архивное состояние.

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

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

1)  перевод объектов проектирования в более низкие состояния нужно начинать с последних дочерних объектов;

2)  перевод в более высокие состояния нужно начинать с родительских объектов.

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

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